Le vérificateur aveugle : ce que notre porte anti-fabrication est autorisé à voir

En juillet 2026, nous avons testé le vérificateur qui protège notre pipeline de conformité multi-étapes contre les fabrications en insérant des faits fictifs dans ses entrées. La plupart des fabrications insérées sont passées au travers. Ce résultat ressemblait à une faille de sécurité dans le seul composant dont le rôle est de détecter les fabrications. Ce n'était pas le cas, et la raison pour laquelle ce n'était pas le cas est une règle de conception que nous traitons désormais comme un principe permanent.

Le test d'insertion avait alimenté ses faits fictifs dans le brief de raisonnement, le document que le vérificateur est contractuellement tenu de traiter comme une vérité établie, puis a compté combien le vérificateur avait marqué. Mesuré de cette manière, le vérificateur n'aurait pas pu réussir un test de compétence sur la détection de fabrications. Pendant ce temps, la solution intuitive à laquelle tout le monde pense — laisser le vérificateur marquer tout fait du brouillon absent du brief — a fait quelque chose de pire que de manquer des fausses informations : sur des brouillons propres, il a marqué 9 sur 9 pour une famille de modèles et 3 sur 9 pour une autre. Et le contrat restreint que nous avons conservé a détecté, lors d'un vrai passage en production, la classe d'échec que sa portée couvre effectivement : une citation que le brouillon affirmait et que l'ensemble approuvé du brief ne contenait pas.

Nous appelons le principe derrière cette approche le vérificateur aveugle : une porte anti-fabrication doit être limitée à ce qu'elle peut réellement voir. L'élargissement que nous avons mesuré jugeait la vérité sans accès aux sources et marquait la plupart des brouillons propres tout en n'en détectant aucun des fausses informations qui avaient motivé son existence. La vérification d'honnêteté doit être mécanique, et mécanique signifie que la réponse se trouve dans les entrées.

Le test qui nous a induits en erreur

Le pipeline s'appelle Beyond, notre mode de génération de documents multi-étapes. Un modèle planificateur lit la tâche et rédige un brief de raisonnement. Un modèle exécutant rend chaque étape planifiée par rapport à ce brief. Un modèle vérificateur juge chaque brouillon d'étape avant qu'il ne soit libéré à l'utilisateur. (Une quatrième étape résume le passage terminé ; elle ne joue aucun rôle dans cette histoire.) Les trois rôles de jugement reçoivent des entrées différentes, et cette différence est le point central de ce billet.

Notre vérificateur est délibérément aveugle. Le planificateur et l'exécutant voient tous deux le contexte complet : l'historique de la conversation, les mémoires de l'espace de travail, les fichiers de l'espace de travail, le contenu des documents téléchargés et les connaissances du cadre injectées. Le vérificateur ne voit que deux documents : le brief et le brouillon en cours d'examen. Son contrat traite les faits et jugements du brief comme établis, et son rôle est de vérifier que le brouillon est resté fidèle à ceux-ci.

Le test en laboratoire a violé cette prémisse sans s'en rendre compte. Nous avons inséré manuellement des faits fictifs dans un brief minimal, exécuté le vérificateur et compté combien de fabrications insérées il avait marquées. Il en a marqué peu ; la plupart sont passées. Nous avons qualifié le vérificateur de défectueux. Ce que l'expérience mesurait en réalité, c'était si le vérificateur remettrait en question le document qu'il est contractuellement tenu de faire confiance. Il a refusé, comme prévu dans sa conception.

Dans la même période, un passage en production a révélé ce qui ressemblait à une preuve flagrante : un fait organisationnel dans la sortie publiée qui ne figurait dans aucun des documents que nous avions vérifiés. Avant de déployer une correction, nous l'avons nous-mêmes rétractée : le fait "fabriqué" se trouvait dans un fichier téléchargé que l'exécutant avait légitimement lu. Le fait était étayé. Notre contrôle ponctuel, comme le vérificateur, n'avait simplement pas examiné ce fichier. Un enquêteur qui ne peut pas voir les sources ne peut pas non plus juger de l'étayage. Nous avions mené sur nous-mêmes la même expérience défectueuse que celle que nous avions menée sur le modèle.

Le piège mesuré

