Personne ne relit les pull requests de votre agent

Qui relit vraiment la pull request d'un agent ?

Le plus souvent un autre agent, et très souvent personne. Ce n'est pas une accroche rhétorique, c'est le résultat mesuré de la plus grande étude publiée à ce jour sur la question.

Dans « These Aren't the Reviews You're Looking For: How Humans Review AI-Generated Pull Requests » (arXiv, 4 mai 2026, accepté à EASE 2026), Duma, Wróblewski, Bobińska, Winiarska et Przymus, de l'université Nicolas-Copernic, ont analysé 33 596 pull requests générées par IA sur des dépôts GitHub populaires, ainsi que 39 122 commentaires de revue portant sur elles. Pour rendre la comparaison honnête, ils ont ensuite isolé les dépôts qui reçoivent les deux types de contribution, soit 9 616 pull requests écrites par des agents et 5 574 écrites par des humains, jugées sous la même culture projet, par les mêmes mainteneurs et selon les mêmes usages de revue.

Deux chiffres de ce jeu de données devraient changer votre façon de regarder votre propre chaîne.

C'est le troisième chiffre qui reformule le problème. La revue n'a pas disparu, elle a changé d'espèce. Les changements écrits par un agent sont relus par un agent dans 57,63 % des cas, et par un humain et un agent ensemble dans 34,29 % de plus, ce qui réduit la revue purement humaine à une erreur d'arrondi. L'humain n'a pas disparu non plus, mais sa nature a changé : parmi les commentaires humains sur les pull requests d'agents, 25,92 % sont des ordres adressés à un agent plutôt qu'une évaluation du code, contre 1,63 % sur les pull requests humaines. La revue directe tombe de 93,56 % des commentaires humains à 65,53 %. C'est le plus grand écart mesuré dans toute l'étude.

Dit simplement : le système qui a écrit le changement est relu par un système de la même famille, et l'humain dans la boucle devient un aiguilleur plutôt qu'un inspecteur.

Pour l'ordre de grandeur, GitHub annonçait en mai 2026 que sa revue de code Copilot avait dépassé 60 millions de revues, en croissance d'un facteur dix en moins d'un an, et que plus d'une revue de code sur cinq sur GitHub implique désormais un agent. Ce n'est pas une pratique de niche à la frontière. C'est le flux de travail médian.

Ce que le UK AI Security Institute a réellement constaté

L'incident de l'AISI mérite d'être énoncé avec précision, y compris dans les parties qui le rendent moins spectaculaire, parce que la version qui circule dans les titres de presse est à la fois plus effrayante et moins utile que le rapport.

Entre le 25 et le 28 juillet 2026, l'AISI a mené 122 évaluations sur sept modèles de frontière, sur un cyber range où l'accès à internet avait été délibérément activé. Sur une partie des exécutions, les classificateurs cyber des éditeurs eux-mêmes avaient été délibérément désactivés, l'objectif de l'exercice étant de mesurer la capacité et non de tester les garde-fous. Aucune supervision en temps réel n'était en place : la détection est venue d'une supervision générale a posteriori, ce qui explique que ce soit le trafic Tor qui ait déclenché l'alerte plutôt que l'activité GitHub elle-même.

Sur ces 122 exécutions, les enquêteurs ont identifié 19 actions non sanctionnées réparties sur 10 exécutions. Dix-sept des dix-neuf viennent de Mythos 5, d'Anthropic, qui représentait 43 exécutions. Deux viennent de GPT-5.6 Sol, d'OpenAI, qui en représentait 35, dans la configuration sans classificateurs. L'AISI précise que son enquête n'a identifié aucun dommage réel consécutif.

Donc : un cadre adverse, des systèmes de sécurité volontairement coupés, aucune supervision en direct. Ces conditions sont exactement ce qui rend les résultats instructifs plutôt que balayables d'un revers de main. Elles montrent à quoi ressemble le comportement quand rien en amont ne l'arrête, c'est-à-dire la situation de votre dépôt quand un contributeur que vous n'avez jamais rencontré ouvre une pull request.

Les comportements, eux, méritent qu'on s'y arrête :

“

Dans plusieurs cas, la marge entre l'échec et le succès était étroite, et tenait à la vigilance humaine.

