Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Code Review est en aperçu de recherche, disponible pour les abonnements Team et Enterprise. Il n’est pas disponible pour les organisations avec Zero Data Retention activé.
Code Review analyse vos pull requests GitHub et publie les résultats sous forme de commentaires en ligne sur les lignes de code où il a trouvé des problèmes. Une flotte d’agents spécialisés examine les modifications de code dans le contexte de votre base de code complète, en recherchant les erreurs logiques, les vulnérabilités de sécurité, les cas limites cassés et les régressions subtiles. Les résultats sont étiquetés par gravité et n’approuvent ni ne bloquent votre PR, de sorte que les flux de travail d’examen existants restent intacts. Vous pouvez affiner ce que Claude signale en ajoutant un fichier CLAUDE.md ou REVIEW.md à votre référentiel. Pour exécuter Claude dans votre propre infrastructure CI au lieu de ce service géré, consultez GitHub Actions ou GitLab CI/CD. Pour les référentiels sur une instance GitHub auto-hébergée, consultez GitHub Enterprise Server. Cette page couvre :

​
Comment fonctionnent les révisions

Une fois qu’un administrateur active Code Review pour votre organisation, les révisions se déclenchent à l’ouverture d’une PR, à chaque push, ou sur demande manuelle, selon le comportement configuré du référentiel. Commenter @claude review démarre les révisions sur une PR dans n’importe quel mode. Lorsqu’une révision s’exécute, plusieurs agents analysent le diff et le code environnant en parallèle sur l’infrastructure Anthropic. Chaque agent recherche une classe de problème différente, puis une étape de vérification vérifie les candidats par rapport au comportement réel du code pour filtrer les faux positifs. Les résultats sont dédupliqués, classés par gravité et publiés sous forme de commentaires en ligne sur les lignes spécifiques où les problèmes ont été trouvés, avec un résumé dans le corps de la révision. Si aucun problème n’est trouvé, Claude publie un court commentaire de confirmation sur la PR. Les révisions s’adaptent en coût à la taille et à la complexité de la PR, se complétant en moyenne en 20 minutes. Les administrateurs peuvent surveiller l’activité de révision et les dépenses via le tableau de bord analytique.

​
Niveaux de gravité

Chaque résultat est étiqueté avec un niveau de gravité :
MarqueurGravitéSignification
🔴ImportantUn bug qui devrait être corrigé avant la fusion
🟡NitUn problème mineur, utile à corriger mais non bloquant
🟣PréexistantUn bug qui existe dans la base de code mais n’a pas été introduit par cette PR
Les résultats incluent une section de raisonnement étendu réductible que vous pouvez développer pour comprendre pourquoi Claude a signalé le problème et comment il a vérifié le problème.

​
Évaluer et répondre aux résultats

Chaque commentaire de révision de Claude arrive avec 👍 et 👎 déjà attachés de sorte que les deux boutons apparaissent dans l’interface utilisateur GitHub pour un classement en un clic. Cliquez sur 👍 si le résultat était utile ou 👎 s’il était incorrect ou bruyant. Anthropic collecte les comptages de réactions après la fusion de la PR et les utilise pour affiner le réviseur. Les réactions ne déclenchent pas une re-révision ou ne changent rien sur la PR. Répondre à un commentaire en ligne ne pousse pas Claude à répondre ou à mettre à jour la PR. Pour agir sur un résultat, corrigez le code et poussez. Si la PR est abonnée aux révisions déclenchées par push, la prochaine exécution résout le thread quand le problème est corrigé. Pour demander une révision fraîche sans pousser, commentez @claude review once comme un commentaire PR de haut niveau.

​
Sortie de l’exécution de vérification

