Performance du Process Mining : benchmarks et conseils

Les facteurs qui influencent la performance du Process Mining

La performance du Process Mining dépend de trois facteurs : le volume de données que vous chargez, la manière dont vous les structurez et la façon dont le système les traite. Ce guide couvre ces trois aspects à l’aide de benchmarks réels et de méthodes concrètes pour améliorer les résultats.

Nous publions tous nos chiffres. Comparez-les avec ceux de n’importe quel outil de Process Mining du marché.

Le pipeline de données : où passe le temps

Lorsque vous chargez des données dans ProcessMind, trois étapes se déroulent. Voici précisément où passe le temps :

1. Chargement, qui domine le temps total. Votre fichier transite par Internet jusqu’à notre infrastructure cloud. C’est le principal goulot d’étranglement pour les fichiers volumineux. Les contraintes physiques s’imposent : un fichier CSV de 50 millions d’événements, soit 11 Go, nécessite 2 minutes avec une connexion gigabit, 18 minutes à 100 Mbit/s ou plus de 3 heures à 10 Mbit/s. Les mêmes données au format Parquet ne représentent que 1,7 Go, ce qui réduit ces durées à 19 secondes, 3 minutes et 28 minutes. C’est la principale raison d’utiliser des formats en colonnes comme Parquet ou ORC, ou des jeux de données plus petits.

2. Prétraitement, coût ponctuel d’environ 30 secondes à 2,5 minutes. Une fois le chargement terminé, nous transformons vos données en stockage optimisé en colonnes : les événements sont indexés, les transitions d’activités sont précalculées, les variantes de processus sont identifiées et les statistiques récapitulatives sont calculées. Cette étape prend 30 secondes pour les petits jeux de données et jusqu’à 2,5 minutes pour 100 millions d’événements. Ce coût n’est facturé qu’une fois par chargement, puis vous en bénéficiez pour les analyses suivantes.

3. Modifications du modèle, recalcul partiel de 6 à 52 secondes. Lorsque vous modifiez le modèle de processus en ajoutant ou supprimant des activités, ou en changeant les correspondances, seuls les calculs dépendant du modèle sont mis à jour. Cette étape prend 6 secondes pour les petits jeux de données et jusqu’à 52 secondes pour 100 millions d’événements, soit bien moins qu’un prétraitement complet. Les modifications des filtres sont instantanées.

Comprendre la performance des requêtes

Une fois vos données chargées, plusieurs caractéristiques déterminent la vitesse des requêtes. Les comprendre vous aide à concevoir de meilleurs exports et à définir des attentes réalistes.

Le nombre d’activités compte. Les modèles de processus comportant 10 à 20 activités distinctes sont optimaux. Au-delà de 50 activités, le calcul du flux de processus prend plus de temps et sa compréhension devient plus difficile. Un trop grand nombre de nœuds et d’arêtes crée une surcharge visuelle. Si votre export contient de nombreuses activités, envisagez de regrouper les étapes liées.

La diversité des variantes influe sur le calcul. Un processus dans lequel 80 % des cas suivent 5 variantes s’analyse plus rapidement qu’un processus où chaque cas emprunte un chemin différent. Une forte variation n’est pas un problème en soi et signale souvent des difficultés réelles, mais prévoyez des temps de requête légèrement plus longs.

Plus de colonnes signifie davantage de données à parcourir. Chaque attribut inclus est indexé et interrogé. Les colonnes essentielles, CaseId, Activity et Timestamp, sont toujours nécessaires. Les colonnes supplémentaires facilitent le filtrage et la catégorisation, mais chacune entraîne une surcharge.

Les cas longs prennent plus de temps. Un cas comportant 50 événements nécessite davantage de calculs qu’un cas en comportant 5. Si votre processus comprend des cas couvrant des centaines d’événements, les requêtes seront proportionnellement plus lentes. Cette caractéristique est inhérente au Process Mining et ne dépend pas d’un outil particulier.

