Quel est le quotidien de nos consultantes et consultants en projet ? Quels sont les challenges techniques à relever et quelles solutions sont apportées ? Derrière une mise en production réussie, un déploiement ou un Proof of Concept, il y a des consultantes et des consultants, une équipe, des technologies et beaucoup d’expertise et d’intelligence collective ! Cette série d’articles vise à vous dévoiler l’envers du décor, à travers leur témoignage.

Antoine est un statisticien de cursus. Il a choisi de surfer sur la vague Data Science depuis 2017, pour maintenant être en charge de la mise en production de services de Machine Learning dans le monde de l’entreprise. Il a rejoint Devoteam Revolve en début d’année 2020, avec pour motivation de contribuer à l’ambition de Revolve de se positionner en acteur majeur du marché de la prestation en MLOps. Antoine fait aujourd’hui partie de la communauté ML, qui mène en interne des débats d’idées pour faire émerger la connaissance des pratiques de pointe.

Sur quel sujet travailles-tu actuellement ?

Je suis en mission au sein d’une équipe d’analystes dans l’entité digitale d’un groupe industriel français. Notre objectif est de livrer une plateforme numérique qui sera un support d’aide à la décision pour les opérateurs dans les traitements du produit final. J’interviens en tant que Data Scientist et ingénieur Cloud pour la construction de l’infrastructure qui supportera ces technologies. L’enjeu étant de veiller à ce que la consigne stipulée par le client soit appliquée, qui est d’automatiser autant que possible la mécanique des multiples rouages back-end. Afin qu’à terme, des profils non experts de cette logistique IT puissent intervenir dans le cadre de la commercialisation et de la gestion après-vente de ce livrable.

Et sur la partie Machine Learning ?

J’interviens d’abord sur la partie expérimentale du design du Machine Learning. Cette mission consiste à trouver une formule mathématique (un modèle) qui sera en capacité de prédire un comportement futur cible, à partir d’un algorithme d’apprentissage et d’un ensemble de données dont on dispose à l’instant présent. L’application de ce modèle vise à prescrire des recommandations sur la base de ce potentiel prédictif, tout en garantissant une marge d’erreur acceptable avec la réalité du terrain.

En parallèle, la mission qui m’est confiée est de bâtir le socle AWS qui pourra supporter cette charge opérationnelle, lorsque nous distribuerons la solution aux utilisateurs finaux. Actuellement, nous sommes encore en phase de prototypage. Nous procédons à l’essai d’une architecture pilote sur un cas d’usage spécifique, avant de passer à la phase d’industrialisation, en vue de l’intégration progressive de divers usines dans l’interface digitale. A ce propos, Data Scientists, experts métiers et consultants SRE (site reliable engineering) se concertent dès à présent pour statuer sur certains problèmes d’ingénierie, comme par exemple le choix entre l’adoption d’une approche générique, ou une approche plus spécifique à chacun des cas d’usage (i.e. un modèle pour tous, ou un modèle sur mesure pour chaque usine).

Peux-tu présenter en détail le travail du Data Scientist ?

Nous traitons des données qui sont émises par les capteurs dans les usines. Ces données reflètent des phénomènes évolutifs dans le temps (séries chronologiques). L’analyste doit capter les phénomènes intrinsèques; notre rôle est de bien saisir quelles sont les attentes de l’utilisateur final (opérateur sur site) par rapport à ce que l’analyse de la donnée peut lui fournir.

L’opérateur a l’expertise du processus industriel, qui lui permet de savoir quel paramétrage du traitement va avoir tel impact, et son bénéfice sur le produit final. En tant que Data Scientist, nous devons identifier les rapprochements à faire entre les données issues des capteurs, et ensuite transcrire cela dans une logique algorithmique qui restituera la capacité recherchée d’inférence du futur.

Cela suppose de faire du tri dans les données ?

