Tous les articles
Comparatif13 août 2026 · 5 Min de lecture

Outil BPMN avec simulation : ce que la notation peut calculer et ce qu’elle ne peut pas

En bref

BPMN est une notation pour la structure, c’est‑à‑dire pour les étapes, les bifurcations et les rôles. Pour calculer, il lui manque cinq éléments : le processus d’arrivée, la dispersion des durées de traitement, la capacité par ressource, les probabilités de bifurcation et les calendriers de travail. La norme BPSim a été créée précisément pour cela, afin d’attacher ces informations à un modèle BPMN. Un outil BPMN doté d’un module de simulation ne calcule donc bien que dans la mesure où il accepte ces cinq types de données. S’ajoute la question de savoir s’il fournit les résultats sous forme d’un intervalle plutôt que d’une valeur unique.

Inhaltsverzeichnis

Il y a une phrase qui conduit régulièrement à de mauvaises décisions lors du choix d’un outil : « Notre outil BPMN peut aussi faire de la simulation. » Elle est le plus souvent vraie et presque toujours inutile, car elle peut signifier tout, depuis une vérification de plausibilité jusqu’à un simulateur d’événements complet.

La raison tient à la notation elle‑même.

Ce que BPMN décrit et ce qu’il ne décrit pas

BPMN 2.0 est une norme de l’OMG pour la structure d’un processus : tâches, événements, passerelles, couloirs, flux de messages. Elle répond complètement et précisément à la question « que se passe‑t‑il dans quel ordre, et qui le fait ? ».

Pour calculer, il lui manque cinq informations que la notation ne prévoit tout simplement pas :

  1. Le processus d’arrivée. Combien de dossiers arrivent, et comment sont‑ils répartis ? Vingt demandes par jour réparties uniformément donnent une image totalement différente de vingt demandes arrivant en masse tôt le lundi.
  2. La dispersion des durées de traitement. Pas « 10 minutes », mais « 5 à 20 minutes, la plupart du temps 8 ». C’est la dispersion qui pilote la file d’attente, pas la moyenne.
  3. La capacité par ressource. Combien de personnes avec quel taux d’activité, et quelles fonctions partagent un pool ?
  4. Les probabilités de branchement. Une passerelle XOR indique qu’il y a un branchement. La fréquence d’emprunt de chaque chemin n’apparaît nulle part dans le diagramme.
  5. Le calendrier. Huit heures par jour, jours fériés, équipes. Une demande qui arrive le vendredi à 16:50 n’attend pas dix minutes, mais trois jours.

BPSim a été créé précisément pour ce problème. La norme de la WfMC attache des paramètres de simulation à un modèle BPMN, sans modifier la notation. Le besoin de cette norme est la meilleure preuve que BPMN seul ne peut pas calculer.

Ce que livrent typiquement les modules de simulation dans les outils BPMN

Les suites de modélisation répandues (Bizagi Modeler, SAP Signavio, ARIS et autres) proposent la simulation par paliers. La structure habituelle, quel que soit le fournisseur :

  • Vérification de structure. Un jeton traverse‑t‑il le modèle ou existe‑t‑il des impasses et des branches jamais atteintes ? Utile, mais ce n’est pas encore une simulation au sens strict.
  • Analyse temporelle. Durées par tâche, d’où la durée de traversée. Toujours sans limite de capacité, donc sans files d’attente.
  • Analyse des ressources. Là ça devient intéressant : personnes avec capacité, ce qui crée des files d’attente et de l’utilisation.
  • Analyse des calendriers. Temps de travail et équipes, rendant ainsi les temps d’attente réalistes.

Camunda n’appartient volontairement pas à cette énumération : c’est un moteur d’exécution, pas un environnement de simulation. Il laisse de vrais cas traverser le processus et les mesure. C’est plus précieux que n’importe quelle simulation. Mais seulement quand le processus est déjà automatisé. Avant la décision, il n’aide pas.

Les cinq questions à poser à votre outil

Ouvrez votre outil de modélisation et vérifiez en dix minutes :

1. Puis‑je saisir une durée comme une plage ? Si le champ n’accepte qu’un seul nombre, l’outil calcule avec des valeurs moyennes. Alors le résultat sera systématiquement trop optimiste. Les files d’attente naissent de la dispersion, et sans dispersion elles n’existent pas.

2. Obtiens‑je un résultat avec une fourchette ? Une durée de parcours de « 6,4 jours » n’est pas une explication, juste un nombre. « P10 4,1 à P90 11,8 jours » est une information. Les outils qui ne donnent que des valeurs ponctuelles ont soit calculé de manière déterministe, soit omis la dispersion.

