La revue de code

Un code écrit par Claude se relit comme n’importe quel code. La bonne nouvelle, c’est que Claude Code sait aussi relire, et qu’il peut le faire avec un regard neuf : un relecteur qui n’a pas vu la conversation n’est pas influencé par le raisonnement qui a produit le code. Cette leçon présente la commande /code-review, la relecture par rapport à une spécification et les options pour automatiser la revue des pull requests.

La commande /code-review

/code-review (alias : /review) se tape à l’invite de la session où vous travaillez. Sans argument, Claude relit les modifications de votre branche courante, y compris celles qui ne sont pas encore commitées, cherche les bugs de correction et rapporte ce qu’il a trouvé dans la conversation. Selon le modèle et le niveau d’effort, la revue couvre aussi la réutilisation de code existant, la simplification et l’efficacité. La commande fonctionne sur toutes les offres et compte dans votre consommation comme le reste de la session.

En terminal, la revue tourne comme un sous-agent en arrière-plan, avec sa propre fenêtre de contexte : vous continuez à travailler, et les résultats arrivent dans la conversation quand elle se termine. Vous demandez ensuite à Claude de corriger ce qui a été trouvé.

Choisir ce qu’on relit

Tapez une cible après la commande :

Trois options changent ce que fait la revue :

• --fix demande aussi à Claude d’appliquer les corrections dans vos fichiers, en passant par votre mode de permission ;
• --comment publie les remarques en commentaires sur la pull request GitHub (ou en une note sur une merge request GitLab) ;
• un niveau d’effort arbitre entre couverture et confiance : à low, la revue ne rapporte que les problèmes dont elle est le plus sûre, donc moins de faux positifs ; de medium à max, elle élargit sa couverture. Sans niveau précisé, elle reprend le dernier que vous avez tapé.

Une précaution avec --fix en arrière-plan : ses modifications échappent aux points de contrôle de votre session, donc /rewind ne les annule pas. Servez-vous de git pour revenir en arrière.

Relire par rapport à une spécification

/code-review cherche des bugs en général. Si vous voulez vérifier que le travail correspond à votre plan, écrivez la demande vous-même. Les bonnes pratiques officielles donnent ce modèle :

use a subagent to review the rate limiter diff against SPEC.md, check every requirement is implemented and the listed edge cases have tests, report gaps that affect correctness and skip style

Ne supprimez pas la fin, « skip style ». Un relecteur à qui l’on demande de trouver des problèmes en trouvera toujours. Si vous corrigez chaque remarque, vous finissez avec des couches d’abstraction inutiles et des tests pour des cas impossibles.

Exiger des preuves

Quelle que soit la façon de vérifier, demandez des preuves : la commande que Claude a lancée et sa sortie, ou une capture d’écran. « Tous les tests passent », seul, ne dit pas grand-chose, et lire la sortie est plus rapide que relancer la vérification vous-même. Quand Claude annonce qu’il a fini, la commande /verify lui fait construire et lancer l’application et regarder le résultat : elle attrape ce que les tests et le typage laissent passer.

Les règles de l’équipe

/code-review est une skill intégrée à Claude Code : il n’y a pas de fichier à modifier. Pour que chaque revue applique les règles de votre projet, écrivez-les dans CLAUDE.md. Une skill de projet nommée code-review remplace même la commande intégrée, si votre équipe veut sa propre procédure.

Aller plus loin

• Ultrareview : /code-review ultra lance une revue plus approfondie dans le cloud, qui compare votre branche à la branche par défaut du dépôt. C’est vous qui la déclenchez.
• La revue automatique des pull requests : le service Code Review de Claude Code relit chaque pull request d’un dépôt GitHub ; un propriétaire de l’organisation l’active.
• GitHub Actions et GitLab CI/CD permettent d’automatiser la revue et le tri des tickets dans votre intégration continue.

À vous de jouer

Une revue à deux niveaux. Sur une branche avec des modifications, lancez /code-review low, puis /code-review high sur le même code. Comparez le nombre de remarques et leur fiabilité. Demandez enfin à Claude de corriger les deux remarques les plus importantes, et vérifiez le résultat avec vos tests.

Sources officielles : Code review (Claude Academy) · Review locally with /code-review · Best practices · Overview

Points clés à retenir

• /code-review relit la branche courante dans un sous-agent qui n’a pas vu votre conversation, et rapporte les bugs de correction
• Une cible (plage de commits, branche, PR) et des options : --fix pour corriger, --comment pour publier sur la PR, un effort low pour moins de faux positifs
• Pour vérifier un travail contre votre plan, demandez une revue par rapport à SPEC.md en précisant « skip style »
• Exigez la commande et sa sortie comme preuve ; /verify lance l’application pour de vrai