diff --git a/doc/fr/developpeurs/conventions-git.md b/doc/fr/developpeurs/conventions-git.md
index 7184a9d41fd3f0c37f7060d7068e6bfed6f5da6d..c3daf57d213b9a7caafa2cc40cda1d358441a521 100644
--- a/doc/fr/developpeurs/conventions-git.md
+++ b/doc/fr/developpeurs/conventions-git.md
@@ -2,20 +2,20 @@
 
 ## Nommage des branches
 
-### Branche créée par gitlab
+### 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 l'issue liée.
-Dans ce cas vous devez préfixer la branche par votre pseudo gitlab suivi d'un slash, exemple :
+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 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 :
+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.
+pseudo := pseudo de votre compte Gitlab.
 type := voir "Liste des types de commit".
 description := courte description en anglais à l'impératif présent, 3 à 4 mots maximum, pas d'articles.
 
@@ -42,7 +42,7 @@ Exemple, renommage d'un trait `Toto` en `Titi` dans la crate `durs-bidule` :
 ### Liste des types de commit
 
 * `build` : Modification des scripts de build, de packaging ou/et de publication des livrables.
-* `ci` : Modification de la chaine d'intégration continue.
+* `ci` : Modification de la chaîne d'intégration continue.
 * `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é.
@@ -55,7 +55,7 @@ Exemple, renommage d'un trait `Toto` en `Titi` dans la crate `durs-bidule` :
 
 Si vous avez besoin d'effectuer une action qui ne rentre dans aucun de ses types, contactez les principaux développeurs du projet pour discuter de l'ajout d'un nouveau type de commit dans cette liste.
 
-## Stratégie de mise a jour
+## Stratégie de mise à jour
 
 On met à jour uniquement avec des rebase, les merge sont strictement interdits !
 
@@ -107,6 +107,6 @@ 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 censé 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 chaîne d'intégration continue puisse vérifier votre code, et si elle réussit 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.
diff --git a/doc/fr/developpeurs/developper-un-module-durs.md b/doc/fr/developpeurs/developper-un-module-durs.md
index eef750048b8850cc59ad1957028105ff5e3022dc..09e23f7ffbd92b204d85611501079e2586915fc3 100644
--- a/doc/fr/developpeurs/developper-un-module-durs.md
+++ b/doc/fr/developpeurs/developper-un-module-durs.md
@@ -9,7 +9,7 @@ Si ce n'est pas déjà fait, vous devez au préalable [préparer votre environne
 
 ## Architecture générale du dépôt durs
 
-Le dépôt durs est constitué de deux types de crates : les binaires et les bibliothèques (nommées librairies par abus de language).
+Le dépôt durs est constitué de deux types de crates : les binaires et les bibliothèques (nommées librairies par abus de langage).
 
 Les crates binaires sont regroupés dans le dossier `bin` et sont au nombre de deux :
 
@@ -68,7 +68,7 @@ La seule obligation que vous devez respecter pour que votre module soit reconnu
 Ensuite vous n'avez plus qu'à modifier les crates binaires pour qu'elles importent votre structure qui implémente le trait `DursModule`. (La modification des binaires sera détaillée plus loin).
 
 Les traits sont au cœur du langage Rust, on les utilise partout et tout le temps. Ils ressemblent au concept d'interfaces que l'on peut trouver dans d'autres langages.
-Un trait défini un **comportement**, il expose effectivement des méthodes un peu comme les interfaces ainsi que des traits parents rapellant le concept d'héritage mais un trait peut également exposer des types, et c'est d'ailleurs le cas du trait `DursModule`.
+Un trait défini un **comportement**, il expose effectivement des méthodes un peu comme les interfaces ainsi que des traits parents rappelant le concept d'héritage mais un trait peut également exposer des types, et c'est d'ailleurs le cas du trait `DursModule`.
 
 Le trait `DursModule` expose 2 types que vous devrez donc définir dans votre module : `ModuleConf` et `ModuleOpt`.
 
@@ -97,7 +97,7 @@ Le module skeleton donne un exemple de configuration avec un champ de type `Stri
 
 ### Le type `ModuleOpt`
 
