diff --git a/Virtualisation-et-clonage.md b/Virtualisation-et-clonage.md
index 005f173..6e27762 100644
--- a/Virtualisation-et-clonage.md
+++ b/Virtualisation-et-clonage.md
@@ -39,6 +39,22 @@ Set-OPS  + Ansible    ──> configuration réelle du serveur
 ```
 C'est *pour ça* que l'infra est reconstructible : cloner + reconfigurer = quelques minutes.
 
+**Et cloud-init s'efface ensuite.** Il ne s'arrête pas après la première seconde : il se
+réveille à *chaque* démarrage et relit le lecteur que l'hyperviseur a attaché à la VM — un
+lecteur qui peut redéfinir les comptes, les clés SSH autorisées, les mots de passe et le
+réseau. Sur une machine que le plan possède désormais, c'est un **second maître** : le plan
+ne le décrit pas, `make valider` ne le mesure pas, et il parle en premier.
+
+Le durcissement (`serveur_durci`) le **retire** donc, une fois qu'il a réussi — et c'est
+parce qu'il a réussi qu'Ansible a pu entrer. Le gabarit, lui, le garde : sans lui, un clone
+n'a ni adresse ni nom d'hôte.
+
+*Pourquoi ça ne coupe pas le réseau* : l'adresse posée à la naissance vit dans
+`/etc/network/interfaces.d/50-cloud-init`, un fichier qui **n'appartient à aucun paquet** —
+`dpkg -S` ne le trouve pas, et le `postrm` ne le nomme jamais, même en `purge` (mesuré le
+2026-09-09). Le rôle le vérifie quand même, avant et après : une VM qui perd ce fichier ne
+se plaint pas, elle repart sans adresse et plus personne ne peut entrer pour le voir.
+
 ---
 
 ## ③ Pourquoi c'est transférable