Comment Écrire un Bon Prompt pour Claude Code (2026)

Comment écrire un bon prompt pour Claude Code ?

Un bon prompt Claude Code divise par 3 le nombre d'allers-retours, réduit votre facture API, et produit du code qui passe la review du premier coup. Un mauvais prompt, à l'inverse, vous fait perdre 20 minutes à clarifier, corriger, reformuler — sur chaque tâche. La différence entre les deux n'est pas un don, c'est une méthode qu'on peut apprendre en quelques heures.

Ce guide détaille la technique CRAFT utilisée par les power users en 2026, illustre chaque principe avec des exemples avant/après réels, et liste les 7 erreurs de prompting qui plombent 80 % des sessions débutant. À la fin, vous aurez une checklist mentale qui transformera vos prompts en moins d'une semaine de pratique.

Sommaire

Pourquoi le prompt fait toute la différence {#pourquoi}

Trois données objectives qui justifient d'investir 4-5 heures à apprendre le prompting :

Autrement dit : le prompting est l'investissement avec le meilleur ROI que vous puissiez faire sur Claude Code. Plus que la connaissance des hooks, plus que la maîtrise de MCP, plus que les sous-agents. Tout part du prompt.

Si vous démarrez, lisez d'abord notre [guide débutant Claude Code](/blog/comment-utiliser-claude-code-guide-debutant-2026) — ce guide-ci suppose que vous savez déjà lancer une session.

La méthode CRAFT : structurer un bon prompt {#craft}

CRAFT est l'acronyme qui résume les 5 dimensions d'un bon prompt Claude Code :

C — Context

L'erreur la plus fréquente : prompter "fait X" sans donner le contexte. Claude Code ne sait pas si vous êtes en TypeScript ou Python, si vous utilisez React 18 ou 19, si votre projet est nouveau ou legacy.

Mauvais : "Crée un endpoint pour récupérer les users" Bon : "Sur le projet Fastify + Drizzle + Postgres en /Users/me/projects/myapp, crée un endpoint GET /api/users avec pagination cursor-based, en cohérence avec le pattern utilisé dans /api/posts/index.ts."

R — Request

La requête doit être active et spécifique. Évitez les formulations vagues qui ouvrent la porte aux interprétations.

Mauvais : "Améliore la perf" Bon : "Identifie les 3 requêtes SQL les plus lentes dans api/dashboard et propose des index pour réduire chaque P95 sous 50ms."

A — Acceptance

Comment vous saurez que c'est terminé ? C'est la dimension la plus négligée et celle qui change tout.

Mauvais : "Ajoute les tests" Bon : "Ajoute des tests Vitest qui couvrent 100 % des branches de utils/parser.ts, avec au moins 3 cas edge (input vide, malformé, oversize). npm test -- utils/parser doit passer sans warning."

F — Format

Le format inclut le langage, le style de code, les conventions de naming, et même la structure de réponse attendue.

Mauvais : "Refactor ce composant" Bon : "Refactor Dashboard.tsx en extrayant les sous-composants DashboardHeader, DashboardStats, DashboardChart dans des fichiers séparés. Conventions : nommage PascalCase, props typées via interface (pas type), export nommé (pas default)."

T — Thinking

Claude Code v2 supporte un mode "thinking" qui peut être réglé sur "off", "low", "medium", "high". Pour les tâches complexes, demandez explicitement plus de réflexion.

Pour tâche triviale : "Ajoute un log en début de fonction" — pas besoin de thinking. Pour refactor complexe : "Réfléchis en mode high aux trade-offs entre les approches A et B avant de proposer une implémentation."

10 exemples avant/après concrets {#exemples}

Exemple 1 : génération de composant React

Avant :

"fais un composant pricing"

Après :

"Crée un composant `<PricingCards />` Next.js 15 + Tailwind, qui accepte une prop `plans: PricingPlan[]` où PricingPlan a `{ name, price, features, ctaUrl, highlight?: boolean }`. Layout 3 colonnes desktop, stack mobile. La card avec `highlight: true` a un ring purple et un badge "Populaire" en haut. CTA via `<Link>` Next.js. Aucun state interne, pur composant de présentation."

Exemple 2 : debugging

Avant :

"ça marche pas"

Après :

"Quand j'appelle `POST /api/checkout` avec le payload ci-dessous, je reçois une 500 avec ce stacktrace : [paste]. Le bug est apparu après le merge du PR #142. Le code concerné est dans `api/checkout/index.ts` lignes 45-78. Analyse, hypothèse, fix."

Exemple 3 : ajout de feature

Avant :

"ajoute du dark mode"

Après :

"Ajoute un dark mode au projet. Stack actuelle : Next.js 15 + Tailwind CSS + shadcn/ui. Utilise `next-themes` (`v0.3.0+`), toggle dans le header existant à `components/Header.tsx`. Les variables CSS Tailwind sont déjà préparées dans `globals.css` (mode class). Garder le SSR sans flash (`suppressHydrationWarning` sur `<html>`). Tester sur 5 pages clés."

Exemple 4 : refactor

Avant :

"nettoie ce fichier"

Après :

"Refactor `hooks/useDashboard.ts` (200 lignes) en séparant : (1) la logique de fetching dans un hook `useDashboardData`, (2) la logique de filtres dans `useDashboardFilters`, (3) la logique de pagination dans `useDashboardPagination`. Le composant qui utilise `useDashboard` doit garder la même signature publique. Tests existants doivent passer sans modification."

Exemple 5 : génération de tests

Avant :

"ajoute des tests"

Après :

"Génère des tests Vitest pour `utils/sanitizer.ts`. Couvre les cas : input vide, input null, HTML simple, HTML imbriqué malicieux (`<script>`, `onerror`), input Unicode. Mock pas nécessaire (fonction pure). Cible 100 % branches. Place les tests dans `utils/sanitizer.test.ts`."

Exemple 6 : migration

Avant :

"passe en typescript"

Après :

"Migre les fichiers du dossier `src/utils/` (7 fichiers `.js`) en TypeScript. Étapes : (1) renommer en `.ts`, (2) ajouter les types des paramètres et retours, (3) résoudre les implicit any, (4) vérifier que `tsc --noEmit` passe. Tu peux utiliser `unknown` quand le type est vraiment dynamique, mais préfère des types précis. Ne touche pas aux autres dossiers."

Exemple 7 : optimisation perf

Avant :

"c'est lent"

Après :

"La page `/dashboard` a un LCP de 4.2s d'après Lighthouse. Cibler 2.0s. Analyse via le Network tab que je décris : [paste résumé]. Hypothèses à explorer en ordre : (1) bundle JS trop gros, (2) requêtes API en cascade, (3) images non optimisées. Propose un plan d'action priorisé par impact estimé."

Exemple 8 : intégration API tierce

Avant :

"intègre Stripe"

Après :

"Intègre Stripe Checkout côté Next.js (App Router) pour vendre un seul produit à 49€. Étapes : (1) endpoint `POST /api/checkout/session` qui crée une Checkout Session, (2) bouton "Acheter" sur la landing qui redirige, (3) page `/success` et `/cancel`. Webhook `POST /api/webhooks/stripe` qui écoute `checkout.session.completed` et persiste en DB. Utilise la lib `stripe` (`v17+`), `STRIPE_SECRET_KEY` dans `.env.local`."

Exemple 9 : documentation

Avant :

"écris la doc"

Après :

"Génère un `README.md` pour ce projet. Structure : (1) titre + tagline, (2) install (npm install + .env exemple), (3) commandes (dev, build, test), (4) architecture (5 lignes max, qu'est-ce que les principaux dossiers), (5) déploiement. Pas de section "contributors" ni "license" — je les ajouterai. Ton : direct, pas marketing, exemples concrets."

Exemple 10 : code review

Avant :

"review mon code"

Après :

"Review le diff du PR ci-dessous. Critères : (1) bugs potentiels, (2) violations des conventions du projet (voir `CLAUDE.md`), (3) opportunités de simplification sans sur-engineering, (4) tests manquants. Pour chaque point, indique le fichier, la ligne, la sévérité (blocking / nice-to-have), et propose un fix concret."

7 erreurs de prompting à éviter {#erreurs}

Erreur 1 : prompter sans CLAUDE.md

Sans CLAUDE.md, vous répétez le contexte à chaque session : stack, conventions, structure du projet. C'est épuisant et coûteux en tokens. Voir la section [CLAUDE.md ci-dessous](#claude-md).

Erreur 2 : être vague sur l'acceptation

"Améliore le truc" laisse Claude Code deviner. Donnez toujours un critère mesurable : "Le test X doit passer", "Lighthouse > 90", "Aucun import circulaire", etc.

Erreur 3 : trop demander d'un coup

Un prompt qui demande "ajoute le auth + le pricing + le dashboard" déraille toujours. Découpez en 3 prompts successifs. Mieux : utilisez un sous-agent par sujet (voir notre guide [sous-agents Claude Code](/blog/claude-code-sub-agents-guide-pratique-2026)).

Erreur 4 : oublier les contraintes négatives

"Ajoute l'auth" peut faire installer NextAuth, Clerk, Lucia, Auth0... Précisez : "Ajoute l'auth avec NextAuth v5, pas avec une autre lib".

Erreur 5 : ne pas exploiter les modes thinking

Sur les tâches d'architecture, demandez "thinking high". Sur les tâches triviales, "thinking off". Adapter le mode au sujet économise tokens et temps. Voir notre article [commandes Claude Code voice/loop/effort](/blog/commandes-claude-code-voice-loop-effort).

Erreur 6 : prompter en anglais quand le projet est en français

Si votre projet, votre code, votre équipe parlent français, prompter en anglais introduit de la friction. Claude est aussi bon en français qu'en anglais depuis Claude 3.5. Restez cohérent.

Erreur 7 : pas de retour quand ça fonctionne

Si Claude Code produit une excellente solution, dites-le explicitement : "Parfait, garde cette approche pour les composants similaires." Cette info sert pour la suite de la session — et peut être ajoutée au CLAUDE.md.

Patterns avancés : few-shot, role-play, chain-of-thought {#avances}

Pattern 1 : few-shot prompting

Donnez 2-3 exemples du résultat attendu avant la nouvelle tâche.

Voici comment je nomme les commits dans ce projet :
- "feat: add pricing page"
- "fix: dashboard 500 on empty user"
- "chore: bump deps to react 19"

Maintenant, génère le message de commit pour ce diff : [paste]

Pattern 2 : role-play (avec parcimonie)

Donner un rôle à Claude peut aider sur des tâches qui demandent un angle particulier.

Tu es un security engineer senior qui review du code Node.js.
Critère unique : vulnérabilités OWASP Top 10.
Review ce fichier en priorité décroissante de risque.

Attention : le role-play est utile mais surutilisé. Pour 90 % des tâches, un prompt CRAFT bien construit suffit, sans avoir besoin de "tu es un expert X".

Pattern 3 : chain-of-thought

Demandez explicitement à Claude de réfléchir étape par étape avant de coder.

Avant d'écrire le code, liste en 3 bullets : (1) les hypothèses que tu fais sur la stack,
(2) les 2 approches que tu vois, (3) laquelle tu choisis et pourquoi.
Ensuite seulement, propose le code.

Sur les tâches complexes, ce pattern réduit drastiquement les itérations.

Pattern 4 : décomposition explicite

Décompose la tâche "implémenter le checkout Stripe" en 5 étapes ordonnées.
Pour chaque étape, indique : fichier impacté, durée estimée, test de validation.
Je validerai chaque étape avant de passer à la suivante.

C'est le pattern Spec-Driven Development qu'on détaille dans notre guide [Spec-Driven Development avec Claude Code](/blog/spec-driven-development-claude-code-methode-2026).

Le CLAUDE.md : votre prompt système permanent {#claude-md}

Le fichier CLAUDE.md à la racine de votre projet est lu à chaque session de Claude Code. C'est l'endroit où mettre tout ce que vous répéteriez sinon dans chaque prompt.

Structure type d'un bon CLAUDE.md

# Project: PodcastFlow

## Stack
- Next.js 15 (App Router)
- TypeScript strict mode
- Tailwind CSS + shadcn/ui
- Drizzle ORM + Postgres
- Auth via NextAuth v5
- Déployé sur Vercel

## Conventions
- Composants : PascalCase, export nommé (pas default)
- Hooks : préfixe "use", dans `/hooks`
- API routes : `app/api/[ressource]/route.ts`
- Pas de `any`, utiliser `unknown` puis narrowing

## Tests
- Vitest pour unit + integration
- Playwright pour E2E (`tests/e2e/`)
- Toujours mocker les appels externes (Stripe, email)

## Commandes
- `npm run dev` : dev local sur :3000
- `npm test` : tous les tests
- `npm run lint:fix` : auto-fix lint

Règles d'or pour le CLAUDE.md

Pour un guide complet sur le CLAUDE.md et la gestion du contexte, voir [Claude Code gérer le contexte (compact, context rot)](/blog/claude-code-gerer-contexte-compact-context-rot-2026).

Pour une démonstration des techniques de prompting avancées en pratique, regardez cette vidéo récente.

Le prompting en équipe : partager ses bonnes pratiques

Dans une équipe, le prompting consistent entre les membres devient un sujet à part. Trois pratiques qui fonctionnent en 2026 :

1. CLAUDE.md versionné

Le CLAUDE.md est dans le repo Git comme n'importe quel fichier. Toute l'équipe l'enrichit via PR. C'est devenu un fichier aussi important que package.json.

2. Banque de prompts partagée

Créez un dossier docs/prompts/ dans le repo où chaque membre commit ses meilleurs prompts (avec contexte d'usage). En 3 mois, vous aurez une bibliothèque de 30-50 prompts réutilisables.

3. Rituel "prompt review"

Une fois par sprint, l'équipe partage ses 2-3 meilleurs prompts de la période. C'est un moyen rapide de niveler le niveau de l'équipe, et de détecter les patterns qui méritent d'être codifiés dans le CLAUDE.md.

C'est exactement ce que fait l'équipe de [formation-openclaw.com](https://formation-openclaw.com) qui s'est structurée autour de Claude Code dès le démarrage du projet — ils ont un dossier prompts/ versionné avec plus de 80 prompts réutilisables.

FAQ prompting Claude Code {#faq}

Faut-il prompter en français ou en anglais ?

Choisissez la langue de votre projet. Si votre code et votre équipe sont en français, restez en français — Claude maîtrise les deux langues équivalemment depuis Claude 3.5. Mélanger les deux dans une même session ajoute du bruit sans bénéfice. Exception : les noms de variables et la doc technique restent toujours en anglais, comme dans le code.

Combien de mots un bon prompt doit-il faire ?

Pour une tâche simple : 50 à 100 mots suffisent. Pour une tâche complexe : 150 à 400 mots. Au-delà, c'est généralement le signe que vous devriez découper la tâche en plusieurs prompts ou utiliser un sous-agent. Le CLAUDE.md permet justement de réduire la taille de chaque prompt en factorisant le contexte permanent.

Le prompting Claude Code est-il différent du prompting Claude.ai ?

Oui, sur un point clé : avec Claude Code, vous agissez sur des fichiers réels, donc la précision des chemins, conventions, et patterns du projet est critique. Claude.ai en chat fonctionne plus comme un assistant général. Pour Claude Code, investissez dans le CLAUDE.md — c'est le facteur 10x du prompting.

Comment savoir si mon prompt est bon ?

Un bon prompt produit un résultat exploitable en une seule itération dans 80 % des cas. Si vous devez systématiquement ajouter "non, plutôt X", "tu as oublié Y", c'est que le prompt initial manquait de contexte ou d'acceptance criteria. Tenez un mini-journal de vos 20 derniers prompts pour identifier les patterns qui marchent.

Faut-il connaître toutes les commandes Claude Code (/compact, /clear, etc.) ?

Pas immédiatement. Les trois plus utiles sont /compact (réduire le contexte), /clear (repartir d'une session vierge dans la même conversation), et /cost (voir les tokens consommés). Voir notre article [commandes Claude Code voice/loop/effort](/blog/commandes-claude-code-voice-loop-effort) pour le détail.

Les prompts d'autres devs sont-ils transférables à mon projet ?

Partiellement. La structure est transférable (CRAFT, few-shot, chain-of-thought), mais le contenu (stack, conventions) doit être adapté. Ne copiez jamais un prompt complet sans l'adapter à votre contexte, sinon Claude Code peut produire du code stylistiquement incompatible avec votre codebase.

Peut-on automatiser la création de bons prompts ?

Partiellement, oui. Anthropic propose un Prompt Generator dans la console (console.anthropic.com/dashboard) qui transforme une intention vague en prompt structuré. Utile pour démarrer, mais le prompt généré demande presque toujours un travail d'adaptation manuel — l'outil ne connaît pas votre projet.

Conclusion

Un bon prompt Claude Code est court, précis, structuré (CRAFT : Context, Request, Acceptance, Format, Thinking). Investir 4-5 heures à pratiquer cette méthode triple votre productivité en 2 semaines — c'est l'un des plus gros ROI accessibles aux développeurs en 2026.

Les 3 priorités absolues : (1) écrire un CLAUDE.md clair et concis, (2) toujours préciser le critère d'acceptance dans le prompt, (3) découper les grosses tâches en plusieurs prompts successifs. Le reste — patterns avancés, few-shot, role-play — vient ensuite.

Pour passer du prompting "bon" au prompting "expert", la pratique encadrée fait toute la différence. La [formation Claude Code complète](https://go.saas-ia.io/se-faire-remplacer-par-lia) consacre un module entier au prompting avancé avec corrections personnalisées de vos prompts réels.

Articles connexes