Processus métier¶

Modéliser qui fait quoi, dans quel ordre, et comment les exceptions sont gérées — avec BPMN comme lingua franca.

Pourquoi modéliser les processus¶

Un système d'information n'existe pas dans le vide. Il automatise, partiellement ou totalement, des processus métier. Si on ne comprend pas le processus, on ne peut pas concevoir le système qui le supporte. Et si on ne le modélisé pas, on le comprend mal — chaque participant a sa propre vision, et les zones grises restent invisibles jusqu'à l'incident.

La modélisation des processus répond a trois questions :

1. Qui fait quoi ? Les rôles et responsabilités dans chaque étape.
2. Dans quel ordre ? Les enchainements, les parallelismes, les conditions.
3. Que se passe-t-il quand ca deraille ? Les exceptions, les timeouts, les escalades.

On utilisé BPMN 2.0 comme notation de référence. Non pas parce que c'est la seule option, mais parce que c'est un standard ISO (19510) compris par les équipes métier et techniques. Les diagrammes d'activité UML sont une alternative viable — on les compare plus loin.

BPMN 2.0 : les fondamentaux¶

BPMN (Business Process Model and Notation) organisé un processus autour de quatre familles d'éléments : les événements, les activités, les passerelles (gateways) et les flux.

Événements¶

Un événement représenté quelque chose qui se produit pendant le processus. Il a une cause ou un effet.

Activités¶

Passerelles (Gateways)¶

Les passerelles controlent la divergence et la convergence des flux.

Flux¶

Pools et lanes¶

Les pools et les lanes répondent à la question "qui fait quoi". Un pool représenté un participant (organisation, système, rôle majeur). Les lanes subdivisent un pool en responsabilités internes.

graph TD
    subgraph "Pool : Client"
        A1[Passer commande] --> A2[Recevoir confirmation]
    end

    subgraph "Pool : Plateforme e-commerce"
        subgraph "Lane : Service commercial"
            B1[Valider commande] --> B2[Confirmer au client]
        end
        subgraph "Lane : Logistique"
            B3[Preparer colis] --> B4[Expedier]
        end
    end

    A1 --"message : commande"--> B1
    B2 --"message : confirmation"--> A2
    B1 --> B3

Règles fondamentales¶

• Un flux de sequence ne traverse jamais la frontiere d'un pool. Seuls les flux de message connectent les pools.
• Les lanes sont optionnelles — elles ajoutent de la clarte sur les responsabilités mais ne changent pas la semantique.
• Un pool "boite noire" (collapsed pool) représenté un participant dont on ne détaillé pas le processus interne.

Sous-processus et call activities¶

Sous-processus¶

Un sous-processus encapsule un fragment de processus pour réduire la complexité visuelle. Il existe en deux variantes :

• Sous-processus imbrique : défini à l'intérieur du processus parent. Il voit les données du parent.
• Sous-processus evenementiel : déclenché par un événement (erreur, timer, signal). Utile pour la gestion d'exceptions.

Call activities¶

Une call activity référence un processus défini séparément et réutilisable. C'est l'équivalent d'un appel de fonction. Le processus de facturation peut être appelé depuis le processus de vente, le processus de retour et le processus d'abonnement.

Exemple complet : processus de commande¶

flowchart TD
    START((Commande recue)) --> VALID[Valider la commande]
    VALID --> STOCK{Stock disponible ?}

    STOCK --"Oui"--> PAR1[/Parallele/]
    STOCK --"Non"--> BACK[Notifier client - rupture]
    BACK --> END_KO((Fin - annulation))

    PAR1 --> FACT[Generer facture]
    PAR1 --> PREP[Preparer colis]

    FACT --> PAR2[/Synchronisation/]
    PREP --> PAR2

    PAR2 --> PAY{Paiement confirme ?}
    PAY --"Oui"--> SHIP[Expedier]
    PAY --"Non"--> CANCEL[Annuler commande]

    SHIP --> NOTIF[Notifier client - expedition]
    NOTIF --> END_OK((Fin - livraison))
    CANCEL --> END_KO2((Fin - annulation))

Ce diagramme illustre :

• Un événement de début (commande reçue)
• Une passerelle exclusive (stock disponible ?)
• Une passerelle parallèle (facturation et préparation en parallèle)
• Une synchronisation (attente des deux branches)
• Une seconde passerelle exclusive (paiement confirme ?)
• Deux événements de fin (livraison ou annulation)

Diagramme d'activité UML vs BPMN¶

Les diagrammes d'activité UML et les diagrammes BPMN couvrent un territoire similaire. Le choix dépend du public et du contexte.

Orchestration vs choregraphie¶

Deux philosophies existent pour coordonner les participants d'un processus.

Orchestration¶

Un coordinateur central (orchestrateur) dirige le processus. Il appelle les participants dans l'ordre, géré les erreurs, décidé des branchements. En BPMN, c'est un processus dans un pool qui envoie des messages aux autres pools.

Avantages : visibilité centralisee, gestion des erreurs simple, processus lisible. Inconvénients : point de défaillance unique, couplage fort avec l'orchestrateur.

Choregraphie¶

Aucun coordinateur. Chaque participant réagit aux événements des autres. Le processus emerge de la collaboration. En BPMN 2.0, un diagramme de choregraphie montre les interactions sans pool central.

Avantages : découplage, autonomie des participants, résilience. Inconvénients : processus difficile à suivre, gestion des erreurs distribuée, debugging complexe.

graph LR
    subgraph "Orchestration"
        O[Orchestrateur] --"1. Valider"--> S1[Service stock]
        O --"2. Facturer"--> S2[Service facturation]
        O --"3. Expedier"--> S3[Service logistique]
    end

graph LR
    subgraph "Choregraphie"
        E1[Commande creee] --"ecoute"--> S1[Service stock]
        S1 --"Stock reserve"--> S2[Service facturation]
        S2 --"Facture emise"--> S3[Service logistique]
    end

Le choix entre orchestration et choregraphie est une décision d'architecture qui impacte profondement le couplage, la testabilité et l'observabilité du système. On y revient en détail au chapitre sur la connexion des systèmes.

Niveaux de détail et decomposition¶

Un processus BPMN se decompose en niveaux de détail, comme un DFD. Le niveau 0 montre le processus de bout en bout avec les étapes principales. Chaque étape peut être détaillée dans un sous-processus.

Stratégie de decomposition¶

On commence toujours par la vue d'ensemble. Si elle ne tient pas sur un écran, elle est déjà trop détaillée. Chaque sous-processus est documente séparément — un diagramme BPMN lisible tient sur une page A4 en paysage.

Erreurs de decomposition¶

• Tout mettre sur un seul diagramme : le processus devient une carte du metro illisible
• Découper trop tôt : on crée des sous-processus avant de comprendre le processus global
• Sous-processus a une seule activité : sur-decomposition, la granularité est trop fine

Bonnes pratiques de modélisation¶

Chapitre suivant : Données et domaine — classes, relations, modèle entité-relation et normalisation pour structurer les données du système.