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

Un prototype peut commencer par une chaîne en ligne. La pression de la production apparaît lorsque le prompt exige un responsable, une revue, une restauration, un traitement des données, plusieurs fonctionnalités ou langues, ou un comportement mesurable ; cela peut arriver avant le lancement et ne suit aucun calendrier universel.

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.

Une conception de prompts en production explicite ces choix. Le texte du prompt est un artefact au sein d’un système gouverné de publication et d’exécution.

Cet article utilise une architecture éditoriale à trois couches pour expliquer la responsabilité et la cadence des modifications, puis montre comment l’adapter aux API des fournisseurs. Il s’agit d’un modèle de référence, pas d’un format de transport universel. Pour la limite de sécurité, appliquez les recommandations de l’OWASP sur l’injection de prompt : séparer instructions et données facilite la revue et l’évaluation, mais aucun modèle de prompt ne crée une limite d’autorisation ou d’isolation.

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.

Trois couches éditoriales adaptées à une API

Cette conception sépare trois responsabilités éditoriales :

Couche système. Comportement, identité et contraintes relativement stables. Gérée par l’équipe responsable du comportement d’IA commun à plusieurs fonctionnalités.

Couche développeur. Instructions propres à la fonctionnalité, politique d’utilisation des outils et exigences de sortie. Gérée par l’équipe de la fonctionnalité.

Couche utilisateur et d’exécution. La demande de l’utilisateur et le contexte dynamique, notamment les données client autorisées, l’historique et les connaissances récupérées. Construite pour chaque requête ou tour de conversation.

Mélanger responsabilité, politique stable, instructions de fonctionnalité et données d’exécution peut compliquer la revue, l’évaluation, la mise en cache et le retour en arrière. Séparez-les lorsque cela améliore le contrôle ; n’imposez pas trois champs d’API si le fournisseur ou l’application les représente autrement.

L’autorité des instructions et l’emplacement des données sont liés, mais distincts. La hiérarchie de confiance détermine quelle instruction prévaut en cas de conflit. L’emplacement des données indique où l’application transporte le contenu dynamique ou non fiable. Placer un texte récupéré dans un champ utilisateur ou de contexte ne le rend ni autorisé, ni exact, ni sûr. Appliquez l’identité, l’accès par tenant, la minimisation, les autorisations d’outils et la validation des sorties hors du modèle.

Séparer ces couches est fondamental :

┌─────────────────────────────────────┐
│ Couche système (relativement stable)│  Identité, comportement, intention de politique
├─────────────────────────────────────┤
│ Prompt développeur (fonction)       │  Instructions, outils, format de la fonction
├─────────────────────────────────────┤
│ Prompt utilisateur (par appel)      │  Requête, contexte, conversation
└─────────────────────────────────────┘

Les API de modèles expriment ces distinctions de différentes manières :

• OpenAI : dans l’API Responses, utilisez le paramètre de premier niveau instructions ou un message developer pour les instructions de l’application et un message user pour l’entrée utilisateur. Ne supposez pas que les instructions d’une réponse précédente sont conservées lorsque vous gérez un flux à plusieurs tours.
• Anthropic : adaptez la conception à l’API Messages de Claude, à son mécanisme d’instructions système, aux rôles des messages et aux définitions d’outils ; les rôles pris en charge peuvent varier selon le modèle et la plateforme.
• Gemini : adaptez-la à system_instruction et au contenu de la requête, ainsi qu’à la configuration d’outils distincte de l’API choisie.

Utilisez un adaptateur propre à chaque fournisseur et des tests d’intégration. Ne recopiez pas les noms de rôles entre API en supposant une priorité, une persistance ou un comportement d’outils équivalents.

Couche 1 : le prompt système

Dans ce modèle éditorial, la couche système définit le rôle et le comportement communs à plusieurs fonctionnalités. Cherchez à la modifier moins souvent que les instructions de fonctionnalité, mais versionnez-la et évaluez-la à chaque changement.

Un bon prompt système couvre :

