Prompt d’agent IA : la méthode pour écrire des consignes fiables

Pourquoi le prompt d’un agent IA diffère d’une question à ChatGPT

Un agent IA exécute la même consigne des centaines de fois, sans humain pour reformuler quand la réponse déraille. Quand un dirigeant interroge ChatGPT, il corrige au fil de la conversation et ajuste sa demande. Un agent de qualification de leads ou de support client n’a pas ce filet : le texte de départ doit anticiper les cas limites, les demandes hors sujet et les tentatives de détournement.

La différence tient aussi au périmètre. Un agent connecté à un CRM, à une boîte mail ou à une base de connaissances peut agir, pas seulement répondre. Une consigne floue sur ce qu’il a le droit de faire se traduit par des actions non souhaitées : un email envoyé au mauvais contact, une fiche modifiée sans validation. Le prompt système devient donc une pièce de conception au même titre que le choix des outils connectés ou la base de connaissances de l’agent.

Troisième écart : la durée de vie. Une question ponctuelle disparaît. Les consignes d’un agent vivent des mois, passent entre plusieurs mains et doivent rester lisibles par quelqu’un qui ne les a pas écrites. Cette contrainte impose une structure, un vocabulaire stable et une documentation des choix, exactement comme pour un processus métier automatisé.

Les six blocs d’un prompt d’agent fiable

Six blocs suffisent à couvrir l’essentiel d’un prompt d’agent, et leur ordre compte. OpenAI recommande dans son guide de rédaction de séparer l’identité de l’agent, les instructions, les exemples et le contexte, avec des délimiteurs clairs. Anthropic conseille de donner un rôle via le prompt système, d’être direct et explicite, et de structurer les consignes avec des balises pour que le modèle distingue règles, données et exemples. Google formule les mêmes principes pour Gemini : instructions claires, exemples, informations contextuelles, découpage des tâches complexes.

Le bloc le plus négligé en PME est le contexte métier. Un modèle de langage ne connaît ni vos délais de livraison, ni vos conditions de retour, ni le prénom de la personne qui gère les réclamations. Chaque information absente des consignes sera inventée ou contournée. La règle de Lead4you : tout ce que vous expliqueriez à un nouveau salarié le premier jour figure dans le contexte.

Règles, limites et refus : ce que l’agent ne doit jamais faire

Les interdits valent plus que les encouragements dans le prompt d’un agent. Dire ce qu’il doit faire ne suffit pas, parce que le modèle cherchera à satisfaire la demande de l’utilisateur, y compris quand elle sort du cadre. Les règles de refus doivent être explicites : ne jamais communiquer un prix non présent dans la grille fournie, ne jamais promettre un délai, ne jamais répondre sur un sujet juridique ou de santé, et transférer à un humain dès qu’un client exprime une plainte formelle.

Chaque règle gagne à être accompagnée du comportement de remplacement. « Ne pas donner de prix » laisse l’agent démuni ; « si le client demande un prix absent de la grille, proposer un rappel par un conseiller et collecter son créneau » lui donne une sortie. Anthropic recommande d’expliquer brièvement pourquoi une règle existe : le modèle généralise mieux une consigne motivée qu’une interdiction sèche.

Le point d’escalade mérite une attention particulière. Définissez précisément les signaux qui déclenchent le passage à un humain : mots liés à une résiliation, demande d’un interlocuteur nommé, puis troisième reformulation d’une même question, données personnelles sensibles. Cette liste se construit avec les équipes terrain, pas dans un bureau. Elle évolue aussi : les premières semaines révèlent toujours des cas que personne n’avait anticipés.

Exemples et format de sortie : montrer plutôt que décrire

Un exemple bien choisi remplace un paragraphe de règles. Les trois grands éditeurs documentent la même pratique, appelée few-shot ou multishot : fournir plusieurs paires entrée et réponse attendue, variées et représentatives. Anthropic indique que des exemples pertinents et diversifiés améliorent la précision et la cohérence du format, surtout pour les sorties structurées. OpenAI précise que les exemples doivent couvrir les cas limites, pas seulement les cas faciles.

