7 Exemples de System Prompt pour la Production (Modèles Prêts à Copier-Coller, 2026)

Les meilleurs exemples de system prompt ne ressemblent pas aux formules « you are a helpful assistant » qu'on trouve dans les tutoriels. Ce sont des blocs d'instructions précis qui empêchent une application en production de dérailler à 2 heures du matin. Dans notre propre pipeline de contenu, nous faisons tourner plus d'une dizaine de subagents Claude, chacun piloté par un system prompt que nous avons réécrit à plusieurs reprises après un bug livré sur Claude Opus 4.8 ou GPT-5. Cet article laisse de côté les démos jouets. Vous obtenez 7 vrais system prompts prêts à copier, dont deux tirés directement de cette pile de production, plus l'anatomie en 6 blocs qui soutient chacun d'entre eux.

Points Clés à Retenir

• Un system prompt est un ensemble d'instructions persistantes (rôle, contraintes, format de sortie, garde-fous) défini une seule fois, avant tout message utilisateur.
• Si un contenu est identique sur 1 000 requêtes, placez-le dans le system prompt ; le contenu propre à chaque requête va dans le tour utilisateur.
• Six blocs construisent un prompt fiable : rôle, contexte, contraintes, format de sortie, garde-fous, exemples.
• Les modèles de raisonnement (série o, GPT-5, Claude Opus 4.5+) veulent des objectifs de haut niveau, pas une formulation agressive du type « vous DEVEZ ».

Que Contient un System Prompt ? Les 6 Blocs de Construction

Un system prompt est un ensemble d'instructions persistantes qui définissent le rôle, le comportement, les contraintes et le format de sortie d'un modèle pour toute une session, fixées une seule fois avant le premier message utilisateur. Les prompts fiables partagent six blocs de construction : rôle, contexte, contraintes, format de sortie, garde-fous, et des exemples en option. Mettez-les dans cet ordre et vous tenez la version courte de comment écrire un system prompt qui survit à la production.

Voici ce que fait chaque bloc.

Le bloc rôle compte plus qu'il n'y paraît. La documentation d'Anthropic le dit clairement : définir un rôle dans le system prompt oriente le comportement et le ton du modèle, et « même une seule phrase fait la différence ». Pour le bloc garde-fous, les règles de refus et de sécurité méritent une vraie réflexion ; nous approfondissons le sujet dans notre guide des guardrails. Et si vous configurez Claude, Anthropic recommande des balises XML (<instructions>, <context>, <input>) pour séparer chaque type de contenu afin que le modèle ne les mélange pas.

Voici un squelette prêt à copier qui assemble les six blocs en un seul modèle :

# ROLE
You are a {role} for {audience}. Your scope is {narrow scope}.

# CONTEXT
{Stable facts the model needs on every request.}

# CONSTRAINTS
- {Hard rule 1}
- {Hard rule 2}
- Do not {forbidden action}.

# OUTPUT FORMAT
{Exact structure: length, format, JSON schema.}

# GUARDRAILS
- If {edge case}, then {fallback or escalate to a human}.
- If you are unsure, say so instead of guessing.

# EXAMPLES (optional)
{One or two model answers that show the target quality.}

Six blocs transforment une intuition en spécification. Il ne s'agit ici que de la couche system prompt. Pour les techniques plus larges (few-shot, chain-of-thought, prompt chaining), consultez notre guide de prompt engineering, et gardez-les en dehors du system prompt lui-même. Un system prompt de session diffère aussi d'un fichier au niveau du dépôt regroupant des instructions persistantes au niveau du projet comme un CLAUDE.md, qui régit tout un codebase plutôt qu'une seule session API.

7 Exemples de System Prompt en Production (Prêts à Copier-Coller)

Voici 7 exemples de system prompt que vous pouvez coller dès aujourd'hui dans votre paramètre system ou votre message developer. Chacun cible un vrai cas d'usage (agent, RAG, support, coding, JSON, QA de contenu, traduction), et chacun montre pourquoi ses blocs clés existent. Les deux derniers tournent dans notre propre pipeline. Les dépôts qui font fuiter les prompts de Cursor et Devin prouvent la demande ; ce que personne ne livre, c'est l'annotation qui explique pourquoi chaque bloc est là.

1. Agent Autonome

Cadrez le rôle de façon étroite, détaillez les règles d'usage des outils, et donnez-lui une condition d'arrêt pour qu'il ne boucle pas indéfiniment.

