BPMN (Business Process Model and Notation) est le langage standard pour dessiner les processus métier : un ensemble de symboles que le métier et l'informatique lisent de la même manière et qui, dans sa version 2.0, peut être exécuté par un moteur. Savoir lire et écrire un diagramme BPMN est la compétence centrale de toute personne qui travaille avec des processus — et maîtriser les passerelles (gateways) est ce qui sépare un beau dessin d'un processus qui fonctionne.
Ce guide parcourt les symboles BPMN regroupés par familles, avec un SVG de chacun, explique les quatre passerelles et l'erreur classique qui provoque un blocage, et se termine par un diagramme BPMN complet d'approbation de factures. C'est le complément pratique de notre guide Qu'est-ce que le BPM ?.
BPMN est l'acronyme de Business Process Model and Notation : modèle et notation des processus métier. C'est la norme internationale pour représenter graphiquement le fonctionnement d'un processus, maintenue par l'Object Management Group (OMG) et reprise comme norme ISO/IEC 19510. Son objectif est qu'un même diagramme soit compris par trois publics qui parlent normalement des langages différents : l'analyste métier qui connaît le processus, le responsable qui l'approuve et l'équipe technique qui l'implémente.
La grande différence entre le BPMN et un simple diagramme de flux est la sémantique précise. Dans un diagramme de flux, un losange signifie « une décision » et chaque auteur le dessine à sa manière. En BPMN, un losange avec un X à l'intérieur est une passerelle exclusive au comportement défini au millimètre, distinct du losange avec un signe + (parallèle). Cette précision est ce qui permet au diagramme BPMN 2.0 d'être exécutable : un moteur de processus l'interprète directement et le transforme en une application réelle, sans que personne n'ait à le « traduire » en code et à perdre des nuances en chemin.
Il convient de situer le BPMN dans la discipline plus large qu'il sert. Le BPMN est la notation utilisée dans la phase de modélisation du cycle de vie BPM ; si vous voulez le panorama complet — ce qu'est la gestion par processus, en quoi elle diffère d'un workflow ou du RPA et comment elle se déploie — commencez par le guide pilier Qu'est-ce que le BPM ?.
En une phrase : le BPMN est aux processus ce que la portée est à la musique. Un langage commun que tout le monde peut lire et qu'une machine peut exécuter. Ce guide vous apprend à le lire et à bien l'écrire.
BPMN 2.0 définit des dizaines de symboles, mais vous n'avez pas besoin de les mémoriser tous. Quatre familles couvrent l'immense majorité des diagrammes métier : les événements, les activités, les passerelles et les flux de séquence. Autour d'eux, deux éléments d'organisation — les couloirs (responsabilité) et les artefacts (annotations et objets de données) — complètent le tableau.
Cercles. Quelque chose qui survient : démarre, interrompt ou termine le processus.
Rectangles arrondis. Le travail : tâches et sous-processus.
Losanges. Décisions : le flux se ramifie ou se synchronise.
Flèches. L'ordre : ils relient les éléments en séquence.
Un pool représente un participant (une organisation ou un système) ; à l'intérieur, les couloirs (lanes) divisent le travail par rôle ou par service. Ils placent chaque activité sous un responsable clair. Nous le détaillons à la section 6.
Ils n'altèrent pas le flux, ils le documentent : objets de données (un document qui entre ou sort d'une tâche), annotations de texte (notes pour le lecteur) et groupes (cadres qui regroupent visuellement). Utiles pour que le diagramme se lise tout seul.
Un événement est quelque chose qui survient pendant le processus. Il se dessine toujours comme un cercle, et l'épaisseur du trait indique sa position dans le flux : l'événement de début a un trait fin, l'intermédiaire est un double cercle et celui de fin a un trait épais. Cette règle, à elle seule, vous permet déjà de lire d'un coup d'œil par où entre et sort un processus.
De plus, une icône à l'intérieur du cercle indique le type d'événement : une enveloppe est un événement message (quelque chose arrive ou est envoyé), une horloge est une minuterie (un délai expire), un éclair est une erreur et un triangle est un signal (un avis que plusieurs processus peuvent écouter en même temps).
Le processus démarre lorsque quelque chose arrive de l'extérieur : un e-mail, un formulaire web envoyé, une facture reçue. C'est le déclencheur le plus courant dans les processus métier.
Il fait attendre le flux (« attendre 3 jours ») ou, accolé au bord d'une tâche, l'interrompt si le délai expire. C'est la base des escalades automatiques par SLA.
Il capture une défaillance d'une tâche ou d'un sous-processus et dévie le flux par une branche de traitement des erreurs, sans interrompre l'exécution.
Il clôt un chemin du processus. Un diagramme peut avoir plusieurs événements de fin (approuvé, rejeté, annulé) : ce n'est pas une erreur, c'est une bonne pratique pour distinguer les issues.
Une activité est le travail réalisé, et elle se dessine comme un rectangle aux coins arrondis. Ce qui distingue un type de tâche d'un autre est une petite icône dans le coin supérieur gauche : une personne pour la tâche utilisateur, des engrenages pour la tâche de service, une main pour la tâche manuelle, un parchemin pour la tâche de script et un tableau pour la tâche de règle métier (business rule).
Lorsqu'une activité enferme à son tour un autre processus, c'est un sous-processus (avec un signe + sur le bord inférieur, indiquant qu'il peut être déplié) ou une call activity (bord épais) qui invoque un processus réutilisable défini à part. Et les marqueurs à la base de la tâche indiquent une répétition : une boucle (↻) ou trois barres de multi-instance (la même tâche pour plusieurs éléments à la fois, p. ex. « demander un devis à 3 fournisseurs »).
Un détail qui compte pour l'exécution : le type de tâche n'est pas décoratif. Dans un moteur BPMN, une tâche utilisateur crée une entrée dans la boîte de réception d'une personne ; une tâche de service déclenche un appel à un système ou une API ; une tâche de règle évalue une table de décision. C'est pourquoi bien modéliser le type de chaque tâche est ce qui rend le diagramme directement exécutable. Une tâche de service peut être résolue par du code, par un robot RPA ou par un agent IA gouverné — le diagramme ne change pas.
Les passerelles sont le cœur de la logique d'un processus et la partie qui suscite le plus de doutes. Elles se dessinent toujours comme un losange, et un symbole intérieur définit leur comportement. Il y en a quatre que vous devez maîtriser. La règle mentale : une passerelle divergente ouvre des chemins et la convergente les réunit ; utiliser le mauvais type au moment de les réunir est la cause numéro un des processus qui se bloquent.
Le flux prend un seul chemin, le premier dont la condition est vraie. C'est le « if/else » du processus. Exemple : « le montant dépasse-t-il 5 000 € ? » → Oui, il part en approbation du directeur ; Non, il est comptabilisé directement. Une seule des deux branches s'exécute.
Elle active tous les chemins simultanément, sans conditions. Exemple : lors de l'embauche, en parallèle on prépare le matériel informatique, on inscrit la personne à la paie et on demande la carte d'accès. La convergence parallèle attend que toutes se terminent avant de poursuivre.
Elle active tous les chemins dont la condition est vraie, de un à tous. Exemple : une réclamation peut nécessiter, selon le cas, une revue juridique, une revue technique ou les deux. La convergence inclusive n'attend que les branches qui se sont réellement activées.
Le chemin n'est pas décidé par une condition de données, mais par quel événement survient en premier. Exemple : après l'envoi d'un devis, le processus attend : si l'acceptation du client arrive, il part en facturation ; si le délai de 15 jours expire (minuterie), il part en suivi commercial.
L'erreur la plus fréquente en modélisation BPMN : ouvrir le flux avec une passerelle exclusive (où une seule branche s'active) puis tenter de le refermer avec une passerelle parallèle de convergence. La parallèle attend l'arrivée de toutes les branches — mais comme l'exclusive n'en a activé qu'une, les autres n'arrivent jamais. Le processus attend pour toujours : c'est un deadlock (blocage).
La règle pour l'éviter : fermez avec le même type que celui avec lequel vous avez ouvert. Ce qui a divergé en exclusive se réunit en exclusive ; le parallèle, en parallèle ; l'inclusif, en inclusif. Faire correspondre l'ouverture et la fermeture élimine l'immense majorité des blocages.
Un diagramme BPMN ne montre pas seulement ce qui se passe, mais qui le fait. C'est le rôle des couloirs (swimlanes). Imaginez une piscine vue de dessus : le grand rectangle est le pool (le participant complet, p. ex. « Notre entreprise ») et les bandes horizontales à l'intérieur sont les couloirs, un par rôle ou service : Finances, RH, le système. Chaque tâche se dessine dans le couloir du responsable qui l'exécute — ainsi, en lisant verticalement, vous savez à qui appartient chaque étape.
La distinction clé est quand utiliser un couloir et quand un pool séparé :
Lorsque tous les participants appartiennent à la même organisation et partagent le processus. Les tâches se relient par des flux de séquence (flèches pleines) qui passent d'un couloir à l'autre. Exemple : les Finances et le système ERP dans le processus de factures.
Lorsqu'une autre organisation intervient (un client, un fournisseur, une administration) dont le processus interne échappe à votre contrôle et à votre vue. Les pools ne se relient pas par des flux de séquence, mais par des flux de message (flèches en pointillés) : ils n'échangent que des communications.
Cette règle évite une erreur courante : placer le client comme un couloir de plus dans votre pool. Vous n'orchestrez pas les tâches internes du client — vous lui envoyez et recevez seulement des messages. Le modéliser comme un pool séparé clarifie la limite de responsabilité et rend le diagramme honnête sur ce que vous contrôlez réellement.
Réunissons le tout dans un diagramme réel. Nous modélisons l'approbation d'une facture avec un pool à deux couloirs — Finances (les personnes) et Système (les étapes automatiques) — un événement de début de type message, une tâche de service d'OCR, une passerelle exclusive qui décide selon le montant, une tâche utilisateur d'approbation, l'enregistrement dans l'ERP et un événement de fin.
Lisez-le en suivant les flèches : la facture arrive et démarre le processus dans le couloir Système ; la tâche de service OCR extrait le montant, le fournisseur et l'échéance ; la passerelle exclusive regarde le montant. Celles de moins de 5 000 € n'ont besoin de personne et vont directement à l'ERP ; celles qui le dépassent remontent au couloir Finances, où une personne approuve avant que le système ne les enregistre. Un unique événement de fin marque « comptabilisée ».
Remarquez ce que le diagramme rend explicite sans une seule ligne de prose : quelles étapes sont automatiques et lesquelles sont humaines (les couloirs), où se trouve la décision et selon quel critère (la passerelle et son libellé), et quand une personne intervient (seulement au-dessus du seuil). C'est toute la puissance du BPMN : il documente, communique et — en BPMN 2.0 — s'exécute, le tout avec le même dessin. C'est précisément le type de processus que vous trouverez prêt à activer dans le catalogue de modèles BPM.
Voici la différence qui a changé le marché. Dans le monde des diagrammes de flux d'autrefois, le dessin était de la documentation : quelqu'un l'approuvait, puis une équipe le « traduisait » en code. Dans cette traduction, on perdait des nuances, on introduisait des écarts et, six mois plus tard, le diagramme et la réalité ne coïncidaient plus.
Avec BPMN 2.0 sur un moteur de processus, il n'y a pas de traduction : le diagramme est le programme. Le moteur lit le XML du modèle (BPMN 2.0 définit un format d'échange standard) et l'exécute tel quel. Lorsque le flux atteint une tâche utilisateur, le moteur crée l'entrée dans la boîte de réception de la personne ; sur une tâche de service, il appelle le système ; sur une passerelle, il évalue la condition et choisit la branche. Ce que le métier a validé est, littéralement, ce qui tourne en production.
Sur une plateforme BPM low-code, cela va encore plus loin : au-delà du diagramme, vous concevez les formulaires, les règles et les intégrations de façon visuelle, sans programmer. Les phases de modélisation et d'exécution du cycle de vie BPM fusionnent en une seule. C'est pourquoi le premier processus en production se mesure en semaines, et non en mois.
Si vous voulez voir comment se construit un processus BPMN exécutable de bout en bout, découvrez la plateforme BPM low-code de Dokuflex ; et pour le contexte complet de la discipline, le guide Qu'est-ce que le BPM ?.
Un diagramme BPMN techniquement correct peut tout de même rester illisible. Ces conventions, simples, font la différence entre un modèle qui se comprend tout seul et un modèle qui nécessite une explication :
« Approuver la facture », « Enregistrer dans l'ERP », « Notifier le client ». Pas « Facture » ni « Gestion » : une tâche est une action. Les événements, en revanche, se nomment comme un substantif ou un état (« Facture reçue », « Contrat signé »).
Dessinez le flux principal sur une ligne droite horizontale et laissez les exceptions et les rejets sortir vers le haut ou vers le bas. Le lecteur doit pouvoir suivre le cas normal sans effort et voir les déviations comme des branches.
Les flèches qui se croisent sont le signal visuel d'un diagramme désordonné. Réorganisez la position des tâches jusqu'à ce que les flux ne se chevauchent plus ; c'est presque toujours possible.
Si un processus grandit trop, il devient illisible. Encapsulez des blocs dans des sous-processus dépliables : le diagramme de premier niveau raconte l'histoire, et chaque sous-processus apporte le détail à qui en a besoin.
Ce qu'ouvre une exclusive, une exclusive le referme ; le parallèle, une parallèle. C'est la règle qui évite les deadlocks de la section 5. Et étiquetez toujours les branches d'une exclusive (Oui/Non, <5 000/>5 000).
Un processus évolue. Conservez des versions du modèle et, dans le moteur, faites cohabiter l'ancienne version pour les dossiers en cours et la nouvelle pour ceux qui démarrent. Modifier le diagramme ne devrait pas casser ce qui est déjà en route.
Et une erreur de fond au-delà de la notation : ne modélisez pas le processus que vous aimeriez avoir, modélisez celui que vous avez — y compris ses exceptions réelles — puis améliorez-le. Un diagramme idéalisé qui ignore les cas difficiles se casse dès le premier jour en production.
BPMN est l'acronyme de Business Process Model and Notation (modèle et notation des processus métier). C'est la norme internationale, maintenue par l'Object Management Group (OMG) et reprise dans la norme ISO/IEC 19510, qui définit un langage graphique pour dessiner les processus de façon que toute personne les comprenne et, en BPMN 2.0, qu'un moteur puisse les exécuter.
Non. Un diagramme de flux classique est informel : chaque auteur utilise les symboles à sa manière et il n'est pas exécutable. BPMN 2.0 est une norme à la sémantique précise : chaque symbole a une signification définie (événements de type message ou minuterie, passerelles exclusives ou parallèles, couloirs par responsable) et un moteur BPM peut interpréter le diagramme et le mettre en production sans le réinterpréter.
La passerelle inclusive (losange avec un cercle à l'intérieur, symbole O). Elle active tous les chemins dont la condition est vraie, de un à tous à la fois. Si une seule condition peut être vraie, utilisez l'exclusive (X) ; si vous voulez toujours lancer tous les chemins en parallèle, sans condition, utilisez la parallèle (+). Pensez à refermer la divergence inclusive par une autre passerelle inclusive de convergence afin de synchroniser correctement.
Pour dessiner, n'importe quel éditeur prenant en charge la norme suffit (y compris des éditeurs gratuits basés sur bpmn.io). Mais la valeur du BPMN 2.0 est que le diagramme est exécutable : sur une plateforme BPM low-code, le même diagramme que vous validez avec le métier devient l'application réelle, avec formulaires, règles et intégrations, sans avoir à le redessiner dans un autre outil.
Oui. Une tâche d'un processus BPMN peut être exécutée par une personne, un service, un robot RPA ou un agent IA. Modéliser l'étape d'IA comme une tâche de service au sein du diagramme préserve la traçabilité : la passerelle suivante décide selon le résultat ou le niveau de confiance, et le flux est escaladé vers une tâche utilisateur lorsque l'IA n'atteint pas le seuil (human-in-the-loop).
Même si BPMN 2.0 définit des dizaines de symboles, quatre groupes couvrent 90 % des diagrammes réels : les événements (début, intermédiaire, fin), les activités (tâches et sous-processus), les passerelles (exclusive, parallèle, inclusive et basée sur événements) et les flux de séquence, organisés en couloirs. Avec ce sous-ensemble, on modélise la quasi-totalité des processus métier.
Apportez le processus que vous avez dessiné — factures, congés, onboarding — et nous vous montrons le même diagramme BPMN s'exécutant dans Dokuflex lors d'une démo de 30 minutes. Sans engagement et avec votre cas, pas avec un cas de laboratoire.