Mon article en bref
Le story mapping, ou user story mapping, est une technique de cadrage produit qui range les user stories sur deux axes : le parcours de l’utilisateur à l’horizontale, la priorité à la verticale. Formalisée par Jeff Patton, elle corrige un défaut du backlog en liste : une fois les éléments empilés, on ne voit plus le récit qu’ils composent.
Voici les points essentiels à retenir :
- Définition : une carte à deux dimensions qui replace chaque user story dans le parcours utilisateur qu’elle sert.
- Origine : Jeff Patton, dès 2005, puis sous sa forme actuelle en 2008 et dans son livre en 2014.
- Les deux axes : à l’horizontale l’ordre du récit d’usage, à la verticale la priorité — de l’indispensable au confort.
- Le vrai produit de l’atelier : le découpage en tranches de livraison, pas la carte elle-même.
- À ne pas confondre : une story map organise ce qu’il faut construire, une customer journey map documente ce que vit un client.
- Comment faire : un atelier de deux à quatre heures, en équipe complète, du récit vers les tâches puis vers les tranches.
Le story mapping, ou user story mapping, est une technique de cadrage agile qui organise les user stories d’un produit sur deux axes : à l’horizontale, l’ordre dans lequel l’utilisateur traverse le produit ; à la verticale, la priorité de chaque élément. Le résultat s’appelle une story map.
On rencontre aussi les traductions « carte des récits utilisateur » et « carte des parcours utilisateur », même si l’anglicisme reste dominant dans les équipes francophones. Voyons d’où vient la méthode, comment se lit une carte, comment animer l’atelier, et à quoi ressemble concrètement une story map terminée.
Sommaire
Qu’est-ce que le story mapping ? Définition
Une story map se lit comme une frise : chaque colonne correspond à un moment du parcours, placé dans l’ordre où il se produit réellement. C’est la différence de fond avec un backlog produit classique, qui range les éléments par priorité et perd du même coup cette chronologie. La carte porte donc une information que la liste ne peut pas contenir : le contexte d’usage de chaque story.
L’objectif n’est pas esthétique. Il s’agit de rendre visibles deux choses qu’une liste dissimule : ce qui manque au produit, et ce qu’il faut livrer en premier pour qu’il soit utilisable de bout en bout. Tout le reste — les post-it, les couleurs, les outils — n’est qu’un support de cette lecture.
D’où vient le story mapping ?
La technique est attribuée à Jeff Patton, consultant et coach produit. Il en formule les principes dès 2005 dans un article intitulé It’s All in How You Slice It, puis décrit la pratique sous sa forme actuelle en 2008 dans The new user story backlog is a map. Le glossaire de l’Agile Alliance retient cette double filiation. L’ouvrage de référence, User Story Mapping, paraît en 2014 et diffuse largement le vocabulaire employé aujourd’hui.
Le problème qu’il résout : le backlog plat
Un backlog est une liste ordonnée. Cette forme répond très bien à la question « sur quoi travaille-t-on ensuite ? », mais mal à deux autres, que toute équipe finit par se poser : qu’avons-nous oublié ? et que livre-t-on d’abord pour que le produit tienne debout ? Patton résume le défaut par une image parlante : on arrache toutes les feuilles de l’arbre, on les met dans un sac, puis on coupe l’arbre. Les user stories sont toujours là, mais la structure qui leur donnait un sens a disparu.
Le second symptôme est la fatigue de priorisation. Arbitrer entre cent vingt lignes prises une par une est un exercice épuisant et peu fiable, parce qu’aucune ligne ne dit à quel moment du parcours elle intervient. Remettre ces mêmes lignes sur une carte fait apparaître des groupes évidents, et l’arbitrage porte alors sur des ensembles cohérents.
Un backlog dit dans quel ordre travailler. Une story map dit à quoi ressemblera le produit une fois ce travail fait.
En vidéo : le principe du story mapping expliqué en quelques minutes (chaîne Best Of Business Analyst).
Comment se lit une story map : backbone, corps et tranches
Une story map s’organise en trois couches, toujours les mêmes. En haut, la colonne vertébrale — le backbone — qui énonce les grandes activités de l’utilisateur. En dessous, les tâches puis les stories qui réalisent chaque activité. Et en travers, des lignes horizontales qui découpent l’ensemble en tranches de livraison.
L’axe horizontal : le récit d’usage
Le backbone se construit en racontant l’usage à voix haute. Patton parle de narrative flow, de flux narratif : le bon ordre est celui dans lequel on expliquerait le comportement du produit à quelqu’un qui ne le connaît pas. Ces grandes activités correspondent le plus souvent à ce qu’une équipe agile appellerait des epics, à ceci près qu’elles sont ici ordonnées dans le temps et non par importance.
Cette ligne du haut mérite d’être solide, car tout le reste s’y accroche. Le Nielsen Norman Group recommande d’ailleurs de l’alimenter avec de la recherche exploratoire sur les tâches principales de l’utilisateur : sans cela, le backbone reste une hypothèse d’équipe, formulée depuis l’intérieur de l’organisation.
L’axe vertical : de l’indispensable au confort
Sous chaque colonne, les éléments descendent par ordre de nécessité décroissante : en haut ce sans quoi l’activité est impossible, plus bas les variantes, les cas particuliers et les améliorations. La première ligne complète porte un nom précis chez Patton, le walking skeleton — le squelette qui marche : le plus petit système capable de faire traverser tout le parcours à un utilisateur. C’est de là qu’un MVP défendable sort naturellement, et non d’une addition des fonctionnalités jugées les plus séduisantes.
Story map, customer journey map, backlog : ne pas confondre
La confusion est fréquente, parce que ces trois objets parlent de parcours ou de contenu produit. Leur différence tient à ce qu’ils décrivent et à ce qu’on en tire :
| Outil | Ce qu’il représente | Ce qu’on en tire |
|---|---|---|
| Story map | Les stories à construire, rangées le long du parcours d’usage | Un découpage en livraisons utilisables |
| Customer journey map | Le vécu d’un client, points de contact et ressentis inclus | Des points de friction à corriger |
| Backlog produit | Une liste ordonnée d’éléments à traiter | Le prochain travail de l’équipe |
Retenons la distinction principale : la customer journey map documente une expérience vécue, la story map organise un produit à construire. Les deux se complètent très bien — une friction repérée sur la première devient une colonne à renforcer sur la seconde — mais elles ne se substituent pas l’une à l’autre.
Comment faire un story mapping ? L’atelier étape par étape
Le story mapping est un atelier collectif, pas un livrable à produire seul devant un écran. Comptez deux à quatre heures pour une première carte sur un périmètre délimité, et prévoyez de la reprendre : une carte se construit rarement bien du premier coup. Six étapes suffisent à la mener.
- Cadrer le périmètre et l’utilisateur — une carte, un type d’utilisateur, un objectif. Les éléments issus du product discovery servent de matière première.
- Dérouler le récit à voix haute — poser les grandes activités de gauche à droite, sans entrer dans le détail. C’est le backbone, et il doit se lire comme une histoire.
- Décomposer en tâches — sous chaque activité, ce que l’utilisateur fait concrètement. Ces tâches seront reformulées en user stories plus tard, pas maintenant.
- Chercher les manques — relire la frise colonne par colonne et traquer les étapes sautées, les cas d’erreur absents, les colonnes anormalement vides.
- Prioriser à la verticale — remonter l’indispensable, descendre le confort. Une grille comme la priorisation MoSCoW aide à trancher les cas litigieux.
- Découper en tranches de livraison — tirer un trait horizontal sous la première ligne utilisable, puis d’autres en dessous. C’est l’étape qui donne à l’exercice toute sa valeur.
💡 Le test de la tranche — prenez une tranche et demandez-vous si un utilisateur pourrait aller au bout de son parcours avec seulement ce qu’elle contient. Si la réponse est non, ce n’est pas une livraison : c’est un lot de travaux.
Qui participe à un atelier de story mapping ?
L’équipe au complet, et pas seulement ceux qui écrivent les stories. Le Product Owner apporte l’intention métier et arbitre l’axe vertical ; les développeurs signalent les dépendances techniques et les colonnes plus coûteuses qu’elles n’en ont l’air ; un profil design garantit que le récit correspond à un usage réel et non à un enchaînement d’écrans. Au-delà de huit à dix participants, la carte se construit encore, mais la conversation se dilue — et c’est bien la conversation qui produit la compréhension partagée, pas le mur de post-it.
Au mur ou dans un outil en ligne ?
Le format d’origine est physique : un mur, des post-it, une équipe debout. Les outils de tableau blanc collaboratif comme Miro, FigJam ou Mural reproduisent fidèlement la structure à deux axes, et certains greffons de suivi de projet — pour Jira notamment — affichent le backlog directement sous forme de carte. Le choix dépend surtout de la géographie de l’équipe : le mur reste plus rapide et plus engageant en présentiel, l’outil devient indispensable dès qu’une partie des participants est à distance. Dans les deux cas, la carte doit rester facile à modifier, sinon elle cesse très vite d’être consultée.
Story map : un exemple concret et les pièges à éviter
Prenons un cas volontairement simple, à titre d’illustration : une application de commande de repas en ligne. Le backbone se lit de gauche à droite, exactement dans l’ordre où un utilisateur traverse le service :
- Trouver un restaurant — recherche par nom, filtres par type de cuisine ou par distance, consultation d’une fiche.
- Composer sa commande — parcourir la carte, ajouter des plats, choisir les options et les quantités.
- Valider et payer — récapitulatif, adresse de livraison, choix du moyen de paiement.
- Suivre la livraison — confirmation, estimation d’arrivée, statut de la course.
- Donner son avis — noter le restaurant, commenter, signaler un problème.
C’est en relisant cette frise que les trous apparaissent. La colonne « Valider et payer » ne prévoit rien en cas d’échec de paiement ; « Suivre la livraison » ne dit pas ce qui se passe si la commande arrive incomplète. Ces manques sont invisibles dans un backlog trié par priorité, pour une raison simple : un élément absent n’y laisse aucune trace. Sur une carte, il laisse une colonne vide, et le vide se voit.
Vient ensuite le découpage horizontal, qui transforme la carte en plan de livraison :
- Tranche 1, le squelette qui marche — chercher un restaurant par son nom, ajouter un plat, payer par carte, recevoir une confirmation. Un utilisateur peut aller au bout : le produit existe.
- Tranche 2, l’usage réel — filtres de recherche, suivi de livraison, gestion de l’échec de paiement. Le produit devient utilisable au quotidien.
- Tranche 3, le confort et la fidélisation — favoris, avis, commande récurrente, parrainage.
Ces trois tranches sont trois livraisons possibles, et chacune se tient toute seule. C’est l’inverse exact du découpage par couche technique — d’abord la base de données, ensuite les écrans, enfin les paiements — qui ne produit rien de testable avant la toute fin du projet.
Les pièges les plus fréquents
- Cartographier l’organisation plutôt que l’utilisateur — quand le backbone reprend les services de l’entreprise, la carte redevient un organigramme déguisé.
- Tout détailler d’emblée — écrire les stories des lignes basses est du travail perdu : elles auront changé avant d’être développées, si elles le sont un jour.
- Découper les tranches par couche technique — une tranche qui ne contient que du back-end n’est pas une livraison, seulement un jalon interne.
- Confondre la carte et la roadmap — une story map ordonne, elle ne date pas. Y ajouter des échéances la transforme en engagement de planning.
- Laisser la carte se figer — une carte qu’on ne met plus à jour devient une décoration, et les décisions repartent dans le backlog.
Une carte vivante, pas un poster
La story map n’est pas un livrable à archiver : c’est un support de travail qui vit au rythme du produit. Chaque session de backlog refinement est une occasion de la corriger, de descendre ce qui s’est révélé secondaire et de remonter ce que les utilisateurs réclament. Sur ce point mon avis est net : la valeur d’un atelier de story mapping se mesure aux désaccords qu’il fait remonter, pas à la propreté du mur qui en sort. Une carte sur laquelle tout le monde s’est accordé en quarante minutes est presque toujours une carte qui n’a rien creusé.
FAQ — Tout savoir sur le story mapping
Le story mapping, c’est quoi exactement ?
C’est une technique de cadrage agile qui dispose les user stories d’un produit sur deux axes : l’ordre du parcours utilisateur à l’horizontale, la priorité à la verticale. La carte obtenue, appelée story map, montre d’un seul coup d’œil ce que fait le produit et dans quel ordre le construire.
Quel est le but du story mapping ?
Rendre visible ce qu’une liste dissimule : les étapes du parcours qu’on a oubliées, et le plus petit ensemble de stories qui rend le produit utilisable de bout en bout. Le but final est donc un découpage en livraisons cohérentes, pas la carte elle-même.
Qui anime un atelier de story mapping ?
Le plus souvent le Product Owner ou un facilitateur agile, avec l’équipe au complet autour de la carte. L’animateur fait dérouler le récit et relance sur les manques ; il n’arbitre pas seul les priorités, qui se décident collectivement avec l’intention métier portée par le Product Owner.
Quelle différence entre story mapping et customer journey map ?
La customer journey map documente l’expérience vécue par un client, ses points de contact et ses ressentis, sur un périmètre souvent plus large que le produit. La story map, elle, organise les stories à construire le long du parcours d’usage. La première sert à comprendre, la seconde à découper le travail.
Quels outils pour faire une story map ?
Un mur et des post-it suffisent, et restent le format le plus rapide en présentiel. À distance, les tableaux blancs collaboratifs comme Miro, FigJam ou Mural reproduisent la structure à deux axes, et certains greffons affichent un backlog Jira sous forme de carte. Le critère décisif est la facilité à modifier la carte.
Le story mapping est-il réservé aux projets informatiques ?
Non. La méthode s’applique à toute situation où un utilisateur traverse une suite d’étapes : un parcours d’achat en ligne, un processus d’inscription, un service interne, une refonte de site. Il faut simplement pouvoir raconter l’usage comme une histoire, du début à la fin.
