6 user stories avec critères d’acceptation

Une user story sert à formuler un besoin utilisateur de façon simple, testable et orientée valeur. Si vous cherchez un exemple de user story, le plus utile n’est pas seulement de copier un modèle, mais de comprendre pourquoi il fonctionne, comment il se découpe et quels critères permettent de dire qu’il est terminé.

Le format le plus courant est : En tant que [persona], je veux [objectif], afin de [bénéfice]. Cette phrase courte alimente le backlog produit, facilite les échanges entre métier, design et développement, puis se complète avec des critères d’acceptation.

Table des matières

Une user story n’est pas une mini-spécification

Une user story, ou récit utilisateur, décrit une intention du point de vue de l’utilisateur final. Elle ne détaille pas toute l’architecture technique, tous les écrans ni toutes les règles internes dès le départ. Son rôle est d’ouvrir une conversation claire : qui a besoin de quoi, dans quel contexte, et pour obtenir quel résultat ?

Par exemple, une mauvaise formulation serait : Ajouter un bouton de téléchargement PDF dans l’onglet factures. C’est déjà une solution. Une meilleure user story serait : En tant que client, je veux télécharger ma facture au format PDF afin de la transmettre à mon service comptable. Le besoin devient plus compréhensible, plus priorisable et plus facile à vérifier.

Ce qu’une bonne user story doit contenir

Une user story efficace repose sur trois éléments : un persona, un objectif concret et un bénéfice métier ou utilisateur. Le persona évite les formulations floues comme “utilisateur” quand plusieurs profils existent. L’objectif précise l’action attendue. Le bénéfice justifie pourquoi cette demande mérite une place dans le backlog produit.

On ajoute ensuite des critères d’acceptation. Ils décrivent les conditions à réunir pour considérer la story comme livrée. Sans eux, l’équipe risque de développer une fonctionnalité qui semble correcte techniquement, mais qui ne répond pas exactement au besoin attendu.

Différence avec une tâche, une epic et une feature

Élément	Rôle	Exemple
User story	Décrit un besoin utilisateur livrable	Recevoir une alerte quand une commande est expédiée
Epic	Regroupe plusieurs stories autour d’un grand objectif	Améliorer le suivi de commande
Tâche	Décrit un travail technique ou opérationnel	Créer l’endpoint d’envoi de notification
Feature	Désigne une fonctionnalité produit plus large	Notifications de livraison

6 exemples de user stories prêts à adapter

Les exemples suivants montrent comment passer d’un besoin général à une user story exploitable. Chaque cas inclut des critères d’acceptation pour aider l’équipe à cadrer la livraison.

Exemples e-commerce et SaaS

Contexte	User story	Critères d’acceptation
E-commerce	En tant que client, je veux filtrer les produits par taille et couleur afin de trouver plus rapidement un article disponible.	Les filtres affichent uniquement les options disponibles ; la liste se met à jour sans rechargement complet ; les filtres sélectionnés restent visibles.
SaaS B2B	En tant qu’administrateur, je veux inviter un nouveau collaborateur par e-mail afin de lui donner accès à l’espace de travail.	L’invitation contient un lien sécurisé ; le lien expire après un délai défini ; l’administrateur voit le statut de l’invitation.
Application mobile	En tant qu’utilisateur mobile, je veux réinitialiser mon mot de passe depuis l’application afin de retrouver l’accès à mon compte sans contacter le support.	Un e-mail de réinitialisation est envoyé ; un message confirme l’envoi ; les erreurs d’adresse inconnue sont formulées clairement.

Exemples métier : RH, logistique et finance

Contexte	User story	Critères d’acceptation
RH	En tant que manager, je veux consulter les demandes de congés de mon équipe afin de valider les absences sans créer de conflit de planning.	Les demandes sont triées par date ; les chevauchements sont signalés ; le manager peut accepter ou refuser avec un commentaire.
Logistique	En tant qu’agent d’entrepôt, je veux scanner un colis à chaque étape afin de mettre à jour son statut en temps réel.	Le scan associe le colis à une étape ; un message d’erreur apparaît si le code est invalide ; l’historique reste consultable.
Finance	En tant que comptable, je veux exporter les transactions filtrées afin de préparer un rapprochement bancaire plus rapidement.	L’export respecte les filtres appliqués ; le fichier contient les champs nécessaires ; un message indique la réussite ou l’échec de l’export.

Rédiger une user story efficace sans la surcharger

