Comment écrire des prompts système pour agents IA qui ne tombent pas en panne en production

Table des matières

Mis à jour juillet 2026.

TL;DR: Un prompt système en production comporte cinq couches : identité (qui est l’agent et ce qu’il ne peut pas faire), contexte (ce qu’il sait de son environnement), tâche (à quoi ressemble le succès étape par étape), format de sortie (la couche la plus sous-estimée) et cas limites (que faire quand les entrées sont défectueuses). La plupart des prompts échouent parce qu’ils omettent les couches 4 et 5. Rédigez le format de sortie avant tout le reste — cela vous oblige à être précis sur ce que vous voulez vraiment.

[Point de vue de l’opérateur] Je gère plus de 30 agents IA en production pour ma marque de conseil et Pickleland, une salle de pickleball à Pflugerville, TX. J’ai réécrit plus de prompts système que je n’en ai rédigé — généralement parce que la première version semblait bien fonctionner lors des tests, puis se dégradait silencieusement en production. Voici ce que j’ai appris sur la rédaction de prompts durables.

Le problème du prompt système que personne n’admet

La plupart des prompts système pour agents sont rédigés en environ 20 minutes, testés sur deux ou trois exemples, puis jamais retouchés. Le modèle est déployé. Pendant un moment, ça fonctionne. Puis quelque chose change — les entrées deviennent plus complexes, le modèle est mis à jour, un nouveau cas limite apparaît — et l’agent commence à produire de mauvais résultats. En silence. À grande échelle.

Le problème n’est pas que le prompt original était mauvais. C’est que la plupart des prompts sont rédigés pour démontrer le chemin heureux. Ils sont conçus pour l’entrée que vous aviez en tête quand vous avez construit l’agent, pas pour la distribution complète des entrées que l’agent verra réellement.

Les prompts système en production sont différents des prompts de démonstration. Ils doivent gérer des entrées que vous n’avez pas conçues, échouer gracieusement quand quelque chose se passe mal, et produire une sortie cohérente même quand le comportement du modèle change légèrement d’une version à l’autre.

Les cinq couches d’un prompt système en production

Je pense à chaque prompt système que je rédige en cinq couches. Elles n’ont pas à apparaître dans cet ordre — mais elles doivent toutes être présentes.

Couche 1 : Identité

L’identité dit au modèle qui il est et quelles sont ses contraintes opérationnelles. Pas un personnage de jeu de rôle — une définition fonctionnelle de ce que cet agent fait et ne fait pas.

Une couche d’identité solide répond à trois questions :

• De quoi cet agent est-il responsable ?
• De quoi n’est-il explicitement PAS responsable (et doit-il escalader ou refuser) ?
• Quels standards maintient-il ?

Couche d’identité faible :

Vous êtes un agent de service client utile pour une salle de pickleball.

Couche d’identité plus solide :

Vous êtes l'assistant de réservation de Pickleland, une salle de pickleball
à Pflugerville, TX. Votre travail est de répondre aux questions sur la
disponibilité des courts, les options d'adhésion et les événements à venir.

Vous ne gérez PAS les litiges de facturation, les demandes de remboursement
ou les plaintes concernant le personnel — redirigez ceux-ci vers l'équipe
opérationnelle humaine via le chemin d'escalade défini ci-dessous.

Vous répondez avec un ton amical mais efficace. Vous n'inventez jamais la
disponibilité ou les prix. Quand vous ne savez pas quelque chose, vous le
dites et proposez de prendre un message pour l'équipe opérationnelle.

La portée explicite de ce qui n’est PAS dans le périmètre est la partie que la plupart des opérateurs omettent. Sans elle, le modèle essaiera d’être utile en dehors de son domaine — et c’est là que les choses tournent mal.

Couche 2 : Contexte

Le contexte est ce que l’agent sait de son environnement qui n’est pas dans le message de l’utilisateur. Cela inclut :

• La date et l’heure actuelles (injectez cela dynamiquement — ne faites jamais confiance au sens interne du temps du modèle)
• L’état pertinent des systèmes externes (événements à venir, inventaire, détails du compte utilisateur)
• Les règles métier qui ne sont pas évidentes à partir de la description de la tâche

La plupart des agents que je passe en revue manquent de contexte. L’opérateur suppose que le modèle “sait” des choses qu’il ne sait pas. N’assumez pas. Injectez.

Couche 3 : Tâche

La couche de tâche décrit ce que fait l’agent, étape par étape. Pas “aider les clients” — le vrai flux de décision. Rédigez-la comme un organigramme, pas comme une directive. Les organigrammes sont plus robustes parce qu’ils réduisent le besoin du modèle d’inférer ce que vous voulez dans les cas ambigus.

Couche 4 : Format de sortie

C’est la couche la plus sous-estimée, et celle qui est la plus responsable des échecs silencieux.

Si vous ne spécifiez pas le format de sortie précisément, le modèle produira une sortie qui semble correcte à un lecteur humain mais qui est suffisamment incohérente pour briser l’analyse en aval. Rédigez le format de sortie en premier. Si vous ne pouvez pas décrire exactement à quoi vous voulez que la sortie ressemble, vous ne comprenez pas encore assez bien la tâche pour l’automatiser.

Pour la sortie structurée, spécifiez le schéma exact. Pour la sortie en prose, spécifiez la structure, la longueur et les contraintes de ton — y compris les anti-modèles explicites comme “Ne commencez jamais par ‘Certainement’ ou ‘Bien sûr.’”

Pour les agents à enjeux élevés, j’utilise la sortie structurée de Claude avec un schéma JSON défini.

Couche 5 : Cas limites

La couche des cas limites répond : que fait l’agent quand l’entrée est ambiguë, incomplète, dans la mauvaise langue, hostile, ou clairement incorrecte ? Pour chaque cas limite, donnez au modèle un chemin de réponse explicite.

Comment je maintiens les prompts système dans le temps

Un prompt système en production est un document vivant :

1. Vérification ponctuelle hebdomadaire. Je passe en revue cinq à dix sorties aléatoires de chaque agent à enjeux élevés.
2. Révision après mise à jour du modèle. Chaque fois que la version du modèle sous-jacent change, j’exécute l’agent contre l’ensemble doré complet de mon cadre d’évaluation.
3. Journal des cas limites. Je tiens un journal des entrées que l’agent a mal gérées. Quand trois entrées ou plus partagent un modèle, j’ajoute une règle explicite.
4. Versionnage du prompt. Chaque changement significatif reçoit un commentaire de version.

Questions fréquentes

Quelle longueur doit avoir un prompt système en production ?

Assez long pour couvrir les cinq couches. Assez court pour que vous puissiez le lire en deux minutes et repérer la dérive. Pour la plupart de mes agents, c’est 200 à 600 mots.

Quand dois-je diviser une tâche complexe en plusieurs agents plutôt qu’un seul prompt long ?

Quand la tâche a deux modes distincts ou plus qui nécessitent un contexte différent, des formats de sortie différents ou une gestion des erreurs différente. Voir agents déclenchés par événements vs planifiés pour le modèle.

Quelle est la raison la plus courante pour laquelle un prompt qui fonctionnait en test échoue en production ?

Les entrées de test n’étaient pas représentatives de la distribution de production. Construisez un ensemble de test à partir du trafic de production réel, pas d’entrées imaginées.