Prompt engineering : guide français complet et pratique

Vous demandez à une IA de rédiger un article, puis vous obtenez une réponse vague, trop longue ou remplie d’affirmations invérifiables. Le problème ne vient pas toujours du modèle. Un prompt engineering efficace consiste à transformer une intention floue en consigne testable, avec un contexte, des contraintes, un format de sortie et des critères de réussite. En pratique, commencez par écrire le résultat attendu, ajoutez les données utiles, donnez un exemple si le style compte, puis évaluez la réponse avant de modifier la consigne.

Ce guide français propose une méthode réutilisable pour ChatGPT, Claude, Gemini, Ollama et les API de modèles de langage. L’objectif n’est pas de trouver une formule magique, mais de construire des prompts fiables, versionnés et adaptés à votre travail.

Prompt engineering, définition simple

Le prompt engineering est la conception et l’amélioration méthodique des instructions envoyées à un modèle d’intelligence artificielle. Le prompt peut demander une réponse, une transformation, une classification, du code ou une action dans un workflow. L’ingénierie commence lorsque vous ne vous contentez plus d’une demande improvisée et que vous observez la qualité obtenue sur plusieurs cas réels.

Un bon prompt ne sert pas à rendre le modèle plus intelligent. Il réduit l’ambiguïté, expose les informations que le modèle ne peut pas deviner et fixe une forme de réponse exploitable. Il doit aussi indiquer ce que faire lorsque les données manquent. Cette dernière règle est essentielle pour limiter les inventions.

Les recommandations officielles d’OpenAI, Anthropic et Google convergent sur un point : un prompt se travaille par itérations et doit être évalué sur un objectif précis. Anthropic recommande notamment de définir les critères de réussite et un moyen de les mesurer avant de modifier la consigne.

La structure en cinq blocs qui fonctionne

Pour une tâche professionnelle, séparez la consigne en cinq blocs. Le rôle décrit le point de vue attendu. Le contexte fournit les faits, les documents ou le public. La tâche précise le verbe d’action. Les contraintes encadrent ce qui est autorisé. Le format de sortie indique exactement ce que vous voulez récupérer.

<role>
Tu es un rédacteur technique spécialisé en WordPress.
</role>

<context>
Public : administrateur débutant.
Sujet : erreur 500 après une mise à jour PHP.
Sources autorisées : les liens fournis dans le dossier.
</context>

<task>
Explique le diagnostic dans l’ordre le plus sûr.
</task>

<constraints>
N’invente aucune commande. Signale les informations manquantes.
</constraints>

<output>
Un résumé de 60 mots, puis six étapes numérotées et une checklist.
</output>

Les balises XML ne sont pas obligatoires. Des titres Markdown ou des délimiteurs explicites conviennent aussi. Leur avantage est de séparer les instructions des données. Cette séparation est particulièrement utile quand un document fourni par un utilisateur peut contenir des phrases qui ressemblent à des ordres.

Écrire une consigne claire sans la rendre inutilement longue

Commencez par un résultat observable. « Fais mieux » ne permet pas de décider si la réponse est correcte. « Réécris cette introduction en 120 mots, pour un lecteur débutant, avec une définition et un exemple » fournit un test immédiat. Précisez le public, le niveau technique, la langue, le ton et le canal de diffusion uniquement lorsqu’ils changent réellement la sortie.

Préférez les verbes concrets : extraire, comparer, corriger, classer, résumer, expliquer, convertir. Remplacez les adjectifs vagues par des critères. Une réponse « professionnelle » peut devenir une réponse avec trois recommandations hiérarchisées, une justification par recommandation et une réserve lorsque la preuve manque.

Regroupez les contraintes qui se contredisent. Une limite de 100 mots et une demande de couverture exhaustive ne peuvent pas être satisfaites simultanément. Donnez une priorité : exactitude, exhaustivité, brièveté ou style. Le modèle pourra alors arbitrer au lieu de produire un compromis confus.

Zero shot, few shot et exemples bien choisis

