🎨 markdownlint.

.vscode/settings.json

@@ -12,8 +12,9 @@
         "MD014": false,
         "MD026": false,
         "MD033": {
-            "allowed_elements": ["img", "span", "sup", "a"]
+            "allowed_elements": ["img", "span", "sup", "a", "div"]
         },
+        "MD034": false,
         "MD041": false
     }
 }

FRENCH/src/ch06-02-match.md

@@ -4,6 +4,7 @@
 -->
 
 <a id="la-structure-de-contrôle-match"></a>
+
 ## La structure de contrôle de flux `match`
 
 <!--

FRENCH/src/ch11-02-running-tests.md

@@ -20,8 +20,8 @@ tests qu'il produit. Vous pouvez rajouter des options en ligne de commande pour
 changer le comportement par défaut de `cargo test`. Par exemple, le
 comportement par défaut des binaires produits par `cargo test` est de lancer
 tous les tests en parallèle et de capturer la sortie pendant l'exécution des
-tests, ce qui lui évite d'être affichée sur l'écran pendant ce temps, facilitant 
-la lecture des messages relatifs aux résultats de l'exécution des
+tests, ce qui lui évite d'être affichée sur l'écran pendant ce temps,
+facilitant la lecture des messages relatifs aux résultats de l'exécution des
 tests.
 
 <!--
@@ -116,9 +116,10 @@ state.
 -->
 
 Nous avons réglé le nombre de tâches à `1`, ce qui indique au programme de ne
-pas utiliser le parallélisme. Exécuter ces tests en n'effectuant qu'une seule tâche
-à la fois va prendre plus de temps que de les lancer en parallèle, mais cela assure que
-les tests ne vont pas s'influencer mutuellement s'ils partagent le même état.
+pas utiliser le parallélisme. Exécuter ces tests en n'effectuant qu'une seule
+tâche à la fois va prendre plus de temps que de les lancer en parallèle, mais
+cela assure que les tests ne vont pas s'influencer mutuellement s'ils partagent
+le même état.
 
 <!--
 ### Showing Function Output

FRENCH/src/ch11-03-test-organization.md

@@ -189,9 +189,9 @@ module. Comme nous l'avons vu dans [la section "Désigner un élément dans
 l'arborescence de modules"][paths]<!-- ignore -->, les
 éléments dans les modules enfants peuvent utiliser les éléments dans leurs
 modules parents. Dans ce test, nous importons dans la portée tous les éléments
-du parent du module `test` grâce à `use super::*;`, permettant ensuite au test de 
-faire appel à `addition_interne`. Si vous pensez qu'une fonction privée ne doit
-pas être testée, il n'y a rien qui vous y force avec Rust.
+du parent du module `test` grâce à `use super::*;`, permettant ensuite au test
+de faire appel à `addition_interne`. Si vous pensez qu'une fonction privée ne
+doit pas être testée, il n'y a rien qui vous y force avec Rust.
 
 <!--
 ### Integration Tests
@@ -233,9 +233,9 @@ can then make as many test files as we want to in this directory, and Cargo
 will compile each of the files as an individual crate.
 -->
 
-Nous créons un dossier *tests* au niveau le plus haut de notre dossier 
-projet, juste à côté de *src*. Cargo sait qu'il doit rechercher les fichiers de
-test d'intégration dans ce dossier. Nous pouvons ensuite construire autant de
+Nous créons un dossier *tests* au niveau le plus haut de notre dossier projet,
+juste à côté de *src*. Cargo sait qu'il doit rechercher les fichiers de test
+d'intégration dans ce dossier. Nous pouvons ensuite construire autant de
 fichiers de test que nous le souhaitons dans ce dossier, et Cargo va compiler
 chacun de ces fichiers comme une crate individuelle.
 
@@ -315,9 +315,9 @@ Listing 11-12) and then a summary line for the unit tests.
 
 Les trois sections de la sortie concernent les tests unitaires, les tests
 d'intégration et les tests de documentation. La première section relative aux
