BPMN expliqué : ce que c’est et pourquoi les organigrammes ne suffisent pas

La plupart des équipes se heurtent un jour à un mur : le processus qu'elles exécutent et celui qu'elles pensent exécuter s'avèrent être deux choses différentes. Quelqu'un dessine un organigramme lors d'une réunion, quelqu'un d'autre construit quelque chose de légèrement différent dans le système réel, et trois mois plus tard, les deux ont tellement divergé que corriger un bug nécessite une discussion sur ce que le processus était censé faire au départ.

BPMN a été conçu pour combler cet écart. Non pas en ajoutant davantage de documentation, mais en offrant aux équipes métier et techniques un langage graphique commun dans lequel une passerelle signifie la même chose, que vous soyez l'analyste qui l'a dessinée ou le développeur qui l'implémente. C'est ce qui fait de BPMN bien plus qu'un organigramme sophistiqué. La norme est formalisée sous ISO/IEC 19510 et reconnue par l'Object Management Group comme la norme mondiale de notation des processus, ce qui signifie que le langage est indépendant des fournisseurs et stable, sans dépendre de l'outil que votre équipe utilise cette année.

L'idée centrale est la suivante : la véritable valeur de BPMN ne réside pas dans son jeu de symboles. Elle se trouve dans ce que ce jeu de symboles rend possible : un langage partagé suffisamment précis pour être implémenté directement par des développeurs, et suffisamment lisible pour être compris par les parties prenantes métier sans interprète. C'est ce qu'il faut comprendre avant de décider si BPMN a sa place dans votre boîte à outils de gestion des processus.

Là où les processus se dégradent habituellement

• BPMN est une norme ISO, pas un outil logiciel : elle est conçue pour être indépendante des fournisseurs.
• Elle résout le problème de traduction entre la logique métier et l'exécution technique.
• Si votre équipe a dépassé les organigrammes de base sans savoir quelle est la prochaine étape, BPMN est probablement la réponse.

Ce que signifie réellement Business Process Model and Notation

Business Process Model and Notation est une norme internationale ouverte permettant de représenter graphiquement des processus métier. Elle a été développée par l'Object Management Group (OMG) et publiée sous la référence ISO/IEC 19510, ce qui signifie qu'elle est maintenue par un organisme de normalisation, et non par un fournisseur de logiciels. Cette distinction compte davantage qu'il n'y paraît.

Lorsqu'une personne dit qu'elle utilise BPMN, cela signifie qu'elle dessine des diagrammes de processus selon un ensemble de règles précises et cohérentes. Cela ne veut pas dire « nous avons utilisé Lucidchart » ou « nous utilisons des boîtes de style Visio ». La notation permettant de spécifier les processus métier reste la même, quel que soit l'outil qui l'affiche. Tout outil conforme peut lire le même diagramme.

L'OMG a conçu BPMN spécifiquement pour réduire l'écart entre la conception des processus métier et leur implémentation technique. L'objectif de BPMN n'a jamais été de produire une belle documentation : il s'agissait de fournir aux analystes de processus, aux architectes et aux développeurs un diagramme que tous puissent interpréter sans débattre de la signification d'une flèche. Un losange pour une passerelle de décision, un cercle pour un événement, un rectangle pour une tâche. Ce ne sont pas des choix esthétiques. C'est le vocabulaire partagé qui permet au langage de fonctionner.

Un point mérite d'être clarifié : BPMN est une norme de notation, et non une catégorie de logiciel. Vous pouvez l'implémenter dans un outil de dessin de tableur, une suite BPM dédiée ou sur un tableau blanc. La norme ne s'en préoccupe pas. Ce qui fait d'un diagramme un diagramme BPMN conforme, c'est le respect du système de symboles, et non la plateforme utilisée pour le dessiner.

Cette conception indépendante des fournisseurs explique précisément pourquoi les organisations qui travaillent entre équipes, outils et fuseaux horaires y reviennent constamment.

Les quatre catégories de symboles utilisées par chaque diagramme BPMN

Un diagramme BPMN repose sur quatre catégories d'éléments. Comprendre ce que chacune représente, ainsi que les problèmes qui surviennent lorsque les équipes en ignorent une ou l'utilisent mal, est plus important que mémoriser chaque symbole disponible.

• Objets de flux.

