Sur cette page
> ressources > documentation > dépannage > Résolution des problèmes liés aux données

Résolution des problèmes liés aux données

Résolution des problèmes liés aux données

Les problèmes de données se manifestent de manière précise : cas qui se désagrègent, événements dans le mauvais ordre, étapes manquantes ou chiffres impossibles. Cette page remonte du symptôme à la cause, puis de la cause à la solution, dans ProcessMind lorsqu’un réglage suffit, et dans l’extrait lorsque rien d’autre ne permet de corriger le problème.

Pour connaître l’ensemble du flux de préparation, notamment à quoi ressemblent de bonnes données et comment les obtenir, consultez Nettoyage et préparation des données. Pour découvrir les contrôles effectués par la plateforme sur vos données, consultez Qualité des données.

Premiers contrôles

Avant d’examiner le fichier source, regardez ce que ProcessMind vous indique déjà :

  • La liste rouge au-dessus des panneaux. Dans l’onglet Général du jeu de données, une liste rouge indique le blocage : ID de cas, Activité ou Heure de fin manquant, activités sans données, attributs sans valeurs ou incompatibilité entre un fichier importé de nouveau et le type de processus dans lequel il a été chargé. Commencez par là.
  • badge et panneau de qualité. Le score couvre les valeurs manquantes, les valeurs incohérentes et les problèmes d’horodatage ; le panneau détaille la fraîcheur, la couverture des attributs et l’analyse des activités.
  • Recommandations de données par l’IA. Une analyse du jeu de données répertorie les problèmes détectés et suggère des associations ainsi que des corrections.
  • Attributs du jeu de données. Définissez le nom d’affichage, le type de données et le format d’horodatage, ou masquez une colonne, sans rien réexporter.

La plupart des problèmes concernent trois champs

ID de cas identifie l’instance de processus, Activité nomme l’étape et Heure de fin la situe sur la chronologie. Heure de début, Utilisateur, Coût et tCO₂e apportent un contexte supplémentaire. Associez l’un des champs requis à la mauvaise colonne et tout ce qui suit devient incorrect.

Symptômes dans le graphe de processus

Les cas sont répartis entre plusieurs cas

Vous constatez : une instance de processus apparaît sous la forme de nombreux cas courts, comportant chacun une ou deux étapes, et le graphe se réduit à une ligne d’activités.

Pourquoi : la colonne associée à ID de cas identifie un élément plus petit que l’instance de processus, par exemple une ligne de commande, un numéro de facture ou un numéro de document provenant d’un système.

Correction : associez la colonne qui identifie l’instance complète : la commande, le ticket ou la demande d’indemnisation. Si aucune colonne ne permet de le faire, l’unification doit être réalisée en amont. Regroupez les identifiants dans SQL ou dans votre tâche ETL afin que chaque événement d’une même instance porte le même ID de cas, puis importez de nouveau le fichier. Les conventions de nommage propres à chaque système sont décrites dans Où trouver les données.

Les événements sont dans le mauvais ordre

Vous constatez : des activités qui se produisent plus tard apparaissent avant celles qui se produisent plus tôt, par exemple une facture datée avant sa commande.

Pourquoi : trois causes reviennent souvent. L’horodatage a été interprété avec un format incorrect, par exemple une 03/04/2025 valeur lue comme le 4 mars au lieu du 3 avril. Des événements provenant de systèmes situés dans des fuseaux horaires différents ont été mélangés sans conversion. Ou la mauvaise colonne a été associée au champ temporel.

Correction : vérifiez le format dans les attributs du jeu de données et confirmez que le type est Timestamp, et non du texte. Convertissez toutes les sources vers un même fuseau horaire avant de combiner les exportations, triez chaque cas selon son horodatage et vérifiez quelques cas de bout en bout.

Des étapes sont manquantes

Vous constatez : le graphe ignore une étape qui a bien lieu.

Pourquoi : l’étape ne laisse aucune trace dans les données, par exemple une approbation téléphonique ou une signature papier, l’activité n’a jamais été associée ou un filtre l’a retirée de l’affichage.

Correction : gardez visibles les étapes existantes mais non enregistrées en marquant l’activité comme une étape data flow through, puis associez les autres avec Association et dissociation des activités. Les activités non associées apparaissent en transparence, avec des connexions en pointillés. Vérifiez ensuite quels filtres sont actifs.