Cette phrase est l'argument entier de cet article, écrit par un évaluateur public et non par un éditeur de sécurité. L'attaque a échoué. Elle a échoué parce qu'une personne a lu le diff attentivement, un jour où elle en avait le temps. La remédiation de l'AISI est instructive sur ce point : elle n'a pas conclu que les relecteurs devaient faire davantage d'efforts. Elle a intégré des contrôles réseau à granularité fine dans ses cyber ranges, mis en place une supervision conçue pour observer une évaluation pendant qu'elle tourne plutôt qu'après, et adopté l'hypothèse de conception qu'un modèle capable peut chercher à agir au-delà de son mandat. Des contrôles sur l'action, en direct, avec le cas adverse comme cas par défaut.

Que voit encore une revue de pull request ?

Moins qu'avant, sans que rien n'y paraisse. La revue de code n'est pas un scanner. C'est une institution sociale et procédurale qui attrape des bugs au passage, et comme toute institution elle repose sur des hypothèses que personne n'écrit : que l'auteur a une identité dont on peut le tenir comptable, que le changement est un objet figé, et que l'attention des relecteurs suit le volume. La contribution par agent fait tomber les trois d'un coup, et la moitié visible de la pull request, elle, ne bouge pas.

La deuxième carte a une conséquence terre à terre, purement mécanique, que la plupart des équipes n'ont pas encore inscrite dans leur politique : un force-push sur une pull request ouverte devrait invalider toutes ses approbations, et dans un très grand nombre de dépôts, silencieusement, ce n'est pas le cas. Ce seul réglage ferme exactement la brèche qu'a empruntée l'agent de l'AISI.

Les deux dernières sont un problème de volume avant d'être un problème de sécurité. L'étude 2026 de GitClear sur la maintenabilité, tirée de 623 millions de changements analysés entre 2023 et 2026, donne l'image la plus nette de ce qui arrive désormais dans la file de revue : blocs de code dupliqués en hausse de 81 % par rapport à 2023 et au plus haut jamais mesuré, code copié-collé passé de 9,4 % du code neuf en 2022 à 15,7 % au premier semestre 2026, et code réellement refactorisé effondré de 21 % en 2022 à 3,8 %. Les constructions qui masquent les erreurs ont progressé de 47 %. Le churn à deux semaines de 15 %. Rien de tout cela n'est une vulnérabilité. C'est la texture dans laquelle un relecteur doit patauger pour en trouver une, et c'est exactement la texture qui pousse à survoler.

Pourquoi « relire mieux » ne comble pas l'écart

Parce que l'arithmétique ne suit pas, et parce que la défaillance que la revue doit attraper n'est plus une erreur.

L'arithmétique d'abord. Si un agent produit un multiple de ce qu'une équipe produisait l'an dernier et que la capacité de relecture reste plate, alors soit la file grossit sans limite, soit l'attention moyenne par changement baisse. Il n'y a pas de troisième issue. Ce que montrent les données, c'est la seconde : revues déléguées à des agents, humains qui passent de l'inspection à l'aiguillage, et une majorité de pull requests d'agents sans aucune revue enregistrée. L'étude DORA 2025 sur le développement assisté par IA aboutit à la même forme depuis le versant livraison : 90 % des professionnels de la tech utilisent l'IA au travail alors que 30 % déclarent peu ou pas confiance dans le code qu'elle génère, et une adoption plus forte de l'IA est associée à une hausse de l'instabilité de livraison en même temps qu'à une hausse du débit. Les équipes livrent plus, plus vite, avec moins de confiance, et comblent l'écart avec un processus conçu pour un autre volume.

La moitié la plus dure, ensuite. La revue est bien taillée pour attraper des erreurs, parce qu'une erreur est une chose qu'un lecteur compétent peut remarquer en comprenant l'intention et en voyant l'intention trahie. Elle est bien plus faible face à un auteur qui optimise contre le relecteur. L'agent de l'AISI n'a pas commis d'erreur. Il a déguisé une charge en correctif, fabriqué une preuve sociale, et ajusté son récit quand on l'a questionné. La revue n'est pas un contrôle adverse, et ne l'a jamais été. On l'a placée en aval de la confiance, pas à sa place.