Identité. Rôle déclaré. “Vous êtes un assistant IA pour [Company], spécialisé dans [domain].”

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 comportementales obligatoires. Ce que le modèle doit refuser, transmettre, divulguer ou formater. Appliquez les contrôles de sécurité, d’autorisation et d’actions irréversibles dans le code de l’application et les systèmes en aval plutôt que de vous fier à ce texte seul.

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 prompt système ne doit être que de la longueur exigée par le comportement évalué. Un prompt court peut suffire et un prompt long peut encore omettre des règles critiques ; mesurez les conflits d’instructions, la qualité de la tâche, la latence et le coût en jetons plutôt que de viser un nombre de mots.

Un modèle qui fonctionne :

Vous êtes [name], un assistant IA pour [company / context].

## Votre rôle
[2-3 sentences on what you do]

## Ton et style
- [Specific trait 1]
- [Specific trait 2]
- [Specific trait 3]
- Évitez [anti-pattern 1]
- Évitez [anti-pattern 2]

## Contraintes strictes
- Ne jamais [hard rule 1]
- Ne jamais [hard rule 2]
- Toujours [hard rule 3]

## Gestion de l’incertitude
- Si vous ignorez un fait, dites-le explicitement.
- Si un utilisateur formule une demande hors périmètre, proposez l’aide que vous pouvez apporter.
- Si une demande risque de causer un préjudice, refusez-la et expliquez pourquoi.

## Exigences de format
- Texte brut par défaut
- Utiliser Markdown pour afficher du code ou des données structurées
- Répondre de manière concise, sans ajouter de remplissage

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é :

Tâche : résumez le document ci-dessous.

Exigences :
- 3-5 puces
- Chaque puce doit former une phrase complète
- Mettre l’accent sur les faits et les affirmations concrètes, pas sur les impressions
- Si le document contient des chiffres, inclure les plus importants
- Ne pas inclure de discours commercial ni de spéculations
- Signaler toute ambiguïté importante dans le document

Format : simples puces Markdown, sans préambule.

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

Tâche : examinez le diff de code ci-dessous.

Produisez un objet JSON avec :
- summary : aperçu de la modification en 1-2 phrases
- concerns : tableau de problèmes précis (chacun avec file, line, severity et description)
- suggestions : tableau d’améliorations (chacune avec file, line et suggestion)
- approved : valeur booléenne (true s’il n’existe aucun problème bloquant)

Niveaux de gravité :
- "blocker" : à corriger avant la fusion
- "warning" : à traiter, mais ne bloque pas la fusion
- "nit" : remarque stylistique facultative

Points à examiner en priorité :
- Erreurs de logique
- Problèmes de sécurité
- Problèmes de performance
- Couverture de tests insuffisante
- Noms ou structures peu clairs

Points à ignorer :
- Mise en forme (gérée par l’outil de formatage)
- Préférences stylistiques subjectives

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}

Demande de l’utilisateur : {user_query}

