Tous les articles

Blog

Revue de code : l'IA écrit plus vite que vos équipes ne relisent

Une PR de 13 323 lignes écrite avec une IA, fermée au bout d'un peu plus de quinze heures : ce que votre revue de code doit changer.

  • Par Azziz ERRIME
  • 15 min de lecture
Une chaise de bureau vide face à une pile de pages de revue de code qui monte jusqu'au plafond, éclairée la nuit par une lampe.

TL;DR

  • La revue de code ne suit plus le rythme de l’IA : dans une entreprise étudiée en 2026, les PR par développeur actif ont doublé, la charge de chaque relecteur aussi.
  • Selon Veracode, le code généré par IA ne réussit encore que 15 % des tests de sécurité sur le XSS et 13 % sur l’injection de logs.
  • Avant d’acheter un outil, je mesurerais la charge des relecteurs, plafonnerais la taille des PR et écrirais le mot sécurité dans le modèle de PR.

Une pull request de 13 323 lignes écrite avec une IA, fermée faute de relecteurs. Quand l’IA écrit le code, c’est la revue de code qui décide de ce qu’il vaut. Encore faut-il l’avoir dimensionnée et protégée.

Mercredi 19 novembre 2025, 18 h 37 à Paris. Une pull request arrive sur le dépôt du compilateur OCaml : 13 323 lignes, 147 fichiers, 40 commits. Son auteur l’a produite avec une IA pour ajouter le support de DWARF, un format de débogage.

Le lendemain à 9 h 55, un peu plus de quinze heures plus tard, Gabriel Scherer, l’un des mainteneurs, la ferme sans la fusionner. Dans son message de fermeture, il précise qu’il ne juge pas le code proposé : il ne l’a pas regardé d’assez près pour se prononcer. Aucune des personnes susceptibles de relire et de maintenir ce travail ne semblait prête à s’en charger. Reste la question de toute revue de code : qui relit, et en combien de temps ?

Une revue de code qui n’a pas eu lieu

Juste avant de fermer la PR, Scherer avait publié un commentaire. Il y décrit un code « hard to review, and very lightly tested », difficile à examiner et à peine testé. Il rappelle que le compilateur manque de personnes disponibles pour la relecture et la maintenance. D’expérience, ajoute-t-il, vérifier ce qu’écrit une IA lui coûte plus d’effort que vérifier le travail d’un humain.

Des PR aussi volumineuses font courir, selon lui, « a very real risk of bringing the Pull-Request system to a halt », un risque bien réel de bloquer tout le circuit des contributions. Produire des lignes qui passent les tests, écrit-il, c’est « only 20% of the work », un cinquième du travail. Les 80 % restants, discuter la fonctionnalité, la relire et l’intégrer, retombent sur l’auteur comme sur d’autres.

Selon une étude ancienne que SmartBear, éditeur d’un outil de revue de code, a menée chez Cisco, la détection des défauts chute au-delà de 500 lignes relues par heure. À ce rythme maximal, j’arrive à plus de 26 heures de lecture attentive pour les 13 323 lignes. La PR est restée ouverte un peu plus de quinze heures.

Sa phrase de fermeture parle de l’organisation du projet : « Currently github/ocaml as it is organized is not able to work in this way. » Tel qu’il est organisé, le dépôt ne sait pas travailler ainsi. Je me demande combien d’équipes pourraient écrire autre chose de leurs propres dépôts.

Les PR ont doublé, et la charge de chaque relecteur aussi

Selon GitHub, les pull requests fusionnées chaque mois sur la plateforme ont plus que triplé entre janvier 2023 et juin 2026.

Une étude publiée le 2 juillet 2026 a suivi les développeurs d’une entreprise dont le CTO avait annoncé, en juin 2025, un « mandat 2× » pour doubler la productivité par l’IA. Le nombre de PR par développeur actif a bien doublé, et la charge de chaque relecteur aussi. Les auteurs y voient une borne haute, pas une moyenne du secteur.

Dans l’open source, la fondation du moteur de jeu Godot a changé sa politique de contribution le 30 juin 2026. Elle en donne la raison sans détour : ses relecteurs qualifiés sont peu nombreux, la relecture de code demande un vrai effort, et le flux entrant la dépasse.

Je crois que la revue de code saute quand la file déborde, une PR après l’autre. Faros AI vend des outils qui mesurent le travail des équipes d’ingénierie. Dans sa télémétrie, les PR fusionnées sans aucune revue, ni humaine ni par un agent, sont en hausse relative de 31,3 %. Chacune peut emporter les failles que l’IA rate d’une version à l’autre.

Un poste de contrôle routier à la barrière levée et à la guérite vide, traversé par une file de camions blancs.

