Qu'est-ce que /code-review de Claude Code ? Utilisation, choix du niveau, tarifs d'ultra, inconvénients et résultats d'un essai réel

La commande /code-review de Claude Code lit le diff que vous avez sous la main (les modifications non commitées et les commits en avance sur l'upstream), y cherche des bugs de correction et vous les signale. C'est une skill intégrée, livrée avec Claude Code : vous la lancez directement depuis le terminal, sans installer d'application GitHub. Taper /review revient exactement au même.

Cet article s'appuie sur le texte original de la documentation officielle de Claude Code (la section « Review a diff locally » de Code Review, Find bugs with ultrareview et Commands) ainsi que sur le CHANGELOG pour expliquer ce qu'elle fait, comment choisir entre les niveaux (de low à max) et ultra, et comment se servir de --fix et --comment. Chaque point de spécification décrit ici a été vérifié dans le texte source au 2 octobre 2026. Les sections 9 et 10 racontent aussi ce qui s'est passé quand j'ai réellement lancé /code-review high sur le code de ce site, et les inconvénients relevés en chemin.

1. Qu'est-ce que /code-review ? Une skill intégrée qui cherche les bugs de votre diff

La référence des commandes (Commands) la décrit ainsi, en anglais : « Review the current diff, or a PR number, branch, or path you pass, for correctness bugs », autrement dit elle relit le diff en cours, ou le numéro de PR, la branche ou le chemin que vous lui passez, à la recherche de bugs de correction. La même page ajoute que, selon le modèle et le niveau d'effort, la revue couvre aussi des pistes de nettoyage, et la page Code Review précise qu'elle signale les bugs de correction ainsi que des nettoyages portant sur la réutilisation, la simplification et l'efficacité. La chasse aux bugs est donc sa mission principale ; les suggestions de nettoyage s'y ajoutent selon les conditions.

La syntaxe est la suivante :

/code-review [low|medium|high|xhigh|max|ultra] [--fix] [--comment] [pr#|branch|path]

Quatre propriétés sont bonnes à connaître d'emblée :

• Elle tourne en arrière-plan. La revue s'exécute comme un sous-agent doté de sa propre fenêtre de contexte : elle n'encombre pas votre conversation. Les signalements y arrivent une fois la revue terminée.
• Elle lit CLAUDE.md, mais pas REVIEW.md. REVIEW.md est le fichier d'instructions de la version application GitHub de Code Review, présentée plus bas.
• /review est un alias. D'après la documentation, avant la v2.1.223, /review était une commande distincte qui relisait une PR GitHub en une seule passe. Aujourd'hui, c'est la même chose que /code-review.
• Son ancien nom était /simplify. Selon le CHANGELOG, /simplify a été renommée en /code-review dans la v2.1.147, puis /simplify est revenue sous la forme d'une commande distincte qui ne fait que du nettoyage et ne cherche pas de bugs.

Dans le terminal et lors des exécutions en -p, les signalements reviennent sous forme de texte dans la réponse. Dans les applications qui demandent une liste de signalements, comme l'application de bureau, ils s'affichent en liste : chaque entrée indique l'emplacement dans le fichier, un résumé d'une phrase et une étiquette de catégorie comme correctness. Quand Claude les corrige ensuite, chaque entrée est marquée comme corrigée, ignorée ou sans modification nécessaire.

2. Utilisation de base : choisir ce qu'on relit

La forme la plus simple consiste à la taper sans argument dans la session où vous travaillez.

# Relire les commits en avance sur l'upstream + les modifications non commitées
/code-review

# Relire à un niveau précis
/code-review high

# Passer un numéro de PR pour relire la pull request d'un collègue
/code-review high 1234

# Passer une plage de branches
/code-review main...my-feature

Sans argument, la cible correspond, selon la documentation, aux commits de votre branche en avance sur son upstream, plus toutes les modifications non commitées. S'il n'y a rien de nouveau sur la branche ni dans l'arbre de travail, elle n'a rien à signaler. Pour relire autre chose, passez-lui une cible :

Sauf si vous ajoutez ultra, tout ce qui reste après le niveau et les options est traité comme la cible de la revue. Par exemple, /code-review /fix-issue 123 ne charge pas /fix-issue comme une seconde skill : le texte /fix-issue 123 est lu comme la cible.

Dans les cas suivants, elle s'exécute au premier plan, dans votre conversation, et non en arrière-plan : quand vous la relancez alors qu'une revue précédente est encore en cours, en mode non interactif avec -p ou l'Agent SDK, et quand vous réglez la variable d'environnement CLAUDE_CODE_DISABLE_BACKGROUND_TASKS sur 1 (ce qui désactive aussi toutes les autres fonctions d'arrière-plan).

3. Choisir un niveau : de low à max

Le niveau est un compromis entre l'étendue de la revue et le degré de certitude exigé pour ses signalements. La documentation explique qu'en low et medium, la revue ne signale que ce dont elle est le plus sûre, ce qui limite les faux positifs, tandis que de high à max, elle élargit la couverture et peut inclure des signalements dont elle est moins sûre.

Le bon critère, c'est le temps que vous pouvez consacrer à lire les signalements. Pour une vérification rapide entre deux tâches, prenez low ou medium ; pour attraper davantage de choses avant un merge, si vous pouvez vous permettre d'écarter vous-même les faux positifs, prenez high ou plus. Cette répartition suit la description de la documentation. Qu'un niveau plus élevé consomme plus de tokens relève de la même logique que l'effort en général, mais la documentation officielle ne donne aucun chiffre de durée ni d'usage par niveau. Ce que recouvre l'effort lui-même est expliqué dans notre article sur le réglage de l'effort dans Claude Code.

Sans niveau, elle reprend « le dernier niveau que vous avez tapé »

Si vous ne tapez pas de niveau, la revue utilise le dernier niveau, de low à max, que vous avez tapé vous-même. Cela inclut un niveau tapé lors d'une session précédente ; vous voyez alors un avis du type Reusing high effort, the level you typed last time. Les détails :

• Le niveau mémorisé est mis à jour quand vous tapez par exemple /code-review high dans une session interactive.
• Un niveau passé lors d'une exécution non interactive en -p n'est pas mémorisé.
• ultra n'utilise pas le niveau mémorisé et ne le met pas à jour.
• Si vous n'avez jamais tapé de niveau, c'est l'effort actuel de la session qui s'applique.

La documentation précise aussi qu'avant la v2.1.223, un /code-review sans niveau utilisait toujours l'effort actuel de la session. Si vous l'omettez en comptant sur l'ancien comportement, la revue peut tourner à un niveau plus élevé (ou plus bas) que prévu : si cela compte pour vous, tapez le niveau à chaque fois.

4. Se servir de --fix et --comment

Ce que fait --fix ne s'annule pas forcément avec /rewind

C'est le point le plus important à surveiller. D'après la documentation, les modifications faites par --fix lors d'une revue en arrière-plan ont lieu en dehors des points de contrôle de votre session, si bien que /rewind ne les annule pas. Passez plutôt par git pour revenir en arrière. Quand la revue tourne au premier plan (revue précédente encore en cours, -p, etc.), elle modifie les fichiers pendant votre propre tour, et /rewind les restaure comme d'habitude.

# Commiter l'état actuel avant --fix pour pouvoir revenir en arrière facilement
git add -A && git commit -m "wip: before code-review --fix"
/code-review medium --fix

# Si le résultat ne vous plaît pas, annulez-le avec git
git diff
git restore .

Vous pouvez aussi lancer la revue sans --fix, lire les résultats, puis demander de « corriger seulement les n^os 1 et 3 ». Si vous n'êtes pas sûr que tous les signalements doivent être appliqués, c'est la voie la plus prudente. Les points de contrôle sont détaillés dans notre article sur les points de contrôle et /rewind.

Où --comment publie

• Pull requests GitHub : les signalements sont publiés en commentaires en ligne sur les lignes concernées.
• Merge requests GitLab : ils sont publiés en une seule note via glab, la CLI de GitLab (v2.1.257 ou ultérieure). Si glab n'est pas installé, les signalements s'affichent seulement dans le terminal.

Sur GitLab, passez la MR sous forme d'URL ou au format !123. Un simple numéro ou un nom de branche n'est traité comme une MR que si l'origin est sur gitlab.com ; pour une instance GitLab auto-hébergée, la documentation indique d'utiliser l'URL ou !123. Au 2 octobre 2026, la documentation officielle ne dit pas si la publication sur GitHub nécessite une authentification comme gh.

5. ultra : revue multi-agents dans le cloud et tarifs

/code-review ultra est une revue approfondie qui fait tourner plusieurs agents relecteurs en parallèle dans un bac à sable du cloud d'Anthropic, et non sur votre machine. C'est un aperçu de recherche appelé ultrareview ; sur les comptes où il est disponible, /ultrareview en est un alias. La documentation officielle cite trois avantages par rapport à un /code-review local :

• Un meilleur signal : chaque signalement est reproduit et vérifié de façon indépendante, si bien que les résultats portent sur de vrais bugs plutôt que sur des suggestions de style.
• Une couverture plus large : davantage d'agents explorent la modification en parallèle, ce qui fait remonter des problèmes qu'une revue locale peut manquer.
• Aucune ressource locale : elle tourne dans le cloud, vous pouvez donc continuer à travailler dans votre terminal pendant ce temps.

Tarifs et exécutions gratuites

ultra est facturée sur les crédits d'usage (usage supplémentaire), et non sur l'usage inclus dans votre forfait.

• Exécutions gratuites : les trois exécutions de Pro et Max sont une dotation unique par compte et ne se renouvellent pas.
• Coût par exécution : une fois les exécutions gratuites épuisées, comptez en général 5 à 25 $ en crédits d'usage, selon la taille de la modification. La boîte de dialogue de lancement affiche une estimation avant chaque exécution.
• Décompte des exécutions : une exécution est comptée dès que la session cloud démarre. Un arrêt en cours de route ou un échec consomme quand même une exécution gratuite. Les revues payantes sont facturées selon ce qui a réellement tourné.
• Prérequis : les revues payantes ne se lancent pas si les crédits d'usage ne sont pas activés. Vous pouvez le vérifier avec /usage-credits. La confirmation de facturation sur les crédits d'usage s'affiche une fois par conversation.

Que « 5 à 25 $ » soit cher ou bon marché dépend de ce à quoi on compare. Par rapport à /code-review de low à max, qui reste dans les limites de votre forfait sans facturation séparée, ultra est une dépense en plus. Par rapport à la version application GitHub de Code Review décrite plus bas (15 à 25 $ en moyenne par revue), en revanche, les fourchettes de prix se recoupent. Mais Code Review est un système différent, qui tourne automatiquement sur chaque PR, et les chiffres ne sont pas exprimés de la même façon (« moyenne » d'un côté, « fourchette habituelle » de l'autre) : on ne peut donc pas les comparer directement.

Durée, périmètre et cas où elle n'est pas disponible

• Durée : en général 5 à 10 minutes. Elle tourne en arrière-plan ; vous pouvez la suivre ou l'arrêter avec /tasks. L'arrêter ne renvoie aucun résultat partiel.
• Périmètre : sans argument, elle relit votre branche actuelle par rapport à la branche par défaut du dépôt, plus les modifications non commitées et indexées. C'est une base différente du « en avance sur l'upstream » du /code-review local. Passez un nom de branche, comme dans /code-review ultra develop, pour changer de base.
• Relire une PR : passez un numéro, comme dans /code-review ultra 1234, et rien n'est envoyé depuis votre machine ; le cloud clone directement la PR. Cela fonctionne avec github.com et avec un GitHub Enterprise Server connecté.
• Limites : une revue de branche couvre par défaut jusqu'à 500 fichiers modifiés et 8 000 lignes modifiées (la documentation précise que ces valeurs peuvent changer).
• Cas où elle n'est pas disponible : elle exige une connexion avec un compte claude.ai et n'est pas disponible via Amazon Bedrock, l'Agent Platform de Google Cloud ou Microsoft Foundry, ni pour les organisations en Zero Data Retention. Dans ce cas, /code-review ultra s'exécute comme une revue locale.

Une revue de branche empaquette l'état de votre dépôt local et l'envoie dans le cloud. Les modifications non commitées de fichiers aux noms évoquant des identifiants, comme .env et *.tfvars, suivent les mêmes règles que l'envoi vers une session cloud. Le fonctionnement général des sessions cloud est expliqué dans notre article sur les sessions cloud.

Publier les résultats sur la PR (--post) et lancer depuis un script

Quand vous relisez une PR github.com avec ultra, vous pouvez publier les résultats sur la PR sous la forme d'un seul commentaire, depuis votre propre compte GitHub (v2.1.227 ou ultérieure). Il s'agit d'un commentaire ordinaire, ni une revue ni une approbation, et par défaut rien n'est publié (--no-post). /code-review ultra 1234 --post présélectionne la publication dans la boîte de dialogue de lancement, mais la confirmation s'affiche quand même avant le démarrage. La publication commence à la fin de la revue : il faut donc garder la session ouverte jusqu'au bout.

Pour la CI ou les scripts, utilisez la sous-commande claude ultrareview. Elle attend les résultats et les écrit sur stdout (avec --json, --timeout (45 minutes par défaut) et --post disponibles). claude -p '/code-review ultra' se contente de lancer la revue et se termine sans attendre : vous n'obtenez pas les résultats, et quand la facturation sur les crédits d'usage est requise, la revue ne se lance même pas.

# Relire la PR 1234 avec ultra depuis un script et récupérer les résultats
claude ultrareview 1234

# Utiliser une autre base que la branche par défaut
claude ultrareview origin/main

6. En quoi elle diffère des fonctions voisines

Claude Code propose plusieurs fonctions de revue aux noms proches. La fonction de l'application GitHub appelée « Code Review » prête particulièrement à confusion, car elle est documentée sur la même page que la commande /code-review.

• /simplify : quatre agents vérifient en parallèle la réutilisation des fonctions existantes, la simplification, l'efficacité et le bon niveau d'abstraction de la modification, puis appliquent les corrections. Elle ne cherche pas les bugs de correction. La page Code Review conseille d'ailleurs, si vous aviez scripté /simplify pour trouver des bugs, de passer à /code-review --fix.
• /security-review : examine le diff entre votre branche actuelle et la branche par défaut d'origin à la recherche de vulnérabilités comme les injections, les problèmes d'authentification et l'exposition de données. Elle nécessite un remote origin.
• Code Review (application GitHub) : une fois activée par un Owner de l'organisation, plusieurs agents sur l'infrastructure d'Anthropic examinent une PR à son ouverture, à chaque push ou quand quelqu'un écrit @claude review, et laissent des commentaires ligne par ligne. C'est un aperçu de recherche réservé à Team et Enterprise (indisponible pour les organisations en Zero Data Retention). Le prix varie selon les tokens, 15 à 25 $ en moyenne par revue, pour 20 minutes en moyenne, et il est facturé sur les crédits d'usage, en dehors des limites du forfait. Vous pouvez ajuster ce qu'elle signale avec REVIEW.md.
• claude-code-action : fait tourner Claude Code dans les workflows GitHub Actions de votre propre dépôt. L'exemple de revue de la documentation officielle appelle la version plugin de la skill code-review (/code-review:code-review --comment) pour commenter la PR. Le coût correspond aux tarifs de l'API Claude (ou aux tokens de l'abonnement) plus le temps d'exécution de GitHub Actions.

Les classer selon « où ça tourne, qui paie et ce que ça regarde » clarifie les choses. Pour vérifier votre propre diff en local, /code-review ; pour une relecture approfondie avant le merge, ultra ; pour une exécution automatique sur chaque PR de l'équipe, Code Review de l'application GitHub ou claude-code-action.

7. Quand Claude la lance de lui-même, et comment l'en empêcher

Claude peut lancer /code-review de lui-même. Si vous lui demandez en langage courant de relire vos modifications, il peut exécuter la skill sans que vous tapiez la commande, et une tâche planifiée dont le prompt est /code-review lance aussi une revue. Une tâche planifiée ne lance toutefois jamais ultra (la revue dans le cloud) : ultra ne tourne que si vous tapez vous-même /code-review ultra.

Pour empêcher à la fois Claude et les tâches planifiées de la lancer, tout en la gardant disponible quand vous la tapez vous-même, ajoutez ceci à un fichier de paramètres comme ~/.claude/settings.json :

{
  "skillOverrides": {
    "code-review": "user-invocable-only"
  }
}

Les revues en arrière-plan tournent comme des sous-agents. La façon dont les sous-agents gèrent le contexte et les modèles est expliquée dans notre article sur les sous-agents et les équipes d'agents.

8. Quoi utiliser, et quand

Le tableau comparatif de la documentation officielle indique que le /code-review local convient le mieux pour obtenir un retour rapide pendant qu'on itère, et ultra pour être confiant avant de merger des modifications substantielles. Transposé à un flux de travail quotidien, cela donne :

Comme les 3 exécutions gratuites d'ultra ne se renouvellent pas, mieux vaut les garder pour les modifications à large rayon d'impact, ou celles sur lesquelles la revue locale n'a pas tranché, plutôt que pour de petites corrections. De même, utilisez /security-review pour vous concentrer sur les vulnérabilités et /simplify pour améliorer la lisibilité plutôt que chercher des bugs : c'est cette répartition par objectif que décrit la documentation.

9. Je l'ai essayée sur le code de ce site

Le 2 octobre 2026, j'ai lancé /code-review high sur le code de l'outil de détection d'images IA publié sur ce site. L'outil lit les métadonnées et la provenance (C2PA) d'une image entièrement dans le navigateur, et la cible comptait quatre fichiers : la logique de l'interface, la logique d'analyse (un Web Worker), le contrôleur et le template de la page. Je l'ai exécutée dans l'application de bureau de Claude Code (Claude Code 2.1.284 intégré, modèle Opus 5.5), juste après avoir moi-même cherché des bugs et en avoir corrigé cinq.

Chaque signalement indiquait « quel fichier, quelle ligne » et « quelle entrée provoque quoi ». J'ai vérifié chacun d'eux dans le code source de la bibliothèque que l'outil utilise pour lire les métadonnées des images (exifr) et avec des images de test que j'ai réellement fabriquées, puis j'ai corrigé les 9 qui se sont révélés réels. Les principaux :

Autrement dit, même juste après avoir cherché et corrigé moi-même, 9 bugs d'un autre type étaient encore là. Les signalements portant sur des hypothèses (« la bibliothèque devrait se comporter ainsi »), en particulier, étaient difficiles à repérer sans lire le code source de la bibliothèque. Cela dit, il s'agit du résultat d'une seule exécution sur une seule base de code. Elle ne trouvera pas forcément de vrais bugs dans la même proportion à chaque fois, et je ne l'ai comparée ni à low, ni à medium, ni à max, pas plus que je n'ai essayé ultra, qui est payante.

10. Inconvénients et points d'attention

À l'usage et à la lecture de la documentation officielle, voici cinq points à surveiller :

• Elle consomme vos limites. Les revues locales sont elles aussi décomptées de votre usage normal de Claude, et les niveaux élevés consomment davantage. Avec ultra, une fois les 3 exécutions gratuites épuisées sur Pro et Max (dès le départ sur Team et Enterprise), vous payez environ 5 à 25 $ par exécution en crédits d'usage.
• Ne prenez pas les signalements pour argent comptant. La documentation elle-même indique qu'à partir de high, des signalements moins sûrs peuvent apparaître. Cette fois, 9 sur 10 étaient réels, mais vérifier chacun d'eux demande quand même du travail.
• --fix ne s'annule pas avec /rewind. Les modifications faites en arrière-plan doivent être annulées avec git : commitez avant de l'utiliser.
• Elle ne vérifie que la correction du code. Elle ne contrôle pas si le contenu d'un texte ou d'une configuration correspond aux faits. Par exemple, un problème fréquent sur ce site, « l'article dit autre chose que la spécification officielle », sort de son périmètre.
• Claude peut la lancer de lui-même. Si vous ne le souhaitez pas, le paramètre de la section 7 la limite aux lancements manuels.

Mon avis : la lancer une fois en high après avoir écrit du nouveau code ou fait une grosse modification, c'est l'usage qui justifiait l'effort et la consommation. En revanche, elle ne convient pas aux retouches de texte ni aux petits changements de configuration.

Conclusion

/code-review est une skill intégrée qui relit votre diff local ou une PR en se concentrant sur les bugs de correction. Elle tourne en arrière-plan sans interrompre votre travail, et son coût reste dans votre usage normal. En low ou medium, vous n'obtenez que les signalements les plus sûrs ; de high à max, le filet est plus large mais il faut trier les résultats ; et si vous omettez le niveau, elle reprend le dernier que vous avez tapé.

--fix, qui va jusqu'à la correction, est pratique, mais les modifications faites en arrière-plan ne s'annulent pas avec /rewind : commiter d'abord est le réflexe prudent. Pour aller plus loin, ultra passe environ 5 à 10 minutes dans le cloud et ne renvoie que des signalements vérifiés ; Pro et Max ont droit à 3 exécutions gratuites uniques, après quoi il en coûte environ 5 à 25 $ par exécution en crédits d'usage. Code Review de l'application GitHub et claude-code-action, aux noms proches, sont des choses différentes, tant par l'endroit où elles tournent que par leur coût.

Lancée une fois sur le code de ce site, elle a fait 10 signalements, dont 9 vrais bugs, alors que je venais moi-même de corriger des choses. Il faut vérifier chaque signalement, mais elle vaut largement d'être lancée une fois après du nouveau code ou une grosse modification.

FAQ

Q. Quelle est la différence entre /review et /code-review ?

R. Aujourd'hui, il n'y en a pas. /review est un alias de /code-review et accepte les mêmes niveaux et options. D'après la documentation officielle, avant la v2.1.223, /review était une commande distincte, en lecture seule, qui relisait une PR GitHub en une seule passe.

Q. Utiliser /code-review coûte-t-il un supplément ?

R. Pas de low à max. Dans le tableau comparatif de la documentation officielle, son coût est décompté de l'usage normal. Celle qui coûte en plus, c'est ultra : après les 3 exécutions gratuites sur Pro et Max, comptez environ 5 à 25 $ par exécution en crédits d'usage.

Q. Les 3 exécutions gratuites d'ultra se renouvellent-elles chaque mois ?

R. Non. La documentation officielle décrit les trois exécutions de Pro et Max comme une dotation unique par compte, qui ne se renouvelle pas. Les revues arrêtées en cours de route ou qui échouent comptent quand même pour une exécution. Team et Enterprise n'ont aucune exécution gratuite.

Q. Peut-on annuler les modifications faites par --fix ?

R. Avec git. Les modifications d'une revue qui a tourné en arrière-plan ont lieu en dehors de vos points de contrôle, donc /rewind ne les annule pas. Si la revue a tourné au premier plan (revue précédente encore en cours, -p, etc.), /rewind peut les restaurer. Dans le doute, commitez avant d'utiliser --fix.

Q. Les règles de REVIEW.md s'appliquent-elles à /code-review ?

R. Non. Le /code-review local suit CLAUDE.md mais ne lit pas REVIEW.md. REVIEW.md est le fichier d'instructions de la version application GitHub de Code Review. Placez dans CLAUDE.md les règles que la revue locale doit suivre.

Sources

• Documentation officielle de Claude Code : Code Review (y compris la section « Review a diff locally »)
• Documentation officielle de Claude Code : Find bugs with ultrareview
• Documentation officielle de Claude Code : Commands
• Documentation officielle de Claude Code : Claude Code GitHub Actions
• Claude Code : CHANGELOG

Toutes les sources ont été vérifiées dans leur texte original le 2 octobre 2026. La documentation officielle indique qu'ultrareview est un aperçu de recherche et que ses fonctions, ses tarifs et sa disponibilité peuvent changer.