Agentic coding sur de grandes bases de code : le vrai problème n'est pas l'agent, c'est la mémoire

Un développeur de Sequoia pose la main au fond d'une salle et déclare : "Who here writes 100% of their code using Claude Code ?" Quelques mains. Silence amusé. Puis Boris Cherny, créateur de Claude Code chez Anthropic, lève la sienne. Il n'a pas écrit une ligne de code manuellement depuis octobre 2025. En mai 2026, il produit quelques dizaines de pull requests par jour — record personnel : 150 PRs en une journée¹. Sur une base TypeScript de taille raisonnable, bien structurée, le problème est effectivement "solved". Cherny le dit lui-même.

Puis vient la nuance, glissée en une phrase : "There's very big complicated codebases. There's weird languages the model isn't good at yet."

C'est là que la grande majorité des équipes enterprise se trouvent. Leur problème n'est pas de savoir si l'agentic coding marche — elles ont lu les mêmes articles, elles ont fait leurs propres tests. Leur problème est que ça marche sur des projets neufs, et qu'il s'effondre partiellement dès qu'on pose l'agent sur 300 000 lignes de code C# accumulé sur dix ans, sans documentation, avec trois layers d'abstraction custom et une équipe qui a tourné deux fois.

Ce texte ne parle pas des cas faciles. Il parle du vrai goulot.

Le goulot que personne ne cherchait

Pendant deux décennies, l'industrie a optimisé la manière dont les humains écrivent du code. Waterfall, puis Agile, puis DevOps, puis Platform Engineering. À chaque étape, le goulot identifié était la production de code : trop lente, trop chère, trop sujette aux erreurs.

L'agentic coding inverse ce problème. Ce n'est plus produire le code qui est difficile — c'est comprendre le code existant. Google l'a dit sans détour en lançant Code Wiki en novembre 2025 : "Reading existing code is one of the biggest, most expensive bottlenecks in software development"². Cette affirmation ne parle pas des modèles ni des agents. Elle parle du goulot réel, celui qui existait avant les LLMs et qui n'a pas disparu avec eux.

Un agent de codage est un nouveau collaborateur à chaque session. Patrick Debois, inventeur du terme DevOps et fondateur de Tessl, l'a formulé de façon mémorable : "Chaque session est un nouvel employé qui repart de zéro"³. Pas de mémoire musculaire, pas de conversations de couloir, pas de souvenir de la prise de décision qui a conduit à cette architecture bizarre dans le module de paiement. L'agent voit le code, mais il ne connaît pas le projet.

Sur une codebase de 10 000 lignes, ce n'est pas un problème grave — l'agent peut lire l'ensemble en quelques secondes. Sur une codebase de 300 000 lignes avec des dizaines de modules interdépendants, c'est la différence entre un agent qui refactorise proprement et un agent qui produit du code fonctionnel en surface mais contradictoire avec trois conventions établies en 2022.

Le nouveau goulot est là. Et il a un nom.

Context Engineering : l'art de nourrir les agents

Le Context Engineering est le passage du prompt engineering — interaction isolée, mémoire éphémère, ROI linéaire — à la gestion d'un environnement global pour les agents : mémoire persistante cross-sessions, contexte structuré et versionné, ROI composé.

La formule la plus précise vient d'Aristidis Vasilopoulos, chercheur indépendant qui a passé 70 jours à construire un système distribué C# de 108 000 lignes avec Claude Code, en mesurant tout⁴. Son architecture se décompose en trois tiers :

Tier 1 — Constitution (Hot Memory) : un fichier Markdown de 660 lignes, toujours chargé en contexte. Il encode les conventions de nommage, les commandes de build, les patterns architecturaux, les modes de défaillance connus et des trigger tables qui routent l'agent vers les bons spécialistes. C'est la mémoire institutionnelle permanente de la codebase.

Tier 2 — Agents spécialisés (Warm Memory) : 19 spécifications d'agents (9 300 lignes au total), fonctionnant comme mécanismes d'amorçage domaine. Plus de la moitié du contenu est constitué de faits codebase — formules, patterns, modes de défaillance spécifiques à chaque sous-système — plutôt que d'instructions comportementales.

Tier 3 — Knowledge Base (Cold Memory) : 34 documents de spécification (16 250 lignes) récupérés à la demande via un serveur MCP. Ce n'est pas de la documentation — c'est du contexte actionnable, versionnée, et référencée dynamiquement.

