Demandez ce que le check vert a prouvé

Quand un check passe au vert, demandez ce qu’il a prouvé. Puis demandez ce qu’il n’a pas prouvé. C’est le conseil que je retiens du nouvel article d’Addy Osmani sur l’esprit critique quand les agents font le travail.

Ça me concerne directement : mes agents de code mergent et déploient maintenant leurs propres pull requests. L’article est sorti cinq jours après que je leur ai confié cette dernière étape. Pendant cette première semaine, 557 pull requests ont été mergées sur mon compte GitHub. J’ai donc confronté sa checklist à mon organisation. Elle a tenu là où j’avais défini « vérifié » avant le travail, et cédé là où j’ai fait confiance à un check vert au-delà de ce qu’il vérifiait.

Addy travaille sur Claude Code chez Anthropic, et il aime les agents. Il le dit d’entrée : ce n’est pas un appel à en utiliser moins. Lire l’article sur X, publié le 3 novembre.

C’est ma troisième note sur la revue de code. La première : relisez le plan, pas la pull request. La deuxième : comment l’équipe Claude Code relit le code qu’écrit Claude, un article coécrit par Addy.

La lente glissade vers « ça a l’air bon »

Voilà le piège. Les réponses des agents ont l’air justes la plupart du temps. Elles sont bien écrites, en grande partie correctes, et ne réclament pas de seconde lecture. Vous pouvez lancer dix agents à la fois, mais vous n’avez toujours qu’une paire d’yeux.

Addy décrit trois niveaux de confiance envers un agent :

1. Déléguer. Vous confiez la tâche, mais le résultat reste le vôtre.
2. S’en remettre. La réponse devient votre étape suivante. Vous ne la traitez plus comme une hypothèse à tester.
3. Capituler. La réponse devient discrètement la vôtre, et vous arrêtez de la vérifier. « Capitulation cognitive » (cognitive surrender) est un terme de Steven Shaw et Gideon Nave, deux chercheurs de Wharton.

Personne n’y arrive d’un seul coup. Vous lisez une réponse avec attention. Elle était bonne, alors vous survolez la suivante. De la troisième, vous ne regardez que les grandes lignes. Puis quelqu’un montre une ligne du doigt et demande pourquoi elle est là. Vous ne savez pas, même avec l’aide de votre agent.

C’est son test : si vous ne savez pas expliquer la réponse, même avec votre agent, elle n’est plus à vous. Parfois, ça va. Addy a laissé une IA choisir entre trois hôtels équivalents pour enregistrer un cours, et il le referait. Il ne le ferait pas pour de l’argent, pour la carrière de ses enfants, ni pour décider si du code peut partir en production.

Quatre-vingts pull requests par jour

Jusqu’en octobre, chaque changement finissait chez moi. Ma page Comment je travaille avec l’IA le dit encore : « une pull request que je lis et que je merge ». Cette phrase n’est plus vraie.

Ça a changé en deux temps. Le 8 octobre, huit pull requests attendaient depuis des jours dans le dépôt qui contient la configuration de mes agents. Deux étaient empilées, l’une construite sur l’autre. J’ai donc dit à chaque agent : mergez et nettoyez les pull requests que vous ouvrez. Le 29 octobre, j’ai retiré les dernières exceptions, dont mon appli de finances, mes applis de santé et ce site. Et j’ai ajouté une étape de plus : le déploiement.

La règle est écrite dans CLAUDE.md, le fichier que mes agents de code lisent au démarrage d’une session. Une fois le changement vérifié et la pull request déclarée mergeable par GitHub, l’agent la merge et la déploie. Puis il vérifie l’appli en ligne et fait le ménage derrière lui. Ça reste ainsi jusqu’à ce que je dise le contraire.

Le même paragraphe fixe le sens de « vérifié » : les tests, la CI (les vérifications que GitHub lance à chaque changement) et un vrai navigateur pour tout ce qui a un écran. C’est le conseil d’Addy : décidez ce que « vérifié » veut dire avant de commencer, parce qu’après coup, vous trouverez toujours une raison d’accepter le résultat. Ma définition existait avant le premier merge d’un agent. Aucun agent ne décide donc après coup de ce qui compte comme fini.

Et le volume, c’est exactement son sujet. Du 29 octobre au 4 novembre, 557 pull requests ont été mergées dans 65 dépôts de mon compte GitHub. Environ 80 par jour. Personne ne lit 80 pull requests par jour, et la règle ne me le demande pas.

Un check vert prouve une seule chose

L’avertissement d’Addy : on peut lâcher les preuves sans s’en rendre compte. « Y a-t-il des preuves qui soutiennent ma conclusion ? » devient en silence « est-ce que le check est passé au vert ? ». Les agents rendent les tests bon marché, alors il y a du vert partout. Mais un test écrit avec la même erreur que le code passe quand même. Et un check couvre une seule chose, même quand on a l’impression qu’il couvre tout.