Le zero shot demande la tâche sans exemple. Il suffit pour une opération simple et permet de garder un prompt court. Le few shot ajoute quelques paires entrée sortie afin de montrer une classification, un ton ou une structure. Les exemples ne remplacent pas la consigne : ils montrent le comportement attendu sur des cas représentatifs.

Un bon exemple couvre un cas normal, un cas limite et, si nécessaire, un cas où la réponse doit être « données insuffisantes ». Gardez le même format pour chaque exemple. Si vous donnez trois sorties avec des structures différentes, le modèle devra deviner laquelle imiter.

Tâche : classer le ticket et répondre en une phrase.

Exemple 1
Ticket : Le formulaire affiche une page blanche après l’envoi.
Sortie : catégorie=erreur serveur ; réponse=Vérifiez le journal PHP et le code HTTP.

Exemple 2
Ticket : Je veux ajouter un logo dans l’en-tête.
Sortie : catégorie=personnalisation ; réponse=Indiquez votre thème et la méthode utilisée.

Nouveau ticket : {{ticket}}
Répondez exactement avec catégorie=... ; réponse=...

Deux à cinq exemples soigneusement choisis valent souvent mieux qu’une longue liste de règles. Testez toutefois la consigne sur des demandes différentes de celles présentes dans les exemples. Sinon, vous risquez de mesurer la mémorisation d’un motif plutôt que la capacité à généraliser.

Contexte long, sources et sorties structurées

Un modèle ne sait pas automatiquement quelles informations de votre entreprise sont exactes. Fournissez les extraits pertinents et identifiez leur origine. Demandez de citer le passage utilisé ou de distinguer les faits des recommandations. Pour un document long, annoncez les sections, utilisez des délimiteurs et rappelez la question à la fin si la documentation officielle du modèle le conseille.

Pour une intégration, ne demandez pas seulement « renvoie du JSON ». Définissez les champs, les types, les valeurs autorisées et le comportement en cas d’absence. Quand l’API le permet, utilisez une sortie structurée ou un schéma validé côté application. Une validation locale reste nécessaire, car une réponse bien formée peut contenir une information fausse.

{
  "type": "object",
  "properties": {
    "priority": {"type": "string", "enum": ["low", "medium", "high"]},
    "reason": {"type": "string"},
    "needs_human": {"type": "boolean"}
  },
  "required": ["priority", "reason", "needs_human"],
  "additionalProperties": false
}

Pour des données sensibles, limitez ce qui entre dans le prompt. Supprimez les identifiants inutiles, masquez les secrets et vérifiez la politique de conservation du fournisseur. Un prompt bien écrit ne corrige pas une mauvaise gouvernance des données.

Adapter le prompt au modèle utilisé

Les modèles ne réagissent pas tous de la même manière à une instruction identique. Les modèles généralistes suivent souvent mieux une consigne explicite sur le format. Les modèles de raisonnement peuvent préférer un objectif clair et moins de micro gestion. Un petit modèle local peut avoir besoin d’un contexte plus court, d’un vocabulaire direct et d’exemples très réguliers.

Ne publiez pas une promesse de compatibilité sans test. Faites passer le même jeu d’évaluation à votre modèle distant et à votre modèle local. Mesurez l’exactitude, le respect du format, le coût, la latence et le taux de refus. Notre guide Ollama en français détaille l’installation, les modèles et l’API locale. Pour les assistants connectés à des outils, consultez aussi notre guide du serveur MCP.

Évitez de citer des versions que vous n’avez pas vérifiées. Les noms, limites de contexte et comportements changent. Le prompt doit décrire la tâche de manière durable, tandis que la configuration de modèle reste dans votre code ou votre environnement de déploiement.

Évaluer puis améliorer un prompt

La méthode la plus rentable est de constituer un petit jeu de tests. Commencez avec 10 à 30 requêtes représentatives, annotées par une personne. Pour chaque réponse, notez séparément l’exactitude, la complétude, le format, le ton et la sécurité. Une moyenne unique masque souvent un défaut important, par exemple une bonne rédaction mais des citations inventées.

