Presque toutes les équipes produit ont un deck de personas. Très peu de produits sont différents grâce à lui.
Le deck contient généralement quatre personnages plastifiés aux noms du genre « Marie du Marketing », une photo de banque d'images, un âge, une liste d'outils préférés et une citation que personne n'a jamais prononcée. Il est présenté une fois, admiré, puis plus jamais consulté, parce qu'au moment où il faut décider de ce que doit faire le premier écran, il n'a rien à dire.
Un persona utilisateur ne vaut la peine d'être écrit que s'il aboutit à une décision : ce groupe voit une première expérience différente, sinon le persona n'était que de la décoration. Ce guide couvre ce qu'est un persona utilisateur, les six champs qui portent tout le poids, comment construire des personas à partir du comportement dont vous disposez déjà, quatre exemples détaillés, et comment transformer chacun en quelque chose que vit réellement un nouvel utilisateur.
La plupart des projets de personas s'arrêtent à la première étape, c'est pourquoi rien ne change jamais en aval.
Points clés à retenir
- Un persona utilisateur est un groupe qui partage un job et un premier succès, pas un profil démographique accompagné d'une photo.
- S'il ne change aucune décision, ce n'est pas un persona. Nommez le changement dans le produit ou supprimez la slide.
- Construisez-les d'abord à partir du comportement, puis menez des entretiens pour comprendre pourquoi ce comportement ressemble à ça.
- Six champs suffisent : job, déclencheur, premier succès, freins, preuves et ce qui change.
- Trois à cinq personas, c'est la fourchette réaliste pour la plupart des produits SaaS ; au-delà, il s'agit généralement de démographie déguisée.
- Un persona n'atteint les utilisateurs qu'à travers un segment, c'est-à-dire le même groupe écrit sous forme de règle qu'un logiciel peut évaluer.
Qu'est-ce qu'un persona utilisateur ?
Définition du persona utilisateur : une description courte et fondée sur des preuves d'un groupe de personnes qui utilisent votre produit pour la même raison et le jugent sur le même premier succès. Son objectif est de faciliter une décision : par quelle tâche commence la première expérience, quels mots emploie l'interface, ce qui peut attendre. Une description qui ne change rien de tout cela est un portrait de personnage, pas un persona.
La distinction compte parce qu'elle change ce que vous y mettez. L'âge, la localisation et l'intitulé de poste ne sont utiles que s'ils prédisent un comportement, et dans la plupart des produits SaaS ils en prédisent très peu : deux personnes au même poste dans des entreprises identiques peuvent attendre des choses complètement différentes de votre produit le jour de leur inscription. Ce qui prédit le comportement, c'est le job qu'elles cherchent à accomplir et l'événement qui les a poussées à chercher un outil.
C'est pourquoi le travail sur les personas s'enlise si souvent. L'équipe produit des descriptions exactes de qui sont les utilisateurs, découvre qu'elle ne peut agir sur rien de tout cela, et cesse discrètement de faire référence au deck.
Persona, segment, ICP et buyer persona
Quatre termes s'emploient indifféremment dans la même réunion, ce qui est un moyen sûr de perdre une heure. Ils répondent à des questions différentes :
| Terme | Répond à | Qui l'utilise |
|---|---|---|
| Persona utilisateur | Pourquoi ce groupe se comporte-t-il ainsi, et de quoi a-t-il besoin en premier ? | Produit, design, onboarding |
| Segment utilisateur | Quels comptes correspondent à ce groupe en ce moment ? | Produit, growth. C'est une règle, pas une histoire |
| ICP | À quelles entreprises devrions-nous vendre, tout simplement ? | Ventes, stratégie marketing |
| Buyer persona | Qui signe, et quelles objections soulève-t-il ? | Marketing, ventes |
Le duo qui compte pour le travail produit, c'est persona et segment. Un persona explique un groupe ; un segment utilisateur est le même groupe exprimé sous forme de règle qu'un logiciel peut évaluer : rôle admin, compte créé aujourd'hui, invité plutôt qu'inscrit par lui-même. Un persona sans segment correspondant n'atteint jamais personne ; un segment sans persona derrière lui est un filtre que personne dans la salle ne sait expliquer.
L'acheteur est rarement l'utilisateur. En SaaS B2B, la personne qui signe le contrat et celle qui ouvre le produit un mardi matin sont souvent deux personnes différentes, avec des motivations différentes. Construire la première expérience autour du buyer persona est une erreur courante et coûteuse : l'acheteur est déjà convaincu ; l'utilisateur, lui, doit l'être en faisant quelque chose.
Ce que contient un persona utile
Six champs font tout le travail. Tout le reste (la photo, l'âge, le trajet domicile-travail imaginaire) peut être supprimé sans perte d'information, et son absence rend le persona plus court et plus susceptible d'être lu.
Six champs, une page. S'il faut une deuxième page, c'est qu'elle décrit deux personas.
📋 Modèle de persona utilisateur
- Job to be done
- Ce pour quoi cette personne « embauche » le produit cette semaine, formulé comme elle le formulerait : « sortir le rapport hebdo sans demander à l'équipe technique », pas « tirer parti de l'analytique ».
- Déclencheur
- L'événement qui l'a poussée à s'inscrire ce jour-là précisément. Un nouveau poste, un tableur qui a cassé, une consigne venue d'en haut, l'invitation d'un collègue.
- Premier succès
- L'action unique qui prouve la valeur pour ce groupe. C'est rarement la même action d'un persona à l'autre, et c'est précisément pour cela qu'un flux d'onboarding unique sous-performe.
- Freins
- Ce qui la sépare de cette action : des données manquantes, des droits qu'elle n'a pas, un vocabulaire qu'elle ne partage pas avec votre interface.
- Preuves
- D'où cela vient (entretiens, tickets de support, enregistrements de sessions, données produit) et combien de comptes cela couvre. Un pourcentage garde tout le monde honnête.
- Ce qui change
- La décision produit que ce persona entraîne. Pas de décision, pas de persona.
Le dernier champ est celui que les équipes sautent, et le seul qui rentabilise l'exercice. Il sert aussi de filtre : si deux personas donnent la même réponse dans ce champ, il s'agit d'un seul persona sous deux noms.
Comment créer des personas utilisateur en 5 étapes
L'ordre ci-dessous part des données dont vous disposez déjà et utilise les entretiens pour les expliquer, plutôt que l'inverse. Comptez environ deux semaines de travail à temps partiel pour un produit de quelques milliers de comptes.
Partir du comportement, pas des opinions
Mener des entretiens dans chaque groupe comportemental
Regrouper selon le job et le déclencheur
Rédiger chaque persona en six champs
Les dimensionner, puis réduire à trois ou cinq
1. Partir du comportement, pas des opinions
Avant que quiconque n'écrive un nom sur une slide, regroupez vos comptes selon ce qu'ils ont fait pendant leur première semaine : quelle fonctionnalité ils ont touchée en premier, s'ils ont invité quelqu'un, s'ils ont importé des données, s'ils sont revenus le deuxième jour. Deux ou trois profils apparaissent généralement tout de suite, et ils correspondent rarement aux publics que l'équipe imaginait. C'est aussi là que vous apprenez quels groupes atteignent leur moment aha et lesquels calent en chemin.
2. Mener des entretiens dans chaque groupe comportemental
Huit à douze conversations par groupe suffisent pour entendre la même histoire revenir. Demandez ce qui s'est passé le jour de l'inscription, ce que la personne a essayé en premier et ce qu'elle s'attendait à voir. Ne demandez pas aux gens de se décrire ; demandez-leur de vous raconter la dernière fois qu'ils ont eu le problème. Les réponses vous donnent le déclencheur et le vocabulaire, deux choses impossibles à déduire de l'analytique seule.
3. Regrouper selon le job et le déclencheur
Regroupez maintenant les entretiens selon ce que les gens cherchaient à accomplir, pas selon qui ils étaient. Un fondateur solo et un responsable des opérations dans un grand groupe peuvent appartenir au même persona s'ils sont arrivés pour la même raison et ont besoin du même premier succès, et deux personnes au même poste peuvent appartenir à deux personas différents. Si vos groupes se réorganisent sans cesse par taille d'entreprise ou par rôle, vérifiez si cette variable prédit réellement ce que les gens font ensuite, ou si c'est simplement la plus facile à voir.
4. Rédiger chaque persona en six champs
Une page chacun, avec le modèle ci-dessus. Gardez le langage des utilisateurs ; les formulations qui reviennent mot pour mot dans les entretiens sont celles qui ont leur place dans vos états vides, vos tooltips et votre microcopie UX. Là où vous avez dû deviner, indiquez-le. Un persona avec deux lacunes assumées est plus utile qu'un persona sans lacune et sans preuve.
5. Les dimensionner, puis réduire à trois ou cinq
Indiquez un pourcentage des inscriptions à côté de chaque persona. C'est l'étape qui empêche le client le plus bruyant de façonner le parcours par défaut : un groupe qui représente deux pour cent des nouveaux comptes peut être servi, mais pas depuis le premier écran. Ensuite, coupez. Si deux personas se voyaient proposer le même onboarding, le même état vide et les mêmes tooltips, fusionnez-les.
N'inventez pas ce que vous n'avez pas entendu. Dès qu'un persona contient un détail que personne n'a dit (un âge, un hobby, une « journée type »), il commence à servir de preuve dans des débats où aucune preuve n'existe. Chaque ligne doit pouvoir être rattachée à un entretien, un ticket ou une requête.
Exemples de personas utilisateur
Quatre exemples tirés d'un produit d'analytique B2B fictif, rédigés dans la version courte. Notez que la partie intéressante de chacun est la dernière ligne, pas la première.
- Job : décider en une semaine si cet outil peut remplacer le tableur que l'équipe maintient actuellement à la main.
- Déclencheur : le tableur a cassé, ou la personne qui le maintenait est partie.
- Premier succès : voir ses propres données dans un graphique, pas des données d'exemple.
- Freins : l'import exige des identifiants qu'il n'a peut-être pas ; il ne lira pas de documentation pendant une évaluation.
- Preuves : 14 entretiens, 31 % des inscriptions en self-serve.
- Job : faire la seule chose pour laquelle on l'a ajouté, puis retourner à son vrai travail.
- Déclencheur : un e-mail d'un coéquipier contenant un lien.
- Premier succès : terminer cette tâche unique : approuver, commenter, téléverser.
- Freins : aucun contexte sur la raison d'être de l'espace de travail ; une visite complète du produit est perçue comme un obstacle.
- Preuves : 9 entretiens, 38 % de tous les nouveaux utilisateurs, le groupe le plus important en volume.
- Job : amener trente collègues à utiliser l'outil sans animer lui-même de sessions de formation.
- Déclencheur : le contrat a été signé et il a été désigné responsable.
- Premier succès : le premier coéquipier invité qui réalise une action en autonomie.
- Freins : les droits, le SSO, et aucune idée de qui est bloqué ; sa crainte est un déploiement qui meurt en silence.
- Preuves : 11 entretiens, 12 % des inscriptions mais la majorité du revenu d'expansion.
- Job : reprendre quelque chose qu'il a configuré il y a des mois et qu'il a oublié.
- Déclencheur : une échéance, une demande de rapport ou un nouveau trimestre.
- Premier succès : retrouver ce qu'il a construit la dernière fois et confirmer que ça fonctionne toujours.
- Freins : l'interface a changé depuis ; son modèle mental n'est plus à jour.
- Preuves : tickets de support et données de session ; 8 % des comptes actifs mensuels.
Transformer un persona en une première expérience différente
C'est ici que le deck devient un changement produit. Quatre mécanismes couvrent presque tous les cas, et aucun ne demande de budget de recherche pour être maintenu.
-
Demander plutôt que deviner
Une seule question sur le premier écran, « qu'est-ce qui vous amène aujourd'hui ? », avec vos personas comme réponses. L'auto-sélection fonctionne mieux que n'importe quelle déduction, et la répartition des réponses sert en continu de recherche sur les personas.
-
Déduire quand c'est possible
Utilisateurs invités, rôles admin, type d'abonnement et source d'acquisition sont connus avant que quiconque ne réponde à quoi que ce soit. Servez-vous-en pour les personas déjà identifiables et gardez la question pour ceux qui ne le sont pas.
-
Changer le parcours, pas seulement le texte
Un message d'accueil différent sur la même visite en douze étapes, ce n'est pas de la personnalisation. Chaque persona doit découvrir une première expérience réellement différente : une checklist, une visite en deux étapes, ou un seul tooltip et rien d'autre.
-
Mesurer par persona
Ventilez l'activation par persona dès le départ. Un taux d'activation global masque le cas où vous avez amélioré les choses pour le groupe le plus nombreux tout en les dégradant pour le groupe qui paie.
La recherche sur les personas la moins coûteuse qui soit : demander sur le premier écran, puis orienter selon la réponse.
Le parcours que suit ensuite chaque persona est une question de séquencement, et la règle générale est d'en montrer moins que ce qui paraît naturel ; l'approche de l'onboarding progressif introduit une fonctionnalité quand le comportement montre qu'elle est devenue pertinente, plutôt que dans les soixante premières secondes. Pour les groupes que vous ne pouvez pas identifier à l'inscription, un sondage in-app quelques jours plus tard comble le manque sans interrompre la première session.
À faire et à éviter
✅ À faire
- Partir du comportement de la première semaine
- Regrouper par job et par déclencheur
- Indiquer un pourcentage à côté de chaque persona
- Citer les mots réellement employés par les utilisateurs
- Conclure chaque persona par une décision
- Donner à chaque persona un premier succès différent
- Les revoir tous les deux trimestres
❌ À éviter
- Inventer des âges, des photos ou des hobbies
- Construire la première expérience pour l'acheteur
- Confondre un persona avec un segment
- Garder neuf personas que personne ne sait citer
- Personnaliser le message d'accueil et rien d'autre
- Laisser un groupe de 2 % dicter le parcours par défaut
- Les écrire une fois et les ranger dans un tiroir
Créer un onboarding basé sur les personas avec Kompassify
Une fois les personas définis, le travail consiste à orienter les utilisateurs, et cela ne demande pas de sprint. Kompassify est une plateforme d'adoption digitale no-code pour les équipes SaaS : chaque persona peut donc avoir sa propre première expérience sans livrer de code produit.
- Posez la question avec une étape d'onboarding à choix multiples et envoyez chaque réponse vers son propre parcours.
- Orientez selon ce que vous savez déjà grâce aux segments : rôle, abonnement, invité ou inscrit par lui-même, ancienneté du compte.
- Donnez à chaque persona son propre flux : une visite guidée produit pour l'un, une checklist pour un autre, un seul tooltip pour la personne venue faire une seule chose.
- Comblez les manques plus tard avec un sondage in-app adressé aux groupes que vous n'avez pas pu identifier à l'inscription.
- Comparez l'activation par persona dans l'analytique produit, et ne gardez la segmentation que si l'écart bouge.
Gratuit jusqu'à 100 utilisateurs actifs mensuels, offres payantes à partir de $129/mois, conforme au RGPD et hébergé dans l'UE.
Offrez à chaque persona sa propre première expérience
Posez une question, orientez selon la réponse, et laissez chaque groupe atteindre le succès qui compte pour lui, sans écrire de code.
Commencer gratuitement →Questions fréquentes
Qu'est-ce qu'un persona utilisateur ?
Un persona utilisateur est une description courte et fondée sur des preuves d'un groupe de personnes qui utilisent votre produit pour la même raison et le jugent sur le même premier succès. Il existe pour faciliter une décision : par quelle tâche la première expérience doit commencer, quels mots l'interface doit employer, quelle fonctionnalité peut attendre. Une description qui ne change rien à tout cela est un portrait de personnage, pas un persona, aussi bien écrite soit-elle.
Comment créer des personas utilisateur ?
En cinq étapes. Partez du comportement dont vous disposez déjà, en regroupant les comptes selon ce qu'ils ont fait pendant leur première semaine plutôt que selon qui ils sont. Interrogez huit à douze personnes par groupe candidat et demandez-leur ce qui s'est passé le jour de leur inscription. Regroupez selon le job et le déclencheur, pas selon la démographie. Rédigez chaque persona en six champs : job to be done, déclencheur, premier succès, freins, preuves et ce qui change dans le produit. Puis mesurez la taille de chaque groupe, car un persona qui représente deux pour cent des inscriptions ne devrait pas façonner le parcours par défaut.
Que doit contenir un persona utilisateur ?
Six champs portent tout le poids : le job pour lequel la personne « embauche » votre produit cette semaine, l'événement déclencheur qui l'a poussée à s'inscrire ce jour-là précisément, le premier succès qui prouve la valeur pour ce groupe en particulier, les freins qui la séparent de ce succès, les preuves qui fondent l'affirmation, y compris le nombre de comptes couverts, et la décision produit que le persona modifie. L'âge, la photo de banque d'images, les outils préférés et la biographie inventée peuvent tous être supprimés sans rien perdre.
Quelle est la différence entre un persona utilisateur et un segment utilisateur ?
Un persona est un livrable de recherche écrit pour des humains ; un segment est le même groupe exprimé sous forme de règle qu'un logiciel peut évaluer, par exemple rôle égal à admin et compte créé depuis moins d'un jour. Les personas expliquent pourquoi un groupe se comporte comme il le fait, les segments permettent de montrer quelque chose de différent à ce groupe. Un persona sans segment correspondant n'atteint jamais un utilisateur, et un segment sans persona derrière lui est un filtre que personne ne sait expliquer.
Combien de personas utilisateur faut-il avoir ?
Trois à cinq pour la plupart des produits SaaS, et chacun doit mériter sa place en changeant quelque chose. Le test pratique consiste à savoir si vous pouvez nommer un premier succès différent pour chacun : si deux personas se voyaient proposer le même onboarding, le même état vide et les mêmes tooltips, il s'agit d'un seul persona sous deux noms. Les produits qui en ont plus de cinq décrivent généralement plusieurs publics en termes démographiques plutôt que plusieurs jobs distincts.
Un buyer persona est-il la même chose qu'un persona utilisateur ?
Non, et en SaaS B2B ce sont souvent des personnes différentes. Un buyer persona décrit qui signe le contrat, sur quoi cette personne est évaluée et quelles objections elle soulève : c'est un livrable marketing et commercial. Un persona utilisateur décrit qui ouvre le produit un mardi matin et ce qu'il cherche à terminer. Construire l'onboarding pour l'acheteur est une erreur courante et coûteuse : l'acheteur est rarement la personne qui doit atteindre la première valeur.
À quelle fréquence faut-il mettre à jour les personas ?
Revoyez-les tous les deux trimestres et chaque fois que votre mix d'acquisition change, car une nouvelle offre tarifaire, un nouveau canal ou une nouvelle intégration peut faire apparaître un groupe que les personas n'ont jamais décrit. La maintenance la moins coûteuse est une seule question d'onboarding posée à l'inscription : la répartition des réponses vous indique quand un persona grandit, rétrécit ou manque entièrement, sans lancer de projet de recherche.
Comment utiliser les personas dans l'onboarding produit ?
Demandez aux nouveaux utilisateurs, dès le premier écran, à quel persona ils correspondent, puis orientez chaque réponse vers une première expérience différente : une checklist de configuration pour la personne qui paramètre l'espace de travail, une courte visite d'une seule fonctionnalité pour le spécialiste, un seul tooltip pour le collègue invité qui n'a besoin que d'une tâche. Mesurez l'activation séparément pour chaque groupe. Si l'expérience orientée ne fait pas bouger l'activation pour au moins un persona, la segmentation reposait sur la mauvaise distinction.