Conception de prompts en production : couches système, développeur et utilisateur

Dans un prototype, un prompt est une chaîne que vous avez écrite un après-midi. En production, cette approche s’effondre généralement au bout d’environ un mois.

Vous voudrez modifier une partie des instructions sans toucher aux autres, adapter le comportement à différents segments de clientèle, comparer des versions par un test A/B, revenir à la version précédente en cas de rupture et savoir quand le prompt a été modifié pour la dernière fois, ainsi que pourquoi.

Un système de prompts en production gère tout cela. Ce n’est pas “écrire une chaîne”. C’est une architecture.

Cet article décrit cette architecture : trois couches, une discipline de création de modèles, un contrôle de version, des évaluations et des pratiques opérationnelles qui transforment les prompts, de simples artefacts, en infrastructure.

Le travail sur les prompts en production comporte deux artefacts distincts : des modèles réutilisables et des données par demande. Versionnez les modèles comme du code. Traitez les prompts rendus et les réponses du modèle comme des journaux sensibles dès lors qu’ils contiennent des données utilisateur, client ou internes.

Les trois couches

Les prompts en production ont trois couches distinctes, chacune avec des préoccupations différentes :

Couche système. Comportement stable, identité, contraintes. Change rarement. Gérée par l’équipe concevant le comportement de l’IA.

Couche développeur. Instructions par fonctionnalité, descriptions d’outils, exigences de format de sortie. Change quand les fonctionnalités changent. Gérée par l’équipe de la fonctionnalité.

Couche utilisateur. La demande spécifique de l’utilisateur, plus un contexte dynamique (ses données, l’historique de la conversation, les connaissances récupérées). Différente à chaque appel.

Mélanger ces couches est l’erreur la plus courante en production. Le prompt système atteint 5 000 mots en mélangeant l’identité, les instructions de fonctionnalité et le contexte dynamique, et maintenant, changer une chose casse d’autres.

Séparer ces couches est fondamental :

┌─────────────────────────────────────┐
│ System prompt (stable)              │  Identity, behavior, hard constraints
├─────────────────────────────────────┤
│ Developer prompt (per-feature)      │  Feature instructions, tools, format
├─────────────────────────────────────┤
│ User prompt (per-call)              │  User query, context, conversation
└─────────────────────────────────────┘

Les API de modèles prennent explicitement en charge cette distinction :

• OpenAI : rôles system, developer, user.
• Anthropic : system, puis messages avec les rôles user et assistant. Les descriptions d’outils sont un paramètre séparé.
• Gemini : systemInstruction, puis contents avec les rôles.

Utilisez ces distinctions intentionnellement.

Couche 1 : le prompt système

Le prompt système définit qui est l’IA et comment elle se comporte. Il change rarement.

Un bon prompt système couvre :

Identité. Qui est l’IA. “Vous êtes un assistant IA pour [Entreprise], spécialisé dans [domaine].”

Voix et style. La manière dont elle doit s’exprimer, définie par des caractéristiques précises plutôt que des descriptions vagues.

Contraintes strictes. Ce qu’elle ne doit jamais faire. Produire certains contenus, prendre certaines décisions, ignorer certaines instructions.

Schémas de comportement. La manière de gérer les situations courantes : refus, transmission à une personne et incertitude.

Sécurité et conformité. Déclarations obligatoires, règles réglementaires, politiques de contenu.

Ce qu’il ne doit pas contenir :

• Instructions spécifiques à une fonctionnalité (“pour les e-mails de vente, faites X”).
• Contexte dynamique (“l’historique des commandes de l’utilisateur est…”).
• Descriptions d’outils (elles vont ailleurs).
• Des choses qui changent fréquemment.

Un bon prompt système fait 300 à 1000 mots. Plus long et il devient difficile à gérer ; plus court et vous sous-spécifiez le comportement.

Un modèle qui fonctionne :

You are [name], an AI assistant for [company / context].

## Your role
[2-3 sentences on what you do]

## Voice and style
- [Specific trait 1]
- [Specific trait 2]
- [Specific trait 3]
- Do not [anti-pattern 1]
- Do not [anti-pattern 2]

## Hard constraints
- Never [hard rule 1]
- Never [hard rule 2]
- Always [hard rule 3]

## How to handle uncertainty
- If you don't know something factual: say so explicitly.
- If a user asks for something outside scope: offer what you can help with.
- If a request might cause harm: refuse and explain why.

