Machine learning en production : un « mythe » s’écroule
Le machine learning entre en production dans les grands groupes, mais le fait de donner les clés des déploiements des modèles aux data scientists n’est plus une pratique recommandée. Désormais, Data engineer, Data Scientists et DevOps doivent s’entendre pour industrialiser les modèles ML.
Dans le cadre de la conférence DataOps Rocks orchestrée par Saagie le 23 septembre 2021, Yann Barraud, Global Chief Data Officer chez Carrefour, David Lépicier, Global Data & Analytics director chez Pernod-Ricard, et Guillaume De Saint Marc, Senior Director Engineering, Emerging Technologies & Incubation chez Cisco, ont échangé sur les pratiques de data science au sein de leurs entreprises. Dans ces trois organisations, les modèles de machine learning sont entrés en production.
Les responsables constatent que ce passage d’une phase de recherche au déploiement en production demande un changement d’organisation.
« Notre conviction chez Carrefour, c’est qu’il nous faut considérer un projet data comme un produit, peu importe sa complexité », martèle Yann Barraud. « Ce sujet est prioritaire par rapport à la mise en place de processus et d’outils de déploiement. L’équipe doit savoir construire et déployer un projet de manière intelligente, se concentrer sur le même objectif. Ce n’est qu’à partir de ce moment, que l’on sélectionne les solutions nécessaires pour industrialiser tout cela ».
« Notre conviction chez Carrefour, c’est qu’il nous faut considérer un projet data comme un produit, peu importe sa complexité ».
Yann BarraudGlobal Chief Data Officer, Carrefour
Il s’agit de mettre en place une organisation digne de ce nom mêlant les capacités des data scientists avec celles des développeurs.
« Chez Carrefour, nous avons des équipes techniques responsables de la mise à disposition des données de qualité. Les équipes de data science consomment les éléments déployés par les data engineers », explique Yann Barraud. « Mais avant de leur transmettre les données, une équipe de gouvernance vérifie leur qualité avant de développer les modèles. Ensuite, les data scientists travaillent main dans la main avec des data engineers, afin d’effectuer le feature engineering. Les modèles de machine learning seront déployés en collaboration avec un DevOps, partie prenante de l’équipe ».
« Si les équipes sont bien constituées, qu’elles ont bien compris les enjeux du projet et les contraintes des uns et des autres, cela fonctionnera », affirme-t-il.
Le data scientist omnipotent s’efface au profit des équipes
Pour autant, l’intention se confronte souvent à la réalité.
« Aujourd’hui, cela ressemble encore à un rêve d’ingénieur, mais les projets d’IA devraient se déployer comme des projets logiciels standards. À ceci près que la gestion de version demande des efforts plus importants. Il faut non seulement le faire pour le code des modèles, mais également pour les données et les métadonnées utilisées. Il y a des solutions sur le marché qui commencent à offrir les capacités nécessaires, mais cette profusion de versioning complique les choses », reconnaît Yann Barraud.
Pour sa part, Guillaume De Saint Marc estime que les capacités low-code/no-code ne suffisent pas encore à rendre opérationnel les data scientists, ou alors dans le cadre de « projets simples ». « Dès que l’on développe des solutions avancées, l’on a besoin d’équipes IT, DevOps et MLOps qui fonctionnent bien ensemble. »
Selon David Lépicier, un mythe s’écroule dès qu’il s’agit de déployer des modèles de machine learning en production.
« L’on sort du mythe où le data scientist doit tout faire. L’on se rend compte que pour 6 à 8 data scientists, il faut un Machine learning Engineer responsable de la qualité du code, un garant du bon fonctionnement des modèles », explique-t-il.
En clair, il s’agit de répartir les tâches entre les bons membres d’une équipe data, plus que de formaliser directement une approche DataOps ou MLOps.
« De la même manière, le data scientist va être la figure de proue capable de présenter clairement les tenants et les aboutissants d’un projet, mais avoir des data analysts capables de faire la même chose est bénéfique », note David Lépicier.
Quant à la collecte de données, le data steward doit s’assurer de la propreté des informations récoltées, selon le responsable. « Dans une entreprise comme la nôtre qui n’est pas une société technologique, il faut que les équipes puissent comprendre et intégrer les nouveaux rôles dans leurs processus. Il nous faut créer des partenariats avec des sociétés pour collecter et analyser ces données, ne pas faire manipuler les fichiers par 15 personnes avant qu’ils n’arrivent dans les mains des équipes de data science», liste-t-il.
Yann Barraud, lui, a identifié un nouveau rôle dont l’intitulé est apparu aux alentours de 2018 : le data translator. Son rôle n’est autre que de reprendre une partie du travail des data scientists en ce qui concerne la communication avec les métiers. Selon l’offre d’emploi de Carrefour toujours en vigueur, il est « le pivot entre les équipes métiers et les équipes de data scientists, data engineers, data governance et data viz de la direction ».
Il est à la fois en mesure de réaliser des analyses et des explorations de données de premier niveau et de communiquer avec aisance les besoins des métiers, dont il est le représentant auprès des data scientists ; et à l’inverse, retranscrire les travaux des data scientists aux métiers. En clair, Carrefour cherche un data analyst ou un statisticien de bon niveau avec des capacités de chef de produit. « L’idée c’est qu’il soit capable de faire un peu d’idéation et de détecter les opportunités de cas d’usage auprès des équipes métiers, cas d’usages dont il deviendra le product owner », précise Yann Barraud.
De manière générale, la nature de ces métiers pousse les entreprises à l’inventivité dans leur manière de recruter.
« Les filières de formation en France fonctionnent bien, mais les marchés [de la data science] sont extrêmement tendus », commente Guillaume De Saint Marc. « C’est d’ailleurs une opportunité pour notre pays. Chez Cisco, nous avons ouvert des bureaux en France et en Europe parce qu’il y avait des pénuries dans la Silicon Valley. En revanche, il ne faut pas chercher à recruter la personne idéale, le profil magique », conseille-t-il. « Il ne faut pas oublier les équipes internes. Aujourd’hui, les sujets autour de la donnée et du machine learning intéressent beaucoup de monde. Franchement, la plupart des ingénieurs souhaitent développer leurs compétences dans ce domaine et sont curieux. Il faut jouer sur les deux tableaux, interne et externe ».
« Il ne faut pas oublier les équipes internes. Aujourd’hui, les sujets autour de la donnée et du machine learning intéressent beaucoup de monde ».
Guillaume De Saint MarcSenior Director Engineering, Emerging Technologies & Incubation, Cisco
Chez Pernod-Ricard, il y avait déjà une trentaine de membres dans l’équipe IT spécialiste de l’infrastructure et du data engineering. « Dans l’équipe de data science, nous sommes passés de deux à 60 collaborateurs », témoigne David Lépicier. « Nous avons estimé les besoins et les gains potentiels de trois cas d’usage majeurs sur nos marchés. Nous avons recruté une trentaine de profils en interne et l’autre moitié en freelance. Il faut s’assurer de l’intérêt des personnes pour ce type de projet, et du mélange de compétences techniques et métiers, en facilitant le rapprochement des collaborateurs », note-t-il. Ainsi, les Machine learning engineers expliqueraient aux data scientists l’intérêt d’optimiser leur code, en vue d’un passage des modèles de machine learning en production, entre autres.
L’équipe de Pernod-Ricard est internationale, mais des unités spécifiques sont présentes à Shanghai, Mumbai et New York « pour déployer [les modèles ML] localement, sur leur marché ». En revanche, pas de miracle, certains groupes n’arrivent pas à s’entendre, selon David Lépicier. « Dans certains cas, nous avons fait appel à des coaches. La bonne entente, le dialogue prend du temps, mais je considère que c’est mieux que de voir quelqu’un quitter la société ».
Chez Carrefour, les équipes de data science sont réparties par pays et sont en cours de constitution. « Nous n’allons pas aller chercher à former des équipes internationales, en télétravail. Je pense que nous ne sommes pas assez matures pour cela. Nous recrutons localement, en interne et à l’externe pour des besoins spécifiques », déclare Yann Barraud.
Quand le FinOps rencontre le MLOps
Outre le recrutement, le passage des modèles de machine learning en production réclame une surveillance accrue des coûts des traitements de données. L’approche FinOps croise les démarches MLOps et DataOps.
Pour autant, le niveau de maturité diffère entre les entreprises de ce panel. Chez Cisco et Carrefour, les pratiques sont en place.
« Nous avons mis en place une démarche FinOps au niveau de l’ensemble de nos équipes cloud. Cela permet de faire des optimisations et économies d’échelle majeures ; sur certains sujets l’on parle de centaine de milliers, voire de millions d’euros d’économies par an grâce au FinOps », témoigne Yann Barraud.
Les équipes de data science ont également mis en place les bonnes pratiques chez Carrefour, après une période de sensibilisation et « parce qu’il y a eu des dérives ». « Les équipes ont mis en place des systèmes de supervision avec des alertes qui permettent de les notifier s’ils respectent les budgets alloués au développement, et ne sont pas en train d’exploser la facture à cause de mauvaises pratiques », ajoute-t-il.
« Si vous êtes dans votre data center privé, vous allez peut-être empiéter sur les ressources d’une autre business unit. Si vous êtes dans le cloud, cela va très bien se passer et vous n’allez pas forcément constater de limites. En revanche, vous allez recevoir la facture, potentiellement salée », prévient Guillaume De Saint Marc. « À partir du moment où l’on pilote les applications, il faut être capable de comprendre les coûts qui sont associés. Cela peut être assez piégeux », remarque-t-il.
Il existe pourtant des mesures de prudence. « Nous faisons deux choses », indique Guillaume De Saint Marc. « Nous menons un exercice pratique ou théorique pour projeter un déploiement à l’échelle d’une application. Deuxièmement, nous supervisons tout ce qui peut perturber le fonctionnement d’une application : les montées en charge soudaines, les pannes, les cyberattaques, etc. »
Chez Pernod-Ricard, l’approche FinOps n’est pas encore la priorité. « Aujourd’hui, le coût de consulting et de travail sur la donnée est tellement énorme que l’utilisation de la plateforme cloud en tant que telle n’est pas forcément ce que l’on surveille en premier », avoue David Lépicier. « Nous surveillons les grosses dépenses, mais ce n’est pas l’enjeu le plus important chez nous pour l’instant ».
« Aujourd’hui, le coût de consulting et de travail sur la donnée est tellement énorme que l’utilisation de la plateforme cloud en tant que telle n’est pas forcément ce que l’on surveille en premier ».
David LépicierGlobal Data & Analytics director, Pernod Ricard
Machine learning en production : une histoire de ROI
Il s’agit surtout de trouver les bons cas d’usage, synonymes de gains financiers ou opérationnels. Là encore, ce travail relève d’une approche itérative. « Par exemple pour l’optimisation des promotions, nous formulons une hypothèse correspondant à x % d’amélioration d’une campagne. Elle pourrait entraîner une dépense d’environ n euros, dont nous pouvons tirer un gain y. Une fois les hypothèses les plus probantes sélectionnées, il faut les tester. Parfois le ROI est bon, parfois non », explique David Lépicier.
Cette méthodologie très scientifique a pourtant fait ses preuves, pour évaluer la pertinence d’un modèle de promotion par rapport à un autre dans une chaîne de magasins comme Carrefour. « Cela a un véritable impact sur le terrain », affirme le responsable. De même, les data scientists de Pernod-Ricard ont concocté des modèles de recommandation afin d’optimiser les voyages des commerciaux itinérants se rendant dans les bars, les restaurants et les hôtels. Là encore, les retours sont positifs.
Chez Carrefour, un modèle de machine learning a été conçu pour optimiser la production de pains dans certains magasins français. Il s’agit d’éviter de surproduire – et donc les invendus – tout en faisant en sorte de disposer suffisamment de produits sur les présentoirs. « En France, la baguette est un élément important de la visite en magasin. Un client va généralement faire quelques courses en sus de l’achat de sa baguette », contextualise Yann Barraud. « Pouvoir prédire la demande localement et le manque à gagner, nous a permis d’optimiser la production de pains. Puis, nous mesurons les résultats des ventes dans quelques magasins afin d’ajuster notre modèle prédictif, pour ensuite généraliser son usage ».
Pour approfondir sur Intelligence Artificielle et Data Science
