En 2026, GitHub annonçait que l’utilisation de Copilot Code Review avait été multipliée par dix en moins d’un an. La production de code s’accélère. Les reviewers, eux, ne se sont pas démultipliés.

Reviewer une PR prend toujours du temps : relire le ticket, comprendre ce qui a été fait, lancer la branche, regarder les tests, vérifier qu’on n’a pas recréé un truc qui existait déjà ailleurs.

Quand on est seule sur son domaine, comme moi, le problème existe déjà sans IA. Il est très facile de demander dans le miroir :

« T’es sûre de ton code ? »

Et de se répondre oui.

Évidemment que je suis sûre. C’est moi qui viens de passer une semaine dessus.

Erreur. Échec total. Infamie.

Rien de plus trompeur qu’un développeur et la fierté qu’il porte à la feature qu’il vient de terminer.

Quand les agents de programmation sont devenus réellement bons, début 2025, je me suis donc dit : youpi, enfin un potentiel « collègue » capable de juger mon code et d’y trouver des failles, une mauvaise utilisation du langage… Parce que l’auto-review permanente, c’est un peu l’ouroboros du développement logiciel.

Aujourd’hui, faire reviewer son code par une IA est facile. Copilot, Claude Code, Codex, CodeRabbit, Greptile : les solutions ne manquent pas.

La vraie question devient plutôt : comment éviter que cette IA me fasse une review complètement nulle ?

Un reviewer qui veut trop aider

Un modèle peut être mauvais dans deux directions : il peut vous féliciter pour votre naming exceptionnel, ou sortir quinze commentaires dont douze décrivent des problèmes imaginaires.

Une étude publiée en 2026 sur CodeRabbit a analysé plus de 31 000 couples commentaire/réponse provenant de plus de 10 000 PR. Seulement 36,4 % des commentaires étudiés ont été acceptés. Parmi les causes de rejet : les faux positifs, les remarques redondantes, les problèmes hors scope et la mauvaise compréhension de l’intention du développeur.

Le problème devient vite celui du rapport signal/bruit. Demander au modèle de faire davantage n’arrange pas forcément les choses.

Une étude publiée en 2026 observe un phénomène de surcorrection sur plusieurs benchmarks de code : selon le modèle et la tâche, demander une explication ou une correction peut conduire le modèle à rejeter des implémentations correctes, parfois en invoquant des exigences absentes. Ces résultats ne mesurent pas directement la qualité des reviews de PR, mais montrent que demander plus de raisonnement ne garantit pas une meilleure évaluation.

Un bon reviewer sait parfois répondre : « Rien à signaler. » Je veux la même chose de mon agent : s’il n’a rien de solide, qu’il se taise. Pas facile pour un LLM de se taire.

Own your code

Si je merge ce code, c’est mon code. S’il bugue, c’est entièrement de ma faute.

« Oui, non, mais ils ont nerfé 5.6 depuis hier… »

Ça reste ton code. Tu es responsable de son développement et de ses conséquences.

Peu importe qu’il ait été écrit par moi, Claude ou autre : l’agent ne sera pas là six mois plus tard quand le bug apparaîtra.

Son rôle n’est donc pas de décider si je peux merger, mais plutôt de me dire : « Essaie de me donner de bonnes raisons de ne pas merger. » Je peux défendre mes choix et leurs compromis. Lui cherche les endroits où mon raisonnement casse.

Ce que je veux qu’il cherche

Le lint et le formatage n’ont pas besoin d’un LLM, alors je préfère utiliser le modèle sur quelques patterns précis.

Le code dupliqué

Les agents reproduisent très bien les patterns existants. Parfois trop bien. S’il y a de mauvaises habitudes dans votre codebase, il les reprendra sans harness adapté.

Un nouveau helper apparaît alors qu’un équivalent existe déjà trois dossiers plus loin. Une étude de 2026 sur des PR générées par des agents observe justement davantage de redondance et moins de réutilisation que dans les contributions humaines étudiées.

Donc, lorsqu’une nouvelle abstraction apparaît, je veux que mon reviewer cherche dans le repository avant de commenter. Pas pour interdire la duplication. Trois lignes répétées valent parfois mieux qu’une abstraction prématurée.

Les tests qui ne testent rien

Les agents aiment beaucoup produire des tests. Oh que oui.

Le test qui vérifie l’implémentation plutôt que le comportement, celui qui mock absolument tout, ou le fix accompagné d’un test qui passait déjà avant le fix.

