Epic, user story, tâche : différences et exemples
Epic, user story, tâche : définitions claires, une même feature déclinée aux trois niveaux, quand découper et les anti-patterns à éviter. Guide pratique.
Par l’équipe RoadmapHero · Mis à jour le · 8 min de lecture
L’essentiel
- Un epic est un gros chantier orienté résultat, de 2 semaines à 3 mois et d’environ 5 à 20 stories : c’est le niveau qui a sa place sur la roadmap.
- Une user story est une tranche d’epic tenant dans un sprint, souvent de 1 à 3 jours, qui livre une valeur observable au format persona, besoin, bénéfice avec des critères d’acceptation.
- Une tâche est une étape technique vers la complétion d’une story, portée par les développeurs, durant de quelques heures à deux jours et créée au sprint planning.
- Découpez un epic en stories quand il passe en Next, une story quand elle dépasse environ un demi-sprint, et évitez les epics fourre-tout, les stories techniques et les epics éternels.
Epic, user story, tâche : la question a l'air d'un débat de vocabulaire, jusqu'au jour où votre backlog devient une liste plate de 400 tickets indifférenciés. Ces trois niveaux existent parce que le travail produit se joue dans trois conversations différentes — stratégique, sprint, technique — et que chacune a besoin d'items à la bonne maille. Quand la hiérarchie est propre, roadmap, backlog et tableau de sprint racontent enfin la même histoire à trois niveaux de zoom.
Définitions : epic, user story, tâche
L'epic
Un epic est un gros chantier orienté résultat ou capacité : « Facturation en self-service », « Refonte de l'onboarding », « SSO pour les comptes entreprise ». Trop gros pour un sprint — de 2 semaines à 3 mois — et trop flou pour être estimé précisément. C'est normal : un epic est un conteneur de découverte progressive, pas un bon de commande. C'est lui qui a sa place sur la roadmap, à côté des objectifs qu'il sert (un sujet que nous détaillons dans roadmap vs backlog).
La user story
Une user story est une tranche d'epic, dimensionnée pour un sprint, qui livre une valeur observable : « En tant que comptable, je veux télécharger une facture en PDF, afin de l'archiver ». Elle suit le format persona/besoin/bénéfice, respecte INVEST et porte des critères d'acceptation. La story est l'unité de priorisation et d'estimation — la monnaie de la gestion du backlog.
La tâche
Une tâche est une étape technique vers la complétion d'une story : « créer le template PDF de facture », « ajouter l'endpoint de téléchargement », « écrire le test e2e du flux ». Les tâches décrivent le comment, appartiennent aux développeurs, durent de quelques heures à deux jours, et n'ont aucune obligation de porter une valeur utilisateur en propre. On les crée au sprint planning, pas avant.
La hiérarchie et sa granularité
Niveau | Taille typique | Rédigé par | Répond à | Vit dans |
|---|---|---|---|---|
Epic | 2 semaines – 3 mois, 5 à 20 stories | PM / product owner | Quel résultat visons-nous ? | La roadmap |
User story | 1 à 3 jours, tient dans un sprint | PM + équipe en refinement | Que peut faire l'utilisateur, et pourquoi ? | Le backlog, le sprint |
Tâche | Quelques heures à ~2 jours | Les développeurs | Que faut-il construire ou modifier ? | Le tableau de sprint |
Certaines organisations ajoutent un quatrième niveau au-dessus des epics — initiatives ou thèmes — pour regrouper les epics sous un objectif stratégique. Utile à l'échelle, bruit inutile pour un produit mono-équipe. Commencez à trois niveaux ; n'en ajoutez que quand la conversation de roadmap l'exige.
Une même feature aux trois niveaux
Les abstractions trompent ; voici un découpage complet. Un SaaS B2B décide de permettre le paiement par facture, pas seulement par carte.
L'epic
Epic : Paiement par facture — les clients entreprise peuvent choisir le paiement par facture à 30 jours, afin que les comptes pilotés par les achats ne churnnent plus au moment de payer. Métrique de succès : 80 % des deals entreprise signés sans carte bancaire.
Les stories qu'il contient
En tant qu'acheteur d'un compte approuvé, je veux choisir « paiement par facture » au checkout, afin de commander sans carte d'entreprise.
En tant qu'admin finance, je veux recevoir la facture PDF par email à la commande, afin de la traiter dans notre outil comptable.
En tant qu'account manager, je veux approuver ou refuser les demandes de paiement par facture, afin de maîtriser le risque de crédit.
En tant qu'acheteur, je veux voir mes factures en cours et leurs échéances sur la page facturation, afin de payer à temps.
En tant qu'admin finance, je veux qu'une facture en retard déclenche une relance à J+7 et J+21, afin que le recouvrement ne dépende pas d'une relance manuelle.
Les tâches sous une story
La story « choisir le paiement par facture au checkout » se découpe en :
Ajouter l'entité moyen de paiement et l'option « facture » derrière un feature flag.
Étendre l'API de checkout pour accepter le paiement par facture des comptes approuvés.
UI : sélecteur de paiement avec état d'éligibilité et texte d'aide.
Émettre l'événement « commande passée – facture » pour le service de facturation.
Test e2e : un compte approuvé finalise sa commande sans carte.
Relisez les trois niveaux : l'epic parle chiffre d'affaires, les stories parlent capacité utilisateur, les tâches parlent code. Personne n'a besoin de traduire.
Quand découper (et quand s'abstenir)
Découpez un epic en stories quand il passe en « Next » — un epic prévu dans deux trimestres n'a besoin que d'un titre et d'une métrique de succès. Le détailler trop tôt, c'est du stock qui sera réécrit.
Découpez une story quand l'équipe ne sait pas l'estimer, ou quand l'estimation dépasse environ un demi-sprint. Utilisez les patterns de découpage vertical (étapes de workflow, règles métier, chemin nominal d'abord) — jamais de découpe backend/frontend.
Découpez une story en tâches au sprint planning, par ceux qui vont la construire. Un découpage en tâches fait des semaines à l'avance, c'est de la divination.
Ne découpez pas ce qui est déjà petit. Une story de 2 jours avec des critères d'acceptation clairs n'a pas besoin de cinq sous-tâches pour avoir l'air organisée. La cérémonie n'est pas de la rigueur.
L'estimation suit la même hiérarchie : les epics reçoivent des tailles de t-shirt ou des fourchettes grossières, les stories des story points, les tâches des heures — ou rien du tout.
Les anti-patterns à éviter
L'epic fourre-tout — « Améliorations », « Dette technique », « Vrac T3 ». Un epic sans résultat visé ni date de fin est un tiroir à bazar : il ne se termine jamais, donc n'est jamais célébré, audité ni arrêté. Tout epic mérite une métrique de succès et une fin plausible.
Les stories techniques — « En tant que développeur, je veux refactorer le module de session ». Si aucun résultat utilisateur ou business n'est observable, c'est une tâche sous une story ou un epic qui en a un, ou une ligne du budget d'ingénierie — pas une story.
L'epic éternel — ouvert depuis 14 mois, à 60 % pour toujours. Fermez-le, livrez ce qui existe, rouvrez plus petit si nécessaire.
Les stories qui sont des epics déguisés — « En tant qu'admin, je veux un système de permissions » ne tiendra jamais dans un sprint. Si vous écrivez « système », « module » ou « plateforme » dans une story, vous êtes en train de nommer un epic.
La roadmap au niveau tâche — montrer 300 tâches aux parties prenantes, c'est montrer du bruit. La roadmap montre les epics ; le sprint montre stories et tâches.
Le refus de toute hiérarchie — viable à 30 tickets, ingérable à 300. La structure est ce qui permet de bien rédiger ses user stories sans perdre la vue d'ensemble.
Quel niveau pour quelle conversation
Comité de direction → epics uniquement, avec résultats visés et statut.
Revue de roadmap avec les parties prenantes → epics, plus les 2-3 stories phares qui les rendent concrets.
Backlog refinement → stories : découpage, critères d'acceptation, estimations.
Sprint planning et daily → stories et tâches.
Quand une réunion patine, vérifiez l'altitude : la moitié des « mauvaises réunions backlog » sont des conversations d'epic imposées à des tâches, ou l'inverse.
Epics, stories et tâches dans RoadmapHero
RoadmapHero implémente cette hiérarchie nativement : les epics regroupent les stories, les tickets portent story points, checklists d'acceptation, champs personnalisés et coûts estimés vs réels. Les dépendances rendent explicites les liens entre stories, et le ticket health repère les epics éternels et les stories à l'abandon avant qu'ils ne pourrissent. Les mêmes données alimentent deux vues : une roadmap partageable au niveau epic pour les parties prenantes, et un backlog au niveau story pour l'équipe — priorisé au HeroScore. Si le delivery se fait dans Jira, Linear ou GitHub, les intégrations bidirectionnelles gardent les niveaux synchronisés, et l'agent White Rabbit replanifie automatiquement les tickets en retard. Essai gratuit, sans engagement.
Questions fréquentes
Quelle est la différence entre un epic et une user story ?
Un epic est un gros chantier — un résultat ou une capacité qui s'étale sur plusieurs sprints et se découpe progressivement. Une user story est une tranche de ce chantier, dimensionnée pour un sprint, qui livre une valeur utilisateur observable. Les epics nourrissent les conversations de roadmap ; les stories, celles du sprint.
Quelle taille doit faire un epic ?
Repère utile : un epic couvre de 2 semaines à 3 mois de travail et se découpe en 5 à 20 stories. En dessous, c'est probablement une grosse story ; au-delà d'un trimestre, il glisse vers l'initiative ou le thème et mérite d'être scindé.
Les tâches doivent-elles suivre le format user story ?
Non. Les tâches décrivent le comment, pas le quoi : « ajouter un index sur la table factures » ou « mettre à jour le client API » suffisent tels quels. Forcer « En tant que développeur, je veux… » sur une tâche ajoute de la cérémonie sans information.
Les bugs sont-ils des stories, des tâches ou un type à part ?
Traitez les bugs comme un type de ticket à part. Un bug qui casse un comportement existant n'est pas une nouvelle valeur utilisateur : le format story lui va mal. Suivez-les séparément, priorisez-les face aux stories, et rattachez-les à l'epic concerné quand ils se concentrent.
Qui découpe les epics en stories, et les stories en tâches ?
Le PM ou le product owner pilote le découpage epic → stories, idéalement avec l'équipe pendant le refinement. Le découpage story → tâches appartient aux développeurs — en général au sprint planning — car les tâches sont des décisions d'implémentation.