Modélisation BPMN des processus

Introduction

Dans la leçon précédente, les processus de l’organisation ont été identifiés et classés selon la typologie AFNOR : processus métiers, processus de support et processus de pilotage. Cette base est indispensable, car on ne peut pas représenter correctement un processus si l’on ne sait pas d’abord ce qu’il produit, qui y participe, où il commence, où il se termine et quels événements le font évoluer.

Cette leçon prolonge directement ce travail en abordant la représentation d’un processus sous forme d’un diagramme BPMN. L’objectif n’est pas de faire de la technique informatique avancée, mais de savoir lire, construire et améliorer un diagramme de collaboration BPMN 2.0 pour analyser le système d’information au regard de la performance.

Pourquoi BPMN ? Parce qu’un processus mal décrit entraîne souvent :

• des tâches oubliées ;
• des responsabilités floues ;
• des retards ;
• des doubles saisies ;
• des erreurs de circulation de l’information ;
• une mauvaise coordination entre services ;
• une difficulté à faire évoluer le système d’information.

À l’inverse, une représentation claire permet de :

• visualiser les enchaînements d’activités ;
• comprendre les échanges entre acteurs ;
• repérer les points de blocage ;
• intégrer de nouvelles règles de gestion ;
• améliorer la performance du processus.

Objectifs d’apprentissage

À l’issue de cette leçon, vous devez être capable de :

• comprendre le lien entre système d’information et performance des processus ;
• comprendre et représenter un processus avec un diagramme BPMN 2.0 ;
• utiliser correctement les principaux éléments : piscines, couloirs, activités, évènements, passerelles, flux et artefacts ;
• lire un diagramme de collaboration ;
• améliorer ou enrichir un processus en fonction de nouvelles règles de gestion.

1. Le système d’information au regard de la performance des processus

1.1 Pourquoi représenter les processus ?

Le système d’information soutient le fonctionnement de l’organisation. Il collecte, traite, stocke et diffuse l’information nécessaire aux activités. Mais cette information ne circule pas de manière abstraite : elle circule dans des processus.

Un processus correspond à un enchaînement organisé d’activités visant un résultat. Par exemple :

• traiter une commande client ;
• payer un fournisseur ;
• recruter un salarié ;
• enregistrer une facture ;
• gérer une demande de remboursement.

Analyser le système d’information au regard de la performance consiste à se poser des questions comme :

• L’information arrive-t-elle au bon moment ?
• Le bon acteur réalise-t-il la bonne tâche ?
• Les validations sont-elles correctement placées ?
• Y a-t-il des étapes inutiles ?
• Les échanges entre services sont-ils fluides ?
• Les règles de gestion sont-elles bien intégrées ?

La modélisation BPMN aide précisément à répondre à ces questions.

1.2 BPMN comme outil d’analyse de la performance

BPMN signifie Business Process Model and Notation. En français, on parle de notation de modélisation des processus métier.

Cette notation permet de représenter visuellement :

• les acteurs impliqués ;
• les tâches réalisées ;
• l’ordre d’exécution ;
• les points de décision ;
• les événements qui déclenchent ou terminent le processus ;
• les échanges entre participants.

Elle est particulièrement utile pour :

• décrire un processus existant ;
• repérer les dysfonctionnements ;
• préparer une amélioration ;
• faciliter le dialogue entre gestionnaires, utilisateurs et spécialistes du SI.

Autrement dit, BPMN est un langage commun entre les métiers et le système d’information.

2. Comprendre et représenter un processus

2.1 Rappel : les composants d’un processus

Un processus comprend généralement :

• un déclencheur ;
• des activités ;
• des acteurs ;
• des échanges d’informations ;
• parfois des décisions ;
• un résultat ou une fin.

Exemple simple : traitement d’une commande client.

1. Le client envoie une commande.
2. Le service commercial vérifie la demande.
3. Le stock est contrôlé.
4. Si le produit est disponible, la commande est validée.
5. La préparation est lancée.
6. Le client reçoit une confirmation.