Ce sont les principaux éléments visuels : les événements (des cercles indiquant où un processus commence, se termine ou est interrompu), les activités (des rectangles aux coins arrondis représentant des tâches ou sous-processus) et les passerelles (des losanges qui contrôlent les ramifications, les fusions ou les divisions du flux). Les objets de flux portent la logique du processus. Lorsque les équipes les laissent ambigus, en utilisant des boîtes génériques sans préciser s'il s'agit d'une tâche ou d'un appel de sous-processus, le diagramme paraît complet, mais l'implémentation échoue au premier cas limite.

• Objets de connexion.

Ce sont les lignes qui relient les objets de flux. Le flux de séquence (lignes continues avec flèches) indique l'ordre des activités au sein d'un même participant. Le flux de messages (lignes pointillées) indique la communication entre des participants distincts. Les associations relient les artefacts aux objets de flux. Les utiliser incorrectement est subtil, mais lourd de conséquences : employer un flux de séquence là où un flux de messages est nécessaire implique qu'un seul participant contrôle les deux côtés d'une interaction. Cela produit des diagrammes incorrects pour les workflows impliquant plusieurs parties et perturbe les personnes qui les lisent ultérieurement.

• Couloirs.

Un couloir permet à BPMN d'attribuer des responsabilités. Un pool représente un participant : une personne, une équipe, un système ou une organisation. Les couloirs subdivisent un pool en rôles ou départements. Lorsque les équipes dessinent des diagrammes de processus sans couloirs, la responsabilité de chaque étape se perd et les transferts entre rôles deviennent invisibles. Le diagramme décrit ce qui se passe, mais pas qui est responsable de chaque partie. En production, c'est là que le travail passe entre les mailles du filet.

• Artefacts.

Ce sont des éléments complémentaires — objets de données, magasins de données, groupes et annotations textuelles — qui apportent du contexte sans modifier le flux de séquence. Les artefacts constituent la partie la plus fréquemment ignorée d'un diagramme BPMN, et leur absence signifie généralement que le diagramme ne montre pas quelles données un processus consomme ou produit. Pour la conformité, l'audit ou le transfert vers l'automatisation, ce contexte manquant finit généralement par poser problème. C'est aussi la catégorie d'éléments BPMN que la plupart des débutants considèrent comme facultative. Elle ne l'est pas toujours. Tout dépend de la nécessité d'agir à partir du diagramme ou simplement de le lire.

Les types de diagrammes BPMN et quand utiliser chacun d'eux

BPMN prend en charge trois types distincts de diagrammes. L'une des causes les plus fréquentes de confusion vient des équipes qui tentent d'utiliser un diagramme de processus pour représenter ce qui devrait être un diagramme de collaboration. La spécification de l'OMG indique clairement que BPMN s'adapte aux collaborations complexes entre plusieurs parties, mais chaque type sert un objectif différent, et le mauvais type produit le mauvais modèle.

Diagrammes de processus : cartographier ce qu'un participant contrôle

Un diagramme de processus, parfois appelé diagramme d'orchestration, constitue le point de départ par défaut. Il décrit ce qui se passe au sein d'un seul participant — une équipe, un système ou une organisation — sans montrer comment ce participant interagit avec le monde extérieur. Un workflow de traitement des commandes clients géré entièrement par un seul département, une séquence d'approbation automatisée de documents, une checklist d'onboarding attribuée aux RH : tous ces cas se prêtent bien à un diagramme de processus.

Ce type couvre la majorité de ce que les équipes doivent réellement documenter. Il montre le flux du processus, de l'événement de début à l'événement de fin, y compris les passerelles de décision, les tâches correspondant aux activités individuelles et les participants au processus dans des couloirs. Le flux de séquence entre les tâches est clair. Les responsabilités sont visibles.

Là où les équipes se trompent : lorsqu'un processus implique une autre organisation, un système tiers ou un client agissant de manière indépendante, un diagramme de processus unique commence à déformer la situation. Montrer les actions d'un client à l'intérieur du pool de votre équipe implique que vous contrôlez ces actions. Ce n'est pas le cas. C'est là qu'interviennent les diagrammes de collaboration.

Diagrammes de collaboration et de chorégraphie pour les workflows multipartites

Un diagramme de collaboration montre l'interaction entre deux participants ou plus, chacun étant représenté par un pool distinct. Les flux de messages — les lignes de connexion pointillées — traversent les limites des pools afin d'indiquer l'endroit où un participant envoie quelque chose à un autre. Un fournisseur qui soumet une facture, un client qui confirme une commande, un système partenaire qui renvoie une mise à jour de statut : ce sont des interactions multipartites, et un diagramme de collaboration est la bonne manière de les modéliser.

