Revue de code agentique

• L'amélioration fulgurante des performances des agents de codage déplace le point difficile de l’ingénierie de l’écriture du code vers le fait de décider si l’on peut lui faire confiance ; la revue devient alors la tâche au plus fort effet de levier
• L’IA augmente fortement la production, mais dégrade la qualité et la facilité de revue ; un écart mesuré montre qu’avec 4 fois plus de code, la valeur réelle n’augmente que d’environ 10 %
• L’intensité de revue nécessaire varie selon le blast radius (rayon d’impact) du changement ; un développeur solo et une équipe qui maintient un grand système vieux de 10 ans n’ont absolument pas les mêmes contraintes
• Les agents raisonnent, mais ce raisonnement n’est pas joint à la PR et est jeté, ce qui impose au reviewer de reconstruire depuis zéro une intention disparue
• Écrire est devenu moins coûteux, mais comprendre reste cher ; les équipes qui construiront un système de revue digne de confiance prendront l’avantage à l’avenir

---

Ce que montrent réellement les données de 2026

• Des affirmations qui relevaient pendant des années de l’anecdote ou du débat sont désormais mesurées à grande échelle par des organisations aux intérêts divergents, parfois concurrentes ; elles arrivent toutes à la même conclusion : l’IA fait exploser la production, mais dégrade la qualité et la possibilité de revue

• Mesures Faros AI (données de mars 2026)

  • Suivi de 4 000 équipes et 22 000 développeurs lors du passage d’une faible adoption de l’IA à une forte adoption
  • Côté positif : les développeurs fusionnent plus de PR et terminent plus de travail, le débit par ingénieur augmente
  • Chiffres négatifs
    • le churn de code augmente de 861 %
    • le ratio incidents / PR augmente de 242,7 %
    • le taux de défauts par développeur passe de 9 % à 54 %
    • le temps médian de revue augmente de 441,5 % (le temps avant première revue et le temps moyen de revue doublent tous deux environ)
    • les PR fusionnées sans revue augmentent de 31,3 %
  • Les merges sans revue ne résultent pas d’un choix conscient : les reviewers n’arrivent plus à suivre le volume, et du code jamais lu est fusionné au quotidien
  • Même les équipes aux pratiques d’ingénierie matures et disciplinées sont touchées de la même manière ; un bon process ne protège pas (le volume arrive plus vite que la vitesse à laquelle on peut concevoir le process)

• Étude CodeRabbit (décembre 2025)

  • Analyse de 470 PR open source (320 coécrites par IA, 150 écrites uniquement par des humains) ; les changements issus de l’IA s’accompagnent d’environ 1,7 fois plus de problèmes
    • environ 75 % de problèmes supplémentaires de logique et de justesse
    • 1,5 à 2 fois plus de problèmes de sécurité
    • plus de 3 fois plus de problèmes de lisibilité
  • David Loker, directeur IA : « une faiblesse prévisible et mesurable que les organisations doivent atténuer activement » — puisqu’elle est connue et localisable, on peut viser le process de revue avec précision

• Données de productivité GitClear (jusqu’en 2025)

  • Les utilisateurs qui emploient l’IA tous les jours ont environ 4 fois plus de production brute que les non-utilisateurs, mais par rapport à eux-mêmes un an plus tôt, le gain réel de productivité n’est que d’environ 12 %
  • La structure reste la même : 4 fois plus de code à faire relire intégralement par des humains
  • Bill Harding précise que même ces 12 % relèvent en partie d’un biais de sélection (les développeurs les plus solides se concentrent dans le groupe IA)

• Rapport GitHub

  • Copilot Review a été exécuté plus de 60 millions de fois au total, soit une croissance par 10 en un an ; plus d’une revue sur cinq sur la plateforme implique désormais un agent
  • Ce n’est plus une pratique de niche, mais la façon même dont le code est produit
• Quatre jeux de données, quatre méthodologies, une même conclusion : le goulot d’étranglement ne disparaît pas, il se déplace vers l’étape de vérification

Tout le monde ne résout pas le même problème

• La plupart des données alarmantes ci-dessus proviennent de télémétrie d’entreprise et de mainteneurs open source submergés ; elles s’appliquent en grande partie beaucoup moins au développeur solo qui construit quelque chose utilisé par très peu de personnes

