Parler à Claude

Structure de base d'un prompt

Un appel à Claude est composé de trois blocs, dont un seul est obligatoire :

• System prompt (facultatif) : qui est Claude, son rôle, ses règles. Le socle permanent.
• Messages User / Assistant : la conversation, en alternance. Le message User est obligatoire.
• La réponse de Claude complète le dernier tour.

Le principe fondateur derrière tout le reste : les modèles récents suivent des instructions explicites, ils ne devinent pas. Si vous souhaitez un format, une longueur, un ton, une langue : dites-le. N'attendez pas que le modèle infère votre intention.

Mauvais : "parle-moi des outils Sept-Tools". Mieux : "Liste les 5 familles de produits Sept-Tools, une phrase par famille, en français, sans introduction."

Etre clair et direct

Traitez Claude comme un brillant nouvel employé sans contexte : capable, mais qui ne connaît ni votre entreprise, ni vos conventions, ni ce que vous avez en tête. Tout ce que vous ne dites pas, il doit le deviner, et il se trompera parfois.

Trois leviers concrets :

• Donnez le contexte de la tâche : à quoi sert le résultat, qui va le lire, dans quel cadre.
• Soyez séquentiel : si l'ordre compte, numérotez les étapes.
• Dites ce que vous voulez, pas ce que vous ne voulez pas quand c'est possible : "réponds en 3 phrases" vaut mieux que "ne sois pas trop long".

Test mental imparable : montrez votre prompt à un collègue. S'il a besoin de poser une question pour l'exécuter, le modèle aussi. Comblez le manque.

Attribuer un rôle (system prompt)

Donner à Claude un rôle via le system prompt modifie la qualité de base et le ton des réponses. "Tu es un expert en sécurité applicative qui audite du code PHP WooCommerce" oriente tout le vocabulaire, le niveau de détail et les priorités des réponses qui suivent.

Pourquoi ça marche : vous déplacez le modèle vers la région du langage où vivent les bons experts. Un rôle bien choisi vaut souvent plusieurs paragraphes d'instructions.

Bonnes pratiques :

• Placez le rôle dans le system prompt, pas enfoui dans le message utilisateur.
• Soyez spécifique : "rédacteur technique pour un public sécurité non technique" vaut mieux que "écris bien".
• Combinez rôle + mission + contraintes : "Tu es X. Ta mission est Y. Règles : Z."

C'est exactement ce que fait le mode Frankenstein de Pierre, mais poussé à l'extrême : un system prompt composé qui assemble plusieurs personnalités d'experts. Nous le disséquerons dans le module 6.

Séparer les données des instructions (XML)

Quand votre prompt mélange vos instructions et les données à traiter, le modèle confond les deux : il prend un morceau de texte à analyser pour une instruction, ou l'inverse. La solution canonique avec Claude : les balises XML.

Claude est spécifiquement entraîné à respecter des balises comme <document>, <instructions>, <example>. Elles créent des frontières nettes.

<instructions>
Résumez le document ci-dessous en 3 points, pour un dirigeant très occupé.
</instructions>

<document>
{ ... le long texte à résumer, collé ici ... }
</document>

Avantages : zéro confusion données/instructions, des réponses plus fiables, et vous pouvez référencer les balises ("dans le <document>, trouvez..."). C'est LE réflexe pour tout prompt contenant un grand bloc de texte, une transcription, du code ou des données collées.

Formater la sortie et parler a la place de Claude (prefill)

Deux techniques pour contrôler la forme exacte de la réponse.

1. Spécifier le format de sortie. Demandez explicitement : JSON, tableau markdown, liste, balises. Pour un JSON robuste, décrivez le schéma attendu et précisez "retourner uniquement le JSON, sans texte autour".

2. Prefill (parler a la place de Claude). Via l'API, vous pouvez commencer vous-même le message de l'Assistant. Claude poursuivra a partir de la. C'est le moyen le plus fiable pour imposer un format.

