A la croisée de plusieurs disciplines, la Data Science s’appuie sur des méthodes et des algorithmes pour tirer des informations et de la connaissances à partir de données structurées et non structurées. Encore inconnu il y a quelques années, le métier de Data Scientist évolue très rapidement; au travail sur les jeux de données, à l’entraînement et au perfectionnement des modèles s’ajoutent maintenant des compétences Ops et Cloud. Afin de prendre la mesure de cette évolution et confronter notre expérience à celle du marché, nous vous proposons une série d’entretiens avec des Data Scientists externes à Devoteam Revolve.

Consultant Data Scientist après une carrière dans la recherche autour de sujets liés à l’énergie, Christophe Thibault a choisi de se reconvertir pour travailler sur le traitement de données et devenir Data Scientist. Après trois années dans le métier, il partage avec nous ses réflexions sur le métier de la Data Science, ses enjeux au quotidien, les cas d’usage et les problématiques traitées, et les outils utilisés.

Peux-tu te présenter en quelques mots ?

Je suis consultant Data Scientist depuis 3 ans. J’ai un cursus de physicien, avec un diplôme d’ingénieur en chimie et un Phd en physique. J’ai fait une partie de ma carrière dans la recherche fondamentale et expérimentale sur des sujets liés à l’énergie : hydrogène, batteries, etc. J’ai travaillé en France, en Europe et en Asie, puis j’ai eu envie de changement. J’ai réfléchi à une reconversion professionnelle, j’avais déjà travaillé sur le traitement de données et la Data Science lors de mon PhD, sujet émergent à ce moment, m’intéressait. J’ai postulé au master Big Data Telecom ParisTech, et j’ai suivi cette formation durant 18 mois. Je suis maintenant Data Scientist, et depuis deux ans et demi je travaille dans l’équipe digitale d’un grand groupe industriel français.

Quelles compétences te sont les plus utiles dans ton travail ?

J’ai la chance d’avoir un background dans la physique et la chimie, c’est un plus pour travailler dans cet environnement. Nous travaillons essentiellement sur des grandeurs physiques (débits, concentrations, conductivités, etc.) , ce sont des concepts que je connais bien et cela aide pour travailler sur les données. Il est très important de bien comprendre les relations qu’il pourrait y avoir entre les différentes grandeurs et concepts. Les experts métier sont aussi là pour nous expliquer les différents phénomènes des usines, et les processus mis en œuvre. Ils nous aident également à valider les résultats.

Pour la data, nous travaillons sur les séries temporelles et sur des prédictions (“forecast”, c’est-à-dire prédiction dans l’avenir). J’utilise ce que j’ai appris durant le master et aussi bien sûr au fil du temps avec l’expérience, je mène les premières analyses sur notebook Python (qui est pratique pour une première exploration et pour aussi présenter les conclusions au métier)  pour explorer les données, les relations entre les variables, et comprendre les phénomènes. Le travail du Data Scientist consiste ensuite à apporter sa connaissance de la data aux experts métiers, et leur expliquer les différentes méthodes et les algorithmes qui pourraient les aider à atteindre leurs objectifs. Actuellement, nous travaillons surtout sur des séries temporelles, ce qui est différent de jeux de données où le temps n’intervient pas.

Comment définis-tu le métier de Data Scientist ?

Le métier évolue très vite. Durant mon master II, on travaillait sur des jeux de données, on essayait d’avoir de bons scores en appliquant différents algorithmes selon les thématiques. Au fur et à mesure, on se rend compte que le Data Scientist doit faire plus que cela. Il échange avec le client pour déceler son besoin et bien le comprendre, il doit aussi pouvoir communiquer avec les experts métier. Techniquement, le métier de DS évolue très vite. Nous travaillons maintenant sur le Cloud, et la fiche de mission commence à diverger vers le ML Ops et l’industrialisation. Ce n’est plus le Data Scientist d’il y a 5 ans qui se contentait d’appliquer un algorithme à un jeu de données, un peu type kaggle, qui certes est formateur mais est très loin de ce que l’on peut faire au sein de l’entreprise. 

Quels types d’outils utilises-tu ?

On travaille dans un premier temps sur les notebook Python. C’est un outil simple, un “brouillon” dans lequel on peut tester des idées, de nombreuses approches, rédiger du texte, ou inclure les graphiques, ce qui permet de présenter les résultats de façon claire au client. Embarquer le client dans la démarche est essentiel : s’il ne comprend pas ce qu’on fait, il sera compliqué d’avancer et de discuter. C’est un bon outil pour explorer les données, tester les algorithmes , et il y a un aspect pédagogique.

