Set-OPS-Public/wiki/La-preuve.md
Daniel Allaire 85fed974a4 wiki : rattraper la reconstruction, et une unite sur la verification du deploye
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>
2026-08-09 15:11:43 -04:00

91 lines
4.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 (**P01P33**) 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`.