BUC - Business Use Case (cas d'utilisation métier)

À quoi sert ce document

Le BUC décrit une interaction complète entre un acteur et le système, du déclencheur jusqu'au résultat métier obtenu. Il existe parce qu'une exigence isolée ne dit pas dans quel enchaînement elle s'applique : le cas d'utilisation restitue ce déroulé. C'est aussi le point de rencontre entre MOA et MOE, chacun lisant le même scénario avec ses lunettes. Sa valeur tient à un détail souvent négligé : les alternatives et les cas d'erreur pèsent en général plus lourd, en charge de développement, que le scénario nominal.

Quand le produire

• Quand le besoin porte sur un enchaînement d'actions plutôt que sur une fonction isolée.
• Pour faire valider un comportement par un métier qui ne lit pas des exigences numérotées.
• Comme base de construction des cas de test de recette.
• Pour cadrer un périmètre agile : le BUC porte la vision d'ensemble, les user stories le découpage.

Le plan, rubrique par rubrique

1. Identification

   Les métadonnées qui rendent le cas traçable jusqu'en production.

   • Identifiant unique et stable (BUC-012), utilisé par les tests et les incidents
   • Intitulé formulé comme un objectif métier, verbe à l'infinitif
   • Version, auteur, date, statut de validation
   • Processus métier de rattachement

2. Acteurs

   Qui interagit avec le système dans ce cas.

   • Acteur principal : celui dont le besoin déclenche le cas
   • Acteurs secondaires : systèmes tiers, services appelés, validateurs
   • Rôle et habilitations requises

3. Objectif métier

   Le résultat recherché par l'acteur, en une phrase, sans vocabulaire technique.

4. Préconditions

   Ce qui doit être vrai avant que le cas puisse démarrer.

   • État du système et des données requis
   • Cas d'utilisation qui doivent avoir été exécutés avant

5. Déclencheur

   L'événement qui lance le scénario (action utilisateur, échéance, arrivée d'un fichier, appel d'API).

6. Scénario nominal

   Le déroulé quand tout se passe bien, en étapes numérotées alternant acteur et système.

   • Une action par étape, numérotée
   • Alternance explicite : ce que fait l'acteur, ce que fait le système en retour
   • Aucune branche conditionnelle dans le nominal : elles vont en extensions

7. Scénarios alternatifs

   Les variantes qui aboutissent quand même au résultat, rattachées au numéro d'étape concerné.

   • Numérotation dérivée (3a, 3b) pointant l'étape du nominal
   • Condition de déclenchement de la variante
   • Retour au nominal ou fin propre du cas

8. Cas d'erreur et exceptions

   Ce qui se passe quand ça échoue. Section la plus rentable du document.

   • Erreur, message rendu à l'acteur, état laissé au système
   • Reprise possible ou non, et à quel point du scénario
   • Traçabilité : ce qui est journalisé, ce qui déclenche une alerte

9. Postconditions

   L'état du système une fois le cas terminé, en succès comme en échec.

10. Règles de gestion

    Les règles métier appliquées dans le cas, référencées et non recopiées.

    • Renvoi vers le référentiel de règles (RG-034) plutôt que duplication
    • Calculs, seuils, contrôles de validité

11. Exigences rattachées

    Le lien de traçabilité avec le cahier des charges et les tests.

    • Exigences couvertes (EF-001, EF-014)
    • Cas de test associés

Les erreurs qui coûtent cher

• Écrire le scénario du point de vue du système. Un BUC se lit du côté de l'acteur : « le gestionnaire saisit la commande », pas « le module reçoit un objet Commande ».
• Ne traiter que le chemin heureux. Les cas d'erreur représentent le gros de la charge de développement et la quasi-totalité des incidents en production.
• Recopier les règles de gestion dans chaque BUC. À la première évolution, les copies divergent. Une règle vit à un seul endroit et se référence.
• Confondre BUC et user story. Le BUC décrit un usage métier complet et durable, la user story est une unité de découpage pour un sprint. Les deux coexistent, avec un lien entre eux.
• Faire un BUC par écran. Le découpage suit le processus métier, pas l'interface.