Demandez à cinq personnes d'une équipe produit de décrire comment un nouvel utilisateur passe de l'inscription à son premier vrai résultat, et vous obtiendrez cinq réponses différentes, toutes plus courtes que la réalité. Le designer se souvient des écrans qu'il a conçus. L'ingénieur se souvient des endpoints. Le support se souvient des trois endroits où les gens bloquent, dont aucun n'apparaît dans la version des autres. Personne ne ment : chacun détient un fragment. Un parcours utilisateur est ce que l'on dessine quand on décide d'arrêter de débattre à partir de fragments.
Un parcours utilisateur est le diagramme d'une tâche, du moment où l'utilisateur entre jusqu'au moment où il a terminé : chaque écran qu'il voit, chaque action qu'il effectue et (c'est ce qui le rend utile) chaque décision que le produit prend à sa place sur l'étape suivante. Il est volontairement austère. Pas de couleurs à débattre, pas de mise en page à critiquer. Ce qu'il produit, c'est un accord sur ce qui se passe réellement, condition préalable pour le changer.
Ce guide couvre tout le sujet : ce qu'est un parcours utilisateur (et ce qu'il n'est pas), le petit ensemble de symboles d'un diagramme de parcours utilisateur, ce qui distingue les parcours des task flows, des wireflows, des entonnoirs et des journey maps, une méthode en sept étapes pour en créer un à partir de vraies données produit, six exemples de parcours utilisateur annotés issus de produits SaaS, les bonnes pratiques qui gardent un parcours honnête, et quoi faire une fois que le diagramme vous a montré où les utilisateurs s'en vont.
À retenir
- Un parcours utilisateur, c'est une tâche dessinée de bout en bout : les écrans, actions et décisions ordonnés entre un point d'entrée et un état final, pas un plan de site, pas un wireframe.
- Les embranchements sont tout l'intérêt. Un parcours sans losange de décision est un task flow : le chemin idéal. Les vrais utilisateurs ne sont presque jamais sur le chemin idéal.
- Cinq formes suffisent : la pilule pour le début et la fin, le rectangle pour un écran ou une action, le losange pour une décision, le parallélogramme pour les données entrantes ou sortantes, la flèche pour la direction, avec chaque branche étiquetée.
- Parcours et journey map diffèrent par l'altitude : la journey map dit quelle étape fait mal, tous canaux confondus ; le parcours utilisateur dit quel clic en est la cause, dans le produit.
- Dessinez-le à partir du produit livré, pas de mémoire, puis associez un vrai taux d'abandon à chaque étape : un parcours non mesuré n'est qu'une opinion en forme de diagramme.
- Le diagramme est le diagnostic, pas le remède : une fois que vous savez quelle étape fuit, la solution est en général un guidage à cette étape (un tooltip, une checklist, une visite guidée), pas une refonte de tout le chemin.
Qu'est-ce qu'un parcours utilisateur ? (Définition)
Un parcours utilisateur (user flow) est la suite ordonnée d'écrans, d'actions et de décisions qu'une personne traverse pour accomplir une tâche précise dans un produit. Il commence à un point d'entrée (une page marketing, un e-mail d'invitation, une notification, un élément de menu) et se termine sur un état que l'on peut réellement vérifier : le projet est publié, le collègue est invité, les données sont importées. Entre les deux se trouve tout ce que le produit demande à l'utilisateur, et tout ce que le produit décide à son sujet.
Le parcours utilisateur, en une définition. Un parcours utilisateur est le diagramme d'une seule tâche dans un produit, tracé du point d'entrée à l'état final, qui représente chaque écran ou action par un nœud et chaque chemin possible entre eux par une flèche étiquetée, y compris les chemins qui ne mènent nulle part. Son rôle n'est pas de décrire l'apparence du produit, mais de rendre visible l'endroit où le chemin bifurque, tourne en boucle, cale ou s'arrête sans bruit.
Deux mots de cette définition portent tout le poids. Seule : un parcours utilisateur couvre une tâche, pas tout votre produit, « inviter un collègue », pas « la collaboration ». Dès qu'un parcours essaie de tout couvrir, il devient un plan de site, et aucun plan de site n'a jamais expliqué un abandon. Et possible : un parcours qui ne dessine que le chemin que vous espériez voir emprunter est une spécification, pas une carte. La valeur est dans les embranchements : la vérification des droits qui envoie la moitié de vos invités vers un écran que personne n'a conçu, l'espace de travail vide qui accueille un utilisateur qui n'a rien importé.
On parle aussi de flux utilisateur, de user flow chart ou de diagramme de flux, et la notation est ouvertement empruntée aux logigrammes. Cet emprunt est un atout : un product manager, un designer, un ingénieur et un responsable support savent tous lire un losange sans formation, et c'est précisément pour cela que le format survit dans une discipline qui réinvente ses livrables tous les trois ou quatre ans.
Les symboles du diagramme de parcours utilisateur : toute la notation
Le vocabulaire est réduit à dessein. Cinq formes couvrent presque tous les parcours qui méritent d'être dessinés, et chaque symbole supplémentaire que vous inventez est un symbole qu'il faudra expliquer en réunion :
Trois conventions rendent ces formes lisibles. Dessinez de gauche à droite, parce que le temps se lit de gauche à droite et qu'un parcours qui part dans tous les sens est un parcours que personne ne vérifie. Étiquetez chaque flèche qui sort d'un losange (« oui / non », « avec données / vide », « admin / membre »), car une branche sans étiquette est une décision que vous n'avez pas vraiment prise. Et donnez un nœud à chaque impasse : si un chemin laisse l'utilisateur en plan, dessinez-le. L'effacer du diagramme ne l'efface pas du produit.
Cinq formes et deux branches étiquetées. La branche qui compte est souvent celle que personne n'a conçue : ici, l'invité qui arrive dans un espace de travail où il ne reste plus aucune licence.
Parcours utilisateur vs task flow vs wireflow vs journey map vs entonnoir
Ces cinq livrables sont utilisés de façon interchangeable en réunion, puis donnent lieu à cinq conversations différentes. Ce ne sont pas des formats concurrents : ils répondent à des questions différentes, et le moyen le plus rapide de choisir est de savoir sur quelle question vous butez vraiment :
| Livrable | Ce qu'il montre | La question à laquelle il répond | Embranchements ? |
|---|---|---|---|
| Parcours utilisateur (user flow) | Écrans, actions et décisions d'une tâche, tous les chemins compris | Où le chemin bifurque-t-il, cale-t-il ou aboutit-il à une impasse ? | Oui, c'est tout l'intérêt |
| Task flow | Le chemin idéal unique à travers une tâche | Quelle est la séquence prévue ? | Non |
| Wireflow | Un parcours utilisateur dont les nœuds sont des wireframes | À quoi ressemble chaque étape, dans l'ordre ? | En général peu |
| Journey map | Un persona à travers les étapes et les canaux, avec émotions et points de douleur | Quelle étape de la relation fait mal, et pourquoi ? | Pas structurellement |
| Entonnoir / rapport de conversion | Le nombre d'utilisateurs qui passent un petit nombre d'étapes ordonnées | Combien de personnes vont jusqu'au bout ? | Non, uniquement des agrégats |
Parcours utilisateur vs journey map
C'est le duo que l'on confond le plus, et la différence tient à l'altitude. Une journey map (carte d'expérience) vit autour du produit : elle suit un persona à travers les étapes et les canaux (la publicité, la démo, la première connexion, le ticket de support, le renouvellement) et note ce qu'il pensait et ressentait à chacune. Un parcours utilisateur vit dans le produit et reste purement mécanique : cet écran, ce clic, cette bifurcation, dans une session. La journey map vous dit que « la première semaine est écrasante » ; le parcours utilisateur vous dit que 41 % des utilisateurs arrivent sur l'écran de projet vide et ne reviennent jamais. La plupart des équipes ont besoin des deux, dans cet ordre : construisez la journey map pour trouver l'étape douloureuse, puis dessinez le parcours de la tâche concernée pour trouver l'étape à corriger.
Parcours utilisateur vs entonnoir
Un entonnoir, c'est un parcours utilisateur dont on a retiré tout ce qui est intéressant. Il vous donne quatre barres et un taux de conversion ; le parcours vous donne la raison. Quand vos analytics produit montrent une chute de 60 % entre « compte créé » et « premier projet », l'entonnoir a fait son travail et ne peut pas aller plus loin ; les six écrans, les deux vérifications de droits et l'erreur de validation silencieuse cachés dans cette seule barre sont exactement ce que le parcours sert à révéler. Utilisez les entonnoirs pour trouver quel parcours dessiner, puis le parcours pour trouver ce qu'il faut corriger.
Pourquoi les parcours utilisateur comptent pour l'onboarding et l'activation
Le parcours utilisateur est un livrable de design, mais c'est dans l'onboarding utilisateur qu'il rapporte le plus, là où l'écart entre le chemin prévu et le chemin réel est le plus grand et le plus coûteux :
-
Il transforme un taux d'abandon en emplacement
« L'activation est à 22 % » ne permet pas d'agir ; « 62 % des utilisateurs qui arrivent sur l'écran d'import repartent sans choisir de fichier », si. Le parcours ramène l'indicateur global à un nœud précis, la seule altitude à laquelle quelqu'un peut réellement livrer une correction.
-
Il révèle les états que personne n'a conçus
Chaque produit a des écrans qui n'existent qu'au bout d'une branche : l'espace de travail sans aucune donnée, l'essai qui expire en pleine tâche, le membre en lecture seule qui a cliqué sur un lien réservé aux admins. C'est là que les nouveaux utilisateurs atterrissent le plus souvent et là que l'attention du design arrive en dernier, ce qui explique pourquoi les états vides méritent leur propre nœud dans chaque parcours.
-
Il rend visible le nombre d'étapes, et le nombre d'étapes, c'est le time to value
Rien ne réduit le time to value comme la suppression d'étapes, et rien ne révèle les étapes supprimables comme le fait de voir onze rectangles à la suite là où l'équipe pensait qu'il y en avait quatre. Compter les nœuds est l'exercice d'optimisation le moins cher du travail produit.
-
Il montre que des utilisateurs différents ont besoin de chemins différents
Un admin qui configure un espace de travail et un membre invité qui le rejoint n'accomplissent pas la même tâche et ne devraient pas recevoir le même guidage. Des parcours dessinés par persona le rendent évident, et plaident pour un onboarding segmenté plutôt qu'une seule visite guidée pour tout le monde.
-
Il vous dit où le guidage a sa place, et où il ne l'a pas
Un parcours montre les étapes que les utilisateurs franchissent seuls : elles n'ont besoin d'aucune aide, et en ajouter n'est que de la friction. Les deux ou trois nœuds qui fuient sont ceux où un tooltip, un élément de checklist ou une étape de visite guidée justifie l'interruption.
Le vrai résultat du parcours n'est pas le diagramme, c'est la flèche qui descend. Un seul nœud fait l'essentiel des dégâts, et vous savez maintenant lequel.
Comment créer un parcours utilisateur en 7 étapes
Dessiner un parcours utilisateur prend un après-midi si vous résistez à deux tentations : partir des écrans au lieu des tâches, et dessiner de mémoire au lieu de partir du produit livré. La séquence ci-dessous met volontairement les données en premier : le diagramme ne vaut quelque chose que si vous pouvez vous y fier.
- Choisir une tâche et l'écrire en une phrase
- Nommer les points d'entrée et l'état final
- Lister les étapes intermédiaires, dans l'ordre
- Ajouter une décision partout où le produit oriente les utilisateurs différemment
- Parcourir le flux dans le produit en production et le corriger
- Associer un vrai chiffre à chaque étape
- Marquer ce que vous allez changer, et ce que vous laissez tel quel
1. Choisir une tâche et l'écrire en une phrase
Commencez par une phrase dans la langue de l'utilisateur : « En tant que nouvel admin, je veux les données de mon équipe dans l'espace de travail pour pouvoir lancer mon premier rapport. » Pas « parcours d'onboarding », pas « le module projets » : une tâche avec un début et une fin. La phrase fait un vrai travail : elle fixe le périmètre, nomme le persona et énonce le résultat que vous mesurerez ensuite. Les parcours échouent plus souvent parce qu'ils sont trop larges que parce qu'ils sont trop superficiels, et le remède est toujours le même : couper un parcours en deux.
2. Nommer les points d'entrée et l'état final
La plupart des parcours ont plus d'une porte d'entrée. Les utilisateurs arrivent sur « inviter un collègue » depuis un état vide, une page de paramètres, un rappel dans une checklist ou un lien dans un rapport partagé, et chaque porte les fait entrer avec un contexte et des attentes différents. Listez tous les points d'entrée, car une étape évidente depuis une porte paraît incohérente depuis une autre. Définissez ensuite l'état final assez précisément pour pouvoir le requêter : pas « l'utilisateur est onboardé », mais « l'invité a accepté et ouvert un projet partagé ». Si vous ne pouvez pas l'écrire sous forme de requête, vous ne pouvez pas savoir si le parcours fonctionne.
3. Lister les étapes intermédiaires, dans l'ordre
Écrivez maintenant le milieu en texte brut, une ligne par écran ou action, avant de dessiner quoi que ce soit. Le texte vous oblige à l'honnêteté : il est très facile de sauter une étape dans un diagramme, et très visible quand une liste passe de « clique sur Importer » à « voit les résultats ». Incluez les étapes qui appartiennent au produit plutôt qu'à l'utilisateur, comme un e-mail de confirmation ou une synchronisation en arrière-plan, car c'est pendant l'attente que les utilisateurs décident si quelque chose est cassé.
4. Ajouter une décision partout où le produit oriente les utilisateurs différemment
C'est l'étape qui distingue un parcours utilisateur d'une simple liste de tâches. Reprenez votre liste et demandez-vous à chaque ligne : deux utilisateurs pourraient-ils voir des choses différentes ici ? Les suspects habituels sont le rôle et les droits, le forfait et ses limites, les données vides ou remplies, les erreurs de validation, la première visite ou une visite de retour, et l'appareil. Chaque « oui » devient un losange avec une flèche étiquetée par issue, et chaque flèche doit atterrir quelque part, même si la destination honnête est un écran qui ne dit rien d'utile. C'est une découverte, pas une erreur de dessin.
5. Parcourir le flux dans le produit en production et le corriger
Ouvrez un compte réellement neuf et accomplissez la tâche vous-même, lentement, en notant chaque écran que vous rencontrez vraiment. Le produit livré compte toujours plus d'étapes que ce dont l'équipe se souvient : un écran intermédiaire ajouté pour une exigence de conformité, une modale restée d'un lancement d'il y a deux trimestres, un e-mail de vérification qui met désormais quatre-vingt-dix secondes à arriver. Regardez ensuite quelques enregistrements de sessions d'utilisateurs réels qui accomplissent la même tâche. Votre propre parcours vous donne la vraie structure ; les enregistrements vous montrent les hésitations, et c'est dans l'hésitation que le guidage a sa place.
6. Associer un vrai chiffre à chaque étape
Un parcours sans données est un diagramme d'opinions. Indiquez à côté de chaque nœud le nombre d'utilisateurs qui l'atteignent et le pourcentage qui continuent. Deux schémas comptent, et ils appellent des corrections opposées : un problème de découverte, quand peu d'utilisateurs atteignent un nœud, signifie que le point d'entrée est en cause : personne ne trouve la porte. Un problème d'exécution, quand beaucoup atteignent un nœud et peu en sortent, signifie que l'étape elle-même est trop difficile, trop floue ou trop exigeante à ce moment-là. Trompez-vous de diagnostic et vous passerez un sprint à embellir un écran que presque personne ne voit.
7. Marquer ce que vous allez changer, et ce que vous laissez tel quel
Terminez l'exercice en marquant au maximum trois nœuds sur le diagramme : la fuite que vous allez corriger, l'impasse à laquelle vous allez donner une vraie destination, et l'étape que vous allez purement et simplement supprimer. La suppression mérite sa propre ligne, car c'est le levier le plus puissant à disposition et celui que les équipes oublient : une étape supprimée ne pourra plus jamais embrouiller personne. Tout le reste du parcours est laissé tel quel, volontairement, et écrire « on garde » à côté est ce qui empêche l'exercice de se transformer en une refonte que personne n'a planifiée.
Le piège : dessiner le parcours que vous aimeriez avoir. Un parcours utilisateur assemblé à partir de la spécification et des maquettes sera net, court et faux, et faux précisément de la manière qui masque votre problème, car les étapes les plus susceptibles d'être oubliées (l'e-mail de vérification, la vérification des droits, l'état vide) sont exactement celles où les utilisateurs partent. Si le diagramme donne une meilleure image de votre produit que votre taux d'activation, vous avez dessiné le task flow par accident.
6 exemples de parcours utilisateur pour les produits SaaS
Plutôt qu'un modèle abstrait, voici les six parcours qui méritent le plus d'être dessinés dans un produit SaaS, avec la décision qui se cache généralement dans chacun. Dessinez-les dans cet ordre : ils sont classés selon leur impact direct sur le chiffre d'affaires.
1. De l'inscription à la première valeur
Le parcours qui décide de tout le reste : de la page de tarifs ou de la publicité jusqu'à la création du compte, la vérification, la configuration de l'espace de travail et la première action qui produit un vrai résultat. La décision cachée est presque toujours la vérification de l'e-mail, une étape qui sépare vos nouveaux utilisateurs entre ceux qui continuent et ceux qui retournent dans leur boîte de réception, se laissent distraire et ne reviennent jamais. Dessinez-la comme un losange à part entière et mettez un chiffre sur les deux branches. L'essentiel de ce que vous rapporte un parcours d'inscription bien conçu se perd à nouveau dans les quatre écrans qui suivent, c'est pourquoi le parcours ne doit pas s'arrêter à « compte créé ».
Deux losanges décident de l'essentiel du taux d'activation de ce produit : l'e-mail est-il vérifié, et l'espace de travail vide propose-t-il une action suivante ?
2. Configuration initiale d'un compte vide
Le parcours qui commence après l'inscription et se termine quand le compte contient assez de la réalité de l'utilisateur pour être utile : une intégration connectée, des enregistrements importés, un collègue invité, un projet configuré. C'est généralement un parcours sur plusieurs sessions, et c'est cette propriété qui fait échouer la plupart des conceptions : un utilisateur qui part à l'étape trois et revient le lendemain doit reprendre, pas recommencer. Cette seule exigence suffit à justifier une checklist d'onboarding plutôt qu'un assistant linéaire, et c'est sur le diagramme du parcours que cette forme multi-sessions devient impossible à ignorer.
3. Inviter un collègue
Faussement simple, et l'un des parcours les plus précieux de tout produit collaboratif, car un deuxième utilisateur dans un compte change complètement l'équation de la rétention. Il a aussi deux protagonistes, l'invitant et l'invité, et le parcours du second est celui qu'on oublie généralement de dessiner. C'est là que se concentrent les décisions cachées : l'invité a-t-il déjà un compte, reste-t-il des licences dans le forfait, arrive-t-il dans l'espace de travail auquel on l'a invité ou sur un écran d'accueil générique sans savoir pourquoi il est là ?
4. Découvrir et adopter une deuxième fonctionnalité
L'adoption au-delà de la première fonctionnalité n'arrive presque jamais par hasard, et ce parcours montre pourquoi : ses points d'entrée sont faibles. Personne ne se lève le matin avec l'envie d'utiliser votre module de reporting ; on y arrive par un élément de menu jamais cliqué, une annonce peut-être fermée, ou un moment de besoin que le produit n'a pas su repérer. Le dessiner révèle généralement que le parcours n'a en réalité aucun vrai point d'entrée, ce qui requalifie le problème en découverte de fonctionnalité plutôt qu'en utilisabilité, et oriente la solution vers un rappel contextuel plutôt qu'une refonte.
5. Atteindre une limite et passer à l'offre supérieure
Le parcours du chiffre d'affaires. Un utilisateur se heurte à un plafond de son forfait (licences, enregistrements, exports) et le produit décide à cet instant si le moment ressemble à une étape naturelle ou à un racket. Dessinez séparément chaque chemin vers le paywall, car le contexte fait tout : un utilisateur bloqué en pleine tâche a besoin d'un autre écran qu'un utilisateur qui compare les forfaits dans les paramètres. La décision qui mérite une étiquette, c'est ce qui se passe sur « pas maintenant », car cette branche détermine si vous aurez une conversion plus tard ou un compte perdu.
6. Se remettre d'une erreur
Le parcours que les équipes ne dessinent presque jamais, et celui où la confiance se joue vraiment. Import raté, session expirée, paiement refusé, conflit de synchronisation : chacun a un moment où le produit annonce à l'utilisateur que quelque chose s'est mal passé, et la question du parcours est de savoir vers quoi pointe la flèche qui sort de ce nœud. Si la réponse honnête est « vers rien : l'utilisateur est censé se débrouiller », vous avez trouvé un vrai défaut qu'aucun test d'utilisabilité du chemin idéal n'aurait jamais fait remonter.
Un raccourci qui vaut le coup. Si vous ne dessinez qu'un seul parcours, dessinez celui qui va de l'inscription au moment où l'utilisateur obtient pour la première fois un vrai résultat avec votre produit. Tout le reste de l'activité (activation, rétention, expansion) dépend de la praticabilité de ce chemin, et c'est le parcours où la suppression d'une seule étape a le plus de chances de se voir dans les chiffres du mois suivant.
Bonnes pratiques du parcours utilisateur : à faire, à éviter
✅ À faire
- Limiter chaque parcours à une tâche avec un état final vérifiable
- Dessiner de gauche à droite, un nœud par écran ou action
- Étiqueter chaque branche qui sort de chaque décision
- Inclure les points d'entrée : tous, pas seulement le principal
- Donner un nœud aux impasses pour qu'elles ne restent pas invisibles
- Parcourir le produit en production avant de faire confiance au diagramme
- Indiquer un vrai taux d'abandon à côté de chaque étape
- Dessiner des parcours distincts pour des segments vraiment différents
❌ À éviter
- Vouloir couvrir tout le produit dans un seul diagramme
- Ne dessiner que le chemin idéal et l'appeler parcours utilisateur
- Le confondre avec un plan de site, un wireframe ou un rapport d'entonnoir
- Le construire à partir de la spécification plutôt que du produit livré
- Inventer de nouveaux symboles qu'il faut apprendre à l'équipe
- Cacher les branches gênantes pour garder un schéma propre
- Laisser le diagramme se périmer après la release suivante
- Répondre à chaque fuite par « ajoutons une étape à la visite »
Du diagramme de parcours au parcours guidé
Un parcours utilisateur terminé vous livre deux choses : une liste d'étapes qui fuient, et un diagnostic de la raison de chaque fuite. Ces deux informations correspondent directement au type d'aide qui les corrige, et faire le bon rapprochement représente l'essentiel du savoir-faire, car la mauvaise intervention sur la bonne étape ne change toujours rien :
| Ce que montre le parcours | Le vrai problème | Ce qui le corrige |
|---|---|---|
| Peu d'utilisateurs atteignent un nœud | Découverte : personne ne trouve la porte | Un hotspot ou une annonce in-app au point d'entrée |
| Beaucoup arrivent, peu continuent | Exécution : l'étape est floue ou difficile | Un tooltip ou une courte visite produit à ce moment précis |
| Les utilisateurs partent et reviennent plus tard | Multi-sessions : la progression n'est pas mémorisée | Une checklist qui persiste et reprend là où chaque utilisateur s'est arrêté |
| Une branche ne mène nulle part | Un état non conçu | Une vraie destination et une explication contextuelle |
| Des segments différents bloquent à des nœuds différents | Un seul chemin pour plusieurs tâches | Des parcours ciblés par rôle ou par forfait |
C'est l'étape où la plupart des exercices de parcours utilisateur meurent en silence. Le diagramme est dessiné, les étapes qui fuient sont identifiées, puis les corrections rejoignent le backlog technique derrière tout le reste, si bien que le parcours est toujours exact un an plus tard, et c'est exactement le problème. Avec Kompassify, la couche de guidage se pose sur votre produit en production au lieu de dépendre de votre cycle de release :
- Guidez l'étape précise qui fuit. Créez une visite guidée, un tooltip ou un hotspot sur l'écran exact que votre parcours a signalé, dans un éditeur visuel posé sur votre vrai produit : sans code, sans déploiement.
- Donnez de la mémoire aux parcours multi-sessions. Une checklist d'onboarding suit la progression de chaque utilisateur : celui qui est parti à l'étape trois revient à l'étape quatre, pas au début.
- Envoyez des chemins différents à des personnes différentes. Ciblez le guidage par segment pour que les admins, les membres invités et les utilisateurs en essai reçoivent chacun le parcours que vous avez dessiné pour eux.
- Sauvez les impasses. Placez un message contextuel sur les branches que personne n'a conçues (l'espace de travail vide, le droit manquant, l'essai expiré) le temps que la vraie correction soit planifiée.
- Bouclez la boucle avec des chiffres. Les analytics intégrés montrent la complétion et l'abandon par étape, pour que la prochaine version du diagramme soit dessinée à partir de preuves plutôt que de souvenirs.
Kompassify est conforme au RGPD et hébergé dans l'UE, gratuit jusqu'à 100 utilisateurs actifs mensuels, avec des forfaits payants à partir de $129/mois.
Corrigez l'étape que votre parcours vient de révéler
Kompassify ajoute des visites produit, des checklists d'onboarding, des tooltips et des hotspots à votre produit existant (sans code, sans cycle de release), pour que le nœud qui fuit sur votre diagramme reçoive de l'aide cette semaine plutôt qu'au prochain trimestre. Ciblez par segment, suivez la complétion à chaque étape et vérifiez si la correction a fonctionné. Conforme au RGPD, hébergé dans l'UE et gratuit jusqu'à 100 utilisateurs actifs mensuels.
Commencer gratuitement →Questions fréquentes
Qu'est-ce qu'un parcours utilisateur (user flow) ?
Un parcours utilisateur, ou user flow, est la suite ordonnée d'écrans, d'actions et de décisions qu'une personne traverse pour accomplir une tâche précise dans votre produit : s'inscrire, inviter un collègue, publier son premier projet. On le dessine sous forme de diagramme : les points d'entrée en ovales, les écrans et les actions en rectangles, les décisions en losanges, et une flèche pour chaque déplacement possible entre eux. Contrairement à un wireframe, un parcours utilisateur ne dit rien de la mise en page ; contrairement à un entonnoir, il montre chaque embranchement et chaque impasse au lieu d'un seul pourcentage global. Son but est de rendre visible le chemin réel, pour voir où il bifurque, où il tourne en boucle et où il s'arrête sans bruit.
Quelle est la différence entre un parcours utilisateur et une journey map ?
Le périmètre et l'altitude. Un parcours utilisateur se situe dans le produit et reste mécanique : cet écran, ce clic, cette décision, pour une tâche dans une session. Une journey map (carte d'expérience) se situe autour du produit et parle d'émotions : elle suit un persona à travers les étapes et les canaux (une publicité, un appel de démo, la première connexion, un ticket de support, un renouvellement) et note ce qu'il pense et ressent à chaque étape. La journey map vous dit quelle étape fait mal ; le parcours utilisateur vous dit quel clic en est la cause. La plupart des équipes ont besoin des deux, généralement dans cet ordre : cartographier l'expérience pour trouver l'étape douloureuse, puis dessiner le parcours utilisateur de la tâche concernée pour trouver l'étape à corriger.
Quels symboles utilise-t-on dans un diagramme de parcours utilisateur ?
La notation vient des logigrammes et reste volontairement réduite. Un ovale ou une pilule arrondie marque un point d'entrée ou un état final. Un rectangle représente un écran que l'utilisateur voit ou une action qu'il effectue. Un losange est une décision, une bifurcation avec une branche étiquetée pour chaque issue, y compris les mauvaises. Un parallélogramme indique des données qui entrent ou sortent, comme l'envoi d'un formulaire ou un lien reçu par e-mail. Les flèches indiquent le sens de la progression, et chaque flèche qui sort d'un losange doit porter la condition qui y envoie l'utilisateur. Tout ce qui dépasse ces cinq formes coûte en général plus en explications qu'il n'apporte en précision.
Comment créer un parcours utilisateur ?
Partez d'une tâche, pas d'un écran : choisissez une chose que l'utilisateur cherche à accomplir, puis nommez les points d'entrée qui y mènent et l'état final qui la conclut. Listez les étapes nécessaires entre les deux, puis ajoutez un losange de décision partout où le produit peut envoyer des utilisateurs différents à des endroits différents : droits d'accès, limites du forfait, comptes vides, erreurs de validation. Dessinez de gauche à droite, étiquetez chaque branche, puis parcourez le flux dans votre produit en production et corrigez-le, car le produit livré compte toujours plus d'étapes que ce dont tout le monde se souvient. Enfin, placez vos données d'analytics produit à côté pour que chaque étape porte un vrai taux d'abandon, et marquez les étapes que vous voulez changer.
Quels sont des exemples de parcours utilisateur dans un produit SaaS ?
Les parcours à dessiner en premier sont ceux qui décident du chiffre d'affaires : de l'inscription à la première valeur, la configuration initiale d'un compte vide, l'invitation d'un collègue, la découverte et l'adoption d'une deuxième fonctionnalité, l'atteinte d'une limite du forfait et le passage à l'offre supérieure, et la reprise après une erreur ou un import raté. Chacun a une tâche claire, un état final mesurable et au moins une décision qui envoie discrètement des utilisateurs dans une impasse : un e-mail non vérifié, un espace de travail vide, un droit que l'invitant n'avait pas, un écran de mise à niveau sans aucune explication sur ce qui a changé.
Quelle est la différence entre un task flow et un parcours utilisateur ?
Un task flow est le chemin idéal unique à travers une tâche : une seule ligne, aucun embranchement, la version qu'un designer montrerait en démo. Un parcours utilisateur garde les embranchements : différents points d'entrée, différents segments d'utilisateurs, différentes décisions, et les chemins que prennent les gens quand quelque chose échoue. Les task flows servent à rédiger une spécification ou un test du chemin idéal ; les parcours utilisateur sont ce qu'il vous faut quand vous cherchez à expliquer pourquoi l'activation stagne, car les utilisateurs bloqués ne sont presque jamais sur le chemin idéal.
Comment transformer un parcours utilisateur en guidage dans le produit ?
Une fois le parcours dessiné et chaque étape associée à un taux d'abandon, vous savez exactement où l'utilisateur a besoin d'aide, et de quel type. Une étape que les gens n'atteignent jamais demande de la découverte : un hotspot ou une annonce. Une étape que les gens atteignent puis abandonnent demande une explication à ce moment précis : un tooltip ou une courte visite produit. Un parcours sur plusieurs sessions demande une checklist qui mémorise la progression. Avec une plateforme no-code comme Kompassify, vous construisez chacun de ces éléments par-dessus votre produit en production dans un éditeur visuel, vous les ciblez sur le segment qui bloque et vous publiez sans cycle de release. Kompassify est conforme au RGPD et hébergé dans l'UE, gratuit jusqu'à 100 utilisateurs actifs mensuels, avec des forfaits payants à partir de $129/mois.