Comment fonctionne vraiment Claude Code Review : diffs, hooks et ce que l'agent détecte

Claude Code Review : Le guide pratique des revues de PR agentiques

Claude Code peut examiner une pull request ou un diff local comme le ferait un ingénieur senior rigoureux — en lisant les fichiers modifiés, en retraçant les points d'appel, en vérifiant les tests, et en renvoyant des constats classés par gravité avec des correctifs suggérés. Ce guide porte spécifiquement sur l'utilisation de Claude Code (l'outil CLI agentique d'Anthropic) pour la revue de code : comment le déclencher, comment bien le prompter, comment l'automatiser à chaque commit ou PR, et comment l'intégrer dans un pipeline d'équipe.

Ce que signifie vraiment « Claude Code Review »

Il existe deux choses très différentes que les gens appellent « revue de code Claude ». La première consiste à demander à Claude, dans une interface de chat, d'examiner un extrait de code que vous collez. La seconde — et le sujet de ce guide — consiste à exécuter Claude Code, l'outil CLI agentique d'Anthropic, sur un vrai diff ou une vraie pull request au sein de votre dépôt réel.

Cette distinction compte énormément. Lorsque Claude Code examine un diff, il ne raisonne pas de manière isolée sur un extrait collé. C'est un agent autonome qui peut ouvrir des fichiers, suivre les imports, lire les instructions de projet de votre CLAUDE.md, vérifier les tests adjacents, et comprendre le contexte complet d'un changement avant même d'émettre un seul constat. Cette conscience inter-fichiers est ce qui rend le résultat véritablement utile plutôt que générique.

Claude Code est disponible en tant que CLI que vous installez localement (npm install -g @anthropic-ai/claude-code), ou en tant qu'agent s'exécutant dans un bac à sable cloud — nous y reviendrons plus loin pour les deux approches. La documentation officielle d'Anthropic couvre l'installation et la configuration initiale.

Le workflow /review étape par étape

Claude Code est livré avec une commande slash /review conçue spécifiquement pour cette tâche. Voici le workflow complet, du diff jusqu'au résultat exploitable.

Étape 1 — Diriger Claude Code vers le diff

Vous disposez de plusieurs façons de lui fournir les changements à examiner.

Changements indexés (la commande /review) :

/review

À l'intérieur d'une session Claude Code, la commande slash /review lance une revue de vos changements. C'est le workflow local le plus courant : vous indexez votre travail, vous lancez /review, et vous voyez les constats avant de committer. (Le comportement exact de la commande évolue — consultez la documentation Claude Code d'Anthropic pour la syntaxe actuelle.)

Une plage git spécifique : Vous pouvez aussi simplement demander à l'agent en langage naturel — par exemple, « Examine le diff entre main et cette branche et signale tout bug ou régression. » Comme Claude Code peut exécuter lui-même des commandes git, il produira le diff pour la plage indiquée et l'examinera. C'est pratique pour revoir une branche de fonctionnalité avant d'ouvrir une PR, et cela évite de dépendre d'une syntaxe de flag exacte.

Une URL de pull request GitHub : Si votre projet a le GitHub CLI configuré, Claude Code peut récupérer directement le diff de la PR. Vous fournissez l'URL ou le numéro de la PR dans votre prompt, et l'agent utilise gh pour récupérer le diff ainsi que la description de la PR, ce qui lui donne un contexte d'intention en plus du code.

Étape 2 — Chargement du contexte

Avant d'émettre des constats, Claude Code lit le contexte nécessaire pour évaluer correctement le diff :

• CLAUDE.md — le fichier d'instructions de votre projet, qui peut définir des zones d'attention prioritaires pour la revue, des motifs interdits, des règles d'architecture, ou des conventions d'équipe. C'est votre principal levier pour personnaliser ce à quoi l'agent prête attention.
• Modules importés et appelants — si une fonction modifiée est appelée à dix endroits, l'agent lit ces points d'appel pour vérifier si le changement est rétrocompatible.
• Tests existants — il lit les fichiers de tests pour comprendre le contrat prévu du code modifié, et pour remarquer quand une nouvelle logique manque de couverture.
• Fichiers de configuration — eslint, tsconfig, pyproject.toml et fichiers similaires aident l'agent à comprendre quelles règles de linting sont déjà appliquées en CI, afin qu'il ne répète pas des constats que votre outillage détecte déjà.

