10 patterns de prompts dangereux dans Claude Code | Ce qu'il ne faut pas faire et les alternatives sûres
Découvrez 10 patterns de prompts dangereux à ne jamais donner à Claude Code. Apprenez comment des instructions vagues mènent à la perte de code, la destruction de BD, des factures explosives et des fuites de clés.
Rédigez-vous des prompts en pensant « il comprendra bien ce que je veux dire » ? Claude Code exécute les instructions à la lettre. Des instructions vagues ou dangereuses produisent des résultats non souhaités.
Cet article présente 10 patterns de prompts dangereux qui ont causé de véritables incidents, avec des alternatives sûres pour chacun. Si vous reconnaissez l’un de ces patterns après la lecture, modifiez-le immédiatement.
Pattern 1 : « Lis tout et comprends l’ensemble du projet »
Pourquoi c’est dangereux
❌ « Lis tout ce dépôt et comprends-le avant d'implémenter »Sur un dépôt avec des centaines de fichiers, le contexte explose. Des dizaines de milliers de tokens sont consommés et le traitement s’arrête avec l’erreur Prompt is too long. S’il s’arrête en cours de lecture, l’implémentation se fait sur la base d’une compréhension incomplète.
De plus, si des fichiers contenant .env ou des clés secrètes existent, ils sont tous chargés dans le contexte.
Alternative sûre
✅ « Vérifie la structure du répertoire src/api/ et lis uniquement les fichiers liés à l'auth »
✅ « Lis d'abord seulement package.json et le README pour avoir une vue d'ensemble du projet »
✅ « Utilise Grep pour trouver les fichiers liés à l'authentification avant de les lire »Point clé : Limitez explicitement la portée de ce qui doit être lu. Claude Code essaiera de lire largement si rien n’est spécifié.
Pattern 2 : « En cas d’erreur, réessaie automatiquement »
Pourquoi c’est dangereux
❌ « En cas d'erreur lors de l'appel à l'API externe, réessaie automatiquement jusqu'au succès »Si un service externe est en panne, il va continuer à marteler l’API dans une boucle infinie. Des incidents réels ont enregistré des dizaines de milliers d’appels en une heure, avec des factures atteignant des centaines ou des milliers d’euros. Cela se produit surtout avec des jobs batch nocturnes qui s’exécutent sans être remarqués jusqu’au matin.
Alternative sûre
✅ « En cas d'erreur, réessaie jusqu'à 3 fois.
Attendre 1 seconde avant la 1ère tentative, 4 secondes avant la 2ème, 16 secondes avant la 3ème.
Si les 3 échouent, journaliser l'erreur et arrêter le traitement »
✅ « Utilise le code suivant pour les tentatives :
withRetry(fn, { maxAttempts: 3, baseDelayMs: 1000 }) »Pattern 3 : « Connecte-toi directement à la BD de production et vérifie »
Pourquoi c’est dangereux
❌ « Connecte-toi à la BD de production à DATABASE_URL, vérifie le nombre d'utilisateurs, puis effectue des corrections »Ce qui commence par « juste vérifier » comporte le risque que les requêtes de correction suivantes soient exécutées contre la BD de production. Si après un SELECT suit accidentellement un DELETE ou UPDATE, les données de production disparaissent. La connexion à la production déclenche facilement des opérations au-delà de la portée prévue.
Alternative sûre
✅ « Connecte-toi à la BD de développement (DATABASE_URL_DEV) et vérifie le nombre d'utilisateurs.
Ne te connecte pas à la production »
✅ « Génère la requête mais ne l'exécute pas.
Je la réviserai et l'exécuterai moi-même »
✅ Dans CLAUDE.md :
« L'exécution de requêtes contre DATABASE_URL de production est interdite.
Vérifier d'abord sur le staging, exécuter seulement après approbation de l'utilisateur »Pattern 4 : Coller des clés API directement dans le prompt
Pourquoi c’est dangereux
❌ « Utilise QIITA_TOKEN=abc123def456 pour publier sur Qiita »
❌ « Utilise sk-ant-api03-xxxxx pour appeler l'API Anthropic »Le contenu écrit dans un prompt est sauvegardé comme historique de conversation. Il est transmis tel quel lors de la délégation à des sous-agents. Il reste dans les journaux du répertoire local .claude/ et peut se retrouver à l’extérieur sans le vouloir via des outils de sauvegarde ou lors du partage de code.
Alternative sûre
✅ « Utilise QIITA_TOKEN de .env pour exécuter scripts/qiita-publish.mjs »
← La valeur du token n'existe que dans .env ; seul le nom de la variable va dans le prompt
✅ Lire depuis les variables d'environnement dans votre script :
const token = process.env.QIITA_TOKEN;
if (!token) throw new Error("QIITA_TOKEN n'est pas défini");Pattern 5 : « Résous le conflit et pousse en production »
Pourquoi c’est dangereux
❌ « Il y a un conflit avec la branche main. Résous-le et pousse en production »git push --force peut être choisi comme moyen de « résoudre le conflit ». Cela risque d’effacer les commits des membres de l’équipe. De plus, « pousser en production » peut résulter en un push direct qui contourne le CI/CD.
Alternative sûre
✅ « Vérifie le conflit avec main et propose une stratégie de merge.
Attends mon approbation avant de merger et pusher réellement »
✅ Dans CLAUDE.md :
« git push --force est interdit.
Si le force est nécessaire, utiliser --force-with-lease et confirmer avec l'utilisateur »// .claude/settings.json
{
"permissions": {
"deny": [
"Bash(git push --force *main*)",
"Bash(git push --force *master*)"
]
}
}Pattern 6 : « Supprime tous les vieux fichiers et nettoie »
Pourquoi c’est dangereux
❌ « Supprime tous les fichiers de dist/, .cache/ et les anciens fichiers de logs pour nettoyer »Comme « ancien » est ambigu, des fichiers nécessaires peuvent être supprimés. En particulier, les répertoires .cache/ peuvent contenir des données critiques spécifiques au système d’exploitation ou aux outils. Spécifier plusieurs répertoires à la fois résulte en rm -rf dist .cache logs/, qui peut se propager à des chemins non souhaités.
Alternative sûre
✅ « Supprime uniquement le contenu du répertoire site/dist/.
Laisse le répertoire lui-même. Ne touche à aucun autre répertoire »
✅ « Montre-moi la liste des fichiers à supprimer avant de les supprimer pour que je puisse confirmer.
Supprime après mon approbation »Pattern 7 : « Approuve tout automatiquement et exécute tout d’un coup »
Pourquoi c’est dangereux
❌ « Passe toutes les confirmations intermédiaires et exécute tout jusqu'à la fin »
❌ « Exécute-le avec l'option --dangerously-skip-permissions »Le flux d’approbation est un mécanisme de sécurité. Le contourner laisse Claude Code procéder avec ce qu’il juge comme « le plus efficace ». Cela pourrait signifier rm -rf, force push ou des écritures dans la BD de production—tout sans confirmation.
Alternative sûre
✅ « Liste d'abord les étapes pour cette tâche.
Après mon approbation, exécute une étape à la fois et confirme le résultat à chaque étape »
✅ Pour l'automatisation, n'autorise que les opérations de confiance :
"allow": ["Read(**)", "Glob(**)", "Bash(npm run test)"]Pattern 8 : « Mets à jour les migrations et nettoie la BD »
Pourquoi c’est dangereux
❌ « Les fichiers de migration sont en désordre. Nettoie-les et mets tout à jour »« Nettoyer » peut être interprété comme supprimer les anciens fichiers de migration. Si l’historique des migrations disparaît, configurer de nouveaux environnements ou effectuer un rollback devient impossible. Si une commande de type migrate reset est exécutée, les données de production pourraient être effacées.
Alternative sûre
✅ « Montre la liste des fichiers de migration et signale seulement les doublons ou problèmes.
N'apporte aucun changement »
✅ « Vérifie les migrations non appliquées et montre le SQL qui serait exécuté.
Exécute après mon approbation »
✅ Dans CLAUDE.md :
« Ne pas supprimer les fichiers de migration.
Toujours obtenir la confirmation de l'utilisateur avant d'exécuter des migrations contenant ALTER/DROP »Pattern 9 : « Mets tous les packages à jour vers la dernière version »
Pourquoi c’est dangereux
❌ « Les packages npm sont obsolètes. Mets tout à jour vers la dernière version »npm update ou npm install package@latest peut bumper des versions majeures. Si des breaking changes sont inclus, le build local peut passer mais le service pourrait tomber après le déploiement en production. La rupture en cascade des dépendances est également fréquente.
Alternative sûre
✅ « Exécute npm outdated et montre la liste des packages qui peuvent être mis à jour.
Je vérifierai séparément tout ce qui bumpe une version majeure »
✅ « Mets à jour uniquement les packages avec des vulnérabilités de sécurité (détectées par npm audit) »
✅ « Mets à jour uniquement react et next.js vers la dernière version mineure.
Ne bumpe pas la version majeure »Pattern 10 : « Déploie d’abord, les tests peuvent attendre »
Pourquoi c’est dangereux
❌ « J'écrirai les tests plus tard, déploie d'abord pour l'instant »
❌ « Le CI est lent, passe-le avec --no-verify et pousse »Les tests et le CI ne sont pas « lents »—ils « te protègent ». Le pire pattern est de découvrir des bugs en production pour la première fois après les avoir sautés. --no-verify désactive tout y compris les git hooks, donc le scan de secrets et le lint sont également ignorés.
Alternative sûre
✅ « Écris d'abord les tests et déploie après qu'ils passent.
Même si la couverture est insuffisante, les chemins principaux suffisent »
✅ « Investigue pourquoi le CI est lent et accélère-le en exploitant le cache.
Ne le saute pas »
✅ Dans CLAUDE.md :
« --no-verify est interdit.
N'utilise jamais aucun moyen de sauter le CI »Résumé : 3 principes pour écrire des prompts sûrs
Principe 1 : Spécifier explicitement la portée « Tout », « tous » et « l’ensemble » sont des mots dangereux. Spécifie exactement ce qui doit être lu, modifié et supprimé.
Principe 2 : Maintenir les étapes de confirmation Insère « vérifier », « proposer » ou « montrer la liste » avant « exécuter ». Surtout pour les opérations qui affectent la production.
Principe 3 : Ne jamais mettre de secrets dans les prompts
Les clés API, mots de passe et chaînes de connexion vont dans .env. Seuls les noms de variables vont dans les prompts.
| Expression dangereuse | Alternative sûre |
|---|---|
| « Lis tout » | « Lis seulement le répertoire [X] » |
| « Réessaie automatiquement » | « Réessaie jusqu’à 3 fois, puis arrête » |
| « Connecte-toi à la BD de production » | « Vérifie sur la BD de dev, j’exécute en production » |
| « Supprime tout et nettoie » | « Supprime seulement [X], montre-moi la liste d’abord » |
| « Exécute tout d’un coup » | « Laisse-moi confirmer les étapes d’abord, puis procède » |
Claude Code ne fait que suivre des instructions—il n’a aucune intention malveillante. Le danger vient de la personne qui donne des instructions vagues. Développer l’habitude d’écrire des instructions spécifiques et clairement délimitées est le chemin le plus rapide pour prévenir les incidents.
Articles connexes
- 7 incidents de production réels avec Claude Code et procédures de récupération complètes
- Le guide complet des meilleures pratiques de sécurité de Claude Code
- Le guide complet des permissions de Claude Code
Références
Passez votre flux Claude Code au niveau supérieur
50 modèles de prompts éprouvés, prêts à être copiés-collés dans Claude Code.
PDF gratuit : aide-mémoire Claude Code en 5 minutes
Laissez simplement votre e-mail et nous vous enverrons immédiatement l'aide-mémoire A4 en PDF.
Nous traitons vos données avec soin et n'envoyons jamais de spam.
À propos de l'auteur
Masa
Ingénieur passionné par Claude Code. Il gère claudecode-lab.com, un média tech en 10 langues avec plus de 2 000 pages.
Articles similaires
Maîtrisez les coûts API de Claude Code : 5 techniques pour passer de $450 à $45/mois
Les vrais chiffres derrière la tarification de l'API Claude Code. Découvrez comment le prompt caching, l'optimisation des modèles et le traitement par lots ont permis une réduction de 90 %, de $450 à $45 par mois.
7 incidents de production réels avec Claude Code : récupération complète avec RCA et prévention
7 incidents de production réels avec Claude Code : fuites de clés API, suppressions de BD, explosions de facturation et pannes de service — avec analyse des causes racines et stratégies de prévention.
Guide Complet de Sécurité pour Claude Code : Clés API, Permissions et Protection de la Production
Guide pratique de sécurité pour utiliser Claude Code en toute sécurité. De la gestion des clés API aux paramètres de permissions, automatisation via Hooks et protection de l'environnement de production — avec des exemples de code fonctionnels.