Pourquoi « build vert » sans la sortie brute n'a aucune valeur de preuve

Si tu as 30 secondes. Quand un agent IA déclare qu'un build est vert, qu'un test passe, qu'un drift a été détecté, ou qu'un contact « n'existe pas » dans la base, la phrase n'est pas une preuve, c'est une assertion. Dans la plupart des cas elle est juste. Quand elle est fausse, elle l'est toujours de la même manière, par confiance interne au modèle découplée de l'état externe vérifiable. Règle de survie après 118 808 lignes produites en 32 jours de travail effectif avec Claude Code, toute affirmation factuelle vient avec sa preuve matérielle dans le même message, ou n'a aucune valeur évidentielle.

---

Quatre faux positifs en deux heures

10 avril 2026, après-midi, refonte d'un module sensible de l'ERP. J'enchaîne cinq blocs de modifications avec un agent Claude Code, et à chaque étape l'agent rend la même formule, « Compiled successfully. » Je pousse. Le runtime crashe. Je relis la sortie, je vois QRCodeSVG référencé alors que l'import a été supprimé, isSeancePassed passé à un composant qui ne l'accepte plus, des types non régénérés après un changement de schéma Supabase, des refs JSX orphelines après un revert. Quatre annonces consécutives de vert avec quatre erreurs TypeScript bien réelles derrière.

Niran est au bureau d'à côté, hoodie sombre, l'emballage replié de son burger en équilibre sur un coin de laptop. Il lit un PDF en silence. Au quatrième Compiled successfully qui se révèle faux, je me tourne vers lui ; il lève les yeux une seconde, hoche la tête, revient à son écran. La verbosité de l'agent et l'économie de gestes du judoka tiennent la même conversation, et c'est lui qui a raison.

Je ne reproche pas à l'agent d'avoir menti. Il a résumé ce qu'il croyait avoir vu. Le résumé est cohérent avec son état interne et désaligné avec la matière. Pas un seul de ces quatre crashes ne se serait produit si l'agent avait collé la sortie brute de pnpm build plutôt que sa lecture résumée.

Le glissement épistémique

Le problème n'est pas la véracité, c'est la valeur évidentielle. Une assertion sans matériel à l'appui ne se vérifie pas, elle se croit ou pas. Le mécanisme est connu : un agent entraîné par reinforcement learning from human feedback résume par défaut parce qu'il a appris que les humains préfèrent les réponses brèves aux logs verbeux ; ce qui est un service en chat devient un piège en production. « Le build est vert » sans la sortie brute du compilateur ne peut être ni infirmé ni confirmé par un tiers, c'est un état d'âme du système, pas un fait du monde. Tant qu'on ne distingue pas ces deux régimes, on opère à l'aveugle dans la zone grise où s'accumulent les régressions silencieuses qu'aucun monitoring ne détecte. La fonction du résumé n'est pas d'être faux, c'est de n'être pas vérifiable.

Cinq formes de la même évasion

L'évasion est toujours la même. Un verbe d'état au présent, « est », « passe », « confirme », « introuvable », sans rattachement à un artefact externe vérifiable. Cinq variantes que je rencontre dans le repo Rembrandt :

1. « Le build est vert. » Sans la sortie brute de pnpm build ou tsc --noEmit.
2. « Les tests passent, la CI est verte. » Sans rapport runner ni URL du run.
3. « Drift détecté entre l'enum DB et l'enum TS », ou son inverse, « le contact n'existe pas dans la base ». Sans la requête SQL exécutée ni ses lignes brutes.
4. « EXPLAIN ANALYZE confirme que l'index est utilisé. » Sans le plan brut, sur la requête exacte que l'application envoie. Pas la table cible isolée, parce qu'une vue intermédiaire avec un CASE COALESCE peut tuer l'index sans que l'isolation le révèle.
5. « Le webhook renvoie 400 / 422. » Sans le payload brut côté partenaire, alors que neuf fois sur dix le diagnostic part de là.

Toutes partagent la même grammaire. La parade est uniforme. On ne demande pas à l'agent de mieux raisonner, on lui demande de joindre la commande et sa sortie brute, ou la requête SQL et ses lignes, ou le payload, dans le même message que l'assertion. Sans ça, l'assertion ne vaut rien.