Les résultats sont mesurés : 283 sessions, 2 801 prompts humains, 16 522 tours autonomes. Plus de 80% des prompts font moins de 100 mots. Le contexte pré-chargé remplace les explications répétées. Une spécification du système de sauvegarde de 283 lignes, référencée dans 74 sessions, a produit zéro bug de corruption. Un agent réseau de 915 lignes a identifié trois bugs de synchronisation subtils qui avaient résisté à cinq tentatives précédentes.

Le coût de maintenance de cette infrastructure : 1 à 2 heures par semaine.

La presse de Gutenberg et le développeur qui ne savait pas lire son propre code

Il y a une analogie historique qui éclaire la situation, et Cherny la pose lors de son interview Sequoia. En Europe au XV^e siècle, 10% de la population savait lire et écrire. Les scribes étaient des professionnels indispensables, employés par des rois souvent illettrés. Cinquante ans après l'invention de l'imprimerie par Gutenberg, plus de livres avaient été publiés en Europe que dans les mille années précédentes. Le coût d'un livre avait chuté de 100 fois. Quelques siècles plus tard, le taux d'alphabétisation mondial atteignait 70%¹.

"Software will be similarly democratized, but faster than 50 years."

La phrase-pivot de Cherny — "the best person to write accounting software is not an engineer, it's a really good accountant" — ne parle pas seulement de démocratisation. Elle pointe une réalité qui concerne directement les grandes codebases : la connaissance du domaine précède la connaissance du code. L'expert comptable sait ce que le système doit faire. L'agent sait comment le coder. Ce qui manque au milieu, c'est le contexte qui relie les deux : la connaissance du projet, de ses contraintes, de son histoire, de ses invariants.

C'est exactement le problème que le Context Engineering adresse.

Le débit possible — et ce qui l'amplifie

L'Anthropic Economic Index publié en septembre 2025 a mesuré un basculement : 77% des usages professionnels via API impliquent désormais des patterns d'automatisation — contre une majorité d'usages augmentatifs (collaboration humain-IA) pour les utilisateurs individuels⁵. Les entreprises délèguent, pas seulement assistent.

Le rapport identifie également un goulot d'étranglement clé pour le déploiement sophistiqué en entreprise : "l'accès aux informations contextuelles appropriées". Les tâches complexes nécessitent des entrées longues, impliquant un besoin de modernisation des données et d'investissements organisationnels significatifs. En d'autres termes : le modèle peut faire le travail, mais seulement si on lui donne de quoi travailler.

Sur le plan du débit brut, l'image que dresse Cherny est saisissante : quelques centaines d'agents actifs en journée, quelques milliers la nuit sur des tâches de fond. Le /loop de Claude Code — un mécanisme qui utilise cron pour planifier des jobs récurrents — permet à un agent de babysitter les pull requests, corriger les tests flakys, ou regrouper les feedbacks utilisateurs toutes les 30 minutes¹. Les Routines, lancées en parallèle, permettent à ces boucles de tourner côté serveur même quand le laptop est fermé.

Mais tout ce débit ne vaut rien si l'agent ne comprend pas la codebase sur laquelle il travaille. Un agent qui produit 150 PRs par jour sur une base TypeScript bien architecturée produit des contributions utiles. Le même agent, sans contexte, qui refactorise un module legacy peut créer plus de dette qu'il n'en efface.

La structure du coût : une équation que les DSI sous-estiment

L'ère des assistants de codage IA bon marché s'est terminée en 2025. Cursor, Claude Code, Kiro ont harmonisé leurs tarifs à la hausse — conséquence directe de la tension sur l'approvisionnement GPU, des coûts de licence modèles et des frais d'infrastructure⁶. Wei Zhou de SemiAnalysis est direct : aucune solution immédiate ne permettra de réduire ces coûts sans innovations majeures sur les modèles ou l'efficacité du KVCache.

Bradley Shimmin de The Futurum Group ajoute une mise en garde structurelle : les coûts croissent avec l'expansion de la base de code. Un assistant de codage IA sur un projet de 10 000 lignes coûte peu. Sur un monolithe de 500 000 lignes, chaque interaction consomme davantage de tokens de contexte, chaque session de refactoring mobilise plus de mémoire. Charlie Dai (Forrester) nuance le discours du ROI : pour les projets complexes et à grande échelle, le coût cumulé des outils et de la supervision senior peut équivaloir à l'embauche d'un développeur — un sujet que nous détaillons dans notre volet sur le coût de l'agentic coding.

