L6 — Les Processus (BPMN) : l'action opérationnelle

« Processes are the invisible engines of the organization. » — Michael Hammer & James Champy, Reengineering the Corporation (1993)

« Un bon processus n’est pas celui qui est bien dessiné. C’est celui qui transforme la décision en exécution. »

Vidéo d’introduction

L6 — Les Processus BPMN

Télécharger cette leçon en PDF

Le tunnel d’achat que personne ne comprenait

En 2018, la DSI de Discount Voyages avait un problème de processus qu’elle n’arrivait pas à résoudre. Le tunnel d’achat en ligne — du clic sur « Réserver » à la confirmation de réservation — était constitué de douze étapes enchaînées par six systèmes différents. Chaque étape faisait l’objet d’une documentation PowerPoint locale, d’un wiki Confluence dépassé, et parfois d’un schéma Visio qui n’avait plus rien à voir avec la réalité. Les incidents de production se multipliaient. Le service client recevait des appels de clients bloqués à des étapes différentes. Personne ne savait expliquer pourquoi.

Camille, l’architecte d’entreprise, est appelée. Elle commence par un geste inhabituel : ne pas regarder la documentation, mais interviewer les opérateurs. Elle passe une semaine avec l’équipe du service client, deux jours avec les développeurs du site web, une demi-journée avec la comptabilité. Elle reconstitue le tunnel d’achat tel qu’il est réellement vécu — pas tel qu’il est documenté. Elle découvre quatre choses :

Le tunnel documenté n’existe pas. Les étapes documentées dans les PowerPoint ne correspondent plus au comportement réel des systèmes depuis la dernière mise à jour du site.
Les étapes implicites sont les plus longues. Trois étapes cruciales ne sont nulle part documentées — la validation du panier par l’anti-fraude, la mise en attente du paiement 3D Secure, la double-saisie comptable post-réservation.
Le schéma qu’on dessine est un acte politique. Chaque service veut que son étape apparaisse comme étant la plus rapide, la plus fiable, la plus moderne. Dessiner le vrai processus, c’est nommer les responsabilités qui fâchent.
Le BPMN est le bon outil, mais pas pour la raison qu’on croit. Le BPMN n’est pas fait pour « documenter ». Il est fait pour rendre le flux discutable — pas seulement visible.

Camille passe six semaines à produire un BPMN du tunnel d’achat, en étroite collaboration avec les six services concernés. Le schéma final fait sept pages. Il remplace les douze PowerPoint locaux, les trois wikis Confluence, les cinq Visio obsolètes. Mieux : il devient la référence pour les comités de gouvernance, les revues d’incident, les nouveaux projets d’évolution.

C’est ce que cette leçon cherche à vous transmettre : comment utiliser BPMN pour rendre les flux discutables, et pas seulement visibles.

Le BPMN qui suit modélise le tunnel d’achat de Discount Voyages tel que Camille l’a reconstitué — 5 activités, 4泳lane, 1 passerelle de décision. Cette vue macro est volontairement épurée pour rester discutable :

Premier principe — BPMN ≠ UML ≠ organigramme : chaque outil a sa fonction

L’un des pièges les plus coûteux consiste à utiliser un mauvais outil pour modéliser les processus. Cette erreur produit des documents hybrides qui ne servent personne, et qui sont abandonnés au bout de six mois.

Le choix de l’outil de modélisation de processus n’est pas anodin. Quatre grandes familles coexistent, avec des fonctions différentes :

L’organigramme — représente une structure hiérarchique de pouvoir. Utile pour les organigrammes RH, pas pour les processus.
UML Activity Diagram — représente un comportement algorithmique. Précis, formel, adapté aux développeurs. Rébarbatif pour les opérationnels.
BPMN 2.0 (OMG) — représente un flux métier avec une grammaire normalisée. Précis pour les développeurs, lisible pour les opérationnels. Conçu pour l’exécution (BPMN est aussi un format exécutable par les moteurs de workflow).
Cartographie des processus SIPOC (Supplier-Input-Process-Output-Customer) — représente les interfaces d’un processus. Vue macroscopique, pas de flux détaillé.

La contrefaçon classique consiste à dessiner un organigramme en prétendant que c’est un processus, ou à dessiner un diagramme d’activité UML en prétendant que c’est un BPMN. La parade est de tester le document final par deux questions :

« Un opérationnel non-technique peut-il lire ce document et pointer du doigt son étape ? » — si non, c’est trop formel pour un processus.
« Un développeur peut-il extraire de ce document les conditions de chaque transition ? » — si non, c’est trop vague pour un processus.

