Prompts système pour agents : 12 design patterns pour concevoir des prompts système prêts pour la production

La conception de prompts système désigne la construction structurée du prompt système d'un agent IA à partir de briques réutilisables : rôle, objectif, contraintes, instructions d'outils, format de sortie, exemples, gestion des erreurs, réflexion, mémoire, escalade, critères d'arrêt et sécurité. En 2026, un bon prompt système d'agent est modulaire, auditable et piloté par les évals : un artefact versionnable plutôt qu'un mur de texte en prose.

La différence entre un agent de démo et un système prêt pour la production tient rarement au modèle. Elle tient au substrat du prompt : le rôle, les outils, le format de sortie et les critères d'arrêt sont-ils proprement définis ? Les douze design patterns suivants sont les briques récurrentes vers lesquelles convergent les agents en production sérieux (Claude Code, Cursor, Devin, OpenAI Codex Agents).

Réponses rapides

• La structure l'emporte sur la prose : un prompt système d'agent s'articule en quatre couches (Identity, Capability, Behavioral, Context), séparées par des balises XML ou des titres Markdown. Le modèle analyse les prompts structurés de façon plus fiable.
• La bonne longueur : 500-3 000 tokens pour le cœur (hors schémas d'outils). Trop vague, il produit des sorties incohérentes ; trop détaillé, il devient fragile et déclenche l'effet lost in the middle dans le prompt lui-même.
• Un pattern sans éval, c'est du folklore : chaque pattern est vérifié sur un jeu d'évaluation. Des classiques comme « Tu es un expert » ou « Take a deep breath » n'ont souvent aucun effet mesurable sur les modèles modernes.

Les fondations : le modèle à quatre couches

Avant que les patterns individuels ne fassent effet, chaque prompt système d'agent a besoin d'une ossature. Les prompts système en production s'organisent systématiquement en quatre couches, qui dictent aussi l'agencement du cache (couches stables en tête, couches dynamiques à la fin) :

Anthropic recommande de séparer ces sections par des balises XML comme <instructions> ou par des titres Markdown (situation en 2026). L'avantage est double : le modèle analyse la structure de façon plus fiable, et l'ingénieur peut comparer, versionner et tester en A/B chaque section.

Les 12 design patterns en un coup d'œil

1-3 : rôle, objectif, contraintes

L'anti-pattern « Tu es un assistant serviable » est trop vague et n'apporte aucun pilotage. La base, c'est un rôle concret avec un domaine et des limites. Tout aussi nuisibles : les contraintes contradictoires comme « Sois concis, mais exhaustif ». Mieux vaut un comportement par défaut clair avec des clauses de dérogation explicites. Important : 5-8 règles hautement prioritaires au maximum. Le modèle applique moins souvent les dernières règles d'une liste de 47 points (lost in the middle dans le prompt système lui-même) ; le reste a sa place dans les descriptions d'outils.

4 : instructions d'outils

Les définitions d'outils ne sont pas une couche séparée : le modèle les analyse à chaque tour d'inférence. Quand un agent agit mal, la cause, selon Anthropic, ne vient « dans la plupart des cas » pas du modèle, mais de la définition de l'outil. Règle empirique : 3-5 outils toujours chargés, les autres via la recherche d'outils. À partir de 10 outils, une dégradation mesurable commence. Le composant le plus efficace, et le plus souvent oublié, est la clause When-not-to-use : si search_web et query_internal_db coexistent, c'est elle qui décide de la sélection. En revanche, si deux outils se recoupent entièrement sur le plan fonctionnel, aucun prompt, aussi bon soit-il, n'y peut rien : il faut alors les fusionner ou les séparer proprement selon leur fonction.

5-6 : format de sortie et exemples few-shot

« Fiable » signifie en 2026 100 %, pas 95. Les Structured Outputs d'OpenAI imposent, via le décodage contraint, un respect à 100 % du schéma JSON (GA depuis août 2024). Anthropic a lancé des Structured Outputs natifs en novembre 2025, disponibles pour tous depuis février 2026. Là aussi, le décodage contraint impose le schéma : le schéma JSON se trouve dans output_config.format. Pour les appels d'outils, strict: true dans la définition de l'outil impose le schéma. L'ancien contournement via tool_choice avec un pseudo-outil comme return_structured_result fonctionne toujours, mais sans le mode strict il ne garantit pas une conformité totale au schéma. Pour combiner chain-of-thought et sortie structurée en un seul appel, le pattern XML a fait ses preuves en production : le modèle réfléchit de manière visible dans le bloc <thinking>, et le système en aval n'analyse que le bloc <final_output>. Les exemples few-shot (comme le tableau input_examples d'Anthropic) couvrent les paramètres imbriqués ou optionnels sur lesquels le modèle, sans eux, devine. Important : des exemples variés et canoniques, sans doublons, sinon le modèle choisit le plus proche.

7-8 : gestion des erreurs et réflexion

