[docs] FR: typos

doc/fr/developpeurs/checklist-commit.md

-# Liste des éléments a vérifier avant de commiter
+# Liste des éléments à vérifier avant de commiter
 
-- [ ] J'ai supprimé tout les TODO.  
+- [ ] J'ai supprimé tous les TODO.
 - [ ] J'ai utilisé au maximum les traits afin que mon code soit générique.
 - [ ] J'ai évité au maximum l'usage du clonage en passant des références.
 - [ ] J'ai modifié les tests impactés par mes changements.
 - [ ] J'ai créé des tests couvrants les nouvelles fonctionnalités.
-- [ ] Tout les tests automatisés passent bien.  
+- [ ] Tous les tests automatisés passent bien.
 - [ ] Je n'ai pas de warning clippy.
 - [ ] J'ai bien appliqué fmt.
 - [ ] J'ai choisi un nom de commit conforme aux [conventions git du projet](conventions-git.md).
-- [ ] J'ai bien découpé mes changements en plusieurs petits commit atomiques.  
+- [ ] J'ai bien découpé mes changements en plusieurs petits commits atomiques.

doc/fr/developpeurs/conventions-git.md

@@ -4,26 +4,26 @@
 
 ### Branche créée par gitlab
 
-Le plus souvent, votre branche sera nommée automatiquement par Gitlab puisque vous êtes censé créer votre branche en cliquant sur le bouton "Create a merge request" sur de l'issue liée.
-Dans ce cas vous devez préfixer la branche par votre peseudo gitlab suivi d'un slash, exemple :
+Le plus souvent, votre branche sera nommée automatiquement par Gitlab puisque vous êtes censé créer votre branche en cliquant sur le bouton "Create a merge request" sur l'issue liée.
+Dans ce cas vous devez préfixer la branche par votre pseudo gitlab suivi d'un slash, exemple :
 
     elois/2-test-de-ticket
 
 ### Branche créée manuellement
 
-Dans tout les autres cas, votre branche doit impérativement commencée par le pseudo de votre compte gitlab afin que tout un chacun sache qui travaille sur cette branche. Voici la convention a respecter pour les branches que vous créez manuellement :
+Dans tous les autres cas, votre branche doit impérativement commencer par le pseudo de votre compte gitlab afin que tout un chacun sache qui travaille sur cette branche. Voici la convention à respecter pour les branches que vous créez manuellement :
 
     pseudo/type/description
 
 pseudo := pseudo de votre compte gitlab.
 type := voir "Liste des types de commit".
-description := courte description en anglais a l'impératif présent, 3 à 4 mots maximum, pas d'articles.
+description := courte description en anglais à l'impératif présent, 3 à 4 mots maximum, pas d'articles.
 
 Exemple :
 
     elois/ref/rename_module_trait
 
-## Nommage des commit
+## Nommage des commits
 
 Chaque commit doit suivre la convention suivante :
 
@@ -31,11 +31,11 @@ Chaque commit doit suivre la convention suivante :
 
 Le type doit être un mot clé de type parmi la liste des types de commit.
 
-La crate dolit être le nom de la crate concernée par le commit sans le préfixe `durs-`.
+La crate doit être le nom de la crate concernée par le commit sans le préfixe `durs-`.
 
-L'action doit être un verbe a l'impératif et le sujet un nom.
+L'action doit être un verbe à l'impératif et le sujet un nom.
 
-Exemple, renomage d'un trait `Toto` en `Titi` dans la crate `durs-bidule` :
+Exemple, renommage d'un trait `Toto` en `Titi` dans la crate `durs-bidule` :
 
     [ref] bidule: rename Toto -> Titi
 
@@ -43,9 +43,9 @@ Exemple, renomage d'un trait `Toto` en `Titi` dans la crate `durs-bidule` :
 
 * `build` : Modification des script de build, de packaging ou/et de publication des livrables.
 * `ci` : Modification de la chaine d'intégration continue.