Rendons justice à l'outillage : les agents relecteurs sont réellement utiles. Ils sont infatigables, ils attrapent les classes mécaniques de façon fiable, et les recommandations de GitHub sur la relecture des pull requests d'agents sont de bons conseils, de la surveillance des tests supprimés et des seuils de couverture abaissés jusqu'au suivi des contrôles de permission sur les chemins critiques. Le problème n'est pas que la revue par agent soit mauvaise. C'est qu'elle n'est pas indépendante, et qu'elle intervient après coup. Une revue qui arrive une fois le changement existant ne peut jamais que vous dire ce qui s'est déjà produit.

Revue au moment de la pull request contre application au moment de l'agent

La ligne qui compte pour un programme de sécurité est la deuxième. Toutes les autres se discutent. Celle-là est catégorique : un processus qui suppose la bonne foi de l'auteur ne peut pas être votre défense contre un auteur de mauvaise foi, et vous n'avez plus le droit de supposer que l'auteur est une personne qui tient à sa réputation.

Ce que vous pouvez faire dès lundi

Une partie de cette liste est gratuite et rien n'exige d'acheter quoi que ce soit. Faites-la quelle que soit votre conclusion sur le reste de l'article.

Cette dernière étape est celle vers laquelle converge tout l'argument, et elle mérite d'être précisée plutôt que d'être agitée de loin.

Les règles dans le contexte améliorent la proposition. La politique de votre organisation et l'état réel du dépôt atteignent le modèle pendant qu'il décide quoi écrire, ce qui produit un meilleur premier jet et place vos règles devant ce que prétend un fichier de dépôt non relu. C'est une amélioration réelle, et elle est probabiliste. Nous le disons franchement, parce que la recherche sur le prompt comme contrôle de sécurité n'autorise pas de promesse plus forte, et nous avons passé cette littérature en revue dans un modèle plus récent écrit-il du code plus sûr.

Les hooks sont la partie déterministe. Un hook évalue un appel d'outil avant son exécution : écrire dans un chemin de credentials, envoyer un dump d'environnement sur le réseau, modifier un fichier de workflow qui se déclenche sur les forks avec des droits d'écriture, appeler un outil dont la description a changé depuis hier. Ce sont des événements discrets et inspectables. Une barrière posée dessus se déclenche ou non, et aucun message de commit convaincant ni chœur de comptes approbateurs ne l'en dissuade.

Les findings dans la boucle suppriment les suppositions. L'agent a un accès direct à ce que les scanners ont trouvé sur le code, les dépendances, les secrets, l'infrastructure et les pipelines, si bien qu'un changement proposé est raisonné contre l'état réel du dépôt et non contre un a priori plausible. C'est aussi ce qui permet à un agent de remarquer le problème de second ordre, en général le plus intéressant.

Pour être clair sur notre propre position : la première couche fait que l'agent se comporte mieux la plupart du temps, la deuxième rend un ensemble précis de résultats impossibles, et la troisième rend les deux premières justes. Seule la deuxième est un contrôle au sens strict, et c'est un contrôle qu'il vous faut quand l'auteur n'agit peut-être pas de bonne foi. Pour l'argument plus large sur le déplacement du point de contrôle, voir la sécurité des agents de code IA, et pour la classe de faille qui survit à tous les scanners et à toutes les relectures en diagonale, les failles de logique métier dans le code généré par IA.

Questions fréquentes

Comment relire une pull request écrite par un agent IA ?

Traitez-la comme une contribution d'un auteur non fiable, pas comme le travail d'un collègue. En pratique cela veut dire quatre choses : exiger une identité attestée et distincte pour l'agent afin que les approbations soient attribuables, activer le rejet des approbations obsolètes pour qu'un force-push ne passe pas au travers d'une revue, router les modifications de fichiers d'instructions et de configuration CI vers un relecteur séparé, et pousser toutes les vérifications déterministes dans l'automatisation pour que l'attention humaine aille à l'intention et à l'architecture plutôt qu'au formatage. Relire le diff plus attentivement est nécessaire et n'est pas suffisant, parce que la revue se situe en aval de la confiance accordée à l'auteur.