Sans représentation graphique, ce déroulement reste verbal et parfois ambigu. Avec BPMN, on visualise immédiatement :

• qui fait quoi ;
• dans quel ordre ;
• à quel moment une décision intervient ;
• quels messages sont échangés.

2.2 Ce qu’une bonne représentation doit montrer

Un diagramme BPMN correct doit permettre de comprendre rapidement :

• le point de départ du processus ;
• la succession logique des tâches ;
• les participants ;
• les alternatives possibles ;
• le point d’arrivée ;
• les éventuels documents ou informations utiles à la compréhension.

Une représentation utile n’est donc pas seulement « jolie » : elle doit être lisible, fidèle à la réalité, et suffisamment précise pour aider à l’analyse.

3. Le diagramme BPMN de collaboration

3.1 Définition

Le programme vise la représentation d’un processus sous forme d’un diagramme BPMN de collaboration.

Un diagramme de collaboration sert à montrer :

• plusieurs participants ;
• leurs activités respectives ;
• les messages échangés entre eux.

C’est donc la forme la plus pertinente lorsque le processus implique plusieurs acteurs ou plusieurs entités :

• client et entreprise ;
• service commercial et service logistique ;
• entreprise et banque ;
• salarié et service RH.

3.2 Pourquoi parler de collaboration ?

Parce qu’un processus n’est pas toujours exécuté par un seul acteur. Bien souvent, la performance dépend de la qualité de la coordination entre plusieurs intervenants.

Exemple : une facture fournisseur n’est pas seulement traitée par la comptabilité. Elle peut mobiliser :

• le fournisseur ;
• le service achats ;
• le service réception ;
• la comptabilité ;
• la direction pour validation.

Le diagramme de collaboration permet de rendre visibles ces interactions.

4. Les éléments fondamentaux de BPMN 2.0

4.1 Les piscines

La piscine (pool) représente un participant au processus.

Ce participant peut être :

• une organisation ;
• un service ;
• un client ;
• un fournisseur ;
• une banque ;
• une administration.

Dans un diagramme de collaboration, chaque participant important est souvent représenté par une piscine distincte.

Exemple

Dans un processus de commande :

• une piscine Client ;
• une piscine Entreprise.

La piscine sert à délimiter le périmètre d’action d’un participant.

Pourquoi c’est important ?

Parce qu’une mauvaise délimitation des participants crée de la confusion. On ne sait plus :

• qui déclenche l’action ;
• qui prend la décision ;
• qui envoie l’information ;
• qui reçoit le message.

4.2 Les couloirs

Les couloirs (lanes) subdivisent une piscine. Ils permettent de distinguer les rôles ou services à l’intérieur d’un même participant.

Exemple dans la piscine Entreprise :

• couloir Service commercial ;
• couloir Magasin ;
• couloir Comptabilité.

Intérêt des couloirs

Les couloirs permettent de visualiser la répartition des responsabilités. Ils sont très utiles pour repérer :

• les transferts internes ;
• les tâches redondantes ;
• les ruptures de charge ;
• les zones où le processus ralentit.

En pratique, si un document passe par trop de couloirs, cela peut révéler un processus trop lourd.

4.3 Les activités

Les activités représentent les actions réalisées dans le processus.

Dans le cadre de cette leçon, il faut surtout savoir reconnaître et utiliser les tâches.

Exemples d’activités :

• saisir la commande ;
• vérifier le stock ;
• envoyer la confirmation ;
• valider la demande ;
• enregistrer la facture.

Bonnes pratiques de formulation

Une activité doit être formulée avec un verbe d’action clair :

• Contrôler la disponibilité ;
• Émettre la facture ;
• Notifier le client.

Éviter les formulations vagues comme :

• Commande ;
• Facture ;
• Traitement.

