La promesse « la code review est un goulot d’étranglement, on va la résoudre avec une IA » est séduisante. Et oui, des outils comme la fonctionnalité “Code Review” de Claude Code vont dans ce sens. Sauf que dans la vraie vie, le problème numéro 1 n’est pas la qualité des suggestions. C’est le bruit. Si ton bot transforme chaque PR en mur de commentaires, tu n’as pas accéléré le flux. Tu l’as juste déplacé.
Ma position est assez simple : une code review IA, ça se pilote comme un reviewer junior. Tu lui donnes un mandat clair, tu lui interdis les “avis de style”, tu exiges des preuves, et tu assumes que la décision finale reste humaine. Si tu fais ça, tu peux gagner du temps. Si tu ne le fais pas, tu crées un nouveau goulot.
Pourquoi la “code review IA” devient vite un goulot d’étranglement
Une PR, c’est déjà une négociation. Entre l’auteur, le reviewer, les contraintes du produit, les dettes existantes, la deadline, le risque. Quand tu ajoutes une IA qui commente tout, tu ajoutes un acteur qui ne paie pas le coût social de ses remarques. Donc elle en fait trop. C’est mécanique.
Le pattern que je vois le plus souvent, c’est celui-ci : l’IA détecte 20 micro-trucs (typage, style, noms de variables, “tu pourrais extraire une fonction”), et au milieu il y a 2 vrais sujets (un test manquant, une régression perf évidente, une permission trop large). Résultat, l’équipe scrolle, se fatigue, ignore… et tu rates le vrai signal. Pire, tu perds du temps à répondre au bot, à “négocier” avec un commentaire qui n’a pas de contexte produit.
Donc oui, “code review bottleneck”. Mais la solution n’est pas “plus de review”. C’est moins de commentaires, plus de signal.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Traiter l’IA comme un reviewer junior : mandat clair, pas de pouvoir
Un reviewer junior utile, ce n’est pas quelqu’un qui redessine l’architecture. C’est quelqu’un qui voit les pièges évidents, qui te force à prouver que ça marche, et qui remonte les zones à risque. La code review IA doit faire exactement ça. Le reste, tu le refuses.
Concrètement, je pose une règle : l’IA n’a pas le droit de “demander” un refactor si elle ne peut pas justifier un risque clair. Et elle n’a pas le droit de lancer une discussion de style si on a déjà un formatter ou des conventions d’équipe. Son job, c’est de sortir un diagnostic, pas une doctrine.
Ça rejoint d’ailleurs le positionnement “depth, not speed” qu’Anthropic met en avant sur Claude Code : si tu l’utilises pour scanner bêtement tout et commenter tout, tu passes à côté. Le bénéfice, c’est quand tu le forces à aller en profondeur sur quelques points.
Ce que je délègue vraiment à une code review IA (et ce qui reste humain)
Sur le terrain, l’IA est bonne pour les sujets “techniques mais localement vérifiables”. Les tests manquants ou mal ciblés, les conditions aux limites (null, empty, timezone, overflow, encodage), les régressions de complexité évidentes, les appels réseau dans une boucle, les changements de requêtes SQL qui explosent un N+1, les validations d’entrée trop permissives, les secrets loggés “par accident”, ce genre de choses. Pas besoin de connaître la roadmap pour dire “là, tu as une surface d’attaque” ou “là, tu as une régression probable”.
En revanche, tout ce qui touche au produit, à l’UX, aux compromis métier, à la cohérence globale du domaine, aux invariants fonctionnels implicites, à l’architecture du système, ça reste humain. Une IA peut te proposer une refonte “propre” qui est totalement incompatible avec ton legacy, ton cycle de release, ton onboarding, ou ton modèle de responsabilités d’équipe. Et c’est normal.
Le bon découpage, c’est donc : l’IA remonte les risques et les preuves. Le reviewer humain décide si on change maintenant, si on documente, ou si on accepte le risque.
Le format qui évite le spam : “top 5 risques + preuves + fichiers”
Si tu ne contraints pas le format de sortie, tu vas avoir droit à une pluie de commentaires ligne par ligne. C’est impressionnant, mais ce n’est pas actionnable. Ce que je veux, c’est un commentaire unique avec un nombre limité de points, priorisés, et surtout reliés à des extraits précis.
Mon format préféré est brutal : maximum 5 risques. Pour chaque risque, l’IA doit donner une preuve (fichier, fonction, ligne ou extrait), expliquer l’impact probable, puis proposer une correction minimale. Si elle n’a pas de preuve, elle n’a pas le droit d’être alarmiste.
Tu es un reviewer junior. Objectif : remonter DU SIGNAL, pas du style.
Contexte : revue de Pull Request.
Contraintes :
- Ne commente pas le formatting, la mise en forme, les noms de variables, ou les "nitpicks".
- Ne propose pas de refactor large sauf si tu prouves un risque clair (bug, perf, sécu, data loss).
- Pas plus de 5 points.
Sortie (obligatoire) :
1) Top 5 risques (du plus critique au moins critique)
Pour chaque risque :
- Type (bug/perf/sécu/maintenabilité)
- Preuve : fichier + symbole (classe/fonction) + extrait de code
- Impact concret : ce qui peut arriver en prod
- Fix minimal : le plus petit changement acceptable
2) Tests : dis-moi ce qui manque (cas limites) et où l’ajouter.
3) "No issue found" si tu n'as rien de sérieux à signaler.
Entrée : diff de la PR + fichiers touchés.Ce prompt a un effet magique : il retire à l’IA la tentation de faire la maîtresse d’école. Et il t’oblige à traiter une review IA comme un document de risque, pas comme un fil de discussion.
Règles anti-bruit : tu ne veux pas d’un bot “opinionated”
Le bruit vient souvent de trois endroits. D’abord, le style. Si tu as Prettier, Black, gofmt, rustfmt, PHP-CS-Fixer, bref un outil, alors la “review style” est déjà automatisée. L’IA ne doit pas repasser derrière. Tu veux un pipeline, pas un débat.
Ensuite, le refactor gratuit. “On pourrait extraire une classe”, “on pourrait utiliser un pattern”, “on pourrait rendre ça plus clean”. Peut-être. Mais une PR, ce n’est pas un atelier. Si l’IA ne peut pas relier ça à un risque (bug probable, complexité qui explose, couplage dangereux, testabilité réellement bloquée), tu coupes court.
Enfin, le ton. Une IA peut avoir l’air sûre d’elle sur des points flous. Je bannis les formulations du genre « ceci est mauvais » sans preuve. Je préfère 2 remarques bien étayées qu’un roman.
Coût et tokens : quand ça vaut le coup, quand c’est du gaspillage
Les reviews IA, ce n’est pas “gratuit”. Anthropic facture Claude Code au token, et la presse évoque des ordres de grandeur autour de 15 à 25 dollars par exécution selon la complexité. Même si tes chiffres à toi sont différents (modèle, contexte, taille de diff), la logique est la même : tu dois budgéter.
Mon arbitrage est simple : je n’envoie pas une micro-PR de 20 lignes dans le broyeur. Ça ne vaut pas le coût, et ça n’apprend rien. En revanche, dès que tu as une PR grosse, un module sensible, une surface de sécurité (auth, permissions, paiement), une zone perf (API chaude, requêtes), ou un bout de code qui a déjà cassé en prod, là l’IA a un ROI. Tu payes pour acheter du “regard frais” et une chasse aux oublis.
Le piège, c’est de l’activer en automatique sur tout. Tu te retrouves à dépenser tous les jours, et l’équipe n’écoute plus le bot. C’est le pire des mondes : coût + bruit + indifférence.
Intégration GitHub/GitLab : un commentaire unique et un label
L’intégration la plus propre, c’est celle qui ne pollue pas la conversation. Je préfère un seul commentaire “AI review” qui se met à jour, plutôt que 30 threads. Idéalement, tu ajoutes un label du style ai-reviewed quand la review est présente, et tu la retires si la PR change trop (gros push, force push, nouveau commit massif). Comme ça, tu sais ce que tu lis.
Sur GitHub, tu peux le faire avec une GitHub Action qui poste un commentaire unique. Peu importe l’implémentation exacte, l’important est le comportement : un seul artefact, lisible, versionné implicitement par les commits de la PR.
name: AI Code Review
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
review:
runs-on: ubuntu-latest
permissions:
pull-requests: write
contents: read
steps:
- name: Generate AI review (external)
run: |
echo "Ici tu appelles ton job Claude/LLM avec le diff et tu produis un message unique."
- name: Post single PR comment
uses: actions/github-script@v7
with:
script: |
// Pseudo-code: find existing comment with a marker and update it, else create.
// Keep one comment, no inline spam.Sur GitLab, tu peux viser le même résultat via un job CI qui poste une note sur la MR, ou via un bot. Le point non négociable, c’est l’ergonomie : si l’équipe doit cliquer partout pour reconstituer le signal, ça ne tiendra pas.
Définition de done : une PR “AI-assisted” n’est pas une PR “validée”
Le label “AI-assisted” ne doit pas être un tampon de conformité. C’est juste une information : quelqu’un (ou un pipeline) a demandé à une IA de chercher des risques. Ça ne dit pas que c’est bon. Ça dit que le bot a parlé.
Ce que je demande à l’auteur d’une PR, c’est d’accuser réception des points sérieux et de dire ce qu’il fait de chacun. Corrigé, non reproductible, accepté avec justification, repoussé avec ticket. Pas besoin d’en faire un rituel lourd, mais il faut une trace. Sinon tu as l’illusion du contrôle.
Et côté reviewer humain, je garde une règle : si la review IA sort un risque “critique” (sécu, data loss, bug évident), je veux un humain qui le relit. Pas pour “vérifier l’IA”, mais parce que c’est précisément le moment où tu dois être rigoureux.
Les limites à connaître (sinon tu vas te faire avoir)
Une IA peut halluciner un comportement, surtout si elle ne voit qu’un diff sans le contexte d’exécution. Elle peut te dire « cela va casser » alors que ce code est behind a feature flag, ou que l’invariant est ailleurs, ou que c’est un vieux compromis assumé. Si tu prends tout au pied de la lettre, tu vas refactor du vent.
Deuxième limite : la confidentialité. Si ton code est sensible, si tu as des secrets qui traînent, si tu bosses dans un cadre réglementé, tu dois être clair sur ce que tu envoies et à quel service. “Ça marche” ne suffit pas comme argument. Il faut une politique.
Troisième limite : l’effet pervers sur l’équipe. Si l’IA devient la voix la plus bruyante, les juniors n’apprennent plus à reviewer, et les seniors se mettent à “négocier avec le bot”. Le bon usage, c’est celui qui augmente le niveau de rigueur et qui réduit la charge cognitive. Pas celui qui remplace la responsabilité.
Mon avis : la bonne code review IA, c’est une machine à remonter des risques
Je n’attends pas d’une IA qu’elle ait “raison”. J’attends qu’elle soit bonne pour repérer les angles morts. Si tu la cadres comme un reviewer junior, tu récupères ce qu’elle sait faire de mieux : lire vite, repérer des patterns, te forcer à justifier, et surtout te rappeler les basiques que tu oublies quand tu es la tête dans le guidon.
Le jour où tu as un workflow propre, tu te surprends à aimer le truc. Pas parce que l’IA est magique, mais parce que la review redevient ce qu’elle devrait être : un filet de sécurité. Pas une seconde phase de dev.
