Comment écrire un system prompt efficace

Un bon system prompt change tout. Avec le même modèle, vous pouvez obtenir une réponse vague, trop bavarde ou incohérente… ou au contraire un assistant cadré, utile et régulier. La différence vient souvent des instructions système.

Le problème, c’est que beaucoup de guides expliquent ce qu’est un system prompt sans montrer comment le construire proprement. Résultat : on empile des règles, on mélange rôle, ton, format et exceptions, puis on s’étonne que le modèle réponde de travers.

Dans ce guide, vous allez voir comment écrire un system prompt clair, testable et durable pour ChatGPT, Claude ou Gemini, avec une structure simple, des exemples concrets et les erreurs qui font dérailler les résultats.

Qu’est-ce qu’un system prompt, au juste ?

Un system prompt est l’ensemble d’instructions placé au niveau le plus haut pour cadrer le comportement du modèle. C’est là qu’on définit son rôle, ses priorités, ses contraintes de ton, son format de sortie et parfois les règles métier qu’il doit suivre.

Chez OpenAI, cette couche d’instructions correspond aujourd’hui au champ instructions de l’API Responses ou à un message developer, qui prend priorité sur le message utilisateur. Anthropic suit la même logique avec le champ system, utilisé pour définir le rôle et les consignes globales de Claude. Google recommande aussi les system instructions pour fixer le comportement, le contexte et le format attendus dans Gemini.

En clair : le system prompt n’est pas la demande ponctuelle de l’utilisateur. C’est le cadre permanent dans lequel cette demande sera interprétée.

Pourquoi un bon system prompt améliore vraiment les résultats

Un system prompt bien écrit sert à trois choses.

1. Réduire l’ambiguïté. Un modèle généraliste peut répondre de mille façons. Si vous précisez le rôle, le niveau attendu et le format de sortie, vous réduisez la marge d’interprétation.

2. Stabiliser la qualité. Sans cadre système, un assistant peut être excellent sur une réponse puis médiocre sur la suivante. Avec de bonnes instructions, le comportement devient plus prévisible d’un tour à l’autre.

3. Diminuer la charge sur le prompt utilisateur. Si le ton, la structure et les règles sont déjà définis au niveau système, l’utilisateur n’a plus besoin de répéter les mêmes consignes à chaque requête.

C’est exactement pour ça que les documentations officielles insistent sur les instructions de haut niveau : elles servent à piloter le modèle avant même qu’il ne lise la tâche.

La structure simple d’un system prompt efficace

Le meilleur system prompt n’est pas forcément long. Il est surtout structuré.

Voici une trame robuste qui fonctionne dans la majorité des cas :

Rôle — qui est l’assistant ?
Mission — que doit-il accomplir ?
Contexte — dans quel environnement ou usage ?
Règles de sortie — quel format, quelle longueur, quel niveau de détail ?
Contraintes — ce qu’il doit éviter ou ne jamais faire
Critères de qualité — à quoi ressemble une bonne réponse ?

Sous forme compacte :

Tu es [rôle précis].

Ta mission : [objectif concret].

Contexte : [qui est l’utilisateur, environnement, contraintes métier].

Règles de réponse :
- [format attendu]
- [niveau de détail]
- [ton]
- [structure]

Contraintes :
- [ne pas inventer]
- [signaler l’incertitude]
- [ne pas sortir du périmètre]

Critères de qualité :
- [ce qui rend la réponse utile]

Cette structure évite le piège classique du pavé confus où toutes les consignes sont mélangées.

Étape 1 : définir un rôle précis, pas générique

C’est l’erreur la plus courante : écrire « tu es un assistant utile ». Ça ne sert presque à rien.

Un bon rôle donne un point de vue opérationnel au modèle. Plus il est relié à une tâche réelle, mieux c’est.

❌ Tu es un assistant IA utile.

✅ Tu es un consultant SEO senior spécialisé dans les audits on-page pour des sites de contenu francophones.

Anthropic recommande explicitement de donner un rôle à Claude, même en une phrase. OpenAI suit la même logique avec les instructions de haut niveau. Le rôle agit comme un cadre de décision : il influence le vocabulaire, le niveau de détail et les arbitrages implicites du modèle.

Bonne pratique : définissez un rôle par usage, pas un rôle universel pour tout faire.

Étape 2 : écrire la mission en langage concret

La mission doit décrire le résultat attendu, pas une intention vague.

❌ Aide l’utilisateur au mieux.

✅ Aide l’utilisateur à produire des briefs SEO actionnables, structurés en H2/H3, avec mot-clé principal, angles, FAQ et maillage interne recommandé.

Un bon test : si vous donnez cette mission à un collègue humain, comprend-il ce qu’il doit livrer ? Si la réponse est non, le modèle sera perdu lui aussi.

Étape 3 : ajouter le contexte qui change la réponse

Le contexte évite les réponses « génériques internet ». C’est souvent là qu’on gagne en qualité.

Vous pouvez préciser :

le type d’utilisateur final
le niveau d’expertise attendu
la langue
le secteur
les contraintes d’outil ou de workflow
les critères métier importants

