lancelot : modèle 9100 avec agent QEMU, machine-id régénéré, pool et destroy par l'API

- modèle par défaut 9100 debian13-bwpoc (dérivé de 9001 + qemu-guest-agent),
  fabrication en SSH root seulement si pve_template_create: true
- régénération du machine-id par l'agent QEMU (sinon même IP DHCP pour tous les clones)
- pool bwpoc créé par l'API, 99-destroy par l'API
- correctif ansible-core 2.21 (copie de hostvars), clé SSH id_ed25519 ou id_rsa

Déploiement validé sur lancelot : 50-tests 26 OK, 0 KO.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

README.md

@@ -55,7 +55,7 @@ Les mots de passe (MariaDB, Redis, admin de l'UI) sont générés au premier lan
 
 ## Compte Proxmox dédié
 
-Le clonage et le pilotage des VM passent par l'API avec l'utilisateur `bwpoc@pve` et un jeton, limité à un pool `bwpoc`. Seule la création du modèle (import d'une image disque par chemin, réservé à `root@pam`) se fait en SSH root, une fois.
+Le clonage et le pilotage des VM passent par l'API avec l'utilisateur `bwpoc@pve` et un jeton, limité à un pool `bwpoc`. Par défaut, le PoC clone un modèle cloud-init Debian 13 existant (`pve_template_vmid`, 9001 sur lancelot : VLAN 200, agent QEMU), donc aucun SSH root n'est nécessaire. Avec `pve_template_create: true`, le modèle 9100 est fabriqué en SSH root (import d'une image disque par chemin, réservé à `root@pam`), une fois.
 
 Privilèges nécessaires, regroupés dans un rôle `BWPoC` :
 
@@ -71,7 +71,7 @@ Et les ACL, au plus juste :
 
 | Chemin | Rôle | Pourquoi |
 |---|---|---|
-| `/pool/bwpoc` | `BWPoC` | les VM du PoC et le modèle 9100, placé dans le pool |
+| `/pool/bwpoc` | `BWPoC` | les VM du PoC (et le modèle 9100 s'il est fabriqué par le PoC) |
 | `/storage/zfs` | `PVEDatastoreUser` | allouer les disques des clones |
 | `/sdn/zones/localnetwork/vmbr0/200` | `PVESDNUser` | brancher les VM sur le VLAN 200 (et seulement lui) |
 | `/nodes/lancelot` | `PVEAuditor` | lecture du nœud par le module Ansible |
@@ -112,7 +112,7 @@ make deploy        # = ansible-playbook playbooks/site.yml
 
 | Étape | Playbook | Ce qu'elle fait |
 |---|---|---|
-| 1 | `00-proxmox.yml` | en root (une fois) : télécharge l'image Debian 13 genericcloud, y ajoute l'agent QEMU, crée le modèle cloud-init (VMID 9100) et le pool `bwpoc`. Puis par l'API avec `bwpoc@pve` : clone les VM dans le pool, cloud-init en DHCP + clé SSH, agrandit les disques, démarre, lit l'IP obtenue par l'agent QEMU et l'écrit dans `inventory/host_vars/<vm>/dhcp.yml` |
+| 1 | `00-proxmox.yml` | si `pve_template_create: true`, en root (une fois) : fabrique le modèle 9100 depuis l'image Debian 13 genericcloud. Puis par l'API : crée le pool `bwpoc`, clone le modèle (9001 par défaut), cloud-init en DHCP + clé SSH, agrandit les disques, démarre, régénère le machine-id par l'agent QEMU (sinon tous les clones obtiennent la même IP DHCP), lit l'IP obtenue par l'agent QEMU et l'écrit dans `inventory/host_vars/<vm>/dhcp.yml` |
 | 2 | `10-base.yml` | paquets de base, agent QEMU, résolution locale des noms du PoC vers le WAF, Docker CE depuis le dépôt officiel |
 | 3 | `20-apps.yml` | stack des applis, filtrage `DOCKER-USER` (mode split) |
 | 4 | `30-bunkerweb.yml` | stack BunkerWeb, attente qu'`api` réponde au travers du WAF, écriture de `credentials/ACCES.txt` |
@@ -233,8 +233,8 @@ La SQLi de Juice Shop renvoie alors la liste complète des produits (200) au lie
 
 ```bash
 make waf           # réapplique la conf BunkerWeb après modification de bunkerweb.yml
-make destroy       # supprime les VM en root sur le nœud (confirmation demandée), modèle conservé
-ansible-playbook playbooks/99-destroy.yml -e destroy_template=true   # supprime aussi le modèle
+make destroy       # supprime les VM par l'API (confirmation demandée), modèle conservé
+ansible-playbook playbooks/99-destroy.yml -e destroy_template=true   # supprime aussi le modèle, s'il a été fabriqué par le PoC
 ```
 
 Sur `bw-waf`, la stack vit dans `/opt/bwpoc/bunkerweb` (`docker compose ps`, `logs`, `pull`...). Sur `bw-apps`, dans `/opt/bwpoc/apps`.