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

| | |
| --- | --- |
| **Projet** | *à compléter* |
| **Version** | *à compléter* |
| **Date** | *à compléter* |
| **Auteur** | *à compléter* |
| **Rédigé par** | MOA / business analyst |
| **Destinataires** | Métier, MOE, testeurs |
| **Statut** | Brouillon / En relecture / Validé |

---

## 1. Identification

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

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 2. Acteurs

<!-- Qui interagit avec le système dans ce cas. -->

<!-- Points à couvrir :
     - Acteur principal : celui dont le besoin déclenche le cas
     - Acteurs secondaires : systèmes tiers, services appelés, validateurs
     - Rôle et habilitations requises
-->

*à compléter*

## 3. Objectif métier

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

*à compléter*

## 4. Préconditions

<!-- Ce qui doit être vrai avant que le cas puisse démarrer. -->

<!-- Points à couvrir :
     - État du système et des données requis
     - Cas d'utilisation qui doivent avoir été exécutés avant
-->

*à compléter*

## 5. Déclencheur

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

*à compléter*

## 6. Scénario nominal

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

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 7. Scénarios alternatifs

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

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 8. Cas d'erreur et exceptions

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

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 9. Postconditions

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

*à compléter*

## 10. Règles de gestion

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

<!-- Points à couvrir :
     - Renvoi vers le référentiel de règles (RG-034) plutôt que duplication
     - Calculs, seuils, contrôles de validité
-->

*à compléter*

## 11. Exigences rattachées

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

<!-- Points à couvrir :
     - Exigences couvertes (EF-001, EF-014)
     - Cas de test associés
-->

*à compléter*

---

## Notes de rédaction

**Quand produire ce document**

- 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.

**Erreurs les plus fréquentes**

- É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.

**Référentiel de rattachement**

UML use case, format Cockburn. La structure de référence (acteur, préconditions, scénario nominal numéroté, extensions, postconditions) vient d'Alistair Cockburn, Writing Effective Use Cases. Elle reste la plus utilisée en contexte MOA français.

---

Modèle « BUC - Business Use Case (cas d'utilisation métier) » (Conception fonctionnelle), publié par DataALC.
Version en ligne, commentée : https://www.dataalc.com/boite-a-outils/templates/buc/

Ce modèle est fourni comme base de travail : adaptez-le à votre contexte, supprimez les rubriques sans objet plutôt que de les laisser vides.