L'art du prompting
Ton CLAUDE.md donne à Claude le contexte de ton projet. Maintenant, voyons comment lui parler efficacement pour obtenir le meilleur résultat à chaque prompt.
La règle d'or
Montre ton prompt à un collègue qui ne connaît pas le projet. S'il est perdu, Claude le sera aussi.
C'est le test ultime d'un bon prompt. Claude est comme un développeur brillant mais nouveau dans ton équipe : il n'a aucun contexte sur tes conventions, ton architecture ou tes préférences. Plus tu es explicite, meilleur est le résultat.
Anatomie d'un prompt qui échoue
Avant d'apprendre les bonnes pratiques, regardons ce qui se passe quand on écrit un prompt trop vague. Voici un cas réel sur LaunchList.
Le prompt vague qui fait perdre 45 minutes
/api/checkout au lieu d'une Server Action, utilisé Stripe.js côté client au lieu de Stripe Checkout, et n'a pas ajouté la vérification de signature du webhook. Résultat : 3 fichiers à supprimer, une architecture à reprendre, et 45 minutes perdues.Voici le même besoin, exprimé correctement :
Le prompt corrigé
Tu es un développeur full-stack spécialisé en Next.js et Stripe.
CONTEXTE :
LaunchList est une app Next.js 16 avec Drizzle ORM et Better-Auth.
Les utilisateurs créent des waitlists payantes. Le schéma Drizzle
a déjà une table "reservations" avec les colonnes stripeSessionId
et status. Stripe est configuré avec les clés dans .env.
OBJECTIF :
Ajouter le paiement par Stripe Checkout pour rejoindre une waitlist.
CONTRAINTES :
- Utiliser une Server Action (pas d'API Route) pour créer la session Checkout
- Utiliser Stripe Checkout (redirect), pas Stripe.js côté client
- Ajouter un webhook /api/webhooks/stripe avec vérification de signature
- Le webhook met à jour le statut de la réservation dans la base
- Suivre le pattern existant dans src/app/dashboard/actions.ts
RÉSULTAT :
- src/app/[slug]/actions.ts (Server Action createCheckoutSession)
- src/app/api/webhooks/stripe/route.ts (handler webhook)
- Modifier src/app/[slug]/page.tsx (bouton "Réserver ma place")
La différence : le premier prompt a généré du code inutilisable. Le second a produit exactement ce qu'il fallait, du premier coup. Le temps investi dans un bon prompt est toujours rentable.
Les 5 principes fondamentaux
1. Donne du contexte
Explique la situation actuelle, pas juste ce que tu veux. Claude performe mieux quand il comprend le pourquoi derrière ta demande.
Prompt
Mauvais :
"Ajoute un bouton sur la page dashboard"
Bon :
"Ajoute un bouton 'Exporter CSV' sur la page /dashboard de LaunchList
qui télécharge la liste des inscrits à une waitlist au format CSV.
Le bouton doit être visible uniquement par le owner de la waitlist.
Utilise une Server Action et le header Content-Disposition."
Le premier prompt laisse Claude deviner quel bouton, où, et pour quoi. Le second lui donne tout ce dont il a besoin.
2. Sois spécifique sur le résultat attendu
Décris le format de sortie, les fichiers à modifier, les contraintes techniques. Plus c'est précis, moins Claude improvisera.
Prompt
Mauvais :
"Améliore la query du dashboard"
Bon :
"Refactorise la query Drizzle dans src/app/dashboard/page.tsx pour :
- Ajouter le calcul du revenu par waitlist (somme des réservations)
- Ajouter la gestion des erreurs avec try/catch
- Retourner un objet { data, error } au lieu de throw"
3. Découpe les tâches complexes
Une tâche = un prompt. Les instructions séquentielles (listes numérotées) aident Claude à ne rien oublier.
Prompt
Mauvais :
"Crée un système d'authentification complet avec email,
Google, GitHub, protection des routes et gestion des rôles"
Bon :
"Commençons par l'authentification.
Étape 1 : Configure Better-Auth avec le provider email/password.
On fera les autres providers ensuite."
Pour les tâches vraiment complexes (refactoring multi-fichier, nouvelle feature majeure), utilise le Plan Mode (Shift+Tab x2) pour que Claude analyse et planifie avant de coder. On couvre cette technique en détail dans la page Les modes de Claude Code.
4. Donne un rôle à Claude
Une seule phrase de contexte sur le rôle active les connaissances pertinentes et améliore la qualité de la réponse.
Prompt
Sans rôle :
"Regarde la page de waitlist et dis-moi si c'est bien"
Avec rôle :
"Tu es un senior security engineer spécialisé en applications web Next.js.
Analyse src/app/[slug]/page.tsx pour les vulnérabilités OWASP Top 10.
Concentre-toi sur l'injection SQL via les query params,
le XSS dans l'affichage du nom de waitlist,
et la vérification d'autorisation sur les actions."
Le rôle n'est pas du roleplay : c'est un mécanisme qui guide Claude vers le bon domaine d'expertise. "Tu es un expert en performance React" produira une analyse différente de "Tu es un expert en accessibilité."
5. Dis ce qu'il faut faire (pas ce qu'il ne faut PAS faire)
La formulation positive fonctionne mieux. "Fais X" est une instruction plus claire que "Ne fais pas Y", car elle ne laisse pas de place a l'interprétation.
Prompt
Formulation négative :
"Ne mets pas de commentaires inutiles.
N'utilise pas de librairies externes.
Ne crée pas de fichiers supplémentaires."
Formulation positive :
"Ajoute des commentaires uniquement pour la logique métier non évidente.
Utilise uniquement les dépendances déjà installées dans package.json.
Modifie exclusivement les fichiers existants."
Structure d'un bon prompt
Deux formats fonctionnent bien selon la complexité de ta demande.
Format simple (prompts courts)
Pour les demandes directes, structure ton prompt en 4 blocs :
Format simple
CONTEXTE :
La page /dashboard de LaunchList affiche les waitlists
de l'utilisateur connecté avec le nombre d'inscrits.
OBJECTIF :
Ajouter un badge de statut (active/paused/closed) sur chaque carte.
CONTRAINTES :
- Le statut vient de la colonne "status" dans la table waitlists
- Utiliser les couleurs : vert (active), jaune (paused), gris (closed)
- Style cohérent avec les badges existants dans src/components/ui
RÉSULTAT :
Modifier src/app/dashboard/WaitlistCard.tsx uniquement.
Format XML (prompts complexes)
Pour les demandes complexes, les balises XML (<context>, <instructions>, etc.) permettent à Claude de distinguer clairement les instructions du contexte et des données. C'est particulièrement utile quand ton prompt contient du code ou des exemples.
Format XML
<context>
LaunchList - app Next.js 16 avec Drizzle ORM et Better-Auth.
La page /dashboard affiche les waitlists avec leurs stats.
Le schéma a une table "waitlists" avec les colonnes :
name, slug, status, userId, createdAt.
</context>
<instructions>
Ajoute la pagination sur la page dashboard.
1. 10 waitlists par page
2. Boutons Précédent/Suivant
3. Afficher "Page X sur Y"
</instructions>
<constraints>
- Utiliser les Server Components
- Pas de librairie externe, juste les query params
- Style cohérent avec le reste de l'app (Tailwind)
</constraints>
<output>
Modifie uniquement src/app/dashboard/page.tsx.
</output>
Le module Prompting avancé (Premium) va plus loin : few-shot prompting, prompting agentique (Claude investigue et corrige un bug en autonomie), auto-vérification, et surtout comment structurer ton CLAUDE.md comme outil de prompting permanent.
Itérer efficacement
Un bon prompt donne rarement un résultat parfait du premier coup. La vraie compétence, c'est de savoir itérer de manière précise et additive. Chaque itération doit être un ajustement ciblé, pas une remise à zéro.
Voici un échange complet sur LaunchList pour créer le composant WaitlistCard :
Prompt initial
Crée un composant WaitlistCard dans src/components/WaitlistCard.tsx
pour afficher une waitlist sur le dashboard.
Props : name (string), slug (string), subscriberCount (number),
revenue (number), createdAt (Date).
Affiche le nom, le nombre d'inscrits, le revenu total en euros,
et la date de création. Utilise Tailwind CSS, style card avec
border et shadow-sm.
Itération 1 : ajouter le badge de statut
Bien. Ajoute un badge de statut en haut à droite de la carte.
La prop status est de type "active" | "paused" | "closed".
Couleurs : vert pour active, jaune pour paused, gris pour closed.
Utilise un span avec rounded-full et des classes Tailwind.
Itération 2 : ajuster le sparkline
Le sparkline prend trop de place. Réduis sa hauteur à 32px
et déplace-le en bas de la carte, sous les stats.
Garde la même largeur (100% de la carte).
Itération 3 : ajouter le skeleton loader
Ajoute un composant WaitlistCardSkeleton dans le même fichier,
exporte-le aussi. Il doit avoir la même structure que WaitlistCard
mais avec des blocs animate-pulse en gris. Utilise-le comme
fallback dans le Suspense du dashboard.
Remarque le pattern : chaque itération est précise (un seul changement), additive (elle construit sur le résultat précédent), et spécifique (elle décrit exactement le rendu attendu). Évite les prompts comme "c'est pas terrible, refais" qui obligent Claude à deviner ce qui ne va pas.
Claude Code garde le contexte de la conversation. Réfère-toi aux échanges précédents au lieu de tout répéter. Si la conversation devient trop longue, utilise /compact pour résumer.
Commandes utiles
| Commande | Utilisation |
|---|---|
/clear | Réinitialiser le contexte (nouvelle tâche = nouvelle session) |
/compact | Résumer la conversation quand elle devient longue |
Escape x2 | Éditer le dernier prompt |
Shift+Tab x2 | Activer le Plan Mode avant une tâche complexe |
Checklist
Avant de passer à la page suivante, vérifie que tu sais :
- Structurer un prompt avec contexte, objectif, contraintes et résultat attendu
- Donner un rôle pertinent à Claude pour cibler son expertise
- Itérer de manière précise et additive sur un résultat
Prochaine étape
Tu maîtrises les bases du prompting. Il est temps de mettre tout ça en pratique avec ton premier projet.