La rédaction d’une user story commence rarement par une phrase parfaite. Elle naît d’un problème observé : un utilisateur qui abandonne un parcours, un support client saturé, une étape manuelle répétitive, une donnée difficile à retrouver. Le bon réflexe consiste à partir de cette friction, puis à formuler le besoin sous forme de résultat attendu.

Avant d’écrire la story, regardez le contexte où le problème apparaît : moment du parcours, contraintes métier, émotion de l’utilisateur, fréquence du problème, conséquences si rien ne change. Cette lecture évite de transformer un symptôme en fonctionnalité inutile. Un bouton supplémentaire peut sembler évident, alors que le vrai besoin est parfois de réduire une étape, clarifier un libellé ou automatiser une vérification.

Utiliser le modèle sans devenir mécanique

Le modèle En tant que…, je veux…, afin de… est un point de départ, pas une formule magique. Si la phrase devient artificielle, reformulez-la jusqu’à ce que l’intention soit naturelle. Une bonne story doit pouvoir être comprise par un développeur, un designer, un commercial ou un responsable métier sans traduction technique.

Évitez aussi les personas trop vagues. En tant qu’utilisateur peut suffire pour un service très simple, mais il devient insuffisant dès que plusieurs profils interagissent avec le produit. Un administrateur, un client invité, un agent support et un manager n’ont pas les mêmes droits, attentes ni contraintes.

Ajouter des critères d’acceptation testables

Les critères d’acceptation doivent être précis, observables et liés au comportement attendu. Ils peuvent être rédigés en liste simple ou dans un format inspiré du BDD, par exemple : Étant donné que je suis connecté, quand je clique sur “Exporter”, alors un fichier CSV est généré avec les données filtrées.

Pour vérifier leur qualité, posez une question simple : est-ce qu’un testeur pourrait valider ce critère sans demander une explication supplémentaire ? Si la réponse est non, le critère est probablement trop flou.

Les erreurs fréquentes qui rendent les user stories inutiles

Une user story faible ne bloque pas toujours le projet immédiatement. Elle crée plutôt des malentendus progressifs : estimation instable, développement incomplet, retours tardifs, frustration côté métier. Voici les pièges les plus courants.

Décrire une solution au lieu d’un besoin : “Ajouter un bouton bleu” n’explique pas le problème utilisateur.
Oublier le bénéfice : sans “afin de”, la priorité devient difficile à défendre.
Écrire une story trop grande : si elle nécessite plusieurs sprints, elle ressemble davantage à une epic.
Ne pas préciser les critères d’acceptation : l’équipe ne sait pas où se trouve la ligne d’arrivée.
Mélanger plusieurs objectifs : une seule story ne doit pas porter trois besoins indépendants.
Ignorer le contexte métier : une story correcte en apparence peut être inutilisable si elle ne respecte pas les règles du terrain.

Le test INVEST comme checklist rapide

Le modèle INVEST aide à relire une user story avant de la mettre en sprint. Elle doit être Indépendante, Négociable, porteuse de Valeur, Estimable, suffisamment Petite et Testable. Ce n’est pas une règle administrative, mais une grille de discussion utile pendant le refinement.

Si une story échoue à plusieurs critères, il vaut mieux la retravailler avant le sprint planning. Une story non testable ou trop large ralentit souvent plus l’équipe qu’une story réécrite en atelier pendant quinze minutes.

Modèle simple pour créer vos propres user stories

Pour rédiger rapidement une user story, partez de ce canevas :

En tant que [persona précis], je veux [action ou objectif], afin de [bénéfice mesurable ou compréhensible].

Ajoutez ensuite trois à cinq critères d’acceptation. Ils doivent couvrir le cas nominal, les erreurs possibles et les limites importantes. Par exemple, pour une story de téléchargement de facture, pensez au format du fichier, aux droits d’accès, au message en cas d’échec et à la cohérence des informations affichées.

Identifiez le persona concerné.
Décrivez le problème ou l’objectif en langage utilisateur.
Formulez le bénéfice attendu.
Vérifiez que la story peut être livrée dans un délai raisonnable.
Ajoutez des critères d’acceptation testables.
Relisez la story avec les personnes métier et l’équipe technique.

Vous pouvez gérer ces récits dans Jira, Trello, Asana, Notion, Miro ou un simple tableau partagé. L’outil importe moins que la clarté du backlog et la qualité des échanges pendant les ateliers de refinement, de story mapping ou de sprint planning.

Une bonne user story ne cherche pas à tout dire. Elle donne juste assez de contexte pour décider, concevoir, développer et tester une petite unité de valeur. C’est cette simplicité qui en fait un outil puissant pour aligner les équipes agiles autour de besoins réellement utiles.