Acteurs et interactions¶

Identifier qui utilise le système, ce qu'il en attend, et ou s'arrêtent les responsabilités du système.

Pourquoi commencer par les acteurs¶

Avant de modéliser des classes, des flux ou des composants, on doit répondre a une question fondamentale : qui interagit avec le système, et pour obtenir quoi ? Le diagramme de cas d'usage UML existe précisément pour ca. Il ne décrit pas comment le système fonctionne — il décrit ce que le système fait pour ses acteurs.

C'est une distinction cruciale. On ne modélisé pas l'implémentation. On modélisé la valeur percue par l'extérieur. Un cas d'usage "Passer une commande" ne dit rien sur la base de données, le framework web ou le pattern CQRS. Il dit : un client peut passer une commande, et le système s'engage à la traiter.

Cette vue est la première qu'on produit dans un projet parce qu'elle force a clarifier les frontieres. Tant qu'on ne sait pas ce qui est dedans et ce qui est dehors, on ne peut pas concevoir l'intérieur.

Les acteurs¶

Un acteur est une entité externe au système qui interagit avec lui. Il représenté un rôle, pas une personne physique. Un même individu peut incarner plusieurs acteurs (un employe qui est aussi client). Un acteur peut être humain ou non.

Catégories d'acteurs¶

Generalisation d'acteurs¶

Quand plusieurs acteurs partagent des cas d'usage communs, on utilise la generalisation. Un acteur "Employe" generalise "Manager" et "Opérateur" — les deux heritent des cas d'usage d'Employe, mais chacun a des cas spécifiques.

graph TD
    EMP[Employe]
    MGR[Manager]
    OPR[Operateur]

    MGR -->|herite| EMP
    OPR -->|herite| EMP

La generalisation evite de dupliquer les cas d'usage communs. Mais on ne doit pas en abuser — une hiérarchie profonde d'acteurs est un signal que le modèle dérivé vers l'implémentation (on confond rôles métier et droits d'accès).

Le diagramme de cas d'usage¶

Le diagramme de cas d'usage UML contient trois éléments fondamentaux : les acteurs, les cas d'usage (ellipses), et la frontiere du système (rectangle).

Éléments constitutifs¶

Exemple : plateforme e-commerce¶

graph LR
    subgraph "Systeme e-commerce"
        UC1((Parcourir le catalogue))
        UC2((Passer une commande))
        UC3((Payer))
        UC4((Suivre la livraison))
        UC5((Gerer le stock))
        UC6((Traiter le retour))
        UC7((Authentifier))
    end

    CLI[Client] --> UC1
    CLI --> UC2
    CLI --> UC4
    CLI --> UC6

    GES[Gestionnaire] --> UC5
    GES --> UC6

    PAY[Passerelle paiement] --> UC3
    TRA[Transporteur] --> UC4

    UC2 --"include"--> UC7
    UC2 --"include"--> UC3
    UC6 --"extend"--> UC2

Ce diagramme répond a trois questions en un regard : qui sont les acteurs, que fait le système pour eux, et ou s'arrêté la responsabilité du système (la passerelle de paiement et le transporteur sont dehors).

La frontiere du système¶

La frontiere du système est l'élément le plus sous-estime du diagramme de cas d'usage. Elle materialise une décision d'architecture : ce que le système prend en charge vs ce qu'il délégué.

Ce que la frontiere révélé¶

Placer un élément à l'intérieur ou à l'extérieur de la frontiere a des conséquences directes :

Diagramme de contexte¶

Le diagramme de contexte est une version simplifiée du cas d'usage : le système est une boite noire, les acteurs sont autour, et les fleches indiquent les interactions de haut niveau. C'est le niveau 1 du modèle C4 (voir chapitre 03, section C4).

graph TD
    CLI[Client web/mobile] --"commandes, consultations"--> SYS[Plateforme e-commerce]
    SYS --"confirmations, notifications"--> CLI

    GES[Gestionnaire] --"gestion stock, retours"--> SYS
    SYS --"tableaux de bord"--> GES

    SYS --"requetes de paiement"--> PAY[Passerelle paiement]
    PAY --"confirmations"--> SYS

    SYS --"demandes d'expedition"--> TRA[Transporteur]
    TRA --"statuts livraison"--> SYS

Specifier les cas d'usage¶

Un diagramme seul ne suffit pas. Chaque cas d'usage significatif doit être spécifié avec un scenario nominal et des scenarios alternatifs. La spécification est le contrat entre le métier et l'équipe technique.

