Daniel Allaire
5bc3bceac1
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
3.3 KiB
Set-OPS — moteur souverain et compagnon pédagogique
Pour qui : celui qui apprend le métier. Chaque unité part d'un fondamental TIC, pas d'un produit. Pour exploiter dès aujourd'hui, va à Reprendre l'écosystème ; pour modifier le moteur, la carte du dépôt est dans
docs/carte-set-ops.md.
Bienvenue. Set-OPS est le moteur Ansible qui déploie un écosystème numérique souverain complet (Alliance Boréale · tout est libre). Mais c'est aussi, et volontairement, un outil pédagogique : il instancie pour de vrai la quasi-totalité des fondamentaux des TIC, avec des méthodes 100 % génériques.
Deux usages, un seul système
- Exploiter : monter et opérer un écosystème réel (PKI, identité, courriel, DNS, observabilité, supervision, sauvegardes…).
- Apprendre : chaque service est une lentille sur un fondamental. Tu n'apprends pas « Keycloak » — tu apprends le SSO/OIDC. Pas « step-ca » — la PKI. Ces savoirs se transfèrent partout (Active Directory, Okta, Vault, n'importe quel DNS…).
Ce wiki est publié depuis le dépôt (
wiki/). Une page modifiée dans l'interface de la forge est détruite à la publication suivante : on lit ici, on écrit dans le dépôt.
Comment ce wiki est organisé
| Section | Contenu |
|---|---|
| Unités d'apprentissage | Un fondamental TIC par page, toujours selon le même moule (ci-dessous). Des services (identité, PKI, courriel…) et de la méthode (le plan, le multi-instance, la preuve). |
| Opérations (runbooks) | Les procédures ne vivent pas ici : elles sont dans le dépôt, docs/runbooks-exploitation.md. Le wiki y pointe (même règle que la référence technique, ci-dessous). |
| Glossaire | Les concepts-clés en une phrase (seed, bindings, le plancher, hôte fantôme, voûte…). |
| Référence technique | Le détail du « comment » vit dans le dépôt (docs/, README des rôles) — ce wiki y pointe, ne le recopie pas (pour éviter la dérive). |
Le moule d'une unité d'apprentissage
Chaque unité suit quatre temps :
1. Le concept (générique, indépendant de tout produit) 2. Comment Set-OPS le fait (le vrai, observable dans le lab) 3. Pourquoi c'est transférable (les équivalents ailleurs) 4. À toi de jouer (observe · interroge · casse · répare)
Par où commencer
- 🔑 Reprendre l'écosystème — si tu dois l'exploiter dès aujourd'hui : l'ordre des opérations, pas la théorie.
- 👉 Identité & SSO — l'unité-pilote côté services (SSO, annuaire, OIDC).
- 🧭 Le plan & l'adressage dérivé — l'unité-pilote côté méthode : un seed, tout en découle. C'est la clé de voûte du reste.
- 🌐 Multi-instance & fédération — un moteur, N écosystèmes.
- 🔬 La preuve — ne jamais affirmer plus que ce qu'on prouve.
Deux axes sont enseignés partout : le QUOI (les concepts) et le COMMENT (les méthodes de métier : déclaratif, idempotent, vérifier-avant-déployer, restaurer-pour-prouver, durcir). C'est la culture d'un artisan du numérique souverain.