30 techniques pratiques d’incitation de Claude issues d’une utilisation quotidienne réelle

D’innombrables guides sur l’« engineering de prompts » sont marqués comme favoris sans jamais être révisés. Trop nombreux sont ceux qui semblent décrire quelqu’un ayant simplement envoyé deux prompts, pris une capture d’écran et l’ayant présentée comme une méthode.

Ce qui suit diffère principalement en raison de son origine : des mois d’échanges quotidiens, parfois fastidieux, avec Claude, utilisés dans divers projets secondaires et pour des travaux d’écriture indépendante, avec beaucoup d’essais et d’erreurs pour déterminer quelles « bonnes pratiques » fréquemment répétées résistent réellement à la réalité du travail concret.

Ces techniques sont regroupées en quatre catégories en fonction de ce qu’elles accomplissent réellement, et non de leur complexité apparente sur le papier :

Part 1 — Say What You Mean          (clarity & structure)
Part 2 — Put Up Guardrails          (constraints & format control)
Part 3 — Make It Reason Out Loud    (thinking & iteration)
Part 4 — Build a System, Not a Prompt (workflows & long context)

Partie 1 — Exprimez-vous clairement

1. Soyez explicite, pas vague

Ce reste l’une des erreurs les plus fréquentes commises par les gens lorsqu’ils rédigent des instructions. Demander "améliorez ceci" vous donne quelque chose de générique et facile à oublier. Demander "rédigez à nouveau ce paragraphe de manière à ce qu’un fondateur non technique puisse comprendre les compromis en deux phrases" vous donne quelque chose d’utilisable.

Une règle pratique : si la rédaction d’une instruction prend moins de 10 secondes, elle n’est probablement pas assez précise.

2. Utilisez des balises structurales pour séparer les différentes parties de votre instruction

Les balises de style XML méritent d’être utilisées en permanence — non pas parce que l’on prétendrait qu’il s’agit de la « langue maternelle » de Claude (une affirmation difficile à vérifier et qu’il convient d’aborder avec scepticisme lorsqu’elle est avancée avec une certitude absolue), mais parce que les balises résolvent un problème réel et pratique : lorsque des instructions, du contexte et des exemples se mélangent dans un même bloc de texte, le modèle doit deviner où commence et s’arrête chaque section. Les balises éliminent complètement ce besoin de deviner.

<instructions>
Summarize the risks section only. Ignore financial projections.
</instructions>
<context>
[pasted document]
</context>
<output_format>
3 bullet points, no more than 15 words each
</output_format>

3. D’abord le contexte, ensuite la question

Cet ordre est plus important qu’il n’y paraît au premier abord. Coller un document long avant de poser une question a tendance à produire des réponses nettement moins bonnes que si la question était posée après que tout le contenu ait été présenté. Une explication plausible, bien qu’elle ne soit pas scientifiquement vérifiée, est que cet ordre empêche le modèle de tenter de formuler une réponse avant d’avoir vraiment fini de lire tout le texte.

[long document]
---
Based on everything above, what's the single biggest
risk to the Q3 timeline?

4. Montrer, plutôt que de simplement décrire (exemples à faible quantité d’exemples)

Les adjectifs descriptifs sont peu précis et souvent vagues. Un seul exemple concret du ton, de la structure ou du format souhaité est bien plus efficace qu’un paragraphe entier de description. Pour les tâches récurrentes — emails aux clients, retours sur les revues de code et autres routines similaires — il est utile de conserver deux ou trois exemples de « norme d’or » dans un fichier de notes, prêts à être collés chaque fois que ce même type de tâche se présente.

5. Expliquez pourquoi, pas seulement la règle

C’est l’une des techniques les plus surprenantes de cette liste. Dire à Claude « garde cela en dessous de 280 caractères » fonctionne, techniquement parlant. Mais lui indiquer « ce texte sera envoyé directement sur Twitter, et tout ce qui dépasse 280 caractères sera coupé au milieu de la phrase » produit un résultat nettement plus méticuleux. On dirait que donner une raison pousse le modèle à prendre en compte cette contrainte tout au long de sa réponse, plutôt que de se contenter de compter les caractères à la fin.

6. Permettre explicitement l’option « Je ne sais pas »

Une seule ligne vaut la peine d’être ajoutée à presque toutes les demandes de recherche ou d’analyse :

If the available information isn't enough to draw a
conclusion, say so directly instead of guessing.

En omettant cette ligne, il existe un risque réel d’obtenir des réponses prétentieuses mais sans fondement. En l’incluant, la réponse devient parfois "il n’y a pas suffisamment d’informations pour en être certain" — ce qui est insatisfaisant sur le moment, mais c’est toujours mieux que de découvrir des faits inventés des heures plus tard.

7. Spécifiez le format de sortie, ne l’assumez pas

