La qualification des données est critique
Wikipédia énumère sept étapes pour un processus d’analyse de données : exigences de données, collecte de données, traitement de données, nettoyage de données, analyse exploratoire des données, modélisation des données, et enfin la génération des résultats en production. Lorsqu’il s’agit que Lokad prévoit les stocks, optimise les prix, ou chaque fois que nous abordons une forme d’optimisation du commerce, 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 l’effort généralement appliqué 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, une myriade d’entreprises essaie de tirer davantage parti de leurs données. La qualification des données est probablement la deuxième cause la plus importante d’échecs de projets, juste après des objectifs d’affaires flous ou inappropriés – ce qui se produit chaque fois qu’une initiative part de la “solution” plutôt que du “problème”. Éclaircissons cette mystérieuse étape de la “qualification des données”.
Les données comme sous-produit des applications métier
La grande majorité des logiciels d’entreprise est conçue pour aider à faire fonctionner les entreprises : le système de Point-Of-Sale est là pour permettre aux clients de payer ; le système de gestion d’entrepôt est là pour préparer et stocker les produits ; le logiciel de web conferencing permet aux gens de tenir leurs réunions en ligne, etc. Ce type de logiciel peut également produire des données, mais celles-ci ne sont qu’un sous-produit secondaire de l’objectif principal de ce logiciel.
Les systèmes mentionnés sont conçus pour faire fonctionner 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 privilégiées. Par exemple, si un code-barres ne fonctionne pas lorsqu’il est scanné au point de vente de votre hypermarché local, le caissier choisira invariablement un produit qui se trouve avoir le même prix et le scannera deux fois ; parfois, il dispose même d’un mémo rassemblant plusieurs codes-barres sur un bout de papier. Le caissier a raison : la priorité numéro 1 est de permettre au client de payer quoi qu’il arrive. Générer des relevés de stocks précis n’est pas un objectif immédiat comparé au besoin urgent de servir une file de clients.
On pourrait soutenir que le problème du scan des codes-barres relève en réalité d’un problème de nettoyage des données. Cependant, la situation est assez subtile : les enregistrements restent, dans une certaine mesure, précis puisque le montant facturé au client demeure correct et de même que 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 observons que trop souvent, les entreprises – et leurs vendeurs de logiciels également – ignorent avec enthousiasme ce schéma fondamental pour presque toutes les données d’entreprise 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 profondeur la sémantique des données. La plupart du temps, lorsque de grandes entreprises nous envoient des fichiers de données tabulaires à Lokad, elles nous transmettent également une feuille Excel, où chaque colonne présente dans les fichiers reçoit une brève ligne de documentation, typiquement comme : Prix : le prix du produit. Cependant, une documentation aussi succincte laisse une myriade de questions en suspens :
- quelle est la monnaie applicable au produit ?
- s’agit-il d’un prix avec ou sans taxe ?
- existe-t-il une autre variable (comme une remise) qui influe sur 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 ?
- y a-t-il des cas particuliers, comme des zéros pour refléter des valeurs manquantes ?
Les dates sont également d’excellents candidats aux ambiguïtés sémantiques lorsqu’une table orders contient une colonne date, la date peut faire référence au moment de :
- la validation du panier
- l’enregistrement du paiement
- l’encaissement 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 couvre à peine les bizarreries réelles rencontrées dans des situations concrètes. Récemment, par exemple, en travaillant pour l’une des plus grandes entreprises en ligne européennes, nous avons constaté que les dates associées aux bons de commande n’avaient pas la même signification selon le pays d’origine des usines fournisseurs. Les fournisseurs européens expédiaient avec des camions et la date reflétait l’arrivée à l’entrepôt ; tandis que les fournisseurs asiatiques expédiaient, eh bien, par bateau, et la date reflétait l’arrivée au port. Ce petit détail représentait généralement plus de 10 jours de différence dans le calcul du lead time.
Pour les ensembles de données liés aux entreprises, la sémantique des données dépend presque toujours des processus et pratiques sous-jacents de l’entreprise. La documentation relative à ces processus, quand 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 (ou assainissement) 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 les expériences. Par exemple, les mesures d’un graphique dans une expérience en 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 de données d’entreprise. Des valeurs aberrantes peuvent être rencontrées lors du traitement des résidus d’une récupération de base de données ratée, mais dans l’ensemble, ces valeurs sont marginales. L’intégrité (du point de vue métier) 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 cas les plus fréquents, et sont assez performants lorsqu’il s’agit de les corriger par la suite. Cependant, la qualification des données est très différente en ce sens que l’objectif n’est ni de supprimer ni de corriger des points de données, mais plutôt d’éclairer l’ensemble des données, afin que l’analyse subséquente ait vraiment un sens. La seule chose qui est “altéré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 de l’effort
En travaillant sur des dizaines de projets axés sur les données liés au commerce, à l’aérospatiale, à l’hôtellerie, à la bio-informatique, à l’énergie, nous avons observé que la qualification des données a toujours été l’étape la plus exigeante du projet. Les algorithmes de machine learning 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 du machine learning est en grande partie une question de connaissance préalable du domaine. Il en va de même pour le traitement du Big Data.
Les problèmes de qualification des données sont insidieux car vous ignorez ce qui vous échappe : c’est l’écart sémantique entre la sémantique « vraie » 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 qu’elle est perçue par les personnes effectuant l’analyse des données. Ce que vous ignorez peut vous nuire. Parfois, l’écart sémantique invalide complètement l’analyse dans son ensemble.
Nous constatons que la plupart des praticiens IT sous-estiment largement la profondeur des particularités qui accompagnent la plupart des ensembles de données d’entreprise réels. La plupart des entreprises ne disposent même pas d’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 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 relançons fréquemment le travail de qualification des données sous l’apparence de tâches plus nobles telles que le « réglage d’algorithmes statistiques » ou des tâches similaires à consonance scientifique.
La réalité du travail, cependant, est que la qualification des données n’est pas seulement intensive en termes de main-d’œuvre, c’est aussi une tâche véritablement difficile en soi. C’est un mélange entre la compréhension de l’entreprise, la compréhension de la manière dont les processus se déploient sur de nombreux systèmes – certains d’entre eux étant invariablement de type legacy – et la réduction de l’écart entre les données à la sortie et les attentes du pipeline de machine learning.
La plupart des entreprises investissent largement en deçà de ce qu’il faudrait en qualification des données. En plus d’être un défi sous-estimé, investir des talents dans la qualification des données ne se traduit pas par une démo tape-à-l’œil ni même par des chiffres concrets. En conséquence, les entreprises se précipitent vers les étapes ultérieures du processus d’analyse des données pour se retrouver à patauger dans de la mélasse, car rien ne fonctionne vraiment comme prévu. Il n’existe pas de solution miracle pour une compréhension réelle des données.