Nous nous sommes donc tournés vers le côté brouillon, là où les entrées du vérificateur diffèrent réellement. La correction intuitive : marquer tout fait dans le brouillon qui n'apparaît pas dans le brief. Nous avons construit exactement cette règle et l'avons mesurée sur des brouillons propres, des brouillons ne contenant aucune fabrication, générés par les familles de modèles que le pipeline utilisait à l'époque. La mesure et la décision de rejeter la règle sont enregistrées dans le commentaire de conception du contrat livré et dans l'historique des commits ; le travail a été réalisé et enregistré lors de la session de révision du 22 juillet 2026 :

Règle testée	Brouillons propres marqués	Brouillons générés par
Marquer les faits du brouillon absents du brief	9 sur 9	GLM 5.2
Marquer les faits du brouillon absents du brief	3 sur 9	Grok 4.20

Une porte qui rejette la plupart ou la totalité des brouillons propres n'est pas une porte ; c'est une panne. Avec GLM 5.2, chaque brouillon propre testé aurait au minimum déclenché un nouveau rendu ; ce qu'un deuxième échec de vérification aurait alors produit (un avertissement ou un arrêt) n'a pas été mesuré. Le mécanisme est structurel. Un fait dans le brouillon qui est absent du brief n'est pas une preuve de fabrication, car l'exécutant est autorisé, par conception, à étayer les faits à partir de sources que le vérificateur ne peut pas voir. Pour juger "ce fait est-il réel ?", un vérificateur aveugle aux sources n'a que ses croyances préalables, et le travail de conformité est le domaine où les croyances préalables échouent dans les deux sens : les faits réels sont spécifiques à l'espace de travail du client, et les faux sont plausibles.

Notez ce que la règle élargie ne pouvait pas non plus faire : détecter une seule des fausses informations du test d'insertion, car celles-ci vivaient dans le brief, que le contrat restreint comme l'élargi traitent comme une vérité. Par construction, l'élargissement n'a pas ajouté de rappel sur cette classe ; nos mesures sur les brouillons propres ont montré ce qu'il a ajouté à la place. C'est cette paire de résultats qui nous a convaincus que le mandat, et non le modèle, était le problème.

Le contrat qui a survécu

Ce que le vérificateur est autorisé à juger est écrit dans son prompt livré, et la frontière est nette. Par étape, il fait respecter deux contrats et rien d'autre :

