Daniel Allaire
777bea8408
L'epreuve de portabilite est passee. Un second ecosysteme souverain complet, monte depuis zero par le meme moteur : 14 hotes, 2583 taches ok, 331 changed, 0 failed. Plan distinct, voute separee, realm technolibre, sa propre AC — et une topologie differente : LDAP et SSO sur des machines separees la ou Chezlepro les co-localise. Cinq devis CONFORME (identite, certificats, PostgreSQL, courriel, frontiere — 55 lignes 0 ecart). Le sixieme dit exactement la bonne chose : les 6 services repondent depuis l'edge, aucun depuis le poste, qui ne resout pas encore technolibre.internal (6 entrees /etc/hosts absentes — le plancher). SIXIEME DEFAUT MOTEUR. Le devis d'identite interrogeait LDAP en `ldapi:///` — un socket UNIX LOCAL — depuis l'hote serveur_keycloak. Cela ne marchait que par CO-LOCATION ACCIDENTELLE. Un tenant qui separe l'annuaire du SSO echouait sur « Failed to import python-ldap » : l'hote SSO n'a pas de client LDAP. Les deux lectures sont deleguees a l'hote DERIVE par resoudre_annuaire. P35 (D-75) : toute application dont le role exige une base en a une au plan. La garde de resoudre_base existait deja, mais s'est declenchee a la 92e tache de collab-01, apres quarante minutes, pour un ecart entierement lisible dans le plan. Rien n'y est code en dur : les roles concernes sont ceux qui INCLUENT resoudre_base, et le groupe reclame est lu dans le DEFAUT de la variable passee — jamais deduit du nom. serveur_icingaweb2 reclame la base de serveur_icinga ; une preuve supposant « role = groupe » aurait crie sur un cas sain. Eprouvee dans les deux sens ET sur les deux tenants, dont les registres n'ont pas la meme portee : base retiree -> ECHEC la nommant ; restauree -> OK. Verifie : prouver.py 35 OK sur les deux instances, ansible-lint production. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.7 KiB
4.7 KiB
La preuve — prouver, pas affirmer
Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.
① Le concept (générique)
Une affirmation sans vérification rejouable n'est que du marketing. « C'est sécurisé », « c'est sauvegardé », « ça fonctionne » — prouve-le. La discipline se résume à une règle :
Ne jamais affirmer plus que ce qu'on prouve.
Trois idées la portent :
- Registre d'affirmations — chaque promesse publique est tracée vers une commande qui la vérifie, ou marquée honnêtement « non prouvée ».
- Harnais rejouable — une seule commande rejoue toutes les preuves et produit une pièce justificative datée. On ne « croit » pas : on relance.
- Le registre a le droit de perdre — une preuve qui échoue fait redescendre l'affirmation. C'est la seule condition pour qu'un tel registre ait de la valeur.
② Comment Set-OPS le fait
- Le registre :
docs/audit/affirmations.md— chaque affirmation du dépôt (README, docs, aidemake, GUI) reliée à une preuve et un statut (✅/🟡/❌/⚪). - Le harnais :
make prouverrejoue les preuves automatisables (P01–P35) et écritdocs/audit/preuve-<date>.md.make verifierles inclut : il échoue si une preuve échoue. - Chaque preuve garde une classe d'erreur. Extrait :
| Preuve | Ce qu'elle empêche de mentir |
|---|---|
| P03 | l'inventaire n'est pas généré du plan (diff vide) |
| P06 | un registre incohérent (dont l'hôte fantôme) |
| P17 | un modèle invalide (tous, pas seulement le socle) |
| P18 | un gabarit de voûte incomplet |
| P19 | un champ du plan que le GUI ne sait pas éditer |
| P20 | de l'adressage stocké (tout doit dériver du seed) |
| P21 | une collision d'index entre instances fédérées |
| P31 | une capacité du dépôt non expliquée (script muet, cible sans aide, rôle sans README) |
| P32 | un intrant qu'un rôle exige et que l'instance ne fournit pas |
| P33 | deux rôles co-localisés qui revendiquent le même port |
| P35 | une application dont le rôle exige une base sans entrée au plan — sinon l'écart n'apparaît qu'après quarante minutes de déploiement |
| P34 | un document qui ne déclare pas son lecteur — il finirait rangé par sujet, donc introuvable |
Ce que ces preuves ne font pas, et il faut le savoir avant de leur faire confiance. Elles sont toutes statiques : elles lisent le dépôt, sans un seul appel réseau. Elles établissent qu'il est cohérent avec lui-même — jamais que le système déployé lui ressemble. C'est dans cet angle mort qu'un certificat d'autorité a pu rester expiré huit heures sous un harnais vert. La conformité du déployé est l'affaire des devis de service (voir
docs/devis-services.md).
Ce n'est pas un framework de test parallèle : le harnais orchestre l'outillage existant, il ne réimplémente aucune validation.
③ Pourquoi c'est transférable
| Set-OPS | Équivalents ailleurs |
|---|---|
make prouver |
tests automatisés, CI/CD, terraform validate |
| registre d'affirmations | traçabilité de conformité (SOC 2, ISO) |
| pièce justificative datée | audit trail, preuve d'audit |
| « le registre peut perdre » | un test vert n'est utile que s'il peut virer rouge |
Tu as appris la vérification rejouable, la preuve d'audit, la culture du test — pas « le harnais de Set-OPS ».
④ À toi de jouer
- Produis une preuve.
make prouver(voûte exportée). Lisdocs/audit/preuve-<date>.md: chaque preuve, son verdict, l'affirmation couverte. - Fais échouer une preuve — exprès. Introduis un hôte fantôme : dans
applications.yml, pointe une appli vers un hôte qui n'existe pas dansserveurs.yml.make prouver: P06 échoue, en nommant l'hôte. Corrige (ou via le<select>de la GUI) : vert. - Une autre. Remets de l'adressage dans une nomenclature (
vlan: 42),make prouver: P20 échoue. Retire-le : vert. - Lis le registre. Ouvre
docs/audit/affirmations.md: trouve une affirmation ⚪ (non prouvable localement) — vois comment elle est assumée comme intention, jamais présentée comme prouvée. - Comprends la valeur. Demande-toi : quelle promesse est-ce que je fais sans preuve ? C'est exactement ce que ce registre force à regarder en face.
Pour aller plus loin (dépôt)
- Le mode d'emploi :
docs/audit/README.md. - Le registre :
docs/audit/affirmations.md; le harnais :scripts/prouver.py. - L'épreuve humaine (« exploitable sans IA ») :
docs/audit/protocole-operateur-independant.md.