-tests unitaires est la même que celle que nous avons déjà vue : une ligne pour chaque test
-unitaire (celui qui s'appelle `interne` que nous avons inséré dans l'encart
-11-12) suivie d'une ligne de résumé des tests unitaires.
+tests unitaires est la même que celle que nous avons déjà vue : une ligne pour
+chaque test unitaire (celui qui s'appelle `interne` que nous avons inséré dans
+l'encart 11-12) suivie d'une ligne de résumé des tests unitaires.
 
 <!--
 The integration tests section starts with the line `Running

FRENCH/src/ch12-03-improving-error-handling-and-modularity.md

@@ -62,10 +62,10 @@ Le troisième problème est que nous avons utilisé `expect` pour afficher un
 message d'erreur lorsque la lecture du fichier échoue, mais le message affiche
 uniquement `Quelque chose s'est mal passé lors de la lecture du fichier`. Lire
 un fichier peut échouer pour de nombreuses raisons : par exemple, le fichier
-peut ne pas exister, ou parce que nous n'avons pas le droit de l'ouvrir. Pour le moment,
-quelle que soit la raison, nous affichons le message d'erreur `Quelque chose
-s'est mal passé lors de la lecture du fichier`, ce qui ne donne aucune
-information à l'utilisateur !
+peut ne pas exister, ou parce que nous n'avons pas le droit de l'ouvrir. Pour
+le moment, quelle que soit la raison, nous affichons le message d'erreur
+`Quelque chose s'est mal passé lors de la lecture du fichier`, ce qui ne donne
+aucune information à l'utilisateur !
 
 <!--
 Fourth, we use `expect` repeatedly to handle different errors, and if the user
@@ -280,12 +280,13 @@ other and what their purpose is.
 Un autre signe qui indique qu'il y a encore de la place pour de l'amélioration
 est la partie `config` de `interpreter_config` qui sous-entend que les
 deux valeurs que nous retournons sont liées et font partie d'une même valeur de
-configuration. Or, à ce stade, nous ne tenons pas compte de cela dans la 
-structure des données que nous utilisons si ce n'est en regroupant les deux valeurs dans un
-tuple ; nous pourrions mettre les deux valeurs dans une seule structure et
-donner un nom significatif à chacun des champs de la structure. Faire ainsi
-permet de faciliter la compréhension du code par les futurs développeurs de ce
-code pour mettre en évidence le lien entre les deux valeurs et leurs rôles respectifs.
+configuration. Or, à ce stade, nous ne tenons pas compte de cela dans la
+structure des données que nous utilisons si ce n'est en regroupant les deux
+valeurs dans un tuple ; nous pourrions mettre les deux valeurs dans une seule
+structure et donner un nom significatif à chacun des champs de la structure.
+Faire ainsi permet de faciliter la compréhension du code par les futurs
+développeurs de ce code pour mettre en évidence le lien entre les deux valeurs
+et leurs rôles respectifs.
 
 <!--
 Listing 12-6 shows the improvements to the `parse_config` function.
@@ -383,14 +384,13 @@ un compromis qui en vaut la peine.
 > le [chapitre 13][ch13]<!-- ignore -->, vous allez apprendre à utiliser des
 > méthodes plus efficaces dans ce genre de situation. Mais pour le moment, ce
 > n'est pas un problème de copier quelques chaînes de caractères pour continuer
-> à progresser car vous allez le faire une seule fois et les chaînes
-> de caractères `nom_fichier` et `recherche` sont très courtes. Il est plus important 
-> d'avoir un programme
-> fonctionnel qui n'est pas très optimisé plutôt que d'essayer d'optimiser à
-> outrance le code dès sa première écriture. Plus vous deviendrez expérimenté
-> en Rust, plus il sera facile de commencer par la solution la plus
-> performante, mais pour le moment, il est parfaitement acceptable de faire
-> appel à `clone`.
+> à progresser car vous allez le faire une seule fois et les chaînes de
+> caractères `nom_fichier` et `recherche` sont très courtes. Il est plus
+> important d'avoir un programme fonctionnel qui n'est pas très optimisé plutôt
+> que d'essayer d'optimiser à outrance le code dès sa première écriture. Plus
+> vous deviendrez expérimenté en Rust, plus il sera facile de commencer par la
+> solution la plus performante, mais pour le moment, il est parfaitement
+> acceptable de faire appel à `clone`.
 
 <!--
 We’ve updated `main` so it places the instance of `Config` returned by
@@ -720,8 +720,8 @@ make the function conform to its new type signature.
 Nous avons fait deux changements dans le corps de notre fonction `new` :
 plutôt que d'avoir à appeler `panic!` lorsque l'utilisateur n'envoie pas assez
 d'arguments, nous retournons maintenant une valeur `Err`, et nous avons intégré
-la valeur de retour `Config` dans un `Ok`. Ces modifications rendent 
-la fonction conforme à son nouveau type de signature.
+la valeur de retour `Config` dans un `Ok`. Ces modifications rendent la
+fonction conforme à son nouveau type de signature.
 
 <!--
 Returning an `Err` value from `Config::new` allows the `main` function to

FRENCH/src/ch12-04-testing-the-librarys-functionality.md

@@ -192,8 +192,9 @@ et la valeur de retour. Rappelez-vous que dans le
 [chapitre 10][ch10-lifetimes]<!-- ignore --> nous avions vu que le paramètre
 de durée de vie indique quelle durée de vie d'argument est connectée
 à la durée de vie de la valeur de retour. Dans notre cas, nous indiquons que le
-vecteur retourné devrait contenir des slices de chaînes de caractères qui proviennent 
-des slices de l'argument `contenu` (et pas de l'argument `recherche`).
+vecteur retourné devrait contenir des slices de chaînes de caractères qui
+proviennent des slices de l'argument `contenu` (et pas de l'argument
+`recherche`).
 
 <!--
 In other words, we tell Rust that the data returned by the `search` function