Étape 3 — Analyse

Les passes d'analyse de Claude Code couvrent plusieurs dimensions simultanément :

• Correction — bugs logiques, erreurs de décalage d'un, déréférencements nuls, hypothèses algorithmiques incorrectes
• Sécurité — risques d'injection, identifiants exposés, désérialisation non sécurisée, contrôles d'autorisation manquants
• Fiabilité — gestion d'erreurs manquante, rejets de promesses non gérés, cas limites non couverts
• Maintenabilité — logique dupliquée, nommage peu clair, documentation manquante pour un comportement non évident
• Couverture de tests — chemins de code ajoutés sans tests correspondants

L'agent ne se contente pas de signaler une ligne ; il explique pourquoi le constat est important et quel serait l'impact s'il était déployé en production.

Étape 4 — Constats structurés

Le résultat est une liste de constats, chacun comprenant :

• Un label de gravité (généralement : critique / avertissement / suggestion)
• La référence du fichier et de la ligne
• Une explication en langage clair du problème
• Un correctif suggéré — souvent un extrait de code prêt à appliquer

Par défaut, les constats sont affichés dans le terminal. Pour un usage en équipe, vous pouvez les rediriger : les envoyer vers un fichier, les publier en tant que commentaires de PR via gh pr comment, ou utiliser un hook pour les écrire dans un journal de revue partagé.

La revue Claude Code suit un pipeline structuré — de l'entrée du diff, au chargement du contexte, à l'analyse, jusqu'aux constats classés et aux suggestions de correctifs, avec des hooks permettant une automatisation complète.

Un exemple concret : vrai diff, vraie revue

Pour rendre cela concret, voici un diff Python minimal et ce qu'une revue Claude Code met en évidence.

Le diff :

# Before
def get_user(user_id):
    result = db.query(f"SELECT * FROM users WHERE id = {user_id}")
    return result[0]

# After (in PR)
def get_user(user_id):
    result = db.query(f"SELECT * FROM users WHERE id = {user_id}")
    if result:
        return result[0]
    return None

Ce que l'auteur de la PR pensait avoir corrigé : une KeyError lorsqu'aucun utilisateur n'est trouvé.

Ce que Claude Code met en évidence dans sa revue :

1. Critique — Injection SQL (ligne 2) : La f-string interpole user_id directement dans la requête. Une valeur comme 1; DROP TABLE users;-- s'exécuterait. Correctif : utiliser des requêtes paramétrées — db.query("SELECT * FROM users WHERE id = ?", (user_id,)).

2. Avertissement — Propagation implicite du retour None : Les appelants de get_user qui ne vérifient pas None échoueront désormais à distance. Trois points d'appel (listés par fichier) qui supposent qu'un objet utilisateur est toujours renvoyé sont à revoir.

3. Suggestion — Annotation de typage manquante : Le type de retour devrait être Optional[User] afin que les IDE et les vérificateurs de types puissent détecter automatiquement le cas None au niveau des points d'appel.

4. Suggestion — Test ajouté mais incomplet : Le nouveau test test_get_user_not_found vérifie seulement que None est renvoyé ; il ne vérifie pas le comportement lorsque user_id vaut 0 ou n'est pas un entier.

L'auteur original a corrigé la KeyError mais a introduit un risque silencieux de propagation de None et n'a pas remarqué l'injection SQL préexistante. Claude Code a détecté les deux — et les a trouvés parce qu'il a lu les points d'appel, pas seulement le diff.

Bien prompter Claude Code pour de meilleures revues

La qualité d'une revue est directement proportionnelle à la qualité du contexte que vous donnez à l'agent. Ces prompts et techniques produisent des résultats constamment meilleurs.