• Trois variables déterminent votre position

  • blast radius : ce qui se passe si ça casse — rien du tout, ou bien des utilisateurs furieux, de l’argent perdu, une fuite de données personnelles
  • durée de vie du code : un prototype jetable à réécrire la semaine suivante, ou une base de code maintenue pendant des années
  • nombre de personnes qui doivent comprendre : uniquement vous, qui avez tout en tête, ou une équipe qui partage la propriété dans le temps

• Solo, greenfield, aucun utilisateur

  • Le second rôle de la revue, la distribution de connaissance dans l’équipe, n’existe pas (vous êtes l’équipe)
  • Choix raisonnable : s’appuyer fortement sur les tests et l’automatisation, ne relire en profondeur que les parties vraiment importantes, et effleurer le reste
  • Mais cela ne fonctionne que si les tests sont réels ; sauter la revue sans filet de sécurité ne fait pas disparaître le travail, cela le diffère simplement à un coût plus élevé
  • « Aucun utilisateur » autorise à différer la revue, pas à sauter la vérification

• Le milieu dangereux

  • Dès qu’un projet a des utilisateurs, le rôle de chasse aux bugs devient soudain crucial (les bugs nuisent à des gens) et le rôle de partage de connaissance s’active lui aussi
  • Quand une équipe conserve encore quelques mois les habitudes de l’époque solo avant de se prendre un postmortem, les chiffres de Faros deviennent son propre dashboard

• Grandes organisations, bases de code anciennes, beaucoup d’utilisateurs

  • Tous les chiffres d’alerte s’appliquent à intensité maximale ; un changement que personne ne comprend devient une comprehension debt (dette de compréhension) qui finira en incident d’astreinte pour quelqu’un
  • Le point central n’est pas « l’entreprise doit être prudente, le solo peut être relax » mais que l’objectif de la revue change selon la position, donc les règles doivent changer aussi
  • Greffer un pipeline d’entreprise avec multi-agents et exigences de preuves à un prototype à deux personnes crée une friction absurde ; appliquer « les tests passent donc on déploie » à un système de paiement fabrique des incidents avec coche verte

Ce que fait réellement la revue aujourd’hui

• Quand un humain écrit du code, l’intention vient gratuitement avec ; les alternatives pesées puis abandonnées restent dans la tête de l’auteur, et la revue consistait à examiner ce raisonnement
• Les agents modernes raisonnent aussi, et affichent parfois visiblement leur thinking trace, mais ce raisonnement est jeté au moment où le diff est produit et n’est pas joint à la PR
• En plus, il s’agit du raisonnement de l’agent sur comment implémenter, pas du jugement humain sur si c’est la bonne chose à faire
• Résultat : la revue ne consiste plus à vérifier un raisonnement visible sous les yeux, mais à reconstruire une intention non documentée, ce qui la rend plus difficile et plus lente (d’où les 441 % supplémentaires)

• AI Slop and the Software Commons (article de 2026)

  • Analyse de 1 154 messages issus de 15 fils Reddit et Hacker News
  • Formulation d’un développeur : relire une PR d’agent fait de lui « le premier humain à voir ce code »
  • Selon l’article, la revue « n’a pas été conçue pour restaurer une intention disparue »

• La solution est un problème d’outillage

  • L’intention disparue peut être restaurée — le raisonnement existait, il a simplement été jeté
  • Si l’on force l’agent à expliciter ce qu’il essayait de faire et ce qu’il a écarté, puis qu’on capture cela dans la PR comme decision log (journal de décision), une grande partie du coût de reconstruction disparaît
• « Une IA qui relit une IA » n’est pas à elle seule une réponse complète ; un second modèle avec d’autres connaissances préalables attrape beaucoup de vrais bugs, mais n’apporte pas le jugement humain sur la question “ce changement mérite-t-il d’exister ?”

Les outils sont bons, mais pas pour la raison qu’ils mettent en avant

• Les outils de revue IA dédiés sont désormais suffisamment bons, et il est recommandé d’exécuter au minimum un agent principal de codage (et si possible un agent de revue dédié) sur tout, y compris les side projects

