Anatomie d'un prompt efficace

Le prompt comme assemblage de blocs, pas comme phrase unique

Un professionnel qui rédige un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire récurrent ne part pas d'une page blanche à chaque fois. Il assemble des blocs identifiables, dans un ordre pensé, dont chacun résout un type d'ambiguïté précis. Ce chapitre détaille ces blocs — rôle, contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire, tâche, contraintes, format, exemples — et montre comment les combiner selon la complexité réelle de la tâche à accomplir.

Cette décomposition n'est pas un exercice académique. Elle sert un objectif concret : diagnostiquer rapidement pourquoi un prompt échoue. Face à un résultat insatisfaisant, un utilisateur qui connaît l'anatomie d'un prompt sait immédiatement où chercher — un contexte manquant, une contrainte non formulée, un format resté implicite — plutôt que de reformuler au hasard jusqu'à obtenir un résultat acceptable par tâtonnement.

Chaque bloc décrit dans ce chapitre répond à une question précise que le modèle se pose implicitement : qui dois-je incarner, de quoi est-ce que je dispose, que dois-je produire, dans quelles limites, sous quelle forme, et à quoi ressemble un bon résultat. Omettre un bloc, c'est laisser le modèle répondre à cette question à votre place — selon la régularité la plus probable, pas selon votre intention réelle.

Les six composants d'un prompt professionnel

Tous les prompts n'ont pas besoin des six composants. Une question factuelle simple se contente souvent d'une tâche clairement énoncée. Mais dès qu'un prompt doit être réutilisé, partagé en équipe ou intégré à un processus, chacun des six blocs mérite d'être considéré explicitement — même si la décision finale est de l'omettre volontairement.

1. Le rôle

Le rôle indique au modèle sous quelle posture il doit produire la réponse — quel niveau d'expertise, quelle perspective professionnelle, quel registre de vocabulaire adopter. « Tu es juriste spécialisé en droit du travail » ne transforme pas le modèle en juriste, mais oriente fortement le vocabulaire, le niveau de prudence et les angles d'analyse mobilisés dans la réponse générée.

Le rôle est utile lorsque plusieurs perspectives professionnelles pourraient légitimement traiter le même sujet différemment — un même contrat lu par un juriste, un contrôleur de gestion ou un commercial n'appelle pas la même analyse. Il est superflu, voire contre-productif, sur une tâche mécanique comme l'extraction de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire d'un tableau, où il n'ajoute rien à la précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire du résultat et alourdit inutilement le prompt.

2. Le contexte

Le contexte regroupe les faits, données ou références nécessaires pour que la réponse s'ancre dans le cas réel traité, et non dans une généralité statistiquement plausible. C'est le bloc le plus souvent négligé, car ce qui est évident pour l'utilisateur ne l'est jamais pour le modèle, qui ne dispose que de ce qui figure explicitement dans le prompt.

Annoncer le sujet (« Ce prompt concerne un contrat de prestation ») n'est pas fournir du contexte. Fournir le contexte, c'est joindre le contrat réel, ou les clauses concernées, ou les montants en jeu — les éléments concrets à partir desquels une réponse spécifique peut être produite plutôt qu'une réponse générique sur le sujet annoncé.

3. La tâche

La tâche est l'instruction centrale : ce que le modèle doit effectivement produire. Elle gagne à être formulée par un verbe d'action précis — résumer, classer, comparer, réécrire, extraire — plutôt que par une question ouverte qui laisse le type de réponse indéterminé.

Une tâche mal délimitée mélange souvent plusieurs objectifs distincts dans une seule phrase, ce qui pousse le modèle à arbitrer lui-même l'ordre de priorité. « Analyse ce document, donne-moi des recommandations et résume les risques » contient en réalité trois tâches distinctes, que le modèle traitera dans un ordre et avec un niveau de détail qu'il choisira seul, faute de hiérarchie explicite.

4. Les contraintes

Les contraintes fixent les limites de la réponse : longueur, ton, périmètre d'information autorisé, éléments à exclure explicitement. Elles sont souvent le bloc le plus rentable à ajouter, car elles réduisent immédiatement la variance du résultat sans nécessiter de reformulation complexe du reste du prompt.

Une contrainte efficace est vérifiable. « Réponds de façon concise » est une contrainte molle, sujette à interprétation — concis pour qui, par rapport à quoi ? « Réponds en 100 mots maximum, sans introduction ni conclusion » est une contrainte vérifiable : n'importe qui peut constater, en lisant le résultat, si elle a été respectée ou non.