You are a research agent. Your only job is to answer the user's
question using the provided tools.

TOOLS: web_search, read_url, calculator.

RULES
- Plan first: list the steps before calling any tool.
- Call one tool at a time and check the result before the next call.
- Never invent a URL or a fact. If a tool fails twice, stop.

STOP CONDITION
- When you have enough to answer, stop calling tools and reply.
- If the task needs account access or a purchase, hand off to a
  human and explain why.

Pourquoi ça marche : le rôle étroit associé à une condition d'arrêt explicite, c'est ce qui distingue un agent qui termine sa tâche d'un autre qui brûle des tokens en boucle. C'est le cœur des bonnes pratiques pour un system prompt d'agent.

2. RAG / Questions-Réponses sur Documents Récupérés

Avec la récupération de documents, tout l'enjeu est d'empêcher le modèle de répondre à partir de sa propre mémoire. Une seule règle suffit.

You answer questions using ONLY the context provided below.

CONTEXT
{retrieved_chunks}

RULES
- If the answer is not in the context, say: "I don't have that
  in my sources." Do not use outside knowledge.
- Cite the source after each claim using [chunk_id].

OUTPUT
Two to four sentences, plain text, with citations.

Pourquoi ça marche : « seulement à partir du contexte » plus un format de citation, c'est le garde-fou anti-hallucination le moins cher que vous puissiez écrire pour un system prompt RAG.

3. Bot de Support Client

Le ton, un chemin d'escalade et une règle stricte sur l'argent gardent un bot de support utile sans le laisser promettre ce qu'il ne peut pas tenir.

You are a support agent for Northwind's billing team. Be warm,
brief, and factual.

CONTEXT
- Customers are on Free, Pro, or Enterprise plans.
- Refunds are allowed within 14 days of a charge.

CONSTRAINTS
- Never promise a refund above $200 without escalation.
- Do not give tax or legal advice.

GUARDRAILS
- If the customer is angry or asks for a manager, escalate to a
  human and say a teammate will follow up within one business day.
- If you are unsure of a policy, say you'll check rather than guess.

Pourquoi ça marche : le garde-fou sur les remboursements et le repli vers l'escalade bloquent les deux modes de défaillance qui font retirer les bots de support de la production.

4. Assistant de Coding

Contraignez le format de sortie et les versions, et forcez-le à expliquer avant de modifier.

You are a coding assistant for a Next.js 15 + TypeScript codebase.

RULES
- Explain your plan in two sentences before writing any code.
- Output changes as a unified diff, not full files.
- Match the existing style. Do not add dependencies without asking.
- Target Node 20. Do not use APIs newer than that.

If a request is ambiguous, ask one clarifying question before editing.

Pourquoi ça marche : « diff, pas des fichiers entiers » plus un plafond de version gardent l'assistant à l'intérieur de votre stack. La conception de prompts pour les agents de coding est assez riche pour mériter son propre guide, donc on garde cet exemple concis.

5. Données Structurées / Extraction JSON

Placez le schéma dans le bloc format de sortie et interdisez la prose. C'est le pattern pour des sorties structurées fiables.

You extract structured data from raw text. Return ONLY valid JSON,
no prose, no markdown fences.

SCHEMA
{
  "company": "string",
  "amount_usd": "number",
  "date": "YYYY-MM-DD",
  "confidence": "low | medium | high"
}

RULES
- If a field is missing from the text, use null.
- Never guess a value to fill a field.
- Output must parse with JSON.parse on the first try.

Pourquoi ça marche : un schéma littéral plus « uniquement du JSON valide » bat toujours un format simplement décrit. Pour les patterns d'application au-delà du prompt (validation par schéma JSON, extraction via des outils), consultez notre guide sur les sorties structurées.

6. Agent QA de Contenu / Validateur (issu de notre pipeline de production)

Celui-ci tourne dans notre propre pile. Le system prompt de notre validateur est un exemple de contraintes négatives : il dit au modèle exactement ce qu'il ne doit PAS écrire, puis un script vérifie les règles littéralement.

You are a content QA agent. You check one blog draft against a
fixed style contract.

BANNED VOCABULARY (auto-fail on any hit)
delve, leverage, robust, seamless, tapestry, pivotal, elevate,
harness, foster, bolster, paramount, intricate, "in today's",
"when it comes to", "it's worth noting", "game-changer"

FORMAT LIMITS
- Em-dashes: max 3 per 1,000 words of body.
- Vague quantifiers ("many", "several", "significantly"): max 1
  per 500 words of body.

