Découvrez les défis en aval de l’apprentissage supervisé

On s’est rendu compte lors du chapitre précédent qu’un projet ML ne commence pas avec :

• import pandas as pd dataset_initial = pd.read_csv(fichier_de_donnes.csv)

De la même manière, un projet de ML ne se termine pas avec :

• predictions = model.predict(features)

Si vous avez suivi le cours Maitrisez l’apprentissage supervisé, alors vous avez déjà acquis des notions de base sur le drift et le MLOps. Ce ne sont pas les seuls challenges que l’on rencontre en aval d’un projet ML.

Nous allons découvrir ensemble avec Khémon, lors de cette interview, quels sont ces autres défis. Ensuite, nous allons distiller les points saillants ensemble, à l’instar du chapitre précédent

Lexique 

• Séries Temporelles : l’analyse des séries temporelles est un sous-domaine du Machine Learning et de la statistique au sens large ! Toute donnée qui évolue dans le temps peut être considérée comme une série temporelle (température de la journée, ventes par jour d’un magasin, etc.). Les modéliser avec un algorithme nécessite des raisonnements et des connaissances spécifiques. Ce notebook Kaggle présente les bases rudimentaires à connaître dans ce domaine.

• Marché : Dans les entreprises du Retail, on va souvent désigner par un marché soit un pays, soit une catégorie très large de produits que l’entreprise propose à la vente. Dans le contexte de l’interview de Khémon, il s’agit plutôt de la première.

• Uplift : L’uplift d’une métrique donnée est la différence entre la valeur de cette métrique en appliquant un levier métier et la valeur de la même métrique sans avoir appliqué ce même levier. C’est un concept très utilisé en marketing par exemple quand on souhaite mesurer l’efficacité d’une campagne.

• Counterfactual Analysis : Nous renvoyons au chapitre Donnez de la transparence à votre modèle supervisée du cours sur l’apprentissage supervisé pour ce concept ;).

• End User (Utilisateur Final) : Dans un projet ML, il s’agit de l’utilisateur métier des prédictions du modèle de ML.

• Insights : C’est un terme souvent employé pour désigner les messages clés que l’on tire après une analyse de données.

• Programmation linéaire : C’est un cousin du Machine Learning ! Définir en une phrase de quoi il s’agit est complexe, nous renvoyons alors vers GeeksforGeeks comme article d’introduction. 

• Proof of Concept : Très connue sous son abréviation POC. C’est un terme de plus en plus utilisé dans le monde de l’entreprise. Généralement, on dit que l’on fait un POC quand on est dans une phase d’évaluation de la faisabilité d’un projet et d’estimation de la valeur ajoutée d’une technologie. Voici un article de Cadremploi pour en savoir plus. 

Un seul besoin, trois algorithmes !

Le premier point clé dans le témoignage de Khémon est le suivant : vu le besoin des utilisateurs métier, il n’était pas possible de tout adresser avec un seul modèle (et donc avec un simple fit + predict).

Effectivement, les utilisateurs métier ont le besoin légitime de réaliser des simulations avec et sans promotions pour mesurer la rentabilité. Ces simulations passent par un modèle de ML, mais aussi par des analyses de type counterfactuals.

Au-delà des prédictions en elles-mêmes, il faut que l’outil de simulation via le ML soit en phase avec et non à contresens du quotidien de l’utilisateur métier. Celui-ci travaille avec un calendrier de promotion sur 6 mois et donc une vision globale sur sa stratégie de promotions, alors que le modèle de ML est entraîné à réaliser des prédictions individuelles, bouteille par bouteille et semaine par semaine.

Ce modèle, combiné avec l’algorithme de counterfactuals, peut être très bon pour réaliser des prédictions à court terme. Mais ces deux technologies ne seront pas capables de déterminer de manière autonome si l’uplift réalisé avec la bouteille A pendant la semaine S entrera en conflit avec l’uplift de la semaine S+2 sur la bouteille B (c’est l’effet de cannibalisation des promos dont Khémon parlait !). Or, c’est cette vision globale dans un calendrier que l’utilisateur métier souhaite !

Il a fallu alors réaliser un troisième algorithme à base de programmation linéaire pour packager les prédictions du modèle et les valoriser à une maille plus macro que celle de l'entraînement.