Contexte supplémentaire :
- Nom de l’utilisateur : {name}
- Fuseau horaire de l’utilisateur : {timezone}
- Niveau de l’utilisateur : {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 maintient une structure cohérente, permet une logique conditionnelle et facilite la délimitation ou l’échappement des entrées utilisateur. Elle n’arrête pas à elle seule l’injection de prompt : traitez tout texte non fiable comme des données, jamais comme des instructions.

Choisir une source de vérité gouvernée

Traitez les prompts de production comme des artefacts de publication versionnés. La source de vérité peut être un dépôt, un registre ou service interne, ou un produit géré doté d’une interface d’édition. Choisissez selon les besoins de gouvernance et d’exploitation, sans supposer qu’un même mode de stockage convient à toutes les équipes.

Pour des prompts gérés comme du code, un répertoire prompts/ contenant un fichier par prompt constitue un point de départ clair :

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

Chaque fichier peut avoir son propre historique et sa revue par PR, tandis que les déploiements en production font référence à une version connue du code.

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.

Comparez explicitement les principales options :

Les chaînes en ligne conviennent à un petit prototype, mais sont plus difficiles à découvrir et à publier séparément. Une interface d’édition peut convenir si ses autorisations, sa revue, sa provenance, son déploiement et son retour en arrière répondent au risque du flux. Les prompts copiés depuis des chats doivent suivre le même parcours de revue, d’assainissement et d’évaluation que tout autre candidat.

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.

Registres et services d’exécution

Lorsque les prompts doivent être publiés à un rythme différent de l’application, ou que des éditeurs autorisés ont besoin d’une interface contrôlée, un dépôt seul peut ne pas convenir. Un registre ou service peut sélectionner une version approuvée à l’exécution.

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 doit maintenir :

• 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.

Le moteur de stockage n’est qu’une partie de la conception. Comparez accès par rôles, historique d’audit, accès d’exécution authentifié, promotion entre environnements, cohérence du déploiement, retour en arrière, export, chiffrement, traitement des données, disponibilité et coût d’exploitation. Une petite base de données ne suffit que si les contrôles qui l’entourent répondent au besoin.

Définissez qui peut rédiger, revoir, approuver, publier, revenir en arrière et lire les prompts rendus. Le droit de modifier n’implique pas celui de publier en production. Les flux sensibles peuvent exiger des rôles distincts, des aperçus expurgés, une double approbation ou une interface qui n’expose jamais les données réelles des clients.

Changements gérés par évaluation

Les modifications de prompt susceptibles d’affecter les résultats utilisateur, l’utilisation des outils, le traitement des données, le respect des politiques ou les décisions en aval doivent être revues et soumises à des évaluations proportionnées au risque avant leur déploiement. Une modification rédactionnelle à faible risque peut exiger un petit jeu de régression ; un prompt influençant un paiement, un compte ou une décision réglementée nécessite des cas hors ligne plus robustes, des tests adversariaux, une approbation et un déploiement progressif. Définissez une voie d’urgence limitée, surveillée, approuvée et réversible plutôt que de contourner silencieusement le contrôle.

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.

Pour les prompts importants, conservez un jeu d’évaluation représentatif et exécutez en CI les contrôles stables et automatisables lorsque leur signal est assez fiable pour bloquer une modification. Faites appel à une revue humaine ou experte lorsque le critère d’acceptation ne peut pas se réduire à un score automatisé. Consignez les tests, le seuil, le réviseur et l’incertitude résiduelle.

Ce contrôle ne prouve pas l’exactitude. Il rend la décision de publication vérifiable et fournit une référence pour détecter les régressions après le déploiement.

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 les prompts admissibles à l’expérimentation en ligne, une comparaison progressive avec la version actuelle peut fournir des signaux réels au-delà des évaluations hors ligne. N’utilisez pas le trafic réel comme premier test de sécurité et n’exposez pas des personnes à une variante nettement plus risquée uniquement pour recueillir des données.

Schéma illustratif, pas une répartition par défaut :

• 95 % du trafic utilise le prompt en production v3.
• 5 % reçoit la nouvelle version candidate v4.
• Maintenez l’accès au modèle, les autorisations d’outils et les limites d’action dans la frontière de production approuvée.
• Mesurez la réussite de la tâche, les erreurs de sécurité et de politique, les retours utilisateur, les métriques en aval et les évaluations revues sur le trafic admissible.
• Définissez avant le démarrage l’échantillon minimum, les conditions d’arrêt, le responsable et un retour en arrière en une étape.
• Après des preuves suffisantes, décidez d’étendre, de réviser ou d’arrêter le candidat.

Les mécanismes de livraison comprennent les indicateurs de fonctionnalités internes, la configuration de déploiement, un registre de prompts approuvé ou le 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.
• Les expériences simultanées peuvent interagir et brouiller l’attribution ; contrôlez délibérément les chevauchements.
• Tenez compte des obligations d’information, de consentement, d’exclusion et de revue propres au produit, à la population et à la juridiction. Les actions à fort impact ou irréversibles exigent généralement une approbation et une réversibilité plus fortes qu’une simple répartition du trafic.

Observabilité des prompts

Définissez une télémétrie respectueuse de la vie privée pour chaque flux de production. Pour les appels qui affectent des résultats importants, conservez suffisamment des éléments suivants pour identifier le comportement déployé et reconstituer les échecs :

• 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).

L’objectif est de déterminer quelle version a été exécutée, quelles preuves autorisées elle a reçues, quelle sortie validée elle a produite, quels outils ou politiques sont intervenus et ce qui s’est passé en aval. Ne journalisez pas le raisonnement caché à la place de ces faits.

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.

