Cessez d'envoyer en révision les erreurs de code généré par l'IA détectables par l'EDI

Par JetBrains

Cessez d'envoyer en révision les erreurs de code généré par l'IA détectables par l'EDI, par JetBrains

Les outils de codage IA ont peut-être permis à vos développeurs de gagner en productivité, mais ils ont créé un problème pour votre processus de révision de code. Le volume des pull requests a considérablement augmenté, et le code soumis à la révision comporte des schémas d'erreurs qui n'étaient pas courants avant l'IA générative. Pourtant, ce sont les mêmes personnes, avec les mêmes horaires de travail, qui sont chargées de tout réviser.

La plupart des responsables techniques cherchent encore comment y remédier. D’après notre enquête « State of Developer Ecosystem 2025 », menée auprès de plus de 24 000 développeurs, la tendance dominante est l’approche ad hoc : les développeurs utilisent simplement les outils d’IA comme bon leur semble, avec peu de gouvernance venant de la hiérarchie.

Des études indiquent qu’environ 20 à 25 % des erreurs de code générées par l’IA sont détectables grâce à une analyse structurelle et statique automatisée. Ces vérifications peuvent être effectuées dans l’environnement où le code a été écrit, avant qu’une pull request ne soit soumise. Aucun cadre de gouvernance n’est nécessaire, aucune nouvelle couche de processus n’est requise.

Le raisonnement est simple : le jugement de vos réviseurs est une ressource limitée. Chaque erreur structurelle qui parvient jusqu’à la révision en consomme une partie. Chaque erreur structurelle détectée plus tôt n’en consomme pas.


La révision de code est un processus décisionnel – l’IA n’a fait qu’ajouter davantage de décisions

Les données de DX pour le quatrième trimestre 2025, portant sur 51 000 développeurs, ont montré que les utilisateurs quotidiens de l’IA fusionnent 60 % de pull requests en plus par semaine que les utilisateurs occasionnels. Un essai contrôlé randomisé mené en 2025 auprès de trois grandes entreprises a révélé que les développeurs ayant accès à un assistant de codage IA accomplissaient 26 % de tâches en plus par semaine que ceux du groupe témoin qui n’y avaient pas accès.

Plus de code soumis à la révision signifie plus de décisions par réviseur et par jour. Cette pression a un coût mesurable. Des décennies avant l’apparition des outils de codage basés sur l’IA, des chercheurs ont constaté que le temps consacré à la révision était un facteur statistiquement significatif dans l’efficacité de la correction des défauts, même après avoir pris en compte les compétences des développeurs. Un temps plus long passé par ligne de code révisée était systématiquement associé à un plus grand nombre de défauts détectés.

Les compétences seules ne pouvaient pas compenser la précipitation. De meilleurs outils devraient le faire – mais les outils, y compris les outils modernes assistés par l'IA, n'ont pas encore comblé l'écart entre ce qu'un réviseur voit et ce qu'il a besoin de savoir :

- Une étude de 2024 portant sur l'outil de révision de code par IA d'une entreprise a révélé que même si 73,8 % des commentaires de révision automatisés étaient pris en compte, le temps de clôture des pull requests augmentait tout de même de 42 %. Les commentaires étaient utiles, mais la charge de travail n'était pas réduite.

- En 2025, une étude empirique portant sur 16 outils de révision de code basés sur l'IA et plus de 22 000 commentaires a révélé que leur efficacité variait considérablement.

- Une étude de janvier 2026 a montré qu'une révision efficace nécessite bien plus qu'un simple aperçu du code ajouté ou supprimé. Les réviseurs jonglent entre les outils de suivi des tickets, la documentation, les discussions d'équipe et les rapports d'intégration continue pour comprendre ce qu'un changement implique dans la base de code qu'ils examinent.

- Les outils de révision continuent de laisser aux développeurs le soin de se faire une vue d'ensemble. L'IA a creusé ce fossé, elle ne l'a pas comblé.

L'IA envoie un type de code différent à réviser

Une analyse de 2025 portant sur plus de 500 000 échantillons de code a révélé que le code généré par l'IA présente un profil d'erreurs distinct : des constructions inutilisées, des valeurs codées en dur et des failles de sécurité à haut risque qui sont plus courantes que dans le code écrit par des humains. Une autre étude de 2025 a identifié des catégories de défauts sans véritable équivalent dans le code écrit par des humains.