Les cas ne se terminent jamais

Vous constatez : de nombreux cas s’arrêtent sans atteindre d’événement de fin.

Pourquoi : l’exportation s’arrête à une date alors que les cas sont encore en cours, le modèle ne comporte aucun événement de fin ou l’activité de clôture ne figure pas dans le jeu de données.

Correction : ajoutez au modèle un véritable événement de fin, ou acceptez les cas ouverts et excluez-les de l’analyse temporelle, car les métriques temporelles ne comptent que les cas clôturés. Un cas qui n’est pas terminé ne constitue pas une erreur de données.

Les volumes semblent gonflés

Vous constatez : une activité est réalisée à une fréquence étonnamment élevée, ou le nombre de cas dépasse celui des rapports métier.

Pourquoi : des lignes en double, le même événement ayant été enregistré deux fois par une intégration ou une extraction répétée.

Correction : supprimez les doublons selon l’ID de cas, l’activité et l’horodatage avant l’importation ; le flux de préparation explique généralement l’origine des extractions dupliquées.

La carte est encombrée

Vous constatez : des centaines d’activités, dont la plupart sont techniques.

Pourquoi : les connexions, les nouvelles tentatives et les tâches en arrière-plan figurent dans le même extrait que les étapes métier.

Correction : masquez les attributs que vous n’analysez pas, filtrez les événements qui ne font pas partie du processus et regroupez les événements de bas niveau dans l’activité à laquelle ils appartiennent. La limite entre le niveau de détail utile et le bruit relève d’une décision des experts du processus.

Les données de plusieurs systèmes ne concordent pas

Vous constatez : le processus présente des lacunes là où un système aurait dû apporter des données.

Pourquoi : les systèmes sont extraits à des moments différents, utilisent des libellés différents pour une même étape ou l’un des extraits n’a pas été récupéré.

Correction : alignez les fenêtres d’extraction et le vocabulaire des activités avant de combiner les données, puis attribuez à chaque jeu de données son rôle de principal ou de comparaison au lieu de concaténer des fichiers qui ne concordent pas.

Symptômes dans le jeu de données

L’importation est refusée

Vous constatez : l’importation se termine par une erreur ou le fichier est chargé dans une seule colonne.

Pourquoi : le fichier ne respecte pas l’une des exigences de structure. Les problèmes les plus courants sont l’absence de ligne d’en-tête, qui doit se trouver sur la première ligne, les lignes vides entre les entrées, les nombres stockés comme du texte et les fichiers Excel dont les données se trouvent dans la deuxième feuille, car seule la première feuille est lue.

Correction : placez l’en-tête sur la ligne 1, supprimez les lignes vides, vérifiez que les nombres sont bien des nombres et déplacez les données d’événements vers la première feuille. Les séparateurs et les guillemets des fichiers CSV, TSV et TXT sont détectés automatiquement. Un résultat dans une seule colonne signifie généralement que le fichier ne peut pas être interprété. Réexportez-le au format CSV ou Parquet.

Les colonnes ou les types sont incorrects

Vous constatez : une colonne est manquante ou un horodatage est traité comme du texte.

Pourquoi : le fichier a changé depuis la dernière importation ou le type a été détecté incorrectement.

Correction : définissez manuellement le type et le format des données ou masquez la colonne. Après avoir remplacé un fichier, vérifiez dans la liste rouge qu’il n’existe pas d’incompatibilité entre le nouveau fichier et le jeu de données dans lequel il a été chargé.

Les horodatages ne sont pas reconnus

Vous constatez : la colonne d’horodatage est vide ou les durées sont beaucoup trop longues.

Pourquoi : un format inhabituel, un ordre du jour et du mois propre aux paramètres régionaux, une précision mixte, avec des secondes et des millisecondes dans une même colonne, ou des conversions de fuseau horaire appliquées deux fois.

Correction : définissez explicitement le format dans les attributs du jeu de données, séparez les exportations à précision mixte à la source et utilisez un seul fuseau horaire avant l’importation.

Les valeurs sont vides

Vous constatez : la couverture des attributs dans le panneau de qualité présente des lacunes ou un graphique comporte une catégorie null.

