Prompt engineering : cadrer un modèle pour des tâches métier

Demander à un assistant conversationnel de « résumer ce texte » donne un résultat différent à chaque fois. C’est sans conséquence pour un usage personnel ; c’est rédhibitoire pour une tâche métier, où l’on attend le même format, la même rigueur et la même prudence pour le millième document que pour le premier. Le prompt engineering est l’art d’écrire des consignes qui rendent le comportement d’un modèle de langage fiable et reproductible. Cet article en présente les principes, tels qu’ils ressortent des guides officiels d’Anthropic, d’OpenAI et de Google, puis les applique à un cas concret.

Objectifs d’apprentissage

• considérer un prompt comme une spécification, avec des critères de réussite vérifiables ;
• connaître les composantes d’un prompt efficace et la façon de les structurer ;
• utiliser les exemples (few-shot) à bon escient ;
• évaluer et versionner un prompt comme on teste et versionne du code.

1. Un prompt est une spécification

Anthropic ouvre son guide par une étape qui précède toute technique : définir les critères de réussite et un moyen de les tester. Avant d’écrire la moindre consigne, demandez-vous : à quoi reconnaîtrai-je une bonne réponse ? Quel format exact ? Que doit faire le modèle quand l’information manque ?

Une image utile : rédigez votre prompt pour un collaborateur brillant mais nouveau, qui ne connaît ni votre établissement, ni vos conventions, ni la raison de la tâche. Tout ce que vous ne lui dites pas, il le devinera, et ses suppositions ne seront pas les vôtres.

2. Les composantes d’un prompt efficace

Les trois guides convergent sur un petit nombre d’éléments :

Deux conseils de forme ont un effet mesurable. D’abord, séparer les parties du prompt avec des balises XML (<instructions>, <contexte>, <exemple>) ou des titres Markdown, pour que le modèle ne confonde pas une consigne avec une donnée. Ensuite, pour les longs documents, Anthropic recommande de placer les documents en tête et la question à la fin, et indique que cette disposition peut améliorer la qualité des réponses jusqu’à 30 % dans ses tests.

Enfin, donnez la raison de vos règles. Une consigne justifiée (« réponds en phrases courtes, car le texte sera lu à voix haute ») se généralise mieux qu’une consigne nue, appliquée trop littéralement.

3. Les exemples : la technique la plus fiable

Montrer vaut mieux que décrire. Les guides d’Anthropic qualifient les exemples de moyen parmi les plus fiables d’orienter le format, le ton et la structure, et suggèrent trois à cinq exemples pertinents, variés et balisés. Google les recommande par défaut, mais prévient que trop d’exemples peuvent conduire le modèle à les imiter servilement. Choisissez donc des exemples qui couvrent les cas difficiles, notamment ceux que l’on confond facilement.

4. Exemple guidé : trier les courriels d’un service de scolarité

Un service reçoit chaque jour des dizaines de courriels d’étudiants. On souhaite les orienter automatiquement vers le bon bureau, sans jamais répondre à leur place.

<role>
Tu assistes le service de scolarité de l'Université. Tu ne réponds
pas aux étudiants : tu classes leurs messages pour un agent humain.
</role>

<bureaux>
- inscriptions : inscription, réinscription, frais, carte d'étudiant
- examens : calendrier, convocations, notes, réclamations de notes
- diplomes : attestations, relevés, retrait de diplôme
- autre : tout ce qui ne relève pas clairement des trois bureaux
</bureaux>

<consignes>
Réponds uniquement avec un objet JSON :
{"bureau": "...", "urgence": "haute|normale", "resume": "une phrase"}
"urgence" vaut "haute" si une échéance de moins de 7 jours est
mentionnée. En cas de doute sur le bureau, choisis "autre" : un agent
réorientera le message, alors qu'un mauvais classement le retarderait.
</consignes>

<exemple>
Message : "Bonjour, ma note de statistiques n'apparaît pas alors que
les délibérations sont vendredi."
Sortie : {"bureau": "examens", "urgence": "haute",
"resume": "Note manquante avant les délibérations de vendredi."}
</exemple>

<message>{{texte_du_courriel}}</message>

Observez les choix. La sortie est un JSON, que votre programme valide avant tout usage : l’OWASP recommande précisément de vérifier le format de sortie avec du code déterministe. Le cas d’incertitude est prévu et justifié. Et le message de l’étudiant est placé dans une balise dédiée, pour qu’un texte du type « ignore tes consignes » soit traité comme une donnée.

5. Réduire les hallucinations

Pour les tâches qui s’appuient sur des documents, la documentation d’Anthropic propose trois stratégies de base :

• autoriser « je ne sais pas » explicitement ;
• faire extraire des citations exactes avant de répondre, pour ancrer la réponse dans le texte ;
• exiger une source pour chaque affirmation, ce qui rend la réponse vérifiable.

6. Évaluer et versionner

Un prompt se juge sur un jeu de cas fixes, jamais sur une réponse réussie. Constituez une trentaine de messages réels anonymisés, avec la sortie attendue ; à chaque modification du prompt, relancez le jeu et comparez le taux de réussite. OpenAI recommande en outre d’épingler une version précise du modèle en production et de construire des suites d’évaluation, car même deux versions d’une même famille peuvent se comporter différemment. Conservez vos prompts dans le dépôt de code, avec le modèle sur lequel ils ont été testés.

Erreurs fréquentes

• Corriger un prompt au vu d’un seul exemple raté, et en dégrader dix autres sans le voir.
• Mélanger consignes et données sans délimitation.
• Exiger un format sans le valider par programme.
• Changer de modèle sans relancer l’évaluation.

À retenir

Un bon prompt est une spécification claire, structurée, illustrée d’exemples, et testée sur un jeu de cas fixes. La créativité vient ensuite ; la reproductibilité d’abord.

Références

• Anthropic, Prompting best practices.
• Anthropic, Reduce hallucinations.
• OpenAI, Prompt engineering.
• Google, Prompt design strategies.
• OWASP, LLM01:2025 Prompt Injection.