## Format expectations
- Plain text by default
- Use markdown when displaying code or structured data
- Be concise; do not pad responses with filler

C’est le squelette. Toute interaction passe par lui. Les changements sont délibérés et rares.

Couche 2 : le prompt développeur

Le prompt développeur est spécifique à la fonctionnalité. Différentes fonctionnalités ont différents prompts développeurs.

Un prompt développeur pour une fonctionnalité de résumé :

Task: produce a summary of the document below.

Requirements:
- 3-5 bullet points
- Each bullet is one complete sentence
- Focus on facts and concrete claims, not impressions
- If the document contains numbers, include the most important ones
- Do not include marketing language or speculation
- If the document is ambiguous about something important, note it

Format: plain markdown bullets, no preamble.

Un prompt développeur pour une fonctionnalité de revue de code :

Task: review the code diff below.

Output a JSON object with:
- summary: 1-2 sentence overview of the change
- concerns: array of specific issues (each: file, line, severity, description)
- suggestions: array of improvements (each: file, line, suggestion)
- approved: boolean (true if no blocking concerns)

Severity levels:
- "blocker": must be fixed before merge
- "warning": should be addressed but not blocking
- "nit": stylistic, optional

Focus on:
- Logic errors
- Security issues
- Performance issues
- Missing test coverage
- Unclear naming or structure

Skip:
- Formatting (handled by formatter)
- Subjective style preferences

Chaque fonctionnalité a son propre prompt développeur. Ils sont stockés séparément, versionnés séparément, évalués séparément.

Couche 3 : le prompt utilisateur

La couche utilisateur est dynamique. Elle inclut généralement :

La demande réelle de l’utilisateur. “Résumez ce document pour moi.”

Le contexte que le système a récupéré. Documents de RAG, historique client, historique de conversation.

Variables par appel. Nom de l’utilisateur, fuseau horaire, préférence linguistique, niveau de compte.

Cette couche est construite de manière programmatoire au moment de l’appel. La structure ressemble généralement à :

{conversation_history_summary}

{retrieved_context}

User's request: {user_query}

Additional context:
- User name: {name}
- User timezone: {timezone}
- User tier: {tier}

La structure exacte dépend de la fonctionnalité. Le principe : les données vont ici, pas dans les prompts système ou développeur.

Discipline de création des modèles

Les prompts en production sont construits à partir de modèles. La concaténation de chaînes directement dans le code convient à un prototype, mais ne passe pas à l’échelle.

Un système de modèles simple :

from string import Template

SUMMARIZE_TEMPLATE = Template("""
$conversation_summary

Document to summarize:
$document

User's specific instructions: $user_instructions
""")

prompt = SUMMARIZE_TEMPLATE.substitute(
    conversation_summary=summarize_conversation(history),
    document=document_text,
    user_instructions=user_query,
)

Pour aller plus loin, utilisez une bibliothèque de modèles telle que Jinja2 ou Handlebars, avec des conditions et des fragments réutilisables.

{% if user_tier == "enterprise" %}
You have access to advanced analysis features.
{% endif %}

{% if retrieved_context %}
Relevant context from your knowledge base:
{{ retrieved_context }}
{% endif %}

User's request: {{ user_query }}

La création à partir de modèles aide à prévenir l’injection de prompt par les variables — sous réserve d’échapper les entrées utilisateur lorsque nécessaire —, permet une logique conditionnelle et garantit une structure cohérente.

Contrôle de version

Les prompts sont du code. Stockez-les dans le contrôle de source.

Un modèle qui fonctionne : un répertoire prompts/ dans votre dépôt, avec un fichier par prompt :

prompts/
  system/
    main.txt
    customer-support.txt
    code-assistant.txt
  features/
    summarize.txt
    classify-ticket.txt
    generate-email.txt
  templates/
    base.j2

Chaque fichier est un prompt séparé, avec son propre historique de commits. Les changements sont examinés via des PR. Les déploiements en production font référence à des versions spécifiques.

Pourquoi cela importe :

• Visibilité des différences. Lorsqu’un prompt change, les différences apparaissent dans la pull request. Les personnes chargées de la revue voient précisément ce qui a changé.
• Retour en arrière. Lorsqu’un changement casse quelque chose, vous pouvez revenir en arrière.
• Historique. Les questions « quand avons-nous modifié la politique de remboursement ? » et « pourquoi ce paragraphe existe-t-il ? » trouvent leur réponse dans l’historique Git.
• Outils. Les linters, validateurs, ensembles d’évaluation intègrent tous les prompts basés sur des fichiers.

