Pools et couloirs dans BPMN : Définir clairement les responsabilités

Dans un diagramme BPMN, les Pools et les Lanes sont des éléments visuels essentiels utilisés pour définir qui fait quoi. Plus que de simples outils de mise en page, ils aident à structurer les processus clairement, en montrant les rôles, départements, organisations ou systèmes impliqués dans l'exécution.

Un pool représente toujours un participant au processus — quelqu'un ou quelque chose qui exécute ou collabore dans le processus, comme une entreprise, un département ou un système. Cette séparation visuelle aide à clarifier comment les participants interagissent à travers des échanges de messages et des responsabilités clairement définies.

Qu'est-ce qu'un Pool ?

Pour commencer à structurer un processus BPMN, vous devez d'abord identifier qui est impliqué. Un pool est l'élément qui représente chaque participant — qu'il s'agisse d'une entreprise, d'un département ou d'un système — qui joue un rôle dans le processus.

Un pool peut représenter :

• Une organisation (par exemple, "Fournisseur")
• Un département (pour les processus internes collaboratifs)
• Un système (tel que "ERP" ou "CRM")

Dans les modèles de processus collaboratifs, chaque pool montre quel participant effectue quelle partie du processus, et comment ils échangent des informations via des flux de messages.

Qu'est-ce que les Lanes ?

Après avoir identifié les participants, l'étape suivante consiste à comprendre comment les responsabilités sont divisées au sein de chacun. C'est là que les lanes interviennent : ce sont des subdivisions internes dans un pool qui montrent qui est responsable de chaque tâche.

Les Lanes divisent un pool en rôles, départements ou fonctions au sein du participant.

• Elles aident à attribuer la responsabilité de chaque tâche.
• Elles montrent la collaboration entre les domaines.
• Elles ne contiennent pas de logique — elles sont simplement des organisateurs visuels.

🔄 Flux de Séquence vs. Flux de Message

Lors de la modélisation de processus avec plusieurs participants (représentés par des piscines), il est essentiel de comprendre comment les tâches sont connectées. Toutes les connexions ne sont pas identiques — il y a une différence claire entre les flux internes, qui montrent l'ordre des activités au sein d'un participant, et les flux de message, qui montrent la communication entre différents participants.

• Flux de Séquence (flèches pleines) : connecte les activités au sein de la même piscine, montrant l'ordre d'exécution.

• Flux de Message (lignes pointillées) : connecte les activités entre différentes piscines, indiquant un échange d'informations ou une coordination.

✅ Meilleures Pratiques

Maintenant que vous comprenez les piscines, les couloirs et les types de flux, voici quelques meilleures pratiques pour vous aider à utiliser ces éléments efficacement et à garder votre diagramme clair, précis et prêt pour l'exécution ou la documentation.

• Utilisez des piscines distinctes pour des participants distincts.
• Utilisez des couloirs pour définir clairement les responsabilités au sein d'une piscine.
• Ne connectez jamais les piscines avec un flux de séquence — utilisez toujours un flux de messages.
• Nommer clairement les piscines et les couloirs en utilisant des termes compris par votre organisation.
• Évitez de nommer les couloirs d'après des individus. Utilisez des rôles ou fonctions (par exemple, “Analyste Achats” ou “Responsable Financier”) afin que le processus reste valide même si l'équipe change.

💡 Bons exemples de noms de couloirs : “RH,” “Finance,” “Manager du Demandeur”
❌ À éviter : “John Smith,” “Ana Pereira”

Comment gérer les messages entre les pools

Dans BPMN, la communication entre différents participants (représentés par des pools séparés) doit toujours se faire en utilisant des flux de messages — et non des flux de séquence. Pour représenter cela correctement, vous pouvez utiliser des types de tâches spécifiques et des événements de message conçus à cet effet.

Voici les principaux éléments que vous pouvez utiliser :

Tâche d'envoi

Une tâche d'envoi est utilisée lorsque le processus doit envoyer un message à un autre pool. Elle montre visuellement que le but principal de la tâche est de distribuer un message à un participant.

💡 Exemple : Après avoir validé une demande de résiliation, une tâche d'envoi peut être utilisée pour notifier le département informatique.

Tâche de réception

Une tâche de réception est utilisée lorsque le processus attend de recevoir un message spécifique d'un autre pool avant de continuer. Elle représente un point d'attente explicite pour la communication entrante.

💡 Exemple : L'équipe informatique peut utiliser une tâche de réception pour attendre une demande formelle de révocation d'accès.

Événements de message intermédiaires

Vous pouvez également utiliser des événements de message intermédiaires pour modéliser des points de communication plus flexibles.

