Une user story sert à formuler un besoin utilisateur de façon simple, compréhensible et actionnable par une équipe agile. Si vous cherchez un exemple de user story, le plus utile n’est pas de copier un modèle à l’identique, mais de comprendre pourquoi il fonctionne, comment il se découpe et quels critères d’acceptation permettent de le valider sans ambiguïté.
Ce qu’une user story décrit vraiment
Une user story, ou récit utilisateur, est une petite unité de travail centrée sur la valeur attendue par un utilisateur. Elle ne décrit pas d’abord une solution technique, mais un besoin dans un contexte donné. C’est ce qui la rend utile dans un backlog produit : elle aide le Product Owner, les développeurs, les designers et les parties prenantes à parler du même objectif.
Quiz : Maîtriser les User Stories
Le format le plus courant est le suivant : En tant que [persona], je veux [objectif], afin de [bénéfice]. Cette structure oblige à préciser trois éléments essentiels : qui est concerné, ce que cette personne veut accomplir et pourquoi cela a de la valeur. Elle évite aussi les formulations floues, parce qu’elle ramène chaque demande à un besoin réel.
User story, spécification fonctionnelle et tâche : ne pas tout mélanger
Une user story n’est pas une spécification fonctionnelle détaillée. Elle ouvre une conversation et cadre une intention. La spécification, elle, peut préciser les règles métier, les cas limites, les contraintes d’interface ou les dépendances. Une tâche technique, de son côté, décrit souvent le travail à faire pour livrer la story : créer une API, modifier une base de données, écrire un test automatisé.
| Élément | Rôle principal | Exemple |
|---|---|---|
| User story | Décrire un besoin utilisateur | En tant que client, je veux suivre ma commande afin de savoir quand elle arrivera. |
| Epic | Regrouper plusieurs stories autour d’un grand objectif | Gestion du suivi de livraison. |
| Tâche | Découper le travail de réalisation | Créer l’événement de mise à jour du statut de livraison. |
| Spécification | Détailler les règles et comportements attendus | Le statut doit être mis à jour à chaque changement transmis par le transporteur. |
Exemples concrets de user stories à adapter
Un bon exemple de user story doit être assez précis pour guider l’équipe, mais pas au point de fermer la discussion. Voici plusieurs cas utilisables comme base, avec leur contexte et leurs critères d’acceptation. L’idée est de partir d’un besoin clair, puis de vérifier ce que l’équipe doit pouvoir observer ou tester.
Exemple e-commerce : suivre une commande
User story : En tant que client ayant passé une commande, je veux consulter son statut de livraison afin de savoir si je dois être présent le jour de la réception.
Critères d’acceptation :
- Le client voit le statut actuel de sa commande depuis son espace personnel.
- Les statuts affichés sont compréhensibles : commande préparée, expédiée, en livraison, livrée.
- Si un lien de suivi transporteur existe, il est accessible depuis la page de commande.
- En cas d’indisponibilité du suivi, un message clair indique que l’information sera mise à jour prochainement.
Exemple SaaS : inviter un membre dans une équipe
User story : En tant qu’administrateur d’un espace de travail, je veux inviter un nouveau membre par e-mail afin qu’il puisse accéder aux projets de l’équipe.
Critères d’acceptation :
- L’administrateur peut saisir une adresse e-mail valide.
- Le nouvel utilisateur reçoit une invitation contenant un lien d’activation.
- L’invitation expire si elle n’est pas utilisée après un délai défini par l’équipe produit.
- L’administrateur voit le statut de l’invitation : envoyée, acceptée ou expirée.
Exemple mobile : reprendre une action interrompue
User story : En tant qu’utilisateur mobile, je veux retrouver mon formulaire prérempli après une interruption afin de ne pas recommencer ma saisie depuis le début.
Critères d’acceptation :
- Les champs déjà saisis sont conservés si l’application est fermée puis rouverte.
- L’utilisateur est informé que ses informations ont été sauvegardées temporairement.
- Les données sensibles ne sont pas affichées sans protection adaptée.
- Si la sauvegarde échoue, un message prévient l’utilisateur avant qu’il quitte l’écran.
La méthode pour rédiger une user story efficace
La rédaction commence rarement par la phrase elle-même. Avant de remplir le modèle, clarifiez le persona, le contexte d’usage et le résultat attendu. Une user story trop vague produit un backlog difficile à prioriser ; une story trop technique risque de perdre le lien avec la valeur utilisateur. Le bon niveau de détail se situe entre les deux.
Partir du persona, pas de l’écran à créer
Écrire “En tant qu’utilisateur” peut suffire pour un brouillon, mais ce persona reste souvent trop large. Un client régulier, un administrateur, un agent logistique, un manager RH ou un visiteur non connecté n’ont pas les mêmes contraintes. Plus le persona est précis, plus les discussions deviennent concrètes : fréquence d’usage, niveau d’autonomie, urgence du besoin, risques en cas d’erreur.
Pensez à une équipe qui construit un radeau : si chacun attache sa planche sans savoir qui doit monter dessus, combien de courant il faudra affronter et quelle rive atteindre, l’assemblage peut sembler solide tout en dérivant au premier remous. Une user story joue ce rôle de point d’amarrage. Elle relie la fonctionnalité à une personne, à une situation et à une destination mesurable. Sans ce repère, le backlog flotte, les priorités se déplacent et l’équipe confond facilement activité produite et valeur livrée.
Ajouter des critères d’acceptation testables
Les critères d’acceptation indiquent à quelles conditions la user story peut être considérée comme terminée. Ils évitent les malentendus au moment du sprint planning, du développement ou de la recette. Ils doivent être observables : “l’expérience doit être fluide” est trop subjectif ; “l’utilisateur peut modifier son adresse avant validation” est vérifiable.
Une formulation inspirée du BDD peut aider, notamment avec la logique Gherkin : Étant donné un contexte, quand une action se produit, alors un résultat attendu doit apparaître. Par exemple : “Étant donné un administrateur connecté, quand il saisit une adresse e-mail valide et clique sur inviter, alors une invitation est envoyée et le membre apparaît avec le statut en attente.” Cette forme reste simple à relire et donne un point d’appui commun pour les échanges entre métier et technique.
Vérifier la qualité avec INVEST
L’acronyme INVEST est un bon repère pour relire une user story. Elle doit être indépendante autant que possible, négociable, porteuse de valeur, estimable, suffisamment petite et testable. Si une story dépend de cinq autres éléments, ne peut pas être estimée ou ne contient aucun critère de validation, elle mérite probablement un refinement avant d’entrer dans un sprint.
Erreurs fréquentes et corrections rapides
Les mauvaises user stories ne sont pas forcément longues ou mal écrites. Elles peuvent être grammaticalement correctes mais inutilisables pour l’équipe. Le problème vient souvent d’un manque de contexte, d’une solution imposée trop tôt ou d’un bénéfice artificiel. Dans la pratique, il vaut mieux une story simple et discutable qu’une phrase lisse mais vide.
| Erreur | Pourquoi c’est gênant | Correction |
|---|---|---|
| En tant qu’utilisateur, je veux un bouton bleu afin de cliquer dessus. | La story décrit une solution visuelle, pas un besoin. | En tant que visiteur, je veux identifier clairement l’action principale afin de finaliser mon inscription sans hésiter. |
| En tant qu’admin, je veux gérer les droits. | Le périmètre est trop large et difficile à estimer. | Découper en stories : inviter un membre, modifier un rôle, désactiver un accès. |
| En tant que client, je veux exporter mes données afin d’avoir une fonctionnalité d’export. | Le bénéfice répète l’objectif sans expliquer la valeur. | En tant que client, je veux exporter mes factures afin de les transmettre à mon comptable. |
| En tant que système, je veux synchroniser les données. | Le persona n’est pas un utilisateur réel ou métier. | Reformuler autour de la personne qui bénéficie de la synchronisation. |
Une autre erreur consiste à transformer chaque demande en user story sans priorisation. Le backlog produit n’est pas une liste de souhaits. Chaque récit doit contribuer à un objectif produit, résoudre un problème identifié ou réduire une incertitude importante. Sinon, l’équipe risque d’empiler des fonctionnalités peu utilisées et de perdre du temps sur des sujets secondaires.
Modèle prêt à l’emploi et outils utiles
Pour rédiger rapidement, vous pouvez partir d’un modèle simple, puis l’enrichir pendant les ateliers de refinement ou de story mapping. L’objectif n’est pas de remplir des cases, mais de faciliter la discussion entre métier, produit et technique. Un bon modèle sert de base commune, pas de carcan.
Modèle de user story :
- Titre : une phrase courte orientée besoin.
- Persona : qui rencontre le problème ou attend le bénéfice.
- User story : En tant que…, je veux…, afin de…
- Contexte : situation, déclencheur, contrainte ou fréquence d’usage.
- Critères d’acceptation : conditions vérifiables de réussite.
- Notes : dépendances, hypothèses, questions ouvertes.
Des outils comme Jira, Trello, Asana ou Miro peuvent aider à organiser les user stories dans un backlog, un tableau Kanban ou une carte de parcours. Jira convient souvent aux équipes produit et développement qui suivent des sprints. Trello peut suffire pour des équipes plus légères. Miro est particulièrement utile pour un atelier de story mapping, lorsque l’on veut visualiser le parcours utilisateur avant de découper les epics en stories.
Avant de valider une user story, utilisez cette mini-checklist : le persona est-il clair ? Le bénéfice est-il réel ? La story peut-elle être discutée avec l’équipe ? Peut-elle être estimée ? Les critères d’acceptation sont-ils testables ? Le périmètre est-il assez petit pour être livré dans un sprint ? Si la réponse est non à plusieurs questions, mieux vaut affiner la story plutôt que la pousser trop vite en développement.
- User stories : exemples concrets, critères d’acceptation et méthode de rédaction - 5 juillet 2026
- Infrastructure as a service : louer serveurs, stockage et réseau sans perdre le contrôle - 4 juillet 2026
- Maîtrise d’œuvre informatique : missions, compétences et rôle du chef de projet - 3 juillet 2026
Articles qui pourraient vous intéresser :
Hub harnes mondial relay : fonctionnement, services et conseils pratiques
Tableau de répartition des tâches : la méthode pour équilibrer vos charges et gagner en polyvalence
Grille indiciaire catégorie C : salaires, échelons et revalorisations 2024
Facteurs de production : définition, exemples concrets et enjeux de la combinaison productive