Au cours des dernières années, on a empilé beaucoup de pratiques autour du développement : standards de code, linting, règles de pull request, portes de QA, couches de tests, validations avant déploiement et monitoring après la mise en production. On a construit tout ça pour garder la production stable et le code maintenable.
Ces pratiques reposaient sur une contrainte centrale : le temps des développeurs coûtait cher, alors il fallait réduire au minimum le travail à refaire. Depuis l’an dernier, l’IA agentique commence à remettre cette hypothèse en question.
La question que l'IA soulève
Quand j’écoute les conversations actuelles sur l’IA, surtout autour des workflows agentiques, un récit revient souvent : passer de l’idée à la production avec très peu de friction. Valider la spécification au début, valider le résultat à la fin, puis accorder moins d’attention au code entre les deux.
Ce modèle est séduisant, mais il me laisse avec des questions.
Le point de tension, pour moi, est très concret : le processus compte encore, la qualité du code compte encore, et la qualité des tests compte encore. Si les humains participent moins à la rédaction et davantage à la validation, la responsabilité doit être explicite au lieu d’être présumée.
Entre promesse et réalité
De mon côté, la réalité n’est ni noire ni blanche. L’IA est déjà utile, mais le rythme des changements est difficile à absorber. Des choses qui semblaient impensables au début de 2025 sont devenues normales au début de 2026.
Au cours de la dernière année, on a essayé plusieurs usages : génération de code, assistants de revue, rédaction de tests, exploration de bases de code, et même des fichiers d’orientation dans les dépôts pour aider les outils à comprendre la structure et les standards. Une partie a très bien fonctionné, surtout sur les projets plus récents.
La partie la plus difficile, c’est le code hérité. La plupart de nos systèmes n’ont pas été pensés pour l’IA. On traîne des structures anciennes, de la complexité accumulée et une documentation inégale. Dans ce contexte, même des développeurs expérimentés ont besoin de temps pour bien comprendre.
S’attendre à ce qu’un agent fasse constamment mieux sans ce contexte me semble optimiste.
Des réactions différentes, des limites temporaires
Cet écart entre la promesse et le contexte explique pourquoi les réactions varient autant. Certains développeurs s’appuient beaucoup sur l’IA. D’autres résistent, parce que le code généré ne respecte pas toujours les standards locaux ou semble demander plus de corrections qu’un départ à zéro.
On a aussi commencé à voir des effets secondaires : des PR trop volumineuses, une qualité de revue inégale, des tests manquants parce que des gens supposaient que le modèle avait tout pris en charge, et parfois des auteurs qui n’étaient pas capables d’expliquer clairement ce que le changement faisait.
Alors on a mis des limites. Pour l’instant, les développeurs demeurent responsables du code généré. Ils doivent le comprendre, le tester et l’expliquer. Ça me semble nécessaire aujourd’hui, même si je m’attends à ce que ces limites évoluent à mesure que les outils et les pratiques mûrissent.
Repenser de vieux problèmes
Mon propre point de vue a changé au cours des derniers mois. Au lieu de consacrer l’essentiel de l’effort à rafistoler du vieux code, j’ai commencé à utiliser l’IA pour planifier la migration de certaines zones du système vers des cibles plus propres.
L’approche était simple : rendre le contexte découvrable, définir clairement la destination, puis laisser le modèle raisonner vers la cible au lieu de suradapter les vieux patterns. Les premiers POC ont été plus rapides et plus proches de ce qu’il me fallait que je ne l’aurais cru.
Ça a changé la question pour moi. Pendant des années, la dette technique ressemblait à quelque chose qu’on reconnaissait, mais qu’on réduisait rarement de façon significative, parce que la pression de livraison gagnait toujours.
J’ai monté des feuilles de route pour réduire la dette avec une capacité limitée, et on n’a jamais avancé assez vite pour la devancer. En même temps, on est passés de neuf équipes de développement à trois, puis à deux, tout en soutenant les mêmes systèmes. Dans ce contexte, la dette n’est plus un sujet secondaire. Elle entre directement en compétition avec chaque nouvelle fonctionnalité. Si les équipes continuent de rétrécir, comment on réduit la dette tout en livrant du travail utile?
Commencer par la spécification
Une idée qui revient souvent pour moi, c’est de commencer par la spécification. Pas à partir de rien, mais à partir d’un plan bien défini. Les fonctionnalités dont on a vraiment besoin. Élaguer la logique d’affaires qui s’est accumulée avec le temps et qui n’a pas besoin d’être portée plus loin. Un vrai plan de tests. Laisser l’IA bâtir une version propre du système autour de ça, au lieu de patcher sans fin l’ancien. Si quelque chose est faux, on le retire, on raffine le plan et on demande à l’IA de recommencer. Ce n’est pas l’option la plus optimale, mais la contrainte n’est plus le temps des développeurs. Elle s’est déplacée ailleurs. Elle est maintenant dans le plan : l’itérer et l’affiner jusqu’à ce qu’il soit clair, autant pour vous que pour l’IA.
Quand l'itération coûte moins cher
C’est là que ça devient contre-intuitif. Pendant des années, on a protégé le temps des développeurs en essayant d’éviter le travail à refaire. Aujourd’hui, créer puis jeter un POC peut prendre des minutes ou des heures plutôt que des jours ou des semaines.
Ça n’enlève pas le besoin de revue, de sécurité ou de qualité. Ça déplace simplement l’endroit où l’effort doit aller. Il faut mettre plus d’énergie à cadrer le problème, valider le comportement et assumer la responsabilité. Et moins d’énergie à préserver chaque choix de la première version.
Je ne vois pas l’avenir avec clarté. Mais il me semble de plus en plus probable que notre principale contrainte se déplace de l’écriture du code vers la définition, la revue et la gouvernance de ce qui est construit.
Questions ouvertes
Ça me laisse avec quelques questions ouvertes :
Je surveille toujours quatre points de pression : jusqu’où la génération peut s’étendre avant que la qualité des revues se dégrade, comment la responsabilité évolue quand les humains valident les résultats au lieu de rédiger chaque ligne, comment la cohérence architecturale tient le coup avec une itération plus rapide, et comment les nouveaux développeurs apprennent le métier pendant qu’il continue de changer.
J’avais l’habitude de présenter ça surtout comme une amélioration d’outils. Avec le temps, j’ai commencé à le voir comme un changement de gouvernance qui déplace l’endroit où le jugement d’ingénierie s’applique.
- Patrick