Pourquoi nous évitons les connecteurs prêts à l'emploi (et ce que nous faisons à la place)

Vous cherchez des modèles de data ? Parcourez nos guides d’amélioration continue des processus avec des modèles prêts à l’emploi pour des processus comme De l’achat au paiement (P2P), De la commande à l’encaissement (O2C) et Comptes fournisseurs.

Le Process Mining a besoin de data — mais on s’y prend mal

« La data représente 80 % du travail en Process Mining. »

Vous avez sans doute déjà entendu cette statistique. Nous l’avons vécue, nous aussi. Mais voici la vérité qui dérange : que la data représente 80 % du travail n’a rien d’une loi immuable — c’est le symptôme d’une mauvaise approche.

Quand l’extraction de data se transforme en projet de plusieurs mois, c’est qu’on s’est égaré. Le but du Process Mining, ce ne sont pas des pipelines parfaits. Ce sont les insights. Découvrir que des factures restent 12 jours sans qu’on y jette un œil. Constater que 40 % des commandes nécessitent une intervention manuelle à cause d’un mauvais paramétrage.

La data est un moyen, pas une fin.

Alors pourquoi autant de projets de Process Mining se bloquent‑ils sur la phase data ? Souvent, tout part d’un choix : opter pour des connecteurs prêts à l’emploi.

La promesse des connecteurs prêts à l’emploi

Soyons justes : la promesse est séduisante.

Les connecteurs prêts à l’emploi sont des intégrations préconfigurées censées extraire la data de processus depuis des systèmes comme SAP, Salesforce, ServiceNow ou Oracle. Le pitch ressemble à ceci :

• Pointez vers votre système
• Appuyez sur un bouton
• Votre data apparaît, parfaitement formatée
• Programmez une actualisation quotidienne
• Et c’est fini

Dans un monde idéal, ce serait révolutionnaire. Et pour être honnêtes, nous l’avons vu fonctionner — en démo. Parfois même en production, dans des environnements simples avec des configurations standard.

Mais voilà : votre entreprise n’est pas un environnement de démo.

Le retour à la réalité

Nous avons passé des années à accompagner des organisations sur le Process Mining. Nous avons vu ce qui marche et ce qui ne marche pas. Et, à maintes reprises, nous avons constaté que les connecteurs prêts à l’emploi créent plus de problèmes qu’ils n’en résolvent.

Le « démarrage rapide » qui dure un an

L’un de nos clients a lancé son projet de Process Mining tout enthousiaste grâce à un connecteur SAP vendu comme miraculeux. « Trois semaines pour les premiers insights », lui avait‑on promis.

Dix‑huit mois plus tard, il corrigeait encore des problèmes de qualité des données.

Ce n’est pas un cas isolé. Nous avons vu des projets de connecteurs s’éterniser plus d’un an, engloutissant budget et énergie. Le paramétrage soi‑disant « simple » devient tout sauf simple une fois confronté à la réalité du terrain.

Pourquoi les connecteurs peinent dans la vraie vie

• Votre système n’est pas standard. Les connecteurs sont conçus pour des versions précises de logiciels précis. Or les entreprises personnalisent : ajout de champs, workflows modifiés, structures de tables qui évoluent. Votre ERP ? Il a sans doute évolué depuis des années. Le connecteur s’attend à une installation « idéale » ; vous avez un système vivant, façonné par des années de décisions métier.

• Les connecteurs veulent tout couvrir. Un connecteur conçu pour tous les cas d’usage de Process Mining devient d’une complexité folle. Il gère des cas limites que vous ne verrez jamais, sans forcément prendre en charge l’analyse dont vous avez vraiment besoin. Le « tout‑en‑un » vous impose une complexité qui n’apporte aucune valeur.

• Le labyrinthe multi‑tables. La plupart des connecteurs s’appuient sur plusieurs tables sources. Puissant, oui, mais complexe à configurer et à maintenir. Il faut comprendre votre processus, le modèle de données du connecteur, celui du système source, et leur mapping. Ça fait beaucoup de modèles à gérer.

• Les boîtes noires inspirent la défiance. Quand un connecteur se met à dysfonctionner (et ça arrive toujours), impossible de voir à l’intérieur. La data est‑elle erronée dans la source ? Le connecteur la transforme‑t‑il mal ? Problème de configuration ? Vous déboguez à l’aveugle, frustrant pour tous — et quasi impossible à expliquer aux parties prenantes.

• Du travail en double. Ironie : nombre d’organisations ont déjà de la data propre dans leurs data warehouses ou data lakes. Vos data engineers ont bâti des pipelines, résolu des soucis de qualité, créé des datasets fiables. Un connecteur ignore tout cela et repart de zéro, au risque de s’écarter des données de référence de l’entreprise.

• Des libellés génériques qui embrouillent. Le connecteur impose une terminologie standard qui ne correspond pas toujours à votre vocabulaire. Quand le connecteur parle d’« Order Confirmation » et que votre équipe dit « Accusé de réception de commande », vous créez une couche de traduction qui ralentit chaque échange.

• Le piège ETL. La plupart des connecteurs vous enferment dans l’outillage ETL de l’éditeur : apprentissage d’un système propriétaire, dépendance à des fonctionnalités maison, compétences peu transférables. Pendant ce temps, votre entreprise a déjà une stack ETL et des personnes qui la maîtrisent.