Structure d'une spécification¶

Exemple de spécification¶

Cas d'usage : Passer une commande

• Acteur principal : Client authentifie
• Preconditions : Le panier contient au moins un article disponible
• Postconditions : La commande est enregistree, le stock est réservé, le paiement est initié

Scenario nominal :

1. Le client consulte son panier
2. Le client confirme l'adresse de livraison
3. Le système calcule les frais de port
4. Le client choisit le mode de paiement
5. Le système transmet la demande à la passerelle de paiement
6. La passerelle confirme le paiement
7. Le système enregistre la commande et réservé le stock
8. Le système envoie une confirmation par email

Extensions :

• 3a. Adresse hors zone de livraison : le système affiche une erreur et propose de modifier l'adresse
• 6a. Paiement refuse : le système propose un autre moyen de paiement
• 6b. Timeout de la passerelle : le système enregistre la commande en attente et notifie le client
• 7a. Stock insuffisant : le système propose un article de remplacement ou un délai

Erreurs classiques¶

Modéliser les cas d'usage semble simple — c'est justement ce qui rend les erreurs fréquentes. Voici les pieges les plus courants.

Trop de cas d'usage¶

Quand le diagramme contient 40 ellipses, il ne communique plus rien. On a confondu cas d'usage et fonctionnalité. "Modifier le mot de passe" n'est probablement pas un cas d'usage — c'est une étape d'un cas plus large ("Gérer son compte"). La règle : un cas d'usage représenté un objectif complet de l'acteur, pas une action atomique.

Mauvais niveau d'abstraction¶

À l'inverse, "Utiliser le système" est trop abstrait pour être utile. Le bon niveau se situe entre "l'acteur atteint un objectif métier" et "l'acteur clique sur un bouton". On vise le niveau "objectif utilisateur" (user goal) dans la terminologie d'Alistair Cockburn.

Confondre cas d'usage et fonctionnalité technique¶

"Écrire dans la base de données" n'est pas un cas d'usage. Aucun acteur externe ne formule ce besoin. Les cas d'usage décrivent des interactions métier, pas des opérations techniques internes.

Relations include/extend mal utilisées¶

On utilisé include quand un cas inclut toujours un autre (sans exception). On utilisé extend quand un cas ajoute un comportement optionnel a un autre. En pratique, extend est souvent mal compris et mal utilisé — si on hesite, on s'en passe.

graph LR
    UC1((Passer commande)) --"include"--> UC2((Authentifier))
    UC3((Appliquer un code promo)) --"extend"--> UC1

L'authentification est toujours nécessaire pour passer commande (include). L'application d'un code promo est optionnelle (extend).

Oublier les acteurs système¶

On pense naturellement aux acteurs humains. On oublie les systèmes externes : le batch de synchronisation, le webhook du partenaire, le service de monitoring. Ces acteurs ont des contraintes différentes (latence, format, authentification) et leurs cas d'usage doivent apparaître.

Niveaux de cas d'usage (Cockburn)¶

Alistair Cockburn propose une échelle de niveaux pour classer les cas d'usage selon leur portee. Cette classification aide à éviter les problèmes de granularité.

La règle : la majorité des cas d'usage d'un système doivent être au niveau "user goal". Les cas "summary" servent de chapeau pour organiser. Les cas "subfunction" ne sont détaillés que s'ils sont partages par plusieurs cas de niveau supérieur (comme l'authentification).

De l'analyse au modèle vivant¶

Le diagramme de cas d'usage est un outil d'analyse, pas un artefact a maintenir indéfiniment. Une fois que les frontieres et les acteurs sont stabilises, le diagramme a rempli son rôle. Ce qui doit vivre, ce sont les spécifications de cas d'usage — elles deviennent des scenarios de test, des critères d'acceptation, des contrats d'API.

La traçabilité fonctionne ainsi :

graph LR
    CU[Cas d'usage] --"se traduit en"--> US[User story / specification]
    US --"se traduit en"--> TEST[Test d'acceptation]
    TEST --"valide"--> CODE[Implementation]

Un cas d'usage qui n'a pas de test d'acceptation correspondant est un cas d'usage oublie. Un test d'acceptation qui ne correspond à aucun cas d'usage est un test orphelin. La cohérence entre les deux est le signal qu'on a bien modélisé.

Chapitre suivant : Processus metier — modéliser les enchainements d'activités, les responsabilités et les événements avec BPMN.