Plus propre, ou juste plus rapide ?
Il y a une question que presque personne ne pose sérieusement : le code généré par IA est-il de meilleure qualité, ou simplement produit plus vite ?
Les deux hypothèses sont défendables en théorie. Un modèle entraîné sur des millions de dépôts pourrait produire un code plus idiomatique qu’un développeur pressé. Ou bien il pourrait produire, très efficacement, exactement le code qu’un développeur pressé aurait écrit, en plus grande quantité.
Les données disponibles en 2026 tranchent, et elles ne vont pas dans le sens optimiste.
La dette a changé de forme
La dette technique, telle qu’on la connaissait, était bruyante. Une fonction de 400 lignes, un nom de variable incompréhensible, un TODO de 2019 : le code criait sa propre dette. Un développeur qui ouvrait le fichier savait immédiatement où il mettait les pieds.
Le code généré par IA ne crie pas. Il est bien indenté, correctement nommé, souvent documenté. Il passe la revue parce qu’il n’y a rien à signaler localement.
Le problème n’est pas local. Il est structurel, et il se mesure à l’échelle du dépôt, pas du fichier.
Ce que mesurent 623 millions de changements
GitClear publie depuis plusieurs années une analyse longitudinale du code committé sur des dépôts publics et privés. L’édition 2026, The Maintainability Gap, porte sur 623 millions de changements de code entre 2023 et 2026. Les indicateurs se répartissent proprement en deux catégories.
Les signaux de réutilisation s’effondrent :
Les appels de fonctions inter-fichiers ont chuté de 35 % depuis 2023. C’est le signal le plus direct de réutilisation de code existant : quand il baisse, cela signifie qu’on ré-écrit au lieu de rappeler.
L’activité de refactoring est tombée à 3,8 % des lignes modifiées, contre 21 % en 2022. Divisée par cinq.
La maintenance de code ancien a reculé de 74 % par rapport à 2022.
Les signaux de risque montent :
Le copier-coller à l’intérieur d’un même commit a augmenté de 41 %.
La duplication de blocs de code a bondi de 81 %, atteignant 73 lignes dupliquées pour mille lignes modifiées.
Les constructions masquant les erreurs, blocs try/catch vides, valeurs par défaut silencieuses, ont progressé de 47 %.
Le churn à deux semaines (code réécrit moins de quinze jours après avoir été écrit) a grimpé de 15 %.
Le renversement le plus parlant tient en une phrase. Avant l’IA, face au choix entre dupliquer un bout de code et le factoriser, les développeurs choisissaient le refactoring deux fois sur trois. Aujourd’hui, ils sont environ cinq fois plus susceptibles de dupliquer.
Pourquoi c’était prévisible
Il ne s’agit pas d’un défaut des modèles. Il s’agit d’un effet d’incitation, et il est parfaitement rationnel au niveau individuel.
Un assistant travaille sur un contexte borné : le ticket, le fichier ouvert, quelques fichiers voisins. Il n’a ni la mémoire ni le mandat de la cohérence globale du système. Quand il a besoin d’une logique qui existe déjà ailleurs dans le dépôt, l’option la moins coûteuse, pour lui comme pour vous, est de la régénérer sur place.
Ajoutez l’asymétrie de coût. Demander « écris-moi cette fonction » prend dix secondes. Demander « trouve où cette logique existe déjà, comprends pourquoi elle est écrite ainsi, et factorise proprement les deux usages » prend une demi-heure, produit un diff plus large, et déclenche une revue plus longue.
L’IA n’a pas créé la préférence pour la solution rapide. Elle a rendu la solution rapide quasi gratuite, et la solution propre relativement plus chère. C’est suffisant pour renverser une pratique d’ingénierie en trois ans.
C’est exactement ce que le rapport DORA 2025 décrit sous le nom d’effet amplificateur : l’IA magnifie les forces et les faiblesses d’une organisation. Là où la discipline de refactoring était déjà fragile, elle disparaît.
La sécurité, angle mort systématique
Il y a une seconde dimension, plus mesurable et plus immédiatement coûteuse.
Veracode teste depuis 2023 la sécurité du code généré par les modèles, selon un protocole stable : 80 tâches de code réparties sur quatre langages, quatre classes de vulnérabilités classiques (injection SQL, XSS, injection de logs, cryptographie faible), analyse statique du résultat. La mise à jour Spring 2026 couvre plus de 150 modèles.
Le résultat est le plus instructif de toute cette recherche :
Le taux de réussite aux tests de sécurité stagne autour de 55 %. Il est pratiquement identique à celui mesuré deux ans plus tôt, alors que, sur la même période, la correction syntaxique est passée d’environ 50 % à plus de 95 %.
Les modèles ont appris à écrire du code qui compile et qui fonctionne. Ils n’ont pas appris à écrire du code sûr. Ce n’est pas la même courbe de progrès, et rien n’indique qu’elles vont converger.
Le détail est pire que la moyenne : 29 % de réussite en Java, 15 % sur les failles XSS, 13 % sur l’injection de logs.
Une équipe qui triple son volume de code sans tripler sa capacité d’analyse de sécurité ne triple pas sa productivité. Elle triple sa surface d’exposition.
Pourquoi c’est invisible
Trois raisons pour lesquelles cette dette ne remonte pas dans les tableaux de bord.
Elle ne se voit pas en revue. La revue de code est un exercice local : on regarde un diff. Un bloc dupliqué depuis un autre fichier est un bloc correct. Il faudrait connaître tout le dépôt pour repérer le doublon, ce qu’aucun relecteur ne fait à l’échelle.
Elle ne se voit pas dans les métriques de vélocité. Débit de livraison, tickets fermés, fréquence de déploiement : tous ces indicateurs s’améliorent pendant la phase d’accumulation. La dégradation apparaît plus tard, sous forme d’un ralentissement diffus que personne ne rattache à sa cause.
Elle ne se voit pas dans le calendrier des décideurs. Les gains de vitesse sont trimestriels. La facture de maintenabilité arrive à dix-huit ou trente-six mois. Peu de dirigeants sont encore en poste sur le même périmètre pour faire le lien.
C’est la définition même d’une externalité : quelqu’un encaisse le bénéfice, quelqu’un d’autre paie le coût, et les deux ne se rencontrent jamais.
Ce qui fonctionne réellement
Quatre leviers, par ordre d’efficacité constatée.
Mesurer la duplication en continu, pas la couverture de tests. La couverture de tests est facile à satisfaire avec du code généré, un modèle écrit volontiers des tests qui passent. Le taux de duplication et le churn à deux semaines sont beaucoup plus difficiles à truquer. Ce sont les deux indicateurs à mettre sous surveillance.
Réserver un budget de refactoring explicite. Si le refactoring est tombé à 3,8 % des lignes modifiées, c’est parce qu’il n’est jamais prioritaire face à une fonctionnalité. Le seul mécanisme qui tienne est une allocation nommée dans le planning, avec un propriétaire.
Traiter l’analyse de sécurité comme un passage obligé, pas comme une étape de fin de projet. Le constat de Veracode est sans ambiguïté : le prompt seul ne produit pas de code sûr, et la situation ne s’améliore pas d’elle-même. L’analyse statique automatisée dans la chaîne d’intégration est le minimum, pas une bonne pratique optionnelle.
Décider ce qui n’est pas généré. C’est le levier le plus simple et le moins appliqué. Sur le cœur métier, les couches d’authentification, la gestion des données sensibles et les abstractions structurantes, la génération assistée fait courir un risque disproportionné au gain. Tracer cette frontière explicitement, par écrit, dans l’équipe.
Le vrai sujet n’est pas le code
Il y a une hypothèse implicite derrière l’euphorie actuelle : si l’IA dégrade la maintenabilité, une IA future saura réparer.
C’est possible. Mais c’est un pari, pas un plan. Et il repose sur une intuition fausse : maintenir n’est pas un problème de génération, c’est un problème de compréhension. Comprendre pourquoi une décision a été prise il y a trois ans, quelles contraintes métier l’ont dictée, quels clients dépendent du comportement actuel, cette information n’est pas dans le code. Elle est dans la tête des gens qui l’ont écrit.
Le vrai risque de la période n’est donc pas d’accumuler du mauvais code. C’est d’accumuler du code que plus personne dans l’équipe n’a jamais eu besoin de comprendre.
Questions fréquentes
**Le code généré par IA est-il de moins bonne qualité que le code écrit par un humain ? ** Localement, non : il est souvent correct et lisible. Structurellement, les données de GitClear (623 millions de changements, 2023-2026) montrent une dégradation nette des indicateurs de maintenabilité : duplication en hausse de 81 %, réutilisation inter-fichiers en baisse de 35 %, refactoring passé de 21 % à 3,8 % des lignes modifiées.
**Le code généré par IA est-il sûr ? ** D’après les tests Veracode de 2026 portant sur plus de 150 modèles, environ 55 % du code généré passe les tests de sécurité sur des classes de vulnérabilités classiques, un taux stable depuis deux ans, alors que la correction syntaxique a bondi à plus de 95 %.
**Comment mesurer la dette technique liée à l’IA ? ** Deux indicateurs difficiles à truquer : le taux de duplication de blocs et le churn à deux semaines (part du code réécrit moins de quinze jours après sa création). La couverture de tests est un mauvais indicateur dans ce contexte.
**Faut-il interdire la génération de code sur certaines parties d’un projet ? ** C’est une pratique pragmatique et efficace : définir explicitement les zones, cœur métier, authentification, données sensibles, abstractions structurantes, où la génération fait courir un risque disproportionné au gain de temps.
Sources
GitClear, The Maintainability Gap: 2026 AI Code Quality Research
Veracode, Spring 2026 GenAI Code Security Update
Veracode, 2025 GenAI Code Security Report
DORA, Balancing AI tensions (2025)
Cloud Security Alliance, AI-generated code vulnerability surge (2026)