Prompts ChatGPT : écrire des instructions fiables

Le prompt engineering est souvent traité comme un ensemble d'astuces. Cette approche est insuffisante dès qu'un modèle de langage entre dans un workflow sérieux. Un prompt utile doit être pensé comme une interface entre une intention humaine et un système probabiliste.

L'objectif n'est pas d'impressionner le modèle. L'objectif est de réduire l'ambiguïté.

Un prompt est une spécification

Un bon prompt dit au modèle :

• quel rôle adopter
• quelle tâche accomplir
• quel contexte utiliser
• quel format de sortie respecter
• quelles limites ne pas franchir

Exemple faible :

Résume ce document.

Exemple exploitable :

Tu es un assistant technique.
Résume ce document pour une équipe backend.
Fais 5 points maximum.
Mets en avant les risques, les décisions et les dépendances.
N'invente rien si une information manque.

La seconde version ne rend pas le modèle "plus intelligent". Elle rend l'attente plus claire.

Les 5 blocs d'un prompt robuste

Pour la plupart des cas d'usage, un prompt sérieux contient cinq blocs.

1. L'objectif

Commencez par le résultat attendu et son destinataire. Un rôle peut préciser la perspective, mais « tu es un expert mondial » ne compense jamais une tâche floue.

• objectif : résumer une décision technique
• destinataire : équipe backend
• usage : préparer la prochaine réunion

2. La tâche

La tâche doit être explicite :

• résumer
• extraire
• classer
• générer
• reformuler

3. Le contexte délimité

Le contexte doit être utile, pas massif. Séparez clairement les instructions des données à traiter avec des balises ou des délimiteurs. Le contenu d'un ticket, d'un e-mail ou d'une page web reste une donnée non fiable : il ne doit pas pouvoir redéfinir la tâche.

4. Les contraintes

Exemples :

• ne pas inventer d'informations
• utiliser un ton professionnel
• respecter une longueur maximale
• répondre en JSON

5. Le format de sortie

Si la sortie doit être exploitée par une application, le format doit être imposé et validé côté code.

Un modèle réutilisable

Pour une tâche courante, ce squelette suffit souvent :

Objectif : résumer une décision technique pour une équipe backend.

Contexte :
<document>
{{CONTENU}}
</document>

Contraintes :
- utilise uniquement les informations du document ;
- signale explicitement toute information manquante ;
- distingue les décisions, les risques et les actions.

Format attendu :
- 5 points maximum ;
- une section « À confirmer » si nécessaire ;
- aucune introduction générique.

Les balises ne rendent pas le contenu sûr par elles-mêmes. Elles rendent la frontière visible et facilitent l'application de règles supplémentaires dans le code.

La plupart des mauvais prompts échouent pour des raisons prévisibles

Les causes d'échec les plus fréquentes sont:

• objectif flou
• contexte incomplet
• consignes contradictoires
• absence de format attendu
• attente implicite de raisonnement métier non fourni

Quand un modèle répond mal, le problème n'est pas toujours le modèle. C'est souvent une spécification pauvre.

Quand il faut imposer un format strict

Dès qu'une sortie alimente un autre composant logiciel, il faut privilégier une structure stable.

Retourne strictement un JSON avec:
- intent: string
- confidence: number
- requires_human_review: boolean

Dans un système de production, ne vous contentez pas de demander du JSON dans le texte. Utilisez une sortie contrainte par un schéma lorsque le fournisseur le permet, puis désérialisez et validez le résultat. Prévoyez aussi le refus du modèle, un champ absent et une valeur métier invalide.

Le bon niveau de détail

Un prompt trop court laisse trop d'interprétation. Un prompt trop long dilue le signal.

La bonne pratique est de donner:

• assez de contexte pour cadrer
• assez peu de bruit pour garder la tâche lisible

Il faut donc supprimer tout ce qui ne change pas réellement la qualité de la sortie.

Les exemples sont utiles, mais pas toujours

Le few-shot prompting fonctionne bien pour montrer :

• le style attendu
• le niveau de détail
• le schéma de sortie
• la distinction entre bon et mauvais résultat

Mais si la tâche est déjà claire et stable, multiplier les exemples peut augmenter le coût et la latence sans gain significatif. Commencez sans exemple, observez les erreurs récurrentes, puis ajoutez uniquement les cas qui lèvent une ambiguïté réelle.

Tester un prompt au lieu de le juger à l'œil

Un prompt n'est pas fiable parce qu'il a réussi une fois. Préparez un petit jeu de cas représentatifs : entrée normale, contexte incomplet, texte très long, formulation ambiguë et contenu contradictoire. Pour chaque cas, définissez les propriétés attendues de la réponse.

Suivez des critères utiles au produit : exactitude des faits extraits, respect du format, taux de réponse nécessitant une reprise humaine, coût et latence. Rejouez ces cas après un changement de prompt ou de modèle. Cette démarche évite d'améliorer un exemple visible tout en dégradant les autres.

Prompt engineering et architecture applicative

Dans une application, le prompt ne doit pas vivre caché dans un contrôleur. Il doit être:

• versionné
• relu
• testé
• rattaché à un cas d'usage précis

Exemple:

public sealed class TicketSummaryPrompt
{
    public string Build(string ticketText) => $"""
        Objectif : résumer ce ticket pour l'équipe support.
        Contraintes : 4 points maximum, mentionner l'urgence
        si elle est explicite et ne pas inventer de cause.

        <ticket>
        {ticketText}
        </ticket>
        """;
}

Ici, le prompt devient un composant applicatif maintenable. En production, conservez également son identifiant de version dans les traces afin de relier une régression au bon changement.

Ce qu'un prompt ne corrigera jamais

Un bon prompt n'efface pas:

• un mauvais cas d'usage
• un manque de contexte fiable
• une sortie impossible à vérifier
• une intégration applicative mal pensée

Le prompt engineering n'est pas un substitut à l'architecture.

Conclusion

L'art des prompts consiste moins à trouver la formule parfaite qu'à écrire des instructions claires, testables et orientées résultat. Plus le système est important, plus le prompt doit être traité comme une spécification technique.

Un bon prompt ne cherche pas à "convaincre" le modèle. Il cherche à rendre la tâche difficile à mal comprendre.

Pour approfondir, OpenAI publie ses bonnes pratiques de prompt engineering pour ChatGPT, notamment sur la clarté des consignes et l'amélioration itérative.