Données de benchmark en conditions réelles, mars 2026

Savoir à quoi vous attendre vous aide à planifier. Ces benchmarks sont exécutés sur une infrastructure AWS de production, avec la latence réelle du réseau, puis calculés comme moyennes de plusieurs tests. Nous avons testé plus de 50 types de requêtes pour chaque taille de jeu de données.

Durées de chargement et de prétraitement

Le tableau ci-dessous présente des estimations réalistes pour chaque taille de jeu de données. Pour les fichiers volumineux, surtout avec des connexions lentes, le chargement domine. Il s’agit du principal facteur de votre temps d’attente total.

Les tailles de fichiers correspondent à des fichiers CSV non compressés utilisant un schéma d’Event Log courant, avec CaseId, Activity, Timestamp et 5 à 8 attributs métier. Vos fichiers peuvent être plus ou moins volumineux selon le nombre de colonnes et leur contenu.

Les durées de chargement à 1 Gbit/s sont mesurées avec un débit effectif de 88 Mo/s vers AWS eu-central-1. Les autres vitesses sont extrapolées à partir de débits pratiques : 50 Mbit/s → environ 5 Mo/s, 100 Mbit/s → environ 10 Mo/s, 10 Mbit/s → environ 1 Mo/s. Le débit réel dépend de votre réseau, de la distance jusqu’au centre de données et de la charge du moment.

À retenir : le temps de prétraitement se stabilise entre 1 et 2,5 minutes, quelle que soit l’échelle. Le temps de chargement augmente linéairement avec la taille du fichier. Réduire la taille du fichier est l’optimisation la plus efficace à votre disposition.

Choisir le bon format de fichier

Le format du fichier que vous chargez a une incidence majeure sur la vitesse de chargement et le temps de prétraitement. ProcessMind prend en charge CSV, Parquet, ORC, Excel et XES. Pour les jeux de données volumineux, Parquet et ORC sont nettement plus performants que CSV, tant en taille de fichier qu’en vitesse de traitement.

Comparaison des tailles de fichiers

Les fichiers Parquet sont 85 % plus petits que les fichiers CSV. Les fichiers ORC sont 82 % plus petits. Tous deux sont des formats en colonnes dotés d’une compression intégrée, aucune étape supplémentaire n’est donc nécessaire. Votre outil ETL ou votre plateforme de données, comme Spark, Databricks, dbt ou BigQuery, prend probablement déjà en charge l’export au format Parquet ou ORC.

Prétraitement selon le format

La taille du fichier ne représente que la moitié du sujet. Après le chargement, vos données passent par une ingestion et un calcul analytique dépendant du format, notamment l’indexation des événements ainsi que le calcul des transitions et des variantes. L’étape analytique domine et prend le même temps pour tous les formats. CSV.GZ est le seul format à ajouter un temps significatif, car les fichiers gzip ne peuvent pas être répartis pour une décompression parallèle.

Le temps de prétraitement est presque identique pour Parquet, ORC et CSV, car le calcul analytique domine, quel que soit le format d’entrée. En revanche, le prétraitement de CSV.GZ se dégrade nettement à grande échelle : il passe d’environ une minute pour 1 million d’événements à plus de 4 minutes pour 100 millions. Les fichiers compressés au format gzip ne peuvent pas être répartis ni traités en parallèle. La décompression ajoute donc une étape de plus en plus longue avant le début de l’analyse.

Vue d’ensemble

Si vous tenez compte à la fois du temps de chargement et du prétraitement, le choix du format devient évident :

À grande échelle, Parquet et ORC sont clairement les plus performants, car leurs fichiers sont nettement plus petits. Le chargement constitue le principal goulot d’étranglement. Le prétraitement prend à peu près le même temps pour tous les formats, à l’exception de CSV.GZ, qui subit une pénalité de décompression croissante.

Chargement delta : ajouter des données sans tout recharger

