Claude Code nous a économisé 97 % du travail, puis c'est devenu un désastre complet

SECTION 1

Claude Code sur une base de code legacy : le contexte de l'expérimentation

Début 2025, quelques semaines après son lancement par Anthropic, nous avons expérimenté Claude Code sur CodeConcise, un outil que nous avons développé chez Adservio pour comprendre les bases de code patrimoniales. L'objectif était de déterminer si un agent de codage pouvait accélérer une tâche bien délimitée mais chronophage : l'ajout du support de nouveaux langages de programmation.

Typiquement, ce travail demandait deux à quatre semaines à une équipe de deux développeurs. Avec Claude Code et un expert métier, il n'a fallu que quelques minutes de génération et quelques heures de validation pour le langage Python, soit environ 97 % du travail économisé. Mais la même approche appliquée à JavaScript s'est soldée par un échec complet, en trois tentatives successives. Ce contraste spectaculaire est précisément ce qui rend l'expérience instructive.

Nous republions ce retour d'expérience avec le recul de juillet 2026 : l'outillage a considérablement mûri, mais les leçons de fond, sur les boucles de rétroaction, la qualité du code existant et les limites structurelles des agents, restent étonnamment actuelles. Nous avons conservé le récit d'origine et actualisé le regard que nous portons sur lui.

SECTION 2

Claude Code et le paysage 2026 des agents de codage supervisés

Claude Code est un agent de codage développé par Anthropic et lancé le 24 février 2025. C'est un exemple de ce qu'on qualifie « d'agent de codage supervisé » : un outil capable d'effectuer des tâches sophistiquées dans les flux de travail de développement logiciel, parfois de manière autonome, sous le contrôle d'un développeur qui cadre la demande et valide les étapes clés.

### Terminal, IDE ou cloud : trois familles d'agents

Sa particularité d'origine, fonctionner en ligne de commande plutôt que dans un IDE, est devenue une catégorie à part entière. En 2026, trois familles d'agents coexistent : les agents en terminal (Claude Code, OpenAI Codex CLI, Gemini CLI, et des outils open source comme Aider ou Goose), les agents intégrés à l'IDE (Cursor, GitHub Copilot dont l'Agent Mode est généralement disponible sur VS Code et JetBrains depuis mars 2026, ou Windsurf, devenu Devin Desktop après son rachat par Cognition), et les agents cloud qui prennent en charge une tâche de bout en bout dans leur propre environnement d'exécution, comme Devin. Le terminal reste le meilleur point d'intégration dans un écosystème d'outils plus large qu'un IDE.

### Des modèles qui ont changé d'échelle depuis nos tests

Au moment de notre expérimentation, Claude Code s'appuyait sur les modèles Claude Sonnet de l'époque. Mi-2026, il utilise par défaut Claude Opus 4.8 sur les offres Max et API, et Claude Sonnet 5, avec sa fenêtre de contexte native d'un million de tokens, sur les abonnements Pro. Le Model Context Protocol (MCP), encore émergent lors de nos tests, s'est imposé comme le standard de connexion entre agents et sources de données, adopté par l'ensemble de l'écosystème. La performance d'un agent dépend toujours des mêmes fondamentaux : orchestrer le contexte du code, formuler des requêtes efficaces au modèle et s'intégrer aux fournisseurs de contexte.

@cite:a-quelle-vitesse-les-assistants-de-codage

SECTION 3

CodeConcise : cartographier le code patrimonial avec AST et GraphRAG

Pour comprendre l'expérimentation, il faut présenter brièvement CodeConcise. L'outil utilise les arbres de syntaxe abstraite (AST) non seulement pour décomposer les bases de code et en extraire la structure, mais aussi pour naviguer dans ces bases lorsqu'un LLM est utilisé pour les résumer et les expliquer.

