Le rôle et le system prompt

Une seule phrase de rôle change le vocabulaire, la profondeur et les priorités de toutes les réponses qui suivent.

Temps de lecture : 12 min | Niveau : Intermédiaire

Ce que tu sauras faire après

Distinguer le system prompt du message utilisateur, et savoir quoi mettre où.
Écrire un rôle qui change réellement la réponse au lieu de la décorer.
Réutiliser 4 system prompts prêts à l'emploi pour ton quotidien dev et data.
Placer un system prompt dans un appel API Claude et OpenAI.
Reconnaître où se cache le system prompt dans une interface de chat.

🧩 System prompt vs message utilisateur

Un appel à un modèle se compose de deux types de texte :

	System prompt	Message utilisateur
Rôle	Les règles permanentes	La demande du moment
Durée de vie	Vaut pour toute la conversation	Vaut pour ce tour
Contenu	Qui tu es, comment tu réponds, ce qui est interdit	Les données, la question précise
Change souvent ?	Non, tu l'écris une fois	Oui, à chaque message

L'image la plus utile vient de la doc OpenAI : pense au system prompt comme la définition d'une fonction et au message utilisateur comme ses arguments. La fonction ne change pas ; les arguments changent à chaque appel.

Une hiérarchie d'autorité

Ce n'est pas qu'une question de place dans la requête. OpenAI décrit explicitement des niveaux d'autorité différents entre les rôles de message :

developer : instructions fournies par le développeur de l'application, prioritaires sur les messages utilisateur.
user : instructions de l'utilisateur final, prioritaires après les messages developer.
assistant : les messages générés par le modèle lui-même.

Retiens le principe : ce que tu places dans le system prompt pèse plus lourd que ce que tu écris dans le message du moment.

Où est le system prompt quand tu es dans un chat ?

Dans une interface de chat grand public, tu ne le vois pas directement. Tu le retrouves sous d'autres noms selon les produits : instructions personnalisées, projets, GPT personnalisés, préférences. C'est le même mécanisme : un texte injecté avant ta conversation.

En pratique, si tu utilises un assistant pour ton travail tous les jours, écris ton system prompt une fois et range-le là. Tu arrêtes de répéter « je suis data engineer, on est sur PostgreSQL » à chaque message.

🎭 Ce que le rôle change vraiment

Anthropic le formule simplement : définir un rôle dans le system prompt focalise le comportement et le ton du modèle pour ton cas d'usage, et même une seule phrase fait une différence.

Concrètement, le rôle agit sur trois choses.

1. Le vocabulaire

Même question, trois rôles, trois réponses.

Rôle	Question : « cette table est lente, pourquoi ? »
Expert SQL PostgreSQL	Parle de plan d'exécution, seq scan, cardinalité, statistiques, `EXPLAIN ANALYZE`
Analyste business	Parle de volume de données, de fraîcheur, de ce que l'utilisateur perçoit
Formateur	Explique d'abord ce qu'est un index, avec une analogie

2. La profondeur

Un rôle « senior » ou « expert » produit des réponses plus techniques et plus courtes. Un rôle « pédagogue » développe davantage. Tu choisis selon ce que tu vas faire de la réponse.

3. Les priorités

Tu privilégies toujours la lisibilité à la performance et Tu privilégies toujours la performance à la lisibilité sur le même code donnent deux revues opposées. Explicite ton arbitrage : sinon le modèle choisit à ta place.

🧷 4 system prompts prêts à l'emploi

Copie-les tels quels. Remplace les [CHAMPS].

A. Expert SQL PostgreSQL

Tu es un data engineer senior, expert PostgreSQL [VERSION_PG, ex: 16].

Contexte permanent :
- Entrepôt analytique de [SECTEUR_ACTIVITE].
- Les tables de faits font entre [VOLUME_MIN] et [VOLUME_MAX] lignes.
- Les requêtes sont lues et modifiées par des analystes de niveau SQL intermédiaire.

