Dans beaucoup d’entreprises, il existe un processus “officiel” (décrit dans un outil, un document, ou lors d’un atelier), et un process “réel”, celui qui se déroule dans les systèmes au fil des journées, des urgences et des exceptions. Entre les deux, l’écart peut coûter cher : délais qui dérivent, retours arrière, irritants clients, surcharge d’équipes. Le process mining ne promet pas de magie. Mais il met une lampe torche là où, d’habitude, tout le monde suppose. Et cette différence-là change souvent la discussion en entreprise.

Vous avez un “process” quelque part… mais savez-vous vraiment comment il se passe ?

Le point de départ ressemble presque toujours à la même scène : un processus est “connu”, documenté, parfois même piloté en comité. Pourtant, sur le terrain, les équipes racontent autre chose : “ça dépend”, “on contourne”, “on attend la validation”, “on relance”. Ce n’est pas forcément de la mauvaise volonté. C’est juste la vie d’un process dans une entreprise avec des contraintes, des exceptions, des systèmes qui ne se parlent pas toujours.

Avant de parler mining, il faut clarifier le sujet : cherche-t-on à réduire un délai ? à comprendre une hausse de rework ? à sécuriser une étape de contrôle ? Sans cette question, l’analyse devient une visite guidée intéressante… mais peu actionnable.

Process mining, en clair : qu’est-ce qu’on “mine” exactement ?

Le process mining, c’est de l’exploration de processus à partir de données d’événements enregistrées par les systèmes. Concrètement, on ne “mine” pas des opinions ni des intentions. On mine des traces : des étapes horodatées qui décrivent ce qui s’est passé, dans quel ordre, et combien de temps cela a pris. À ce titre, les informations produites sont vérifiables, et donc discutables avec les équipes.

Ce que le mining révèle bien : les variantes (les chemins possibles d’un process), les boucles, les goulots, les handovers, les temps d’attente. Ce qu’il ne fait pas : deviner pourquoi une personne a cliqué, ni corriger automatiquement le processus. L’analyse aide à poser des hypothèses, pas à remplacer le travail d’amélioration continue.

Pourquoi pas juste une analyse de data “classique” ?

Une analyse BI classique répond très bien à “combien ?” et “quand ?”. Volume de dossiers, durée moyenne, nombre de retours. Utile, évidemment. Le process mining répond plutôt à “dans quel ordre ?” et “par quels chemins ?”. C’est une différence subtile… jusqu’au moment où un indicateur semble stable, alors que le processus s’est fragmenté en dizaines de variantes.

En clair : la BI mesure souvent des points. Le process mining observe une trajectoire complète. Et une trajectoire, ça raconte toujours plus qu’un total mensuel.

Le triptyque à comprendre : case, activité, timestamp

Tout process mining tient sur trois colonnes. Sans elles, l’exploration devient vite floue, voire trompeuse.

• Case id : l’objet suivi de bout en bout (commande, dossier, demande, réclamation). Un processus = une collection de “cas”.
• Activité : l’étape observée dans les systèmes (“création”, “validation”, “envoi”, “paiement”…).
• Timestamp : le moment où l’événement se produit. Sans horodatage fiable, l’ordre et les durées deviennent discutables.

Simple, non ? Enfin… presque. Car dans les entreprises, les libellés changent, les horodatages sont multiples, et une “validation” peut cacher dix réalités. Le mining commence souvent par remettre de la précision là où les mots sont trop larges.

D’où viennent les données : ERP, CRM, tickets, emails… et les pièges qui vont avec

Les données d’événements viennent des systèmes qui enregistrent des actions : ERP (par exemple SAP), CRM (par exemple Salesforce), ITSM (par exemple ServiceNow), outils de ticketing, portails, applications internes. Parfois, une partie du process passe aussi par des emails ou des fichiers — et là, la traçabilité devient plus fragile. Autrement dit : on voit ce qui est écrit dans les logs, pas ce qui s’est dit au téléphone.