Une fois le jeu de données de référence chargé, vous n’avez pas besoin de tout recharger lorsque de nouvelles données arrivent. ProcessMind prend en charge le chargement delta, ou chargement incrémentiel, afin que vous puissiez ajouter de nouveaux événements à un jeu de données existant.

Fonctionnement :

1. Chargez votre jeu de données initial, par exemple les commandes d’achat du premier trimestre 2026 avec 2,3 millions d’événements
2. Lorsque les données du deuxième trimestre arrivent, chargez uniquement les nouveaux événements dans un fichier delta, par exemple 800 000 nouveaux événements
3. ProcessMind fusionne automatiquement les fichiers et relance le traitement

L’impact sur les performances est important. Au lieu de recharger votre jeu de données croissant à chaque mise à jour, vous ne chargez que les nouvelles données :

Après un chargement delta, le prétraitement est relancé sur le jeu de données combiné, avec le même coût de 1 à 2,5 minutes. Vous économisez toutefois tout le temps de chargement des données déjà transférées.

Le chargement delta est idéal pour :

• Actualisations hebdomadaires ou mensuelles des données : ajoutez les nouvelles transactions dès qu’elles sont disponibles
• Surveillance continue des processus : gardez vos Dashboards à jour sans transferts volumineux
• Journaux d’événements qui s’enrichissent : ajoutez les nouveaux événements provenant de votre ERP, de votre CRM ou d’autres systèmes sources

Les fichiers delta doivent utiliser le même format et la même structure de colonnes que le chargement initial. Consultez le guide du chargement incrémentiel des données pour plus d’informations.

Utiliser l’API pour les chargements volumineux ou automatisés

Pour les jeux de données de plusieurs gigaoctets ou les chargements récurrents, les scripts et les outils en ligne de commande sont plus fiables que les chargements depuis un navigateur. Les navigateurs peuvent interrompre la session, consommer trop de mémoire ou perdre la progression en cas de coupure réseau.

Pourquoi l’API est plus adaptée aux fichiers volumineux :

• Transferts fiables. Si la connexion est interrompue, vous pouvez relancer le transfert sans recommencer depuis le début.
• Aucune limite de mémoire du navigateur. Les navigateurs ont des difficultés avec les fichiers de plusieurs gigaoctets. Les outils en ligne de commande les gèrent facilement.
• Automatisation. Planifiez des chargements nocturnes, intégrez-les à vos pipelines ETL ou déclenchez-les depuis votre CI/CD.
• Suivi de la progression. Des outils comme curl affichent la progression du transfert en temps réel.
• Chargements delta. Ajoutez automatiquement de nouvelles données selon un calendrier.

Exemple avec curl :

# Upload a Parquet file directly using a presigned URL
curl -X PUT "$PRESIGNED_URL" --upload-file data.parquet

ProcessMind fournit des URL pré-signées qui autorisent les chargements directs vers le stockage cloud. Aucune information d’authentification supplémentaire n’est nécessaire au-delà de votre clé API. Vous pouvez également copier directement l’URL de chargement pré-signée depuis le menu des paramètres du jeu de données dans l’interface ProcessMind.

Consultez la documentation de l’API pour découvrir des exemples complets en Bash, JavaScript et Python, notamment pour obtenir des URL pré-signées, charger des fichiers delta et traiter des jeux de données volumineux par programmation.

Vitesse d’itération du modèle

Lorsque vous affinez votre modèle de processus en renommant des activités, en modifiant les correspondances ou en ajoutant des regroupements, seuls les calculs dépendant du modèle doivent être mis à jour. Les données de base restent en place :

Les modifications du modèle sont rapides, car l’étape initiale de chargement des données, qui augmente avec la taille du jeu de données, est déjà terminée. Seule l’étape d’agrégation dépendant du modèle est relancée, notamment pour les correspondances d’activités, les transitions et les variantes. Pour les jeux de données allant jusqu’à 20 millions d’événements, les modifications du modèle sont terminées en moins de 25 secondes. Même avec 100 millions d’événements, elles prennent moins d’une minute, soit bien moins qu’un prétraitement complet.

