Accueil › Claude Code › Prompts

Claude Code Prompts : le guide complet pour maîtriser vos commandes

Les prompts dans Claude Code ne se limitent pas à taper une question dans le terminal : c’est un système complet de commandes intégrées, de fichiers de configuration persistants et de skills réutilisables qui transforment votre productivité de développeur.

Comprendre le système de prompts de Claude Code

Claude Code n’est pas un chatbot classique. C’est un agent qui opère directement dans votre terminal, lit votre codebase, exécute des commandes et édite vos fichiers. Cette architecture change fondamentalement la façon dont vous formulez vos requêtes.

Le système de prompts de Claude Code repose sur trois piliers distincts. Premièrement, les prompts conversationnels que vous tapez directement dans le terminal interactif. Deuxièmement, les slash commands (commandes préfixées par /) qui déclenchent des actions spécifiques. Troisièmement, les fichiers de configuration comme CLAUDE.md qui injectent du contexte persistant dans chaque session.

La différence avec un IDE comme Cursor ou GitHub Copilot est structurelle. Dans Claude Code, chaque prompt peut déclencher la lecture de fichiers, l’exécution de commandes shell, la création de sous-agents et la modification de votre code. Vous ne demandez pas une complétion : vous déléguez une tâche à un agent autonome.

Rédiger des prompts conversationnels efficaces

Les règles de base

La documentation officielle d’Anthropic et les retours de la communauté convergent sur cinq principes pour des prompts efficaces dans Claude Code.

Soyez spécifique sur le langage et le framework. Ne dites pas « en Python », dites « en Python 3.12 avec FastAPI et Pydantic v2 ». Claude Code utilise Claude Opus 4.6 comme modèle par défaut, capable de résoudre des problèmes complexes, mais la précision de votre prompt détermine la qualité du résultat.

Référencez les fichiers directement avec @. Plutôt que de décrire l’emplacement d’un fichier, tapez @src/auth/middleware.ts. Claude Code lit le fichier avant de répondre, ce qui lui donne un contexte exact plutôt qu’une approximation.

Fournissez du contexte riche. Vous pouvez coller des images (screenshots d’UI, diagrammes d’architecture), donner des URLs de documentation, ou piper des données avec cat error.log | claude. Plus Claude Code a de contexte pertinent, moins il improvise.

Laissez Claude Code chercher le contexte lui-même. Plutôt que de tout fournir manuellement, dites à Claude de tirer son propre contexte via des commandes Bash, des outils MCP ou la lecture directe de fichiers. C’est souvent plus efficace que de tout spécifier vous-même.

Demandez des explications avant l’implémentation. Un prompt comme « Explique ton approche avant d’implémenter » force Claude Code à planifier avant d’agir, ce qui réduit les itérations correctives.

Exemples de prompts par cas d’usage

Voici des prompts testés qui produisent des résultats fiables dans différents contextes de développement.

Génération de code :

Crée un middleware Express en TypeScript qui valide les JWT.
Utilise jose pour la vérification, gère les cas d'erreur
(token expiré, signature invalide, token absent) et retourne
des codes HTTP appropriés. Ajoute les types pour req.user.
Fichier cible : @src/middleware/auth.ts

Debugging :

J'ai cette erreur : "TypeError: Cannot read property 'id' of undefined"
dans @src/services/user-service.ts ligne 42.
Lis le fichier, identifie la cause racine, propose un fix
et écris un test unitaire qui couvre ce cas.

Refactoring :

Refactore @src/api/routes/ pour extraire la logique métier
dans des services dédiés dans @src/services/.
Conserve les mêmes signatures d'API. Fais tourner les tests
après chaque modification pour vérifier qu'il n'y a pas de régression.

Revue de code :

Analyse @src/controllers/ pour des vulnérabilités de sécurité :
injection SQL, XSS, credentials exposées, configurations non sécurisées.
Classe les problèmes par sévérité et propose un fix pour chacun.

Les erreurs de prompts les plus courantes

La documentation officielle identifie trois anti-patterns qui dégradent systématiquement les résultats.

La session fourre-tout. Vous commencez une tâche, demandez autre chose sans rapport, puis revenez à la première tâche. Le contexte est pollué d’informations inutiles. La solution : utilisez /clear entre les tâches non liées.

La correction en boucle. Claude fait une erreur, vous corrigez, c’est toujours faux, vous corrigez encore. Le contexte se remplit d’approches échouées. Après deux corrections ratées, faites /clear et rédigez un meilleur prompt initial intégrant ce que vous avez appris.