Pourquoi ? Parce qu’un diagramme BPMN doit décrire une action, pas seulement un objet.

4.4 Les évènements

Les évènements marquent quelque chose qui arrive dans le processus.

On distingue au minimum :

• l’évènement de début ;
• l’évènement de fin.

Évènement de début

Il indique ce qui déclenche le processus.

Exemples :

• réception d’une commande ;
• arrivée d’une facture ;
• demande d’un client ;
• dépôt d’un dossier.

Évènement de fin

Il indique quand le processus est terminé.

Exemples :

• commande confirmée ;
• paiement effectué ;
• dossier rejeté ;
• facture comptabilisée.

Pourquoi les évènements sont essentiels

Ils cadrent le processus. Sans eux, on ne sait pas exactement :

• quand il commence ;
• quand il s’achève ;
• ce qui relève ou non du périmètre étudié.

4.5 Les flux

Il existe deux grandes logiques de flux à distinguer visuellement dans BPMN.

a) Le flux de séquence

Le flux de séquence indique l’ordre d’exécution des activités à l’intérieur d’un participant.

Exemple :

1. Vérifier la commande
2. Contrôler le stock
3. Préparer l’expédition

Le flux de séquence répond à la question : que se passe-t-il ensuite ?

b) Le flux de message

Le flux de message représente un échange entre participants.

Exemple :

• le client envoie une commande à l’entreprise ;
• l’entreprise envoie une confirmation au client.

Le flux de message répond à la question : quelle information est transmise à un autre participant ?

Pourquoi cette distinction est importante

Confondre flux de séquence et flux de message revient à mélanger :

• l’enchaînement interne des tâches ;
• la communication entre acteurs.

Or cette distinction est centrale pour analyser la performance du système d’information.

4.6 Les passerelles

Les passerelles (gateways) servent à représenter une décision, un choix, une alternative ou parfois une synchronisation.

Dans le cadre de cette leçon, il faut surtout comprendre leur rôle dans les embranchements logiques.

Exemple simple

Après le contrôle du stock :

• si stock disponible → préparer la commande ;
• sinon → informer le client de l’indisponibilité.

La passerelle permet donc de représenter un point où le chemin du processus peut diverger.

Pourquoi les passerelles sont utiles

Sans elles, un diagramme devient trompeur. Il laisse croire que toutes les activités s’enchaînent toujours de la même manière, alors que la réalité comporte des cas différents.

4.7 Les artefacts

Les artefacts complètent la compréhension du diagramme sans modifier directement la logique d’exécution.

Dans le cadre du programme, il faut surtout savoir qu’ils servent à enrichir la lecture.

Ils peuvent par exemple permettre de montrer :

• un document ;
• une information utile ;
• un commentaire ;
• un regroupement visuel.

Pourquoi utiliser des artefacts ?

Parce qu’un processus réel s’appuie souvent sur des supports d’information : bon de commande, facture, mail, justificatif, dossier, etc. Les artefacts aident à faire le lien entre activités et informations manipulées.

5. Méthode pas à pas pour construire un diagramme BPMN

5.1 Étape 1 : délimiter le processus

Avant de dessiner, il faut répondre à quatre questions :

1. Quel est le déclencheur ?
2. Quel est le résultat attendu ?
3. Quels sont les participants ?
4. Quelles sont les grandes étapes ?

Exemple

Processus : traitement d’une commande client.

• Début : réception de la commande.
• Fin : confirmation d’expédition envoyée.
• Participants : client, service commercial, magasin.
• Étapes : réception, contrôle, validation, préparation, notification.

5.2 Étape 2 : identifier les participants et créer les piscines/couloirs

On commence par structurer le diagramme :

• une piscine Client ;
• une piscine Entreprise ;
• dans l’entreprise, des couloirs : Commercial et Magasin.

Cette étape est déterminante car elle organise la lecture.

5.3 Étape 3 : placer l’évènement de début et l’évènement de fin

Exemple :

