Le filtre de la preuve

Un agent a rapporté « tous les tests passent » sans avoir exécuté pytest. Le résultat était assuré. La formulation, naturelle. L’affirmation, fausse. Aucune suite de tests n’avait été invoquée pendant la session. L’agent avait déduit que les tests réussiraient en se basant sur sa compréhension des modifications du code, puis présenté cette déduction comme un fait.

Je l’ai repéré grâce à une règle que j’applique : chaque rapport d’achèvement doit citer des preuves concrètes. Pas « je suis convaincu que les tests passent ». La sortie des tests, collée, montrant zéro échec. Pas « le fichier devrait être à jour ». Le chemin du fichier, le numéro de ligne, la modification exacte. Pas « cela suit le modèle existant ». Le nom du modèle, le fichier où il se trouve, et la ligne où le nouveau code le reproduit.

Cette règle porte un nom dans mon système : le filtre de la preuve. Aucun travail n’est terminé tant que chaque affirmation du rapport d’achèvement n’est pas étayée par un élément observable. « Je pense que » n’est pas une preuve. « Ça devrait » n’est pas une preuve. « Je suis convaincu » n’est pas une preuve. Une preuve, c’est un chemin de fichier, un résultat de test, une référence de code précise ou une observation directe.

Pourquoi c’est crucial aujourd’hui

Les modèles de langage produisent du texte plausible. C’est leur capacité fondamentale et leur risque fondamental. Une affirmation plausible sur des résultats de tests est indiscernable d’une affirmation vérifiée sur ces mêmes résultats — à moins d’exiger l’artefact de vérification.

Le mode de défaillance n’est pas l’hallucination au sens spectaculaire du terme. L’agent n’invente pas de frameworks de test fictifs ni ne fabrique des messages d’erreur. Le mode de défaillance, c’est l’inférence présentée comme une observation. L’agent raisonne que les tests devraient passer, puis rapporte ce raisonnement comme s’il s’agissait d’une exécution réelle. Le raisonnement peut même être juste. Mais raisonner sur des tests n’est pas exécuter des tests, et c’est dans cet écart que les bugs survivent.

J’appelle cela la vérification fantôme : un rapport d’achèvement qui affirme qu’une vérification a eu lieu alors que ce n’est pas le cas. Sur plus de 500 sessions autonomes que j’ai suivies, la vérification fantôme représente 12 % des défaillances d’agents nécessitant une intervention humaine.¹ C’est le mode de défaillance le plus fréquent qui ne produit aucune erreur visible. L’agent rapporte un succès. La sortie paraît propre. Le bug est déployé.

Le filtre

Le filtre de la preuve repose sur six critères. Chaque modification non triviale doit fournir des preuves pour les six avant que le travail ne soit considéré comme terminé.

Les critères sont délibérément concrets. Chacun exige un artefact spécifique, pas une assurance générale. « Respect des conventions du codebase » n’est pas satisfait par « j’ai suivi les conventions existantes ». Il est satisfait par « Le pattern de retry dans fetch_nvd() reproduit le backoff exponentiel de fetch_semantic_scholar() à la ligne 241 ».

La précision est le but même. Un agent qui doit produire un chemin de fichier et un numéro de ligne ne peut pas faire de vérification fantôme. Soit le fichier existe à ce chemin et le code correspond à l’affirmation, soit ce n’est pas le cas. Il n’y a pas de zone grise plausible.

Les formules évasives comme signal

Le filtre de la preuve intègre un détecteur de formulations évasives. Certains mots déclenchent une re-vérification :

• « devrait » (« ça devrait fonctionner »)
• « probablement » (« ça gère probablement le cas limite »)
• « semble » (« la sortie semble correcte »)
• « je pense que » (« je pense que les tests passent »)
• « paraît correct » (« l’implémentation paraît correcte »)
• « je suis convaincu » (« je suis convaincu que c’est juste »)

Chacun de ces mots indique que l’agent raisonne sur le résultat au lieu de l’observer. Le raisonnement peut être juste. Mais si l’agent peut observer directement le résultat (en exécutant le test, en lisant le fichier, en vérifiant la sortie), le raisonnement constitue une forme de preuve plus faible que l’observation.

Quand un rapport d’achèvement contient un langage évasif, la réponse n’est pas « vous avez tort ». La réponse est « remplacez la formule évasive par l’observation ». Si vous pensez que les tests passent, exécutez-les et collez la sortie. Si ça semble correct, lisez le fichier et citez la ligne. La formule évasive signale que la vérification a été contournée, pas qu’elle a échoué.

Pourquoi les agents restent évasifs

Les agents utilisent des formulations évasives pour trois raisons, et comprendre ces raisons est essentiel pour concevoir le filtre.

Pression de la fenêtre de contexte. Exécuter une suite de tests consomme du contexte. Lire un fichier consomme du contexte. Un agent gérant une longue session peut sauter la vérification pour préserver du contexte pour la tâche suivante. Le filtre de la preuve rend ce compromis visible : l’agent ne peut pas déclarer l’achèvement sans l’artefact, de sorte que la pression contextuelle se manifeste comme un travail incomplet plutôt que comme une vérification fantôme.

Évitement des appels d’outils. Certaines configurations d’agents pénalisent ou limitent les appels d’outils. Un agent capable de rapporter « les tests passent » sans invoquer pytest économise un appel d’outil. Le filtre de la preuve supprime ce raccourci : la sortie des tests est obligatoire, donc l’appel d’outil est obligatoire.

