En mars 2026, je passais 45 minutes par MR à reviewer. Aujourd'hui, 20 minutes. Pas en travaillant plus vite. En faisant relire par un agent avant les humains.
La différence ne vient pas de l'IA. Elle vient de ce que les reviewers humains n'ont plus à faire.
Le vrai problème de la code review
La code review mélange deux types de travail complètement différents :
Le travail mécanique. Naming, imports, conventions d'équipe, tests manquants, failles sécurité évidentes, code mort. C'est répétitif. C'est la même checklist à chaque MR. C'est exactement le type de tâche où l'IA excelle.
Le jugement. Architecture, dette technique contextuelle, impact sur des fichiers éloignés du diff, compromis d'équipe, charge cognitive pour un mainteneur futur. C'est là où la valeur du reviewer humain se joue. Un humain qui a le contexte du projet, de l'équipe, de la roadmap produit.
Le problème : les deux sont mélangés dans la même session de review. Le reviewer humain passe 15 minutes sur des nits que l'aurait pu capter un script, et 5 minutes sur les vraies décisions architecturales. Il sort de la review épuisé mais sans avoir touché au cœur du problème.
Le workflow concret : IA passe 1, humain passe 2
La structure en 4 étapes :
Étape 1 : Coder la feature. Comme d'habitude. Rien ne change ici.
Étape 2 : Passer la MR à l'agent IA en mode review. Pas après coup. Avant d'envoyer aux humains. L'agent reçoit le diff, le ticket Jira, et les conventions du projet. Il ressort des commentaires classés par sévérité.
Étape 3 : Corriger ce que l'agent repère. Les nits, les failles sécurité, les bugs logiques évidents. Le travail mécanique. Tu corriges, tu push, c'est propre.
Étape 4 : Envoyer en review humaine. Le reviewer humain reçoit un code déjà nettoyé. Il ne perd plus de temps sur les conventions ou les imports manquants. Il se concentre sur les vraies questions : est-ce que cette architecture tient la route dans 6 mois ? Est-ce que cette abstraction va créer de la dette ? Est-ce que l'équipe pourra maintenir ça ?
Le gain n'est pas que en temps. C'est en qualité d'attention. Le reviewer humain fait ce qu'il fait le mieux : juger, arbitrer, transmettre du contexte.
Le prompt de review qui fonctionne
Voici le template que j'utilise. Tu le colles dans ton agent IA (Claude Code, Cursor, n'importe lequel) avec le diff de ta MR :
Tu es un reviewer senior. Relis ce diff et classe chaque observation par sévérité.
P1 — Bloquant : faille sécurité, bug logique, perte de données. Corriger AVANT merge.
P2 — Important : conventions non respectées, tests manquants, dette technique introduite. Corriger avant merge si raisonnable.
P3 — Nit : style, nommage, suggestions d'amélioration. Corriger si facile, ignorer si ça ralentit.
Pour chaque observation, donne :
1. Le fichier et la ligne concernée
2. La classification (P1/P2/P3)
3. La correction concrète (pas une explication théorique)
Format : Markdown. Sois bref. Zéro blabla.Ce qui change avec un prompt vague ("relis mon code") :
Prompt vague | Prompt structuré |
|---|---|
Commentaires verbeux, pas de priorisation | Commentaires classés P1/P2/P3 |
"Il faut améliorer la performance ici" | "Ligne 42 : O(n²) → utiliser un Map. P2." |
Le reviewer humain doit tout relire | Le reviewer humain start sur les P1 |
Impossible de trier le bruit du signal | Chaque commentaire a un niveau d'urgence |
Ce que l'IA repère bien vs. ce qu'elle ne repère pas
C'est ici qu'il faut être honnête. L'IA n'est pas omnisciente.
L'IA repère bien :
Failles sécurité évidentes (injections SQL, XSS, dépendances connues vulnérables)
Code mort, imports inutilisés, variables déclarées non lues
Violations de conventions du projet (si elles sont dans le contexte)
Tests manquants pour des branches conditionnelles
Complexité cyclomatique excessive, nesting trop profond
L'IA repère mal :
Cohérence avec la roadmap produit. L'IA ne sait pas que cette feature doit évoluer dans 2 sprints
Dette technique contextuelle. "Oui c'est un workaround, mais l'alternative c'est 3 semaines de refactoring qu'on a pas prévues"
Compromis d'équipe. "Oui c'est pas idéal, mais Romain a commencé comme ça et on va pas tout casser"
Charge cognitive pour un mainteneur futur. L'IA voit le code tel qu'il est, pas tel qu'il sera lu dans 6 mois par un nouveau dev
La règle : si l'observation est purement technique, l'IA peut la traiter. Si elle nécessite du contexte projet, de l'histoire d'équipe, ou un arbitrage produit, c'est au reviewer humain.
Le piège : l'AI slop en code review
Un commentaire de review généré par IA a une signature reconnaissable : verbeux, techniquement correct, mais générique. Tu pourrais le coller sur n'importe quel PR de n'importe quel projet. Il ne dit rien de spécifique au code sous tes yeux.
Marqueurs typiques :
Trois bullets qui disent la même chose avec des mots différents
"It's worth noting that..." ou "Il convient de souligner..."
Un ton assuré sur des affirmations qu'aucun humain n'a vérifiées
Une section "options considered" qui liste trois alternatives sans rapport avec tes contraintes réelles
La discipline : ne jamais valider un commentaire IA sans le relire. Si le commentaire est générique, reformule-le en question spécifique avant de le push. Pattern utile : le read-back asynchrone, inspiré des protocoles militaires. Le reviewer reformule l'intention présumée de l'auteur sous forme de question :
"Si je comprends bien, tu veux que cette fonction renvoie X dans le cas Y, c'est bien ça ?"
"L'intention ici c'est de couvrir Z, ou juste W ?"
Ça marche aussi en reverse : quand l'IA te propose un commentaire, tu reformules en question pour vérifier que tu as compris le vrai problème.
Comment calibrer ta confiance dans l'IA
L'Oversight Tax : déléguer à un agent ne supprime pas la charge cognitive, elle la déplace. Tu restes assez alerte pour détecter des erreurs que tu ne fais plus toi-même. C'est épuisant.
Le piège : un agent qui échoue à 15% par étape sur un workflow de 8 étapes n'a que 27% de chances de terminer correctement (0,85^8 ≈ 0,27). Si tu dois tout revérifier, tu n'as rien gagné.
La calibration se fait par répétition. Règle des ~50 exécutions réussies : après 50 MRs où l'IA a bien repéré les problèmes et pas inventé de faux positifs, tu peux réduire ta vérification aux P1 uniquement. En dessous de 50, tu relis tout. Au-dessus, tu fais confiance sur les P2/P3 et tu gardes un œil sur les P1.
Ça prend 2-3 semaines à arriver à 50 MRs si tu en fais 3-4 par jour. Après, la charge cognitive chute. L'IA passe d'outil qu'on surveille à système dans lequel on a confiance.
Les résultats honnêtes
45 minutes → 20 minutes par MR (gain ~55%)
Les comments humains sont meilleurs : moins de bruit, plus d'arbitrages
Les MRs reviennent moins en boucle (moins de allers-retours pour des nits)
Les reviewers seniors se concentrent sur l'architecture et la dette
Les devs junior apprennent plus vite : les commentaires IA sont des micro-lessons de conventions
Le chiffre qui m'a frappé : le coût d'une code review routinière est de ~0,72$ par agent IA vs ~48$ par ingénieur senior (données Digital Applied 2026, agrégation Forrester/Anthropic). Un ratio de 66x. Ça ne remplace pas le reviewer humain. Ça libère son temps pour ce qui compte.
Liens sélectionnés
1. AI Code Review: Approaches, Tools, and Best Practices (Collin Wilkins, fév. 2026). Le guide le plus complet de 2026 : trois approches (local agent, CI/CD pipeline, vendor tools), comparaison CodeRabbit/Greptile/Copilot, et best practices pour réduire les faux positifs.
2. CodeRabbit Documentation. Doc officielle : comment CodeRabbit structure ses reviews (sévérité, triggers, revues incrémentales). Utile pour comprendre ce que l'outil fait vraiment avant de l'adopter.
3. Greptile. L'alternative orientée détection de bugs : $30/seat/month, 50 reviews incluses, self-hostable. Leur angle : compréhension cross-file, pas juste le diff.
4. AI Code Review in CI/CD Pipeline (Pockit, avril 2026). Comment builder un reviewer IA custom dans ton pipeline : architecture, context assembler, et les pièges à éviter. Pour ceux qui veulent roll leur propre solution.
Outil de la semaine
CodeRabbit — review IA GitLab/GitHub, $24/user/mois (illimité), essai gratuit 14j. L'avantage : il s'intègre directement dans ta MR et commente ligne par ligne. Attention aux MRs Renovate (à mettre en mode manuel). Alternative : solution maison avec une clé API LLM, comme on a benchmarké en équipe.
Tu fais comment aujourd'hui ? Tu relis toi-même avant d'envoyer en review, ou tu envoies direct ? Si tu utilises déjà l'IA pour relire, quelle est ta stratégie pour éviter l'AI slop ?
Une ligne. Ça m'aide à calibrer les prochains numéros sur votre stack réelle.