diff --git a/fr/6/00-overview.md b/fr/6/00-overview.md
index c22073bd70..b9fa8fff23 100644
--- a/fr/6/00-overview.md
+++ b/fr/6/00-overview.md
@@ -10,7 +10,7 @@ Vous n'êtes pas un CryptoZombie ordinaire...
 
 En finissant la Leçon 5, vous avez prouvé que vous avez une assez bonne compréhension de Solidity.
 
-Mais aucune DApp est terminée sans un moyen pour ses utilisateurs d'interagir avec...
+Mais aucune DApp n'est terminée sans un moyen pour ses utilisateurs d'interagir avec...
 
 Dans cette leçon, nous allons voir comment interagir avec votre smart contract et construire un front-end basique pour votre DApp en utilisant une bibliothèque appelée **Web3.js**.
 
diff --git a/fr/6/01.md b/fr/6/01.md
index 8b94115ce3..ba9677c1c7 100644
--- a/fr/6/01.md
+++ b/fr/6/01.md
@@ -363,7 +363,7 @@ material:
       </html>
 ---
 
-En terminant la Leçon 5, notre DApp zombie est terminée. Maintenant, nous allons créer une page web basique où vos utilisateurs pourrons interagir avec.
+En terminant la Leçon 5, notre DApp zombie est terminée. Maintenant, nous allons créer une page web basique où vos utilisateurs pourront interagir avec.
 
 Pour cela, nous allons utiliser une bibliothèque JavaScript de la fondation Ethereum appelée **_Web3.js_**.
 
@@ -384,7 +384,7 @@ Les nœuds Ethereum parlent seulement un langage appelé **_JSON-RPC_**, qui n'e
 
 Heureusement, Web3.js cache ces vilaines requêtes de notre vue, et vous avez seulement besoin d'interagir avec une interface JavaScript pratique et lisible.
 
