De la revue de code à la conversion du jugement : notes de terrain sur le travail avec des agents

Qu’est-ce qui change vraiment dans la chaîne de production quand les agents de programmation entrent dans le travail quotidien ? Eh bien, la compétence la plus utile pourrait se révéler être celle à laquelle personne n’a été formé.

Voici un petit moment, bien réel, du travail avec des agents de programmation. Vous confiez une tâche à l’un d’eux, il revient avec une pull request (PR) et l’on trouve, noyée dans sa propre relecture du travail, une remarque de ce genre : « Le second SELECT de cette procédure n’est pas protégé par rapport au premier : et si quelqu’un supprime la table entre les deux ? » La fenêtre en question est inférieure à la milliseconde. Personne ne va supprimer cette table. Et pourtant, l’agent le signale avec la même gravité qu’un véritable bug de perte de données. Multipliez cela à l’échelle d’une grosse PR et vous obtenez une expérience que beaucoup d’entre nous reconnaissent désormais : des diffs qui s’étalent, des revues qui s’en prennent à du code existant sur lequel personne n’a rien demandé, et le sentiment diffus de perdre la main sur votre propre base de code.

L’explication la plus répandue, c’est que notre métier devient un métier de management : vous voilà manager de plusieurs agents, peut-être même d’un agent qui en manage d’autres. Cette lecture nous semble séduisante et, pour l’essentiel, fausse. Manager des humains fonctionne parce qu’ils sont assez lents pour que votre débit corresponde à peu près au leur, et parce qu’ils partagent votre intention. Les agents vont plus vite que vous ne pouvez les superviser et ne partagent pas votre intention : ils n’en ont qu’une reconstruction plausible. Le « manager d’agents » se réduit alors au « relecteur d’un flot ininterrompu », et c’est là que la suringénierie fait le plus mal.

Le problème de fond, c’est que cette suringénierie n’est pas un bug qu’un prompt suffit à faire disparaître. Elle est structurelle. Un ingénieur humain qui a déjà livré du code en production dispose d’un budget de risque implicite : une réserve finie d’attention, de capacité de revue et de tolérance à la régression, qu’il dépense de façon délibérée. Ce chemin de code est très sollicité, il a donc droit au traitement soigné ; ce script tourne une fois par trimestre, alors du moment qu’il fait le travail, cela suffit. Un agent n’a pas de budget de ce genre. Toute amélioration possible lui paraît gratuite, alors il les propose toutes. La remarque sur la suppression de la table, c’est simplement un agent qui puise dans un budget dont il ignore l’existence.

Bon, autant vous l’avouer : certains après-midi, je valide tout simplement la version boursouflée, parce que batailler avec ce truc me demanderait plus d’énergie qu’il ne m’en reste. Ce n’est pas glorieux. Mais tout ingénieur qui prétend ne l’avoir jamais fait ment.

L’intuition est donc juste : l’agent a besoin d’une notion du coût de l’effort. Mais lui enseigner ce coût directement échoue en général, parce que ce coût n’est pas une propriété du code. C’est une propriété de votre situation cette semaine : la capacité de revue dont vous disposez, la proximité de la prochaine mise en production, la confiance que vous accordez à ce recoin du système. Encodez-le, et il sera périmé dès que la situation changera. Les limites structurelles strictes – un plafond de taille de diff, par exemple – échouent autrement : elles pénalisent l’agent pour ce refactoring occasionnel, vraiment meilleur, qui a le malheur d’être volumineux. Aucun des deux extrêmes ne tient.

Ce qui marche mieux se situe entre les deux, et coûte moins cher qu’on ne le croit : laissez l’agent présenter le coût comme un choix, en amont, dans le plan plutôt que dans le code. Demandez-lui, avant qu’il n’écrive quoi que ce soit, d’exposer trois plans – une intervention minimale, une intervention raisonnable et une réécriture complète de toute la chaîne – et choisissez. Trois plans, ça ne coûte presque rien ; trois implémentations, si. Vous dépensez votre jugement au seul moment où il est bon marché de l’exercer, avant le travail, au lieu de le redépenser ligne à ligne pendant la revue. C’est très proche de ce que recommandent les propres consignes d’Anthropic pour Claude Code avec le mode plan : explorer et s’accorder sur le périmètre avant de toucher au moindre fichier, puis laisser la vérification exécutable tenir la dernière ligne de défense.

Mais le recadrage le plus pertinent que nous ayons trouvé va plus loin, et c’est celui qui mérite d’être retenu. Si la revue ressemble à une bataille perdue d’avance, c’est que vous payez le même coût de jugement à chaque PR et que rien ne s’accumule : c’est du travail à l’état pur, rien ne fructifie. L’autre voie est une discipline qu’un modèle récent d’ingénierie agentique appelle la conversion en gouvernance : prendre un jugement que vous referiez sinon à la main à chaque fois et le figer dans une structure durable – une règle de lint, une clause de spécification, un périmètre par défaut, un invariant de test – pour que le système tranche automatiquement à partir de là. Le jugement se dépense une seule fois, puis reste acquis pour de bon.

Et il y a un retournement qui rend la chose presque séduisante. La vitesse de l’agent, celle-là même qui vous submerge, est aussi un capteur. Parce qu’il génère autant de code aussi vite, il fait remonter sans cesse les mêmes classes de défaillances, bien plus vite que ne le ferait une équipe humaine. Les PR tentaculaires et les remarques sur la suppression de la table ne sont pas que du bruit : ce sont des signaux, qui vous montrent à haute fréquence précisément les jugements que vous devez porter encore et encore. Chacun de ceux qui reviennent est candidat à la conversion. La question n’est plus « comment relire plus vite ? » mais « parmi les jugements que j’ai portés cette semaine, lesquels ne devraient plus jamais revenir à un humain ? ». Cette structure accumulée, c’est du capital d’ingénierie : on la construit une fois et elle continue de rapporter. Le hic, il faut bien le dire, c’est que les spécifications et les contrôles peuvent dériver à mesure que le code évolue ; ce capital demande donc de l’entretien, mais c’est un problème bien plus enviable que le flot ininterrompu du départ.