Daniel Allaire
ac85278366
La refonte de ce matin posait une convention. Une convention qu'on n'outille pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique au corpus documentaire. Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32 autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus utile du depot au §6 de autorisation.md. Les 38 le declarent desormais, lecteur determine document par document et non colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie, gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE). Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la premiere page ajoutee : un document qui s'annonce genere, et un fragment sans titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation dans leur corps — d'etre exemptes a tort. Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en nommant deux documents que mon inventaire avait manques (docs/audit/). Puis test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la nommant ; restauree -> OK. Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en revue ; elle garantit qu'on a du y penser. P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md annoncaient encore 30 preuves). Verifie : prouver.py 0 (34 OK), plan-recette inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
80 lines
3.5 KiB
Markdown
80 lines
3.5 KiB
Markdown
# La méta-classe — une définition, tout l'écosystème
|
|
|
|
> **Pour qui :** le **mainteneur** — le concept qui explique pourquoi on écrit *un* plan et non onze serveurs.
|
|
|
|
Set-OPS se comporte comme une **méta-classe** : on n'écrit pas onze serveurs, on
|
|
écrit *une* **définition d'écosystème** (le plan déclaratif) ; l'instanciation
|
|
engendre la flotte entière, cohérente. Le réseau, la taille des VM, les groupes, les
|
|
liens de bases (DSN) et l'exposition DNS sont **dérivés** — jamais saisis deux fois.
|
|
|
|
> Concept acté dans [`positionnement.md`](positionnement.md) : « la définition
|
|
> instancie toute la flotte ». La dérivation des ressources est décrite dans
|
|
> [`dimensionnement-ressources.md`](dimensionnement-ressources.md).
|
|
|
|
## Schéma
|
|
|
|
```mermaid
|
|
flowchart TB
|
|
subgraph DEF["① DÉFINITION — la méta-classe (le plan déclaratif)"]
|
|
direction LR
|
|
NOM["nomenclature.yml<br/>catégories · VLAN · fonctions"]
|
|
SRV["serveurs.yml<br/>VM = fonction + état + overrides"]
|
|
APP["applications.yml<br/>app → rôle · hôte · expose"]
|
|
BD["bases-donnees.yml<br/>serveurs_bd · DSN · portée"]
|
|
DOM["domaines.yml<br/>domaines publics · edge"]
|
|
EMP["roles/*/meta/empreinte.yml<br/>empreinte ressources"]
|
|
TPL[("golden template<br/>Debian 13 durci")]
|
|
end
|
|
|
|
subgraph GEN["② DÉRIVATION — make instancier (le constructeur)"]
|
|
direction LR
|
|
R1["réseau<br/>VMID · VLAN · IP · gw"]
|
|
R2["ressources<br/>cœurs · RAM · disque"]
|
|
R3["groupes<br/>socle + services + état"]
|
|
R4["liens<br/>DSN + exposition DNS"]
|
|
end
|
|
|
|
subgraph INST["③ INSTANCES — la flotte (inventory hosts.yml)"]
|
|
direction LR
|
|
INV[["hosts.yml"]]
|
|
VMS(("11 VM<br/>infra-pki · dns · mail · edge<br/>idm · data · obs · mon · forge · web"))
|
|
end
|
|
|
|
ECO["④ ÉCOSYSTÈME souverain en service<br/>PKI · DNS · IdM/SSO · Données · Observabilité · Forge · Web"]
|
|
|
|
DEF --> GEN --> INST
|
|
TPL -. "clone + cloud-init" .-> VMS
|
|
INV --> VMS
|
|
INST -- "make deployer · rôles par groupe" --> ECO
|
|
```
|
|
|
|
## Le même schéma en texte
|
|
|
|
```
|
|
① DÉFINITION — la « méta-classe » (instance/plan/ + roles/*/meta/empreinte.yml)
|
|
nomenclature · serveurs · applications · bases-données · domaines
|
|
⟦ golden template Debian 13 durci ⟧
|
|
│ make instancier
|
|
▼
|
|
② DÉRIVATION — le constructeur (instancier.py · inventory_rules · filter_plugins)
|
|
réseau (VMID·VLAN·IP·gw) · ressources (cœurs·RAM·disque) · groupes · DSN+DNS
|
|
│ = instanciation
|
|
▼
|
|
③ INSTANCES — la flotte (inventory hosts.yml : 11 VM cohérentes)
|
|
infra-pki·dns·mail·edge · idm · data · obs · mon · forge · web
|
|
▲ clone du golden template + identité cloud-init
|
|
│ make deployer (rôles Ansible par groupe)
|
|
▼
|
|
④ ÉCOSYSTÈME souverain en service
|
|
PKI · DNS interne · IdM+SSO · Bases · Observabilité · Forge · Web
|
|
|
|
1 définition ───────────────▶ N VM : réseau, taille, groupes, DSN, DNS
|
|
(édite le plan) tout dérivé, rien saisi deux fois.
|
|
```
|
|
|
|
## Pourquoi c'est une *méta*-classe
|
|
|
|
Une classe ordinaire instancie **un** objet. Ici, **une** définition instancie un
|
|
**ensemble cohérent** d'objets (VM + services + liens), avec leurs invariants garantis
|
|
par dérivation plutôt que par discipline humaine. Éditer le plan, c'est faire évoluer
|
|
la classe ; régénérer, c'est ré-instancier — de façon idempotente.
|