Rôles, personas et contraintes opératoires

Pourquoi ce chapitre compte

Un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire qui fonctionne une fois, dans une conversation isolée, ne suffit pas en contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire professionnel. Ce qui distingue un usage artisanal d'un usage industrialisé, c'est la capacité à fixer un cadre stable, reproductible d'un appel à l'autre : qui parle avec quelle autorité, sous quelle identité fonctionnelle, et dans quelles limites. Ce chapitre traite de trois leviers souvent confondus — le system prompt, le persona, les contraintes opératoires — et d'un comportement qu'on sous-estime trop souvent en le traitant comme un défaut à contourner plutôt qu'une fonctionnalité à concevoir : le refus.

Ces notions ne sont pas décoratives. Un system prompt mal conçu, un persona réduit à une étiquetteétiquetageIATravail consistant à associer à chaque exemple la réponse attendue. C'est presque toujours le poste le plus coûteux d'un projet d'apprentissage supervisé.Voir dans le glossaire, ou des contraintes non vérifiables produisent des résultats instables et coûteux à corriger une fois en production. À l'inverse, un cadre bien posé une seule fois se réutilise sur des centaines d'appels sans dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire notable.

System prompt vs user prompt : deux niveaux de contrôle

La plupart des interfaces de modèles de langage distinguent deux canaux d'instruction. Le system prompt définit le cadre général, stable, généralement invisible pour l'utilisateur final : qui le modèle incarne, quelles règles il doit suivre en toute circonstance, quelles limites ne sont jamais négociables au fil de la conversation. Le user prompt porte la demande spécifique du moment, celle qui change à chaque appel.

Cette séparation correspond à deux durées de vie différentes de l'information : ce qui doit rester vrai sur mille appels différents relève du system prompt ; ce qui ne vaut que pour l'appel en cours relève du user prompt. Mélanger les deux — remettre à chaque appel l'intégralité du cadrage dans le user prompt, ou glisser une instruction ponctuelle dans le system prompt — complique inutilement la maintenance d'un prompt destiné à être réutilisé.

Ce que fait, et ne fait pas, le system prompt

Le system prompt fixe l'identité fonctionnelle, le registre de langage, les sujets hors périmètre et les règles de sécurité applicables à toute la conversation. Il n'a pas vocation à contenir la tâche du jour : la mélanger avec le cadrage général rend le prompt plus difficile à faire évoluer, puisque toute modification de la tâche impose de retoucher un bloc censé rester stable.

Un system prompt bien rédigé augmente très fortement la probabilité que le modèle respecte le cadre fixé, mais il ne constitue pas une barrière technique infranchissable comparable à une validation de code. Un modèle reste un système probabiliste : sur un flux suffisamment large de requêtes, y compris adverses, des écarts résiduels sont possibles. Traiter le system prompt comme l'unique ligne de défense d'un système sensible est une erreur d'architecture, pas seulement de rédaction.

La hiérarchie d'autorité entre les instructions

Les modèles de langage professionnels sont entraînés à traiter le system prompt comme prioritaire sur le user prompt en cas de conflit direct. Si le system prompt interdit un comportement et que le user prompt demande explicitement ce même comportement, le modèle est censé faire prévaloir le system prompt. Cette hiérarchie est une tendance statistique renforcée à l'entraînement, pas une règle logique appliquée avec une certitude absolue.

Un contenu externe injecté dans le contexte — un document fourni par l'utilisateur, une page web récupérée, un message d'un tiers — peut contenir des instructions qui tentent de se faire passer pour des règles de niveau système, ou qui cherchent à faire oublier les règles réellement définies en amont. Ce risque, appelé injection de promptInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire, ne se corrige pas uniquement en écrivant un system prompt plus ferme ; il appelle des garde-fous complémentaires, comme le filtrage du contenu externe avant de l'injecter dans le contexte, ou la limitation des actions que le modèle peut déclencher sans confirmation.

Construire un persona opérationnel

Donner un rôle au modèle — « tu es un expert en droit du travail » — est un réflexe courant, mais insuffisant à lui seul. Un persona opérationnel va plus loin : il définit non seulement une identité, mais un comportement observable et vérifiable dans les réponses produites.

Les composants d'un persona utile

Un persona qui influence réellement le comportement du modèle rassemble plusieurs éléments, distincts d'une simple étiquette :

