Table of Contents

La preuve — prouver, pas affirmer

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 (P01–P21) 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

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). Lis docs/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 dans serveurs.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.

Set-OPS

🏠 Accueil

Unités d'apprentissage

Fondations

Communication

Données

Observabilité

Socle & méthode

Flotte & preuve

Opérations

Runbooks → dépôt docs/runbooks-exploitation.md

Repères

Glossaire
Référence technique → dépôt docs/