Écrire un prompt système qui tient six mois

Un prompt système est l’ensemble des instructions permanentes envoyées au modèle avant chaque échange, et il faut le traiter comme du code parce qu’il influence durablement le comportement attendu du système. Il fixe le rôle, les règles, le format de sortie et les limites, quelle que soit la question posée ensuite par l’utilisateur.

La comparaison avec le code concerne sa maintenance : historique, revue et tests. Une instruction en langage naturel ne garantit pas une exécution déterministe. L’annonce de GPT-4 du 14 mars 2023 décrit le rôle du message système tout en soulignant que le modèle reste imparfait.

Pourtant il vit trop souvent dans un champ de configuration, sans historique, modifié directement en production par la dernière personne qui a eu une idée. C’est la principale cause de régression silencieuse que j’observe.

Les six mois du titre sont un horizon de maintenance, pas une durée garantie. Ce qui aide un prompt à tenir est l’organisation qui l’entoure : un historique, un jeu de tests et une discipline de modification.

Je maintiens un prompt système avec un historique, des changements isolés, des limites explicites et une séparation entre règles stables et données métier variables.

• Il vit dans le dépôt, versionné avec le reste. Toute modification passe par une revue, comme une ligne de code.
• Une seule modification à la fois, mesurée sur le jeu de tests avant d’être conservée.
• Il énonce ce qu’il ne faut pas faire, explicitement : ne pas inventer de référence, ne pas répondre hors du corpus fourni, dire quand l’information manque.
• Il ne contient aucune donnée métier susceptible de changer : les seuils, les listes et les dates vont dans le contexte, pas dans le prompt.
• Il est court. Sa longueur doit servir la tâche. Je retire les répétitions et les correctifs contradictoires ; une tâche complexe peut exiger davantage de consignes.

Écrire un prompt système robuste suit six étapes : définir la tâche, poser les règles métier, interdire explicitement, fixer le format de sortie, autoriser le refus, puis mesurer sur un jeu de tests. L’ordre compte, parce que chaque étape s’appuie sur la précédente.

1. Définir la tâche en une phrase. Qui utilise le système, pour faire quoi, à partir de quels documents. Si la phrase ne tient pas, le périmètre est trop large.
2. Poser les règles métier stables. Celles qui ne changeront pas dans l’année : le ton, la langue, le public visé, les obligations de citation.
3. Écrire les interdits. Ne pas inventer de référence, ne pas répondre hors des documents fournis, ne pas donner d’avis juridique ou médical si ce n’est pas le rôle du système.
4. Fixer un format de sortie strict. Une structure attendue, des champs nommés, une longueur cible. Un format précis se vérifie automatiquement.
5. Autoriser explicitement le refus. Dire au modèle qu’il peut et doit signaler quand l’information manque.
6. Mesurer avant de figer. Lancer le jeu de tests, noter le résultat, et n’enregistrer la version qu’ensuite.

Les raisons pour lesquelles les premiers essais avec GPT-4 échouent tiennent souvent à l’absence des étapes 3 à 5 : le modèle n’a ni interdits, ni format, ni droit de ne pas savoir.

L’erreur qui coûte le plus cher dans un prompt système est de corriger un cas particulier en y ajoutant une instruction, parce que le correctif peut dégrader silencieusement des cas déjà correctement traités. Le bénéfice local ne suffit pas à établir le bilan du changement.

Personne ne le voit, parce que la vérification s’est arrêtée au cas qu’on voulait corriger. Répété sans revue, ce mécanisme peut produire un prompt illisible dont plus personne n’ose retirer une ligne.

La bonne réponse à un cas particulier peut se trouver ailleurs : dans le découpage du corpus, dans la récupération, ou dans l’acceptation que ce cas relève de l’humain. Certaines décisions ne se confient d’ailleurs à aucune instruction : c’est le sujet de ce qu’on ne délègue jamais à un modèle.

Autoriser le refus donne au système une issue attendue lorsque les informations manquent, mais cette consigne doit être vérifiée sur des cas documentés.

Autoriser explicitement le système à ne pas répondre. Je teste deux familles de cas : ceux qui doivent recevoir une réponse et ceux qui doivent être refusés. Une consigne seule ne prouve ni une baisse des erreurs ni une meilleure confiance. Le refus doit expliquer ce qui manque et orienter vers une action utile.

