Modélisation des processus : quelle méthode pour quoi — et où chaque diagramme s’arrête
La modélisation des processus est la représentation graphique d’un seul déroulement avec des symboles standardisés : déclencheur, tâches, décisions, rôles, résultat. La méthode dépend de l’objectif — diagramme de flux pour un déroulement avec un seul rôle, Swimlane dès que plusieurs rôles sont impliqués, BPMN si le modèle doit ensuite être exécuté par un moteur ou vérifié à l’externe, SIPOC comme étape préparatoire pour le périmètre, analyse de la chaîne de valeur pour les flux de matière et d’information ainsi que les stocks. En pratique, cinq symboles couvrent presque tous les diagrammes : début, tâche, décision, flux, fin. Un modèle décrit toutefois uniquement la structure ; le taux d’arrivée, la dispersion des durées, la capacité et le calendrier ne figurent dans aucune notation. C’est précisément pour cela qu’un modèle achevé comporte six cases de taille égale, sans indiquer laquelle ralentit le déroulement — cela ne peut être établi que par une mesure.

Inhaltsverzeichnis
Un modèle de processus se dessine vite et devient presque aussi vite inutile. Pas parce qu’il serait faux — les cases sont le plus souvent correctes. Mais parce qu’il ne répond pas à la question pour laquelle il a été réalisé. On dessine pour savoir où intervenir. On livre une structure où chaque étape apparaît d’égale importance.
Cet article repose donc sur deux piliers. D’abord le savoir‑faire : quelle méthode sert à quoi, quels symboles sont réellement nécessaires, comment choisir le niveau de détail et dans quel ordre procéder. Ensuite la limite : les quatre informations qui n’apparaissent dans aucune notation et sans lesquelles aucun diagramme n’indique quelle étape freine le déroulement.
Qu’est‑ce que la modélisation de processus ?
La modélisation de processus est la représentation graphique d’un processus métier unique avec des symboles standardisés. Elle répond à quatre questions : qu’est‑ce qui déclenche le déroulement ? Quelles tâches suivent dans quel ordre ? Où il y a des bifurcations et qui décide ? Par quoi se termine‑t‑il ?
Les termes sont couramment confondus, mais ils renvoient à des choses différentes :
| Terme | Niveau | Répond |
|---|---|---|
| Carte des processus | tous les processus d’une entreprise | Quels processus existent ? |
| Modèle de processus | un processus, étape par étape | Comment se déroule ce processus précis ? |
| Documentation de processus | un processus plus règles, formulaires, délais | Comment l’exécuter correctement ? |
| Gestion des processus (BPM) | l’organisation | Qui est responsable, qui mesure et qui améliore les processus ? |
La carte des processus est le plan de la ville, le modèle de processus l’itinéraire pour une rue. Qui confond les deux obtient une carte avec deux cents cases que personne n’ouvrira après la présentation. La façon de créer le niveau supérieur est décrite dans la procédure pour créer une carte des processus.
À quoi sert un modèle :
- Intégration : les nouvelles collaboratrices et les nouveaux collaborateurs voient le déroulement au lieu de se le faire raconter
- Audit et certification : la norme ISO 9001 exige de toute façon cette structure
- Changement de système : ce qu’il faut représenter avant qu’un logiciel ne le prenne en charge
- Transferts : les points où une opération change de responsable
- Exceptions : les cas traités différemment parce qu’ils ne sont documentés nulle part
À quoi il ne sert pas :
- Priorisation. Toutes les cases ont la même taille.
- Estimation des efforts. Une étape peut durer dix minutes ou quatre jours.
- Planification des capacités. La fréquence d’exécution du processus n’apparaît pas dans le diagramme.
As‑is et To‑be : d’abord dessiner ce qui est
La modélisation connaît deux types de modèles. Le modèle As‑is montre l’état réel : comment le déroulement se passe aujourd’hui. Y figurent les détours, les retouches et le fichier Excel qui officieusement existe. Le modèle To‑be montre l’état souhaité après modification.
L’ordre n’est pas négociable : d’abord l’As‑is, ensuite le To‑be. Qui commence par le Soll optimise un déroulement qu’il ne connaît pas.
Entre les deux se situe toutefois une troisième étape que la plupart des guides omettent : mesurer. Un modèle To‑be construit directement à partir de l’As‑is est une liste de souhaits. Il améliore l’étape dont on a le plus parlé en atelier — et ce n’est rarement pas celle qui freine le déroulement. L’étape bruyante est désagréable, celle coûteuse est silencieuse, là où les opérations stagnent.
Règle pratique : un modèle To‑be est créé pour exactement une étape, celle que désignent les mesures. Tout le reste demeure tel quel pour l’instant.
Modélisation de processus : aperçu des méthodes
| Méthode | Ce qu’elle montre | Effort | Adaptée pour |
|---|---|---|---|
| Organigramme (flowchart) | déroulement du début à la fin, bifurcations | faible | un déroulement avec une ou deux fonctions |
| Swimlane | idem, mais par responsabilité en couloirs | faible à moyen | déroulements impliquant plusieurs départements |
| BPMN 2.0 | activités, événements, gateways, messages, pools | élevé | modèles à exécuter ou à faire auditer externement |
| EPK | alternance événement‑fonction | moyen | entreprises disposant déjà d’un parc ARIS |
| eEPK | EPK plus unité organisationnelle et objet d’information | moyen à élevé | obligations de documentation, preuve de responsabilité |
| SIPOC | cinq colonnes : Supplier, Input, Process, Output, Customer | très faible | délimitation avant le modèle proprement dit |
| Analyse flux de valeur | flux matériel et d’information, stocks, temps d’attente | élevé | production et tout ce qui a des stocks visibles |
| Chaîne de valeur | cinq à neuf blocs sans détails intérieurs | très faible | vue d’ensemble pour la direction et les tiers |
| Modèle détaillé | chaque étape avec sous‑processus et exceptions | très élevé | transmission à l’IT, préparation à l’automatisation |
Organigramme (flowchart)
La forme la plus simple : départ, tâches, losanges pour décisions, fin. Tout le monde le comprend sans formation, et c’est là sa valeur. La limite apparaît dès que plusieurs rôles interviennent — alors la responsabilité n’est plus qu’un texte dans la case et les transferts, où le temps se perd, disparaissent.
Swimlane
Le même déroulement, chaque rôle a son couloir. L’avantage n’est pas esthétique, mais pratique : chaque flèche quittant un couloir est un transfert. Les transferts sont les points où les opérations stagnent parce que personne n’est ensuite responsable et que personne n’a encore commencé. Pour des processus inter‑départementaux, la Swimlane est le choix standard.
BPMN 2.0
Le standard international de l’Object Management Group, environ 150 symboles, lisible par machine. Sa force est la précision : un modèle BPMN peut être exporté, vérifié et exécuté par un moteur de processus. Sa faiblesse est la courbe d’apprentissage — côté métier, peu de monde le lit volontiers.
Choisissez BPMN si le modèle va être exécuté, exporté ou audité. Ne l’utilisez pas pour le prestige. Un Swimlane propre, relu par le département, vaut mieux qu’un modèle BPMN correct que personne n’ouvre.
EPK et eEPK
La chaîne de processus pilotée par événements alterne strictement événement ("la demande est arrivée") et fonction ("enregistrer la demande"), reliés par des connecteurs UND, ODER, XOR. Elle est répandue dans les pays germanophones via ARIS. L’EPK étendue ajoute à chaque fonction l’unité organisationnelle et l’objet informationnel — donc qui réalise l’étape et avec quoi.
L’alternance imposée est force et faiblesse : elle oblige à nommer les déclencheurs, mais double souvent la longueur des modèles. Pertinente si l’entreprise a déjà un parc EPK. Pour un modèle neuf sur table rase, il y a rarement motif.
SIPOC
Cinq colonnes : Suppliers, Inputs, Process, Outputs, Customers. Ce n’est pas un diagramme de déroulement mais la délimitation préalable. Rempli en une heure, il clarifie la question qui fait échouer la plupart des modélisations : où commence et où finit le processus ? La partie processus reste volontairement grossière — cinq à sept blocs.
Analyse flux de valeur
Issue du Lean Management. Elle cartographie les flux matériels et d’information et renseigne chaque étape par des chiffres : temps de traitement, temps d’attente, stock, taux d’erreur. C’est la seule méthode classique qui soit intrinsèquement quantitative. Sa maison est la production ; dans les processus administratifs le "stock" est la file d’attente dans la boîte de réception, ce qui rend l’analyse plus lourde mais pas impossible.
Chaîne de valeur et modèle détaillé
Deux extrémités d’une même échelle. La chaîne de valeur montre cinq à neuf blocs sans intérieur — la version pour la direction et les externes. Le modèle détaillé montre chaque étape avec sous‑processus, exceptions et systèmes — la version pour la transmission à l’IT. Les deux sont légitimes. Deviennent inutilisables les diagrammes qui mélangent les deux niveaux : trois cases pour la moitié du service commercial, puis quatorze pour la procédure d’approbation.
Quelle méthode choisir ? Trois questions
- Plusieurs rôles ou départements sont‑ils impliqués ? Oui → Swimlane. Non → Organigramme.
- Le modèle doit‑il être exécuté, exporté ou audité ? Oui → BPMN 2.0.
- S’agit‑il de matière, de stocks ou de temps d’attente ? Oui → Analyse flux de valeur.
Si la délimitation n’est pas claire, commencez par un SIPOC. Le reste relève du goût — et le goût est un mauvais conseiller pour les notations, car le modèle sera lu par des personnes qui ne partagent pas ce goût.
Symboles pour la modélisation de processus
Les symboles usuels viennent de la tradition des organigrammes et sont identiques dans la plupart des outils :
- Ovale (terminateur) : début et fin du processus
- Rectangle : une tâche ou activité
- Losange : une décision, avec sorties étiquetées
- Flèche : la direction du déroulement
- Rectangle aux côtés doubles : un sous‑processus modélisé ailleurs
- Parallélogramme : données en entrée ou sortie
- Rectangle à base ondulée : un document
- Forme en D : un délai, donc un temps de repos
- Rectangle à bord supérieur oblique : saisie manuelle — en pratique l’indicateur le plus fiable d’un rupture de média
En BPMN, les cinq principaux s’appellent : événement de départ (cercle fin), tâche (rectangle à coins arrondis), gateway exclusif (losange avec X), flux de séquence (flèche continue), événement de fin (cercle épais). Ils suffisent pour la plupart des déroulements.
Deux règles valent mieux que toute liste de symboles : chaque losange a des sorties étiquetées — "oui"/"non" ou la condition. Et : chaque chemin se termine. Une branche qui mène nulle part est dans le diagramme un défaut esthétique et dans la réalité l’opération qui ne se termine jamais.
Modéliser un processus : six étapes
Étape 1 : fixer les limites
Deux phrases, par écrit, avant de dessiner : par quoi débute le processus (déclencheur) et par quoi il se termine (résultat) ? À défaut, le modèle s’allonge pendant la création — chaque conversation ajoute quelque chose au début ou à la fin. C’est la cause la plus fréquente pour qu’une modélisation de deux jours prenne trois semaines.
Étape 2 : recueillir les étapes — auprès de celles et ceux qui les exécutent
Pas auprès des responsables. Ils connaissent le déroulement souhaité, et la différence avec le réel est précisément ce que vous recherchez. Cinq questions qui font remonter ce qui n’est écrit dans aucune procédure :
- Qu’est‑ce qui déclenche cette opération chez vous, et comment le voyez‑vous ?
- De quoi avez‑vous besoin pour pouvoir commencer, et d’où cela vient‑il ?
- Sur quoi attendez‑vous le plus souvent ?
- Que faites‑vous quand quelque chose manque ou que le système ne coopère pas ?
- Que faites‑vous ici différemment de ce qui est écrit — et pourquoi ?
Étape 3 : définir la granularité
La règle qui décide du niveau : une étape est un morceau de travail que rôle et système exécutent d’un seul tenant. Si le rôle change, si le système change, ou si le travail est interrompu, commence une nouvelle étape.
Appliquée, cette règle donne pour un processus métier normal huit à quinze étapes. Si vous obtenez cinquante, vous modélisez des frappes clavier. Si vous en obtenez quatre, vous modélisez des départements.
Étape 4 : dessiner
Appliquez la méthode issue des trois questions ci‑dessus, puis un premier passage sans exceptions : le cas normal de gauche à droite. Ensuite seulement ajoutez les bifurcations — et pas toutes. Un processus comprend typiquement un tiers d’exceptions ; modélisez les deux ou trois les plus fréquentes. Le reste est consigné en texte à côté.
Étape 5 : faire relire
Le diagramme final revient aux mêmes personnes que pour l’étape 2, avec une seule question : « Où cela ne correspond‑il pas ? » Pas « Est‑ce que cela convient ? » — tout le monde répondra oui. L’expérience montre que le groupe corrige deux à quatre points, et qu’au moins un d’entre eux n’est pas anodin.
Étape 6 : ajouter des chiffres
L’étape qui manque dans la plupart des guides et sans laquelle le modèle reste décoratif. Quatre informations par étape, au besoin estimées :
- Durée en intervalle : optimiste, typique, pessimiste — pas une moyenne
- Temps d’attente avant : combien de temps l’opération attend‑elle avant qu’on commence
- Fréquence : combien de fois l’étape se produit par mois, avec la part des exceptions
- Rôle et système, plus : rupture de média oui/non
Pourquoi l’intervalle plutôt que la moyenne : qui met des moyennes dans une chaîne de processus sous‑estime systématiquement une fois qu’il y a des portes, boucles ou partages de charge. Le calcul est expliqué dans Votre Excel calcule correctement et se trompe quand même.
Exemple : un processus de devis modélisé
Le modèle suivant vient de notre analyse type AN‑2026‑01. Il est construit, non relevé chez un client — la structure est issue de déroulements types en Mittelstand, les chiffres proviennent d’une simulation sur 500 exécutions. Pour l’essentiel, cela suffit : la différence entre image et mesure est une propriété de la méthode, pas un secret industriel.
En Swimlane, six étapes, quatre rôles :
┌────────────┐ ┌──────────────┐
Service interne ●──│ 01 Demande │ │ 05 Devis │──▶ ●
│ enregistrer│ │ rédiger │
└─────┬──────┘ └──────▲───────┘
│ │
┌─────▼──────┐ │
Conception │ 02 Clarif. │ │
│ technique │ │
└─────┬──────┘ │
│ │
┌─────▼──────┐ ┌───────────┐ non ┌────────┴────┐
Calcul │ 03 Calcu- │──▶│ 04 Valida- │──────────▶│ Demande de │
│ lation │ │ tion ? │ │ précision │
└────────────┘ └─────┬─────┘ └─────────────┘
│ oui
▼
Commercial 06 Envoi & Relance ──▶ ●
Le diagramme est correct. Il indique qui fait quoi dans quel ordre et montre trois ruptures de média (e‑mail, Excel, Word). Ce qu’il n’indique pas : laquelle des six étapes freine le déroulement ?
Graphiquement, les six cases ont la même taille. En calcul, non :
{
"caption": "Charge par rôle en As‑is. Analyse type AN‑2026‑01, construit, 500 exécutions simulées",
"unit": "%",
"data": [
{ "label": "Conception", "value": 118, "tone": "critical" },
{ "label": "Calcul", "value": 86 },
{ "label": "Service interne", "value": 74 },
{ "label": "Direction commerciale", "value": 41 }
]
}
Un rôle dépasse 100 pour cent — il reçoit plus de travail qu’il n’en peut traiter, et devant son étape s’accumule une file d’attente. Le modèle représente ce rôle par un couloir parmi quatre, au même niveau que la direction commerciale à 41 pour cent de charge.
La durée de parcours se comporte en conséquence. Ce n’est pas un nombre mais un intervalle :
[
{ "label": "Temps de parcours P10", "value": "1,8", "unit": "Jours", "note": "le cas rapide" },
{ "label": "Temps de parcours P50", "value": "4,6", "unit": "Jours", "note": "le cas typique" },
{ "label": "Temps de parcours P90", "value": "11,2", "unit": "Jours", "tone": "critical", "note": "ce qui serait annoncable" },
{ "label": "Exécutions au‑delà de la capacité", "value": "34", "unit": "%", "tone": "critical" }
]
Entre le cas typique et le cas annoncable il y a un facteur deux. Dans le diagramme rien n’en montre — et cela vaut pour tout diagramme, quelle que soit la notation. L’analyse complète avant‑après est disponible sous Le processus de devis qui bloque en conception.
Les quatre informations qui n’apparaissent dans aucune notation
Pourquoi aucun modèle n’indique l’engorgement tient à une raison simple : les notations décrivent la structure, pas la charge. Pour calculer il manque quatre grandeurs que ni BPMN, ni EPK, ni une Swimlane ne prévoient :
- Taux d’arrivée — à quelle fréquence le processus est déclenché et avec quelle irrégularité. Quarante opérations par semaine ce n’est pas la même chose si trente arrivent le lundi.
- Dispersion des durées — pas "deux heures" mais "entre une et quatre heures, généralement deux". Sans dispersion il n’y a pas de file d’attente et le calcul est trop optimiste.
- Capacité — combien de personnes peuvent réaliser l’étape et quel pourcentage de leur temps. Un couloir peut représenter une personne ou huit.
- Calendrier — heures de travail, congés, validations qui n’ont lieu que le mardi. Un déroulement qui prend trois heures en calcul prend néanmoins une journée s’il traverse la nuit.
Ces quatre informations se recueillent le mieux pendant la modélisation, à l’étape 6 ci‑dessus. Elles sont le passage du dessin au calcul — et le point où se décide si le modèle devient une action ou un tableau décoratif.
Erreurs fréquentes
-
Trop fin. Deux cents cases pour un processus. Remède : la règle de l’étape 3 — rôle, système, d’un seul tenant.
-
Le Soll dessiné au lieu de l’Ist. On le reconnaît à l’absence de retouches dans le modèle. Dans les déroulements réels il y en a toujours.
-
Avoir uniquement interrogé les cadres. Cela donne invariablement la procédure officielle. La différence avec le réel est la valeur de l’exercice.
-
Choisir la notation par prestige. BPMN parce que ça a l’air professionnel ; personne ne le relit — et un modèle non relu est une assertion.
-
Ignorer les exceptions. Le cas normal est dessiné ; trente pour cent des opérations se déroulent autrement. Deux à trois exceptions devraient figurer dans l’image, le reste en texte.
-
Pas de chiffres. Le modèle est fini, la question « que faisons‑nous d’abord ? » reste une question d’opinion.
-
Pas de propriétaire, pas d’occasion de mise à jour. Un modèle sans personne responsable et sans événement déclencheur d’actualisation — migration, réorganisation, revue annuelle — est faux au bout de douze mois sans que personne s’en aperçoive.
Avec quoi modéliser ?
Pour une première version : papier, tableau blanc, post‑it. Les post‑it se déplacent, et un diagramme propre incite moins à la contradiction. Pour la mise au net, les outils de diagramme habituels suffisent — pour un processus isolé l’outil est la plus petite des questions. Lorsque des modèles sont maintenus des années ou exécutés, des suites BPM avec référentiel, versioning et approbation entrent en jeu ; c’est une décision d’achat qui a son propre coût et qui vaut rarement la peine sous un nombre à deux chiffres de processus maintenus.
Si l’on saisit pendant l’atelier au lieu de dessiner
Un cas particulier mérite d’être mentionné car il explique la raison la plus courante d’abandon : en atelier personne ne dessine les cases. Qui dessine à côté ne suit pas, et qui prend des notes retranscrit après — ou pas. Notre application de bureau FlowVisual propose pour cela une ligne de capture : une ligne par étape, Entrée pour la suivante, la chaîne se relie automatiquement.
La demande arrive
Calculer le devis @Commercial 20-40min
Validation @Chef 5min ?>10k
Retouche @Commercial !informations manquantes
Quatre marqueurs, pas plus de grammaire : @ la fonction, un intervalle la durée, ? la condition, ! le point douloureux. Tout est facultatif — une ligne nue est valide, et ce que personne n’a dit reste ouvert au lieu d’apparaître comme une valeur nulle inventée dans le modèle. Qui préfère ne pas partir de rien ouvre un des six modèles fournis (Devis, Validation facture, Réclamation, Onboarding, Service desk, Traitement commande) ou importe des procédures existantes ; chaque étape proposée porte une citation littérale et un fichier et est acceptée individuellement.
L’intérêt n’est pas le dessin mais ce qu’il est possible de faire ensuite : rôle, durée et fréquence présents dès la ligne permettent au diagramme fini d’avoir déjà les quatre informations du chapitre précédent — et de pouvoir être calculé plutôt que seulement regardé. Comment cela se déroule en un passage est expliqué dans la procédure, section « Si le processus n’existe pas encore ».
Plus important que l’outil : le modèle doit résider là où les personnes travaillent déjà. Un diagramme dans un outil inacces‑sible pour le métier ne sera pas maintenu — on l’imprimera et il deviendra obsolète sur le mur.
Conclusion
La modélisation de processus est un savoir‑faire avec des règles claires : d’abord les limites, parler avec les exécutants, choisir une notation adaptée au but, une étape par rôle et système, doser les exceptions, faire relire. Qui suit cela obtient en un à deux jours un modèle solide.
Ce que le modèle ne donne pas, il ne le donnera pas davantage avec une meilleure notation : l’ordre dans lequel intervenir. Pour cela il faut des chiffres dans les cases et un calcul — taux d’arrivée, dispersion, capacité, calendrier. Le diagramme est la condition nécessaire. Il n’est pas la réponse.
Étapes suivantes :
- Rédigez en deux phrases le déclencheur et le résultat
- Tenez deux à trois entretiens avec les exécutants, en posant les cinq questions ci‑dessus
- Dessinez en Swimlane, huit à quinze étapes
- Faites relire avec la question « Où cela ne correspond‑il pas ? »
- Pour chaque étape, ajoutez intervalle de durée, temps d’attente, fréquence, rupture de média
- Ensuite seulement décidez où intervenir
Pour aller plus loin :
- Créer une carte des processus — le niveau au‑dessus du modèle unique
- Lay bare : chiffrer l’As‑is — la deuxième étape de la méthode Flowrefy, donc précisément les chiffres dans les cases
- Analyse de processus — comment transformer le modèle en une affirmation solide
Pour recalculer : Avec le calculateur de coûts de processus gratuit, vous évaluez en quelques minutes ce que coûte le déroulement modélisé par mois — y compris le potentiel d’économie et la ventilation étape par étape.