Les pièges les plus fréquents :

• Horodatages incohérents (timezone, champ mis à jour au lieu de “créé”).
• Activités trop génériques (“traité”, “clos”, “ok”) qui masquent le processus.
• Doublons d’événements (rejeu technique, synchronisation, reprises).
• Données manquantes sur des étapes clés (le process a l’air “court” alors qu’il est juste incomplet).

Qualité des données : une carte approximative ou un GPS qui vous égare ?

Dans la pratique, la qualité des données décide de la valeur de l’analyse. Un process “propre” mais faux est plus dangereux qu’un processus un peu brouillon mais honnête. Sur le terrain, c’est même une source classique de problèmes : on “corrige” un chemin qui n’existait que parce que les logs étaient mal structurés.

Sur le terrain, un bon réflexe consiste à “commencer petit mais vrai”. Un pilote sur quelques semaines et un périmètre clair apprend souvent plus vite qu’un grand projet qui veut tout embrasser.

Choisir un processus à miner : lequel fera gagner du temps sans braquer l’organisation ?

Un processus idéal pour démarrer coche souvent ces critères : fréquence élevée, irritants visibles, dépendance à plusieurs systèmes, variabilité (beaucoup de chemins), sponsor disponible. Un process trop politique ou trop rare donne peu de signal et beaucoup de discussions.

Candidats typiques dans les entreprises :

• Order-to-cash (commande → facturation → paiement)
• Procure-to-pay (demande d’achat → commande → réception → facture)
• Support (ticket → diagnostic → escalade → résolution)
• Onboarding (création comptes, accès, validations)

Un premier périmètre “pilotable” : la stratégie du couloir plutôt que de la cathédrale

Le mining se plante rarement sur l’outil. Il se plante sur le cadrage. Définir un début et une fin sans ambiguïté, décider quelles variantes sont “dans” ou “hors” scope, choisir une période, une population de cas, et un niveau de détail d’activités.

Un périmètre “couloir” n’est pas un compromis au rabais. C’est une stratégie : apprendre vite, stabiliser le modèle de données, puis élargir. Dans une entreprise, ce rythme protège aussi les équipes du “grand audit permanent” que certains redoutent, notamment dans les métiers exposés.

Les étapes de mise en œuvre, dans l’ordre qui évite les déconvenues

Un déroulé pragmatique ressemble à ceci :

• Cadrage : questions métier, objectifs, périmètre du processus
• Extraction et préparation des événements
• Découverte du process (process discovery)
• Contrôles de conformité (conformance)
• Analyse de performance (temps, files d’attente)
• Plan d’actions, suivi, itérations

Lors de l’analyse de pilotes menés avec des équipes d’entreprise (côté consultant et praticien BPM), un apprentissage revient : tant que la question initiale n’est pas formulée en termes observables (“où perd-on du temps entre A et B ?”), le process découvert devient un poster. Joli, mais pas décisif.

Préparation des événements : la partie moins glamour, mais qui change tout

Concrètement, la préparation consiste à rendre les données exploitables pour l’exploration :

• Mapper les activités (libellés stables, niveau de détail utile).
• Construire ou consolider le case id (attention aux fusions de dossiers).
• Normaliser les dates (formats, timezone, champs pertinents).
• Gérer les multi-événements (plusieurs actions au même timestamp, ou dans le désordre).
• Enrichir avec des attributs (canal, montant, produit, type de demande) pour segmenter l’analyse.

Un point qui fait gagner des semaines : stabiliser un modèle de données réutilisable. Quand le mapping d’activités change à chaque extraction, le process change “artificiellement” et tout le monde perd confiance.

Quels indicateurs suivre : les KPIs qui parlent aux équipes, pas seulement à l’analyste

Les KPIs les plus utiles en process mining sont ceux qui relient le processus à une action possible :