Exemple :

Le public est francophone, niveau intermédiaire.
Les réponses doivent être orientées action, sans jargon inutile.
Le contenu sera publié sur un site SEO : privilégie les formulations claires et les listes courtes.

Anthropic souligne que donner le pourquoi d’une contrainte améliore souvent la qualité. Si une règle existe pour une raison précise, dites-le.

Ne mets pas d’ellipses, car les réponses seront lues à voix haute par une synthèse vocale.

Cette explication aide le modèle à généraliser correctement au lieu de suivre une règle de façon mécanique.

Étape 4 : verrouiller le format de sortie

Si vous voulez un format spécifique, dites-le au niveau système. N’espérez pas que le modèle le devine.

Vous pouvez encadrer :

la structure en sections
la longueur maximale
le type de sortie (JSON, tableau, puces, plan)
l’ordre des informations
la présence d’une conclusion ou non

Exemple simple :

Réponds toujours avec cette structure :
1. Diagnostic rapide
2. Recommandations prioritaires
3. Exemple concret
4. Prochaine action

Exemple plus strict :

Si l’utilisateur demande une extraction de données, retourne un JSON valide.
N’ajoute aucun texte avant ou après le JSON.

C’est particulièrement utile si vous combinez votre assistant avec du few-shot prompting ou avec des sorties structurées côté API.

Étape 5 : écrire de vraies contraintes

Les contraintes empêchent les dérives. Sans elles, le modèle comble les trous, improvise, ou sur-répond.

Les plus utiles sont souvent les plus simples :

ne pas inventer une source ou un chiffre
signaler clairement l’incertitude
demander une précision si la requête est trop ambiguë
rester dans un périmètre donné
éviter certains tons ou formulations

Exemple :

Si une information manque, dis-le explicitement.
N’invente jamais de statistiques, de références ou de fonctionnalités produit.
Si la demande est trop vague pour répondre correctement, pose au maximum 2 questions de clarification.

Ce type de garde-fou a plus d’impact qu’une longue liste de micro-règles stylistiques.

Étape 6 : définir ce qu’est une bonne réponse

Un modèle suit mieux une consigne quand il sait à quoi ressemble le résultat attendu.

Ajoutez 2 à 4 critères de qualité mesurables :

Une bonne réponse doit :
- être directement exploitable
- aller droit au but
- donner au moins un exemple concret
- éviter le jargon inutile

C’est une astuce sous-estimée. Elle force le modèle à optimiser sa réponse selon vos critères réels, pas selon sa moyenne statistique.

Faut-il ajouter des exemples dans le system prompt ?

Oui, quand le format ou le style sont critiques.

Anthropic recommande 3 à 5 exemples bien structurés pour améliorer la cohérence. Dans Claude, les balises XML comme <examples> et <example> aident à séparer proprement les consignes, le contexte et les exemples. OpenAI et Gemini répondent aussi très bien à quelques exemples courts quand on veut verrouiller un format de sortie.

Mais attention : le few-shot dans le system prompt ne doit pas transformer vos instructions en roman.

À faire :

exemples courts
cas proches de l’usage réel
format homogène
diversité minimale

À éviter :

10 exemples quasi identiques
exemples trop longs
exemples contradictoires avec les règles écrites

Si vous voulez aller plus loin, lisez aussi notre guide sur le chain-of-thought prompting pour comprendre quand il faut guider le raisonnement et quand il vaut mieux rester simple.

Exemple 1 : system prompt pour un assistant rédaction SEO

Tu es un rédacteur SEO senior spécialisé dans les contenus francophones à forte valeur pratique.

Ta mission est d’aider l’utilisateur à produire des articles utiles, structurés et précis.

Contexte :
- Le public est francophone.
- Le ton doit être expert mais accessible.
- Les paragraphes doivent rester courts.
- Le contenu doit éviter les formulations creuses et robotiques.

Règles de réponse :
- Commence par répondre directement.
- Structure les réponses avec des H2/H3 ou des listes si utile.
- Donne au moins un exemple concret quand tu proposes une méthode.
- Si un mot-clé principal est fourni, intègre-le naturellement.

Contraintes :
- N’invente jamais de données, d’études ou de citations.
- Si l’information manque, dis-le clairement.
- N’utilise pas de phrases génériques comme "dans le paysage actuel" ou "il est important de noter".

Critères de qualité :
- Réponse actionnable
- Ton naturel
- Pas de remplissage
- Valeur pratique immédiate

Ce prompt fonctionne parce qu’il est spécifique sans être surchargé.

Exemple 2 : system prompt pour un assistant support client

Tu es un agent support pour un logiciel SaaS B2B.

Ta mission est d’aider les utilisateurs à résoudre leur problème rapidement, avec des réponses claires et rassurantes.

Règles de réponse :
- Réponds en français.
- Commence par reformuler brièvement le problème.
- Donne les étapes dans l’ordre.
- Termine par une vérification ou une prochaine action.

Contraintes :
- N’invente jamais une fonctionnalité produit.
- Si la réponse dépend d’un accès au compte, indique que l’utilisateur doit contacter le support humain.
- Si tu n’es pas certain, dis-le.

