L’essentiel
Attribuer un rôle peut orienter le vocabulaire, l’angle, le niveau de détail et les priorités d’une réponse. « Tu aides un responsable de petite entreprise à comprendre un rapport technique » est plus utile que « tu es le meilleur expert du monde ». Le premier décrit une mission et un public ; le second ajoute une prétention impossible à vérifier.
Un persona ne donne ni diplôme, ni accès à des données absentes, ni autorité juridique. Il ne remplace pas une source, un outil spécialisé ou une validation professionnelle. Utilisez-le comme réglage de communication et de perspective, pas comme preuve de compétence.
Les quatre dimensions d’un rôle utile
- Fonction : ce que l’assistant prépare — expliquer, relire, comparer ou structurer.
- Destinataire : pour qui la sortie est conçue et ce que cette personne connaît déjà.
- Priorités : exactitude, pédagogie, brièveté, conformité à une charte ou repérage des risques.
- Limites : actions interdites, informations manquantes, niveau d’autorité et moment de l’escalade.
Le rôle est plus efficace lorsqu’il modifie une décision observable. Un « relecteur accessibilité » doit repérer le jargon, expliciter les acronymes et proposer des alternatives compréhensibles. Un « lecteur pressé » doit commencer par la décision et limiter le contexte. À l’inverse, une biographie fictive de quinze lignes consomme du contexte sans nécessairement améliorer le résultat.
Rôle, ton et autorité ne sont pas synonymes
Le rôle répond à « depuis quelle perspective travailler ? ». Le ton répond à « comment s’exprimer ? ». L’autorité répond à « quelles décisions ou actions sont permises ? ». Vous pouvez demander un ton rassurant sans prétendre être psychologue, ou une lecture attentive aux risques sans autoriser le modèle à approuver un contrat.
Dans une application, les rôles techniques des messages peuvent également déterminer la priorité de certaines instructions. Cette hiérarchie dépend du produit. Elle ne doit pas être confondue avec le persona écrit dans le texte. Une phrase « tu es administrateur » ne crée aucun droit informatique réel.
Quand utiliser ou éviter les personas
Utilisez un rôle pour adapter une explication à un public, simuler plusieurs lectures d’un même document, appliquer une grille de revue ou maintenir une voix éditoriale. Demander successivement la lecture d’un client, d’un technicien et d’un responsable conformité peut faire émerger des questions différentes — à condition de considérer ces sorties comme des hypothèses de revue.
Évitez d’utiliser un persona comme substitut à l’expertise réglementée, comme justification d’une décision concernant une personne ou comme moyen de contourner les règles d’un service. Pour un travail complexe, séparez les perspectives dans des étapes identifiables plutôt que de demander au modèle d’incarner cinq spécialistes à la fois.
Exemple avant / après : expliquer une clause contractuelle
Avant
Tu es un avocat infaillible. Dis-moi si je peux signer ce contrat.
Le rôle réclame une autorité et une certitude que le modèle ne possède pas. La décision finale est déléguée sans contexte juridique suffisant.
Après
Agis comme assistant de préparation à une revue juridique. Pour un dirigeant non juriste, reformule chaque clause en langage courant, liste les obligations, dates et montants explicitement présents, puis formule les questions à poser à un avocat. Ne conclus pas que le contrat est sûr ou conforme.
La seconde version exploite la perspective juridique pour préparer le travail, sans simuler une validation professionnelle.
Prompt à copier : rôle borné
RÔLE DE TRAVAIL
Tu es un assistant de [fonction concrète].
DESTINATAIRE
La sortie s’adresse à [public], qui connaît [niveau actuel].
MISSION
[Tâche précise et résultat visé.]
PRIORITÉS
1. [...]
2. [...]
3. [...]
LIMITES
- Tu ne disposes que des informations fournies ci-dessous.
- Tu ne prends aucune décision à la place de [responsable].
- Tu sépares faits, hypothèses et questions.
- Tu orientes vers [personne compétente] si [condition].
FORMAT
[Structure et longueur.]
DONNÉES
[Contenu autorisé à traiter.]
Exercice guidé : trois perspectives, une seule décision humaine
Choisissez une page d’inscription à une newsletter. Faites-la examiner selon trois rôles : lecteur débutant, responsable marketing et relecteur accessibilité.
- Définissez pour chaque rôle deux priorités observables.
- Demandez trois analyses séparées de cinq points maximum.
- Repérez les recommandations communes et les conflits.
- Décidez vous-même des changements en indiquant votre critère d’arbitrage.
Critères de réussite
- Chaque rôle conduit à une grille différente et concrète.
- Aucun persona ne prétend représenter tous les vrais utilisateurs.
- Les observations citent un élément visible de la page.
- La décision finale reste attribuée à une personne identifiée.
Erreurs fréquentes
- Écrire une biographie détaillée sans lien avec la tâche.
- Confondre ton confiant et exactitude démontrée.
- Attribuer au rôle un accès, un diplôme ou une capacité inexistante.
- Demander plusieurs personas contradictoires dans une seule réponse.
- Laisser le rôle prendre une décision à fort impact.
- Oublier le public, les priorités et le format au profit d’un simple titre de métier.
Checklist d’un rôle responsable
- La fonction influence-t-elle réellement le travail demandé ?
- Le destinataire et son niveau sont-ils définis ?
- Les priorités sont-elles observables ?
- Les limites d’autorité sont-elles explicites ?
- Une condition d’escalade est-elle prévue ?
- La sortie sera-t-elle validée selon son risque ?
Mini-quiz
Question 1. « Tu es médecin » rend-il une réponse médicale plus fiable ?
Voir la réponse
Non par lui-même. Cette phrase peut orienter le vocabulaire, mais ne fournit ni examen clinique, ni données manquantes, ni qualification réelle, ni validation.
Question 2. Quel élément rend un rôle testable ?
Voir la réponse
Des priorités observables reliées à la mission, par exemple définir chaque acronyme et citer les passages qui motivent une alerte.
Sources et approfondissement
- Anthropic, rôles et bonnes pratiques de prompting, documentation évolutive consultée le 29 juillet 2026.
- OpenAI, rôles de messages et instructions, documentation évolutive consultée le 29 juillet 2026.
- Google AI for Developers, instructions, persona et contraintes, documentation évolutive consultée le 29 juillet 2026.
Vérifié le 29 juillet 2026.
