La qualification des données est essentielle
Wikipedia énumère sept étapes pour un processus d’analyse des données : les besoins en données, la collecte des données, le traitement des données, le nettoyage des données, l’analyse exploratoire des données, la modélisation des données, et enfin la génération des résultats de production. Lorsque Lokad prévoit les stocks, optimise les prix, ou chaque fois que nous abordons une forme d’optimisation commerciale, notre processus est très similaire à celui décrit ci-dessus. Cependant, il existe une autre étape vitale qui représente généralement plus de la moitié de tous les efforts appliqués par l’équipe de Lokad et qui ne fait même pas partie de la liste ci-dessus. Cette étape est la qualification des données.
Maintenant que le “Big Data” est devenu un mot à la mode, de nombreuses entreprises essaient de faire plus avec leurs données. La qualification des données est probablement la deuxième cause la plus fréquente d’échec des projets, juste après des objectifs commerciaux peu clairs ou peu judicieux - ce qui se produit chaque fois qu’une initiative part de la “solution” plutôt que de partir du “problème”. Éclairons cette étape mystérieuse de “qualification des données”.
Les données en tant que sous-produit des applications métier
La grande majorité des logiciels métier sont conçus pour aider à exploiter les entreprises : le système de point de vente permet aux clients de payer ; le système de gestion d’entrepôt permet de prélever et de stocker les produits ; le logiciel de visioconférence permet aux personnes de mener leurs réunions en ligne, etc. Ces logiciels peuvent également produire des données, mais les données ne sont qu’un sous-produit secondaire de l’objectif principal de ce logiciel.
Les systèmes mentionnés sont conçus pour exploiter l’entreprise, et par conséquent, chaque fois qu’un praticien doit choisir entre de meilleures opérations ou de meilleures données, de meilleures opérations seront toujours toujours privilégiées. Par exemple, si un code-barres échoue lorsqu’il est scanné au point de vente de votre hypermarché local, le caissier choisira invariablement un produit qui a le même prix et le scannera deux fois ; parfois, il a même une liste de codes-barres rassemblés sur une feuille de papier. Le caissier a raison : la priorité n°1 est de permettre au client de payer quoi qu’il arrive. Générer des enregistrements de stock précis n’est pas un objectif immédiat par rapport au besoin urgent de servir une file de clients.
On pourrait soutenir que le problème de numérisation des codes-barres est en réalité un problème de nettoyage des données. Cependant, la situation est assez subtile : les enregistrements restent précis dans une certaine mesure, car le montant facturé au client reste correct, tout comme le nombre d’articles dans le panier. Filtrer naïvement tous les enregistrements suspects ferait plus de mal que de bien pour la plupart des analyses.
Pourtant, nous constatons que trop souvent, les entreprises - et leurs fournisseurs de logiciels également - ignorent avec enthousiasme ce schéma fondamental pour presque toutes les données commerciales générées, passant directement du traitement des données au nettoyage des données.
La qualification des données concerne la sémantique des données
L’objectif de l’étape de qualification des données est de clarifier et de documenter en détail la sémantique des données. La plupart du temps, lorsque les (grandes) entreprises envoient des fichiers de données tabulaires à Lokad, elles nous envoient également une feuille Excel, où chaque colonne trouvée dans les fichiers reçoit une brève ligne de documentation, généralement comme suit : Prix : le prix du produit. Cependant, une telle ligne de documentation succincte laisse une myriade de questions ouvertes :
- quelle est la devise applicable au produit ?
- s’agit-il d’un prix avec ou sans taxe ?
- y a-t-il une autre variable (comme une remise) qui affecte le prix réel ?
- est-ce vraiment le même prix pour le produit sur tous les canaux ?
- la valeur du prix est-elle censée avoir un sens pour les produits qui ne sont pas encore vendus ?
- existe-t-il des situations particulières comme des zéros pour refléter des valeurs manquantes ?
Les dates sont également d’excellents candidats pour des ambiguïtés sémantiques. Lorsqu’une table commandes contient une colonne date, la date-heure peut se référer à l’un des éléments suivants :
- la validation du panier
- l’enregistrement du paiement
- la compensation du paiement
- la création de la commande dans le logiciel de comptabilité
- l’expédition
- la livraison
- la clôture de la commande
Cependant, une telle liste restreinte ne couvre guère les bizarreries réellement rencontrées dans des situations réelles. Récemment, par exemple, en travaillant pour l’une des plus grandes entreprises en ligne européennes, nous avons réalisé que les dates associées aux bons de commande n’avaient pas la même signification en fonction du pays d’origine des usines fournisseurs. Les fournisseurs européens expédiaient par camion et la date reflétait l’arrivée dans l’entrepôt ; tandis que les fournisseurs asiatiques expédiaient par bateau et la date reflétait l’arrivée au port. Ce petit “twist” représentait généralement plus de 10 jours de différence dans le calcul du délai d’approvisionnement.
Pour les ensembles de données liés à l’activité commerciale, la sémantique des données dépend presque toujours des processus et des pratiques de l’entreprise sous-jacente. La documentation relative à ces processus, lorsqu’elle existe, se concentre généralement sur ce qui intéresse la direction ou les auditeurs, mais très rarement sur la myriade de petits éléments qui existent dans le paysage informatique de l’entreprise. Pourtant, le diable se cache dans les détails.
La qualification des données n’est pas le nettoyage des données
Le nettoyage des données a le plus de sens dans les sciences expérimentales où certains points de données (valeurs aberrantes) doivent être supprimés car ils fausseraient incorrectement les expériences. Par exemple, les mesures de graphique dans une expérience d’optique pourraient simplement refléter un défaut du capteur optique plutôt que quelque chose de réellement pertinent pour l’étude.
Cependant, ce processus ne reflète pas ce qui est généralement nécessaire lors de l’analyse des données commerciales. Les valeurs aberrantes peuvent être rencontrées lorsqu’il s’agit des restes d’une récupération de base de données ratée, mais le plus souvent, les valeurs aberrantes sont marginales. L’intégrité (du point de vue commercial) de la grande majorité des bases de données actuellement en production est excellente. Des entrées erronées existent, mais la plupart des systèmes modernes font un bon travail pour prévenir les plus fréquentes et sont assez efficaces pour les corriger par la suite. Cependant, la qualification des données est très différente dans le sens où l’objectif n’est ni de supprimer ni de corriger les points de données, mais plutôt de mettre en lumière les données dans leur ensemble, de sorte que l’analyse ultérieure ait vraiment du sens. La seule chose qui est “modifiée” par le processus de qualification des données est la documentation originale des données.
La qualification des données représente la majeure partie des efforts
Lors de la réalisation de dizaines de projets axés sur les données dans les domaines du commerce, de l’aérospatiale, de l’hôtellerie, de la bioinformatique et de l’énergie, nous avons constaté que la qualification des données a toujours été l’étape la plus exigeante du projet. Les algorithmes d’apprentissage automatique peuvent sembler sophistiqués, mais tant que l’initiative reste dans les limites bien connues des problèmes de régression ou de classification, le succès en apprentissage automatique dépend principalement des connaissances préalables dans le domaine. Il en va de même pour le traitement des Big Data.
Les problèmes de qualification des données sont insidieux car on ne sait pas ce qui manque : il s’agit de l’écart sémantique entre la sémantique “réelle” telle qu’elle devrait être comprise en termes de données produites par les systèmes en place, et la sémantique “réelle” telle que perçue par les personnes effectuant l’analyse des données. Ce que vous ne savez pas peut vous nuire. Parfois, l’écart sémantique invalide complètement toute l’analyse.
Nous constatons que la plupart des professionnels de l’informatique sous-estiment largement la profondeur des particularités qui accompagnent la plupart des ensembles de données commerciales réelles. La plupart des entreprises n’ont même pas une ligne complète de documentation par champ de table. Pourtant, nous constatons généralement que même avec une demi-page de documentation par champ, la documentation est encore loin d’être exhaustive.
L’un des (nombreux) défis auxquels Lokad est confronté est qu’il est difficile de facturer quelque chose qui n’est même pas perçu comme un besoin en premier lieu. Ainsi, nous effectuons fréquemment des travaux de qualification des données sous le prétexte de tâches plus nobles telles que “l’optimisation d’algorithmes statistiques” ou des tâches similaires qui sonnent scientifiques.
La réalité du travail est cependant que la qualification des données est non seulement intensive du point de vue des ressources humaines, mais c’est aussi une tâche vraiment difficile en soi. C’est un mélange entre la compréhension du métier, la compréhension de la manière dont les processus se répartissent sur de nombreux systèmes - dont certains sont invariablement de type hérité - et le comblement de l’écart entre les données telles qu’elles sont et les attentes du pipeline d’apprentissage automatique.
La plupart des entreprises investissent très peu dans la qualification des données. En plus d’être un défi sous-estimé, investir dans la qualification des données ne donne pas lieu à une démonstration spectaculaire ou même à des chiffres concrets. Par conséquent, les entreprises se précipitent vers les étapes ultérieures du processus d’analyse des données pour se retrouver enlisées car rien ne fonctionne vraiment comme prévu. Il n’y a pas de solution miracle pour une compréhension réelle des données.