Concrètement, CodeConcise exige des implémentations spécifiques à chaque langage d'une classe abstraite nommée IngestionTool. Chaque implémentation retourne une liste de nœuds et d'arêtes extraits du code, qui alimentent un graphe de connaissances. Des traversées agnostiques du langage enrichissent ensuite ce graphe avec des informations extraites du code à l'aide d'un LLM. Le graphe est enfin exploité par un agent et par GraphRAG pour fournir des insights aux utilisateurs, une architecture qui reste, en 2026, l'un des patterns de référence pour l'analyse de code legacy à grande échelle.

### Pourquoi ajouter un langage coûtait deux à quatre semaines

Chaque nouveau langage supporté impose d'écrire le code qui produit et interprète son AST : trouver des bases de code d'exemple représentatives, construire une suite de tests automatisés, puis implémenter l'outil d'ingestion. Comptez deux à quatre semaines pour une équipe de deux développeurs. C'est la raison pour laquelle le support n'était ajouté qu'à la demande, et c'est l'hypothèse que nous voulions tester : si un agent réduisait drastiquement ce coût, nous pourrions couvrir la majorité des langages dès le départ et consacrer notre temps à des travaux à plus forte valeur ajoutée.

SECTION 4

Le succès Python : des semaines de travail réduites à quelques minutes

Première demande : identifier les modifications nécessaires pour ajouter le support de Python. La question peut sembler simple pour un développeur qui connaît la base de code depuis quelques semaines, mais elle est précieuse pour un nouveau venu sur le projet. Avec accès au code et à sa documentation, Claude Code a produit des résultats stupéfiants : il a correctement identifié toutes les modifications nécessaires, et le code suggéré montrait qu'il n'avait pas seulement inspecté les outils d'ingestion existants, mais aussi assimilé les modèles de conception utilisés pour les implémenter.

### Trois minutes de travail autonome, deux défauts détectés par nos tests

Deuxième demande : implémenter lui-même les modifications. « Je dois construire un nouvel outil pour charger du code Python dans CodeConcise. Veuillez le faire et le tester. » Un peu plus de trois minutes plus tard, toutes les modifications étaient implémentées localement, tests compris, et tous les tests suggérés par Claude Code passaient. Mais lorsque nous avons chargé son propre code source dans un graphe de connaissances et exécuté nos tests end-to-end, deux problèmes sont apparus : la structure du système de fichiers ne faisait pas partie du graphe, et les arêtes reliant les nœuds ne respectaient pas notre modèle, les dépendances d'appel manquaient, ce qui aurait empêché le pipeline de compréhension de traverser le graphe comme attendu.

Cette découverte illustre l'importance des boucles de rétroaction multiples quand une IA écrit du code. Sans nos propres tests, le problème n'aurait été découvert que bien plus tard, de façon perturbatrice et coûteuse, le développeur comme l'agent ayant perdu le contexte du travail en cours. Après retour, le code a été corrigé en quelques secondes, en suivant fidèlement les patterns existants comme l'utilisation d'Observers pour construire la structure du système de fichiers au fil de l'analyse.

Il faut souligner que, pour ce cas d'usage, une grande partie de la réflexion complexe avait déjà été faite par les concepteurs de l'outil : la logique métier était proprement séparée des détails d'implémentation spécifiques à chaque langage. Claude Code n'avait « qu'à » rassembler ces informations et comprendre, à partir de la conception existante, ce qui devait être construit. Bilan : quelques minutes de génération et une poignée d'heures de validation, là où il fallait des semaines.

SECTION 5

L'échec JavaScript : grammaires cassées et bibliothèques inventées

Forts de ce succès, nous avons tenté la même approche pour JavaScript, avec un prompt précis : utiliser le StageObserver comme ailleurs et appliquer le visitor pattern au lexer et au parser, comme dans le chargeur TSQL. Première tentative : Claude Code s'appuie sur la grammaire ANTLR pour JavaScript, que nous n'avons jamais réussi à faire fonctionner, ce qui dépasse la responsabilité de l'agent, mais nous a empêchés de vérifier le code produit.

