Vous avez peut-être déjà reçu des personas : une belle fiche avec une photo, un prénom, un âge, des loisirs et une citation. Elle a été présentée une fois en réunion de lancement, puis rangée dans un dossier partagé que personne n'a rouvert. L'outil n'y est pour rien. Le problème vient de la façon dont la fiche a été fabriquée, et surtout du fait que personne n'avait décidé à quoi elle servirait.
J'ai conçu Moonworkers, mon logiciel de paie pour les petites entreprises britanniques, en partant des utilisateurs : des personas, puis des wireframes, puis un design system Figma. Et j'utilise chaque jour une forme très réduite de persona dans ma machine de contenu. Voici ce que j'en retiens : quel type de persona faire selon votre temps et vos données, comment le construire, et comment vous en servir ensuite.
01Un persona est un outil de décision, pas un portrait
Nielsen Norman Group définit le persona comme une description fictive mais réaliste d'un utilisateur type, fondée sur de la recherche auprès de vraies personnes. Le même article donne la règle que je trouve la plus utile : chaque information doit avoir une raison d'être. Si elle ne change pas la conception et n'aide à trancher aucune décision, on la retire. Le vin préféré du persona n'a rien à faire dans la fiche d'un intranet, mais il compte pour une place de marché de sommeliers.
L'autre intérêt, plus discret, est le vocabulaire commun. En réunion, le prénom du persona remplace une longue description. Au lieu que chacun ait sa propre idée de « l'utilisateur », l'équipe parle de la même personne. Quand quelqu'un dit « ça, Claire ne le lira jamais sur son téléphone entre deux rendez-vous », la discussion avance.
Ma règle, du coup, est simple : un persona qui ne tranche aucune décision est une affiche. Avant d'en écrire un, je note les trois ou quatre décisions qu'il devra aider à prendre (la page d'accueil, l'ordre d'un parcours, le ton des contenus, ce qu'on ne fera pas). C'est aussi la première question que pose Nielsen Norman Group dans son article sur le périmètre des personas : à quoi serviront-ils ?
02Trois façons de faire des personas, selon le temps et les données
Il n'existe pas une seule manière de créer des personas. Nielsen Norman Group en décrit trois types, qui diffèrent par la recherche sur laquelle ils reposent :
- les proto personas, construits en atelier de 2 à 4 heures à partir de ce que l'équipe sait déjà ou suppose, pour aboutir à 3 à 6 personas ;
- les personas qualitatifs, tirés d'entretiens avec 5 à 30 utilisateurs, que l'auteur juge adaptés à la plupart des équipes ;
- les personas statistiques, qui ajoutent une enquête auprès d'au moins 100 répondants, idéalement 500, et une analyse de données.
Pour une PME, le choix se fait souvent entre les deux premiers. Le proto persona a un mérite réel : il rend explicites les hypothèses de chacun. Il a aussi un défaut, que le même article nomme : il peut devenir une chambre d'écho des erreurs de l'équipe. Je le présente toujours comme une hypothèse à vérifier, jamais comme un résultat.
Le persona statistique, lui, est rarement justifié dans une petite structure. Il demande la recherche qualitative en amont, plus un travail statistique, et finit souvent assez proche des personas qualitatifs. Une précision m'a marqué dans ce texte : des personas bâtis uniquement sur la démographie ou les statistiques du site ne disent pas pourquoi les gens agissent. Or c'est le pourquoi qui sert à concevoir.
03Créer des personas en cinq étapes
Voici la méthode que je suis, dans une version qui tient en quelques semaines au plus pour une petite équipe.
1. Écrire les décisions avant les fiches
Je liste ce que les personas devront trancher, et à quel niveau. Un persona pour toute l'entreprise et un persona pour un outil précis ne contiennent pas les mêmes informations : plus le périmètre est large, plus les données sont générales, et moins elles aident à dessiner un écran.
2. Rassembler ce qu'on sait déjà, puis le traiter comme une hypothèse
Le manuel de service du gouvernement britannique est très clair sur ce point : toute opinion qui ne vient pas des utilisateurs est une hypothèse à prouver par la recherche. Je pars donc des statistiques, des demandes reçues par le support et des retours commerciaux, en gardant cette étiquette en tête.
3. Parler à de vrais utilisateurs
Des entretiens courts, centrés sur ce que la personne essaie de faire, comment elle le fait aujourd'hui et ce qui la gêne. Je cherche les mots qu'elle emploie, parce qu'ils finiront dans les titres et les boutons.
4. Regrouper par comportements et besoins, pas par âge
Je regroupe les personnes qui partagent les mêmes buts, les mêmes difficultés et les mêmes attentes, même si tout le reste les sépare. Je rédige ensuite les besoins dans le format du manuel britannique : « En tant que… j'ai besoin de… afin de… ».
5. Réduire la fiche à ce qui sert
Un nom pour s'en souvenir, le contexte d'usage, le niveau de familiarité avec le sujet, les buts, les freins, une phrase dite par un vrai utilisateur. Le reste part. Ensuite, la fiche doit vivre dans les outils de travail : dans le brief de la maquette, dans le cahier de test, dans la semaine de cadrage d'un projet.
04Ce que j'ai fait avec Moonworkers et avec ce blog
Sur Moonworkers, les personas ont servi de point de départ à tout le reste. Ils ont guidé les wireframes, puis le design system Figma qui a suivi.
Dans ma machine de contenu, j'utilise une version plus brutale. Le brief de chaque article contient un champ « lecteur » : qui lit, dans quelle situation, avec quel problème, en une phrase. Tant que ce champ fait moins de 30 caractères, ou qu'il reprend le texte d'exemple, l'outil refuse le brief et la rédaction ne commence pas. C'est un persona réduit à ce qui sert une décision, et contrôlé par une machine plutôt que par la bonne volonté.
Ce champ change vraiment le texte. Un article écrit pour « les entreprises » parle à tout le monde, donc à personne. Un article écrit pour un fondateur à qui l'on a déjà vendu des fiches inutiles commence ailleurs, choisit d'autres exemples et s'arrête plus tôt.
05Le persona B2B : un rôle dans une situation
En B2B, je décris d'abord un rôle dans une situation, pas une personne avec un âge et des loisirs. La personne qui utilise l'outil chaque jour n'est souvent pas celle qui le choisit, ni celle qui signe. Chacune a ses propres questions, et une page qui ne répond qu'à l'une d'elles laisse les autres sans réponse.
Le manuel britannique rappelle aussi de penser aux personnes qui fournissent ou accompagnent le service, pas seulement aux utilisateurs « typiques ». Dans un logiciel professionnel, c'est souvent le comptable, l'administrateur ou le support. Ils n'apparaissent dans aucune fiche marketing, et ce sont pourtant eux qui recommandent ou bloquent un outil.
Pour la partie acquisition, je relie chaque persona B2B à un moment du parcours d'achat et à ce qu'il doit lire à ce moment-là. C'est ce lien qui permet ensuite de construire un plan marketing qui ne s'adresse pas à tout le monde à la fois.
06Ce qui fait échouer les personas
Dans une courte vidéo, Why Personas Fail, Nielsen Norman Group liste les causes d'échec qu'il observe. J'en retiens trois.
D'abord, des personas trop larges. On veut une seule série qui serve à toute l'entreprise, et l'on obtient des fiches si générales qu'elles n'aident à concevoir aucune fonctionnalité précise. Ensuite, des personas livrés comme des affiches, sans dire à l'équipe comment s'en servir. Enfin, des personas créés seul dans son coin, puis remis aux autres, qui n'y croient pas parce qu'ils ne savent pas d'où ils viennent.
J'ajoute une limite honnête de mon côté. Les personas ne remplacent pas un test avec de vrais utilisateurs : relire une maquette « en se mettant à la place de Claire » aide, mais ne dit pas ce que Claire fera vraiment. C'est pour ça que je les fais suivre d'un prototype cliquable testé avant le développement. Et si votre budget ne permet aucun entretien, un proto persona vaut mieux que rien, à condition de le présenter comme une supposition.
07Par où commencer cette semaine
Si vous avez déjà des personas dans un dossier, ressortez-les et posez une seule question : quelle décision ont-ils aidé à prendre ces six derniers mois ? Si la réponse est aucune, ne les jetez pas tout de suite. Gardez ce qui s'appuie sur des faits, retirez le décor, et ajoutez les décisions qu'ils devront servir.
Si vous partez de zéro, commencez petit : une demi-journée d'atelier pour écrire vos hypothèses, puis cinq entretiens avec de vrais clients pour les confronter. Vous aurez un persona principal imparfait mais utile, que vous corrigerez au fil des tests.
C'est le genre de travail que je fais en début de projet, dans le cadrage ou la conception, et vous trouverez le détail dans mes services. Si vos personas dorment dans un dossier, on peut en parler.