gabarit : ancien supprime, le nouveau porte son nom

Le cluster ne porte plus qu'un gabarit : modeleChezlepro, VMID 99998.

Trois verifications avant de supprimer : le nouveau avait deja produit une VM
deployee et prouvee (web-dorsal-01, cinq devis CONFORME) ; aucune VM ne
dependait du disque de 99999 (recherche de base-99999 dans tous les disques du
cluster — un clone lie aurait rendu la suppression destructrice pour la flotte
entiere) ; et le nom de 99999 confirme avant le DELETE, meme verrou que raser.

L'ordre n'etait pas indifferent : supprimer d'abord, renommer ensuite. Deux
modeleChezlepro sur le cluster auraient rendu le clonage PAR NOM ambigu —
exactement la collision qui avait fait rapporter ok a proxmox_kvm sans rien
faire le 2026-08-07.

Ce que le nouveau n'a plus : resolv.conf du reseau de fabrication, searchdomain
public, et une cle PRIVEE d'hote SSH.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,30 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-09 — L'ancien gabarit supprimé, le nouveau porte son nom
+
+Le cluster ne porte plus qu'un gabarit : **`modeleChezlepro`, VMID 99998**. Le plan le
+désigne par nom *et* par VMID, et les deux concordent.
+
+**Trois vérifications avant de supprimer**, parce qu'un gabarit doré ne se remplace pas
+sur une impression :
+
+- le nouveau avait déjà **produit une VM déployée et prouvée** — `web-dorsal-01`, rasée,
+  recréée, déployée sans échec, cinq devis `CONFORME` ;
+- `proxmox_clone_complet: true`, et **aucune VM ne dépendait du disque de 99999** (vérifié
+  en cherchant `base-99999` dans les disques de toutes les VM du cluster) : un clone lié
+  aurait rendu la suppression destructrice pour la flotte entière ;
+- le nom de 99999 confirmé avant le `DELETE` — le même verrou que `raser`, pour la même
+  raison.
+
+**L'ordre n'était pas indifférent : supprimer d'abord, renommer ensuite.** L'inverse aurait
+laissé deux `modeleChezlepro` sur le cluster, et le clonage *par nom* serait devenu
+ambigu — exactement la collision qui avait fait rapporter `ok` à `proxmox_kvm` sans rien
+faire, le 2026-08-07.
+
+Ce que le nouveau n'a plus, et que l'ancien portait depuis sa fabrication : un
+`/etc/resolv.conf` pointant `192.168.12.254`, un `searchdomain` public, et une **clé privée
+d'hôte SSH**.
+
 ## 2026-08-09 — `client_unbound` : survivre à la perte de connexion, sans la masquer
 
 Le déploiement de `web-dorsal-01` s'était interrompu autour du redémarrage d'Unbound —