BPMN 2.0 : modéliser un processus que tout le monde comprend
BPMN compte plus d'une centaine d'éléments. Une douzaine suffit pour décrire la plupart des processus d'une administration ou d'une entreprise, à condition de respecter quelques règles de lisibilité.
La notation BPMN (Business Process Model and Notation), dont la version 2.0 est publiée par l’OMG depuis 2011 et normalisée sous la référence ISO/IEC 19510, est devenue la langue commune des processus. Elle a pourtant mauvaise réputation : schémas tentaculaires, symboles obscurs, documents que personne ne relit. Le problème n’est pas la notation, mais l’usage qu’on en fait. Voici comment produire des schémas qu’un chef de service, un agent et un développeur lisent de la même façon.
Les douze symboles qui suffisent
La norme définit de nombreux éléments. Pour décrire un processus métier, un petit noyau couvre la grande majorité des cas.
| Élément | Forme | Usage |
|---|---|---|
| Événement de début | Cercle fin | Ce qui déclenche le processus (une demande reçue) |
| Événement de fin | Cercle épais | Un résultat atteint (demande accordée, demande rejetée) |
| Événement intermédiaire de minuterie | Double cercle avec horloge | Un délai ou une échéance |
| Événement intermédiaire de message | Double cercle avec enveloppe | Attente ou envoi d’une information externe |
| Tâche | Rectangle arrondi | Une action faite par un acteur, nommée par un verbe |
| Sous-processus | Rectangle avec « + » | Un ensemble de tâches détaillé ailleurs |
| Passerelle exclusive | Losange avec « X » | Un seul chemin selon une condition |
| Passerelle parallèle | Losange avec « + » | Plusieurs chemins menés en même temps |
| Flux de séquence | Flèche pleine | L’ordre des étapes |
| Flux de message | Flèche pointillée | Un échange entre deux participants |
| Bassin et couloirs | Grand cadre découpé | Une organisation et ses acteurs |
| Objet de données | Feuille cornée | Un document produit ou utilisé |
Le reste (passerelles inclusives ou complexes, compensation, événements conditionnels) a son utilité, mais réservez-le aux schémas exécutables, lus par des spécialistes.
Six règles de lisibilité
- Un couloir par acteur : un rôle (« agent d’accueil »), pas une personne nommée.
- Un verbe à l’infinitif par tâche : « Vérifier les pièces », pas « Vérification » ni « Pièces ».
- Un chemin principal de gauche à droite : le cas nominal se lit d’un trait ; les exceptions partent vers le haut ou le bas.
- Des passerelles nommées : une question sur la passerelle (« Dossier complet ? »), une réponse sur chaque sortie.
- Des fins explicites : chaque issue a son événement de fin, nommé par son résultat.
- Une page au plus : au-delà, découper en sous-processus.
La méthode en atelier
- Fixer les bornes. Quel événement déclenche le processus, quels résultats le terminent. Sans bornes, l’atelier dérive vers tout le service.
- Lister les acteurs. Ils deviennent les couloirs. Les acteurs externes (usager, fournisseur) ont leur propre bassin.
- Dérouler le cas nominal. Le plus fréquent, sans exception. Des étiquettes adhésives sur un mur fonctionnent mieux qu’un logiciel à ce stade.
- Ajouter les exceptions principales. Pièce manquante, refus, délai dépassé. On s’arrête à celles qui représentent un volume réel.
- Raconter le schéma. Une personne qui fait le travail lit le schéma à voix haute. Chaque hésitation signale une erreur ou une ambiguïté.
- Saisir dans un outil conforme. Le schéma validé est saisi dans un modeleur qui exporte au format BPMN XML, pour être réutilisé.
Un schéma de processus est validé quand la personne qui fait le travail peut le raconter sans aide.
Deux niveaux de schéma, deux publics
Une confusion fréquente consiste à vouloir un seul schéma pour tout le monde. Il en faut souvent deux.
- Sert à comprendre, discuter, améliorer
- Noyau de symboles, langage métier
- Lu par la direction, les agents, les auditeurs
- Pilote un moteur de processus
- Données, formulaires, règles, appels de services
- Maintenu par les équipes techniques, dérivé du descriptif
Le schéma exécutable reste fidèle au descriptif dans sa structure ; il ajoute les détails techniques. Quand le processus change, on modifie d’abord le descriptif, avec les métiers, puis on répercute.
Les erreurs qui rendent un schéma inutile
Trois erreurs reviennent souvent. La première : modéliser le processus idéal au lieu du processus réel, ce qui empêche de mesurer l’écart. La deuxième : multiplier les passerelles sans condition explicite, si bien que personne ne sait quel chemin prendre. La troisième : oublier les délais, alors que les échéances (relance à quinze jours, clôture à deux mois) structurent la plupart des processus administratifs.
BPMN devient lisible quand on s’en tient à un noyau de symboles, à des règles d’écriture simples et à une validation par les personnes qui font le travail. Le schéma exécutable vient ensuite, comme une traduction fidèle.
Les processus modélisés en BPMN alimentent directement les circuits de GedFlow. Pour choisir entre modélisation, automatisation légère ou moteur de processus, voir le dossier automatisation des processus.
Pour approfondir : GedFlow · Automatisation des processus
Questions fréquentes
BPMN est-il réservé aux informaticiens ?
Non. La notation a été conçue pour être lue par les métiers. Seule la version exécutable, qui alimente un moteur de processus, exige des compétences techniques.
Quel outil utiliser pour dessiner en BPMN ?
Tout outil qui respecte la norme et exporte au format BPMN XML convient. L'important est de pouvoir réutiliser le schéma, pas d'en faire une image figée.
Quelle différence entre BPMN et un logigramme ?
BPMN a une sémantique normalisée : chaque symbole a un sens précis, ce qui permet de partager et d'exécuter le modèle. Un logigramme libre se prête à plusieurs lectures.
Jusqu'à quel niveau de détail descendre ?
Jusqu'au niveau où chaque tâche est réalisée par un acteur en une fois. Au-delà, on décrit une procédure, qui relève d'un mode opératoire.