- ▸ Un agent qui réussit à froid et échoue en production
- ▸ Quand un modèle invente une quatrième version d'un concept qui en avait déjà trois
- ▸ Le vrai problème n'est pas le code, c'est l'absence de langage commun
- ▸ Depuis les débuts du génie logiciel, une seule réponse : le budget
Un agent IA qui échoue sur un dépôt vieux de quatre ans réussit sans effort sur un projet neuf : même modèle, deux résultats opposés. Selon le blog technique Cold Take (27 août 2026), l’écart ne vient pas du modèle mais de l’absence de langage partagé dans le code existant. Doter un système de cette « prêteté » à l’agentique devient un chantier à part entière, distinct du choix du modèle.
Ce qu’il faut retenir 1. Un même agent LLM obtient des résultats nets sur un dépôt neuf et se met à inventer des variantes conceptuelles sur un système en production depuis quatre ans. 2. La cause identifiée par Cold Take n’est pas la capacité du modèle : c’est l’absence de définition unique et partagée des concepts métier dans le code. 3. La pratique historique consistant à réserver 10 à 20 % du budget technologique au remboursement de la dette technique ne suffit plus à rendre un système lisible pour un agent. 4. La proposition défendue est de reconstruire, morceau par morceau, ce que l’article appelle une carte du contexte du système. 5. Le chantier n’est pas ponctuel : il se mène par incréments, section de code après section de code.
Un agent qui réussit à froid et échoue en production
Le scénario décrit par Cold Take est précis. Demandez à un agent de créer un champ « statut de l’offre d’emploi » dans un dépôt qui vient de naître : il en produit un, propre, cohérent, sans hésitation. Demandez la même chose dans un système qui expédie du code en production depuis quatre ans, et le modèle invente une quatrième orthographe d’un concept qui existait déjà sous trois formes différentes ailleurs dans la base.
Ce contraste entre projet neuf et projet ancien n’a rien d’anecdotique pour les équipes qui pilotent des déploiements d’agents. La plupart des démonstrations publiques d’agents de code s’appuient sur des dépôts vierges ou de petite taille, là où la structure est encore simple et le vocabulaire technique cohérent. Le travail quotidien des équipes d’ingénierie, lui, consiste à introduire ces mêmes agents dans des bases chargées d’arborescences de dépendances lourdes, de couplages forts entre modules et d’un arriéré de dette technique fait de tout ce qui n’a jamais été traité.
L’écart de performance entre ces deux contextes ne se limite pas à une baisse de vitesse ou à quelques erreurs de syntaxe. Il change la nature même de ce que produit le modèle : au lieu de compléter un système, l’agent en complexifie la structure conceptuelle, ajoutant sa propre variante à une liste de variantes déjà existante.
Quand un modèle invente une quatrième version d’un concept qui en avait déjà trois
L’échec a une forme reconnaissable, selon l’analyse publiée sur Cold Take. Ce n’est pas un plantage, ni une erreur de compilation visible immédiatement dans les tests. C’est une décision silencieuse, prise par le modèle à la place de l’équipe, sur un point que le système lui-même n’a jamais tranché.
Dans un dépôt neuf, la question « où stocker le statut d’une candidature » n’a qu’une réponse possible, puisqu’aucune réponse concurrente n’existe encore. Dans un système qui tourne depuis plusieurs années, cette même question se heurte à un empilement d’implémentations successives : un champ status, un champ state, une table de correspondance héritée d’une migration antérieure, parfois les trois à la fois, chacun couvrant une partie légèrement différente du même besoin métier.
Face à cette pluralité non résolue, le modèle ne choisit pas entre les options existantes. Il en fabrique une nouvelle. Le résultat correspond, sur le papier, à la demande formulée par l’utilisateur : le champ est bien créé, la fonctionnalité semble bien fonctionner en test isolé. Mais le système gagne une quatrième façon de nommer le même concept, ce qui aggrave exactement le problème que l’équipe cherchait à résoudre en introduisant l’agent.
Ce type d’erreur est plus coûteux à détecter qu’un bug classique. Un test unitaire qui échoue attire l’attention immédiatement. Une incohérence sémantique supplémentaire, elle, passe la revue de code sans alerte, puisque chaque champ pris isolément est syntaxiquement correct. Le problème ne se manifeste que plus tard, quand une autre équipe, ou un autre agent, doit choisir laquelle des quatre versions consulter pour connaître le vrai statut d’une candidature.
Le vrai problème n’est pas le code, c’est l’absence de langage commun
Derrière chaque champ dupliqué se cache une question laissée sans réponse par l’organisation elle-même : quelle est la définition exacte du concept, qui a autorité pour la trancher, et où cette définition est-elle censée vivre dans le code. L’analyse de Cold Take pointe précisément cette couche : sous le problème technique visible se trouve un second problème, plus profond, fait de confusion, de sens manquant et d’absence de langage partagé pour le résoudre.
Cette distinction change la manière de poser le diagnostic. Un modèle de langage n’échoue pas parce qu’il manque de capacité de raisonnement sur du code complexe : il échoue parce que le système sur lequel il travaille ne lui fournit aucune réponse fiable à des questions que le système lui-même n’a jamais tranchées en interne. Un dépôt qui contient trois définitions concurrentes d’un même concept métier n’a, par construction, aucune réponse unique à donner à un agent qui en cherche une.
Le constat rejoint un vocabulaire déjà connu des équipes qui pratiquent la conception pilotée par le domaine (domain-driven design) : sans langage ubiquitaire, c’est-à-dire sans vocabulaire métier partagé entre développeurs, produit et code source, chaque nouvelle intervention sur le système, humaine ou automatisée, ajoute sa propre interprétation plutôt que de s’aligner sur une référence commune. Un agent LLM ne fait qu’accélérer et rendre visible un défaut de gouvernance sémantique qui existait déjà avant son arrivée.
Depuis les débuts du génie logiciel, une seule réponse : le budget
La dette technique n’est pas un problème né avec les agents IA. Le concept traverse l’histoire du développement logiciel depuis ses débuts, sous une forme ou une autre : du code qui fonctionne mais dont la structure n’a pas suivi la croissance du produit, des raccourcis pris pour tenir une échéance, des choix d’architecture devenus obsolètes sans jamais être révisés. Cold Take resitue le problème actuel dans cette continuité : au commencement du génie logiciel, il y avait déjà, et uniquement, la dette technique.
La réponse organisationnelle qui s’est imposée au fil des décennies reste, elle, restée globalement la même : réserver une part du budget d’ingénierie au nettoyage. La pratique documentée par Cold Take consiste à sanctuariser 10 à 20 % du budget technologique pour résorber la dette technique accumulée, plutôt que de la laisser s’empiler indéfiniment.
Ce mécanisme fonctionnait tant que la dette technique restait un problème interne à l’équipe d’ingénierie, traité au rythme humain des sprints et des revues de code. Un développeur qui rencontre un champ status et un champ state dans la même base sait, par expérience du produit et par échanges informels avec ses collègues, lequel utiliser dans quel contexte. Cette connaissance tacite, jamais formalisée dans le code lui-même, suffisait à faire fonctionner le système au quotidien.
| Dimension | Projet neuf (greenfield) | Système en production depuis plusieurs années |
|---|---|---|
| Définition des concepts métier | Une seule version, créée à la demande | Plusieurs versions concurrentes, jamais arbitrées |
| Comportement observé de l’agent IA | Champ généré correctement dès la première tentative | Le modèle ajoute une variante supplémentaire au lieu de réutiliser l’existant |
| Connaissance tacite disponible | Non nécessaire, le système est encore simple | Répartie entre développeurs, rarement écrite dans le code |
| Traitement historique de la dette | Faible, la dette ne s’est pas encore constituée | 10 à 20 % du budget technologique, selon la pratique documentée par Cold Take |
| Nature du problème pour un agent | Technique, résolu par la génération de code | Sémantique, en amont de toute génération de code |
Ce tableau met en évidence ce que la lecture par le seul prisme budgétaire ne capture pas : la connaissance tacite qui permettait à une équipe humaine de naviguer dans un système confus n’est d’aucune aide pour un agent, qui n’a accès qu’à ce qui est écrit, formalisé et cohérent dans le dépôt lui-même.
Pourquoi le budget de nettoyage habituel ne suffit plus
L’introduction d’agents dans un système qui porte cette dette non résolue déplace le point de rupture. Tant que seuls des humains intervenaient sur le code, la confusion sémantique restait un coût diffus : temps perdu en réunions de clarification, bugs occasionnels liés à une mauvaise interprétation d’un champ, onboarding plus lent pour les nouveaux arrivants. Coûteux, mais absorbable au rythme de l’équipe.
Un agent LLM, lui, ne dispose pas de cette connaissance tacite accumulée par les développeurs au fil des années. Il ne peut s’appuyer que sur ce que le code, la documentation et les tests lui exposent directement. Quand cette base est incohérente, l’agent ne demande pas de clarification à un collègue autour d’un café : il tranche seul, silencieusement, et le plus souvent dans le sens qui aggrave la duplication existante plutôt que de la résorber.
Concrètement, pour une équipe technique, cela signifie que le calcul historique du budget de dette technique doit intégrer un critère qui ne s’y trouvait pas jusqu’ici : la capacité du système à répondre sans ambiguïté aux questions qu’un agent va lui poser. Un système peut être fonctionnellement stable, correctement testé et pourtant rester impraticable pour l’automatisation agentique, précisément parce que ses définitions métier n’ont jamais été unifiées. Le budget de 10 à 20 % conçu pour un rythme humain n’a pas été dimensionné pour ce nouveau type de consommateur du code.
Reconstruire une carte du contexte, morceau par morceau
Face à ce constat, Cold Take formule une thèse simple dans son énoncé mais exigeante dans son exécution : le modèle n’est pas ce qu’il faut faire monter en gamme. Le code, lui, n’est pas prêt, et cette préparation, cette « prêteté », est quelque chose qui se construit.
La formule qui résume l’approche proposée consiste à « regenerate the context map » — régénérer la carte du contexte du système. L’idée n’est pas de réécrire l’application, mais de reconstruire, domaine par domaine, une représentation explicite et unique de ce que chaque concept métier signifie, où il vit dans le code, et quelle version fait autorité quand plusieurs coexistent encore temporairement.
Ce travail se distingue d’un grand projet de refonte par sa méthode : il s’agit d’un processus incrémental, avance pièce par pièce, plutôt que d’un chantier bloquant mené en une seule fois. Une équipe peut commencer par clarifier un seul domaine fonctionnel, celui qui génère le plus d’incohérences visibles pour les agents qu’elle déploie, avant d’étendre progressivement l’effort aux modules voisins. Chaque domaine clarifié devient une zone où un agent peut opérer avec un niveau de fiabilité proche de celui observé sur un projet neuf, tandis que les zones non encore traitées restent des points de vigilance identifiés.
Cette logique incrémentale a une conséquence directe sur la manière de prioriser le travail. Plutôt que de chercher à rendre l’intégralité d’un système lisible pour un agent avant tout déploiement, une équipe peut cibler les domaines où l’automatisation agentique apporte le plus de valeur immédiate, et concentrer l’effort de clarification sémantique sur ce périmètre précis. La préparation du code cesse ainsi d’être un préalable théorique pour devenir un critère opérationnel de séquencement des projets.
L’objection du « il suffit de mieux prompter » ne tient pas face à l’exemple du champ dupliqué
Une critique revient régulièrement face à ce type de diagnostic : pourquoi ne pas simplement fournir plus de contexte au modèle dans l’invite elle-même, plutôt que de réorganiser le code source. L’argument a une part de vérité — des instructions plus précises réduisent effectivement certaines erreurs d’un agent. Il ne résout cependant pas le cas décrit par Cold Take, où le problème ne vient pas d’un manque d’information transmise au modèle, mais de l’absence d’une information stable à transmettre.
Quand un système contient trois définitions concurrentes d’un même concept métier, aucune invite, aussi détaillée soit-elle, ne peut indiquer au modèle laquelle des trois fait autorité, puisque le système lui-même ne le sait pas. Demander à un agent de « bien vérifier les champs existants avant d’en créer un nouveau » suppose que ces champs existants portent une hiérarchie claire entre eux. Or c’est précisément cette hiérarchie qui fait défaut dans un système où la dette technique s’est accumulée sans arbitrage.
Notre lecture : traiter ce problème uniquement par l’ingénierie de prompt revient à demander au symptôme de compenser la cause. Le prompt peut réduire la fréquence des erreurs les plus visibles, mais il ne remplace pas le travail de clarification qui consiste à établir, une bonne fois, quelle version d’un concept métier fait référence dans le système. Tant que cette clarification n’a pas eu lieu, chaque nouvelle session d’un agent reproduit la même ambiguïté, avec ou sans instructions supplémentaires.
Ce que change une carte du contexte régénérée pour les équipes qui déploient des agents
Le déplacement de perspective proposé par Cold Take a une portée qui dépasse le seul cas des agents de code. Il touche à la manière dont une organisation documente et arbitre sa propre connaissance métier, indépendamment de l’outil qui viendra ensuite exploiter cette connaissance. Un système dont les concepts sont clairement définis et uniques profite autant à un nouveau développeur humain qu’à un agent, ce qui change l’équation économique du chantier : la clarification sémantique cesse d’être un coût dédié à l’intelligence artificielle pour redevenir un investissement de qualité logicielle au sens large.
Reste une question que l’article ne tranche pas explicitement, et qui se posera à chaque équipe engageant ce travail : jusqu’où pousser la clarification avant qu’un domaine soit jugé suffisamment lisible pour qu’un agent y opère sans supervision renforcée. La réponse ne peut pas être uniforme d’un système à l’autre, puisqu’elle dépend directement de l’ampleur de la dette accumulée et du rythme auquel chaque organisation peut se permettre d’avancer, domaine par domaine.
FAQ
Qu’est-ce que le « brownfield » dans ce contexte ?
Le terme désigne les projets logiciels existants, développés et maintenus au fil du temps, par opposition aux projets neufs dits « greenfield ». Un système brownfield porte généralement une dette technique accumulée, des couplages entre modules et des définitions métier parfois dupliquées, ce qui le rend structurellement plus difficile à faire évoluer, y compris pour un agent IA.
Pourquoi les agents LLM inventent-ils des concepts différents plutôt que de réutiliser l’existant ?
Selon l’analyse de Cold Take, cela résulte d’un manque de langage partagé dans le code. Quand un système ne dispose d’aucune définition unique pour un concept donné, le modèle n’a pas de référence fiable à réutiliser : il en fabrique une nouvelle, qui vient s’ajouter aux versions déjà présentes plutôt que de les remplacer.
Sources citées dans cet article – Domain-Driven Agents, coldtake.dev, publié le 27 août 2026.
Note méthodologique : cette analyse s’appuie sur une source technique unique, disponible à ce jour sur le sujet des agents pilotés par le domaine appliqués au code existant. Les données chiffrées mentionnées (part du budget technologique consacrée à la dette technique) proviennent de cette même source.
