un site prend son propre index, et la garde les compte enfin

Decision de l exploitant : sites et locataires se partagent la classe A,
chacun avec son propre index. L exception du guide — un site derive du meme
index que son tenant — disparait.

Ce qu elle cachait : le plan d administration du site vit dans 10.17.0.0/24,
a l interieur du supernet du locataire OPS-Chezlepro. Pas dangereux, mais
10.17.0.0/16 designait deux choses. Et les zones du site ne derivaient de
rien — le site etait la seule partie du systeme sans seed.

La seconde liste nait avec cette decision : un site et un locataire peuvent
desormais reclamer le meme nombre, et make instances ne voyait que les depots
OPS-*. La decouverte lit maintenant SITE-*/underlay.yml et son champ index.
Un site sans index declare reste hors du compte.

SITE-Technolibre : squelette du deuxieme site pour la visite du 14. Un seul
noeud Proxmox en version 9, meme forme que Chezlepro, adresse depuis l index
31. COLLECTE.md liste les 35 valeurs a relever.

Reste a l exploitant : OPS-Chezlepro passe a 37, ce qui libere 17 pour le
site qui l utilise deja.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

COLLECTE.md

@@ -59,7 +59,7 @@ Ce qu'il y a entre le nœud Proxmox et l'OPNsense décide du mode de routage :
 ## 5. Cohabitation d'adressage
 
 - [ ] `ip route` sur le poste de Mathieu — quelles plages `10.x` sont déjà prises ?
-- [ ] Son réseau bureautique / son VPN utilisent-ils `10.0.3x` ou `10.23.x` ? ______
+- [ ] Son réseau bureautique / son VPN utilisent-ils `10.31.x` ou `10.23.x` ? ______
 - [ ] Docker présent sur ses machines d'administration ? (`172.17`+ déjà pris)
 
 ## 6. Le gabarit
@@ -93,6 +93,5 @@ Par un canal chiffré, **séparément du reste**, et jamais dans git :
       (`proxmox-firewall` nftables en 9) et le SDN (passé GA).
 - [ ] **Nœud unique** — pas de Ceph, pas de migration, le gabarit et les clones sont sur
       la même machine. Le SPOF est total et assumé.
-- [ ] **Deuxième site** — `10.0.31–36` est déjà l'adressage du site de Chezlepro. Les
+- [ ] **Index 31** — celui du SITE. Vérifier qu'aucune plage `10.31.x` n'existe déjà chez
-      réutiliser ici ferme la possibilité de relier les deux sites (§8 du guide) tant
+      Mathieu (`ip route | grep 10.31`). `make instances` garde la fédération.
-      qu'aucun n'est renuméroté.

README.md

@@ -41,13 +41,12 @@ dessous de 64 Go, il faut décider de réduire avant de câbler, pas pendant le
 
 ## L'adressage
 
-- **Gestion** : `10.23.0.0/24` — la bande basse du supernet de son locataire, que la
+- **Gestion** : `10.31.0.0/24` — l'index du SITE, distinct de celui de son locataire
-  dérivation des zones n'alloue jamais (elles commencent à `.16`).
+  (23). Le plan d'administration de l'hébergeur ne vit plus chez un de ses clients.
-- **Zones du site** : `10.0.31` à `10.0.36` — **identiques à celles de Chezlepro**.
+- **Zones du site** : `10.31.31` à `10.31.36` — **même forme que Chezlepro** (le 3e octet
-  Statu quo décidé le 2026-09-12 : un index se redéploie assez facilement pour qu'une
+  reste le numéro de VLAN), avec l'index du site au 2e octet.
-  collision ne justifie pas de revoir la méthode.
+  > Décision du 2026-09-12 : sites et locataires se partagent la classe A, chacun avec son
-  > Conséquence connue : les deux sites ne peuvent pas être reliés (§8 du guide de
+  > propre index. Les deux sites peuvent donc être reliés (§8 du guide) sans renumérotage.
-  > préparation) tant qu'aucun des deux n'est renuméroté.
 - **Chemins** (transit) : `10.0.4.0/24`, comme chez Chezlepro.
 
 ## L'ordre des gestes, le jour J

plan/serveurs.yml

@@ -22,7 +22,7 @@ serveurs:
   site-ops-01:
     etat: actif
     reseau: site-pilotage
-    ip: 10.0.31.11
+    ip: 10.31.31.11
     noeud: <<NOEUD>>
     gabarit: { vcpu: 2, memoire: 4096, disque: 40G }
     vmid: 9001