• Le verrouillage fournisseur, par design. Soyons clairs : des pipelines data complexes et propriétaires sont un « plus » pour l’éditeur. Après six mois investis dans une infrastructure à base de connecteur, changer d’outil devient très coûteux. Ce n’est pas un hasard.

Les coûts cachés

Au‑delà des défis techniques, l’approche par connecteur a de vrais coûts :

• Temps : des mois passés à extraire la data au lieu de l’analyser
• Argent : des licences de connecteurs coûteuses, plus des honoraires de consultants pour la mise en place
• Opportunité : des améliorations de processus retardées le temps de construire le pipeline
• Motivation : les équipes se démobilisent quand le projet s’enlise sur la data
• Confiance : les parties prenantes doutent de la valeur du Process Mining quand les premiers projets dérapent

Notre approche : des modèles de data

Nous avons pris un autre chemin. Plutôt que de construire des connecteurs, nous avons créé des modèles de data.

La philosophie est simple : définir la data nécessaire dans un format proche de votre processus et facile à produire.

Commencez avec Excel

Oui, vraiment. Vous pouvez démarrer avec Excel.

Nouveau sur les event logs ? Notre guide comment créer un event log pour le Process Mining vous accompagne pas à pas pour construire votre premier event log, avec des exemples en Excel et en SQL.

Nos modèles de données précisent exactement les colonnes nécessaires à chaque analyse. Pour beaucoup de processus, il suffit d’un Case ID, d’un Timestamp et du nom d’une Activity — plus les attributs qui comptent pour votre métier.

Vous pouvez le faire vous‑même. Aujourd’hui. Sans attendre l’IT. Sans procédure d’achat. Sans consultant. Exportez quelques données de votre système, mettez‑les au format de notre modèle, importez‑les, et vous analysez déjà votre processus.

Est‑ce parfait ? Non. Est‑ce rapide ? Absolument. Et pour comprendre votre processus, la vitesse compte plus que la perfection.

Pourquoi une seule table ?

Nous utilisons volontairement un format mono‑table pour la majorité des analyses. Cela peut sembler restrictif, jusqu’à ce qu’on comprenne pourquoi :

1. Simple à comprendre : n’importe qui peut ouvrir une feuille et saisir ce qui se passe
2. Simple à produire : pas de jointures complexes ni de gestion de relations
3. Le Process Mining le fait de toute façon : même les outils qui ingèrent plusieurs tables les fusionnent en un event log pour l’analyse

Vous pouvez toujours travailler avec plusieurs tables dans ProcessMind — vues différentes, processus distincts, voire de l’object‑centric Process Mining. Mais rien n’oblige à commencer par là. Démarrez simple, n’ajoutez de la complexité que si elle apporte de la valeur.

Travaillez avec votre équipe data

Voici un constat : l’approche par connecteur contourne souvent vos data engineers. C’est une erreur.

Votre équipe data connaît vos systèmes. Elle sait où se nichent les problèmes de qualité, quels champs sont fiables et lesquels il faut vérifier. Elle a probablement déjà résolu bon nombre de soucis qu’un connecteur rencontrera.

Nos modèles de données créent un langage commun. Transmettez le modèle à votre data engineer : il comprendra immédiatement ce qu’il faut. Il peut utiliser les outils qu’il maîtrise déjà — SQL, votre plateforme ETL, votre data warehouse — pour produire exactement les données attendues.

Aucun nouveau système à apprendre. Pas de formation propriétaire. Juste des besoins clairs que des pros de la data peuvent adresser rapidement.

Capitalisez sur l’existant

La plupart des organisations disposent déjà d’une infrastructure data conséquente :

• Des data warehouses avec des données nettoyées et validées
• Des pipelines ETL fiables pour faire circuler l’information
• Des data lakes avec des données historiques
• Des outils de BI avec des requêtes éprouvées

L’approche par modèles de données permet d’exploiter tout cela. Inutile de reconstruire l’existant. Pas de pipelines data parallèles. Capitalisez sur les investissements déjà réalisés.

Conséquence directe : les données préparées pour le Process Mining peuvent servir ailleurs. Constituez un dataset une fois, réutilisez‑le pour le Process Mining, le machine learning, la BI classique et tout le reste. C’est ça, l’efficacité.

Flexibilité dopée à l’IA

Même avec des modèles clairs, nous savons que la data n’arrive pas toujours parfaitement formatée. C’est pourquoi nous avons intégré un mapping de data piloté par l’IA dans ProcessMind.

Importez votre data : notre système la comprend souvent automatiquement — il reconnaît la colonne du case ID, celle du timestamp et celle des noms d’activité. Si quelque chose n’est pas reconnu correctement, vous pouvez l’ajuster manuellement en quelques clics.

L’objectif : supprimer les frictions entre vous et les insights.

Envie de vous lancer ?

Nous avons conçu ProcessMind autour de ces principes : des besoins data simples. Un délai de création de valeur court. Et vous gardez la main.

Explorez nos guides d’amélioration continue des processus pour trouver des modèles de data pour les processus les plus courants. Chaque guide inclut :

• Les activités du processus et la data à capturer
• Des fichiers modèles utilisables immédiatement
• Des recommandations pour les systèmes populaires comme SAP, Oracle et Microsoft Dynamics
• Les bonnes pratiques de préparation de la data

Ou commencez un essai gratuit et importez un peu de data. Vous serez peut‑être surpris par la vitesse à laquelle les insights apparaissent quand vous n’attendez pas la configuration d’un connecteur.

La data n’est pas l’objectif. Comprendre votre processus, oui. Allons plus vite vers cet objectif.