-Au lieu d'écrire la requête ci-dessus, appelez une fonction dans votre code ressemblera à ceci :
+Au lieu d'écrire la requête ci-dessus, appeler une fonction dans votre code ressemblera à ceci :
 
 ```
 CryptoZombies.methods.createRandomZombie("Vitalik Nakamoto 🤔")
diff --git a/fr/6/02.md b/fr/6/02.md
index 8836f2b7d4..668d55f8c3 100644
--- a/fr/6/02.md
+++ b/fr/6/02.md
@@ -393,7 +393,7 @@ Vous pourriez héberger votre propre nœud Ethereum comme fournisseur. Mais il e
 
 ## Infura
 
-<a href="https://infura.io/" target=_blank>Infura</a> est un service qui a plusieurs nœuds Ethereum avec une fonctionnalité de cache pour des lectures plus rapides, que vous pouvez accéder gratuitement depuis leur API. En utilisant Infura comme fournisseur, vous pouvez envoyer et recevoir des messages de la blockchain Ethereum de manière fiable, sans avoir à vous occuper de votre propre nœud.
+<a href="https://infura.io/" target=_blank>Infura</a> est un service qui a plusieurs nœuds Ethereum avec une fonctionnalité de cache pour des lectures plus rapides, auquel vous pouvez accéder gratuitement depuis leur API. En utilisant Infura comme fournisseur, vous pouvez envoyer et recevoir des messages de la blockchain Ethereum de manière fiable, sans avoir à vous occuper de votre propre nœud.
 
 Vous pouvez configurer Web3 pour utiliser Infura comme fournisseur web3 de cette manière :
 
@@ -407,7 +407,7 @@ Cependant, vu que notre DApp va avoir beaucoup d'utilisateurs - et que ces utili
 
 La cryptographie est compliquée, et à part si vous êtes un expert en sécurité et que vous savez vraiment ce que vous faîtes, ce ne sera sûrement pas une bonne idée de vouloir gérer les clés privées vous-même.
 
-Heureusement, vous n'avez pas besoin - il existe déjà des services qui s'en occupe pour vous. Le plus connu est **_MetaMask_**.
+Heureusement, vous n'avez pas besoin - il existe déjà des services qui s'en occupent pour vous. Le plus connu est **_MetaMask_**.
 
 ## MetaMask
 
@@ -448,6 +448,6 @@ Vous pouvez utiliser ce code standard dans toutes les applications que vous cré
 
 ## A votre tour
 
-Nous avons créez une balise script vide avant la balise de fermeture `</body>` dans notre fichier HTML. Vous pouvez écrire notre code javascript pour notre leçon ici.
+Nous avons créé une balise script vide avant la balise de fermeture `</body>` dans notre fichier HTML. Vous pouvez écrire notre code javascript pour notre leçon ici.
 
 1. Faites un copier/coller du code modèle ci-dessus pour détecter MetaMask. C'est le bloc qui commence par `window.addEventListener`.
diff --git a/fr/6/03.md b/fr/6/03.md
index 9dcb0584d1..8210089242 100644
--- a/fr/6/03.md
+++ b/fr/6/03.md
@@ -860,7 +860,7 @@ material:
       </html>
 ---
 
-Maintenant que nous avons initialiser Web3.js avec le fournisseur Web3 de MetaMask, nous allons configurer la communication avec notre smart contract.
+Maintenant que nous avons initialisé Web3.js avec le fournisseur Web3 de MetaMask, nous allons configurer la communication avec notre smart contract.
 
 
 Web3.js va avoir besoin de 2 choses pour pouvoir communiquer avec notre contrat : son **_adresse_** et son **_ABI_**.
@@ -869,14 +869,14 @@ Web3.js va avoir besoin de 2 choses pour pouvoir communiquer avec notre contrat
 
 Après avoir fini d'écrire votre smart contract, vous allez le compiler et le déployer sur Ethereum. Nous allons voir le **déploiement** dans la **prochaine leçon**, mais vu que c'est assez différent que d'écrire du code, nous avons décidé de ne pas faire dans l'ordre et de parler de Web3.js en premier.
 
-Après avoir déployer votre contrat, il sera associé à une adresse Ethereum pour toujours. Si vous vous rappelez la leçon 2, l'adresse du contrat CryptoKitties sur Ethereum est `0x06012c8cf97BEaD5deAe237070F9587f8E7A266d`.
+Après avoir déployé votre contrat, il sera associé à une adresse Ethereum pour toujours. Si vous vous rappelez la leçon 2, l'adresse du contrat CryptoKitties sur Ethereum est `0x06012c8cf97BEaD5deAe237070F9587f8E7A266d`.
 
 Vous allez avoir besoin de copier cette adresse après le déploiement afin de pouvoir communiquer avec le smart contract.
 
 
 ## ABI du contrat
 
-L'autre chose que Web3.js à besoin pour communiquer avec votre contrat et son **_ABI_**.
+L'autre chose dont Web3.js a besoin pour communiquer avec votre contrat et son **_ABI_**.
 
 ABI veut dire "Application Binary Interface" (Interface Binaire d'Application). Fondamentalement, c'est une représentation des fonctions de votre contrat au format JSON qui indique à Web3.js comment formater les appels aux fonctions pour que votre contrat les comprenne.
 
@@ -897,9 +897,9 @@ var myContract = new web3js.eth.Contract(myABI, myContractAddress);
 
 ## A votre tour
 
-1. Dans le `<head>` de notre document, ajouter une autre balise de script pour `cryptozombies_abi.js` afin que nous puissions importer l'ABI à notre projet.
+1. Dans le `<head>` de notre document, ajoutez une autre balise de script pour `cryptozombies_abi.js` afin que nous puissions importer l'ABI à notre projet.
 
-2. Au début de notre balise `<script>` dans le `<body>`, déclarez une `var` appelée `cryptoZombies`, mais ne lui attribuez pas de valeur. Nous allons nous servir de cet variable plus tard pour stocker notre contrat instancié.
+2. Au début de notre balise `<script>` dans le `<body>`, déclarez une `var` appelée `cryptoZombies`, mais ne lui attribuez pas de valeur. Nous allons nous servir de cette variable plus tard pour stocker notre contrat instancié.
 
 3. Ensuite, créez une `function` appelée `startApp()`. Nous la compléterons dans les 2 prochaines étapes.
 
diff --git a/fr/6/04.md b/fr/6/04.md
index 3002e21f0a..5658a6e7ee 100644
--- a/fr/6/04.md
+++ b/fr/6/04.md
@@ -439,11 +439,11 @@ Web3.js a deux méthodes que nous allons utiliser pour appeler les fonctions de
 
 ### Call
 
-`call` est utilisé pour les fonctions `view` et`pure`. C'est exécuté seulement sur le nœud local, et cela ne va pas créer de transaction sur la blockchain.
+`call` est utilisé pour les fonctions `view` et `pure`. Il est exécuté seulement sur le nœud local, et cela ne va pas créer de transaction sur la blockchain.
 
 > **Rappel :** les fonctions `view` et `pure` sont des fonctions en lecture seule et ne changent pas l'état de la blockchain. Elles ne coûtent pas de gas et l'utilisateur n'aura pas besoin de signer de transaction avec MetaMask.
 
-En utilisant Web3,js, vous allez appeler (`call`) une fonction nommée `myMethod` avec le paramètre `123`  comme ceci :
+En utilisant Web3.js, vous allez appeler (`call`) une fonction nommée `myMethod` avec le paramètre `123`  comme ceci :
 
 ```
 myContract.methods.myMethod(123).call()
@@ -453,7 +453,7 @@ myContract.methods.myMethod(123).call()
 
 `send` va créer une transaction et changer l'état des données sur la blockchain. Vous aurez besoin d'utiliser `send` pour toutes les fonctions qui ne sont pas `view` ou `pure`.
 
