Comment écrire une User Story?

⭐️ Introduction

Tu arrives dans une nouvelle équipe. On te donne accès à Jira ou Linear, un backlog à moitié vide, et on te dit :

“On a besoin des User Stories pour le prochain sprint.”

Problème : tu n’as jamais vraiment appris à en écrire. Ou alors tu as bricolé :

• des exemples copiés,

• des specs transformées en tickets,

• des critères flous “on verra pendant le dev”.

Résultat classique : incompréhensions, stories trop grosses, discussions sans fin, et dette technique qui s’accumule sprint après sprint.

Cet article te donne une méthode claire pour écrire des User Stories utiles, actionnables et livrables, sans improviser.

⭐️ 1. Définition : c’est quoi une User Story ?

Une User Story (US) est une description concise d’un besoin utilisateur exprimé sous forme d’objectif, et non une solution technique.

Elle sert à :

• clarifier pour qui on construit,

• expliquer ce qu’il veut accomplir,

• montrer la valeur attendue,

• cadrer le périmètre et les conditions d’acceptation.

Une US n’est pas :

❌ une spec détaillée

❌une solution déguisée

❌ un ticket technique

❌ un endroit où “caser tout ce qu’on ne sait pas où mettre”.

Une User Story s’inscrit toujours dans une hiérarchie plus large : Epic → Capabilities → Fonctionnalités → User Stories (selon l’organisation).

Elle représente le plus petit niveau livrable de valeur utilisateur, là où la vision devient action concrète.

Si tu veux aller à l’essentiel, notre fiche récap te donne la vue d’ensemble.

Elle synthétise tout l’article pour t’aider à écrire des User Stories claires, utiles et livrables.

⭐️ 2. Syntaxe standard d’une User Story

La formulation universelle :

En tant que [utilisateur / rôle] Je veux [objectif / action] Afin de [valeur / résultat attendu]

Exemples :

• En tant qu’abonné, je veux ajouter mon moyen de paiement afin de finaliser mon abonnement.

• En tant qu’agent support, je veux rechercher un utilisateur rapidement afin de résoudre son problème plus vite.

⭐️ 3. Le critère INVEST (la base d’une bonne User Story)

Une bonne US doit être INVEST :

Lettre	Signification	Ce que ça implique
I – Independant	Indépendante	Peut être livrée sans dépendre d’une autre story.
N – Negotiable	Négociable	Le “comment” n’est pas figé : l’équipe discute.
V – Valuable	Valeur	Apporte un bénéfice concret à l’utilisateur.
E – Estimable	Estimable	Claire → l’équipe peut l’estimer.
S – Small	Petite	Livrable dans un sprint.
T – Testable	Testable	Critères d’acceptation clairs et vérifiables.

⭐️ 4. Structure complète d’une User Story

Une US complète contient :

1. Titre clair

2. User Story (formulation en 3 lignes)

3. Contexte (optionnel mais recommandé)

4. Critères d’acceptation (Gherkin)

5. Cas limites / Edge Cases

6. Règles fonctionnelles

7. Constraints / NFR (performance, sécurité, accessibilité…)

8. Dépendances

9. Découpage en tâches

Tu peux l’utiliser comme template Notion.

⭐️ 5. Critères d’acceptation (format Gherkin)

Le format Given / When / Then est le plus simple et le plus robuste :

Given (état initial)
When (action de l’utilisateur)
Then (résultat attendu mesurable)

Exemple :

Given Je suis connecté
When Je clique sur “Ajouter une carte”
Then Je peux saisir mes informations et les valider

⭐️ 6. Edge Cases (Cas limites)

Les Edge Cases sont les “et si…” : conditions inhabituelles, mais possibles.

Exemples :

• “Et si l’utilisateur a 0 moyen de paiement ?”

• “Et si le réseau coupe pendant la validation ?”

• “Et si l’utilisateur entre un numéro invalide ?”

⚠️ Les Edge Cases ne doivent jamais être implicites → ils font partie du périmètre.

⭐️ 7. DoR (Definition of Ready) : Quand une US est prête

Une US est “Ready” quand :

• Le rôle utilisateur est clair

• L’objectif est clair

• La valeur est exprimée

• Critères d’acceptation rédigés

• Edge cases identifiés

• Impact sur la data connu (tracking)

• Dépendances identifiées

• Taille raisonnable (petite)

• Alignement côté produit & design

Checklist :

☐ Persona identifié
☐ Contexte clair
☐ “En tant que…” rédigé
☐ Critères Gherkin complets
☐ Edge cases listés
☐ UX validée / maquette prête
☐ NFR connus
☐ Pas de dépendances bloquantes
☐ Story estimable
☐ Maquettes Livrées

⭐️ 8. DoD (Definition of Done) : Quand une US est vraiment terminée

Checklist DoD standard :