Il y a une différence réelle entre demander "un tableau" et demander "un tableau de texte brut formaté de manière à pouvoir être collé proprement dans un bloc de code, car Medium a tendance à corrompre les tableaux Markdown". En décrivant précisément la forme souhaitée pour la réponse, on évite complètement ce déséquilibre.

8. Définissez à quoi ressemble un "résultat final", pas seulement la tâche

Au lieu de décrire la tâche elle-même, décrire à quoi ressemblerait un résultat réussi permet généralement d’obtenir des résultats plus précis :

I need a competitor comparison so my co-founder can
pick a pricing tier in under 5 minutes without asking
me follow-up questions.

Ce seul paragraphe a plus de poids que trois paragraphes entiers de règles de formatage.

Partie 2 — Mettre en place des limites

9. Contraintes négatives — indiquer ce que cela ne doit PAS faire

Parfois, il est plus rapide de définir l’objectif en excluant ce que l’on ne veut pas plutôt qu’en essayant de préciser exactement ce que l’on souhaite :

Do not sound like: a LinkedIn thought-leader post.
Do not include: "in today's fast-paced world," filler
caveats, or a summary that repeats the intro.

10. Une instruction de système au style « contrat »

Pour tout ce que vous prévoyez de réutiliser, rédigez l’instruction de système comme un bref contrat juridique plutôt que comme une description des caractéristiques :

Role: technical editor for a solo dev's blog
Goal: tighten prose without changing meaning
Constraints:
 - keep first-person voice
 - no invented statistics
 - flag anything that sounds AI-generated
If unsure: ask one clarifying question, don't guess
Output: plain markdown, no headers added

11. Éviter le jeu du « faire semblant d’être un expert senior »

C’est une technique qu’il vaut mieux abandonner. Indiquer à Claude de « jouer le rôle d’un ingénieur expérimenté de 20 ans » ne semble pas changer grand-chose lorsque vos instructions sont déjà précises. La définition du personnage a bien moins d’impact que les contraintes réelles que vous imposez. Recourir à un rôle pour compenser l’absence de détails précis est généralement le signe que les instructions elles-mêmes ont besoin d’être affinées.

12. Auto-évaluation selon un critère d’évaluation

Au lieu de demander simplement « vérifiez votre travail », fournissez un véritable critère d’évaluation et exigez une note auto-évaluée avant la sortie finale :

Score your draft 1-10 on: technical accuracy, whether
a beginner could follow it, and whether it sounds
like a real person wrote it. Then revise based on
your own score. Show only the revised version.

Cette approche a permis de détecter à plusieurs reprises des erreurs réelles dans les explications de code et les résumés de données.

13. Sélectionnez soigneusement les documents longs plutôt que de tout mettre

Apporter plus de matériel ne améliore pas automatiquement la qualité de la réponse. Coller toute une base de code ou un PDF long sans aucun filtrage préalable a tendance à produire des réponses qui se contentent de parcourir la partie centrale du document et s’attardent uniquement sur les sections d’ouverture et de fermeture. Une meilleure approche consiste à faire en sorte que Claude extrait d’abord les passages pertinents avant de raisonner uniquement sur ceux-ci — une version à petite échelle d’un pipeline « récupérer puis raisonner » :

Step 1: extract the 5 passages most relevant to
[my question], quoting them exactly.
Step 2: analyze only those passages.

14. Taguer plusieurs documents lors de la comparaison des sources

Lorsque l’on compare plus d’une source, il convient de les étiqueter et de les numéroter explicitement au lieu de se contenter de les séparer par des lignes vides. Ce petit ajustement réduit considérablement le risque que le modèle attribue une affirmation au mauvais document.

<document index="1" name="Q3_report.pdf">...</document>
<document index="2" name="Q2_report.pdf">...</document>

15. Limites strictes pour une sortie structurée

Lorsqu’un JSON strict ou un schéma spécifique est requis, indiquez-le directement en énumérant les clés exactes, plutôt que de décrire vaguement la structure en espérant que le modèle l’inférera correctement :

Return only a JSON object with keys: title, summary,
confidence (0-1), open_questions (array of strings).
No text before or after the JSON.

Partie 3 — Demander une explication verbale détaillée

16. Demander une justification étape par étape pour tout ce qui n’est pas trivial

Ajouter une instruction demandant au modèle de résoudre le problème par étapes avant de donner une réponse finale, et d’identifier tous les cas limites au fur et à mesure, demande plus d’efforts qu’il n’y paraît. Cela vaut la peine d’être appliqué à tout ce qui implique des calculs mathématiques, une logique en plusieurs étapes ou une décision nécessitant des compromis. Omettre cette démarche pour des tâches qui semblent « évidemment simples » est précisément quand les erreurs ont tendance à survenir.

