Une narration de cas d’utilisation bien r\u00e9dig\u00e9e transforme des objectifs syst\u00e9miques abstraits en sp\u00e9cifications concr\u00e8tes et \u00e9tape par \u00e9tape. En documentant des interactions pr\u00e9cises, des points de d\u00e9cision et des chemins de gestion des erreurs, les \u00e9quipes \u00e9tablissent une source unique de v\u00e9rit\u00e9 qui aligne les chefs de produit, les d\u00e9veloppeurs, les testeurs et les analystes m\u00e9tier. Cette \u00e9tude de cas explore l’anatomie d’une documentation de cas d’utilisation efficace, en d\u00e9montrant comment les r\u00e9cits structur\u00e9s, les mod\u00e8les standardis\u00e9s et les mod\u00e8les visuels compl\u00e9mentaires convergent pour produire des sp\u00e9cifications fonctionnelles sans ambigu\u00eft\u00e9. \u00c0 travers un sc\u00e9nario concret de retrait de cash par un distributeur automatique, nous examinerons comment capturer la logique m\u00e9tier, g\u00e9rer les d\u00e9viations et assurer la tra\u00e7abilit\u00e9 du concept \u00e0 la mise en \u0153uvre.<\/p>\n
![\"Mastering](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a0ff6c455a21.png\")
<\/p>\n
\n
1. Concepts fondamentaux<\/h2>\n
Avant d’\u00e9crire des sp\u00e9cifications d\u00e9taill\u00e9es, il est essentiel de comprendre les composants fondamentaux qui donnent \u00e0 un cas d’utilisation son int\u00e9grit\u00e9 structurelle :<\/p>\n
- \n
- \n
Acteur :<\/strong>\u00a0Toute entit\u00e9 (humaine, syst\u00e8me externe ou mat\u00e9riel) qui interagit avec le syst\u00e8me afin d’atteindre un objectif.<\/p>\n
- \n
- \n
Acteur principal :<\/em>\u00a0Initie l’interaction pour remplir un objectif sp\u00e9cifique (par exemple, un client bancaire).<\/p>\n<\/li>\n
- \n
Acteur secondaire\/Support :<\/em>\u00a0Fournit des services ou des donn\u00e9es n\u00e9cessaires au syst\u00e8me pendant son ex\u00e9cution (par exemple, une API bancaire centrale ou une passerelle de paiement).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n
- \n
Pr\u00e9conditions :<\/strong>\u00a0L’\u00e9tat du syst\u00e8me ou de l’environnement qui doit d\u00e9j\u00e0 exister avant que le cas d’utilisation ne puisse commencer. Elles sont suppos\u00e9es vraies et ne sont pas valid\u00e9es dans le d\u00e9roulement.<\/p>\n<\/li>\n
- \n
D\u00e9clencheur :<\/strong>\u00a0L’\u00e9v\u00e9nement sp\u00e9cifique ou l’action utilisateur qui d\u00e9clenche le cas d’utilisation.<\/p>\n<\/li>\n
- \n
Sc\u00e9nario principal de succ\u00e8s (flux de base) :<\/strong>\u00a0La s\u00e9quence optimale, sans erreur, des \u00e9tapes qui conduit \u00e0 la r\u00e9ussite de l’objectif de l’acteur. Souvent appel\u00e9e le \u00ab chemin heureux \u00bb.<\/p>\n<\/li>\n
- \n
Extensions \/ Flux alternatifs et d’exception :<\/strong>\u00a0Les d\u00e9viations document\u00e9es par rapport au flux principal.<\/p>\n
- \n
- \n
Flux alternatifs :<\/em>\u00a0Des chemins valides diff\u00e9rents pour atteindre le m\u00eame objectif (par exemple, utiliser une m\u00e9thode de paiement diff\u00e9rente).<\/p>\n<\/li>\n
- \n
Flux d’exception :<\/em>\u00a0Conditions d’erreur, \u00e9checs de validation ou contraintes syst\u00e8me qui interrompent l’objectif et n\u00e9cessitent un traitement sp\u00e9cifique.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n
- \n
Postconditions :<\/strong>\u00a0L’\u00e9tat garanti du syst\u00e8me, des donn\u00e9es ou de l’environnement apr\u00e8s la r\u00e9ussite du cas d’utilisation.<\/p>\n<\/li>\n<\/ul>\n
\n2. Le mod\u00e8le de sp\u00e9cification standard<\/h2>\n
La coh\u00e9rence est essentielle pour la maintenabilit\u00e9. Le mod\u00e8le suivant fournit une structure largement adopt\u00e9e qui garantit la compl\u00e9tude sans redondance inutile :<\/p>\n
\n\n
\n \nChamp<\/th>\n Description<\/th>\n<\/tr>\n<\/thead>\n \n ID et nom du cas d’utilisation<\/strong><\/td>\n Un identifiant unique et un titre verbe-nom (par exemple\u00a0 UC-201 : Retirer de l'argent<\/code>).<\/td>\n<\/tr>\n\n Acteur(s)<\/strong><\/td>\n Liste tous les participants principaux et secondaires.<\/td>\n<\/tr>\n \n Description<\/strong><\/td>\n Un r\u00e9sum\u00e9 concis du but du cas d’utilisation et de sa valeur m\u00e9tier.<\/td>\n<\/tr>\n \n Pr\u00e9conditions<\/strong><\/td>\n \u00c9tats du syst\u00e8me ou environnementaux requis avant le d\u00e9marrage.<\/td>\n<\/tr>\n \n D\u00e9clencheur<\/strong><\/td>\n L’\u00e9v\u00e9nement exact qui d\u00e9clenche l’interaction.<\/td>\n<\/tr>\n \n Sc\u00e9nario principal de succ\u00e8s<\/strong><\/td>\n \u00c9tapes num\u00e9rot\u00e9es et s\u00e9quentielles d\u00e9taillant le parcours r\u00e9ussi par d\u00e9faut.<\/td>\n<\/tr>\n \n Extensions \/ Exceptions<\/strong><\/td>\n Flux alternatifs mapp\u00e9s \u00e0 des \u00e9tapes sp\u00e9cifiques du sc\u00e9nario principal (par exemple\u00a0 3a<\/code>,\u00a08b<\/code>).<\/td>\n<\/tr>\n\n Postconditions<\/strong><\/td>\n L’\u00e9tat final du syst\u00e8me apr\u00e8s une ex\u00e9cution r\u00e9ussie.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n3. R\u00e9cit d’\u00e9tude de cas : UC-201 Retirer de l’argent<\/h2>\n
La sp\u00e9cification suivante montre comment le mod\u00e8le et les concepts fondamentaux sont appliqu\u00e9s \u00e0 un sc\u00e9nario bancaire r\u00e9el.<\/p>\n
ID et nom du cas d’utilisation :<\/strong>\u00a0
UC-201 - Retirer de l'argent<\/code>
\nActeur principal :<\/strong>Client bancaire
\nActeur secondaire :<\/strong>\u00a0Syst\u00e8me bancaire central \/ R\u00e9seau de guichets automatiques
\nDescription :<\/strong>\u00a0D\u00e9cris comment un client bancaire authentifi\u00e9 retire de l’argent de son compte courant ou de son compte d’\u00e9pargne \u00e0 l’aide d’un guichet automatique (ATM).
\nPr\u00e9conditions :<\/strong>\u00a0Le guichet automatique maintient une connexion r\u00e9seau active et contient une quantit\u00e9 suffisante de monnaie physique.
\nD\u00e9clencheur :<\/strong>\u00a0Le client ins\u00e8re sa carte bancaire dans le lecteur de carte du guichet automatique.<\/p>\nSc\u00e9nario principal de succ\u00e8s (flux principal)<\/h3>\n
- \n
- \n
Le syst\u00e8me lit la carte bancaire et demande le num\u00e9ro d’identification personnel (PIN).<\/p>\n<\/li>\n
- \n
Le client saisit son PIN.<\/p>\n<\/li>\n
- \n
Le syst\u00e8me valide le PIN aupr\u00e8s du syst\u00e8me bancaire central.<\/p>\n<\/li>\n
- \n
Le syst\u00e8me affiche les options de transaction disponibles.<\/p>\n<\/li>\n
- \n
Le client s\u00e9lectionne \u00ab Retirer de l’argent \u00bb.<\/p>\n<\/li>\n
- \n
Le syst\u00e8me demande le type de compte (courant\/\u00e9pargne) et le montant du retrait.<\/p>\n<\/li>\n
- \n
Le client s\u00e9lectionne le compte cible et saisit un montant disponible.<\/p>\n<\/li>\n
- \n
Le syst\u00e8me v\u00e9rifie la disponibilit\u00e9 des fonds aupr\u00e8s du syst\u00e8me bancaire central.<\/p>\n<\/li>\n
- \n
Le syst\u00e8me d\u00e9bite le compte et commande au distributeur de billets de lib\u00e9rer le montant sp\u00e9cifi\u00e9.<\/p>\n<\/li>\n
- \n
Le syst\u00e8me distribue l’argent, expulse la carte et imprime un re\u00e7u de transaction.<\/p>\n<\/li>\n
- \n
Le client r\u00e9cup\u00e8re l’argent, la carte et le re\u00e7u.<\/p>\n<\/li>\n<\/ol>\n
Extensions (flux alternatifs et d’exception)<\/h3>\n
- \n
- \n
3a. PIN invalide :<\/strong><\/p>\n
- \n
- \n
Le syst\u00e8me informe le client du PIN incorrect et demande une nouvelle saisie.<\/p>\n<\/li>\n
- \n
Le client saisit un nouveau PIN.<\/p>\n<\/li>\n
- \n
Reprendre \u00e0 l’\u00e9tape 3.<\/em><\/p>\n<\/li>\n
- \n
Exception :<\/em>\u00a0Si le client saisit un PIN invalide trois fois de suite, le syst\u00e8me retient la carte et termine la session.<\/p>\n<\/li>\n<\/ol>\n<\/li>\n
- \n
8a. Fonds insuffisants :<\/strong><\/p>\n
- \n
- \n
Le syst\u00e8me affiche une erreur \u00ab Fonds insuffisants \u00bb et invite le client \u00e0 saisir un montant inf\u00e9rieur ou \u00e0 annuler.<\/p>\n<\/li>\n
- \n
Le client s\u00e9lectionne \u00ab Annuler \u00bb.<\/p>\n<\/li>\n
- \n
Le syst\u00e8me \u00e9jecte la carte et termine la session.<\/p>\n<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n
Postconditions<\/h3>\n
La transaction est enregistr\u00e9e de mani\u00e8re s\u00e9curis\u00e9e, le solde du compte est mis \u00e0 jour avec pr\u00e9cision, l’inventaire physique des billets de l’ATM est r\u00e9duit en cons\u00e9quence, et le terminal revient \u00e0 l’\u00e9cran d’accueil inactif.<\/p>\n
\n4. Meilleures pratiques d’\u00e9criture<\/h2>\n
Pour garantir que les descriptions de cas d’utilisation restent exploitables, \u00e9volutives et conviviales pour les d\u00e9veloppeurs, respectez ces directives \u00e9tablies :<\/p>\n
- \n
- \n
Maintenez une perspective bo\u00eete noire :<\/strong>\u00a0Documentez\u00a0ce que<\/em>\u00a0le syst\u00e8me fait du point de vue de l’utilisateur, et non pas\u00a0comment<\/em>\u00a0il l’obtient internement. \u00c9vitez de faire r\u00e9f\u00e9rence aux sch\u00e9mas de base de donn\u00e9es, aux points d’entr\u00e9e d’API ou aux positions des pixels dans l’interface utilisateur.<\/p>\n<\/li>\n
- \n
Utilisez le voice active et une syntaxe claire :<\/strong>\u00a0Utilisez des constructions sujet-verbe directes pour \u00e9liminer toute ambigu\u00eft\u00e9.<\/p>\n
- \n
- \n
\u00c9vitez :<\/em>\u00a0\u00ab Le code PIN est \u00e9valu\u00e9 par le syst\u00e8me. \u00bb<\/p>\n<\/li>\n
- \n
Pr\u00e9f\u00e9r\u00e9 :<\/em>\u00a0\u00ab Le syst\u00e8me valide le code PIN. \u00bb<\/p>\n<\/li>\n<\/ul>\n<\/li>\n
- \n
Mettez en \u00e9vidence les extensions explicitement :<\/strong>\u00a0Attachez toujours les flux alternatifs et les flux d’exception directement au num\u00e9ro d’\u00e9tape \u00e0 partir duquel ils d\u00e9vient (par exemple,\u00a0
5a<\/code>\u00a0d\u00e9part de l’\u00e9tape 5). Cela pr\u00e9serve la tra\u00e7abilit\u00e9 et simplifie la g\u00e9n\u00e9ration des cas de test.<\/p>\n<\/li>\n- \n
Ciblez les processus \u00e9l\u00e9mentaires m\u00e9tier (EBP) :<\/strong>\u00a0Chaque cas d’utilisation doit repr\u00e9senter une t\u00e2che compl\u00e8te et valorisable effectu\u00e9e par un acteur en r\u00e9ponse \u00e0 un seul \u00e9v\u00e9nement m\u00e9tier. \u00c9vitez de documenter des clics d’interface utilisateur granulaires ou des micro-interactions syst\u00e8me.<\/p>\n<\/li>\n
- \n
S\u00e9parez les pr\u00e9conditions des d\u00e9clencheurs :<\/strong>\u00a0Une pr\u00e9condition est un \u00e9tat statique (par exemple, \u00ab L’utilisateur a une session active \u00bb), tandis qu’un d\u00e9clencheur est une action dynamique (par exemple, \u00ab L’utilisateur clique sur \u00ab Soumettre la commande \u00bb \u00bb). Les maintenir distincts emp\u00eache les chevauchements logiques et les confusions de port\u00e9e.<\/p>\n<\/li>\n<\/ol>\n
\n5. Visualisation des interactions syst\u00e8me<\/h2>\n
Bien que les r\u00e9cits textuels offrent une profondeur, les mod\u00e8les visuels fournissent une clart\u00e9 structurelle imm\u00e9diate. Int\u00e9grer les diagrammes de cas d’utilisation et les diagrammes de s\u00e9quence aux sp\u00e9cifications garantit que les parties prenantes partagent une compr\u00e9hension unifi\u00e9e des limites du syst\u00e8me et de son ex\u00e9cution temporelle.<\/p>\n
A. Diagramme des relations de cas d’utilisation<\/h3>\n
Ce diagramme cartographie les interactions des acteurs, d\u00e9finit les limites du syst\u00e8me et illustre les relations d’inclusion entre les comportements r\u00e9utilisables.<\/p>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a0ff6731cd78.png\")
<\/p>\n\n\nPlantUML<\/span>
\n
\n - \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n