Flux de message
Une flèche en pointillés entre deux piscines qui montre un message envoyé d'un participant à l'autre.
Ce que représente un flux de message
Un flux de message est une flèche en pointillés avec une tête ouverte et un petit marqueur d'enveloppe à sa source ou en son milieu. Il relie des activités ou des événements dans des *piscines différentes*. Sémantiquement, il dit « quand cette étape source se déclenche, un message est envoyé à l'étape cible ». Contrairement au flux de séquence, un flux de message ne transfère pas de jeton ; chaque piscine a ses propres jetons, et le message est la seule chose qui traverse la frontière.
Cette distinction est essentielle parce qu'elle fixe où se trouve le contrôle. Un flux de séquence implique « je fais ceci, puis je fais cela, même acteur ». Un flux de message implique « j'envoie ceci ; quelqu'un d'autre, hors de mon contrôle, décide si et quand il agit dessus ». À chaque fois qu'un processus touche un tiers — un client, un fournisseur, une API externe — la frontière se matérialise par un flux de message, jamais un flux de séquence.
Les règles à retenir
- Les flux de message connectent uniquement des *piscines différentes*. Entre activités d'une même piscine, utilisez des flux de séquence.
- Les sources sont typiquement des événements de message qui lèvent, des événements de fin de message, ou des activités produisant un message en sortie. Les cibles sont des événements de message qui rattrapent, des événements de début de message, ou des activités qui consomment un message.
- Un flux de message vers une piscine repliée (boîte noire) est parfaitement valide — inutile de modéliser l'autre côté.
- Ne mélangez pas flux de séquence et flux de message de façon à rendre ambiguë la frontière interne/externe. Un flux est l'un ou l'autre.
Les flux de message dans LucidFlow
LucidFlow place des flux de message partout où le document source décrit une communication asynchrone entre parties — « on envoie au client un lien par e-mail », « la banque nous envoie l'avis de règlement ». La heatmap calcule le temps d'attente d'un flux de message comme l'écart entre l'envoi et la réception — qui est généralement le délai le plus important de tout processus inter-organisationnel. Modélisé ainsi, « le client met en moyenne 4 jours à répondre » devient un goulot d'étranglement visible que vous pouvez cibler avec une automatisation de relance.
Questions fréquentes
Un flux de message peut-il traverser une frontière de couloir à l'intérieur d'une même piscine ?
Non. Traverser une frontière de couloir est un flux de séquence — le jeton se déplace toujours dans le même participant. Les flux de message sont strictement piscine à piscine.
Un flux de message est-il synchrone ou asynchrone ?
BPMN le modélise comme asynchrone par défaut — l'émetteur envoie et continue, le destinataire traite quand il peut. Une interaction requête/réponse synchrone est représentée par deux flux de message : un de l'appelant vers l'appelé, un de l'appelé en retour.
Comment modéliser un message vers un système et non une personne ?
De la même façon. La piscine destinataire est le système. Si les rouages internes du système sont hors de propos, repliez la piscine en boîte noire et montrez simplement le flux de message entrant et l'éventuelle réponse ressortant.