Comment tu réponds :
- Tu écris du SQL PostgreSQL valide, jamais de syntaxe d'un autre moteur.
- Tu formates : mots-clés en majuscules, une clause par ligne, indentation de 2 espaces.
- Tu préfères des CTE nommées à des sous-requêtes imbriquées, pour la lisibilité.
- Quand une requête peut être lente, tu signales pourquoi en une phrase après le bloc SQL.
- Tu n'écris jamais de DROP, TRUNCATE ou DELETE sans WHERE, même si on te le demande :
  tu proposes la version sûre et tu expliques le risque en une ligne.
- Si le schéma fourni ne suffit pas pour écrire la requête, tu poses la question
  précise qui manque au lieu d'inventer des noms de colonnes.

B. Reviewer Python

Tu es un développeur Python senior qui relit du code de data engineering.

Contexte permanent :
- Code exécuté dans [ORCHESTRATEUR, ex: Airflow 2.x] sur des volumes de l'ordre
  de [ORDRE_DE_GRANDEUR, ex: quelques millions de lignes].
- Python [VERSION, ex: 3.12]. Bibliothèques autorisées : [LISTE, ex: pandas, polars, sqlalchemy].

Comment tu relis, dans cet ordre de priorité :
1. Correction : le code produit-il le bon résultat ?
2. Cas limites : valeurs nulles, DataFrame vide, colonne absente, doublons, fuseaux horaires.
3. Performance au regard du volume indiqué.
4. Lisibilité.

Comment tu réponds :
- Un tableau markdown | Gravité | Ligne | Problème | Correctif |.
- Gravité parmi : bloquant, important, mineur.
- Le correctif est du code, pas une description de code.
- Tu ne commentes ni le style ni le nommage sauf si ça cause un bug réel.
- Si tu ne vois aucun problème bloquant, tu le dis explicitement. Tu n'inventes pas
  de remarque pour remplir.

C. Analyste business

Tu es un analyste data qui traduit des chiffres pour des décideurs non techniques.

Contexte permanent :
- Secteur : [SECTEUR]. Indicateurs suivis : [LISTE_KPI].
- Tes lecteurs sont [PUBLIC, ex: des responsables de magasin] : ils ne lisent
  ni SQL ni code, et ils ont 3 minutes.

Comment tu réponds :
- Tu commences par la conclusion en une phrase, avant toute explication.
- Tu cites toujours le chiffre exact et la période exacte quand tu affirmes quelque chose.
- Tu distingues clairement ce que les données montrent de ce que tu supposes :
  toute hypothèse est introduite par « hypothèse : ».
- Tu ne parles ni de table, ni de jointure, ni de requête.
- Tu termines par la prochaine question à creuser, en une phrase.
- Si les données fournies ne permettent pas de conclure, tu l'écris franchement
  et tu dis quelle donnée manque.

D. Aide à la rédaction professionnelle

Celui-ci est fait pour ton besoin d'écriture : tu donnes des notes brouillonnes, il rend un texte propre.

Tu es un rédacteur professionnel francophone qui met en forme les écrits
d'un ingénieur data. Il pense vite et écrit en style télégraphique.

Ton travail : transformer ses notes brutes en texte clair, sans jamais ajouter
d'information qui n'est pas dans les notes.

Règles absolues :
- Tu n'inventes aucun fait, aucun chiffre, aucune décision, aucune date.
- Si une note est ambiguë, tu produis la version la plus prudente et tu listes
  la question à trancher sous le texte, dans une section « À vérifier ».
- Tu écris en phrases courtes. Une idée par phrase.
- Tu n'utilises ni jargon marketing, ni formule creuse, ni superlatif.
- Tu gardes les termes techniques tels quels, tu ne les traduis pas.
- Tu tutoies ou vouvoies selon ce qui est indiqué dans la demande ; par défaut, tu vouvoies.

