Votre prompt marche parce qu'aucun vrai utilisateur n'a tapé dedans
Chaque prompt a l'air brillant dans le playground. Vous l'avez écrit, vous savez ce que l'agent doit faire, vous le testez avec des inputs qui matchent votre modèle mental. Puis ça ship, et le premier vrai utilisateur tape « slt tu peux me dire mon solde j'ai oublié mon mail c'est genre jess truc » et l'agent invente avec aplomb une réponse sur autre chose.
Le gap entre un prompt de démo et un prompt de prod est le gap entre « le modèle sait le faire quand on lui demande gentiment » et « le modèle le fait toujours quand l'input est cassé ». Voilà les patterns sur lesquels on s'appuie.
Pattern 1 : Outputs en forme de schéma, toujours
Si l'output de votre prompt alimente un autre système — un tool call, une UI, un autre agent — il doit être structuré. Pas « merci de retourner du JSON ». Utilisez le mode structured output natif du modèle (JSON Schema pour OpenAI, tool use pour Claude, response schema pour Gemini). Ce n'est pas une préférence stylistique ; c'est un levier de robustesse.
const schema = {
type: "object",
properties: {
intent: { type: "string", enum: ["balance", "transfer", "support", "unknown"] },
confidence: { type: "number", minimum: 0, maximum: 1 },
needs_clarification: { type: "boolean" },
clarification_question: { type: "string" },
},
required: ["intent", "confidence", "needs_clarification"],
};
La valeur d'enum unknown plus le booléen needs_clarification est le truc. Vous donnez au modèle une manière socialement acceptable d'admettre qu'il ne sait pas. Si vous ne lui donnez pas cette sortie, il inventera.
Pattern 2 : Few-shot les modes d'échec, pas le happy path
L'instinct est de remplir votre prompt d'exemples de l'agent faisant la bonne chose. Le levier est à l'opposé — montrez au modèle quoi faire quand l'input est cassé.
Un vrai exemple d'un de nos déploiements :
INPUT: « j'voudrais annul le truc de la semaine dernière »
OUTPUT: {
"intent": "support",
"confidence": 0.4,
"needs_clarification": true,
"clarification_question": "Vous pouvez me dire ce que vous voulez annuler ? Un abonnement, une commande, ou autre chose ?"
}
INPUT: « yo »
OUTPUT: {
"intent": "unknown",
"confidence": 0.1,
"needs_clarification": true,
"clarification_question": "Bonjour ! Comment puis-je vous aider aujourd'hui ?"
}
Trois ou quatre comme ça dans un system prompt font plus pour la robustesse en prod que dix exemples happy path.
Pattern 3 : Contraindre la surface, puis élargir
Le mode d'échec le plus courant qu'on voit dans les prompts de founders est trop de surface de capacité. Le prompt dit « tu es un assistant IA utile qui peut tout faire » et puis on s'étonne que l'agent parte hors-script. Commencez l'inverse :
- Listez l'ensemble exact d'actions que l'agent est autorisé à faire
- Dites-lui explicitement quoi faire quand on demande quelque chose hors de cette liste
- Élargissez la surface seulement après avoir vu de vraies conversations et identifié des gaps
C'est l'équivalent d'écrire une state machine. Chiant, oui. Mais chiant c'est tout l'intérêt.
Pattern 4 : Tester avec le pire input que vous pouvez produire
Votre eval set doit inclure :
- Fautes, correcteurs auto, ponctuation manquante
- Langues code-switchées
- Requêtes avec trop de contexte (« tu te souviens la dernière fois quand on a parlé de... »)
- Requêtes sans contexte (« ok fais-le »)
- Inputs de systèmes amonts où un champ est revenu en
nullouundefinedau lieu d'une string
Si votre prompt marche seulement sur des inputs propres, il ne marche pas.
À retenir
Un prompt n'est pas un bout de langage naturel. C'est un petit programme avec un interpréteur flou. Schéma-formez les outputs, donnez au modèle un moyen de dire qu'il ne sait pas, few-shot les cas d'échec, et commencez étroit. Faites ces quatre choses et vos prompts survivront au contact des utilisateurs — ou du moins boiteront à travers gracieusement.