Set-OPS-Public/wiki/La-preuve.md

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–P61, sans trou dans la série) 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
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

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.

---

Le défaut le plus dangereux n'est pas l'erreur, c'est la copie

Set-OPS pilote plusieurs écosystèmes. Avant d'agir, chaque script doit donc savoir lequel il regarde — par le lien instance, ou par la variable SETOPS_INSTANCE.

En août 2026, neuf scripts avaient chacun écrit leur propre réponse à cette question. Trois lignes chacun. Aucune n'était fausse en soi.

Le problème n'est pas l'erreur : c'est que neuf copies ne vieillissent pas ensemble. Quand on améliore l'une, les huit autres ne le savent pas. Et personne ne peut le voir, parce que de l'intérieur d'un fichier, la copie locale a toujours l'air correcte.

Ce que ça donnait

make placement-plan visait un autre tenant et répondait :

Devis du placement — tenant « instance »
  noeud asgard · stockage TrueNAS · gabarit 99998   →  CONFORME

C'était vrai — sur l'autre écosystème. Sa copie lisait le lien au lieu de la variable. Comme les deux tenants portaient les mêmes valeurs de placement, le verdict semblait juste. C'est très exactement la circonstance où une erreur ne se voit pas.

Cinq défauts de cette famille sont sortis en cinq jours. Tous dans des outils qui constatent — preuves et devis — jamais dans ceux qui agissent. C'est moins grave et plus insidieux : un outil qui agit mal, on le voit ; un outil qui mesure mal dit « conforme », et on passe à la suite.

La réponse

Une source unique : une fonction, dans un fichier, que tous appellent. Si elle est fausse, elle l'est partout d'un coup — donc visible, donc corrigée une fois.

Et une preuve, P41, qui refuse la prochaine copie. Elle en a trouvé une dixième le jour de son écriture, dans le fichier des preuves lui-même.

C'est la même leçon que proxmox-hebergeur.yml : les nœuds et stockages du cluster recopiés chez chaque tenant avaient divergé. Une source, pas N copies — pour les données comme pour le code.

---

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.