Gardez en tête également le fait de maîtriser la complexité technique du projet. Si vous devez faire 3 modèles de ML pour un seul projet, vous augmentez significativement l’effort de maintenance de l’ensemble du projet ;)

Trois algorithmes, plusieurs projets !

Khémon a expliqué que le déploiement du modèle se faisait “par marché” (ce qui signifie par pays dans le langage du retail) et il a rapidement évoqué la question des contraintes juridiques. Il a précisé en effet que certains pays imposent des restrictions sur les durées max des promotions. En outre, il a parlé de l’effet de fatigue des promotions, qui peuvent varier d’un pays à l’autre, comme les comportements clients ne sont pas les mêmes.

Étant une multinationale, l’entreprise peut avoir des dizaines d’assortiments de contraintes métiers différentes. Les utilisateurs métiers travaillent probablement de manière plus ou moins différente : on peut imaginer des calendriers sur trois mois au lieu de six, ou alors des répartitions de portefeuille clients différents. Ne parlons même pas des différences techniques : les données ne sont probablement pas collectées avec des formats identiques, à une fréquence identique et avec du contenu identique.

Comme vous vous en doutez bien, ces changements sont suffisamment significatifs pour nécessiter des équipes dédiées ! L’entreprise peut décider d’avoir un Data Scientist pour traiter toutes les variantes du même projet, si les différences entre pays ou régions restent faibles. Ou a contrario, plusieurs Data Scientists peuvent être amenés à couvrir plusieurs variantes. Tout dépend de la complexité de l’organisation et du projet.

Une prédiction, plusieurs conclusions !

Ici, nous allons toucher à la subjectivité dans l’utilisation des prédictions d’un modèle ML. Khémon explique vers la fin de l’interview que les prédictions d’un modèle sur les ventes futures peuvent être challengées par le Revenue Growth Manager, qui reste l’ultime décisionnaire pour construire le calendrier de promotions sur 6 mois.

Que devons-nous faire dans ces cas-là ? Privilégier l’expertise métier de l’utilisateur, ou le pouvoir prédictif du modèle ? Khémon nous apprend via son témoignage qu’une bonne façon d’adresser la situation est de factualiser le plus possible la prédiction du modèle. Il propose en effet :

• D’accompagner la prédiction du modèle d’arguments supplémentaires, en allant chercher dans l’historique de données les situations les plus similaires (marques similaires, période de l’année similaire, etc.) et de regarder ce que propose le modèle comme uplift

• D’être transparent sur le degré d’incertitude associé au modèle, en présentant par exemple les marques où le modèle performe en général moins bien ou au contraire bien mieux.

Avant de passer à la section qui suit, soulignons ensemble les similarités et les différences entre le use case de Victor et celui de Khémon. On pourrait simplifier en disant que les deux essayent de déterminer, dans un contexte retail, quelle promotion appliquer à quel produit. Toutefois, ce serait réducteur et faux :

• Sur un plan très technique, Victor va prendre des promotions dont les caractéristiques sont déjà fixées et va utiliser du ML pour montrer les promos aux bonnes personnes. Alors que Khémon utilise le ML pour fixer les caractéristiques des promos.

• Victor est dans un contexte B2C, l’utilisateur final achète ou n’achète pas le produit présenté par le modèle, il n’y a a priori pas de couche intermédiaire entre les deux. Alors que le projet de Khémon a une nature B2B2C. Le modèle n’est visible qu’au Revenue Growth Manager qui le pilote et le challenge directement via des simulations

• Victor est dans un contexte où le modèle doit être alimenté avec de la donnée rafraîchie en temps réel (en streaming) alors que Khémon réalise des prédictions à la semaine et un calendrier sur six mois. Ces temporalités très différentes changent radicalement les choix techniques : de l’ETL jusqu’au déploiement du modèle, en passant par les métriques d’évaluation ou encore les stratégies d'entraînement

• Les deux utilisent des baselines auxquels comparer leurs modélisations. Victor parle de personnalisation simple ou d’absence de personnalisation, alors que Khémon parle de counterfactuals ;)

• Les deux mettent les profils métiers au centre de leur projet, que ce soit pour affiner au maximum possible l’approche de ML, ou pour mettre en place une Data Observability

Nous allons désormais entamer la dernière section de ce cours ! Vous êtes à présent au courant des défis rencontrés en amont et en aval de votre code de modélisation supervisée. Il ne nous reste plus que les problématiques communes entre les deux pour clôturer !

