User stories : du besoin utilisateur à une fonctionnalité claire
Apprendre à écrire, découper et valider une user story, avec critères d’acceptation, INVEST, exemples et pièges courants.
Où en êtes-vous avec cette notion ?
Une indication personnelle, enregistrée uniquement dans ce navigateur.
Le format café
L’essentiel à comprendre, le temps d’un café.
Envie de creuser ? Un cours plus complet vous attend juste après, à déplier sans quitter cette page.
Le concept
Une user story décrit un petit besoin du point de vue de la personne qui en bénéficiera. Elle aide une équipe à parler d’abord de valeur utilisateur, avant de parler de code.
La formule la plus connue est :
En tant que [type d’utilisateur],
je veux [capacité],
afin de [bénéfice].
Exemple :
En tant que client, je veux choisir un créneau disponible afin de réserver sans appeler l’entreprise.
Retenez les trois questions : qui ? veut quoi ? pourquoi ?
Pourquoi c’est utile
« Créer un calendrier React » est une tâche ou une solution technique. La story précédente exprime le résultat recherché. Plusieurs solutions peuvent alors être discutées sans perdre de vue le besoin.
Une story n’est pas une spécification complète : sa petite phrase sert de point de départ à une conversation.
Les critères d’acceptation
Ils décrivent les conditions observables qui permettront de dire que le besoin est satisfait.
Pour la réservation :
- seuls les créneaux disponibles sont proposés ;
- le client choisit une date et une heure ;
- une réservation validée rend le créneau indisponible ;
- une confirmation est affichée.
Story, epic et tâche
EPIC : réservation en ligne
├── STORY : consulter les créneaux
├── STORY : réserver un créneau
└── STORY : annuler une réservation
├── TÂCHE : créer l’endpoint
├── TÂCHE : ajouter le bouton
└── TÂCHE : écrire les tests
Une epic est un grand besoin à découper. Une story est une capacité utile et assez petite. Une tâche décrit le travail nécessaire pour la construire.
La grille INVEST
Une bonne story tend à être :
- I — Independent : aussi indépendante que possible ;
- N — Negotiable : ouverte à la discussion ;
- V — Valuable : porteuse d’une valeur identifiable ;
- E — Estimable : suffisamment comprise pour être estimée ;
- S — Small : assez petite ;
- T — Testable : vérifiable.
INVEST est une grille de contrôle, pas une loi.
Le piège classique
En tant que développeur, je veux créer PostgreSQL, l’API, React et les emails afin de terminer l’application.
Cette phrase mélange des tâches et plusieurs fonctionnalités. Préférez par exemple :
En tant que client, je veux recevoir une confirmation après ma réservation afin de savoir que mon rendez-vous est enregistré.
Les choix de base de données, d’API et d’interface deviennent ensuite des tâches techniques.
Mémo
Story = utilisateur + besoin + valeur.
Critères d’acceptation = conditions de réussite.
Tâches = comment l’équipe construit la solution.
Epic = besoin trop grand, à découper.
À retenir : une user story ne dit pas d’abord au développeur quoi coder ; elle explique quel résultat utile on veut obtenir.
Et si on allait plus loin ?
Le café vous a donné les repères. Prenez maintenant le temps de comprendre les mécanismes et de pratiquer, si vous le souhaitez.
Aller plus loinÉcrire, découper et valider de vraies user storiesDévelopper le coursReplier le cours
Objectif
À la fin de ce cours, vous saurez transformer une demande floue en stories exploitables, écrire leurs critères d’acceptation, repérer une story trop grosse et séparer le besoin des tâches techniques.
1. Une technique agile, pas une obligation Scrum
Les user stories sont historiquement associées aux pratiques agiles, notamment Extreme Programming, puis se sont largement diffusées dans les équipes produit.
Le Scrum Guide n’impose pas la syntaxe « En tant que… je veux… afin de… ». Scrum parle d’éléments du Product Backlog. La user story est une technique pratique pour en décrire certains, pas une règle universelle.
2. Les 3 C : Card, Conversation, Confirmation
Une manière essentielle de comprendre les stories est celle des 3 C :
- Card : une description courte du besoin ;
- Conversation : métier, produit, design et développement précisent ensemble ce qui est attendu ;
- Confirmation : des critères permettent de vérifier que le besoin est satisfait.
La phrase n’est donc pas le produit fini de la réflexion. Elle est le début de la bonne conversation.
3. Construire une story pas à pas
Demande brute :
« Il faudrait retrouver les anciens devis d’une agence. »
Qui ?
Supposons que la personne concernée soit un gestionnaire d’agence.
Quoi ?
Il veut consulter les devis précédemment créés pour cette agence.
Pourquoi ?
Il veut retrouver rapidement l’historique commercial sans rechercher chaque devis séparément.
On obtient :
En tant que gestionnaire d’agence, je veux consulter l’historique des devis de l’agence afin de retrouver rapidement les échanges commerciaux passés.
Le « afin de » est précieux : il force à rechercher la valeur. S’il est impossible à formuler, le besoin mérite souvent d’être rediscuté.
4. Rendre la story vérifiable
Ajoutons des critères d’acceptation :
- la fiche d’une agence affiche une section « Historique des devis » ;
- seuls les devis rattachés à cette agence apparaissent ;
- chaque ligne affiche numéro, date, statut et montant ;
- cliquer sur un devis ouvre son détail ;
- sans devis, un état vide explicite est affiché.
Remarquez l’absence de noms de composants React ou de requêtes SQL. Ces détails relèvent du comment technique, sauf contrainte particulière.
5. Given / When / Then
Pour un comportement précis, les critères peuvent devenir des scénarios :
Étant donné qu’une agence possède trois devis
Quand le gestionnaire ouvre sa fiche
Alors les trois devis sont affichés dans l’historique
Et pour un cas limite :
Étant donné qu’une agence ne possède aucun devis
Quand le gestionnaire ouvre son historique
Alors un message indique qu’aucun devis n’est disponible
Ce format n’est pas obligatoire. Il est utile lorsque les conditions, actions et résultats doivent être très explicites.
6. Tester avec INVEST
Prenons cette story :
En tant que client, je veux gérer mon compte afin de gérer mes informations.
Elle respecte la syntaxe, mais reste mauvaise : « gérer » est vague, la valeur est floue, le périmètre est probablement trop grand et l’estimation difficile.
Découpons :
En tant que client, je veux modifier mon adresse email afin de recevoir mes confirmations sur ma nouvelle adresse.
Puis :
En tant que client, je veux modifier mon mot de passe afin de sécuriser mon compte si je pense qu’il a été compromis.
Une bonne syntaxe ne suffit donc pas : la story doit être réellement compréhensible, petite et testable.
7. Découper verticalement
Évitez ce découpage :
❌ faire la base de données
❌ faire l’API
❌ faire le frontend
Aucune tranche ne fournit seule une capacité utilisateur complète.
Préférez :
✅ consulter les créneaux disponibles
✅ réserver un créneau
✅ annuler son rendez-vous
✅ recevoir un rappel
Chaque story peut traverser interface, API et base de données : on parle de tranche verticale. Elle produit un petit résultat utilisable de bout en bout.
Pour découper, on peut séparer parcours principal et cas particuliers, lecture et écriture, rôles, règles métier, types de données ou niveaux de complexité.
8. Toutes les tâches ne sont pas des user stories
Une migration PostgreSQL, une mise à jour de dépendance, de l’observabilité ou une correction de vulnérabilité sont de vrais travaux. Inutile de les déguiser artificiellement en « En tant que développeur… ».
Même chose pour un bug : étapes de reproduction, comportement observé et comportement attendu sont souvent plus utiles qu’une fausse story.
La user story est un outil pour exprimer une valeur ou un besoin, pas une syntaxe obligatoire pour tout ticket.
9. Choisir le bon rôle
« En tant qu’utilisateur » peut être suffisant si tous les utilisateurs ont le même besoin. Sinon, précisez : visiteur, client authentifié, gestionnaire, administrateur, etc.
Le rôle n’est utile que s’il change le contexte, les droits ou le besoin. Multiplier artificiellement les personas rend le backlog plus confus.
10. Critères d’acceptation et Definition of Done
Ne les confondez pas.
Les critères d’acceptation sont propres à la story : « après réservation, le créneau n’est plus proposé ».
La Definition of Done exprime des exigences qualité plus générales : tests réussis, revue effectuée, documentation mise à jour, déploiement réalisé, etc.
Une fonctionnalité peut donc satisfaire son comportement métier tout en n’étant pas encore considérée comme terminée par l’équipe.
11. Du besoin au code
Besoin métier
↓
User story
↓
Conversation
↓
Critères d’acceptation
↓
Découpage / estimation / priorité
↓
Tâches techniques
↓
Développement + tests
↓
Validation
La story conserve le fil conducteur : les décisions techniques servent le résultat attendu.
12. Exemple complet : click & collect
Story
En tant que client ayant commandé, je veux voir le statut de ma commande afin de savoir quand venir la récupérer.
Critères d’acceptation
- le client peut consulter le statut de sa commande ;
- les statuts visibles sont « reçue », « en préparation » et « prête » ;
- le dernier statut enregistré est affiché ;
- un client ne peut pas consulter la commande d’un autre ;
- une commande inconnue affiche un message adapté.
Tâches techniques possibles
- exposer le statut via l’API ;
- sécuriser l’accès ;
- créer le composant d’état ;
- connecter la mise à jour temps réel ;
- écrire les tests.
Les tâches peuvent évoluer sans modifier la valeur exprimée par la story. C’est la séparation entre quoi/pourquoi et comment.
13. Erreurs fréquentes
- Décrire une solution au lieu d’un besoin : « je veux un bouton bleu ».
- Écrire un « afin de » qui répète simplement l’action.
- Créer une story géante comme « gérer tout le back-office ».
- Accumuler tant de critères qu’ils cachent plusieurs stories.
- Découper uniquement par couches techniques.
- Considérer la story comme un contrat figé et arrêter de discuter avec le métier.
- Forcer tous les bugs et travaux techniques au format user story.
- Utiliser des critères non vérifiables comme « l’interface doit être intuitive » sans résultat observable.
14. Checklist pratique
Avant de lancer une story, vérifiez :
- Qui bénéficie du résultat ?
- Quel comportement attend cette personne ?
- Quelle valeur obtient-elle ?
- Les critères sont-ils observables et testables ?
- La story est-elle suffisamment petite ?
- Plusieurs « et » cachent-ils plusieurs besoins ?
- Les cas limites importants sont-ils compris ?
- Les dépendances sont-elles connues ?
- Le besoin est-il décrit sans imposer inutilement la solution technique ?
Exercice
Demande brute :
« Dans l’espace client, il faudrait les factures, pouvoir télécharger les PDF, payer, changer les coordonnées et envoyer un message au support. »
Essayez de la découper avant de lire la correction.
Correction
Un découpage possible :
- En tant que client, je veux consulter mes factures afin de connaître mes paiements passés et à venir.
- En tant que client, je veux télécharger le PDF d’une facture afin de l’archiver dans ma comptabilité.
- En tant que client, je veux payer une facture en attente en ligne afin de la régler sans virement manuel.
- En tant que client, je veux mettre à jour mes coordonnées afin que les prochains documents utilisent mes informations actuelles.
- En tant que client, je veux envoyer une demande liée à mon compte afin d’obtenir de l’aide depuis mon espace client.
Chaque story porte une valeur distincte, reçoit ses propres critères et peut être priorisée indépendamment.
Pour aller plus loin
- Scrum Guide — Product Backlog et cadre Scrum.
- Agile Alliance — User Stories — présentation de la pratique.
- Martin Fowler — User Story — rôle de la conversation et limites du format.
Mémo final
Une bonne user story ne cherche pas à tout documenter. Elle formule un petit besoin utile, compréhensible et vérifiable, puis déclenche la conversation qui permettra de construire la bonne solution.
Vous pouvez aussi vous arrêter ici. L’approfondissement est facultatif.
Les repères Cours Café
Pour aller à la source
Documentation de référence. Vérification éditoriale encore à effectuer.
Gardez une trace de cette idée.
Favoris, notes et progression seront disponibles après connexion du stockage distant.