Deuxième tentative, en lui demandant d'utiliser tree-sitter : l'agent se met à utiliser des bibliothèques qui n'existent pas. Troisième et dernière tentative, en le laissant choisir son approche : il opte pour une analyse par expressions régulières… dont le code référence des packages internes purement inventés. Trois essais, trois impasses, aucun code vérifiable.

### Des hallucinations présentées avec l'assurance de faits

Le constat était clair : l'agent manquait d'un mécanisme de vérification robuste pour le code qu'il produit, comme s'il se privait du retour qu'apporterait un simple test unitaire. Ce comportement n'avait rien d'inédit, nous l'avions observé plusieurs fois avec d'autres assistants de codage. Pour vérifier que le succès Python n'était pas un coup de chance, nous avons refait l'exercice en C : résultats comparables à ceux de Python, quoique obtenus par correspondance d'expressions régulières plutôt que par une approche AST plus fiable.

@cite:il-faut-traiter-les-hallucinations-de-l-ia-comme

SECTION 6

Six facteurs qui déterminent la qualité du code produit par un agent

Cette expérience porte sur un cas d'usage très spécifique : gardons-nous d'en tirer des conclusions générales injustifiées. Mais l'écart spectaculaire entre Python et JavaScript s'explique par des facteurs que dix-huit mois de pratique ont depuis largement confirmés.

La qualité du code existant, d'abord : un code modulaire, propre, documenté, conçu avec une séparation claire des préoccupations maximise la probabilité de bons résultats, ce que nous avons toujours considéré comme important pour les humains l'est aussi pour les agents. L'écosystème de bibliothèques, ensuite : Python fournit en standard un module de conversion du code en AST, là où JavaScript imposait de s'appuyer sur des grammaires externes fragiles. Les données d'entraînement, enfin : les LLM produisent un meilleur code pour les langages massivement représentés dans leur corpus d'origine.

S'y ajoutent trois facteurs transverses : le modèle sous-jacent, dont les performances conditionnent directement celles de l'agent ; l'agent lui-même, l'ingénierie de ses prompts internes, la conception de ses flux de travail et les outils mis à sa disposition ; et la collaboration humaine, car c'est en faisant travailler ensemble développeurs expérimentés et agents qu'on obtient le meilleur des deux mondes, les premiers connaissant les astuces qui guident les seconds vers de meilleurs résultats.

@cite:comment-cultiver-la-confiance-avec-les-assistants-de-codage

SECTION 7

Ce que 2026 a confirmé : et ce qui a changé depuis l'expérimentation

Dix-huit mois plus tard, l'essentiel du diagnostic tient toujours. Les agents ont gagné des mécanismes de vérification intégrés, exécution automatique des tests et des compilateurs, hooks de validation, sous-agents de relecture, qui auraient probablement intercepté les bibliothèques inventées de notre échec JavaScript avant qu'elles n'atteignent le développeur. Les fenêtres de contexte d'un million de tokens et la généralisation de MCP ont, de leur côté, réduit les pertes de contexte qui pénalisaient les longues sessions de travail.

Mais la leçon de fond est inchangée : aucun agent ne remplace des boucles de rétroaction indépendantes. Tests end-to-end, revue humaine et intégration continue restent la seule garantie que le code généré fait réellement ce qu'il prétend faire. La vitesse de génération a changé d'ordre de grandeur ; la responsabilité de la validation, elle, n'a pas bougé, et c'est précisément sur ce point que nous concentrons aujourd'hui nos accompagnements en adoption d'agents de codage.

Remerciements à Birgitta Böckeler pour son soutien et ses conseils lors de nos expériences. Avis de non-responsabilité : les déclarations et opinions exprimées dans cet article sont celles de leurs auteurs et ne reflètent pas nécessairement les positions d'Adservio.

FAQ

Questions fréquentes