#3 La Data Science dans les grands groupes

Avec Ouriel Bettach, consultant senior en Data Science.

Écouter l’épisode

Transcription

François: Bonjour et bienvenue dans Post mortem. Aujourd’hui, j’ai le plaisir de discuter avec Ouriel Bettach, consultant en Data Science depuis maintenant plus de 5 ans. Bonjour Ouriel.

Ouriel: Bonjour François.

François: Ouriel, tu as travaillé pour plusieurs clients grâce à ton métier de consultant. Ça t’a permis de voir beaucoup d’environnement en termes d’équipes, de process et de méthodologies sur des projets de Data Science. Aujourd’hui l’objectif, ça va être de revenir, pas sur un post mortem spécifique au sein d’une équipe, mais de faire un petit panorama des différentes expériences que tu as pu rencontrer et de voir quelles sont les pitfalls récurrents et ce qu’on peut faire pour essayer d’en tirer des leçons à travers ces différentes expériences.

Ouriel: Oui, tout à fait. Pour me présenter un peu, je suis Ouriel Bettach, je suis Data Scientist chez OCTO Technology. J’étais avant dans un autre cabinet de conseil. Ça fait à peu près 6 ans que je fais de la Data Science. A la fin de mes études, je me suis tout de suite orienté vers ce domaine. Et effectivement, dans le métier de consultant, on est amené à voir beaucoup de situations. Principalement dans les grands groupes français et internationaux. Mais pas que. Ça m’est arrivé de faire des missions dans des startups, dans du service public ou même pour une association qui aidait les réfugiés, donc dans le milieu associatif. Principalement, je dirais que 90% de ce que j’ai vu se situe dans les grands groupes. Et comme tu le dis, le monde de la data a beaucoup évolué ces six dernières années. Surtout quand on parle de mise en production. Ce que je fais aujourd’hui avec mes clients n’a absolument plus rien à voir avec ce qu’on pouvait faire il y a six ans. C’est une très bonne nouvelle. Ça veut dire que les premiers projets et programmes en Data Science qui ont pu voir le jour et qui tournent en prod [en production], c’est un succès qui rend palpable la promesse de l’IA qu’on avait déjà depuis pas mal d’années. Les dirigeants des grandes boîtes commençaient un peu à s’inquiéter des promesses et de ne pas voir les choses tourner en prod et de ne pas voir les dollars qui arrivent. Là je pense qu’on commence à comprendre la promesse et on commence à passer de la slide à du concret.

François: Sur quels types de problématique as-tu été appelé dans tes premières missions? Est-ce que c’était « On veut appliquer du ML? Venez chez nous trouver des cas d’usage concret », ou est ce qu’il y avait déjà des cas d’usage identifiés en interne de type “Ah ici, on a une application qui par de l’ingénierie logicielle classique ne peut pas vraiment être résolue. On une maturité suffisante en interne pour comprendre que telle approche machine learning pourrait la résoudre.” Est-ce que tu avais déjà des scénarios si matures ou est-ce que c’est quelque chose qui est venu un peu plus tard ?