1. Le contrat de l'étape elle-même : le brouillon livre ce que le titre et le cahier des charges du contenu de cette étape exigent. Un contenu manquant n'est une violation que lorsque le cahier des charges de cette étape l'exige.
2. Les jugements et citations du brief comme contraintes globales, où exactement trois choses sont des violations :
   • contradiction : une affirmation dans le brouillon qui contredit directement une puce de jugement ou le cahier des charges de l'étape,
   • citation altérée : une citation du brief reproduite de manière incorrecte (mauvaise clause, article ou formulation d'exigence),
   • citation ou exigence inventée : une citation ou exigence de cadre affirmée dans le brouillon que le brief ne contient pas.

L'absence n'est jamais une violation des contraintes globales. Le brief achemine le contenu entre les étapes ; une étape de courriel aux parties prenantes omet correctement les citations au niveau des clauses qui appartiennent à l'étape de politique. Le vérificateur ne juge pas le style, le ton, la longueur ou la qualité globale. Un brouillon simple qui est fidèle à son étape passe.

Cette forme a été imposée par la mesure, à deux reprises. D'abord, une calibration en conditions réelles le 11 juin 2026, sur la topologie de lancement dont le vérificateur était Claude Haiku 4.5 (l'ensemble de tâches de la session n'a pas été enregistré dans le journal durable ; la revendication durable est le décompte des problèmes ci-dessous) : sur 12 problèmes soulevés par le vérificateur lors d'une utilisation réelle, 2 étaient réels et 10 étaient des marquages trop littéraux sur des brouillons qui étaient en réalité fidèles. (Cette métrique compte les problèmes marqués, pas les rejets de brouillons propres.) Ensuite, les mesures 9 sur 9 et 3 sur 9 des brouillons propres mentionnées ci-dessus. Les deux mesures ont condamné le mandat élargi, chacune sur son propre axe de faux positifs ; la portée étroite est restée ciblée sur la classe d'échec qui compte.

La narrowness (étroitesse) n'est pas une faiblesse. C'est ce qui maintient la vérifiabilité de la vérification. "Ce brouillon contredit-il le brief ?" est une question dont la réponse réside entièrement dans les deux documents devant le vérificateur ; aucun fait externe n'est nécessaire pour la trancher. "Cette affirmation est-elle vraie ?" n'est pas ce type de question, et aucune ingénierie de prompt que nous avons mesurée ne la transforme en l'une ou l'autre.

Ce qui attrape les fabrications à la place

Si le vérificateur aveugle ne vérifie que la fidélité, qu'est-ce qui se trouve entre l'utilisateur et une sortie fabriquée ? Trois couches, chacune limitée à une vérification qui n'a pas besoin de faits en dehors de ses propres entrées :

Citations contre une liste fermée. Le brief porte un ensemble de citations explicite. Les instructions de l'exécutant disent : reproduire les citations du brief exactement telles qu'écrites ; ne jamais omettre, altérer ou inventer de citations de cadre. Qu'un numéro de clause appartienne à une liste finie et connue est vérifiable sans voir aucune source. Dans un domaine de conformité, ce monde fermé est la cible appropriée : la sortie dangereuse n'est pas une paraphrase, c'est une citation vers un texte que l'ensemble approuvé n'autorise pas.

Une porte d'intégrité où une source existe. Sur les passages ayant effectué des recherches web, le pipeline vérifie en plus les URL et les prix de sortie contre l'ensemble de preuves approuvé, car la vérité de référence y est disponible et finie.

Une plomberie fail-closed, avec une exception délibérée. Le verdict du vérificateur est la seule sortie machine-readable du pipeline, un objet JSON strict avec un booléen pass et une liste de problèmes qui doit être en accord avec lui. Un verdict qui ne peut pas être analysé déclenche un échec, jamais un passage. Un verdict échoué déclenche exactement un nouveau rendu avec la liste des problèmes, puis une re-vérification ; un deuxième échec libère l'étape avec un drapeau d'avertissement, après avoir été inspecté deux fois. Une panne du vérificateur ou un verdict non analysable obtient un seul nouvel essai, puis arrête le passage, et l'étape en cours n'est jamais libérée. L'exception compte et vaut la peine d'être énoncée clairement : fail-closed s'applique à l'inspection, et non à la correction. Un passage signifie que le vérificateur n'a détecté aucune violation de contrat, ce qui n'est pas une garantie de vérité de la part d'un modèle imparfait, et un brouillon marqué deux fois échoué n'a rien "passé".

La détection, en direct

Le 2 septembre 2026, nous avons exécuté une sonde à tâche unique via notre pipeline de production sur notre propre compte payant : une tâche que nous avions rédigée nous-mêmes, sans matériel client téléchargé. Le but était de prouver de bout en bout la topologie à quatre rôles testée ce jour-là, qui exécutait chaque rôle sur GLM 5.3 (effort élevé pour le planificateur, faible pour l'exécutant, le vérificateur et le récapitulatif). La tâche : rédiger un bref aperçu de registre d'actifs pour la norme ISO/IEC 27001:2022 Annexe A, sur une page.

Le brouillon de l'exécutant citait les clauses 9.2 et 9.3 de l'ISO/IEC 27001:2022, les clauses d'audit interne et de revue de direction. Les deux clauses existent dans la norme ; la citation est exactement ce vers quoi tend un document de conformité compétent. Le problème est contractuel, et non factuel : l'ensemble de citations approuvé du brief ne les contenait pas, ce qui en fait des citations inventées au sens du contrat, des citations affirmées dans le brouillon que le brief n'autorise pas. Le vérificateur a retourné un verdict d'échec en nommant le problème, l'exécutant a refait le rendu avec les citations ramenées dans l'ensemble approuvé, et la deuxième tentative a passé. Le passage s'est terminé en 155 secondes sans avertissement ni troncature, tous les appels ayant été effectués sur GLM 5.3.

Deux propriétés de cette détection comptent plus que l'anecdote. D'abord, la classe : l'échec qui s'est réellement produit en production était un dépassement de citation au-delà de l'ensemble approuvé, précisément la violation que le contrôle aveugle couvre, et non un fait inséré manuellement. Ensuite, l'ampleur du contrôle : le vérificateur a fonctionné avec un effort de raisonnement faible et n'a vu que deux documents. Lors de l'évaluation de la même semaine de la topologie (1er septembre 2026 : cinq tâches difficiles couvrant la discipline de portée, l'omission d'audience, la correction des citations, la cohérence inter-documents et la gestion des preuves non vérifiées ; trois essais par tâche par branche ; 30 passages au total sur deux branches, GLM 5.3 et une branche proxy Grok 4.20), la branche GLM 5.3 du vérificateur a retourné un verdict JSON strict analysable dans les 15 de ses passages, avec zéro arrêt. Le jugement était indépendant : Claude Haiku 4.5, exécuté via OpenRouter. La porte qui a attrapé l'échec en production est l'appel de modèle le plus restreint du pipeline.

Ce que cela ne prétend pas

La détection en production est un point de données issu d'une sonde délibérée, et non une estimation de taux. Le harnais de test d'insertion était un fichier de grattage interne que nous n'avons pas conservé ; nous défendons son résultat qualitatif (la plupart des fausses informations insérées sont passées, taux de détection approximatif d'un sur quatre à l'époque) mais ne le publions pas comme mesure précise, car les artefacts, les versions de modèles et l'ensemble de tâches derrière celui-ci n'étaient pas figés. L'enregistrement durable pour le test de la règle élargie est les mesures 9 sur 9 et 3 sur 9 des brouillons propres dans le commentaire du contrat livré, mesurées et enregistrées le 22 juillet 2026 ; l'enregistrement nomme les familles génératrices de brouillons (GLM 5.2, Grok 4.20) mais ne nomme pas le modèle vérificateur ni l'ensemble de tâches, donc nous attribuons uniquement les brouillons, et nous n'avons pas relancé le test sur d'autres familles. L'enquête rétractée de juillet sur le passage en production précède notre discipline actuelle de preuve, donc nous la décrivons sans identifiants de passage ni attribution de modèle. Le risque résiduel est réel et documenté dans le dépôt : sur les passages sans recherche web, un fait organisationnel inventé par l'exécutant, distinct d'une citation inventée, n'a toujours pas de porte automatisée, et nous n'avons pas mesuré à quelle fréquence cela se produit ; le corriger signifierait donner au vérificateur les sources, une refonte, et non une clause de prompt. Tout ce qui suit est valable à la date indiquée : contrat et code au 16 septembre 2026, sonde 2 septembre 2026, évaluation 1er septembre 2026, calibration en conditions réelles 11 juin 2026, mesure de la règle élargie 22 juillet 2026.

La liste de contrôle

Avant de faire confiance, d'élargir ou de "corriger" une porte de vérification dans votre propre pipeline d'agent :

1. Décidez ce que le vérificateur peut voir, et laissez cela décider ce qu'il peut juger. Aveugle aux sources signifie fidélité uniquement : contradictions, citations altérées, citations inventées.
2. L'absence d'une référence que le producteur peut légitimement dépasser n'est jamais une violation. Si vous ne pouvez pas prouver que le fait était fabriqué plutôt qu'étayé dans une source que vous n'avez pas transmise, ne le marquez pas.
3. Rendez l'honnêteté mécanique partout où votre domaine le permet. Citations contre une liste fermée, URL et prix contre un ensemble de preuves approuvé : ceux-ci sont vérifiables à partir des entrées. La vérité ouverte ne l'est pas.
4. Calibrez sur des brouillons réels avant de faire confiance à la porte. Mesurez votre part de faux positifs avant d'élargir le contrat ; la nôtre était de 10 sur 12 problèmes en utilisation réelle (11 juin 2026). Concevez le contrat pour que l'absence ne soit pas une violation.
5. Un verdict qui ne peut pas être analysé doit arrêter l'étape, jamais la faire passer. Conservez un seul verdict machine-readable et faites en sorte que le booléen pass soit en accord avec la liste des problèmes.
6. Un nouveau rendu sur un verdict échoué, puis une re-vérification. Libérez une étape marquée deux fois échouée uniquement avec un drapeau d'avertissement, après deux inspections. Ne libérez jamais de contenu non inspecté sur un chemin, y compris les pannes du vérificateur. Un passage signifie qu'aucune violation de contrat n'a été détectée, et non que le contenu est vrai.
7. Testez avec la classe d'échec que votre domaine produit réellement (pour nous, des citations dépassant l'ensemble approuvé), et non avec la classe la plus facile à simuler (des faits insérés manuellement). Et faites attention à où vous les insérez : un faux écrit dans le document de vérité de base du vérificateur ne teste rien concernant la fabrication.
8. Lorsque votre propre enquête sur une fabrication suspectée dépend d'entrées que vous n'avez pas vérifiées, vous êtes le vérificateur aveugle. Rétractez d'abord, mesurez ensuite.

Un vérificateur qui voit moins n'est pas une porte plus faible. Ses verdicts restent vérifiables, car il juge le seul contrat que le producteur a effectivement reçu.