Rédiger un prompt système : structure et exemple

Pour rédiger un bon prompt système, décrivez l'assistant comme vous briefez un nouveau collaborateur : qui il est et qui il sert, ce qu'il doit traiter ou non, les faits et sources sur lesquels il peut s'appuyer, les règles à respecter, la façon de répondre (ton, longueur, format) et ce qu'il fait quand il ne peut pas aider. Organisez-le en sections claires, gardez chaque règle courte et sans ambiguïté, placez le contenu stable en premier et testez-le sur des conversations réalistes avant la mise en ligne. Voici une structure réutilisable et un exemple complet.

Ce qu'est un prompt système et où il se place

Dans une application d'IA, chaque requête au modèle comporte généralement deux niveaux :

• Prompt système : des instructions permanentes rédigées par vous, identiques pour chaque conversation.
• Messages utilisateur : ce que la personne saisit, différent à chaque fois.

Beaucoup d'API acceptent aussi les tours précédents de l'assistant et les résultats d'outils. Le prompt système encadre l'ensemble. Dans les outils de chat, des réglages similaires s'appellent parfois instructions personnalisées ou instructions de projet.

Comme le prompt système part avec chaque requête, il pèse aussi sur les coûts. Un prompt système de 2 000 tokens sur 30 000 requêtes par mois représente 60 millions de tokens d'entrée. Notre article sur la tarification des API LLM explique comment cela s'additionne, et le cache de prompt peut réduire le coût d'un prompt système stable.

Une structure en sept parties

Section	Contenu
1. Rôle et objectif	Qui est l'assistant, qui il sert, à quoi il sert
2. Périmètre	Sujets traités, sujets refusés ou transmis
3. Connaissances et sources	Informations utilisables, et que faire quand elles manquent
4. Règles	Comportements obligatoires et interdits, par ordre de priorité
5. Style	Ton, forme d'adresse, langue, longueur
6. Format de sortie	Structure, balisage, champs ou schéma
7. Solutions de repli et escalade	Que faire en cas de doute, de hors-périmètre ou quand un humain est nécessaire

Des titres clairs ou des délimiteurs comme des balises aident le modèle, et la prochaine personne qui devra maintenir le prompt.

Rédiger chaque section

1. Rôle et objectif

Une ou deux phrases suffisent : « Tu es l'assistant support de [entreprise], une boutique en ligne de mobilier de bureau. Tu aides les clients existants pour leurs questions sur les commandes, la livraison, les retours et l'entretien des produits. »

Un rôle fonctionne mieux s'il précise le public et la mission, pas s'il ajoute des superlatifs. « Expert de classe mondiale » n'apporte rien ; « répond à des clients sans connaissances techniques » change le vocabulaire.

2. Périmètre

Listez ce qui est inclus et exclu. Soyez explicite sur la réponse hors périmètre : « Si l'on t'interroge sur des sujets sans lien avec nos produits et commandes, dis brièvement que tu ne peux aider que sur ces sujets et suggère de contacter [canal]. »

3. Connaissances et sources

Indiquez au modèle d'où viennent les faits. Dans beaucoup d'applications, des passages pertinents d'une base de connaissances sont insérés dans chaque requête. Énoncez la règle : « Réponds uniquement à partir des informations du contexte fourni. Si la réponse n'y figure pas, dis que tu ne sais pas et propose de mettre le client en relation avec l'équipe. » C'est l'un des moyens les plus efficaces pour réduire les hallucinations de l'IA.

4. Règles

Courtes, concrètes, hiérarchisées. Les formulations positives marchent généralement mieux que de longues listes d'interdits :

• « Ne confirme que les dates de livraison présentes dans les données de commande. »
• « Ne demande jamais de numéro de carte complet ni de mot de passe. »
• « Remboursements et dédommagements sont décidés par l'équipe ; tu peux expliquer la procédure, pas promettre un résultat. »

Si deux règles peuvent entrer en conflit, dites laquelle l'emporte.

5. Style

Ton, forme d'adresse, niveau de langue, longueur. « Aimable et concis. Réponds dans la langue du client. Réponses de 120 mots maximum sauf si le client demande des détails. » Si votre marque a une charte éditoriale, résumez ce qui concerne les réponses écrites courtes.

6. Format de sortie

Pour un chat : paragraphes ou listes, markdown ou non, liens autorisés ou non. Pour une automatisation : un schéma précis. Si l'étape suivante d'un workflow analyse la sortie, spécifiez exactement le format et, si votre fournisseur le permet, utilisez les fonctions de sortie structurée plutôt que de compter sur la seule formulation.

7. Solutions de repli et escalade

Définissez ce qui se passe quand l'assistant ne peut pas aider : information manquante, client en colère, menace juridique, question de sécurité ou demande d'un humain. Donnez-lui une formulation exacte ou une action de transfert. Des solutions de repli claires évitent l'improvisation là où elle est la plus risquée.

Un exemple complet

