Dans le quotidien d'un·e Data Scientist

Ludwine : Bonjour à tous et à toutes, je suis Ludwine et vous écoutez le podcast Human Coders. Dans chaque épisode, j'invite un ou une dev ou un professionnel de l'informatique pour parler de tech, de pratiques de développement ou de sujets plus généraux, mais toujours en lien avec l'informatique. Au programme également, des parcours de dev qui, j'espère, vous inspireront.

Tous les épisodes sont disponibles sur SoundCloud ou sur votre application de podcast préférée. Pensez à vous abonner et à nous laisser des commentaires ou des likes, ça nous fera toujours plaisir.

Aujourd'hui, on va parler d'un sujet que vous connaissez sûrement tous, ou du moins dont vous avez tous entendu parler : le Machine Learning. Précisément, on va rentrer dans le quotidien de Nastasia Saby, qui est ingénieure Machine Learning. Elle travaille sur des projets depuis l'ingestion des données jusqu'au monitoring des modèles de Machine Learning. On va parler de feature engineering, de tests de données, mais aussi de futurs buzzwords ou nouveaux besoins actuels qui, selon elle, sont un peu plus en phase avec la réalité du terrain, notamment le Data Drift et l'Explainability. Bonjour Nastasia.

Nastasia : Bonjour !

Ludwine : Est-ce que tu pourrais te présenter, s'il te plaît ?

Nastasia : Je m'appelle Nastasia. Je viens du monde du développement backend et j'ai sauté dans celui de la data, de la Data Science et du Machine Learning parce que je voyais des copains qui étaient là-dedans. Je trouvais ça passionnant de faire autant de choses, c'était super intéressant. Aujourd'hui, je suis ingénieure Machine Learning. C'est un peu un grand mot pour dire que je suis Data Scientist avec la spécialité de tout ce qui tourne autour de la production des modèles de Machine Learning.

Ludwine : Pourquoi pas Data Ingénieur alors ?

Nastasia : Ça dépend beaucoup des entreprises. Pour moi, les Data Ingénieurs ont une composante moins importante de Data Science. J'interviens davantage sur le choix des modèles, leur paramétrage et le monitoring des performances d'un modèle. Il faut avoir des notions, ou au moins s'intéresser à la manière dont on valide un modèle de Machine Learning et aux métriques pertinentes à choisir.

Les étapes d'un projet de Machine Learning

Ludwine : Le Machine Learning, l'intelligence artificielle, les réseaux de neurones, le Deep Learning, les régressions linéaires, les Random Forest... Ce sont beaucoup de buzzwords. L'idée de cet épisode est d'aborder le sujet plus en profondeur via ton expérience. En quoi consiste concrètement le travail sur un projet de Machine Learning ? Quelles sont les différentes étapes ?

Nastasia : Il y a plusieurs étapes assez linéaires, même si on peut itérer au milieu. On commence par récupérer la donnée. Cette donnée est souvent brute et on travaille très rarement directement avec. Il faut la préparer, la nettoyer, et en extraire ce qu'on appelle des features. Ce sont elles qui nous permettent d'entraîner le modèle ; c'est la donnée propre et utilisable.

Ensuite, il y a l'apprentissage, puis la validation. Il ne suffit pas d'entraîner, il faut vérifier que l'algorithme choisi est bon en faisant une validation sur des données qu'il n'a jamais vues, mais aussi vérifier que ça se passe bien dans la "vraie vie". Il y a aussi du monitoring et de l'infrastructure. Ce sont des aspects dont on parle moins souvent.

Le feature engineering

Ludwine : Est-ce que tu pourrais nous détailler le feature engineering, peut-être avec un exemple ?

Nastasia : Le feature engineering, c'est le fait de passer de données brutes à des données que l'algorithme peut "manger". On fait ça pour plusieurs raisons. Déjà pour des raisons techniques : la plupart des modèles n'acceptent que des valeurs numériques. Si on a des valeurs catégorielles, comme des noms de pays, il faut leur donner une correspondance en chiffres.

