diff --git a/doc/fr/developpeurs/checklist-commit.md b/doc/fr/developpeurs/checklist-commit.md
index 2c4ab93d3cf773e719818ae67802650a8b0f1e15..c8469b34b65ade8be5e1862e89301998095caff3 100644
--- a/doc/fr/developpeurs/checklist-commit.md
+++ b/doc/fr/developpeurs/checklist-commit.md
@@ -1,12 +1,12 @@
-# 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 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.  
-- [ ] 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 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.
+- [ ] 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 commits atomiques.
diff --git a/doc/fr/developpeurs/conventions-git.md b/doc/fr/developpeurs/conventions-git.md
index 15f5bb6289f5d5195b7f759f6e14a0135b4a2686..6f5721c5caa3b43946f381aae536eca613b86e3c 100644
--- a/doc/fr/developpeurs/conventions-git.md
+++ b/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 a lors que je n'ai pas fini ?
+> 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.
diff --git a/doc/fr/developpeurs/developper-un-module-durs.md b/doc/fr/developpeurs/developper-un-module-durs.md
index 4c96c6c08523413b19f7682b343fba22f880f86a..eb990adbc2ed2a50a1e41deb1619f6e3e7b3c015 100644
--- a/doc/fr/developpeurs/developper-un-module-durs.md
+++ b/doc/fr/developpeurs/developper-un-module-durs.md
@@ -11,22 +11,22 @@ Si ce n'est pas déjà fait, vous devez au préalable [préparer votre environne
 
 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).
 
-Les crates binaires sont regroupés dans le dossier `bin` et sont au nomdre de deux :
+Les crates binaires sont regroupés dans le dossier `bin` et sont au nombre de deux :
 