BPMN est l’outil qui répond aux deux questions par l’affirmative. C’est pour cela qu’il s’est imposé comme standard international depuis 2005, maintenu par l’Object Management Group (OMG) et promu par l’OCEB (Object Management Group Certified Expert in BPM).

Et toi ? Sur ton dernier processus modélisé, as-tu utilisé un organigramme, un diagramme UML, un BPMN, ou autre chose ? Le document final était-il lisible par les opérationnels ET exploitable par les développeurs ?

Deuxième principe — Macro-processus dynamique vs domaine fonctionnel stable

Le Capability Map (L5) montre ce que l’organisation doit savoir faire. Les processus montrent comment elle le fait. Ce sont deux objets différents, et il faut savoir les articuler.

L’Open Group distingue clairement les deux dans ses guides :

Le Capability Map est stable dans le temps — une mutuelle « sait facturer » depuis 1948 et continuera dans vingt ans. Le Capability Map est révisé annuellement.
Les processus sont dynamiques — ils changent à chaque évolution des outils, des réglementations, des pratiques commerciales. Les processus sont révisés en continu.

Cette distinction a une implication directe : il ne faut pas chercher à cartographier exhaustivement tous les processus. Le Capability Map est exhaustif ; les processus sont échantillonnés. On ne modélise en BPMN que les processus qui font l’objet d’une décision, d’une réorganisation, ou d’une difficulté opérationnelle. Les autres processus restent dans la mémoire collective.

La contrefaçon classique consiste à produire un « référentiel des processus » exhaustif de 200 processus documentés en BPMN, qui n’est jamais utilisé. C’est l’équivalent, en processus, d’une cartographie applicative exhaustive qu’on ne consulte jamais. La parade est de ne modéliser en BPMN que les processus en jeu dans une décision, et de re-modéliser quand la décision évolue.

Et toi ? Combien de processus as-tu modélisés en BPMN sur ton dernier projet ? Ce nombre est-il cohérent avec le nombre de décisions qui ont été prises sur la base de cette modélisation ?

Troisième principe — Ruthless minimization : ne modéliser que ce qui sert la décision

La tentation du modélisateur est de tout représenter. La règle d’or en BPMN est inverse : ne modéliser que ce qui sert la décision en cours.

Cette règle — qu’on peut appeler ruthless minimization — s’applique à trois niveaux :

Niveau activité — ne pas détailler les sous-étapes d’une activité. Une activité « Vérifier le dossier client » est une boîte noire ; on ne dessine pas ses trois sous-étapes. Si le détail est utile à la décision, on le met dans une泳道 (swimlane) séparée.
Niveau泳道 — ne pas multiplier les泳道. Au-delà de cinq ou六 participants, le BPMN devient illisible. Si le processus en compte plus, on découpe en sous-processus.
Niveau exception — ne pas représenter toutes les exceptions. On représente l’exception qui est l’objet de la décision, pas celles qui sont déjà gérées par les outils (gestion d’erreur automatique, retry, etc.).

La contrefaçon classique consiste à dessiner un BPMN qui « montre tout » — toutes les étapes, tous les participants, toutes les exceptions. Le résultat est un schéma de trois mètres de large, illisible, qui décourage toute discussion. La parade est de demander avant chaque boîte ajoutée : « cette information est-elle nécessaire à la décision en cours ? » Si non, on retire la boîte.

Pour Discount Voyages, Camille a modélisé le tunnel d’achat avec un seul BPMN principal (sept pages, niveau activité), puis trois BPMN de sous-processus (un par sous-processus critique : paiement 3D Secure, validation anti-fraude, double-saisie comptable). Le tout est lisible. Le tout est discutable.

Et toi ? Sur ton dernier BPMN, combien d’activités as-tu représentées ? Combien de泳lane ? Combien d’exceptions ? Ces nombres sont-ils cohérents avec l’objectif de la décision qui a conduit à modéliser ?

Quatrième principe — Top-down d’abord, bottom-up ciblé ensuite

L’ordre de modélisation compte. Modéliser d’abord les processus de bout en bout, puis zoomer sur les sous-processus critiques — pas l’inverse.

L’OCEB (Object Management Group Certified Expert in BPM) recommande un ordre de modélisation en deux passes :

Passe 1 — Top-down — identifier les trois à cinq processus clés de l’organisation. Pour chacun, dessiner un BPMN de niveau macro (5 à 15 activités). Ce BPMN sert à la communication exécutive, à l’arbitrage des priorités, à la revue annuelle.
Passe 2 — Bottom-up ciblé — pour les processus qui font l’objet d’une décision ou d’une réorganisation, zoomer. Dessiner un BPMN détaillé (20 à 50 activités), avec les泳lane, les exceptions, les indicateurs.