Sa ligne d’arrivée, c’est une preuve qu’on peut montrer : un test qui passe, une capture d’écran, un log, une trace. Quand un agent dit « fini », il lit d’abord la commande lancée et ce qu’elle a renvoyé. Le résumé de l’agent vient en dernier.

Trois fois dans mon organisation, quelque chose est passé et a prouvé moins qu’il n’y paraissait :

• La feuille de style. En septembre, une note de ce site est partie en ligne avec ses schémas sans style. L’agent avait vérifié le CSS avec un anti-cache, un petit ajout dans l’URL qui contourne le cache. L’agent a donc eu le nouveau fichier, mais les navigateurs des lecteurs avaient toujours l’ancien. Le check prouvait que le serveur avait le nouveau CSS. Il ne prouvait pas que quelqu’un le verrait.
• La page blanche. Un script a écrit une page dans mon appli de notes, un remplaçant de OneNote que j’héberge moi-même. Puis il l’a relue par l’API, et les deux correspondaient. Mais dans l’appli, la page était blanche : un nœud de texte vide dans une cellule de tableau faisait refuser toute la page à l’éditeur. Le check prouvait que le serveur avait stocké la page, pas qu’elle s’ouvre.
• La sauvegarde quotidienne. La même appli enregistre une copie de sa base chaque jour et garde les 14 dernières. La tâche tourne sans erreur. Mais le nettoyage compte aussi 14 anciennes sauvegardes ponctuelles dont le nom de fichier commence pareil. Il supprime donc chaque nouvelle copie juste après l’avoir écrite. Chaque étape fait son travail, et il n’y a pas de sauvegarde quotidienne. Au moment où j’écris, le bug est toujours ouvert.

Chaque erreur devient une règle

C’est là que mon organisation fait ce que demande Addy. Quand quelque chose n’est pas à la hauteur, dit-il, notez pourquoi « dans une config partagée, un hook ou un test, pour que ça ne se reproduise pas. C’est comme ça que le goût s’accumule. »

Un hook, c’est un tout petit script qui tourne avant la commande d’un agent et qui peut dire non. La plupart des règles de mes agents sont nées d’une erreur :

• Docker, arrêté deux fois. Sur macOS, pkill lit toute option écrite après le premier motif comme un motif de plus. Un agent a écrit ses options en dernier. Elles ont touché Docker Desktop et arrêté tous les conteneurs, le 13 octobre puis de nouveau le 22. Depuis le 25 octobre, un hook refuse cet ordre et affiche la commande corrigée. J’y ai rejoué 830 anciennes commandes : 12 refusées, et les 12 étaient de vraies erreurs.
• Les conflits de ports. Des agents prenaient des ports qu’une autre appli utilisait déjà. Depuis le 15 octobre, un hook vérifie les commandes docker et Tailscale contre ma liste de ports avant qu’elles tournent. Il a 43 tests.
• Les schémas sans style. C’est devenu une règle : ouvrir la page dans un vrai navigateur, en largeur téléphone et bureau, sur ma machine puis de nouveau sur le site en ligne. Ce site a un vérificateur qui fait exactement ça, sous Chromium et WebKit, les moteurs de Chrome et de Safari.
• Des tests sur les vraies données. Le 25 octobre, un agent a lancé les tests de mon appli de films dans le conteneur en production. Le chemin de base de données du conteneur l’a emporté sur celui des tests, donc les tests ont vidé les tables de production. La liste des films a été reconstruite depuis la copie gardée sur le disque des films. Les points de reprise sont revenus depuis la sauvegarde du matin, moins tout ce qui avait été regardé ensuite. Cette règle est une ligne dans la mémoire de mes agents et un correctif dans les tests de l’appli. Ce n’est pas encore un hook, donc elle ne marche que tant qu’un agent la lit.

J’ai noté mon organisation avec ses questions

Addy garde une courte liste de questions qu’il se pose. J’en ai essayé cinq sur mon organisation, et la plupart ont trouvé un trou.

« Ai-je formulé une hypothèse avant de demander ? » Chaque changement commence par une issue GitHub, et un hook refuse une pull request qui n’en cite pas. Mais l’issue dit ce que je veux, pas ce que j’attends.

« Qu’est-ce qui devrait être vrai pour que ce soit faux ? Puis allez vérifier. » Mon test dans un vrai navigateur pose exactement cette question, avec un script, à chaque changement visuel. Celle-là tient.