-* durs-server : produit un éxécutable de durs en ligne de commande, donc installable sur un serveur.
-* durs-desktop : produit un éxécutable de durs en application graphique de bureau (n'existe pas encore).
+* durs-server : produit un exécutable de durs en ligne de commande, donc installable sur un serveur.
+* durs-desktop : produit un exécutable de durs en application graphique de bureau (n'existe pas encore).
 
 Les modules durs sont des crates de type bibliothèques, vous devez donc placer la crate de votre module dans le dossier `lib`.
 
 Le dossier `lib` est organisé en 4 sous-dossiers correspondant à 4 types de bibliothèques :
 
-1. `tools` : les bibliothèques outils, pouvant potentiellement servir a toutes les crates.
+1. `tools` : les bibliothèques outils, pouvant potentiellement servir à toutes les crates.
 2. `modules` : les bibliothèques représentant un module durs.
-3. `modules-lib` : les bibliothèques dédiés uniquement a certain modules.
-4. `core` :  les bibliothèques structurantes du coeur et de l'interphasage avec les modules.
+3. `modules-lib` : les bibliothèques dédiées uniquement à certains modules.
+4. `core` :  les bibliothèques structurantes du cœur et de l'interphasage avec les modules.
 
-Pour développer votre module, vous devez créer une crate dans le dossier `modules/{your-module-name}`.  
-Le nom de votre crate tel que décris dans le Cargo.toml devra etre préfixée par `durs-`. En revanche, le dossier dans lequel se trouvera votre module aura le nom de votre module **sans le préfixe** `durs-`.
+Pour développer votre module, vous devez créer une crate dans le dossier `modules/{your-module-name}`.
+Le nom de votre crate tel que décrit dans le Cargo.toml devra être préfixé par `durs-`. En revanche, le dossier dans lequel se trouvera votre module aura le nom de votre module **sans le préfixe** `durs-`.
 
 Exemple : si vous souhaitez créer un module nommé `toto`, vous placerez la crate contenant le code de votre module dans le dossier `lib/modules/toto` et dans le Cargo.toml de votre crate vous indiquerez comme nom `durs-toto`.
 
@@ -36,38 +36,38 @@ Si vous souhaitez découper votre module en plusieurs crates, le dossier de votr
 
 Exemple : vous souhaitez déplacer une partie du code de votre module toto dans une nouvelle crate `tata`. Vous devrez déplacer votre module `toto` dans `lib/modules/toto/toto` et créer votre module tata dans `lib/modules/toto/toto-tata`. De plus, votre nouvelle doit déclarer dans sont Cargo.toml le nom `durs-toto-tata`.
 
-Régle générale : le dossier d'une crate doit avoir le même nom que la crate mais **sans le préfixe** `durs-`.
+Règle générale : le dossier d'une crate doit avoir le même nom que la crate mais **sans le préfixe** `durs-`.
 
-\* La crate principale doit être celle qui sera importée par les crates binaires et elle doit exposer une structure publique qui implémentera le trait `DursModule` (plus de détail plus bas).
+\* La crate principale doit être celle qui sera importée par les crates binaires et elle doit exposer une structure publique qui implémentera le trait `DursModule` (plus de détails plus bas).
 
 ### Développer une lib pour plusieurs modules
 
-Si vous souhaitez développer une bibliothèque commune a plusieurs modules et utilisée exclusivement par ceux-ci, vous devrez ranger cette bibliothèque commune dans le dossier `modules-common`, ce dossier n'existe pas encore car il n'existe pas encore de groupe de modules partageant des bibliothèques communes, n'hésitez pas a le créer si le cas se présente pour vous.
+Si vous souhaitez développer une bibliothèque commune à plusieurs modules et utilisée exclusivement par ceux-ci, vous devrez ranger cette bibliothèque commune dans le dossier `modules-common`, ce dossier n'existe pas encore car il n'existe pas encore de groupe de modules partageant des bibliothèques communes, n'hésitez pas à le créer si le cas se présente pour vous.
 
-Le dossier `tools/` ne doit contenir que des bibliothèques utilisées (aussi) par le coeur.
+Le dossier `tools/` ne doit contenir que des bibliothèques utilisées (aussi) par le cœur.
 
 Pour résumer :
 
-* Une bibliothèque est utilisée par le coeur et éventuellement par des modules : dossier `tools`.
+* Une bibliothèque est utilisée par le cœur et éventuellement par des modules : dossier `tools`.
 * Une bibliothèque est utilisée exclusivement par des modules : dossier `modules-common`.
 * Une bibliothèque est utilisée exclusivement par un seul module : dossier `modules-lib/{MODULE_NAME}`.
 
 ## Le module skeleton
 
 Pour vous aider, le projet comporte un module nommé `skeleton` qui comporte tout ce qu'il faut a un module durs pour fonctionner.
-Dans la suite de ce tutoriel, nous allons vous guider pas a pas pour créer votre module a partir d'une copie du module `skeleton`.
+Dans la suite de ce tutoriel, nous allons vous guider pas à pas pour créer votre module à partir d'une copie du module `skeleton`.
 
-Le module skeleton contient de morceaux de code permettant d'exemplifier les différentes usages courant, comme modifier la configuration de votre modules ou découper votre module en plusieurs threads, certains usages ne vous serviront peut-être pas et vous pourrez donc purement supprimer le code afférant dans votre copie.
+Le module skeleton contient des morceaux de code permettant d'exemplifier les différents usages courant, comme modifier la configuration de votre modules ou découper votre module en plusieurs threads, certains usages ne vous serviront peut-être pas et vous pourrez donc purement supprimer le code afférant dans votre copie.
 
-Evidemment, le module skeleton contient également quelques ingrédients indispensable au fonctionnement de tout module durs, et c'est par ceux-ci que nous allons commencer.
+Évidemment, le module skeleton contient également quelques ingrédients indispensable au fonctionnement de tout module durs, et c'est par ceux-ci que nous allons commencer.
 
 ## Le trait `DursModule`
 
-La seule obligation que vous devez respecter pour que votre module soit reconnu par le coeur est d'exposer une structure publique qui implémente le trait `DursModule`.
+La seule obligation que vous devez respecter pour que votre module soit reconnu par le cœur est d'exposer une structure publique qui implémente le trait `DursModule`.
 
-Ensuite vous n'avez plus qu'a modifier les crates binaires pour qu'elle importent votre structure qui implémente le trait `DursModule`. (La modification des binaire ssera détaillée plus loin).
+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 coeur du langage Rust, on les utilises partout et tout le temps. Ils ressemblent au concept d'interfaces que l'on peut trouver dans d'autres langages.
+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`.
 
 Le trait `DursModule` expose 2 types que vous devrez donc définir dans votre module : `ModuleConf` et `ModuleOpt`.
@@ -90,14 +90,14 @@ impl Default for YourModuleConf {
 }
 ```
 
-Le type `ModuleConf` doit lui même implémenter toute une série de trait permettant la gestion automatisé de votre configuration par le coeur. Heureusement beaucoup de traits peuvent être implémentés automatiquement par le compilateur gràçe a la macro `#[derive(Trait1, ..., TraitN)]`.  
-Le seul trait que vous devrez implémenter manuellement est le trait `Default`, il expose une seule fonction `default()` qui sera utilisée par le coeur pour générer la configuration par défaut de votre module.
+Le type `ModuleConf` doit lui même implémenter toute une série de traits permettant la gestion automatisée de votre configuration par le cœur. Heureusement beaucoup de traits peuvent être implémentés automatiquement par le compilateur grâce à la macro `#[derive(Trait1, ..., TraitN)]`.
+Le seul trait que vous devrez implémenter manuellement est le trait `Default`, il expose une seule fonction `default()` qui sera utilisée par le cœur pour générer la configuration par défaut de votre module.
 
 Le module skeleton donne un exemple de configuration avec un champ de type `String` nommé `test_fake_conf_field`. Ce champ permet d'alimenter le code d'exemple de modification de la configuration.
 
 ### 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 aucun option) vous pouvez créer un type structure vide.
+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.
 
 Exemple de structure vide :
 
@@ -111,25 +111,25 @@ Exemple de structure vide :
 pub struct YourModuleOpt {}
 ```
 
-Le module skeleton donne un exemple de `ModuleOpt` avec un champ, cela afin de montrer comment fonctionne l'éxécution d'une sous-commande injectée par un module.
+Le module skeleton donne un exemple de `ModuleOpt` avec un champ, cela afin de montrer comment fonctionne l'exécution d'une sous-commande injectée par un module.
 
 ### Les fonctions du trait `DursModule`
 
-Le trait `DursModule` expose 6 fonctions dont 4 doivent obligatoirement être implémentés par votre modules. Les fonctions optionnelles sont celles disposant d'une implémentation par défaut, vous pouvez évidemment les réimplémenter si besoin.
+Le trait `DursModule` expose 6 fonctions dont 4 doivent obligatoirement être implémentées par votre module. Les fonctions optionnelles sont celles disposant d'une implémentation par défaut, vous pouvez évidemment les réimplémenter si besoin.
 
-Voici un résumé des 6 fonctions avant de nous plogner dans le détail de chacune d'elles.
+Voici un résumé des 6 fonctions avant de nous plonger dans le détail de chacune d'elles.
 
 Les 4 fonctions obligatoires :
 
-* `name` : Dopit retourner le nom de votre module
+* `name` : doit retourner le nom de votre module
 * `priority` : doit indiquer si votre module est obligatoire ou optionnel et s'il est activé par défaut.
 * `ask_required_keys` : doit indiquer de quelles clés cryptographiques votre module a besoin.
-* `start` : Fonction appelée dans un thread dédié quand le noeud durs est lancé (seulement si votre module est activé). C'est un quelque sorte le "main" de votre module.
+* `start` : fonction appelée dans un thread dédié quand le noeud durs est lancé (seulement si votre module est activé). C'est en quelque sorte le "main" de votre module.
 
-Les 2 fonctions optionelles concernent uniquement la ligne de commande :
+Les 2 fonctions optionnelles concernent uniquement la ligne de commande :
 
-* `have_subcommand` : retourne un booléen indiquant si votre module doit injecter une sous commande a la commande durs. L'implémentation par défaut retourne `false`.
-* `exec_subcommand` : fonction appelée quand l'utilisateur a saisi a sous-commande de votre module. L'implémentation par défaut ne fait rien.
+* `have_subcommand` : retourne un booléen indiquant si votre module doit injecter une sous commande à la commande durs. L'implémentation par défaut retourne `false`.
+* `exec_subcommand` : fonction appelée quand l'utilisateur a saisi la sous-commande de votre module. L'implémentation par défaut ne fait rien.
 
 #### La fonction `name`
 
@@ -140,9 +140,9 @@ Déclaration :
     fn name() -> ModuleStaticName;
 ```
 
-`ModuleStaticName` est une tuple struct contenant un seul élément de type `&'static str`. C'est une pratique courante en Rust que d'encapsuler des types standards dans des tuple struct pour manipuler des types pus expressifs. Notez bien qu'il s'agit d'une abstraction sans cout car le compilateur désencapsulera tout vos types dans le binaire final, donc vous pouvez abuser des tuples struct a volonté, c'est considéré comme une bonne pratique. Si vous ne connaissez pas le type `&'static str` je vous renvoie au [Rust Book](https://doc.rust-lang.org/book/second-edition/ch10-03-lifetime-syntax.html#the-static-lifetime).
+`ModuleStaticName` est une tuple struct contenant un seul élément de type `&'static str`. C'est une pratique courante en Rust que d'encapsuler des types standards dans des tuple struct pour manipuler des types pus expressifs. Notez bien qu'il s'agit d'une abstraction sans coût car le compilateur désencapsulera tous vos types dans le binaire final, donc vous pouvez abuser des tuples struct à volonté, c'est considéré comme une bonne pratique. Si vous ne connaissez pas le type `&'static str` je vous renvoie au [Rust Book](https://doc.rust-lang.org/book/second-edition/ch10-03-lifetime-syntax.html#the-static-lifetime).
 
-Dans la pratique, le type `ModuleStaticName` est vraiment très simple a utiliser, si votre module se nomme `toto` vous pouvez écrire :
+Dans la pratique, le type `ModuleStaticName` est vraiment très simple à utiliser, si votre module se nomme `toto` vous pouvez écrire :
 
 ```rust
     fn name() -> ModuleStaticName {
@@ -150,13 +150,13 @@ Dans la pratique, le type `ModuleStaticName` est vraiment très simple a utilise
     }
 ```
 
-Toutefois, vous aurez probablement besoin du nom de votre module a plusieurs endroits dans le code, la bonne pratique consiste donc a créer une constante globale :
+Toutefois, vous aurez probablement besoin du nom de votre module à plusieurs endroits dans le code, la bonne pratique consiste donc à créer une constante globale :
 
 ```rust
 static MODULE_NAME: &'static str = "toto";
 ```
 
-Puis a remplacer dans l'implémentation de la fonction `name` :
+Puis à remplacer dans l'implémentation de la fonction `name` :
 
 ```rust
     fn name() -> ModuleStaticName {
@@ -175,7 +175,7 @@ Déclaration :
 
 Les différents niveaux de priorité possibles sont présentés dans la [documentation auto-générée](https://nodes.duniter.io/rust/duniter-rs/duniter_module/enum.ModulePriority.html).
 
-Il suffit de choisir la variante de l'énumération qui vous conviens puis de la retournée. Par exemple si votre module est optionel et désactivé par défaut :
+Il suffit de choisir la variante de l'énumération qui vous convient puis de la retourner. Par exemple si votre module est optionnel et désactivé par défaut :
 
 ```rust
     fn priority() -> ModulePriority {
@@ -192,9 +192,9 @@ Déclaration :
     fn ask_required_keys() -> RequiredKeys;
 ```
 
-Toutes les variantes de l'énumération `RequiredKeys` sont présentés dans la [documentation auto-générée](https://nodes.duniter.io/rust/duniter-rs/duniter_module/enum.RequiredKeys.html).
+Toutes les variantes de l'énumération `RequiredKeys` sont présentées dans la [documentation auto-générée](https://nodes.duniter.io/rust/duniter-rs/duniter_module/enum.RequiredKeys.html).
 
-Il suffit de choisir la variante de l'énumération qui vous conviens puis de la retournée. PAr exemple si vous n'avez besoin d'aucune clé :
+Il suffit de choisir la variante de l'énumération qui vous convient puis de la retourner. Par exemple si vous n'avez besoin d'aucune clé :
 
 ```rust
     fn ask_required_keys() -> RequiredKeys {
@@ -247,12 +247,12 @@ Déclaration :
     ) -> Result<(), ModuleInitError>;
 ```
 
-Dans le cas d'un module qui ne servirait qu'a ajouter une sous-commande a la ligne de commande Durs, l'implémentation de la fonction start reste oblogatoire et le module doit absolument s'enregistrer auprès du router quand même et garder son thread actif jusqu'a 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 a 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 votrre 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.
+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.
 
-Ensuite si `load_conf_only` vaut `true` vous n'avez plus rien a faire, retournez `Ok(())`.
+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 :
 
 1. Créez votre channel
@@ -263,20 +263,20 @@ En revanche, si `load_conf_only` vaut `false` c'est qu'il vous faut réellement
 
 4. Faites les traitements que vous devez faire avant votre main loop (ça peut être rien si votre module est petit).
 
-5. Lancez votre main loop au sein de laquelle vous écouterez les messages arrivant dans votre channel.
+5. Lancez votre main loop au sein duquel vous écouterez les messages arrivant dans votre channel.
 
-Si jamais le router n'a pas reçu l'enregistrement de tout les modules au bout de 20 secondes, il interromp de programme.  
-Le plus important est donc d'enregistrer votre module auprès du router AVANT tout traitement lourd ou couteux.
-20 secondes peut vous sembler énorme, mais garder en tête que Durs peut être amené a s'éxcuter dans n'importequel 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é a d'autres taches).
+Si jamais le router n'a pas reçu l'enregistrement de tous les modules au bout de 20 secondes, il interrompt le programme.
+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 couteux dans votre module, il peut être pertinent de ne pas l'inclure dans la release pour micro-pc (architecture arm), n'hésitez pas a 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 couteux 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 a l'initialisation.
+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.
+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
 
 Tout d'abord, il faut ajouter votre module aux dépendances des crates binaires. Les dépendances d'une crate sont déclarées dans son fichier `Cargo.toml`.
 
-Par exemple, pour ajouter le module `toto` a la crate binaire `durs-server` il faut ajouter la ligne suivante dans la section `[dependencies]` du fichier `bin/durs-server/Cargo.toml` :
+Par exemple, pour ajouter le module `toto` à la crate binaire `durs-server` il faut ajouter la ligne suivante dans la section `[dependencies]` du fichier `bin/durs-server/Cargo.toml` :
 
     durs-toto = { path = "../../lib/modules/toto" }
 
@@ -284,24 +284,24 @@ 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 Carego.toml de `durs-server`, il vas falloir utiliser votre module dans le main.rs :
+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 :
 
 1. Utilisez votre structure implémentant le trait DursModule :
 
     pub use durs_toto::TotoModule;
 
-2. Ajouter votre module en paramètre de la macro `durs_plug!` :
+2. Ajoutez votre module en paramètre de la macro `durs_plug!` :
 
     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, tout 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-noeuds, 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!` :
 
     durs_inject_cli![WS2PModule, .., TotoModule],
 
-    La macro `durs_inject_cli!` n'accepte qu'un seul tableau qui doit comporter tout les modules injectant une sous-commande, pas de distinction ici.
+    La macro `durs_inject_cli!` n'accepte qu'un seul tableau qui doit comporter tous les modules injectant une sous-commande, pas de distinction ici.
 
-    Notez que votre module doit DANS TOUT LES CAS être ajouté a la macro `durs_plug!` sinon sa sous-commande ne fonctionnera pas.
+    Notez que votre module doit DANS TOUT LES CAS être ajouté à la macro `durs_plug!` sinon sa sous-commande ne fonctionnera pas.
 
-Tutoriel en cours de rédaction...
\ No newline at end of file
+Tutoriel en cours de rédaction...
diff --git a/doc/fr/developpeurs/installer-son-environnement-de-dev.md b/doc/fr/developpeurs/installer-son-environnement-de-dev.md
index a525249bfcc84a30befc8198828e35e2bc8f00ba..ee63f65150d5f0514c9fb356fb2d37bf3c1152bd 100644
--- a/doc/fr/developpeurs/installer-son-environnement-de-dev.md
+++ b/doc/fr/developpeurs/installer-son-environnement-de-dev.md
@@ -3,7 +3,7 @@
 Date: 2018-05-11
 Authors: elois
 
-Dans ce tutoriel nous allons voir comment installer un environnement [Rust](https://www.rust-lang.org) complet.  
+Dans ce tutoriel nous allons voir comment installer un environnement [Rust](https://www.rust-lang.org) complet.
 Cela vous servira pour vos propres projets Rust, ou pour contribuer a Duniter-rs, ou pour faire du binding NodeJS-Rust.
 
 ## Installation de la toolchain stable
@@ -12,45 +12,45 @@ 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
 
 Vous aurez aussi besoin d'un environnement de développement intégré.
 
-Rust étant un langage très récent, il n'a pas d'Environnement de Développement Intégré (IDE) dédié.  
+Rust étant un langage très récent, il n'a pas d'Environnement de Développement Intégré (IDE) dédié.
 Heureusement, plusieurs IDE existants intègrent Rust via des plugins, nous vous recommandons VSCode ou IntelliJ.
 
 Vous pouvez également développer en Rust avec les IDE/Editeurs suivants :
@@ -88,11 +88,11 @@ Enfin installez le plugin pour rust en tapant "Rust" dans le moteur de recherche
 
 Une fois vscode installé nous aurons besoin des 3 plugins suivants :
 
-* BetterTOML  
+* BetterTOML
 * CodeLLDB
 * Rust (rls)
 
-Après avoir installé les plugins, relancez votre IDE, il devrait vous proposer spontanément d'installer RLS, dites oui.  
+Après avoir installé les plugins, relancez votre IDE, il devrait vous proposer spontanément d'installer RLS, dites oui.
 Si cela échoue pour RLS, vous devrez l'installer manuellement avec la commande suivante :
 
     rustup component add rls-preview rust-analysis rust-src
@@ -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.