On parle beaucoup de persona. Mais au moment de trancher - une feature, un parcours, une priorité - il n’est presque jamais invoqué. Pas parce qu’il est inutile, mais parce qu’il est rarement construit pour ça.
Dans beaucoup de projets web, le persona documente, il rassure, il remplit une slide. Mais il ne tranche rien. Un persona utile n’est pas un portrait. C’est un outil de décision. Et c’est exactement ce qu’on remet au centre ici.
Un persona n’est pas une définition d’utilisateur
Un persona n’a pas pour rôle de définir un utilisateur. Cette confusion est fréquente, et elle explique pourquoi tant de personas deviennent inutiles dès que le projet avance.
Le persona n’est pas un outil de description
Décrire un utilisateur - son profil, ses caractéristiques, le “qui” - relève du marketing. C’est utile pour segmenter, communiquer, positionner une offre. Mais ce n’est pas à ça que sert un persona dans un projet produit.
👉 Un persona intervient quand la question n’est plus “qui est l’utilisateur ?” mais “pour qui prend-on cette décision ?”.
Autrement dit : quand il faut arbitrer, prioriser, renoncer.
Ce qui se passe quand on confond les deux
Dans beaucoup de projets, le persona prend la forme d’une fiche propre et rassurante. On y trouve un rôle, quelques traits généraux, parfois un prénom ou une photo.
Le document est clair, mais il ne change rien aux décisions.
Pourquoi ? Parce qu’il décrit sans jamais orienter. Il explique, mais ne tranche pas. Et dès qu’une discussion devient un peu tendue - roadmap, périmètre, délais - il disparaît.
Un persona utile pose un cadre, pas un portrait
Un persona utile ne cherche pas à tout dire d’un utilisateur.
Il cadre une situation précise dans laquelle des choix doivent être faits.
Il met volontairement certains besoins au premier plan, en laisse d’autres de côté, et assume ce point de vue. C’est cette prise de position qui lui donne sa valeur.
💡 Ce qu’il faut retenir
Décrire un utilisateur aide à comprendre.
Construire un persona sert à décider.
Les informations qui rendent un persona vraiment utilisable
Un persona devient utile quand il permet de trancher sans débat inutile.Pour ça, il y a quatre informations qui comptent vraiment.
Le contexte dans lequel la décision se joue
La première question n’est pas qui est cette personne, mais dans quelle situation elle agit.
Est-ce qu’elle utilise le produit :
- sous contrainte de temps ?
- en mobilité ou derrière un bureau ?
- seule ou en coordination avec d’autres ?
🔍 Exemple
Un même outil peut être utilisé :
- calmement, en début de journée, pour préparer ;
- ou en urgence, sur mobile, pour corriger.
👉 Ce ne sont pas deux profils différents. Ce sont deux contextes d’usage. Et ils n’appellent pas les mêmes choix produit.
L’objectif concret, pas l’intention vague
Un persona utile explicite ce que la personne cherche réellement à accomplir.
Pas “mieux gérer son activité”. Mais, par exemple :
- finaliser une action avant une échéance précise ;
- identifier rapidement ce qui bloque ;
- faire avancer un dossier sans dépendre de trois validations.
👉 L’objectif sert de filtre. Tout ce qui ne l’aide pas devient secondaire.
Les contraintes qui pèsent sur les choix
C’est souvent là que le persona devient vraiment actionnable.
Un persona utile rend explicites :
- les contraintes de temps ;
- les outils déjà imposés ;
- les dépendances à d’autres rôles ou systèmes.
🔍 Exemple
Un utilisateur peut avoir accès à une fonctionnalité avancée, mais ne jamais l’utiliser parce qu’elle nécessite :
- une validation hiérarchique lente ;
- ou une saisie qu’il ne peut pas faire sur le terrain.
👉 Ce ne sont pas des préférences. Ce sont des freins structurels qui doivent orienter les décisions produit.
Les irritants existants, pas les attentes idéales
Enfin, un persona utile s’appuie sur ce qui coince aujourd’hui :
- Ce que la personne contourne ;
- Ce qu’elle repousse ;
- Ce qu’elle fait à la main faute de mieux.
🔍 Exemple
Si un utilisateur exporte systématiquement ses données dans Excel, c’est un signal : quelque chose dans le produit ne lui permet pas d’agir efficacement.
👉 Les irritants sont souvent plus utiles que les besoins formulés.
Tous les personas ne servent pas au même moment
Un des pièges classiques avec les personas, c’est de vouloir tout faire rentrer dans un seul.
Un persona est toujours contextuel. Il sert à éclairer un type de décision, à un moment donné du cycle produit.
Persona de cadrage : comprendre pour quoi on construit
Au début d’un projet (ou lors d’une refonte) le persona sert avant tout à poser le cadre.
Il aide à répondre à des questions structurantes :
- Pour qui ce produit est-il vraiment prioritaire ?
- Quel usage doit être servi avant les autres ?
- Quels besoins ne doivent surtout pas être sacrifiés ?
🔍 Exemple
Sur un outil interne, choisir de prioriser l’agent terrain plutôt que le manager, ou l’inverse, change radicalement les parcours, les écrans, les arbitrages UX.
👉 Le persona sert ici à assumer un choix, pas à décrire tout le monde.
Persona de conception : trancher des choix produit
Quand on entre dans le concret (fonctionnalités, parcours, écrans) le persona devient un outil de décision tactique.
Il permet de trancher sans débat abstrait :
- Cette option aide-t-elle vraiment ce persona dans son contexte ?
- Est-ce que ça simplifie son action principale ou l’alourdit ?
🔍 Exemple
Si le persona clé agit sous contrainte de temps :
- une confirmation supplémentaire peut être un frein ;
- même si elle rassure d’autres profils moins prioritaires.
👉 Ici, le persona sert à dire non et à l’assumer.
Persona d’arbitrage : prioriser dans la durée
Enfin, certains personas servent surtout à prioriser dans le temps.
Ils aident à décider :
- ce qui doit être fait maintenant ;
- ce qui peut attendre ;
- ce qui ne sera jamais traité.
🔍 Exemple
Un persona “utilisateur expert” peut justifier des optimisations avancées… mais rarement en phase de lancement. Le garder en tête permet d’anticiper, sans surcharger la V1.
👉 Le persona ne dicte pas tout. Il aide à séquencer intelligemment.
📌 Conclusion
Un persona n’a pas vocation à être complet. Il doit être suffisamment précis pour faire trancher une décision.
S’il ne permet pas de prioriser, il n’apporte rien.
S’il aide à dire non, alors il est bien construit.
