Éviter les prompts dangereux dans Claude Code: pas de push auto, pas de tests sautés

Demander à Claude Code “corrige tout, pousse les changements et on fera les tests plus tard” peut sembler efficace. Mais avec un outil capable de modifier des fichiers, d’exécuter des commandes shell, d’utiliser git et de consulter la documentation, cette phrase peut aussi supprimer les garde-fous de revue.

Ce guide ne cherche pas à dramatiser. Il sert à prévenir. J’ai vérifié la documentation officielle de Claude Code le 3 juin 2026, notamment les modes de permissions, /permissions, settings.json et les workflows courants, puis j’ai transformé les formulations risquées en prompts utilisables.

flowchart LR
  A["Écrire la demande"] --> B["Autoriser l'analyse"]
  B --> C["Relire le plan"]
  C --> D["Modifier peu"]
  D --> E["Tester et vérifier le diff"]
  E --> F["Humain décide push/deploy"]

Ce qui rend un prompt dangereux

Dangereux ne veut pas dire malveillant. Ici, cela désigne une demande où le périmètre, l’autorité ou le critère de réussite restent flous alors que Claude Code peut lancer des actions puissantes. Pour débuter simplement: une limite de permission est l’endroit où l’agent doit demander confirmation avant de modifier des fichiers, lancer des commandes ou sortir du projet.

Claude Code peut lire et chercher dans les fichiers, éditer du code, exécuter des tests et utiliser git. La documentation officielle explique qu’en session locale, Claude Code peut travailler avec les fichiers et capacités de terminal disponibles pour l’utilisateur. Un bon prompt doit donc préciser ce qui est autorisé et ce qui est interdit.

Formulation risquée	Remplacement plus sûr
Corrige tout	Nommer les fichiers ciblés et exclus, puis demander un plan
Push quand c’est fini	Résumer diff et tests; je déciderai du push
Saute les tests	Proposer la vérification minimale utile et expliquer si elle ne tourne pas
Vérifie en base de production	Utiliser dev/staging; générer le SQL de production sans l’exécuter
Saute toutes les confirmations	Analyser en Plan mode, puis avancer étape par étape avec approbation
Supprime les vieux fichiers	Lister d’abord les candidats; supprimer seulement après accord
Mets tout à jour vers latest	Séparer correctifs sécurité, minor updates et major updates
Cherche et implémente	Citer les sources officielles et séparer constats et propositions

Limites de permissions dans la documentation actuelle

Le mode de permission de Claude Code ne change pas parce que vous écrivez “fais attention” dans le chat. En CLI, on le change avec Shift+Tab ou --permission-mode; dans les IDE et Desktop, avec le sélecteur; les valeurs persistantes vivent dans settings.json.

Au 3 juin 2026, les modes principaux sont: default, qui demande avant les actions non limitées à la lecture; acceptEdits, qui accepte automatiquement les éditions de fichiers et opérations courantes; plan, adapté à la lecture, l’exploration et la proposition avant modification; auto, une research preview avec contrôles de sécurité en arrière-plan; dontAsk, qui refuse les outils non préapprouvés; et bypassPermissions, à réserver aux conteneurs ou VM isolés.

La commande /permissions affiche les règles Allow, Ask et Deny. Deny gagne, donc une équipe devrait bloquer les force push, la lecture de .env et les commandes de déploiement production au lieu de compter sur la mémoire de chacun. Les règles partagées vont dans .claude/settings.json; les essais personnels dans .claude/settings.local.json.

settings.json minimal

Utilisez cet exemple comme base et adaptez seulement les noms de commandes.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force *)",
      "Bash(* --no-verify *)"
    ]
  }
}

Le point clé est la retenue. Une règle large comme Bash(*) affaiblit la couche d’approbation. Préapprouver des vérifications répétables comme npm run test et git diff garde la session rapide sans masquer les opérations risquées.

Cas d’usage 1: correction de bug

La demande risquée est: “Corrige tout le login et push si ça marche.” Le périmètre est trop large et l’action distante est attachée à la modification.

