kengdevParlons de votre projet
Mis à jour le 2026-09-10
La revue de code assistée par IA fait relire chaque diff par un modèle qui poste des commentaires, avant qu'une personne approuve. L'IA ne fusionne rien: elle réduit le temps passé à repérer les problèmes mécaniques et laisse la décision de merge à un humain.
Raccourcir le délai de revue sans transformer l'approbation en formalité que personne ne lit.
Un outil qui commente tout finit par être ignoré. Règle-le pour parler moins et plus juste.
L'IA commente, l'humain approuve
La revue de code reste un pilier de qualité, mais elle a ses coûts: du temps, une variance selon le reviewer, et des files d'attente qui bloquent le delivery. La revue IA vise un premier passage rapide et plus cohérent.
En pratique, le bot regarde le diff et les lignes autour, le style, les patterns suspects, parfois des règles globales d'équipe. Il poste ses commentaires sur la MR ou la PR. Il ne merge pas.
Les avantages et les limites observés tiennent en deux colonnes:
| La revue IA apporte | Elle rate encore |
|---|---|
| Un premier feedback rapide | Les critères d'acceptation d'une user story |
| De la couverture quand les reviewers saturent | L'intent métier subtil |
| Des retours cohérents sur les règles transverses | Les races rares et le design produit |
Sans le contexte de la user story, le bot reste de toute façon sur des règles globales.
Risque: fatigue de revue inversée
Si tout est « approuvé par l'IA », plus personne ne lit vraiment le code. C'est le même piège qu'un HITL mal calibré.
La contre-mesure tient en trois règles: le bot reste en commentaires seuls; l'auth, le paiement, les migrations et les PII passent toujours en revue senior; et une checklist humaine courte reste obligatoire.
Plus de commits ne veut pas dire plus de valeur. On regarde les incidents post-merge et le temps de compréhension du module.
Ce que l'IA détecte bien (et mal)
Le bot détecte bien tout ce qui se voit directement dans le diff:
- Le style évident
- Les null checks manquants
- Les API dépréciées
- Les tests absents sur le happy path
- Les secrets hardcodés simples
Il détecte mal ce qui demande du contexte: l'intent métier, les edge cases rares, la dette architecturale transversale, ou l'ironie dans les specs.
Juge le ratio signal sur bruit après deux sprints de calibration, pas sur un seul faux positif. Et si plus de 30% des commentaires d'une règle sont ignorés, coupe la règle.
Mise en place en 2 sprints
Le déploiement tient en deux sprints:
- Sprint 1: installe le bot sur un repo non critique, mesure le bruit face aux vrais catches, pose une checklist humaine de 5 items et forme l'équipe en 45 minutes.
- Sprint 2: étends aux repos principaux. Le blocage de merge ne s'applique qu'aux règles déterministes (secrets, lint), jamais à un avis LLM flou seul.
Intègre le tout à ta CI existante, GitHub ou GitLab. Et si le diff quitte ton périmètre, vérifie la confidentialité du code: DPA, mode enterprise ou self-host.
Si vous voulez poser une revue IA et les conventions qui vont avec, on peut cadrer la démarche en 20-40 minutes.
Questions fréquentes
La revue IA remplace-t-elle les seniors ?
Non. Elle enlève des nitpicks et libère du temps pour l'architecture et les risques. Les seniors restent décideurs sur les chemins critiques.
Bloquer le merge sur avis LLM ?
C'est déconseillé au début. Bloque le merge sur les règles déterministes (secrets, lint), pas sur un avis de modèle.
GitLab Duo / Copilot review ?
Ce sont des options d'écosystème. Évalue l'intégration, la confidentialité et le bruit: la policy d'équipe prime sur la marque de l'outil.
Code propriétaire sensible ?
Vérifie d'abord si le code quitte ton périmètre. Préfère les options enterprise, le self-host, ou une rétention clairement écrite.
Lien vibe coding ?
Le vibe coding sans revue est le pire cas. La revue IA aide le premier passage, mais elle ne remplace pas la compréhension du diff.
Sources et repères
- Best practices for Claude CodeAnthropic
Documentation primaire à consulter pour les caractéristiques et évolutions du produit.
