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>
4.6 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–P34) 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 |
| 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.