• Lead time (temps de traversée) et ses composantes : où se trouve le temps, vraiment ?
• Temps d’attente vs temps de travail : l’analyse sépare souvent les deux.
• Taux de rework : boucles, retours arrière, reprises.
• Variantes dominantes vs “longue traîne” : ce qui est rare peut coûter très cher.
• Throughput : débit, pics de charge, saisonnalité.
• Conformité à une règle : SLA, étape obligatoire, contrôle requis.
• Handovers : passages d’équipe à équipe (souvent synonymes d’attente).
• Automation rate : part automatisée vs manuelle, utile avant une automatisation.

Attention aux faux amis : un KPI “moyen” peut mentir

La moyenne est confortable. Et pourtant, elle masque fréquemment l’essentiel : les cas extrêmes. En process mining, regarder médiane et percentiles (P75, P90) évite de piloter un processus “typique” qui n’existe presque pas.

À ce titre, la segmentation change tout : par canal, type de produit, agence, catégorie de demande. Question simple, mais décisive : vaut-il mieux optimiser 60 % des cas déjà fluides, ou comprendre les 10 % qui font exploser les délais ? C’est souvent là que se joue l’efficacité réelle.

Outils de process mining : comment s’y retrouver sans faire un concours de fonctionnalités

Il existe des suites “enterprise” (forte intégration SI, gouvernance), des solutions plus légères (exploration rapide), et des approches open source via notebooks. Le choix dépend moins du marketing que de la réalité des systèmes, des droits d’accès, et du niveau d’industrialisation attendu.

Un repère utile : si l’objectif est d’apprendre et de convaincre, une approche simple peut suffire. Si l’objectif est de déployer à l’échelle de plusieurs entreprises d’un groupe, la gouvernance et la performance deviennent centrales. Les outils ne rattrapent pas un modèle de données instable.

Sur quels critères choisir votre outil, vraiment ?

• Connecteurs aux systèmes (ERP, CRM, ticketing) et facilité d’extraction.
• Capacités de préparation des données (mapping, transformations, historique).
• Gestion des droits (au niveau cas / attribut) et exigences conformité.
• Découverte + conformance + filtres + segmentation.
• Collaboration : ateliers, commentaires, partage, export.
• Performance sur gros volumes et coût total (licences + run).

Compétences : faut-il être data scientist pour s’y mettre ?

Non, mais il faut un binôme solide. Côté entreprise, une petite équipe fonctionne bien : une personne qui connaît le processus, une personne à l’aise avec extraction et qualité de données, un appui IT pour l’accès aux systèmes, et quelqu’un habitué à l’animation d’actions terrain. Le poste le plus rare est souvent le “traducteur” : celui qui transforme l’analyse en décisions simples, compréhensibles par les métiers.

Un détail rarement anticipé : il faut aussi des compétences techniques pour qualifier les logs, poser les bonnes jointures, et éviter de “raconter une histoire” avec un mauvais identifiant. Un cas fréquent, et vécu en mission : fusionner deux sources et, sans s’en rendre compte, créer un faux chemin. Résultat : on cherche un goulot qui n’existe pas. Perte de temps, tension inutile. Mieux vaut le dire tôt.

Cas d’usage : là où le process mining apporte souvent des réponses rapides

Le process mining est particulièrement utile dès qu’un processus traverse plusieurs systèmes et que les variantes explosent :

• Finance : factures, paiements, relances, litiges
• Achats : cycle de commande, exceptions, validations
• Service client : tickets, escalades, respect des SLA
• RH : onboarding, demandes internes, accès
• ITSM : incidents, changements, récurrences
• Supply : préparation, livraison, retours

Sur le terrain, l’exploration met souvent en évidence une chose simple : la majorité des cas suit un chemin stable, puis une minorité “dérape” à cause d’un petit nombre de motifs répétitifs. L’analyse devient alors une chasse aux causes probables, pas une chasse aux coupables. Et c’est aussi une façon plus saine de piloter les opérations et les services.