• Caractéristiques des principaux outils

  • CodeRabbit : le plus largement déployé ; n°1 en F1 sur le benchmark indépendant Martian (janvier-février 2026), précision d’environ 49 % et meilleur recall du secteur
  • Greptile : sacrifie de la précision pour gagner en recall ; dans un benchmark, environ 82 % de détection de bugs (contre 44 % pour CodeRabbit), mais davantage de faux positifs
  • Anthropic Code Review : moins de 1 % des résultats signalés comme erronés par les ingénieurs maison ; la part de PR recevant une vraie revue passe de 16 % à 54 %

• Expérience à 4 reviewers en parallèle (résultat hors éditeurs)

  • Un ingénieur a appliqué en parallèle CodeRabbit, Sentry Seer, Greptile et Cursor BugBot pendant trois semaines et demie sur 146 vraies PR, pour 679 détections
  • Parmi 617 emplacements signalés uniques, 93,4 % n’ont été détectés que par un seul outil, 6 % par deux, presque aucun par trois, et aucun par les quatre
  • Les quatre outils n’ont pas signalé ensemble la même ligne une seule fois
  • Chaque outil a ses points forts : Greptile est presque sans faux positifs sur la justesse et l’architecture, CodeRabbit jette le filet le plus large et propose des corrections en un clic, Seer excelle sur la gravité des incidents de production
  • L’hétérogénéité est la clé — quatre exemplaires du même modèle ne sont qu’un reviewer unique avec une facture plus grosse ; quatre reviewers réellement différents révèlent des bugs qu’aucun ne trouverait seul

• Recommandations pratiques

  • Ne cherchez pas l’outil unique « meilleur » (il n’existe pas)
  • Dans les zones à haut risque, combinez volontairement deux outils de nature différente (dans l’expérience ci-dessus : Greptile pour la justesse du quotidien + Seer pour la gravité des incidents de production)
  • En solo, un bon reviewer et de vrais tests suffisent
  • Indépendamment du marketing, mesurez impérativement sur votre propre code ; tous les résultats sont limités à une base de code donnée

Faut-il confier davantage de revue à l’IA ?

• Une question qui aurait paru hérétique il y a un an est désormais posée par des ingénieurs expérimentés : la machine doit-elle faire une plus grande part de la revue, peut-être même la majorité ?

• Le fait inconfortable : la revue IA fonctionne

  • Moins de 1 % des détections d’Anthropic ont été marquées comme erronées ; l’outil attrape des bugs que les humains laissent passer, et il ne se fatigue pas à la 30e PR de la journée (le moment où la fiabilité humaine est la plus basse)
  • En face, les humains ne suivent pas — les merges sans revue montent de 31 %, les temps de revue augmentent de trois chiffres
  • Le cadrage honnête n’est pas « faut-il lui en confier davantage ? », mais « l’IA en fait déjà ; allons-nous le faire intentionnellement, ou continuer à prétendre que des humains lisent tout ? »

• Le point de vue du loop engineering

  • Le postulat de la boucle n’est plus qu’un humain rédige des prompts pour un agent, mais qu’on construit un système qui rédige des prompts pour des agents, avec au centre un agent juge qui détermine si le travail est terminé
  • Le reviewer devient alors le prochain rôle explicitement retiré de la boucle interne par design ; un an après l’automatisation de l’écriture vient l’automatisation de la vérification, et l’humain remonte d’un niveau

• Le risque de la boucle fermée

  • Si un agent écrit, qu’un autre relit et qu’un troisième juge, on obtient une boucle fermée de modèles ayant des angles morts corrélés, surtout s’ils appartiennent à la même famille et convergent avec assurance sur les mêmes erreurs
  • Un « looks good » assuré sans humain est une confiance empruntée — la certitude du système devient la nôtre alors qu’en réalité personne ne comprend

• L’humain ne disparaît pas, il monte d’un étage

  • Il ne lit plus chaque diff ; il possède ce qui ne se transfère pas aux modèles, et l’accountability compte
  • Ce que l’humain doit garder : décider si c’est le bon changement à produire, poser des gates coûteuses quand le blast radius est élevé, et surveiller les comportements que personne n’a spécifiés (les modèles ne relisent que le code existant et signalent rarement des exigences que personne n’a écrites)
  • Du human in the loop au human on the loop — au lieu de lire chaque PR, on échantillonne, on fait du spot-check, on audite le système et l’on concentre son attention limitée là où l’erreur fait vraiment mal