Ouriel: Alors non, clairement il y a six ans, ce n’était pas du tout le cas et on ne savait pas par où commencer. Il y avait tellement de choses à faire. On ne savait vraiment pas par quel bout prendre le problème. Il faut comprendre qu’on est dans des grands groupes qui n’ont pas l’agilité et la dextérité d’une startup qui peut dire « On lance quelque chose. On voit si ça marche, on est en test and fail, on est en mode fail fast où on peut se permettre de tester plein de trucs. » Là, ce qui se passe très clairement, c’est qu’on a une décision des C-Levels qui disent, « on veut voir de l’IA dans nos process. On ne sait pas exactement comment. » Donc ça va être le Chief Strategy qui va dire « OK, on peut en mettre ici, ici, ici » mais il ne comprend pas très bien ce que c’est non plus. Il va appeler ses équipes qui vont se retourner vers les équipes plus techniques avec son Chief Digital Officer, qui a un rôle qui est plus ou moins assez répandu aujourd’hui, mais qui ne l’était pas forcément il y a quelques années, et encore moins pour les Chief Data Officer. Du coup, au début, on tâtonnait. On ne savait pas exactement ce qu’on cherchait. On ne savait pas s’il y avait de la valeur dans les données. On ne savait pas si nos données étaient propres et une des questions principales quand on ouvrait, quand on faisait des cadrages avec nos clients. C’était « je n’ai aucune idée de ce que vaut ma donnée. » En fait quelques mecs qui font des extractions sur Excel et font quelques dashboard sur Qlik ou sur PowerBI. Mais pour faire du prédictif, on veut aller plus loin dans la donnée. Est-ce que ma donnée est suffisamment propre et clair. Est-ce qu’il y a suffisamment de valeur. On a mené des proof of concepts, des proofs of value. C’était ce qu’on a principalement fait entre 2015 et 2018. Avec au final peu de projet qui allait jusqu’à la prod. En fait, on faisait des proofs of concepts, des proofs of value et là, on mettait en évidence toutes les difficultés et tous les obstacles qui allaient se mettre sur ce chemin. Et ce n’est pas que des obstacles techniques, de problématiques logiciels classiques. On va avoir des soucis organisationnels. On va avoir des soucis très business. Il faut sensibiliser les opérationnels à dire comment on va changer leur métier, à dire comment demain ils vont utiliser un outil qui embarque de l’IA. Et il y a effectivement des soucis techniques. Il y a 5, 6 ans, on parlait pu de Dev Ops. On ne savait pas industrialiser de la data science. On pensait pouvoir faire de la data science comme on lançait un script ou une procédure SAS ou une procédure sur un outil statistique ou sur un outil de dashboarding. On se rend compte que pour avoir un produit orienté data science, c’est beaucoup plus compliqué que ça.

François: Est-ce que dans tes expériences en accompagnement, tu as pu voir des dénominateurs communs dans ces façons dont des projets pouvaient ne pas marcher de la façon dont c’était prévue? Est-ce qu’il y a des choses que l’on retrouve dans ces différentes expériences et sur lesquelles on pourrait essayer d’être meilleur en tant qu’organisation?

Ouriel: Moi, ce que j’ai vu honnêtement, c’est une vraie ascension. On a pris les problèmes, un par un, qui étaient toujours différents. Quand on arrivait à résoudre un problème, ce problème là que j’évoque, à quoi ça sert et pourquoi c’est bien et on ne va pas pousser. Ça c’est un problème qu’on peut dire résolu avec le cloud qui maintenant est beaucoup plus intuitif, beaucoup plus aidant à faire des choses avec que ce soit AWS, Azure ou GCP. Ils ont vraiment des offres d’accompagnement et des services managés qui sont aidants. Je dirais qu’on est plus formés, on est plus mature sur ces projets. Donc ça, c’était un des premiers problèmes que j’ai rencontré. J’en ai rencontré d’autres après, qui sont très différents. Par exemple, je suis allé chez un groupe de gestion d’eau, fournisseur d’eau. L’idée, c’est qu’on avait une startup chez un grand fournisseur d’eau, une initiative entrepreneuriale. On a monté une plateforme de streaming et de batch sur AWS avec une architecture lambda pour essayer d’aider les gens à mieux consommer leur eau.

François: Excuse-moi, je t’interrompt; architecture lambda ici lambda ne fait pas référence aux services de AWS, de function-as-a-service, mais c’est bien le type d’architecture, où l’on a en parallèle du batch et du stream et on essaye de réconcilier à partir d’une certaine fenêtre de temps pour avoir des donnés consistantes.

Ouriel: Effectivement, une architecture qui mixe du streaming, du batch. Et là, on a mis en prod. On a mis en prod une plateforme, des traitements, qui se matérialisaient vraiment à la fin par des rapports prédictifs sur la consommation d’eau qui ont été envoyés aux gens. Donc petite fierté. On a envoyé des choses et ensuite on a voulu aller plus loin. Et au moment de scaler là, ça n’allait plus. Pourquoi ? Parce que clairement, on n’avait pas adopté des principes DevOps. On n’avait pas vraiment de référent DevOps. Pour situer, on est en 2017. Dans nos équipes, on n’avait pas de référent on tâtonnait un petit peu sur ces sujets-là. Et en Devops, tant qu’on ne s’est pas pris le mur, on ne comprend pas pourquoi c’est utile. Que ça soit sur du versionning, sur du déploiement, sur la gestion des environnements. Et là, on commençait à comprendre qu’un produit data, au final, pouvait être assimilé à un produit logiciel. Dans nos équipes et dans ce que je voyais ; On avait un peu cette distinction à ce moment-là. En disant “Nan, quand on fait de la data science, on ne fait pas du logiciel, on développe des choses, ce n’est pas les mêmes technos, c’est pas les mêmes manières de déployer, etc.” Et là, je dirais que ce mur du scale. Depuis, on parle quasiment que de ça. C’est nos sujets principaux d’expliquer à nos clients et d’aider nos clients à scaler. On n’avait pas du tout cette logique DevOps, de Craftmanship, d’intégrer des bonnes pratiques de développement logiciel dans du code qui traite de la data et qui fait de la date science. Donc, je pense que ça, c’est apparu depuis avec des meilleures pratiques. Je dirai que c’était le projet de la familiarisation avec les services managés dans le cloud, avec le fait d’ouvrir ce monde-là à la Data Science.

