Le guide pour réussir à l’ère de l’innovation.
Un projet de machine learning ne commence pas avec le choix d’un algorithme. Il commence par une question métier, puis par l’examen des données disponibles. Une entreprise peut disposer de nombreux fichiers, historiques de ventes ou informations clients sans avoir un jeu de données réellement exploitable pour entraîner un modèle.
Le machine learning apprend des régularités à partir d’exemples. Si ces exemples sont incomplets, contradictoires, mal décrits ou issus d’un processus qui a changé au fil du temps, le modèle risque de produire des résultats peu fiables. Il peut aussi sembler performant lors des tests, tout en échouant dans les conditions réelles.
La préparation des données sert donc plusieurs objectifs : comprendre ce qui est mesuré, vérifier la qualité des informations, limiter les biais, respecter les règles applicables et rendre les résultats interprétables. Cette phase doit être considérée comme un projet à part entière, avec un responsable, des critères d’acceptation et une documentation accessible aux personnes qui utilisent les données.
Avant de réunir des fichiers, il faut décrire la décision que le modèle doit aider à prendre. Une formulation vague comme « prédire les ventes » ne suffit pas. Il est préférable de préciser :
Par exemple, une petite entreprise peut vouloir estimer le volume de commandes de la semaine suivante. Elle devra définir l’horizon de prévision, l’unité d’analyse, les produits concernés et la manière de traiter les périodes sans vente. Pour un modèle de détection d’impayés, la cible peut être un retard supérieur à un délai défini, mais cette définition doit être identique dans tout l’historique.
Cette étape évite de collecter des données inutiles ou de construire un modèle impossible à exploiter. Elle permet également de repérer un risque fréquent : utiliser, au moment de l’entraînement, une information qui n’existait pas encore au moment où la décision aurait dû être prise. Ce phénomène, appelé fuite de données, donne une vision artificiellement favorable des performances.
L’inventaire doit recenser les sources internes et externes, leur format, leur fréquence de mise à jour, leur propriétaire et leurs conditions d’utilisation. Les sources peuvent inclure un logiciel de gestion commerciale, un outil de relation client, des feuilles de calcul, des exports comptables, des capteurs ou des formulaires en ligne.
Pour chaque source, il est utile de répondre à quelques questions :
Un dictionnaire de données formalise ensuite le sens de chaque colonne. Il peut préciser le nom du champ, sa définition, son type, son unité, ses valeurs autorisées, son caractère obligatoire et sa source. « Client actif », « chiffre d’affaires » ou « date de livraison » peuvent avoir des significations différentes selon les services. Sans définition partagée, les rapprochements deviennent fragiles.
La responsabilité ne doit pas être laissée uniquement à la personne qui développe le modèle. Les équipes métier connaissent les règles de gestion, tandis que les profils techniques contrôlent les formats, les transformations et les flux. Leur collaboration est nécessaire pour distinguer une anomalie de saisie d’un événement commercial réel.
La qualité des données peut être examinée selon plusieurs dimensions. Il est préférable de produire un état initial chiffré, puis de répéter les contrôles après chaque transformation importante.
| Dimension | Question à vérifier | Exemple de contrôle |
|---|---|---|
| Complétude | Les champs nécessaires sont-ils renseignés ? | Calcul du taux de valeurs manquantes par colonne |
| Exactitude | La valeur correspond-elle à la réalité attendue ? | Comparaison avec une source de référence |
| Cohérence | Les règles entre champs sont-elles respectées ? | Une date de livraison est-elle postérieure à la commande ? |
| Unicité | Chaque événement est-il compté une seule fois ? | Recherche de doublons sur un identifiant |
| Actualité | La donnée est-elle assez récente pour l’usage prévu ? | Mesure du délai entre collecte et utilisation |
Les valeurs manquantes ne doivent pas être remplacées automatiquement par zéro. Une absence peut signifier « non renseigné », « non applicable », « inconnu » ou « aucune occurrence ». Ces situations n’ont pas la même signification statistique. Il faut donc documenter la règle de traitement : suppression d’une ligne, création d’une catégorie « inconnu », imputation par une méthode déterminée ou conservation de l’absence comme information.
Les valeurs extrêmes méritent également une analyse. Une commande exceptionnellement élevée peut être une erreur, mais aussi un événement commercial valide. Supprimer ces observations sans vérification peut rendre le modèle moins représentatif. Chaque correction devrait laisser une trace : ancienne valeur, nouvelle valeur, motif, date et personne ou processus à l’origine de la modification.
Un jeu de données destiné au machine learning doit associer des variables explicatives à une cible clairement définie. La cible peut être une catégorie, une valeur numérique ou un événement qui se produit dans une période donnée. Sa construction doit respecter le calendrier réel du processus étudié.
Les données doivent ensuite être séparées en plusieurs ensembles. L’ensemble d’entraînement sert à ajuster le modèle. L’ensemble de validation sert à comparer des réglages ou des approches. L’ensemble de test doit rester à l’écart jusqu’à l’évaluation finale. Lorsque les données suivent le temps, une séparation chronologique est généralement plus réaliste qu’un mélange aléatoire. Les observations anciennes peuvent servir à l’apprentissage et les plus récentes à l’évaluation.
Il faut aussi vérifier que des informations proches ne se retrouvent pas dans plusieurs ensembles. Deux lignes concernant le même client, le même dossier ou le même produit peuvent donner au modèle une information indirecte sur les données de test. La performance mesurée serait alors surestimée.
La notion de représentativité doit être examinée avant l’entraînement. Si l’historique contient principalement une catégorie de clients, une région ou une période particulière, le modèle peut fonctionner correctement sur ce groupe et moins bien sur les autres. Les résultats doivent être comparés par segment pertinent, sans utiliser de caractéristiques sensibles de manière injustifiée. La Commission nationale de l’informatique et des libertés, la CNIL, rappelle que l’utilisation de données personnelles doit respecter les principes du Règlement général sur la protection des données, notamment la minimisation, la transparence et la limitation des finalités.
Un projet de machine learning peut impliquer des données personnelles, même lorsque l’objectif initial n’était pas lié à l’analyse prédictive. Un nom, une adresse électronique, un identifiant client, une adresse IP ou une combinaison de caractéristiques peuvent permettre d’identifier une personne. La qualification dépend du contexte et des possibilités de rapprochement.
Avant de réutiliser un historique, il faut vérifier la finalité poursuivie, la base juridique, l’information des personnes, les durées de conservation, les droits applicables et les mesures de sécurité. La CNIL recommande d’intégrer la protection des données dès la conception et de limiter les informations utilisées à ce qui est nécessaire pour l’objectif défini.
L’anonymisation et la pseudonymisation ne désignent pas la même opération. Une donnée pseudonymisée reste susceptible d’être rattachée à une personne grâce à des informations supplémentaires. Elle demeure donc une donnée personnelle dans de nombreux cas. L’anonymisation vise une impossibilité réelle et durable de réidentifier les personnes, ce qui demande une analyse sérieuse du risque de rapprochement.
Il convient également de contrôler les accès, de chiffrer les transferts lorsque cela est nécessaire, de séparer les environnements de développement et de production et de définir une procédure de suppression. Si une analyse d’impact relative à la protection des données est requise, elle doit être réalisée avant le déploiement, avec l’appui du délégué à la protection des données lorsqu’il existe. Le machine learning ne dispense pas de respecter les obligations liées à la protection des personnes.
Un modèle peut reproduire un biais déjà présent dans les données. Cela ne suppose pas une intention discriminatoire : un historique de décisions humaines, une couverture inégale des territoires ou des différences de saisie peuvent suffire à créer un effet défavorable pour certains groupes.
L’analyse doit porter sur la manière dont les données ont été produites. Qui a été observé, qui ne l’a pas été, et pour quelle raison ? Les personnes ayant refusé une démarche ou abandonné un parcours sont-elles absentes de la base ? La cible est-elle mesurée de la même façon pour tous ? Ces questions sont particulièrement importantes pour le recrutement, l’octroi de crédit, l’accès à un service ou la gestion des risques.
Une variable peut aussi être un indicateur indirect d’une caractéristique sensible. Le code postal, le type de contrat ou l’historique d’utilisation peuvent parfois refléter une information que l’on ne souhaitait pas utiliser. Il ne suffit donc pas de retirer une colonne sensible pour éliminer tout risque.
Les contrôles doivent comparer les erreurs et les performances par sous-groupes pertinents, lorsque cela est licite et possible. Les critères d’équité dépendent du cas d’usage et peuvent entrer en tension. Une décision de déploiement doit prendre en compte les conséquences concrètes, la possibilité de recours humain et la nécessité d’expliquer une décision. Le modèle ne doit pas devenir une justification automatique d’une pratique difficile à défendre.
Une préparation fiable ne repose pas sur des corrections manuelles effectuées une seule fois dans un tableur. Il faut décrire les étapes de manière reproductible : import, filtrage, dédoublonnage, conversion des formats, traitement des valeurs manquantes, création des variables et séparation des ensembles.
Chaque version du jeu de données doit être identifiable. La documentation peut inclure la date d’extraction, les sources utilisées, le nombre de lignes, les règles appliquées, les colonnes supprimées et les contrôles réalisés. La conservation des versions facilite l’analyse d’une erreur et permet de comprendre pourquoi les résultats changent.
Des tests automatiques simples peuvent détecter une rupture de qualité : colonne absente, date située dans le futur, valeur négative interdite, volume quotidien anormal ou taux de valeurs manquantes supérieur à un seuil défini. Ces tests doivent déclencher une alerte avant que les données n’alimentent le modèle.
Pour une petite structure, il n’est pas nécessaire de commencer par une architecture complexe. Un dictionnaire partagé, une convention de nommage, un registre des transformations et quelques contrôles systématiques peuvent déjà améliorer nettement la fiabilité. L’essentiel est que la méthode soit comprise par plusieurs personnes et qu’elle puisse être rejouée sans dépendre de la mémoire d’un seul intervenant.
Le lancement ne devrait intervenir que lorsque des critères explicites sont remplis. Parmi les points à valider :
La performance initiale ne suffit pas. Les données peuvent changer : comportement des clients, catalogue, tarifs, réglementation, saisonnalité ou processus de saisie. Cette évolution peut réduire la pertinence du modèle. Il faut donc suivre la qualité des entrées, la fréquence des prédictions, les écarts entre prévisions et résultats observés, ainsi que les situations dans lesquelles une personne corrige la recommandation.
Un dispositif de réexamen doit préciser quand le modèle sera évalué à nouveau, quelles évolutions déclenchent une nouvelle phase d’apprentissage et qui peut suspendre son utilisation. Pour les décisions sensibles, une validation humaine, une explication compréhensible et une procédure de contestation doivent être prévues. La préparation des données ne s’arrête donc pas au premier entraînement : elle se prolonge pendant toute la durée de vie du projet.
Non. Le volume nécessaire dépend de la complexité du problème, de la variabilité des situations et de la qualité des observations. Un historique plus réduit, mais bien défini et cohérent, peut être plus utile qu’une base volumineuse contenant des doublons et des erreurs. Un test simple avec une méthode de référence permet d’évaluer si les données disponibles apportent déjà une valeur suffisante.
Oui, à condition de contrôler leur structure, leur version, les formules, les cellules fusionnées, les formats de date et les modifications manuelles. Un fichier peut servir à une première exploration, mais un projet récurrent nécessite généralement une chaîne d’import et de validation documentée.
La responsabilité doit être partagée selon les rôles. Les équipes métier définissent le sens des informations et les règles de gestion. Les profils techniques contrôlent les traitements et les flux. Une personne doit toutefois coordonner les décisions, suivre les anomalies et tenir la documentation à jour.
Pas nécessairement, mais il faut justifier chaque catégorie utilisée, limiter la collecte et appliquer les règles de protection des données. La pseudonymisation, la réduction des variables et la limitation des accès peuvent réduire les risques sans remplacer l’analyse juridique et la documentation des finalités.
© e1-conference.com. CGU
