Dans beaucoup d’organisations, le même constat revient en boucle : le processus “sur le papier” semble cohérent, et pourtant le process réel patine. Retards, reprises, exceptions, frictions entre équipes… et cette impression désagréable de piloter à l’aveugle parce que les données sont éparpillées entre plusieurs systèmes. Le process mining s’est imposé précisément pour réduire ce décalage : reconstruire ce qui se passe vraiment, à partir des traces laissées par les événements, puis suivre des indicateurs concrets pour améliorer l’efficacité dans la durée. Et oui, cela commence parfois par une surprise un peu gênante : découvrir que “l’étape la plus lente” n’est pas celle que tout le monde pointait en réunion.
Vous sentez que « ça coince », mais où exactement ?
Un projet de mining démarre rarement par curiosité. Il démarre parce que quelque chose résiste. Sur des missions d’analyse process/data menées en contexte ERP, CRM et ITSM, trois signaux reviennent, presque mécaniquement :
1) Des retards récurrents : le processus met “trop longtemps”, sans que personne ne sache isoler l’étape qui bloque vraiment (attente, validation, transfert, stock, facturation…).
2) Trop d’exceptions : le process standard existe, mais il devient minoritaire. Les équipes gèrent des cas particuliers à la pelle : plus de charge, plus de rework, moins d’efficacité.
3) Un manque de visibilité entre systèmes et équipes : un ERP d’un côté, un CRM de l’autre, un outil tickets, un workflow… et au milieu, des informations qui se perdent.
La question utile, avant même de parler d’outil : s’agit-il d’un sujet de processus… ou d’un sujet de données ? Parce que le mining ne compense pas une traçabilité inexistante. Il la met à nu. Et quand les traces manquent, la discussion se déplace : “Pourquoi n’a-t-on aucun événement sur cette validation ?” devient plus important que “Quel dashboard veut-on ?”.
Process mining, en mots simples (et sans jargon)
Le process mining, c’est une méthode qui consiste à reconstruire un process réel à partir des événements enregistrés par les systèmes : ERP, CRM, ITSM, outils de workflow, logs applicatifs, etc. Concrètement, on prend des données horodatées, on relie les étapes d’un même dossier (commande, ticket, facture…), puis on visualise le processus tel qu’il s’exécute réellement.
À distinguer d’une cartographie “déclarative” en atelier : utile, mais souvent influencée par la théorie, les habitudes, ou ce que le métier pense faire. Le mining ramène une base factuelle : les traces. Et cette base, quand elle est discutée calmement, fait gagner un temps fou sur les arbitrages.
Ce que le process mining n’est pas (ça évite des malentendus)
Le process mining n’est pas :
- Un outil magique d’automatisation à lui seul : il éclaire, il ne “répare” pas automatiquement.
- Un audit “one shot” : utile en diagnostic, mais sa vraie valeur vient avec le suivi.
- Un sujet réservé à l’IT : le métier est au centre, sinon les résultats restent théoriques.
Les attentes réalistes : découvrir le process réel, vérifier la conformité, prioriser des actions d’amélioration, et suivre des KPI de manière continue. Pas plus. Mais déjà beaucoup. À ce titre, un piège classique consiste à attendre une “vérité unique” : selon la source (ERP vs outil satellite), un même dossier peut raconter une histoire légèrement différente. C’est normal. Il faut trancher, documenter, avancer.
Pourquoi maintenant : des systèmes partout, des données aussi… mais dispersées
Dans l’entreprise moderne, un même processus traverse plusieurs systèmes. Un dossier naît dans un canal (web, mail, téléphone), passe par un outil, puis un autre, change de main, parfois de pays, parfois d’équipe. Chaque relais produit des informations, mais rarement au même endroit. Et les données ne sont pas toujours alignées : libellés différents, timestamps incohérents, étapes manquantes.
Le mining est devenu pertinent parce qu’il exploite cette réalité multi-outils, au lieu de la subir. À condition de poser une question simple : où sont les événements, qui les produit, et à quel moment ? Sans cette cartographie des traces (pas des idées), l’analyse part vite en spirale.
Avant de choisir un outil, clarifiez le cas d’usage
Sur le terrain, beaucoup d’initiatives échouent pour une raison bête : un objectif flou. Avant les outils (même si le marché est riche), une mini-grille de cadrage évite de partir dans tous les sens :
- Quel processus : order-to-cash, procure-to-pay, service client, onboarding…
- Quel problème : délais, coûts, non-conformité, surcharge, rework.
- Quel périmètre : entité, pays, canal, gamme produit.
- Quelle décision attendue : supprimer une étape, changer une règle, redéfinir un circuit, ajuster des SLA…
Un bon cadrage, c’est un process et une question. Pas dix. Et si la question n’implique aucune décision possible, mieux vaut la reformuler tout de suite. Sinon, on mesure pour mesurer, ce qui épuise les équipes.
Les données dont vous avez vraiment besoin (et celles qu’on croit nécessaires)
Pour démarrer, le trio minimal est connu, mais souvent sous-estimé :
- Case id : l’identifiant du dossier (commande, facture, ticket…).
- Activité : l’étape réalisée.
- Timestamp : la date/heure de l’événement.
Ensuite, les “plus” qui donnent de la valeur : ressource (équipe/rôle), canal, montant, type clients, priorité, statut, catégorie… Ces attributs servent à segmenter le processus et à transformer des informations générales en décisions métier actionnables.
Côté systèmes, les sources typiques sont l’ERP, le CRM, l’ITSM, les outils bpm/workflow, et les logs applicatifs. La difficulté n’est pas de “tout prendre”, mais de prendre ce qui explique le process. Trop de champs, et l’équipe passe ses semaines à nettoyer au lieu d’analyser. Pas assez, et on ne comprend pas les variantes.
Qualité des données : la marche que tout le monde sous-estime
Les meilleurs modèles de mining ne survivront pas à des données bancales. Dans la pratique, les questions qui font gagner du temps sont très concrètes :
- Les timestamps sont-ils fiables (création réelle vs mise à jour tardive) ?
- Y a-t-il des événements manquants (étapes non tracées) ?
- Des doublons (même action écrite deux fois) ?
- Des libellés incohérents (validation / approuvé / ok) ?
“Garbage in, garbage out”, oui. Pourtant, ce n’est pas une fatalité : documenter les règles de nettoyage et les hypothèses rend l’analyse défendable, et donc utile à l’entreprise. Dans la pratique, une petite feuille de “dictionnaire des événements” évite des mois de discussions : qu’appelle-t-on “clôturé” ? À partir de quel statut un dossier est-il réellement en attente client ? Ce sont des détails. Ils font tout.
Méthode d’implémentation : un chemin en 8 étapes (pratique, pas théorique)
Après plusieurs missions côté entreprise (en tant que consultant et analyste process/data), une constante se vérifie : la réussite dépend moins de la technique que de l’enchaînement. Voici un déroulé robuste, pensé pour passer de l’idée à une routine de pilotage du processus. Pas d’effet “usine à gaz”. Juste des étapes qui s’emboîtent.
Étape 1 : choisir un processus “pilotable”
Critères simples : volume suffisant, impacts visibles, sponsor identifié, données accessibles, horizon de valeur court. Un process trop rare ou trop politique devient un piège. Et quand le process touche dix directions, les réunions grossissent… tandis que les décisions, elles, rétrécissent.
Étape 2 : constituer le duo (métier + data/IT) et poser les règles
Qui valide la définition des étapes ? Qui arbitre quand deux systèmes racontent une histoire différente ? Qui documente ? Sans gouvernance, les informations se contredisent et les équipes perdent confiance. Une règle simple aide : une décision = un responsable nommé, même si la décision est “on ne tranche pas, on accepte deux versions”.
Étape 3 : identifier les événements et les extraire depuis les systèmes
Inventaire des sources, extraction, fréquence (batch, quotidien), sécurité, anonymisation si nécessaire. Point d’attention classique : relier plusieurs systèmes au même case id. Parfois, il n’existe pas tel quel : il faut le construire via des clés de rapprochement. Et c’est souvent là que se cache la difficulté, pas dans l’algorithme.
Étape 4 : construire le log d’événements (le vrai cœur du mining)
Normalisation des libellés, gestion des statuts, contrôle des timestamps, règles d’ordre si des événements arrivent “à égalité”. Documenter les règles de fusion et les exclusions : c’est ce qui rend le process lisible et réutilisable. Sur un projet, une erreur fréquente a été d’agréger “modification” et “validation” sous le même verbe. Résultat : un process qui semblait tourner en rond… alors que c’était juste un mauvais dictionnaire.
Étape 5 : découvrir le processus réel et le comparer au process “attendu”
Découverte automatique, variantes, boucles, chemins rares. Puis comparaison avec un modèle de référence (par exemple un modèle bpm existant, ou des règles internes). L’objectif n’est pas de “piéger” : c’est de comprendre où le processus diverge, et pourquoi. Et parfois, la divergence est saine : elle correspond à un cas client particulier, à une contrainte légale, à une opération manuelle assumée.
Étape 6 : diagnostiquer : où sont les goulots et pourquoi
Analyse des temps d’attente, des temps de traitement, des transferts, des retours arrière. Segmentation par produit, canal, région, typologie clients. Sur le terrain, c’est là que les débats changent de nature : moins d’opinions, plus de faits. Et surtout, des faits situés : “Le délai explose pour les dossiers X en fin de mois” n’est pas la même discussion que “on est lents”.
Étape 7 : décider et agir (sinon, ça reste un joli tableau)
Transformer les résultats en actions : ajuster une règle de validation, supprimer une étape inutile, clarifier une responsabilité, prioriser une automatisation ciblée, former sur un point précis. Un bon mining mène à une décision, pas à une collection de graphes. Et la décision doit être testable : si une règle change, quels KPI bougent, et dans quel délai ?
Étape 8 : industrialiser : passer du projet à la routine
Tableaux de bord, alertes, revues mensuelles, ownership, gouvernance. Question simple, rarement posée assez tôt : qui “tient” le processus une fois l’analyse terminée ? Sans propriétaire, l’amélioration retombe. Et les traces, elles, continuent d’arriver… mais personne ne les lit.
KPIs à suivre : les familles qui parlent aux équipes
Les KPI efficaces sont ceux qui déclenchent une discussion utile entre métier et data/IT, et qui relient le process à une décision. En pratique, cinq familles couvrent l’essentiel : temps, qualité, conformité, charge, variabilité. Mieux vaut cinq indicateurs bien définis que vingt “à peu près”.
KPIs de temps : là où l’inefficacité se cache souvent
- Lead time de bout en bout (durée d’un dossier).
- Temps d’attente vs temps de traitement.
- Temps entre deux activités clés (handover delay).
- Respect des SLA / OLA.
Conseil terrain : toujours regarder médiane + percentiles (P90/P95), pas seulement la moyenne. La moyenne masque la “long tail”, ces cas rares qui consomment énormément de ressources. Et si un KPI n’est pas stable d’un mois à l’autre, la première question est souvent… “a-t-on changé une règle de calcul ?”.
KPIs de qualité : retours arrière, reprises, exceptions
- Taux de reprises (rework rate).
- Nombre moyen de boucles par dossier.
- Part du “happy path” vs non standard.
- First time right (du premier coup).
KPIs de conformité : suivre les écarts sans faire la police
- Taux de conformité au chemin attendu.
- Activités interdites ou manquantes.
- Séquences non respectées (validation après exécution, par exemple).
- Contrôles obligatoires non effectués.
Utilité : audit, risques, réglementaire, mais aussi qualité interne. Pourtant, si la conformité devient un outil de sanction, le process “s’adapte” et la qualité des données se dégrade. Il faut donc cadrer l’usage : amélioration collective, pas chasse aux fautes.
KPIs de charge et de ressources : comprendre qui fait quoi, et quand
- Volume de cas par période.
- Charge par équipe / rôle.
- Nombre de transferts (handover count).
- Encours (work in progress).
Nuance importante : ces indicateurs sont pertinents au niveau équipe, rarement au niveau individuel. Sinon, l’entreprise obtient de la défiance au lieu d’amélioration. Dans la pratique, une équipe qui se sent observée “à la loupe” change ses comportements de saisie, et les logs perdent en valeur.
KPIs de variabilité : le révélateur des process instables
- Nombre de variantes actives.
- Poids des 5 variantes principales.
- Taux de cas “long tail”.
- Dispersion des durées (écart-type, percentiles).
KPIs orientés business : relier process et résultats
Selon le contexte : coût de traitement, recouvrement, pénalités, satisfaction, churn, taux de conversion. Attention toutefois : corrélation n’est pas causalité. Une variante de processus peut être plus longue parce qu’elle concerne des dossiers plus risqués, pas parce qu’elle est mal conçue. L’interprétation compte autant que la mesure, et c’est là que l’expertise métier pèse vraiment.
Tableau de lecture rapide : quels KPIs pour quelle question ?
| Question opérationnelle | Famille de KPI | Indicateurs utiles | Décision typique |
|---|---|---|---|
| Où se crée l’attente dans le process ? | Temps | Lead time, temps d’attente vs traitement, P90/P95 | Revoir une validation, réduire les handovers, ajuster un SLA |
| Pourquoi autant de reprises ? | Qualité | Rework rate, boucles, first time right | Clarifier les règles, corriger une étape amont, standardiser un input |
| Respecte-t-on le process attendu ? | Conformité | Écarts, activités manquantes, séquences interdites | Renforcer un contrôle, simplifier une règle, former |
| Qui est surchargé, quand, et pourquoi ? | Charge | Encours, volume, transferts, charge par rôle | Rééquilibrer, ajuster des priorités, lisser un planning |
| Le process est-il stable ? | Variabilité | Variantes, long tail, dispersion | Réduire la complexité, cadrer les exceptions, segmenter |
Cas pratiques : comment relier méthode + KPIs, sans se perdre
Ici, l’objectif n’est pas d’empiler des scénarios “parfaits”. L’idée est plutôt d’illustrer comment un process mining s’ancre dans une question concrète, puis dans une short-list de KPI. C’est souvent là que l’efficacité se joue : moins d’indicateurs, mais mieux reliés au métier. Et un rappel utile : un KPI sans décision associée reste un chiffre décoratif.
Cas pratique 1 : order-to-cash, quand la facturation arrive trop tard
Question de départ : à quel moment le process décroche entre commande, livraison, facture, paiement ? Dans la pratique, la difficulté est de réconcilier les données entre ERP et outils périphériques, puis de visualiser les variantes (facture partielle, litige, avoir, relance). Sur une mission, un simple découpage “factures avec litige” vs “sans litige” a suffi à expliquer l’essentiel de la dispersion des délais, ce qui a évité de s’attaquer au mauvais maillon.
KPIs à suivre : lead time, temps d’attente entre étapes clés, taux d’exceptions, rework, encours, répartition des variantes.
Cas pratique 2 : procure-to-pay, trop de retours et de validations
Question de départ : d’où viennent les boucles (réception, facture, rapprochement), et lesquelles sont “normales” vs évitables ? Ici, la conformité est utile, mais elle doit rester orientée réduction de friction, pas contrôle. Par exemple, un taux de non-conformité peut augmenter… simplement parce qu’une règle a été rendue plus stricte. Le KPI doit donc être lu avec le contexte de la règle.
KPIs à suivre : first time right, nombre de boucles, conformité au chemin attendu, durée par segment fournisseur, handovers.
Cas pratique 3 : service client / IT tickets, le “ping-pong” entre équipes
Question de départ : pourquoi les tickets se transfèrent autant, et où s’empilent les temps d’attente ? C’est un processus idéal pour le mining car les systèmes ITSM tracent beaucoup d’événements (création, assignation, requalification, attente client, résolution, réouverture). Dans la pratique, un indicateur simple comme “nombre de transferts avant résolution” change vite les discussions : on ne parle plus d’impressions, on parle de flux.
KPIs à suivre : nombre de transferts, temps d’attente, taux de réouverture, respect des SLA, variantes, charge par file.
Cas pratique 4 : parcours d’onboarding, éviter les dossiers qui s’enlisent
Question de départ : quelles étapes manquent, et sur quels canaux les dossiers “s’enlisent” ? Souvent, les données sont dispersées (CRM, workflow, validation conformité), d’où l’intérêt d’un log d’événements propre. Une limite à connaître : si une étape se fait hors système (mail, fichier partagé), le mining la “voit” mal. Il faut alors tracer l’événement, même minimalement, sinon l’analyse attribue l’attente à l’étape suivante.
KPIs à suivre : lead time, activités manquantes, non-conformité, long tail, segmentation par canal.
Retour terrain : ce qui change vraiment quand le mining est bien cadré
Sur le terrain, lors de l’analyse d’un processus multi-systèmes, un apprentissage revient : les premières visualisations “choquent” souvent les équipes, parce que le process réel est plus fragmenté que prévu. Dans la pratique, le déclic arrive quand la lecture est faite avec le métier : on segmente (par canal, typologie, priorité), on évite les moyennes, et on relie chaque constat à une action d’amélioration mesurable. Sans cette étape, les informations restent intéressantes… mais elles ne deviennent pas de l’efficacité. Autre leçon apprise à la dure : si la première restitution ressemble à un “procès”, même involontairement, le projet se fige. Il vaut mieux commencer par une lecture neutre, presque factuelle, puis demander : “Qu’est-ce qui vous surprend ?”.
Témoignage recueilli en contexte de pilotage opérationnel : Camille, responsable support dans une entreprise de services, résumait ainsi l’apport après une mise en place de suivi : « Le premier gain, ce n’était pas un tableau de plus. C’était d’avoir le même vocabulaire entre équipes : ce qu’on appelle “en attente”, “assigné”, “résolu”. Une fois les définitions calées, les KPI sur les transferts et les temps d’attente ont enfin servi à trancher, pas à débattre. »
Choisir ses outils : les questions qui comptent plus que le logo
Le choix des outils dépend surtout de la maturité data et du cas d’usage. Les critères qui évitent les mauvaises surprises :
- Connecteurs vers vos systèmes (ou facilité d’intégration).
- Préparation des données (ETL, data modeling, gestion des règles).
- Exploration : filtres, variantes, comparaisons, segmentation.
- Conformité : règles, contrôles, tolérances.
- Collaboration : commentaires, partage, gouvernance.
- Déploiement : cloud/on-prem, sécurité, coûts, gestion des accès.
Quelques repères de marché, à titre d’exemples (et pas comme vérité universelle) : Celonis est souvent cité pour la profondeur d’exploration et l’écosystème, tandis que certaines offres s’intègrent naturellement à des environnements IBM selon les parcs applicatifs. Au fond, le bon choix reste celui qui colle au processus visé, aux données disponibles et aux contraintes de l’entreprise. Et si un POC ne teste pas l’extraction, il ne teste rien : la valeur se joue là.
Process mining et BPM : rivaux ou alliés ?
Rivaux, rarement. Alliés, souvent. Le bpm sert à concevoir, standardiser, documenter un processus. Le process mining sert à observer et mesurer le process réel, et à piloter l’amélioration en continu. Un usage très concret : prendre un modèle BPM comme référentiel, puis mesurer la conformité et la dérive au fil du temps. Cela évite de réécrire des procédures “au feeling” tous les six mois.
Erreurs fréquentes (et comment les éviter sans dramatiser)
- Partir trop large : un seul processus, une question, sinon le mining devient un inventaire.
- Négliger la définition du case id : sans identifiant stable, le process reconstruit est fragile.
- Confondre activité et statut : “en cours” n’est pas une action, c’est un état.
- Regarder uniquement la moyenne : elle gomme les cas extrêmes, souvent coûteux.
- Produire un rapport sans plan d’action : les informations ne valent que si elles déclenchent une décision.
- Oublier l’adhésion : si les équipes voient un outil de contrôle, la coopération baisse.
Conseils de pro : rendre le process mining utile dès le premier mois
Trois pratiques qui marchent, progressivement, sans “big bang” :
Quick wins : viser une friction claire (un transfert inutile, une validation redondante), puis mesurer avant/après. L’amélioration doit être observable. Si rien ne bouge, la question n’est pas “le mining est-il mauvais ?”, mais “l’action était-elle réaliste ?”.
Ateliers de lecture de process : pas des ateliers “théoriques”. Des ateliers où les équipes commentent le process découvert, et où les définitions sont verrouillées. Un bon signe : quand une personne dit “Ah, donc chez nous ‘assigné’ veut dire ‘pris en charge’… pas ‘envoyé à une équipe’”.
Tableau de bord minimal : 3 à 5 KPI, mis à jour à une fréquence réaliste, avec un rituel de revue. Sans rituel, le processus retombe dans l’angle mort.
Un point souvent sous-estimé : la technologie ne remplace pas l’arbitrage. Même avec de l’intelligence embarquée et des recommandations “prêtes à l’emploi”, les décisions métier restent une affaire de contexte, de risques, et de priorités. Parfois, l’action la plus utile est une règle plus simple, pas un robot.
La checklist avant de lancer : êtes-vous prêt ?
- Le processus cible est-il clairement nommé et borné (début/fin) ?
- Un sponsor côté métier est-il engagé sur les décisions ?
- Le case id est-il défini et stable dans les systèmes ?
- Les données contiennent-elles activité + timestamp exploitables ?
- La fréquence de mise à jour est-elle définie (et tenable) ?
- Les KPI sont-ils définis avec des règles partagées ?
- Un plan d’actions et un owner du process sont-ils nommés ?
Astuce bonus : commencer petit, mais penser “suivi”
Un démarrage solide : un processus, 3–5 KPI, une revue régulière, et une boucle d’amélioration. Le process mining devient alors un instrument de pilotage, pas une photo figée. Quel process donnerait le plus de visibilité dès demain : facturation, tickets, achats, onboarding ? Au bout du compte, le vrai gain n’est pas “d’avoir un graphe”. C’est d’obtenir un langage commun, puis des décisions répétables, et une traçabilité qui tient quand les équipes changent ou que les volumes montent.
Qu’est-ce que le process mining et comment ça fonctionne ?
Le process mining reconstruit un processus réel à partir de données d’événements (activité, identifiant de dossier, timestamp) issues des systèmes. Il permet de visualiser les chemins réellement suivis, de mesurer les délais, et d’identifier les variantes et boucles du process.
Quelles données faut-il pour démarrer un projet de mining ?
Le minimum est un case id, une activité et un timestamp. Des attributs complémentaires (canal, montant, catégorie, équipe) enrichissent l’analyse et permettent de segmenter le processus pour prendre des décisions métier.
Quels KPIs suivre en priorité en process mining ?
Les KPI de temps (lead time, attente vs traitement) et de qualité (rework, boucles, first time right) donnent souvent les premiers leviers d’efficacité. Ensuite viennent la conformité, la charge et la variabilité, selon les objectifs de l’entreprise.
Le process mining remplace-t-il le BPM ?
Non : le bpm sert à concevoir et standardiser, tandis que le mining observe le process tel qu’il s’exécute réellement. Ensemble, ils permettent de comparer l’attendu et le réel, puis de piloter l’amélioration.
Combien de temps faut-il pour obtenir des résultats ?
Les premiers résultats arrivent après la construction d’un log d’événements propre et une lecture partagée avec le métier. Le délai varie selon l’accès aux données et le nombre de systèmes à relier, mais un périmètre bien cadré accélère fortement.
Au final, le process mining n’est ni un gadget, ni une promesse d’optimisation instantanée. C’est une discipline de pilotage : relier des données de systèmes au processus réel, choisir quelques KPI qui parlent aux équipes, et installer une routine d’amélioration. Pour les entreprises, le meilleur conseil observé en mission reste étonnamment simple : commencer petit, cadrer les définitions, puis faire vivre le process via un flux de revue régulier, au plus près du travail réel, et avec des solutions concrètes (dont une automatisation bien choisie) plutôt qu’un grand rapport qui dort sur un blog. Cela limite les inefficacités, améliore la productivité, et ouvre des perspectives plus solides sur la façon dont les métiers fonctionnent, s’exécutent et s’alignent sur la conformité mise en oeuvre par les équipes et les systèmes informatiques.
Sources :
- ieee.org
- iso.org
- gartner.com