Utiliser CLAUDE.md pour définir des instructions permanentes

Le plus grand levier se trouve dans le fichier CLAUDE.md de votre projet. Ajoutez une section ## Review Guidelines :

## Review Guidelines
- We use parameterized queries everywhere. Flag any string interpolation in SQL.
- All public functions must have return-type annotations (Python) or JSDoc (JS).
- Security findings should always be severity: critical, not warning.
- We prefer explicit error returns over exceptions in the data layer.
- Do not flag import ordering — Black handles that automatically.

Cela instruit l'agent une seule fois, et chaque revue du projet hérite de ces règles sans que vous ayez à reformuler le prompt à chaque fois.

Fournir l'intention dans le prompt

Lorsque vous invoquez une revue de manière interactive, indiquez à l'agent ce que la PR cherche à accomplir :

/review This PR migrates our auth flow from JWT to session cookies. Focus on
session fixation, secure cookie attributes, and any places we might be leaking
the old JWT validation logic.

Le contexte d'intention permet à Claude Code de prioriser les constats pertinents plutôt que de générer une liste de contrôle uniforme sur toutes les dimensions.

Demander d'abord une passe uniquement sur la gravité

Pour les gros diffs, une approche en deux passes est efficace :

/review Pass 1: list only critical and warning severity findings with file+line.
No suggestions yet.

Ensuite, une fois que vous avez la liste des constats critiques, demandez les détails de correction sur des constats spécifiques. Cela évite le problème d'un résultat de revue de 200 lignes où le bug critique est enfoui entre des suggestions de style.

Demander une confirmation de compréhension

Pour les changements complexes :

Before reviewing, summarize what this diff is trying to do in two sentences,
then proceed with the review.

Si le résumé est incorrect, vous savez que l'agent a mal interprété le diff et vous pouvez le corriger avant de perdre du temps sur des constats erronés.

Automatiser les revues avec des hooks

Exécuter /review manuellement est utile, mais le vrai gain de productivité vient du fait de rendre la revue automatique — afin que chaque commit ou chaque PR ouverte la déclenche sans qu'un humain ait à s'en souvenir. Le système de hooks de Claude Code rend cela possible. (Le système de hooks est couvert en profondeur dans le guide des hooks Claude Code — cette section se concentre spécifiquement sur le cas d'usage de la revue.)

Revue automatique à chaque commit

Dans le .claude/settings.json de votre projet, ajoutez un hook Stop :

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "claude -p 'Review the diff from the last commit (git diff HEAD~1 HEAD) and list any bugs, security issues, or regressions.'"
          }
        ]
      }
    ]
  }
}

Avec cela en place, chaque fois que Claude Code termine une tâche (y compris les tâches de codage qui se terminent par un commit), le hook se déclenche et examine le diff résultant. Les constats apparaissent dans votre terminal immédiatement après que le commit est effectué.

Revue automatique à l'ouverture d'une PR

Pour l'intégration CI, exécutez Claude Code en mode headless (claude -p "<prompt>") au sein d'un job GitHub Actions et publiez le résultat en tant que commentaire de PR. Le modèle ci-dessous est illustratif — Anthropic publie également une GitHub Action officielle Claude Code, consultez donc la documentation Claude Code pour la configuration CI actuelle et recommandée plutôt que de copier les flags mot pour mot :

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Install Claude Code
        run: npm install -g @anthropic-ai/claude-code
      - name: Run review
        run: |
          claude -p "Review the diff between origin/${{ github.base_ref }} and HEAD. \
          List bugs, security issues, and regressions, ranked by severity." > review.md
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
      - name: Post review as PR comment
        run: gh pr comment ${{ github.event.number }} --body-file review.md
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Cela publie automatiquement les constats de Claude Code en tant que commentaire de PR à chaque push. Vos réviseurs humains concentrent alors leur attention sur les constats déjà mis en évidence par l'agent, plutôt que de passer du temps de revue sur les éléments que Claude Code détecte de manière fiable.

Ce que Claude Code Review détecte — et ce qui lui échappe