• Cas Kun Chen (ancien ingénieur Meta L8, builder solo)

  • Il sort environ 40 PR par jour et a pratiquement arrêté la revue de code, en faisant tourner 20 à 30 agents en parallèle
  • Il a déplacé l’effort vers le plan — rédaction détaillée en amont, puis exécution des agents pendant des heures ; la qualité du plan détermine la durée d’exécution autonome
  • Il n’a pas arrêté la vérification ; il écrit lui-même l’intention à l’avance, ce qui résout à moitié le problème du « premier humain à voir le code » (l’humain comprend le pourquoi avant, pas après)
  • Il ne travaille pas sans filet — une gate de revue automatique qu’il appelle No Mistakes inspecte le code avant fusion, et si les agents se bloquent, ils attendent une escalade
  • Mais c’est un builder solo, sans grande équipe ni système vieux de dix ans truffé de pièges ; ses conditions ne sont pas celles de la plupart des lecteurs — les copier dans une équipe au service de nombreux utilisateurs reviendrait à rejouer les chiffres de Faros sur son propre dashboard
• Conclusion sur le spectre : en solo sans utilisateurs, confier presque tout à l’IA est une position défendable en 2026 ; à grande échelle avec de nombreux utilisateurs, les machines prennent le premier et le second passage ainsi que les 90 % ennuyeux, mais il faut garder de vrais humains sur les chemins qui portent la charge, et le bon niveau d’implication humaine se règle non par culpabilité mais par le blast radius

Que faire concrètement

• Principe organisationnel : aligner l’effort de revue sur le coût de l’erreur, avancer au maximum les tâches déterministes et bon marché, et réserver l’attention humaine à ce que seuls les humains peuvent faire

• Hiérarchiser par le risque, pas par l’auteur (Tier by risk, not by author)

  • Un changement de configuration peut se contenter d’un linter et d’un coup d’œil
  • Une modification sur un chemin critique de logique métier doit déclencher la panoplie complète : typage, tests, deux reviewers IA différents, un humain propriétaire du système concerné, et un passage sécurité
  • N’appliquez pas une revue lourde au boilerplate, et ne laissez pas passer un gros changement juste parce que les tests sont verts

• Faire échouer vite la longue traîne coûteuse (Fast-fail the expensive tail)

  • Early-Stage Prediction of Review Effort (janvier 2026), étude sur 33 707 PR rédigées par agent
  • Les agents sont bons sur les petits changements bien définis ; environ 28 % sont fusionnées presque immédiatement, mais dès qu’ils reçoivent un retour subjectif, ils ont tendance à « disparaître » et à abandonner les allers-retours qui constituent le cœur de la revue
  • Un article associé de 2026 montre que l’abandon du reviewer représente 38 % des PR d’agents rejetées
  • Les chercheurs ont construit un circuit breaker qui prédit, avant qu’un humain ne les voie, les PR coûteuses à maintenir à partir de signaux bon marché comme le type de fichiers ou la taille du patch ; cela fonctionne bien

• Relever le seuil de ce qui mérite d’être relu

  • La solution n’est pas de verrouiller le dépôt, mais de refuser la revue des changements arrivés sans preuves
  • Exigences avant revue : expliquer l’objectif du changement, fournir un diff plutôt que 3 500 lignes sans commentaires, joindre la sortie des tests, et montrer qu’on a réellement exécuté le code
  • Au lieu d’absorber soi-même le coût élevé de reconstruction de l’intention, on le renvoie à la personne qui soumet le changement, qui peut le traiter à moindre coût

• Garder les PR délibérément petites

  • Les PR d’agents sont plus grosses (en moyenne 51 % plus grandes dans les données Faros), et la participation des reviewers est l’un des meilleurs prédicteurs de fusion
  • Une PR volumineuse et impossible à relire est soit rejetée immédiatement, soit pire, validée au tampon
  • Demandez aux agents de produire de petits commits ; un diff qu’un humain peut réellement lire n’est plus une politesse, mais une contrainte de conception

• Lire les changements de tests plus attentivement que le code

  • Mode d’échec typique des agents : changer le comportement, puis « réparer » les tests en réécrivant les assertions pour qu’elles correspondent au nouveau comportement cassé
  • Une coche verte au-dessus de 200 tests modifiés ne signifie rien tant qu’on n’a pas vérifié que les modifications étaient justes ; un diff qui réécrit beaucoup de tests doit être traité comme un signal d’alerte et lu en priorité
  • La valeur du mutation testing : la couverture dit qu’une ligne a été exécutée, le test de mutation dit si les tests remarqueraient qu’elle est fausse