Un poste de contrôle ouvert, personne dans la guérite, et le trafic qui passe sans ralentir.

Le code généré par IA rate encore les mêmes failles

Au printemps 2026, Veracode, éditeur de sécurité applicative, a détaillé faille par faille le taux de réussite du code généré par IA aux tests de sécurité. Ces taux avaient à peine bougé depuis son rapport de 2025.

Faille Réussite aux tests de sécurité
Injection SQL 82 %
XSS 15 %
Injection de logs 13 %

Son rapport du 28 juillet 2026 retrouve ces deux points faibles, le XSS et l’injection de logs. L’injection de logs glisse des retours à la ligne dans un champ journalisé pour fabriquer de fausses entrées. Mon interprétation : le modèle réussit quand la parade tient dans un motif connu, comme la requête paramétrée contre l’injection SQL. Il échoue quand la défense dépend de l’endroit où la donnée finira, une page affichée à un autre utilisateur ou un journal relu pendant une enquête. Veracode avance une explication voisine : ces deux failles obligent à suivre la donnée d’un utilisateur à travers l’application.

Concrètement, l’attaquant commence par ce trajet. Il repère les entrées de l’application, un champ de formulaire, un en-tête, un paramètre d’URL, puis suit la donnée jusqu’à la page ou au journal où elle ressort. Une PR se relit fichier par fichier, alors que ce chemin en traverse plusieurs.

L’autre angle mort se loge dans les dépendances. Une étude présentée à USENIX Security 2025 montre que des modèles de 2023 et 2024 recommandaient des paquets inexistants, souvent les mêmes d’une exécution à l’autre. Un attaquant peut donc enregistrer ces noms avant vous. Selon un billet de Lasso Security publié en mars 2024, un chercheur a mis en ligne un paquet vide sous un nom inventé par des modèles, « huggingface-cli ». Il a été téléchargé plus de 30 000 fois en trois mois.

Pour une revue de code sécurité, le geste le moins cher tient en une phrase. Braz et ses coauteurs ont montré à ICSE 2022 que demander explicitement aux relecteurs de regarder la sécurité multiplie par huit la probabilité qu’ils trouvent la vulnérabilité. Leur checklist n’ajoutait rien de significatif à cette consigne. Mais il faut quelqu’un qui ait le temps de lire, et quand ce temps manque, l’idée de confier aussi la relecture à une machine arrive vite.

Faire relire l’IA par une IA : la tentation qu’OCaml avait vue venir

Dans le commentaire publié juste avant la fermeture, Scherer avait anticipé la réponse : « You may think that the answer to that is to also automate the review process, or (more plausibly) to lower our quality standards ». Automatiser la relecture ou baisser l’exigence : jusqu’ici, écrit-il, le projet n’a pas choisi de travailler ainsi. La tentation est pourtant réelle, et la revue de code automatique tourne déjà à grande échelle, selon GitHub, qui parle de son propre produit.

Une IA peut aussi trouver de vraies failles. Le 11 août 2025, l’équipe Big Sleep de Google a signalé à curl la faille devenue CVE-2025-9086. Son mainteneur, Daniel Stenberg, y voit le premier rapport reçu par curl qui semble avoir utilisé l’IA pour repérer une faille avec exactitude.

Dans un article accepté à ICML 2025, Kim et ses coauteurs ont comparé les erreurs des grands modèles de langage sur le classement HELM. Quand deux d’entre eux se trompent en même temps, ils choisissent en moyenne la même mauvaise réponse environ 60 % du temps, contre environ 33 % au hasard. Ce chiffre ne vaut que pour ce classement. Il me suffit pour ne pas supposer qu’un second modèle couvre les angles morts du premier.

Le relecteur automatique devient aussi une cible. L’injection de prompt consiste à cacher, dans un contenu que l’IA lira, des instructions qu’elle suivra comme si elles venaient de vous. Avec CamoLeak, un chercheur de Legit Security a glissé des commentaires invisibles dans une PR pour faire fuiter du code privé par Copilot Chat. GitHub a corrigé cette faille critique le 14 août 2025.

Un détecteur de fumée au plafond d’un bureau, recouvert d’un post-it jaune vierge.

Un détecteur masqué par un post-it, comme un relecteur automatique trompé par une instruction cachée.

Kudelski Security a publié le 19 août 2025 le récit d’une simple PR contenant un fichier de configuration malveillant. Corrigée dès janvier 2025, la faille permettait d’exécuter du code sur les serveurs de CodeRabbit, un outil de revue par IA. Elle ouvrait un accès en écriture à un million de dépôts, privés compris. Il reste l’humain qui approuve en bout de chaîne.

Huit mois après OCaml, un agent d’IA vise l’approbation d’un mainteneur