• début : Commande reçue ;
• fin : Confirmation envoyée.

5.4 Étape 4 : placer les activités dans le bon couloir

Exemple :

Couloir Commercial :

• Enregistrer la commande ;
• Vérifier la disponibilité ;
• Informer le client.

Couloir Magasin :

• Préparer la commande.

5.5 Étape 5 : relier les activités par des flux de séquence

On relie les tâches dans l’ordre logique.

5.6 Étape 6 : ajouter les flux de message entre participants

Exemple :

• le client envoie la commande ;
• l’entreprise envoie la confirmation.

5.7 Étape 7 : insérer les passerelles si nécessaire

Exemple :

• stock disponible ?
  • oui → préparer la commande ;
  • non → informer le client.

5.8 Étape 8 : enrichir avec des artefacts si cela améliore la compréhension

Par exemple :

• document « Bon de commande » ;
• commentaire « contrôle manuel ».

6. Exemple complet : processus de traitement d’une commande

6.1 Description textuelle

Un client transmet une commande. Le service commercial l’enregistre puis vérifie la disponibilité des produits. Si les produits sont disponibles, le magasin prépare l’expédition et le service commercial envoie une confirmation au client. Sinon, le client est informé de l’indisponibilité.

6.2 Traduction en BPMN

Participants :

• Piscine Client
• Piscine Entreprise
  • Couloir Service commercial
  • Couloir Magasin

Évènement de début : commande reçue

Activités :

• Recevoir la commande
• Enregistrer la commande
• Vérifier la disponibilité
• Préparer l’expédition
• Informer le client
• Envoyer la confirmation

Passerelle : stock disponible ?

Évènements de fin :

• confirmation envoyée ;
• indisponibilité notifiée.

6.3 Ce que l’analyse permet de voir

Une fois le diagramme établi, on peut déjà poser des questions de performance :

• le contrôle du stock est-il manuel ou automatisé ?
• qui informe le client ?
• combien de temps s’écoule entre la commande et la décision ?
• y a-t-il un risque de ressaisie ?
• le magasin reçoit-il l’information sans délai ?

On voit ici que la modélisation n’est pas un exercice décoratif : elle sert à analyser.

7. Améliorer et enrichir un processus en fonction de nouvelles règles

L’un des objectifs explicitement visés par le programme est de savoir améliorer, enrichir un processus en fonction de nouvelles règles.

C’est un point fondamental : un processus n’est jamais totalement figé. Il évolue avec :

• les exigences de contrôle ;
• la réglementation ;
• les attentes des clients ;
• l’organisation interne ;
• les outils numériques.

7.1 Qu’est-ce qu’une nouvelle règle ?

Une nouvelle règle peut être :

• une validation supplémentaire ;
• un seuil de contrôle ;
• une notification obligatoire ;
• une séparation des tâches ;
• une condition nouvelle de traitement.

Exemples

• Toute commande supérieure à 10 000 € doit être validée par un responsable.
• Toute rupture de stock doit donner lieu à une alerte automatique.
• Toute facture sans bon de réception doit être mise en attente.

7.2 Méthode d’amélioration d’un diagramme BPMN

Pour enrichir un processus, il faut procéder avec méthode.

Étape 1 : repérer la règle nouvelle

Exemple : « au-delà de 10 000 €, une validation hiérarchique est obligatoire ».

Étape 2 : identifier l’impact sur le déroulement

Cette règle crée :

• une condition ;
• une activité supplémentaire de validation ;
• éventuellement un nouvel acteur.

Étape 3 : modifier le diagramme

On ajoute :

• une passerelle : montant > 10 000 € ?
• si oui : activité Valider la commande dans le couloir du responsable ;
• si non : suite normale.

Étape 4 : vérifier la cohérence globale

Il faut s’assurer que :

• tous les chemins aboutissent à une fin ;
• les responsabilités sont claires ;
• les flux sont correctement orientés ;
• le diagramme reste lisible.