ENFORCEMENT
- Do not "write naturally." Check every rule literally.
- A deterministic script (ai_slop_check.py) greps the draft and
  exits non-zero on any hit. If it fails, the post does not publish.

Pourquoi ça marche : une liste d'interdictions énumérée plus un grep, c'est applicable d'une façon qu'un « évitez les mots à la mode » ne sera jamais. Le modèle peut discuter avec une impression ; il ne peut pas discuter avec un code de sortie non nul.

7. Agent de Traduction (issu de notre pipeline de production)

Également le nôtre. Le prompt du traducteur est un contrat de format de sortie et d'exhaustivité, avec une auto-vérification que le modèle applique sur sa propre sortie.

You are an expert translator. You translate ONE blog post into ONE
target language.

COMPLETENESS CONTRACT
- Output the SAME number of H2 sections as the source.
- Line count must land within 80-120% of the source.
- Translate the FAQ fully. Never submit a partial draft.

DIACRITICS SELF-CHECK
- Keep native characters. If you output "karsilastirma" instead of
  "karşılaştırma" (Turkish), or "developpement" instead of
  "développement" (French), the translation is WRONG. Re-do it.

If you cannot meet the contract, report the problem. Do not ship a
truncated post.

Pourquoi ça marche : un contrat d'exhaustivité plus un exemple concret de mauvaise sortie attrape les échecs silencieux qu'une vague consigne « traduisez avec précision » laisse passer.

Ce Que Nous Avons Appris en Faisant Tourner des System Prompts en Production

Trois bugs de system prompt dans notre propre pipeline nous ont appris plus qu'aucune page de documentation. Les trois venaient d'instructions qui semblaient correctes mais n'étaient ni précises ni vérifiables. Voici ce qui a cassé sur nos 16+ subagents Claude, et le correctif exact qui a tenu à chaque fois. Le schéma est toujours le même : les règles vagues sont ignorées, les règles précises et vérifiées de l'extérieur tiennent.

Le bug du vocabulaire interdit. Pendant des semaines, le modèle continuait de glisser leverage et robust dans les brouillons, peu importe la gentillesse de nos consignes. Une ligne vague « évitez les mots à la mode » ne changeait rien. Le correctif a été l'Exemple 6 : une liste d'interdictions énumérée dans le prompt, plus un script qui grep la sortie et s'arrête avec un code non nul au moindre hit, avec en plus un plafond d'em dashes de 3 pour 1 000 mots. La leçon : les contraintes vagues sont ignorées ; les contraintes énumérées et vérifiées de l'extérieur tiennent.

Le bug des diacritiques. Notre traducteur produisait silencieusement de l'ASCII en turc, en français et en espagnol. karşılaştırma ressortait en karsilastirma, et personne ne l'a remarqué avant qu'un lecteur natif ne le signale. Le correctif a été une table des caractères natifs dans le prompt, un exemple explicite de mauvaise sortie, et un grep post-exécution (zéro caractère natif signifie qu'il faut retraduire). La leçon : donnez au modèle un exemple concret de l'échec, pas seulement une règle.

Le bug de l'identifiant stable. C'est le plus coûteux. Un system prompt qui redérivait un slug localisé à chaque nouvelle traduction faisait créer par le publisher un second document en ligne par article. Nous avons livré 54 documents en ligne en double le 2026-06-13 et ne les avons dépubliés que le 2026-07-05, soit trois semaines de dilution de l'autorité de lien et de signalements de contenu dupliqué. Le correctif : fixer l'identité explicitement et réutiliser l'ID existant tel quel. Un system prompt qui régénère ses propres identifiants de façon non déterministe livre des doublons ; le nôtre en a créé 54 en ligne avant que nous ne fixions l'ID.

Quelles Sont les Erreurs les Plus Courantes sur un System Prompt ?

Les erreurs les plus courantes sur un system prompt sont les instructions en mur de texte, les règles contradictoires, une formulation uniquement négative, le fait de déverser du contexte propre à chaque requête dans un prompt statique, et l'absence de repli. Sur les modèles 2026, il y en a une nouvelle : les CAPS agressives et la formulation « vous DEVEZ » sur-déclenchent désormais Claude Opus 4.5+.

Voici la liste de correctifs rapides :