Tu rends toujours deux choses : le texte final, puis la section « À vérifier »
si elle n'est pas vide.

💻 Où se met le system prompt dans un appel API

Claude — paramètre `system`

Chez Anthropic, le system prompt est un paramètre à part entière, au même niveau que model et messages. Il n'est pas un message dans le tableau messages.

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    system="You are a helpful coding assistant specializing in Python.",
    messages=[
        {"role": "user", "content": "How do I sort a list of dictionaries by key?"}
    ],
)

print(message.content)

Exemple repris de la documentation Anthropic. Le même appel en cURL :

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 1024,
    "system": "You are a helpful coding assistant specializing in Python.",
    "messages": [
      {"role": "user", "content": "How do I sort a list of dictionaries by key?"}
    ]
  }'

Retiens la structure, pas l'identifiant de modèle : les noms de modèles changent souvent. Vérifie l'identifiant à jour dans la documentation au moment où tu écris ton code.

OpenAI — paramètre `instructions` ou rôle `developer`

Chez OpenAI, deux voies coexistent. Le paramètre instructions donne au modèle des consignes de haut niveau sur son comportement, son ton et ses objectifs. Attention à une limite documentée : instructions ne s'applique qu'à la génération en cours et ne persiste pas dans une conversation multi-tours passant par previous_response_id. L'autre voie est un message de rôle developer placé avant le message user.

Un principe qui vaut partout

Google conseille de placer les contraintes de comportement, la définition de persona et les exigences de format dans l'instruction système ou tout au début du prompt utilisateur. Si ton outil n'expose pas de system prompt, mets ces éléments en tête de ton message. L'effet est proche.

🚧 Trois erreurs sur le rôle

Un rôle décoratif. Tu es un expert mondial en données n'apporte rien : aucune de ces phrases ne change une décision. Un rôle utile contient une spécialité (PostgreSQL 16) et un arbitrage (lisibilité avant performance).

Un system prompt qui gonfle. La fenêtre de contexte est limitée, et tout ce que tu y laisses en permanence prend la place du contenu utile. Microsoft consacre une section entière à cette « efficacité d'espace » : préfère un tableau à un JSON où chaque nom de champ est répété, et surveille les espaces inutiles, qui comptent comme des tokens. Si ton system prompt dépasse une trentaine de lignes, déplace les détails ponctuels dans le message utilisateur.

Les données dans le system prompt. Le system prompt contient des règles, pas des données. Un CSV, un schéma, un log vont dans le message utilisateur, balisés (fichier 05). Sinon tu recharges les mêmes données à chaque tour, et tes règles se noient dedans.

A retenir

System prompt = les règles permanentes. Message utilisateur = la demande et les données du moment.
Image OpenAI : le system prompt est la fonction, le message utilisateur ses arguments.
Les rôles ont des niveaux d'autorité différents : developer prime sur user.
Chez Claude, le system prompt est le paramètre system, pas un élément du tableau messages.
Un rôle utile porte une spécialité et un arbitrage explicite, pas un adjectif flatteur.
Écris ton system prompt une fois et range-le dans les instructions personnalisées de ton outil.
Ne mets jamais de données volumineuses dans le system prompt.

Le rôle et le system prompt#

Ce que tu sauras faire après#

🧩 System prompt vs message utilisateur#

Une hiérarchie d'autorité#

Où est le system prompt quand tu es dans un chat ?#

🎭 Ce que le rôle change vraiment#

1. Le vocabulaire#

2. La profondeur#

3. Les priorités#

🧷 4 system prompts prêts à l'emploi#

A. Expert SQL PostgreSQL#

B. Reviewer Python#

C. Analyste business#

D. Aide à la rédaction professionnelle#

💻 Où se met le system prompt dans un appel API#

Claude — paramètre system#

OpenAI — paramètre instructions ou rôle developer#

Un principe qui vaut partout#

🚧 Trois erreurs sur le rôle#

A retenir#

Sources#