Le même agent, le même modèle, la même consigne. Dans un dépôt créé la semaine dernière, il ajoute un champ propre, cohérent, du premier coup. Dans un système qui expédie du code en production depuis quatre ans, il invente un quatrième nom pour un concept qui en portait déjà trois ailleurs dans la base.
Le scénario est décrit par le blog technique Cold Take, dans un texte publié le 27 août 2026. Les deux essais tournent avec le même modèle. La différence tient au terrain sous l’agent.
Deux terrains, un seul modèle
D’un côté, le dépôt neuf. Arborescence courte, dépendances peu nombreuses, vocabulaire encore homogène parce qu’une poignée de personnes l’ont écrit en quelques semaines. Un agent y travaille comme sur une table vide : tout ce dont il a besoin tient dans ce qu’il peut lire.
De l’autre, le système ancien. Couplages forts entre modules, arbres de dépendances lourds, et surtout un vocabulaire qui a dérivé. Le même concept métier porte trois noms selon l’endroit, parce que trois équipes successives l’ont baptisé chacune à sa façon sans que personne n’arbitre. Rien n’est cassé. Rien n’est clair non plus.
La quasi-totalité des démonstrations publiques d’agents de programmation se déroule sur le premier terrain. Le travail réel des équipes d’ingénierie, lui, se passe presque toujours sur le second. Nous évaluons donc ces outils dans le seul environnement où ils ne peuvent pas se tromper de mot.
Le champ « statut de l’offre d’emploi », en quatre exemplaires
L’exemple retenu par Cold Take est volontairement banal : demander à un agent d’ajouter un champ « statut de l’offre d’emploi ». Sur le projet vierge, il en produit un, propre, sans hésitation. Sur le système de quatre ans, il en produit un quatrième, à côté des trois qui existent déjà.
Ce raté ne relève pas de l’hallucination habituelle. L’agent ne lit pas la base entière : il lit une fenêtre, celle qu’on lui donne. Dans cette fenêtre, aucune définition ne fait autorité sur les autres. Alors il tranche. Sa réponse est cohérente localement et fausse globalement.
Un développeur fraîchement arrivé dans l’équipe commettrait exactement la même erreur, à un détail près : il poserait la question à voix haute. Il demanderait pourquoi trois noms coexistent, lequel fait foi, et lequel est mort depuis la refonte de l’an dernier. Cette conversation-là n’est écrite nulle part. Elle vit dans les têtes, et l’agent n’y a pas accès.
Rembourser la dette technique ne rend pas le code lisible par une machine
Depuis les débuts du génie logiciel, un code devenu difficile appelle une réponse budgétaire : réserver 10 à 20 % de l’effort d’ingénierie au remboursement de la dette technique. La pratique est saine, elle a fait ses preuves, et elle vise une chose précise : rendre le code supportable pour des humains.
Or les deux publics n’ont pas les mêmes besoins. Un humain compense un vocabulaire flou avec de la mémoire d’équipe, une réunion, un collègue qui passe. Un agent n’hérite d’aucune de ces béquilles : il ne dispose que du texte. Nettoyer une fonction trop longue améliore la vie du premier sans changer grand-chose pour le second, tant que le concept métier reste défini à trois endroits contradictoires.
Rendre un système lisible par un agent devient ainsi un chantier distinct du choix du modèle. Ce n’est pas la même ligne de dépense, ni la même compétence, ni le même calendrier.
Aucune consigne ne crée la définition qui manque
L’objection arrive vite dans les équipes : il suffirait de mieux formuler la demande. Elle bute sur le champ dupliqué. Aucune consigne, si détaillée soit-elle, ne fait apparaître une définition qui n’existe pas dans le dépôt. Pour désigner la bonne version, encore faut-il qu’une version ait été désignée comme la bonne.
La consigne oriente un agent vers une information disponible. Elle ne fabrique pas l’arbitrage que personne n’a rendu. La limite est structurelle, et elle déplace la charge du fournisseur du modèle vers l’équipe propriétaire du code.
Cartographier les concepts, un module à la fois
La proposition défendue par Cold Take consiste à régénérer, morceau par morceau, ce que le texte appelle une carte du contexte du système : une description explicite des concepts, de leur définition faisant autorité et de leur périmètre. Pas un document unique produit en un trimestre, mais un travail par incréments, section de code après section de code.
L’outillage commence à suivre : Cognition a lancé fin octobre 2025 les Codemaps de Windsurf, des cartes de code annotées par le modèle, et Claude Code lit un fichier CLAUDE.md déposé dans le dépôt pour y trouver les conventions maison. Les deux fournissent à la machine un texte de plus à lire ; aucun ne rend l’arbitrage qui désigne, entre trois définitions concurrentes, celle qui fait foi.
La démarche a ses zones d’ombre, et il faut les dire. Aucun chiffre de retour sur investissement ne l’accompagne, le chantier n’a pas de fin visible, et une carte du contexte se périme aussi vite que le code qu’elle décrit si personne ne la maintient. Son mérite est ailleurs : elle transforme une plainte diffuse sur la qualité des agents en une tâche d’ingénierie identifiable, planifiable, attribuable.
Une équipe qui déploie des agents cette année peut en tirer un test simple. Avant de comparer deux modèles, mesurez leur écart de résultat entre votre projet le plus récent et votre module le plus ancien. Cet écart ne dit rien du fournisseur : il dit ce que votre base de code raconte d’elle-même, et il chiffre le travail préparatoire qu’il vous reste à faire.
Tant que les agents seront jugés sur des dépôts vierges, leurs notes mesureront le terrain autant que la machine. Une démonstration utile leur confierait votre pire module, pas un projet sorti la semaine dernière.