7.3 Exemple d’enrichissement

Processus initial

1. Enregistrer la commande
2. Vérifier le stock
3. Préparer l’expédition
4. Envoyer confirmation

Nouvelle règle

Toute commande supérieure à 10 000 € doit être validée par le responsable commercial.

Processus enrichi

1. Enregistrer la commande
2. Passerelle : montant > 10 000 € ?
   • non → vérifier le stock
   • oui → validation par le responsable commercial puis vérifier le stock
3. Passerelle : stock disponible ?
   • oui → préparer l’expédition
   • non → informer le client
4. Envoyer confirmation si préparation possible

Apport de cette modification

Le diagramme devient plus fidèle à la réalité. Il permet aussi de vérifier si cette nouvelle règle :

• ralentit le processus ;
• améliore la sécurité ;
• nécessite un nouveau rôle ;
• impose une adaptation du système d’information.

8. Comment analyser un diagramme BPMN du point de vue de la performance

Une fois le diagramme construit, il faut savoir l’exploiter.

8.1 Repérer les points de rupture

Un point de rupture est un endroit où le processus peut ralentir, échouer ou devenir coûteux.

Exemples :

• trop de validations successives ;
• allers-retours entre plusieurs couloirs ;
• dépendance à une action manuelle ;
• absence d’information automatique.

8.2 Repérer les redondances

Si deux activités réalisent en pratique le même contrôle, le diagramme permet de le voir.

Exemple :

• le service commercial vérifie une information ;
• la comptabilité refait exactement le même contrôle plus loin.

Cela peut signaler une perte d’efficacité.

8.3 Repérer les responsabilités mal définies

Un diagramme bien construit montre clairement qui agit.

Si une tâche semble placée dans le mauvais couloir, ou si un acteur manque, cela révèle un problème d’organisation.

8.4 Repérer les décisions critiques

Les passerelles mettent en évidence les points où une décision change le chemin du processus. Ces points sont souvent sensibles :

• risque d’erreur ;
• besoin de justification ;
• nécessité d’une règle claire.

8.5 Repérer les échanges d’information essentiels

Les flux de message montrent où l’information circule entre participants. Si un message est tardif, incomplet ou inutile, la performance se dégrade.

9. Erreurs fréquentes en modélisation BPMN

9.1 Confondre acteur et activité

Erreur : écrire Comptabilité dans une tâche.

Correction :

• Comptabilité doit être un couloir ou un participant ;
• la tâche doit être un verbe d’action : Enregistrer la facture.

9.2 Oublier l’évènement de début ou de fin

Un processus sans début ni fin clairement identifiés devient flou.

9.3 Mélanger flux de séquence et flux de message

Un flux de séquence ne sert pas à relier deux participants différents comme s’il s’agissait d’une simple succession interne.

9.4 Multiplier inutilement les détails

Le but est de comprendre le processus, pas de noyer le lecteur dans des micro-actions sans intérêt.

9.5 Oublier les règles de gestion

Un diagramme peut être graphiquement correct mais faux sur le fond s’il ne tient pas compte d’une condition importante.

10. Cas pratique guidé

10.1 Situation

Une entreprise traite les demandes d’achat internes ainsi :

1. Un salarié formule une demande.
2. Le responsable hiérarchique valide ou refuse.
3. Si la demande est validée, le service achats consulte un fournisseur.
4. Le fournisseur envoie une offre.
5. Le service achats passe commande.
6. Le processus se termine.

Nouvelle règle : si le montant dépasse 5 000 €, la direction doit valider avant la commande.

10.2 Analyse préalable

Participants :

• Salarié
• Responsable hiérarchique
• Service achats
• Fournisseur
• Direction

Début : demande d’achat émise

Fin : commande passée ou demande refusée

10.3 Construction du diagramme

Étape 1 : piscines et couloirs

On peut représenter :