Il est important d'avoir une vision claire de l'étendue des capacités. La revue par IA est véritablement puissante pour une catégorie spécifique de constats, et de manière fiable insuffisante pour d'autres.

Claude Code excelle dans la correction mécanique, les motifs de sécurité et la cohérence — tandis que le jugement produit, les menaces inédites et la validation de conformité restent des responsabilités humaines.

Ce que Claude Code détecte de manière fiable :

• Erreurs de décalage d'un, déréférencements null/undefined, et incompatibilités de types visibles dans le diff et son contexte immédiat
• Motifs de sécurité connus : injection SQL, XSS, failles CSRF, références directes non sécurisées à des objets, validation d'entrée manquante, secrets dans le code
• Violations de style et de convention par rapport aux règles définies dans votre CLAUDE.md et vos fichiers de configuration
• Logique dupliquée — la conscience inter-fichiers de l'agent signifie qu'il remarque quand une fonction que vous venez d'ajouter existe déjà dans un module utilitaire situé deux répertoires plus loin
• Gestion d'erreurs manquante — rejets de promesses non gérés, clauses except nues, fonctions pouvant renvoyer None ou undefined sans que l'appelant s'y attende
• Lacunes de couverture de tests pour les chemins de code spécifiques ajoutés dans le diff

Ce que Claude Code ne remplace pas dans le jugement humain :

• Les décisions produit et exigences. Est-ce que la fonctionnalité devrait exister, est-ce que l'UX a du sens, est-ce que le contrat d'API est la bonne abstraction — cela nécessite un contexte métier qu'aucun agent ne possède.
• Les menaces de sécurité inédites. L'agent connaît les classes de vulnérabilités connues ; il n'invente pas de modèles de menace spécifiques à l'environnement de déploiement ou à la logique métier de votre application.
• La performance à l'échelle. L'analyse statique ne peut pas se substituer à des sorties de profileur, des résultats de tests de charge, ou une compréhension des schémas de trafic réels.
• La conformité réglementaire. Le RGPD, HIPAA, PCI-DSS, et exigences similaires requièrent une validation humaine et souvent une revue juridique. La revue par IA ne peut pas s'y substituer.
• La dynamique d'équipe et la gouvernance d'architecture. « Est-ce que cela a sa place dans ce module ? » ou « Devrions-nous adopter cette dépendance ? » requièrent un contexte organisationnel.

Le cadrage sain : la revue Claude Code élimine la partie ennuyeuse de la revue de code — détecter les erreurs mécaniques, faire respecter les conventions, signaler les motifs connus comme mauvais — afin que vos réviseurs humains puissent consacrer leur attention limitée aux décisions de jugement qui nécessitent réellement un jugement humain.

Intégrer Claude Code Review dans un pipeline d'équipe

Amener une équipe à réellement utiliser la revue agentique de manière cohérente nécessite de la traiter comme une partie intégrante de votre workflow, et non comme un extra optionnel.

Le modèle à trois couches

Un pipeline d'équipe qui fonctionne bien comporte trois couches :

1. Pré-commit local — Le développeur exécute /review avant de pusher. La configuration de hook décrite ci-dessus automatise cela. Les constats à cette couche sont les moins coûteux à corriger.
2. Portail CI — Le workflow GitHub Actions publie les constats de Claude Code en tant que commentaire de PR avant qu'un réviseur humain ne soit assigné. Les réviseurs humains ne sont assignés qu'après que la revue CI est passée (aucun constat critique).
3. Attention de la revue humaine — Les réviseurs humains utilisent le commentaire de Claude Code comme guide de tri. Leur travail consiste à évaluer les éléments de jugement — adéquation architecturale, correction produit, compromis de performance — et non à relire chaque ligne à la recherche de fautes de frappe.

Partager les conventions CLAUDE.md

Votre CLAUDE.md est la couche de configuration du comportement de revue de l'agent. Traitez-le comme du code : committez-le, versionnez-le, faites relire ses modifications en PR. Lorsque l'équipe convient que Claude Code devrait arrêter de signaler un motif particulier (parce que vous avez un linter pour cela), mettez à jour CLAUDE.md et le changement s'applique à chaque future revue.

