Le code IA passe la revue, la facture arrive en production

Un chiffre résume la contradiction que vivent beaucoup d'équipes en 2026 : 94 % des responsables techniques interrogés par New Relic jugent le code généré par IA de meilleure qualité que le code humain, au moment de la revue. Pourtant, une fois ce code parti en production, 78 % constatent une hausse des incidents et 82 % ont subi au moins une panne majeure liée à du code IA au cours des six derniers mois¹. L'écriture s'est accélérée, le contrôle de ce qui atteint les utilisateurs n'a pas suivi.

Pour une PME ou une ETI qui adopte les agents de code sans étoffer sa chaîne de validation, ce décalage a un coût concret. Il ne se voit pas dans la vélocité affichée, il se voit dans les astreintes et les correctifs.

Bien noté avant le déploiement, coûteux après

Le rapport State of AI Coding 2026 de New Relic s'appuie sur une enquête menée par Hanover Research auprès de 200 décideurs techniques américains, tous cadres ou au-dessus, dans des entreprises du mid-market et grands comptes qui utilisent l'IA générative et agentique en développement¹. Le constat central tient en une phrase : le code IA obtient de bonnes notes en revue, puis déclenche des incidents une fois en service.

Les autres chiffres du rapport prolongent ce diagnostic. 86 % des répondants signalent une augmentation du temps que leurs profils seniors passent à réparer du code, et 74 % estiment qu'au moins un quart du code IA a demandé une reprise significative sur les douze derniers mois¹. New Relic parle d'« agent debt », la dette accumulée par du code produit vite, validé en apparence, puis payé en exploitation.

Le goulot s'est déplacé vers la vérification

Cette dette a une cause structurelle. L'enquête State of Code 2026 de Sonar, conduite auprès de plus de 1 100 développeurs dans le monde, mesure que l'IA représente déjà 42 % du code intégré, une part que les répondants voient monter à 65 % d'ici 2027². Le volume à relire a donc changé d'échelle, mais la confiance ne suit pas : 96 % des développeurs déclarent ne pas faire pleinement confiance à la justesse fonctionnelle du code IA, et seuls 48 % affirment le vérifier systématiquement avant de le committer².

L'écart entre ces deux chiffres porte un nom. Werner Vogels, directeur technique d'Amazon Web Services, l'a qualifié de « verification debt » : la partie difficile n'est plus d'écrire le code, c'est de valider qu'il fait bien ce qu'on croit². Sonar ajoute un angle qui parlera aux responsables de PME : 35 % des développeurs accèdent à leurs outils d'IA via des comptes personnels plutôt que par des accès validés par l'entreprise, ce qui crée un angle mort pour la sécurité et la conformité².

Ce que révèle l'analyse des pull requests

Un troisième jeu de données descend au niveau du code lui-même. CodeRabbit a analysé 470 pull requests open source sur GitHub, dont 320 coécrites avec de l'IA et 150 écrites uniquement par des humains³. Le nombre de pull requests par auteur a progressé de 20 % sur un an grâce à l'IA, mais le nombre d'incidents par pull request a augmenté de 23,5 % sur la même période³.

Le détail des défauts explique ce résultat. Selon la même analyse, le code coécrit avec l'IA présente environ 1,7 fois plus de problèmes au total, avec des erreurs de logique 1,75 fois plus fréquentes et des vulnérabilités de sécurité jusqu'à 2,74 fois plus nombreuses³. Ces défauts ne se traduisent pas toujours par un rollback immédiat, ce qui rejoint le constat de New Relic : le code passe la revue, puis se manifeste plus tard en production sous forme de bugs discrets. Nous avions déjà observé cet allongement du travail de relecture dans un précédent article sur la revue du code IA.

Ce que ça implique pour une PME ou une ETI

Sur le terrain, ces rapports pointent tous vers la même correction de trajectoire. La vélocité seule, mesurée en pull requests fusionnées ou en lignes produites, devient un indicateur trompeur si le taux d'incidents par livraison grimpe en parallèle.

Trois réflexes limitent la casse. D'abord, durcir la chaîne d'intégration continue : tests automatisés, analyse statique et couverture doivent bloquer une pull request avant qu'un humain fatigué ne l'approuve par défaut. Ensuite, investir dans l'observabilité en production, car une partie des défauts du code IA n'apparaît qu'à l'exécution, sur des cas que la revue ne couvre pas. Enfin, nommer un responsable humain identifié pour chaque changement, plutôt que de laisser la signature de l'agent tenir lieu de garantie.

Le point sur les comptes personnels mérite une décision explicite. Fournir des accès professionnels aux outils d'IA coûte moins cher qu'un incident de fuite de données, et cela redonne à l'entreprise une visibilité sur ce qui entre dans son code.

Notre lecture

Ces trois rapports ne disent pas que le code IA est mauvais. Ils disent que le gain d'écriture se déplace vers un poste que peu d'organisations ont renforcé : la vérification et l'exploitation. Pour une PME ou une ETI, la question utile n'est pas « écrit-on plus vite ? », mais « sait-on encore ce qui part en production, et qui en répond ? ». Tant que la réponse reste floue, chaque pull request supplémentaire ajoute à la dette plutôt qu'à la valeur. Les équipes qui tirent un vrai bénéfice de l'IA sont celles qui ont réinvesti le temps gagné dans des garde-fous, pas celles qui l'ont converti en volume.

Sources

• New Relic, The 2026 State of AI Coding Report : https://newrelic.com/resources/report/2026-state-of-ai-coding
• New Relic, communiqué de presse (10 juin 2026) : https://newrelic.com/press-release/20260610
• Sonar, State of Code Developer Survey 2026 : https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/
• CodeRabbit, State of AI vs Human Code Generation Report : https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report