Un projet, plusieurs cadrages !

Rappelons trois évidences du cadrage d’un projet dans sa globalité : tout projet nécessite d’avoir une bonne définition des parties prenantes, d’être encadré par un budget cohérent et d’avoir une politique de maintenance s’il a vocation à vivre dans la durée. Les projets Data et plus particulièrement ML ne font pas exception à cela.

Commençons par la partie maintenance. Votre projet ML n’a de la valeur que si 1) vous avez de la visibilité sur les briques de votre code qui peuvent présenter des aléas 2) vous êtes capable de rapidement identifier des problèmes et de les corriger avec un outillage efficace.

C’est une discussion que nous avons déjà explorée en surface dans la troisième partie de ce cours quand on a parlé du MLOps. En revanche, le MLOps ne se limite pas qu’aux outils à mettre en place pour surveiller du drift. Ce n’est pas moi qui le dis, ce sera Médéric, notre expert MLOps, qui va nous partager son retour d’expérience sur le sujet !

Lexique 

• Linting : Un Linter est un programme qui va automatiquement scanner votre code pour détecter certains types d’erreurs ou des problèmes de qualité de données. Un Linter prend souvent la forme d’une extension de votre IDE, comme l'extension Ruff de VSCode par exemple.

• Codebase : Un terme qui fait tout simplement référence au code de votre projet.

• Coverage de code : Il s’agit d’une métrique qui permet d’estimer la part de votre codebase qui est dotée de tests (unitaires ou d’autres) en se basant sur plusieurs critères.

• Datadog : Il s’agit d’un software open source spécialisé dans le monitoring de l’infrastructure Cloud qui héberge tous les projets Data. On parle ici de monitoring de l’utilisation des serveurs et des services (machines virtuelles, containers, etc.).  

Déjà, le témoignage de Médéric est extrêmement riche sur le plan technique. Il nous partage certaines lacunes récurrentes et précises dans les projets Data :

• Le manque de testing : avoir un code sans tests concerne autant les Data Scientists que les Data Engineers que Data Analysts que les Analytics Engineers, autant la partie amont que la partie aval du projet ML. On peut même aller plus loin avec des outils de coverage de code comme SonarCloud.

• Les discordances entre les infras : Si tout le monde utilise pip pour installer des packages, et non des alternatives plus robustes comme poetry ou plus récemment uv, alors on est quasiment sûr d’avoir du code qui plante en production car rien n'est en place pour garantir la reproductibilité des dépendances, comme conçues en local.

• Le manque de versionning : autant sur les données que sur les modèles de ML, il faut avoir la capacité de “remonter dans le temps” pour reproduire les conditions identiques dans lesquelles votre modèle a réalisé votre prédiction. Faute de quoi, vous ne pourrez jamais identifier la cause racine d’un problème qui a eu lieu en production par le passé et qui pourrait être récurrent.

Il est en effet contreproductif d’encourager vos collègues Data Scientist d’utiliser un tout nouveau package de deep learning, sans que les profils plus DevOps soient dans la boucle pour évaluer l’impact d’un changement sur l’infra (environnements virtuels, images Dockers etc.). La maturité technique des équipes est également un facteur à considérer : Si vous êtes dans une équipe Data qui n’a jamais utilisé de tests unitaires pour leurs projets en production, vous n’allez pas introduire la notion de testing de la même manière que vous le feriez avec une équipe qui est déjà à l’aise avec pytest et qui aurait le niveau technique pour aborder la notion de coverage de code.

Médéric a mentionné plusieurs outils très pertinents pour adresser des problématiques très précises (SonarCloud pour le coverage, Ruff pour le linting et le formatting, DataDog pour le monitoring de l’infra dans le Cloud), mais elles doivent être au service du fonctionnement actuel de l’organisation avant tout.

Le Data Scientist pourrait en théorie (et en pratique) réaliser les analyses exploratoires, les modèles, comprendre le besoin métier, réaliser les déploiements, etc. Toutefois, quand une équipe Data commence à croître, il devient critique de redéfinir les rôles et les responsabilités et de “redistribuer” toutes ces tâches pour rester efficace et pouvoir passer à l’échelle.

Médéric nous présente pendant l’interview quelques scénarios qui ont été discutés au sein de Décathlon Digital et nous présente les avantages et les inconvénients. Parmi les facteurs qui ont alimenté cette réflexion, on retrouve :

