La gestion des données n’est pas toujours la partie la plus amusante de la science des données. Elle inclut plusieurs étapes essentielles qui nécessitent du temps et qui sont aussi à la source de la génération de valeur.
Dans cet article, je vous livre ma méthodologie pour s’attaquer à un projet data, basé sur les bonnes pratiques de l’industrie et sur mon expérience.
Avant de se lancer dans la mise en route d’un nouvel algorithme prédictif avec lequel nous pensons qu’il pourra prédire avec plus de précision le taux de décrochage de nos contacts, nous devons nous assurer que nous avons les données nécessaires, que nous avons modifié ou supprimé toutes les valeurs ou observations problématiques, et que nous avons transformé ces informations en un jeu de données avec lequel nous allons pouvoir travailler.
💡 Quelle meilleure façon de procéder qu’avec une liste pratique couvrant la collection des données depuis des sources externes, la compréhension du problème à résoudre, les étapes de transformation et la documentation de l’ensemble du process ?
Au cours d’un projet data, les données initiales peuvent provenir de plusieurs types de sources : internes ou externes, privées ou publiques, brutes ou retraitées.
Tout le monde essaye de maintenir un niveau de qualité acceptable mais par expérience il est préférable de toujours valider les données même si votre interlocuteur ou fournisseur vous assure que tout est en ordre.
Le temps passé à ces vérifications n’est pas perdu. Si des incohérences sont repérées, mieux vaut qu’elles le soient au début du projet qu’en cours. Et si tout semble cohérent, cette étape nous aura permis de commencer à nous familiariser avec la donnée.
La vérification du fonctionnement des systèmes permettant la récupération des données que ce soit un serveur FTP (File Transfer Protocol) ou une API (Application Programming Interface) ou même via email est essentielle. Il s’agira pour cette étape de s’assurer que les identifiants et mots de passe sont corrects, que les paramètres de connexion fonctionnent et que les accès sont opérationnels.
Lorsque vous avez des échéances à communiquer à votre client, vous serez en meilleure position si vous savez qu’un de votre fournisseur a pris du retard sur la mise en place de son API.
Sur le même thème que précédemment : se méfier des systèmes des autres.
Si vous travaillez à partir de templates ou si vous reprenez les notes ou le code d’autres personnes, assurez-vous d’y revenir après avoir travaillé un certain temps sur votre projet. Une fois que vous serez plus familiarisé avec le projet, les données et les transformations, vous remarquerez des choses à corriger ou à optimiser et peut-être des éléments que vous avez manqué la première fois.
Lorsque vous commencez à travailler sur un projet data, il est souvent fort probable que vous travailliez sur un sujet que vous ne connaissez pas suffisamment. Par exemple, le jargon pour le B2B (business to business) n’est pas le même que pour le B2C (business to customer). Une entreprise de retail n’a pas les mêmes données qu’une autre dans l'événementiel ou bien l’assurance.
Certaines informations peuvent être trouvées sur Internet, dans d'autres cas, vous devrez vous plonger dans les données de votre projet ou les données associées (référentiel produit, données de géolocalisation). Enfin n’oubliez pas votre client. Il fait appel à votre expertise de la donnée : faites appel à son expertise du domaine !
La familiarité avec le domaine est une clé essentielle tout au long du processus. Cette connaissance inestimable s’applique dans les traitements et les vérifications sur les données, jusqu’à la présentation de la solution finale au client.
Quelles sont les questions auxquelles vous essayez de répondre avec ces données ? Comment allez-vous y répondre ? Allez-vous exécuter des modèles et présenter les résultats lors d'une réunion avec le client, ou leur envoyer des fichiers csv, ou écrivez-vous un algorithme qui s'exécutera en production ?
Savoir ce que vous devez produire vous aidera à décider quoi faire des données : comment les préparer, que faire des données manquantes ou dans quel format vous voulez que vos données soient après toutes les transformations.
L’exploration des données est une étape importante du process et sera répété plusieurs fois. Elle permet de continuer à se familiariser avec les données avec plus de granularité.
Voici quelques questions pour démarrer :
Vous pouvez aussi examiner des échantillons aléatoires pour voir à quoi ressemblent les données. Cela vous permettra d’affiner vos choix, notamment ceux du modèle de données et des types de données que vous allez attribuer.
La préparation des données passe par cette étape de nettoyage qui n’est pas forcément la plus facile. Il s’agit de gérer les valeurs manquantes, les valeurs aberrantes, les doublons.
Les choix de traitement ont des conséquences sur les données et donc sur la qualité des analyses et modélisations qui seront faites en aval. Elles peuvent être immédiate et visible ou différées et camouflées ou tout autre combinaison. Une bonne connaissance des données initiales, du domaine et de l’activité de votre client peut vous épargner sur ces traitements beaucoup de peine par la suite.
Lors de la transformation ou la fusion des données, il est important de toujours s'arrêter et de vérifier que le résultat correspond bien aux attentes. Une simple vérification sur le nombre de colonnes ou de lignes attendues est un bon départ.
Il peut être intéressant de prendre quelques exemples et de vérifier manuellement que les résultats sont corrects. Cela peut être ennuyeux mais beaucoup moins ennuyeux que de se rendre compte d'une erreur après la mise en production.
Dans d’autres cas, même si les transformations sont correctes, elles ne signifient pas nécessairement ce que vous pensez qu'elles font. Par conséquent, il est très important de les valider et de poser des questions si les calculs ne correspondent pas à ce que vous voyez.
Et il est aussi possible que ce soit la validation qui soit suspecte. Rester critique dans cette étape de validation des transformations permet de s’assurer que les données produites sont cohérentes et exploitables pour la suite.
Lorsque vous tentez des opérations complexes sur des jeux de données conséquent, n'essayez pas d'élaborer les algorithmes de nettoyage et de transformation sur l'ensemble des données disponibles. Économisez plutôt votre énergie et votre temps et appliquez vos traitements en fonctionnant avec des prototypes de jeu de données qui rassemblent des exemples de cas d'utilisation pertinents.
Une fois que cela fonctionne, essayez-le sur les données réelles, et comme évoqué précédemment, assurez-vous de valider vos résultats.
La documentation est pour moi l’un des éléments qui vous fera sortir du lot et qui vous permettra de gagner en efficacité. Lorsque l’on se lance dans un projet data, il y a beaucoup de demandes qui arrivent au fur et à mesure de l’avancement, les livrables peuvent changer, une spécificité du domaine inconnue au départ peut induire de repenser la transformation de la donnée ou le client demande après quelques mois en production de lui rappeler les règles de déduplication. Dans tous ces cas et bien d’autres encore, une documentation détaillée vous fera gagner un temps précieux.
🔎 Par expérience personnelle, en plus du cahier des charges incontournable ou du dictionnaire de données, je fais au mieux pour maintenir un document de log répertoriant toutes les informations rencontrées, les liens vers des données pertinentes, les questions du client et les changements qui ont été effectués avec leur justification. Il n’est pas nécessaire de faire un document présentable mais ces détails sont salvateurs lorsque vous devez présenter ou transmettre le projet à quelqu'un, ou si vous ou le client avez des questions dans quelques mois !
Enfin, utilisez un outil de versioning (Git) pour vos projets. Pour faire simple le versioning permet, grâce à un système de clone (copie du projet sur un réseau local ou sur le cloud), d’avancer simultanément sur différentes tâches. Il permet également d’archiver un ensemble de fichiers en conservant la chronologie de toutes les modifications qui ont été effectuées dessus. De cette façon, il n’y a aucun risque d’altérer ou de perdre les informations déjà enregistrées sur le dépôt commun (ou repository).
Nous y voilà ! Nous sommes maintenant prêts pour travailler sur notre nouvel algorithme prédictif. Beaucoup de travail a été effectué pour y arriver et il s’agit là de la réalité des systèmes de production actuels.
Maintenant que les données sont propres et organisées, nous pouvons passer à la partie que la plupart des data scientist préfèrent : l’analyse et la modélisation.
Mais il ne faut jamais oublier qu'aucune analyse ou algorithme exceptionnel ne compenseront complètement des données non retraitées !