diff --git a/Birner_tp3_Network_Automation_avec_Ansible.pdf b/Birner_tp3_Network_Automation_avec_Ansible.pdf
index 38f7394f4b397f3a0db7f5cbd91c0598626d9cda..cbee0cebe67049c0943fcbea699b0abf5b88e919 100644
Binary files a/Birner_tp3_Network_Automation_avec_Ansible.pdf and b/Birner_tp3_Network_Automation_avec_Ansible.pdf differ
diff --git a/README.md b/README.md
index f22907c991f966bc2f2c238db809423d836c4f17..142bab43dfab7588bf74cf8b4f043cb933bbd083 100644
--- a/README.md
+++ b/README.md
@@ -36,7 +36,7 @@ Illustration de la topologie que nous allons utiliser pour ce laboratoire.
 ansible -m ping -i "H1,H2,R1,R2" all
 ```
 
-Cette commande fait appel au module de ping et effectue un ping sur tous les hôtes spécifié dans l'inventory. En réalise un test connectivity depuis notre machine.
+Cette commande fait appel au module **ping** et effectue un ping sur tous les hôtes spécifié dans l'inventory. On réalise donc ici un test connectivity depuis notre machine hôte.
 
 
 **Résultat de la commande:**
@@ -124,7 +124,7 @@ ssh H1 ls /tmp/hello.txt
 
 ## Quelle est la différente entre les modules command, shell et raw ? Expliquez et donner des exemples.
 
-Ces trois commande on le même objectif, à savoir exécuter des commandes sur les noeuds.
+Ces trois commandes ont le même objectif, à savoir exécuter des commandes sur les noeuds.
 
 ### Command
 
@@ -177,7 +177,7 @@ Exemple playbook
 
 ### Raw
 
-Maintenant, le module **raw** utilise simplement SSH et contourne le sous-système du module Ansible. De cette façon, le module **raw** fonctionnera avec succès sur le nœud géré même si Python n'est pas installé (sur le nœud géré). Le module "raw" est utile lorsque vous avez besoin de faire des choses comme installer Python sur un hôte où Python n'est pas déjà installé.
+Maintenant, le module **raw** utilise simplement SSH et contourne le sous-système du module Ansible. De cette façon, le module **raw** fonctionnera avec succès sur le nœud géré même si Python n'est pas installé (sur le noeud géré). Le module "raw" est utile lorsque vous avez besoin de faire des choses comme installer Python sur un hôte où Python n'est pas déjà installé.
 
 Exemple ad-hoc
 ```bash
@@ -419,11 +419,11 @@ ansible-playbook -i inventory.yaml playbook.yml
 
 \newpage
 ## Vérification du bon fonctionnement
-Dans cette illusation on peut voir que toutes machines ont le bon hostname. Cela veut dire que la première tâches du playbook à savoir renommer les machines a correctement été effectué.
+Dans cette illusation on peut voir que toutes machines ont le bon hostname. Cela veut dire que la première tâches du playbook à savoir renommer les hostname des machines a correctement été effectué.
 
 ![Ping entre H1 et H2 après application du playbook](./images/test_ping_h1_h2.png)
 
-On peut également constater que le ping entre la machine H1 et H2 passe correctement. Cela veut dire que les tâches 2 et 3 du playbook à savoir la configuration réseau de H1, H2 ainsi que R1, R2 a bien été effectuée.
+On peut également constater que le ping entre la machine H1 et H2 passe correctement. Cela veut dire que les tâches 2 et 3 du playbook à savoir la configuration réseau de H1, H2 ainsi que R1, R2 ont bien été effectuée.
 
 **Configuration réseau de H1** (/etc/network/interfaces.d/interfaces_playbook.conf 
 )
@@ -714,6 +714,22 @@ Pour réaliser les tâches demandées, nous avons découpé le playbook en sept
 ...
 ```
 
+Pour tester le playbook avant application de celui, voici la commande utilisée afin de checker la synthax:
+```bash
+ ansible-playbook --syntax-check -i ../inventory.ini Config_Wireguard.yml   
+```
+
+Puis la commande suivante pour tester la configuration sans l'appliquer de manière idem-potente:
+```bash
+ansible-playbook -i ../inventory.ini Config_Wireguard.yml --vault-password-file vault_file -CD
+```
+
+Et enfin, la commmande qui permet d'appliquer la configuration du playbook sur nos noeuds:
+```bash
+ansible-playbook -i ../inventory.ini Config_Wireguard.yml --vault-password-file vault_file
+```
+
+
 \newpage
 
 ![Test d'application du playbook](./images/test_playbook_wireguard.png)
@@ -765,7 +781,7 @@ echo "  H1PRIV: $(cat privkey_H1 )" >> keys.yml
 echo "  H1PUB: $(cat pubkey_H1 )" >> keys.yml
 ```
 