Actuellement nous sommes plutôt dans une situation de manque d’informations que de trop plein, mais oui, nous sommes amenés à décider quelle information est utile et quelle autre ne l’est pas. Nous avons ensuite la responsabilité de construire les pipelines qui vont servir à faire fonctionner cette solution. Donc si nous consommons une donnée pour exécuter le modèle, nous devons aussi assurer son acheminement. A savoir que nous avons besoin d’un maximum de données pour que le phénomène observé soit correctement représenté au travers du modèle. Mais attention, si le volume d’informations est trop important, cela complexifie le rapatriement des données pour que le modèle serve bien ses prédictions.

Les données sont-elles également pondérées ?

Il y a un traitement binaire oui/non, est-ce qu’une information est utile ou pas ? Puis nous avons recours à une logique d’apprentissage machine : à vrai dire, la pondération est au cœur du principe du Machine Learning, il s’agit de calibrer le modèle pour avoir des poids qui représentent justement l’influence de chacune des caractéristiques (features) sur la variable cible.

C’est ce qui fait l’apprentissage, nous donnons des variables en entrée de l’algorithme, au Machine Learning de saisir la bonne approche de combinaison et d’attribution des poids adéquats au problème.

Comment ce projet a-t-il démarré ?

Il y a tout d’abord eu une phase expérimentale de preuve de concept (PoC), réalisée par un autre prestataire, qui a livré des “notebooks”. La restitution a montré à l’équipe en interne que la démarche était réaliste et pouvait aboutir à une solution. En l’état, le code n’était pas industrialisable, mais il montrait ce qu’on pouvait faire avec les données.

Comme il y avait une volonté d’investir sur le Machine Learning dans le cadre d’un programme à grande échelle, ma candidature a été retenue pour passer des notebooks aux scripts, et ensuite mettre en place un pipeline CD4ML (déploiement continu de solutions d’apprentissage machine). Nous avons basculé sur AWS. Et depuis, nous intégrons les bonnes pratiques d’ingénierie logicielle, et tout ce qui fait partie de la boîte à outils du consultant Revolve : GitLab, CloudFormation, Docker, etc. Dans ce projet mon rôle est double. Dans un premier temps en tant que data scientist, faire de l’itération sur ce qui a été produit (développement de fonctions applicatives en Python), puis construire le service API qui permettra aux utilisateurs d’envoyer une requête et de récupérer en retour des prédictions.

Peux-tu préciser ce qu’est un notebook ?

Le Machine Learning, c’est dans les faits une discipline scientifique, le travail consiste à mener des expérimentations. 9 fois sur 10 les tentatives seront improductives. Car une solution d’apprentissage machine est dans la plupart des cas sujette à un processus d’optimisation stochastique. Le problème mathématique posé sous le capot est de l’optimisation sous contrainte, et cette optimisation contient inévitablement des degrés de liberté. Il arrive donc souvent que l’expérimentation débouche sur des résultats qui ne sont pas assez satisfaisants pour aller au-delà de la phase laboratoire.

Le notebook vient en support à ce constat. Conçue en 2014, cette application est basée sur de l’HTML et de l’injection de code en Julia, Python ou R (JuPytR), trois langages informatiques massivement adoptés par la communauté Data Science. Le noyau permet d’exécuter le code dans un environnement hôte local, et d’avoir une interface web qui allie édition de code et édition de texte. Au lieu de développer dans des scripts, puis d’utiliser un terminal pour exécuter le programme dans le but d’obtenir une réponse, le notebook permet d’explorer/exposer rapidement des résultats numériques ou graphiques, tout en agrémentant de commentaires (avec le format d’écriture Markdown). Sur la base de ces résultats, le Data Scientist est alors amené à échanger avec le métier. Il doit alors convaincre que les résultats produits ont une valeur concrète. Le notebook permet donc de mener à bien ce procédé d’expérimentation, depuis l’écriture du code jusqu’à la restitution des résultats. Il y a cependant un débat sur le sujet : est-ce que le notebook ne sert que pour la phase de lancement de projet, ou peut-il être un support contenant l’ensemble du code source en environnement de production ?