François: Donc, à ce moment-là, on a vraiment une prise de conscience que, finalement, toutes les bonnes pratiques qu’on a eu en développement logiciel de version control, de tests, de configuration as code. Petit à petit, elles arrivent dans le monde de la data science, du ML et cette frontière commencent à disparaître ?

Ouriel: Ouais, c’est quelque chose qu’on a réussi un petit peu à tacler. Il y a une question qui est à quel moment on fait intervenir la prod dans le cycle de développement d’un projet ? J’ai un projet qui était assez parlant sur ça. C’est pour un groupe d’énergie. On avait un cas, un cas concret qui était de faire de la classification automatique sur des factures. C’était sur des systèmes SAP et on nous demandait de réinjecter de la donnée simplement dans SAP, de réinjecter le résultat d’un modèle de scoring ou de classification dans SAP. Et là, on a pris le problème un petit peu d’un angle différent. On a essayé de commencer par la prod, c’est à dire, quitte à ce qu’il y est des choses manuelles. L’important, c’est qu’au final, dans le système de l’utilisateur, il y ait quelque chose qui soit le résultat d’un modèle de machine learning. En fait, on va essayer de faire des scripts, faire des procédures pour récupérer les données depuis SAP, et faire tourner nos modèles en R, réinjecter avec le bon niveau de sécurité des données dans le modèle. Et là, ça tournait. C’était plutôt un gros succès. Parce qu’en à peine un mois et demi, on a mis le modèle en prod avec des résultats concrets chez les opérationnels qui avaient le résultat du modèle en production et qui pouvaient l’analyser. Alors on a eu un autre souci forcément. L’autre souci, c’était la maintenance. Et effectivement, ça vient confirmer ce qu’on est en train de dire. C’est une période où on a compris comment mettre des choses en production. Comment utiliser nos outils à bon escient. Mais est-ce qu’on sait maintenir des scripts qui peuvent être compliqués, par exemple en R ou en Python ? Est-ce qu’on a fait des tests ? On faisait peu de unit tests [tests unitaires] à cette époque-là. On n’était pas dans une approche Test Driven Developement — Cette Pratique de TDD dont on parle beaucoup, pas que dans la data. C’est plutôt la data [science] qui se source de ces méthodes là — Mais c’est des choses que l’on appliquait peu, dont on voit vraiment l’apport.

François: Le premier déploiement, avoir le système qui marche, c’est pas si dur que ça. La plupart des algorithmes pour répondre à des questions de classification sont des problèmes résolus. Si on a un data set évidemment suffisant. Et finalement le problème ça ne va pas être d’entraîner un modèle, mais c’est plutôt sa maintenance, son intégration. Faire la différence entre, le composant purement ML et son interface avec l’infrastructure. Et ça, OK, peut-être qu’on arrive à déployer très rapidement dans un sens, mais le parallèle de ça, c’est comment est-ce qu’on gère la maintenance. Et peut-être que, comme tu l’as dit, tant qu’on n’a pas pris le mur, on ne s’en rend pas compte. Tant que le modèle n’a pas drifté une fois en prod et qu’on fait des prédictions n’importe comment. On ne s’en rend pas compte. Et peut-être dans le meilleur des mondes, les modèles ne driftent pas et on n’a pas besoin de maintenance. Ce n’est pas toujours comme ça. Et en parallèle, le risque, c’est lorsque l’on part purement dans un environnement de staging, où on fait les choses bien. Beaucoup de tests. On assure d’avoir un pipeline résilient en termes de déploiement, monitoring, model management. Ça peut prendre des mois. Et pour un client, pour voir la valeur, on ne comprend pas, tant qu’on ne voit pas un modèle, des classifications et les outputs qui reviennent dans le système. On ne comprend pas à quoi ça sert tant qu’on n’en voit pas la valeur. Donc comment est-ce que tu estimerais le juste milieu ? Entre ces deux approches pour concilier, OK, du maintenable, du résilient, et en même temps délivrer de la valeur plus vite ?