La règle, codée dans le CLAUDE.md racine

# Vérification matérielle (extrait CLAUDE.md racine)
- Toute affirmation "build vert / tests passent / CI verte / drift
  détecté / contact introuvable / OK" doit être accompagnée *dans le
  même message* de la commande de vérification et de sa sortie brute.
- Tout chiffre relayé à un humain doit être vérifié par requête SQL
  avant d'être relayé.
- EXPLAIN ANALYZE sur requête de production : exécuter sur la requête
  exacte que l'application envoie (vue/RPC incluses), pas sur la table
  cible isolée. Deux runs consécutifs avant de juger.
- Sur 400/422 d'un partenaire externe : exiger le payload brut avant
  de proposer un fix.
- `tsc --noEmit` CLI = autorité, panneau IDE = potentiellement périmé.

Côté humain, trente secondes de friction par échange et zéro push cassé sur les chantiers où la règle tient. La règle écrite ne suffit pas pour autant. Une discipline qui repose sur la mémoire s'érode. Il faut durcir.

Durcir avec un script

scripts/verify-head-builds.sh stash le working tree, fait tsc --noEmit sur HEAD, et restore. C'est ce qui permet d'exiger un build vert sur le commit qu'on s'apprête à pousser, pas sur l'arbre de travail mêlé de modifications non stagées.

# scripts/verify-head-builds.sh — extrait load-bearing
HAS_LOCAL_CHANGES=0
if ! git diff --quiet HEAD 2>/dev/null \
   || [[ -n "$(git ls-files --others --exclude-standard)" ]]; then
  HAS_LOCAL_CHANGES=1
fi

if [[ $HAS_LOCAL_CHANGES -eq 1 ]]; then
  git stash push -u -q --message "verify-head-builds-autostash-$$"
fi

# tsc sur HEAD pur, sans contamination du working copy
if npx tsc --noEmit 2>&1; then
  echo "✓ HEAD compile proprement — safe à push"
else
  echo "✗ HEAD ne compile PAS — fix avant push"
  exit 1
fi

Et une convention d'écriture côté agent : tout chiffre relayé à un humain assorti de la requête SQL qui l'a produit, sous forme de bloc collable. Pas de chiffres orphelins, ni en prose, ni en commit message. Bruyant la première semaine, transparent ensuite.

Ce que tu peux copier dans ton projet

Snippets complets (extrait CLAUDE.md règle d'évidentialité, script verify-head-builds.sh complet) dans le dossier material-verification/ du repo compagnon de la série, licence MIT.

Trois gestes directement applicables si tu travailles avec un agent coding :

1. La règle d'évidentialité dans le CLAUDE.md racine (cinq bullets ci-dessus). Sans cet ancrage écrit, le reste est cosmétique.

2. Le script verify-head-builds.sh : stash + tsc --noEmit sur HEAD + restore. Treize lignes de bash, MIT.

3. Une convention de chiffres traçables. Tout chiffre accompagné de sa requête SQL dans le même message. Pas de chiffres orphelins en prose, ni en commit message.

Et vous, sur quelle assertion verte avez-vous arrêté de croire en premier ? Je lis les commentaires.

Ce qu'on ne croit plus

Au bout de quelques semaines, on entend « Compiled successfully » différemment. Pas un constat, une prétention dont la valeur dépend strictement de ce qui suit. Si rien ne suit, la prétention est nulle. La règle vaut hors IA aussi. Un humain qui dit « je viens de vérifier, le compteur est à 1247 » sans coller la requête vit dans la même zone grise. Niran n'a jamais eu besoin qu'on lui explique cette différence. Au judo, la chute n'est pas un avis sur la chute, c'est le sol qui répond.

---

Code compagnon, rembrandt-samples/material-verification/, CLAUDE.md.snippet + verify-head-builds.sh, MIT.

La règle d'évidentialité ci-dessus est désormais R1 du Counterpart Toolkit : github.com/michelfaure/doctrine-counterpart, 14 règles opérationnelles, install en 1 commande, CC-BY-4.0.