Ce n'est pas un argument contre l'agentic coding. C'est un argument pour une architecture du contexte qui réduit le coût par interaction. Un agent qui dispose d'une Constitution de 660 lignes décrit en Tier 1 n'a pas besoin que le développeur réexplique à chaque session l'architecture du module de paiement. Chaque explication évitée est un coût token évité. L'investissement initial dans le contexte se rembourse à chaque session ultérieure — c'est précisément ce que Vasilopoulos documente empiriquement.

Le Context Development Lifecycle : traiter le contexte comme du code

Patrick Debois, après avoir co-créé le mouvement DevOps en 2009, a appliqué le même raisonnement au contexte. Son Context Development Lifecycle (CDLC) est un cycle en quatre phases qui traite le contexte non comme un fichier markdown oublié, mais comme un artefact d'ingénierie à part entière³⁷.

Générer : rendre explicite la connaissance implicite — à trois niveaux : technique (standards, patterns architecturaux), projet (priorités, scope, historique des décisions), et business (conformité, attentes client, contraintes réglementaires). La plupart des équipes ne fournissent que le premier niveau à leurs agents.

Évaluer : appliquer les principes du TDD au contexte. Définir des scénarios de comportement attendu, exécuter les agents, mesurer statistiquement les sorties (les LLMs étant non-déterministes). Chaque échec d'évaluation révèle non pas un défaut de l'agent, mais une spécification non écrite.

Distribuer : traiter le contexte comme un package versionné et sécurisé. L'insight structurel de Debois : pour la première fois, il existe une raison égoïste de partager la connaissance — un meilleur contexte améliore directement les interactions de celui qui l'a produit, en plus de bénéficier à l'équipe.

Observer : fermer la boucle. En production, les agents révèlent les lacunes du contexte par leurs questions, leurs choix inattendus, leurs improvisations. Ces signaux alimentent le cycle suivant.

L'effet volant d'inertie (Context Flywheel) de Debois est la thèse la plus forte pour les grandes équipes : la première itération capture les conventions ; la dixième transforme la façon dont toute l'équipe code. Plus vite, plus cohérent, moins de corrections. Le fossé concurrentiel n'est ni dans les outils (qui convergent) ni dans les modèles (qui se commoditisent) — il est dans la connaissance produit accumulée pendant deux ans.

Un avertissement mérite d'être gardé à l'esprit : des fenêtres de contexte infinies ne résolvent pas le problème. Plus de contexte signifie plus de contradictions potentielles. Le défi ne passe pas de la curation à une fenêtre plus large — il passe de la curation à la gouvernance.

Thariq, ingénieur chez Anthropic, le documente pratiquement : avec une fenêtre de 1 million de tokens, le phénomène de context rot — dégradation des performances quand le contexte se dilue sur trop de tokens — commence à se manifester vers 300 000 à 400 000 tokens⁸. La question n'est pas d'avoir un contexte plus grand. C'est d'avoir un contexte plus pertinent.

Risques et limites : ce que les vitrines ne montrent pas

Cherny est honnête sur les limites de son propre setup : "coding is solved" vaut pour TypeScript/React, sur une codebase relativement propre, avec un développeur expert qui supervise des centaines d'agents. Ce n'est pas la situation d'une ESN qui déploie des agents sur le système de facturation d'une banque de détail, écrit en Java 8, avec une couverture de tests à 20%.

Plusieurs risques structurels méritent d'être nommés.

La spec obsolète est le mode de défaillance principal. Vasilopoulos l'identifie explicitement : une spécification incorrecte ou périmée n'est pas neutre — elle induit activement en erreur l'agent, qui la suit consciencieusement. Le contexte pourrit, et il le fait silencieusement. Les équipes qui maintiennent des CLAUDE.md ou des constitutions sans revue régulière accumulent de la dette contextuelle qui se matérialisera en bugs difficiles à tracer.

La supervision reste coûteuse sur le code de production complexe. Charlie Dai (Forrester) signale que sur les projets à grande échelle, le coût de la supervision senior peut équivaloir à l'embauche d'un développeur. L'agentic coding ne supprime pas le besoin de revue — il le déplace. La question est de savoir si ce déplacement libère du temps de conception ou crée simplement un nouveau goulot à l'étape de relecture.

