Exemple de diagramme en couloirs (swimlane) : des logigrammes interfonctionnels qui montrent chaque transfert

Un client demande un remboursement de 40 USD le lundi. Le support l'approuve dans l'heure et le transmet à la finance, qui émet les remboursements par lot le jeudi. La banque peut ensuite mettre 5 à 10 jours ouvrés à afficher le crédit. Dix jours après la demande, sans rien sur son relevé, le client conteste le débit.

Chaque équipe a fait son travail dans les délais. Le retard se trouvait entre les équipes, dans les files d'attente où la demande attendait son prochain responsable. Un logigramme simple de ce processus paraît inoffensif. Un diagramme en couloirs place chaque étape dans le couloir de celui qui la réalise, et le problème apparaît sous la forme de flèches qui traversent les couloirs.

Cet article explique les diagrammes en couloirs et quand en utiliser un plutôt qu'un logigramme ou du BPMN, puis déroule un exemple de remboursement : symboles, transferts, améliorations et conseils de dessin.

Ce qu'est un diagramme en couloirs

Un diagramme en couloirs est un logigramme divisé en couloirs parallèles, un par acteur : une personne, un rôle, une équipe ou un système. Chaque étape se trouve dans le couloir de celui qui l'exécute. Les flèches donnent toujours l'ordre ; les couloirs ajoutent la responsabilité. Logigramme interfonctionnel, diagramme swim lane et cartographie de processus en couloirs sont d'autres noms pour la même chose.

Une flèche à l'intérieur d'un couloir est du travail qui circule dans une équipe. Une flèche qui franchit la limite d'un couloir est un transfert : le travail change de responsable et attend généralement dans une file avant que quelqu'un s'en occupe.

Dans Improving Performance, publié pour la première fois en 1990, Geary Rummler et Alan Brache soutenaient que « les plus grandes opportunités d'amélioration de la performance se trouvent souvent dans les interfaces fonctionnelles », là où le travail passe d'un service à l'autre : l'espace blanc de l'organigramme, comme le dit leur sous-titre. Un diagramme en couloirs dessine cet espace blanc.

Diagramme en couloirs, logigramme ou BPMN ?

Choisissez selon la question à laquelle vous devez répondre. Si c'est « que se passe-t-il ensuite ? », un logigramme suffit, comme le logigramme de réponse aux incidents que suit un ingénieur d'astreinte. Si c'est « qui a ceci maintenant, et depuis combien de temps attend-il ? », il vous faut des couloirs. Choisissez BPMN quand un moteur de processus exécutera le modèle, ou quand les événements et flux de messages entre organisations doivent être exacts. La spécification BPMN 2.0.2 appelle ses pools et couloirs des swimlanes et laisse au modélisateur le sens d'un couloir ; l'exemple de diagramme BPMN traite de cette notation.

L'exemple : une demande de remboursement, étape par étape

Une boutique en ligne gère les remboursements avec quatre acteurs : le client, le support, la finance et le système de paiement (prestataire de paiement plus facturation). La politique de l'exemple accepte les remboursements sous 30 jours, laisse le support approuver ceux de moins de 100 USD et envoie les plus gros à la finance.

1. Le client demande un remboursement.
2. Le support vérifie la commande par rapport à la politique de remboursement.
3. Si la demande sort de la politique, le support envoie un refus motivé.
4. Si elle est inférieure à 100 USD, le support l'approuve et émet le remboursement le jour même.
5. Si elle est de 100 USD ou plus, la finance l'examine. Si la finance trouve un motif de refus, le support explique la décision au client.
6. Le système de paiement rembourse le moyen de paiement d'origine et envoie un e-mail de confirmation.
7. La banque affiche le crédit environ 5 à 10 jours ouvrés plus tard, d'après la documentation de Stripe sur les remboursements.

Symboles d'un diagramme en couloirs