Cette double passe évite deux travers :

Le travers top-down-only — un BPMN macro qui se contente de dire « il y a un processus de vente » sans jamais entrer dans le détail. Décision impossible.
Le travers bottom-up-only — un BPMN détaillé d’un sous-processus sans vision d’ensemble. On ne sait pas si ce sous-processus est critique, négligeable, ou redondant.

Pour Discount Voyages, Camille a d’abord modélisé les cinq processus clés (réservation, paiement, facturation, service client, marketing) en BPMN macro (5-10 activités chacun). Puis elle a zoomé sur le tunnel d’achat en BPMN détaillé, parce que c’était l’objet de la décision. Les quatre autres processus clés restent au niveau macro.

Et toi ? Sur ton dernier projet de modélisation, as-tu démarré top-down puis zoomé, ou as-tu directement dessiné le détail d’un sous-processus ? Quel a été l’usage réel de chacun des BPMN produits ?

Cinquième principe — Le BPMN comme contrat entre métier et IT

Le BPMN n’est pas un document technique, ni un document métier. C’est un contrat entre les deux — un acte commun qui engage les deux parties sur la même compréhension du flux.

La fonction politique du BPMN est aussi importante que sa fonction technique. Quand un BPMN est validé conjointement par un opérationnel et un développeur, les deux parties s’engagent sur :

Les activités — qui fait quoi, dans quel ordre
Les transitions — sous quelles conditions le flux passe d’une activité à l’autre
Les exceptions — que se passe-t-il si l’activité échoue, si l’entrée n’arrive pas, si le délai est dépassé
Les indicateurs — comment mesure-t-on la performance du processus

Cet engagement est réversible : on peut modifier le BPMN si les conditions changent, mais chaque modification est une décision documentée. C’est ce qui distingue un BPMN de un document Word oublié.

La contrefaçon classique consiste à produire un BPMN technique sans validation opérationnelle — un schéma que personne ne reconnaît comme étant le sien. Le BPMN reste sans usage, et finit par être abandonné. La parade est d’associer systématiquement un opérationnel à chaque modélisation, et de ne jamais figer un BPMN sans signature opérationnelle.

Pour Discount Voyages, Camille a tenu six ateliers d’une demi-journée chacun, un par service concerné. Chaque atelier a abouti à une version signée du BPMN. C’est cette signature qui a rendu le BPMN opérationnel — pas le schéma lui-même.

Et toi ? Sur ton dernier BPMN, qui l’a validé ? Un développeur seul, un opérationnel seul, ou les deux ensemble ? Combien de fois le BPMN a-t-il été consulté pour une vraie décision depuis sa validation ?

Application — Mon BPMN

À produire séance tenante. Un seul processus réel de ton organisation, modélisé selon les cinq principes de cette leçon.

Choisir le processus — un processus qui fait l’objet d’une décision, d’une réorganisation, ou d’une difficulté opérationnelle.
Dessiner le BPMN macro — 5 à 15 activités, 3 à 5泳lane. Niveau d’abstraction permettant la discussion exécutive.
Identifier les sous-processus critiques — sur les 5 à 15 activités, lesquelles font l’objet d’une décision ou d’une difficulté ? (Une à trois activités maximum.)
Dessiner le BPMN détaillé du sous-processus — pour chaque sous-processus critique, 20 à 50 activités, avec exceptions et indicateurs.
Valider avec un opérationnel — un atelier d’une demi-journée, aboutissant à une signature commune.
Diffuser le BPMN signé — wiki d’architecture, comité de gouvernance, base de connaissance.

Ce BPMN est ton premier livrable de processus. Il sert de contrat entre ton service et les services partenaires.

Encadré Au lecteur / À l’animateur

Question d’ouverture : « Sur ton dernier processus critique, as-tu utilisé un organigramme, un diagramme UML, un BPMN, ou autre chose ? »

Profils à observer :

Le modélisateur exhaustif. Veut tout représenter, produit des schémas illisibles. Question : « Cette activité est-elle nécessaire à la décision ? »
Le formaliste UML. Produit des schémas précis que personne ne lit. Question : « Un opérationnel peut-il pointer du doigt son étape ? »
Le politique qui veut un schéma qui arrange. Évite de représenter les responsabilités qui fâchent. Question : « Qui est responsable de cette activité sur ton BPMN ? »
L’isolé qui modélise seul. N’associe aucun opérationnel. Produit des schémas sans usage. Question : « Qui a signé ton dernier BPMN ? »

