Cela fait une semaine que je travaille sur la création de workflows d'agent IA et du coup j'ai décidé de me remettre à mon travail en les utilisant.
Mais je me suis aperçue que les workflows d'IA classiques type tdd ne sont pas adaptés pour faire des fix.
Le workflow avait déjà dépensé plusieurs milliers de tokens, et il n'avait pas résolu le problème. Donc j'ai du guider et superviser l'IA qui a fini par le résoudre.
C'est là que je me suis demandé, faudrait il ne pas tout corriger sur une fonctionnalité donnée plutôt que de chercher le bug dans la fonctionnalité...
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
Le paradoxe de l'IA : excellente en création, médiocre en maintenance
Greenfield vs brownfield : deux mondes pour l'agent IA
En développement logiciel, on distingue deux contextes fondamentalement différents.
Le greenfield, c'est la construction neuve : on part d'une feuille blanche, on crée l'architecture, on écrit le code sans contrainte héritée.
Le brownfield, c'est la maintenance et l'évolution d'un existant : on intervient dans un « immeuble déjà construit » dont on n'a ni les plans originaux, ni l'historique complet des rénovations.
En greenfield, l'agent IA maîtrise parfaitement le contexte. Et pour cause : c'est lui qui a créé le code.
Il connaît chaque décision architecturale, chaque convention adoptée, chaque dépendance choisie. Le contexte est explicite, contenu dans la conversation, et le périmètre est défini.
En brownfield, tout change. L'agent arrive dans un système qu'il n'a pas construit. Il ne voit qu'une fraction du code à chaque session. Il ne connaît pas l'historique des décisions.
Et surtout, il ne peut pas inférer ce que The Friday Deploy appelle les « contrats invisibles » : ces hypothèses implicites sur les flux de données, ces particularités d'intégration, ces règles métier encodées dans le code que personne n'a documentées parce que « tout le monde le sait ».
L'étude publiée sur arXiv autour du framework D3 confirme ce diagnostic : les systèmes legacy posent des défis uniques liés à la documentation incomplète et aux connaissances architecturales fragmentées.
L'IA excelle quand le périmètre est défini et le contexte explicite ; elle échoue quand le contexte est implicite et distribué dans des dizaines de fichiers, l'historique git, la documentation, les tickets, et surtout la tête des développeurs.
Les chiffres qui confirment le décalage
Les données empiriques convergent toutes dans la même direction. Voici un récapitulatif des études les plus significatives :
| Source | Donnée clé | Impact |
|---|---|---|
| METR (juillet 2025) | Développeurs 19 % plus lents avec IA sur des projets existants complexes | Essai contrôlé randomisé sur 16 développeurs, repos de 22k+ stars |
| ThoughtWorks (via StartupHakk) | Le débugage IA échoue dans plus de 70 % des cas complexes | Taux d'échec massif sur la maintenance |
| CodeRabbit (décembre 2025) | Le code IA contient 1,7x plus de défauts, 2,25x plus d'erreurs de logique métier | Analyse de milliers de pull requests |
| Stack Overflow Survey 2025 | Confiance dans la précision IA : 29 % (en baisse de 40 % un an plus tôt) | Désillusion mesurable des développeurs |
| Stack Overflow Survey 2025 | 45 % des développeurs citent les « solutions presque correctes » comme frustration principale | Le problème du « presque juste » |
| IEEE Spectrum | Des tâches de cinq heures passent à sept ou huit heures avec l'IA | Dégradation silencieuse de la productivité |
Pourquoi les agents IA échouent au débugage
Le constat chiffré est clair, mais il faut comprendre les causes structurelles. Trois facteurs expliquent pourquoi le débugage est fondamentalement plus difficile que la construction pour un agent IA.
Le problème de la fenêtre de contexte
Les modèles frontière offrent aujourd'hui un à deux millions de tokens de contexte. Cela semble colossal, mais une application complexe dépasse largement cette limite quand on considère l'ensemble de la codebase, les configurations, les tests, la documentation et l'historique.
En pratique, cela signifie que l'agent travaille toujours avec une vue partielle du système. Et cette vue partielle se dégrade.
Factory.ai a documenté le phénomène de « Context Rot » : la qualité de raisonnement du modèle se dégrade de manière non-uniforme bien avant d'atteindre la limite théorique de la fenêtre de contexte.
La recherche vectorielle naïve, utilisée par la plupart des outils pour injecter du contexte pertinent, « aplatit la structure du code » et détruit les relations entre composants.
Le code est aussi « dense en tokens », comme le souligne Agiflow : une seule ligne de code se traduit en plus de tokens qu'une ligne de langage naturel.
Le scan de multiples fichiers, l'analyse de logs, les vérifications statiques — chaque étape du débugage brûle des tokens sans nécessairement rapprocher de la solution.
La métaphore est parlante : l'IA essaie de résoudre un puzzle de mille pièces en ne voyant que cinquante pièces à la fois. Et ces cinquante pièces changent à chaque tour.
En greenfield, tout le contexte est dans la conversation.
En brownfield, l'information critique est fragmentée, éparpillée entre le code, les configurations, les messages de commit et les connaissances tacites de l'équipe — autant de sources que l'agent ne peut pas reconstituer dans une seule fenêtre de contexte.
L'absence de modèle mental global
Le débugage humain repose sur un modèle mental du système. Quand un développeur senior enquête sur un bug, il raisonne en termes de flux : « si je tire ce fil ici, quels composants sont affectés ? ».
Il pose des questions que l'IA ne sait pas formuler : « Qu'est-ce qui a changé récemment ? », « Est-ce un symptôme d'un problème plus profond ? », « Ce pattern, je l'ai déjà vu, et la dernière fois la cause était ailleurs ».
L'IA n'a pas de modèle mental persistant entre les sessions. Elle « redécouvre » l'architecture à chaque conversation.
Elle ne peut pas reproduire l'intuition du développeur expérimenté : ce mélange de contexte historique et de reconnaissance de patterns qui fait que le senior trouve la cause racine en dix minutes là où le junior cherche pendant des heures.
Comme le formule Addy Osmani, ingénieur senior chez Google Chrome : « Traitez le code IA comme le travail d'un développeur junior ».
Relire et tester systématiquement. L'erreur courante est de faire confiance aveuglément à une correction proposée par l'agent parce qu'elle compile et qu'elle « a l'air logique ».
L'IA corrige ce qu'elle voit, pas ce qu'elle comprend. La différence est fondamentale en débugage.
L'effet boule de neige : quand le fix crée des régressions
C'est peut-être le problème le plus insidieux. Comme le note StartupHakk, l'IA « comble les lacunes avec des suppositions éclairées — ce qui mène souvent à plus de bugs ».
Les corrections proposées par l'agent compilent, passent les tests immédiats, et semblent fonctionner. Mais elles introduisent des bugs silencieux, des effets de bord que personne ne détecte avant qu'il ne soit trop tard.
Le rapport CodeRabbit quantifie le risque : le code IA produit 2,29x plus de problèmes de concurrence et 2,74x plus de vulnérabilités XSS que le code humain.
Quand cet agent « corrige » du code existant, il superpose ses propres biais sur un système qu'il ne comprend pas entièrement.
Le résultat est une boucle de débugage infernale : le fix A casse B, le fix B casse C, le fix C recasse A.
VentureBeat rapporte que l'impossibilité de sortir d'une boucle de corrections défaillantes dans un même thread gaspille un temps de développement considérable. Le sondage Stack Overflow 2025 confirme : 66 % des développeurs passent plus de temps à corriger du code IA « presque correct » que prévu.
C'est le piège du « presque juste ». La correction a l'air bonne. Elle passe les tests évidents. Mais elle a déplacé le problème, et deux jours plus tard un autre bug émerge, plus subtil, plus difficile à tracer. La spirale est lancée.
Le coût réel du débugage IA : retour d'expérience sur un projet SvelteKit 5
Le contexte : un projet full-stack avec de nombreuses dépendances
Je travaille depuis plusieurs mois sur une application SvelteKit 5 full-stack, avec de nombreuses dépendances et intégrations tierces.
Le projet avait été largement construit avec l'assistance d'agents IA, et cette phase de construction s'était remarquablement bien passée. L'IA était dans son élément : greenfield pur, contexte explicite, architecture qu'elle avait elle-même contribué à dessiner.
Les problèmes sont apparus dès la phase de maintenance. Des corrections de bugs, des ajustements de logique métier, des adaptations d'intégration. Des tâches que tout développeur considère comme « normales » dans le cycle de vie d'un projet. Sauf qu'avec l'agent IA, rien n'était normal.
L'agent perdait le fil. Il ne voyait qu'une partie du code à chaque session. Il ne comprenait pas les effets de bord entre les composants. Il proposait des corrections qui passaient les tests locaux mais cassaient d'autres parties de l'application.
Et surtout, il consommait une quantité déraisonnable de tokens pour des corrections mineures — parce que chaque tentative nécessitait de recharger le contexte, d'analyser les fichiers, de proposer un fix, de vérifier les résultats, et de recommencer quand la correction ne fonctionnait pas.
Dans notre expérience, l'outil qui m'avait impressionné en construction est devenu une source de frustration en maintenance.
Quand le débugage coûte plus cher que la reconstruction
Le moment de bascule est arrivé sur un module qui concentrait plusieurs intégrations et une logique d'état complexe. Un bug d'affichage apparemment anodin. L'agent IA a proposé un premier fix. Le fix a corrigé le symptôme visible mais introduit une régression dans un autre composant.
Deuxième tentative : la régression est corrigée, mais le comportement initial réapparaît dans un cas limite.
Troisième tentative, puis quatrième : l'agent commence à tourner en rond, proposant des variations mineures de la même approche, chacune brûlant des tokens pour recharger et analyser le contexte.
La consommation de tokens explosait. Environ 200 000 tokens sur quatre tentatives, et six heures de va-et-vient pour un résultat partiel. Chaque tentative nécessitait de recharger le contexte, d'analyser les fichiers concernés, de proposer un correctif, de vérifier les résultats.
Après la quatrième tentative échouée, j'ai pris la décision de pivoter : reconstruire le module entier from scratch avec l'IA, en utilisant les spécifications fonctionnelles et les tests existants comme guide.
Le résultat a été frappant. La reconstruction a consommé environ 60 000 tokens en deux heures et demie — une fraction du temps et des tokens engloutis par les tentatives de débugage. Le module reconstruit fonctionnait du premier coup, avec une couverture de tests en prime.
| Opération | Tokens estimés | Temps | Résultat |
|---|---|---|---|
| Construction initiale du module | ~50 000 | 2 h | Fonctionnel |
| Tentatives de debug (x4) | ~200 000 | 6 h | Échec partiel |
| Reconstruction complète | ~60 000 | 2 h 30 | Fonctionnel + testé |
L'IA était de retour en greenfield, son terrain de prédilection, et la différence d'efficacité était spectaculaire.
Ce n'est pas un cas isolé. Les données de Glide le confirment : certains développeurs ont dépensé plus de 1 000 $ en tokens pour des corrections, et des agents consomment 100x plus de tokens pendant le débugage par rapport à une tâche de construction équivalente.
La spirale de dette technique ne fait qu'aggraver le problème : le code IA, avec 1,7x plus de défauts et 8x plus de code dupliqué (Salesforce Ben), crée une dette qui rend le débugage encore plus difficile. Forrester prédit que 75 % des décideurs technologiques feront face à une dette technique modérée à sévère d'ici 2026. La corrélation avec l'adoption massive du code généré par IA n'est pas une coïncidence.
Le framework décisionnel : corriger ou reconstruire ?
Plutôt que de naviguer à l'instinct, j'ai formalisé un cadre de décision basé sur quatre critères objectifs. Ce framework n'a pas la prétention d'être universel, mais il fournit une structure de réflexion qui transforme la frustration en stratégie.
Les 4 critères de la décision
1. Taille du module
La taille du module est le premier filtre. Elle détermine si le contexte nécessaire au débugage tient dans la fenêtre de contexte de l'agent.
- Petit (< 500 lignes) : la correction est généralement viable. Le contexte complet du module tient dans la fenêtre, et l'agent peut raisonner efficacement.
- Moyen (500-2 000 lignes) : zone grise. Il faut évaluer les autres critères avant de décider.
- Grand (> 2 000 lignes) : envisager la reconstruction, surtout si le module est mal structuré. Le contexte sera nécessairement partiel.
2. Niveau de couplage
Le couplage détermine la faisabilité de la reconstruction, pas seulement du débugage.
- Faible (interfaces claires, contrats explicites) : reconstruction facile. Le module peut être remplacé indépendamment sans casser les intégrations.
- Fort (dépendances croisées, état partagé) : correction préférable avec supervision humaine. La reconstruction risque de casser les intégrations existantes.
3. Couverture de tests
Les tests sont le facteur multiplicateur de toute décision.
- Élevée (> 80 %) : corriger avec confiance. Les tests servent de filet de sécurité et d'ancre de contexte pour l'IA — ils définissent le comportement attendu sans ambiguïté.
- Faible (< 30 %) : reconstruire avec une approche test-first. Sans filet de sécurité, l'IA ne peut pas valider ses propres corrections.
4. Nombre de tentatives échouées
C'est la « règle des trois tentatives » : si l'IA a échoué trois fois à corriger le bug, il faut pivoter vers la reconstruction. Chaque tentative supplémentaire consomme des tokens et risque d'aggraver le problème par des régressions en cascade.
La matrice de décision
| Critère | Corriger | Évaluer au cas par cas | Reconstruire |
|---|---|---|---|
| Taille | < 500 lignes | 500 - 2 000 lignes | > 2 000 lignes |
| Couplage | Fort (risque de casser les intégrations) | Moyen | Faible (interfaces claires) |
| Tests | > 80 % de couverture | 30 - 80 % | < 30 % |
| Tentatives | Première ou deuxième tentative | Troisième tentative | Plus de trois tentatives |
Lecture de la matrice : si la majorité des critères pointent vers « corriger », corriger. Si la majorité pointent vers « reconstruire », reconstruire. En cas de partage, le nombre de tentatives échouées tranche.
L'arbre de décision en pratique
Le bug est-il dans un module < 500 LOC ?
├── OUI --> Le module a-t-il des tests > 80 % ?
│ ├── OUI --> CORRIGER (l'IA a le contexte et le filet de sécurité)
│ └── NON --> Écrire les tests d'abord, puis CORRIGER
└── NON --> Le module est-il faiblement couplé ?
├── OUI --> RECONSTRUIRE (repartir de zéro avec les specs et les tests)
└── NON --> Le bug est-il isolable dans une sous-section ?
├── OUI --> CORRIGER la sous-section uniquement
└── NON --> RECONSTRUIRE avec supervision humaine renforcée
Règle transversale : après trois tentatives de correction échouées, pivoter vers la reconstruction quel que soit le résultat de l'arbre.
Cas concrets : quand corriger, quand reconstruire
| Situation | Décision | Justification |
|---|---|---|
| Bug CSS dans un composant isolé (80 lignes) | Corriger | Petit module, contexte complet, pas d'effets de bord |
| Problème d'authentification traversant cinq fichiers | Reconstruire le module auth | Couplage élevé, contexte trop distribué, risque de régressions en cascade |
| Race condition dans un hook de gestion d'état (300 lignes, zéro test) | Reconstruire avec tests-first | Pas de filet de sécurité, l'IA ne peut pas valider ses corrections |
| Bug de logique métier dans un service bien testé (1 200 lignes, 90 % couverture) | Corriger | Les tests guident l'IA et valident le fix |
Stratégies pour maximiser l'efficacité du débugage IA
Quand on choisit de corriger — et c'est souvent le bon choix pour les petits modules bien testés — il existe des stratégies concrètes pour maximiser les chances de succès de l'agent.
L'architecture modulaire : le prérequis oublié
Des modules découplés avec des interfaces claires sont des modules que l'IA peut comprendre isolément. Le monolithe est l'ennemi du débugage IA : trop de contexte nécessaire, trop de dépendances implicites, trop d'effets de bord possibles.
En pratique, cela signifie investir dans la modularité bien avant d'avoir un bug à corriger. Des fichiers de taille raisonnable, des responsabilités clairement séparées, des contrats d'interface explicites. Factory.ai confirme que des contextes plus petits et ciblés surpassent systématiquement les contextes massifs en termes de qualité de raisonnement de l'agent.
Investir dans la modularité aujourd'hui, c'est investir dans la « debuggabilité IA » de demain. Ce n'est pas un luxe architectural, c'est une nécessité opérationnelle.
Le CLAUDE.md comme GPS de la codebase
Les guides d'Anthropic recommandent d'utiliser un fichier CLAUDE.md comme « ancre de contexte persistante entre les sessions ». Ce fichier documente l'architecture, les conventions, les patterns utilisés, les pièges connus. Pour chaque module : ses responsabilités, ses dépendances, ses invariants.
L'approche « just-in-time » préconisée par Anthropic consiste à charger les données à la demande plutôt que de tout pré-charger. Un CLAUDE.md bien structuré permet à l'agent de savoir où chercher l'information pertinente sans saturer sa fenêtre de contexte.
Dans notre expérience, un CLAUDE.md détaillé compense partiellement l'absence de modèle mental persistant chez l'IA. L'agent ne « comprend » pas l'architecture au sens humain du terme, mais il dispose au moins d'une carte de navigation fiable. Addy Osmani recommande la même approche : utiliser des fichiers d'instructions personnalisés pour imposer un style et des contraintes à l'agent, réduisant ainsi la surface d'erreur.
Les tests comme ancre de contexte et filet de sécurité
Les tests automatisés jouent un double rôle dans le débugage assisté par IA. D'abord, ils définissent le comportement attendu sans ambiguïté — c'est le meilleur « contexte » qu'on puisse donner à l'agent. Ensuite, ils servent de filet de sécurité en détectant les régressions avant qu'elles n'atteignent la production.
Le pattern dual-agent documenté dans le framework D3 (arXiv) formalise cette approche : un agent qui construit, un agent qui révise. Les résultats sont significatifs : 83 % des praticiens passent moins de temps à corriger le code grâce à une meilleure planification initiale et une révision systématique.
Les commits granulaires, comme le recommande Addy Osmani, fonctionnent comme des « save points ». Revenir en arrière devient indolore en cas de régression introduite par l'agent. Et quand un modèle se bloque dans une boucle, changer de modèle IA peut débloquer la situation : chaque outil a ses angles morts, et un regard algorithmique différent peut identifier ce que le premier a manqué.
Savoir quand « reset » le contexte
Le signe le plus fiable d'une boucle de débugage improductive : l'agent répète les mêmes corrections avec des variations mineures, les tokens s'accumulent, et le bug persiste. À ce stade, continuer dans le même thread est contre-productif.
La compaction de contexte, documentée par Anthropic, consiste à résumer l'historique de conversation quand on approche des limites de la fenêtre. En pratique, c'est souvent plus efficace de démarrer un nouveau thread avec un résumé précis du problème et des tentatives déjà effectuées.
Les sub-agents spécialisés offrent une alternative structurelle : un agent par module plutôt qu'un agent pour tout le projet. Chaque sub-agent opère avec un contexte restreint et ciblé, ce qui correspond exactement aux conditions où l'IA performe le mieux.
L'erreur courante est de demander à l'IA de « corriger l'application ». La bonne approche : « corriger cette fonction en respectant ces tests ». Un périmètre clair, un objectif mesurable, un filet de sécurité explicite. Comme le résume Addy Osmani : les pratiques classiques du génie logiciel deviennent plus importantes avec l'IA, pas moins.
Récapitulatif des stratégies
| Stratégie | Principe | Impact attendu |
|---|---|---|
| Architecture modulaire | Modules découplés avec interfaces claires | Contexte isolé, reconstruction facilitée |
| CLAUDE.md comme GPS | Ancre de contexte persistante entre sessions | Compensation partielle de l'absence de modèle mental |
| Tests comme ancre de contexte | Définir le comportement attendu sans ambiguïté | Filet de sécurité + guide pour l'agent |
| Reset de contexte | Nouveau thread avec résumé ciblé | Sortie des boucles de débugage improductives |
Conclusion : l'IA est un bâtisseur, pas encore un réparateur
Les agents IA ont transformé la construction de logiciels. Sur ce point, les données sont sans ambiguïté : 80 % des développeurs les utilisent (Stack Overflow 2025), et à raison. Construire une application avec l'assistance d'un agent IA est plus rapide, souvent plus structuré, et — pour les projets greenfield — remarquablement efficace.
Mais le débugage reste le territoire du développeur humain assisté, pas de l'agent autonome. Ce n'est pas un réquisitoire anti-IA. C'est un constat lucide sur les forces et faiblesses actuelles des outils. L'IA excelle avec un périmètre clair, un contexte explicite et un objectif mesurable. Le débugage d'applications complexes est l'exact opposé : périmètre flou, contexte distribué, objectif parfois mal défini.
Le framework présenté dans cet article n'est pas une solution miracle. C'est une boussole. Au lieu de s'acharner sur un fix qui tourne en boucle, pivoter consciemment vers la reconstruction quand les critères le justifient. Taille du module, niveau de couplage, couverture de tests, nombre de tentatives : quatre variables suffisent pour prendre une décision éclairée plutôt qu'une décision frustrée.
Les modèles vont s'améliorer. Les fenêtres de contexte vont s'agrandir. Le context engineering va mûrir comme discipline. Mais aujourd'hui, la meilleure stratégie reste de jouer sur les forces de l'IA : lui donner des périmètres clairs, des contextes explicites, et des filets de sécurité solides. Et quand le débugage tourne en rond, avoir le réflexe de se poser la question : « Est-ce que je ne devrais pas reconstruire ce module plutôt que chercher cette fuite indéfiniment ? »
L'IA est comme un architecte brillant qui peut concevoir un immeuble en un temps record, mais qui peine à identifier une fuite dans la plomberie d'un bâtiment qu'il n'a pas conçu. La bonne stratégie ? Parfois, il faut refaire la salle de bain plutôt que de chercher la fuite indéfiniment.
Et vous, quel est votre seuil pour décider entre corriger et reconstruire ? Quels critères utilisez-vous ? Partagez vos retours d'expérience — c'est exactement le type de connaissance collective qui manque encore dans notre industrie.
Qui suis je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le coeur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr
Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA.
Débuguer une application construite par l'IA : faut-il corriger ou tout reconstruire ?