IA en code review : retour d'expérience après 6 mois avec Claude

Je développe seul crmcoaching (un CRM pour coachs professionnels) sur une stack NestJS 11, Prisma 7, PostgreSQL, Next.js 16 et architecture hexagonale. Pas d'équipe. Pas de reviewer humain disponible à chaque PR. Et pourtant, la qualité ne peut pas régresser : c'est un SaaS en production.

Depuis décembre 2025, Claude est dans ma boucle de review systématique. Le bilan après 6 mois : le temps de review que je passe moi-même a baissé d'environ 40% sur les aspects mécaniques (sécurité, conventions, couverture de tests), et j'ai attrapé plusieurs bugs avant de les pousser en staging. Mais Claude rate aussi des choses de façon prévisible, et comprendre ces angles morts change tout à la façon dont on l'utilise.

Ce qui fait la différence, ce n'est pas l'outil. C'est la méthode d'intégration.

Les trois façons d'utiliser Claude en review

Avant d'entrer dans ce que Claude trouve ou rate, il faut clarifier le mode d'utilisation : les résultats varient significativement selon la façon dont on l'intègre.

Claude Code en local (mode interactif)

C'est le mode que j'utilise le plus souvent. Après avoir implémenté une feature dans un worktree isolé, je demande à Claude Code de reviewer le diff avant de créer la PR. L'avantage : Claude a accès au repo complet, aux fichiers de contexte (CLAUDE.md, conventions hexagonales, règles biome), et peut naviguer dans le code adjacent pour vérifier la cohérence. Le coût est inclus dans l'abonnement Claude Pro : pas de calcul à la PR.

Claude via API avec le diff + contexte projet

Pour les PR plus complexes ou quand je veux un avis "extérieur" sans contexte de session accumulé, j'envoie le diff complet avec un prompt système qui embarque les conventions crmcoaching. Le coût est environ 0,10 à 0,40 € par PR selon la taille du diff (claude-sonnet-4, ~800 tokens en input pour une PR moyenne + diff). Sur 20 PR par mois, c'est inférieur à 8 €.

Prompt système avec conventions intégrées (CI review automatique)

Le mode le plus scalable si on veut une review systématique sans action manuelle. Un workflow GitHub Actions envoie le diff à l'API Claude dès l'ouverture d'une PR, avec le prompt système suivant :

// apps/api/src/infrastructure/claude/review-prompt.ts

export const REVIEW_SYSTEM_PROMPT = `
Tu es un reviewer senior sur le projet crmcoaching.

Stack : NestJS 11, Prisma 7, PostgreSQL, Zod 4, architecture hexagonale, Vitest.
Frontend : Next.js 16 App Router, React 19, Tailwind v4, TanStack Query.

Conventions obligatoires :
- Architecture hexagonale stricte : domain/ ne dépend de rien, application/ dépend de domain/, infrastructure/ implémente les ports
- Pas de non-null assertion (!) sans justification explicite en commentaire
- Fonctions > 50 lignes : extraire un helper avant de merger
- Complexité cognitive > 15 : bloquant (biome noExcessiveCognitiveComplexity)
- Conventional Commits : feat:, fix:, refactor:, test:, chore:
- Tests obligatoires par couche : unit sur domain/ et application/, integration sur infrastructure/ (vraie DB), Playwright sur les pages

Pour chaque finding, utilise le format :
- [sécurité] pour les injections, secrets, vulnérabilités
- [architecture] pour les violations hexagonales, couplage
- [qualité] pour la complexité, les fonctions trop longues
- [tests] pour la couverture manquante
- [convention] pour le style et le nommage

Faux positifs à éviter : ne signale pas les biome-ignore avec justification explicite.
`.trim();

Ce prompt injecte directement les règles de .claude/rules/ dans le contexte de review. Le résultat : Claude signale les violations hexagonales (une couche application/ qui importe directement depuis infrastructure/), les non-null assertions sans justification, et les fonctions qui dépassent le seuil biome, avec une précision que je n'aurais pas trouvé moi-même en relecture rapide.

Ce que Claude trouve bien

Violations de l'architecture hexagonale

C'est le finding le plus utile sur crmcoaching. Quand une use-case importe directement un service Prisma au lieu de passer par le Port, Claude le détecte fiablement si les conventions hexagonales sont dans le prompt système. Sur les 6 derniers mois, 7 violations de ce type ont été attrapées avant merge, dont 2 qui auraient créé des couplages difficiles à défaire ensuite.

Sécurité évidente

Secrets hardcodés, logique d'autorisation absente sur un endpoint, JWT validé sans vérification de l'audience. Claude détecte ces patterns mieux que ma relecture humaine, non pas parce qu'il est plus intelligent, mais parce qu'il ne fatigue pas et applique le pattern systématiquement. Une étude Stanford (2023) documentait que 40% du code IA-généré contenait des vulnérabilités dans des contextes de sécurité spécifiques : Claude en review détecte précisément ces patterns dans le code qu'il a lui-même généré.