Pour la plateforme Machine learning, nous travaillons sur AWS : on peut implémenter des algorithmes et des pipelines, industrialiser et mettre en production nos travaux. Nous utilisons des services de stockage (S3, dynamoDB), des fonctions d’automatisation (type AWS Glue), et Sagemaker pour la partie ML. On y trouve aussi des notebooks, des algorithmes dockerisés, le service est prêt à l’emploi, et entièrement customisable.

Quels sont les outils AWS qui te servent le plus ?

Nous utilisons des buckets S3 pour le stockage des données, AWS Glue qui est un ETL (extraction, transformation, chargement), des tables dynamoDB, AWS Athena qui est un service de requêtes SQL, des fonctions Lambda (code Python), pour automatiser des tâches relativement simples, limitées en mémoire et en temps, et Stepfunctions pour orchestrer les fonctions Lambda ainsi que les jobs d’entraînements/prediction. Dans le cas d’un pipeline de traitement avec des fonctions, nous utilisons Stepfunctions pour tout automatiser, et Cloudwatch pour lancer ces fonctions de façon ponctuelle. Stepfunctions nous permet aussi d’ajouter tous les algorithmes implémentés avec Sagemaker, tous les training jobs et les jobs de prédiction.Enfin, nous utilisons Insight pour faire de la visualisation de données. 

Et quels sont les services les moins utilisés ou les moins pratiques ?

Nous avions commencé à utiliser Code Commit pour la partie CI/CD, cependant l’outil n’est pas toujours très simple à utiliser quand on est habitué à Git. Nous sommes actuellement en train de migrer sur Gitlab, ce qui nous simplifie la tâche.

Quels sont les outils ou fonctionnalités qui manquent aujourd’hui ?

Au-delà des outils ou fonctionnalités, ce serait plutôt apprendre à mieux gérer un projet, mieux appréhender les méthodes Agile, utilisation de versioning, etc. pour être plus efficace.  

Quels sont les cas d’usage métier ?

Nous travaillons essentiellement sur deux projets. 

Le premier est un projet destiné aux usines de traitement des eaux, où sont utilisés des filtres qui s’encrassent au cours du temps. L’analyse des données vise à prédire le moment le plus opportun pour nettoyer ces filtres ou les changer. Étant donné le coût de remplacement de ces composants, les enjeux économiques sont élevés. De la même façon, le nettoyage doit être prévu plusieurs semaines à l’avance, et implique certaines contraintes logistiques, il est donc essentiel de pouvoir anticiper ce besoin. Actuellement, ce projet est encore en cours. Après une phase d’exploration avec les experts métiers pour valider les algorithmes et les résultats, nous avons lancé un premier pilote sur un site, et l’industrialisation a commencé début 2021. Le projet avance bien, les algorithmes sont satisfaisants et les résultats sont bons. La difficulté de ce projet est que le cahier des charges demande d’avoir un algorithme commun à tous les sites, or ils ne fonctionnent pas tous de la même manière, avec des processus différents. En Data Science, on dit souvent qu’un algorithme fonctionne bien avec un jeu de données, mais si on change le jeu… Le défi est donc de trouver un algorithme donnant d’assez bons résultats sur la dizaine de jeux de données étudiés.

Le deuxième cas d’usage est lié au traitement de l’eau, à un clarificateur d’eau (pour le cas d’une station d’épuration par exemple). On cherche à prédire la valeur de la turbidité (clarté de l’eau) et par ce biais optimiser (au niveau du prix) la quantité de produits chimiques à introduire dans les cuves. On travaille aussi le forecast des produits chimiques et des produits qui rentrent dans les différents processus (optimisation de la logistique). 

Quelle est la fréquence de mise à jour des modèles en production ?

Certains modèles sont mis à jour quotidiennement, ils sont ré-entraînés tous les jours avec de nouvelles données, pour d’autres c’est tous les quinze jours. On décide de ré-entraîner les modèles en fonction des résultats des algorithmes, quand ils passent en dessous d’un certain seuil, on essaie de réajuster. Mais de manière générale, nous faisons beaucoup de veille, et donc nous cherchons toujours à améliorer les modèles et à en trouver de nouveaux. Certains aspects de la solution sont satisfaisants mais pourraient être améliorés, et c’est pour cela que je cherche de nouveaux algorithmes. Notre modèle en production fonctionne, mais je n’en suis pas satisfait à 100%, j’essaie donc de trouver le temps d’étudier de nouveaux algorithmes et de les tester. 

Il faut expérimenter, se documenter, trouver l’algorithme qui serait le bon candidat, puis l’implémenter et d’industrialiser, et donc changer pas mal de choses dans ce qui est en production.

Et les modèles en phase de R&D ou POC ?