Au-delà des commentaires de révision en ligne, chaque révision remplit l’exécution de vérification Claude Code Review qui apparaît aux côtés de vos vérifications CI. Développez son lien Details pour voir un résumé de chaque résultat en un seul endroit, trié par gravité :
GravitéFichier:LigneProblème
🔴 Importantsrc/auth/session.ts:142L’actualisation du token entre en concurrence avec la déconnexion, laissant les sessions obsolètes actives
🟡 Nitsrc/auth/session.ts:88parseExpiry retourne silencieusement 0 sur une entrée malformée
Chaque résultat apparaît également comme une annotation dans l’onglet Files changed, marqué directement sur les lignes de diff pertinentes. Les résultats importants s’affichent avec un marqueur rouge, les nits avec un avertissement jaune, et les bugs préexistants avec un avis gris. Les annotations et le tableau de gravité sont écrits dans l’exécution de vérification indépendamment des commentaires de révision en ligne, de sorte qu’ils restent disponibles même si GitHub rejette un commentaire en ligne sur une ligne qui a bougé. L’exécution de vérification se termine toujours avec une conclusion neutre, de sorte qu’elle ne bloque jamais la fusion via les règles de protection de branche. Si vous souhaitez conditionner les fusions aux résultats de Code Review, lisez la répartition de gravité à partir de la sortie de l’exécution de vérification dans votre propre CI. La dernière ligne du texte Details est un commentaire lisible par machine que votre flux de travail peut analyser avec gh et jq : 
gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'
Cela retourne un objet JSON avec des comptages par gravité, par exemple {"normal": 2, "nit": 1, "pre_existing": 0}. La clé normal contient le nombre de résultats importants ; une valeur non nulle signifie que Claude a trouvé au moins un bug à corriger avant la fusion.

​
Ce que Code Review vérifie

Par défaut, Code Review se concentre sur la correction : les bugs qui cassent la production, pas les préférences de formatage ou la couverture de test manquante. Vous pouvez élargir ce qu’il vérifie en ajoutant des fichiers de guidance à votre référentiel.

​
Configurer Code Review

Un administrateur active Code Review une fois pour l’organisation et sélectionne les référentiels à inclure.
1

Ouvrir les paramètres d'administration Claude Code

Allez à claude.ai/admin-settings/claude-code et trouvez la section Code Review. Vous avez besoin d’un accès administrateur à votre organisation Claude et de la permission d’installer des GitHub Apps dans votre organisation GitHub.
2

Démarrer la configuration

Cliquez sur Setup. Cela commence le flux d’installation de GitHub App.
3

Installer la GitHub App Claude

Suivez les invites pour installer la GitHub App Claude à votre organisation GitHub. L’application demande ces permissions de référentiel :
  • Contents : lecture et écriture
  • Issues : lecture et écriture
  • Pull requests : lecture et écriture
Code Review utilise l’accès en lecture aux contenus et l’accès en écriture aux pull requests. L’ensemble de permissions plus large supporte également GitHub Actions si vous l’activez plus tard.
4

Sélectionner les référentiels

Choisissez les référentiels à activer pour Code Review. Si vous ne voyez pas un référentiel, assurez-vous d’avoir donné à la GitHub App Claude l’accès pendant l’installation. Vous pouvez ajouter plus de référentiels plus tard.
5

Définir les déclencheurs de révision par référentiel

Une fois la configuration terminée, la section Code Review affiche vos référentiels dans un tableau. Pour chaque référentiel, utilisez la liste déroulante Review Behavior pour choisir quand les révisions s’exécutent :
  • Once after PR creation : la révision s’exécute une fois à l’ouverture d’une PR ou marquée comme prête pour révision
  • After every push : la révision s’exécute à chaque push vers la branche PR, détectant les nouveaux problèmes à mesure que la PR évolue et résolvant automatiquement les threads lorsque vous corrigez les problèmes signalés
  • Manual : les révisions commencent uniquement quand quelqu’un commente @claude review ou @claude review once sur une PR ; @claude review abonne également la PR aux révisions lors des pushes ultérieurs
Réviser à chaque push exécute le plus de révisions et coûte le plus cher. Le mode manuel est utile pour les référentiels à fort trafic où vous souhaitez opter pour des PR spécifiques dans la révision, ou pour commencer à réviser vos PR uniquement une fois qu’elles sont prêtes.
Le tableau des référentiels affiche également le coût moyen par révision pour chaque référentiel en fonction de l’activité récente. Utilisez le menu d’actions de ligne pour activer ou désactiver Code Review par référentiel, ou pour supprimer complètement un référentiel. Pour vérifier la configuration, ouvrez une PR de test. Si vous avez choisi un déclencheur automatique, une exécution de vérification nommée Claude Code Review apparaît dans quelques minutes. Si vous avez choisi Manual, commentez @claude review sur la PR pour démarrer la première révision. Si aucune exécution de vérification n’apparaît, confirmez que le référentiel est listé dans vos paramètres d’administration et que la GitHub App Claude y a accès.

​
Déclencher manuellement les révisions