Temps de réponse des Dashboards

Une fois vos données chargées, voici les temps de réponse observés pendant l’analyse. Les durées ci-dessous correspondent aux médianes de plusieurs exécutions de benchmark. Chaque composant du Dashboard envoie ses requêtes indépendamment et se charge en parallèle :

Tendances à retenir :

• Statistiques, notamment les décomptes et durées récapitulatifs, restent à environ 0,6 s quelle que soit la taille. Ces requêtes sont fortement optimisées.
• Flux de processus, c’est-à-dire le diagramme de processus, augmente avec la taille du jeu de données, car il calcule les transitions entre toutes les activités.
• Les variantes et les catégories évoluent modérément. Les données préagrégées les maintiennent rapides.
• Le navigateur de données reste rapide grâce à la pagination. Avec des filtres appliqués, il passe sous la seconde.
• L’animation varie selon le nombre de cas actifs visualisés.

À retenir : avec les tailles de jeux de données recommandées, de 1 à 10 millions d’événements, chaque composant du Dashboard répond en moins de 3,5 secondes. Même avec 50 millions d’événements, la plupart des requêtes aboutissent en 2 à 4 secondes lorsque des filtres sont appliqués. Seuls les flux de processus et les vues de catégories non filtrés sur des jeux de données de 50 millions d’événements ou plus atteignent 5 à 6 secondes.

Commencer petit, évoluer progressivement

Voici le conseil le plus important de ce guide : ne commencez pas avec votre plus grand jeu de données.

Les chiffres parlent d’eux-mêmes :

La plupart des organisations constatent que 1 à 5 millions d’événements suffisent largement pour obtenir des analyses concrètes. Le comportement du processus se stabilise bien avant 10 millions d’événements. Au-delà, vous ajoutez surtout des répétitions de schémas déjà observés.

Si votre fichier Parquet de 1 million d’événements, d’une taille de 34 Mo, se charge en 3 secondes et vous fournit la même cartographie de processus que 50 millions d’événements, pourquoi attendre 18 minutes ?

Stratégie de données : trouver la bonne taille

Les chiffres ci-dessus racontent une histoire claire : avec 1 à 5 millions d’événements, les chargements prennent quelques secondes, le prétraitement moins de 2 minutes et les Dashboards répondent en 1 à 2,5 secondes. Avec 50 millions d’événements, vous attendez 20 minutes pour le chargement à 100 Mbit/s et les Dashboards ralentissent à 3 à 6 secondes. L’expérience est très différente.

La vraie question n’est donc pas « à quelle vitesse l’outil fonctionne-t-il ? », mais « de quelle quantité de données ai-je réellement besoin ? ». La réponse est presque toujours inférieure à ce que vous pensez.

Segmentez d’abord, agrégez ensuite

Commencez par analyser un pays, un service ou une ligne de produits.

Il ne s’agit pas de limiter l’analyse, mais de gagner en clarté. Une analyse segmentée produit des résultats plus précis que des moyennes globales.

Pourquoi la segmentation fonctionne :

• Les processus varient selon les régions. Les opérations allemandes suivent des circuits d’approbation différents de ceux des opérations américaines. Le droit du travail français crée des flux de travail RH différents. Les analyser ensemble ajoute du bruit.
• Des parties prenantes différentes, des priorités différentes. Le vice-président de la région EMEA s’intéresse à l’EMEA. Présentez-lui les données de l’EMEA. La vue globale pourra venir ensuite.
• Des itérations plus rapides. Les données d’un seul pays peuvent représenter 500 000 événements au lieu de 10 millions. Vous itérez en quelques minutes, et non en quelques heures.
• Une comparaison intégrée. Après avoir analysé l’Allemagne, faites de même pour la France. Vous pouvez alors comparer.

