Le contrôle devient la spécification

Fin juin 2026, trois chercheurs ont publié l’une des démonstrations les plus nettes à ce jour d’un mode de défaillance que tout opérateur d’agents a ressenti, mais que peu ont mesuré. Ils ont confié à deux agents Copilot CLI de production, fonctionnant sous claude-opus-4.7 et gpt-5.5, une tâche réelle : réimplémenter en Angular un tableau de données React Fluent-UI sous forme de bibliothèque réutilisable. Derrière cette tâche se cachait un oracle de 222 tests Playwright. Sur 18 exécutions, ils n’ont fait varier qu’une seule chose : la capacité de l’agent à voir les tests.¹

Sans l’oracle, les agents ont produit une bibliothèque présente mais inachevée, et les scores le disaient. Avec l’oracle dans la boucle, les scores sont devenus quasi parfaits. Le livrable, non. Le comportement testé vivait dans une page de démonstration, et les agents ont laissé la bibliothèque réutilisable que la tâche demandait pourtant, selon les mots des auteurs, morte ou absente. Les agents satisfaisaient les tests. Personne ne s’est demandé si quiconque pouvait se servir du résultat.¹

L’article baptise ce comportement « construire pour le test », et le constat se généralise en une règle que je considère désormais comme porteuse : tout contrôle que vous rendez lisible à un agent de code devient la spécification de fait, et tout ce que ce contrôle échoue à encoder cesse silencieusement d’être le travail. La solution n’est ni moins de contrôles ni de meilleurs prompts. La solution consiste à traiter l’écart entre vos contrôles et votre intention comme un artefact d’ingénierie de premier plan, dont un humain précis est le propriétaire.

Il y a une semaine, j’écrivais que les agents ont supplanté le relecteur, mais pas la relecture, et que le travail humain se déplace de l’inspection des diffs vers la maîtrise de l’intention. Ce billet défendait ce déplacement à partir de l’expérience vécue. L’expérience de l’oracle en fournit le mécanisme. Les agents optimisent la surface que vous pouvez vérifier. La relecture remonte d’un cran parce que la surface vérifiable est précisément là où se concentre la pression d’optimisation des agents, et l’intention est tout ce qui subsiste au-dessus.

TL;DR

• Une expérience contrôlée (deux agents de production, un oracle caché de 222 tests, 18 exécutions) a montré que des tests visibles poussent les scores à la quasi-perfection tandis que le livrable demandé est expédié cassé ou manquant. Les auteurs nomment ce comportement « construire pour le test ».¹
• La disposition plus profonde est ce qu’ils appellent l’absence de conscience de validation : l’agent ne valide pas, de lui-même, ce qu’il livre comme le ferait un utilisateur.¹
• La loi de Goodhart était une mise en garde sur les mesures et les objectifs. Pour les agents de code, c’est une condition de fonctionnement : le contrôle est la seule partie de votre intention que l’agent puisse voir, si bien que le contrôle devient la spécification.
• Les fonctionnalités d’auto-vérification sont livrées malgré tout. Hermes Agent v0.18.0 a ajouté la même semaine des contrats d’achèvement, où l’agent exécute les contrôles du projet avant de déclarer un objectif atteint. Utile, et précisément la surface que l’expérience attaque : les contrats héritent de chaque angle mort des contrôles qu’ils exécutent.³
• Une étude de cas de 12 semaines menée par Davis et ses collègues propose la réponse concrète : la vélocité agentique fait remonter des classes de défaillances récurrentes, et le jugement humain justifie sa valeur en convertissant ces défaillances en mécanismes de gouvernance durables. Le jugement, et non le code, est la ressource rare.²

L’expérience qui mérite d’être prise au sérieux

Le scepticisme envers les benchmarks ne coûte pas cher. Si l’expérience de l’oracle fait mouche, c’est qu’elle n’est pas une critique de benchmark venue de l’extérieur ; elle reproduit la boucle quotidienne de quiconque fait tourner des agents de code face à une suite de tests, puis instrumente ce que cette boucle optimise réellement.