• Événement de message émis (envoi) : utilisé pour envoyer un message en cours de processus.
• Événement de message reçu (réception) : utilisé pour attendre un message avant de continuer le flux.

Ceux-ci sont utiles lorsque le message n'est pas l'objectif principal de la tâche, mais fait partie d'une activité plus large.

💡 Exemple : Un événement de message reçu peut être placé avant une tâche d'approbation qui ne doit commencer qu'une fois qu'une confirmation externe est reçue.

Événement de début de message

Si un processus est déclenché par un message d'un autre participant, vous pouvez utiliser un événement de début de message au début de ce processus.

💡 Exemple : Le processus de “Gestion des accès aux systèmes informatiques” peut commencer par un événement de début de message lorsqu'il reçoit une demande du processus RH.

Utiliser la bonne combinaison de tâches de message et d'événements aide à rendre le flux de processus plus précis, maintenable et prêt pour l'automatisation — surtout lorsque des systèmes ou des partenaires externes sont impliqués.

Événement de fin de message

Un événement de fin de message est utilisé lorsqu'un processus se termine en envoyant un message à un autre participant. Il représente le point final du processus, où un message est envoyé — souvent pour notifier une autre équipe ou déclencher un processus de suivi.

• Il est visuellement similaire à d'autres événements de fin, mais marqué d'un symbole d'enveloppe.
• Couramment utilisé dans les sous-processus ou les processus de soutien qui doivent rendre compte au flux principal.

💡 Exemple : Après avoir terminé la vérification de la dette, le processus financier se termine par un événement de fin de message qui notifie l'équipe RH, leur permettant de procéder aux étapes finales.

Exemple Pratique : Résiliation de Contrat de Travail

Explorons maintenant un exemple de BPMN pour renforcer ce que nous avons appris — cette fois en utilisant le processus de Résiliation de Contrat de Travail.

C'est un scénario courant dans le monde réel qui nécessite une coordination entre plusieurs équipes — telles que les RH, les managers directs et le département informatique — pour s'assurer que toutes les étapes sont complétées de manière sécurisée, cohérente et dans le bon ordre.

Dans cet exemple, nous nous concentrons sur l'utilisation des flux de messages entre les pools pour :

• Initier des processus dans d'autres équipes
• Maintenir le processus principal faiblement couplé tout en assurant la coordination
• Transitionner les tâches entre les voies pour refléter les changements de responsabilité basés sur les rôles

Commençons par analyser les flux mis en évidence dans l'image ci-dessous.

La flèche A montre un flux de séquence reliant deux tâches au sein du même pool. Alors que le processus de Résiliation de Contrat de Travail passe de "Compléter la Documentation de Résiliation" à "Valider la Demande de Résiliation", la responsabilité se déplace entre les voies, représentant différents rôles au sein de l'organisation.

De plus, la flèche B illustre un flux de message. Ici, le processus principal envoie un message à l'équipe de Gestion des Accès Systèmes Informatiques, initiant un processus séparé pour révoquer l'accès au système. Ce sous-processus fonctionne de manière indépendante — le processus principal de résiliation n'attend pas sa complétion.

Examinons maintenant comment le processus interagit avec le troisième pool.

La flèche C représente un message déclenché par l'événement intermédiaire “Notification de Dettes en Souffrance” et reçu par l'événement de début “Résiliation de l'Employé Traitée” dans le troisième pool. Ce pool contient une seule tâche, et à son achèvement, il atteint l'événement de fin “Vérification des dette terminée,” qui à son tour envoie un autre message — représenté par la flèche D.

Pendant ce temps, dans le pool appelant, l'utilisateur RH peut exécuter la tâche “Annuler les Avantages et Déductions” en parallèle avec le processus du troisième pool. Cependant, le flux doit s'arrêter à “Recevoir le Message de Vérification Financière” pour attendre la confirmation de l'équipe financière.

Ce comportement de blocage garantit qu'aucun processus de résiliation ne peut être finalisé sans vérification de la dette de l'équipe financière.

Ce processus complet fait partie de notre base de données d'exemples et est disponible gratuitement pour tous les utilisateurs de HEFLO. 👉 Cliquez sur le bouton ci-dessous pour créer un compte HEFLO gratuit et explorer ce diagramme BPMN en entier, directement dans le modélisateur.

Types de Pool : Boîte Noire et Boîte Blanche

Parfois, vous n'avez pas besoin ou ne souhaitez pas montrer ce qui se passe à l'intérieur de chaque participant. C'est pourquoi BPMN vous permet de représenter un pool de deux manières, selon le niveau de détail interne que vous souhaitez afficher.

1. Pool Boîte Noire

Un pool boîte noire est utilisé lorsque vous ne montrez pas le processus interne du participant. Il apparaît dans le diagramme, mais ne contient aucune tâche visible.

