D-77 : l'underlay derive du meme index que son tenant, le stockage sort en 192.168

Mon « numero de site » etait un SECOND SEED a tenir et a synchroniser, alors que
tout derive deja d'index (D-17). Rejete au profit de la proposition de l'exploitant,
meilleure : l'underlay occupe la BANDE BASSE du supernet du tenant,
10.(10+index).0-15.x.

La bande basse est sure PAR LA REGLE, pas par chance : les zones valent
10.(10+index).(15+categorie).0/24, donc 3e octet >= 16. Les octets 0 a 15 ne sont
JAMAIS alloues. Consequence heureuse : les 3e et derniers octets de l'underlay
actuel sont preserves — seul le 2e change, et l'invariant .1 (D-04) survit.

Verifie sur les quatre cas qui comptent : Technolibre sur l'underlay de Chezlepro,
Technolibre chez Mathieu (meme /16, bandes disjointes), Chezlepro restaure chez
Mathieu, et le lien entre les deux sites. Aucun recouvrement.

Le STOCKAGE en sort : jumbo, non route, il ne quitte jamais son site, donc aucun
besoin d'etre unique. Identique partout en 192.168.<vlan>.0/24 — l'adresse dit son
VLAN. Contrepartie assumee : ces reseaux ne traverseront jamais un lien
inter-sites ; sans consequence, puisque ce qui voyage entre deux sites est l'ETAT,
par le depot de sauvegarde, pas le stockage bloc.

Calendrier : applique tout de suite la ou c'est gratuit (site neuf), differe a
froid pour Chezlepro — 10.0.x.x et 10.21.x.x ne se chevauchent pas entre-temps.

Reste a outiller : borner le 3e octet de l'underlay sous OCTET_ZONE + 1 (P23).

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

docs/decisions-architecture.md

@@ -117,6 +117,15 @@ sont les seules vérifiables.
 | **D-71** | **Une PKI et un DNS fonctionnels avant toute chose** ; puis, par VM : socle → enrôlement PKI → enregistrement DNS (A **et** PTR) | `deployer-tout` déroule par COUCHES — correct, mais chaque VM réclame alors un certificat à une autorité pas encore debout, et l'échec se lit comme un défaut du rôle et non d'ordre. Les deux hôtes d'amorçage se **dérivent** de `applications.<step_ca\|powerdns>.hote` : déplacer l'autorité déplace l'amorçage. **Deux exceptions structurelles assumées** — l'AC s'auto-signe, le DNS pose son propre enregistrement | `Makefile` `_amorcer-socle`, `scripts/socle_amorcage.py` | — |
 | **D-76** | Le **gabarit doit se FABRIQUER par le dépôt**, pas se façonner à la main — décidée le 2026-08-12, **volontairement différée** après Technolibre | tout dérive d'un plan et se prouve ; le gabarit est la **seule pièce faite à la main** — 853 lignes de procédure manuelle — et il est en amont des quatorze VM. Le 2026-08-09 l'a démontré : l'ancien portait une **clé privée d'hôte SSH** et un `/etc/resolv.conf` figé, recopiés dans chaque clone, et il a fallu le recapturer. La preuve de reconstruction s'arrête donc un cran trop tôt : on reconstruit la flotte, pas ce dont elle est clonée. **Cible** : image cloud Debian officielle → signature vérifiée contre une empreinte épinglée (`verifier_signature.py`, déjà écrit) → import, réglages, conversion. **Coût honnête** : la recette doit être COMPARÉE au gabarit courant avant bascule — un réglage oublié serait hérité par les quatorze VM, et découvert loin de sa cause. **En attendant**, un gabarit se transporte d'un cluster à l'autre par `vzdump` / `qmrestore` | `docs/procedure-template-debian13-proxmox.md`, `scripts/verifier_signature.py` | — *(à construire)* |
 