Le détail important est le suivant : chaque pool d'un diagramme de collaboration peut contenir son propre processus interne, mais le diagramme de collaboration lui-même montre l'échange de messages, et non la logique interne. Cette distinction est essentielle dans la conception de processus complexes, lorsque les diagrammes de processus métier doivent communiquer la gouvernance et la responsabilité au-delà des frontières organisationnelles.

Les diagrammes de chorégraphie vont plus loin dans l'autre direction. Au lieu de montrer ce que chaque participant fait en interne, un diagramme de chorégraphie montre uniquement la séquence des échanges de messages entre les participants : aucune logique interne, aucune tâche, aucun couloir. Considérez-le comme une vue contractuelle : voici quelles informations circulent entre les parties et dans quel ordre. Ce type de workflow est moins fréquent dans la modélisation quotidienne, mais devient utile lorsque plusieurs systèmes indépendants doivent s'accorder sur le séquencement des messages sans orchestrateur central.

La règle pratique : si un système ou une équipe contrôle l'ensemble du flux, utilisez un diagramme de processus. Si deux parties échangent des messages de manière indépendante, utilisez un diagramme de collaboration. Si vous vous intéressez uniquement à la chorégraphie des messages et non aux implémentations internes, utilisez un diagramme de chorégraphie.

BPMN face aux autres notations et outils de modélisation des processus

BPMN n'est pas la seule notation disponible, et choisir la mauvaise pour votre situation coûte plus de temps que le choix initial ne le laisse penser. Voici comment se comparent les principales options.

Quelques points méritent d'être précisés. UML et BPMN sont toutes deux des normes OMG, et les équipes supposent parfois qu'elles servent le même objectif. Ce n'est pas le cas. Le langage de modélisation unifié a été conçu pour modéliser des systèmes logiciels : structures de classes, machines à états, diagrammes de séquence. Il peut décrire des comportements similaires à des processus via des diagrammes d'activité, mais il n'est pas conçu pour être lisible par une partie prenante métier sans expérience en architecture logicielle. La notation graphique de BPMN, au contraire, a été conçue dès le départ pour être lisible entre rôles. Un losange de passerelle dans BPMN signifie la même chose, que le lecteur soit un COO ou un ingénieur backend.

Le decision model and notation (DMN) mérite d'être mentionné, car il apparaît fréquemment aux côtés de BPMN dans les outils modernes de modélisation des processus. DMN gère la logique de décision que BPMN ne modélise pas bien : des règles métier telles que « si la facture dépasse 10 000 $ et que le fournisseur est nouveau, exiger une approbation secondaire ». BPMN modélise le processus ; DMN modélise les règles à l'intérieur de la passerelle. Ils sont conçus pour fonctionner ensemble, et non pour se remplacer.

Les organigrammes de base conviennent parfaitement à une esquisse sur tableau blanc. Le problème est qu'ils ne portent aucune signification exécutable ni notation standard. Deux personnes issues d'équipes différentes peuvent dessiner le même organigramme et attribuer des significations totalement différentes à une flèche. Il ne s'agit pas d'un débat de préférence entre BPMN et organigramme : c'est précisément la raison pour laquelle une notation standard existe.

Ce que BPMN 2.0 a changé et pourquoi le numéro de version revient toujours

BPMN 1.2 était une norme de notation visuelle. Point final. Vous pouviez dessiner un processus, le partager avec une équipe et l'utiliser pour la documentation et l'analyse. En revanche, vous ne pouviez pas remettre ce diagramme directement à un moteur de processus et le faire exécuter.

BPMN 2.0 a fondamentalement modifié le périmètre de la spécification. La version 2.0 de BPMN a ajouté une sémantique d'exécution : une définition formelle de la manière dont chaque élément d'un diagramme doit se comporter lorsqu'il est exécuté par un moteur de processus. La mise à jour bpmn 2.0.2 a encore affiné cet aspect. Une tâche dans un diagramme BPMN 2.0 n'est pas simplement une boîte portant une étiquette : elle a une portée sémantique qu'un moteur d'exécution conforme peut interpréter directement. Cela a permis, pour la première fois, à un même diagramme de servir à la fois d'artefact de communication pour les parties prenantes métier et de spécification exécutable pour un moteur de processus.