@@ -207,9 +208,10 @@ incorrectly.
 Autrement dit, nous disons à Rust que les données retournées par la fonction
 `rechercher` vont vivre aussi longtemps que la donnée dans l'argument `contenu`
 de la fonction `rechercher`. C'est très important ! Les données sur lesquelles
-pointent les slices doivent toujours être en vigueur pour que la référence reste valide ;
-si le compilateur croit que nous créons des slices de `recherche` plutôt que de
-`contenu`, ses vérifications de sécurité seront incorrectes.
+pointent les slices doivent toujours être en vigueur pour que la référence
+reste valide ; si le compilateur croit que nous créons des slices de
+`recherche` plutôt que de `contenu`, ses vérifications de sécurité seront
+incorrectes.
 
 <!--
 If we forget the lifetime annotations and try to compile this function, we’ll
@@ -601,9 +603,9 @@ and output, lifetimes, testing, and command line parsing.
 -->
 
 Très bien ! Nous avons construit notre propre mini-version d'un outil classique
-et nous avons beaucoup appris sur la façon de structurer nos applications. Nous en avons aussi
-appris un peu sur les entrées et sorties des fichiers, les durées de vie, les
-tests et l'interprétation de la ligne de commande.
+et nous avons beaucoup appris sur la façon de structurer nos applications. Nous
+en avons aussi appris un peu sur les entrées et sorties des fichiers, les
+durées de vie, les tests et l'interprétation de la ligne de commande.
 
 <!--
 To round out this project, we’ll briefly demonstrate how to work with

FRENCH/src/ch12-05-working-with-environment-variables.md

@@ -361,14 +361,13 @@ of the other methods we’ve seen on `Result`.
 
 Nous utilisons la méthode `is_err` sur le `Result` pour vérifier si nous obtenons
 une erreur, signalant par conséquent que la variable d'environnement n'est pas
-définie et donc que nous *devons* effectuer une recherche sensible à la casse. 
-Si la variable d'environnement
-`MINIGREP_INSENSIBLE_CASSE` a une valeur qui lui a été assignée, `is_err` va
-retourner `false` et le programme va procéder à une recherche non sensible à
-la casse. Nous ne nous préoccupons pas de la *valeur* de la variable d'environnement,
-mais uniquement de savoir si elle est définie ou non, donc nous utilisons
-`is_err` plutôt que `unwrap`, `expect` ou toute autre méthode que nous avons
-vue avec `Result`.
+définie et donc que nous *devons* effectuer une recherche sensible à la casse.
+Si la variable d'environnement `MINIGREP_INSENSIBLE_CASSE` a une valeur qui lui
+a été assignée, `is_err` va retourner `false` et le programme va procéder à une
+recherche non sensible à la casse. Nous ne nous préoccupons pas de la *valeur*
+de la variable d'environnement, mais uniquement de savoir si elle est définie
+ou non, donc nous utilisons `is_err` plutôt que `unwrap`, `expect` ou toute
+autre méthode que nous avons vue avec `Result`.
 
 <!--
 We pass the value in the `case_sensitive` variable to the `Config` instance so
