Process mining vs cartographie des processus : que choisir ?

Lorsqu'une organisation cherche à améliorer ses processus, deux approches reviennent régulièrement dans les discussions : le process mining et la cartographie des processus. Les deux visent à mieux comprendre comment le travail s'effectue réellement, mais elles partent de prémisses différentes, mobilisent des ressources différentes et produisent des résultats différents. Choisir entre les deux — ou comprendre comment les combiner — est une question stratégique pour tout DSI ou responsable de transformation.

Qu'est-ce que le process mining ?

Le process mining est une discipline analytique qui reconstruit automatiquement les processus réels à partir des traces numériques laissées dans les systèmes d'information : logs d'événements, journaux de transactions, historiques d'activité dans les ERP, CRM ou autres applications métier.

L'idée centrale est simple : si votre ERP enregistre chaque action effectuée sur une commande (création, validation, expédition, facturation), il est possible de reconstituer automatiquement le flux réel suivi par des milliers de commandes, de le comparer à un flux théorique et d'identifier les écarts, les variantes non attendues et les goulots d'étranglement.

Les outils de process mining leaders (Celonis, Signavio Process Intelligence, IBM Process Mining, Apromore) s'appuient sur l'algorithme Alpha, les algorithmes de la famille Heuristics Miner ou des approches par apprentissage automatique pour extraire des modèles de processus à partir des logs.

Ce que le process mining fait bien

• Analyse des données massives : il peut traiter des millions de cas sans effort humain de collecte.
• Détection des variantes : il révèle les chemins non documentés que les équipes empruntent en pratique.
• Mesure de la conformité : il compare le processus réel au processus cible et calcule un taux de conformité.
• Identification des goulots d'étranglement : en mesurant les temps de cycle réels entre chaque étape, il localise les ralentissements.

Les limites du process mining

Le process mining est puissant, mais il a des prérequis exigeants :

• Qualité des données : les logs doivent être structurés, horodatés et contenir un identifiant de cas cohérent. De nombreuses PME n'ont pas de données exploitables dans ce format sans un travail préalable de nettoyage.
• Couverture applicative : le process mining ne « voit » que ce qui est tracé numériquement. Les étapes manuelles, les échanges par email ou les actions hors système restent invisibles.
• Coût de mise en œuvre : les licences des outils leaders démarrent généralement à plusieurs dizaines de milliers d'euros par an, ce qui les met hors de portée de nombreuses PME et ETI.
• Absence de contexte SI : le process mining décrit comment les processus se déroulent dans les applications, mais ne relie pas ces processus à l'architecture globale du système d'information.

Qu'est-ce que la cartographie des processus ?

La cartographie des processus est une approche structurée et collaborative qui consiste à modéliser explicitement les processus d'une organisation : qui fait quoi, dans quel ordre, avec quelles applications, selon quelles règles. Elle produit des représentations visuelles (diagrammes BPMN, logigrammes, matrices RACI) qui servent de référentiel commun aux équipes métier et à la DSI.

Contrairement au process mining, la cartographie des processus ne part pas des données systèmes : elle part des acteurs. C'est un exercice collaboratif, souvent conduit sous forme d'ateliers, dans lequel les équipes formalisent leur connaissance opérationnelle.

Vous pouvez approfondir les bases de cet exercice dans notre guide complet de cartographie des processus métier et dans l'article sur la méthodologie par étapes.

Ce que la cartographie des processus fait bien

• Accessibilité : elle ne nécessite pas de données systèmes de qualité industrielle ni d'investissement logiciel lourd.
• Engagement des équipes : l'acte de modéliser ensemble crée un alignement et une compréhension partagée que l'analyse de logs ne peut pas produire.
• Intégration au SI : lorsque la cartographie des processus est liée à la cartographie applicative, elle permet d'analyser les dépendances entre processus et applications, d'identifier les risques opérationnels et de préparer les projets de transformation.
• Documentation réglementaire : elle produit des artefacts directement utilisables pour les audits ISO 27001, NIS2 ou DORA.
• Analyse du potentiel d'automatisation : en qualifiant chaque étape par son mode d'exécution (manuel, assisté, automatisé) et sa durée, elle permet d'estimer les heures automatisables sans avoir besoin de logs détaillés.

Les limites de la cartographie des processus

• Subjectivité : elle repose sur ce que les équipes déclarent faire, qui peut s'écarter de la réalité opérationnelle réelle.
• Effort de maintenance : une cartographie statique vieillit rapidement si elle n'est pas maintenue activement.
• Échantillon limité : elle décrit le processus idéal ou le plus fréquent, pas la distribution réelle des variantes.

Comparaison synthétique

Quand utiliser le process mining ?

Le process mining est le bon choix lorsque :

• Vous avez un ERP ou CRM mature avec des années d'historique de logs structurés.
• Vous souhaitez analyser des processus à fort volume (plusieurs milliers de cas par mois) pour lesquels les ateliers de modélisation seraient insuffisants pour capturer la réalité statistique.
• Vous menez un projet de transformation d'un processus spécifique et avez besoin d'une baseline objective avant de définir le processus cible.
• Vous disposez d'un budget et d'une équipe data capables de préparer les données et d'exploiter les outils.

Des cas d'usage typiques : analyse du process Order-to-Cash dans un ERP industriel, détection des contournements dans un processus de validation de factures, mesure du taux de conformité d'un processus achat après une transformation.