Évitez les prompts stockés sous forme de chaînes dans le code, difficiles à trouver et à comparer ; ceux stockés dans une interface tierce, dont la gestion des versions vous échappe ; et ceux copiés depuis des conversations, qui ne sont ni traçables ni testables.

Ne placez jamais dans le dépôt les conversations de production, les dossiers clients, les demandes d’assistance, les documents internes ou les prompts générés qui contiennent des variables sensibles. Le contrôle de version est réservé aux modèles réutilisables, aux données de test et aux exemples d’évaluation assainis. Les traces réelles doivent être conservées dans un système d’observabilité doté de règles de conservation, de contrôles d’accès et de mécanismes de suppression.

Les prompts comme données : stockage externe

Pour les prompts qui changent fréquemment — tests A/B, variantes selon le segment de clientèle ou la langue —, la gestion des versions fondée sur des fichiers est trop lente.

Solution : une base de données ou un service qui stocke les versions des prompts avec leurs métadonnées.

prompt = prompt_service.get(
    name="summarize",
    version="v3",
    locale="en",
    user_tier="enterprise",
)

Le service maintient :

• Les versions actuelles et historiques de chaque prompt.
• Métadonnées : quand ajouté, par qui, pourquoi.
• Des scores d’évaluation attachés à chaque version.
• Capacité de retour en arrière.

Outils : PromptLayer, Helicone, en interne. Pour la plupart des équipes, une solution interne avec un schéma de base de données simple fonctionne bien.

L’interface est déterminante. Ingénieurs et non-ingénieurs — équipes produit ou éditoriales — doivent pouvoir modifier les prompts. Toute modification doit toutefois être revue et réussir les évaluations avant son activation.

Changements gérés par évaluation

Chaque changement de prompt passe par des évaluations avant le déploiement. C’est incontournable pour les systèmes de production sérieux.

Le flux :

1. L’ingénieur ou le non-ingénieur rédige un changement de prompt.
2. Le changement est exécuté contre l’ensemble d’évaluation.
3. Les résultats de l’évaluation sont examinés avec le changement.
4. Si les évaluations passent (aucune régression, idéalement des améliorations), le changement peut être approuvé.
5. Les changements approuvés sont déployés.
6. La surveillance après déploiement détecte ce que les évaluations n’ont pas couvert.

En pratique, cela signifie que chaque prompt a un ensemble d’évaluation, et que l’ensemble s’exécute en CI sur les changements de prompt.

Sans ce contrôle, les changements de prompt provoquent des ruptures imprévisibles. Avec lui, vous pouvez avancer rapidement et en confiance.

Liste de vérification pratique pour le déploiement

Avant qu’une version de prompt soit mise en production, exigez une courte liste de vérification :

La liste de vérification jointe à cet article transforme ces vérifications en une revue de déploiement répétable.

Tests A/B en production

Pour de nouveaux prompts, les tests A/B contre la version existante sur une petite fraction du trafic en production donnent des signaux du monde réel au-delà des évaluations.

Dispositif :

• 95 % du trafic utilise le prompt en production v3.
• 5 % reçoit la nouvelle version candidate v4.
• Mesures : retours des utilisateurs, indicateurs en aval et scores d’évaluation sur le trafic réel.
• Après suffisamment de données, décidez : déployer v4 à 100 % ou garder v3.

Outils : indicateurs de fonctionnalité — LaunchDarkly ou solution interne —, services de gestion des versions de prompts tels que PromptLayer, et routage personnalisé.

Avertissements :

• Les tests A/B ne captent que les signaux mesurés. Sans retour des utilisateurs ni indicateurs de conversion en aval, ils apportent peu d’informations.
• La significativité statistique exige un volume suffisant. Les tests A/B sont donc difficiles pour les fonctionnalités peu utilisées.
• Ne lancez pas trop de tests A/B en même temps ; les interactions deviennent confuses.

Observabilité des prompts

Chaque appel LLM en production doit journaliser :

• Lequel des modèles de prompt a été utilisé (nom, version).
• Les variables substituées, au moyen de noms autorisés et de valeurs expurgées lorsque nécessaire.
• Le prompt final généré uniquement si la politique l’autorise ; sinon, une représentation expurgée, échantillonnée ou hachée.
• La réponse du modèle, expurgée ou échantillonnée pour les flux sensibles.
• Latence, nombre de jetons et coût.
• Signaux en aval (retour utilisateur, métriques de succès).