Le CLAUDE.md surchargé. Vous y mettez toutes les commandes possibles, vos guidelines de style, des snippets de code. Le fichier devient trop long et dilue l’attention du modèle. Un CLAUDE.md efficace fait moins de 200 lignes et contient uniquement les informations universellement applicables à votre projet.

Les slash commands : référence complète

Claude Code v2.1.81 intègre plus de 50 slash commands natives, plus 5 skills groupées. Tapez / dans le terminal interactif pour voir la liste complète, puis continuez à taper pour filtrer.

Les commandes essentielles

Les commandes avancées

Les 5 skills groupées (bundled skills)

Contrairement aux commandes intégrées qui exécutent une logique fixe, les skills groupées sont des prompts détaillés qui laissent Claude orchestrer le travail avec ses outils. Elles peuvent créer des sous-agents en parallèle, lire des fichiers et s’adapter à votre codebase.

Raccourcis clavier essentiels

CLAUDE.md : le fichier de mémoire persistante

Le fichier CLAUDE.md est le levier numéro un pour améliorer la qualité de vos résultats. Claude Code le lit automatiquement au début de chaque session. C’est l’équivalent d’une mémoire permanente de projet.

Que mettre dans CLAUDE.md

Quatre catégories d’informations méritent d’y figurer.

Le contexte projet. Une ligne qui oriente Claude : « Application Next.js 14 e-commerce avec App Router, Stripe et Prisma ORM. » Cette simple phrase change radicalement la qualité des réponses parce que Claude sait immédiatement dans quel écosystème il opère.

Les commandes clés. Comment lancer les tests (npm test), builder (npm run build), linter (npm run lint), déployer. Claude utilise ces commandes exactes quand vous lui demandez d’exécuter quelque chose. Si elles ne sont pas dans CLAUDE.md, il doit les deviner.

Le style de code. Vos préférences concrètes : « TypeScript strict mode, pas de any« , « named exports uniquement », « composants fonctionnels avec hooks ». Soyez spécifique. « Formater correctement le code » ne dit rien. « Utiliser des ES modules, pas CommonJS » dit tout.

Les pièges du projet. Les avertissements que seul un dev qui connaît le projet peut donner : « Le webhook Stripe dans /app/api/webhooks doit valider les signatures », « Les images produit sont sur Cloudinary, pas en local », « Ne jamais commit les fichiers .env ».

Structure recommandée

# Mon Projet

Application Next.js 14 avec App Router, Stripe et Prisma.

## Commandes
- `npm run dev` : serveur dev (port 3000)
- `npm test` : tests Jest
- `npm run test:e2e` : tests Playwright
- `npm run lint` : vérification ESLint
- `npm run db:migrate` : migrations Prisma

## Style de code
- TypeScript strict, pas de types `any`
- Named exports uniquement
- Tailwind pour le CSS, pas de fichiers CSS custom

## Architecture
- `/app` : pages et layouts App Router
- `/components/ui` : composants réutilisables
- `/lib` : utilitaires partagés
- `/prisma` : schéma et migrations

## Attention
- NE JAMAIS commit les fichiers .env
- Le webhook Stripe valide les signatures obligatoirement
- Voir @docs/authentication.md pour le flow d'auth

Bonnes pratiques pour CLAUDE.md

Gardez le fichier sous 200 lignes. Il est chargé dans chaque message. Le prompt système de Claude Code contient déjà environ 50 instructions. Selon les recherches de HumanLayer, les LLM de type thinking peuvent suivre 150 à 200 instructions de façon fiable. Au-delà, la performance d’instruction-following décline linéairement pour les gros modèles et exponentiellement pour les plus petits.

Préférez les pointeurs aux copies. Ne collez pas de snippets de code dans CLAUDE.md : ils deviennent obsolètes rapidement. Utilisez des références de fichiers (@src/auth/flow.ts) pour diriger Claude vers le contexte faisant autorité.

Ne confiez pas au LLM le travail d’un linter. Les guidelines de style de code dans CLAUDE.md ajoutent des instructions et des snippets souvent inutiles dans la fenêtre de contexte. Utilisez des outils déterministes (ESLint, Prettier) via les hooks plutôt que de demander au modèle de formater le code.

Utilisez la hiérarchie de fichiers. Le CLAUDE.md racine contient les règles universelles. Des CLAUDE.md dans les sous-dossiers (/frontend/CLAUDE.md, /backend/CLAUDE.md) ajoutent du contexte spécifique. Claude Code charge automatiquement les fichiers enfants quand il travaille dans ces répertoires.