• Mur de texte. Correctif : découpez-le en six blocs et placez le contenu stable en premier.
• Instructions contradictoires. Correctif : une règle par ligne ; résolvez les conflits avant de livrer.
• Formulation uniquement négative. Correctif : dites quoi faire, pas seulement quoi éviter.
• Surcharge de CAPS et de « DOIT ». Sur les modèles récents d'Anthropic, ça se retourne contre vous. Leur documentation dit désormais que là où vous auriez écrit « CRITICAL: You MUST use this tool », vous pouvez utiliser une formulation normale comme « Use this tool when. » Le conseil de 2025 est devenu l'erreur d'aujourd'hui.
• Contexte dynamique dans un prompt statique. Gardez les données propres à chaque requête dans le tour utilisateur. Ce qui va où est une discipline à part entière ; notre guide de context engineering couvre le sujet.
• Absence de repli. Définissez toujours un chemin de refus et d'escalade.
• Ignorer la longueur et le coût. Des prompts plus longs ajoutent de la latence et un coût en tokens à chaque appel ; ne gardez que ce qui mérite sa place.

Pour les bases de clarté d'instruction, l'article de bonnes pratiques d'OpenAI reste une checklist solide.

Comment Tester et Itérer sur un System Prompt ?

Testez un system prompt comme vous testez du code. Construisez un petit jeu de données de référence (golden set) avec des sorties attendues, puis vérifiez la réponse du modèle par rapport à celles-ci à chaque changement. Faites un A/B entre deux versions de prompt sur les mêmes entrées et gardez celle qui passe le plus de vérifications. Les assertions battent l'inspection visuelle à tous les coups.

Une boucle d'évaluation minimale ressemble à ceci :

# pseudo eval loop
for case in golden_set:
    out = model(system=PROMPT, user=case.input)
    assert is_valid_json(out)              # format check
    assert case.expected_field in out      # content check
    if case.no_context:
        assert "I don't have that" in out  # refusal check
# ship the prompt version that passes the most cases

Le grep de l'Exemple 6 est l'assertion la moins coûteuse que vous puissiez exécuter : ça ne coûte rien et ça ne se fatigue jamais. Quand votre bibliothèque de prompts dépasse une poignée d'entrées, versionnez et testez vos prompts avec de vrais outils de gestion de prompts plutôt qu'en copiant-collant entre des fichiers. Le principe reste le même à toute échelle : ne modifiez jamais un prompt de production sans une vérification qui vous dit si vous l'avez amélioré ou dégradé.

System Prompt vs User Prompt vs Message Developer

Un system prompt fixe un comportement stable ; un user prompt porte la tâche propre à chaque requête ; un message developer est le rôle des modèles de raisonnement d'OpenAI qui contient des instructions au niveau de l'application, classées au-dessus des messages utilisateur dans la chaîne de commandement. Anthropic utilise un paramètre system de premier niveau plutôt qu'un message role: "system". Voici la distinction en trois volets que les concurrents ratent généralement.

OpenAI est explicite sur ce classement : « les messages developer sont des instructions fournies par le développeur de l'application, prioritaires sur les messages utilisateur ». Donc si un utilisateur tente de contourner les règles de votre app, c'est le message developer qui l'emporte dans la chaîne de commandement.

Les Modèles de Raisonnement Ont-Ils Besoin de System Prompts Différents ? (2026)

Oui. Les modèles de raisonnement comme la série o d'OpenAI, GPT-5 et Claude Opus 4.5+ veulent des objectifs de haut niveau, pas des scripts étape par étape. OpenAI compare un modèle de raisonnement à un collègue senior à qui vous faites confiance pour les détails, contre un modèle GPT qui se comporte comme un junior ayant besoin d'instructions explicites.

Ce cadrage change la façon d'écrire le prompt. Pour un modèle de raisonnement, énoncez l'objectif et les contraintes et « faites-leur confiance pour régler les détails » ; pour un modèle GPT, détaillez les étapes. Sur-spécifier un modèle de raisonnement le rend souvent pire, pas meilleur.

Le côté Claude a son propre changement 2026. Parce qu'Opus 4.5+ est plus réactif au system prompt, la vieille habitude d'empiler CRITICAL: et MUST le sur-déclenche désormais. Ramenez ce langage à une formulation normale. Une note de coût : placez votre contenu stable et réutilisé au début du prompt pour que le prompt caching puisse s'activer et réduire la latence sur les appels répétés. Et si votre modèle de raisonnement fait un travail étape par étape, le chain-of-thought prompting est un sujet à part entière avec son propre guide, donc nous ne le réenseignerons pas ici.