C'est pourquoi le numéro de version revient encore lorsque les équipes évaluent des logiciels de modélisation des processus métier aujourd'hui. Les outils qui affirment prendre en charge BPMN varient considérablement quant à ce que cela signifie réellement. Certains outils ne prennent en charge BPMN qu'en tant que format de dessin. D'autres implémentent la sémantique d'exécution BPMN 2 et peuvent exécuter le diagramme comme un processus. Cette différence détermine si votre diagramme BPMN est une documentation ou un artefact opérationnel.

Avant BPMN 2.0, l'écart entre le modèle de processus et l'implémentation était comblé par le business process execution language (BPEL), un langage d'exécution basé sur XML qui nécessitait une traduction depuis le modèle visuel. BPMN 2.0 a largement absorbé ce rôle en rendant la notation visuelle elle-même exécutable, ce qui explique pourquoi les discussions sur BPEL ont fortement diminué dans les échanges sur les outils d'entreprise après la mise à jour de la spécification bpmn.

L'implication pratique : si vous évaluez aujourd'hui une plateforme compatible BPMN, demandez si elle implémente la sémantique d'exécution BPMN 2 ou si elle utilise BPMN comme couche de rendu au-dessus d'une logique d'exécution propriétaire. La réponse change le degré réel de portabilité de vos modèles de processus.

Qui utilise réellement BPMN et dans quel but

BPMN apparaît dans quatre contextes réels distincts, et l'objectif de BPMN diffère dans chacun d'eux. Regrouper tous ces usages sous l'appellation « gestion des processus d'entreprise » ne rend service à personne, car l'outil qui aide une équipe conformité à créer une piste d'audit fait quelque chose de différent du diagramme qui aide un product manager à extraire des exigences logicielles.

Les analystes de processus métier utilisent BPMN pour améliorer les processus

Les analystes métier sont probablement les utilisateurs les plus fréquents de BPMN en pratique. Le cas d'usage principal consiste à cartographier les états actuel et cible : documenter le fonctionnement actuel d'un processus, identifier les points de lenteur ou de défaillance, puis communiquer l'état futur amélioré à toutes les personnes affectées par le changement.

BPMN rend ce travail possible parce qu'il est lisible par tous les rôles. Un analyste peut s'asseoir avec les personnes qui exécutent le processus, capturer le workflow dans un diagramme BPMN, le leur présenter pour validation, puis remettre ce même diagramme à l'équipe d'implémentation sans avoir à le redessiner. Décrire les processus métier dans une notation partagée permet de maintenir la discussion sur le processus lui-même, tandis que le résultat de la cartographie des processus ne se perd pas dans la traduction entre documentation et livraison.

Les normes d'amélioration des processus dans les secteurs réglementés exigent souvent des preuves documentées qu'un processus a été modélisé, testé et approuvé avant la mise en production de changements. Les diagrammes BPMN constituent cette preuve. Résultat pratique essentiel : l'optimisation des opérations métier n'oblige pas à reconstruire la documentation depuis zéro à chaque étape d'approbation.

D'après ce que j'observe dans les tickets de support riches en processus, les équipes qui rencontrent le plus de difficultés sont celles qui documentent l'état actuel, mènent la discussion d'amélioration, puis laissent le diagramme BPMN diverger tandis que l'implémentation réelle avance sans lui. Le diagramme devient de l'archéologie en moins de six mois.

C'est généralement à ce moment-là que le travail d'amélioration des processus cesse de produire des résultats.

Comment les architectes d'entreprise et les équipes produit utilisent les modèles BPMN

Les architectes d'entreprise utilisent BPMN pour aligner les systèmes informatiques sur les workflows opérationnels réels — pas les workflows théoriques d'un organigramme, mais ceux qui ont vraiment lieu. Une architecture système conçue à partir d'un modèle BPMN précis reflète généralement la logique métier réelle plutôt que la version simplifiée que quelqu'un avait décrite lors d'une réunion d'exigences deux ans auparavant. Le cas d'usage PRE_RESEARCH est simple ici : les architectes utilisent BPMN pour identifier et structurer les cas d'usage que les systèmes de support doivent gérer, ce qui signifie que les décisions de conception logicielle reposent sur une réalité de processus documentée plutôt que sur des hypothèses.

