diff --git a/Virtualisation-et-clonage.md b/Virtualisation-et-clonage.md
index 6e27762..853088a 100644
--- a/Virtualisation-et-clonage.md
+++ b/Virtualisation-et-clonage.md
@@ -49,6 +49,15 @@ Le durcissement (`serveur_durci`) le **retire** donc, une fois qu'il a réussi 
 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.
 
+*Ce que ça ne fait pas* : ça **ne reprend pas la main à l'hébergeur**. `qemu-guest-agent`
+reste sur chaque VM — il doit y être, c'est par lui que la création confirme qu'une machine
+existe — et l'API de l'hyperviseur expose sur son dos `exec`, `file-write`,
+`set-user-password`, `shutdown` : strictement plus que le lecteur cloud-init. Ce qui est
+fermé est plus étroit, et bien réel : une réapplication *automatique, à chaque démarrage*,
+depuis un support que le plan ne possède pas, et un interpréteur Python complet lancé en
+root au démarrage. Qu'un hyperviseur puisse tout faire chez ses invités est une propriété
+de la virtualisation, pas de cloud-init.
+
 *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