Résistez à l'envie d'en ajouter : chaque symbole supplémentaire est une chose de plus qu'un analyste financier doit apprendre avant de vérifier votre travail.

Ce que révèlent les couloirs

Transferts

Comptez les flèches qui franchissent la limite d'un couloir. Un remboursement de moins de 100 USD en franchit trois : du client au support, du support au système de paiement, du système de paiement de nouveau au client. Un remboursement de 100 USD ou plus en franchit quatre, tout comme une demande que la finance refuse. Avant l'existence du seuil, chaque remboursement suivait un chemin à quatre transferts. Chaque transfert est une file d'attente ; dans l'histoire d'ouverture, le travail a pris quelques minutes et l'attente des jours.

Attentes et boucles de reprise

Les attentes se cachent aux transferts : écrivez-les donc sur les flèches. Pour mesurer en détail le temps par étape et entre les étapes, dessinez une cartographie de la chaîne de valeur.

Les boucles de reprise sont des flèches qui reviennent vers un couloir déjà visité par le travail. Le refus de la finance revient volontairement au support, car le support gère la conversation avec le client. Quand le support demande au client un numéro de commande que le formulaire aurait pu exiger, c'est du gaspillage pur.

Responsables manquants

Une étape que vous ne pouvez placer dans aucun couloir est une lacune de responsabilité. Vérifiez les remboursements échoués : Stripe précise qu'un remboursement peut échouer, par exemple quand le compte bancaire du client est clos, que l'argent peut mettre jusqu'à 30 jours à revenir sur votre solde, et que vous devez construire votre propre logique pour prévenir les clients ou votre équipe. Si aucun couloir ne possède cette étape, personne ne le fera.

Améliorer le processus à partir du diagramme

1. Supprimez un transfert. Laissez le support émettre directement les petits remboursements, ce qui retire la file de la finance de chaque remboursement sous le seuil. Les prestataires de paiement le permettent sans accès complet : le rôle Refund Analyst de Stripe peut consulter et rembourser des paiements, mais pas créer de paiements ni voir le solde (au moment de la rédaction, novembre 2026).
2. Ajoutez un seuil d'approbation. Choisissez-le à partir de données : triez les remboursements du dernier trimestre par montant et regardez combien de demandes, et quelle somme, tombent sous chaque candidat. Écrivez le chiffre dans la décision elle-même pour que personne n'ait à le chercher. Si la limite doit être imposée plutôt que respectée sur parole, vérifiez-la dans votre outil de remboursement avant qu'il n'appelle l'API de paiement.
3. Fixez un objectif à chaque transfert, écrit sur la flèche : le support répond sous 1 jour ouvré, la finance décide sous 2. Un petit remboursement est alors émis sous 1 jour ouvré et un gros sous 3. Les 5 à 10 jours ouvrés de la banque échappent à votre contrôle : dites-le dans l'e-mail de confirmation.

Couloirs horizontaux ou verticaux

BPMN autorise les couloirs dans les deux sens. La différence est pratique :

Choisissez un sens pour un ensemble de diagrammes liés, afin que les lecteurs n'aient jamais à se réorienter.

Le diagramme en couloirs de la demande de remboursement

Comment le lire :

• Quatre couloirs, de haut en bas : client, support, finance et système de paiement.
• Yes sort toujours à droite, No vers le bas. Chaque question est formulée de sorte que Yes signifie que quelque chose demande de l'attention : hors politique, 100 USD ou plus, un motif de refus.
• Le vert est le chemin du remboursement. Les demandes de moins de 100 USD descendent du support directement au système de paiement et n'entrent jamais dans le couloir de la finance.
• Le rouge est le chemin du refus. Les deux refus se terminent par l'envoi du motif au client par le support.
• Les libellés des transferts portent les objectifs ; la flèche en pointillés représente les 5 à 10 jours ouvrés de la banque.
• Le bloc Markdown liste la politique, les objectifs et les transferts par chemin.

Dessiner clairement des diagrammes en couloirs