@@ -450,7 +449,8 @@ PS> Remove-Item Env:MINIGREP_INSENSIBLE_CASSE
 We should get lines that contain “to” that might have uppercase letters:
 -->
 
-Nous devrions trouver cette fois-ci également toutes les lignes qui contiennent “to” écrit avec certaines lettres en majuscule:
+Nous devrions trouver cette fois-ci également toutes les lignes qui contiennent
+“to” écrit avec certaines lettres en majuscule:
 
 <!--
 <!-- manual-regeneration

FRENCH/src/ch12-06-writing-to-stderr-instead-of-stdout.md

@@ -18,8 +18,8 @@ la macro `println!`. Dans la plupart des terminaux, il y a deux genres de
 sorties : la *sortie standard* (`stdout`) pour les informations générales
 et *la sortie d'erreur standard* (`stderr`) pour les messages d'erreur. Cette
 distinction permet à l'utilisateur de choisir de rediriger la sortie des
-messages sans erreurs d'un programme vers un fichier mais continuer à afficher les messages
-d'erreur à l'écran.
+messages sans erreurs d'un programme vers un fichier mais continuer à afficher
+les messages d'erreur à l'écran.
 
 <!--
 The `println!` macro is only capable of printing to standard output, so we
@@ -171,7 +171,7 @@ After changing `println!` to `eprintln!`, let’s run the program again in the
 same way, without any arguments and redirecting standard output with `>`:
 -->
 
-Après avoir changé `println!` en `eprintln!`, exécutons à nouveau le programme 
+Après avoir changé `println!` en `eprintln!`, exécutons à nouveau le programme
 de la même manière, sans aucun argument et en redirigeant la sortie standard
 avec `>` :
 

FRENCH/src/ch13-02-iterators.md

@@ -652,8 +652,8 @@ always starting new instances with a value of 0 in the `count` field.
 La structure `Compteur` a un champ `compteur`. Ce champ contient une valeur
 `u32` qui gardera la trace de l'endroit où nous sommes dans le processus
 d'itération de 1 à 5. Le champ `compteur` est privé car nous voulons que ce soit
-l'implémentation de `Compteur` qui gère sa valeur. La fonction `new` impose 
-de toujours démarrer de nouvelles instances avec une valeur de 0 pour le champ
+l'implémentation de `Compteur` qui gère sa valeur. La fonction `new` impose de
+toujours démarrer de nouvelles instances avec une valeur de 0 pour le champ
 `compteur`.
 
 <!--
@@ -822,7 +822,6 @@ pourrions le faire, comme le montre le test dans l'encart 13-23 :
 methods on our `Counter` iterator</span>
 -->
 
-
 <span class="caption">Encart 13-23 : utilisation d'une gamme de méthodes du
 trait `Iterator` sur notre itérateur `Compteur` </span>
 

FRENCH/src/ch13-04-performance.md

@@ -71,8 +71,8 @@ s'agisse d'une abstraction de haut niveau, sont compilés à peu près comme si
 vous aviez écrit vous-même le code un niveau plus bas. Les itérateurs sont l'une
 des abstractions à *coût zéro* de Rust, c'est-à-dire que l'utilisation de
 l'abstraction n'impose aucun surcoût lors de l'exécution. C'est la même notion
-que celle que Bjarne Stroustrup, le concepteur et développeur original de C++, définit 
-en tant que *coût zéro* dans “Foundations of C++” (2012) :
+que celle que Bjarne Stroustrup, le concepteur et développeur original de C++,
+définit en tant que *coût zéro* dans “Foundations of C++” (2012) :
 
 <!--
 > In general, C++ implementations obey the zero-overhead principle: What you

FRENCH/src/ch14-02-publishing-to-crates-io.md

@@ -106,9 +106,9 @@ in the *target/doc* directory.
 Ici nous avons écrit une description de ce que fait la fonction `ajouter_un`,
 débuté une section avec le titre `Exemples` puis fourni du code qui
 montre comment utiliser la fonction `ajouter_un`. Nous pouvons générer la
-documentation HTML à partir de ces commentaires de documentation en lançant `cargo doc`.
-Cette commande lance l'outil `rustdoc` qui est distribué avec Rust et place la
-documentation HTML générée dans le dossier *target/doc*.
+documentation HTML à partir de ces commentaires de documentation en lançant
+`cargo doc`. Cette commande lance l'outil `rustdoc` qui est distribué avec Rust
+et place la documentation HTML générée dans le dossier *target/doc*.
 
 <!--
 For convenience, running `cargo doc --open` will build the HTML for your