Zoom : conformité et risques, quand le process réel s’éloigne du modèle BPM

Quand un processus est décrit dans des modèles de bpm, le process mining permet de vérifier la conformité : l’étape obligatoire a-t-elle lieu ? les contrôles sont-ils contournés ? Dans les entreprises régulées, c’est précieux pour les audits.

Toutefois, l’écart “modèle vs réalité” n’est pas toujours un problème. Il peut signaler que le modèle ne reflète plus le travail réel, ou que les équipes compensent une règle inapplicable. L’analyse doit donc déboucher sur une décision : corriger le processus, ou corriger la règle. C’est là que l’intelligence collective compte, bien plus qu’une vue graphique.

Zoom : performance et goulots, le classique qui marche… si on segmente

Les goulots se voient souvent vite : files d’attente entre deux activités, handovers multiples, variantes rares mais longues. Mais relier un goulot à une cause demande une analyse plus fine : segmentation par type de cas, comparaison des chemins, lecture des données d’attributs.

Un point d’attention : un goulot peut être “normal” (contrôle obligatoire) ou “accidentel” (rework, escalade, erreur de saisie). Sans cette nuance, le mining peut pousser à optimiser ce qui protège l’entreprise.

Et après les insights : transformer ça en amélioration et automatisation, sans effet vitrine

Un process découvert ne vaut que par les décisions qu’il rend possibles. La meilleure mécanique est progressive : prioriser 2–3 irritants, tester une action, mesurer, stabiliser, puis élargir. L’exploration sert ensuite à vérifier que le processus s’est réellement simplifié. C’est une logique d’amélioration continue, pas une démo ponctuelle.

Et attention à la tentation : lancer une automatisation sur une étape instable amplifie parfois le chaos. Tant que les données d’entrée sont inconsistantes, l’automatisation accélère surtout les erreurs. À l’inverse, quand le process est stabilisé, l’automatisation devient un vrai levier d’amélioration.

Pour aller plus loin, certaines équipes combinent process mining et monitoring en quasi réel. C’est utile, mais seulement si l’organisation est prête : sinon, on crée de la surveillance sans décision. Et ça, ça abîme la confiance.

Erreurs fréquentes (et comment les éviter sans dramatiser)

• Vouloir couvrir tout le processus dès le départ, sans périmètre testable.
• Confondre activité et statut vague (“traité”), ce qui ruine l’analyse.
• Ignorer les exceptions “rares”, alors qu’elles plombent le process.
• Oublier la gouvernance et la gestion des accès aux données.
• Présenter un process “joli” mais inexploitable par le terrain.
• Lancer sans sponsor, ni question claire, ni décision attendue.

Questions à se poser avant de lancer un pilote

• Quel objectif concret pour ce process (délai, conformité, rework) ?
• Quel processus et quelles bornes (début/fin) ?
• Quelles données et quels systèmes sources, avec quel niveau de confiance ?
• Qui valide la lecture du process découvert côté terrain ?
• Quels KPIs définir pour juger le pilote (et décider de la suite) ?
• Quel délai de décision réaliste : 2 semaines, 1 mois, 1 trimestre ?

Mini-feuille de route sur 30 jours : un démarrage réaliste

Semaine 1 : cadrage, définition du processus, choix du case id, liste des événements attendus, validation des accès données.
Semaine 2 : extraction, nettoyage, mapping activités, premiers contrôles qualité, itérations courtes avec le terrain.
Semaine 3 : découverte du process, segmentation simple, premiers KPIs (lead time, rework), préparation d’une lecture partagée.
Semaine 4 : atelier de validation, liste priorisée d’actions, définition d’un suivi, décision sur l’élargissement du périmètre.

Ce qui est “suffisant” pour apprendre : un process lisible, des données cohérentes sur une période, et une poignée de décisions possibles. Le reste vient après. Et, en pratique, c’est souvent ce rythme qui évite les dérives de planning.