-> **Remarque :** Envoyer une transaction avec `send` demandera à l'utilisateur de payer du gas, en faisant apparaître MetaMask pour leur demander de signer une transaction. Quand on utilise MetaMask comme fournisseur web3, tout cela se fait automatiquement quand on appelle `send()`, et on n'a pas besoin de faire quoique ce soit de spécial dans notre code. Plutôt cool !
+> **Remarque :** Envoyer une transaction avec `send` demandera à l'utilisateur de payer du gas, en faisant apparaître MetaMask pour leur demander de signer une transaction. Quand on utilise MetaMask comme fournisseur web3, tout cela se fait automatiquement lors de l'appel de `send()`, et on n'a pas besoin de faire quoi que ce soit de spécial dans notre code. Plutôt cool !
 
 En utilisant Web3.js, vous allez envoyer (`send`) une transaction appelant une fonction `myMethod` avec le paramètre `123` comme ceci :
 
@@ -475,9 +475,9 @@ Zombie[] public zombies;
 
 En Solidity, quand vous déclarez une variable `public`, cela crée automatiquement une fonction "getter" (une fonction de récupération) public avec le même nom. Si vous voulez récupérer le zombie avec l'id `15`, vous l’appellerez comme si c'était une fonction : `zombies(15)`.
 
-Voici comment nous écririons notre fonction JavaScript de notre front-end qui récupérerait un id zombie, interrogerait notre contrat pour ce zombie, et renverrai le résultat :
+Voici comment nous écririons notre fonction JavaScript de notre front-end qui récupérerait un id zombie, interrogerait notre contrat pour ce zombie, et renverrait le résultat :
 
-> Remarque : Tous les exemples de code que nous utilisons dans cette leçon utilisent la **version 1.0** de Web3.js, qui utilise les promesses au lieu des callbacks. Beaucoup de tutoriels que vous allez voir en ligne utilisent une ancienne version de Web3.js. La syntaxe a beaucoup changée avec la version 1.0, si vous copiez du code d'autres tutoriels, assurez-vous qu'ils utilisent la même version que vous !
+> Remarque : Tous les exemples de code que nous utilisons dans cette leçon utilisent la **version 1.0** de Web3.js, qui utilise les promesses au lieu des callbacks. Beaucoup de tutoriels que vous allez voir en ligne utilisent une ancienne version de Web3.js. La syntaxe a beaucoup changé avec la version 1.0, si vous copiez du code d'autres tutoriels, assurez-vous qu'ils utilisent la même version que vous !
 
 ```
 function getZombieDetails(id) {
diff --git a/fr/6/05.md b/fr/6/05.md
index 848af7e624..e7abd33f33 100644
--- a/fr/6/05.md
+++ b/fr/6/05.md
@@ -457,7 +457,7 @@ Maintenant essayons de mettre en place quelque chose - disons que nous voulons q
 
 Évidemment nous allons d'abord devoir utiliser notre fonction `getZombiesByOwner(owner)` pour récupérer tous les IDs des zombies que l'utilisateur possède.
 
-Mais notre contrat Solidity s'attend que `owner` soit une `address` Solidity. Comment connaître l'adresse de l'utilisateur de notre application ?
+Mais notre contrat Solidity s'attend à ce que `owner` soit une `address` Solidity. Comment connaître l'adresse de l'utilisateur de notre application ?
 
 ## Obtenir l'adresse de l'utilisateur avec MetaMask
 
@@ -488,7 +488,7 @@ Ce code vérifie toutes les 100 millisecondes que `userAccount` est toujours ég
 
 ## A votre tour
 
-Faisons en sorte de notre application montre l'armée de zombie de notre utilisateur au chargement initial de la page, et surveille le compte MetaMask actif pour mettre à jour l'interface s'il change.
+Faisons en sorte que notre application montre l'armée de zombie de notre utilisateur au chargement initial de la page, et surveille le compte MetaMask actif pour mettre à jour l'interface s'il change.
 
 1. Déclarez une `var` appelée `userAccount`, mais ne lui attribuez pas de valeur
 
diff --git a/fr/6/06.md b/fr/6/06.md
index 9e67328875..5d6790a99f 100644
--- a/fr/6/06.md
+++ b/fr/6/06.md
@@ -491,11 +491,11 @@ Ce tutoriel serait incomplet si nous ne vous montrions pas comment afficher les
 
 Cependant, de façon réaliste, vous allez vouloir utiliser un framework front-end comme React ou Vue.js pour votre application, car ils vous simplifient vraiment la vie en tant que développeur front-end.  
 
-Afin de rester concentrer sur Ethereum et les smart contracts, nous allons simplement vous montrer un exemple rapide en JQuery pour vous montrer comment analyser et afficher les données récupérées de votre smart contract.
+Afin de rester concentrés sur Ethereum et les smart contracts, nous allons simplement vous montrer un exemple rapide en JQuery pour vous montrer comment analyser et afficher les données récupérées de votre smart contract.
 
 ## Afficher les données zombie - un exemple primaire
 
-Nous avons ajouter un `<div id="zombies"></div>` vide au corps de notre document, ainsi qu'une fonction `displayZombies` vide.
+Nous avons ajouté un `<div id="zombies"></div>` vide au corps de notre document, ainsi qu'une fonction `displayZombies` vide.
 
 Rappelez-vous du précédent chapitre, nous avons appelé `displayZombies` à l'intérieur de `startApp()` avec le résultat obtenu de l'appel à `getZombiesByOwner`. Il recevra un tableau d'IDs zombie qui ressemblera à :
 
@@ -503,15 +503,15 @@ Rappelez-vous du précédent chapitre, nous avons appelé `displayZombies` à l'
 [0, 13, 47]
 ```
 