Exemple : une entreprise européenne de logistique comptant 42 millions d’événements d’expédition répartis dans 8 pays :

• Tout analyser : 42 M d’événements, 9,3 Go, 16 min de téléversement (100 Mbit/s), 2 min de prétraitement
• Analyser uniquement l’Allemagne : 8,5 M d’événements, 1,9 Go, 3 min de téléversement, 1,5 min de prétraitement
• Analyser uniquement les Pays-Bas : 3,1 M d’événements, 690 Mo, 1 min de téléversement, 1 min de prétraitement
• Utiliser le chargement différentiel : téléverser d’abord les données allemandes, puis ajouter celles des Pays-Bas lorsqu’elles sont prêtes

Filtrer le parcours standard

Excluez le parcours standard avant le téléversement. Cette technique peut réduire les jeux de données de 90 à 95 %.

La plupart des processus métier suivent la règle des 80/20. La grande majorité des cas emprunte le parcours standard et aboutit correctement. Si vous recherchez des exceptions, des manquements aux règles de conformité ou des écarts de processus, ces données ne vous sont pas nécessaires.

Exemple : un processus purchase-to-pay comprenant 1,2 million de bons de commande, soit 8,4 M d’événements :

• 1,1 M de commandes (92 %) suivent le parcours standard : créer le bon de commande → approuver → réceptionner les marchandises → facturer → payer
• 96 000 commandes (8 %) présentent des exceptions : rejets, retours, factures en double et approbations manquantes

Si vous analysez des problèmes de conformité, exportez uniquement les cas présentant une exception. Vous réduisez ainsi le volume de 92 %, en passant de 8,4 M d’événements (1,9 Go) à 670 000 événements (150 Mo). Sur une connexion à 100 Mbit/s, le temps de téléversement passe de 3 minutes à 15 secondes. En exportant au format Parquet (15 Mo), vous pouvez même téléverser le fichier en moins de 2 secondes.

Sélection des colonnes : moins, c’est mieux

Chaque colonne exportée mobilise de la bande passante, de l’espace de stockage et du temps de traitement. Sélectionner soigneusement les colonnes constitue l’une des optimisations les plus efficaces à votre disposition.

Ce que vous pouvez exclure :

• Champs de texte longs. Descriptions de commandes, commentaires, notes et champs de texte libre. Un champ de description de 500 caractères sur 5 M d’événements ajoute 2,5 Go à votre fichier.
• Données à caractère personnel (PII). Noms, adresses e-mail et numéros de téléphone. Supprimer les PII réduit la taille du fichier, élimine les risques liés à la vie privée et simplifie la conformité.
• Identifiants redondants. Si vous disposez de OrderId, OrderGUID, OrderReference et LegacyOrderNumber ne sont pas nécessaires.
• Colonnes d’audit. CreatedBy, ModifiedBy, CreatedDate et ModifiedDate. Sauf si vous les analysez spécifiquement, excluez-les.
• Colonnes système. Indicateurs internes, clés de partition et métadonnées techniques.

Exemple : un export SAP de 1,8 M d’événements liés à des bons de commande, comprenant 45 colonnes, a été réduit à 12 colonnes essentielles :

• Taille du fichier : 2,1 Go → 380 Mo (réduction de 82 %)
• Au format Parquet : 380 Mo → 58 Mo (réduction supplémentaire de 85 %)
• Temps de téléversement (100 Mbit/s) : 3,5 min → 6 secondes
• Même valeur analytique

Les colonnes importantes : CaseId, Activity, Timestamp et quelques attributs métier, tels que le statut, le montant, la catégorie et la région. Tout le reste est probablement superflu.

Quand le volume devient déterminant

Certaines questions d’analyse nécessitent réellement de grands jeux de données. Le comprendre vous aide à prendre la bonne décision :

