Découvrez quand utiliser une user story plutôt qu’un cas d’utilisation sur vos projets agiles. Améliorez la productivité de votre équipe en choisissant la bonne approche.
Utilisez une user story quand vous livrez de la valeur par incréments sur un produit mature et que l’équipe peut discuter des détails ensemble. Utilisez un cas d’utilisation quand la fonctionnalité implique plusieurs acteurs, une logique de branchement ou un processus réglementé qui exige une trace écrite. La plupart des projets réels ont besoin des deux, et la bonne méthode consiste à écrire d’abord le cas d’utilisation, puis à le découper en stories que l’équipe peut réellement terminer dans un sprint.
Voici la carte rapide :
Ce choix se répercute sur la planification de sprint et sur la traçabilité. Les équipes qui ne jurent que par les stories perdent souvent de vue les cas limites dès que trois ou quatre stories touchent au même processus. Celles qui ne jurent que par les cas d’utilisation ont tendance à sur-documenter des fonctionnalités que personne n’a encore demandées, ce qui ralentit la livraison sans bénéfice réel.
Astuce : Si vous fixez un élément de backlog vide sans arriver à trancher, demandez-vous si un ingénieur QA pourrait écrire un test à partir de la seule phrase. Sinon, il vous faut probablement la structure d’un cas d’utilisation, pas juste une story plus longue.
Choisir entre une user story et un cas d’utilisation revient à évaluer la quantité de structure dont le processus a besoin pour qu’une équipe puisse le construire sans risque.
| Point | Détails |
|---|---|
| Adaptez l’artefact à la complexité | Les stories pour les fonctionnalités incrémentales à acteur unique ; les cas d’utilisation pour les processus multi-acteurs ou à branchements. |
| Les stories reportent le détail volontairement | Les 3C (Carte, Conversation, Confirmation) déplacent le détail vers la discussion, pas vers la carte elle-même. |
| Un cas d’utilisation a besoin de ses six sections | Acteur, préconditions, flux principal, flux alternatifs, exceptions et postconditions le rendent testable. |
| Convertissez avec traçabilité | Étiquetez chaque story issue d’un cas d’utilisation avec l’identifiant de ce dernier pour garder des exigences DRY. |
| Surveillez l’encombrement des stories | Des critères d’acceptation qui se ramifient signalent qu’il est temps d’écrire un cas d’utilisation et de découper le travail. |
Une user story est un énoncé court, en langage courant, d’un besoin, écrit du point de vue de la personne qui en tire bénéfice. Le gabarit standard est : « En tant que [utilisateur], je veux [action], afin de [bénéfice]. » C’est tout. Elle est volontairement incomplète.
Les stories ne sont pas des cahiers des charges. Ce sont les marque-pages d’une conversation que l’équipe n’a pas encore eue, et Scrum le dit sans détour : les stories fonctionnent parce qu’elles favorisent une compréhension partagée, pas parce que la phrase écrite contient tout ce que le développeur doit savoir. Le vrai détail arrive plus tard, par les 3C:
Voici un exemple : « En tant que client fidèle, je veux enregistrer mon adresse de livraison, afin de ne pas avoir à la ressaisir à chaque commande. » Les critères d’acceptation pourraient préciser que le système conserve jusqu’à cinq adresses, en marque une par défaut et permet au client de modifier ou de supprimer n’importe quelle entrée.
Astuce : Gardez les stories atomiques. Si votre liste de critères d’acceptation se met à se ramifier en scénarios « si ceci, alors cela » sur cinq niveaux, vous n’écrivez plus une story : vous écrivez un cas d’utilisation déguisé en story.
Un cas d’utilisation est une spécification structurée, étape par étape, de la façon dont un acteur interagit avec un système pour atteindre un objectif. Là où une story tient sur une fiche, un cas d’utilisation se lit comme un court scénario, avec des embranchements pour ce qui arrive quand les choses tournent mal.
La comparaison de Visual Paradigm le formule clairement : les user stories capturent le qui, le quoi et le pourquoi ; les cas d’utilisation capturent le comment, y compris les préconditions, le chemin principal, les chemins alternatifs et les exceptions. C’est cette structure qui rend les cas d’utilisation utiles dès qu’il y a plus d’un acteur ou plus d’une façon dont l’interaction peut échouer.
Un cas d’utilisation complet comprend généralement :
Un plan rapide pour « Traiter un remboursement » pourrait donner : le client lance un retour, le système vérifie l’éligibilité de la commande, le client choisit le mode de remboursement, le système valide la réponse de la passerelle de paiement, le système émet le remboursement et met à jour le statut de la commande. Chacune de ces cinq étapes peut se ramifier : et si la commande est hors du délai de retour ? Et si la passerelle expire ? Une story passerait sur ces branches. Un cas d’utilisation les nomme.
Les cas d’utilisation conviennent surtout aux systèmes interactifs, orientés utilisateur. Karl Wiegers a fait remarquer qu’ils sont moins efficaces pour les traitements par lots ou les systèmes très algorithmiques, où la complexité se cache en coulisses plutôt que dans l’interaction elle-même.
Rien n’éclaire mieux la différence que de voir une même fonctionnalité passer par les deux formats. Prenons la « réinitialisation de mot de passe », une fonctionnalité dont tout produit finit par avoir besoin.
En user story :
« En tant qu’utilisateur inscrit, je veux réinitialiser mon mot de passe, afin de retrouver l’accès à mon compte si je l’oublie. » Critères d’acceptation : le système envoie un lien de réinitialisation à l’adresse e-mail enregistrée, le lien expire au bout de 30 minutes, et l’utilisateur peut définir un nouveau mot de passe respectant les exigences de complexité.
En cas d’utilisation :
| Élément | Détail |
|---|---|
| Acteur | Utilisateur inscrit |
| Objectif | Retrouver l’accès au compte après l’oubli du mot de passe |
| Préconditions | L’utilisateur a une adresse e-mail vérifiée au dossier |
| Flux principal | L’utilisateur demande la réinitialisation, le système envoie le lien, l’utilisateur clique, définit un nouveau mot de passe, le système confirme et le connecte |
| Flux alternatif | L’utilisateur demande une réinitialisation pour une adresse non vérifiée ; le système envoie une demande de vérification à la place |
| Exceptions | Lien expiré, e-mail non délivrable, nouveau mot de passe non conforme, compte bloqué après trop de tentatives |
| Postconditions | Mot de passe mis à jour et anciennes sessions invalidées, ou utilisateur informé de l’échec avec la marche à suivre |
Remarquez ce que la story ne mentionne jamais : ce qu’il advient des sessions déjà ouvertes sur d’autres appareils, ce que fait le système d’une adresse non vérifiée, ou le nombre de tentatives de réinitialisation qui déclenche un blocage. Ce ne sont pas des oublis. Ce sont des détails que la story renvoie à la conversation et aux tests, exactement comme Mountain Goat Software décrit le fonctionnement des stories.
Le cas limite où la story seule ne suffit plus : dès que les critères d’acceptation de la « réinitialisation de mot de passe » listent cinq branches d’exception et trois chemins alternatifs, vous avez dépassé le format de la fiche. C’est le signal qu’il faut écrire le cas d’utilisation, puis le retailler en deux ou trois stories plus propres : une pour le chemin heureux, une pour la gestion du blocage, une pour le flux d’adresse non vérifiée.
La checklist INVEST est le filtre standard de la qualité d’une story, et il vaut la peine d’y faire passer chaque story avant qu’elle n’entre au backlog :
Découper une story trop grosse suit en général un schéma : découper par étape du processus (rechercher, filtrer, trier deviennent trois stories au lieu d’une), par variation de données (prendre d’abord l’import CSV, ajouter Excel ensuite), ou par rôle utilisateur (la vue administrateur livrée avant la vue en lecture seule). Le story mapping, une technique qui aligne les stories le long du parcours utilisateur, rend ces découpes visibles avant que quiconque ne se dispute sur le périmètre en réunion de planification.
Des tests d’acceptation écrits au format Gherkin traduisent les critères en quelque chose que le produit et la QA peuvent tous deux vérifier :
Étant donné un utilisateur inscrit disposant d’une adresse e-mail vérifiée
Quand il demande une réinitialisation de mot de passe
Alors le système envoie un lien de réinitialisation qui expire au bout de 30 minutes
Astuce : Confiez la responsabilité des tests d’acceptation à la personne qui écrit la story, pas à celle qui la prend en sprint. Celle qui est la plus proche du « pourquoi » repère le plus vite les cas limites manquants.
Un gabarit de cas d’utilisation qui survit à la validation des parties prenantes et au passage à l’ingénierie demande plus de structure qu’un paragraphe de prose. Les sections de base sur lesquelles s’appuient les praticiens :
Les diagrammes méritent leur place quand un cas d’utilisation implique plus de deux acteurs, ou quand les parties prenantes continuent de mal lire la description textuelle. Un diagramme de cas d’utilisation UML, avec les acteurs en bonshommes-bâtons et les cas d’utilisation en ovales reliés par des traits, clarifie le périmètre d’un coup d’œil, là où trois paragraphes échouent. Passez le diagramme pour les flux simples à acteur unique : il ajoute de la charge sans ajouter de clarté.
Gardez le récit concis : une phrase par étape, voix active, aucun détail d’implémentation. « Le système valide le jeton de paiement » vaut mieux que « le microservice de paiement appelle l’API de la passerelle tierce et analyse la réponse JSON ». Cela a sa place dans un document de conception technique, pas dans le cas d’utilisation.
Relier les scénarios aux cas de test est ce qui empêche les cas d’utilisation de se périmer. Chaque flux alternatif et chaque exception devrait correspondre à au moins un identifiant de cas de test. Quand les équipes sautent cette étape, les cas d’utilisation deviennent une documentation à laquelle personne ne se fie, parce que personne ne sait si les tests correspondent encore au comportement décrit six mois plus tard.
La décision se joue en général sur trois variables : la complexité, la réglementation et la durée de vie attendue de la documentation.
| Attribut du projet | Penchez vers |
|---|---|
| Acteur unique, chemin simple | User story |
| Plusieurs acteurs ou systèmes en interaction | Cas d’utilisation |
| Secteur réglementé exigeant des pistes d’audit | Cas d’utilisation |
| Fonctionnalité rapide sur un produit stable et bien compris | User story |
| Nouveau système dont le comportement doit être documenté avant construction | Cas d’utilisation |
| Équipe distribuée ayant besoin d’un contexte partagé sans point quotidien | Cas d’utilisation |
Trois règles rapides à retenir : si une fonctionnalité touche plus d’un acteur et compte plus de deux flux alternatifs, écrivez d’abord le cas d’utilisation. Si les critères d’acceptation d’une story se mettent à ressembler à un document juridique, vous avez choisi le mauvais artefact. Si votre équipe travaille dans la même pièce et livre chaque semaine, les stories seules suffisent en général.
En pratique, cela se déroule de façon prévisible. Un tunnel de commande pour un site e-commerce avec un seul prestataire de paiement et un seul mode de livraison tient confortablement en trois ou quatre stories. Le même tunnel avec trois prestataires de paiement, une livraison fractionnée et une escalade en revue anti-fraude passe d’abord par un cas d’utilisation, parce que les flux alternatifs sont plus nombreux que le chemin heureux. Un formulaire d’admission en santé avec accès par rôle et journalisation d’audit exige un cas d’utilisation avant la moindre story, car la comparaison de LogRocket souligne que les besoins de réglementation et de conformité sont précisément là où les cas d’utilisation justifient leur coût.
Une fois le cas d’utilisation écrit, le vrai travail consiste à le transformer en quelque chose qu’une équipe de sprint peut exécuter sans perdre le détail que vous venez de capturer. C’est là que la plupart des équipes réussissent la livraison hybride ou abandonnent discrètement un artefact au profit de l’autre, par lassitude.
Une approche de traçabilité simple qui fonctionne sans outillage supplémentaire : tenir un tableur ou un champ de backlog qui associe chaque identifiant de cas d’utilisation aux identifiants de ses stories filles, et le mettre à jour à mesure que des stories s’ajoutent ou se découpent. Ce n’est pas glorieux, mais dériver les stories d’un cas d’utilisation validé de cette manière garde des exigences DRY au lieu de les éparpiller dans une douzaine de stories sans point de référence commun.
Checklist de décomposition avant de clore la revue du cas d’utilisation :
Attention à l’encombrement des stories : quand les critères d’acceptation d’une story enflent au-delà de cinq ou six conditions parce qu’elle absorbe discrètement une logique de branchement qui relève d’une autre story, découpez-la. Cette boursouflure est en général le signe que l’étape de décomposition du cas d’utilisation a été sautée.
Gabarit de user story :
Gabarit de cas d’utilisation :
Identifiant du cas d’utilisation : UC-[numéro]
Nom : [titre court et descriptif]
Acteur principal : [qui le déclenche]
Préconditions : [ce qui doit être vrai avant]
Flux principal : [étapes numérotées]
Flux alternatifs : [variantes numérotées, rattachées à une étape du flux principal]
Exceptions : [conditions d’échec et réponse du système]
Postconditions : [état final garanti]
Checklist « prêt pour l’affinage » (stories) :
Checklist « prêt pour validation » (cas d’utilisation) :
Dix erreurs reviennent sans cesse dans les backlogs et les documents d’exigences, et la plupart ont une correction simple :
Les outils de backlog comme Jira, Azure DevOps et Linear gèrent nativement les stories, et la plupart acceptent des champs personnalisés ou des liens pour rattacher une story à l’identifiant d’un cas d’utilisation parent. Les référentiels d’exigences (Confluence, Notion ou un outil dédié de gestion des exigences) accueillent le récit complet du cas d’utilisation, là où le format d’une carte de backlog ne suffit plus.
Les outils de diagramme prennent tout leur intérêt dès qu’un cas d’utilisation implique trois acteurs ou plus. Un diagramme de cas d’utilisation UML réalisé dans un outil comme Lucidchart ou Visual Paradigm clarifie le périmètre plus vite qu’un paragraphe de plus. Les outils de gestion des tests (TestRail, Xray) bouclent la boucle en reliant les critères d’acceptation et les exceptions des cas d’utilisation à de vrais cas de test, pour que personne n’ait à deviner si le comportement documenté correspond encore à ce qui est livré.
Quelques conventions de nommage font gagner un temps réel : préfixer les identifiants de cas d’utilisation de façon constante (UC-001), étiqueter les stories ou les cas d’utilisation liés à la conformité avec un libellé partagé comme regulated, et ne jamais laisser une story désigner un cas d’utilisation par son seul nom, puisque les noms changent et pas les identifiants. Pour les équipes qui construisent des fonctionnalités pilotées par l’IA, où le comportement est probabiliste plutôt que déterministe, des tests de régression structurés deviennent particulièrement importants, car les critères d’acceptation seuls capturent rarement toutes les façons dont la sortie d’un modèle peut dériver.
La documentation reste vivante quand elle est relue à chaque livraison, et non traitée comme un artefact ponctuel. Une approche par journal des modifications qui trace ce qui a changé et quand donne aux équipes un moyen léger de garder cas d’utilisation et stories alignés sur ce qui est réellement déployé.
L’auditabilité change complètement le calcul. Quand un régulateur ou une équipe de conformité interne doit voir exactement comment un système se comporte dans toutes les conditions, les exceptions et postconditions structurées d’un cas d’utilisation fournissent une preuve qu’une story de deux phrases n’apportera jamais.
En finance, les pistes d’audit exigent des flux alternatifs documentés pour chaque état de transaction, y compris les échecs partiels et les annulations. En santé, les processus validés imposent souvent une validation formelle des séquences d’interaction exactes avant qu’un système ne touche des données patient, ce qui rend les sections de préconditions et de postconditions d’un cas d’utilisation quasi obligatoires. Dans les systèmes critiques pour la sécurité, des flux déterministes et des preuves d’acceptation documentées ne sont pas optionnels. La clause « afin de » d’une story ne tient pas quand un auditeur demande ce qu’il advient si un capteur tombe en panne en pleine séquence.
Le geste concret consiste à intégrer les preuves de conformité directement dans les sections d’exception et de postcondition du cas d’utilisation, plutôt que d’entretenir un document de conformité séparé qui finit inévitablement par s’écarter de ce que fait réellement le système.
Le processus de build de Kreante commence presque toujours par un cas d’utilisation, même sur des projets menés en cycles de sprints agiles dès le premier jour. Sur le projet DAVCO AI, l’équipe a validé le processus central sous forme de cas d’utilisation avec le client avant d’écrire la moindre story, en cartographiant chaque acteur et chaque exception du pipeline d’automatisation. Ce cas d’utilisation est ensuite devenu le document source d’un backlog de stories prêtes pour le sprint, chacune rattachée à la section du processus initial qu’elle couvrait.
La leçon qui se confirme sans cesse : sauter l’étape du cas d’utilisation sur tout ce qui implique plus d’un acteur coûte plus de temps en reprises qu’elle n’en fait gagner en préparation. Les équipes qui veulent adopter cette approche hybride n’ont pas besoin d’un processus plus lourd : il leur faut un point de contrôle discipliné avant l’écriture des stories.
Si votre équipe se demande si une fonctionnalité mérite ce niveau de structure en amont, en particulier pour des processus pilotés par l’IA ou des automatisations à réelle logique de branchement, le travail de développement de solutions d’IA de Kreante commence exactement par ce type de validation de cas d’utilisation, avant qu’une seule ligne de code ne soit écrite. C’est la différence entre un prototype qui marche en démo et un système qui tient quand de vrais utilisateurs commencent à heurter les cas limites que personne n’avait notés.
Quelques sources méritent d’être gardées sous la main si vous voulez aller plus loin que cette comparaison :
Pour les équipes qui hésitent sur la part de détail à mettre par écrit plutôt qu’à laisser à la conversation, l’article de Kreante sur la communication claire en gestion de projet traite directement le versant alignement des parties prenantes de ce problème.
Une user story est un énoncé court et informel d’un besoin, destiné à déclencher une conversation, tandis qu’un cas d’utilisation est une spécification structurée, étape par étape, couvrant les préconditions, le flux principal, les flux alternatifs et les exceptions.
Les 3C sont la Carte (le texte court de la story), la Conversation (la discussion qui précise le détail) et la Confirmation (les critères d’acceptation qui définissent quand la story est terminée).
Non. Un epic est une grande user story, trop volumineuse pour un seul sprint, qui se découpe en stories plus petites au fil du temps, tandis qu’un cas d’utilisation est une spécification comportementale structurée, avec des acteurs, des flux et des exceptions définis. Leurs périmètres peuvent se recouper, mais ils sont construits différemment et servent des objectifs de documentation différents.
Parmi les exemples courants : « traiter un remboursement », « réinitialiser un mot de passe » avec gestion du blocage et de l’expiration, « intégrer un nouveau collaborateur » à cheval sur les systèmes RH et informatiques, ou « déposer une demande d’indemnisation » avec ses branches de validation et d’approbation, chacun décrit avec ses acteurs, son flux principal et ses chemins alternatifs.
Oui, et c’est une bonne pratique courante. Le flux principal, les flux alternatifs et les exceptions d’un cas d’utilisation validé deviennent chacun des stories candidates, chaque story étant rattachée à l’identifiant du cas d’utilisation d’origine pour la traçabilité.
Pour aller plus loin
Ne laissez pas votre veille s'arrêter ici. Explorez nos autres ressources pour maîtriser votre stack technologique.
FundamentalsDécouvrez comment atténuer les biais de l'IA tout au long du cycle de vie du modèle et adoptez des approches structurées pour des résultats équitables.
FundamentalsDiscover the future of app development with our comprehensive guide to No Code in 2025. Learn how No Code platforms empower businesses to innovate rapidly, reduce costs, and streamline operations without traditional coding. Perfect for business leaders ready to embrace digital transformation.
FundamentalsDive into No Code development and discover how it transforms app creation. Learn about essential tools, benefits, and automation success stories to enhance your business processes.