Lancez /init pour démarrer, puis éditez. La commande génère un CLAUDE.md de base à partir de la structure de votre projet. Supprimez le superflu (c’est plus rapide que d’écrire de zéro) et ajoutez ce qui manque.

Créer des commandes personnalisées (slash commands custom)

Les commandes custom sont des prompts sauvegardés dans des fichiers Markdown que vous invoquez par leur nom. C’est le passage de « j’écris un prompt à chaque fois » à « j’ai un système de prompts réutilisables ».

Création basique

Créez un fichier Markdown dans .claude/commands/ (portée projet) ou ~/.claude/commands/ (portée globale). Le nom du fichier devient la commande.

# Commande projet
mkdir -p .claude/commands
echo "Analyse ce code pour des problèmes de performance
et propose des optimisations :" > .claude/commands/optimize.md

# Commande personnelle (tous les projets)
mkdir -p ~/.claude/commands
echo "Revue de sécurité de ce code :" > ~/.claude/commands/security.md

Vous invoquez ensuite la commande en tapant /optimize ou /security dans Claude Code.

Utiliser des arguments

Les commandes custom acceptent des arguments positionnels ($1, $2) ou l’ensemble des arguments ($ARGUMENTS).

# .claude/commands/fix-issue.md
Corrige l'issue #$1 avec une priorité $2.
Lis d'abord l'issue sur GitHub, puis implémente le fix
et écris les tests associés.

Usage : /fix-issue 42 haute

Frontmatter avancé

Ajoutez un bloc YAML en tête du fichier pour contrôler le comportement de la commande.

---
allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*)
argument-hint: [message]
description: Crée un commit git structuré
model: claude-sonnet-4-6
---

# Contexte Git
- Status actuel : !`git status`
- Diff actuel : !`git diff`

Crée un commit avec le message : $ARGUMENTS
Respecte le format Conventional Commits.

Le frontmatter offre plusieurs options clés. Le champ allowed-tools liste les outils que Claude peut utiliser sans demander permission. Le champ model force un modèle spécifique (pratique pour utiliser Haiku sur des tâches simples et économiser des tokens). Le champ description aide Claude à savoir quand auto-invoquer la commande.

La syntaxe !`commande` exécute des commandes shell avant l’envoi du prompt à Claude. Le résultat remplace le placeholder. C’est du préprocessing, pas quelque chose que Claude exécute.

Exemples de commandes utiles

Résumé de Pull Request :

---
allowed-tools: Bash(gh *)
context: fork
agent: Explore
---

## Contexte PR
- Diff : !`gh pr diff`
- Commentaires : !`gh pr view --comments`
- Fichiers modifiés : !`gh pr diff --name-only`

## Tâche
Résume cette pull request en français :
1. Objectif principal du changement
2. Fichiers clés modifiés et pourquoi
3. Risques potentiels ou points d'attention
4. Verdict : prêt à merger ou modifications nécessaires

Nouveau composant React :

---
description: Scaffold un nouveau composant React
argument-hint: [ComponentName]
---

Crée un nouveau composant React "$ARGUMENTS" :
1. Fichier composant dans src/components/$ARGUMENTS.tsx
2. Fichier test dans src/components/$ARGUMENTS.test.tsx
3. Export dans src/components/index.ts
Respecte les conventions du fichier CLAUDE.md.
Utilise des composants fonctionnels avec hooks et TypeScript strict.

Les Skills : prompts intelligents et auto-découverts

Les skills sont l’évolution des commandes custom. Elles suivent le standard ouvert Agent Skills, ce qui signifie qu’elles fonctionnent dans plusieurs outils IA, pas uniquement Claude Code.

Créer une skill

Chaque skill nécessite un fichier SKILL.md dans un répertoire dédié.

# ~/.claude/skills/explain-code/SKILL.md
---
name: explain-code
description: Explique du code avec des diagrammes et des analogies.
  Utiliser quand l'utilisateur demande "comment ça marche ?"
---

Quand tu expliques du code, inclus toujours :

1. **Analogie** : compare le code à quelque chose du quotidien
2. **Diagramme** : utilise de l'ASCII art pour montrer le flux
3. **Pas à pas** : explique étape par étape ce qui se passe
4. **Piège courant** : signale une erreur fréquente ou un malentendu

Différences clés avec les commandes

Les skills se distinguent des commandes custom sur plusieurs points importants.