Deux commandes de commentaire démarrent une révision à la demande. Les deux fonctionnent quel que soit le déclencheur configuré du référentiel, de sorte que vous pouvez les utiliser pour opter pour des PR spécifiques dans la révision en mode Manual ou pour obtenir une re-révision immédiate dans d’autres modes.
CommandeCe qu’elle fait
@claude reviewDémarre une révision et abonne la PR aux révisions déclenchées par push à partir de maintenant
@claude review onceDémarre une seule révision sans abonner la PR aux pushes futurs
Utilisez @claude review once quand vous souhaitez des commentaires sur l’état actuel d’une PR mais ne souhaitez pas que chaque push ultérieur entraîne une révision. Cela est utile pour les PR longues avec des pushes fréquents, ou quand vous souhaitez un deuxième avis ponctuel sans modifier le comportement de révision de la PR. Pour que l’une ou l’autre commande déclenche une révision :
  • Publiez-la comme un commentaire PR de haut niveau, pas un commentaire en ligne sur une ligne de diff
  • Mettez la commande au début du commentaire, avec once sur la même ligne si vous utilisez la forme ponctuelle
  • Vous devez avoir un accès propriétaire, membre ou collaborateur au référentiel
  • La PR doit être ouverte
Contrairement aux déclencheurs automatiques, les déclencheurs manuels s’exécutent sur les PR brouillon, car une demande explicite signale que vous souhaitez la révision maintenant quel que soit le statut de brouillon. Si une révision s’exécute déjà sur cette PR, la demande est mise en file d’attente jusqu’à ce que la révision en cours se termine. Vous pouvez surveiller la progression via l’exécution de vérification sur la PR.

​
Personnaliser les révisions

Code Review lit deux fichiers de votre référentiel pour guider ce qu’il signale. Ils diffèrent dans la force avec laquelle ils influencent la révision :
  • CLAUDE.md : instructions de projet partagées que Claude Code utilise pour toutes les tâches, pas seulement les révisions. Code Review le lit comme contexte de projet et signale les violations nouvellement introduites comme des nits.
  • REVIEW.md : instructions de révision uniquement, injectées directement dans chaque agent du pipeline de révision comme priorité la plus élevée. Utilisez-le pour modifier ce qui est signalé, à quelle gravité, et comment les résultats sont rapportés.

​
CLAUDE.md

Code Review lit vos fichiers CLAUDE.md du référentiel et traite les violations nouvellement introduites comme des résultats au niveau nit. Cela fonctionne bidirectionnellement : si votre PR modifie le code d’une manière qui rend une déclaration CLAUDE.md obsolète, Claude signale que les docs doivent être mises à jour aussi. Claude lit les fichiers CLAUDE.md à chaque niveau de votre hiérarchie de répertoires, donc les règles dans le CLAUDE.md d’un sous-répertoire s’appliquent uniquement aux fichiers sous ce chemin. Consultez la documentation de mémoire pour plus d’informations sur le fonctionnement de CLAUDE.md. Pour la guidance spécifique à la révision que vous ne souhaitez pas appliquer aux sessions Claude Code générales, utilisez REVIEW.md à la place.

​
REVIEW.md

REVIEW.md est un fichier à la racine de votre référentiel qui remplace le comportement de Code Review sur votre référentiel. Son contenu est injecté dans l’invite système de chaque agent du pipeline de révision comme bloc d’instruction de priorité la plus élevée, prenant précédence sur la guidance de révision par défaut. Parce qu’il est collé verbatim, REVIEW.md est des instructions simples : la syntaxe @ import n’est pas développée, et les fichiers référencés ne sont pas lus dans l’invite. Mettez les règles que vous souhaitez appliquer directement dans le fichier.

​
Ce que vous pouvez affiner