Le petit bonus qui change la dynamique : montrer tôt une visualisation qui parle au métier

Une astuce qui marche souvent : organiser rapidement un atelier de lecture du process découvert, sans chercher à convaincre. Laisser les équipes réagir : “Pourquoi on repasse par là ?”, “Ça, c’est l’escalade”, “Ici on attend toujours”. Ce sont des hypothèses en direct, et elles nourrissent une analyse plus pertinente.

Témoignage terrain, entendu lors d’une revue de processus support : Sarah, responsable d’équipe Service Desk (profil : manager opérationnel ; contexte : tickets et escalades dans un outil ITSM), expliquait que la visualisation avait surtout aidé à trancher un débat interne. Le mining montrait que les boucles venaient moins d’un manque de compétences que d’une catégorie mal routée, créant des retours inutiles entre groupes. Bénéfice concret : une règle de catégorisation ajustée et un suivi sur les retours arrière, plutôt qu’un plan de formation trop large.

Dernière question, utile pour passer à l’action : si un seul process devait être miné ce mois-ci, lequel ferait gagner le plus de temps (et de sérénité) dans l’entreprise ?

Comment le process mining peut-il aider mon entreprise rapidement ?
En identifiant les variantes réelles d’un processus, les boucles et les temps d’attente à partir des données d’événements. L’analyse met souvent en évidence 2–3 causes récurrentes qui expliquent une grande partie des retards. Le gain vient surtout de décisions ciblées, pas d’une refonte totale.

Quelles données faut-il pour faire du process mining ?
Au minimum : un case id, une activité, un timestamp, issus des systèmes (souvent via des journaux et traces applicatives). Plus les données sont cohérentes et les activités bien définies, plus l’exploration est fiable. Des attributs (canal, type, montant) aident à segmenter l’analyse.

Quelle est la différence entre process mining et une analyse BI classique ?
La BI agrège et explique des volumes, des délais ou des taux. Le process mining reconstruit l’enchaînement réel des étapes d’un processus et révèle ses variantes. Les deux approches sont complémentaires, mais le mining répond mieux aux questions de “chemins” et de rework.

Faut-il un outil spécifique pour démarrer le process mining ?
Un outil aide beaucoup, mais le facteur clé reste la qualité des données et le cadrage du process. Certaines entreprises démarrent en mode exploratoire (prototypage), puis industrialisent quand les usages et la gouvernance sont clairs. L’essentiel est de pouvoir itérer vite et partager une lecture commune.

Combien de temps pour un pilote de process mining ?
Un pilote peut produire une première lecture exploitable en 3 à 6 semaines, selon l’accès aux systèmes et la qualité des données. Mais la stabilisation (modèle, gouvernance, suivi) prend souvent plus longtemps. La bonne métrique est la vitesse de décision, pas la perfection du modèle.

Le process mining fonctionne-t-il si une partie du process passe hors système ?
Oui, mais avec des limites : l’exploration reflète ce qui est tracé. Si des étapes se font par email ou fichiers sans événements, le processus reconstruit peut paraître artificiellement court. Dans ce cas, il faut soit instrumenter (via des systèmes et outils informatiques adaptés), soit accepter la zone grise et l’indiquer clairement.

Quels outils de process mining sont les plus utilisés en entreprise ?
Les outils varient selon le contexte : suites dédiées, modules intégrés à des plateformes data, ou approches open source. Certaines entreprises citent souvent Celonis pour des déploiements à grande échelle, mais le bon choix dépend surtout des connecteurs, de la gouvernance et de la capacité à passer de la découverte à l’amélioration mesurable.

Sources :

• processmining.org
• ieee.org

Quelques mots sur l'autrice

Derrière Société Industrie, il n’y a pas un simple projet éditorial, mais un parcours construit au fil des années au contact des entreprises, des décideurs et des réalités du terrain.