-* `deps` : Modification des dépendances sans modification du code : ce peut-être pour mettre à jours des dépendances tierces ou pour supprimer des dépendances tierces qui ne sont plus utilisées.
+* `deps` : Modification des dépendances sans modification du code : ce peut être pour mettre à jour des dépendances tierces ou pour supprimer des dépendances tierces qui ne sont plus utilisées.
 * `docs` : Modification de la documentation (y compris traduction et création de nouveau contenu).
-* `feat` : Développement d'une nouvelle fonctionnalitée.
+* `feat` : Développement d'une nouvelle fonctionnalité.
 * `fix` : Correction d'un bug
 * `opti` :  Optimisation : amélioration des performances ou/et réduction de l'espace mémoire/disque utilisé.
 * `pub` : commit lié a la publication d'une crate sur [crates.io](https://crates.io).
@@ -59,7 +59,7 @@ Si vous avez besoin d'effectuer une action qui ne rentre dans aucun de ses types
 
 On met à jour uniquement avec des rebase, les merge sont strictement interdits !
 
-Chaque fois que la branche `dev` est mise a jours, vous devez rebaser chacun de vos branche de travail sur dev. Pour chaque branche :
+Chaque fois que la branche `dev` est mise à jour, vous devez rebaser chacune de vos branche de travail sur dev. Pour chaque branche :
 
 1. Placez vous sur votre branche
 2. Lancez un rebase sur dev
@@ -69,27 +69,27 @@ Chaque fois que la branche `dev` est mise a jours, vous devez rebaser chacun de
 3. Réglez les conflits s'il y en a. Une fois les conflits résolus vous devez :
     a. commiter les fichiers qui étaient en conflit
     b. Continuer le rebase avec la commande `git rebase --continue`
-    c. Refaire 3. pour chaque commit ou il y a des conflits
+    c. Refaire 3. pour chaque commit où il y a des conflits
 
-4. Vous n'avez plus de conflits apmrès un `git rebase --continue`, c'est que le rebase est terminé. Passez a la branche suivante.
+4. Vous n'avez plus de conflits après un `git rebase --continue`, c'est que le rebase est terminé. Passez à la branche suivante.
 
-Si quelque chose s'est mal passé et que vous ne savez plus ou vous en êtes, vopus pouvez annuler votre rebase et reprendre de zéro avec la commande `git rebase --abort`.
+Si quelque chose s'est mal passé et que vous ne savez plus où vous en êtes, vous pouvez annuler votre rebase et reprendre de zéro avec la commande `git rebase --abort`.
 
 Il se peut que vous n'ayez pas de conflits du tout, dans ce cas vous sautez directement de l'étape 2. à 4. sans passer par 3.
 
 ## Quand pusher
 
-Idéalement a chaque fois que vous êtes sur le point d'etteindre votre ordinateur, soit environ 1 fois par jour (uniquement pour les jours ouv ous codez sur le proejt bien sûr).
+Idéalement à chaque fois que vous êtes sur le point d'éteindre votre ordinateur, soit environ 1 fois par jour (uniquement pour les jours où vous codez sur le projet bien sûr).
 
-Pensez bien a préfixer votre commit par `wip:` pour indiquer que c'est un "work in progress".
+Pensez bien à préfixer votre commit par `wip:` pour indiquer que c'est un "work in progress".
 
 > Pourquoi puhser alors que je n'ai pas fini ?
 
-Si votre ordinateur rencontre un problème (panne, perte de données, reformatage, etc), pusher vous permet de vous assurez d'avoir toujours une copie de votre travail quelque part sur les internets.
+Si votre ordinateur rencontre un problème (panne, perte de données, reformatage, etc), pusher vous permet de vous assurer d'avoir toujours une copie de votre travail quelque part sur les internets.
 
 ## Comment merger ma contribution
 
-Lorsque vous avez fini votre développement, éxécutez `fmt` et `clippy` pour être sur que votre code est propre puis éxécutez tout les tests pour être sur qu'ils passent :
+Lorsque vous avez fini votre développement, exécutez `fmt` et `clippy` pour être sûr que votre code est propre puis exécutez tous les tests pour être sûr qu'ils passent :
 
     cargo +nightly fmt
     cargo +nightly clippy