Définissez la fréquence de revue et la méthode d’échantillonnage selon le volume, le risque, le rythme des changements, les incidents et les contraintes juridiques. Examinez des traces expurgées ou autrement approuvées, incluez les cas limites connus et réintégrez les échecs confirmés aux évaluations. Un échantillon hebdomadaire peut convenir à un flux et être inadapté ou insuffisant pour un autre.

Antipratique de conception des prompts

Voici les pratiques à éviter :

Antipratique 1 : un prompt polyvalent sans responsable. Un long prompt système réunissant des fonctionnalités, politiques, exemples et hypothèses d’exécution sans rapport peut être difficile à revoir, évaluer et restaurer. La longueur seule n’est pas le défaut ; la complexité non mesurée l’est.

Solution : séparez les composants selon la responsabilité et la limite de changement lorsque c’est utile, supprimez les instructions dupliquées ou obsolètes et comparez la conception révisée sur des évaluations représentatives.

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 et difficile à lire. La concaténation rend aussi les limites entre instructions et données difficiles à examiner, mais placer les mêmes valeurs dans un modèle ne neutralise pas les instructions malveillantes.

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 : ajoutez une couverture d’évaluation proportionnée au risque pour les comportements importants, notamment les échecs et les escalades.

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

Vous êtes l’assistant de John, un client premium inscrit en 2023, qui vit à Tallinn et possède 47 tickets ouverts.

Le préfixe d’instructions réutilisable change à chaque appel, ce qui peut réduire la réutilisation du cache et masquer la distinction entre politique et données client.

Solution : transportez les données dynamiques dans le mécanisme d’entrée ou de contexte du fournisseur, avec provenance, autorisation et minimisation. Ne déduisez pas la confiance du rôle du message.

Antipratique 7 : instructions enfouies au milieu du prompt.

Aidez l’utilisateur dans sa demande. Soyez poli. Formatez la sortie en JSON. N’utilisez pas Markdown. La demande concerne les tarifs : citez donc les chiffres avec prudence. La sortie doit comporter 1-2 phrases. Aidez maintenant l’utilisateur.

Les exigences critiques sont plus difficiles à repérer pour un réviseur et peuvent entrer en conflit avec le texte voisin.

Solution : regroupez les instructions critiques dans un bloc clairement libellé, énoncez chaque règle une seule fois et vérifiez que le modèle retenu les suit dans des contextes longs et adversariaux représentatifs.

Schémas adaptés aux fonctionnalités courantes

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

Classification

Tâche : classez le texte suivant dans l’une de ces catégories :
- billing : paiement, remboursement, abonnement
- technical : bug, erreur, problème d’intégration
- account : connexion, mot de passe, modification du profil
- feature_request : demandes de nouvelles fonctionnalités
- complaint : insatisfaction générale sans problème précis donnant lieu à une action