Les boucles robustes distinguent les types d'erreurs : une erreur d'outil (500/timeout) autorise une nouvelle tentative avec des paramètres inchangés (2 fois max. avec backoff), une erreur de validation (400) une nouvelle tentative avec des paramètres ajustés, et une erreur d'autorisation (403) aucune nouvelle tentative, mais une escalade. L'anti-pattern le plus dangereux est la suppression silencieuse des erreurs : les appels d'outils échouent et l'agent continue comme si de rien n'était. Les erreurs doivent revenir au modèle sous forme de résultats d'outil explicites. La réflexion/vérification coûte généralement 2-3 fois plus de tokens pour 5-15 points de pourcentage de qualité. Pour un agent qui valide une commande de 50 000 EUR, le ROI est évident ; pour un agent de service client avec des marges de quelques centimes, tu dois faire tes calculs avec précision.

9-10 : gestion de la mémoire et escalade/HITL

Même à l'intérieur de la fenêtre de contexte, le modèle « oublie » l'état introduit tôt. Mesures d'atténuation : épingler l'état critique (objectif, tâche en cours, faits clés) à la fin du prompt système (les modèles accordent plus d'attention à la fin qu'au milieu), un en-tête placé avant chaque tour de l'utilisateur et un scratchpad tenu à jour explicitement comme point d'ancrage. En environnement multi-tenant, la contamination de la mémoire fait partie des bugs de production les plus fréquents. Remède : une réinitialisation explicite de la session au début de chaque conversation et l'ID de session comme paramètre obligatoire pour tous les outils d'état. Pour les décisions à fort enjeu, une validation human-in-the-loop doit précéder l'exécution de l'outil.

11-12 : critères d'arrêt et sécurité

Selon la recherche, les boucles infinies ont été la catégorie de bugs de production la plus fréquente en 2025-2026. Une terminaison robuste combine un nombre maximal d'itérations (10-30 en usage général, 50-100 pour le code, comme plafond strict), un critère de succès, un plafond de coûts et une détection d'états répétés (même appel d'outil avec les mêmes paramètres 3 fois comme détecteur de thrashing). Enfin, les consignes de sécurité doivent être marquées explicitement comme non négociables et placées au-dessus des instructions de persona. L'anti-pattern « persona au-dessus de la sécurité » est un vecteur d'injection de prompt connu. Pour les charges de travail en Europe s'ajoutent les patterns RGPD : pseudonymisation avant l'injection de contexte et une couche de masquage des PII avant l'injection dans le RAG.

Cas pratique : agent de triage dans une PME

Une PME de la zone DACH (Allemagne, Autriche, Suisse) exploite un agent de triage pour le service client avec le budget suivant (situation en 2026) : prompt système de 800-1 500 tokens, définitions d'outils de 800-1 500 tokens (4-5 outils avec input_examples), retrieval de base d'environ 2 000 tokens (3-5 chunks avec re-ranking), historique de conversation sous les 4 000 tokens (fenêtre glissante N=10), sortie de 1 000-2 000 tokens. Au total, environ 10 000 tokens par appel. Le prompt système et les définitions d'outils totalisent 1 600-3 000 tokens, soit entre un cinquième et un tiers de l'entrée, et restent identiques d'un appel à l'autre. Pour ce préfixe, le Prompt Caching entre en jeu : sur la plupart des modèles Claude, les lectures de cache coûtent 10 % du tarif d'entrée standard, à condition que le préfixe atteigne la longueur minimale du modèle (de 512 à 4 096 tokens selon la documentation d'Anthropic, situation en octobre 2026). Les coûts d'entrée par appel baissent ainsi d'environ 20-30 %, les coûts de sortie restent les mêmes. Si le cache expire, réécrire le préfixe coûte plus cher qu'une entrée normale.

Pseudo-code pour les garde-fous de la boucle :

• max_iterations = 20
• on tool_error(403): escalate_to_human() (pas de nouvelle tentative)
• on tool_error(500): retry(max=2, backoff=true)
• on repeated_call(same_tool, same_params, n>=3): break (thrashing)
• if confidence < 0.8 or amount > 5000: handoff_to_human()
• terminate_on: submit_final_answer() called

Remarque importante pour le choix du modèle : avec les tokenizers standard, l'allemand produit 30-50 % de tokens de plus que l'anglais. Une fenêtre de 200K ne contient donc qu'autant de contenu allemand qu'environ 130K-150K tokens de texte anglais. La discipline sur la longueur du prompt n'en est que plus importante, et le caching d'autant plus rentable.

Pour les agences et le B2B

Une agence qui exploite des agents clients dans plusieurs secteurs ne devrait pas écrire les prompts système de zéro pour chaque client, mais les dériver par héritage de templates à partir d'une base commune à l'agence : le branding et le comportement du client sont redéfinis, les douze patterns restent constants. Cela passe mieux à l'échelle, car l'infrastructure partagée (framework d'évals, bibliothèque d'outils, observabilité) produit des rendements cumulés, tandis que les « flocons de neige » propres à chaque client génèrent une charge de maintenance exponentielle. Pour les décideurs B2B en Europe, le message clé est le suivant : un prompt système n'est pas un texte écrit une fois pour toutes, mais un artefact d'ingénierie versionné, avec régression d'évals à chaque modification. Blck Alpaca, basée à Vienne, accompagne les entreprises dans la mise en place de cette discipline reproductible du prompt système, du choix des patterns jusqu'à la couche de journalisation conforme au règlement européen sur l'IA et au RGPD.