• Identité fonctionnelle — le rôle exact tenu, formulé de façon spécifique plutôt que générique.
• Périmètre de compétence — ce que ce rôle couvre, et ce qu'il ne couvre explicitement pas.
• Ton et registre — le niveau de langage, la formalité, la présence ou l'absence d'humour ou d'emphase.
• Rapport à l'incertitude — la conduite à tenir lorsque l'information manque ou que la demande sort du périmètre défini.
• Limites non négociables — les sujets ou actions que ce persona refuse de traiter, quelle que soit l'insistance de la demande.

Un persona qui ne définit que l'identité fonctionnelle, sans les quatre autres éléments, se comporte de façon nettement moins stable dès que la conversation s'éloigne du cas d'usage nominal prévu au départ.

Persona opérationnel versus étiquette de rôle

Étiquette de rôle : « Tu es un assistant de support technique. » Cette formulation oriente vaguement le registre, mais ne précise ni le périmètre de produits couverts, ni la conduite à tenir face à une question hors sujet, ni le niveau de détail technique attendu. Le comportement du modèle reste largement déterminé par des régularités générales issues de l'entraînement, pas par le contexte réel de l'entreprise.

Persona opérationnel : « Tu es l'assistant de support technique de niveau 1 pour le logiciel Facture Pro. Tu couvres uniquement les questions d'installation, de connexion et de facturation de ce logiciel. Pour toute question portant sur un autre produit, ou sur un sujet juridique ou comptable, indique que la question sort de ton périmètre et invite à contacter le support concerné, sans tenter d'y répondre toi-même. Utilise un vocabulaire simple, sans jargon informatique non expliqué. Si l'information nécessaire pour répondre n'est pas fournie dans le contexte, demande-la avant de formuler une hypothèse. » Cette seconde formulation fixe un comportement observable : on peut vérifier, réponse après réponse, si le périmètre est respecté, si le ton reste conforme, et si le modèle demande effectivement les informations manquantes plutôt que de les deviner.

La différence entre les deux tient à la vérifiabilité. Un persona opérationnel permet de constater, en lisant une réponse, s'il a été respecté ou non. Une étiquette de rôle seule ne le permet pas, car aucun comportement précis n'en découle mécaniquement.

Le ton comme paramètre technique

Le ton est souvent traité comme un détail esthétique, secondaire par rapport au contenu. C'est une erreur en contexte professionnel : le ton influence directement la longueur des réponses, la tendance à nuancer ou à trancher, et la probabilité que le modèle ajoute des avertissements superflus ou, à l'inverse, omette une réserve nécessaire.

Décrire un ton par des adjectifs seuls — « professionnel », « accessible », « rassurant » — laisse une marge d'interprétation large, chaque adjectif recouvrant des registres très différents selon le contexte. Un ton défini par des descripteurs concrets et par un exemple contrastif produit un résultat nettement plus stable.

Plutôt que d'écrire « adopte un ton professionnel », précisez ce que ce ton exclut concrètement : « Réponds sur un ton neutre et direct. Évite les formules d'enthousiasme ("excellente question", "je suis ravi de vous aider") et les tournures hésitantes ("il se pourrait que", "peut-être que"). Formule les affirmations certaines sans détour, et signale explicitement les affirmations incertaines par une phrase dédiée plutôt que par une nuance diluée dans le texte. » Cette formulation est vérifiable : on peut relire une réponse et constater la présence ou l'absence de ces formulations précises.

Contraintes opératoires : cadrer le périmètre

Les contraintes fixent les limites dans lesquelles une réponse doit s'inscrire. Elles se répartissent en trois familles, qu'il est utile de distinguer pour ne pas en oublier une par inadvertance.

Contraintes de contenu

Elles déterminent quels sujets, quelles sources ou quels types d'information peuvent figurer dans la réponse. Exemple : « Ne mentionne aucun tarif ou engagement contractuel qui ne figure pas explicitement dans le document fourni. »

Contraintes de format

Elles déterminent la structure de sortie attendue : longueur, présence ou absence de sections, structure de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire. Exemple : « Réponds en trois paragraphes maximum, sans liste à puces. »

Contraintes de processus

Elles déterminent la conduite à tenir avant de produire une réponse : quand demander une clarification, quand citer une source, quand refuser de répondre. Cette famille est la plus souvent négligée, alors qu'elle conditionne directement la fiabilité du système en production.

Le refus utile : une fonctionnalité, pas un bug

