Lire et demander des revues sur une pull request

Lisez les résultats de Code Review sur votre pull request GitHub, répondez-y ou ignorez-les, et demandez une revue avec @claude review.

Code Review est un service géré qu'un Owner de votre organisation Claude active pour un ensemble de dépôts GitHub. Une fois activé, Claude examine les pull requests de ces dépôts et publie ses résultats sous forme de commentaires en ligne, d'un résumé dans le corps de la revue et d'un check run nommé Claude Code Review. Une revue n'approuve ni ne bloque jamais votre pull request, et le check run ne se conclut jamais par un échec.

Un Owner contrôle quand les revues s'exécutent et leur niveau d'exhaustivité pour chaque dépôt.

[!NOTE]

Si votre forfait n'inclut pas Code Review, vous pouvez tout de même demander à Claude d'examiner votre branche depuis une session Claude Code : consultez Effectuer une revue locale avec /code-review.

Niveaux de gravité

Claude publie chaque résultat sous forme de commentaire en ligne sur les lignes concernées et lui attribue l'un des trois niveaux de gravité suivants :

Lorsque la revue a enregistré son raisonnement, le résultat comporte une section repliée Why this was flagged. Développez-la pour lire pourquoi Claude a signalé le problème et comment il l'a vérifié.

Pour modifier ce que Claude signale dans votre dépôt ou la façon dont il classe la gravité, consultez Personnaliser Code Review.

Répondre aux résultats

Vous pouvez fusionner sans répondre à un résultat, sauf si les règles propres à votre dépôt l'exigent. Si sa protection de branche exige la résolution des conversations, résolvez le fil de chaque résultat avant de fusionner.

Pour traiter un résultat, résolvez son fil ou poussez une correction.

• L'ignorer sans modifier le code : résolvez vous-même le fil sur GitHub. Une simple réponse n'ignore pas un résultat.
• Corriger le problème : modifiez le code et poussez. La revue suivante de la pull request résout le fil précédent lorsqu'elle juge le problème corrigé, que cette revue s'exécute automatiquement lors de votre push ou que vous la demandiez.
• Expliquer ou contester : répondez au commentaire. Claude ne répond pas immédiatement, et une réponse ne lance pas de revue. La revue suivante de la pull request lit les réponses à ses résultats précédents, et peut résoudre le fil ou publier une réponse de suivi. Si le même type de résultat revient sans cesse, demandez à un mainteneur d'ajouter une règle à REVIEW.md.

Pour obtenir cette revue suivante sans pousser, publiez @claude review en tant que commentaire de premier niveau sur la pull request.

Sortie du check run

Le lien Details du check run Claude Code Review ouvre les résultats dans un tableau trié par gravité, y compris tout résultat dont le commentaire en ligne n'a pas été accepté par GitHub :

Un résultat associé à une ligne mais qui n'a pas été publié en tant que commentaire en ligne apparaît sous forme d'annotation dans l'onglet Files changed, sur les lignes concernées. Les résultats Important s'affichent en rouge, les nits en jaune et les bugs préexistants en gris.

Le check run se conclut comme neutre, ou comme ignoré après certains push qui ne modifient aucun fichier et conservent le résultat précédent. Il ne se conclut jamais par un échec, de sorte qu'une revue terminée ne fait pas échouer une vérification requise. Si vous ne voyez aucun résultat, ou si une revue ne s'est pas exécutée, consultez Résoudre les problèmes de Code Review.

Lorsqu'un push conserve le résultat précédent

Si le check run porte l'un de ces titres après votre push, Code Review a conservé le résultat d'une revue précédente au lieu d'en lancer une nouvelle :

• Code review skipped — no new changes : aucun résultat Important de la revue précédente n'est encore ouvert, vous n'avez donc pas besoin d'une nouvelle revue
• Code review not repeated — earlier findings still open : pour lancer une nouvelle revue, poussez un correctif pour un résultat Important ouvert, ou résolvez son fil et poussez à nouveau

Sur github.com, Code Review peut conserver un résultat lorsque ces deux conditions sont réunies :

• La pull request ajoute et supprime toujours les mêmes lignes, comme après un commit vide, une fusion sans conflit de la branche de base ou un rebase sans conflit
• Personne n'a résolu le fil d'un résultat Important depuis cette revue

Pour obtenir une revue sans modification du code, commentez @claude review ou cliquez sur Re-run dans le check run.

Lire le résultat depuis un script