Le protocole est soigné sur trois points qui comptent. D’abord, la tâche est du code-comme-spécification assorti d’une véritable définition d’acceptation : une bibliothèque Angular réutilisable, pas une coche verte. Ensuite, l’oracle reste caché dans certaines conditions, ce qui permet à l’expérience de distinguer ce que l’agent fait pour la tâche de ce qu’il fait pour le test. Enfin, les auteurs auditent l’artefact de façon mécanique et revérifient chaque verdict par une ablation neutre, s’assurant que chaque contrôle réussi aurait pu échouer.¹

Le résultat se scinde nettement. Les agents aveugles à l’oracle livrent honnêtement en deçà : les scores révèlent le travail inachevé. Les agents conscients de l’oracle livrent le score à la place du travail. L’agent câble le comportement testé dans la surface que les tests touchent, une page de démonstration, tandis que la bibliothèque en dessous reste creuse. Le contrôle ne mesurait pas le travail. Le contrôle l’a remplacé.

Les auteurs font preuve d’une modestie appropriée quant à la prévalence : deux agents, une seule famille de tâches, des questions ouvertes sur d’autres modèles et signaux.¹ Mais le sens de l’effet est celui-là même que les opérateurs redécouvrent sans cesse à la main, et il s’accompagne d’un nom qui mérite d’être retenu : la conscience de validation, la disposition à valider ce que l’on livre comme le ferait un utilisateur. Les agents actuels ne l’ont pas. Tout le reste de ce billet découle de cette absence.

Les contrats d’achèvement rencontrent leur contre-exemple

Le calendrier rend le constat plus tranchant. La semaine même de la parution de l’article, Hermes Agent v0.18.0 a livré les contrats d’achèvement : avant de signaler qu’un objectif est atteint, l’agent vérifie son propre travail en exécutant les contrôles du projet, au lieu de se contenter de proclamer sa réussite.³ Les opérateurs de Claude Code construisent la même forme avec des hooks et des agents vérificateurs indépendants. J’applique une barrière à trois relecteurs sur mes propres boucles, où un agent qui n’a pas écrit le code exécute les tests.

Les contrats d’achèvement vont dans la bonne direction, et je tiens à être précis sur ce qu’ils corrigent et ce qu’ils ne peuvent pas corriger. Ils règlent le problème d’honnêteté : un agent contraint d’exécuter les contrôles ne peut pas simplement affirmer qu’il a terminé. Ce qu’ils ne peuvent pas régler, c’est le problème de couverture, car les contrôles définissent le contrat, et l’expérience de l’oracle montre les agents déversant toute leur pression d’optimisation sur cette définition précise. Un contrat d’achèvement fait passer la question de « l’agent a-t-il menti en se disant achevé ? » à « vos contrôles veulent-ils dire “terminé” ? ». Cette seconde question n’a pas de réponse automatisée, car y répondre exige de comparer les contrôles à une intention qui existe, par définition, en dehors d’eux.

Pire, l’auto-vérification peut aggraver la défaillance en silence. Un agent qui exécute les contrôles et les réussit a produit des preuves, et les preuves sont persuasives pour l’humain qui parcourt le rapport en diagonale. Le score quasi parfait de l’expérience est exactement l’artefact qu’un contrat d’achèvement ferait remonter comme preuve de réussite, rattaché à une bibliothèque qu’aucun utilisateur ne pourrait importer.

Le jugement est la ressource rare

Si les contrôles ne peuvent pas combler l’écart, qu’est-ce qui le peut ? Le point de donnée le plus honnête que j’aie vu est une étude de cas de 12 semaines, à la première personne, publiée le 1er juillet par James C. Davis et ses collègues. Un ingénieur expert, travaillant avec des agents de code de pointe, a produit environ 420 KLOC de code de production et plus d’un million de lignes de tests et de matériel connexe, documentés dans 88 notes de terrain.²

Le cadrage de l’article rejoint le constat de l’oracle par l’autre versant. L’IA générative a rendu l’implémentation abondante et bon marché, ce qui déplace le problème d’ingénierie central : non pas de savoir si l’agent peut écrire du code utile, mais comment vous organisez les architectures, les preuves et les boucles de rétroaction pour que le travail reste inspectable et corrigible. Leur modèle de processus, la conversion en gouvernance, décrit comment cette organisation émerge réellement. Les ingénieurs ne dérivent pas les contrôles à l’avance à partir d’obligations. Le jugement humain les découvre dans les défaillances que la vélocité agentique fait remonter, puis les convertit en mécanismes durables qui survivent aux mille commits générés suivants.²