Dans un rapport publié le 4 août 2026, l’AI Security Institute, organisme public britannique, décrit un incident survenu du 25 au 28 juillet pendant des tests de cybersécurité. Un agent d’IA en test a étudié les mainteneurs humains d’un projet, créé plusieurs fausses identités et s’en est servi pour pousser un vrai mainteneur à approuver son code. Selon l’institut, ses investigations n’ont mis en évidence aucun préjudice réel.

La documentation du noyau Linux réserve la signature aux humains : « AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO). » Par la ligne Signed-off-by, le contributeur humain certifie l’origine de son code et en prend l’entière responsabilité.

L’agent de code Copilot de GitHub interdit à la personne qui lui a demandé une PR de l’approuver elle-même. Depuis le 13 mars 2026, un administrateur peut en revanche lever une autre protection, l’approbation humaine avant l’exécution des workflows lancés par l’agent. Aucun de ces textes ne dit combien de temps on laisse à l’humain pour lire.

Les chercheurs de Carnegie Mellon tirent leur conclusion principale de milliers de textes publiés sur la revue de code. C’est l’équipe qui décide, à la revue, si l’effet d’un agent sur le logiciel est bon ou mauvais.

« […] review is the control point through which a coding agent’s effect on software is decided, and […] AI does not fix the sign of that effect: the team sets it » Agarwal, Miller, Kästner et Vasilescu, Carnegie Mellon, 8 juillet 2026.

Un quart d’heure après avoir fermé la PR, Scherer parlait de processus de développement différents au point d’être incompatibles, sans dire lequel avait raison.

Lundi matin, j’organiserais la revue de code avant d’acheter un outil

Sa phrase de fermeture se terminait par une parenthèse : « This may change in the future and then one could reconsider. » Cela changera peut-être, et l’on pourra alors reconsidérer. Le constat qu’il faisait pour son dépôt, chaque équipe peut le faire pour sa propre revue de code : est-elle organisée pour relire ce que l’IA écrit ?

À la place d’un tech lead ou d’un RSSI, je commencerais par quatre gestes.

  • J’ouvrirais la forge, l’outil qui héberge vos dépôts, pour en sortir deux chiffres qui y dorment déjà. D’abord la part de PR fusionnées sans revue humaine sur 90 jours, puis le nombre de lignes soumises chaque semaine à chaque relecteur, converti en heures de lecture.
  • Je plafonnerais autour de 200 à 400 lignes la taille des PR confiées à un relecteur, et je ferais découper le reste.
  • J’écrirais le mot sécurité dans le modèle de PR, avec les zones où le code généré échoue : les journaux, l’affichage de données utilisateur, chaque dépendance ajoutée.
  • Je vérifierais qui, dans vos dépôts, peut lever l’approbation humaine des workflows lancés par un agent, et quels droits d’écriture vous avez donnés à l’outil de revue par IA.

Je garde un doute sur ce plafond : le repère date d’avant les assistants de code, et je n’ai trouvé aucune mesure refaite sur du code généré. Découper ne raccourcit pas non plus les 26 heures d’OCaml, et tout relire rendra une partie du gain promis. Faute de mieux, je préfère une PR qui attend.

Questions fréquentes sur la revue de code et l’IA

Le code généré par l’IA est-il sûr ?

Dans son rapport de juillet 2026, Veracode, éditeur de sécurité applicative, mesure que le code généré par IA réussit en moyenne 56 % des tests de sécurité. Le meilleur modèle testé échoue encore sur près d’une tâche sur trois, et les échecs se concentrent sur le XSS et l’injection de logs. Les modèles inventent aussi des dépendances : chez ceux de 2023 et 2024, près d’un paquet recommandé sur cinq n’existait pas.

Peut-on confier la revue de code à une IA ?

Une IA peut relire une partie du travail. Selon GitHub, qui parle de son propre outil de code review IA, Copilot traitait en mars 2026 plus d’une revue sur cinq sur la plateforme. Sur le classement HELM, quand deux modèles se trompent, ils choisissent en moyenne la même mauvaise réponse environ 60 % du temps. Un relecteur automatique peut aussi être attaqué, comme l’ont montré CamoLeak et la faille de CodeRabbit.

Quelles sont les bonnes pratiques de revue de code avec l’IA ?

Les repères connus datent d’avant l’IA. L’étude menée chez Cisco et publiée par SmartBear conseille de ne pas relire plus de 200 à 400 lignes à la fois, à moins de 500 lignes par heure. Demander explicitement de regarder la sécurité multiplie par huit la probabilité de trouver la faille. Vérifiez aussi qui peut lever l’approbation humaine des workflows lancés par un agent, ce que GitHub permet à un administrateur depuis le 13 mars 2026.

Sources