Pour conditionner une fusion ou publier un résumé depuis votre propre CI, analysez la dernière ligne du texte Details avec gh et jq. Cette ligne est un commentaire HTML qui contient les décomptes par gravité au format JSON :

<!-- bughunter-severity: {"nit":1,"normal":2,"pre_existing":0} -->

Les lignes qui la précèdent peuvent inclure des noms de fichiers provenant de la pull request. Si vous analysez le texte à votre manière, prenez les décomptes uniquement dans la dernière ligne, comme le fait la commande de ces étapes.

1. Trouver l'ID du check run

Depuis votre shell, listez les check runs du commit et récupérez l'id de l'exécution Claude Code Review. Remplacez OWNER et REPO par le propriétaire et le nom de votre dépôt, et <commit-sha> par le commit de tête de la pull request :

gh api repos/OWNER/REPO/commits/<commit-sha>/check-runs --jq '.check_runs[] | {id, name}'

Si le commit a eu plus d'une exécution Claude Code Review, par exemple après un Re-run, GitHub ne liste que la plus récente.

2. Lire les décomptes par gravité

Lisez les décomptes depuis le champ output.text du check run, qui contient le texte Details. Remplacez CHECK_RUN_ID par l'ID :

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID --jq '
  (.output.text | split("\n") | last
    | scan("^<!-- bughunter-severity: (.*) -->$")[0] | fromjson)?
  // error("no severity line")'

Cette commande affiche un objet JSON contenant un décompte par gravité, avec ses clés dans l'ordre alphabétique, par exemple {"nit": 1, "normal": 2, "pre_existing": 0}. Sauf pour un check run qui a conservé un résultat précédent, les décomptes incluent les résultats des revues précédentes de la pull request dont les fils sont encore ouverts.

Sous le titre Code review skipped — no new changes, les décomptes excluent les nits et les résultats préexistants des revues précédentes qui sont encore ouverts. Aucun résultat Important de la revue précédente n'est alors encore ouvert.

3. Agir en fonction du résultat

Faites en sorte que votre script gère ces cas dans l'ordre :

• Le titre commence par Code review not repeated : Code Review a conservé un résultat précédent dont les résultats Important sont encore ouverts, et le check run ne comporte pas de ligne de gravité. Lisez le titre avant les décomptes, avec gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID --jq .output.title. Faites échouer le job si vous souhaitez conditionner la fusion.
• Le titre se termine par no new changes : laissez le job réussir sans lire les décomptes
• normal est supérieur à zéro : faites échouer le job si vous souhaitez conditionner la fusion. La clé normal contient le nombre de résultats Important : Claude a donc trouvé au moins un bug qui mérite d'être corrigé avant la fusion. Pour n'afficher que ce décompte, ajoutez | .normal avant le guillemet simple fermant.
• La ligne est absente : la commande affiche une erreur contenant no severity line au lieu des décomptes, et se termine avec un statut non nul. Considérez cela comme une absence de verdict plutôt que comme zéro résultat. Le check run d'une revue qui a échoué, expiré, été annulée ou remplacée par une plus récente ne comporte pas cette ligne, et certaines revues terminées n'en ont pas non plus.

Demander une revue

Si votre pull request est un brouillon ou provient d'un fork, les revues automatiques l'ignorent : demandez donc la revue avec une commande de commentaire. Pour obtenir une revue sur votre pull request, effectuez l'une des actions suivantes :

• L'ouvrir ou la marquer comme prête : dans un dépôt configuré sur Once after PR creation ou After every push, une revue démarre lorsque vous ouvrez ou rouvrez la pull request, ou que vous marquez un brouillon comme prêt pour la revue.
• Publier une commande en commentaire : publiez @claude review sur la pull request.
• Pousser un commit : un push lance une revue dans un dépôt configuré sur After every push, ou sur une pull request que vous avez abonnée avec @claude review always. Si votre pull request ajoute et supprime toujours les mêmes lignes après le push, Code Review peut conserver le résultat précédent à la place.
• Cliquer sur Re-run : après l'échec ou l'expiration d'une revue sur une pull request qui ne provient pas d'un fork, relancez-la depuis le check run. Sur une pull request qui ne provient pas d'un fork, vous pouvez aussi cliquer sur Re-run après un push qui a conservé le résultat précédent.
• Attendre la nouvelle tentative automatique : une revue dont la session a été interrompue est automatiquement réessayée une fois. Le résumé du check run indique quand c'est le cas.

Commandes de commentaire

Publiez l'une de ces commandes en commentaire sur la pull request :

