Contexte technique
Je constate de plus en plus souvent la même tendance : les entreprises se tournent vers l'agentic AI coding non par effet de mode, mais parce que l'écart de coût et de rapidité est devenu colossal. Pour l'implémentation de l'IA, cela s'apparente presque à un code de triche : un prototype en quelques jours, des premiers utilisateurs conquis rapidement et des équipes réduites. Et c'est précisément là que je commence à émettre des réserves.
Si l'on dépasse la simple démo pour analyser la base de code après six mois, le tableau est nettement moins idyllique. Selon les données les plus souvent citées dans les études récentes sur le code généré par IA, la productivité augmente d'environ 31.4%, mais cela s'accompagne d'une hausse de 23.7% des vulnérabilités, de 30% d'alertes d'analyse statique en plus, et d'une augmentation de 41% de la complexité du code.
Ce qui m'interpelle dans ces chiffres, ce n'est pas uniquement la dégradation de la qualité en soi. C'est le fait qu'elle se dissimule sous les traits d'un travail d'ingénierie tout à fait normal. De l'extérieur, le code peut sembler modulaire, mais sous le capot, on découvre des dépendances cachées, une faible encapsulation et des pans entiers de code qu'un développeur humain devra démêler plus tard comme s'il s'agissait d'une improvisation hâtive.
Un autre signal d'alarme préoccupant : une partie des méthodes générées finit tout simplement par être supprimée lors de la revue de code. Des études mettent en évidence qu'environ 9.9% du code est supprimé dans les pull requests générées par des agents. Autrement dit, l'agent ne se contente pas d'accélérer la livraison, il sature également le pipeline avec du superflu que l'équipe doit analyser, vérifier puis jeter.
Dans un contexte d'entreprise (enterprise), cela s'avère particulièrement dangereux. L'agent passe à travers les étapes standards de CI/CD et importe des dépendances qui résolvent un problème local, mais qui sont totalement incompatibles avec vos critères de sécurité. Tant que le produit est jeune, on tolère cela. Dès que la croissance démarre, cette forme d'intégration IA se transforme soudainement en une taxe sur chaque modification future.
Ce que cela change pour les affaires et l'automatisation
Je ne cherche pas à dramatiser ni à condamner définitivement cette approche. Pour démarrer un projet, créer des outils internes, concevoir un MVP ou automatiser des tâches spécifiques, l'automatisation par IA est souvent amplement justifiée. Un lancement rapide s'avère parfois bien plus crucial qu'une maintenabilité irréprochable.
Cependant, les grands gagnants sont ceux qui, dès le départ, font la distinction entre la vitesse éphémère et le cœur de leur produit. Les perdants sont les équipes qui laissent l'agent rédiger l'intégralité du code sans fixer de barrières architecturales, sans traçabilité des modifications et sans un budget réaliste pour gérer la charge des revues de code.
En pratique, je recommande de surveiller de près trois éléments : dans quelles zones l'agent peut coder librement, quelles dépendances il est autorisé à introduire et qui est chargé de restructurer un prototype réussi en un système de production robuste. Chez Nahornyi AI Lab, nous résolvons continuellement ce type de blocages pour nos clients : nous ne bannissons pas l'automatisation de l'IA, mais nous l'intégrons de manière à ce que vous n'ayez pas besoin d'un excavateur pour nettoyer votre produit dans un an.
Si votre base de code grandit déjà et que vous remarquez que la vitesse commence à nuire à la qualité, analysons cela ensemble au niveau du workflow et de l'architecture IA. Chez Nahornyi AI Lab, je peux vous aider à structurer le développement de vos solutions IA afin que l'automatisation ne vienne pas dévorer l'avenir de votre produit et de votre équipe.