Les product managers et les ingénieurs utilisent les modèles BPMN différemment. Un product manager peut parcourir un diagramme BPMN avec un client, valider chaque étape, identifier les étapes automatisées et celles qui resteront manuelles, puis utiliser le diagramme validé comme base des exigences logicielles. Le diagramme devient l'artefact de transfert entre la découverte produit et l'ingénierie. Les ingénieurs peuvent lire le même diagramme BPMN et identifier les appels de services, les branches de décision et les transitions d'état que le logiciel doit prendre en charge.

Les personnes qui tirent le meilleur parti de BPMN dans ces rôles sont celles qui traitent le diagramme comme un artefact vivant, et non comme un livrable. Les équipes métier et IT qui mettent à jour le modèle BPMN lorsque le processus change maintiennent l'alignement entre documentation et implémentation. Les équipes qui laissent vieillir le diagramme avant d'essayer de le réconcilier avec l'implémentation six mois plus tard découvrent généralement qu'elles modélisent de l'archéologie, et non la réalité du processus.

Un cas pratique : une équipe qui crée des workflows automatisés peut utiliser un diagramme BPMN pour cartographier la logique du processus avant de configurer une automatisation. Avant même qu'un seul nœud soit connecté dans Latenode ou dans tout autre outil, le diagramme répond à des questions telles que : où le processus se divise-t-il, qui reçoit l'exception, qu'est-ce qui déclenche l'étape suivante ? Lorsque l'étape de modélisation des processus métier intervient avant l'étape de construction, la configuration du workflow traduit une décision déjà prise ; elle ne résout pas un problème de conception au sein d'un éditeur. Les équipes qui ignorent cette étape et construisent directement à partir de descriptions verbales produisent généralement des workflows qui fonctionnent pour le parcours idéal et échouent dans tous les autres cas. Le langage de modélisation des processus métier existe précisément pour rendre ce travail de conception explicite et partagé avant le début de l'implémentation.

Trois idées reçues sur BPMN qui créent de vrais problèmes

Je retrouve constamment les mêmes trois hypothèses erronées dans les conversations qui précèdent une adoption de BPMN mal cadrée.

Chacune peut être corrigée, mais chacune crée de véritables frictions avant que les équipes y parviennent.

Idée reçue n° 1 : BPMN est simplement un organigramme avec des symboles sophistiqués.

C'est l'idée la plus courante, et elle vient généralement d'utilisateurs métier ou de parties prenantes qui ont vu quelques diagrammes BPMN et décidé qu'ils ressemblaient à des formes PowerPoint plus compliquées. La différence ne réside pas dans la complexité visuelle, mais dans la précision et l'exécutabilité. Une flèche d'organigramme signifie « puis quelque chose se passe ». Un flux de séquence BPMN possède une définition spécifique dans la norme. Une passerelle BPMN a un comportement défini : exclusif, inclusif, parallèle, basé sur les événements. Cette notation graphique normalisée permet à un diagramme d'être lu de manière cohérente par deux personnes qui ne se sont jamais rencontrées et implémenté de manière cohérente par un développeur qui n'était pas présent à la réunion initiale. Les organigrammes génériques ne peuvent pas faire cela. La représentation graphique semble similaire. Le poids sémantique est entièrement différent.

Idée reçue n° 2 : un diagramme BPMN correct doit utiliser tous les symboles.

Cette idée produit des diagrammes si denses en événements intermédiaires, événements de frontière et marqueurs de compensation que personne ne parvient à les lire. BPMN compte plus de 100 éléments définis dans la spécification complète. La plupart des modèles de processus réels en utilisent peut-être quinze à vingt. Les recommandations d'IBM sur BPMN sont constantes sur ce point : des sous-ensembles plus simples fonctionnent mieux en pratique, non pas comme compromis, mais comme approche réellement recommandée pour la plupart des modélisations métier. Utiliser chaque symbole disponible n'est pas un signe de justesse. C'est généralement le signe que quelqu'un a appris l'ensemble du vocabulaire symbolique avant d'apprendre quand l'utiliser.

Idée reçue n° 3 : BPMN est trop technique pour les parties prenantes métier.

