Guide 1 · 10 pages
Bien prompter avec Claude (chat)
Dix principes pour transformer une demande floue en une réponse précise et utile. Chaque page contient une leçon complète (pourquoi ça compte, comment faire, ce qu'il faut éviter), un exemple Avant / Après, puis un court quiz pour vérifier que tu as bien compris.
Sois clair et précis
Dis exactement ce que tu veux : un prompt vague donne une réponse vague.
La leçon
Claude ne lit pas dans tes pensées : il répond à ce que tu écris, pas à ce que tu avais en tête. Quand la demande est large, il doit choisir lui-même l'angle, le niveau de détail et la longueur — et il tombe rarement pile sur ce que tu voulais.
Comment faire : précise le sujet exact, l'angle, le public visé et, si possible, le nombre d'éléments attendus. « Explique le marketing » devient « explique en 5 points les bases du marketing digital pour une petite boutique de bijoux ». Chaque détail ajouté réduit le nombre d'allers-retours nécessaires.
À éviter : les demandes en un mot (« marketing ? ») et les formules creuses (« sois utile », « fais au mieux ») qui n'apportent aucune information exploitable.
Parle-moi du marketing.
Donne le contexte et l'objectif
Explique qui tu es, pour qui c'est, et pourquoi.
La leçon
La même tâche change complètement de résultat selon la situation. « Écris un e-mail » n'aura pas la même forme si tu es élève ou directeur, si tu écris à un ami ou à un client, si le but est de t'excuser ou de convaincre.
Comment faire : donne en une phrase ton rôle, ton destinataire et ton intention. « Je suis chef de projet, j'écris à mon équipe de 5 personnes pour reporter une réunion, ton chaleureux mais professionnel. » Avec ça, Claude ajuste le vocabulaire, le ton et le niveau de détail tout seul.
À retenir : ce qui est évident pour toi ne l'est pas pour Claude tant que tu ne l'écris pas. Le contexte n'est jamais du temps perdu.
Écris un e-mail pour annuler une réunion.
Précise le format, le ton et la longueur
Demande la forme exacte du résultat.
La leçon
Une bonne réponse au mauvais format reste inutilisable. Si tu voulais trois puces et que tu reçois deux paragraphes, tu devras recommencer. Autant fixer la forme dès le départ.
Les leviers de forme : le format (puces, tableau, paragraphe, liste numérotée), la longueur (« 15 mots max », « 100 mots », « une page »), le ton (formel, neutre, enthousiaste) et le public (« pour des collègues pressés », « pour un enfant »).
Exemple : « Résume en 3 puces de 15 mots maximum, ton neutre. » Sans ces consignes, Claude choisit à ta place — parfois bien, souvent pas exactement comme tu voulais.
Résume cet article.
Montre des exemples (few-shot)
Un ou deux exemples valent mieux qu'une longue explication.
La leçon
Montrer est souvent plus clair que décrire. Quand tu veux une sortie d'un type précis, donne un ou deux exemples du résultat attendu : Claude imite alors le format et les critères. C'est ce qu'on appelle le few-shot, l'apprentissage par l'exemple.
Comment faire : avant ta vraie demande, glisse 2–3 mini-exemples « entrée → sortie ». Pour classer des avis : « 'Livraison rapide' → Positif ; 'Ça va' → Neutre ; 'Cassé' → Négatif ». Claude comprend immédiatement tes catégories, sans longue explication.
Quand c'est le plus utile : le tri, l'étiquetage, la mise en forme répétitive, et le respect d'un style « maison » que tu aurais du mal à décrire avec des mots.
Classe ces avis clients.
Donne un rôle à Claude
Préciser une perspective oriente le style et la profondeur.
La leçon
Demander une perspective oriente d'un coup le style, le vocabulaire et la profondeur. « Relis mon texte » est vague ; « agis comme un correcteur d'édition exigeant » fixe un niveau d'attente et un angle d'analyse.
Comment faire : commence par « Agis comme… » ou « Tu es… », puis donne la mission précise. « Agis comme un professeur de physique qui explique à un lycéen » produira des explications simples avec des analogies ; « agis comme un relecteur juridique » produira un regard prudent et formel.
Pourquoi ça marche : le rôle est un raccourci. Il remplace une longue description du ton voulu par une image que Claude sait incarner.
Relis mon texte.
Demande un raisonnement étape par étape
Pour les problèmes complexes, demande de réfléchir avant de conclure.
La leçon
Sur un problème qui demande de la réflexion (maths, logique, comparaison, décision), demander à Claude de montrer son raisonnement avant de conclure réduit nettement les erreurs. En déroulant les étapes, il évite les sauts logiques.
Comment faire : « Résous ce problème étape par étape, puis donne la réponse finale clairement séparée à la fin. » Tu peux ainsi suivre le cheminement et repérer où une erreur s'est éventuellement glissée.
À ne pas surutiliser : pour une question simple et factuelle (« capitale de la France ? »), une réponse directe suffit. Le pas-à-pas sert quand il y a vraiment quelque chose à raisonner.
La réponse à ce problème de logique ?
Découpe les grosses tâches
Enchaîne plusieurs prompts plutôt qu'un seul énorme.
La leçon
Une demande gigantesque en un seul bloc (« écris-moi un livre entier ») donne souvent un résultat moyen partout : Claude doit tout tenir à la fois et ne peut s'appuyer sur tes retours en cours de route.
Comment faire : avance par étapes. Demande d'abord un plan, valide-le, puis fais rédiger partie par partie. À chaque étape tu vérifies, tu corriges, et la qualité finale grimpe nettement.
Exemple : « Étape 1 : propose un plan en 8 chapitres pour un guide débutant. On rédigera ensuite chapitre par chapitre. » Le plan sert de squelette commun avant d'écrire le contenu.
Écris-moi un livre complet sur la cuisine italienne.
Structure ton prompt
Sépare le contexte, la tâche et les contraintes.
La leçon
Quand tout est jeté dans un même paragraphe, Claude peut confondre une consigne importante avec un simple détail. Séparer les parties l'aide à lire ta demande sans rien rater.
Comment faire : utilise des titres ou des balises pour délimiter chaque bloc : <contexte>…</contexte>, <tache>…</tache>, <contraintes>…</contraintes>. Claude repère alors clairement « voici la situation », « voici ce qu'il faut faire », « voici les limites à respecter ».
Quand l'utiliser : dès que ta demande dépasse deux ou trois lignes ou contient plusieurs contraintes. Pour une question courte, ce n'est pas nécessaire.
Formule en positif
Dis ce qu'il faut faire, pas seulement ce qu'il faut éviter.
La leçon
« Ne fais pas X » dit à Claude ce qu'il faut éviter, mais le laisse libre pour tout le reste — y compris des choses que tu ne voulais pas non plus. Une consigne positive décrit directement le résultat visé, donc elle est plus facile à suivre.
Comment faire : transforme l'interdiction en objectif concret. « N'utilise pas de jargon » devient « écris dans un langage simple qu'un lycéen comprend, et remplace chaque terme technique par une explication courte ». Tu obtiens exactement ce que tu cherches.
Le bon équilibre : garde les interdictions pour les vraies limites (« ne dépasse pas 200 mots ») et exprime le reste en positif.
N'utilise pas de jargon.
Itère : corrige au lieu de tout réécrire
Affine par petites touches plutôt que de recommencer de zéro.
La leçon
La première réponse est rarement parfaite, et c'est normal : prompter est un dialogue, pas un coup unique. Recommencer un prompt entier à chaque fois te fait perdre ce qui marchait déjà.
Comment faire : garde la base et demande des retouches ciblées. « C'est presque ça ; raccourcis le 2ᵉ paragraphe et ajoute un exemple chiffré, garde le reste. » Les petites corrections successives convergent vite vers ce que tu veux.
Cas des faits : pour une info récente ou un chiffre précis, ne suppose pas que Claude la connaît. Fournis la donnée toi-même, ou demande-lui de la vérifier. Cela évite les approximations.
(repartir d'un prompt entièrement neuf à chaque essai)
Guide 2 · 10 pages
Bien prompter avec Claude Code (Opus 4.8)
« Claude Code 4.8 » désigne Claude Code propulsé par le modèle Opus 4.8. Contrairement au chat, c'est un agent qui lit tes fichiers, exécute des commandes et modifie le code. Dix pratiques issues de la documentation officielle, chacune avec sa leçon et son quiz.
Raisonne « agent », pas « chatbot »
Tu décris l'objectif ; Claude Code explore, planifie, modifie les fichiers et exécute des commandes.
La leçon
Un chatbot répond à une question et attend la suivante. Claude Code, propulsé par Opus 4.8, est différent : c'est un agent qui lit ton dépôt, lance des commandes, écrit et modifie des fichiers, et avance seul vers un objectif pendant que tu surveilles — ou que tu t'éloignes.
Ce que ça change pour toi : tu n'écris plus le code pour le faire relire. Tu décris le résultat voulu, et Claude explore, planifie et implémente. La bonne formulation n'est donc pas « comment ajouter OAuth ? » mais « ajoute OAuth : explore d'abord src/auth, propose un plan, puis implémente ».
À garder en tête : cette autonomie est puissante mais se pilote. Tu peux l'interrompre et le rediriger à tout moment.
Comment ajouter une authentification Google ?
Gère le contexte (la ressource n°1)
La fenêtre de contexte se remplit vite et la qualité baisse quand elle est pleine.
La leçon
Presque toutes les bonnes pratiques découlent d'une seule contrainte. La fenêtre de contexte contient tout : l'historique, chaque fichier lu, chaque sortie de commande. Or elle se remplit très vite, et plus elle est pleine, plus la qualité baisse — Claude « oublie » des consignes et fait davantage d'erreurs.
Comment faire : traite le contexte comme une ressource précieuse. Entre deux tâches sans rapport, fais /clear pour repartir propre. Au sein d'une grosse tâche, tu peux compacter l'historique avec /compact. Évite la « kitchen sink session » qui empile dix sujets différents.
Règle simple : un sujet = une session propre. Une conversation courte et ciblée bat presque toujours une longue session encombrée.
Donne-lui un moyen de vérifier son travail
Fournis un test, un build ou une capture d'écran : sinon « ça a l'air fini » est le seul signal.
La leçon
Claude s'arrête quand le travail semble fini. Sans moyen de vérifier, « ça a l'air bon » est le seul signal disponible — et c'est toi qui deviens le contrôle qualité, repérant les erreurs une par une.
Comment faire : donne-lui un signal qu'il peut lire lui-même : une suite de tests, un build, un linter, ou une capture d'écran à comparer à une maquette. La boucle se ferme alors toute seule : il code, lance le check, lit le résultat et corrige jusqu'à ce que ça passe.
Exemple : « écris validateEmail ; cas de test : user@example.com → vrai, invalid → faux ; lance les tests et corrige jusqu'au vert. » Demande aussi à voir la preuve (la sortie des tests), plutôt qu'une simple affirmation de réussite.
implémente une fonction qui valide les e-mails
Explore → Planifie → Code → Commit
Sépare la recherche de l'exécution avec le mode plan.
La leçon
Laisser Claude coder immédiatement risque de résoudre… le mauvais problème. Le mode plan (Shift+Tab deux fois) sépare la recherche de l'exécution : Claude lit le code et propose un plan sans rien modifier, tu valides, puis il implémente.
Les quatre phases : explorer (« lis src/auth et explique le flux actuel »), planifier (« propose un plan détaillé pour ajouter Google OAuth »), implémenter (en sortant du mode plan, et en vérifiant contre le plan), puis commit avec un message clair.
Quand sauter le plan : pour un correctif évident (corriger une faute, renommer une variable). Si tu peux décrire le changement en une phrase, le plan est superflu.
Donne un contexte spécifique
Référence les fichiers, pointe vers un patron existant, décris le symptôme.
La leçon
Claude infère ton intention, mais il ne lit pas dans ta tête. Plus tu es précis sur les fichiers, les patrons à imiter et le symptôme, moins tu auras de corrections à faire.
Trois réflexes : référence les fichiers avec @ (« regarde @src/auth/login.ts ») pour que Claude les lise avant de répondre ; pointe vers un exemple existant à imiter (« suis le patron de @components/Button.tsx ») ; pour un bug, décris le symptôme, l'endroit probable et ce que « corrigé » signifie.
Exemple : « login KO après expiration de session : vois @src/auth/, surtout le rafraîchissement de token ; écris un test qui reproduit le bug, puis corrige. » Tu peux aussi coller des captures d'écran et donner des URLs de documentation.
corrige le bug de login
Écris un bon CLAUDE.md
Un fichier court, lu à chaque session, avec ce que Claude ne peut pas deviner.
La leçon
CLAUDE.md est un fichier spécial que Claude lit au début de chaque conversation. Il lui donne le contexte qu'il ne peut pas deviner en lisant le code : commandes du projet, conventions de style particulières, étiquette du dépôt, pièges connus.
Comment faire : lance /init pour générer une base à partir de ton projet, puis affine. Inclus ce qui est indevinable (« lance le typecheck après une série de changements ») ; exclus les évidences et tout ce que Claude trouve déjà en lisant le code.
La règle d'or : reste court. Un CLAUDE.md trop long produit l'effet inverse : noyé dans le bruit, Claude en ignore une partie et rate tes vraies consignes. Pour chaque ligne, demande-toi : « est-ce que la retirer ferait faire une erreur à Claude ? » Sinon, coupe-la.
Configure les permissions
Réduis les interruptions sans perdre le contrôle.
La leçon
Par sécurité, Claude Code demande la permission avant toute action qui modifie ton système : écriture de fichier, commande shell, outil externe. C'est rassurant, mais après la dixième validation tu ne lis plus vraiment : tu cliques.
Trois moyens d'alléger, sans perdre le contrôle : le mode auto, où un classifieur ne bloque que ce qui paraît risqué (escalade de droits, infrastructure inconnue) ; les listes d'autorisation via /permissions, pour autoriser des commandes sûres comme npm run lint ; le sandbox, qui isole Claude au niveau du système pour qu'il travaille librement dans des limites définies.
Exemple : claude --permission-mode auto -p "corrige toutes les erreurs de lint". Tu choisis toi-même le curseur entre tranquillité et surveillance.
(cliquer « autoriser » 30 fois de suite sans plus rien lire)
Corrige tôt et souvent
Des boucles de feedback serrées battent les longues sessions polluées.
La leçon
Les meilleurs résultats viennent de boucles de feedback serrées. Plutôt que de laisser Claude s'enfoncer dans une mauvaise voie, reprends la main dès qu'il dévie.
Les outils : Esc stoppe l'action en cours en conservant le contexte ; Esc + Esc ou /rewind ouvrent un menu pour revenir à un état précédent (conversation et/ou code) ; « annule ça » lui fait défaire son dernier changement ; /clear remet le contexte à zéro.
La règle des deux corrections : si tu as corrigé deux fois le même point sans succès, le contexte est pollué d'approches ratées. Fais /clear et repars d'un prompt plus précis intégrant ce que tu as appris. Une session propre l'emporte presque toujours.
Délègue aux sous-agents
Investigation et revue dans un contexte séparé, pour garder le tien propre.
La leçon
Le contexte étant ta ressource la plus rare, les sous-agents sont parmi les outils les plus utiles. Quand Claude explore un dépôt, il lit beaucoup de fichiers qui remplissent ta fenêtre. Un sous-agent explore dans un contexte séparé et te renvoie seulement un résumé : ta conversation principale reste propre.
Deux usages : l'investigation (« utilise des sous-agents pour étudier comment notre système gère le rafraîchissement de token ») et la revue. Un relecteur en contexte frais ne voit que le diff et tes critères : il juge sans le biais d'avoir écrit le code lui-même.
Astuce : la compétence /code-review fait exactement cela. Précise au relecteur de ne signaler que les écarts de correction, pas les préférences de style, pour éviter le sur-zèle.
Évite les pièges, développe ton intuition
Reconnaître les erreurs classiques fait gagner un temps fou.
La leçon
Cinq pièges reviennent sans cesse — voici chacun avec son remède :
- La kitchen sink session (sujets mélangés dans une session) → /clear entre tâches sans rapport.
- Les corrections en boucle → après deux échecs, /clear et un meilleur prompt initial.
- Le CLAUDE.md trop long → élaguer sans pitié pour que les vraies règles ressortent.
- La confiance sans vérification → toujours fournir tests ou captures ; si tu ne peux pas vérifier, ne livre pas.
- L'exploration infinie → cadrer le périmètre, ou déléguer à un sous-agent.
Enfin : ces règles sont des points de départ, pas des lois. Observe ce qui marche pour toi — quand une session réussit, note pourquoi ; quand elle patine, demande-toi si le contexte était trop chargé ou le prompt trop vague. Ton intuition se construira avec la pratique.