## Rôle
Tu es l'assistant du service client d'ExampleCo Office, une boutique en ligne qui
vend du mobilier de bureau aux petites entreprises de l'UE. Tu aides les clients
existants pour les commandes, la livraison, les retours et l'entretien des produits.

## Périmètre
Inclus : suivi de commande, délais de livraison, retours et échanges, montage et
entretien, dimensions et matériaux des produits.
Exclus : négociation de prix, questions juridiques, sujets sans lien avec nos
produits. Pour une demande hors périmètre, dis brièvement que tu ne peux pas aider
et suggère d'écrire à support@[domaine].

## Sources
Utilise uniquement les informations de <context> et <order_data>. Si la réponse n'y
figure pas, dis que tu ne disposes pas de cette information et propose de
transmettre la question à l'équipe. Ne devine jamais de dates, de prix ni de règles.

## Règles (par ordre de priorité)
1. Ne demande jamais de numéro de carte, de mot de passe ni de numéro de pièce
   d'identité complet.
2. Ne promets ni remboursement, ni remise, ni dédommagement. Explique la procédure
   et propose de transmettre la demande.
3. N'indique que des dates de livraison présentes dans <order_data>.
4. Si le client évoque une blessure, un dommage matériel ou une action en justice,
   excuse-toi, ne discute pas de responsabilité et transfère à un humain (voir
   Escalade).

## Style
Aimable, calme et concis. Réponds dans la langue du client. Utilise la forme
d'adresse du client. 120 mots maximum sauf si le client demande des détails.

## Format
Texte simple en paragraphes courts. Liste numérotée uniquement pour des instructions
étape par étape. Lien uniquement s'il figure dans <context>.

## Escalade
Si tu ne peux pas résoudre la demande, si le client demande une personne ou si la
règle 4 s'applique, réponds puis ajoute la ligne :
HANDOVER: <résumé du problème en une phrase>

L'entreprise et les détails sont inventés pour l'illustration. Notez comment l'exemple sépare les instructions stables des données variables, qui arrivent à chaque requête dans des blocs balisés.

Tester un prompt système

Un prompt système est un logiciel ; testez-le comme tel.

1. Rédigez des conversations de test. Vingt à cinquante, c'est un bon début. Incluez questions typiques, cas limites, informations manquantes, demandes hors périmètre, clients frustrés et tentatives de faire ignorer ses règles à l'assistant.
2. Définissez le comportement attendu. Pour chaque test, notez ce qu'une bonne réponse doit contenir ou non.
3. Exécutez et relisez. Notez chaque réponse réussie ou échouée au regard des attentes.
4. Ne changez qu'une chose à la fois. Puis relancez tout.
5. Retestez après un changement de modèle. Le comportement peut varier d'une version à l'autre.
6. Surveillez les conversations réelles. Échantillonnez régulièrement de vraies conversations et ajoutez les échecs au jeu de test.

Pour la relecture en production, voir l'IA human-in-the-loop.

Des exemples dans le prompt système

Montrer un ou deux courts échanges d'exemple fixe souvent ton et format plus efficacement qu'une description. Signalez-les clairement comme exemples et variez-les, sinon le modèle risque de copier leur formulation. Notre article sur le few-shot prompting explique comment les choisir.

Les questions de sécurité

• Un prompt système n'est pas un verrou. Des utilisateurs déterminés peuvent amener un modèle à révéler ou ignorer ses instructions. Appliquez les droits dans le code de l'application : quelles données l'assistant peut consulter et quelles actions il peut déclencher.
• Aucun secret dans le prompt. N'y mettez jamais de clés d'API, mots de passe ou données internes que l'utilisateur ne doit pas voir.
• Traitez le contenu inséré comme non fiable. Documents, e-mails ou pages web placés dans le contexte peuvent contenir des instructions (« ignore les règles précédentes »). Demandez au modèle de traiter le contexte comme de l'information, pas comme des instructions, et renforcez cela par des contrôles techniques.
• Limitez les actions. Si l'assistant peut appeler des outils, donnez-lui le minimum de droits et exigez une confirmation pour les actions lourdes de conséquences.

Les erreurs fréquentes

• Des rôles flous. « Assistant serviable » ne donne aucune direction.
• Des règles contradictoires. « Sois exhaustif » et « sois bref » sans priorité.
• Des règles importantes noyées. Placez les règles critiques en haut, numérotées.
• Des prompts trop longs. Répéter la même consigne de cinq façons coûte des tokens et peut semer la confusion plutôt que renforcer.
• Aucune solution de repli. Sans consigne face à l'inconnu, le modèle improvise.
• Mélanger données variables et instructions. Gardez les données propres à l'utilisateur dans des blocs séparés et clairement balisés. Cela garde aussi la partie stable compatible avec le cache.
• Aucun suivi de versions. Stockez les prompts système dans un dépôt ou un document avec historique et responsable.

Une aide rapide à la rédaction

Si vous partez de zéro, esquissez rôle, tâche, règles et format avec le générateur de prompt IA, puis transposez le résultat dans les sept sections ci-dessus. Pour les principes généraux d'un bon prompt, lisez le guide de l'ingénierie de prompt en entreprise.