Dette technique et agents de code IA : les méthodes qui marchent pour un code maintenable
C’est la problématique du moment dans l’IA générative : comment minimiser la dette technique du code généré chaque jour par l’intelligence artificielle ? Avec le recours quasi systématique aux agents de code, les entreprises font face à des contraintes de maintenabilité à long terme du code. Mais de bonnes pratiques et des solutions techniques existent pour maximiser la maintenabilité du code et se rapprocher, voire surpasser, les standards historiques.
Plus de code, plus vite, mais pas forcément meilleur
Le constat est partagé par la majorité des entreprises : les agents de code (Claude Code, GitHub Copilot, Codex, Gemini CLI) permettent de produire des fonctionnalités à un rythme sans précédent, mais cette accélération a un revers. Sans cadre méthodologique rigoureux, le code livré accumule des défauts structurels qui deviennent coûteux à corriger. "L'IA, si on ne la guide pas, va choisir des options qui ne sont pas forcément compatibles avec l'architecture du projet", résume Nicolas Gaudemet, chief AI officer de Onepoint. Les failles de sécurité, notamment, ne sont pas un sujet auquel l'agent prête attention spontanément si rien ne l'y contraint. Côté dépendances, le risque est double : l'IA peut s'appuyer sur des librairies tierces sans vérifier leur compatibilité avec la version utilisée dans le projet, ou à l'inverse, redévelopper des briques qui existent déjà dans la codebase, faute de savoir qu'elles sont disponibles.
Chez SNCF Connect & Tech, l'adoption de l'IA pour le code a été généralisée début 2024 sous forme d'autocomplétion, puis étendue aux agents en mode conversationnel courant 2025. Le vibe coding a rapidement suscité des retours mitigés parmi les 800 collaborateurs tech de l'entreprise. "On s'est assez rapidement rendu compte que cette manière de travailler n'était pas la plus optimale", explique Emmanuel Cordente, CTO de SNCF Connect & Tech. Décrire ses besoins sous forme de chat était trop imprécis, et surtout insuffisant. Résultat, beaucoup de reprises de code, une variabilité forte d'une génération à l'autre, et un gain de temps réel en deçà des attentes.
Donner du contexte pertinent et ciblé à votre agent de code
On le savait déjà, l’absence de contexte pertinent est le principal point de blocage des agents qui ne passent en production en entreprise. Dans le cas des agents de code, le contexte revêt un caractère encore plus important. La qualité du code généré par IA est directement proportionnelle à la qualité du contexte qu'on lui fournit. Conventions de nommage, méthodes d'implémentation propres au projet, architecture cible, version des langages et des frameworks utilisés, composants existants à réutiliser… Autant d'informations que l'agent ne peut pas deviner si personne ne les lui transmet. "C'est comme un humain : si on ne lui dit pas où sont les choses, il ne va pas les chercher au bon endroit", résume Nicolas Gaudemet.
En pratique, ce contexte se structure dans des fichiers dédiés, principalement des fichiers agent.md (lus par l'agent au démarrage de chaque tâche) et des skills spécialisés par domaine, par exemple un jeu de règles distinct pour le front-end et pour le back-end. Chez Suadeo, éditeur de plateforme data et IA, cette approche est industrialisée : règles de développement, conventions de nommage, structure des objets métier, tout est décrit et transmis à l'agent. "On fonctionne avec l'IA comme on fonctionne avec des développeurs. On a des règles de nommage, des skills qui expliquent comment coder chaque méthode", détaille Mohamed Bendjebbour, responsable R&D de l'entreprise.
L'enjeu, toutefois, n'est pas d'empiler de la documentation. La fenêtre de contexte des LLM reste limitée, et la surcharger dégrade les performances de l'agent. Emmanuel Cordente insiste sur cet arbitrage : il ne faut pas réexpliquer ce que le modèle sait déjà, mais concentrer le contexte sur ce qui est spécifique au projet et à l'organisation. Chez SNCF Connect & Tech, le choix a été fait de stocker cette documentation directement dans le repository git. Le recours aux MCP complète le dispositif en permettant à l'agent d'accéder à la documentation à jour des librairies et des langages, point critique quand on sait que les modèles sont souvent entraînés sur des versions antérieures. L'autre piège à éviter : laisser la documentation décrocher du code au fil des itérations. Si l'on ne demande pas explicitement à l'agent de mettre à jour la documentation après chaque modification, le décalage s'installe et le contexte perd progressivement sa valeur.
Travailler en mode spec driven
Fournir du contexte est nécessaire, mais ne suffit pas si la demande du développeur, elle-même, reste floue. C'est le constat qui a poussé SNCF Connect & Tech à structurer son approche agentique en mode Spec Driven Development. Le but ? Spécifier précisément ce que l'on attend avant de laisser l'agent coder. Après une phase d'expérimentation menée en 2025 avec des agents développés en interne, l'entreprise s'appuie désormais sur des frameworks open source comme SpecKit et BMAD pour industrialiser la démarche. Le premier permet de structurer le développement en quatre phases (spécification, plan, découpage en tâches, implémentation). Le second va encore plus loin en simulant une équipe agile complète avec des agents spécialisés par rôle (Product Manager, Architecte, Scrum Master…). "L'objectif, c'est de corriger le problème principal qu'on avait avec le vibe coding, c'est l'aléatoire. On veut décrire pour avoir une variabilité très faible dans la production de l'IA", résume le CTO de SNCF Connect & Tech
Mais sans aller jusqu'à adopter un framework spec driven complet, la règle primordiale est de toujours planifier avant toute modification importante ou ajout de fonctionnalité. Il faut demander à l'agent de proposer un plan et le challenger ensuite (ou d’utiliser le mode plan, quand il existe). "Il ne faut pas le laisser foncer tête baissée dans une solution, mais lui demander d'abord quelles sont les options possibles et de proposer un plan", insiste Nicolas Gaudemet. Côté agent, Kiro d’AWS intègre nativement cette logique spec driven : l'outil transforme un prompt en spécifications structurées, puis en design technique et en tâches d'implémentation, avant de générer le moindre code.
Des revues de code fiables et multi-niveaux
Même avec un contexte riche et des spécifications bien construites, la revue de code reste le passage obligé avant toute mise en production. "Aucune ligne de code généré par IA ne doit passer en production sans validation humaine, sinon c'est un chèque en blanc", tranche Mohamed Bendjebbour. Le volume de code généré par les agents crée mécaniquement une pression sur cette étape. "AWS a dû remettre en place des revues de code humaines systématiques après avoir constaté que le rythme de livraison générait des failles de sécurité en production", rappelle Nicolas Gaudemet.
Pour autant, ce goulot d'étranglement se réduit considérablement quand les étapes amont sont bien exécutées. Un code produit avec les bonnes conventions, planifié et découpé en tâches unitaires, se revoit beaucoup plus vite qu'un bloc monolithique généré en vibe coding. L'autre levier est d'utiliser l'IA elle-même pour pré-filtrer. Il est par exemple possible de faire revoir le code par un agent séparé, dans une conversation distincte, pour éviter les biais du premier agent. Croiser plusieurs modèles d'IA est également une bonne pratique, avant la validation humaine. Le principe est toujours le même : plusieurs niveaux de contrôle automatisés, puis un humain qui tranche sur les fichiers sensibles et l'architecture.
Un code maintenable, bien spécifié et conforme aux conventions du projet se revoit plus vite, se débogue plus vite, et génère moins de reprises en aval. Le temps investi dans le cadrage en amont (contexte, spécifications, règles) se récupère largement en réduction des reprises de code en aval. Ainsi, au-delà de réduire la dette technique, un code maintenable permet paradoxalement de shipper plus vite.