@@ -67,7 +67,7 @@ serveurs:
   site-cache-01:
     etat: actif
     reseau: site-genome
-    ip: 10.0.33.21
+    ip: 10.31.33.21
     noeud: <<NOEUD>>
     gabarit: { vcpu: 2, memoire: 2048, disque: 120G }
     vmid: 9002
@@ -77,7 +77,7 @@ serveurs:
   site-forge-01:
     etat: actif
     reseau: site-genome
-    ip: 10.0.33.11
+    ip: 10.31.33.11
     noeud: <<NOEUD>>
     gabarit: { vcpu: 2, memoire: 4096, disque: 80G }
     vmid: 9003
@@ -113,7 +113,7 @@ serveurs:
   site-pki-01:
     etat: actif
     reseau: site-autorite
-    ip: 10.0.32.11
+    ip: 10.31.32.11
     noeud: <<NOEUD>>
     gabarit: { vcpu: 2, memoire: 2048, disque: 32G }
     vmid: 9004
@@ -133,7 +133,7 @@ serveurs:
   site-dns-01:
     etat: actif
     reseau: site-service
-    ip: 10.0.34.11
+    ip: 10.31.34.11
     noeud: <<NOEUD>>
     gabarit: { vcpu: 2, memoire: 2048, disque: 40G }
     vmid: 9005
@@ -175,7 +175,7 @@ serveurs:
   site-backup-01:
     etat: actif
     reseau: site-sauvegarde
-    ip: 10.0.35.11
+    ip: 10.31.35.11
     noeud: <<NOEUD>>
     gabarit: { vcpu: 2, memoire: 2048, disque: 400G }
     vmid: 9010
@@ -192,7 +192,7 @@ serveurs:
   site-mon-01:
     etat: actif
     reseau: site-supervision
-    ip: 10.0.36.11
+    ip: 10.31.36.11
     noeud: <<NOEUD>>
     gabarit: { vcpu: 2, memoire: 4096, disque: 64G }
     vmid: 9011

underlay.yml

@@ -12,6 +12,13 @@
 underlay:
   # Le locataire que ce site hébergera. Son index est déjà fédéré (23) et il ne
   # change pas : c'est lui qui porte l'adressage d'OPS-Technolibre, ses VLAN et ses VMID.
+  # L'INDEX DU SITE LUI-MÊME. Déclaré ici, et pas seulement porté par les adresses :
+  # c'est ce qui le rend visible à la garde des collisions (`make instances`).
+  # Depuis le 2026-09-12, SITES et OPS partagent la classe A — deux écosystèmes ne
+  # peuvent donc plus prendre le même nombre, quel que soit leur genre.
+  index: 31
+
+  # Le locataire que ce site hébergera, avec SON index à lui.
   tenants:
     OPS-Technolibre: 23
 
@@ -32,12 +39,14 @@ underlay:
 
   reseaux:
     # PLAN DE GESTION — la seule chose qui doit être unique entre deux sites.
-    # `10.<index>.0.0/24`, index 23 : la bande basse du supernet du locataire, que la
+    # `10.<index>.0.0/24`, index 31 : celui du SITE, distinct de celui de son
-    # dérivation des zones n'alloue jamais (elles commencent à .16).
+    # locataire (23). Décision du 2026-09-12 : SITES et OPS partagent la classe A,
+    # chacun avec son propre index — le plan d'administration de l'hébergeur ne vit
+    # plus dans le supernet d'un de ses locataires.
     - nom: management
       description: Gestion du nœud, OOB/IPMI, poste de l'exploitant
       vlan: null
-      sous_reseau: 10.23.0.0/24
+      sous_reseau: 10.31.0.0/24
       mtu: 1500
 
     # LIEN VERS LA FRONTIÈRE. Sans lui, la flotte n'a ni sortie ni chemin de retour :
@@ -50,15 +59,15 @@ underlay:
       mtu: 1500
 
     # LES SIX ZONES DU SITE. Une préoccupation par zone.