5. Le format de sortie

Le format précise la structure exacte attendue en sortie : tableau, liste à puces, JSON, plan en sections numérotées. C'est le bloc qui détermine si un résultat par ailleurs correct sur le fond est exploitable immédiatement ou nécessite une reformulation manuelle avant usage — une différence qui pèse lourd dès que le volume de traitement augmente.

Plutôt que d'écrire « donne-moi un tableau avec les colonnes nom, date et statut », fournissez directement le squelette attendu : un en-tête de tableau vide, ou un exemple de ligne remplie. Le modèle reproduit une structure montrée avec beaucoup plus de fiabilité qu'une structure seulement décrite en langage naturel.

6. Les exemples — positifs et négatifs

Les exemples illustrent concrètement ce qu'une bonne réponse doit contenir. On parle de prompt few-shotFew-shotIATechnique de prompt où l'on fournit quelques exemples entrée-sortie pour guider le modèle sans réentraînement.Voir dans le glossaire lorsque plusieurs exemples accompagnent l'instruction générale. Un seul exemple bien choisi élimine souvent plus d'ambiguïté qu'un paragraphe entier de description abstraite.

Les exemples négatifs, moins connus, jouent un rôle tout aussi important : ils montrent ce qu'il ne faut pas produire, et pourquoi. Leur usage correct diffère sensiblement de celui des exemples positifs, et ce chapitre y consacre une section dédiée plus loin.

L'ordre des blocs : pourquoi il n'est pas neutre

L'ordre dans lequel les blocs apparaissent dans un prompt influence le résultat, en particulier sur les prompts longs. Deux principes pratiques se dégagent de l'usage professionnel courant.

Premièrement, les instructions générales — rôle, tâche, contraintes — gagnent à précéder le contexte volumineux, notamment lorsque celui-ci est long : document entier, extrait de base de données, historique d'échanges. Un modèle qui lit d'abord l'instruction sait quoi chercher en traitant le contexte qui suit ; un modèle qui lit d'abord une masse d'information sans savoir ce qu'on attendra de lui la traite sans grille de lecture, et risque d'en extraire les mauvais éléments.

Deuxièmement, le format de sortie et les exemples gagnent à être placés en fin de prompt, juste avant que le modèle ne commence à générer sa réponse. C'est l'information la plus récente dans le prompt qui influence le plus directement la structure de ce qui va être produit — un principe qui vaut particulièrement pour les prompts dépassant quelques paragraphes.

Empiler du contexte, des contraintes et des exemples sans séparation claire — sans titres, sans balises, sans sauts de ligne — produit un bloc de texte dans lequel le modèle peine à distinguer une instruction d'une donnée parmi d'autres. Structurez visuellement le prompt avec des sections identifiables ; cela coûte quelques secondes de rédaction et évite des heures de correction en aval.

Étude de cas : avant / après

Prompt occasionnel : « Classe ce ticket de support dans la bonne catégorie. » Résultat probable : une catégorie choisie sans que l'on sache si elle provient d'une liste fixe ou inventée à la volée, sans justification, et sans garantie de cohérence d'un ticket à l'autre.

Prompt professionnel : « Tu es agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire de classification pour un service support B2B [rôle]. Voici les cinq catégories valides : Accès compte, Facturation, Bug technique, Demande fonctionnalité, Autre [contexte]. Lis le ticket ci-dessous et attribue-lui une seule catégorie parmi ces cinq [tâche]. Si le ticket mentionne plusieurs sujets, retiens le motif principal exprimé dans les deux premières phrases, pas les sujets évoqués en passant [contrainte]. Réponds uniquement au format JSON : {"categorie": "...", "justification": "..."} [format]. Exemple : un ticket qui commence par se plaindre d'un mot de passe refusé, puis mentionne en fin de message un désaccord sur une facture, doit être classé Accès compte, pas Facturation [exemple négatif implicite]. » Résultat probable : une catégorie choisie parmi une liste fermée, une justification vérifiable, un format directement exploitable par le système de ticketing, et une règle explicite pour trancher les cas ambigus.

La différence ne tient pas à une formulation plus habile au sens littéraire du terme. Elle tient à la quantité d'ambiguïté retirée avant que le modèle ne commence à générer. Sur un volume de plusieurs centaines de tickets par semaine, l'écart entre les deux prompts se traduit directement en heures de reclassification manuelle évitées.

Pourquoi les exemples négatifs comptent autant que les positifs

