Écrire un prompt système pour un agent — sans hallucinations

Un agent automatisé n'a pas votre tolérance à l'ambiguïté. Si le prompt système est flou, l'agent improvise. Et quand l'agent improvise en production, vous découvrez le problème par un ticket support trois jours plus tard.

Cet article décrit la méthode qu'on suit pour écrire les prompts système des agents qui tournent en production — chez nous et chez nos clients.

Ce qui change quand le consommateur n'est plus humain

Un prompt destiné à un humain peut rester ambigu : l'humain demande des précisions, ré-essaie, copie-colle dans un autre outil. Un agent ne fait rien de tout ça. Il prend la sortie telle quelle et la passe à l'étape suivante.

Conséquence pratique : la sortie d'un prompt agent est un contrat. Si le contrat n'est pas rempli, le pipeline casse — silencieusement la plupart du temps.

Le triptyque non-négociable

Un prompt système d'agent qui marche en production tient sur trois piliers.

1. Format strict, déclaré explicitement

Pas « rends un JSON propre », mais : Sortie JSON STRICT, sans texte avant ou après. Schéma : { "intent": "...", "confidence": 0-1, ... }. Et après le schéma, listez les valeurs autorisées pour chaque enum.

2. Comportement face à l'ambiguïté, défini à l'avance

Que fait l'agent quand l'entrée n'est pas claire ? Il ne devine pas. Il marque confidence: 0.4 et requires_human: true. C'est une règle dans le prompt, pas un espoir.

3. Refus explicite hors périmètre

L'agent doit savoir dire « ce n'est pas mon job ». Si l'agent classifie des emails commerciaux et reçoit un email de support, il classifie en category: "out_of_scope" plutôt que de faire de son mieux. Faire de son mieux = produire du bruit.

Exemple : agent classifieur d'emails

Voici la structure que nous recommandons (le prompt complet est dans le catalogue).

Tu es un classifieur d'emails. Pour chaque email, classe-le dans EXACTEMENT UNE catégorie :

- "lead_qualifie" — demande commerciale B2B identifiable
- "support" — demande d'aide sur un produit existant
- "facturation" — relance, contestation, demande de facture
- "spam" — promotion non sollicitée
- "autre" — tout le reste

SORTIE STRICTE EN JSON :
{
  "category": "...",
  "confidence": 0.0-1.0,
  "reasons": [...],
  "suggested_owner": "..."
}

Règles :
- Si confidence < 0.7, suggested_owner = "ceo" (relecture humaine)
- Si plusieurs catégories possibles, choisis la plus restrictive
- Aucun emoji, aucun markdown

Notez l'absence de « bonjour », l'absence de courtoisie, l'absence de présentation. Un agent n'a pas besoin de ces choses. Le prompt est un manuel d'instructions, pas une lettre.

L'orchestration

Un prompt agent vit dans un workflow. Les outils que nous utilisons en production :

• n8n pour orchestrer les nœuds (entrée mail → classifier → routeur → action)
• Supabase pour stocker les décisions et l'historique
• OpenRouter pour basculer entre Claude et GPT selon le coût/latence
• PostHog pour mesurer les taux d'erreur et les confidence moyennes

L'orchestrateur ne change pas le prompt. Il l'appelle. C'est important : ne mélangez pas la logique métier (dans n8n) avec la logique de classification (dans le prompt).

Le pré-mortem qu'il faut faire

Avant de lancer un agent en production, asseyez-vous 15 minutes et imaginez les trois pires sorties possibles. Pour chacune :

• Comment elle se déclenche
• Le coût réel pour le business
• Le mécanisme de rattrapage (humain ? automatique ? alerte ?)

Si une des trois pires sorties n'a pas de mécanisme de rattrapage, ne lancez pas. Travaillez sur le rattrapage avant de pousser.

Pour aller plus loin

• Le pilier méthodologique : Le guide des prompts pour opérateurs
• L'entrée du catalogue : Classifier email entrant en 5 catégories
• L'entrée du catalogue : Pré-filtrer les leads entrants — score 0–100