Au-delà de ça, les données arrivent de différentes sources et formats. Il faut les collecter, les enrichir et les agréger pour leur donner un sens utile à l'algorithme. Par exemple, si on cherche à prédire les pannes d'un ascenseur : on a des capteurs qui récupèrent des événements. On peut avoir l'heure d'ouverture et l'heure de fermeture de la porte (le timestamp). Cette donnée brute est peu parlante. Ce qui nous intéresse peut-être, c'est le laps de temps qui s'écoule entre l'ouverture et la fermeture. Il faut donc faire un calcul pour passer de la donnée brute à une donnée travaillée.

Ludwine : Quel temps représente cette partie de préparation des données et de création de features sur un projet ?

Nastasia : C'est un temps assez conséquent. J'ai connu des projets où le feature engineering était presque un projet à part entière. On voit des initiatives comme chez Uber avec le concept de Feature Store, où des équipes passent leur temps à préparer des features pour qu'elles soient ensuite utilisées par d'autres membres de l'équipe qui se concentrent sur la modélisation. On n'en a pas toujours conscience quand on démarre. Au début, je pensais passer beaucoup de temps sur la modélisation, à chercher le bon modèle, mais la préparation est une part énorme du travail.

La validation des modèles

Ludwine : Tu as aussi cité la validation du modèle et sa performance. En quoi cela consiste-t-il ?

Nastasia : Il y a plusieurs manières de valider un modèle. La première est "hors ligne" (offline) : on entraîne sur un certain jeu de données, puis on fait des prédictions sur un autre jeu de données que l'algorithme n'a jamais vu. On regarde alors les performances. Si on fait de la classification, on regarde combien de fois on a été juste. Si on prédit une valeur numérique, on regarde de combien on s'éloigne de la valeur réelle, car on ne sera jamais 100 % juste.

On peut aussi avoir des métriques "business" personnalisées. Supposons qu'on cherche à prédire la consommation de carburant d'une voiture pour la vendre avec une garantie de consommation annuelle. Si on se trompe et qu'on promet de rembourser la différence, il ne faut pas sous-estimer la consommation. La métrique sera alors de regarder combien de fois on sous-estime, car c'est là qu'est l'impact financier.

Enfin, il y a la validation "en ligne" : comment le modèle performe réellement dans la vraie vie ? On compare les prédictions avec les vraies valeurs au fil du temps. On regarde aussi si on suscite l'intérêt des utilisateurs, par exemple via de l'A/B testing ou du canary testing. C'est un champ beaucoup plus large que le simple test après modélisation.

Collaboration et qualité des données

Ludwine : Les données exploitées sont souvent d'intérêt pour le business ou d'autres équipes. J'imagine qu'il y a une forte collaboration.

Nastasia : Oui, c'est ce que j'ai toujours vu. Les équipes de Data Science collaborent avec les Data Ingénieurs, le DevOps et le business. On cherche vraiment à répondre à un besoin métier.

Ludwine : Parfois, après avoir tout mis en place, on se rend compte que les données choisies au départ ne sont pas si pertinentes, ou qu'il en manque.

Nastasia : On fait des tests de corrélation, mais ce n'est pas toujours parfait. Avoir des données redondantes signifie qu'il faut maintenir plusieurs sources, donc c'est plus de travail. Il faut essayer d'avoir des features qui "parlent" sans en avoir trop. On a toujours des surprises, surtout quand les données sont volumineuses : des choses qui manquent ou des codes dont on n'avait pas compris le sens réel. Cette étape de nettoyage revient parfois à la fin, là où on ne l'attendait plus, et il faut prendre des décisions : supprimer les lignes erronées ou remplacer les données manquantes ? C'est beaucoup de tests pour évaluer ce qui est le plus pertinent.

Tests unitaires de données et Data Drift

Ludwine : On parle souvent de tests unitaires dans le développement. Est-ce qu'on a une approche similaire pour les données ?

