Écrire un prompt système qui tient six mois

Il détermine le comportement du système, il a des effets de bord, il casse quand on le modifie sans mesurer. Toutes les propriétés du code.

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.

Corriger un cas particulier en ajoutant une instruction au prompt système.

Le cas particulier est réglé, et deux cas généraux se dégradent, sans que personne ne le voie, parce que la vérification s'est arrêtée au cas qu'on voulait corriger. Répété dix fois sur six mois, ce mécanisme produit un prompt illisible dont plus personne n'ose retirer une ligne.

La bonne réponse à un cas particulier est presque toujours ailleurs : dans le découpage du corpus, dans la récupération, ou dans l'acceptation que ce cas relève de l'humain.

Un prompt écrit pour exploiter les particularités d'un modèle donné ne survit pas au suivant. Un prompt qui énonce des règles métier claires et un format de sortie strict s'y transpose presque sans retouche.

C'est la différence entre optimiser et spécifier. La première approche gagne quelques points sur le moment ; la seconde évite de tout refaire deux fois par an. Le sujet est développé dans migrer un agent sans régression.

Tout ce qui est stable doit être placé avant tout ce qui varie, sans exception, sous peine de payer plein tarif à chaque requête. Cette contrainte technique produit accessoirement un prompt mieux rangé.

Un seul élément variable en tête, la date du jour, le nom de l'utilisateur, un identifiant de session, casse le préfixe et annule toute réutilisation.

L'ordre qui fonctionne : consigne, règles, description des outils, exemples, puis seulement les extraits récupérés, l'historique et la question. Le mécanisme et son économie sont détaillés dans le contexte répété ne se paie qu'une fois.

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. Les retirer demande une mesure, pas une opinion.

La méthode : retirer une règle, relancer le jeu de tests, comparer le taux d'erreur. Si rien ne bouge, le retrait est acquis.

Le cas le plus fréquent est la contradiction, une règle demande de toujours citer la source, une autre ajoutée six mois plus tard demande d'être concis. 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.

« Si tu ne trouves pas l'information, cherche dans les documents connexes » est une instruction qui compense un problème de récupération et produit des réponses fondées sur des sources non pertinentes. C'est le motif le plus dommageable que je rencontre.

Ce type de règle apparaît toujours après un incident où le système n'avait pas trouvé. Elle traite le symptôme et aggrave la situation : le système répond désormais, mais mal, ce qui est pire qu'un refus.

La correction est en amont, dans la chaîne de récupération. Le diagnostic à mener figure dans reprendre un système d'IA construit par quelqu'un d'autre.

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 suffit à empêcher 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.