Comment écrire un bon prompt IA : la méthode du brief exécutable

Un bon prompt IA n'est pas une formule magique. C'est un brief assez clair pour qu'un modèle sache quoi faire, avec quelle matière, dans quelles limites et sous quelle forme rendre le résultat. La méthode la plus fiable consiste à écrire une demande comme vous la donneriez à un collaborateur : objectif, contexte, contraintes, exemples, format de sortie et règle d'itération.

Le prompt engineering, ou ingénierie de prompt, désigne ce travail de conception et d'amélioration des consignes. La documentation OpenAI le résume autour d'un principe simple : des instructions claires, spécifiques, avec assez de contexte et un format attendu améliorent la qualité des réponses : Prompt engineering.

Besoin et brief : la différence qui change tout

Un besoin décrit ce que vous voulez obtenir. Un brief décrit comment le modèle doit travailler pour produire quelque chose d'utilisable.

Besoin :

Écris une réponse à ce prospect.

Brief :

Rédige un brouillon de réponse professionnelle à un prospect B2B.
Objectif : clarifier son besoin et proposer un rendez-vous.
Contexte : il demande si nous pouvons automatiser le tri des demandes entrantes.
Contraintes : ne promets aucun résultat chiffré, ne parle pas de prix, pose deux questions maximum.
Format : 120 mots, ton sobre, terminé par une proposition de créneau.

Le premier prompt oblige le modèle à deviner. Le second réduit l'ambiguïté. Il ne garantit pas une réponse parfaite, mais il rend l'échec plus facile à diagnostiquer : si la sortie parle de prix, la contrainte n'a pas été respectée ; si elle ne propose pas de rendez-vous, l'objectif a été manqué.

Les six blocs d'un prompt utile

1. L'objectif

Commencez par le résultat attendu. Une tâche doit être observable : résumer, classer, comparer, extraire, rédiger, reformuler, diagnostiquer, préparer.

Évitez les verbes flous comme « optimise » si vous ne dites pas ce qui doit changer. « Optimise cette page » peut signifier améliorer le SEO, raccourcir le texte, corriger le style ou augmenter la conversion. « Réécris la description pour tenir entre 120 et 155 caractères et inclure la requête principale » est exécutable.

2. Le contexte

Le context, ou contexte, est la matière que le modèle peut utiliser : audience, objectif business, extrait de document, données, historique utile, décision déjà prise. Un modèle ne devine pas vos règles internes. Elles doivent être fournies ou retrouvées par un système comme le RAG.

Un bon contexte est sélectionné, pas empilé. Trop de texte inutile peut noyer la consigne, augmenter le coût et dégrader la réponse. Pour comprendre cette limite, l'article LLM, tokens et fenêtre de contexte détaille le rôle des tokens et de la fenêtre de contexte.

3. Les contraintes

Les constraints, ou contraintes, fixent les limites. Elles évitent les sorties séduisantes mais inutilisables.

Exemples :

La documentation Microsoft sur les system messages recommande aussi de définir le rôle, le périmètre, les limites et le comportement attendu quand l'information manque : System message design.

4. Les exemples

Les few-shot examples, ou exemples en petit nombre, montrent au modèle le type d'entrée et de sortie attendu. Ils sont utiles quand le style, le format ou le jugement est difficile à décrire.

Exemple :

Exemple d'entrée :
"Bonjour, je veux savoir si vous pouvez automatiser mes e-mails."

Exemple de sortie :
Intention : demande d'automatisation e-mail
Priorité : à qualifier
Question utile : quel volume d'e-mails recevez-vous chaque semaine ?

OpenAI décrit le few-shot learning comme une manière d'orienter un modèle avec quelques exemples d'entrée et de sortie, sans entraîner un modèle spécifique : Few-shot learning.

5. Le format de sortie

Le output format, ou format de sortie, dit à quoi doit ressembler la réponse. Markdown, tableau, JSON ou format de données structuré, liste de décisions, e-mail, plan en H2, ticket technique : le format doit suivre l'usage réel.

Si une application doit lire la réponse, soyez strict. Si un humain doit la relire, restez lisible. Un format trop lourd donne parfois une impression de contrôle, mais ajoute du bruit.

Mauvais format :

Réponds bien et sois structuré.

Meilleur format :

Retourne :
- Diagnostic en 3 lignes
- Risque principal
- Prochaine action
- Question bloquante, si nécessaire

6. L'itération

L'iteration, ou itération, consiste à améliorer le prompt à partir des défauts observés. Ne réécrivez pas tout à chaque essai. Corrigez une chose : contexte manquant, contrainte ambiguë, format trop large ou exemple insuffisant.

La bonne boucle est courte :

  1. lancer le prompt ;
  2. comparer la sortie au résultat attendu ;
  3. nommer l'écart ;
  4. modifier le bloc concerné ;
  5. tester à nouveau sur un cas proche.