Pour une correction de bug, une question suffit souvent : est-ce que ce test échoue sans le changement ? Je ne veux pas que mon reviewer compte les tests. Je veux qu’il challenge leur utilité. Pour le moment, c’est moi qui dois le faire.

Le naming bizarre

Les modèles nomment généralement bien les choses. Le problème arrive quand ils inventent un nouveau vocabulaire.

Si toute l’application parle de Recipe, introduire un CulinaryContentEntity n’apporte probablement rien. Deux noms pour le même concept finissent vite par créer deux concepts dans le code. Pour ce cas, un système de glossaire aidera grandement : mettez-y vos termes métiers et leur définition.

Les abstractions inutiles

Une feature simple peut soudain produire une interface, une implémentation, une factory, un adapter et trois extensions.

Qu’est-ce qu’on gagne réellement avec cette abstraction aujourd’hui ? Si la réponse est « ça pourrait servir plus tard », on peut probablement attendre plus tard. CQFD.

Un reviewer n’est pas un coding agent

GitHub a raconté comment de meilleurs outils d’exploration avaient d’abord rendu Copilot Code Review moins bon.

Le modèle explorait trop le repository. Il se comportait comme un agent chargé de coder.

Ils ont fini par resserrer son workflow :

diff ↓ problème potentiel ↓ recherche ciblée ↓ preuve ↓ commentaire ou silence

Cette logique me paraît beaucoup plus adaptée à la review. Pour coder, je veux qu’un agent explore. Pour reviewer, je veux qu’il commence par le diff, formule une hypothèse, puis cherche uniquement ce qui lui permet de la vérifier.

Le contexte reste utile, mais il doit avoir une raison d’être : fichier voisin, symbole référencé, composant partagé, règle d’architecture.

Un bon reviewer n’est donc pas juste un bon modèle avec beaucoup d’outils. Il faut surtout lui apprendre comment les utiliser.

Un commentaire doit avoir une preuve

« Cette condition pourrait provoquer un comportement inattendu dans certains edge cases. »

Il faut demander à l’agent d’être précis pour faire gagner du temps à tout le monde.

« Lorsque refreshToken() retourne 401, retryRequest() peut lancer un second refresh avant que le premier soit terminé. Voir AuthClient.swift:82 et TokenStore.swift:41. »

On a le détail et des références précises. C’est ce qu’on attend d’un outil qui peut prendre le temps de donner les détails exacts de ses retours.

L’agent doit répondre à ces questions :

  • Où ?
  • Dans quelles conditions ?
  • Quel impact ?
  • Quelle preuve ?

Mais je pousserais maintenant la logique un peu plus loin. La review ne devrait pas être publiée dès qu’un agent croit avoir trouvé quelque chose. Pour limiter les faux positifs, il devrait d’abord survivre à une seconde étape de validation :

détection ↓ recherche de preuve ↓ vérification ↓ confiance suffisante ? ↓ commentaire ou silence

C’est d’ailleurs le genre d’architecture qu’on retrouve désormais dans plusieurs reviewers agentiques : plusieurs passes ou agents cherchent des problèmes, puis une étape supplémentaire filtre les reviews les moins solides.

Le reviewer ne doit donc pas seulement savoir trouver des problèmes. Il doit aussi savoir éliminer ses propres hallucinations avant de me les envoyer.

Lui apprendre le projet

Un modèle sait reviewer du Swift, du Dart ou du TypeScript. Il connaît la documentation par cœur. Il ne connaît pas forcément mon projet et ses contraintes.

Il ne sait pas que je travaille en feature-first, qu’un repository précis est la source de vérité d’une donnée, qu’une abstraction a été évitée volontairement ou que je souhaite intégrer telle nouveauté du langage.

C’est là que AGENTS.md, les instructions du repository ou un skill maison deviennent utiles. Pas pour lui expliquer qu’une fonction doit avoir un bon nom, mais pour lui transmettre les règles de la maison :

Architecture : - feature-first - domaine indépendant des modèles API - mapping DTO → domaine à la frontière du repository Priorités de review : - sources de vérité dupliquées - concepts métier dupliqués - abstractions inutiles - problèmes d’async et de concurrence - tests inutiles

L’architecture, le vocabulaire métier, les règles de review et éventuellement le ticket ou la Definition of Done peuvent être accessibles à l’agent lorsqu’il en a besoin. À partir de là, je commence à définir le comportement attendu du reviewer.

Tester son reviewer

Comme n’importe quel agent, il faut ensuite l’évaluer.

Je peux reprendre d’anciennes PR ou en créer de fausses avec une liste d’erreurs que l’agent doit trouver.