@@ -97,16 +97,16 @@ Lorsque vous avez fini votre développement, éxécutez `fmt` et `clippy` pour
 
 Puis commitez le tout, sans le préfix wip- cette fois ci.
 
-Ensuite néttoyez l'historique de votre branche avec un rebase interactif :
+Ensuite nettoyez l'historique de votre branche avec un rebase interactif :
 
     git rebase -i dev
 
-Renommez nottament les commit `wip:` et fusionnez les commits liés a fmt ou clippy afin de simplifier l'historique.
+Renommez notamment les commits `wip:` et fusionnez les commits liés à fmt ou à clippy afin de simplifier l'historique.
 
-Enfin faite un push force sur le dépot distant :
+Enfin faites un `push force` sur le dépot distant :
 
     git push -f
 
-Puis rendez vous sur le gitlab et vérifiez que le code sur votre branche distante est bien celui cencé s'y trouver.
+Puis rendez vous sur le gitlab et vérifiez que le code sur votre branche distante est bien celui censé s'y trouver.
 
-Attendez 20 minutes que la chaien d'intégration continue puisse vérifier votre code, et si elle réussi vous pouvez alors supprimer la mention WIP de votre Merge Request et tagger des développeurs expérimentés pour demander une review.
+Attendez 20 minutes que la chaîne d'intégration continue puisse vérifier votre code, et si elle réussi vous pouvez alors supprimer la mention WIP de votre Merge Request et tagger des développeurs expérimentés pour demander une revue de code.

doc/fr/developpeurs/installer-son-environnement-de-dev.md

@@ -12,39 +12,39 @@ Installez la toolchain stable de Rust :
 
     curl https://sh.rustup.rs -sSf | sh
 
-Ajoutez ~/.cargo/bin a votre variable d'environnement PATH :
+Ajoutez ~/.cargo/bin à votre variable d'environnement PATH :
 
     export PATH="$HOME/.cargo/bin:$PATH"
 
-Je vous recommande vivement d'ajouter cette ligne dans le fichier de configuration de votre terminal pour ne pas avoir a la recopier a chaque fois, si vous ne savez pas de quoi je parle alors vous utilisez très probablement le shell par défaut (bash) et le fichier auquel vous devez ajouter cette ligne est `~/.bashrc`
+Je vous recommande vivement d'ajouter cette ligne dans le fichier de configuration de votre terminal pour ne pas avoir à la recopier a chaque fois, si vous ne savez pas de quoi je parle alors vous utilisez très probablement le shell par défaut (bash) et le fichier auquel vous devez ajouter cette ligne est `~/.bashrc`
 
 ## Fmt : le formateur de code
 
-Je vous recommande vivement d'installer l'indispensable formateur automatique de code, d'autant qu'il est maintenue par l'équipe officielle du langage Rust donc vous avez la garantie que votre code compilera toujours (et aura toujours le même comportement) après le passage du formateur.
+Je vous recommande vivement d'installer l'indispensable formateur automatique de code, d'autant qu'il est maintenu par l'équipe officielle du langage Rust donc vous avez la garantie que votre code compilera toujours (et aura toujours le même comportement) après le passage du formateur.
 
 Pour installer `fmt` :
 
     rustup component add rustfmt-preview
 
-Pour formater automatiquement votre code, placez vous a la racine de votre projet et éxécutez la commande suivante :
+Pour formater automatiquement votre code, placez vous à la racine de votre projet et exécutez la commande suivante :
 
     cargo fmt
 
-Je vous recommande fortement de créer un alias dans la configuration de votre shell (~/.bashrc si vous utilisez bash). a titre d'exemple j'ai créer l'alias `fmt="cargo +nightly fmt"`.
+Je vous recommande fortement de créer un alias dans la configuration de votre shell (~/.bashrc si vous utilisez bash). À titre d'exemple j'ai créé l'alias `fmt="cargo +nightly fmt"`.
 
 ## Clippy : le linteur
 
