Anatomie d'un prompt#

Un bon prompt n'est pas une phrase inspirée : c'est un assemblage de 6 briques que tu poses toujours dans le même ordre.

Temps de lecture : 12 min | Niveau : Débutant

Ce que tu sauras faire après#

• Identifier les 6 briques qui composent tout prompt qui fonctionne.
• Repérer quelle brique manque quand une réponse te déçoit.
• Construire un prompt complet sur un cas data réel, brique par brique.
• Réutiliser une trame fixe au lieu de repartir de zéro à chaque fois.

🧱 Pourquoi raisonner en briques#

Quand tu écris « analyse ma table », tu donnes une seule information : le verbe. Le modèle doit deviner tout le reste : qui il est censé être, sur quoi il travaille, jusqu'où il va, sous quelle forme il répond.

La documentation Claude donne une image utile : traite le modèle comme un collègue brillant mais qui vient d'arriver et qui ne connaît ni tes normes ni tes process. Il est compétent. Il n'est pas dans ta tête.

La règle d'or : montre ton prompt à un collègue qui n'a aucun contexte sur la tâche et demande-lui de l'exécuter. S'il est perdu, le modèle le sera aussi. — Prompting best practices, Anthropic

Raisonner en briques résout ton problème d'écriture. Tu n'as plus à « trouver les mots ». Tu remplis 6 cases.

Le tableau des 6 briques#

Les trois briques en gras sont le minimum vital. Si ta réponse est mauvaise, commence toujours par vérifier ces trois-là.

Comment lire ce tableau quand tu bloques#

Tu ne sais pas comment formuler ? Ne rédige pas. Réponds d'abord aux 6 questions de la colonne 3, en style télégraphique, puis colle tes réponses dans la trame. Le modèle se charge de la prose, pas toi.

📋 La trame vide, à copier maintenant#

Voici la trame dont parle le paragraphe ci-dessus. Copie-la dans un fichier à toi. Tu remplaces les champs entre crochets, tu supprimes les lignes inutiles, tu envoies.

Tu es un [METIER_ET_SPECIALITE, ex: data engineer senior spécialisé PostgreSQL 16].

Contexte :
- On travaille sur [OBJET_EXACT, ex: la table de faits `commandes`].
- Environnement : [STACK_ET_VERSIONS, ex: PostgreSQL 16, dbt, Airflow 2.9].
- Volume : [ORDRE_DE_GRANDEUR, ex: 40 millions de lignes].
- Usage réel : [QUI_S_EN_SERT_ET_POUR_QUOI].
- Symptôme ou déclencheur : [CE_QUI_M_AMENE_ICI, ex: requêtes à plus de 30 s depuis 2 semaines].

Ta tâche :
1. [ETAPE_1_VERBE_D_ACTION]
2. [ETAPE_2]
3. [ETAPE_3]