Puis regarder ses retours :

  • Correct ?
  • Utile ?
  • Hors scope ?
  • Faux positif ?

La métrique intéressante n’est pas le nombre de commentaires, mais le rapport signal/bruit.

Si mon reviewer me sort vingt commentaires que je dois moi-même reviewer pendant quinze minutes pour trouver les deux utiles, j’ai juste déplacé le problème. Et le code review étant le bottleneck actuel de l’AI Engineering, on va éviter d’en rajouter.

Chaque retour peut finir dans trois catégories simples :

Addressed Won't fix Incorrect

Si le reviewer produit régulièrement des Incorrect, il faut comprendre pourquoi et le raffiner. S’il remonte toujours le même type de remarque que je classe Won't fix, mon skill est probablement mal écrit.

Le meilleur skill de review, c’est celui qui aura appris de plusieurs reviews réelles.

Toutes les PR ne méritent pas la même review

Si les agents produisent beaucoup plus de code mais que chaque ligne reçoit exactement le même niveau de review humaine qu’avant, on déplace simplement le bottleneck.

Une approche intéressante consiste à adapter la review au rayon d’impact (vous retrouverez souvent le terme « blast radius » dans d’autres articles).

Un changement de texte n’a pas besoin du même niveau de contrôle qu’une modification sur l’authentification, une migration ou du stockage, sauf si vous n’en avez vraiment rien à faire de vos tokens.

Et la taille du diff ne suffit pas :

if user.isAdmin if !user.isAdmin

Une ligne peut suffire.

Pour un changement simple :

Agent coding ↓ Agent review ↓ Tests ↓ Merge

Pour quelque chose de plus risqué :

Agent coding ↓ Agent review ↓ Rapport ciblé ↓ Human review ↓ Tests ↓ Merge

L’humain intervient là où son contexte et son jugement ont réellement de la valeur. On utilise le terme HITL, pour human in the loop, quand on doit intervenir pendant le travail d’un agent.

Faire des PR plus petites

Il reste enfin la solution la moins sexy : produire moins de code à la fois. Des petites PR pour de meilleurs résultats, quand c’est possible, peu importe qui a fait la PR, humain ou agent.

Les agents peuvent transformer une demande simple en une PR avec des dizaines de fichiers. Ils aiment bien surdévelopper, encore plus si on utilise un modèle trop « intelligent » pour le travail.

Ils ont peut-être correctement exécuté la tâche d’un point de vue fonctionnel, mais ont touché à quatre fichiers et fait un refacto parce qu’ils se sont sentis pousser des ailes, au lieu de répondre à la demande en deux lignes.

Plutôt que :

Implement authentication

je préfère :

PR 1 : Domain + contracts PR 2 : API implementation PR 3 : Authentication state PR 4 : Login UI PR 5 : Error / retry flows

Produire cinq PR avec un agent ne coûte plus très cher, alors que comprendre une PR de 2 000 lignes trois jours plus tard coûte beaucoup plus. Comme vous devriez déjà le faire dans une équipe humaine.

Outil générique ou skill maison ?

Copilot Code Review, Claude Code Review, CodeRabbit ou Greptile s’intègrent directement au workflow, mais vous pouvez aussi mettre en place vos propres solutions.

Actuellement, sur mes projets, j’essaie de mettre en place des itérations : création initiale du skill, tests avec des PR simples ou complexes, évaluation et raffinement jusqu’à obtenir le résultat attendu. C’est valable pour le code review comme pour d’autres contextes d’intégration d’agents.

Dans ces skills, je renseigne :

  • mon architecture
  • mon domaine
  • mes compromis
  • ce que je considère comme bloquant
  • ce que je préfère ignorer.

Petit à petit, le skill ressemble moins à une checklist générique et davantage à un collègue qu’on aurait formé au projet.

Une bonne review peut être vide

Au départ, je voulais surtout un deuxième regard, un collègue artificiel capable de voir les erreurs que je ne voyais plus après trois jours sur la même feature.

Mais trouver des choses est facile. Trouver des choses pertinentes, les vérifier et savoir lesquelles méritent réellement mon attention l’est beaucoup moins.

Finalement, rendre un agent de review pragmatique ressemble pas mal à former un reviewer humain qui arriverait sur un nouveau projet (sauf que lui échappe à l’activité Lego des Scrum Masters, ce chanceux). On lui donne les clés pour comprendre le projet et ce qu’on attend de lui, notamment qu’une review sans retour peut être une review.

Sources

Certains passages de cet article ont été corrigés, reformulés et fact-checkés à l’aide d’une IA générative.