# Le plan & l'adressage dérivé > **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer. --- ## ① Le concept *(générique)* Une infrastructure a **beaucoup** de valeurs : adresses IP, VLAN, identifiants de VM, sous-réseaux, passerelles, noms d'hôtes… Deux façons de les gérer : - **Les saisir à la main** — chaque valeur est décidée et écrite quelque part. Fragile : deux endroits finissent par se contredire (l'un dit `10.11.13.11`, l'autre `data-01`), et personne ne sait lequel a raison. - **Les DÉRIVER d'une source unique** — on ne saisit qu'un **seed** (une graine), et *tout le reste se calcule*. Il ne peut plus y avoir de contradiction : il n'y a qu'une vérité. C'est le principe **DRY** (*Don't Repeat Yourself*) appliqué à l'infrastructure, et le principe de la **source unique de vérité**. Le plan **déclaratif** décrit *l'état voulu* ; l'adressage n'y est pas *écrit*, il en **découle**. --- ## ② Comment Set-OPS le fait Le **plan** (`instance/plan/`) est la source unique. Cinq registres : | Registre | Décrit | |---|---| | `serveurs.yml` | les VM (fonction, état, intégrations) | | `applications.yml` | les services et leurs **liens** | | `bases-donnees.yml` | les bases et qui les consomme | | `domaines.yml` | les zones DNS publiques | | `nomenclature.yml` | le **modèle réseau** : zones + placement des fonctions + le **seed `index`** | **Le seed, c'est `index`.** À partir de lui *seul*, Set-OPS dérive **tout** l'adressage : | Élément | Formule (modèle 6 zones) | |---|---| | Supernet | `10.(10+index).0.0/16` | | Sous-réseau de zone | `10.(10+index).(15+zone).0/24` | | Passerelle | `…(15+zone).1` | | VLAN sur le trunk | `1000 + index×10 + zone` | | VMID | `VLAN·octet-hôte·séquence` (9 chiffres) | `make instancier` **génère** `hosts.yml` depuis le plan. **On n'édite jamais `hosts.yml` à la main** — c'est un artefact. On édite le plan (ou la GUI), puis « Appliquer le plan ». La **preuve P20** interdit d'écrire de l'adressage dans la nomenclature : si quelqu'un y remet un `supernet` ou un `vlan`, `make prouver` échoue. La règle est *tenue par une machine*, pas par la discipline. --- ## ③ Pourquoi c'est transférable | Set-OPS | Équivalents ailleurs | |---|---| | adressage dérivé du seed | `cidrsubnet()` de Terraform, IPAM de **NetBox** (dérive les plages) | | plan → inventaire généré | tout générateur d'inventaire (`nb_inventory`, CMDB → config) | | source unique de vérité | principe universel : une valeur, un seul endroit | | DRY | fondamental du génie logiciel | Tu as appris **la dérivation, DRY, la source unique de vérité, le déclaratif** — pas « la nomenclature de Set-OPS ». --- ## ④ À toi de jouer 1. **Observe la dérivation.** Vue **Serveurs** de la GUI : chaque carte montre VMID · IP · VLAN. Aucun n'a été saisi — tous viennent du `index`. Note l'IP d'un hôte. 2. **Change le seed, regarde tout suivre.** Panneau **Intrants → Réseau**, change `index` (ex. de 1 à 7), « Appliquer le plan ». **Toutes** les IP basculent de `10.11.x` à `10.17.x`, les VLAN de `101x` à `107x` — d'un seul chiffre. Puis remets ta valeur. 3. **Sens la source unique.** `make instancier` (diff), puis `make instancier-appliquer` : *« DIFF VIDE : le plan reproduit exactement l'inventaire »* — le plan **est** la vérité. 4. **Casse & répare.** Édite `hosts.yml` à la main (change une IP). Relance `make instancier` : il **signale l'écart**. Ré-applique : le plan **écrase** ta modification. Tu *sens* que `hosts.yml` n'est pas la vérité — le plan l'est. 5. **Éprouve le garde-fou.** Ajoute une ligne `supernet: 10.99.0.0/16` dans une nomenclature, puis `make prouver` : **P20 échoue** (« adressage stocké »). Retire-la : vert. La règle se *prouve*. --- ## Pour aller plus loin *(dépôt)* - Le plan et sa génération : `docs/plan-et-generation.md`. - La dérivation, en code : `scripts/inventory_rules.py` (`supernet_de`, `vlan_de`…). - Le seed multi-instance : unité **[Multi-instance & fédération](Multi-instance-et-fédération)**. - La règle prouvée : unité **[La preuve](La-preuve)** (P20).