• une piscine Entreprise avec couloirs : Salarié, Responsable hiérarchique, Service achats, Direction ;
• une piscine Fournisseur.

Étape 2 : activités

• Émettre la demande
• Valider la demande
• Refuser la demande
• Consulter le fournisseur
• Envoyer l’offre
• Vérifier le montant
• Valider par la direction
• Passer la commande

Étape 3 : passerelles

• demande validée ?
• montant > 5 000 € ?

Étape 4 : flux de message

• consultation envoyée au fournisseur ;
• offre reçue du fournisseur.

10.4 Ce que le diagramme met en évidence

• le fournisseur n’appartient pas à l’entreprise : il doit être dans une autre piscine ;
• la direction n’intervient que dans certains cas : une passerelle est nécessaire ;
• le refus de la demande constitue une fin alternative du processus.

10.5 Apport de la nouvelle règle

La nouvelle règle enrichit le processus en ajoutant :

• un acteur ;
• une décision supplémentaire ;
• un contrôle renforcé.

Mais elle peut aussi :

• allonger le délai ;
• créer un goulet d’étranglement ;
• nécessiter une notification automatique.

C’est exactement ce que l’analyse BPMN permet de discuter.

11. Conseils pratiques pour réussir une modélisation BPMN

11.1 Commencer par le texte

Avant de dessiner, reformulez le processus en phrases simples.

11.2 Identifier les verbes d’action

Chaque tâche doit correspondre à une action réelle.

11.3 Séparer clairement les participants

Si deux acteurs échangent des messages, il faut les distinguer visuellement.

11.4 Faire apparaître les décisions importantes

Toute condition qui modifie le chemin du processus mérite une passerelle.

11.5 Vérifier la cohérence de bout en bout

Chaque chemin doit être lisible depuis le début jusqu’à une fin.

11.6 Garder un niveau de détail pertinent

Le diagramme doit être assez précis pour être utile, mais pas au point de devenir illisible.

12. Ce qu’il faut retenir sur BPMN dans le cadre du DCG

Dans le cadre du programme, l’enjeu principal n’est pas la maîtrise exhaustive de toute la norme BPMN 2.0, mais la capacité à :

• comprendre et représenter les processus de l’organisation ;
• lire et produire un diagramme de collaboration ;
• utiliser correctement les notions de piscines, couloirs, activités, flux, évènements, passerelles et artefacts ;
• analyser le processus du point de vue de la performance ;
• intégrer une nouvelle règle de gestion dans le diagramme.

Autrement dit, BPMN est ici un outil de représentation, d’analyse et d’amélioration des processus.

Résumé

• Le système d’information soutient les processus de l’organisation.
• Pour analyser la performance, il faut représenter les processus de manière claire.
• BPMN 2.0 est une notation adaptée à cette représentation.
• Le diagramme de collaboration montre les participants et leurs échanges.
• Les principaux éléments à maîtriser sont :
  • piscines ;
  • couloirs ;
  • activités ;
  • évènements ;
  • flux de séquence ;
  • flux de message ;
  • passerelles ;
  • artefacts.
• Un diagramme BPMN sert non seulement à décrire l’existant, mais aussi à améliorer le processus lorsque de nouvelles règles apparaissent.

Mémo final

Démarche rapide de modélisation

1. Définir le début et la fin du processus.
2. Identifier les participants.
3. Créer les piscines et couloirs.
4. Lister les activités avec des verbes d’action.
5. Relier avec des flux de séquence.
6. Ajouter les flux de message entre participants.
7. Insérer les passerelles pour les décisions.
8. Ajouter des artefacts si nécessaire.
9. Vérifier la cohérence globale.
10. Adapter le diagramme en cas de nouvelle règle.

Question-clé d’analyse

Le diagramme permet-il de comprendre clairement qui fait quoi, dans quel ordre, selon quelles conditions, et avec quels échanges d’information ?

Si la réponse est oui, la modélisation est utile pour analyser la performance du processus.