Ton équipe livre du code plus vite que jamais. Les courbes de vélocité de sprint pointent vers le haut et vers la droite. Les pull requests — ces paquets de modifications de code soumis à la revue — passent l'approbation à la vitesse de l'éclair. Le PM remercie les outils de codage IA. Tout le monde hoche la tête. La vie est belle.

Sauf que les tickets de bugs grimpent. Les reverts — quand on annule un changement parce qu'il a tout cassé — se multiplient. Le backlog enfle. Personne ne fait le lien parce que le dashboard dit qu'on défonce tout.

Le 30 mars 2026, une équipe de chercheurs de la Singapore Management University a publié la plus grande étude empirique jamais réalisée sur la qualité du code généré par l'IA. Ils ont analysé 304 362 commits vérifiés comme écrits par l'IA (des modifications de code dont l'origine IA a été confirmée) dans 6 275 dépôts GitHub, couvrant cinq outils majeurs : GitHub Copilot, Claude, Cursor, Gemini et Devin. La période : janvier 2024 à octobre 2025.

Ce qu'ils ont trouvé devrait sérieusement calmer l'ambiance de ta prochaine célébration de vélocité.

Sur l'ensemble de ces dépôts, les chercheurs ont identifié 484 606 problèmes distincts. Parmi eux, 89 % étaient des code smells — des patterns qui marchent aujourd'hui mais qui pourrissent demain. Près de 6 % étaient des bugs d'exécution. Et 5,1 % étaient des vulnérabilités de sécurité. Entre 15 % et 29 % des commits IA introduisaient au moins un problème, selon l'outil. Gemini trônait en haut du classement avec 28,7 %. Copilot s'en tirait à 17,3 % — mieux, mais ça reste un commit sur six qui arrive avec des surprises.

Le coup de grâce : 24,2 % de ces problèmes introduits par l'IA étaient toujours vivants dans la dernière version du code. Les failles de sécurité affichaient un taux de survie de 41,1 % — le plus élevé de toutes les catégories. En février 2026, l'étude comptait plus de 110 000 problèmes survivants que l'IA avait déposés là et que les humains n'avaient jamais nettoyés. Les chercheurs résument sans détour : les assistants IA corrigent à peu près autant de code smells qu'ils en créent, mais ils « créent plus de bugs et de problèmes de sécurité qu'ils n'en résolvent ».

Un jour plus tôt, le 29 mars, Exceeds AI a publié des données de benchmark qui mettent en perspective l'impact au niveau organisationnel. Leur analyse situe le ratio de code IA soutenable entre 25 et 40 % de la production totale — la fourchette dans laquelle les équipes obtiennent de vrais gains de productivité de 10 à 15 % sans se noyer dans le rework. La moyenne mondiale actuelle ? 41–42 %. Déjà au-delà de la ligne rouge. Les équipes au-dessus de 40 % de code IA affichent des taux de retravail 20 à 25 % plus élevés. Et voici le paradoxe de productivité qui devrait hanter tout engineering manager : les développeurs se sentent 20 % plus rapides mais mesurent en réalité 19 % de lenteur en plus quand on comptabilise la revue de code, le débogage et les correctifs.

La vitesse perçue augmente. Le débit réel diminue. Le dashboard ment.

Le 6 avril, la chercheuse Margaret-Anne Storey de l'Université de Victoria a donné un nom à ce phénomène dans un nouvel article. Elle l'appelle la « dette cognitive » — l'érosion de la compréhension partagée au sein d'une équipe. Quand l'IA génère du code plus vite que les développeurs ne peuvent le comprendre, l'équipe perd la capacité de modifier son propre système en toute sécurité. Ce n'est pas juste de la dette technique (du code crade qu'on corrigera plus tard). C'est une dette de connaissance — plus personne ne comprend vraiment ce que la codebase fait.

Rien de tout ça ne veut dire qu'il faut arrêter d'utiliser les outils de codage IA. Les gains de productivité sont réels, et le génie ne rentrera pas dans la bouteille. Mais la question que ton équipe devrait se poser n'est pas « combien de code l'IA peut-elle écrire pour nous ? » C'est « combien de code généré par l'IA notre processus de revue et notre couverture de tests peuvent-ils réellement absorber avant que tout parte en vrille ? »

La vélocité a toujours été une vanity metric — un chiffre qui impressionne mais ne dit rien sur la solidité de ce qu'on construit. Maintenant, sans dénominateur qualité, c'est carrément un chiffre dangereux. Ta courbe de sprint monte. Ton compteur de bugs aussi. Même graphique. Histoire radicalement différente.