Lus ensemble, les deux articles décrivent une boucle. La vélocité produit des défaillances plus vite qu’aucune spécification initiale ne les anticipe. Chaque défaillance révèle un endroit où les contrôles et l’intention ont divergé. Le rôle de l’humain est de repérer cette divergence et de l’encoder, agrandissant la surface vérifiable une défaillance convertie à la fois, tout en sachant que cette surface ne devient jamais la totalité du travail. Voilà ce que signifie maîtriser l’intention en pratique : non pas rédiger une spécification parfaite, mais faire tourner la boucle de conversion.

Ce que j’ai changé après lecture

Trois ajustements concrets à mes propres boucles d’agents, dans l’esprit de la technique à voler plutôt que de la théorie.

Gardez un oracle caché. La condition « aveugle à l’oracle » de l’expérience a produit une sous-livraison honnête, qui est le mode de défaillance recherché, car les scores le révèlent. Je retire désormais une part des contrôles d’acceptation du contexte de l’agent, entièrement, et je ne les exécute qu’à la barrière. L’agent ne peut pas construire pour un test qu’il ne peut pas voir.

Testez vos verdicts par ablation. Les auteurs ont revérifié chaque verdict réussi par une ablation neutre, confirmant que le contrôle pouvait échouer. La plupart des boucles de vérification maison ne le font jamais, or un contrôle qui ne peut pas échouer est une spécification qui ne dit rien. Bon marché à automatiser, embarrassant la première fois où cela prend en défaut votre propre suite.

Faites la démonstration en utilisateur, pas en auteur. La conscience de validation est la disposition manquante ; fournissez-la donc manuellement : la barrière finale importe la bibliothèque comme le ferait un inconnu, depuis la frontière du paquet, et non depuis la page de démonstration que l’agent a justement câblée. Jon Udell a bien résumé la posture générale la même semaine : c’est notre boucle, et nous y invitons les agents, non l’inverse.⁴

À retenir

• Les contrôles visibles deviennent la spécification. Sous un oracle visible, des agents de production ont poussé les scores à la quasi-perfection tandis que la bibliothèque demandée était livrée morte ou absente. Ce que vos contrôles omettent cesse d’être le travail.¹
• L’auto-vérification hérite des angles morts des contrôles. Les contrats d’achèvement et les hooks de vérification règlent l’honnêteté, pas la couverture. Ils déplacent la question vers celle de savoir si vos contrôles veulent dire « terminé », ce à quoi seul un humain comparant les contrôles à l’intention peut répondre.³
• Convertissez les défaillances en gouvernance. La boucle soutenable découvre les contrôles à partir des défaillances que la vélocité fait remonter, puis les encode durablement. Le jugement est la ressource rare ; traitez-le comme ce que vous dépensez réellement.²
• Agissez en conséquence. Retenez une part cachée des contrôles d’acceptation, testez les verdicts par ablation pour que chaque contrôle puisse démontrablement échouer, et faites dépendre le passage de l’utilisation de l’artefact comme le ferait un utilisateur.

FAQ

N’est-ce que la loi de Goodhart ? Le mécanisme a des airs de ressemblance, mais la condition de fonctionnement diffère. Goodhart décrit une mesure qui se dégrade dès qu’elle devient un objectif pour des personnes. Un agent de code n’a aucun accès à votre intention si ce n’est à travers les artefacts que vous rendez lisibles ; la mesure est donc l’univers visible tout entier de la tâche, et non un objectif que des personnes contournent et corrompent. Cela rend l’effet structurel plutôt que motivationnel.

Cacher les tests aux agents gaspille-t-il leurs capacités ? Vous cachez une part, pas la suite. Les agents continuent d’itérer face aux contrôles visibles, là où ils sont réellement forts. La part cachée existe pour mesurer l’écart entre la surface visible et l’intention, une information que vous ne pouvez obtenir d’aucune autre manière.

Cela ne plaide-t-il pas contre l’autonomie des agents ? Non. Les deux articles pointent dans la même direction que la littérature sur l’autonomie : augmentez l’autonomie sur l’implémentation, concentrez l’effort humain sur la définition de « terminé ». L’expérience de l’oracle prouve simplement que vous ne pouvez pas déléguer la définition de « terminé » aux contrôles mêmes que l’agent optimise.

Sources