Ce sont les données nécessaires pour comprendre pourquoi le modèle a fourni une réponse étrange à un utilisateur donné. Sans elles, vous en êtes réduit aux conjectures.

Stockage : une table de base de données ou un outil d’observabilité. Tout journaliser entraîne des coûts réels — volume d’appels × nombre de jetons × stockage — et un risque tout aussi réel pour la confidentialité. Déterminez, pour chaque flux, quels champs peuvent être stockés sans risque. Expurgez par défaut les secrets et les données à caractère personnel, et limitez la durée de conservation sauf obligation de conformité contraire. Certaines équipes ne conservent qu’un échantillon.

Revue : examinez régulièrement, par exemple chaque semaine, un échantillon de prompts et de réponses réelles de production. Cette pratique détecte les problèmes non couverts par les évaluations.

Antipratique de conception des prompts

Voici les pratiques à éviter :

Antipratique 1 : le prompt géant. Un prompt système de 10 000 mots qui tente de gérer toutes les situations est difficile à modifier et à déboguer ; le modèle en ignore souvent les instructions les plus éloignées.

Solution : séparez les couches et utilisez un prompt ciblé par fonctionnalité.

Antipratique 2 : concaténation de chaînes dans le code.

prompt = "You are helpful. " + (
    "The user is a paid customer. " if user.tier == "paid" else ""
) + f"Their name is {user.name}. " + ...

Fragile, difficile à lire, propice à l’injection.

Solution : utilisez un système de modèles.

Antipratique 3 : un même prompt pour trop de cas d’usage.

Un unique prompt d’« assistant général » est utilisé pour rédiger des e-mails, effectuer des revues de code, assister les clients et mener des recherches. Ces tâches sont différentes ; un prompt unique n’en optimise aucune.

Solution : prompts développeurs spécifiques à la fonctionnalité sur un prompt système partagé.

Antipratique 4 : prompts codés en dur.

response = openai.chat.completions.create(
    messages=[
        {"role": "system", "content": "You are a helpful assistant..."},
        {"role": "user", "content": query}
    ]
)

Le prompt est caché dans le code. Impossible de le modifier sans un déploiement. Impossible de le tester en A/B. Impossible de le versionner indépendamment.

Solution : extrayez dans un fichier de prompt ou un service.

Antipratique 5 : aucune couverture d’évaluation.

Une fonctionnalité est livrée avec un prompt qui n’a jamais été testé systématiquement. La qualité repose sur une simple impression et toute dérive reste indétectable.

Solution : chaque prompt a un ensemble d’évaluation.

Antipratique 6 : intégrer des données au prompt système.

You are an assistant for John, a premium customer who joined in 2023, lives in Tallinn, and has 47 open tickets.

Le prompt système change alors à chaque appel, ce qui empêche sa mise en cache et crée de la confusion.

Solution : les données dynamiques vont dans la couche utilisateur/contexte, pas dans le prompt système.

Antipratique 7 : instructions enfouies au milieu du prompt.

Help the user with their request. Be polite. Format output as JSON. Don't use markdown. The user is asking about pricing, so be careful about quoting numbers. Output should be 1-2 sentences. Now help them.

Les instructions importantes sont perdues. Le modèle pourrait les manquer.

Solution : structurez avec des sections claires, placez les instructions critiques au début et à la fin (l’effet de récence aide).

Schémas adaptés aux fonctionnalités courantes

Voici quelques schémas propres à certaines fonctionnalités :

Classification

Task: classify the following text into one of these categories:
- billing: payment, refund, subscription
- technical: bug, error, integration issue
- account: login, password, profile changes
- feature_request: new functionality requests
- complaint: general dissatisfaction without specific actionable issue

