Qu’est-ce qu’un user flow ? Définition et méthode

Un user flow, ou flux utilisateur, est un diagramme qui représente le chemin emprunté par un utilisateur pour atteindre un objectif précis dans un produit numérique, en explicitant à chaque étape les décisions qu’il doit prendre et les embranchements qui en découlent. En français, on parle de parcours utilisateur.

Cette nuance porte tout le reste. Un user flow n’est pas la liste ordonnée des écrans d’une application : c’est la carte des choix que l’interface impose. Un diagramme qui n’aligne qu’une file d’écrans est un plan de site déguisé — il ne dit ni où l’on hésite, ni ce qui se passe quand on se trompe. Voici comment en construire un, et comment le distinguer des deux livrables avec lesquels il est le plus souvent confondu.

Qu’est-ce qu’un user flow ?

Le user flow — également appelé UX flow, user flow diagram ou simplement flowchart — sert d’abord à raisonner avant de dessiner. Il se lit de gauche à droite ou de haut en bas, et chaque bifurcation y matérialise une question posée à l’utilisateur : est-il connecté ? a-t-il déjà un panier ? son paiement a-t-il abouti ? Répondre à ces questions sur un diagramme prend quelques minutes ; y répondre pendant la recette coûte un sprint.

Sa vocation est donc de révéler la complexité avant qu’elle ne soit codée. C’est un livrable de conception, produit pendant le product discovery, entre la recherche utilisateur et les premières maquettes. Il concerne autant le product manager que le designer : le premier y vérifie que les règles métier tiennent, le second que le chemin reste praticable.

Les quatre symboles d’un user flow

La notation est empruntée à l’organigramme de programmation et tient en quatre formes, dont la lecture doit être immédiate pour toute l’équipe :

• L’ovale — le point d’entrée et le point de sortie. Un flow sans début explicite ne peut pas être testé.
• Le rectangle — un écran, une page, ou une action réalisée par l’utilisateur.
• Le losange — une décision, avec autant de flèches sortantes qu’il existe d’issues. C’est lui qui fait la valeur du diagramme.
• La flèche — la transition, étiquetée par la condition qui la déclenche : « oui », « non », « champ vide », « paiement refusé ».

Un objectif par flow, pas une application entière

L’erreur de cadrage la plus fréquente consiste à vouloir cartographier un produit complet sur une seule planche : le résultat est illisible et personne ne l’ouvre deux fois. La règle est donc simple — un user flow, un objectif utilisateur : « créer un compte », « retrouver une facture », « annuler une commande ». Ces objectifs ne sont pas à inventer, ils se lisent dans les user stories du backlog, dont une bonne formulation énonce déjà le résultat visé.

User flow, customer journey map ou wireframe : ne pas les confondre

C’est la source de confusion principale, et elle n’est pas anodine : les trois livrables se ressemblent parce qu’ils parlent tous d’utilisateurs, mais ils ne répondent pas à la même question et n’interviennent pas au même moment du projet.

Livrable	Ce qu’il décrit	Échelle	La question à laquelle il répond
User flow	Les étapes et les décisions à traverser pour atteindre un objectif dans le produit	Une tâche, dans une interface	« Par où passe-t-on, et que se passe-t-il si l’on bifurque ? »
Customer journey map	L’expérience globale d’un client, canaux et ressentis compris, avant et après le produit	Une relation, sur des semaines ou des mois	« Que vit cette personne, et où souffre-t-elle ? »
Wireframe	La structure et la hiérarchie du contenu d’un écran unique	Un écran	« Qu’est-ce qu’on voit, et où est-ce placé ? »

Le customer journey map et le wireframe font chacun l’objet d’un article dédié sur ce site : inutile de les redécrire ici. Retenez la règle de bascule. Le journey map se lit dans le temps — avant, pendant, après, sur plusieurs canaux. Le user flow se lit dans la logique — si ceci, alors cela. Le wireframe se lit dans l’espace d’un écran. Le Nielsen Norman Group trace la même frontière en opposant l’expérience holistique du journey aux interactions discrètes du flow.

Les trois ne s’excluent donc pas, ils s’enchaînent : le journey map désigne le moment qui coince, le user flow détaille sa mécanique, le wireframe habille chacun de ses écrans.

Le wireflow, quand les deux se combinent