☐ Code développé
☐ Tests unitaires
☐ Tests d’intégration
☐ Critères Gherkin validés
☐ Edge cases validés
☐ Tracking implémenté
☐ Documentation mise à jour
☐ Demo faite
☐ Validée en environnement de staging
☐ PR merge + feature flag (si utilisé)

⭐️ 9. Découpage en tâches (Task breakdown)

Une User Story = une valeur utilisateur.

Les tâches = ce qu’il faut faire pour livrer cette valeur.

Exemple :

🟣 US : Ajouter un moyen de paiement

Tâches :

• T1 : Création du formulaire

• T2 : Validation du numéro

• T3 : Appel API “AddPaymentMethod”

• T4 : Gestion des erreurs

• T5 : Tracking analytics

• T6 : Tests QA

Règle universelle : une tâche ne doit jamais contenir “tout le dev”.

⭐️ 10. Template complet

# Titre de la User Story

## User Story
En tant que…
Je veux…
Afin de…

## Contexte
(Contexte business, technique ou réglementaire)

## Critères d’acceptation (Gherkin)
Given…
When…
Then…

## Edge Cases
- …
- …

## Règles fonctionnelles
- …

## NFR (Non Functional Requirements)
- …

## Dépendances
- …

## Découpage en tâches
- …

## Notes / Questions ouvertes
- …

⭐️ 11. Les erreurs les plus fréquentes

❌ Confondre “solution” et “objectif utilisateur”

❌ Écrire des US trop larges

❌ Pas de critères Gherkin → discussions infinies

❌ Pas d’edge cases → bugs invisibles

❌ Pas de NFR → performance / sécurité ignorées

❌ Trop de dépendances → impossible à livrer

❌ US = spec technique (pas une valeur)

⭐️ 12. Outils conseillés

• Linear : le meilleur outil au quotidien

• Notion : parfait pour documenter DoR/DoD + templates

• Jira : standard corporate, intégration workflows

• Figma : maquettes / flux UX

• Postman : tests API

• Looker / Mixpanel / Amplitude : vérification du tracking

⭐️ 13. Les meilleurs prompts pour écrire une User Story

Choisis l’IA avec laquelle tu es le plus à l’aise, puis utilise les prompts ci-dessous.

Rédiger une User Story :

Je suis Product Manager. Ma mission est de générer une User Story ultra-complète et actionnable.

CONTEXTE (à remplir) :
- Produit / domaine :
- Problème identifié :
- Objectif business :
- Utilisateur cible (persona, rôle, contexte d’usage) :
- Contraintes (techniques, légales, data, performance…) :
- Découpage attendu (1 sprint max, équipe X) :

INSTRUCTIONS :
En t’appuyant strictement sur ce contexte, génère une User Story INVEST-ready incluant :

1. Titre clair (orienté objectif)
2. Formulation US :
   En tant que…
   Je veux…
   Afin de…
3. Contexte business & utilisateur
4. Critères d’acceptation (Gherkin) en bloc :
   - Given…
   - When…
   - Then…
5. Edge Cases (cas limites) (5 minimum)
6. Règles fonctionnelles (exhaustives, sans ambiguïté)
7. NFR / Contraintes (performance, sécurité, RGPD, accessibilité, compatibilité…)
8. Dépendances** (équipes, API, feature flags, design, data…)
9. Découpage en tâches (dev, design, analytics, QA)
10. Propositions de tests QA (unitaires + d’intégration + exploratoires)
11. Checks INVEST (liste courte validant que la US respecte chaque lettre)

RÈGLES DE SORTIE :
- Pas de langage vague (“peut-être”, “à voir”).  
- Pas de solution technique arbitraire si le contexte ne l’impose pas.  
- Pas de design caché : uniquement besoin + règles fonctionnelles.  
- Tout doit être livrable **en un sprint** (sinon proposer un découpage).

OUTPUT : une User Story prête à être collée dans Jira/Linear/Notion.

Découper une US automatiquement :

Analyse la User Story ci-dessous et détermine si elle respecte réellement le critère S (Small) du framework INVEST.

- Si elle est livrable en un sprint → ne rien changer.
- Si elle est trop large → propose un découpage en :
  - Epics → Capabilities → User Stories → Tasks

Avec pour chaque US découpée :
- Titre
- User Story (En tant que / Je veux / Afin de)
- Contexte
- Critères Gherkin
- Taille estimée (S/M/L)
- Risques

USER STORY :
(colle ici la story)

Réécriture d’une US floue :

Je suis Product Manager. Réécris la User Story suivante pour qu’elle respecte entièrement INVEST, qu’elle soit livrable en un sprint, et structurée (avec Gherkin, NFR, tâches, edge cases, etc.).

Conserve le sens, mais clarifie :
- l’objectif utilisateur
- la valeur
- les règles fonctionnelles
- les critères Gherkin
- les cas limites
- le périmètre

USER STORY À RÉÉCRIRE :
(colle ici la story)

⭐️ 14. Créer ton agent User Story sur mesure avec Dust