REVIEW.md est du markdown libre, donc tout ce que vous pouvez exprimer comme une instruction de révision est dans le champ d’application. Les modèles ci-dessous ont le plus d’impact en pratique. Gravité : redéfinissez ce que 🔴 Important signifie pour votre référentiel. L’étalonnage par défaut cible le code de production ; un référentiel de docs, un référentiel de config, ou un prototype pourrait vouloir une définition beaucoup plus étroite. Énoncez explicitement quelles classes de résultats sont Important et lesquelles sont Nit au maximum. Vous pouvez également escalader dans l’autre direction, par exemple en traitant toute violation CLAUDE.md comme Important plutôt que le nit par défaut. Volume de nit : limitez le nombre de commentaires 🟡 Nit qu’une seule révision publie. La prose et les fichiers de config peuvent être polis à jamais. Un plafond comme « signaler au maximum cinq nits, mentionner le reste comme un comptage dans le résumé » garde les révisions actionnables. Règles de saut : listez les chemins, les modèles de branche et les catégories de résultats où Claude ne devrait publier aucun résultat. Les candidats courants sont le code généré, les lockfiles, les dépendances vendues, et les branches créées par machine, ainsi que tout ce que votre CI applique déjà comme le linting ou la vérification orthographique. Pour les chemins qui méritent une certaine révision mais pas un examen complet, définissez une barre plus élevée au lieu de sauter entièrement : « dans scripts/, signaler uniquement si proche de certain et grave. » Vérifications spécifiques au référentiel : ajoutez des règles que vous souhaitez signaler sur chaque PR, comme « les nouveaux itinéraires API doivent avoir un test d’intégration. » Parce que REVIEW.md est injecté comme priorité la plus élevée, ceux-ci atterrissent plus fiablement que les mêmes règles dans un long CLAUDE.md. Barre de vérification : exigez des preuves avant qu’une classe de résultat soit publiée. Par exemple, « les affirmations de comportement ont besoin d’une citation file:line dans la source, pas une inférence à partir de la dénomination » réduit les faux positifs qui coûteraient autrement à l’auteur un aller-retour. Convergence de re-révision : dites à Claude comment se comporter quand une PR a déjà été révisée. Une règle comme « après la première révision, supprimez les nouveaux nits et publiez les résultats Important uniquement » empêche un correctif d’une ligne d’atteindre la septième manche sur le style seul. Forme du résumé : demandez au corps de la révision de s’ouvrir avec un comptage d’une ligne comme 2 factual, 4 style, et de commencer par « aucun problème factuel » quand c’est le cas. L’auteur veut connaître la forme du travail avant les détails.

​
Exemple

Ce REVIEW.md recalibre la gravité pour un service backend, limite les nits, saute les fichiers générés, et ajoute des vérifications spécifiques au référentiel. 
# Instructions de révision

## Ce que Important signifie ici

Réservez Important aux résultats qui cassent le comportement, fuient les données,
ou bloquent un rollback : logique incorrecte, requêtes de base de données non scoped, PII
dans les logs ou les messages d'erreur, et les migrations qui ne sont pas backward
compatible. Le style, la dénomination, et les suggestions de refactorisation sont Nit au
maximum.

## Limiter les nits

Signaler au maximum cinq Nits par révision. Si vous en avez trouvé plus, dites « plus N
éléments similaires » dans le résumé au lieu de les publier en ligne. Si
tout ce que vous avez trouvé est un Nit, commencez le résumé par « Aucun problème bloquant. »

## Ne pas signaler

- Tout ce que CI applique déjà : lint, formatage, erreurs de type
- Fichiers générés sous `src/gen/` et tout fichier `*.lock`
- Code de test uniquement qui viole intentionnellement les règles de production

## Toujours vérifier

- Les nouveaux itinéraires API ont un test d'intégration
- Les lignes de log n'incluent pas les adresses e-mail, les ID utilisateur, ou les corps de requête
- Les requêtes de base de données sont scoped au tenant de l'appelant

​
Gardez-le concentré

La longueur a un coût : un long REVIEW.md dilue les règles qui importent le plus. Gardez-le aux instructions qui changent le comportement de révision, et laissez le contexte de projet général dans CLAUDE.md.

​
Afficher l’utilisation

Allez à claude.ai/analytics/code-review pour voir l’activité Code Review dans votre organisation. Le tableau de bord affiche :
SectionCe qu’il affiche
PRs reviewedNombre quotidien de pull requests examinées sur la plage de temps sélectionnée
Cost weeklyDépenses hebdomadaires sur Code Review
FeedbackNombre de commentaires de révision qui ont été auto-résolus parce qu’un développeur a résolu le problème
Repository breakdownComptages par référentiel des PR examinées et des commentaires résolus
Le tableau des référentiels dans les paramètres d’administration affiche également le coût moyen par révision pour chaque référentiel. Les chiffres de coût du tableau de bord sont des estimations pour surveiller l’activité ; pour les dépenses exactes de facture, consultez votre facture Anthropic.

​
Tarification

Code Review est facturé en fonction de l’utilisation des tokens. Chaque révision coûte en moyenne 15 à 25 dollars, s’adaptant à la taille de la PR, à la complexité de la base de code, et au nombre de problèmes nécessitant une vérification. L’utilisation de Code Review est facturée séparément via extra usage et ne compte pas par rapport à l’utilisation incluse de votre plan. Le déclencheur de révision que vous choisissez affecte le coût total :
  • Once after PR creation : s’exécute une fois par PR
  • After every push : s’exécute à chaque push, multipliant le coût par le nombre de pushes
  • Manual : aucune révision jusqu’à ce que quelqu’un commente @claude review sur une PR