« Ai-je entendu l’argument inverse sous un autre angle ? » À moitié seulement. Dans le pipeline qui tourne pendant mon absence, un modèle d’une autre entreprise relit le changement avant que la pull request s’ouvre. Partout ailleurs, l’agent qui a construit le changement est aussi celui qui le note.

« Qu’a-t-il décidé à ma place ? » Addy demande à l’agent de lister ses choix : les valeurs par défaut, ce qu’il a laissé de côté, quelle exigence l’a emporté quand deux se contredisaient. Mes pull requests disent ce qui a changé et comment ça a été testé. Rien n’y demande les choix.

« Qu’est-ce que je ne pratique plus ? » Il en écrit la liste chaque mois. Rien dans mon organisation ne le suit.

Donc une tient, une tient à moitié, et trois sont des trous. Mon organisation vérifie bien le résultat, mais presque pas ma propre réflexion, ni avant le travail ni après.

Là où j’espère encore

Addy a un nom pour l’écart entre ce que vos agents produisent et ce que vous signeriez : la taxe d’orchestration. Quand le travail fini s’empile plus vite que vous ne pouvez le vérifier, une session d’agent de plus n’y changera rien. Soit vous renforcez les vérifications, pour qu’une moindre part du travail ait besoin de vous, soit vous ralentissez. Puis sa phrase la plus forte : « Quand vous produisez plus que ce que vous pouvez assumer, vous ne relisez plus. Vous espérez. »

Le 8 octobre, je n’ai pas ralenti. Je suis sorti de l’étape de merge et j’ai gardé les vérifications. Deux des hooks ci-dessus sont arrivés dans les trois semaines suivantes. C’est sa première option, en partie. Trois endroits de mon organisation tournent encore à l’espoir :

• Des notes qui se publient toutes seules. Chaque lundi, un script rédige jusqu’à trois notes courtes pour ce site à partir de ce que j’ai livré. Depuis le 26 septembre, il les publie aussi, sans aucune étape humaine. Le filet de sécurité que j’ai conçu pour lui est toujours une issue ouverte : un second modèle pour vérifier les faits, un contrôle de confidentialité et de ton, et une dépublication en un geste.
• Un correctif téléphone. Celui de mon appli de notes a été mergé et déployé le 31 octobre. Sa propre pull request disait : « Pas prouvable ici : la barre AutoFill et la vraie géométrie du clavier. » L’agent l’a dit clairement. Le correctif est quand même parti, avant que quiconque l’essaie sur un iPhone.
• Le bug de sauvegarde vu plus haut. Un agent l’a trouvé et signalé. Personne ne l’a encore corrigé.

Addy se demande aussi ce qui se passera quand les modèles feront ça mieux que nous. Sa réponse : quelqu’un répond toujours de ce qui part en production. Il cite la recherche d’Anthropic sur ses propres ingénieurs, qui appelle ça le paradoxe de la supervision : « superviser Claude demande justement les compétences en code qui risquent de s’atrophier à force d’abuser de l’IA ». Puis : « Vous pouvez déléguer le travail et une bonne partie de l’audit, mais pas la responsabilité. » Ma règle a déplacé le bouton de merge. Elle n’a pas déplacé la responsabilité.

Essayez

Addy termine par un exercice qui coûte deux lignes. Avant de demander, écrivez ce que vous pensez qu’il va se passer. Quand l’agent a fini, écrivez une chose qu’il n’a pas vérifiée.

Ses autres habitudes, en bref :

• Ayez une hypothèse, même mauvaise.
• Lisez ce que l’agent a lancé et ce que ça a renvoyé avant de lire son résumé.
• Demandez-lui ce qu’il a décidé à votre place.
• Écrivez la demande avec vos propres mots : pour qui, ce qui est hors périmètre, ce que « fini » veut dire.
• Une fois par semaine, faites une vraie tâche sans agent.
• Si vous ne mettriez pas votre nom dessus, ça ne sort pas.

Dans mon organisation, les deux trous les moins chers à combler sont sa première et sa quatrième question : une ligne dans chaque issue pour ce que j’attends, et la liste des choix de l’agent dans chaque pull request.

Pour aller plus loin :

• Critical thinking when agents do the work, l’article d’Addy, environ 15 minutes
• Cognitive surrender, son article précédent sur le terme
• The orchestration tax, sur l’écart entre ce que produisent les agents et ce que vous signeriez
• How AI is transforming work at Anthropic, la recherche derrière le paradoxe de la supervision
• Comment l’équipe Claude Code relit le code qu’écrit Claude, mes notes sur l’article coécrit par Addy

Essayez les deux lignes sur votre prochaine tâche d’agent. Puis dites-moi ce que votre agent n’a pas vérifié.

Texte brut: ask-what-the-green-check-proved.md · Flux Atom · Toutes les notes