Lorsqu’une équipe a besoin des deux à la fois — l’enchaînement et le contenu des écrans — elle produit un wireflow : des wireframes reliés par des flèches conditionnelles. Le Nielsen Norman Group décrit ce format hybride comme la réponse aux applications où l’affichage change sans que la page change. Il coûte plus cher à maintenir : on le réserve aux parcours critiques, une fois le user flow stabilisé.

Comment faire un user flow, étape par étape

La construction demande une heure ou deux, à plusieurs. Six étapes suffisent, et l’ordre compte.

1. Choisir l’objectif et le formuler côté utilisateur — « obtenir un remboursement », et non « développer l’écran de remboursement ».
2. Identifier le point d’entrée réel — un e-mail, une recherche Google, une notification, un lien profond, un menu interne.
3. Lister les étapes du chemin nominal — le trajet quand tout se passe bien, sans chercher l’exhaustivité à ce stade.
4. Placer les décisions — à chaque étape, demander « qu’est-ce qui peut différer d’un utilisateur à l’autre ? ». Chaque réponse devient un losange.
5. Tracer les chemins alternatifs et les échecs — l’étape que l’on saute presque toujours, et qui fait tout l’intérêt du diagramme.
6. Faire relire par un développeur — il repérera les états que l’interface ne sait pas produire et les règles métier manquantes.

Partir d’un objectif utilisateur, pas d’une fonctionnalité

Un flow construit autour d’une fonctionnalité décrit le logiciel ; construit autour d’un objectif, il décrit une intention. La différence se voit dès le premier nœud : « l’utilisateur ouvre l’écran de paiement » suppose déjà qu’il l’a trouvé, quand « l’utilisateur veut payer » oblige à se demander comment il y parvient. La grille QQOQCP aide à poser cette intention, et la spec produit recueille les règles que le diagramme aura mises au jour.

Le point d’entrée change tout le reste

Un même objectif produit deux diagrammes différents selon la porte empruntée. Celui qui arrive par un lien reçu par e-mail est peut-être déconnecté, sur mobile, et n’a jamais vu la page d’accueil ; celui qui passe par le menu interne est connecté et a du contexte. Ne cartographier qu’un point d’entrée — presque toujours celui du chemin idéal — est la cause la plus banale d’un parcours qui casse en production.

Où l’utilisateur peut-il se perdre ?

C’est la question que la plupart des méthodes laissent de côté : elles apprennent à dessiner le chemin, pas à repérer les endroits où il se dérobe. Or un losange mal posé produit un blocage qu’aucune maquette isolée ne révèle, parce qu’il ne se voit qu’en regardant les branches ensemble.

Les quatre pièges d’un embranchement

• La décision que l’utilisateur ne peut pas prendre — le diagramme lui demande de choisir entre deux options dont il n’a pas de quoi juger. Le losange est correct ; c’est l’information qui manque en amont.
• Le cul-de-sac — une flèche entre dans un écran, aucune n’en sort. Cela se repère en dix secondes sur un diagramme, et jamais sur une maquette prise séparément.
• La boucle silencieuse — le formulaire refuse la saisie et renvoie au même écran sans dire ce qui a changé. La personne repasse deux ou trois fois, puis renonce.
• La décision déguisée en information — un écran intermédiaire qui n’existe que pour être lu, et que tout le monde traverse sans le lire.

Ces quatre motifs se détectent en relisant le diagramme à l’envers, depuis l’objectif atteint : chaque nœud doit alors justifier son existence. Un écran qui ne fait ni décider, ni saisir, ni confirmer n’a rien à faire là.

Confronter le diagramme aux parcours réels

Un user flow reste une hypothèse jusqu’à ce qu’on le compare à ce que font vraiment les gens. Les outils d’analytique produit — Pendo en est un exemple courant — montrent à quelle étape le taux de passage chute et quelles branches ne sont jamais empruntées : ils disent où. Le retour client et l’observation directe disent pourquoi.

Un user flow ne se juge pas sur son chemin principal, mais sur ce qu’il prévoit lorsque ce chemin échoue.

Que se passe-t-il en cas d’erreur ?

Un diagramme qui ne décrit que le succès ne décrit qu’une partie des sessions. Les chemins non nominaux — erreurs de saisie, échecs techniques, états vides — concentrent l’essentiel du travail d’implémentation et des tickets de support. Les poser revient à trancher à froid ce qui sera sinon décidé dans l’urgence par celui qui code.