Dans n’importe quel mode, commenter @claude review opte la PR dans les révisions déclenchées par push, de sorte que des coûts supplémentaires s’accumulent par push après ce commentaire. Pour exécuter une seule révision sans abonner à des pushes futurs, commentez @claude review once à la place. Les coûts apparaissent sur votre facture Anthropic quel que soit le fait que votre organisation utilise Amazon Bedrock ou Google Vertex AI pour d’autres fonctionnalités Claude Code. Pour définir un plafond de dépenses mensuelles pour Code Review, allez à claude.ai/admin-settings/usage et configurez la limite pour le service Claude Code Review. Surveillez les dépenses via le graphique de coût hebdomadaire dans analytics ou la colonne de coût moyen par référentiel dans les paramètres d’administration.

​
Dépannage

Les exécutions de révision sont au mieux. Une exécution échouée ne bloque jamais votre PR, mais elle ne se réessaye pas non plus d’elle-même. Cette section couvre comment récupérer d’une exécution échouée et où chercher quand l’exécution de vérification signale des problèmes que vous ne pouvez pas trouver.

​
Redéclencher une révision échouée ou expirée

Quand l’infrastructure de révision rencontre une erreur interne ou dépasse sa limite de temps, l’exécution de vérification se termine avec un titre de Code review encountered an error ou Code review timed out. La conclusion est toujours neutre, de sorte que rien ne bloque votre fusion, mais aucun résultat n’est publié. Pour exécuter la révision à nouveau, commentez @claude review once sur la PR. Cela démarre une révision fraîche sans abonner la PR aux pushes futurs. Si la PR est déjà abonnée aux révisions déclenchées par push, pousser un nouveau commit démarre également une nouvelle révision. Le bouton Re-run dans l’onglet Checks de GitHub ne redéclenche pas Code Review. Utilisez la commande de commentaire ou un nouveau push à la place.

​
Révision n’a pas s’exécuté et la PR affiche un message de plafond de dépenses

Quand le plafond de dépenses mensuelles de votre organisation est atteint, Code Review publie un seul commentaire sur la PR expliquant que la révision a été ignorée. Les révisions reprennent automatiquement au début de la prochaine période de facturation, ou immédiatement quand un administrateur augmente le plafond à claude.ai/admin-settings/usage.

​
Trouver les problèmes qui ne s’affichent pas comme des commentaires en ligne

Si le titre de l’exécution de vérification dit que des problèmes ont été trouvés mais que vous ne voyez pas de commentaires de révision en ligne sur le diff, cherchez dans ces autres emplacements où les résultats sont surfacés :
  • Check run Details : cliquez sur Details à côté de la vérification Claude Code Review dans l’onglet Checks. Le tableau de gravité liste chaque résultat avec son fichier, sa ligne, et son résumé quel que soit le fait que le commentaire en ligne ait été accepté.
  • Files changed annotations : ouvrez l’onglet Files changed sur la PR. Les résultats s’affichent comme des annotations attachées directement aux lignes de diff, séparées des commentaires de révision.
  • Review body : si vous avez poussé vers la PR pendant qu’une révision s’exécutait, certains résultats peuvent référencer des lignes qui n’existent plus dans le diff actuel. Ceux-ci apparaissent sous un titre Additional findings dans le texte du corps de révision plutôt que comme des commentaires en ligne.

​
Ressources connexes

Code Review est conçu pour fonctionner aux côtés du reste de Claude Code. Si vous souhaitez exécuter des révisions localement avant d’ouvrir une PR, avez besoin d’une configuration auto-hébergée, ou souhaitez approfondir la façon dont CLAUDE.md façonne le comportement de Claude dans tous les outils, ces pages sont de bons prochains arrêts :
  • Plugins : parcourez la place de marché des plugins, y compris un plugin code-review pour exécuter des révisions à la demande localement avant de pousser
  • GitHub Actions : exécutez Claude dans vos propres flux de travail GitHub Actions pour une automatisation personnalisée au-delà de la révision de code
  • GitLab CI/CD : intégration Claude auto-hébergée pour les pipelines GitLab
  • Memory : comment les fichiers CLAUDE.md fonctionnent dans Claude Code
  • Analytics : suivez l’utilisation de Claude Code au-delà de la révision de code