Ici, le rôle, la mission et les limites sont parfaitement lisibles.

Exemple 3 : system prompt pour produire du JSON propre

Tu es un assistant d’extraction de données.

Ta mission est d’extraire les informations demandées depuis le texte fourni.

Règles de réponse :
- Retourne uniquement un JSON valide.
- Respecte exactement les clés demandées.
- Utilise null si une valeur est absente.

Contraintes :
- N’ajoute aucun commentaire.
- N’ajoute aucun texte avant ou après le JSON.
- N’invente jamais une valeur absente du texte source.

Pour ce type d’usage, les contraintes explicites sont plus importantes que le style.

Les 7 erreurs les plus fréquentes

1. Vouloir tout faire avec un seul prompt universel

Un prompt unique pour le support, la rédaction, l’analyse et le code finit presque toujours en compromis médiocre. Mieux vaut plusieurs prompts ciblés.

2. Être trop vague

« Sois utile », « sois intelligent », « réponds bien » : ce sont des non-consignes. Elles n’apportent pas assez de signal.

3. Empiler des dizaines de règles

Plus vous ajoutez de consignes, plus vous risquez les conflits internes. Un bon system prompt est dense, pas verbeux.

4. Mélanger rôle, tâche et format dans une seule phrase

Quand tout est tassé dans un bloc flou, le modèle suit mal. Séparer les sections améliore la fiabilité.

5. Oublier les interdictions critiques

Si vous ne dites pas « n’invente pas », le modèle peut tenter de combler les blancs. Sur les usages pros, c’est un vrai risque, surtout si vous manipulez des tokens limités et une fenêtre de contexte chargée où certains détails peuvent passer au second plan.

6. Ne jamais tester les cas limites

Un prompt qui marché sur un cas simple peut s’écrouler dès qu’une demande devient ambiguë. Il faut le tester sur plusieurs scénarios.

7. Réécrire le prompt au lieu de l’évaluer

Les docs OpenAI insistent sur un point essentiel : fixez une version, testez-la, comparez-la, puis itérez. Modifier votre prompt au hasard sans évaluation mène vite à une fausse impression de progrès.

Méthode simple pour tester un system prompt

Avant de le déployer, faites au minimum ces 5 tests :

Cas nominal — la demande standard
Cas ambigu — la demande manque d’informations
Cas hors périmètre — la demande sort du rôle prévu
Cas format strict — vérifier la structure attendue
Cas d’incertitude — vérifier qu’il n’invente pas

Ensuite, notez les échecs : ton incorrect, format cassé, hallucination, longueur excessive, manque de clarté. Corrigez le prompt uniquement sur ces points.

C’est cette logique d’itération qui sépare un prompt “pas mal” d’un prompt fiable en production.

Faut-il faire un system prompt différent pour ChatGPT, Claude et Gemini ?

Oui, légèrement.

La structure de base peut rester la même, mais chaque modèle a ses habitudes. Claude répond particulièrement bien aux consignes claires, au cadrage de rôle et aux exemples structurés avec balises XML. OpenAI met en avant la hiérarchie des rôles et les instructions de haut niveau dans l’API Responses. Gemini recommande également les system instructions pour fixer comportement, contexte et format.

En pratique :

gardez un socle commun
adaptez la syntaxe des exemples selon le modèle
testez séparément les cas sensibles
n’imaginez pas qu’un prompt parfait sur un modèle sera optimal partout

FAQ

Quelle longueur pour un system prompt efficace ?

Dans la plupart des cas, 100 à 300 mots suffisent largement. Au-delà, vous devez avoir une bonne raison : règles métier, formats stricts, cas sensibles. Si votre prompt dépasse 500 mots, vérifiez qu’il n’essaie pas de compenser un mauvais design produit.

Un system prompt peut-il remplacer tous les prompts utilisateur ?

Non. Le system prompt définit le cadre, mais la demande utilisateur reste nécessaire pour indiquer la tâche concrète. Le bon modèle mental : le système fixe les règles, l’utilisateur donne le travail du jour.

Faut-il mettre les exemples dans le system prompt ou dans le prompt utilisateur ?

Si les exemples servent à cadrer durablement le style ou le format, le system prompt est pertinent. Si les exemples changent selon la tâche, mieux vaut les mettre dans le prompt utilisateur ou dans un bloc dédié injecté à la volée.

Quelle différence entre system prompt et custom instructions ?

Sur le fond, c’est proche. Les custom instructions sont une forme de cadrage persistant dans certains outils grand public. Le system prompt est la version plus explicite et plus contrôlable côté API ou application.

Points clés

Un bon system prompt contient un rôle précis, une mission claire, du contexte, des règles de sortie et des contraintes réelles
Le meilleur prompt n’est pas le plus long : c’est le plus structuré et le plus testable
Les exemples sont utiles si le format ou le ton doivent être très stables
Il faut tester les cas limites avant de considérer un prompt comme fiable
ChatGPT, Claude et Gemini acceptent la même logique de base, avec quelques ajustements de syntaxe