hebergeur : l'adressage derive d'un NUMERO DE SITE, et le lien inter-sites

Le document prescrivait 10.0.x.x a tout hebergeur — c'est-a-dire exactement les
plages de Chezlepro. Deux sites qui portent les memes sous-reseaux NE PEUVENT PAS
etre relies : chaque routeur croit que le reseau est chez lui. Le defaut etait
invisible tant qu'il n'existait qu'un seul site.

Il devient bloquant des qu'on veut une reprise apres sinistre MUTUELLE : la
replication doit tourner machine a machine, en continu. D'ou `10.<site>.x.0/24`.
Les VLAN ne changent pas — ils sont locaux et ne traversent jamais le lien ;
une seule table mentale.

Nouveau §8 : relier deux sites. Il separe deux besoins qu'on confond facilement.
Les services publies n'ont besoin de RIEN (edge + TLS + SSO). Le plan de controle,
si : l'inventaire adresse les VM par leurs IP privees DERIVEES — aucun chemin
publie ne peut y mener sans casser la derivation — et les deux API d'admin
tournent avec la verification du certificat DESACTIVEE.

Acces nomade pour exploiter ponctuellement ; site-a-site pour repliquer, parce
qu'il doit tenir sans qu'aucun poste soit allume. Dans les deux cas la politique
est explicite : un lien qui joint deux reseaux defait en silence l'isolation
inter-tenant.

Ce que la reprise mutuelle exige en plus : capacite chez le survivant pour les
DEUX ecosystemes, gabarit present des deux cotes, voute conservee hors de son
propre site. Les sauvegardes sont chiffrees cote client : le site d'accueil
heberge du chiffre qu'il ne peut pas lire — la confiance porte sur la
DISPONIBILITE, pas la confidentialite.

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

docs/preparer-un-site-hebergeur.md

@@ -25,12 +25,27 @@ 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.
+
 | Rôle | VLAN | Sous-réseau | MTU | Qui y vit |
 |---|---|---|---|---|
-| Gestion | 10 | `10.0.0.0/24` | 1500 | frontière `.1`, commutateurs, OOB/IPMI, admin hyperviseur |
-| Transport VXLAN | 11 | `10.0.5.0/24` | 1500 | hyperviseurs seulement |
-| Stockage iSCSI | 20 | `10.0.1.0/24` | 9000 | baie ↔ hyperviseurs |
-| Sortie des tenants | 40 | `10.0.4.0/24` | 1500 | frontière `.1`, nœuds de sortie |
+| 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 |
+
+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.
+
+> **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.**
 
 Deux invariants portés par la preuve `P23` :
 
@@ -56,8 +71,8 @@ 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.0.0.1/24` ; le transit
-en `10.0.4.1/24`, par où sortent les machines du tenant.
+**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.
 
 **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
@@ -132,7 +147,8 @@ 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 |
-| Accès | sur place, ou VPN débouchant sur le VLAN 10 |
+| Numéro de site | `0`, `1`… — voir §2, à décider **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 +
 secret de l'hyperviseur, la clé + secret de l'API de la frontière. Ils n'entrent **jamais**
@@ -151,7 +167,37 @@ Les VM ont besoin de sortir sur Internet pour leurs paquets système. Le reste
 artefacts applicatifs — est **poussé depuis le poste de l'exploitant**, pas téléchargé par
 les machines.
 
-## 8. Ce qu'il ne faut pas faire
+## 8. Relier deux sites (exploitation à distance, reprise après sinistre)
+
+Deux besoins bien distincts, qu'il ne faut pas confondre :
+
+**Les services publiés n'ont besoin de rien.** Nuage, forge, courriel, SSO sortent par la
+frontière en TLS, derrière l'authentification unique. Aucun tunnel n'est requis pour les
+utiliser, et en ajouter un n'apporterait rien.
+
+**Le plan de contrôle, si.** L'inventaire adresse les machines par leurs IP privées
+**dérivées** ; il n'existe aucun chemin publié vers elles, et il ne peut pas y en avoir
+sans casser la dérivation. Les API de l'hyperviseur et de la frontière, elles, tournent
+avec la **vérification du certificat désactivée** — les exposer publiquement reviendrait à
+publier les deux surfaces les plus privilégiées sans savoir à qui l'on parle.
+
+| Besoin | Forme adaptée |
+|---|---|
+| Déployer et exploiter à distance, ponctuellement | accès **nomade** (poste → site) : une clé, révocable, aucun couplage entre sites |
+| **Réplication de sauvegardes, reprise mutuelle** | lien **site-à-site** : il doit tenir sans qu'aucun poste soit allumé |
+
+Dans les deux cas, la politique doit être explicite : un lien qui joint simplement deux
+réseaux **défait en silence l'isolation inter-tenant**. WireGuard s'y prête bien — ses
+`allowed-ips` *sont* la politique : ce qui n'y figure pas ne traverse pas.
+
+> **Ce que la reprise mutuelle exige en plus** : des plages de gestion distinctes (§2), de
+> la capacité chez le survivant pour faire tourner **les deux** écosystèmes, un gabarit
+> présent **des deux côtés**, et la voûte de chaque instance conservée hors de son propre
+> site. Les sauvegardes, elles, sont chiffrées **côté client** : le site d'accueil héberge
+> du chiffré qu'il ne peut pas lire. La confiance demandée porte sur la **disponibilité**,
+> pas sur la confidentialité.
+
+## 9. Ce qu'il ne faut pas faire
 
 - **Ne pas créer de VM à la main** pour le tenant. Elles sont toutes dérivées du plan ;
   une VM créée à côté est invisible pour l'outil, qui la détruira sans le savoir.