Si tu veux aller plus loin que le “prompt copier-coller”, tu peux créer un agent IA dédié aux User Stories avec Dust.

👉 Objectif : produire des User Stories standardisées, actionnables et directement exploitables dans Jira.

⚠️ Important : Dust seul ne suffit pas.Un agent utile doit être connecté à ton outil de delivery ou intégré dans un workflow clair.

Pourquoi un agent dédié ?

• cohérence sur toutes les US

• gain de temps massif

• moins d’oublis (NFR, edge cases, data…)

• même standard pour toute l’équipe

Mais 👉 sans Jira, l’agent reste un outil de rédaction.

Comment faire (workflow complet et réaliste)

1️⃣ Crée un nouvel Agent sur https://dust.tt

Donne-lui un rôle explicite :

“Tu es un Product Manager senior expert en User Stories INVEST, orienté livraison en un sprint.”

2️⃣ Définis clairement les INPUTS de l’agent (étape critique)

❌ Mauvais inputs :

• une User Story déjà écrite

• un ticket Jira flou

• une spec technique

✅ Bons inputs :

• un titre orienté objectif

• ou une opportunité / problème

• ou un objectif business + utilisateur

• contraintes clés (tech, data, légales)

Exemple d’input attendu :

“Permettre à un utilisateur bloqué de mettre à jour ses informations KYC sans contacter le support.”

👉 L’agent transforme une intention → une US complète.

3️⃣ Cadre strictement son périmètre

Dans les instructions de l’agent :

• ✅ écrire des User Stories INVEST

• ✅ structurer Gherkin, edge cases, NFR, tâches

• ❌ proposer des solutions techniques arbitraires

• ❌ inventer du design

• ❌ produire des stories non livrables en un sprint

4️⃣ Impose un FORMAT DE SORTIE compatible Jira

Format obligatoire (copié tel quel) :

• Titre

• Description (User Story : En tant que / Je veux / Afin de)

• Contexte

• Critères d’acceptation (Gherkin)

• Edge cases

• NFR

• Dépendances

• Découpage en tâches

👉 Ce format doit matcher les champs Jira (Summary, Description, AC, Labels…).

5️⃣ Injecte tes référentiels produit

Colle dans l’agent :

• ta structure d’US officielle

• tes règles INVEST

• ta DoR / DoD

• 1–2 User Stories modèles validées (golden samples)

Sans ça → dérive assurée.

6️⃣ Connexion à Jira : ce qui est réellement possible

Deux options réalistes 👇

Option A : Workflow simple (le plus courant)

• L’agent génère la User Story

• Le PM la colle dans Jira

• Champs déjà structurés → zéro retraitement

👉 Suffisant dans 80 % des équipes.

Option B : Connexion Jira via API / automatisation

Objectif :

• créer automatiquement les tickets Jira

• remplir :

  • Summary

  • Description

  • Acceptance Criteria

  • Labels / Components

• appliquer le même standard à toute l’équipe

👉 Nécessite :

• accès API Jira

• configuration côté Dust / outil d’automatisation

• mapping clair des champs

⚠️ Sans ce mapping, l’automatisation est inutile.

Résultat attendu

👉 Un agent qui :

• structure la réflexion produit

• produit des User Stories propres et complètes

• alimente Jira sans dette documentaire

🧠 À retenir :

Un agent User Story n’est pas magique. Il est efficace uniquement s’il est :

• bien alimenté (bons inputs),

• bien cadré (format + règles),

• bien connecté au delivery (Jira).

Sinon, ce n’est qu’un prompt déguisé.

⭐️ 15. FAQ : Les questions que tous les PM posent

Une User Story doit-elle contenir une maquette ?

➡️ Non, mais une US n’est prête (DoR) que si la solution est claire → souvent via une maquette.

Peut-on écrire des US techniques ?

➡️ Non. Une US est toujours utilisateur → un ticket technique est une Tâche/Task, pas une US.

Combien de critères Gherkin par US ?

➡️ Entre 3 et 7.

Trop = flou.

Pas assez = incomplet.

Quand découper une US ?

➡️ Si elle ne tient pas en un sprint → elle est trop grosse.

Faut-il tout mettre en Gherkin ?

➡️ Non : seules les règles vérifiables.

Les NFR restent dans leur section dédiée.

Conclusion

Si tu devais retenir une seule chose : une bonne User Story n’est pas longue, elle est claire.

Quand tes US sont bien écrites :

• les équipes avancent plus vite,

• les décisions sont plus simples,

• les bugs diminuent,

• et le produit gagne en impact.

Si tu veux plus de contenus concrets sur le Product Management :

👉 suis-nous sur LinkedIn

• Ma page perso : ici

• Be My Product : ici

Et si tu veux monter en compétence sérieusement,retrouve nos formations Produit certifiées Qualiopi sur :

👉 https://bemyproduct.com

Moi, c’est Jérôme, Coach Produit & Formateur.

J’aide les équipes à clarifier, structurer et décider, sans bullshit.