GUI : le « pont reseau » n'est pas un reglage de la flotte — l'intitule le dit

Question de l'exploitant apres la decouverte de vmbr3 : a quoi sert cet intrant ?
Mesure : a presque rien.

  proxmox_pont      14 occurrences dans l'inventaire -> DERIVE par hote (VNet de zone)
  proxmox_noeud      0  -> proxmox_clone_noeud est la vraie valeur
  proxmox_stockage   0  -> proxmox_clone_stockage est la vraie valeur

instancier pose le VNet de chaque zone dans proxmox_pont, et l'hote l'emporte sur
le defaut. proxmox_clone_pont n'est donc consulte que par un `make cloner-vm`
manuel, hors flotte. C'est exactement pourquoi vmbr3 a pu y etre faux dix jours.

C'est le pire genre d'intrant : visible dans le GUI, on le corrige, on redeploie,
rien ne change. L'intitule dit desormais sa portee.

D-80 CORRIGEE : j'y avais ecrit « trois cles : noeud, stockage, pont ». Faux pour
le pont. La liaison de placement reelle est noeud, stockage et gabarit ; le pont
se derive comme le reste.

Verifier avant d'enumerer : j'avais liste les cles en lisant le fichier du tenant,
sans regarder lesquelles sont reellement consultees. Deux le sont, une ne l'est
pas — et c'est celle qui etait fausse.

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

CHANGELOG.md

@@ -1,5 +1,38 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-13 — Le « pont réseau » n'était pas un réglage, et l'intitulé le dit maintenant
+
+Question de l'exploitant après la découverte de `vmbr3` : *à quoi sert l'intrant « pont
+réseau » ?* Mesuré, et la réponse est : **à presque rien**.
+
+```
+proxmox_pont       14 occurrences dans l'inventaire  → DÉRIVÉ par hôte (le VNet de sa zone)
+proxmox_noeud       0                                → proxmox_clone_noeud est la vraie valeur
+proxmox_stockage    0                                → proxmox_clone_stockage est la vraie valeur
+```
+
+`instancier` pose le VNet de chaque zone dans `proxmox_pont`, et l'hôte l'emporte sur le
+défaut. **`proxmox_clone_pont` n'est donc consulté que par un `make cloner-vm` manuel**,
+hors flotte — utile pour dépanner, sans effet sur les quatorze VM du plan.
+
+C'est exactement pourquoi `vmbr3` a pu y être faux **dix jours** sans que rien ne bronche.
+Et c'est le pire genre d'intrant : on le voit dans le GUI, on le corrige, on redéploie, et
+rien ne change.
+
+L'intitulé dit désormais sa portée — *« Pont réseau — clones manuels seulement (les VM du
+plan reçoivent le VNet de leur zone) »*. Un intrant dont on comprend la portée cesse
+d'être un piège.
+
+### D-80 corrigée
+
+J'y avais écrit « trois clés : nœud, stockage, pont ». **Faux pour le pont.** La liaison de
+placement réelle est **nœud, stockage et gabarit** ; le pont se dérive comme le reste.
+
+> **Vérifier avant d'énumérer.** J'avais listé les clés de placement en lisant le fichier
+> du tenant, sans regarder lesquelles sont réellement consultées. Deux le sont, une ne
+> l'est pas — et c'est celle qui était fausse.
+
+
 ## 2026-08-13 — `make placement-plan` : et le gabarit, justement
 
 J'avais écarté le gabarit de P37 — « objet du cluster, pas une liste déclarée, donc pas

docs/decisions-architecture.md

@@ -119,7 +119,7 @@ sont les seules vérifiables.
 
 | **D-77** | **L'underlay d'un site dérive du même `index` que son tenant**, dans la **bande basse** `10.<index>.0–15.x` ; les réseaux de **stockage** en sortent et sont **identiques partout**, en `192.168.<vlan>.0/24` | tant qu'il n'existait qu'un site, `10.0.x.x` suffisait. Deux sites qui doivent se joindre — reprise mutuelle, sauvegardes croisées, exploitation à distance — **ne peuvent pas** porter les mêmes plages : chaque routeur croit que le réseau est chez lui. Un « numéro de site » a d'abord été proposé : **rejeté**, c'était un SECOND SEED à tenir et à synchroniser, alors que tout dérive déjà d'`index` (D-17). La bande basse est sûre **par la règle, pas par chance** : les zones valent `10.<index>.(15+categorie).0/24`, donc troisième octet ≥ 16 — les octets 0 à 15 ne sont jamais alloués. Les troisièmes et derniers octets de l'underlay actuel sont ainsi **préservés** : seul le deuxième change, et l'invariant `.1` (D-04) survit intact. Le **stockage** en est sorti parce qu'il est jumbo, non routé, et ne quitte jamais son site : il n'a aucun besoin d'être unique, et l'aligner sur le VLAN (`192.168.20.x` ↔ VLAN 20) fait dire son VLAN à l'adresse. Contrepartie assumée : ces réseaux ne pourront jamais traverser un lien inter-sites — sans conséquence, puisque ce qui voyage entre deux sites est l'**état**, par le dépôt de sauvegarde, pas le stockage bloc | `underlay.yml` (`index`), `scripts/underlay.py`, `docs/preparer-un-site-hebergeur.md` | **P23** |
 