Trois familles de chemins non nominaux

• L’erreur de l’utilisateur — champ mal rempli, mot de passe faux, format refusé. Le diagramme doit dire où la personne retombe, ce qu’elle conserve de sa saisie et ce que le message lui indique. Le Nielsen Norman Group rappelle qu’un message d’erreur utile nomme le problème et propose une sortie, au lieu d’afficher un code.
• L’échec du système — service de paiement indisponible, délai dépassé, session expirée. La question à trancher est courte et presque toujours oubliée : la personne reprend-elle là où elle en était, ou tout est-il perdu ?
• L’état vide — aucun résultat, panier vide, premier accès sans donnée. Ce n’est pas une erreur mais un écran à part entière, et souvent le premier qu’un nouvel utilisateur découvre.

Exemple : les sorties d’un flow de connexion

Prenons l’objectif « se connecter à son compte ». Le chemin nominal tient en trois cases. Le diagramme complet en compte bien davantage : identifiant inconnu, mot de passe erroné, compte non vérifié, compte verrouillé après plusieurs tentatives, code à usage unique jamais reçu, session expirée pendant la saisie. Chacune de ces issues est une flèche sortante, donc un écran à concevoir et un message à écrire — et ces six branches se traduisent presque mot pour mot en acceptance criteria vérifiables. Leur absence explique une bonne part des allers-retours entre développement et recette.

À mon sens, c’est le seul critère qui sépare un user flow utile d’un joli schéma : s’il ne contient aucun chemin d’échec, il n’a pas commencé à servir. Reste à le tenir à jour, car un diagramme périmé est plus dangereux qu’un diagramme absent — après la mise en production d’un MVP, les branches réellement empruntées ne sont plus celles qu’on avait prévues.

FAQ — Tout savoir sur le user flow

Comment dit-on « user flow » en français ?

On dit flux utilisateur ou, plus couramment, parcours utilisateur. « Parcours utilisateur » reste ambigu à l’oral, car il sert aussi à traduire user journey : dans un contexte de conception d’interface, préciser « flux utilisateur » ou garder le terme anglais évite le malentendu.

Quelle différence entre user flow et user journey ?

Le user journey décrit l’expérience globale d’une personne dans le temps et sur tous les canaux, ressentis compris. Le user flow zoome sur une tâche unique à l’intérieur du produit et en détaille la mécanique, décision par décision. Le premier sert à choisir où agir, le second à concevoir la solution.

Quelle différence entre user flow et wireframe ?

Le user flow montre l’enchaînement entre les écrans et les conditions qui font passer de l’un à l’autre ; le wireframe montre l’intérieur d’un seul écran, sa structure et la hiérarchie de son contenu. Le premier est horizontal, le second vertical. Combinés, ils donnent un wireflow.

Quelle différence entre user flow et task flow ?

Un task flow décrit une séquence unique et linéaire, sans embranchement : le chemin que tout le monde suit pour accomplir une tâche donnée. Le user flow, lui, admet des décisions et donc plusieurs issues. Le task flow est en pratique le squelette du user flow avant l’ajout des losanges.

Avec quel outil faire un user flow ?

N’importe quel outil de diagramme collaboratif convient : Figma et FigJam, Miro, Whimsical, Lucidchart, draw.io, ou un simple tableau blanc photographié. Le choix pèse peu ; ce qui compte est que le diagramme soit accessible à toute l’équipe et modifiable en réunion, sans passer par son auteur.

Qui réalise le user flow dans une équipe produit ?

Le plus souvent l’UX designer ou le product designer, parfois le product owner ou le product manager quand les règles métier dominent. Dans les faits, il gagne à être construit à deux ou trois, designer et développeur compris : c’est ce dernier qui repérera les états impossibles à produire.

À quoi ressemble un exemple de user flow ?

Un exemple typique tient sur une planche : un ovale « l’utilisateur reçoit un e-mail de relance », un rectangle par écran traversé, deux ou trois losanges (« est-il connecté ? », « son panier est-il encore valide ? », « le paiement aboutit-il ? »), et une flèche étiquetée par branche, y compris vers les écrans d’erreur et de panier vide.