Quand utiliser la cartographie des processus ?

La cartographie des processus est le bon choix lorsque :

• Vous souhaitez documenter l'ensemble de vos processus métier pour créer un référentiel organisationnel.
• Vous préparez un projet de transformation SI et avez besoin de comprendre les dépendances entre processus et applications.
• Vous devez démontrer votre maîtrise des risques opérationnels dans le cadre d'un audit ou d'une certification.
• Vous cherchez à identifier le potentiel d'automatisation de vos processus sans avoir les données systèmes nécessaires au process mining.
• Vous êtes une PME ou ETI qui démarre sa démarche de structuration des processus.

Des cas d'usage typiques : cartographie des processus avant une migration ERP, création d'un référentiel processus pour une certification ISO 9001, identification des risques opérationnels (bus-factor, processus sans propriétaire) pour NIS2.

Les deux approches sont-elles complémentaires ?

Oui — et les organisations les plus matures dans leur démarche de gestion des processus utilisent les deux en séquence ou en parallèle.

Un schéma courant : la cartographie des processus est réalisée en amont pour créer le modèle cible et aligner les équipes ; le process mining est ensuite utilisé pour mesurer l'écart entre ce modèle et la réalité opérationnelle tracée dans les systèmes. Après transformation, le process mining permet de vérifier que le nouveau processus est effectivement adopté.

À l'inverse, dans une organisation qui dispose déjà de données de process mining mais souffre d'un manque de contexte organisationnel, la cartographie des processus permet de donner du sens aux variantes détectées et de les relier à l'architecture SI globale.

Où se positionne UrbaHive dans ce paysage ?

UrbaHive est une plateforme de cartographie du système d'information qui intègre nativement la cartographie des processus métier. Son positionnement est distinct du process mining sur un point fondamental : UrbaHive relie les processus au SI.

Concrètement, chaque étape d'un processus peut être liée aux applications qui la supportent, aux acteurs qui l'exécutent et aux serveurs ou infrastructures concernés. Cette mise en relation produit des analyses impossibles avec le process mining seul :

• Détection des risques applicatifs : quelle application est un point de défaillance unique pour plusieurs processus critiques ?
• Analyse d'impact : si une application est retirée du SI, quels processus sont affectés ?
• Score d'optimisation : quel est le potentiel d'automatisation global, pondéré par le volume et le mode d'exécution de chaque étape ?

Cette approche est décrite dans notre article sur la façon de lier processus métier et cartographie applicative. Elle s'inscrit dans une démarche d'urbanisation SI qui dépasse la simple analyse des flux.

UrbaHive ne remplace pas un outil de process mining pour les organisations qui disposent des données et du budget nécessaires. En revanche, pour les PME et ETI qui souhaitent structurer leur patrimoine processus, détecter leurs risques opérationnels et préparer leurs projets de transformation, c'est le point de départ le plus accessible et le plus complet.

Conclusion

Le process mining et la cartographie des processus répondent à des questions différentes. Le premier demande : « Comment nos processus se déroulent-ils réellement dans nos systèmes ? » La seconde demande : « Comment nos processus devraient-ils être organisés et comment s'articulent-ils avec notre SI ? » Les deux ont leur légitimité ; le choix dépend de vos données, de votre budget, de votre maturité organisationnelle et de vos objectifs.

Pour la plupart des PME et ETI, la cartographie des processus liée au SI est la démarche de départ la plus pertinente — concrète, accessible et directement utile pour la conformité et la transformation.

Commencez gratuitement sur UrbaHive et construisez votre référentiel processus lié à votre cartographie applicative.

FAQ

Q : Le process mining peut-il fonctionner sans ERP ?

R : En théorie, tout système qui produit des logs d'événements horodatés et structurés peut alimenter un outil de process mining. En pratique, les résultats sont exploitables surtout avec des systèmes transactionnels matures (ERP, CRM, ITSM). Des applications collaboratives comme les outils de ticketing peuvent aussi être utilisées, mais avec une couverture plus limitée.

Q : Faut-il faire la cartographie des processus avant de lancer un projet de process mining ?

R : C'est fortement conseillé. La cartographie des processus permet de définir le périmètre d'analyse, d'identifier les systèmes sources pertinents et de construire le modèle de référence contre lequel le process mining va mesurer la conformité. Sans ce cadre, les résultats du process mining sont plus difficiles à interpréter.

Q : UrbaHive peut-il importer des résultats de process mining ?

R : UrbaHive est une plateforme de cartographie SI et processus ; elle ne consomme pas nativement des logs d'événements. Les deux outils opèrent sur des données différentes et se complètent plutôt qu'ils ne s'intègrent directement.

Q : Quelle est la différence entre le process mining et le task mining ?

R : Le process mining analyse les flux entre applications à partir des logs systèmes. Le task mining enregistre les actions de l'utilisateur au niveau du poste de travail (clics, saisies, copier-coller) pour reconstituer les micro-activités. Les deux sont complémentaires : le task mining capture ce que le process mining ne voit pas (actions hors système).

Q : La cartographie des processus dans UrbaHive est-elle compatible avec BPMN ?

R : L'éditeur de processus UrbaHive s'inspire des conventions BPMN pour sa notation visuelle. Pour aller plus loin sur les bases de la notation BPMN, consultez notre guide BPMN pour débutants.