Le system prompt définit le rôle, les priorités et les règles stables de l’assistant. Il influence fortement la réponse, mais ne constitue ni un contrôle d’accès ni une garantie. Une bonne instruction système reste courte, explicite et séparée des données dynamiques.
Une structure utile
Décrivez d’abord l’objectif et le public, puis les règles importantes, les limites, l’usage des outils et le format attendu. Distinguez obligations et préférences. Évitez les longues listes redondantes ou contradictoires : le modèle arbitrera de façon imprévisible. Placez les connaissances changeantes dans un RAG ou une API, pas dans le prompt.
Séparer instructions et données
Les messages utilisateur, pages Web et documents récupérés sont non fiables. Encadrez-les comme contenu à analyser et rappelez qu’ils ne modifient pas les règles. Cette séparation réduit certaines injections, mais la sécurité réelle repose sur validation, permissions et limitation des outils côté serveur.
Formats et exemples
Lorsque le fournisseur prend en charge les sorties structurées, utilisez un schéma plutôt qu’une description vague du JSON. Quelques exemples représentatifs clarifient ton et décisions, mais consomment du contexte et peuvent surcontraindre. Ajoutez aussi des cas de refus et d’ambiguïté.
Versionner et mesurer
Associez chaque version du prompt à un dataset et à des métriques de qualité, sécurité, coût et latence. Comparez les changements en aveugle lorsque le jugement est subjectif. En production, tracez l’identifiant de version plutôt que de recopier systématiquement tout le prompt.
FAQ
Plus le prompt est long, meilleur est le résultat ?
Non. La clarté et la cohérence comptent davantage.
Peut-on cacher complètement le system prompt ?
Ne comptez pas sur son secret comme mesure de sécurité ; concevez le système pour résister à sa divulgation.
Faut-il un prompt différent par modèle ?
Souvent, au moins une validation et quelques adaptations sont nécessaires.
Patron de system prompt testable
~~~text Rôle Tu aides le support à classer une demande.
Périmètre Utilise uniquement les catégories facturation, accès et incident.
Règles
- N’invente pas d’information absente.
- Demande une précision si la catégorie reste ambiguë.
- Ne reproduis jamais une donnée bancaire complète.
Sortie Retourne category, confidence et rationale selon le schéma fourni. ~~~
Séparez les règles stables du contexte variable. Les documents RAG et le texte utilisateur doivent rester dans des messages distincts et être considérés comme non fiables. Versionnez le prompt avec un identifiant, puis testez-le sur un jeu fixe :
~~~python cases = [ ("Mot de passe oublié", "accès"), ("Deux prélèvements", "facturation"), ] for text, expected in cases: result = classify(text) assert result.category == expected ~~~
Un system prompt n’est pas une barrière de sécurité. Les autorisations, validations et limites d’outils doivent être imposées par le code.