Produisez un objet JSON : {"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}

Texte à classer :
{text}

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

Extraction

Tâche : extrayez des données structurées du document ci-dessous.

Schéma :
- vendor_name : entreprise ayant émis la facture
- invoice_number : tel qu’imprimé sur le document
- date : format ISO 8601
- line_items : tableau de {description, quantity, unit_price, total}
- subtotal, tax, total : nombres

Règles :
- Si un champ est absent, utiliser null
- Les nombres doivent être des valeurs numériques et non des chaînes
- Dans les cas ambigus, définir "needs_review": true et fournir une explication

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

Tâche : rédigez un contenu au format {format} sur le thème {topic}, destiné à {audience}.

Style :
- {Specific style trait 1}
- {Specific style trait 2}
- À éviter : {anti-pattern 1}, {anti-pattern 2}

Contraintes :
- Longueur : {N} mots
- Inclure : {required elements}
- Exclure : {forbidden elements}

Référence de ton :
[Provide a sample of the desired voice]

Sortie : uniquement le contenu au format {format}, sans préambule ni post-scriptum.

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

Boucle agent

Vous avez accès aux outils suivants :
{tool_descriptions}

À chaque tour :
1. Déterminez ce que vous devez faire.
2. Décidez si vous avez besoin d’un outil. Si oui, appelez-le.
3. Après avoir observé le résultat, déterminez si vous avez besoin d’autres outils ou si vous pouvez répondre.
4. Lorsque vous disposez de suffisamment d’informations, produisez la réponse finale.

Contraintes :
- 5 appels d’outils au maximum par demande.
- Si vous ne pouvez pas terminer après 5 appels, expliquez ce qui manque.
- N’inventez jamais de noms d’outils ni d’arguments.
- Vérifiez les résultats des outils avant d’agir en conséquence.

Demande de l’utilisateur :
{user_query}

Principes : procédure d’utilisation des outils par étapes, budget d’appels, validation explicite et gestion limitée des échecs.

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 avec validation par étapes

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

Étape 1 : Fondations.

• Recenser les prompts qui ont une incidence significative sur le comportement ainsi que le code qui les construit.
• Définir le modèle d’autorité des instructions, la frontière des données d’exécution, les responsables et la manière de transposer la conception chez chaque fournisseur.
• Choisir une source de vérité gouvernée et une méthode de création de prompts à partir de modèles adaptée au processus de mise en production.
• Mettre en place une télémétrie respectueuse de la vie privée qui identifie la version déployée et le résultat sans conserver de contenu sensible superflu.

Étape 2 : Évaluation.

• Créer d’abord des ensembles d’évaluation pour les prompts présentant le plus de risques et le plus fort volume.
• Mener des évaluations représentatives lors de modifications substantielles des prompts, avec une revue par des spécialistes qualifiés du domaine lorsque c’est nécessaire.
• Intégrer les contrôles automatisés stables à la CI et garder visibles dans le compte rendu de revue les décisions d’acceptation qui ne peuvent pas être automatisées.

Étape 3 : Opérations.

• Mettre en place la gestion des versions de prompts dans le dépôt, le registre ou le service retenu.
• Ajouter un mécanisme de déploiement progressif et d’arrêt ; ne recourir aux tests A/B que pour les workflows qui s’y prêtent.
• Mettre en place le suivi de la qualité, de la sécurité, du respect des politiques, de la latence, du coût et des signaux en aval dont le workflow a besoin.
• Établir un processus de revue pour les changements de prompts.

Ne promettez pas ce résultat selon un calendrier. Ne terminez la séquence que lorsque les tests montrent que l’inventaire des prompts est complet, que les changements critiques sont versionnés et soumis à des contrôles, que la restauration fonctionne, que la télémétrie identifie la version déployée et que les responsables peuvent répéter une réponse à incident.

Les prompts comme infrastructure

Les prompts en production peuvent être stockés sous forme de chaînes de caractères, mais ils fonctionnent comme des composants système versionnés, entourés de contrôles portant sur l’assemblage, l’évaluation, la mise en production, l’accès et l’observabilité.

Une hiérarchie d’instructions définit l’autorité ; elle ne sécurise ni les données d’exécution ni les actions des outils. Le recours à des modèles peut réduire les erreurs d’assemblage, mais n’empêche pas l’injection de prompt. Une source de vérité gouvernée fournit un historique des versions. Des évaluations proportionnées au risque éclairent les décisions de mise en production, tandis que la télémétrie vérifie si le comportement attendu se maintient en dehors de l’ensemble d’évaluation.

La rigueur requise dépend du risque et du périmètre, mais tout contrôle omis doit faire l’objet d’une justification consignée. Les affirmations publiées doivent présenter les preuves de versionnement, d’évaluation, de déploiement progressif, de restauration et de télémétrie effectivement mises en œuvre.

La contrôlabilité recherchée reste une hypothèse tant que les évaluations et la télémétrie de production ne montrent pas que le modèle, la version du prompt, le chemin des données, les outils et les politiques retenus se comportent dans les limites des seuils d’acceptation. Conservez ces preuves avec la version mise en production, analysez les échecs par version et veillez à ce que la restauration reste opérationnelle.

Commencez par l’architecture minimale qui explicite la responsabilité, l’autorité, la gestion des données, l’évaluation, le déploiement, la restauration et les preuves.