« C'était dans le prompt » n'est pas une réponse à « pourquoi il a fait ça ? »
La conversation se répète dans toutes les boîtes qui mettent un agent en production. L'agent fait un truc bizarre — il promet un délai qui n'existe pas, il répond à côté, il invente une procédure — et quelqu'un demande ce qui s'est passé. La réponse est toujours la même : « c'était dans le prompt ». Et arrivent les trois questions gênantes. Dans quelle version du prompt ? Qui a écrit cette ligne ? Quelqu'un a testé ce qui se passe si on l'enlève ?
Il n'y a presque jamais de réponse, et ce n'est pas de la négligence : c'est que le mot prompt pousse à traiter le texte comme un message. Un message, on l'écrit une fois, on l'envoie et on l'oublie. Or ce qui gouverne un agent en production n'est pas un message : c'est le document qui définit ce qu'il fait, ce qu'il ne touche pas et qui il appelle quand il bloque. Ça porte un autre nom dans n'importe quelle organisation : une fiche de poste. Et une fiche de poste a un propriétaire, une version et une date de révision.
Ce n'est pas une métaphore de confort. La documentation d'Anthropic recommande de penser au modèle comme à « un employé brillant mais nouveau, qui ne connaît ni tes normes ni tes processus », et propose une règle d'or qui marche aussi bien avec des humains : montre tes instructions à un collègue qui a peu de contexte et demande-lui de les suivre ; s'il s'y perd, le modèle aussi. Source : Prompting best practices, Claude Platform Docs, consulté le 11 septembre 2026.
Ce guide parle d'écrire ce document. Ce n'est pas un cours de prompting ni un modèle magique à copier : c'est la structure minimale qui tient en production, l'endroit où presque tout le monde se trompe, et l'habitude qui sépare itérer de prier.
Les six choses qui doivent être écrites
Peu importe la plateforme, le modèle et le cas d'usage. S'il manque un de ces six blocs, l'agent le remplira tout seul, et ce qu'il remplira, ce n'est pas toi qui l'as décidé. Dans l'architecture décrite par OpenAI, un agent, c'est trois pièces — modèle, outils et instructions — et les instructions sont les « directives et garde-fous explicites qui définissent son comportement ». Explicites est le mot. Source : A practical guide to building agents, OpenAI, consulté le 11 septembre 2026.
| Bloc | Ce qu’il répond | Ce qui arrive s’il manque |
|---|---|---|
| Identité et canal | Qui il est, à qui il parle et par où | Le ton et le tutoiement changent selon les jours |
| Périmètre | Ce dont il s'occupe et ce dont il ne s'occupe pas | Il répond à tout, y compris à ce qu'il ne sait pas |
| Ce qu’il peut décider | Où finit proposer et où commence exécuter | Il exécute des choses que personne n'a autorisées |
| Format de sortie | Sous quelle forme il rend le résultat | Le système de destination le rejette en silence |
| Ce qu’il fait quand il ne sait pas | La sortie honnête par défaut | Il comble le trou avec quelque chose de vraisemblable |
| Quand il escalade | Le seuil exact qui appelle une personne | Personne ne l'apprend avant la réclamation |
Regarde la colonne de droite : aucune de ces pannes ne se manifeste comme une erreur. Toutes se manifestent comme du comportement, ce qui est bien plus cher à détecter. Un agent qui tombe te prévient ; un agent à qui il manque le bloc de périmètre travaille tranquillement pendant des semaines en répondant à des choses qui n'étaient pas les siennes.
L'erreur des règles au négatif (et quoi mettre à la place)
Voici la correction la plus utile de tout le guide, et elle va contre ce que fait presque tout le monde. Quand un agent se comporte mal, le réflexe est d'ajouter une interdiction : « ne promets jamais de délais », « pas d'emojis », « ne donne jamais de prix ». La liste des non grossit semaine après semaine jusqu'à devenir un règlement, et le comportement continue d'apparaître.
La documentation d'Anthropic est explicite là-dessus : dis au modèle ce qu'il doit faire, pas ce qu'il ne doit pas faire. Son exemple pour contrôler le format est exactement celui-ci : au lieu de « n'utilise pas de markdown dans ta réponse », écris « ta réponse doit être composée de paragraphes de prose fluide ». Et quand l'interdiction est inévitable, le même guide recommande d'y joindre la raison : « n'utilise JAMAIS de points de suspension » rend moins bien que « ta réponse sera lue à voix haute par un moteur de synthèse vocale, donc n'utilise jamais de points de suspension, il ne saura pas les prononcer ». Le modèle généralise à partir de l'explication ; de l'interdiction sèche, non. Source : Prompting best practices, Claude Platform Docs, consulté le 11 septembre 2026.
La traduction opérationnelle est simple et elle demande du travail : chaque fois que tu vas écrire un « ne pas », arrête-toi et réponds à deux questions. Qu'est-ce que je veux qu'il fasse à la place ? et pourquoi ? Ce qui en sort, c'est la règle à écrire.
| Ce qu’on écrit | Ce qui marche |
|---|---|
| « Ne promets jamais de délais de livraison » | « Quand on te demande un délai, donne celui que renvoie le système de commandes. S'il ne renvoie rien, dis que tu vas confirmer et ouvre une demande, parce qu'un délai mal donné devient une réclamation. » |
| « N’invente pas d’information » | « Réponds uniquement avec ce que tu trouves dans la documentation. Si ce n'est pas là, dis-le avec ces mots et propose de transmettre la question à une personne. » |
| « Ne donne pas de remises » | « Les remises sont validées par le responsable commercial. Si un client en demande une, enregistre la demande avec le montant et préviens les ventes ; ne confirme rien toi-même. » |
Il y a une exception à connaître : les contraintes de sécurité dures — ce qui ne doit jamais arriver, en aucune circonstance — s'écrivent bien au négatif et sans nuance, et il vaut mieux les répéter au début et à la fin du document. Mais ça fait deux ou trois lignes, pas quarante. Le reste de ton règlement de non est, presque toujours, une spécification positive que personne n'a pris le temps d'écrire.
Ce qu'il décide, ce qu'il propose et ce qu'il ne touche pas
Le bloc qui fait économiser le plus est le plus court. Prends chaque action que l'agent peut exécuter et range-la dans trois colonnes : il l'exécute seul, il la laisse proposée pour que quelqu'un confirme, ou il n'y touche pas. Et écris-le avec des seuils chiffrés, pas des adjectifs : « montants élevés » n'est pas un seuil, « au-dessus de 300 euros » si.
Pour décider dans quelle colonne va chaque action, le guide d'OpenAI propose de noter le risque de chaque outil — faible, moyen ou élevé — selon quatre facteurs : lecture seule ou écriture, réversibilité, permissions exigées et impact financier. C'est cette note qui déclenche la pause ou l'escalade, et c'est un critère bien plus défendable que l'intuition de la réunion du mardi. Source : A practical guide to building agents, OpenAI, consulté le 11 septembre 2026.
Ce bloc des instructions et les permissions techniques de l'agent sont deux choses différentes qui doivent dire la même chose. Les instructions disent ce qu'il doit faire ; les permissions déterminent ce qu'il peut faire. Si le document dit qu'il n'émet pas de remboursements mais que l'identifiant a la portée pour en émettre, la seule chose qui sépare ton entreprise d'un remboursement indu, c'est la bonne conduite du modèle, qui n'est pas un contrôle. Comment refermer cette pince, c'est dans quelles permissions donner à un agent IA, et la carte de l'autonomie à lâcher et dans quel ordre, dans les niveaux d'autonomie d'un agent.
Ce qu'il fait quand il ne sait pas, et quand il appelle une personne
Sans instruction explicite, le comportement par défaut face à un trou est de le combler avec quelque chose de plausible. Pas parce que le modèle ment, mais parce que personne ne lui a donné de meilleure sortie. La meilleure sortie s'écrit en une ligne et change le quotidien : « si la réponse n'est pas dans la documentation, dis-le avec ces mots, ne la déduis pas, et propose de transmettre la question à une personne ».
L'escalade est l'autre moitié. OpenAI la traite comme un mécanisme de sécurité de premier plan et décrit deux déclencheurs à copier tels quels : dépasser un seuil d'échecs — si l'agent n'a pas compris l'intention après N tentatives, il transfère — et les actions à haut risque, c'est-à-dire sensibles, irréversibles ou à fort impact ; les exemples donnés sont annuler des commandes, autoriser de gros remboursements et effectuer des paiements. Source : A practical guide to building agents, OpenAI, consulté le 11 septembre 2026.
Écris ces deux déclencheurs avec des chiffres et avec un destinataire. Pas « escalade quand c'est nécessaire », mais « après deux tentatives sans identifier la commande, passe la conversation au service client avec le résumé et l'historique ». La différence entre ces deux formulations, c'est la différence entre une escalade qui a lieu et une qui n'a pas lieu.
Une chose à la fois : l'habitude qui sépare itérer de prier
Presque tout le monde ajuste les instructions de la même façon : on repère un comportement bizarre, on réécrit quatre paragraphes, on teste deux cas à vue de nez et on met en ligne. Si ça s'améliore, on ne sait pas lequel des quatre changements a réglé le problème. Si ça empire, on ne sait pas lequel l'a cassé. Ce n'est pas itérer, c'est prier avec des étapes intermédiaires.
L'habitude qui transforme ça en ingénierie tient en trois règles. Une. Change une chose à la fois et laisse-la écrite : ce que tu as changé, pourquoi et ce que tu attendais. Deux. Garde l'avant et l'après des mêmes cas — les dix ou quinze qui représentent ton opération réelle, les bizarres compris — parce que sans l'avant tu n'as rien à comparer. Trois. Laisse la version précédente là où tu peux la récupérer en une minute, parce que le changement qui casse quelque chose ne le casse presque jamais pendant le test : il le casse le mardi suivant.
Ces trois règles sont manuelles et marchent dans un tableur, et c'est là qu'elles doivent commencer. Quand l'agent cesse d'être un agent et devient une flotte, le registre à la main ne tient plus et ça devient une fonction opérationnelle avec source unique de vérité, batterie de tests avant déploiement et retour arrière en une minute : c'est tester et versionner les prompts d'IA, et c'est un service, pas un conseil. Ce qui décide du saut, ce n'est pas la taille de l'équipe, c'est le nombre de personnes qui peuvent toucher le document.
Et un avertissement qui fait gagner des semaines : si l'agent échoue parce qu'il ne trouve pas l'information, le problème n'est pas dans les instructions et les réécrire n'y changera rien. Il est dans ce qu'il peut consulter — comment ça se monte et s'évalue, c'est dans entraîner un agent IA — ou dans ce qu'il devrait retenir d'une conversation à l'autre, qui est la mémoire d'un agent IA. Les trois se règlent différemment, et les confondre est la façon la plus courante de perdre un mois.
La fiche d'une page : qui la signe et quand elle a été revue
Termine le document par un en-tête de cinq champs. Ce n'est pas de la bureaucratie : c'est ce qui transforme un texte isolé en un artefact que quelqu'un entretient.
- Propriétaire. Une personne avec un nom, pas un service. Celle qui répond quand l'agent fait quelque chose de bizarre.
- Version et date. Un numéro qui monte et le jour où il est monté. Sans ça, tu ne peux pas dire ce qui tournait la semaine dernière.
- Ce qui a changé et pourquoi. Deux lignes par version. C'est le registre qui t'évite de refaire une expérience ratée dans six mois.
- Cas de test. Où vivent les dix ou quinze cas qui servent à vérifier chaque changement, et qui les met à jour.
- Prochaine révision. Une date. Les instructions périment quand la politique, le catalogue ou le système de destination changent, et personne ne prévient.
Si ton agent est déjà en production et que ce document n'existe pas, l'ordre est celui-ci : écris d'abord le bloc de ce qu'il peut décider et celui de quand il escalade, les deux qui ont de l'argent en face. Le reste peut attendre une semaine. Et le jour où quelqu'un redemande « pourquoi il a fait ça ? », tu pourras ouvrir un fichier, regarder une version et répondre.
Nous écrivons ce document avec le client en face et nous le laissons signé, versionné et avec ses cas de test : ça fait partie de monter des employés IA qui travaillent vraiment, dans la logique générale de créer un agent IA qui tient en production. On ne vend pas le prompt. On facture pour que n'importe qui dans ton équipe puisse lire ce que fait ton agent et pourquoi, sans demander à personne.