17. Utiliser des chaînes d’instructions plutôt qu’une seule demande complexe

Il est tentant de regrouper tout cela en une seule demande : lire ce texte, en faire un résumé, le transformer en posts pour les réseaux sociaux et suggérer un titre. En divisant cela en demandes successives, on obtient de meilleurs résultats à chaque étape, car chaque étape individuelle n’a besoin que de bien s’occuper d’une seule tâche :

[1] extract key facts
      |
      v
[2] turn facts into a 3-paragraph summary
      |
      v
[3] turn summary into 5 short takeaways

18. Brainstorming inversé pour les décisions bloquées

Cette technique semblait au début être un simple truc, mais s’est avérée véritablement utile. Plutôt que de demander directement comment assurer le succès d’un lancement, commencez par demander le contraire :

Brainstorm 10 ways this launch could fail. For each
one, invert it into a concrete thing we'd do
differently. Flag the 3 inversions that are the least
obvious.

Cette approche révèle des points aveugles que la demande simple « donnez-moi une stratégie » a tendance à manquer.

19. Débat avec plusieurs personnalités pour les décisions impliquant des compromis réels

Ce pourrait être la technique la plus efficace de cette liste. Lorsque des décisions impliquent des incitations contradictoires, demandez à Claude d’examiner la question sous plusieurs angles différents avant de formuler une recommandation globale :

Optimist            Skeptic           End user
      "ship faster"      "watch runway"    "don't care
           |                   |            about our
           v                   v             problems"
            \                 |                /
             \                |               /
              \               |              /
               v              v             v
                    synthesized recommendation

Une demande simple du type « Donnez-moi simplement votre recommandation » conduit généralement à une réponse qui semble la plus acceptable. En forçant d’abord un débat interne, on obtient un résultat plus précis et mieux justifié.

20. Auto-critique et révision, en une seule étape

Cela s’appuie sur l’idée des critères établis précédemment, mais de manière plus simple : demandez un premier brouillon, une auto-critique de ce brouillon, ainsi qu’une version finale révisée, tout cela dans une seule demande plutôt que par plusieurs échanges successifs :

Draft 1 -> list 3 weaknesses in Draft 1 -> Draft 2

21. Laissez-le poser des questions de clarification avant de commencer le travail

Pour tout ce qui est ambigu ou ayant des conséquences importantes, indiquez explicitement au modèle de ne pas commencer tout de suite et de poser toutes les questions auxquelles il a besoin de réponses en premier. Cela entraîne un léger retard avant la première réponse réelle, mais permet généralement d’éviter toute reprise de travail ultérieure.

22. Meta-prompting — faire améliorer votre prompt

C’est une méthode sous-utilisée. Lorsqu’un prompt continue de produire des résultats médiocres, au lieu de le réécrire vous-même, demandez directement :

Here's the prompt I've been using: [paste]. Here's the
output it produces: [paste]. What's wrong with the
prompt, and rewrite it.

Cela met souvent en évidence des formulations vagues que vous n’auriez pas pu détecter par vous-même, principalement parce que vous connaissez déjà ce que vous vouliez dire et passez outre l’ambiguïté.

23. Considérez cela comme une conversation, et non un prompt parfait unique

C’est le changement de mentalité le plus important ici, et il s’agit moins d’une technique que d’abandonner une mauvaise habitude : cessez de chercher le prompt parfait. Demandez une première version approximative, réagissez-y, puis affinez progressivement. Essayer d’intégrer toutes les exigences dans un seul prompt volumineux donne systématiquement de moins bons résultats que quelques tours courts d’itération et de retour d’information.

Partie 4 — Construisez un système, pas un prompt

24. Utilisez des fichiers de règles persistants plutôt que de vous répéter

Ce pourrait être le changement d’habitude le plus utile de tous. Au lieu de réécrire constamment le ton, le public et les contraintes dans chaque nouveau prompt, conservez-les dans un fichier rules.md distinct :

# Writing rules
- tone: direct, no fluff
- audience: builders, not consumers
- never use: "leverage", "in today's world"
- always: specific numbers, source links, one action item
- format: short paragraphs, 3 sentences max

Puis commencez chaque session en faisant référence à ce fichier : « Lisez complètement rules.md avant de commencer. Si vous êtes sur le point de enfreindre l’une de ces règles, arrêtez-vous et dites-le-moi plutôt. »

Cela transforme l’approche basée sur des instructions à donner à chaque fois en quelque chose qui consiste à configurer un petit outil persistant. C’est la différence entre mener chaque jour la même bataille et la résoudre une seule fois.

25. Rendre explicite le cycle : planifier, agir, vérifier, itérer

