Être clair et direct
Le modèle ne devine pas ton intention : il complète ton texte. Tout ce que tu laisses implicite, il le remplace par une moyenne.
Temps de lecture : 12 min | Niveau : Débutant
Ce que tu sauras faire après
- Repérer l'implicite dans tes propres prompts et le transformer en explicite.
- Énoncer ce que tu veux plutôt que ce que tu ne veux pas.
- Préciser le public cible et le but, deux informations qui changent tout.
- Appliquer le test du collègue avant d'envoyer un prompt.
- Réécrire 5 prompts du quotidien dev et data en version claire.
🎯 Pourquoi le modèle ne devine pas
Un modèle de langage produit la suite la plus probable de ton texte. Microsoft le formule ainsi : quel que soit le prompt fourni, le modèle répond simplement avec ce qu'il estime le plus probable. Il ne suit pas un « chemin Q/R » spécial parce que tu as mis un point d'interrogation.
Conséquence directe : un prompt vague appelle une réponse moyenne. Pas mauvaise, pas fausse. Moyenne. Générique. Inutilisable.
Anthropic ajoute un point qui compte pour toi : si tu veux un comportement « qui va au-delà », demande-le explicitement au lieu d'espérer que le modèle le déduise d'un prompt vague.
Le test du collègue
Avant d'envoyer, relis ton prompt en te posant une seule question :
Si je donne ce texte à un collègue qui n'a aucun contexte sur la tâche et que je lui demande de l'exécuter, est-ce qu'il serait perdu ?
Si la réponse est oui, le modèle le sera aussi. C'est la règle d'or de la doc Anthropic, et c'est le seul contrôle qualité dont tu as besoin au début.
Les 4 leviers de clarté
1. Remplacer l'implicite par l'explicite
Tout ce qui est « évident pour toi » n'existe pas pour le modèle : la version de ton moteur, le nom de tes tables, le fait que ce soit du code de prod, le fait que tu sois pressé.
Liste mentale rapide, à faire en 10 secondes :
- Quoi : l'objet exact (quelle table, quel fichier, quelle erreur).
- Où : la stack, la version, l'environnement.
- Pour qui : le public qui lira la réponse.
- Pour quoi : ce que tu feras de la réponse ensuite.
- Jusqu'où : le périmètre à ne pas dépasser.
2. Dire ce qu'il faut faire, pas ce qu'il ne faut pas faire
C'est le conseil le plus rentable de la documentation Anthropic, qui le place en premier dans sa section sur le contrôle du format des réponses. Google est plus souple sur ce point et autorise aussi les interdictions ; garde quand même le réflexe positif, pour la raison donnée juste en dessous.
- Au lieu de :
Ne me fais pas de markdown. - Écris :
Réponds en paragraphes de prose continue.
Une négation oblige le modèle à représenter la chose interdite avant de l'écarter. Une formulation positive lui donne directement la cible. Et surtout, une négation ne dit pas quoi faire à la place : elle laisse le champ ouvert.
3. Donner le public cible et le but
Deux phrases qui coûtent 5 secondes et qui changent la réponse entière.
Le lecteur est un analyste métier qui ne lit pas de SQL.Je vais coller ce texte dans un ticket Jira lu par l'équipe support.
Le public fixe le vocabulaire. Le but fixe le format et la longueur.
4. Ordonner les étapes quand l'ordre compte
Anthropic recommande de donner les instructions sous forme d'étapes séquentielles, en liste numérotée ou à puces, quand l'ordre ou l'exhaustivité comptent. Un paragraphe de trois consignes enchaînées se perd. Trois lignes numérotées, non.
🔁 Cinq paires avant / après
Paire 1 — Relire du code
Avant
Tu peux regarder ce code ?Après
Relis cette fonction Python. C'est un utilitaire de transformation appelé dans
un DAG Airflow qui tourne toutes les heures sur environ 2 millions de lignes.
Cherche dans cet ordre :
1. Les bugs de correction (résultat faux).
2. Les problèmes de performance liés au volume indiqué.
3. Les cas limites non gérés (valeurs nulles, colonnes absentes, dates invalides).
Pour chaque point trouvé : le numéro de ligne, le problème en une phrase,
le correctif en code. Ignore le style et le nommage.Pourquoi c'est mieux : « regarder » ne veut rien dire, et sans contexte de volume le modèle ne peut pas juger la performance. Les trois axes ordonnés garantissent qu'aucun n'est oublié, et « ignore le style » évite 20 lignes de remarques inutiles.
Paire 2 — Écrire une requête SQL
Avant
Fais-moi une requête pour avoir le chiffre d'affaires par mois.Après
Écris une requête PostgreSQL 16 qui calcule le chiffre d'affaires mensuel
sur les 12 derniers mois glissants.
Tables disponibles :
- commandes(id, client_id, date_commande DATE, statut TEXT)
- lignes_commande(commande_id, produit_id, quantite INT, prix_unitaire_ht NUMERIC)
Règles métier :
- Ne compte que les commandes dont statut = 'validee'.
- Le chiffre d'affaires est HT : quantite * prix_unitaire_ht.
- Les mois sans commande doivent quand même apparaître, avec 0.
Sortie : le bloc SQL seul, sans explication, sans commentaire.
Colonnes : mois (format AAAA-MM), ca_ht arrondi à 2 décimales.Pourquoi c'est mieux : sans le schéma, le modèle invente des noms de colonnes et tu perds 10 minutes à les corriger. Les règles métier (statut, HT, mois vides) sont exactement ce qu'il ne peut pas deviner. « Le bloc SQL seul » rend la réponse collable directement.
Paire 3 — Comprendre une erreur
Avant
J'ai cette erreur, c'est quoi le problème ?
KeyError: 'montant'Après
Contexte : script pandas qui lit un CSV exporté quotidiennement par un
prestataire, puis agrège par client. Ça tournait depuis 6 mois sans souci,
ça casse depuis l'export d'hier.
Erreur : KeyError: 'montant', levée ligne 42 sur df.groupby('client')['montant'].sum()
Tâche :
1. Donne les 3 causes les plus probables, classées par probabilité.
2. Pour chaque cause, donne la commande exacte à lancer pour la confirmer ou l'écarter.
3. Donne ensuite un correctif défensif qui évite que ça recasse au prochain export.
Ne propose pas de refonte du script. Je veux un correctif ciblé.Pourquoi c'est mieux : « ça marchait avant, ça casse depuis hier » oriente immédiatement vers un changement de format de fichier source, pas vers une faute de frappe. Demander des commandes de vérification transforme une supposition en diagnostic. Et « pas de refonte » cadre le périmètre.
Paire 4 — Documenter une table
Avant
Documente cette table.Après
Rédige la documentation de la table `dim_client` pour notre catalogue de données.
Le lecteur est un analyste business qui écrit du SQL simple mais qui ne
connaît pas notre modèle de données. Il doit pouvoir, après lecture, écrire
une requête correcte sans demander d'aide.
Pour chaque colonne : nom, type, description en une phrase de langage métier,
valeurs possibles si c'est un code, et si la colonne peut être nulle.
Ajoute avant le tableau : 2 phrases sur ce que représente une ligne de cette
table, et la granularité exacte.
Format : un paragraphe d'intro, puis un tableau markdown.
Si une colonne est ambiguë et que tu ne peux pas trancher avec le DDL fourni,
écris « à confirmer avec l'équipe data » plutôt que d'inventer une description.
<ddl>
[COLLER_ICI_LE_CREATE_TABLE]
</ddl>Pourquoi c'est mieux : le public cible (« analyste qui ne connaît pas le modèle ») remplace le jargon technique par du langage métier. « Ce que représente une ligne » est la question n°1 que se pose un analyste et celle qu'aucune doc auto-générée ne traite. La porte de sortie (« à confirmer ») évite les descriptions inventées, qui sont le pire défaut d'une doc de données.
Paire 5 — Résumer une réunion
Avant
Résume ces notes de réunion.Après
Transforme ces notes de réunion en compte rendu que je vais envoyer par mail
à l'équipe data et au responsable produit.
Public : des gens qui n'étaient pas là. Ils doivent comprendre les décisions
sans avoir besoin de me poser de question.
Structure attendue, dans cet ordre :
1. Décisions prises (une puce par décision, au passé, sans conditionnel).
2. Actions : un tableau markdown | Action | Responsable | Échéance |.
3. Points non tranchés qui restent à arbitrer.
Règles :
- Ne mets une action dans le tableau que si un responsable est nommé dans les notes.
- Si l'échéance n'est pas dans les notes, écris « à définir ».
- N'invente aucune décision qui ne soit pas explicitement dans les notes.
- Ton neutre et factuel, pas de formule de politesse.
<notes>
[COLLER_ICI_TES_NOTES_BRUTES]
</notes>Pourquoi c'est mieux : « résume » produit un pavé descriptif ; ce que tu veux réellement, ce sont des décisions et des actions. La règle « pas de responsable nommé, pas de ligne » empêche le modèle d'attribuer des tâches au hasard, l'erreur la plus courante et la plus gênante sur ce cas d'usage.
🧰 La checklist de 30 secondes
Avant d'envoyer, vérifie ces 6 points. Coche mentalement.
| Point | Question | Si non |
|---|---|---|
| Objet | Ai-je nommé l'objet exact (table, fichier, erreur) ? | Ajoute-le |
| Stack | Ai-je donné le moteur, la version, la bibliothèque ? | Ajoute-la |
| Public | Ai-je dit qui va lire la réponse ? | Ajoute une phrase |
| But | Ai-je dit ce que je ferai de la réponse ? | Ajoute une phrase |
| Format | Ai-je décrit la forme de la sortie ? | Décris-la |
| Positif | Mes consignes sont-elles formulées en « fais » et non « ne fais pas » ? | Réécris-les |
⚠️ Deux pièges de la clarté
Trop long n'est pas plus clair. Un prompt de 40 lignes de consignes contradictoires est pire qu'un prompt de 10 lignes nettes. Vise la précision, pas le volume. Microsoft insiste par ailleurs sur l'efficacité d'espace : un tableau coûte moins de tokens qu'un JSON où chaque champ est répété, et les espaces consécutifs comptent comme des tokens séparés.
Attention aux modèles de raisonnement. Microsoft place un avertissement en tête de sa page : ces techniques ne sont pas recommandées pour les modèles de raisonnement comme gpt-5 et la série o. OpenAI le confirme de son côté : les modèles GPT classiques bénéficient d'instructions précises qui fournissent explicitement la logique et les données, tandis que les modèles de raisonnement donnent de meilleurs résultats avec une consigne de haut niveau. Autrement dit : plus le modèle réfléchit seul, moins tu dois lui dicter la méthode. Continue en revanche à donner le contexte, le but et le format.
A retenir
- Le modèle complète le texte le plus probable. Un prompt vague produit une réponse moyenne, pas une réponse fausse : c'est ce qui rend l'erreur difficile à voir.
- Applique le test du collègue : si un collègue sans contexte serait perdu, réécris.
- Formule en positif. Une négation n'indique jamais quoi faire à la place.
- Public + but en deux phrases changent le vocabulaire, la longueur et le format de la réponse.
- Les étapes qui doivent toutes être traitées vont en liste numérotée, pas en paragraphe.
- Donne une porte de sortie (« écris à confirmer ») pour éviter les réponses inventées.
- Sur les modèles de raisonnement, allège les instructions de méthode et garde le contexte.