C'est l'inverse. BPMN a précisément été conçu pour être lisible par les participants à la modélisation métier : c'est l'objectif de conception d'ISO/IEC 19510, et non un bénéfice secondaire. Sa réputation de complexité provient généralement d'implémentations surconçues dans lesquelles les équipes ont appliqué chaque symbole disponible à un processus qui n'en avait pas besoin. Le langage BPMN dans son sous-ensemble opérationnel — événements de début, tâches, passerelles, événements de fin, couloirs — est régulièrement utilisé par des analystes sans formation technique. La notation de modélisation des processus métier n'est intimidante que lorsqu'une personne vous remet un diagramme exploitant le vocabulaire complet pour décrire quelque chose qu'un diagramme en cinq étapes aurait suffi à couvrir. C'est un problème de diagramme, pas de norme.

🤔 Attendez.
La réputation de complexité de BPMN repose presque entièrement sur des implémentations surconçues, et non sur la norme elle-même. Si vous avez déjà vu un diagramme BPMN qui semblait illisible, demandez-vous s'il utilisait correctement la norme ou s'il l'utilisait de manière exhaustive. L'intention d'ISO/IEC 19510 était de garantir la lisibilité entre rôles. Les processus métier sont censés être interprétables à la fois par l'analyste qui a dessiné le diagramme et par l'ingénieur qui le met en œuvre. Lorsque cela ne se produit pas, le problème vient du diagramme, pas de la notation.

Les avantages de BPMN qui vont au-delà de diagrammes plus clairs

Les véritables avantages de BPMN s'accumulent dans des domaines qui n'apparaissent pas dans l'argumentaire initial en faveur de son adoption.

Un langage partagé sans coût de traduction récurrent.

Les processus métier passent des dizaines de fois entre les équipes métier et IT au cours de leur cycle de vie. Sans notation commune, chaque passage exige que quelqu'un traduise la description du processus de la version métier vers la version technique, puis inversement. BPMN réduit ce coût parce que les deux parties lisent le même diagramme. L'OMG a conçu la norme précisément pour cette raison. Ce n'est pas un avantage abstrait : c'est le coût cumulé de chaque réunion d'exigences, revue de processus et validation qui n'a pas été nécessaire parce que le diagramme était déjà suffisamment précis.

Traçabilité du processus jusqu'aux exigences logicielles.

Lorsqu'un processus métier est documenté dans BPMN avant la création d'un logiciel, le diagramme devient une preuve traçable reliant chaque exigence logicielle à une étape précise du processus. Lorsqu'un élément change dans le processus, vous pouvez identifier quelles parties de l'implémentation sont affectées. Sans cette traçabilité, les demandes de changement arrivent sous forme de descriptions vagues et l'analyse d'impact repart de zéro à chaque fois.

Auditabilité des processus réglementés.

Les équipes conformité utilisent BPMN parce qu'il fournit des preuves documentées de ce qu'un processus était censé accomplir, des personnes responsables de chaque étape et de la logique de décision applicable à chaque branche. Dans les secteurs où des pistes d'audit sont requises, un diagramme BPMN constitue un artefact défendable parce qu'il est régi par une norme internationale. La documentation d'IBM a constamment présenté l'auditabilité comme l'un des principaux cas d'usage d'entreprise pour l'adoption de BPMN.

Portabilité indépendante des fournisseurs.

BPMN étant formalisé sous ISO/IEC 19510, tout outil conforme peut lire un diagramme BPMN. Cela signifie que votre documentation de processus ne vit pas dans un format propriétaire qui disparaît lorsque vous changez d'outils. Selon l'OMG et la présentation de la norme par Visual Paradigm, cette portabilité est une caractéristique structurelle de la conception, et non un simple avantage appréciable. Les organisations qui changent de plateformes BPM ou travaillent au-delà des frontières organisationnelles avec des partenaires peuvent partager des diagrammes BPMN sans perdre leur signification. Les implémentations de modèles de gestion de cas combinant BPMN et traitement structuré des cas bénéficient de la même portabilité.

L'avantage pratique de tout cela : les processus métier documentés dans BPMN peuvent circuler entre outils, équipes et versions d'un même processus sans perdre le sens partagé qui y a été intégré dès le départ.

📊 En pratique :
Puisque BPMN est formalisé sous ISO/IEC 19510, un diagramme créé dans un outil conforme peut être importé et exécuté dans un autre sans devoir être redessiné. Cela compte lorsque les équipes changent de plateforme, fusionnent avec des organisations utilisant des outils différents ou transfèrent des modèles de processus entre fournisseurs. La conformité à la norme BPMN est le mécanisme ; la compatibilité entre fournisseurs en est le résultat.