3. Les rôles partagent‑ils une capacité ? En pratique, une même personne réalise trois étapes différentes. Les outils qui gèrent la capacité par tâche au lieu du pool comptent chaque étape indépendamment. La personne qui fait les trois n’est à l’aise dans aucune d’elles.

4. Vois‑je le jour de pointe ou la moyenne mensuelle ? En moyenne mensuelle, presque chaque rôle est en dessous de 80 % d’utilisation. Le jour de pointe, c’est précisément là que le processus a cassé. Si le taux d’utilisation n’indique pas à quoi il se réfère, il est sans valeur.

5. Combien coûte l’amélioration, et qu’apporte‑t‑elle ? Presque aucun outil de modélisation ne répond à cela, car les taux de coût et les investissements ne font pas partie du modèle. Et pourtant, ce chiffre décide du projet.

Le point où même de bons modules s’arrêtent

Supposons que votre outil réussisse les cinq vérifications. Il reste une dernière question. La plupart des analyses échouent sur celle‑ci, non par incapacité technique, mais parce que personne ne la pose :

Où se déplace le goulot d’étranglement si je le résous ?

Un exemple connu : la vérification prend trop de temps, on l’automatise. La simulation confirme : le temps de vérification diminue de 80 %. Ce qu’elle ne montre souvent pas : la validation située après recevait jusque‑là un dossier toutes les 26 minutes, car la vérification freinait. Maintenant elle en reçoit un toutes les 10 minutes et devient surchargée. Le débit n’augmente pas comme promis, et le temps économisé se retrouve dans une nouvelle file d’attente.

Ce n’est pas un cas exotique, mais la règle. Un goulot d’étranglement ne disparaît pas, il migre. Un modèle qui ne permet pas de simuler ce déplacement en quelques secondes mène à des business cases qui, en exploitation, ne se réalisent pas.

Recommandation pratique

  • Vous avez déjà une suite de modélisation avec module de simulation ? Utilisez‑la. Un second outil ne vaut la peine que si vous échouez sur l’une des cinq questions.
  • Vous commencez à modéliser ? Ne commencez pas par BPMN. La notation est conçue pour la documentation ; pour la question « où ça coince et qu’apporte un changement ? » elle est un détour via un langage qu’il faut d’abord apprendre.
  • Vous devez justifier un investissement ? Alors vous avez besoin de plages, du jour de pointe, de pools de ressources partagés et d’un cas Avant/Après en euros. Vérifiez lequel de vos outils existants fournit cela avant d’en acheter un nouveau.

FlowVisual renonce délibérément à BPMN : six blocs au lieu d’une notation, des durées comme plages, l’utilisation au jour de pointe, des pools partagés. Au final, un Avant/Après en euros avec fourchette P10–P90. Qui a besoin de BPMN pour la documentation ne la remplace pas avec cela. FlowVisual répond à une autre question.

Questions fréquentes

Qu'est-ce que BPSim ?

BPSim est une norme de la Workflow Management Coalition qui attache des paramètres de simulation (taux d'arrivée, distributions, coûts, ressources, calendriers) à un modèle BPMN sans changer la notation elle-même. Elle existe parce que BPMN décrit la structure et que ces indications n'y sont simplement pas prévues.

Camunda peut-il simuler des processus ?

Camunda est une machine d'exécution : elle exécute de véritables instances de processus et mesure leurs durées réelles. C'est plus fiable que n'importe quelle simulation. Mais cela suppose que le processus soit déjà automatisé. Pour décider si une modification en vaut la peine, vous avez besoin d'un modèle avant de construire.

La simulation dans Bizagi ou Signavio suffit-elle pour un business case ?

Pour la question de structure et de durée dans de nombreux cas oui. Si cela suffit pour le business case dépend de trois points : si vous pouvez entrer des durées comme fourchette, si les résultats sortent avec un intervalle, et si les pools de ressources partagées sont modélisés. Vérifiez ces trois points avant d'inscrire un chiffre dans un document de décision.

Pourquoi la moyenne d'une durée de traitement n'est-elle pas suffisante ?

Parce que les files d'attente naissent de la dispersion. Deux processus avec la même durée moyenne de traitement ont des temps de traversée totalement différents si l'un d'eux varie fortement. Qui calcule avec des moyennes sous-estime systématiquement le temps d'attente, et d'autant plus que l'utilisation se rapproche de la limite de capacité.

FlowVisual

Calculez-le pour votre propre processus

FlowVisual transforme les chiffres de cet article en un modèle opérationnel, avec vos volumes, vos capacités, votre marge.

Guide: seven steps to the number