Note de l'auteur : voici 25 invites de revue de code pour Claude Code, testées sur le terrain. Elles couvrent 7 scénarios majeurs, dont la revue de sécurité, l'analyse de performance, l'examen d'architecture, la détection de bugs et la revue de PR, avec une formule dédiée pour rédiger vos propres invites.
Claude Code intègre nativement la commande /security-review et un système multi-agents pour la revue de code, mais les résultats par défaut sont souvent trop verbeux et s'attardent sur des détails inutiles. Une bonne invite de revue doit être aussi précise qu'un cas de test : définissez le périmètre, fixez les priorités et exigez des numéros de ligne ainsi que des suggestions de correction. Cet article compile 25 invites de revue de code couvrant 7 scénarios, de la sécurité à l'architecture, prêtes à être copiées-collées.
Valeur ajoutée : 25 invites couvrant les scénarios les plus fréquents, accompagnées d'une formule de rédaction et d'exemples comparatifs.
Formule de rédaction d'invites pour les revues de code
Une bonne invite de revue est aussi précise qu'un cas de test. Une mauvaise invite ressemble à un message Slack vague.
Formule en cinq points
[Rôle] En tant qu'ingénieur senior en {langage/domaine}
[Portée] Examinez {fichier/répertoire/PR} concernant {contenu des modifications}
[Focus] Concentrez-vous sur {sécurité/performance/logique/architecture}
[Format] Format de sortie : {liste numérotée/tableau/commentaires en ligne}
[Niveau] Indiquez le niveau de gravité : {Critical/High/Medium/Low}
| Élément | Mauvais exemple | Bon exemple |
|---|---|---|
| Rôle | (Non défini) | "En tant qu'ingénieur backend senior" |
| Portée | "Jette un œil à ce code" | "Examinez le git diff récent de src/auth/" |
| Focus | "Donne-moi un retour" | "Concentrez-vous sur les injections SQL et le contournement d'authentification" |
| Format | (Sortie libre) | "Liste numérotée, chaque point incluant : fichier:ligne, description du problème, suggestion de correction" |
| Niveau | (Non requis) | "Indiquez le niveau de gravité : Critical/High/Medium/Low" |
Scénario 1 : Revue de sécurité (4 invites)
La revue de sécurité est la priorité absolue lors d'une revue de code. Claude Code propose la commande /security-review, mais des invites personnalisées permettent d'aller beaucoup plus loin.
Invite n°1 : Analyse complète OWASP Top 10
En tant qu'ingénieur en audit de sécurité, examinez tous les fichiers récemment modifiés dans le répertoire src/.
Vérifiez point par point selon l'OWASP Top 10 :
1. Injection (SQL/NoSQL/commande)
2. Défauts d'authentification
3. Exposition de données sensibles
4. XXE
5. Défauts de contrôle d'accès
6. Erreurs de configuration de sécurité
7. XSS
8. Désérialisation
9. Utilisation de composants vulnérables
10. Journalisation et surveillance insuffisantes
Format de sortie : liste numérotée, chaque point incluant [fichier:ligne] [niveau de gravité] [description du problème] [suggestion de correction].
Ne signalez que les problèmes réels, pas les risques théoriques.
Invite n°2 : Revue de sécurité des points de terminaison API
Examinez tous les fichiers de routage API (routes/, controllers/), en vous concentrant sur :
- Les points de terminaison sans middleware d'authentification
- La validation et l'assainissement des entrées
- Les risques d'assignation de masse (mass assignment)
- La configuration de la limitation de débit (rate limiting)
- Les réponses d'erreur divulguant des informations internes
Format de sortie : tableau avec : Chemin du point de terminaison | Problème | Niveau de gravité | Solution de correction
Invite n°3 : Détection de fuite d'informations sensibles
Scannez l'ensemble du projet pour vérifier si les informations sensibles suivantes sont codées en dur ou exposées accidentellement :
- Clés API, secrets, jetons (tokens)
- Chaînes de connexion à la base de données
- Clés privées et certificats
- Adresses IP internes et noms de domaine
- Mots de passe ou identifiants dans les commentaires
La portée inclut : code source, fichiers de configuration, .env.example, docker-compose.yml, README.
Indiquez le chemin du fichier et le numéro de ligne pour chaque découverte.
Invite n°4 : Revue de la logique d'authentification et d'autorisation
En tant qu'expert en sécurité, examinez le code lié à l'authentification et à l'autorisation :
1. La logique de vérification des jetons JWT est-elle complète (expiration, signature, altération) ?
2. Le stockage des mots de passe utilise-t-il un hachage sécurisé (bcrypt/argon2) ?
3. La gestion des sessions présente-t-elle un risque d'attaque par fixation de session ?
4. La configuration CORS est-elle trop permissive ?
5. Le rappel OAuth vérifie-t-il le paramètre state ?
Ne rapportez que les problèmes de niveau Critical et High, avec un exemple de code de correction.
Scénario 2 : Détection de bugs (4 invites)
Invite n°5 : Pointeurs nuls et conditions aux limites
Examinez les fichiers récemment modifiés pour détecter les bugs potentiels suivants :
- Accès à des propriétés sans vérification préalable de null/undefined
- Accès hors limites (out-of-bounds) dans les tableaux
- Erreurs de division par zéro
- Chaînes de caractères vides non traitées
- Valeurs NaN non gérées lors de l'utilisation de parseInt/parseFloat
Pour chaque découverte, indiquez les conditions de déclenchement (quelle entrée provoque le plantage) et proposez le code correctif.
Invite n°6 : Problèmes d'asynchronisme et de concurrence
Examinez tout le code asynchrone du projet (async/await, Promise, callbacks) et vérifiez :
- L'absence de gestion d'erreurs via .catch() sur les promesses
- La présence de conditions de concurrence (race conditions)
- L'utilisation d'await dans des boucles provoquant une exécution séquentielle (à remplacer par Promise.all)
- La présence de "callback hell" pouvant être refactorisé
- La gestion correcte des rollbacks dans les transactions
Présentez le résultat sous la forme : [Fichier:Numéro de ligne] [Problème] [Impact] [Solution]
Invite n°7 : Chasse aux erreurs logiques
Lisez attentivement la logique métier des fonctions suivantes et recherchez :
- Si les branches if/else couvrent tous les cas possibles
- Si les conditions d'arrêt des boucles sont correctes
- Si les opérateurs de comparaison sont appropriés (== vs ===, > vs >=)
- Si la portée des variables est correcte
- Si les valeurs de retour sont définies pour tous les chemins d'exécution
Ne vous souciez pas du style de code, concentrez-vous uniquement sur la correction logique.
Invite n°8 : Examen de la gestion des erreurs
Examinez les mécanismes de gestion des erreurs du projet :
1. Les blocs try/catch capturent-ils des exceptions spécifiques plutôt que des erreurs génériques ?
2. Les blocs catch se contentent-ils d'ignorer l'erreur (catch vide) ?
3. Les erreurs sont-elles correctement propagées vers le haut ?
4. Les messages d'erreur destinés à l'utilisateur sont-ils conviviaux (sans exposer d'informations internes) ?
5. Les opérations critiques (paiements, modifications de données) disposent-elles de mécanismes de rollback en cas d'échec ?
Classez les résultats par ordre de gravité.
Scénario 3 : Analyse de performance (3 invites)
Invite n°9 : Performance des requêtes de base de données
Examinez tout le code effectuant des requêtes en base de données (models/, repositories/, appels ORM) et vérifiez :
- Les problèmes de requêtes N+1 (requêtes exécutées dans une boucle)
- Les champs de recherche manquants d'index
- Si les SELECT * devraient être remplacés par des champs spécifiques
- Si la pagination est utilisée pour les gros volumes de données
- S'il existe des requêtes répétitives pouvant être optimisées par du cache
Pour chaque problème, estimez l'impact sur la performance (faible/moyen/élevé) et proposez le code optimisé.
Invite n°10 : Fuites de mémoire et de ressources
Examinez les fuites de mémoire et de ressources potentielles dans le projet :
- Les écouteurs d'événements sont-ils supprimés lors du démontage des composants ?
- Les minuteurs (setInterval/setTimeout) sont-ils correctement nettoyés ?
- Les connexions à la base de données sont-elles fermées correctement ?
- Les descripteurs de fichiers sont-ils libérés dans un bloc finally ?
- Les grands tableaux/objets sont-ils déréférencés après usage ?
Portez une attention particulière au nettoyage des useEffect dans React et au traitement des flux (streams) dans Node.js.
Invite n°11 : Examen de la complexité algorithmique
Examinez les fonctions récemment modifiées et analysez leur complexité temporelle et spatiale :
- Existe-t-il des implémentations en O(n²) ou plus qui pourraient être optimisées ?
- Peut-on remplacer une recherche linéaire par une table de hachage ?
- Y a-t-il des copies profondes (deep copies) inutiles ?
- La concaténation de chaînes devrait-elle utiliser StringBuilder/join ?
- L'algorithme de tri utilisé est-il le plus approprié ?
Indiquez : Complexité actuelle → Complexité optimisable → Solution d'optimisation spécifique.
Scénario 4 : Revue d'architecture (4 invites)
Invite #12 : Analyse des dépendances et du couplage
Analyse les dépendances des modules dans src/ :
1. Dessine le graphe de dépendances entre les modules (quel module importe quel module)
2. Identifie les dépendances circulaires
3. Identifie les modules ayant le couplage le plus élevé (les plus dépendus par les autres)
4. Suggère quels dépendances devraient être découplées via des interfaces ou des abstractions
Sortie : Tableau des relations de dépendance + liste des dépendances circulaires + suggestions de découplage
Invite #13 : Vérification de la conformité à l'architecture en couches
Vérifie si le code respecte les principes de l'architecture en couches :
- La couche Controller contient-elle de la logique métier ? (Elle ne devrait gérer que le routage et la validation des paramètres)
- La couche Service manipule-t-elle directement la base de données ? (Elle devrait passer par un Repository)
- La couche Model/Entity contient-elle de la logique liée à HTTP ?
- Y a-t-il des appels inter-couches (ex: Controller appelant directement le Repository) ?
Liste chaque fichier et l'emplacement précis du code qui enfreint ces principes.
Invite #14 : Revue de conception d'API
Examine tous les points de terminaison (endpoints) de l'API selon les meilleures pratiques RESTful :
- Le nommage des URL suit-il les conventions REST (noms au pluriel, relations hiérarchiques) ?
- Les méthodes HTTP sont-elles utilisées correctement (GET pour lecture, POST pour création, PUT pour mise à jour, DELETE pour suppression) ?
- Le format des réponses est-il cohérent (codes d'erreur, format de pagination, format de date) ?
- Le versionnage de l'API est-il en place ?
- Y a-t-il des points de terminaison redondants qui pourraient être fusionnés ?
Sortie : Tableau des suggestions d'amélioration (Actuel → Suggestion → Raison)
Invite #15 : Évaluation de la dette technique
Effectue une évaluation complète de la dette technique du projet :
1. Dépendances et versions de frameworks obsolètes
2. Appels d'API dépréciés
3. Valeurs de configuration codées en dur (devraient utiliser des variables d'environnement)
4. Blocs de code dupliqués (copier-coller)
5. Modules critiques manquant de tests unitaires
6. Fonctions trop complexes (complexité cyclomatique > 15)
Classe par urgence de correction : Bloquant (à corriger immédiatement) > Élevé > Moyen > Faible
Scénario 5 : Revue de PR (4 invites)
Invite #16 : Revue rapide des diffs de PR
Examine le diff entre la branche actuelle et main, et évalue en tant qu'ingénieur senior :
1. Quel est l'objectif de cette PR (déduit du diff) ?
2. Les changements sont-ils complets (y a-t-il des fichiers ou une logique manquants) ?
3. De nouveaux bugs ou régressions ont-ils été introduits ?
4. La couverture de tests est-elle suffisante ?
5. Y a-t-il des changements inutiles (code de débogage, bruit de formatage) ?
Signale uniquement les problèmes de niveau High et Critical. Ne fais pas de micro-gestion sur le style de code.
Invite #17 : Vérification de la rétrocompatibilité
Examine tous les changements de la PR actuelle pour vérifier s'il existe des modifications non rétrocompatibles :
- Les signatures ou valeurs de retour des interfaces API publiques ont-elles changé ?
- Y a-t-il des changements cassants (breaking changes) dans le schéma de base de données ?
- Le format des fichiers de configuration a-t-il changé ?
- Des fonctions utilisées par d'autres modules ont-elles été supprimées ?
- Le nom ou le format des variables d'environnement ont-ils été modifiés ?
Pour chaque incompatibilité, évalue l'impact et propose un plan de migration.
Invite #18 : Revue de la suffisance des tests
Compare les changements de code de la PR actuelle avec les changements de tests :
1. Les nouvelles fonctions ont-elles toutes des tests unitaires correspondants ?
2. La logique modifiée a-t-elle mis à jour les tests existants ?
3. Les conditions aux limites et les chemins d'exception sont-ils couverts par des tests ?
4. Les tests d'intégration couvrent-ils les nouveaux points de terminaison API ?
5. Les données de test sont-elles pertinentes (pas de valeurs arbitraires comme 123 ou abc) ?
Liste les suggestions de cas de tests manquants : Nom de la fonction | Scénario de test manquant | Priorité
Invite #19 : Revue de la qualité des commits
Examine l'historique des commits de la PR actuelle :
1. Le message de commit décrit-il clairement le changement ?
2. Chaque commit est-il atomique (un commit pour un objectif) ?
3. Y a-t-il des commits triviaux qui pourraient être fusionnés (squash) ?
4. Y a-t-il des commits temporaires comme "fix typo" ou "wip" qui devraient être nettoyés ?
5. L'ordre des commits est-il logique (infrastructure d'abord, puis logique métier) ?
Suggère les commits à réorganiser et la structure finale des commits.
Scénario 6 : Lisibilité (3 invites)
Invite #20 : Revue de nommage
Examinez le nommage de toutes les variables, fonctions et classes dans les fichiers récemment modifiés :
- Y a-t-il des noms ambigus (data, info, temp, res, obj) ?
- Y a-t-il des abréviations excessives (usr → user, btn → button) ?
- Les noms de booléens ne commençant pas par is/has/should sont-ils présents ?
- Les noms de fonctions commencent-ils par un verbe décrivant précisément l'action ?
- Les noms de classes commencent-ils par un nom décrivant précisément leur responsabilité ?
Pour chaque mauvais nom, proposez une meilleure alternative.
Invite #21 : Revue de la qualité des commentaires
Examinez la qualité des commentaires dans le code :
- Y a-t-il des commentaires de type "quoi" qui devraient être des commentaires de type "pourquoi" ?
- Y a-t-il des commentaires obsolètes (qui ne correspondent plus au code) ?
- Y a-t-il des commentaires qui devraient être extraits en tant que noms de fonctions ?
- Les logiques métier complexes manquent-elles de commentaires explicatifs ?
- Les API publiques disposent-elles de JSDoc/docstring ?
Ne suggérez pas d'ajouter des commentaires évidents (ex: "// incrémenter le compteur").
Invite #22 : Suggestions de découpage de fonctions
Examinez toutes les fonctions de plus de 30 lignes et évaluez si elles doivent être divisées :
- La fonction a-t-elle plusieurs responsabilités (fait-elle plusieurs choses non liées) ?
- Le niveau d'imbrication dépasse-t-il 3 niveaux ?
- Le nombre de paramètres dépasse-t-il 4 ?
- Y a-t-il une logique répétée qui peut être extraite ?
Proposez un plan de découpage concret : fonction d'origine → liste des fonctions divisées → responsabilité de chaque fonction.
Scénario 7 : Suggestions de refactorisation (3 invites)
Invite #23 : Détection de violation du principe DRY
Scannez le projet à la recherche de code dupliqué :
- Identifiez les blocs de code dupliqués de plus de 3 lignes.
- Identifiez les codes ayant une logique similaire mais une écriture différente.
- Identifiez les modèles communs pouvant être extraits en fonctions utilitaires.
Pour chaque groupe de code dupliqué, fournissez le code d'implémentation pour l'extraction en fonction publique.
Invite #24 : Optimisation des modèles de conception
Examinez le code sous l'angle d'un expert en modèles de conception :
- Les nombreux if/else ou switch devraient-ils utiliser le modèle de stratégie ?
- La création d'objets complexes devrait-elle utiliser le modèle de fabrique (factory) ou de bâtisseur (builder) ?
- Le code répétitif devrait-il utiliser le modèle de méthode de modèle (template method) ?
- Les rappels (callbacks) imbriqués devraient-ils utiliser le modèle de chaîne de responsabilité ?
- La gestion d'état global devrait-elle utiliser le modèle d'observateur ?
Ne suggérez des améliorations que si elles réduisent significativement la complexité ; évitez la sur-ingénierie.
Invite #25 : Modernisation du code hérité
Examinez le code hérité du projet et identifiez les parties pouvant être réécrites avec une syntaxe moderne :
- var → const/let
- Fonctions de rappel → async/await
- Boucles for → map/filter/reduce
- Concaténation de chaînes → littéraux de gabarit (template strings)
- require → import
- Class → Composants fonctionnels + Hooks (React)
Fournissez une comparaison du code avant/après et évaluez le risque de refactorisation (faible/moyen/élevé).
🎯 Conseils d'utilisation : Il est recommandé d'enregistrer vos invites de revue les plus utilisées dans
CLAUDE.mdou.claude/skills/pour uniformiser les standards au sein de l'équipe. Grâce à/loop, vous pouvez automatiser les revues de sécurité et les revues de PR.
Si vous construisez un système de revue automatisé via API, nous vous recommandons d'utiliser APIYI (apiyi.com) pour accéder à Claude Opus 4.6 avec une réduction de 20 %.
FAQ
Q1 : Que faire si la commande par défaut /code-review est trop bavarde ?
Créez un fichier REVIEW.md à la racine de votre projet ou ajoutez des règles de revue dans CLAUDE.md pour indiquer clairement à Claude ce sur quoi il doit se concentrer ou ce qu'il doit ignorer. Par exemple : "Signale uniquement les problèmes de niveau Critique et Élevé. Ne chipote pas sur le style de code ou le nommage. Ne suggère pas d'ajouter des commentaires." Claude Code lira automatiquement ce fichier à chaque revue.
Q2 : Comment enregistrer des invites sous forme de compétences (Skills) réutilisables ?
Enregistrez vos invites de revue de sécurité dans .claude/skills/security-review/SKILL.md et définissez user-invocable: true. Cela l'enregistrera en tant que commande slash /security-review. Vous pourrez ensuite simplement taper /security-review pour l'exécuter, sans avoir à copier-coller à chaque fois. Vous pouvez enregistrer plusieurs invites en tant que compétences distinctes.
Q3 : La revue de PR peut-elle être publiée automatiquement en commentaire sur GitHub ?
Oui. Il existe deux méthodes : 1) Tapez @claude review dans un commentaire de PR, et Claude analysera automatiquement le diff pour publier ses découvertes sous forme de commentaires en ligne ; 2) Utilisez la commande /code-review --comment, et Claude publiera les résultats de la revue en tant que commentaire sur le PR. En mars 2026, Anthropic a lancé un système multi-agents dédié à la revue de code, capable de coordonner un groupe d'agents spécialisés pour examiner les PR sous plusieurs angles : sécurité, logique, tests, etc.
Q4 : Combien de jetons (tokens) consomme une invite de revue ?
Cela dépend de l'étendue de la revue. Une revue de fichier unique consomme environ 2 000 à 5 000 jetons, tandis qu'une analyse de sécurité complète du projet peut en consommer entre 10 000 et 30 000. Il est conseillé de limiter le périmètre de la revue à des fichiers ou répertoires spécifiques pour éviter de gaspiller des jetons en "scannant tous les fichiers". En passant par APIYI (apiyi.com), vous pouvez accéder à Claude Opus 4.6 avec une réduction de 20 %, ce qui réduit considérablement les coûts de revue.
Résumé
Les points clés pour les invites de revue de code avec Claude Code :
- 25 invites couvrant 7 scénarios majeurs : Revue de sécurité (4), détection de bugs (4), analyse de performance (3), revue d'architecture (4), revue de PR (4), lisibilité (3), suggestions de refactorisation (3) — à copier-coller directement.
- La formule en cinq éléments pour une bonne invite : Rôle + Périmètre + Priorités + Format + Niveau de sévérité. Soyez aussi précis qu'avec des cas de test, évitez le flou des messages Slack.
- Système de revue à trois niveaux : Commandes intégrées (
/security-review) → Invites personnalisées (les 25 de cet article) → Automatisation continue via/loop.
Nous vous recommandons d'accéder à l'API de Claude Opus 4.6 via APIYI (apiyi.com) avec une réduction de 20 % pour construire votre système de revue de code automatisé.
📚 Références
-
Documentation officielle de Claude Code Code Review : Explication complète de la fonctionnalité de revue intégrée
- Lien :
code.claude.com/docs/en/code-review - Description : Inclut la revue de PR, les systèmes multi-agents et les méthodes de personnalisation
- Lien :
-
Claude Code Security Review : Solution officielle d'examen de sécurité d'Anthropic
- Lien :
github.com/anthropics/claude-code-security-review - Description : Contient l'implémentation complète de la commande /security-review
- Lien :
-
7 invites pour la revue de PR avec Claude : Invites de revue validées par la communauté
- Lien :
rephrase-it.com/blog/7-claude-pr-review-prompts-for-2026 - Description : Comprend des modèles d'invites structurés pour la revue de PR
- Lien :
-
Centre de documentation APIYI : Accès à l'API Claude Opus 4.6 avec 20 % de réduction
- Lien :
docs.apiyi.com - Description : La solution API optimale pour construire des systèmes de revue automatisés
- Lien :
Auteur : Équipe technique APIYI
Échanges techniques : N'hésitez pas à discuter dans la section commentaires. Pour plus de ressources, visitez le centre de documentation APIYI sur docs.apiyi.com