Nastasia : Il y a deux approches : les tests de données et le monitoring de données. L'idée est de ne pas faire confiance à la donnée qui arrive chaque jour pour les prédictions. On lance une batterie de tests, un peu comme de la non-régression, pour vérifier que les données sont semblables à celles de la veille (format, nombre de champs, proportion de valeurs nulles, etc.). Il existe des outils comme Deequ (avec Spark) qui permettent d'évaluer la donnée en entrée.

Ludwine : Et si les tests échouent ?

Nastasia : Ça dépend des projets. Si c'est critique, on arrête tout et on investigue pour comprendre pourquoi la donnée est jugée "mauvaise". Est-ce une anomalie ? Un problème d'ingestion ? Une fois le problème réglé, on continue. Parfois, on met juste de côté une partie des données "pourries".

Ludwine : Qu'est-ce qu'une donnée "pourrie" ?

Nastasia : C'est une donnée qui s'éloigne de ce qu'on a défini. Par exemple, on attend 10 champs avec des proportions précises de valeurs, et on reçoit autre chose. On parle alors de Data Drift. On évalue si la donnée a "dérivé" en comparant les distributions. Si l'écart dépasse un certain seuil, on considère que c'est trop différent pour continuer.

C'est un sujet très actuel. On n'est pas encore totalement sûrs des meilleures manières de détecter ce drift (distance euclidienne, distance de Wasserstein, tests statistiques...). C'est un terrain glissant car il y a peu d'outils matures, mais ça arrive tout le temps. L'exemple le plus frappant est la pandémie : elle a changé les comportements d'achat et la santé économique du jour au lendemain. Les données ont dérivé, les modèles se sont "cassé la figure" car ils n'étaient plus adaptés à la nouvelle réalité. C'est juste une question de temps avant que les données ne changent.

Frustration et réalité du métier

Ludwine : Est-ce que ce n'est pas frustrant de bosser des mois sur un modèle et de voir un événement soudain tout remettre en cause ?

Nastasia : C'est frustrant si on a la tentation de croire qu'on entraîne une fois et que c'est fini. En réalité, ce n'est que le début. Il va y avoir des changements, qu'ils soient soudains ou saisonniers (on ne se comporte pas pareil en été qu'à Noël). Il faut ré-entraîner avec de nouvelles données, mais aussi parfois réaliser que certaines features ne sont plus valides. Ce qui est vicieux, c'est que ça ne se voit pas forcément tout de suite pour l'utilisateur. Il faut être vigilant.

Ludwine : Est-ce que tu as d'autres frustrations ou désillusions à partager ? On présente souvent le Machine Learning comme quelque chose de magique.

Nastasia : Une autre chose importante, c'est l'interprétabilité ou l'Explainability des modèles. Ce n'est pas parce qu'un modèle est performant qu'il va être adopté. Si c'est une recommandation de vidéo, l'utilisateur s'en fiche. Mais si c'est pour un technicien qui doit réparer un ascenseur, il faut qu'il ait confiance. Il faut pouvoir lui dire : "je pense qu'il va y avoir une panne parce que j'ai remarqué tel signal". Donner des explications permet de donner confiance.

On associe souvent l'interprétabilité à l'éthique (éviter les biais), mais ça sert aussi à donner de la confiance, à faire du marketing (recommander un produit parce que tel autre utilisateur l'a fait) ou à débugger son propre modèle pour comprendre quelles features sont vraiment importantes. C'est essentiel pour ouvrir la "boîte noire".

Ludwine : Pour conclure, aurais-tu un dernier message pour nos auditeurs ?

Nastasia : Le Machine Learning est un sujet passionnant, mais pas forcément pour les buzzwords comme l'IA ou les réseaux de neurones. Souvent, on n'a même pas besoin de réseaux de neurones. Ce qui est passionnant, c'est ce champ vaste de la validation, de l'interprétation et de la gestion des surprises que nous réservent les données.

Ludwine : Merci beaucoup Nastasia, le message est clair. J'espère que cet épisode vous a plu. N'hésitez pas à venir en discuter sur notre blog, blog.humancoders.com, ou à nous suivre sur Twitter et LinkedIn. À bientôt pour un nouvel épisode !