-Ce script permet de générer les clés ssh de H1 et H2 via **wg genkey** et en plus de les chiffrer avec le mot de passe contenu dans le fichier **vaul_file**. Enfin, les clés sont stockée dans le fichier keys.yml qui est chargé au début du playbook (première tâche) pour être repartie sur les hotes.
+Ce script permet de générer les clés ssh de H1 et H2 via **wg genkey** et de les chiffrer avec le mot de passe contenu dans le fichier **vaul_file**. Enfin, les clés sont stockée dans le fichier keys.yml qui est chargé au début du playbook (première tâche) pour être repartie sur les hotes.
 
 Contenu du fichier vault_file
 ```{.numberLines}
@@ -824,9 +840,9 @@ server {
        }
 }
 ```
-La configuration nginx suivante définit un serveur web qui écoute l'adresse 10.0.0.1, sur le port 80. En effet, une fois la configuration installée, nous ferons un "curl 10.0.0.1" depuis H1 pour accéder au site web sur H2.
+La configuration nginx suivante définit un serveur web qui écoute l'adresse 10.0.0.1, sur le port 80. En effet, une fois la configuration installée, nous ferons un "curl 10.0.0.1" depuis H1 pour accéder au site web hébergé par H2 en passant par wireguard.
 
-La partie "location" spécifie que toutes les requêtes HTTP reçues seront traitées à partir du répertoire racine **/var/www/html**, et que le fichier index.html sera servi comme point d'entrée.
+La partie "location" spécifie que toutes les requêtes HTTP reçues seront traitées à partir du répertoire racine **/var/www/html**, et que le fichier index.html sera servit comme point d'entrée.
 
 ## Vérification du bon fonctionnement
 
@@ -850,6 +866,8 @@ root@H2:~# ip -c a
        valid_lft forever preferred_lft forever
 ```
 
+Ici, on peut constater que les interface sont bien configurée et que l'interface de wireguard est elle aussi active et correctement configurée.
+
 **Vérification que le service nginx est en fonction**
 
 ```{.numberLines}
@@ -888,6 +906,17 @@ PublicKey = Vy/elocNbmBa6Z78u4KEOvxDVBjmXIOEuzSNDVQe5RQ=
 AllowedIPs = 10.0.0.0/24
 ```
 
+**Test de connectivité via un ping passant par wireguard**
+
+```{.numberLines}
+root@H2:~# ping 10.0.0.2
+PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
+64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=8.53 ms
+64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=3.76 ms
+64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=3.98 ms
+
+```
+
 ### Vérification de H1
 
 **Vérification des interfaces**
@@ -908,20 +937,6 @@ root@H1:~# ip -c a
        valid_lft forever preferred_lft forever
 ```
 
-**Test de connectivité via un ping**
-
-```{.numberLines}
-root@H1:~# ping 3.0.0.2
-PING 3.0.0.2 (3.0.0.2) 56(84) bytes of data.
-64 bytes from 3.0.0.2: icmp_seq=1 ttl=62 time=5.84 ms
-64 bytes from 3.0.0.2: icmp_seq=2 ttl=62 time=3.17 ms
-64 bytes from 3.0.0.2: icmp_seq=3 ttl=62 time=3.20 ms
-
---- 3.0.0.2 ping statistics ---
-3 packets transmitted, 3 received, 0% packet loss, time 2003ms
-rtt min/avg/max/mdev = 3.165/4.068/5.835/1.249 ms
-```
-
 **Vérification de la configuration de wireguard**
 
 ```{.numberLines}
@@ -937,6 +952,16 @@ Endpoint = 3.0.0.2:51820 <----- Endpoint de H2
 AllowedIPs = 10.0.0.0/24
 ```
 
+**Test de connectivité via un ping passant par wireguard**
+
+```{.numberLines}
+root@H1:~# ping 10.0.0.1
+PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
+64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=3.30 ms
+64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=3.67 ms
+64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=3.58 ms
+```
+
 **Récupération de la page web hébergée par H2**
 En exécutant la commande curl, on constate qu'on arrive à récupérer la page web hébergée sur H2 via 10.0.0.1. Cela confirme que l'on passe par le wireguard.
 
@@ -967,13 +992,10 @@ ansible-doc -l
 # Permet de checker si la synthax du playbook est valide
 ansible-playbook --syntax-check Config_H1_H2_Playbook.yml
 
-# Permet de checker si la synthax du playbook est valide
-ansible-playbook --syntax-check -i ../inventory.ini Config_H1_H2_Playbook.yml 
-
 # Permet de valider les tâches du playbook sans appliquer les modifications sur les hôtes
 ansible-playbook -i ../inventory.ini Config_H1_H2_Playbook.yml -CD  
 
-# Permet d'appliquer le playbooken passant le fichier vault
+# Permet d'appliquer le playbook en passant le fichier vault
 ansible-playbook -i ../inventory.ini Config_Wireguard.yml --vault-password-file vault_file
 ```
 
@@ -988,4 +1010,7 @@ ip -c a
 # Permet d'afficher les route intstalée
 ip route
 
+# Permet de générer le fichier keys.yml
+bash Generate_keys.sh
+
 ```
\ No newline at end of file