Un prompt système survit à un changement de modèle quand il énonce des règles métier claires et un format de sortie strict, plutôt que d’exploiter les particularités d’un modèle donné. Les formulations spécifiques à un fournisseur doivent être identifiées comme telles.

Une spécification claire offre une base de comparaison, sans garantir la portabilité. À chaque remplacement, je relance les cas de refus, de format et de réponse fondée sur les documents. Une lecture complémentaire détaille cette discipline dans migrer un agent sans régression.

Le choix d’un modèle n’est pas définitif. Le petit modèle change l’arbitrage régulièrement, et un prompt qui spécifie permet de comparer deux modèles sur le même jeu de tests sans tout réécrire.

Dans un prompt système, je sépare les instructions stables des éléments variables propres à la requête pour faciliter la lecture et la comparaison des versions : la consigne et les règles d’abord, les éléments propres à chaque requête ensuite. Cette discipline rend le prompt lisible et ses versions comparables.

Le découpage que je privilégie : consigne, règles, description des outils, exemples, puis seulement les extraits récupérés, l’historique et la question. Un élément variable glissé en tête, la date du jour, le nom de l’utilisateur, un identifiant de session, mélange ce qui relève de la spécification et ce qui relève de la requête, et rend chaque différence entre deux versions plus difficile à lire.

Cette séparation aide à comprendre ce qui a changé : les règles, les documents ou la question. Le lien suivant est conservé comme lecture complémentaire sur une évolution ultérieure, sans en tirer une propriété technique ni économique à la date de cet article : le contexte répété ne se paie qu’une fois.

On décide de retirer une règle d’un prompt système par la mesure : on la retire, on relance le jeu de tests, et si les cas pertinents restent satisfaisants, on peut envisager son retrait après une revue. Un prompt hérité contient des règles ajoutées après incident dont plus personne ne connaît la raison, et certaines se contredisent.

Le cas le plus fréquent est la contradiction : une règle demande de toujours citer la source, une autre demande d’être concis sans préciser la priorité. Le modèle arbitre comme il peut, de façon instable. Le protocole complet figure dans construire un jeu de tests en une journée.

La règle « si tu ne trouves pas l’information, cherche dans les documents connexes » peut masquer un problème de récupération et favoriser des réponses fondées sur des sources insuffisamment pertinentes. C’est le motif le plus dommageable que je rencontre.

Ce type de règle peut apparaître après un incident où le système n’avait pas trouvé. Elle traite alors le symptôme sans résoudre le défaut : le système risque de répondre sur une mauvaise base, ce qui est pire qu’un refus.

La correction est en amont, dans la chaîne de récupération, présentée dans la seule architecture qui tienne pour répondre sur des documents internes. Le diagnostic à mener figure dans reprendre un système d’IA construit par quelqu’un d’autre.

Le format à livrer est un prompt versionné, commenté règle par règle, avec la date et le motif de chaque ajout : c’est ce qui permet à la personne suivante de le modifier sans casser. Cela ressemble à du code, et c’en est.

Chaque règle porte trois informations en commentaire : la date, l’incident qui l’a produite, et le cas du jeu de tests qui la couvre. Une règle sans cas associé est signalée comme candidate au retrait.

Ce format a un effet inattendu sur la discipline de l’équipe : il devient gênant d’ajouter une règle sans ajouter le cas correspondant, ce qui aide à limiter l’accumulation. C’est le meilleur garde-fou que j’aie trouvé contre la croissance silencieuse d’un prompt, et il rejoint la logique de la dette technique d’un système d’IA. Cette discipline s’enseigne : elle fait partie des fondamentaux abordés en formation IA.

Les erreurs qui font dériver un prompt système sont la modification directe en production, l’empilement de correctifs, les données métier codées en dur et l’absence de droit au refus. Toutes produisent le même résultat : un prompt que personne ne comprend plus.

• Modifier en production. Sans revue ni historique, impossible de savoir quelle modification a causé la régression.
• Empiler les correctifs. Chaque incident ajoute une ligne, aucune n’est jamais retirée.
• Coder en dur des seuils ou des dates. Ils changent, le prompt non, et le système applique une règle périmée.
• Exiger une réponse à tout prix. Une consigne de réponse systématique peut encourager une affirmation sans fondement.
• Changer plusieurs choses à la fois. Quand le score bouge, on ne sait plus laquelle en est la cause.