Un exemple positif montre une trajectoire à suivre. Un exemple négatif élimine une trajectoire proche, mais fausse, que le modèle emprunterait spontanément sans cet avertissement. Cette distinction compte particulièrement lorsque l'erreur probable n'est pas une erreur grossière, mais une erreur plausible — le genre d'erreur qu'un exemple positif seul ne suffit pas à écarter.

Reprenons l'exemple de la classification de tickets. Un exemple positif montre qu'un ticket relatif à un mot de passe oublié doit être classé « Accès compte ». Mais si un ticket évoque à la fois un problème de connexion et une insatisfaction sur la facturation, le modèle peut plausiblement le classer « Facturation » faute d'indication contraire, parce que ce mot y figure aussi. Un exemple négatif ciblé sur exactement ce cas de confusion élimine l'ambiguïté beaucoup plus efficacement qu'une règle générale abstraite.

Les exemples négatifs sont particulièrement utiles dans trois situations : lorsque le prompt remplace un prompt précédent qui produisait une erreur récurrente déjà identifiée, auquel cas montrer explicitement cette erreur à éviter est la correction la plus directe ; lorsque deux catégories ou deux styles de réponse sont proches et risquent d'être confondus ; et lorsque le résultat attendu s'écarte d'un réflexe courant du modèle, comme le fait de préférer une réponse exhaustive et prudente à une réponse volontairement tranchée et concise.

Montrer un contre-exemple sans expliquer ce qui le rend incorrect pousse parfois le modèle à en reproduire des caractéristiques accessoires, sans comprendre la règle réelle. « Ne fais pas comme ceci : [exemple], car cela mélange décision actée et hypothèse non validée » est plus efficace que le contre-exemple présenté seul, sans justification.

Pièges fréquents dans la construction d'un prompt

Certaines erreurs reviennent systématiquement, y compris chez des utilisateurs déjà expérimentés :

• Confondre contexte et tâche. Décrire longuement le sujet du document sans jamais préciser ce qu'on attend en sortie produit un prompt qui ressemble à une introduction, pas à une instruction.
• Multiplier des contraintes contradictoires. Demander une réponse « exhaustive » et « en 50 mots maximum » dans le même prompt force le modèle à arbitrer une contradiction que vous n'avez pas tranchée vous-même.
• Fournir un seul exemple trop spécifique. Un unique exemple positif pousse parfois le modèle à reproduire des détails accessoires de cet exemple — un nom, un chiffre, un tour de phrase — au lieu du principe général qu'il était censé illustrer.
• Utiliser un rôle comme un gadget sans effet réel. Ajouter « Tu es un expert de classe mondiale » n'améliore pas la justesse d'une réponse factuelle ; seul un rôle qui change réellement la perspective d'analyse a un effet mesurable.
• Laisser le format implicite alors que la sortie alimente un autre système. Un texte libre, même bien écrit, qui doit ensuite être découpé manuellement en champs structurés, annule une bonne partie du gain de temps recherché.

Checklist de relecture avant envoi

Avant d'envoyer un prompt destiné à un usage récurrent, vérifiez chacun des points suivants :

• Le rôle est-il nécessaire, et s'il est présent, change-t-il réellement la perspective attendue ?
• Le contexte contient-il des données concrètes, ou seulement une annonce du sujet ?
• La tâche est-elle formulée par un seul verbe d'action clair, ou mélange-t-elle plusieurs objectifs ?
• Chaque contrainte est-elle vérifiable a posteriori sur le résultat obtenu ?
• Le format attendu est-il montré, ou seulement décrit en langage naturel ?
• Au moins un exemple négatif cible-t-il une confusion plausible identifiée au préalable ?

Reprenez un prompt que vous utilisez régulièrement et annotez-le bloc par bloc — rôle, contexte, tâche, contraintes, format, exemples. Les blocs absents ou fusionnés dans une phrase confuse indiquent précisément où porter l'effort de reformulation en priorité.

Ce qu'il faut retenir

Un prompt professionnel n'est pas plus long qu'un prompt occasionnel par souci de forme : il est plus long parce qu'il rend explicite ce que le prompt occasionnel laisse deviner au modèle. Les six blocs présentés dans ce chapitre — rôle, contexte, tâche, contraintes, format, exemples — ne sont pas tous nécessaires à chaque usage, mais chacun mérite d'être considéré consciemment plutôt qu'omis par défaut.

Le chapitre suivant approfondit la décomposition des tâches complexes en étapes intermédiaires, pour les cas où un seul bloc « tâche » ne suffit plus à cadrer correctement un traitement en plusieurs phases.