Calibrer les seuils de gravité

Les équipes trouvent souvent la calibration de gravité par défaut trop bruyante au début. Ajoutez des instructions explicites à CLAUDE.md pour la contrôler :

## Review Severity Rules
- Only flag console.log as a warning if it is in a non-test, non-debug file.
- Import ordering is never a finding; Prettier handles it.
- Treat any hardcoded credential as critical regardless of context.
- Performance suggestions are informational only unless they affect O(n²) loops.

Après quelques semaines d'utilisation, la plupart des équipes constatent que le niveau de bruit diminue considérablement une fois que l'attention de l'agent est calibrée sur les motifs qui comptent réellement dans leur base de code.

Gérer les faux positifs

Claude Code signalera occasionnellement quelque chose de manière incorrecte. La bonne réponse n'est pas de rejeter la revue en bloc — c'est d'ajouter une instruction spécifique au projet dans CLAUDE.md qui gère ce motif. Au fil du temps, cela crée une configuration de revue de plus en plus précise et spécifique au projet, qui reflète les standards réels de votre équipe.

Exécuter Claude Code Review sans installation locale

Tout ce qui a été décrit jusqu'ici suppose que vous avez Claude Code installé et fonctionnant dans votre terminal. Pour de nombreuses équipes — en particulier celles sur des machines d'entreprise verrouillées, des environnements Windows sans WSL, ou des développeurs qui souhaitent effectuer la revue depuis un onglet de navigateur — l'installation locale constitue un point de friction.

Happycapy exécute Claude Code dans un bac à sable cloud sécurisé directement dans votre navigateur. Vous obtenez la capacité complète de revue agentique — y compris le chargement de contexte inter-fichiers, le support de CLAUDE.md, et la commande /review — sans rien installer. Cela est particulièrement utile pour :

• Effectuer une revue de code sur des pull requests depuis un navigateur sans récupérer la branche localement
• Les équipes en cours d'adoption de la revue Claude Code qui veulent un environnement partagé et cohérent avant de déployer des installations locales
• Les machines verrouillées où l'installation de packages npm globaux nécessite l'approbation de l'IT
• La revue de dépôts peu familiers où vous souhaitez le chargement de contexte de l'agent sans cloner l'intégralité du dépôt

Si vous êtes curieux de savoir comment Claude Code se compare à des alternatives en termes de capacité agentique, consultez Claude Code vs. GitHub Copilot et Claude Code vs. Cursor. Et si vous souhaitez comprendre comment Happycapy exécute Claude Code dans un contexte navigateur, Claude Code sur le web couvre l'architecture.

Commencer gratuitement sur happycapy.ai

Foire aux questions

Q : Est-ce que la revue Claude Code fonctionne avec n'importe quel langage ?

