Que fait la commande /security-review de Claude Code ?
La commande /security-review de Claude Code lance une passe unique d’analyse de sécurité sur les changements en attente de ta branche (le diff), pas sur tout le dépôt. Elle cherche injections SQL, failles XSS, défauts d’authentification, gestion non sûre des données et dépendances vulnérables, puis explique chaque problème.
Ce guide s’adresse à celles et ceux qui font écrire leur site ou leur application par Claude Code sans être développeurs. Tu y trouveras comment lancer la commande, lire son rapport, et la routine à répéter avant chaque mise en ligne. Tu y verras aussi ce qu’elle ne remplace pas.
Un diff désigne l’ensemble des lignes ajoutées, modifiées ou supprimées depuis le dernier point de sauvegarde du code. C’est ce périmètre, et lui seul, que la commande examine source : Anthropic, 2026.
Prérequis
- Claude Code installé et à jour. Si tu pars de zéro, commence par le guide du premier projet.
- Un projet suivi par Git, pour que les changements en attente existent et soient lisibles.
- Un accès à l’environnement de test : un site ou une appli que tu peux ouvrir sans toucher aux vraies données.
- Deux comptes de test, un « Alice » et un « Bob », pour l’étape 5.
Étape 1 : ouvre Claude Code dans le dossier du projet
Ouvre ton terminal, place-toi dans le dossier du projet, puis lance Claude Code. C’est la marche à suivre indiquée par l’aide officielle d’Anthropic : ouvrir l’outil dans le dossier, lancer la commande, lire les explications source : Claude Help Center, 2026.
cd mon-projet
claude
La fonction est disponible pour tous les utilisateurs : il suffit de mettre l’outil à jour source : Anthropic, 2026. Si /security-review n’apparaît pas, c’est la première chose à vérifier.
Étape 2 : lance /security-review avant chaque mise en ligne
Tape la commande dans la session :
/security-review
Lance-la quand Claude a fini une série de modifications, avant de publier. Pas pendant qu’il écrit, pas une fois pour toutes en début de projet : le diff change à chaque session, donc la revue aussi.
Ne la confonds pas avec ses voisines. Le tableau ci-dessous reprend la distinction faite par la documentation.
| Outil | Ce qu’il fait | Quand l’utiliser |
|---|---|---|
| Plugin « security guidance » | Relit le code pendant que Claude l’écrit | En continu |
| /security-review | Une seule passe de sécurité sur la branche | Avant chaque mise en ligne |
| /code-review | Cherche des bugs de correction sur le diff | Pour la qualité générale, pas la sécurité |
| Code Review | Relit les pull requests | Si tu travailles avec une équipe |
Étape 3 : lis le rapport et traite d’abord accès et données personnelles
Pour chaque problème, Claude fournit une explication détaillée. Je ne reproduis pas d’exemple de rapport ici : sa mise en forme peut varier d’une version à l’autre, et un faux exemple te donnerait de mauvais repères.
Trie les constats dans cet ordre :
- Accès : authentification, droits, pages ou routes accessibles sans connexion. Le contrôle d’accès regroupe les règles qui décident qui a le droit de voir ou de modifier quoi.
- Données personnelles : e-mails, téléphones, adresses, paiements exposés ou stockés sans protection. C’est aussi le terrain du RGPD, sujet traité dans RGPD et site IA-généré.
- Le reste : dépendances vulnérables, failles XSS (cross-site scripting, c’est-à-dire du code malveillant injecté dans une page vue par d’autres visiteurs) et injection SQL, qui consiste à glisser des commandes de base de données dans un champ de formulaire.
Un secret trouvé dans le code (clé API, mot de passe) passe avant tout : suis alors la marche à suivre pour une clé exposée.
Si une explication reste obscure, demande à Claude de la reformuler sans jargon et de décrire ce qu’un attaquant ferait concrètement. Tu juges ainsi la gravité réelle.
Étape 4 : fais corriger, puis demande une seconde passe
Tu peux demander à Claude d’appliquer les correctifs directement source : Claude Help Center, 2026. Relis ce qu’il change avant d’accepter : tu restes responsable du code que tu valides, et l’avertissement officiel va dans ce sens (voir plus bas).
Relance ensuite la commande. La documentation parle d’une passe unique (« single pass »), donc rien ne garantit qu’un correctif n’en a pas introduit un autre, ni que tous les problèmes sont sortis du premier coup source : Anthropic, 2026. Répète jusqu’à ce que la revue ne signale plus rien d’important.
Étape 5 : fais ce que la commande ne fait pas
La documentation est explicite : ces revues automatisées complètent les pratiques de sécurité et les relectures manuelles existantes, sans les remplacer source : Claude Help Center, 2026. Trois contrôles restent à ta charge.
Le test à deux comptes
Connecte-toi en Alice, crée une donnée (une commande, un document, un profil), et copie son adresse. Connecte-toi ensuite en Bob et ouvre cette adresse. Si Bob voit les données d’Alice, tu as une faille d’accès, même si la revue n’a rien signalé. Pour les bases Supabase, la protection se joue dans les règles RLS.
La lecture des réponses du serveur
Ouvre les outils de développement du navigateur, onglet Réseau, et regarde ce que le serveur renvoie réellement. Une réponse qui contient plus que ce que l’écran affiche (e-mails d’autres utilisateurs, champs internes) est un signal d’alerte. Claude peut aussi tester le site dans Chrome, mais regarde toi-même les cas sensibles.
Un regard humain sur ce qui est grave
Pour un paiement, un espace client ou des données de santé, fais relire le projet par un développeur. L’IA t’aide à repérer, elle ne porte pas la responsabilité du résultat. L’article sur les risques de sécurité du vibe coding montre ce que coûte une revue sautée.
Pièges courants
- Croire qu’un rapport vide veut dire « sécurisé ». Le prompt de la commande demande de ne signaler que les vulnérabilités à forte confiance, avec plus de 80 % de certitude d’exploitabilité source : Anthropic, 2026. Peu de fausses alertes, mais des vraies peuvent être écartées par conception.
- Oublier que seul le diff est examiné. Une faille présente avant tes dernières modifications n’est pas forcément vue. Pour scanner tout le dépôt, la documentation présente le plugin claude-security, installé avec
/plugin install claude-security@claude-plugins-official, qui ajoute la commande /claude-security source : Anthropic, 2026. - Ignorer les catégories exclues. Le prompt écarte par exemple la validation d’entrées sur des champs non critiques sans impact prouvé. Le prompt est personnalisable : copie
security-review.mddans.claude/commands/pour l’adapter, par exemple en ajoutant tes règles métier. Le fichier CLAUDE.md aide aussi à fixer tes exigences. - Utiliser l’Action GitHub sur n’importe quelle PR. Le dépôt officiel précise qu’elle n’est pas durcie contre l’injection de prompt et ne doit servir que sur des pull requests de confiance.
- Lancer la revue une seule fois, en fin de projet. Une revue avant chaque mise en ligne coûte quelques minutes. Les erreurs courantes avec Claude Code ou Codex montrent où se glissent les oublis.
Pour Codex, nous n’affirmons rien : nous n’avons pas de confirmation dans la documentation officielle d’OpenAI d’une commande équivalente. Vérifie-la directement chez l’éditeur, en partant de notre guide de démarrage.
FAQ
/security-review analyse-t-elle tout mon site ?
Non. Elle porte sur les changements en attente (le diff), pas sur l’ensemble du dépôt. Pour un scan complet, la documentation propose le plugin claude-security.
Quelle est la différence avec /code-review ?
/code-review cherche des bugs de correction sur le diff courant. /security-review est distincte : elle se concentre sur les vulnérabilités de sécurité.
Puis-je me passer d'un développeur après une revue propre ?
Pas pour les sujets graves. La documentation précise que ces revues complètent les relectures manuelles sans les remplacer. Pour des paiements ou des données sensibles, fais relire par un humain.
Avant ta prochaine mise en ligne : lance /security-review, corrige d’abord les accès et les données personnelles, relance une seconde passe, puis fais le test Alice et Bob.
Contactez Peechy et vous n'aurez pas ce bug
Vous construisez un site ou une application avec l'IA ? On relit le code, on teste ce qui ne se voit pas à l'écran, accès, données, options de confidentialité, et on corrige avant la mise en ligne.
Contacter Peechy