• Détection d’événements rares. Pour trouver des cas limites qui surviennent une fois sur 100 000, vous avez besoin d’une population suffisamment importante pour obtenir un échantillon représentatif. Si vous devez analyser 50 occurrences d’une exception rare qui se produit dans 0,01 % des cas, il vous faut 500 000 cas.
• Mesure des parcours peu fréquents. Des variantes de processus qui surviennent dans 0,1 % des cas peuvent être invisibles dans un échantillon d’un million d’événements, tout en étant significatives dans une population de 50 M d’événements.
• Conformité et audit. Certaines réglementations exigent de couvrir l’intégralité de la population. L’échantillonnage n’est alors pas acceptable.
• Analyse des tendances sur plusieurs années. Comparer le T1 2024, le T1 2025 et le T1 2026 nécessite des données couvrant les trois périodes. Utilisez le chargement différentiel pour les constituer progressivement.

Si vous devez traiter plus de 50 M d’événements, préparez votre environnement : utilisez le format Parquet, qui réduit un fichier CSV de 11 Go à 1,7 Go et accélère le prétraitement ; utilisez l’API pour des transferts fiables ; et privilégiez une connexion réseau rapide lorsque cela est possible. Après ce premier chargement, les Dashboards restent rapides.

Conserver un modèle et une interface rapides

Les sections précédentes portaient sur le volume de données. L’autre aspect de la réactivité dépend de la manière dont le modèle et les Dashboards sont conçus :

• Simplifiez le modèle. Divisez les grands processus en sous-processus modulaires ; un canevas comportant un millier d’éléments visibles est lent à afficher et impossible à lire. Lancez la mise en page automatique après les changements structurels.
• Sélectionnez les Dashboards avec discernement. Chaque graphique et chaque tuile doivent être calculés. Conservez les graphiques qui servent réellement à agir et placez les autres dans leur propre Dashboard, au lieu de tout empiler dans une seule vue.
• Adaptez le graphique au jeu de données. Pour les grands jeux de données, évitez les visualisations les plus coûteuses en ressources, comme les graphiques circulaires détaillés ou les répartitions comportant de nombreuses catégories, et privilégiez les graphiques synthétiques.
• Appliquez les filtres avec mesure. Les filtres sont peu coûteux individuellement, mais leur combinaison peut l’être. Conservez l’ensemble qui répond à votre question, puis supprimez-le.
• Surveillez l’animation. Le coût de l’animation augmente avec le nombre de cas actifs. Réduisez la vitesse ou désactivez les traînées et les effets lorsque vous avez uniquement besoin de voir le flux. Consultez Animation du processus.
• Archivez et revenez-y ultérieurement. Retirez les anciens jeux de données et processus de l’espace de travail actif, puis utilisez la simulation avec les métriques temporelles pour repérer les goulots d’étranglement à corriger, plutôt que d’optimiser tout en même temps.

Étapes suivantes

La meilleure façon de comprendre les performances du Process Mining consiste à les évaluer avec vos propres données.

1. Commencez par un échantillon. Exportez 1 M d’événements issus d’une période récente au format Parquet. Téléversez-les. Créez votre premier modèle. Observez la rapidité avec laquelle vous pouvez itérer.

2. Appliquez les techniques de ce guide. Utilisez des formats en colonnes. Filtrez les exceptions. Segmentez par région. Supprimez les colonnes inutiles. Chaque optimisation renforce la précédente.

3. Augmentez progressivement le volume. Une fois votre processus compris avec 1 M d’événements, déterminez si vous en avez besoin de davantage. Généralement, ce n’est pas nécessaire. Lorsque c’est le cas, utilisez le chargement différentiel pour ajouter les données plutôt que de les téléverser à nouveau.

Démarrez l’essai gratuit et vérifiez ces résultats par vous-même. Pour vous aider à dimensionner votre jeu de données ou à optimiser vos exports, contactez-nous. Nous avons aidé des centaines d’organisations à trouver le juste équilibre entre volume de données et vitesse d’analyse.