• Représente une partie externe à qui vous envoyez ou de qui vous recevez des messages.
• Commun pour les clients, fournisseurs, partenaires ou systèmes tiers.
• Aide à garder le focus sur ce qui est pertinent pour le processus modélisé.

L'image ci-dessous illustre un bon exemple de pool Boîte Noire. L'événement "Acquisition de biens déclenchée" envoie un message et attend une réponse. Puisque le "Processus d'Achat" représente un processus externe, ce qui se passe à l'intérieur n'est pas montré — et du point de vue du processus principal, cela n'a pas d'importance.

2. Pool Boîte Blanche

Un pool boîte blanche montre les activités internes du participant.

• Utilisé lorsque vous souhaitez modéliser le processus à l'intérieur du participant.
• Peut être subdivisé en couloirs pour montrer les rôles ou départements.
• Vous permet de tracer le flux de séquence entier au sein de l'organisation.

L'exemple "Résiliation de Contrat de Travail" ci-dessus est un cas clair de pool Boîte Blanche, car il affiche toutes les tâches internes et leur flux d'exécution.

🎥 Leçon Vidéo Gratuite : Modélisation d'une Piscine avec Deux Couloirs

Vous voulez voir tout cela en action ?

Nous avons enregistré une leçon vidéo gratuite qui vous guide pas à pas dans la construction d'un processus BPMN en utilisant un seul pool avec deux couloirs. C'est le moyen idéal pour comprendre comment modéliser les responsabilités internes au sein d'un participant.

Dans cette vidéo, vous apprendrez :

• Comment créer un pool et ajouter des couloirs pour différents rôles ou départements
• Comment placer correctement les tâches dans chaque couloir
• Comment connecter les tâches en utilisant des Flux de Séquence au sein du même pool
• Et les meilleures pratiques de mise en page pour garder votre diagramme propre et professionnel

Questions Fréquemment Posées

Même avec les concepts clairement expliqués, certaines questions sont courantes — surtout pour ceux qui découvrent BPMN. Voici les réponses aux doutes les plus fréquents :

Puis-je utiliser des couloirs dans différents bassins ?

Oui. Chaque bassin peut avoir son propre ensemble de couloirs pour représenter des rôles ou départements internes. Cependant, les flux de messages ne doivent connecter que des éléments entre les bassins, jamais entre des couloirs dans différents bassins.

Puis-je connecter des tâches entre bassins en utilisant des flux de séquence ?

Non. Les flux de séquence doivent rester dans le même bassin. Pour connecter différents bassins, utilisez toujours des flux de messages — ils représentent la communication entre les participants.

Les couloirs peuvent-ils être imbriqués ou hiérarchiques ?

Non. Tous les couloirs dans un bassin sont au même niveau. BPMN ne supporte pas les couloirs imbriqués ou indentés.

Dois-je nommer les couloirs d'après des personnes ?

Non recommandé. Utilisez toujours des rôles, départements ou titres de poste. Évitez les noms personnels pour que votre diagramme reste valide dans le temps, même si les membres de l'équipe changent.

Quand dois-je utiliser une Tâche d'Envoi vs. un Événement de Fin de Message ?

Utilisez une Tâche d'Envoi lorsque l'envoi d'un message fait partie d'un processus, généralement suivi par d'autres tâches. Utilisez un Événement de Fin de Message lorsque le processus se termine par l'envoi d'un message — par exemple, pour notifier une autre équipe qu'une tâche est terminée.

Quelle est la différence entre une Tâche de Réception et un Événement de Capture de Message ?

Les deux attendent un message, mais une Tâche de Réception est traitée comme une tâche complète (peut être assignée, suivie, etc.), tandis qu'un Événement de Capture de Message est plus léger et souvent utilisé pour des points de contrôle ou de décision.

Comment démarrer un processus lorsqu'un message est reçu ?

Utilisez un Événement de Début de Message. Il déclenche le début d'un processus lorsqu'un message spécifique arrive — courant dans les processus qui dépendent de demandes externes.

Que faire si j'ai plusieurs équipes travaillant en parallèle ?

Utilisez des branchements parallèles à l'intérieur d'un bassin, ou déclenchez plusieurs flux de messages vers différents bassins. Synchronisez-les avec un événement de réception de message ou un branchement de jonction plus tard, selon votre logique.

Conclusion

Comprendre comment définir les participants et les responsabilités en utilisant des piscines et des couloirs est essentiel pour créer des diagrammes BPMN clairs, collaboratifs et prêts pour l'amélioration ou l'automatisation. Les piscines et les couloirs rendent votre processus facile à lire et aligné avec le fonctionnement réel de votre organisation.