Dans beaucoup d’entreprise, les mêmes signaux reviennent en boucle : délais qui dérivent, clients qui relancent, équipes qui “courent” sans jamais rattraper le retard. Sur le papier, le processus paraît pourtant clair. Et en réunion, tout le monde a une explication plausible. Le hic, c’est que la réalité des systèmes ne suit pas toujours la version racontée. C’est précisément là que le process mining devient utile : regarder les traces d’exécution, pas les intentions, pour comprendre où le process se grippe vraiment.
Vous sentez que “ça coince”, mais où exactement ?
Les symptômes sont souvent très concrets. Un dossier “simple” prend soudain deux semaines. Une commande repasse trois fois par la même étape. Une demande “attend” sans que personne ne sache chez qui. Et, entre deux équipes, une file d’attente invisible se forme : pas vraiment un blocage déclaré, plutôt un entre-deux. Dans ces processus, ce ne sont pas toujours les tâches qui durent ; ce sont les attentes, les allers-retours, les exceptions. Le genre de détails qu’on banalise… jusqu’au jour où tout le monde se met à subir.
En général, les ateliers terrain et la cartographie bpm font émerger une version cohérente. Pourtant, ils capturent surtout ce que chacun pense faire. Or les systèmes enregistrent ce qui se passe réellement, même quand personne ne le voit. Quand l’écart grandit, la discussion tourne vite au ressenti. Le process est “connu”, mais les goulots restent introuvables, et les mêmes problèmes reviennent. Un classique : on corrige un point, puis le blocage réapparaît ailleurs, comme si le flux avait trouvé une autre façon de se coincer.
À ce titre, le process mining s’inscrit naturellement dans une démarche d’amélioration continue, au même titre que certains réflexes issus du Lean Six Sigma, quand il faut objectiver un problème avant de le corriger et gagner en efficacité.
Quand les données des systèmes parlent : l’idée simple derrière le process mining
Le principe du process mining est presque désarmant de simplicité : partir des données d’événements enregistrées par les systèmes (ERP, CRM, ITSM, outils métiers) pour reconstruire le processus tel qu’il s’exécute. Pas celui “prévu”. Pas celui “décrit”. Le réel, avec ses détours, du début à la fin, de bout en bout. Et souvent, ce réel surprend, y compris des équipes très expérimentées.
Concrètement, chaque action laisse une trace : un statut qui change, une validation, une création de ticket, un passage “en attente”, un transfert. Le mining agrège ces traces, les remet dans l’ordre, et dessine la carte du process. Cette technologie est née du croisement entre gestion des processus, science des données et analyse des logs. Progressivement, elle a quitté les laboratoires pour entrer dans les entreprises, parce que les volumes et la granularité des traces ont explosé, et que les flux se sont multipliés. Même les petites tâches, celles qu’on pensait “administratives”, se retrouvent tracées, horodatées, comparables.
Et oui, il y a souvent un moment un peu vexant : le process “officiel” ne correspond pas au processus réel. Cela arrive même dans une entreprise très carrée. Ce n’est pas un jugement ; c’est un constat basé sur des données. Ce qui compte ensuite, c’est ce qu’on en fait : ignorer, ou apprendre.
Ce que le process mining montre que vous ne voyez pas en réunion
Une surprise fréquente : “le même dossier” n’a pas un chemin, mais une multitude. Un processus censé être linéaire devient un ensemble de variantes. Parfois 5, parfois 12, parfois bien plus. Le process mining rend ces variantes visibles, et surtout mesurables : fréquence, durée, points de bifurcation. Là où la réunion parle d’un parcours moyen, le mining montre les parcours réels, avec leurs risques et leurs écarts. C’est moins confortable, certes, mais nettement plus exploitable.
Les goulots typiques apparaissent alors sans filtre : rework (retouches), boucles, validations multiples, transferts entre systèmes, étapes “hors radar” qui rallongent le temps de cycle. Et souvent, le contraste est net : quelques minutes de travail effectif, puis des heures, voire des jours d’attente. C’est ce différentiel qui plombe l’efficacité des opérations sans que personne ne se sente directement responsable, ni même informé. Autre point révélateur : certaines étapes réputées “courtes” le sont… sauf quand un cas particulier arrive, et là, tout déraille.
Trois techniques, trois angles de vue (et oui, ça change tout)
Le process mining n’est pas un monolithe. Il s’appuie sur trois approches complémentaires, et chacune répond à une question différente. Dans la pratique, les entreprises les combinent, selon le métier, le contexte et les défis du moment. C’est un peu comme éclairer une pièce avec trois lampes : une seule ne suffit pas toujours.
- Découverte (discovery) : reconstruire le process tel qu’il est exécuté, à partir des données. C’est souvent le point de départ, celui qui coupe court aux débats interminables et accélère l’analyse.
- Conformité (conformance) : comparer l’exécution réelle à un processus cible, à une règle, à une politique interne. Utile quand l’écart coûte cher, ou quand la conformité est sensible. On identifie alors les écarts, mais aussi les zones grises, celles qui génèrent des problèmes.
- Amélioration (enhancement) : enrichir le modèle avec des durées, des fréquences, parfois des coûts, pour prioriser les actions. Le mining devient alors un support de décision, pas juste une carte, et l’optimisation devient plus rationnelle.
De quelles données avez-vous besoin, concrètement ?
Pour démarrer un process mining, il faut un “trio” minimal dans un event log. Rien d’exotique, mais il faut être soigneux : un identifiant de cas (commande, dossier, demande), une activité (étape), et un horodatage. Sans ces trois éléments, le mining reconstruit mal, ou reconstruit “joli” mais faux. Et un process faux est pire que pas de process du tout, surtout quand on vise une amélioration rapide. Beaucoup se font piéger par un horodatage “date de dernière mise à jour” : pratique pour un tableau, trompeur pour un flux.
Ensuite, certaines informations rendent l’analyse bien plus actionnable : ressource (équipe ou systèmes impliqués), canal, type de produit, statut, motif d’exception. Ces champs permettent de segmenter, donc d’éviter les moyennes qui anesthésient. Dans une entreprise, le processus n’est rarement identique selon le client, l’agence, le type de demande, ou même selon les services concernés. C’est là qu’on découvre, par exemple, qu’un “petit” segment fait exploser la charge, sans bruit.
Où trouver ces données ? Dans les ERP, CRM, WMS, outils ITSM, applications métiers, parfois dans des orchestrateurs ou des couches RPA. Les emails peuvent aider, mais seulement quand c’est structuré ; sinon, mieux vaut rester sur les traces fiables des systèmes. La technologie de process mining ne compense pas une collecte bancale : elle la met en lumière, et c’est là que beaucoup d’entreprises se rendent compte des angles morts. Les doublons, par exemple, ne “gênent” pas tant qu’on n’essaie pas de reconstituer une chronologie.
Les goulots invisibles les plus fréquents (vous en reconnaîtrez peut-être un)
Certains goulots reviennent dans presque toutes les entreprises. Pas parce que les équipes travaillent mal. Plutôt parce que les processus grandissent, se complexifient, s’empilent, et que les systèmes se multiplient sans toujours fonctionner ensemble comme on l’imagine. Et, au passage, une règle locale finit parfois par devenir une règle tacite globale.
- Les files d’attente entre deux systèmes : personne ne “possède” l’entre-deux, donc personne ne l’améliore, et le flux ralentit.
- Les retours arrière pour une information manquante : une petite précision, puis une autre, et le process tourne en rond, avec des problèmes qui se répètent.
- Les règles implicites : contournements, raccourcis, étapes sautées. Ces “workarounds” sauvent la journée… et dégradent le processus sur la durée, tout en augmentant les risques.
- Les pics d’activité : fins de mois, clôtures, campagnes. Le système tient, puis sature, puis le stock de demandes retombe lentement, et la productivité s’effondre sans alerte claire.
Une situation type : du soupçon au diagnostic en quelques jours
Le chemin le plus efficace est souvent le plus sobre. D’abord, choisir un processus où la douleur est tangible : délais, volume, irritants clients. Ensuite, extraire les données d’événements depuis les systèmes concernés, les nettoyer juste ce qu’il faut, puis lancer la découverte. Le process mining génère un premier “film” du process : les variantes, les boucles, les attentes, les transferts, le réel. Et là, en général, les débats changent de ton : moins d’opinions, davantage de “montre-moi où ça se passe”.
À partir de là, l’objectif n’est pas de tout expliquer d’un coup. L’objectif, c’est une liste courte d’hypothèses vérifiables. Par exemple : “Cette étape concentre l’attente”, “Cette variante explose après tel statut”, “Ce transfert crée un délai”. On passe d’un débat à un diagnostic, puis à une vérification terrain. Dans une entreprise, ce basculement change tout, parce qu’il redonne du temps aux équipes au lieu d’en consommer en réunions, et il structure enfin la gestion du sujet. Un conseil vécu : garder une ou deux hypothèses “simples” au début, sinon le pilote s’éparpille et n’atterrit jamais.
Process mining vs BI vs audit : qui fait quoi, et pourquoi les combiner ?
La BI est excellente pour piloter des KPI : volumes, taux, délais moyens. Pourtant, elle explique rarement le chemin réel du processus. Elle dit “combien”, pas “comment”. L’audit, lui, creuse en profondeur, mais sur des échantillons limités, et souvent avec un angle conformité et contrôle. Et parfois, il arrive après la bataille, quand le problème a déjà coûté cher.
Le process mining se place entre les deux : une vue systémique sur l’exécution du process, basée sur les données des systèmes, puis un retour terrain pour comprendre les causes. Simple sur le principe. Dans la réalité, cela demande un minimum de méthode, sinon on obtient un très beau schéma… et peu d’amélioration concrète, donc peu de résultats. Le trio qui marche souvent : BI pour suivre, mining pour expliquer le flux, terrain pour trancher quoi changer.
Choisir un outil de process mining sans se perdre
Il existe de nombreux outils de process mining, et la comparaison se joue souvent sur des critères pragmatiques : connecteurs aux systèmes, gestion des logs, filtres, visualisations, capacités de conformité, vitesse sur gros volumes, gouvernance. Selon le secteur, certaines fonctions deviennent très attendues : par exemple, des contrôles fins, des modèles partagés, ou un suivi en quasi temps réel. Une démo réussie, c’est bien ; un connecteur qui tombe en production, c’est autre chose.
Le déploiement compte aussi : cloud ou on-premise, contraintes de sécurité, rôles entre IT, data et équipes métiers. Et une question toute simple permet de gagner du temps : vos données sont-elles facilement exportables, ou enfermées dans plusieurs applications qui ne se parlent qu’à moitié ? Le mining adore les traces ; il déteste les silos, surtout quand les services se renvoient la balle. C’est là qu’une gouvernance data basique, même modeste, change la donne.
Côté marché, certains noms reviennent souvent dans les actualités : Celonis, ou encore IBM selon les écosystèmes. Mais un bon outil, au fond, reste celui qui colle à vos systèmes, à vos ressources, et au niveau de maturité de l’entreprise, pas celui qui brille le plus en démo. Autrement dit : moins de “waouh”, davantage de “est-ce qu’on peut le tenir sur 6 mois ?”.
Ce que vous allez mesurer (et ce que ça veut dire, vraiment)
Les indicateurs classiques sont redoutablement parlants : temps de cycle, temps d’attente, taux de rework, fréquence des variantes, goulots par équipe ou par systèmes. Mais la valeur vient surtout de la segmentation : par type de demande, canal, agence, clients, produit. Sans cela, les moyennes masquent les extrêmes, et ce sont souvent les extrêmes qui coûtent le plus cher à l’entreprise, en qualité de service comme en charge de travail. Et ce n’est pas rare de découvrir que 10% des cas consomment 60% du temps.
Mesurer l’efficacité d’un process ne consiste pas seulement à accélérer. Il s’agit aussi de stabiliser, de réduire les écarts, de rendre le processus prévisible. Un process un peu plus lent mais fiable peut valoir mieux qu’un process rapide une semaine sur deux. Et, concrètement, c’est là que les résultats deviennent tangibles pour les métiers. La prévisibilité évite les urgences, et les urgences, elles, coûtent cher.
Pièges classiques : pourquoi certains projets n’aboutissent pas
Premier piège : vouloir tout analyser d’un coup. Trop de processus, trop de périmètre, trop de sources. Le process mining devient une usine à gaz, et l’entreprise se décourage. Deuxième piège : des données incomplètes ou incohérentes (horodatages douteux, activités trop agrégées, identifiants mal définis). Le mining amplifie ces défauts, il ne les gomme pas. Autre erreur fréquente : choisir un flux “politique”, où personne ne veut toucher aux règles.
Troisième piège, plus humain : mal lire les résultats. Confondre corrélation et cause, ou pointer du doigt une équipe sans contexte. Le process traverse des contraintes : outils lents, règles de contrôle, pics, dépendances externes. Le but n’est pas de désigner un coupable, mais de résoudre des problèmes qui empêchent les opérations de respirer. Ce point-là, étrangement, est un des plus grands défis. Et si les équipes se sentent attaquées, elles n’alimentent plus les données correctement : tout le monde perd.
Et la question qui fâche : confidentialité, RGPD, traçabilité interne
Le process mining manipule des traces, donc la confidentialité est un sujet sérieux. La règle d’or : minimisation. Collecter ce qui est nécessaire, pseudonymiser quand possible, limiter les accès. Les entreprises qui réussissent posent un cadre : qui voit quoi, combien de temps, pour quel usage, avec quelle traçabilité, et quels contrôles de conformité. Le RGPD n’interdit pas l’analyse ; il oblige à la cadrer, et c’est plutôt sain.
Il y a aussi un enjeu social. Si la démarche est perçue comme un outil de surveillance, le processus se déforme : contournements, réticences, qualité de saisie qui baisse. Expliquer la finalité — améliorer le process, fluidifier le travail, réduire l’attente — est souvent aussi important que la technologie elle-même, voire plus. C’est une mise en œuvre à soigner, sinon les problèmes se déplacent. Une bonne pratique consiste à partager des résultats “système” (flux, délais, boucles), pas des classements individuels.
Comment lancer un premier pilote qui sert vraiment à décider
Un bon pilote de process mining coche quelques critères simples : volumétrie suffisante, douleur ressentie, données disponibles, sponsor métier impliqué. L’idée n’est pas de “prouver que ça marche” en laboratoire, mais de produire des résultats discutables, testables, et donc utiles à la décision dans l’entreprise, avec une analyse transparente. Concrètement, un pilote réussi se termine par des arbitrages, pas par un slide “insight” de plus.
Côté livrables, mieux vaut viser clair : carte du processus réel, top 5 des goulots, estimation d’impact, plan d’actions court, et quelques modèles de suivi. Puis un tempo réaliste : itérer, valider avec le terrain, ajuster, élargir. Le mining est puissant, mais c’est la boucle courte entre données et réalité qui crée l’amélioration, et qui évite de perdre des ressources en reporting inutile. Une règle simple : une action décidée pour chaque gros constat, sinon le projet s’éteint.
Après le diagnostic : améliorer, automatiser… et vérifier que ça marche
Une fois les goulots identifiés, la tentation est grande de sauter directement à l’automatisation. Pourtant, le bon ordre reste souvent : standardiser, simplifier, clarifier les règles, puis automatiser ce qui est stable. Sinon, on accélère un process déjà tordu. Et il devient juste plus vite… inefficace, avec des problèmes amplifiés. L’automatisation ne corrige pas un flux mal compris ; elle le rend seulement plus rapide à mal faire.
L’étape suivante, souvent oubliée, consiste à vérifier dans le temps. Le process mining permet de comparer avant/après, de mettre des alertes sur les dérives, et de suivre la maturité des processus. Quand les systèmes changent, quand l’organisation bouge, le process bouge aussi. Autant le voir tôt, avec une analyse régulière. Et quand une amélioration ne prend pas, ce n’est pas grave : on le sait vite, on corrige vite.
Petite astuce bonus : la question à poser à vos équipes dès demain matin
Une question simple, et pourtant redoutable : “Où attendez-vous le plus sans savoir qui peut débloquer ?” Les réponses sont rarement théoriques. Elles pointent un entre-deux, une dépendance, un flou entre équipes ou entre systèmes. Et c’est exactement le type d’hypothèse que le process mining peut tester rapidement dans les données, via une exploration ciblée. La question est courte ; les effets, eux, peuvent être très concrets.
Le plus intéressant, au fond, n’est pas d’obtenir une carte parfaite du processus. C’est de rendre visibles ces goulots “normaux”, ceux qui se sont installés sans bruit. Quand ils deviennent visibles, ils deviennent discutables. Et quand ils deviennent discutables, ils deviennent améliorables. C’est là que le mining crée de la valeur, concrètement, pour l’efficacité des opérations et la sérénité des équipes, avec une optimisation progressive portée par les métiers et par l’intelligence des données.
Sources :
- celonis.com
- ibm.com