• Un seul responsable par couloir. Nommez les couloirs d'après des rôles, des équipes ou des systèmes, pas des personnes ; un couloir nommé Dana devient faux à la prochaine réorganisation.
• Commencez chaque boîte par un verbe : « Check order and refund policy », pas « Order check ».
• Étiquetez chaque sortie de décision, et gardez chaque réponse du même côté de chaque losange.
• Ordonnez les couloirs selon le trafic, pour que la plupart des transferts ne franchissent qu'une limite. Ne sautez un couloir que volontairement, comme le fait ici le petit remboursement.
• Écrivez les attentes sur les transferts. Le temps d'attente reste invisible tant que personne ne le note.
• Laissez de côté les rouages internes des systèmes. Les appels d'API et les webhooks relèvent d'une vue d'architecture comme le diagramme d'intégration d'une passerelle de paiement.
• Dessinez séparément le processus actuel et la proposition, pour que personne ne prenne le plan pour la situation d'aujourd'hui.
• Terminez chaque chemin par un terminateur, et scindez le diagramme s'il demande plus de six ou sept couloirs.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme, ou ouvrez le modèle de logigramme interfonctionnel, qui contient déjà des couloirs.
2. Ajoutez une Piscina depuis le pack BPMN, nommée Refund request process, avec quatre couloirs : Customer, Support, Finance et Payment system.
3. Depuis le pack Logigramme, ajoutez trois nœuds Début / Fin au couloir Customer : Request refund, Request closed et Refund received.
4. Dans Support, ajoutez un Processus pour vérifier la commande, deux nœuds Décision (Outside refund policy?, $100 or more?) et un Processus pour envoyer le refus.
5. Dans Finance, ajoutez un Processus (Review refund) et une Décision (Reason to decline?). Dans Payment system, ajoutez un Processus pour le remboursement et un Document pour l'e-mail de confirmation.
6. Reliez les étapes avec chaque Yes vers la droite et chaque No vers le bas. Étiquetez les transferts avec leurs objectifs, colorez le chemin du remboursement en vert et celui du refus en rouge, et mettez l'attente de la banque en pointillés.
7. Ajoutez un bloc Markdown depuis le pack Base avec la politique et les objectifs, plus deux notes Texte.

Si le processus existe déjà sous forme de logigramme Mermaid, l'outil de conversion Mermaid en diagramme en tire un premier brouillon modifiable. Un diagramme Free contient 15 nœuds de diagramme : un processus plus long demande donc Pro ou un second diagramme. L'exemple utilise 13 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Qu'est-ce qu'un diagramme en couloirs (swimlane) ? Un logigramme divisé en couloirs, un par personne, équipe ou système, avec chaque étape dans le couloir de celui qui la réalise. Les flèches qui franchissent la limite d'un couloir sont des transferts.

Quelle est la différence entre un diagramme en couloirs et un logigramme ? Un logigramme montre l'ordre des étapes et des décisions. Un diagramme en couloirs ajoute la responsabilité, ce qui rend visibles les transferts, les attentes et les étapes sans responsable.

Un logigramme interfonctionnel est-il la même chose qu'un diagramme en couloirs ? Oui, les noms sont interchangeables, tout comme cartographie de processus en couloirs. BPMN utilise aussi des couloirs, mais dans des pools et avec une notation plus stricte.

Les couloirs doivent-ils être horizontaux ou verticaux ? Les deux fonctionnent. Les couloirs horizontaux conviennent aux longs processus sur grand écran ; les couloirs verticaux aux documents et aux téléphones qui défilent vers le bas. Choisissez un sens par ensemble de diagrammes.

Un système peut-il avoir son propre couloir ? Oui. Un prestataire de paiement ou un ordonnanceur qui travaille de son côté mérite un couloir ; la spécification BPMN compte les systèmes parmi les usages typiques des couloirs.

Commencez gratuitement — un siège, sans carte bancaire.