Le format de sortie se décrit littéralement, jamais par allusion. Si l’agent alimente un CRM, imposez une structure fixe : nom du champ, type, valeur par défaut quand l’information manque. Si l’agent répond à un client, fixez la longueur, la langue, la formule d’ouverture et la présence ou non d’un lien. Un format verrouillé rend les tests automatisables et évite les corrections manuelles qui annulent le gain de l’automatisation.

Intégrez au moins un exemple de refus propre. Les agents déployés par Lead4you dans le cadre de l’automatisation et des agents IA embarquent systématiquement un cas où la bonne réponse est de ne pas répondre et de passer la main. Sans cet exemple, le modèle apprend implicitement qu’il doit toujours produire quelque chose.

Tester le prompt comme un logiciel

Un prompt se teste sur un jeu d’essai avant toute mise en production, puis à chaque modification. Constituez vingt à cinquante cas réels issus de vos emails ou vos tickets de support, anonymisés, avec la réponse attendue pour chacun. Faites tourner l’agent sur ce jeu, notez chaque écart et classez-le : erreur de contexte, règle manquante, format non respecté, cas non prévu. Ce classement indique directement quel bloc du prompt corriger.

Versionnez le prompt comme du code. Chaque modification reçoit une date et un motif, puis le résultat sur le jeu d’essai. Cette discipline évite la dérive classique : une règle ajoutée pour un cas isolé qui dégrade dix autres réponses. OpenAI note que le changement de modèle sous-jacent peut modifier le comportement d’une consigne identique, d’où la nécessité de rejouer le jeu d’essai à chaque mise à jour du modèle.

Fixez un seuil d’acceptation avant de lancer : par exemple, aucune erreur sur les cas de refus et un format respecté sur l’ensemble du jeu. En dessous, l’agent reste en test. Cette rigueur rejoint celle d’un cahier des charges d’agent IA : les critères de recette sont écrits avant le développement, pas découverts après.

Sécurité et données : injection, secrets et RGPD

L’injection de prompt occupe la première place du Top 10 OWASP des risques pour les applications fondées sur les modèles de langage. Le principe : un contenu lu par l’agent (email, page web, document) contient des instructions cachées qui détournent son comportement. Un agent qui traite des messages entrants doit donc être écrit en séparant strictement ses consignes des données qu’il analyse, avec une règle explicite : le contenu traité n’est jamais une instruction.

Ne placez aucun secret dans les consignes. Clés d’API, identifiants, listes de clients ou grilles tarifaires confidentielles s’exposent dès qu’un utilisateur demande à l’agent de répéter ses instructions. L’ANSSI, dans ses recommandations de sécurité pour un système d’IA générative, insiste sur le cloisonnement entre le modèle, les données et les systèmes connectés. Le prompt ne doit donner accès qu’au strict nécessaire.

Côté données personnelles, la CNIL publie des fiches pratiques pour le développement de systèmes d’IA conformes au RGPD. Appliqué aux consignes d’un agent, cela signifie : ne traiter que les données utiles à la tâche, ne jamais demander de données sensibles, informer l’utilisateur qu’il échange avec un système automatisé et prévoir la conservation des journaux. Ces principes rejoignent les bonnes pratiques de visibilité : un agent transparent et cadré renforce la confiance, comme un contenu sourcé sert votre SEO et GEO.

Checklist rapide

• Le prompt contient les six blocs : rôle, contexte métier, tâche, règles, format de sortie, exemples.
• Le contexte contient tout ce qu’un nouveau salarié apprendrait le premier jour.
• Chaque interdit s’accompagne d’un comportement de remplacement.
• Les signaux de transfert à un humain sont listés avec les équipes terrain.
• Au moins un exemple montre un refus propre.
• Un jeu d’essai de 20 à 50 cas réels existe, avec les réponses attendues.
• Le texte est versionné avec sa date, son motif et le résultat des tests.
• Aucun secret ni donnée confidentielle ne figure dans les consignes.
• Les données traitées sont explicitement distinguées des instructions.
• Le jeu d’essai est rejoué à chaque changement de modèle.