-Donc nous voulons que notre fonction `displayZombies` fasse :
+Donc nous voulons que notre fonction `displayZombies` ait le comportement suivant :
 
-1. Premièrement, supprime le contenu du div `#zombies`, s'il y a quelque chose à l'intérieur. (De cette manière, si l'utilisateur change de compte actif dans MetaMask, cela supprimera l'ancienne armée de zombie avant de charger la nouvelle).
+1. Premièrement, supprimez le contenu de la div `#zombies` s'il y a quelque chose à l'intérieur. (De cette manière, si l'utilisateur change de compte actif dans MetaMask, cela supprimera l'ancienne armée de zombie avant de charger la nouvelle).
 
-2. Itère pour chaque `id`, et pour chacun appelle `getZombieDetails(id)` pour récupérer toutes les informations de ce zombie à partir de notre smart contract, ensuite
+2. Itérez pour chaque `id`, et pour chaque appel `getZombieDetails(id)` afin de récupérer toutes les informations de ce zombie à partir de notre smart contract. Ensuite
 
-3. Mettre ces informations dans un gabarit HTML pour qu'elles soient correctement formatées pour l'affichage, et les rajouter au div `#zombies`.
+3. Mettez ces informations dans un template HTML pour qu'elles soient correctement formatées pour l'affichage, et ajoutez-les à la div `#zombies`.
 
-Pour rappel, nous utilisons simplement du JQuery ici, qui n'a pas de gabarit par défaut, le résultat ne sera pas beau. Voici un exemple simple de comment nous pourrions afficher les données pour chaque zombie :
+Pour rappel, nous utilisons simplement du JQuery ici, qui n'a pas de template par défaut, le résultat ne sera pas beau. Voici un exemple simple de comment nous pourrions afficher les données pour chaque zombie :
 
 ```
 // On récupère les informations des zombies à partir de notre contrat. On renvoie un objet `zombie`
@@ -536,7 +536,7 @@ getZombieDetails(id)
 
 Dans l'exemple ci-dessus, nous affichons simplement l'ADN comme une chaîne de caractères. Mais dans votre DApp, vous allez vouloir convertir cela en images pour afficher votre zombie.
 
-Nous avons fait cela en divisant l'ADN en plusieurs chaîne de caractères, et en ayant chaque pair de chiffre qui correspond à une image. De cette manière là :
+Nous avons fait cela en divisant l'ADN en plusieurs chaînes de caractères, et en ayant chaque paire de chiffres qui correspond à une image. De cette manière là :
 
 ```
 // On obtient un entier entre 1 et 7 qui représente la tête de notre zombie :
@@ -548,16 +548,16 @@ var headSrc = "../assets/zombieparts/head-" + head + ".png"
 
 Chaque composant est positionné avec du CSS en utilisant le positionnement absolu, afin de le superposer sur les autres images.
 
-Si vous voulez voir exactement comment nous l'avons implémenté, nous avons rendu le code Open Source de notre composant Vue.js que nous utilisons pour l'apparence des zombies, vous pouvez le voir <a href="https://github.com/loomnetwork/zombie-char-component" target=_blank>ici</a>.
+Si vous voulez voir exactement comment nous l'avons implémenté, nous avons rendu Open Source le code de notre composant Vue.js utilisé pour l'apparence des zombies, vous pouvez le voir <a href="https://github.com/loomnetwork/zombie-char-component" target=_blank>ici</a>.
 
-Cependant, puisqu'il y a beaucoup de code dans ce fichier, c'est en dehors du cadre de ce tutoriel. Pour cette leçon, nous resterons avec l'exemple basique de l'implémentation JQuery ci-dessus, et nous vous laissons l'opportunité de faire une implémentation plus belle comme entraînement 😉
+Cependant, puisqu'il y a beaucoup de code dans ce fichier, c'est en dehors du cadre de ce tutoriel. Pour cette leçon, nous garderons l'exemple basique de l'implémentation JQuery ci-dessus, et nous vous laissons l'opportunité de faire une implémentation plus belle comme entraînement 😉
 
 ## A votre tour
 
 Nous avons créé une fonction `displayZombies` vide pour vous. Nous allons la compléter.
 