Pourquoi : le système source ne capture pas la valeur pour chaque cas ou l’exportation a supprimé les champs vides.

Correction : comblez les lacunes à la source lorsque cela est possible et utilisez les fonctions de gestion des valeurs nulles dans un attribut calculé lorsqu’une valeur vide peut être remplacée par une valeur par défaut pertinente.

Les noms d’activité ne concordent pas

Vous constatez : « Approve Order » et « Order Approval » sont répertoriées comme deux activités ayant le même sens, ou une même étape porte un nom différent selon le pays.

Pourquoi : chaque système source utilise son propre libellé pour désigner le même travail.

Correction : mettez-vous d’accord sur un nom pour chaque étape, puis normalisez les valeurs dans l’extrait ou ajoutez un attribut calculé qui associe les variantes à un même nom, avant d’associer l’activité à partir de ce nom.

Symptômes dans les chiffres

Les moyennes semblent trop faibles

Vous constatez : une durée moyenne des cas que l’entreprise ne considère pas comme réaliste.

Pourquoi : les métriques temporelles ne comptent que les cas clôturés, les cas inachevés sont donc exclus, et les cas terminés sont souvent les plus rapides, surtout sur une période récente.

Correction : comparez des éléments comparables. Limitez la période aux cas qui ont eu le temps de se terminer, lisez les définitions de Métriques temporelles avant de tirer des conclusions à partir d’une seule moyenne et examinez la distribution plutôt que la moyenne.

Les moyennes sont dominées par les valeurs atypiques

Vous constatez : des moyennes très supérieures à celles d’un cas type.

Pourquoi : quelques cas extrêmes tirent la moyenne vers le haut. Il s’agit parfois de véritables exceptions, parfois d’erreurs de données.

Correction : examinez la queue des cas lents, avec le P90 comparé à la médiane, plutôt que la moyenne, vérifiez si les cas extrêmes sont réels et excluez uniquement ce qui est effectivement incorrect. Une exception rare mais réelle constitue une information utile. Métriques temporelles explique chaque mesure.

Une comparaison n’affiche rien

Vous constatez : un jeu de données de comparaison indique Absent (0 cas, couverture de 0 %).

Pourquoi : les filtres actifs ou la période sélectionnée ne contiennent aucun cas pour ce jeu de données, ou ses activités ne sont pas associées au modèle.

Correction : élargissez la période, vérifiez l’association du jeu de données de comparaison et confirmez quel jeu de données est principal.

Quand le volume de données est en cause

Certains problèmes ne sont pas des erreurs de données, mais des problèmes d’échelle :

  • Importations lentes : préférez Parquet ou ORC, et XLSB plutôt que XLSX pour les fichiers Excel ; consultez Formats de données pris en charge.
  • Fichiers qui grossissent : ajoutez les nouvelles périodes avec une importation incrémentielle (delta) au lieu de remplacer l’intégralité du fichier.
  • Analyse lente : supprimez les colonnes que personne n’analyse, filtrez le chemin nominal lorsque vous recherchez des exceptions et examinez une seule période ou une seule région à la fois. Le guide des performances montre le coût des volumes de données.
  • Jeux de données qui peuvent être archivés : archivez ce que vous n’analysez plus afin que l’espace de travail conserve les données sur lesquelles vous agissez réellement.

Corriger le problème à la source

Chaque correction effectuée dans ProcessMind évite un aller-retour, mais certains problèmes ne disparaissent qu’en amont : système source manquant, fuseaux horaires mélangés ou identifiants qu’aucune exportation n’unifie. Ces corrections doivent être apportées dans l’extrait et, si le problème se répète, dans le système qui le produit. Consultez Où trouver les données pour les méthodes propres à chaque système et ETL pour le Process Mining pour les pratiques qui garantissent la fiabilité d’un extrait.

Vous êtes toujours bloqué ?

Si les contrôles ci-dessus n’expliquent pas ce que vous observez, contactez l’équipe d’assistance en indiquant le nom du jeu de données, le cas que vous examinez, ce à quoi vous vous attendiez et ce que vous observez à la place. Une capture du graphe et une capture du panneau de qualité permettent généralement de résoudre le problème plus rapidement qu’une description.

Sujets associés