Un modèle qui refuse de répondre est souvent perçu comme un système en défaut. En contexte professionnel, c'est parfois l'inverse : un refus explicite, formulé au bon moment, protège contre un risque plus coûteux qu'une réponse manquante — une réponse fausse produite avec assurance, ou un avis donné hors du champ de compétence défini pour le système.

Le refus devient utile lorsqu'il est conçu délibérément. Trois situations l'appellent typiquement : une question hors périmètre de compétence, une demande nécessitant une information absente du contexte fourni, et une demande qui requiert un jugement humain — juridique, médical, financier engageant — que le système n'est pas habilité à rendre.

Un modèle qui invente une réponse plutôt que de reconnaître son incertitude produit le résultat le plus coûteux à détecter. Un modèle qui refuse sans expliquer pourquoi frustre l'utilisateur et l'empêche de reformuler efficacement. Un refus utile explique la raison du refus et, quand c'est possible, indique la voie alternative — reformuler la demande, fournir l'information manquante, s'adresser à la bonne personne ou au bon service.

Concevoir des refus qui aident

Un refus bien conçu suit une structure simple : nommer précisément ce qui empêche de répondre, plutôt qu'un refus générique ; indiquer, si possible, ce qui permettrait de répondre — une donnée manquante, une reformulation, un changement de destinataire ; et éviter de refuser un sous-ensemble de la demande qui, lui, aurait pu être traité sans risque. Un refus global sur une demande en partie légitime est presque aussi coûteux, à l'échelle d'un déploiement, qu'une réponse hallucinée : il pousse l'utilisateur à contourner le système ou à cesser de l'utiliser.

Tableau récapitulatif

Pièges fréquents

Certaines erreurs reviennent régulièrement, y compris dans des déploiements déjà en production :

• Confondre étiquette de rôle et persona opérationnel. Un rôle sans périmètre, sans ton défini et sans conduite face à l'incertitude reste soumis aux régularités générales du modèle, pas au contexte réel de l'entreprise.
• Placer une instruction ponctuelle dans le system prompt. Cela le rend plus difficile à faire évoluer sans affecter tous les usages qui en dépendent.
• Traiter le system prompt comme une barrière de sécurité absolue. Il réduit fortement, mais n'élimine pas, le risque de contournement par injection de prompt ; des garde-fous complémentaires restent nécessaires pour les usages sensibles.
• Ne jamais préciser la conduite à tenir en cas de refus. Sans règle explicite, le modèle applique ses réflexes par défaut, peu prévisibles d'un appel à l'autre.
• Confondre concision du ton et absence de contrainte de format. Un ton sobre n'implique pas une réponse courte ou structurée ; ces deux paramètres se fixent séparément.

Checklist opérationnelle

Avant de déployer un prompt destiné à un usage récurrent, vérifiez chacun des points suivants :

• Le system prompt contient-il uniquement ce qui doit rester vrai sur tous les appels, sans mélange avec la tâche du jour ?
• Le persona précise-t-il un périmètre de compétence, et pas seulement une identité fonctionnelle ?
• Le ton est-il défini par des descripteurs concrets et, idéalement, un exemple contrastif, plutôt que par des adjectifs seuls ?
• Les contraintes de contenu, de format et de processus sont-elles chacune envisagées séparément ?
• La conduite à tenir en cas d'information manquante ou de demande hors périmètre est-elle explicitement définie ?
• Un refus, s'il survient, explique-t-il sa raison et, si possible, une voie alternative ?

Reprenez un system prompt que vous utilisez actuellement et testez-le avec une demande volontairement hors périmètre. Si la réponse obtenue tente de traiter la demande plutôt que de la refuser explicitement, la conduite de refus n'est probablement pas assez précisément définie dans vos contraintes de processus.

Ce qu'il faut retenir

Séparer ce qui doit rester stable de ce qui change à chaque appel, construire un persona comme un comportement observable plutôt qu'une étiquette, et fixer des contraintes vérifiables plutôt que des consignes vagues : ces trois disciplines réduisent la variance d'un système construit sur un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire. Le refus, conçu comme un comportement délibéré, complète ce cadre en évitant le risque le plus coûteux — une réponse assurée produite là où l'information fiable manquait. Le chapitre suivant aborde la décomposition des tâches complexes en étapes intermédiaires, lorsque la demande dépasse ce qu'une seule instruction peut raisonnablement couvrir.