-    # ⚠ Identiques à celles du site de Chezlepro (statu quo décidé le 2026-09-12).
+    # Même FORME que le site de Chezlepro — le 3e octet reste le numéro de VLAN.
-    # Conséquence connue : les deux sites ne pourront pas être reliés (§8 du guide)
+    # Ce qui change : le 2e octet porte l'index du site (31) au lieu de 0.
-    # tant qu'aucun des deux n'est renuméroté.
+    # Les deux sites peuvent donc être reliés (§8 du guide) sans renumérotage.
-    - { nom: site-pilotage,    description: Runner et pilotage,          vlan: 31, sous_reseau: 10.0.31.0/24, pont: <<PONT>>, mtu: 1500 }
+    - { nom: site-pilotage,    description: Runner et pilotage,          vlan: 31, sous_reseau: 10.31.31.0/24, pont: <<PONT>>, mtu: 1500 }
-    - { nom: site-autorite,    description: Autorité de certification,   vlan: 32, sous_reseau: 10.0.32.0/24, pont: <<PONT>>, mtu: 1500 }
+    - { nom: site-autorite,    description: Autorité de certification,   vlan: 32, sous_reseau: 10.31.32.0/24, pont: <<PONT>>, mtu: 1500 }
-    - { nom: site-genome,      description: Forge et cache de paquets,   vlan: 33, sous_reseau: 10.0.33.0/24, pont: <<PONT>>, mtu: 1500 }
+    - { nom: site-genome,      description: Forge et cache de paquets,   vlan: 33, sous_reseau: 10.31.33.0/24, pont: <<PONT>>, mtu: 1500 }
-    - { nom: site-service,     description: Noms (DNS autoritaire),      vlan: 34, sous_reseau: 10.0.34.0/24, pont: <<PONT>>, mtu: 1500 }
+    - { nom: site-service,     description: Noms (DNS autoritaire),      vlan: 34, sous_reseau: 10.31.34.0/24, pont: <<PONT>>, mtu: 1500 }
-    - { nom: site-sauvegarde,  description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.0.35.0/24, pont: <<PONT>>, mtu: 1500 }
+    - { nom: site-sauvegarde,  description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.31.35.0/24, pont: <<PONT>>, mtu: 1500 }
-    - { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.0.36.0/24, pont: <<PONT>>, mtu: 1500 }
+    - { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.31.36.0/24, pont: <<PONT>>, mtu: 1500 }
 
   hotes:
     # L'UNIQUE NŒUD. `via` = l'interface physique qui porte le trunk vers la frontière.
@@ -67,14 +76,14 @@ underlay:
 
     # LA FRONTIÈRE, patte par patte. Une ligne par zone qu'elle sert : c'est de là que
     # le devis dérive les interfaces d'arrivée des règles (D-61 raisonne en ARRIVÉE).
-    - { nom: <<FRONTIERE>>, reseau: management,        ip: 10.23.0.1, role: frontiere }
+    - { nom: <<FRONTIERE>>, reseau: management,        ip: 10.31.0.1, role: frontiere }
     - { nom: <<FRONTIERE>>, reseau: transit-frontiere, ip: 10.0.4.1,  role: frontiere }
-    - { nom: <<FRONTIERE>>, reseau: site-pilotage,     ip: 10.0.31.1, role: frontiere }
+    - { nom: <<FRONTIERE>>, reseau: site-pilotage,     ip: 10.31.31.1, role: frontiere }
-    - { nom: <<FRONTIERE>>, reseau: site-autorite,     ip: 10.0.32.1, role: frontiere }
+    - { nom: <<FRONTIERE>>, reseau: site-autorite,     ip: 10.31.32.1, role: frontiere }
-    - { nom: <<FRONTIERE>>, reseau: site-genome,       ip: 10.0.33.1, role: frontiere }
+    - { nom: <<FRONTIERE>>, reseau: site-genome,       ip: 10.31.33.1, role: frontiere }
-    - { nom: <<FRONTIERE>>, reseau: site-service,      ip: 10.0.34.1, role: frontiere }
+    - { nom: <<FRONTIERE>>, reseau: site-service,      ip: 10.31.34.1, role: frontiere }
-    - { nom: <<FRONTIERE>>, reseau: site-sauvegarde,   ip: 10.0.35.1, role: frontiere }
+    - { nom: <<FRONTIERE>>, reseau: site-sauvegarde,   ip: 10.31.35.1, role: frontiere }
-    - { nom: <<FRONTIERE>>, reseau: site-supervision,  ip: 10.0.36.1, role: frontiere }
+    - { nom: <<FRONTIERE>>, reseau: site-supervision,  ip: 10.31.36.1, role: frontiere }
 
   # LE GABARIT ET SON STOCKAGE. Sur un nœud unique, `clone_complet` est le choix sûr :
   # un clone lié dépend à vie du gabarit, et il n'y a pas d'autre nœud pour le porter.