-Si vous contribuez à l'implémentation Rust de Duniter vous devrez également utiliser le linteur Clippy. Et dans tout les cas il est vivement recommandé aux débutants en Rust de l'utiliser, en effet clippy est très pédagogique et vas beaucoup vous aider a apprendre comment il conviens de coder en Rust.
+Si vous contribuez à l'implémentation Rust de Duniter vous devrez également utiliser le linteur Clippy. Et dans tous les cas il est vivement recommandé aux débutants en Rust de l'utiliser, en effet clippy est très pédagogique et va beaucoup vous aider à apprendre comment il convient de coder en Rust.
 
-Éxécutez la commande suivante pour installer clippy :
+Exécutez la commande suivante pour installer clippy :
 
     rustup component add clippy-preview
 
-Pour lancer clippy, rendez-vous a la racine de votre projet puis éxécutez la commande suivante :
+Pour lancer clippy, rendez-vous à la racine de votre projet puis éxécutez la commande suivante :
 
     cargo clippy --all
 
-Clippy vas alors vous signaler de façopn très pédagogique tout ce qu'il conviens de modifier dans votre code pour être plus dans "l'esprit rust".
+Clippy va alors vous signaler de façopn très pédagogique tout ce qu'il convient de modifier dans votre code pour être plus dans "l'esprit rust".
 
 ## IDE/Editeur
 
@@ -130,7 +130,7 @@ Un exemple de fichier `launch.conf` pour VSCode :
 
 ## Paquets supplémentaires pour compiler duniter-rs
 
-Bien que cela soit de plus en plus rare, certaines crates rust dépendent encore de bibliothèques C/C++ et celles-ci doivent être installer sur votre ordinateur lors de la compilation. Sous Debian et dérivés, vous devez avoir `pkg-config` d'installé car le compilateur rust s'en sert pour trouver les bibliothèques C/C++ installés sur votre système.
+Bien que cela soit de plus en plus rare, certaines crates rust dépendent encore de bibliothèques C/C++ et celles-ci doivent être installées sur votre ordinateur lors de la compilation. Sous Debian et dérivés, vous devez avoir `pkg-config` d'installé car le compilateur rust s'en sert pour trouver les bibliothèques C/C++ installées sur votre système.
 
     sudo apt-get install pkg-config
 
@@ -160,8 +160,8 @@ Vous devriez avoir le contenu suivant dans le dossier `hello-world` :
     ├── src
     │   └── main.rs
 
-C'est le contenu minimal de tout projets binaire, le code source ce trouve dans `main.rs`.
-Tout projets Rust (binaire ou bibliothèque) doit contenir un fichier nommé Cargo.toml a la racine du projet, c'est on quelque sorte l'équivalent du `package.json` de NodeJs.
+C'est le contenu minimal de tout projet binaire, le code source se trouve dans `main.rs`.
+Tout projet Rust (binaire ou bibliothèque) doit contenir un fichier nommé Cargo.toml à la racine du projet, c'est en quelque sorte l'équivalent du `package.json` de NodeJs.
 
 Le fichier `main.rs` contient déjà par défaut un code permettant de réaliser le traditionnel "Hello, world!" :
 
@@ -172,16 +172,16 @@ Le fichier `main.rs` contient déjà par défaut un code permettant de réaliser
 Cette syntaxe doit vous rappeler furieusement le C/C++ pour ceux qui connaissent, et c'est bien normal car Rust est conçu pour être l'un des successeurs potentiel du C++. On peut toutefois déjà noter trois différences majeures avec le C/C++ :
 
 1. La fonction main() ne prend aucun paramètre en entrée. Les arguments cli sont capturés d'une autre façon via une utilisation de la bibliothèque standard.