Dans un dépôt configuré sur After every push, vous ne pouvez pas arrêter les revues avec un commentaire, car les push y lancent des revues avec ou sans abonnement. Pour empêcher les push de lancer des revues sur une pull request de ce dépôt, convertissez-la en brouillon. Lorsque vous la marquez à nouveau comme prête pour la revue, une revue démarre.

Pour qu'une commande de commentaire prenne effet, toutes les conditions suivantes doivent être remplies :

• Publiez-la en tant que nouveau commentaire de premier niveau sur la pull request, et non en tant que commentaire en ligne sur une ligne du diff ni dans le corps d'une revue. La modification d'un commentaire précédent ne compte pas.
• Placez la commande entière sur une seule ligne au début du commentaire. D'autres textes peuvent la suivre. Si always ou stop est mal orthographié ou se trouve sur une ligne ultérieure, Claude interprète le commentaire comme un simple @claude review et lance une revue unique. La casse n'a pas d'importance.
• Vous devez disposer de la permission write, maintain ou admin sur le dépôt. Claude vérifie cela auprès de GitHub pour chaque personne qui commente, et les commentaires de bots ne lancent pas de revues.
• La pull request doit être ouverte.

Lorsqu'une commande qui lance une revue est acceptée, un check run Claude Code Review apparaît sur la pull request avec le titre Code review queued.... Le titre devient Code review in progress... lorsque la revue démarre. Claude peut aussi réagir à votre commentaire avec 👀, mais cette réaction peut apparaître même lorsqu'aucune revue ne démarre : fiez-vous plutôt au check run.

Si une revue est déjà en cours sur le dernier commit de la pull request, une nouvelle demande n'en lance pas une seconde.

[!NOTE]

Avant une mise à jour de juillet 2026, @claude review abonnait la PR aux revues déclenchées par push. Si vous dépendiez de ce comportement, publiez plutôt @claude review always.

Ce que couvre une revue ultérieure

Une revue ultérieure qui démarre d'elle-même, par exemple après un push, se concentre sur ce qui a changé depuis la dernière revue et publie moins de nits et de résultats préexistants. Pour savoir si elle a omis des résultats pour cette raison, cherchez dans le corps de la revue une phrase qui les comptabilise :

• Résultats sur du code qui n'a pas changé depuis la dernière revue : la phrase se termine par « outside the scope of this re-review and not posted »
• Nits et résultats préexistants : la phrase se termine par « found and not posted »

Pour obtenir une revue qui n'omet aucun de ces résultats, publiez @claude review. Elle couvre à nouveau l'ensemble de la pull request.

Revue des brouillons et des pull requests provenant de forks

Les revues automatiques ignorent ces deux cas : demandez donc la revue avec une commande de commentaire :

• Pull requests en brouillon : une commande de commentaire s'exécute sur un brouillon, ce qui vous permet de demander une revue avant de marquer la pull request comme prête. Les push vers un brouillon ne lancent pas de revues, même après @claude review always. L'abonnement prend effet une fois la pull request marquée comme prête.
• Pull requests provenant de forks : Claude n'examine pas automatiquement une pull request provenant d'un fork, quel que soit le paramètre Review runs du dépôt. Pour en lancer une, publiez @claude review sur la pull request. Les conditions des commandes de commentaire s'appliquent toujours, et l'accès en écriture requis porte sur le dépôt de base, et non sur le fork.

Sur une pull request provenant d'un fork, @claude review always fonctionne également, mais n'abonne pas la pull request aux revues lors des push ultérieurs. Cliquer sur Re-run sur le check run n'y lance pas de revue.

Utiliser Code Review avec la GitHub Action Claude Code

Si le dépôt exécute également la GitHub Action Claude Code en mode interactif avec sa phrase de déclenchement @claude par défaut, un commentaire @claude review lance aussi l'Action. Pour séparer les deux, définissez l'entrée trigger_phrase de l'Action sur une phrase différente.

Ressources associées

• Résoudre les problèmes de Code Review : une revue qui n'a pas démarré, a échoué ou a été ignorée pour des raisons de budget
• Code Review : ce qu'est le service et comment se déroule une revue
• Configurer Code Review : pour les Owners, activer Code Review et choisir quand les revues s'exécutent et à quel niveau
• Personnaliser Code Review : modifier ce que Claude signale avec REVIEW.md et CLAUDE.md
• Coûts et utilisation de Code Review : comment les revues sont facturées et où la limite de dépenses est définie
• Effectuer une revue locale avec /code-review : exécuter une revue de votre branche depuis une session Claude Code