Quelle est ta position sur ce sujet ?

Je considère que le notebook est pratique pour itérer rapidement, d’autant plus si on est sur le cloud AWS, avec la ressource Amazon SageMaker Studio qui propose l’accès à un serveur JupyterLab enrichi. Maintenant, dans mon mode de travail, je m’en sers sous forme de bac à sable. Dans le contexte de la mise en production d’un service de ML, on se passe du besoin d’observer les résultats d’une tâche précise. AWS automatise cette démarche d’orchestration et de supervision des opérations.

Donc le notebook est un bon instrument pour avoir une interaction directe avec son code, mais il peut devenir une épine dans le pied quand on veut le disposer dans une architecture adaptée aux enjeux du passage à l’échelle. Pour cette raison, nous faisons d’habitude le choix d’adopter des services managés comme Lambda, Batch ou Glue pour exécuter nos scripts en Python, quand on veut distribuer sur une ou plusieurs VM (machines virtuelles). On garde cependant les Notebook dans les archives pour conserver l’historique des expérimentations précédentes. Sur ce point, je précise néanmoins que des moyens existent actuellement pour embarquer des notebooks Jupyter en environnement de production (e.g. Papermill, Kale).

Qui sont tes principaux interlocuteurs ?

Je travaille principalement avec le chef de projet des services de ML qui seront intégrés sur la plateforme, et qui est responsable du suivi d’avancement des tickets qui me sont affectés. En tant que Data Scientist, la bonne compréhension du contexte métier est un élément majeur. Donc cela amène de nombreux échanges avec les experts: l’ingénieur process qui a l’expertise du système étudié, d’autres ingénieurs, des consultants Revolve qui sont impliqués dans la construction d’un data lake, des intervenants AWS Professional Services qui travaillent sur les outils facilitant l’approvisionnement en données. Comme les Data Scientists sont les premiers clients de l’ingestion des données, nous devons aussi faire entendre nos attentes, nos besoins sur les procédures de la livraison de la donnée.

Le métier de Data Scientist nécessite aussi des compétences de communication ?

Par nature, l’activité du Data Scientist tend à apprécier et valoriser le contenu informationnel des signaux faibles enregistrés dans une base de données. On analyse le présent et le passé : comparé au rôle de Data Analyst, on est amené à aller au-delà de l’analyse descriptive et exploratoire. On doit par ailleurs apporter des renseignements révélateurs qui émergent de lots de données parfois massifs, afin de les communiquer aux décideurs. Dans ce cadre de travail, le Data Scientist ne peut pas travailler isolé dans son laboratoire. En l’occurrence ici, sa finalité est d’apporter des recommandations qui auront potentiellement un impact sur les prises de décisions des opérateurs. Il a donc tout intérêt à être au plus près du terrain.

Qu’est-ce que le Cloud a changé sur ce domaine ?

Il y avait beaucoup plus de complexité. Le Cloud AWS donne accès à un catalogue de ressources qui me permettent de ne pas avoir à gérer la complexité de l’optimisation des contraintes réseau, des VM. Je peux directement utiliser un service comme SageMaker et livrer mon service sur un point de terminaison (accessible via requête HTTP grâce à API GateWay et Lambda). Le cloud masque toute la complexité des couches inférieures. En tant que Data Scientist, je veux simplement me limiter à fournir des artefacts (scripts, fichiers de configuration) qui résultent d’expériences d’apprentissage machine.

Sagemaker fournit par exemple des modèles pré entraînés, est-ce que tu les utilises ?