-2. println! n'est pas une fonction, c'est une macro. En Rust toutes les macros sont de la forme `macro_name!(params)`, c'est donc au `!` qu'on les reconnaît. Alors pourquoi une macro juste pour printer une chaîne de caractères ? Et bien parce que en Rust toute fonction doit avoir a un nombre fini de paramètres et chaque paramètre doit avoir un type explicitement défini. Pour outrepasser cette limite on utilise une macro qui vas créer la fonction souhaitée lors de la compilation.
+2. println! n'est pas une fonction, c'est une macro. En Rust toutes les macros sont de la forme `macro_name!(params)`, c'est donc au `!` qu'on les reconnaît. Alors pourquoi une macro juste pour printer une chaîne de caractères ? Et bien parce que en Rust toute fonction doit avoir un nombre fini de paramètres et chaque paramètre doit avoir un type explicitement défini. Pour outrepasser cette limite on utilise une macro qui va créer la fonction souhaitée lors de la compilation.
 3. La fonction main() ne retourne aucune valeur, lorsque votre programme se termine, Rust envoi par défaut le code EXIT_SUCCESS a l'OS. Pour interrompre votre programme en envoyant un autre code de sortie, il existe des macro comme par exemple `panic!(err_message)`
 
-Avant de modifier le code, assurez vous déjà que le code par défaut compile correctement :
+Avant de modifier le code, assurez-vous déjà que le code par défaut compile correctement :
 
     $ cargo build
     Compiling hello-world v0.1.0 (file:///home/elois/dev/hello-world)
     Finished dev [unoptimized + debuginfo] target(s) in 0.91 secs
 
-Cargo est l'équivalent de npm pour Rust, il vas chercher toutes les dépendances des crates (=bibliothèques) que vous installez. Oui en Rust on parle de crates pour désigner une dépendance, ça peut etre une bibliothèque ou un paquet.  
+Cargo est l'équivalent de npm pour Rust, il va chercher toutes les dépendances des crates (=bibliothèques) que vous installez. Oui en Rust on parle de crates pour désigner une dépendance, ça peut être une bibliothèque ou un paquet.
 
 Si vous obtenez bien un `Finished dev [unoptimized + debuginfo] target(s) in x.xx secs`, félicitations vous venez de compiler votre premier programme Rust :)
 
@@ -198,12 +198,12 @@ Comme ça :
 
 Comme indiqué, cargo run exécute votre binaire qui se trouve en réalité dans `target/debug/`
 
-Il existe plusieurs profils de compilation, et vous pouvez même créer les vôtres, deux profils pré-configuré sont a connaître absolument :
+Il existe plusieurs profils de compilation, et vous pouvez même créer les vôtres, deux profils pré-configurés sont à connaître absolument :
 
 1. Le profil `debug` : c'est le profil par défaut, le compilateur n'effectue aucune optimisation et intègre au binaire les points d'entrée permettant à un débogueur de fonctionner.
 2. Le profil `release` : le compilateur effectue le maximum d'optimisation possibles et n'intègre aucun point d'entrée pour le débogueur.
 
-Rust est réputé pour être ultra-rapide, c'est en grande partie grâce aux optimisations poussés effectués lors d'une compilation en profil `release`, mais réaliser ces optimisations demande du temps, la compilation en mode `release` est donc bien plus longue qu'en mode `debug`.
+Rust est réputé pour être ultra-rapide, c'est en grande partie grâce aux optimisations poussées effectuées lors d'une compilation en profil `release`, mais réaliser ces optimisations demande du temps, la compilation en mode `release` est donc bien plus longue qu'en mode `debug`.
 
 Pour compiler en mode `release` :
 
@@ -215,4 +215,4 @@ Pour aller plus loin, je vous invite a lire l'excellent [tutoriel Rust de Guilla
 
 Et si vous savez lire l'anglais, la référence des références que vous devez absolument lire c'est évidemment le sacro-sain [Rust Book](https://doc.rust-lang.org/book/).
 
-Le Rust Book par vraiment de zéro et se lit très facilement même avec un faible niveau en anglais.
+Le Rust Book part vraiment de zéro et se lit très facilement même avec un faible niveau en anglais.