Oui, nous avons aussi de nombreux modèles en phase d’essai. Tout dépend du cahier des charges. Certains Data Scientists essaient le Deep learning et les réseaux de neurones, la phase d’entraînement est longue, il faut beaucoup de patience avant de passer en production. Or, on a souvent besoin d’un service qui soit rapidement mis sur le marché, donc on essaie de trouver des algorithmes plus simples. On doit toujours faire un compromis entre l’efficacité du résultat et la complexité de l’algorithme.

Il faut également prendre en compte le fait qu’on doit présenter les modèles aux experts métier, or ils n’ont pas les connaissances nécessaires pour valider une approche basée sur le deep learning. J’ai déjà proposé du Deep learning sur des séries temporelles, mais pour mon interlocuteur c’était comme une boîte noire; le client a besoin de comprendre ce qui se passe derrière, il doit pouvoir expliquer la démarche. De fait, dans les trois quart des cas, on applique une simple régression linéaire. 

Il y a donc une démarche de sensibilisation à mener sur les méthodes plus avancées ?

Cela dépend de l’écosystème, mais il faut travailler sur l’acculturation Data au sein des équipes digitales, sensibiliser aux enjeux et problématiques de la Data Science. Le machine learning est intimement lié au jeu de données, or on voit encore de nombreux cas où les datasets sont régulièrement modifiés, ce qui complexifie le travail des data scientists. Les comportements peuvent alors changer du tout au tout, et donc impacter la qualité des résultats. Donc oui il y a un travail pédagogique important à mener dans la Data Science. 

Quelle est l’organisation de l’équipe dans laquelle tu travailles ?

Dans l’équipe Data Science, nous avons un product owner, un devops sur AWS, une équipe front end, les experts métiers qui valident les résultats, et un Data Scientist, moi, avec des compétences MLOps et DevOps. C’est une équipe de six personnes.

Quelles sont les difficultés rencontrées ?

Le client n’est pas toujours conscient de la difficulté de mener un projet Data sans des spécifications complètes. Pour livrer une fonctionnalité, il faut connaître précisément les besoins, ce qui n’est pas toujours le cas. Si les spécifications ne sont pas claires, on va coder d’une certaine façon, mais on n’aura pas le résultat escompté et il faudra retravailler sur le code. Il arrive aussi de devoir passer en phase d’industrialisation sur un projet où les spécifications sont encore flottantes. Pour le data scientist, c’est alors très compliqué de travailler sur cette base. Cela peut paraître un détail, mais changer une agrégation ou une fréquence peut impacter tout le pipeline. 

Parfois les jeux de données sont hétérogènes. On commence à travailler dessus, puis les données changent car les méthodes de mesure changent, et l’algorithme ne peut pas forcément s’adapter à ces changements. Ce n’est pas toujours simple à faire comprendre au client, là aussi il y a un travail de sensibilisation à mener.

Une journée classique dans la vie d’un Data Scientist, c’est comment ?

Généralement le matin nous avons des réunions de suivi, un jour sur deux. Chacun explique ce qu’il a fait, ce qu’il va faire, les points bloquants, etc. Ensuite,  je commence à travailler sur mes sujets en cours. Cela peut être de l’industrialisation, où de la veille car le sujet évolue très vite. Se former en continu, découvrir de nouveaux algorithmes et des tutoriels, cela fait partie du travail. Dans un grand groupe, on a aussi beaucoup de réunions, cela occupe une part non négligeable de la journée, il faut pouvoir composer avec. Je travaille aussi avec des stagiaires, j’essaie de les former et de travailler avec eux sur les sujets en commun. Il y a aussi le travail avec les équipes dev et front. C’est un métier assez varié, où toutes les journées ne se ressemblent pas. Ces deux dernières semaines, j’ai travaillé en solo sur de l’exploration de données; les deux semaines prochaines seront consacrées à la mise en production, et là ce sera du travail d’équipe avec le devops.

Et une journée exceptionnelle ?

Quand on a une intuition !

Quand on essaie de résoudre un problème en Data Science, il est très difficile de couper, on y pense à tout moment de la vie quotidienne “Et si j’essayais ça?”. Le lendemain, on teste, on passe 7 à 8 heures à coder et si on obtient le résultat attendu, alors on a un vrai sentiment de satisfaction. Le métier est assez prenant, on peut être confronté à beaucoup de points bloquants, cela occupe une bonne partie de l’espace mental. Il faut considérer qu’il y a deux aspects. Le code, trouver la bonne façon de coder une idée n’est pas forcément trivial, et puis l’aspect mathématique/intuitif lié aux algorithmes, dont il faut bien comprendre le comportement.