Couverture de tests manquante

"Ce use-case n'a pas de test pour le cas d'erreur quand le lead n'existe pas" : ce type de finding revient régulièrement et me fait gagner du temps sur la lecture des specs de test. Claude identifie les branches non couvertes avec une précision correcte, surtout quand les conventions de test par couche sont dans le prompt.

Style et conventions mécaniques

Nommage incohérent avec les conventions du projet, fonction trop longue sans extraction de helper, complexité cyclomatique élevée. Claude commente ces points avec une régularité que ma propre relecture n'a pas quand je suis dans le contexte de l'implémentation.

Ce que Claude rate systématiquement

Après 6 mois, j'ai identifié 5 angles morts récurrents.

La cohérence avec le reste du codebase quand le contexte est insuffisant

Claude revoit le diff. Si le projet utilise un pattern de gestion d'erreur spécifique que je n'ai pas mis dans le prompt système, Claude peut suggérer un pattern différent, techniquement correct mais incohérent avec le reste. La solution : enrichir progressivement le prompt système avec les patterns qui reviennent. C'est un travail itératif, pas une config one-shot.

La logique métier incorrecte

Un calcul de remise selon des règles coaching spécifiques à crmcoaching : si le code est techniquement correct mais que la règle métier est fausse, Claude ne voit pas le problème. Aucun outil IA ne peut combler ce gap : seule ma connaissance du domaine le peut. C'est le point le plus important à ne pas déléguer.

L'impact architectural à long terme

Un changement qui respecte tous les patterns peut introduire un couplage problématique que je ne verrai que 3 mois plus tard. Claude analyse local. Il ne voit pas les implications systémiques d'un changement de modèle de données sur les 8 use-cases qui utilisent l'entité concernée.

La duplication de logique métier cross-domaines

Deux modules qui implémentent la même règle de validation légèrement différemment. Claude revoit chaque diff en isolation et ne peut pas détecter la duplication sans contexte étendu du repo. Claude Code en mode local s'en sort mieux que l'API, parce qu'il peut naviguer activement dans le codebase.

L'intention derrière une constante ou une valeur

Une PR qui modifie un timeout de 5000ms à 3000ms. Claude commente éventuellement sur le style. Il ne sait pas que ce timeout avait été calibré pour contourner un bug de l'API Brevo en production. Cette connaissance implicite ne peut pas être injectée dans un prompt système : elle n'existe que dans les ADRs ou la mémoire du développeur.

L'impact sur ma façon de travailler en solo

Ce que Claude change concrètement dans une boucle solo :

Ce qui s'améliore : ma relecture humaine porte maintenant sur le fond (logique métier, impact architectural, cohérence avec les décisions passées) plutôt que sur la forme (conventions, sécurité mécanique, couverture de tests). Claude filtre ce bruit. Le "time to first review" passe à moins de 2 minutes en mode API, ce qui casse le cycle "j'ai fini la feature, j'attends le feedback, je suis passé à autre chose".

Le risque principal : la délégation de responsabilité. "Claude a reviewé, donc c'est bon." Ce pattern crée une fausse sécurité dangereuse sur les bugs de logique métier. Je l'ai vécu sur une PR de scoring Brevo en mars 2026 : Claude avait validé la structure, mais la règle de scoring était inversée. Bug détecté en staging, pas en production, mais le risque était réel.

La règle que j'applique : Claude revoit les patterns connus (sécurité, conventions, architecture, tests). Moi je revois la logique métier, l'intention du changement, et les impacts cross-domaines. Cette séparation est explicite, pas implicite.

La séparation des responsabilités

Complétez cette séparation avec la checklist de validation du code IA pour les PRs à fort contenu généré.

Les métriques que je suis

Time to first review : avec Claude en mode API, ce metric est inférieur à 2 minutes. C'est un gain réel pour rester dans le flux.

Taux de faux positifs : le pourcentage de commentaires Claude que je rejette comme non-pertinents. Actuellement autour de 20% (en baisse depuis que j'ai enrichi le prompt système avec les patterns crmcoaching). Au-dessus de 30%, il faut retravailler le prompt ou les conventions injectées.

Bug escape rate : bugs détectés en production divisé par bugs détectés en review. Si ce ratio se dégrade malgré Claude, l'IA crée une fausse sécurité. Sur les 6 mois, le ratio s'est amélioré sur les bugs de sécurité et d'architecture, pas sur les bugs de logique métier (cohérent avec les angles morts identifiés).

Coût API : moins de 8 € par mois sur le volume actuel de PRs crmcoaching. Marginal par rapport au coût du temps de review humaine.

FAQ sur l'IA en code review