Auto-invocation. Si la description de votre skill correspond à la tâche en cours, Claude peut l’invoquer automatiquement sans que vous tapiez la commande. Pour les commandes, l’invocation est toujours explicite.

Répertoire de fichiers. Une skill peut contenir des scripts et du contexte supplémentaire dans son dossier. Le SKILL.md est le point d’entrée, mais vous pouvez y ajouter des templates, des exemples, des scripts d’aide.

Exécution en sous-agent. En ajoutant context: fork ou agent: Explore dans le frontmatter, la skill s’exécute dans son propre contexte, ce qui préserve la fenêtre de contexte principale.

Effort configurable. Le frontmatter effort permet de forcer le niveau de raisonnement (low, medium, high, max) quand la skill est invoquée.

Budget de contexte des skills

Les descriptions de skills sont chargées en contexte pour que Claude sache ce qui est disponible. Si vous avez beaucoup de skills, elles peuvent dépasser le budget de caractères. Ce budget est dynamique : 2% de la fenêtre de contexte, avec un fallback à 16 000 caractères. Exécutez /context pour vérifier si des skills sont exclues. Pour ajuster la limite, configurez la variable d’environnement SLASH_COMMAND_TOOL_CHAR_BUDGET.

Le mode CLI : prompts non-interactifs

Claude Code ne se limite pas au mode interactif. Le flag -p (print mode) permet d’exécuter des prompts en one-shot, sans session persistante. C’est la clé pour intégrer Claude Code dans vos scripts, pipelines CI/CD et workflows automatisés.

Exemples d’utilisation CLI

# Requête ponctuelle
claude -p "Explique ce que fait ce projet"

# Output structuré pour scripts
claude -p "Liste tous les endpoints API" --output-format json

# Streaming pour traitement temps réel
claude -p "Analyse ce fichier de logs" --output-format stream-json

# Avec un budget maximum
claude -p "Fix les tests qui échouent" --max-budget-usd 2.00

# Limiter les tours agentiques
claude -p "Review ce fichier" --max-turns 3

# Utiliser le modèle le moins cher pour les tâches simples
claude -p "Vérifie les erreurs de lint" --model haiku

Piping et intégration

La puissance du mode CLI vient de sa composabilité avec les outils Unix.

# Analyse de logs
cat error.log | claude -p "Résume les erreurs critiques"

# Pre-commit hook
git diff --staged | claude -p "Y a-t-il des problèmes de sécurité dans ce diff ?"

# Combinaison avec d'autres outils
find . -name "*.test.ts" -empty | claude -p "Génère des tests pour ces fichiers vides"

Le mode –bare

Introduit dans la v2.1.81 (mars 2026), le flag --bare est conçu pour les appels -p scriptés. Il désactive les hooks, le LSP, la synchronisation des plugins et le scan des skills. Il nécessite une clé API Anthropic (pas d’OAuth) et désactive complètement l’auto-mémoire. C’est le mode le plus léger pour les intégrations en pipeline.

Sessions parallèles et sous-agents

Claude Code supporte l’exécution de plusieurs sessions en parallèle pour accélérer le développement. Vous pouvez gérer plusieurs sessions locales visuellement via l’app desktop Claude Code, ou lancer des sessions indépendantes dans des terminaux séparés.

Prompts pour sous-agents

Les sous-agents sont des agents spécialisés que Claude peut invoquer. Quand Claude utilise la commande Task, il crée un sous-agent qui travaille dans son propre contexte et rapporte ses résultats à l’agent principal.

Vous pouvez définir vos propres sous-agents dans .claude/agents/. Voici un exemple de sous-agent reviewer :

# .claude/agents/code-reviewer/AGENT.md
---
name: code-reviewer
description: Expert en revue de code. Utiliser après les modifications.
tools: Read, Grep, Glob, Bash
model: sonnet
---

Tu es un reviewer senior. Quand tu analyses du code :
- Cherche les vulnérabilités (injection SQL, XSS, etc.)
- Vérifie la gestion d'erreurs
- Évalue la lisibilité et la maintenabilité
- Propose des améliorations concrètes avec exemples

L’intérêt des sous-agents est double : ils préservent la fenêtre de contexte principale (ils travaillent dans leur propre contexte) et ils permettent la parallélisation (plusieurs sous-agents peuvent travailler simultanément sur des tâches différentes).

Workflows de prompts avancés

TDD (Test-Driven Development)

Un des workflows les plus efficaces consiste à demander à Claude d’écrire les tests avant l’implémentation.