Ouriel: Je pense que c’est quelque chose que l’on commence à craquer un petit peu dans les grands groupes. Je peux parler du projet dans lequel je suis maintenant. C’est dans une grosse data factory, une digital factory. Il y a une équipe qui va se charger de la valorisation des cas avec le business. Et il y a une entité dédiée à la résolution des cas. Et là, on va monter une organisation qui repose sur des squads de delivery qui vont être multi compétences. On ne va pas avoir une squad purement de Data Scientists. On va avoir un DevOps, un Data Engineer, un ML Engineer, un Software Engineer. Parce que, ce qui est important, c’est qu’on développe des produits et on ne fait pas des projets. Donc, le fait de développer un produit, dit, il faut une interface. Donc il faut un Software Engineer, un backend. On intègre aussi des Product Owner. La méthode agile facilite et aide la résolution de ces cas-là. Et le but, c’est qu’on s’engage, en un nombre très restreint de sprints, ici en 8 sprints de deux semaines. On s’engage à délivrer un MVP, un produit avec un nombre de fonctionnalités limitées, mais qui respecte toutes les normes, qui respecte les bonnes pratiques, qui est tamponné par les équipes de sécurité. On va avoir aussi un cycle de déploiement continu et ça, c’est quelque chose qui nous vient de la méthode, DevOps, on a un indicateur qui mesure le temps entre la création d’une feature et le moment où elle est dispo en prod. On va mesurer le nombre de mises en prod et ça on va s’inspirer des grosses startups, des grosses licornes, tel que Spotify — qui n’est plus du tout une startup — qui ont insufflé ces pratiques de déploiement continu et qui sont aujourd’hui un atout énorme qui rassure énormément le business parce qu’il voit des choses en prod. Le fait qu’il voit des choses en prod, incomplètes, mais qui tournent, qui valident les process, ça aide à prouver la valeur à leur chef, à débloquer des budgets et à faire des choses un peu plus poussées. Dans le projet dans lequel je travaille aujourd’hui, on a 15 squads de développement, et tous les mois, on lance des nouveaux MVP. Ça carbure. Alors ça pose d’autres soucis, évidemment. Un des gros soucis qu’on a, par exemple, c’est le data management. Pour pouvoir faire 15 MVP en même temps, il faut que les données soient propres, qu’il y ait de la valeur qui soit prouvée dans les données, mais que la donnée soit propre, dispo, que les flux de streaming fonctionnent correctement, etc. Surtout que l’on parle de sujets où les données proviennent principalement de capteurs. C’est des données IoT. Donc, il faut gérer le flux de la donnée, ce qui rend le streaming parfois un petit peu compliqué et des quantités astronomiques de données qui ne sont pas forcément managées de la bonne manière. Il y a une équipe au sein de notre factory qui est dédiée au data management. Je dirais que c’est un des gros challenges de ce qu’on fait aujourd’hui. Qui est l’owner de la donnée ? Qui va s’assurer que la donnée est au bon endroit et au bon moment, dans la bonne qualité ? Qui va gérer les données manquantes et erronées ? Et comment on va organiser ? OK, c’est super, on a datalake bien structuré, etc. Mais comment on s’y retrouve avec des grosses organisations comme ça ? C’est un des gros sujets du moment qui n’est pas encore craqué. Le sujet du data management qui se mélange un peu aussi avec le sujet MLOps. Un modèle, c’est un objet, donc l’objet pickle, qui est la librairie pour sérialiser un objet. Pouvoir le stocker et l’appliquer à différents process. Cet objet-là, il a aussi besoin d’être managé. Il a aussi besoin d’être monitoré, versionné, on va le suivre comme tu disais tout à l`heure, on va suivre son drift. Pour voir s’il est toujours réel. S’il faut le mettre à jour. Comment on s’assure que le modèle avec lequel on le met à jour va être meilleur ou pas que celui qui était là ? Qu’on n’aura pas de régression ? Qu’il n’overfit pas, évidemment. On va suivre tout un tas de métadonnées sur ce modèle. Et ça du coup, tu vas aussi vouloir attacher un dataset de référence, sur lequel ton modèle a été entrainé. Mais il doit aussi dire sur quelles données ton modèle doit être ré-entraîné. Ça va être super important. Comment tu t’assures que t’as pas des biais dans le dataset d’entraînement qui vont générer une régression dans ton modèle ? Ce sujet de Model Management est lié au sujet global du Data Management. Pour dire qu’au final, on doit tout suivre. On ne peut plus laisser des choses dans la nature parce que ce n’est pas maintenable, ça ne tient pas la route. Ça ne tient pas la longueur.

François: C’est le “Pas Maintenable” qui est vraiment intéressant ici. Parce que finalement, ces modèles-là, quand ils sont développés en prototype, en MVP, on peut se contenter d’un extract fait à un instant T dans le temps. On peut se contenter d’un notebook pour expérimenter, par exemple sur Jupyter faire des imports et tester, avoir un modèle, sérialisé sous pickle, si on est sous Python, et le déployer. Le challenge ici, c’est effectivement l’industrialisation — Une fois qu’on déploie ça, on ne joue plus dans la même échelle de temps. On ne joue plus dans le temps du prototypage. Une fois que c’est déployé, on doit avoir une instrumentation qui permette de mesurer tout ça. Le facteur humain doit sortir de la boucle à ce moment-là. Je pense que c’est quelque chose que tu as rencontré; Si on a besoin d’un humain dans la boucle pour détecter un drift, se charger manuellement du processus de ré-entraînement, vérifier si on under/overfit, ça marche peut être pour un modèle sur un produit qui n’est pas régulièrement utilisé, mais lorsque que l’on veut scaler en terme d’instances de modèles déployés ou si on a un modèle par client, par exemple, ou pour un certain nombre d’utilisateurs. À partir d’une échelle, on ne peut plus se permettre d’avoir un tel fonctionnement. Et en fait, ce MLOps, donc les bonnes pratiques du DevOps, d’automatisation de déploiement de software il vient finalement pour du ML aussi. C’est à dire, il faut avoir ce pipeline de réentraînement, de vérification des métriques et de déploiement. Il y a énormément de projets qui sortent en ce moment. Ça fait un petit peu de temps, on peut penser à Uber, Michelangelo donc ils n’ont pas vraiment open sourcer, mais ils ont un article de blog à ce sujet-là. ML Flow, la bibliothèque de Data Bricks à ce sujet-là. Chaque GAFA, on a l’impression, publie un article sur son blog Engineering pour nous parler de sa plateforme de MLOps. Est-ce que c’est l’adoption d’un tel système qui est la prochaine étape ?

Ouriel: Je pense que ça peut l’être. Et ce qui me parait d’autant plus important, c’est de choisir les bons indicateurs pour qu’ils parlent aux métiers. Alors comme tu dis effectivement, il n’y a pas d’humains dans cette boucle-là. Il y a un énorme sujet de change [conduite du changement] ici, de comment quelqu’un qui fait un métier va adopter un nouvel outil à son métier, et il doit lui faire confiance. On n’en a pas parlé mais c’est le sujet d’explicabilité des modèles qui est hyper important dans ce qu’on fait. Jamais tu vas convaincre un opérationnel d’utiliser ton modèle, s’il n’a pas une confiance dans son résultat, s’il n’est pas apte à comprendre ce résultat, à savoir pourquoi il a produit ce résultat. On parle beaucoup des modèles black box et surtout quand on fait du Deep Learning. On a beaucoup de mal à expliquer le pourquoi d’un modèle de deep learning. Quels sont les attributs qui ont contribué à ce que tu vois cette mesure, ce score sur ton outil ?

François: Parce que à ce niveau-là, c’est vrai que si sur une régression, on peut clairement expliquer, d’accord, on a tel coefficient pour telle caractéristique et ça va être assez intuitif pour n’importe qui de comprendre que telle caractéristique a un effet positif ou négatif sur l’output. Arbre de décisions, pareil. On a un petit côté intuitif. “Ah d’accord, on a des branchements”. Un réseau de neurones, quelle que soit sa profondeur. Finalement, ça va perdre du sens très rapidement dans la mesure où on ne pourra pas mettre un sens physique concret sur chacune des cellules de ce neurone.

Ouriel: Tout à fait, en machine learning traditionnel, on a des outils pour expliquer. C’est ce qu’on fait, par exemple en ce moment, sur mon MVP, on va mettre en place quelque chose qui, associé au score, permet de dire pourquoi ce score est élevé et quelle métrique a fait que ce score soit élevé ? C’est une chose que l’on pouvait faire et qui ne sont peut-être pas impossibles, mais beaucoup plus compliqué à faire avec du deep learning. Par exemple, dans la conduite autonome, on utilise beaucoup de deep learning. C’est très important de savoir pourquoi le modèle a pris telle décision à tel moment, donc la décision de s’arrêter pour comprendre si sa décision était légitime. Pour comparer avec des cas où le modèle a pris la décision de ne pas s’arrêter. L’enjeu est énorme aussi sur ce sujet de la transparence du modèle, et la confiance en le modèle.

François: Est-ce que maintenant, tu rencontres dans les missions que tu rejoins, un besoin plus identifié de comprendre les résultats de ces algorithmes de machine learning et d’avoir des outils de pilotage, d’explicabilité qui accompagne tes livrables?

Ouriel: Tout à fait. Je pense qu’on a toujours voulu comprendre. Jamais on a pu convaincre des gens avec des algorithmes s’ils ne le comprenaient pas le fond. S’il y a des vrais experts métiers, jamais un expert métier va faire confiance à un système dont il ne comprend pas le mécanisme de décision. Je pense que la différence, elle s’est faite à quel moment du process tu va intégrer ça ? Avant, on avait besoin de comprendre la conception. On a besoin de comprendre l’algorithme dans ses grandes lignes. Je ne peux pas compter le nombre de fois où j’ai fait des schémas au tableau pour expliquer ce que c’était un SVM, un support vecteur machine, parce que c’est un modèle qui est assez intuitif à expliquer. Que quelqu’un de métier, va très bien comprendre. Et du coup, il avait ce besoin-là, de comprendre au moment du build [ici, lors de la phase de conception du modèle, de l’entraînement], qu’est ce qui allait générer un score ? Aujourd’hui, on a toujours ce besoin-là. Là où ça va plus loin, c’est qu’on a besoin de comprendre en production, qu’est ce qui fait que le modèle donne cette prédiction ou ce scoring-là ? On va en fait monitorer la compréhension du modèle. Ça va être une des métriques qu’on va vouloir monitorer. Alors qu’avant c’était on comprend l’idée au démarrage ou on va comprendre pourquoi on a ces prédictions là au démarrage, mais une fois qu’on va en prod, on en a plus besoin. Pour moi, c’est ça qui a changé dans le mindset.

François: Ça, c’est une thématique qu’on appelle l’accountability, la responsabilité des modèles, qui est vraiment de plus en plus présente en production, avec des besoins. Je pense c’est aussi une prise de conscience, peut-être du public, de manière plus générale sur l’impact de ces systèmes dans notre quotidien, etc. Qui fait que maintenant, pour chaque inférence, on veut comprendre pourquoi un tel résultat. Parce qu’il y a une responsabilité, la peur de système de black box, etc, fait qu’on ne peut pas se contenter de comprendre la distribution dans le jeu d’entraînement, la distribution des données, de leurs propriétés statistiques. Mais on veut aussi maintenant avoir une plus fine compréhension de pourquoi sur tel inférence, on a ce résultat qui est proposé. Donc là, on a déjà eu l’occasion d’évoquer quelques bonnes pratiques pour faciliter le déploiement de ces systèmes. D’une part, l’application des bonnes pratiques du monde du DevOps qui passe au machine learning. Ce concept de MLOps, il y a une grosse prise de conscience à ce sujet-là. Beaucoup d’outils qui sortent à ce sujet-là, ML Flow qu’on a mentionné par exemple ne librairie Open source. Dans l’organisation des équipes, on a aussi la question d’avoir des équipes full stack, c’est à dire plutôt qu’avoir une équipe d’ingénieurs logiciels, les Devs Backend, les Devs Frontend d’un côté, les Sata Scientists d’un autre. Maintenant, on a tendance à voir des équipes qui mélangent ces compétences pour proposer un projet concret plus rapidement. Est-ce qu’il y a d’autres bonnes pratiques ou évolutions que tu as remarqué au cours de tes dernières missions, peut-être plus récentes, qui montreraient des bonnes pratiques à partir desquelles s’inspirer ?

Ouriel: Une des évolutions qu’on a eu, c’est de plus tellement parler de projets, mais de produits. Alors ça peut paraître la même chose. Mais par exemple, pour citer un projet sur lequel j’avais été très investi chez un grand industriel. On avait eu des équipes assez distribuées avec des Software Engineers, des DevOps, des Data Scientists, etc. On mettait en production des API. On avait des démonstrateurs pour illustrer ce qu’on faisait. Le gros souci qu’on avait, c’était un problème d’adoption. Peut-être que quelque chose qui a manqué à pas mal de sujets, c’est vraiment d’intégrer, l’usabilité, intégrer l’user expérience dans les produits data qu’on aurait pu créer. Globalement quand c’est des Data Scientists ou des ingénieurs qui créent les produits. Ils vont répondre aux besoins qu’ils considèrent être le besoin de leurs utilisateurs, mais qui ne l’est pas forcément. Dans pas mal de projets Data Science. On n’a pas assez intégré cette notion-là. Ramener l’utilisateur au centre du produit. On a un peu tendance à le sortir et à lui mettre des choses sur étagère. Et c’est sur ce projet-là qui avait toutes les bonnes pratiques en termes de DevOps, etc. On avait un cycle de mise en prod qui était bon, avec un déploiement continu. Mais, le fait qu’il y ait une incompréhension des utilisateurs et qu’il fallait en fait passer trop de temps [à leur montrer comment le système fonctionnait]. Si déjà on passe trop de temps à expliquer à l’utilisateur comment utiliser son produit, c’est qu’on est un petit peu à côté parce que. Parce qu’il n’a pas été embarqué dans la conception et du coup, comment on sait que ça répond à son besoin ? Un produit data science, ça ne va pas être utilisé par des Data Scientists ou par des ML Engineer, ça va être utilisé par des utilisateurs, des business users, qui doivent avoir leur avis et pouvoir donner leur feedback dès la conception.

François: Est-ce que tu as ressenti au cours de tes dernières expériences, une nouvelle tendance, une nouvelle direction qui se prendrait dans la conduite des projets ML que tu peux avoir. Quelle serait la prochaine frontière que tu identifies ?

Ouriel: Je pense qu’il y en a pas mal. On peut parler de frontières de sécurité. Aujourd’hui, on va s’assurer que chaque étape respecte pas mal de standards de sécurité parfois en termes de machine learning, ça peut être plus compliqué avec des sujets de chiffrement. Ça peut être une des tendances ou on va voir des choses évoluer. Il y a des sujets autour de tout ce qui est Edge Computing. Donc, on voit que L’IA devient physique, que ça soit sur de l’IoT. On a envie de matérialiser l’IA dans les systèmes embarqués, donc ça pose d’autres contraintes de mise en production. Donc c’est un sujet sur lequel je pense qu’il y a pas mal de gens qui travaillent, qui va probablement évoluer et des sujets plus organisationnels. On est en train de craquer une bonne partie des sujets organisationnels avec ces sujets de data management. Je ne serai pas surpris qu’il y ait une solution de data management killer qui sorte dans les années à venir, qui craque le problème quoi. Il y a une très bonne raison pour laquelle on n’a pas cette solution. C’est des process complexes, longs, qui sont spécifiques aux entreprises, donc c’est compliqué d’avoir une solution de la sorte. Pour moi, la tendance devrait être d’avoir un mega management de la data, des modèles et qu’on va réussir à utiliser les métadonnées qu’on aura pu super bien organiser grâce à cet outil, qu’on pourra les restituer à l’utilisateur, on ne fera pas juste du monitoring, et que ça sera une partie intégrante du produit.

François: On se rapproche de la fin de l’épisode. Est-ce qu’il y a une ou des ressources que tu souhaiterais recommander à nos auditeurs et à nos auditrices en termes de bonnes pratiques pour mener et déployer des produits machines learning ?

Ouriel: Aujourd’hui, on a beaucoup de ressources. Moi, j’utilise principalement les blogs. Le blog Towards Data Science est très complet. En termes de lecture, il y a un livre qui reprend les bonnes pratiques de data management s’appelle Data Management at Scale de O’Reilly. Et après une Bible qui est le livre de Deep Learning de Karpathy, Goodfellow, c’est un peu la bible du deep learning qui permet vraiment de comprendre l’intuition derrière toutes ces méthodes-là qui est lié au deep learning. Mais tout reste très vrai pour le machine learning traditionnel. Et je pense que comprendre l’intuition, pas que les modèles, mais des logiques et du pourquoi on fait tout ça, aide à prendre du recul et à trouver le bon moyen d’aider nos clients. Je suis consultant avant d’être data scientist, mon métier, c’est de trouver le bon moyen d’aider le client et surtout de lui expliquer pourquoi c’est le bon moyen et pourquoi ça va l’aider.

François: Ok, ça marche, je mettrais ces deux livres, Data Management at Scale et le livre Deep Learning de Goodfellow dans les notes de l’épisode.

Ouriel: Et j’ajouterai toutes les interviews de tous les talk de Yann LeCun qui sont absolument incroyable. Où il explique vraiment cet aspect intuition. Il passe beaucoup de temps à expliquer la partie, le fait qu’on ne cherche pas forcément à reproduire des mécanismes humains dans des modèles de data science. Il a donné l’exemple des ailes d’un avion, que je trouve super parce qu’il dit “Est-ce qu’un avion a vocation à reproduire des ailes d’oiseau ? Non, pas du tout. Mais il s’en est inspiré. Il s’est inspiré du fait que ça marchait plutôt bien. Le fait que des ailes pour voler du coup on va s’inspirer du thermo dynamisme, de pleins de règles physiques pour lesquelles un oiseau vole, on va essayer de les appliquer à l’avion. Mais on voit bien que les ailes d’un avion ça n’a absolument rien à voir avec les ailes d’un oiseau.” Du coup, il fait ce parallèle là pour expliquer où on va avec le deep learning. On ne cherche pas forcément à reproduire des cerveaux artificiels. En revanche, on s’inspire du système neuronal qui marche par petite fonction et par couches de petites fonctions. Et toutes ces fonctions-là, amplifiées, créent un système beaucoup plus complexe. Grâce à ce système, on arrive à prendre des décisions. C’est ça qu’on va essayer de répliquer, mais en l’appliquant du coup à ce qu’on sait faire.

François: Un petit mot pour la fin?

Ouriel: Continuons de mettre en production. Continuons de tester, il faut tester des choses, échouer pour s’améliorer. Il faut surmonter chacun des obstacles les uns après les autres, en découvrir de nouveaux. C’est comme ça qu’on va progresser.

François: Ça marche. Merci beaucoup Ouriel pour cet échange.

Ouriel: Merci François.

François: J’espère que ce troisième épisode de Post Mortem vous a plu. Je vous invite à partager cet épisode avec quelqu’un qui pourrait l’apprécier. Et n’oubliez pas de vous abonner pour rester au courant des prochains épisodes. A une prochaine, bye.

Épisode enregistré en octobre 2020

Notes de l'épisode

Ouriel Bettach, Data Scientist depuis plus de 6ans, nous propose un panorama de ses expériences au sein de grands groupes industriels sur des projets de machine learning (ML).

On en profite pour faire le bilan sur la façon dont les grands groupes approchent des projets ML et d’évoquer les points bloquants récurrents dans ces projets, avant d’ouvrir sur les challenges qui se dressent à l’horizon.

Points clés ;

1. Avoir une équipe multi-compétences (Software Engineer et Data Scientist) dans une même squad permet de livrer des produits (pas simplement mener des projets) ML plus rapidement.
2. Le data et le model management sont le nerf de la guerre pour répondre aux questions de montée en charge. Le ML Ops est là pour rester. Voir ML Flow.
3. Au-delà du technique, la conduite du changement pour le déploiement d’un produit ML doit être préparée avec les utilisateurs business.

Références

Ouriel nous recommande le blog Towards Data Science pour se tenir au courant des dernières tendances du ML. Pour les livres, deux recommandations cette semaine, une lecture sur le data management et un classique du ML :

- Data Management at Scale: Best Practices for Enterprise Architecture de Piethein Strengholt, ISBN 9781492054788

- Deep Learning de Ian Goodfellow, Yoshua Bengio et Aaron Courville, ISBN 9780262035613

En bonus, Ouriel nous recommande chaudement les interventions de Yann Lecun sur l’apprentissage profond.