Les langages et architectures exotiques restent un terrain difficile. Les modèles ont été entraînés sur des corpus massivement biaisés vers certains stacks (TypeScript, Python, Go). Sur du COBOL, du PL/SQL legacy, ou des DSLs propriétaires, les performances chutent significativement. L'adoption reste inégale — l'Anthropic Economic Index le confirme : les régions et entreprises à fort taux d'adoption présentent des usages diversifiés, tandis que celles qui débutent se concentrent sur le codage, souvent dans des conditions moins complexes⁵.

Le contexte comme surface d'attaque. Debois le soulève : un contexte centralisé et largement distribué est une cible. Les dépendances de contexte méritent la même posture de sécurité dans la chaîne d'approvisionnement que les dépendances de code.

Ce que SFEIR observe sur le terrain

Sur les missions d'accompagnement de grandes organisations industrielles — de Stellantis à Airbus, de Société Générale à EDF — SFEIR observe une tension constante entre la vitesse des agents et la complexité des codebases héritées. La promesse de productivité x10 de l'approche AI for IT de Didier Girard — "écrire du code est désormais un anti-pattern, on ne doit plus produire de code manuellement" — est atteignable. Mais elle suppose un investissement préalable dans l'architecture du contexte qui n'est pas optionnel.

Ce que les équipes qui échouent ont en commun : elles activent les agents sans avoir construit la mémoire institutionnelle qui leur permet de comprendre le projet. Ce que les équipes qui réussissent font différemment : elles traitent la constitution du dépôt, les spécifications d'agents, la knowledge base comme de l'infrastructure — versionnable, testable, maintenable.

La doctrine Single Owner du framework AI for IT s'applique aussi à ce niveau : quelqu'un doit posséder le contexte, l'auditer, le faire évoluer. Sans ownership explicite, le contexte pourrit. Exactement comme la documentation avant lui. Exactement comme l'infrastructure avant elle.

Points clés

• Le vrai goulot n'est pas la génération de code — c'est la compréhension du code existant. Google l'a identifié comme "one of the biggest, most expensive bottlenecks in software development."² Les agents reproduisent ce problème : sans mémoire persistante, chaque session repart de zéro.
• Le Context Engineering est la réponse opérationnelle. L'architecture 3 tiers — Constitution (Hot Memory), Agents spécialisés (Warm Memory), Knowledge Base via MCP (Cold Memory) — documentée empiriquement par Vasilopoulos sur 283 sessions, est le cadre le plus robuste disponible à ce jour.⁴
• Le Context Development Lifecycle de Patrick Debois traite le contexte comme du code. Générer, Évaluer, Distribuer, Observer : un cycle itératif qui crée un volant d'inertie contextuel. L'avantage compétitif est dans la connaissance accumulée sur deux ans, pas dans le choix d'outil.³
• Le débit est possible — et il est documenté. Quelques dizaines de PRs par jour, 150 en record, des milliers d'agents la nuit. Mais ce débit est corrélé à la qualité du contexte fourni, pas à la puissance brute du modèle.¹
• Les coûts croissent avec la base de code. La tension GPU, les coûts de licence modèles, et la consommation de tokens liée à la complexité rendent le context engineering non seulement utile mais économiquement nécessaire.⁶
• La spec obsolète est le mode de défaillance principal. Un contexte incorrect induit activement l'agent en erreur. La maintenance du contexte (1 à 2 heures par semaine selon Vasilopoulos) est une dépense opérationnelle, pas un coût optionnel.⁴
• Fenêtres de contexte infinies ≠ problème résolu. Plus de tokens disponibles signifie plus de contradictions potentielles à gérer. Le défi passe de la curation à la gouvernance.⁸

Sources

1. Boris Cherny (Anthropic), intervention Sequoia AI Ascent — youtube.com, 5 mai 2026.
2. Google, Introducing Code Wiki: accelerating your code understanding — developers.googleblog.com, 13 novembre 2025.
3. Patrick Debois (Tessl), Context Development Lifecycle — tessl.io, 19 février 2026.
4. Aristidis Vasilopoulos, Context Engineering for a 108k-line C# system — arxiv.org, 24 février 2026.
5. Anthropic, Anthropic Economic Index — September 2025 Report — anthropic.com, 15 septembre 2025.
6. InfoWorld, The era of cheap AI coding assistants may be over — infoworld.com, 15 septembre 2025.
7. Patrick Debois (Tessl), The Context Flywheel — tessl.io, 26 février 2026.
8. Thariq (Anthropic) — x.com, 14 avril 2026.