Avant d'écrire l'implémentation, écris les tests unitaires pour
une fonction calculateShippingCost qui prend un poids (en kg)
et une zone de destination (1-5) et retourne un coût en euros.
Couvre les cas normaux, les edge cases (poids zéro, zone max)
et les inputs invalides.

Ensuite, implémente la fonction pour que tous les tests passent.

Ce pattern produit du code nettement plus propre parce que les tests servent de contrat. Claude sait exactement ce que « terminé » signifie avant de commencer.

Planification avant exécution

Pour les tâches complexes, le mode plan (Shift+Tab pour cycler jusqu’à « plan mode ») force Claude à planifier sans exécuter. Vous validez le plan, puis lancez l’exécution. C’est l’architecture mentale recommandée par l’équipe Anthropic : Research → Plan → Execute → Review → Ship.

Je veux migrer notre API REST de Express vers Fastify.
Fais d'abord un plan détaillé phase par phase.
Chaque phase doit avoir des tests de validation.
Ne commence pas l'implémentation avant que j'approuve le plan.

Revue de code automatique sur GitHub

La commande /install-github-app installe une app GitHub qui fait reviewer automatiquement chaque PR par Claude Code. L’outil est puissant mais trop verbeux par défaut. Personnalisez le prompt dans le fichier claude-code-review.yml :

# claude-code-review.yml
direct_prompt: |
  Revue cette pull request et cherche des bugs et des problèmes
  de sécurité. Ne reporte que les bugs et vulnérabilités trouvés.
  Sois concis.

Modifications à grande échelle

La skill /batch orchestre des changements parallèles sur toute la codebase. Testez d’abord sur 2-3 fichiers, affinez votre prompt selon les erreurs, puis lancez sur l’ensemble.

/batch Migre tous les composants React class dans src/components/
vers des composants fonctionnels avec hooks. Conserve les mêmes
props et le même comportement. Lance les tests après chaque fichier.

Le flag --allowedTools restreint les capacités de Claude, ce qui est important quand vous exécutez en mode non supervisé.

Optimiser vos prompts pour Claude Code

Gestion du contexte

La fenêtre de contexte de Claude Code atteint 1M tokens sur les plans Max, Team et Enterprise depuis le 13 mars 2026. C’est un avantage significatif par rapport à d’autres outils, mais la gestion du contexte reste importante pour la qualité des réponses.

Utilisez /compact proactivement plutôt que d’attendre que le contexte soit plein. La compaction automatique se déclenche à 75% de remplissage, mais elle est lente et interrompt les tâches. Vous pouvez guider la compaction : /compact "conserve les patterns de gestion d'erreurs".

Déléguer aux sous-agents est une autre stratégie efficace. Plutôt que de faire toute l’analyse dans la session principale, demandez à Claude de créer un sous-agent pour les tâches exploratoires. Le sous-agent travaille dans son propre contexte et ne pollue pas la fenêtre principale.

Choisir le bon modèle

Claude Code utilise Opus 4.6 par défaut, mais vous pouvez basculer vers Sonnet 4.6 ou Haiku 4.5 selon la tâche.

Tirer parti des outils CLI

Claude Code excelle quand vous lui donnez accès à des outils CLI existants. Installez gh (GitHub CLI) pour les interactions GitHub, aws/gcloud pour le cloud, sentry-cli pour le monitoring. Les outils CLI sont la façon la plus efficiente en contexte d’interagir avec des services externes.

Sans gh, Claude peut utiliser l’API GitHub directement, mais les requêtes non authentifiées atteignent rapidement les limites de rate. Claude est aussi capable d’apprendre des outils qu’il ne connaît pas. Essayez un prompt comme : « Utilise ‘foo-cli-tool –help’ pour apprendre le fonctionnement de l’outil foo, puis utilise-le pour résoudre A, B, C. »

Claude Code Prompts vs la concurrence

Claude Code offre le système de prompts le plus riche parmi les assistants de code. La combinaison CLAUDE.md + skills avec auto-invocation + sous-agents + mode CLI donne un niveau de personnalisation que ni Cursor ni Copilot n’atteignent. Le point faible reste l’absence d’IDE graphique (c’est un outil terminal-first), ce qui élève la barrière d’entrée pour les développeurs habitués aux interfaces visuelles.

Codex d’OpenAI est le concurrent le plus direct en termes de fonctionnalités, avec un système de skills et d’agents similaire. La différence se joue sur le modèle sous-jacent : Opus 4.6 pour Claude Code, GPT-5.4 pour Codex.

Questions fréquentes