Je suis plutôt d’avis de partir de zéro, c’est plus motivant de partir d’une page blanche, d’un notebook vierge. AWS propose des services managés comme Forecaster ou Rekognition, et des modèles pré-entraînés sur le Marketplace, qui permettent à celles et ceux qui ne sont pas experts ML d’intégrer de l’IA en quelques clics. Les algorithmes pré-entraînés peuvent être bénéfiques pour déployer rapidement une application. Mais je préfère personnellement faire tout le travail préparatoire au design du modèle : comprendre la problématique, explorer les données à disposition et ensuite concevoir et paramétrer le modèle. Dans ce travail, on écoute les attentes et les besoins du client. Pour faire une analogie avec le métier d’architecte, on construit sur plan: je ne construis pas une maison standard, je préfère utiliser toutes les possibilités offertes par les solutions open-source et le cloud, ajouter une part d’exotisme à la solution.

Quels étaient les challenges de cette mission ?

J’ai commencé ce projet durant le confinement, donc à distance, et c’était un challenge. C’est plus compliqué dans ces conditions de se faire connaître, d’avoir des moments privilégiés d’échange comme au cours d’une pause café, de parler de tout et de rien et au passage de récupérer des informations pertinentes. Établir des relations de travail, obtenir des informations n’était donc pas simple au départ. 

Plus généralement, l’organisation du travail de Data Scientist peut aussi être un challenge : si on ne s’impose pas une feuille de route, on peut facilement tourner en rond et rester indéfiniment en phase de R&D. On risque de s’écarter de la philosophie agile qui suggère d’itérer rapidement une première fois, avant d’évoluer pas à pas vers une solution finalement mature et conforme au besoin. Quand l’expérimentation n’aboutit pas, il est bon de savoir prendre de la distance et de tourner la page. On peut parfois perdre une semaine ou deux sur une approche qui ne donne pas de résultats, il faut alors pouvoir expliquer au client qu’il ne mise pas sur nous pour rien, mais qu’il faut parfois du temps pour obtenir quelque chose de solide.

Où en est le projet aujourd’hui?

Nous sommes en phase d’UAT (User Acceptance Test), la solution respecte le attentes du MVP (Minimum Viable Product), et l’utilisateur a pu expérimenter l’interface graphique web de la solution. Il est réjouissant de se plonger dans la plateforme, qui est visuellement agréable à utiliser. Et de savoir que nous avons produit les moteurs qui la font fonctionner. L’amélioration continue viendra de l’expérience utilisateur au travers de cette suite de services. Et nous passerons ensuite au réentraînement du modèle, avec actualisation des données d’apprentissage, et aux redesigns éventuels.

Comment se passe ton parcours chez Revolve depuis ton arrivée ?

Quand j’ai rejoint Revolve début 2020, j’avais déjà côtoyé des consultants Revolve durant toute l’année 2019. Je participais aux Lunch and learn du vendredi en tant qu’externe, j’avais eu l’occasion de discuter avec les contributeurs de la communauté Machine Learning.

J’ai alors choisi d’intégrer Revolve car j’ai été séduit par ce projet de toute l’organisation de mettre en avant une compétence en Machine Learning portée par le Cloud. C’est une domaine en pleine expansion, où l’état de l’art n’est pas encore défini, et les débats entre les sachants sont nombreux. Au sein de Revolve il y a de plus en plus de personnes qui veulent passer du temps sur ce sujet, et ensemble nous pouvons construire une base de connaissances qui sera la base d’une amélioration en continu. Nos rendez-vous hebdomadaires du vendredi nous permettent de mettre nos REX en commun et de travailler avec un but clairement défini. Nous apprenons beaucoup de ces rendez-vous. Ce contact entre les consultants, et entre la direction et les consultants, est ce qui m’a convaincu de changer de société. J’apprécie d’avoir l’opportunité d’entreprendre en interne, d’être dans un environnement très proactif et réactif. Le projet de communauté a du sens, cela prend du temps pour capitaliser sur un pool de compétences en Machine Learning, mais nous voyons la communauté grandir de jour en jour avec de plus en plus de seniors.