• La capacité à harmoniser les bonnes pratiques techniques, faute de quoi les passations de projet et de connaissance peuvent être difficiles et le risque de réinventer la roue à plusieurs endroits augmente. C’est un point plus difficile à maîtriser dans un modèle décentralisé où les Data Scientists sont répartis dans plusieurs équipes métier.

• La proximité avec les équipes métiers. Une équipe Data centrale sera nécessairement moins proche.

• La capacité à scaler (passer à l’échelle).

Même si un modèle hybride avec une équipe MLOps centrale semble équilibrer tous ces facteurs, Médéric nous précise bien qu’il ne s’agit pas d’une vérité absolue et que chaque entreprise doit mener sa propre réflexion en fonction des éléments idiosyncrasiques qui la caractérise.

Parlons rapidement de la partie budget. Avec tout ce que vous avez déjà vu dans ce cours, vous avez certainement compris qu’un projet ML n’est pas une brique isolée dans l’entreprise. C’est une brique connectée à tout l’écosystème global. Si on veut s’assurer que des projets Data & ML restent dans le budget de l’entreprise, il faut avoir une visibilité sur le coût de toutes ces briques à la fois et avec une fréquence régulière. C’est exactement l’objectif du FinOps !

Rentrer dans le détail des bonnes pratiques du FinOps nécessiterait son propre cours en entier ! Nous allons nous contenter ici de résumer les points saillants des différents intervenants :

• Le FinOps est une responsabilité autant collective qu’individuelle.

• Le coût d’un service Cloud ne peut pas toujours être isolé des autres services. Victor cite le cas des coûts réseaux, à savoir le coût de sortir un dataset d’un espace de stockage Cloud vers une machine qui entraînera le modèle, par exemple.

À ce sujet, vous pouvez regarder une conférence détaillée sur le FinOps, (en anglais), animée par Victor. 

Oui et non ! D’ailleurs, c'est une excellente question pour conclure. Cette complexité ne doit pas être paralysante pour avancer. Quand vous êtes encore en phase d’analyse exploratoire, aller très loin dans le testing n’a peut-être pas beaucoup de sens. À ce stade, vous ne connaissez pas encore les fonctionnalités qui vont être définitives dans votre code et qui méritent d’être testées. En revanche, même en phase d’analyse exploratoire, vous pouvez mettre en place des choix simples et robustes pour vous éviter des problèmes par la suite, comme la gestion des packages avec poetry ou uv au lieu de pip. ;)

C’est un équilibre que vous allez trouver au fur et à mesure que vous gagnez en expérience. La priorité absolue restera toujours le fait de répondre au besoin métier avec une approche ML adaptée. Le dicton de Médéric en ce sens résume les choses “Make it Done, Make it Right, Make it Fast”. ("Fais-le, fais-le bien, fais-le vite.")

Levons ensemble le stylo sur ce cours en rappelant l’un des derniers conseils de Médéric, qui selon moi est le plus important, de loin, pour toute votre carrière en Data : Soyez curieux ! ;)

En résumé

• Un projet de Machine Learning (ML) ne se limite pas à une simple prédiction (fit + predict) : il peut nécessiter plusieurs algorithmes (modèles supervisés, counterfactual analysis, programmation linéaire) pour répondre aux besoins métier complexes, comme les simulations ou la gestion des contraintes globales.

• Les projets ML dans des environnements internationaux (comme les multinationales) impliquent des variantes locales : les données, les contraintes juridiques, et les besoins des utilisateurs varient selon les marchés, rendant nécessaires des ajustements techniques et organisationnels.

• La subjectivité des décisions métier doit être prise en compte : il est crucial d’accompagner les prédictions de preuves factuelles (insights, incertitudes, historiques similaires) pour gagner la confiance des utilisateurs et faciliter leur adoption.

• Un projet ML nécessite un cadrage rigoureux, incluant : des rôles bien définis (par ex. MLOps), une politique de maintenance technique (tests, versioning, reproductibilité) et une gestion des coûts via le FinOps pour garantir viabilité et évolutivité.

• La réussite d’un projet repose sur l’équilibre entre répondre au besoin métier et maîtriser la complexité technique, en adoptant des bonnes pratiques adaptées à chaque phase (exploration, déploiement, maintenance).