Le wiki datait du 3 aout. Verifie avant d'y toucher : toutes les cibles make citees existent, aucune commande morte. La-preuve.md annoncait P01-P21 ; le harnais est a P33. Les trois nouvelles ajoutees, et surtout la page dit maintenant ce que ces preuves NE FONT PAS : elles sont statiques, elles lisent le depot, et c'est dans cet angle mort qu'une AC est restee expiree huit heures sous un harnais vert. Infra-as-Code-et-idempotence.md enseignait l'idempotence comme acquise. Vrai role par role, faux a l'echelle de la flotte. La page enseigne desormais depuis les chiffres (924 -> 17 -> 0), raconte ce que les 17 cachaient, et explique pourquoi il faut verifier le zero lui-meme. Nouvelle unite « Verifier le deploye » : la difference entre valider du code et verifier un systeme, avec les trois regles qui separent un devis utile d'un devis decoratif. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
91 lines
4.4 KiB
Markdown
91 lines
4.4 KiB
Markdown
# 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,
|
||
aide `make`, GUI) reliée à une preuve et un statut (✅/🟡/❌/⚪).
|
||
- **Le harnais** : `make prouver` rejoue les preuves automatisables (**P01–P33**) et écrit
|
||
`docs/audit/preuve-<date>.md`. `make verifier` les 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** |
|
||
|
||
> **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
|
||
|
||
1. **Produis une preuve.** `make prouver` (voûte exportée). Lis
|
||
`docs/audit/preuve-<date>.md` : chaque preuve, son verdict, l'affirmation couverte.
|
||
2. **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 dans `serveurs.yml`. `make prouver` : **P06
|
||
échoue**, en nommant l'hôte. Corrige (ou via le `<select>` de la GUI) : vert.
|
||
3. **Une autre.** Remets de l'adressage dans une nomenclature (`vlan: 42`), `make prouver` :
|
||
**P20 échoue**. Retire-le : vert.
|
||
4. **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.
|
||
5. **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`.
|