Cette discipline compte autant que le prompt initial. Un prompt professionnel est un actif testable, pas une phrase inspirée.

Template copiable : brief exécutable

Rôle :
Tu es [rôle utile pour la tâche].

Objectif :
[Résultat précis attendu].

Contexte :
[Informations nécessaires, sources, audience, situation].

Contraintes :
- [Limite 1]
- [Limite 2]
- [Ce qu'il faut faire si l'information manque]

Exemples :
Entrée : [exemple court]
Sortie attendue : [exemple court]

Format de sortie :
[Structure exacte : liste, tableau, JSON, e-mail, plan, etc.]

Critère de qualité :
La réponse est réussie si [condition observable].

Ce template n'a pas besoin d'être rempli à chaque ligne pour une petite demande. Il sert de check-list. Pour une tâche simple, trois blocs suffisent souvent : objectif, contexte, format.

Avant / après : transformer une demande vague

Avant :

Fais-moi un plan pour automatiser mon service client avec l'IA.

Après :

Prépare un premier plan d'automatisation IA pour une PME de 25 personnes.
Objectif : réduire le temps de traitement des demandes entrantes sans envoyer de réponse automatique aux clients.
Contexte : les demandes arrivent par e-mail et formulaire. Les équipes perdent surtout du temps à trier, résumer et orienter.
Contraintes : ne propose pas de remplacement complet du service client ; distingue ce qui peut être automatisé, assisté ou laissé à l'humain.
Format : tableau avec 4 colonnes : étape, action IA, validation humaine, risque.
Termine par le premier test à lancer cette semaine.

La seconde version ne demande pas seulement une idée. Elle demande un plan exploitable. Elle force aussi une limite importante : l'humain garde la main sur ce qui engage la relation client. Cette logique rejoint le cadrage d'un premier projet dans Automatisation IA en PME et les usages d'un agent IA en entreprise.

System prompt, prompt chaining et prompt engineering

Un system prompt, ou message système, fixe les règles haut niveau d'un assistant : rôle, périmètre, ton, sécurité, format, outils autorisés. Il doit rester aussi court que le permet la tâche et ne pas contenir de contradictions. Microsoft Learn rappelle qu'un message système n'est pas une solution de sécurité complète ; il complète d'autres contrôles comme le filtrage, le grounding, ou ancrage dans des sources, et l'évaluation.

Le prompt chaining, ou chaînage de prompts, consiste à découper une tâche en plusieurs étapes. Au lieu de demander « analyse, décide, rédige et vérifie » en une seule requête, vous pouvez faire :

  1. extraire les faits ;
  2. identifier les informations manquantes ;
  3. proposer une réponse ;
  4. vérifier la réponse contre les contraintes.

Ce découpage est souvent plus fiable quand la tâche comporte du risque ou plusieurs décisions. Il n'est pas nécessaire pour une reformulation simple. La règle reste sobre : une étape de plus seulement si elle réduit une erreur réelle.

Les erreurs fréquentes

La première erreur consiste à confondre longueur et précision. Un prompt long peut rester mauvais s'il mélange objectifs, digressions et contraintes vagues.

La deuxième consiste à demander une qualité abstraite : « sois excellent », « fais mieux », « rends ça premium ». Le modèle a besoin d'un comportement observable : plus court, sourcé, structuré, sans promesse, avec une question de clarification.

La troisième consiste à oublier le cas d'incertitude. Si vous ne dites pas quoi faire quand l'information manque, le modèle peut combler. Pour un usage professionnel, la consigne doit autoriser la réponse « je ne sais pas » ou « information manquante ».

La quatrième consiste à corriger la réponse sans diagnostiquer la couche fautive. Si le même défaut revient, vérifiez successivement le brief, les données fournies, le modèle, les outils et le contrôle de sortie. Placez ensuite la correction dans la couche qui produit réellement l'écart.

FAQ

Faut-il apprendre le prompt engineering pour utiliser l'IA ?

Il faut surtout apprendre à briefer clairement. Le jargon aide moins que la capacité à formuler objectif, contexte, contraintes et format.

Un bon prompt marche-t-il avec tous les modèles ?

Pas exactement. Les modèles réagissent différemment. Un bon brief reste plus portable qu'une astuce de formulation.

Quand utiliser des exemples ?

Quand le résultat attendu dépend d'un style, d'une structure ou d'un jugement difficile à expliquer. Deux exemples bien choisis valent mieux qu'une longue théorie.

Le system prompt suffit-il à contrôler un assistant ?

Non. Il fixe les règles de base, mais il doit être complété par des tests, des limites d'outils, du contrôle humain et une gestion propre du contexte.

Sources de référence

Par

Publié le

Une question précise ? Posez-la au chat →