IA et automatisation

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

Que changent les agents de programmation au quotidien ? La compétence la plus utile est peut-être celle que personne n’a apprise : figer en structure durable les jugements répétés.

— Nodal Studio

Illustration géométrique en aplats orange, vert sauge et lavande : des lignes évoquant un circuit relient blocs et nœuds, un petit robot pointe le bout du nez derrière un mur sombre et un écran affiche des lignes de code.

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é.

La littérature de 2026 sur les méthodes de travail a largement convergé vers un seul récit : le rôle du développeur passe de l’écriture du code à sa direction, à sa revue et à sa vérification. Andrej Karpathy, qui avait forgé l’expression « vibe coding » début 2025, a fait évoluer le cadrage vers l’« agentic engineering », où le développeur fait office de superviseur plutôt que d’auteur ; les enquêtes du secteur publiées jusqu’à la mi-2026 indiquent qu’une large majorité des développeurs professionnels utilisent désormais des agents de programmation au moins une fois par semaine – 90 % dans l’enquête 2026 de JetBrains. C’est vrai jusqu’à un certain point, mais c’est aussi superficiel : cela décrit le basculement sans affronter le problème auquel se heurtent réellement les praticiens, à savoir que l’artefact soumis à la revue est devenu à la fois plus volumineux et plus sûr de lui quand il se trompe.

Ce problème porte déjà un nom dans le débat qui émerge : le paradoxe de la revue de code. Quand un agent génère non seulement l’implémentation, mais aussi ses tests et sa documentation, les repères traditionnels du relecteur s’effritent : les tests peuvent n’être que des sondes d’observation plutôt que des tests de régression riches en assertions (un schéma relevé dans des analyses de tests écrits par des agents sur des trajectoires SWE-bench), et la documentation décrit ce que l’agent a fait, pas ce que vous vouliez. Les propres consignes d’Anthropic pour Claude Code y répondent en plaçant la vérification au-dessus du dialogue : la pratique la plus payante, selon Anthropic, consiste à donner à l’agent un moyen de contrôler son propre travail – tests exécutables, commandes de lint, comparaisons qui renvoient un succès ou un échec –, car sans critères de réussite vérifiables, l’agent produit du code qui a l’air correct et qui, souvent, ne l’est pas.

Raisonner en termes de budget de risque n’a rien d’une simple métaphore. Cela correspond à une asymétrie réelle : le jugement d’un ingénieur humain sur ce qui ne vaut pas la peine d’être fait est tacite, situationnel et coûteux à expliciter, alors qu’un agent vise un maximum théorique d’exactitude parce qu’il n’a aucune représentation du revers de l’effort : surface supplémentaire, complexité supplémentaire, charge de revue supplémentaire. Le plan à trois niveaux (minimal / raisonnable / réécriture complète) est un mécanisme léger pour rendre ce budget explicite au moment de la planification, et il rejoint la recommandation documentée de séparer de l’implémentation une phase de planification en lecture seule.

Le courant le plus radical de la littérature de 2026 remet en cause la prémisse sur laquelle repose tout cela. Une ligne d’argumentation (Cao, « Agentic Software: How AI Agents Are Restructuring the Software Paradigm », d’abord publié sous le titre « The End of Software Engineering ») soutient que, dans les systèmes pleinement agentiques, le code cesse d’être le support de la logique de décision pour devenir un outillage éphémère, généré puis jeté au sein d’une boucle de raisonnement pilotée par un LLM. Si le code est jetable, l’envie même de blinder une requête SELECT que vous régénérerez la semaine prochaine s’estompe en partie ; ce qui mérite d’être protégé n’est plus l’implémentation, mais la spécification et les invariants qui la sous-tendent. Un courant parallèle (passé en revue dans des travaux comme « Skills for the Future Software Profession », de Roychoudhury, Kang et Ray) avance qu’à mesure que les LLM automatisent la recherche de preuves, le goulet d’étranglement de la vérification formelle se déplace de la preuve de correction vers l’inférence de la bonne spécification, ce qui fait de la spécification, et non du code, l’artefact fondamental ; il avertit aussi que les spécifications inférées dérivent à mesure que les implémentations évoluent et exigent une vérification continue de leur cohérence.

La conversion en gouvernance, le concept sur lequel nous fondons notre conclusion, vient de James C. Davis et de ses collègues : d’abord dans une étude de cas de 12 semaines, « Cheap Code, Costly Judgment » (juillet 2026), puis dans leur cadre Model-Based Agentic Software Engineering (MAGE) (août 2026). La thèse est précise : une implémentation agentique à grande vitesse fait remonter des classes récurrentes de défaillances structurelles, et le jugement d’ingénierie maintient cette vitesse en convertissant ces défaillances en mécanismes de gouvernance durables. C’est le geste qui a du mordant, parce qu’il transforme des leçons choisies en structure d’ingénierie durable dont le travail futur hérite. Le mot « conversion » compte ici : le jugement est un actif éphémère, qui sert une fois puis se perd ; la gouvernance est la forme durable en laquelle il se convertit ; et, à mesure que cette structure s’accumule et abaisse le coût du travail futur, elle devient ce que MAGE appelle le capital d’ingénierie : une structure durable qui réduit le coût ou l’incertitude du travail futur grâce à la réutilisation. Des travaux indépendants sur la fiabilité du génie logiciel agentique (par exemple « Agents as Software », de Barke et Murali) aboutissent au même point depuis le champ des langages de programmation : ils redéfinissent le comportement des agents comme quelque chose à spécifier sur des traces et des états, à vérifier avant le déploiement et à surveiller à l’exécution, ce qui revient, de fait, à appliquer la conversion en gouvernance aux agents eux-mêmes.

La conséquence pratique, pour un studio comme le nôtre, c’est un déplacement de l’endroit où l’on investit l’effort. Relire plus vite ce que produisent les agents, c’est faire du surplace. Ce qui fait fructifier l’effort, c’est de traiter chaque commentaire de revue récurrent comme un diagnostic : le réflexe de la table supprimée trahit en réalité une spécification manquante ; vous n’avez jamais déclaré que cet invariant comptait, alors cessez de le remettre sur le tapis à chaque revue : encodez-le sous forme de contrôle, ou décidez, une bonne fois pour toutes et explicitement, qu’il ne compte pas. La compétence rare et durable n’est plus d’écrire du code, ni même de le relire, mais d’énoncer précisément ce qui doit être vrai et de convertir les jugements que vous répétez en une structure que le système maintient à votre place. Le risque qui reste ouvert, signalé par les mêmes chercheurs, est la dérive des spécifications : ce capital se déprécie, et maintenir les spécifications cohérentes avec des implémentations qui évoluent vite est le prochain goulet d’étranglement qui nous attend. C’est sur ce problème-là que nous préférons travailler.

Sources

Revenir à la lecture rapide (5 min).

À lire aussi