Changez une seule famille de variables à la fois. Vous pouvez d’abord clarifier la tâche, puis ajouter un exemple, puis modifier le format. Conservez la version précédente afin de comparer les résultats. Si le score baisse sur un cas limite, ne le sacrifiez pas sans décision explicite.

tests = [
    {"input": "Erreur 404 après changement de slug", "expected": "permalien"},
    {"input": "Réponse sans preuve dans le document", "expected": "a_verifier"},
]

for test in tests:
    result = run_prompt(test["input"])
    ok = test["expected"] in result
    print({"input": test["input"], "ok": ok})

Versionnez le prompt comme du code. Ajoutez un identifiant de version dans vos logs, anonymisez les entrées et gardez quelques réponses pour les régressions. OpenAI recommande des fixtures, des tests et des évaluations avant de modifier un prompt de production. Cette discipline évite de corriger un exemple au prix de cinq autres.

Sécurité, injection et limites de la consigne

Un prompt système n’est pas une frontière de sécurité suffisante. Une entrée utilisateur, une page web récupérée ou un fichier importé peut contenir une instruction malveillante. OWASP classe l’injection de prompt parmi les risques majeurs des applications LLM et distingue les injections directes des injections indirectes.

Traitez les données externes comme des données, jamais comme des instructions. Séparez les rôles, filtrez les entrées, réduisez les permissions des outils et demandez une confirmation humaine avant une action irréversible. N’accordez pas à un agent l’accès à la messagerie, au système de fichiers ou à une API sensible simplement parce que le prompt lui demande d’être prudent.

Les garde fous utiles sont donc répartis dans plusieurs couches : validation côté application, contrôle d’accès, liste d’outils autorisés, limites de débit, journalisation et évaluation adversariale. NIST recommande de gérer les risques de l’IA sur l’ensemble du cycle de vie, pas seulement au moment de rédiger la consigne.

Checklist d’un prompt prêt pour la production

• Le résultat attendu peut être vérifié sans interprétation subjective.
• Le public et le contexte indispensable sont présents.
• Les données sont séparées des instructions.
• Les contraintes sont compatibles et hiérarchisées.
• Le format de sortie est précis et validé par l’application.
• Les cas d’incertitude et de données manquantes sont prévus.
• Un jeu de tests couvre les cas normaux et limites.
• La version du prompt et le modèle sont journalisés.
• Les permissions ne dépendent pas d’une phrase du prompt.

Pour relier cette méthode au développement assisté, notre article sur le vibe coding rappelle que l’outil accélère la production, mais que les tests et la revue restent à la charge de l’équipe. Le prompt engineering devient vraiment utile lorsque la consigne, l’évaluation et le contrôle du résultat forment un même processus.

FAQ sur le prompt engineering

Quelle est la différence entre prompt et prompt engineering ?

Un prompt est une instruction envoyée à un modèle. Le prompt engineering désigne la conception, le test et l’amélioration de cette instruction pour obtenir un résultat plus fiable.

Faut il écrire un prompt très long ?

Non. Ajoutez uniquement le contexte et les contraintes qui changent la décision. Une consigne courte et testable vaut mieux qu’un texte long rempli de règles contradictoires.

Les exemples sont ils toujours nécessaires ?

Non. Une tâche simple peut fonctionner sans exemple. Ajoutez quelques exemples lorsque le format, le ton ou la classification doit être reproduit avec régularité.

Comment éviter les hallucinations avec un prompt ?

Fournissez des sources, demandez de signaler les informations absentes et vérifiez la réponse dans votre application. Aucun prompt ne garantit à lui seul la vérité d’un résultat.

Le prompt engineering protège t il contre l’injection ?

Non. Il peut clarifier les rôles, mais la sécurité exige aussi des permissions minimales, une validation des entrées, des contrôles applicatifs et une confirmation humaine pour les actions sensibles.

Sources officielles

• OpenAI, guide de prompt engineering
• Anthropic, présentation du prompt engineering
• Google, stratégies de conception des prompts
• OWASP, risques des applications LLM
• OWASP, prévention de l’injection de prompt
• NIST, profil de gestion des risques de l’IA générative