• Traiter la CI comme un mur qu’on ne déplace pas

  • Surveillez les patterns que GitHub signale aux reviewers : tests supprimés, lint désactivé, seuils de couverture abaissés, helpers dupliqués alors qu’ils existent déjà, entrées non fiables qui glissent dans un prompt
  • Ce dernier point est particulièrement important — les fonctionnalités créées par des agents ouvrent une nouvelle source de prompt injection ; si l’on transmet tel quel à un appel LLM du texte contrôlé par l’utilisateur, la vulnérabilité n’apparaît pas dans le diff mais dort dans les données futures
  • Les agents peuvent affaiblir la CI sans malveillance simplement pour passer (la descente de gradient trouve le chemin le moins cher vers le vert) ; les gates déterministes sont la seule partie qu’aucun paragraphe sûr de lui ne peut renverser, donc il faut les garder strictes

• Le merge appartient à un humain

  • Un modèle ne peut ni être pagé ni être tenu responsable, donc la personne qui clique sur le bouton de merge en est propriétaire
  • Quand une revue IA dit calmement et avec assurance « looks good », elle transmet forcément une confiance qui n’a pas été réellement gagnée
  • Traitez toute revue IA comme un capteur, pas comme un verdict — une donnée, pas une décision

Ce que cela implique si vous dirigez une équipe

• La contrainte qui limite la livraison n’est plus la vitesse à laquelle on écrit du code, mais la vitesse à laquelle une personne de confiance peut se convaincre de la justesse d’un changement
• Une planification qui voit la génération comme le goulot d’étranglement et traite la revue comme gratuite garde des dashboards de vitesse au vert tout en se figeant silencieusement
• Le rapport Faros dit explicitement que même si la production augmente, le travail de QA et de revue augmente lui aussi ; réduire les effectifs d’ingénierie au motif que « l’IA nous rend plus rapides » avant d’avoir comblé l’écart de revue est dangereux
• Le prélèvement sur les ingénieurs seniors que représentent des temps de revue multipliés par trois chiffres tombe le plus lourdement sur les personnes qui devraient être les moins bloquées, et il reste invisible dans les métriques qui ne comptent que les PR fusionnées
• Les mainteneurs open source ont heurté ce mur les premiers et le plus violemment — un flux continu de contributions plausibles mais creuses, même bien intentionnées, consomme un vrai temps de triage ; c’est le canari dans la mine, l’entreprise est la suivante
• Les organisations qui réagissent bien ne traitent pas la capacité de revue comme une marge de manœuvre libérée par l’IA, mais comme une ressource réelle à mesurer, protéger et dépenser intentionnellement

Écrire est devenu moins cher, pas comprendre

• N’acceptez pas les réponses uniformes aux deux extrêmes — pour un solo sans utilisateurs, les récits d’horreur de churn et de duplication d’entreprise ne sont pas l’incendie du jour mais un risque futur ; appuyez-vous sur les tests et ne relisez que l’important, tout en reconnaissant honnêtement que le travail différé reste une dette
• À grande échelle avec beaucoup d’utilisateurs, tous les chiffres d’alerte vous concernent directement, et la seule réponse valable est une revue hiérarchisée, fondée sur des preuves, volontairement hétérogène, avec un humain propriétaire du merge
• Ce qui ne change pas sur tout le spectre, c’est l’économie fondamentale — l’écriture est devenue bon marché, la compréhension est restée aussi chère qu’elle l’a toujours été
• Les équipes qui réussiront demain ne seront pas celles qui génèrent le plus de code, mais celles qui bâtissent un système de revue réellement digne de confiance, sans jamais confondre « les tests passent » avec « un humain comprend ce que cela fait et pourquoi »
• Comme le dit Simon Willison, la nature du travail consiste à livrer du code dont on a prouvé qu’il fonctionne — les agents n’ont pas changé cela ; ils ont fait de cette preuve non plus une tâche secondaire, mais le centre du travail
• La capacité à comprendre suffisamment un système pour pouvoir se porter derrière lui reste la compétence la plus durable et la plus intéressante du logiciel, et il n’y a jamais eu de meilleur moment pour devenir exceptionnellement bon à cela