Comment Techsy Aborde Ce Sujet

Chez Techsy, nous construisons des systèmes d'agents pour des clients B2B, et les prompts du validateur et du traducteur présentés plus haut tournent dans cette pile de production. Nous traitons chaque system prompt comme du code : nous le versionnons, le testons contre un golden set, et faisons appliquer les règles non négociables par un script plutôt que par l'espoir. Si vous faites passer une fonctionnalité LLM d'une démo à la production et voulez de l'aide sur le travail d'intégration IA, obtenez une consultation gratuite.

Foire Aux Questions

Qu'est-ce qu'un system prompt ?

Un system prompt est un ensemble d'instructions persistantes, défini une seule fois avant tout message utilisateur, qui définit le rôle, le comportement, les contraintes et le format de sortie du modèle pour toute la session. C'est la couche fixe du « comment il se comporte », et elle reste identique tandis que les messages propres à chaque requête de l'utilisateur changent à chaque tour.

Quelle est la différence entre un system prompt et un user prompt ?

Le system prompt est le « comment il se comporte » fixe, identique sur chaque requête ; le user prompt est le « quoi faire » propre à chaque requête. Une règle simple : si le contenu serait identique sur 1 000 requêtes, il appartient au system prompt, et tout ce qui change à chaque appel va dans le tour utilisateur.

Qu'est-ce qu'un message developer par rapport à un system prompt ?

Les modèles de raisonnement d'OpenAI (série o, GPT-5) prennent un message developer au lieu d'un message system. Il porte des instructions au niveau de l'application, classées au-dessus des messages utilisateur dans la chaîne de commandement, donc il l'emporte si un utilisateur tente de contourner vos règles. Anthropic garde un unique paramètre system de premier niveau plutôt qu'un message basé sur un rôle.

Quelle longueur doit avoir un system prompt ?

Le plus court possible tout en couvrant le rôle, les contraintes, le format de sortie et les garde-fous. Des prompts trop longs ajoutent un coût en tokens et de la latence à chaque appel, et peuvent sur-déclencher un raisonnement supplémentaire sur Claude Opus 4.5+. Si un prompt stable doit être long, placez le contenu réutilisé en premier pour que le prompt caching compense le coût.

Les system prompts fonctionnent-ils de la même façon dans ChatGPT/GPT et dans Claude ?

Même concept, mécaniques différentes. OpenAI utilise un rôle system ou developer à l'intérieur du tableau de messages, tandis qu'Anthropic utilise un paramètre system distinct de premier niveau et privilégie les balises XML pour séparer instructions, contexte et exemples. Les instructions se transposent d'un fournisseur à l'autre ; le câblage et les conventions de formatage, non.

Peut-on changer le system prompt en cours de conversation ?

Via l'API, vous renvoyez l'intégralité du payload de messages à chaque appel, donc vous pouvez techniquement changer le system prompt entre deux tours. Mais le modifier en cours de conversation peut casser la continuité et embrouiller le modèle sur ses propres règles. Préférez le définir une seule fois, ou changez-le délibérément pour un prompt distinct propre à une tâche.

Faut-il utiliser des balises XML ou du markdown dans un system prompt ?

Anthropic recommande des balises XML pour Claude afin de séparer instructions, contexte et exemples de sorte que le modèle ne les mélange pas. Les modèles OpenAI gèrent bien le markdown et les titres simples. Adaptez-vous à la convention du fournisseur plutôt que d'imposer un style unique aux deux, et gardez une cohérence dans le style choisi au sein d'un même prompt.

Les modèles de raisonnement ont-ils besoin de system prompts différents ?

Oui. Les modèles de raisonnement veulent des objectifs de haut niveau, comme un briefing donné à un collègue senior, pas un micro-management étape par étape. Abandonnez les CAPS agressives et le langage « vous DEVEZ » qui sur-déclenchent les modèles récents comme Claude Opus 4.5+, énoncez l'objectif et les garde-fous, et laissez le modèle planifier le chemin pour y arriver.

Quelles sont les parties d'un bon system prompt ?

Six blocs : rôle, contexte, contraintes, format de sortie, garde-fous ou replis, et éventuellement quelques exemples. Le rôle et les contraintes font l'essentiel du travail ; le bloc format de sortie rend les réponses analysables ; les garde-fous définissent ce qui se passe aux limites. Les exemples ne valent la peine d'être ajoutés que lorsque la qualité cible est difficile à décrire avec des mots.