-1. La première chose que nous voulons faire et de supprimer le contenu du div `#zombies`. En JQuery, vous pouvez faire cela avec `$("#zombies").empty();`.
+1. La première chose que nous voulons faire est de supprimer le contenu de la div `#zombies`. En JQuery, vous pouvez faire cela avec `$("#zombies").empty();`.
 
-2. Ensuite, nous allons vouloir itérer tous les ids, en utilisant une boule "for": `for (id of ids) {`
+2. Ensuite, nous allons vouloir itérer sur tous les ids, en utilisant une boucle "for": `for (id of ids) {`
 
-3. À l'intérieur de cette boucle, copiez/collez le bloc de code ci-dessus qui appelle `getZombieDetails(id)` pour chaque id et ensuite utilisez `$("#zombies").append(...)` pour l'ajouter à notre HTML.
+3. À l'intérieur de cette boucle, copiez/collez le bloc de code ci-dessus qui appelle `getZombieDetails(id)` pour chaque id puis utilisez `$("#zombies").append(...)` pour l'ajouter à notre HTML.
diff --git a/fr/6/07.md b/fr/6/07.md
index 97c0168db3..9ce368e312 100644
--- a/fr/6/07.md
+++ b/fr/6/07.md
@@ -551,15 +551,15 @@ Maintenant nous allons voir comment changer les données de notre smart contract
 
 Il y a quelques différences majeures avec les fonctions `call` :
 
-1. Envoyer avec `send` une transaction nécessite une adresse `from` de celui qui appelle la fonction (qui devient `msg.sender` dans votre code Solidity). Nous allons vouloir que ce soit l'utilisateur de notre DApp, afin que MetaMask affiche une fenêtre pour lui demander de signer la transaction.
+1. Envoyer une transaction avec `send` nécessite une adresse `from` de celui qui appelle la fonction (qui devient `msg.sender` dans votre code Solidity). Nous allons vouloir que ce soit l'utilisateur de notre DApp, afin que MetaMask affiche une fenêtre pour lui demander de signer la transaction.
 
-2. Envoyer avec `send` une transaction coûte du gas
+2. Envoyer avec `send` une transaction coûte du gas.
 
 3. Il y a un certain délais entre le moment où l'utilisateur envoie une transaction avec `send` et le moment où cette transaction prend effet sur la blockchain. C'est parce qu'il faut attendre que la transaction soit incluse dans un bloc, et un bloc est créé toutes les 15 sec environ avec Ethereum. S'il y a beaucoup de transactions en attente, ou si l'utilisateur paye un prix de gas trop bas, notre transaction pourrait attendre plusieurs blocs avant d'être incluse, et cela pourrait prendre plusieurs minutes.
 
   C'est pour ça que nous avons besoin que notre application gère la nature asynchrone de ce code.
 
-## Créer de zombies
+## Créer des zombies
 
 Nous allons voir un exemple avec la première fonction de notre contrat qu'un utilisateur appellera : `createRandomZombie`.
 
@@ -599,9 +599,9 @@ function createRandomZombie(name) {
 Notre fonction envoie avec `send` une transaction à notre fournisseur Web3, et met à la chaîne un écouteur d'évènements :
 
 - `receipt` (reçu) va être émis quand la transaction est incluse dans un bloc Ethereum, ce qui veut dire que notre zombie a été créé et sauvegardé dans notre contrat.
-- `error` (erreur) va être émis s'il y a un problème qui empêche la transaction d'être incluse dans un bloc, tel qu'un envoie insuffisant de gas par l'utilisateur. Nous allons vouloir informer l'utilisateur que la transaction n'a pas marché pour qu'il puisse réessayer.
+- `error` (erreur) va être émis s'il y a un problème qui empêche la transaction d'être incluse dans un bloc, tel qu'un envoi insuffisant de gas par l'utilisateur. Nous allons vouloir informer l'utilisateur que la transaction n'a pas marché pour qu'il puisse réessayer.
 
-> Remarque : Vous avec le choix de spécifier le `gas` et `gasPrice` quand vous appelez `send`, ex : `.send({ from: userAccount, gas: 3000000 })`. Si vous ne le spécifiez pas, MetaMask va laisser l'utilisateur choisir ces valeurs.
+> Remarque : Vous avez le choix de spécifier le `gas` et `gasPrice` quand vous appelez `send`, ex : `.send({ from: userAccount, gas: 3000000 })`. Si vous ne le spécifiez pas, MetaMask va laisser l'utilisateur choisir ces valeurs.
 
 ## A votre tour
 
@@ -613,7 +613,7 @@ Nous avons ajouté un `div` avec l'ID `txStatus` - de cette manière, nous pouvo
 
   La logique pour appeler `feedOnKitty` est pratiquement la même - nous allons envoyer une transaction qui appelle la fonction, si la transaction réussie, un nouveau zombie sera créé, et nous aurons donc besoin de rafraîchir l'interface juste après.
 
-  Faites une copie de `createRandomZombie` juste en dessous, avec les changements suivant :
+  Faites une copie de `createRandomZombie` juste en dessous, avec les changements suivants :
 
   a) Appelez la 2ème fonction `feedOnKitty`, avec 2 paramètres : `zombieId` et `kittyId`
 