Objectif: Corriger le bug où la session expire juste après le login.
Périmètre: Seulement src/auth/**, src/session/** et tests/auth/**.
Interdit: git push, deploy, accès DB production, lecture de .env.
Processus:
1. Lire les fichiers pertinents et lister jusqu'à 3 causes probables.
2. Proposer un plan de changement et attendre mon accord.
3. Après accord, faire la plus petite modification utile.
4. Exécuter npm run test -- auth et résumer les échecs éventuels.
5. Finir par un résumé du git diff et des risques restants.

Ainsi Claude Code peut analyser, modifier et vérifier, tout en gardant des points de revue. Les réécritures non liées deviennent moins probables.

Cas d’usage 2: refactor

La demande risquée est: “Nettoie l’ancienne implémentation et supprime ce qui ne sert plus.” Ancien, propre et inutile sont des mots instables.

Objectif: Regrouper les validations dupliquées dans le module billing.
Modifications autorisées: src/billing/validators.ts et ses tests.
Ne pas modifier: migrations/**, prisma/**, public/**, package-lock.json.
Règle de suppression: Lister seulement les candidats. Ne rien supprimer sans accord.
Vérification: Exécuter npm run test -- billing et npm run lint.
Sortie: Résumer raison, impact de compatibilité et tests à ajouter.

Dans un refactor, la liste des exclusions est souvent la partie la plus utile. Les migrations, lockfiles et fichiers générés peuvent sembler inutiles alors qu’ils sont nécessaires.

Cas d’usage 3: revue avant déploiement

La demande risquée est: “La CI est lente, saute-la et envoie en production.” --no-verify peut sauter plus que le lint, y compris les hooks et scans de secrets.

Objectif: Faire une vérification courte avant release.
Commandes autorisées: git status, git diff, npm run test -- --runInBand, npm run build.
Commandes interdites: git push, deploy, --no-verify, npm publish.
Règle de décision:
- S'arrêter si les tests ou le build échouent.
- Résumer seulement les 80 dernières lignes d'un log d'erreur.
- Rapporter l'état: Prêt / À corriger / Décision en attente.

Un déploiement touche clients, paiement, index de recherche, caches et support. Claude Code doit préparer les preuves; l’action finale de release reste explicite et humaine.

Cas d’usage 4: recherche et documentation

La demande risquée est: “Cherche les dernières infos et mets l’article à jour comme tu veux.” Les faits externes changent, donc sources et périmètre d’édition doivent être séparés.

Objectif: Mettre à jour le texte sur les permission modes de Claude Code.
Sources: Privilégier la documentation officielle et lister les URLs à la fin.
Interdit: Ne pas affirmer de fonctionnalité non confirmée par la doc officielle.
Processus:
1. Faire un tableau entre le texte actuel et la documentation officielle.
2. Proposer seulement les modifications; attendre avant d'éditer.
3. Après édition, vérifier les liens anciens et la longueur de description.

Pour la recherche, traitez Claude Code d’abord comme vérificateur de sources et organisateur de diff, pas comme auteur final.

Échecs concrets

Premier cas: les retries illimités. “Réessaie jusqu’à réussir” peut transformer une panne en coûts supplémentaires et pression sur les rate limits. Fixez un nombre maximal, une attente et une condition d’arrêt.

Deuxième cas: les secrets. Des clés API réelles collées dans les prompts peuvent rester dans l’historique, les logs locaux et les passages à des subagents. Les valeurs vont dans des variables d’environnement ou un gestionnaire de secrets; les prompts ne nomment que les variables.

Troisième cas: les dépendances. “Mets tous les packages à latest” peut tirer des versions majeures avec breaking changes. Utilisez npm outdated, séparez correctifs sécurité et mises à jour normales, puis révisez les majors à part.

Quatrième cas: nettoyage et migrations. “Nettoie les fichiers DB” peut être compris comme supprimer l’historique de migration. Demandez d’abord une liste et arrêtez-vous au SQL généré pour toute action touchant la production.

Checklist de revue

Collez ceci à la fin des prompts à fort impact.

Vérification sécurité:
[ ] J'ai nommé les fichiers ciblés et exclus
[ ] git push / deploy / publish est interdit ou soumis à approbation
[ ] J'ai bloqué DB production, API production et opérations payantes
[ ] J'ai exclu .env, clés privées et données personnelles
[ ] J'ai demandé Plan mode ou un plan avant édition
[ ] J'ai inclus au moins un test, lint ou build
[ ] J'ai demandé d'arrêter et résumer les logs en cas d'échec
[ ] J'ai demandé le diff final, les commandes lancées et les risques restants

Si vous voulez des modèles réutilisables au lieu de réécrire ces règles, la page produits contient des packs de prompts et checklists. Pour une adoption en équipe, CLAUDE.md, permissions, portes de revue et exercices d’onboarding peuvent être conçus sur votre vrai dépôt via la formation et le conseil Claude Code.

Liens officiels

実際に試した結果: Dans le workflow de Masa, les trois règles les plus utiles ont été de commencer en Plan mode, limiter les changements à deux à cinq fichiers, et garder push/deploy comme décision humaine. Éviter les prompts dangereux ne ralentit pas Claude Code; cela rend le passage de relais assez précis pour avancer plus vite avec moins de stress de revue.