Oui. Claude Code n'est pas spécifique à un langage — il lit tout diff textuel et applique un raisonnement sur le code qu'il contient. Il tend à être le plus précis sur Python, TypeScript, JavaScript, Go, et Rust (des langages avec une large représentation dans l'entraînement), mais il produit des constats utiles sur Ruby, Java, C#, et la plupart des autres langages courants. Pour les langages spécifiques à un domaine ou les frameworks inhabituels, ajouter du contexte dans CLAUDE.md affine considérablement le résultat.

Q : En quoi /review diffère-t-il du simple fait de demander à Claude, dans un chat, de regarder mon diff ?

La différence clé réside dans l'utilisation agentique d'outils et le contexte du dépôt. Dans un chat, Claude ne voit que ce que vous collez. La commande /review de Claude Code permet à l'agent d'ouvrir des fichiers, de suivre les imports, de vérifier les tests, et de lire les conventions de votre projet — produisant des constats ancrés dans la base de code réelle plutôt que dans l'extrait. Pour des changements volumineux ou interconnectés, cette différence est considérable.

Q : Est-ce que la revue Claude Code détectera les vulnérabilités de sécurité ?

Elle détecte de manière fiable les classes de vulnérabilités bien connues : injection SQL, XSS, failles CSRF, références directes non sécurisées à des objets, secrets codés en dur, assainissement d'entrée manquant. Elle est moins fiable sur les vecteurs d'attaque inédits et spécifiques à l'application, ou les vulnérabilités qui nécessitent une compréhension de votre environnement de déploiement. Considérez-la comme une analyse de sécurité de première passe approfondie, pas comme un test d'intrusion.

Q : Comment empêcher la revue de signaler des éléments que mon linter gère déjà ?

Ajoutez des exclusions explicites à votre CLAUDE.md : « Ne pas signaler l'ordre des imports — isort s'en charge. » ou « Ne pas signaler les espaces en fin de ligne — Prettier les impose. » La plupart des équipes constituent cette liste sur deux à trois semaines d'utilisation et constatent que le rapport signal/bruit s'améliore considérablement.

Q : Puis-je utiliser la revue Claude Code dans un monorepo avec plusieurs langages ?

Oui. Vous pouvez délimiter la revue avec un argument de chemin ou une plage de diff git qui ne couvre que le sous-répertoire que vous avez modifié. Vous pouvez également maintenir des sections de revue spécifiques à chaque langage dans votre CLAUDE.md que l'agent lit dans le cadre de son chargement de contexte.

Q : Que se passe-t-il si le diff est très volumineux — disons, une PR de 3 000 lignes ?

Pour les très gros diffs, envisagez une approche en deux passes : demandez d'abord uniquement les constats critiques et les avertissements (pas de suggestions), triez-les, puis demandez une analyse complète sur des fichiers ou sous-systèmes spécifiques. Pour les refactorisations extrêmement volumineuses, diviser la PR est la meilleure solution — à la fois pour la revue humaine et pour la revue par IA.

Q : Le résultat de la revue est-il déterministe ? Obtiendrai-je les mêmes constats deux fois ?

Non — comme toutes les sorties de grands modèles de langage, il y a de la variation entre les exécutions. Pour les revues à enjeux élevés, exécuter la commande deux fois et comparer les constats est une pratique raisonnable. La plupart des constats critiques apparaissent de manière constante ; les suggestions mineures varient davantage. Utiliser une température plus basse (si configurable pour votre workflow) ou des prompts plus prescriptifs réduit la variance.

Q : Comment la revue Claude Code interagit-elle avec les linters et outils d'analyse statique existants ?

Elle les complète, elle ne les remplace pas. Vos linters détectent les règles de style imposées de manière mécanique et rapide ; Claude Code ajoute une compréhension sémantique — il peut évaluer si une fonction fait la bonne chose, ce qu'aucun linter ne peut faire. Le pipeline idéal exécute les deux : les linters dans les hooks de pré-commit (rapide, déterministe), la revue Claude Code en CI (plus lente, sémantique). La commande /review est consciente de la configuration de votre linter et évite de dupliquer les constats que vos outils produisent déjà.

Q : Puis-je personnaliser le format du résultat de la revue pour le publier sur Slack ou dans un ticket ?

Oui. Vous pouvez demander à l'agent de produire les constats dans un format spécifique — JSON, markdown, ou un modèle correspondant au style de commentaire de PR de votre équipe. Combinez cela avec le système de hooks et un petit script shell, et vous obtenez un pipeline de revue entièrement automatisé qui publie des constats structurés partout où votre équipe effectue son suivi.

À lire aussi : Plongée en profondeur dans les hooks Claude Code — automatisez les vérifications de pré-commit, le linting, et des workflows personnalisés au-delà de la revue.

Guides associés

• Claude Code Hooks: The Power-User Guide to Automating Your Agent
• Build Autonomous Agents with the Claude Code SDK: A Practical Developer's Guide
• Claude Code vs GitHub Copilot: Autonomous Agent or In-Editor Assistant?
• Claude Code Web: How to Run Claude Code in Your Browser (No Install)