-| **D-80** | **Un tenant est agnostique de son underlay.** Les deux symlinks composent deux axes INDEPENDANTS : `instance` designe le tenant, `underlay.yml` la fabric qui l'accueille. Seule exception : une **liaison de placement** de trois cles | le commentaire disait « la fabric reste celle de l'hebergeur, quel que soit le tenant actif » — vrai, mais centre sur l'hebergeur. Le cadrage juste est centre sur le TENANT : tout son adressage derive du seed `index`, donc son plan se deplace d'une fabric a l'autre **sans y toucher**. Ce qui ne se deplace pas, c'est le **placement** — `proxmox_clone_noeud`, `_stockage`, `_pont` — qui vit cote tenant parce que c'est lui qui choisit ou se poser, mais qui NOMME des objets de l'hebergeur. Trois cles, pas trente : c'est ce qui separe « portable » de « theoriquement portable ». Le gabarit (`_vmid_modele`) s'y ajoute, mais il n'est pas verifiable statiquement — c'est un objet du cluster, pas une liste declaree | `underlay.py`, `inventories/*/group_vars/proxmox.yml`, `proxmox-hebergeur.yml` | **P37** |
+| **D-80** | **Un tenant est agnostique de son underlay.** Les deux symlinks composent deux axes INDEPENDANTS : `instance` designe le tenant, `underlay.yml` la fabric qui l'accueille. Seule exception : une **liaison de placement** de trois cles vivantes | le commentaire disait « la fabric reste celle de l'hebergeur, quel que soit le tenant actif » — vrai, mais centre sur l'hebergeur. Le cadrage juste est centre sur le TENANT : tout son adressage derive du seed `index`, donc son plan se deplace d'une fabric a l'autre **sans y toucher**. Ce qui ne se deplace pas, c'est le **placement** : `proxmox_clone_noeud`, `_stockage` et le gabarit `_vmid_modele` — trois valeurs cote tenant, parce que c'est lui qui choisit ou se poser, mais qui NOMMENT des objets de l'hebergeur. Trois, pas trente : c'est ce qui separe « portable » de « theoriquement portable ». **Le PONT n'en fait pas partie** (mesure le 2026-08-13) : `instancier` pose `proxmox_pont` par hote, derive du VNet de sa zone. `proxmox_clone_pont` n'est qu'un REPLI pour un clone manuel hors flotte — d'ou son intitule dans le GUI, et d'ou le fait que `vmbr3` ait pu y rester faux dix jours | `underlay.py`, `inventories/*/group_vars/proxmox.yml`, `proxmox-hebergeur.yml` | **P37** |
 | **D-79** | Le filtrage que l'hyperviseur applique aux VM tourne encore sur **iptables *legacy***. Le passer à `proxmox-firewall` (nftables natif) est une **dette à rembourser**, pas une option — et c'est le même geste qui rend le **pare-feu de VNet** opérant. Décidée le 2026-08-12, **différée après la reconstruction** | mesuré sur `asgard` : `iptables v1.8.9 (legacy)` — pas `(nf_tables)` ; `nftables v1.0.6` installé mais inutilisé par Proxmox ; `proxmox-firewall 0.7.1` **installé et absent des services en cours** ; seul `pve-firewall 5.1.3` tourne. Le pare-feu de VNet est **entièrement expressif** (`type/action/proto/source/dest/dport`, et `policy_forward` ∈ `ACCEPT,DROP` — donc un vrai default-deny inter-zone) : une règle d'essai a été créée, relue, puis retirée. **Mais il n'est implémenté QUE par le moteur nftables** : posée aujourd'hui, une règle serait acceptée, stockée, visible dans l'interface, et n'appliquerait rien. Trois gains dans le même geste — le moteur rejoint la doctrine (« tout est nftables »), le pare-feu de VNet devient réel, et ses règles **survivent à la reconstruction** là où les groupes par VM doivent être ré-attachés à chaque cycle | `devis_proxmox_fw.py`, `docs/sdn-evpn.md` | P25 *(sur le mécanisme actuel)* |
 
 > **Ce qui n'a PAS été établi, et qu'il faudra éprouver.** `nft list tables` exige root et le

scripts/inventory_gui.py

@@ -170,7 +170,14 @@ INTRANTS_SCHEMA = [
     ("proxmox_clone_vmid_modele", "proxmox", "constante", "Proxmox", "VMID du golden template", "int", "tenant"),
     ("proxmox_clone_noeud", "proxmox", "defaut", "Proxmox", "Nœud Proxmox (défaut)", "str", "tenant"),
     ("proxmox_clone_stockage", "proxmox", "defaut", "Proxmox", "Stockage (défaut)", "str", "tenant"),
-    ("proxmox_clone_pont", "proxmox", "defaut", "Proxmox", "Pont réseau (défaut)", "str", "tenant"),
+    # REPLI, pas un reglage de la flotte. Chaque VM du plan recoit le VNet DERIVE de sa
+    # zone (`instancier` pose `proxmox_pont` par hote) ; cette valeur n'est consultee que
+    # si l'hote n'en porte pas — c'est-a-dire jamais dans le flux normal. L'intitule le
+    # dit, sans quoi on la corrige, on redeploie, et rien ne change : `vmbr3` y est reste
+    # faux dix jours sans que rien ne bronche (2026-08-13).
+    ("proxmox_clone_pont", "proxmox", "defaut", "Proxmox",
+     "Pont réseau — clones manuels seulement (les VM du plan reçoivent le VNet de leur zone)",
+     "str", "tenant"),
     ("proxmox_noeuds", "proxmox_hebergeur", "catalogue", "Cluster", "Nœuds disponibles (liste)", "liste", "hebergeur"),
     ("proxmox_stockages", "proxmox_hebergeur", "catalogue", "Cluster", "Stockages disponibles (liste)", "liste", "hebergeur"),
     ("proxmox_ponts", "proxmox_hebergeur", "catalogue", "Cluster", "Ponts réseau disponibles (liste)", "liste", "hebergeur"),