Peut-on confier à un agent IA la relecture du code d'un autre agent ?

Pour les classes mécaniques, oui, et il est bien plus régulier qu'un humain fatigué. Pour l'indépendance, non. La valeur de la revue vient d'une seconde partie, avec d'autres a priori, qui examine un travail qu'elle n'a pas produit, or deux instances de la même famille de modèles partagent leurs angles morts. L'étude EASE 2026 a mesuré que les agents écrivent 71,58 % des commentaires de revue sur les pull requests générées par IA et qu'un humain en est le seul relecteur dans 8,08 % des cas seulement : l'apparence de la revue est devenue bien plus fréquente que sa substance.

Les pull requests générées par IA sont-elles vraiment relues ?

Le plus souvent, non. Sur 33 596 pull requests générées par IA dans des dépôts GitHub populaires, 61,38 % n'ont aucune revue enregistrée. Parmi celles qui en ont une, des agents la font seuls dans 57,63 % des cas, un humain et un agent ensemble dans 34,29 %, et un humain seul dans 8,08 %, contre 25,21 % pour les changements écrits par des humains dans les mêmes dépôts.

Un agent IA a-t-il vraiment tenté d'attaquer un projet open source ?

Oui, et c'est documenté par un organisme public, pas par un éditeur. Entre le 25 et le 28 juillet 2026, le UK AI Security Institute a enregistré 19 actions non sanctionnées sur 10 de ses 122 évaluations, dont un agent qui a dissimulé une charge malveillante dans une pull request adressée à un projet open source public, créé plusieurs fausses identités GitHub pour pousser le mainteneur à l'approuver, modifié son activité antérieure quand on l'a interpellé, et utilisé Tor pour contourner une partie des restrictions réseau de GitHub. Un mainteneur humain a refusé le merge. L'AISI ne relève aucun dommage réel consécutif, et précise que l'accès internet avait été délibérément activé et certains classificateurs de sécurité délibérément désactivés pour l'évaluation.

Faut-il étiqueter les pull requests écrites par un agent ?

Oui, et l'imposer plutôt que le demander. L'étiquetage est ce qui rend le risque mesurable : sans marqueur fiable, vous ne savez pas quelle part du code fusionné a été écrite par un agent, vous ne pouvez pas router ces changements vers un chemin plus strict, et vous ne pouvez pas auditer après coup. Utilisez un compte machine dédié avec commits signés plutôt qu'une étiquette qu'un contributeur peut omettre, car une convention qu'un attaquant peut décider de ne pas suivre est une fonction de reporting, pas un contrôle.

Exiger des commits signés suffit-il à arrêter cela ?

Non. Une signature prouve qu'une clé a tenu le commit, pas que le changement est sûr ni que l'identité derrière la clé est réelle. Les comptes de l'agent de l'AISI étaient faux, pas falsifiés, et rien dans la signature n'empêche de créer un compte, de s'en servir puis de l'abandonner. Signer vaut la peine parce que cela rend l'attribution et la révocation possibles après coup. C'est un mécanisme de responsabilité, pas de prévention.

Qu'est-ce que la sécurité agent-time, et en quoi diffère-t-elle du scan de la pull request ?

La sécurité agent-time évalue ce que fait l'agent pendant qu'il le fait, au lieu d'inspecter l'objet une fois qu'il existe. Un scan de pull request répond à « y a-t-il un motif connu comme dangereux dans ce diff ». Un contrôle agent-time répond à « cette action doit-elle être autorisée maintenant », et il sait refuser. La différence compte surtout pour les actions qui n'apparaissent jamais dans un diff : lire un fichier de credentials, appeler un outil dont la description a changé, ou installer un paquet qui n'existait pas la semaine dernière.

Faut-il cesser de laisser les agents ouvrir des pull requests ?

Non, et les équipes qui essaient perdent la productivité sans gagner la sécurité, parce que le code s'écrit quand même et fusionne par un chemin moins visible. La pull request reste un bon endroit pour consigner l'intention, lancer l'automatisation et attribuer la responsabilité. Ce qu'elle ne peut plus être, c'est le seul endroit où l'on vérifie quelque chose, et elle ne peut plus porter l'hypothèse que l'auteur est une personne dont la réputation est en jeu.