+| **D-77** | **L'underlay d'un site dérive du même `index` que son tenant**, dans la **bande basse** `10.(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.(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`, `docs/preparer-un-site-hebergeur.md`, `scripts/inventory_rules.py` (`OCTET_ZONE`) | **P23** *(à étendre : borner le 3ᵉ octet sous `OCTET_ZONE + 1`)* |
+
+> **Ce que D-77 rend possible, et ce qu'elle coûte.** Elle est la condition de la reprise
+> mutuelle : sans plages distinctes, aucun lien entre deux sites ne peut router. Elle est
+> **gratuite pour un site neuf** et **coûteuse pour un site vivant** — renuméroter, c'est
+> toucher la frontière, les commutateurs, l'IPMI, `vmbr0`. D'où le calendrier retenu :
+> **appliquée immédiatement là où elle est gratuite**, différée à froid ailleurs. Rien ne
+> presse, puisque `10.0.x.x` et `10.21.x.x` ne se chevauchent pas entre-temps.
+
 > **Ce que D-76 retourne.** Le gabarit était tenu pour un « actif central, jamais jetable ».
 > C'est exactement le problème : **un artefact qu'on ne sait pas refaire est un artefact
 > qu'on ne peut pas se permettre de perdre.** Le rendre reproductible le fait passer

docs/preparer-un-site-hebergeur.md

@@ -25,35 +25,40 @@ listes de stockages et de ponts différentes. Un hébergeur décrit son matérie
 
 ## 2. Le plan d'adressage — la seule chose à respecter à la lettre
 
-**Chaque site porte un numéro**, et tout son adressage en dérive : `10.<site>.x.0/24`.
-Le premier hébergeur est le site `0`, le deuxième le site `1`, et ainsi de suite.
+**Un site dérive du même `index` que son tenant.** Il n'y a pas de second registre à
+tenir : le seul seed de tout l'adressage reste l'`index`, et l'underlay occupe la **bande
+basse** du supernet — celle que la dérivation des tenants n'alloue jamais.
 
 | Rôle | VLAN | Sous-réseau | MTU | Qui y vit |
 |---|---|---|---|---|
-| Gestion | 10 | `10.<site>.0.0/24` | 1500 | frontière `.1`, commutateurs, OOB/IPMI, admin hyperviseur |
-| Transport VXLAN | 11 | `10.<site>.5.0/24` | 1500 | hyperviseurs seulement |
-| Stockage iSCSI | 20 | `10.<site>.1.0/24` | 9000 | baie ↔ hyperviseurs |
-| Sortie des tenants | 40 | `10.<site>.4.0/24` | 1500 | frontière `.1`, nœuds de sortie |
+| Gestion | 10 | `10.(10+index).0.0/24` | 1500 | frontière `.1`, commutateurs, OOB/IPMI, admin hyperviseur |
+| Sortie des tenants | 40 | `10.(10+index).4.0/24` | 1500 | frontière `.1`, nœuds de sortie |
+| Transport VXLAN | 11 | `10.(10+index).5.0/24` | 1500 | hyperviseurs seulement |
+| Stockage iSCSI | 20 | `192.168.20.0/24` | 9000 | baie ↔ hyperviseurs |
+| Ceph public | 30 | `192.168.30.0/24` | 9000 | clients ↔ MON/OSD |
+| Ceph cluster | 31 | `192.168.31.0/24` | 9000 | OSD ↔ OSD |
 
-Les **VLAN ne changent pas** d'un site à l'autre : ils sont locaux, ils ne traversent
-jamais un lien inter-sites. Un seul modèle mental vaut mieux qu'une seconde table à
-retenir. Seules les plages L3 diffèrent.
+Index 17 → gestion en `10.27.0.0/24` ; index 11 → `10.21.0.0/24`. Deux sites ne peuvent
+donc **pas** se chevaucher, sans qu'on ait rien de plus à décider.
 