diff --git a/fr/6/08.md b/fr/6/08.md
index 8448e18158..f38e605bce 100644
--- a/fr/6/08.md
+++ b/fr/6/08.md
@@ -585,7 +585,7 @@ material:
 
 Les logiques pour `attack`, `changeName`, et `changeDna` seront extrêmement similaires, elles sont faciles à implémenter et nous ne passerons donc pas de temps à les écrire dans cette leçon.
 
-> En fait, il y a déjà beaucoup de logique qui se répète dans ces appels de fonction, il serait donc utile de les refactoriser et de mettre le code commun dans sa propre fonction. (et d'utiliser un système de modèle pour les messages `txStatus` - Nous voyons déjà comme ça serait beaucoup plus clair avec un framework comme Vue.js !)
+> En fait, il y a déjà beaucoup de logique qui se répète dans ces appels de fonction, il serait donc utile de les refactoriser et de mettre le code commun dans sa propre fonction. (et d'utiliser un système de modèle pour les messages `txStatus` - Nous voyons déjà à quel point ce serait plus clair avec un framework comme Vue.js !)
 
 Voyons un autre type de fonction qui demande un traitement spécial en Web3.js - les fonctions `payable`.
 
@@ -631,6 +631,6 @@ Nous allons ajouter une fonction `levelUp` en dessous de `feedOnKitty`. Le code
 
 3. Quand `levelUp` est appelé, `"0.001"` ETH converti avec `toWei` devra être envoyé, comme dans l'exemple ci-dessus
 
-4. Si cela réussi, le texte devra afficher `"Quelle puissance écrasante ! Le zombie a bien gagné un niveau"`
+4. Si cela réussit, le texte devra afficher `"Quelle puissance écrasante ! Le zombie a bien gagné un niveau"`
 
 5. Nous **n'avons pas** besoin de rafraîchir l'interface en appelant notre smart contract avec `getZombiesByOwner` — car dans ce cas là, la seule chose qui a changé c'est le niveau du zombie.
diff --git a/fr/6/09.md b/fr/6/09.md
index f75274738e..aba189e6e4 100644
--- a/fr/6/09.md
+++ b/fr/6/09.md
@@ -601,7 +601,7 @@ material:
       </html>
 ---
 
-Comme vous pouvez le voir, c'est plutôt simple d'interagir avec votre contrat via Web3.js - une fois que vous avez votre environnement configuré, appeler des fonctions et envoyer des transactions n'est pas vraiment différent qu'avec une API web classique.
+Comme vous pouvez le voir, c'est plutôt simple d'interagir avec votre contrat via Web3.js - une fois que vous avez votre environnement configuré, appeler des fonctions et envoyer des transactions n'est pas vraiment différent d'avec une API web classique.
 
 Il y a encore un aspect que nous voulons couvrir - s'abonner à des évènements de votre contrat.
 
@@ -634,10 +634,10 @@ Afin de filtrer les évènements et écouter seulement les changements liés à
 event Transfer(address indexed _from, address indexed _to, uint256 _tokenId);
 ```
 
-Dans ce cas, puisque `_from` et `_to` sont `indexed`, cela veut dire que nous pouvons les utiliser comme filtre dans notre écouteur d'évènements de notre front-end :
+Dans ce cas, puisque `_from` et `_to` sont `indexed`, cela veut dire que nous pouvons les utiliser comme filtres dans notre écouteur d'évènements de notre front-end :
 
 ```
-// On utilise `filter` pour seulement lancer ce code quand `_to` est égal à `userAccount`
+// On utilise `filter` pour lancer ce code seulement quand `_to` est égal à `userAccount`
 cryptoZombies.events.Transfer({ filter: { _to: userAccount } })
 .on("data", function(event) {
   let data = event.returnValues;
@@ -650,7 +650,7 @@ Comme vous pouvez le voir, utiliser les champs `event` et `indexed` est une bonn
 
 ## Interroger les évènements passés
 
-Nous pouvons interroger les évènements passés en utilisant `getPastEvents`, et utiliser les filtres `fromBlock` et `toBlock` pour indiquer à Solidity l'intervalle de temps pour récupérer nos évènements ("block" dans ce cas fait référence au numéro de bloc Ethereum) :
+Nous pouvons interroger les évènements passés en utilisant `getPastEvents`, et utiliser les filtres `fromBlock` et `toBlock` pour indiquer à Solidity l'intervalle de temps pour récupérer nos évènements (dans ce cas, "block" fait référence au numéro de bloc Ethereum) :
 
 ```
 cryptoZombies.getPastEvents("NewZombie", { fromBlock: 0, toBlock: "latest" })
@@ -662,17 +662,17 @@ cryptoZombies.getPastEvents("NewZombie", { fromBlock: 0, toBlock: "latest" })
 
 Puisque vous pouvez utiliser cette méthode pour récupérer tous les évènements depuis la nuit des temps, cela peut être un cas d'utilisation intéressant : **Utiliser les évènements comme un moyen de stockage moins cher**.
 
-Si vous vous rappelez, enregistrer des données sur la blockchain est un des opérations les plus chères en Solidity. Utiliser des évènements est beaucoup moins cher en terme de gas.
+Si vous vous rappelez, enregistrer des données sur la blockchain est une des opérations les plus chères en Solidity. Utiliser des évènements est beaucoup moins cher en terme de gas.
 
-En contrepartie, les évènements ne sont pas lisibles depuis le smart contract. Mais c'est cas d'utilisation important à retenir si vous voulez stocker de l'information avec un historique sur la blockchain afin de le lire depuis le front-end de votre application.
+En contrepartie, les évènements ne sont pas lisibles depuis le smart contract. Mais c'est un cas d'utilisation important à retenir si vous voulez stocker de l'information avec un historique sur la blockchain afin de le lire depuis le front-end de votre application.
 
-Par exemple, nous pourrions l'utiliser pour avoir un historique de nos combats de zombies - nous pourrions créer un évènement à chaque fois qu'un zombie attaque et gagne. Le smart contract n'a pas besoin de cette information pour calculer quoique ce soit, mais cela pourrait être une information utile pour le front-end de notre application.
+Par exemple, nous pourrions l'utiliser pour avoir un historique de nos combats de zombies - nous pourrions créer un évènement à chaque fois qu'un zombie attaque et gagne. Le smart contract n'a pas besoin de cette information pour calculer quoi que ce soit, mais cela pourrait être une information utile pour le front-end de notre application.
 
 ## A votre tour
 
 Nous allons ajouter du code pour écouter l'évènement `Transfer`, et mettre à jour notre interface si l’utilisateur actuel reçoit un nouveau zombie.
 
-Nous allons avoir besoin d'ajouter ce code à la fin de la fonction `startApp`, pour être sûr que le contrat `cryptoZombies` soit bien initialisé avant d'ajouter l'écouteur d'évènements.
+Nous allons avoir besoin d'ajouter ce code à la fin de la fonction `startApp`, pour être sûrs que le contrat `cryptoZombies` soit bien initialisé avant d'ajouter l'écouteur d'évènements.
 
 1. À la fin de `startApp()`, copiez/collez le bloc de code ci-dessous qui écoute pour un `cryptoZombies.events.Transfer`
 
diff --git a/fr/6/10-wrappingitup.md b/fr/6/10-wrappingitup.md
index 4448aec9af..2252ceef45 100644
--- a/fr/6/10-wrappingitup.md
+++ b/fr/6/10-wrappingitup.md
@@ -11,7 +11,7 @@ material:
     answer: 1
 ---
 
-Félicitations ! Vous avez écrit avec succès votre premier front-end Web3.js qui interagie avec votre smart contract.
+Félicitations ! Vous avez écrit avec succès votre premier front-end Web3.js qui interagit avec votre smart contract.
 
 Comme récompense, vous obtenez votre propre zombie `The Phantom of Web3` de niveau 3.0 (pour Web 3.0 😉), avec en plus le masque de renard. Vous pouvez le voir à droite.
 
@@ -23,13 +23,13 @@ L'implémentation est donc minimale. Voici une liste d'idées de choses que l'on
 
 1. Implémenter des fonctions pour `attack`, `changeName`, `changeDna`, et les fonctions ERC721 `transfer`, `ownerOf`, `balanceOf`, etc. L'implémentation de ces fonctions sera identique aux autres transactions `send` que nous avons vu.
 
-2. Implémenter une "page admin" où vous pouvez exécuter `setKittyContractAddress`, `setLevelUpFee`, et `withdraw`. À nouveau, il n'y a pas de logique spéciale coté front-end - ces implémentations seraient identiques aux fonctions que nous avons déjà vu. Vous devrez juste vous assurer que vous les appelez depuis la même adresse Ethereum que celle qui a déployé le contrat, puisqu'elles ont le modificateur `onlyOwner`.
+2. Implémenter une "page admin" où vous pouvez exécuter `setKittyContractAddress`, `setLevelUpFee`, et `withdraw`. Ici encore, il n'y a pas de logique spéciale coté front-end - ces implémentations seraient identiques aux fonctions que nous avons déjà vu. Vous devrez juste vous assurer que vous les appelez depuis la même adresse Ethereum que celle qui a déployé le contrat, puisqu'elles ont le modificateur `onlyOwner`.
 
 3. Il y a plusieurs vues dans notre application que nous voudrions implémenter :
 
-  a. Une page zombie individuelle, où l'on peut voir les infos d'un zombie en particulier avec un lien permanent associé. Cette page devra afficher l'apparence du zombie, son nom, son propriétaire (avec un lien vers le profil de l'utilisateur), son compteur victoire/défaite, son historique de combats, etc.
+  a. Une page zombie individuelle, où l'on peut voir les infos d'un zombie en particulier avec un lien permanent associé. Cette page devra afficher l'apparence du zombie, son nom, son propriétaire (avec un lien vers le profil de l'utilisateur), son compteur victoires/défaites, son historique de combats, etc.
 
-  b. Une page utilisateur, où on peut voir l'armée de zombie d'un utilisateur avec un lien permanent. On doit pouvoir cliquer sur un zombie pour voir sa page, et aussi cliquer sur un zombie pour l'attaquer si on est connecté avec MetaMask et qu'on a une armée.
+  b. Une page utilisateur, où l'on peut voir l'armée de zombie d'un utilisateur avec un lien permanent. On doit pouvoir cliquer sur un zombie pour voir sa page, et aussi cliquer sur un zombie pour l'attaquer si on est connecté avec MetaMask et qu'on a une armée.
 
   c. Une page d'accueil, qui est une variation de la page utilisateur qui montre l'armée de zombie de l'utilisateur actuel. (C'est la page que nous avons commencé avec index.html).
 
@@ -37,9 +37,9 @@ L'implémentation est donc minimale. Voici une liste d'idées de choses que l'on
 
 5. Une fonction dans l'interface pour que l'utilisateur puisse attaquer le zombie d'un autre utilisateur.
 
-  Une façon de faire ça serait quand l'utilisateur navigue sur la page d'un autre utilisateur, il pourrait y avoir un bouton qui dit "Attaquer ce zombie". Quand l'utilisateur clique dessus, cela afficher un modal qui contient l'armée de l'utilisateur actif et lui demanderait "Avec quel zombie voulez-vous attaquer ?"
+  Une façon de faire ça serait que lorsque l'utilisateur navigue sur la page d'un autre utilisateur, il pourrait y avoir un bouton qui dit "Attaquer ce zombie". Quand l'utilisateur clique dessus, cela afficherait une modale qui contiendrait l'armée de l'utilisateur actif et lui demanderait "Avec quel zombie voulez-vous attaquer ?"
 
-  La page d'accueil utilisateur pourrait aussi avoir un bouton pour chaque zombie "Attaquer un autre zombie". Une fois cliqué, cela pourrait afficher un modal avec un champ de recherche pour rentrer l'ID d'un zombie. Une option pourrait dire "Attaquer un zombie aléatoire", qui rechercherait un nombre aléatoire.
+  La page d'accueil utilisateur pourrait aussi avoir un bouton pour chaque zombie "Attaquer un autre zombie". Une fois cliqué, cela pourrait afficher une modale avec un champ de recherche pour entrer l'ID d'un zombie. Une option pourrait dire "Attaquer un zombie aléatoire", qui rechercherait un nombre aléatoire.
 
   Il faudrait aussi griser les zombies de l'utilisateur dont la période d'attente n'est pas encore passée, afin que l'interface indique à l'utilisateur qu'il ne peut pas attaquer avec ce zombie, et combien de temps il doit attendre.
 
@@ -47,12 +47,11 @@ L'implémentation est donc minimale. Voici une liste d'idées de choses que l'on
 
 7. Pour les nouveaux utilisateurs, on pourrait afficher un message de bienvenue avec un moyen pour créer son premier zombie, en appelant `createRandomZombie()`.
 
-8. On voudrait sûrement ajouter un évènement `Attack` à notre smart contract avec l'adresse de l'utilisateur comme propriété `indexed` comme vu dans le chapitre précédent. Cela permettrait d'avoir des notifications en temps réel - on pourrait afficher une alerte à un utilisateur quand un de ses zombies est attaqué, et il pourrait voir le zombie/utilisateur qui l'a attaqué et rendre la pareille.
+8. On voudrait sûrement ajouter un évènement `Attack` à notre smart contract avec l'adresse de l'utilisateur comme propriété `indexed` comme vu dans le chapitre précédent. Cela permettrait d'avoir des notifications en temps réel - on pourrait afficher une alerte à un utilisateur lorsque l'un de ses zombies est attaqué, et il pourrait voir le zombie/utilisateur qui l'a attaqué et rendre la pareille.
 
 9. On voudrait certainement implémenter une sorte de cache pour notre front-end afin que nous ne soyons pas constamment en train d'interroger Infura avec des requêtes pour les mêmes données. (Notre implémentation actuelle de `displayZombies` appelle `getZombieDetails` pour chaque zombie à chaque fois que nous rafraîchissons l'interface - mais normalement nous devrions l'appeler seulement pour les nouveaux zombies ajoutés à notre armée).
 
-
-10. Un tchat en temps réel pour narguer les autres utilisateurs quand on écrase leur armée de zombie ? Oui svp.
+10. Un chat en temps réel pour narguer les autres utilisateurs quand on écrase leur armée de zombie ? Oui svp.
 
 C'est juste un début - Je suis sûr que vous avez encore pleins d'idées pour l'améliorer - et c'est déjà une bonne liste.