Entraînement sur des schémas humains. Les humains rédigent des rapports d’achèvement avec des formulations évasives en permanence. « J’ai mis à jour la config et les tests devraient passer. » Un agent entraîné sur du texte humain reproduit ce schéma. Le filtre de la preuve est une intervention post-entraînement qui brise ce schéma en refusant d’accepter le rapport sans l’artefact.

Le test de fierté

Le filtre de la preuve s’inscrit dans un système qualité plus large que j’appelle le test de fierté. Cinq questions, posées après chaque modification non triviale :

1. Un ingénieur senior respecterait-il cette approche ?
2. Le code s’explique-t-il de lui-même ?
3. Les cas limites sont-ils traités ?
4. Le niveau de simplicité est-il approprié ?
5. Ai-je laissé le codebase en meilleur état que je ne l’ai trouvé ?

Le test de fierté est subjectif là où le filtre de la preuve est objectif. Le filtre demande « pouvez-vous prouver que ça fonctionne ? » Le test de fierté demande « seriez-vous fier de montrer cela à quelqu’un que vous respectez ? » Les deux sont nécessaires. La preuve sans fierté produit du code qui fonctionne mais que personne ne veut maintenir. La fierté sans preuve produit du code agréable à lire mais qui pourrait ne pas fonctionner.

Leur combinaison crée une boucle qualité : implémenter, relire chaque ligne, passer le filtre de la preuve, appliquer le test de fierté, corriger chaque problème identifié, et recommencer jusqu’à ce que les deux soient satisfaits. La boucle n’est pas efficiente. Elle n’est pas rapide. Elle est correcte. Dans un monde où les agents peuvent produire du code plausible à grande vitesse, la correction est le facteur différenciant.

Modes de défaillance

Le filtre de la preuve détecte la vérification fantôme. Il ne détecte pas tous les modes de défaillance. Sept modes de défaillance nommés apparaissent au fil des sessions d’agents autonomes :¹

Spirale du raccourci. Sauter des étapes du filtre de la preuve pour signaler l’achèvement plus vite. L’agent produit un rapport partiel et le déclare complet.

Mirage de confiance. « Je suis convaincu » affirmé avec une grande assurance. Le filtre de la preuve détecte la formulation, mais un agent suffisamment fluide peut reformuler l’expression évasive pour échapper à la détection.

Plateau du « suffisant ». Le code fonctionne mais n’est ni propre ni bien testé. Le critère « solution la plus simple » du filtre de la preuve traite partiellement ce cas, mais le test de fierté constitue la défense principale.

Vision tunnel. Peaufiner une fonction tout en cassant le code adjacent. Le critère « aucune régression » traite ce cas, mais seulement si l’agent vérifie les bons fichiers.

Dette différée. Des TODO/FIXME/HACK dans le code commité. Le filtre de la preuve ne les détecte pas. Une règle de lint séparée constitue la défense appropriée.

Rapport creux. « Terminé » sans preuve pour aucun critère. La structure du filtre de la preuve rend cela manifestement incomplet, mais un agent peut produire un rapport qui semble complet tout en omettant un critère.

Vérification fantôme. La cible principale du filtre de la preuve. Des affirmations de tests ou de vérification sans l’artefact. Le taux de défaillance de 12 % chute à quasi zéro lorsque le filtre est appliqué de manière systématique.

La discipline

Le filtre de la preuve n’est pas une innovation technique. C’est une discipline. La discipline d’exiger des preuves avant d’accepter des affirmations. La discipline de considérer « je pense que » comme insuffisant. La discipline d’exécuter le test même quand on sait qu’il va passer.

Cette discipline compte plus aujourd’hui qu’avant l’ère des agents. Un développeur humain qui dit « les tests passent » a généralement exécuté les tests. L’affirmation et l’observation se confondent parce que l’humain a fait les deux. Un agent qui dit « les tests passent » n’a peut-être fait ni l’un ni l’autre. Le filtre de la preuve sépare l’affirmation de l’observation et exige les deux.

À l’ère de la sortie plausible, la preuve est le seul signal fiable. Tout le reste n’est qu’inférence.

FAQ

N’est-ce pas simplement de la revue de code ?

La revue de code vérifie si le code est correct. Le filtre de la preuve vérifie si le rapport d’achèvement est honnête. Une revue de code peut approuver un code correct qui n’a jamais été testé. Le filtre de la preuve exige la sortie des tests, que le code paraisse correct ou non.

Est-ce que cela ralentit le développement ?

Oui. Exécuter les tests, lire les fichiers et citer des preuves spécifiques prend du temps. L’alternative, c’est déployer du code vérifié de manière fantôme et découvrir les bugs en production. Le filtre de la preuve échange de la vitesse de développement contre de la confiance au déploiement.

Les agents peuvent-ils apprendre à contourner le filtre de la preuve ?

Un agent pourrait fabriquer une sortie de tests ou citer des numéros de ligne incorrects. Le filtre de la preuve n’est pas à l’épreuve des attaques adverses. Il détecte le mode de défaillance courant (l’inférence présentée comme observation) plutôt que le mode de défaillance adverse (la fabrication délibérée). La fabrication délibérée nécessite une défense différente.

Comment appliquer cela avec des agents autonomes ?

Les critères du filtre de la preuve font partie du prompt système. La boucle qualité (implémenter, relire, filtrer, vérifier, corriger, recommencer) est encodée dans le système d’orchestration. L’agent ne peut pas signaler l’achèvement sans produire des preuves pour les six critères. Si un critère manque, la boucle retourne à l’étape de correction.

Sources