-> **Pourquoi ce numéro de site, alors qu'un seul hébergeur n'en a pas besoin.** Le jour
-> où deux sites doivent se joindre — reprise après sinistre mutuelle, sauvegardes
-> croisées, exploitation à distance — deux sites qui portent `10.0.0.0/24` **ne peuvent
-> pas être reliés** : chaque routeur croit que le réseau est chez lui. Décider ce chiffre
-> coûte une minute avant de câbler ; renuméroter un site vivant, c'est refaire les baies,
-> les hyperviseurs et la frontière. **C'est la décision la moins chère et la plus
-> irréversible de tout ce document.**
+**Les VLAN ne changent jamais** d'un site à l'autre : ils sont locaux, ils ne traversent
+aucun lien inter-sites. Un seul modèle mental, et l'adresse de stockage porte son propre
+numéro de VLAN — `192.168.20.x` est sur le VLAN 20.
 
-Deux invariants portés par la preuve `P23` :
+> **Pourquoi la bande basse est sûre, et non pas seulement libre aujourd'hui.** Les zones
+> d'un tenant sont dérivées en `10.(10+index).(15+categorie).0/24` : leur troisième octet
+> vaut donc **16 au minimum**, et croît avec le nombre de zones. Les octets `0` à `15`
+> ne sont **jamais** alloués — c'est une propriété de la règle, pas une place restée
+> vide. L'underlay y tient largement.
 
-- **Un point de routage porte le même dernier octet partout** : `.1`. La passerelle d'un
-  sous-réseau garde cette adresse, quel que soit l'équipement qui l'assure.
-- **Chaque tenant occupe `10.(10+index).0.0/16`.** Index 11 → `10.21.0.0/16`, index 17 →
-  `10.27.0.0/16`. Aucun réseau de l'hébergeur ne doit chevaucher ces blocs : le symptôme
-  d'une collision est un service qui « ne répond pas » sans aucune erreur nulle part.
+> **Pourquoi le stockage sort de cet espace.** Ces réseaux sont jumbo, non routés, et ne
+> quittent jamais leur site. Ils n'ont donc aucun besoin d'être uniques — et les rendre
+> **identiques partout** épargne une coordination inutile. Contrepartie assumée : ils ne
+> pourront jamais traverser un lien inter-sites. Sans conséquence, puisque ce qui voyage
+> entre deux sites, c'est l'**état** (par le dépôt de sauvegarde), pas le stockage bloc.
+
+Un hébergeur qui n'exploite lui-même **aucun** tenant prend quand même un `index` : c'est
+le seed de son site. Une seule règle, aucun cas particulier.
 
 ### Le MTU n'est pas un détail
 
@@ -71,8 +76,11 @@ C'est le seul équipement qui route, et l'unique point de passage entre l'extér
 l'intérieur. Set-OPS **pilote ses règles par API** : le boîtier reste à l'hébergeur, rien
 n'y est installé.
 
-**Interfaces :** le WAN (noter l'IP publique) ; la gestion en `10.<site>.0.1/24` ; le
-transit en `10.<site>.4.1/24`, par où sortent les machines du tenant.
+**Interfaces :** le WAN (noter l'IP publique) ; la gestion en `10.(10+index).0.1/24` ; le
+transit en `10.(10+index).4.1/24`, par où sortent les machines du tenant.
+
+> **Un point de routage porte le même dernier octet partout** : `.1`, quel que soit
+> l'équipement qui l'assure. Invariant porté par la preuve `P23`.
 
 **Un compte pour l'exploitant :** un utilisateur `ansible` avec sa clé publique.
 **Aucun `sudo` n'est nécessaire** — l'outil lit et appelle l'API. Un compte qui ne peut
@@ -147,7 +155,7 @@ est écrite (`docs/procedure-template-debian13-proxmox.md`).
 | Modèle du commutateur | dicte le dialecte de CLI (`cisco` \| `binardat`) |
 | Domaine public prévu | `exemple.ca` |
 | Gabarit | fait, ou à faire |
-| Numéro de site | `0`, `1`… — voir §2, à décider **avant** de câbler |
+| `index` du site | le même que son tenant — voir §2, à fixer **avant** de câbler |
 | Accès de l'exploitant | sur place, ou lien vers le VLAN de gestion (voir §8) |
 
 **Et deux paires de secrets**, par un canal chiffré et séparément du reste : le Token ID +