Contraintes :
- [LIMITE_TECHNIQUE, ex: PostgreSQL uniquement, pas de syntaxe d'un autre moteur]
- [CE_QU_IL_NE_FAUT_PAS_TOUCHER, ex: aucune instruction destructive]
- Si [SITUATION_AMBIGUE], écris « [VALEUR_DE_REPLI, ex: à vérifier] » plutôt que de supposer.

Format de sortie : [DECRIRE_PRECISEMENT, ex: un tableau markdown à 4 colonnes]
Exemple d'une ligne attendue :
[COLLER_UNE_LIGNE_DE_SORTIE_DEJA_REMPLIE]

<donnees>
[COLLER_ICI_TON_SCHEMA_TON_CODE_OU_TON_EXTRAIT]
</donnees>

Les six briques sont là, dans l'ordre. Un champ que tu ne sais pas remplir ? Écris non connu. Le modèle posera la question au lieu d'inventer.

Brique 1 — Le rôle#

Le rôle fixe le vocabulaire et la profondeur de la réponse. « Tu es un analyste business » et « tu es un ingénieur base de données » produisent deux réponses différentes sur la même table : l'un parle chiffre d'affaires, l'autre parle cardinalité et plan d'exécution.

La doc Anthropic précise qu'une seule phrase de rôle fait déjà une différence, et que sa place naturelle est le system prompt, c'est-à-dire le bloc d'instructions permanent placé avant la conversation (voir le fichier 04).

Brique 2 — Le contexte#

C'est la brique que tout le monde oublie. Le modèle ne voit pas ton écran, ne connaît ni ta stack ni tes volumes.

La documentation Google le dit sans détour : inclus dans le prompt les informations nécessaires pour résoudre le problème, au lieu de supposer que le modèle les a déjà.

Anthropic ajoute un point sous-estimé : donner la motivation derrière une instruction améliore le résultat, parce que le modèle généralise à partir de l'explication.

• Moins efficace : N'utilise jamais de points de suspension.
• Plus efficace : Ta réponse sera lue à voix haute par un moteur de synthèse vocale, donc n'utilise jamais de points de suspension : le moteur ne saurait pas les prononcer.

Transposé data : au lieu de pas de CTE, écris pas de CTE : ce moteur matérialise mal les CTE et ça double le temps d'exécution.

Brique 3 — La tâche#

Un verbe d'action, un objet, un périmètre. Si la tâche a plusieurs étapes dont l'ordre compte, la doc Anthropic recommande explicitement une liste numérotée plutôt qu'un paragraphe.

1. Lis le schéma fourni.
2. Liste les colonnes dont le type est incohérent avec le contenu.
3. Pour chaque incohérence, propose le type correct et la requête ALTER.

Brique 4 — Les contraintes#

Les contraintes délimitent le terrain de jeu : dialecte SQL, longueur, bibliothèques autorisées, choses à ne pas toucher.

Une contrainte très utile, recommandée par Microsoft : donner une porte de sortie au modèle. Ajoute une phrase du type si l'information n'est pas dans le schéma fourni, réponds "non déterminable" au lieu de supposer. Ça réduit les réponses inventées.

Brique 5 — Le format de sortie#

C'est la brique qui te fait gagner le plus de temps au quotidien, parce qu'une sortie bien formatée est directement copiable dans ton code, ton ticket ou ton tableur.

Principe central de la documentation Anthropic, placé en tête de sa section sur le contrôle du format : dis ce qu'il faut faire, pas ce qu'il ne faut pas faire.

Attention à ne pas surinterpréter : Google, lui, admet les deux et écrit simplement qu'on peut dire au modèle « ce qu'il faut faire et ce qu'il ne faut pas faire ». La formulation positive reste le réflexe le plus sûr, pour une raison simple : une interdiction ne dit jamais quoi faire à la place.

• Au lieu de : N'utilise pas de markdown dans ta réponse.
• Écris : Ta réponse doit être composée de paragraphes de prose fluide.

Le fichier 06 traite cette brique en détail.

Brique 6 — Les exemples#

Un exemple vaut dix lignes de description. Anthropic recommande 3 à 5 exemples pour de bons résultats, enveloppés dans des balises <example> (et un bloc <examples> quand il y en a plusieurs). Google va plus loin : « nous recommandons de toujours inclure des exemples few-shot ; les prompts sans exemples sont probablement moins efficaces ».

Le fichier 03 est entièrement consacré à cette brique.

🔬 Cas complet : analyser un schéma de table#

Avant — le prompt qu'on écrit spontanément#

Analyse cette table et dis-moi ce qui ne va pas.

CREATE TABLE commandes (...);

Résultat typique : trois paragraphes génériques sur les bonnes pratiques de modélisation, aucune ligne exploitable.

Après — le même besoin, en 6 briques#

Tu es un data engineer senior spécialisé PostgreSQL 16 et modélisation analytique.

Contexte : entrepôt interne d'une société de e-commerce. La table `commandes` est
la table de faits principale, environ 40 millions de lignes, alimentée toutes les
heures par un DAG Airflow. Les analystes s'en servent surtout pour des agrégats
par jour et par pays. On observe depuis 2 semaines des requêtes à plus de 30 secondes.

Ta tâche :
1. Repère les problèmes de typage (type déclaré incohérent avec l'usage réel).
2. Repère les colonnes candidates à un index, vu les usages décrits ci-dessus.
3. Repère les risques de qualité de données (nullabilité, absence de contrainte).

Contraintes :
- PostgreSQL uniquement, pas de syntaxe propriétaire d'un autre moteur.
- Aucune instruction destructive (pas de DROP, pas de TRUNCATE).
- Si une information manque pour trancher, écris « à vérifier » plutôt que de supposer.

Format de sortie : un tableau markdown à 4 colonnes
| Colonne | Problème | Correction proposée | Priorité (1 à 3) |
Puis, sous le tableau, un bloc SQL unique contenant les ALTER et CREATE INDEX,
dans l'ordre d'exécution, sans commentaire.

Exemple d'une ligne attendue :
| pays_code | Déclaré TEXT alors qu'il contient toujours 2 caractères | ALTER TABLE commandes ALTER COLUMN pays_code TYPE CHAR(2) | 2 |

<schema>
CREATE TABLE commandes (
  id            TEXT,
  client_id     TEXT,
  pays_code     TEXT,
  montant_ttc   TEXT,
  date_commande TEXT,
  statut        TEXT
);
</schema>

Pourquoi c'est mieux#

🧭 L'ordre des briques#

Deux cas à distinguer.

Prompt court (moins d'une page). L'ordre ci-dessus fonctionne bien : rôle, contexte, tâche, contraintes, format, exemples, puis les données.

Prompt avec un document long (gros CSV, long schéma, log de 500 lignes). Anthropic est explicite : place les documents longs en haut du prompt, au-dessus de la question, des instructions et des exemples. La doc indique que mettre la question à la fin peut améliorer la qualité de réponse jusqu'à 30 % dans leurs tests, surtout sur des entrées multi-documents. Google donne la même consigne : contexte d'abord, instruction à la toute fin.

À noter, parce que les sources ne disent pas exactement la même chose : Microsoft conseille de commencer par des instructions claires, tout en précisant dans une note que sur les modèles récents leur test n'a montré aucune différence selon la position. Microsoft recommande aussi de répéter l'instruction à la fin pour exploiter le biais de récence. En pratique : données longues en haut, instruction à la fin, et si le résultat dérape sur un très long prompt, répète l'instruction en une ligne tout en bas.

Le fichier 05 détaille le placement et le balisage.

A retenir#

• Un prompt = 6 briques : Rôle, Contexte, Tâche, Contraintes, Format, Exemples. Tu remplis des cases, tu n'inventes pas une formulation.
• Le trio vital est Contexte, Tâche, Format. Quand une réponse déçoit, vérifie ces trois-là en premier.
• Le modèle est un collègue brillant qui vient d'arriver : il ne devine ni ta stack, ni tes volumes, ni ton intention.
• Donner la raison d'une contrainte marche mieux que la contrainte seule.
• Documents longs en haut, instruction à la fin. Anthropic mesure jusqu'à 30 % de gain sur les entrées multi-documents.
• Formule en positif (« fais ceci ») plutôt qu'en négatif (« ne fais pas cela »).

Sources#

• Prompting best practices — Anthropic
• Prompt engineering overview — Anthropic
• Prompt design strategies — Google Gemini API
• Prompt engineering techniques — Microsoft Foundry / Azure OpenAI
• Prompt engineering — OpenAI