User: Give me the 3 risks, as JSON.
Assistant: {          <-- you prefill this brace

En commençant la réponse par { ou [, vous garantissez que Claude n'ajoutera pas "Bien sûr, voici..." avant le JSON. Prefiller <analysis> force la réponse a démarrer a l'intérieur de cette balise. Très utilisé pour l'extraction automatisée et pour éliminer les préambules.

Précognition : raisonner étape par étape

Sur une tâche qui demande du raisonnement (maths, logique, décision multi-critères, débogage), demander la réponse directe donne souvent une réponse fausse. Demander à Claude de raisonner d'abord, conclure ensuite améliore nettement la précision. C'est le principe du chain-of-thought.

Pourquoi : le modèle produit du texte de façon séquentielle. En lui laissant "poser son raisonnement", on lui fournit des étapes intermédiaires sur lesquelles s'appuyer. Sans cet espace, il doit deviner la réponse en une seule passe.

Trois façons de le déclencher :

• Direct : "Réfléchis étape par étape avant de répondre."
• Structure : "D'abord, dans <reasoning>, analyse. Ensuite, dans <answer>, conclus."
• Extended thinking : les modèles récents disposent d'un mode de réflexion étendue que vous pouvez activer (un budget "thinking" avant la réponse).

Clé pratique : si vous souhaitez ensuite analyser la réponse, isolez le raisonnement dans une balise afin de ne conserver que la conclusion.

Utiliser des exemples (few-shot)

Montrer vaut mieux qu'expliquer. Donner 2 à 5 exemples entrée -> sortie (few-shot) est souvent le moyen le plus rapide d'ancrer un format, un ton, un niveau de détail, une convention de nommage.

Le modèle imite le schéma. Si vos exemples sont du JSON concis et minimal, les réponses suivront. Si vos exemples sont verbeux, les réponses le seront aussi.

Règles :

• Choisissez des exemples représentatifs, incluez un cas limite si le piège est connu.
• Soyez cohérent : même format dans chaque exemple, sinon vous enseignez l'incohérence.
• Entourez-les de balises <example> pour les distinguer de la vraie tâche.

Few-shot + rôle + format de sortie = la combinaison qui résout la plupart des tâches d'extraction et de transformation sans autre astuce.

Éviter les hallucinations

L'hallucination n'est pas un bug rare, c'est une conséquence de son fonctionnement (leçon 1.1). On ne l'élimine pas, on la contraint. La boîte à outils :

• Offrir une porte de sortie : "Si l'information ne figure pas dans le document, répondez exactement : Inconnu." Sans cela, le modèle comble le vide en inventant.
• Ancrer dans les sources : fournir le texte de référence et lui demander de citer le passage exact qui justifie chaque affirmation.
• Demander les preuves en premier : "Avant de répondre, extrayez les citations pertinentes, puis répondez uniquement à partir d'elles."
• Chercher sur le web tout fait situé à la date de coupure ou après, plutôt que de faire confiance à la mémoire d'entraînement.
• Abaisser la température pour les tâches factuelles.

La règle d'or issue de la pratique de Pierre : pour une question factuelle sur le présent, chercher sur le web bat la mémoire du modèle. C'est inscrit dans son Frankenstein prompt.

Composer des prompts complexes (cas réels)

Les prompts de production réels empilent les techniques précédentes dans un ordre stable. Un squelette qui fonctionne pour la plupart des cas sérieux :

1. ROLE         -> "Tu es un ..."
2. CONTEXTE     -> à quoi sert le résultat, qui le lit
3. DONNÉES      -> <document> ... </document> (balises)
4. INSTRUCTIONS -> la tâche, étape par étape
5. EXEMPLES     -> <example> entrée -> sortie </example>
6. THINKING     -> "raisonne dans <analysis> d'abord"
7. FORMAT       -> structure exacte de la sortie
8. GARDES-FOU   -> "si X est absent, répondre Inconnu"

Vous n'avez pas besoin des 8 à chaque fois. Le conseil officiel d'Anthropic : n'ajouter une technique avancée que lorsqu'elle résout un problème concret. Le meilleur prompt n'est ni le plus long ni le plus sophistiqué, c'est le plus clair pour la tâche.

Méthode de travail : commencer simplement, observer ce qui échoue, et ajouter la technique qui corrige précisément cet échec. Itérer. Un prompt de production se raffine, il ne se devine pas du premier coup.

Raisonnement étendu vs chaîne de pensée

Quand vous posez une question difficile à Claude, vous pouvez influencer la quantité de raisonnement qu'il vous montre. Les deux principaux modes sont la chaîne de pensée (CoT) et la pensée étendue.

La chaîne de pensée consiste à demander à Claude de raisonner étape par étape dans sa réponse. On l'active avec une simple instruction : "Réfléchis étape par étape avant de répondre." Claude écrit son raisonnement sous forme de texte visible, puis donne la réponse. Cela fonctionne dans le chat Claude.ai et dans n'importe quel appel API sans options particulières.

La pensée étendue est une fonctionnalité au niveau du modèle, disponible sur Opus et Sonnet. Lorsqu'elle est activée, le modèle utilise un bloc-notes interne (appelé bloc de pensée) avant de produire la réponse finale. Vous voyez un résumé de ce bloc-notes. La pensée étendue consomme plus de tokens (et coûte plus cher) mais elle s'attaque aux problèmes où une CoT de surface ne suffit pas, comme les mathématiques en plusieurs étapes, le débogage de code ou l'analyse juridique.

• Chaîne de pensée : vous la déclenchez par un prompt, gratuite, fonctionne partout, le raisonnement fait partie de la réponse.
• Pensée étendue (API) : ajoutez thinking: { type: "enabled", budget_tokens: N } dans l'appel API ; disponible uniquement sur claude-opus-4-8 et claude-sonnet-4-6.
• Pensée étendue (Claude.ai) : activez le bouton "Extended thinking" avant d'envoyer votre message ; non disponible sur tous les abonnements.
• Quand utiliser la CoT : explications, planification, schémas de rédaction, toute tâche courante.
• Quand utiliser la pensée étendue : démonstrations, débogage complexe, stratégie avec de nombreux compromis, partout où vous avez besoin que le modèle explore des impasses en privé avant de s'engager.

Obtenir du JSON propre en sortie

JSON (JavaScript Object Notation) est un format texte pour les données structurées : clés et valeurs, listes, objets imbriqués. De nombreux outils, applications et automatisations attendent du JSON plutôt que du texte brut. Claude peut en produire de manière fiable si vous formulez votre demande avec précision.

Les trois leviers sont : le schéma explicite (indiquer à Claude les champs et types exacts voulus), le prefill (commencer la réponse de Claude à sa place, pour le forcer à continuer dans ce format), et la validation (vérifier la sortie avant de s'y fier). Utiliser les trois ensemble rend la sortie structurée quasi infaillible.

Techniques clés :

• Schéma dans le prompt : collez ou décrivez la structure JSON exacte dont vous avez besoin, en incluant les noms de champs, les types de valeurs, et les champs obligatoires ou facultatifs.
• Prefill : via l'API, placez {"role":"assistant","content":"{"} comme dernier message pour que Claude soit obligé de continuer avec du JSON valide.
• Instruction stricte : ajoutez "Output raw JSON only. No prose before or after. No markdown code fences." dans le prompt système.
• Validation : parsez la sortie avec JSON.parse() ou un validateur de schéma comme Zod ou Pydantic avant de l'utiliser en aval.

Dans le chat Claude.ai, vous ne pouvez pas utiliser l'astuce du prefill via l'API, mais un schéma clair associé à l'instruction stricte fonctionne très bien. Pour l'automatisation ou la production, l'API avec prefill est la voie la plus sûre.

Les délimiteurs au-delà du XML

Les balises XML comme <context> sont une façon de séparer les parties d'un prompt, mais ce n'est pas la seule. Les délimiteurs sont tous les marqueurs que vous utilisez pour indiquer à Claude où une section se termine et où la suivante commence. Choisir le bon délimiteur rend votre prompt plus lisible et réduit les risques de mauvaise interprétation.

Trois familles de délimiteurs fonctionnent bien en pratique :

• Les titres Markdown (##, ###) : adaptés pour nommer des sections comme "Background", "Task" ou "Constraints". Claude est entraîné sur une grande quantité de Markdown, donc les titres lui semblent naturels.
• Les blocs de code balisés (triple accent grave) : idéaux quand vous collez du code, du JSON, du CSV ou tout texte qui doit être traité littéralement et non interprété comme des instructions.
• Les lignes de marquage explicites comme --- START OF CONTRACT --- et --- END OF CONTRACT --- : utiles quand vous avez besoin de frontières claires et lisibles autour d'un long document inséré dans le prompt.

Le principe fondamental est la cohérence : choisissez un style de délimiteur par rôle (titres pour les sections, blocs pour les données brutes, marqueurs pour les documents collés) et utilisez-le tout au long du prompt. Mélanger les styles au hasard perturbe à la fois Claude et vous-même.

Dites ce qu'il faut faire, pas seulement ce qu'il faut éviter

Quand vous dites à Claude ce qu'il ne faut pas faire, vous laissez l'espace des actions autorisées grand ouvert. Claude doit deviner ce que vous voulez réellement, et il se trompe souvent. Une instruction positive (dire à Claude exactement ce qu'il doit faire) lui donne une cible claire et produit de bien meilleurs résultats.

Pensez-y comme à des indications de chemin. "Ne va pas dans le mauvais sens" est inutile. "Tourne à gauche sur la rue Principale, puis à droite sur l'avenue des Chênes" est actionnable. La même logique s'applique aux prompts.

Situations courantes où les instructions positives l'emportent :

• Ton : Au lieu de "ne sois pas trop formel", écrivez "utilise un ton amical et conversationnel".
• Longueur : Au lieu de "n'écris pas trop", écrivez "limite ta réponse à 100 mots maximum".
• Format : Au lieu de "n'utilise pas de puces", écrivez "écris en prose fluide, en un seul paragraphe".
• Périmètre : Au lieu de "ne pars pas dans tous les sens", écrivez "concentre-toi uniquement sur les tarifs et les options de paiement".

Vous pouvez encore utiliser des formulations négatives quand une exclusion spécifique est vraiment importante, par exemple "n'incluez aucun exemple de code". Mais commencez par ce que vous voulez, et ajoutez les exclusions uniquement pour prévenir une erreur connue.

La boucle d'affinage

La boucle d'affinage consiste à traiter une conversation comme une série de petites corrections de trajectoire plutôt que comme une seule requête parfaite. Au lieu de formuler un long prompt et de tout recommencer si le résultat est mauvais, vous envoyez un court message de suivi qui cible exactement ce qui doit changer.

Cela fonctionne parce que Claude conserve l'intégralité de la conversation dans sa fenêtre de contexte (la mémoire de tout ce qui a été dit jusqu'ici). Chaque message de suivi hérite du contexte précédent, donc vous n'avez qu'à décrire le delta, le changement spécifique souhaité, sans répéter l'ensemble du brief.

Les messages de correction efficaces partagent quelques caractéristiques :

• Identifiez le problème avec précision : "Le troisième paragraphe est trop formel" vaut mieux que "réécris-le."
• Indiquez la direction : "Raccourcis-le" ou "Ajoute un exemple concret ici."
• Précisez ce qu'il faut conserver : "Garde la liste à puces, change seulement l'introduction."
• Demandez un seul changement à la fois : empiler plusieurs corrections dans un même message risque d'en faire perdre certaines.

Quand une conversation dérive trop, il est tout à fait possible de repartir de zéro. Mais épuisez d'abord la boucle d'affinage : la plupart des problèmes sont à une ou deux corrections ciblées d'un bon résultat.

Modèles de prompts réutilisables

Un modèle de prompt est un prompt contenant des espaces réservés nommés que vous remplacez à chaque réutilisation. Au lieu de réécrire la même instruction de zéro, vous la rédigez une seule fois, vous marquez les parties variables avec une étiquette comme [TOPIC] ou {{LANGUAGE}}, et vous remplissez ces emplacements chaque fois que vous en avez besoin.

Les modèles font gagner du temps et maintiennent une qualité constante. Si vous construisez un prompt qui produit un excellent résultat, un modèle fige cette qualité afin que chaque exécution future parte de la même base solide. Ils sont particulièrement utiles pour les tâches que vous répétez chaque semaine, comme résumer des notes de réunion, traduire des descriptions de produits ou rédiger des réponses à des emails.

Un bon modèle comporte trois parties :

• Instructions fixes : le contexte et les règles qui ne changent jamais (par exemple, "Tu es un rédacteur d'entreprise concis").
• Espaces réservés : des emplacements clairement étiquetés pour les parties variables, écrits entre crochets ou accolades pour les rendre visuellement distincts.
• Format de sortie : indique à Claude exactement comment structurer la réponse (liste à puces, étapes numérotées, tableau, etc.).

Vous pouvez stocker vos modèles sous forme de fichiers texte, de notes ou même dans une colonne de tableur. Quand vous en avez besoin, copiez-le, remplissez les emplacements, puis collez le prompt complété dans Claude.ai, Claude Code ou toute autre interface.

Répondre à des questions sur un document long

Lorsque vous confiez à Claude un document long (un contrat, un rapport, un manuel), l'ordre de votre message est déterminant. Placez le document en premier, puis posez votre question. Claude lit de haut en bas : le contexte est donc entièrement chargé avant qu'il traite votre demande. Placer le document après un long préambule oblige Claude à réinterpréter la question par rapport à un texte qu'il n'a pas encore vu.

Posez des questions précises. Des formulations vagues comme "résumer ceci" produisent des réponses vagues. Des questions ciblées comme "Quel est le délai de préavis de résiliation indiqué à l'article 12 ?" produisent des réponses spécifiques et vérifiables. La précision facilite aussi la détection d'une réponse incorrecte.

Demandez à Claude de citer avant de répondre. Cette technique (parfois appelée "citer puis conclure") oblige le modèle à ancrer sa réponse dans le texte réel plutôt qu'à paraphraser de mémoire. Si la citation n'existe pas dans le document, c'est un signal que la réponse est peut-être hallucinée (inventée avec une fausse assurance).

• Collez le document en haut de votre message.
• Faites-le suivre d'une question claire et ciblée.
• Ajoutez l'instruction : "Citez d'abord la ou les phrases pertinentes, puis répondez."
• Vérifiez la citation dans la source avant d'agir sur la base de la réponse.

Prompts en plusieurs langues

Claude lit et écrit dans plus de 50 langues sans aucune configuration. Vous pouvez rédiger votre prompt en français, recevoir la réponse en allemand, puis passer à l'espagnol en cours de conversation. Le modèle détecte votre langue et la reproduit par défaut, donc la règle la plus simple est : écrivez dans la langue dans laquelle vous voulez la réponse.

Le véritable défi n'est pas la fluidité mais la cohérence terminologique : un même terme technique doit apparaître sous la même forme à chaque fois. Si vous appelez un produit "ponceuse orbitale" dans un message et "orbital sander" dans le suivant, Claude risque de les traiter comme deux choses différentes et de produire un résultat incohérent. Fixez votre vocabulaire dès le début et répétez-le à l'identique.

Trois techniques vous aident à rester cohérent entre les langues :

• Bloc glossaire : commencez votre premier message par une courte liste de termes fixes, par exemple Glossaire: ponceuse orbitale = orbital sander = Orbitalschleifer, puis référez-vous à ces étiquettes tout au long de la conversation.
• Instruction de langue : ajoutez une instruction explicite telle que Always answer in English, even if I write in French. Claude la respecte de manière fiable.
• Indicateur de langue dans Claude Code : lors de l'utilisation du CLI (l'outil en ligne de commande que vous utilisez dans un terminal), vous pouvez initialiser la session avec un prompt système via

  claude --system "Reply only in Spanish, keep all code comments in English."

  Cela permet de séparer la langue humaine de la langue du code.

Les projets multilingues, par exemple une équipe francophone qui développe une base de code en anglais, bénéficient particulièrement de cette dernière technique. Gardez le code et les commentaires en anglais (le standard universel pour le code source) tandis que toutes les explications arrivent dans la langue de l'équipe.

Des résumés qui conservent l'essentiel

Il existe deux grandes façons de résumer un texte. Le résumé extractif reprend des phrases ou des expressions exactes de l'original et les assemble. Le résumé abstractif reformule les idées dans de nouveaux mots, comme le ferait un humain qui expliquerait un document à un collègue. Claude pratique le résumé abstractif par défaut, ce qui signifie qu'il peut condenser, réordonner et clarifier plutôt que de simplement copier.

Sans consignes particulières, Claude choisit lui-même la longueur et le point de focalisation. Un court article peut donner lieu à trois phrases ; un long document juridique peut donner lieu à trois paragraphes. Pour garder le contrôle, vous devez être explicite sur deux points : la longueur (nombre de mots, de puces ou de phrases) et le focus (quels sujets, quels publics ou quels usages sont prioritaires).

Voici des paramètres de focus courants que vous pouvez combiner dans un même prompt :

• Public : "pour un dirigeant non technique" versus "pour un ingénieur qui examine l'API"
• Format de sortie : "trois points de liste", "une seule phrase", "un texte de la longueur d'un tweet"
• Angle : "en mettant en avant uniquement les risques", "uniquement les actions à mener", "uniquement l'impact financier"
• Règle de préservation : "conserver tous les chiffres et les dates tels quels" (ancre extractive au sein d'un résumé abstractif)

Combiner des ancres extractives avec une prose abstractive est la technique la plus fiable pour les résumés à enjeux élevés : Claude récrit le récit mais cite les chiffres, noms et dates exacts afin qu'aucun détail ne soit reformulé par erreur.