Pièges d’animation :

Ne pas laisser la discussion dériver vers les outils (Visio, Bizagi, Camunda, etc.). Rappeler que l’outil est secondaire, le standard BPMN est central.
Ne pas confondre BPMN et organigramme. Un processus décrit un flux, pas une hiérarchie.

Cas pratique — Optimisation du processus d’admission patient (Hôpital)

Contexte sectoriel : hôpital régional public, 1 200 lits, 280 000 admissions par an, 4 500 professionnels (médicaux, soignants, administratifs). Le processus d’admission est critique : il conditionne la qualité de prise en charge, la facturation, la sécurité des soins (identitovigilance).

Diagnostic de l’existant. Le processus actuel souffre de 4,5 % d’erreurs d’identification, avec un coût de traitement de 80 € par dossier erroné. L’absence de contrats numérisés et les recherches manuelles permanentes paralysent l’accueil. Le délai médian entre l’arrivée du patient et la disponibilité du dossier administratif est de 45 minutes, dont 30 minutes passées à rechercher des informations dans des classeurs physiques ou à reconstituer un identifiant à partir de documents incomplets.

Parties prenantes :

Chef de service des Admissions (décisionnaire) — porte la responsabilité de la conformité et de la qualité.
Responsable Qualité (décisionnaire) — valide les indicateurs et pilote les plans d’amélioration.
Secrétaires médicales et opérateurs d’admissions (utilisateurs finaux critiques) — leur adhésion conditionne l’efficacité. L’ergonomie de l’interface métier est non négociable.
Service Médical (consommateur du processus) — besoin d’un dossier patient fiable avant la consultation.
Régulateur Externe (ARS, CNIL) — conformité RGPD et identitovigilance.

Démarche de modélisation BPMN 2.0.

L’atelier exige une modélisation rigoureuse, structurée par Pools et Lanes :

Pools (Piscines) : distinguer le Patient, l’Hôpital et le Régulateur Externe (pour la conformité RGPD). Cette séparation rend visibles les frontières de responsabilité.
Lanes (Couloirs) dans la Pool « Hôpital » : séparer l’Accueil, le Service Médical et la Facturation. Chaque lane représente un acteur organisationnel.

Flux TO-BE modélisé :

Le patient arrive à l’accueil, présente sa carte Vitale et une pièce d’identité.
Lecture automatique de la carte Vitale via un terminal NFC (suppression de la saisie manuelle).
Croisement avec le référentiel d’identitovigilance national (INS — Identifiant National de Santé) via les standards HL7/FHIR.
Si identité reconnue : dossier pré-rempli, validation en un clic. Si identité non reconnue : workflow de création avec vérification croisée.
Transmission du dossier au Service Médical en moins de 5 minutes (vs 30 minutes actuellement).
Génération automatique des données de facturation à partir du dossier validé.

Indicateurs cibles :

Réduction du temps d’attente de 45 min à moins de 10 min.
Taux d’erreur d’identification ramené de 4,5 % à moins de 1 %.
Coût par dossier erroné divisé par 5.

Erreur type à éviter. Modéliser les écrans du logiciel au lieu du flux logique du patient. L’architecte modélise le métier, pas l’interface. Un BPMN qui décrit « cliquer sur le bouton X » est un organigramme applicatif déguisé.

Livrables attendus de l’apprenant :

Un BPMN 2.0 du processus d’admission avec trois pools et au moins trois lanes.
Une cartographie des risques avec parades (perte de pièce d’identité, patient inconscient, homonymie).
Un plan d’amélioration continue avec trois KPIs mesurables.

Critères d’évaluation : le BPMN est validé si l’apprenant (1) respecte les Pools/Lanes par acteur organisationnel, (2) introduit les standards HL7/FHIR, (3) propose des indicateurs chiffrés atteignables en 12 mois.

Ce que la leçon 7 vous demande

Ouvrez votre dossier d’architecte à la page suivante. Préparez :

Un BPMN macro d’un processus clé, validé par un opérationnel.
Un BPMN détaillé d’un sous-processus critique, signé conjointement.
Une liste des 3 à 5 processus clés de ton organisation, avec leur statut (modélisé / à modéliser / non applicable).

Sources de cette leçon : OMG, Business Process Model and Notation (BPMN) Version 2.0 (2011) · OCEB 2, Fundamental Level · Hammer & Champy, Reengineering the Corporation (1993) · Cas Discount Voyages (anonymisé)

Leçon suivante : L7 — L’Architecture des Données : la pyramide DAMA.