J'utilise des agents de code tous les jours et il y a une phrase que je crois de moins en moins : « done ».

Pas parce que les modèles mentent volontairement. Le problème est plus bête. L'agent qui vient d'écrire le code est souvent aussi celui à qui l'on demande si le code est bon. On transforme l'auteur en contrôleur qualité, puis on s'étonne que son rapport ressemble beaucoup à sa propre version des faits.

Tom Rochette appelle ça l'« acceptance gap » : produire une solution et pouvoir décider qu'elle mérite d'être acceptée sont deux tâches différentes.

Cette distinction devient franchement utile dès qu'on délègue plus qu'une fonction de vingt lignes.

« Ça marche » a besoin d'un témoin extérieur

Quand un humain confie un bug à un agent, le scénario paresseux ressemble à ça : voici le problème, corrige-le, lance les tests, dis-moi quand c'est fini.

L'agent modifie le dépôt, exécute quelques commandes et revient avec un résumé impeccable. Tests verts. Fichiers modifiés. Petite phrase rassurante sur la compatibilité. Tout est à sa place, y compris la confiance qu'on n'a jamais vraiment vérifiée.

Le problème n'est pas le résumé. C'est l'absence d'un critère indépendant.

Rochette insiste sur une séparation assez ancienne en ingénierie : la vérification demande si l'on a construit correctement ce qui était spécifié ; la validation demande si la spécification correspondait au bon problème.

Un agent peut participer très efficacement à la première. Tests, analyse statique, scénarios, mutation testing, critiques spécialisées : on peut accumuler des preuves autour d'un changement.

La deuxième reste beaucoup plus humaine. Est-ce ce que je voulais ? Est-ce acceptable dans ce produit ? Est-ce que ce comportement étrange est un bug ou une décision ? Aucun npm test ne connaît ton intention secrète. C'est contrariant, les ordinateurs refusent toujours de lire dans nos pensées après plusieurs décennies de marketing promettant l'inverse.

Le prompt n'est pas encore une preuve

L'idée qui m'intéresse ici va un peu plus loin que « écrivez de meilleurs tests ».

Pour un bug, il faut préparer la manière dont on vérifiera le résultat avant, ou au moins en même temps que la correction.

Un test peut échouer avant le patch et passer après. Une migration peut produire un comptage avant/après et une vérification d'intégrité. Une commande d'infrastructure peut donner son état final observé. Un agent de recherche peut rapporter les sources exactes qui soutiennent chaque point important.

Autrement dit, le livrable d'un travail vérifiable n'est pas seulement « la chose ». C'est la chose plus de quoi la contredire.

Pour une feature, Rochette pose une limite différente. On peut tester qu'un bouton fonctionne, pas écrire à l'avance un test exhaustif pour « ce bouton est au bon endroit, avec le bon poids visuel, et maintenant j'ai envie de shipper ». Une partie du besoin apparaît seulement quand on voit et qu'on utilise le résultat.

Là, la bonne infrastructure n'est pas une montagne de critères d'acceptation. C'est une boucle courte : générer, essayer, réagir, recommencer. Le jugement final reste humain parce que le signal mesuré est justement cette réaction.

Ça semble évident quand on l'écrit. Dans les workflows agentiques, c'est pourtant facile de mélanger les deux. On demande des tests pour régler un problème de goût, puis on relit à la main un bug qu'un check aurait pu trancher en une seconde. Très sophistiqué comme manière de perdre du temps.

Plus l'agent est autonome, moins son récit m'intéresse

Il y a une conséquence un peu contre-intuitive.

Quand un agent fait trois actions simples devant moi, son explication peut suffire à suivre ce qui s'est passé. Quand il travaille vingt minutes dans un dépôt, appelle d'autres agents, lance quinze commandes et modifie douze fichiers, son compte rendu devient moins intéressant au moment même où il devient plus joli.

Je ne veux plus seulement le récit de ce qu'il pense avoir fait. Je veux les artefacts qui me permettent de le contredire.

Le diff. Les tests. La sortie de la commande. La capture. Le lien vers la source. La liste des limites restantes. Quelque chose qui existe hors de la phrase « j'ai vérifié ».

Rochette pousse cette logique assez loin sur le code review : déplacer une partie de la confiance du fait de lire chaque ligne vers un système de vérification composé de plusieurs contrôles explicites. C'est une proposition plus radicale, et elle mérite ses propres objections. Un test peut être mauvais. Une spécification peut être fausse. Une batterie de checks peut simplement automatiser notre angle mort avec une efficacité industrielle admirable.

Mais ça renforce plutôt l'idée de départ : une preuve n'est utile que si elle est indépendante de ce qu'elle est censée prouver.

Le travail humain remonte d'un étage

À force d'utiliser des agents, j'ai de moins en moins l'impression que mon boulot consiste à leur expliquer comment coder.

Il consiste davantage à définir quel type de fin j'attends.

Pour un bug, je veux une preuve indépendante. Pour une feature, je veux pouvoir voir et essayer le résultat assez vite pour former mon propre jugement. Ce n'est pas la même boucle, donc demander le même « rapport de fin » aux deux est déjà une petite erreur de conception.

C'est moins spectaculaire qu'un agent qui avale une issue GitHub et recrache une PR. C'est aussi beaucoup plus dur à automatiser, parce que ça oblige à connaître le produit, les risques et ce qu'on est réellement en train de déléguer.

Pour une typo dans une doc, un build vert suffit probablement. Pour une migration qui peut supprimer des données, j'ai soudain beaucoup plus d'imagination concernant les preuves nécessaires. Pour une interface, je préfère souvent dix secondes de preview à trois paragraphes où l'agent m'explique que l'expérience est désormais « intuitive ».

L'autonomie utile ne commence donc peut-être pas quand l'agent sait faire plus de choses seul. Elle commence quand son retour me donne le bon moyen de décider : vérifier quand c'est vérifiable, essayer quand ça relève du goût.