@@ -505,8 +505,8 @@ see them.
 -->
 
 Notez que les types `CouleurPrimaire` et `CouleurSecondaire` ne sont pas listés
-sur la page d'accueil, pas plus que la fonction `mixer`. Nous devons cliquer sur `types`
-et `utilitaires` pour les voir.
+sur la page d'accueil, pas plus que la fonction `mixer`. Nous devons cliquer
+sur `types` et `utilitaires` pour les voir.
 
 <!--
 Another crate that depends on this library would need `use` statements that
@@ -935,9 +935,9 @@ With a unique name, the version, your description, and a license added, the
 *Cargo.toml* file for a project that is ready to publish might look like this:
 -->
 
-Une fois le nom unique, la version, la description et la licence 
-ajoutés, le fichier *Cargo.toml* de ce projet qui est prêt à être publié devrait
-ressembler à ceci :
+Une fois le nom unique, la version, la description et la licence ajoutés, le
+fichier *Cargo.toml* de ce projet qui est prêt à être publié devrait ressembler
+à ceci :
 
 <!--
 <span class="filename">Filename: Cargo.toml</span>

FRENCH/src/ch14-03-cargo-workspaces.md

@@ -625,14 +625,15 @@ in the workspace will be compatible with each other.
 -->
 
 Pour corriger cela, modifiez le fichier *Cargo.toml* pour le paquet
-`additioneur` et indiquez que `rand` est une dépendance de cette crate aussi. La compilation du
-paquet `additioneur` va rajouter `rand` à la liste des dépendances pour
-`additioneur` dans *Cargo.lock*, mais aucune copie supplémentaire de `rand` ne sera
-téléchargée. Cargo s'est assuré que toutes les crates de chaque paquet de
-l'espace de travail qui utilise le paquet `rand` seraient de la même version.
-Utiliser la même version de `rand` dans les espaces de travail économise de
-l'espace car nous n'avons pas à multiplier les copies, ni à nous assurer que les
-crates dans l'espace de travail sont compatibles les unes avec les autres.
+`additioneur` et indiquez que `rand` est une dépendance de cette crate aussi.
+La compilation du paquet `additioneur` va rajouter `rand` à la liste des
+dépendances pour `additioneur` dans *Cargo.lock*, mais aucune copie
+supplémentaire de `rand` ne sera téléchargée. Cargo s'est assuré que toutes les
+crates de chaque paquet de l'espace de travail qui utilise le paquet `rand`
+seraient de la même version. Utiliser la même version de `rand` dans les
+espaces de travail économise de l'espace car nous n'avons pas à multiplier les
+copies, ni à nous assurer que les crates dans l'espace de travail sont
+compatibles les unes avec les autres.
 
 <!--
 #### Adding a Test to a Workspace

FRENCH/src/ch14-04-installing-binaries.md

@@ -18,17 +18,18 @@ binary target, or both.
 -->
 
 La commande `cargo install` vous permet d'installer et utiliser des crates de
-binaires localement. Cela n'est pas conçu pour remplacer les paquets systèmes ; 
+binaires localement. Cela n'est pas conçu pour remplacer les paquets systèmes ;
 c'est plutôt un moyen pratique pour les développeurs Rust d'installer
 des outils que les autres ont partagé sur
 [crates.io](https://crates.io/)<!-- ignore -->. Notez que vous ne pouvez
 installer que des paquets qui ont des destinations binaires. Une *destination
 binaire* est le programme exécutable qui est créé si la crate a un fichier
 *src/main.rs* ou un autre fichier désigné comme binaire, par opposition
-à une destination de bibliothèque qui n'est pas exécutable en tant que telle mais
-qu'il est possible d'intégrer à d'autres programmes. Habituellement, l'information permettant
-de savoir si une crate est une bibliothèque, possède plutôt une destination binaire ou les deux
-à la fois figure dans le fichier *README*.
+à une destination de bibliothèque qui n'est pas exécutable en tant que telle
+mais qu'il est possible d'intégrer à d'autres programmes. Habituellement,
+l'information permettant de savoir si une crate est une bibliothèque, possède
+plutôt une destination binaire ou les deux à la fois figure dans le
+fichier *README*.
 
 <!--
 All binaries installed with `cargo install` are stored in the installation