Pour les tâches complexes où Claude doit appeler des outils, modifier des fichiers ou exécuter des commandes — ne supposez pas que le modèle structurera automatiquement le processus. Décrivez directement ce cycle :

 ┌─────────┐    ┌────────┐    ┌────────┐    ┌────────┐
 │  PLAN   │ -> │  ACT   │ -> │ VERIFY │ -> │ ITERATE│
 │ max 5   │    │ use    │    │ against│    │  or    │
 │ steps   │    │ tools  │    │criteria│    │ done   │
 └─────────┘    └────────┘    └────────┘    └────────┘
                                  |  fail
                                  v
                             back to ACT

L’instruction qui a permis d’éviter le plus grand nombre d’erreurs silencieuses et en cascade est simple : ne passez à l’étape suivante que lorsque l’étape actuelle a été vérifiée avec succès.

26. Fonder les affirmations sur des faits récupérés plutôt que sur la mémoire

Pour toute information factuelle, indiquez explicitement au modèle de s’appuyer sur le matériel qui se trouve devant lui plutôt que de se référer à ses connaissances acquises lors de son entraînement. En lui demandant de « citer la ligne ou la section spécifique d’où provient l’information », vous transformez une réponse qui semble plausible en une que vous pouvez effectivement vérifier. S’il ne peut pas indiquer une source, considérez cela comme un signal pour faire une pause et vérifier manuellement.

27. Insérer des points de contrôle humains avant les actions irréversibles

Toute tâche impliquant l’envoi d’un e-mail, le dépôt de code ou des dépenses doit inclure une pause explicite : « Arrêtez-vous avant d’effectuer l’action finale et montrez-moi ce que vous êtes sur le point de faire. » Aucun système – et aucune confiance en votre propre jugement, même tard dans la nuit – n’est suffisamment fiable pour omettre cette étape.

28. Reconnaître quand un prompt très long n’est pas la bonne approche

Les fenêtres de contexte étendues incitent à y mettre tous les documents en espérant le meilleur. Cela fonctionne parfois bien. Mais souvent, un prompt plus court, sélectionné manuellement et ne contenant que les trois paragraphes pertinents, est plus efficace que l’insertion de tout le document, car on ne force pas le modèle à trier et analyser en même temps. Préférez d’abord sélectionner soigneusement les informations à fournir, et n’utilisez la copie intégrale que lorsque vous ne savez vraiment pas encore ce qui est pertinent.

29. Gérez le contrôle de version de vos prompts comme vous gérez celui du code

Lorsqu’un prompt est utilisé de manière récurrente pour générer des rapports réguliers, des livrables pour des clients ou tout autre travail continu, stockez-le dans un fichier accompagné d’une date et d’une brève note de changement. Cela peut sembler excessif jusqu’à ce qu’un « petit ajustement » brise silencieusement un fonctionnement sur lequel vous comptiez, sans que vous ayez de trace de l’apparence du prompt la semaine précédente.

30. Exécutez le flux de travail localement lorsque vous souhaitez éviter les coûts par token ou conserver les données hors des serveurs externes

Aucune de ces techniques ne nécessite strictement une API hébergée. Pour tout ce que vous itérez à plusieurs reprises — tester une grille d’évaluation auto-évaluative, ou le cycle planer/agir/vérifier décrit ci-dessus — il est souvent judicieux de créer un prototype à l’aide d’un modèle local avec Ollama en premier, puis de transférer le prompt final vers Claude pour la dernière étape. Cela rend l’itération moins coûteuse, et rien ne quitte votre machine tant que vous travaillez encore sur le prompt.

Version hébergée, pour un test rapide avec l’API Claude :

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 500,
    "messages": [{"role": "user", "content": "Score this draft 1-10 on clarity, then revise it: [paste draft]"}]
  }'

Équivalent local auto-hébergé utilisant Ollama, sans clé API et sans frais par token :

# one-time setup
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
docker exec -it ollama ollama pull llama3.1
# same self-evaluation prompt, run locally
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1",
  "prompt": "Score this draft 1-10 on clarity, then revise it: [paste draft]",
  "stream": false
}'

Référence rapide : effort vs. résultat

TECHNIQUE                             EFFORT TO ADOPT   PAYOFF
----------------------------------    ----------------  --------
Rules/context file (#24)              low                very high
Multi-persona debate (#19)            low                high
Plan-act-verify loop (#25)            medium             high
Prompt chaining (#17)                 low                high
Permission to say "I don't know"(#6)  trivial            high
Explain the "why" (#5)                trivial            high
Reverse brainstorming (#18)           low                medium-high
Contract system prompt (#10)          medium             medium
"Act as an expert" persona (#11)      trivial            low

Et si vous n’êtes pas d’accord avec une partie de ce classement, ou si vous avez découvert que l’une de ces techniques nuit réellement à votre cas d’usage particulier, ce type d’exemple contraire est bien plus utile qu’un autre article générique sur des « prompts qui changeront votre vie ».