Output a JSON object: {"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}

Text to classify:
{text}

Principes : catégories énumérées et définies, sortie structurée, niveau de confiance et justification.

Extraction

Task: extract structured data from the document below.

Schema:
- vendor_name: company that issued the invoice
- invoice_number: as printed on the document
- date: ISO 8601 format
- line_items: array of {description, quantity, unit_price, total}
- subtotal, tax, total: numbers

Rules:
- If a field is not present, use null
- Numbers should be numeric, not strings
- For ambiguous cases, set "needs_review": true and explain

Document:
{document}

Principes : schéma explicite, types attendus, gestion des données manquantes et transmission à une personne en cas d’ambiguïté.

Génération avec style

Task: write a {format} on the topic of {topic}, targeting {audience}.

Style:
- {Specific style trait 1}
- {Specific style trait 2}
- Avoid: {anti-pattern 1}, {anti-pattern 2}

Constraints:
- Length: {N} words
- Include: {required elements}
- Exclude: {forbidden elements}

Voice reference:
[Provide a sample of the desired voice]

Output: the {format} only, with no preamble or post-script.

Principes : caractéristiques stylistiques précises, contraintes explicites et voix illustrée par un exemple de référence.

Boucle agent

You have access to the following tools:
{tool_descriptions}

For each turn:
1. Think about what you need to do.
2. Decide if you need a tool. If yes, call it.
3. After observing the result, decide if you need more tools or can answer.
4. When you have enough information, produce the final answer.

Constraints:
- Maximum 5 tool calls per request.
- If after 5 calls you can't complete, explain what's missing.
- Never invent tool names or arguments.
- Verify tool results before acting on them.

User request:
{user_query}

Principes : étapes de raisonnement explicites, budget d’appels d’outils, prévention des informations inventées et analyse des résultats.

Aspects d’équipe

Les prompts en production impliquent généralement plusieurs personnes :

• Les ingénieurs connectent les prompts au système, maintiennent les modèles, gèrent les déploiements.
• Le produit définit ce que les prompts doivent accomplir.
• Le contenu/marketing gère les directives de voix et de style.
• Les experts de domaine connaissent ce qui est correct pour des cas d’utilisation spécifiques (langage juridique, termes médicaux, etc.).

Une pratique utile consiste à instaurer une « revue de prompt » comparable à une revue de code, avec les personnes compétentes pour chaque domaine. Les changements de voix sont examinés par l’équipe éditoriale, les changements logiques par les ingénieurs et le contenu spécialisé par l’expert du domaine.

Pour les cas d’utilisation sensibles (juridiques, médicaux, financiers), les prompts peuvent nécessiter une revue formelle et une approbation. Construisez le processus en conséquence.

Plan de maturité des prompts sur 90 jours

Pour les équipes passant de “les prompts sont des chaînes dans le code” à “les prompts sont une infrastructure gérée” :

Jours 1-30 : Fondations.

• Extraire tous les prompts dans des fichiers dédiés dans le contrôle de source.
• Établir le modèle en trois couches (système / développeur / utilisateur).
• Construire une couche simple de modèles de prompts.
• Mettre en place une journalisation de base des prompts et des réponses.

Jours 31-60 : Évaluation.

• Construire des ensembles d’évaluation pour les cinq premiers prompts.
• Exécuter les évaluations sur les changements de prompts (manuellement d’abord).
• Intégrer les évaluations à l’intégration continue pour les exécuter automatiquement sur les pull requests.

Jours 61-90 : Opérations.

• Mettre en place la gestion des versions de prompts au moyen d’une base de données ou d’un service.
• Ajouter la capacité de test A/B pour au moins un prompt critique.
• Construire des tableaux de bord pour la qualité des prompts en production.
• Établir un processus de revue pour les changements de prompts.

Après 90 jours, les prompts sont une infrastructure gérée. Les changements sont délibérés, testables, examinables, réversibles. La qualité est mesurable. La dérive est détectable.

Les prompts comme infrastructure

Les prompts en production ne sont pas de simples chaînes de caractères. Ils forment un système en couches, régi par une discipline de gestion des versions, de création de modèles, d’évaluation et d’observabilité.

L’architecture en trois couches — système, développeur et utilisateur — sépare les responsabilités et préserve la facilité de gestion. Les modèles de prompts réduisent la fragilité. Le contrôle de version ou un service dédié fournit l’historique. Les évaluations encadrent les changements et l’observabilité détecte ce qu’elles n’ont pas couvert.

Cette discipline est indispensable pour tout système de production sérieux. Les équipes qui l’ignorent se retrouvent avec des prompts dispersés dans le code, sans savoir quelle version est déployée, sans mesure de qualité et avec des changements de comportement constants et inexplicables.

Les équipes qui investissent dans l’infrastructure des prompts obtiennent un comportement de l’IA contrôlable, mesurable et améliorable. C’est ce qui distingue une fonctionnalité durable d’une dette technique croissante.

Commencez par l’architecture. Tout le reste devient plus facile.