-Type représentant les options de ligne de commande pour votre module. Si votre module n'a pas de commande cli (ou une commande cli sans aucune option) vous pouvez créer un type structure vide.
+Type représentant les options de ligne de commande pour votre module (CLI = command line interface). Si votre module n'a pas de commande cli (ou une commande cli sans aucune option) vous pouvez créer un type structure vide.
 
 Exemple de structure vide :
 
@@ -247,10 +247,10 @@ Déclaration :
     ) -> Result<(), ModuleInitError>;
 ```
 
-Dans le cas d'un module qui ne servirait qu'à ajouter une sous-commande à la ligne de commande Durs, l'implémentation de la fonction start reste obligatoire et le module doit absolument s'enregistrer auprès du router quand même et garder son thread actif jusqu'à la fin du programme. J'ai ouvert [un ticket](https://git.duniter.org/nodes/rust/duniter-rs/issues/112) pour améliorer cela.
+Dans le cas d'un module qui ne servirait qu'à ajouter une sous-commande à la ligne de commande Durs, l'implémentation de la fonction `start` reste obligatoire et le module doit absolument s'enregistrer auprès du router quand même et garder son thread actif jusqu'à la fin du programme. J'ai ouvert [un ticket](https://git.duniter.org/nodes/rust/duniter-rs/issues/112) pour améliorer cela.
 
 La 1ère chose à faire dans votre fonction start est de vérifier l'intégrité et la cohérence de la configuration de votre module.
-Si vous détectez la moindre erreur dans la configuration de votre module, vous devez interrompre le programme avec un message d'erreur indiquand clairement le nom de votre module et le fait que la configuration est incorrecte.
+Si vous détectez la moindre erreur dans la configuration de votre module, vous devez interrompre le programme avec un message d'erreur indiquant clairement le nom de votre module et le fait que la configuration est incorrecte.
 
 Ensuite si `load_conf_only` vaut `true` vous n'avez plus rien à faire, retournez `Ok(())`.
 En revanche, si `load_conf_only` vaut `false` c'est qu'il vous faut réellement lancer votre module, cela se fera en plusieurs étapes détaillées plus bas :
@@ -269,7 +269,7 @@ Si jamais le router n'a pas reçu l'enregistrement de tous les modules au bout d
 Le plus important est donc d'enregistrer votre module auprès du router AVANT tout traitement lourd ou coûteux.
 20 secondes peut vous sembler énorme, mais gardez en tête que Durs peut être amené à s'exécuter dans n'importe quel contexte, y compris sur un micro-pc aux performances très très réduites. De plus, Durs n'est pas seul sur la machine de l'utilisateur final, le délai de 20 secondes doit être respecté même dans le pire des scénarios (micro-pc déjà très occupé à d'autres taches).
 
-Si vous prévoyez de réaliser des traitements lours ou/et coûteux dans votre module, il peut être pertinent de ne pas l'inclure dans la release pour micro-pc (architecture arm), n'hésitez pas à poser la question aux développeurs principaux du projet en cas de doute.
+Si vous prévoyez de réaliser des traitements lourds ou/et coûteux dans votre module, il peut être pertinent de ne pas l'inclure dans la release pour micro-pc (architecture arm), n'hésitez pas à poser la question aux développeurs principaux du projet en cas de doute.
 En gros, lorsque votre poste de développement ne fait rien de coûteux en même temps, votre module doit s'être enregistré en moins de 3 secondes, si ça dépasse c'est que vous faites trop de choses à l'initialisation.
 
 ## Injecter votre module dans les crates binaires
@@ -284,7 +284,7 @@ Vous pouvez modifier une copie de la ligne du module skeleton pour être sûr de
 
 ### Injecter votre module dans `durs-server`
 
-Une fois que vous avez ajouter votre module en dépendance dans le Cargo.toml de `durs-server`, il va falloir utiliser votre module dans le main.rs :
+Une fois que vous avez ajouté votre module en dépendance dans le Cargo.toml de `durs-server`, il va falloir utiliser votre module dans le main.rs :
 
 1. Utilisez votre structure implémentant le trait DursModule :
 
@@ -294,7 +294,7 @@ Une fois que vous avez ajouter votre module en dépendance dans le Cargo.toml de
 
     durs_plug!([WS2PModule], [TuiModule, .., TotoModule])
 
-    Notez que `durs_plug!` prend en paramètre 2 tableaux de modules, le 1er correspond aux modules de type réseau inter-noeuds, tous les autres modules doivent se trouver dans le 2ème tableau.
+    Notez que `durs_plug!` prend en paramètre 2 tableaux de modules, le 1er correspond aux modules de type réseau inter-nœuds, tous les autres modules doivent se trouver dans le 2ème tableau.
 
 3. Si votre module doit injecter une sous-commande dans la ligne de commande `durs`, ajoutez le également a la macro `durs_inject_cli!` :
 
diff --git a/doc/fr/developpeurs/installer-son-environnement-de-dev.md b/doc/fr/developpeurs/installer-son-environnement-de-dev.md
index ee63f65150d5f0514c9fb356fb2d37bf3c1152bd..28e23c6bc32bd9939f46a424382390ee0464b3f8 100644
--- a/doc/fr/developpeurs/installer-son-environnement-de-dev.md
+++ b/doc/fr/developpeurs/installer-son-environnement-de-dev.md
@@ -44,7 +44,7 @@ Pour lancer clippy, rendez-vous à la racine de votre projet puis éxécutez la
 
     cargo clippy --all
 
-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".
+Clippy va alors vous signaler de façon très pédagogique tout ce qu'il convient de modifier dans votre code pour être plus dans "l'esprit rust".
 
 ## IDE/Editeur
 
@@ -73,7 +73,7 @@ Ensuite extrayez l'archive dans le dossier contenant vos programmes (/opt pour l
 
     sudo tar xf idea*.tar.gz -C /opt/
 
-Puis éxécutez le script `idea.sh` dans le dossier `/bin` :
+Puis exécutez le script `idea.sh` dans le dossier `/bin` :
 
     cd /opt/idea*/bin/
     ./idea.sh
@@ -216,3 +216,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 part vraiment de zéro et se lit très facilement même avec un faible niveau en anglais.
+
diff --git a/doc/fr/utilisateurs/installer-durs.md b/doc/fr/utilisateurs/installer-durs.md
index fabc46a83420836a9f91bfd921fc2f4ac354f7b3..22d9a715028d0104f37ddb5be2da695158f78a32 100644
--- a/doc/fr/utilisateurs/installer-durs.md
+++ b/doc/fr/utilisateurs/installer-durs.md
@@ -12,7 +12,7 @@ Dans tout les cas vous aurez 3 choix a faire :
 
 `durs-desktop` est destiné aux utilisateurs souhaitant installer Durs sur leur ordinateur personnel et administrer leur noeud Durs via une interface graphique.
 
-`durs-server` est beaucoup plus léger et se manipule via la ligne de commande. Il est nottament utile dans les cas suivants :
+`durs-server` est beaucoup plus léger et se manipule via la ligne de commande. Il est notamment utile dans les cas suivants :
 
 * Installation de durs sur serveur dédié
 * Installation de durs sur micro pc (raspberry pi, brique internet, etc)
@@ -24,7 +24,7 @@ Notez bien : il est possible d'administrer `durs-server` a distance via une inte
 
 <s>Rendez vous sur [le site officiel de Durs](durs.info), vous y trouverez un lien direct vers la dernière version stable.</s>
 
-Le site web de Durs n'existe pas encore, en attendant vous devrez vous renseigenr sur le [forum duniter](forum.duniter.org) pour savoir quelle version installer.
+Le site web de Durs n'existe pas encore, en attendant vous devrez vous renseigenr sur le [forum duniter](https://forum.duniter.org) pour savoir quelle version installer.
 
 Vous trouverez toute les versions disponibles au téléchargement sur [cette page du gitlab](https://git.duniter.org/nodes/rust/duniter-rs/tags).
 
@@ -55,7 +55,7 @@ Ensuite, clonez le dépot git :
 
     git clone https://git.duniter.org/nodes/rust/duniter-rs.git
 
-Rendez vous dans le dossier `duniter-rs` ainsi créer puis dnas le sous-dossier correspondant a la variante que vous souhaitez installer :
+Rendez vous dans le dossier `duniter-rs` ainsi créé puis dans le sous-dossier correspondant à la variante que vous souhaitez installer :
 
 * Pour `durs-server`, rendez-vous dans `bin/durs-server`
 
@@ -76,4 +76,5 @@ Si vous avez des problèmes avec `openssl` lors de la compilation, vous pouvez e
 Cela implique juste que votre noeud ne pourra pas contacter les endpoint WS2P qui sont derrière une couche SSL/TLS.  
 Votre noeud devrait tout de même fonctionner normalement s'il ya suffisamment de endpoint WS2P accesibles en clair.
 
-Si la compilation réussie, votre éxécutable se trouve dans `duniter-rs/target/release` et se nomme `durs` ou  `durs-desktop`. Vous pouvez le déplacer ou bon vous semble sur votre disque puis l'éxécuter directement.
\ No newline at end of file
+Si la compilation réussie, votre exécutable se trouve dans `duniter-rs/target/release` et se nomme `durs` ou `durs-desktop`.
+Vous pouvez le déplacer ou bon vous semble sur votre disque puis l'exécuter directement.
diff --git a/doc/fr/utilisateurs/synchroniser-noeud-durs.md b/doc/fr/utilisateurs/synchroniser-noeud-durs.md
index ec1767cb78c76cebc86d997d502e1acd36e3e8c8..f656fe510ca8b494158bbfeb3f25dafa675b4d23 100644
--- a/doc/fr/utilisateurs/synchroniser-noeud-durs.md
+++ b/doc/fr/utilisateurs/synchroniser-noeud-durs.md
@@ -8,7 +8,7 @@ Cette fonctionnalitée n'est pas encore intégrée à Durs.
 
 Assurez vous d'avoir un noeud Duniter synchronisé sur la même machine.
 
-Si vous éxécutez Durs avec le même utilisateur système, il suffit d'utiliser l'option `--type` comme suit :
+Si vous exécutez Durs avec le même utilisateur système, il suffit d'utiliser l'option `--type` comme suit :
 
     durs sync --type ts
 
@@ -18,11 +18,11 @@ ou
 
 `ts` fait référence au fait que Duniter est écrit en TypeScript.
 
-Si vous éxécutez Durs et Duniter avec un utilisateur système différent, vous devrez indiquer a Durs le chemin vers le répertoire contenant la blockchain brute sous forme de fichiers JSON. Elle se trouve dans `~/.config/duniter/<profile>/<currency>`.
+Si vous exécutez Durs et Duniter avec un utilisateur système différent, vous devrez indiquer a Durs le chemin vers le répertoire contenant la blockchain brute sous forme de fichiers JSON. Elle se trouve dans `~/.config/duniter/<profile>/<currency>`.
 
 Exemple:
 
-si vous êtez sous Linux, que l'utilisateur de duniter est `user`, que vous utilisez le profil duniter par défaut et que vous souhaitez vous synchronisr sur la g1; le chemin vers lma blockchain brute est :
+si vous êtez sous Linux, que l'utilisateur de duniter est `user`, que vous utilisez le profil duniter par défaut et que vous souhaitez vous synchronisr sur la g1; le chemin vers la blockchain brute est :
 
     home/user/.config/duniter/duniter-default/g1
 
@@ -30,4 +30,4 @@ Vous devez coller ce chemin a la fin de la commande sync comme suis :
 
     durs sync --type ts home/user/.config/duniter/duniter-default/g1
 
-/!\ Cela n'est nécessaire que dans le cas ou vous éxécutez Durs et Duniter avec deux utilisateurs différents ! Si Durs et Duniter utilisent le même utilisateur, Durs trouvera la blockchain brute tout seul.
\ No newline at end of file
+/!\ Cela n'est nécessaire que dans le cas ou vous éxécutez Durs et Duniter avec deux utilisateurs différents ! Si Durs et Duniter utilisent le même utilisateur, Durs trouvera la blockchain brute tout seul.