verifier / verifier (push) Has been cancelled

Details

documentation : la tournee des 74 documents, parce qu un balayage ne lit pas

La revision a commence par un balayage par motifs — chemins morts, cibles make
absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque
tout le reste : un motif ne voit que ce qui s exprime en motif.

make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait
au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par
AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus
haut. Il fallait lire pour la voir.

74 documents lus un par un. 66 corriges, 8 exacts.

CE QUI ETAIT FRANCHEMENT FAUX

AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre
des VM reelles. Elle a ete rasee et remontee depuis zero trois fois.
ecosysteme-chezlepro.md, le document montre a un client, portait la meme
phrase : il se sous-vendait gravement.

courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de
son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n
est construit alors qu il rapporte des mesures datees du role en fonctionnement.
hebergeur-exploitation.md disait rien n est fait d un depot qui existe.
filiation-emancipation.md se contredisait a deux ecrans de distance.

DES MODELES DECRITS D APRES UN MONDE ANTERIEUR

Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le
donnaient en exemple d integration FACULTATIVE — il est universel depuis le
2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID
a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki
qui avait raison.

CE QUI CASSE AU PREMIER ESSAI

Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le
FABRIQUE et le critere R2 de l epreuve d operateur independant.
preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait
detruite : raser derive du plan, il ne la detruira jamais — le risque est l
inverse. Un mot de passe d essai en clair dans un depot public.

DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME

P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d
un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux
declarations reelles : 12 annonces, 21 reels.

Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la
conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une
erreur ajoute l assurance a l erreur.

CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT

Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les
meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il
nomme existe. P29 tient les positions d authentification, personne ne tient les
habilitations.

make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort.

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

2026-09-06 16:18:23 -04:00

4.6 KiB

Raw Blame History

Liaisons (bindings)

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

① Le concept (générique)

Un système réel n'est pas fait de pièces isolées, mais de relations : cette app utilise cette base, ce serveur fait confiance à cette AC, ce nœud envoie ses logs à ce collecteur.

Deux façons de câbler ces relations :

En dur — recopier l'adresse/le nom dans chaque config. Fragile : déplacer une pièce oblige à éditer partout, et ça casse la portabilité.
En liaisons déclaratives — on déclare « A est lié à B », et le moteur résout l'adresse concrète au bon moment. Déplacer B ? On ne touche qu'un endroit.

Analogie NetScaler (Citrix ADC) : tu bind un service à un vserver, une policy à un vserver, un monitor à un service. Tu ne codes pas des IP en dur — tu relies des entités, et l'appareil fait le reste. Les liaisons de Set-OPS, c'est exactement ce modèle.

Deux axes pour classer une liaison (indépendants) :

Niveau : app→app/base/domaine (liens) ou nœud→service de flotte (intégrations).
Modalité : requise (constitutive — sans elle, ça ne s'instancie pas) ou optionnelle (élective — un choix, l'absence est légitime).

② Comment Set-OPS le fait

Type	Où	Résolu en	Exemple
`liens`	`applications.yml`	config (host_vars, lookups)	Forgejo → sa base ; app → domaine exposé
`intégrations`	`serveurs.yml`	groupe + agent client	nœud → PKI, sauvegarde, métriques…

Les résolveurs partagés font le pont : resoudre_base (app→base) et resoudre_annuaire (app→annuaire) lisent un registre et bâtissent la connexion — le secret restant déréférencé dans le rôle, jamais en clair.

La modalité structure la robustesse : une liaison requise absente → le moteur refuse d'instancier (ex. une base sans serveur SQL). Une optionnelle absente → silence (ex. un nœud sans client_backup : il ne détient pas d'état, il n'a rien à sauvegarder).

Attention à une troisième catégorie, qui n'est ni l'une ni l'autre : l'universelle. client_pki, client_metrique, client_journal, client_resolveur et client_artefacts ne se déclarent pas — tout hôte les reçoit par dérivation, et P26 refuse qu'un hôte y échappe. Cette unité citait client_journal en exemple d'optionnelle jusqu'au 2026-09-06 : c'est l'inverse. Le plan portait 28 lignes qui disaient « oui » à quelque chose de vrai pour tous ; elles n'existaient que pour être oubliées, et quatre l'avaient été.

C'est le concept de Set-OPS : tu déclares les liaisons, le moteur câble.

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
liens/intégrations déclaratifs	NetScaler bindings · références de ressources Terraform
service ↔ backend	Kubernetes : Service↔Pods, Ingress↔Service
requis vs optionnel	dépendances hard vs soft (partout)

Tu as appris la relation déclarative, la résolution par un moteur, requis vs optionnel — pas un produit. C'est un modèle mental qui vaut de NetScaler à Kubernetes.

④ À toi de jouer

Lis une liaison. Ouvre instance/plan/applications.yml : une app avec expose: (liaison app→domaine), et serveurs.yml : un nœud avec integrations: (liaison nœud→service).
Vois-la se résoudre. Après make instancier, regarde l'inventaire généré : la cible est devenue une valeur concrète (FQDN, groupe) — le moteur a câblé.
Requise, optionnelle, universelle. Compare les trois : retirer client_backup d'un nœud sans état → aucun problème (optionnelle). Déclarer une base sans serveur → make instancier échoue (requise). Essayer de recopier client_metrique dans serveurs.yml → le plan refuse (universelle : elle est dérivée, la recopier créerait une seconde source qui finirait par diverger).
Casse & répare. Casse une liaison requise (ex. réfère une base à un serveur inexistant), relance l'instanciation : échec clair avant tout déploiement. Corrige : ça passe. Le moteur attrape le câblage manquant à ta place.

Pour aller plus loin (dépôt)

Conception + taxonomie (niveau × modalité) : docs/bindings-conception.md (§11).
Résolveurs : roles/resoudre_base, roles/resoudre_annuaire ; registres : instance/plan/.
Toutes les autres unités sont, au fond, des liaisons en action.

4.6 KiB Raw Blame History Unescape Escape