Le profil d'erreurs est déjà suffisamment problématique. Mais la manière dont les réviseurs interagissent avec le code généré par l'IA aggrave encore la situation. Une étude de 2026 a mis en évidence un angle mort chez les réviseurs : les pull requests générées par l'IA, contenant près de deux fois plus de redondances de code, suscitaient moins de réactions négatives de la part des réviseurs que celles écrites par des humains. La plausibilité apparente semblait réduire l'engagement critique.

Plus de volume. De nouveaux types d’erreurs. Moins de contrôle. Que révèlent les données de livraison ?

Une réduction de 7,2 % de la stabilité des livraisons pour chaque augmentation de 25 % de l’adoption de l’IA, selon DORA. Ils ont attribué cette tendance en partie à des ensembles de modifications plus volumineux : plus de code généré signifie des lots plus importants à réviser, et des lots plus importants ont toujours été un indicateur d’instabilité. La taille est le signal. Le profil des défauts et les données de contrôle suggèrent ce qui se cache derrière.

Laisser les machines détecter ce qu’elles peuvent

Les vérifications structurelles et statiques automatisées ne font pas appel au jugement humain. Mais qui met ces vérifications en place ? Même dans les organisations dotées de pratiques d’ingénierie matures, le filtrage structurel ne s’est pas suffisamment imposé au niveau individuel :

- Google, qui effectue des migrations de code basées sur des modèles de langage (LLM) dans l’ensemble de sa base de code, a constaté que les réviseurs devaient annuler les modifications générées par l’IA si souvent que l’organisation a délibérément investi dans la vérification automatisée pour réduire cette charge.

- Uber, qui traite des dizaines de milliers de modifications de code chaque semaine, a constaté que le développement assisté par l'IA surchargeait les réviseurs et a mis en place un système de révision automatisé qui s'exécute avant que les réviseurs humains n'interviennent.

Dans les deux cas, la solution a nécessité une décision organisationnelle. Google et Uber ont choisi de le faire au niveau du pipeline – en amont des pull requests.

Un environnement de développement adapté permet de détecter plus tôt ce type d'erreurs.

Intégrez une analyse structurelle « sans concession » en amont du pipeline

Selon l’enquête Stack Overflow Developer Survey 2025, les développeurs utilisent en moyenne 3,6 environnements de développement. C’est généralement à eux de décider lesquels utiliser. Ils connaissent leurs langages et leurs workflows.

En tant que responsable technique, vous devez savoir si au moins un de ces environnements effectue des vérifications approfondies et sans concession du code généré par l’IA par rapport à ce qui existe réellement dans l’ensemble de la base de code, tous langages confondus. De nombreux environnements de développement ne le font pas ; ils s’appuient plutôt sur des approximations langage par langage.

Cette distinction est plus importante au niveau organisationnel qu’au niveau individuel. Un développeur travaillant dans un seul langage avec une configuration bien paramétrée basée sur des approximations peut ne pas ressentir cette lacune. Mais la qualité de l’analyse structurelle au sein d’une équipe n’est aussi cohérente que la configuration la plus faible de celle-ci.

Les mêmes études sur les « hallucinations » du code généré par l'IA ont révélé qu'environ 44 % d'entre elles comportent des erreurs qu'aucune vérification automatisée ne détecte de manière fiable. C'est déjà bien assez pour vos relecteurs. Protégez leur capacité en ne leur imposant que ce qu'ils peuvent gérer.

Pour chaque langage principal utilisé par votre équipe, il existe un IDE JetBrains permettant de maintenir un modèle structurel approfondi de votre base de code. Tout code qui arrive dans l'éditeur – quel que soit l'outil d'IA qui l'a produit – est vérifié par rapport à ce modèle. Pour les équipes qui souhaitent une application des règles à la fois en amont et dans le pipeline, Qodana étend cette même profondeur d'inspection au CI/CD.

Le jugement de vos relecteurs est votre ressource. Le filtrage structurel est le moyen de le protéger.

Découvrez comment les solutions de JetBrains peuvent vous aider