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 inconnus il y a quelques années, les métiers de la Data Science et du Machine Learning évoluent très vite. Compétences, méthodes, outils… dans cette série d’entretiens, nous confrontons notre expérience à celle du marché, avec la participation de Data Scientists et ingénieurs Machine Learning externes à Devoteam Revolve.

Julien Dassa-Terrier est Docteur en astrophysique et Data Scientist. Passionné de vulgarisation, il anime également des conférences scientifiques, TED X, et une matinale d’actualité scientifique sur Twitch, le Café Croisciences.

Peux-tu te présenter ?

Je suis arrivé à la Data Science par un chemin de traverse, mais finalement assez classique. J’ai un parcours dans la physique théorique & astrophysique, et un doctorat qui  me destinait au métier de chercheur.

Après ma thèse, j’ai décidé de me réorienter. J’ai cherché quelles compétences je pouvais apporter en entreprise, avec ce parcours académique très spécifique, et à priori un peu difficile à vendre aux RH. Le doctorat n’est pas encore très valorisé en France même si ça évolue depuis quelque temps. La data science était un des chemins possibles, le sujet m’intéressait, et maintenant je passe mes journées plongé dans la Data. En ce moment, j’ai un poste de Data Analyst, mais en pratique je fais beaucoup de Data Science.

La Data analyse et la Data Science sont des métiers très proches ?

Cela dépend beaucoup des entreprises. J’ai eu une première expérience en start-up, où j’étais autant Data Analyst que Data Scientist et Data Engineer, parfois même chef de projet, commercial et développeur ! Je suis maintenant dans une entreprise plus grande, mais dans une petite équipe avec de forts besoins en data science et en data analyse, et aujourd’hui j’ai une double casquette. 

La différence entre tous ces domaines, c’est surtout une question de paradigme. Dans mon environnement professionnel, nous travaillons avec Databricks, et la plateforme apporte une certaine vision du monde de la data, avec des platform admins qui maintiennent la plateforme, des data engineers qui construisent l’infrastructure, les transferts de données et les opérations. Le data analyst va chercher la donnée pour faire la BI, et rendre la donnée  exploitable, et le Data Scientist est spécialisé dans la construction et la mise en production d’algorithmes prédictifs, de classification ou de clustering. En théorie tous ces métiers sont distincts. En pratique, on travaille ensemble et on s’entraide, donc on est souvent à cheval sur plusieurs métiers. 

Comment on passe de l’astrophysique à la Data Science ?

La thèse d’astrophysique a des points communs avec les bases du métier de Data Scientist : on fait de l’analyse de données, des simulations, des algorithmes prédictifs, on utilise de grosses bases de données… J’ai aussi beaucoup codé durant cette période, principalement en Python, en R aussi, et j’ai utilisé des outils comme Scikit Learn.

En pratique, le lien entre astrophysique et data science, ce sont les statistiques et l’analyse de données. Par exemple, j’ai travaillé sur la détection de signaux faibles, avec pour finalité de chercher des zones de formations d’étoiles dans la galaxie Andromède, grâce aux ondes radio. Dans mon cas, ces nuages moléculaires (les régions où se forment les étoiles) étaient petits et peu massifs, donc leurs émissions étaient très faibles alors que la donnée était très bruitée. C’est là que les méthodes statistiques et les techniques d’analyse de données entrent en jeu pour distinguer les détections réelles. Evidemment, c’est très loin d’une application dans le monde industriel. C’est un travail purement scientifique pour mieux comprendre l’évolution des galaxies.

Mais la détection de signaux faibles a une application concrète pour beaucoup d’entreprises dans certains domaines très spécifiques, dans l’imagerie satellite par exemple. Cependant la thèse va au-delà de la maîtrise d’un sujet extrêmement précis, aujourd’hui cette expérience me permet d’apporter en entreprise des compétences comme la maîtrise des statistiques, la compréhension de la donnée, la capacité à se projeter, le recul scientifique sur la visualisation de données et ce qu’on en obtient, la compréhension de la différence entre corrélation et causation, etc. Cette intuition face à la donnée, on ne peut vraiment l’acquérir que par la pratique, et le doctorat est un endroit extraordinaire pour ça.

Sur quels cas d’usage de Data Science as-tu travaillé ?

Mes premières missions tournaient autour de la prédiction ou encore de la planification sous contrainte destinée à la maintenance opérationnelle. Les équipes de maintenance ont souvent d’énormes quantités d’opérations à faire et fonctionnent encore très souvent “à l’ancienne”. Avec l’émergence de la maintenance prédictive (où on utilise des algorithmes pour prédire les dysfonctionnements avant qu’ils n’arrivent et faire intervenir des équipes de manière préventive), il y a une forte demande de modernisation. Cette modernisation passe notamment par l’utilisation d’algorithmes d’optimisation des plannings. On vient alors en soutien du chef d’équipe, on lui propose des outils tout en aidant le prestataire à trouver des axes d’amélioration.

Ce type de mission illustre bien les enjeux d’éthique posés par la data : on peut utiliser la donnée aussi bien pour améliorer le service que pour essayer de réduire la taille des équipes. A contrario, la data peut régulièrement aller à l’encontre des préjugés de la hiérarchie et révéler que les équipes sont sous-dimensionnées ou encore que les employés font des journées vraiment longues et intenses, c’est arrivé sur certains de mes projets. Ce n’est pas toujours aussi facile éthiquement, malheureusement. Que se passe-t-il quand la qualité de donnée est insuffisante, qu’on a pas confiance dans l’algorithme, mais qu’il faut quand même livrer un résultat au client ? 

Aujourd’hui je travaille dans le secteur des services numériques sur abonnement, au sein d’une équipe centrée sur la gestion de la donnée. Il y a plusieurs missions qui cohabitent. Je travaille en soutien des Data Engineers qui mettent en place les bases de données, par exemple pour vérifier si les données sont cohérentes entre les bases. Je travaille avec l’équipe BI (business intelligence) pour aider à la mise en place des tableaux de bord à destination du business. Enfin reste une dimension data science qui devrait grandir : par exemple, les algorithmes de machine learning nous aident à anticiper le cycle de vie d’un abonnement client, ce qu’il va rapporter à l’entreprise, est-ce qu’il va se désabonner, etc. 

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

Il y a beaucoup de débats sur le sujet, et chacun a sa propre vision de son métier. Je pense que le dénominateur commun, c’est le travail sur le Machine Learning. Si je devais définir la mission du Data Scientist de façon idéale, ce serait le travail sur les algorithmes de prédiction, classification, clustering, deep learning, reinforcement learning, etc. Tout ce qu’on appelle de “l’IA”, de façon large, relève pour moi de la mission principale du Data Scientist. C’est ce qui fait sa plus-value.

En pratique, le Data Scientist peut remplir de nombreuses missions très différentes. Cela varie selon les entreprises, mais il peut être data analyst, data engineer, parfois aussi commercial ou chef de projet ! A l’exception des grandes structures avec une forte dimension R&D, je pense qu’il est rare que les Data Scientist aient le loisir de ne faire que de l’IA toute la journée.

C’est plutôt un travail en solitaire ou en équipe ?

Le Data Scientist n’est pas un chercheur en IA ou un ML researcher. Il a un rôle de pont, je pense qu’on ne peut pas exercer ce métier sans avoir l’envie de faire comprendre la donnée, la traduire. On doit convaincre ses collègues et ses clients, les aider à comprendre au mieux pourquoi ils peuvent faire confiance à nos propositions. On ne peut pas se contenter de faire une prédiction et la livrer.

Cela suppose donc de participer aux daily meeting, d’échanger avec les autres équipes, d’être sur tous les fronts. C’est d’autant plus vrai que pour de nombreuses entreprises, la data est un sujet “compliqué” : il y a beaucoup de travail pour capter la donnée et comprendre comment elle est organisée. Il n’est pas rare de demander la documentation et qu’on nous réponde littéralement “demande à machin, il travaille dans la boite depuis 5 ans” ! Pour résumer, on ne peut pas faire un travail de data science si on n’a pas de compétence métier, et ça on ne peut pas le faire en ermite. 

Et la vulgarisation ?

Je n’aime pas les boîtes noires, et je n’aime pas demander aux autres de traiter mon travail en boîte noire, donc il est essentiel de pouvoir vulgariser notre sujet. S’il n’est pas possible d’expliquer tous les tenants et aboutissants des algorithmes à notre public – d’autant plus qu’en Deep learning on ne comprend pas à 100% ce qui se passe à l’intérieur – on doit au moins faire comprendre l’idée fondamentale, la démarche, expliquer comment et pourquoi.

On ne peut pas faire comme un magicien : “Tada ! Voilà la donnée, et ce que je vous révèle”. Face à un public qui ne maîtrise pas tous les aspects, on se doit d’expliquer. Ce n’est pas toujours simple car on peut rencontrer de la résistance au niveau du métier. Qui est ce jeune start-upper, qui ne connaît pas la réalité terrain de mon métier, et qui va prendre des décisions qui m’impactent ? Je comprends cette méfiance, et nous avons un travail pédagogique à mener. Par chance, j’adore enseigner et vulgariser ! Il y a quelque chose de très inhumain dans un algorithme, et je sais en tant que DS à quel point un algorithme mal pensé peut faire des dégâts. Il faut donc être capable de rassurer un minimum les gens et à minima voir si on peut leur donner la main sur un outil qu’ils comprennent.

Quels enjeux éthiques soulève l’usage de la donnée ?

Le Data Scientist doit souvent jongler entre son éthique et ce qui est requis par le travail. La data est un domaine qui est tout sauf neutre.

Nous exploitons les données des gens, et nous prenons des décisions qui vont impacter leur vie, le plus souvent sans qu’ils le sachent. Cela nous donne une responsabilité. On essaie donc de trouver un job en accord avec ses principes, sinon on se trouve en dissonance cognitive et ce n’est pas confortable, mais on n’a pas toujours la possibilité de choisir. Cependant il existe des garde-fous. A commencer par un certain nombre de lois, comme la RGPD entre autres, même si elles nous posent des difficultés dans l’analyse des données. Pour moi, la RGPD est non seulement un outil important, mais puissant, utile contrairement à ce que pensent beaucoup de gens. Cela peut rendre notre métier plus difficile mais c’est bien que la réglementation européenne pousse dans ce sens. Cela nous oblige à faire attention à l’usage que nous faisons de ces données, et nous pousse à développer des solutions moins intrusives. 

On peut se poser une autre question éthique : que se passe-t-il quand l’algorithme a des conséquences imprévues, non voulues, ou qu’il a des biais, qui impactent la vie des gens ? Si l’algorithme de planification  me dit que l’équipe de maintenance peut faire 50% de tâches en plus, on doit se poser des questions. Les gens ne travaillent pas, ou il y a quelque chose qu’on n’a pas compris ? Le plus souvent, au contact du terrain, on se rend compte qu’on a manqué quelque chose dans la simulation. On doit alors le faire comprendre au client. Parfois aussi, on tombe face à une réalité qui n’est pas celle que le client espérait en nous engageant… Cela pose la question de la responsabilité des décisions qui pourraient être prises sur la base de nos algorithmes. 

Quel est le rythme d’entraînement des modèles et du passage en production ?

Cela dépend beaucoup de la qualité des données. C’est un des points fondamentaux qui influe énormément sur la capacité à faire les choses vite et bien pour créer les modèles et les entraîner. De nombreux Data Scientists le diront, la phase de collecte de données et de nettoyage est l’une des plus longues et rébarbatives, surtout avec des entreprises qui accumulent beaucoup de données mais de façon peu organisée, ou celles qui collectent peu de données, et où le dataset est limité.

Mais pour créer des modèles prédictifs, il faut penser sur le long terme, et dans de nombreux secteurs d’activité il y a un vrai accompagnement à faire. Ce n’est pas le cas de certains secteurs, où la donnée est ancienne, très organisée, et la qualité de donnée n’est plus un problème. Parfois la qualité de donnée est bien là, mais il faut faire énormément de traitements. Cela prend du temps, et c’est parfois compliqué à faire entendre au métier : pendant ce temps long, on ne produit pas. On est juste en train de créer un beau dataset, et cela peut prendre des semaines.

Quand vient la partie plus amusante du feature engineering, du test et de l’entraînement des modèles, c’est un peu plus rapide, mais ce n’est pas une ligne droite. Il y a des procédés standards (par exemple : régression logistique, random forest puis XGboost et on conserve le meilleur modèle) mais on arrive rarement directement à modèle satisfaisant.

Il faut aussi assurer une veille constante pour aller plus loin.  Cette phase peut être infinie,  d’où l’importance du rétroplanning. A un moment donné,  il faut arrêter de tester des modèles et en choisir un, ou une combinaison de modèles. Enfin, il y a l’aspect technique de la mise en production, et là c’est bien d’avoir un data engineer avec qui travailler. L’industrialisation du modèle est encore un autre sujet, c’est un métier à part : le Machine Learning engineer, qui est un Data Scientist spécialisé dans la mise en prod et l’industrialisation des algorithmes. Mettre en production un modèle qui doit se mettre à jour quand c’est pertinent et demander peu de supervision amène de nouvelles contraintes. Le ML Engineer suit les modèles, leur fonctionnement, traque les anomalies… J ‘aurais tendance à dire que ce métier intervient après celui du data scientist qui crée les prototypes. Dans beaucoup de structures les deux rôles sont occupés par la même personne néanmoins.

Au sein de notre équipe, j’ai découvert Databricks récemment, l’outil apporte des fonctionnalités intéressantes avec AutoML et MLflow (comme la possibilité d’avoir un suivi des modèles). Dans une équipe de petite taille comme la nôtre, les outils Databricks permettent d’avancer très vite par rapport à ce qu’on utilisait avant, Hadoop et Zeppelin.

Quel est l’apport du Cloud ?

Le Cloud prend une place énorme dans le ML ops et cela va aller croissant. Travailler avec le Cloud est très pratique, cela donne des capacités de gestion des tailles de BDD et d’outils pour aller plus vite, les avantages sont nombreux pour les équipes réduites. J’y vois aussi quelques soucis, même si je manque encore de recul sur le sujet, notamment la question du cloud souverain et du droit dont dépendent les fournisseurs de cloud américains. Mais sur le plan technique applicatif, c’est un outil très pratique qui fait gagner beaucoup de temps. On peut faire tourner du code beaucoup plus lourd sans perdre en stabilité. C’est particulièrement adapté aux structures qui n’ont pas la taille pour justifier de maintenir leur propre infrastructure.

Quels types d’outils utilises-tu ?

J’ai pas mal codé en R avec tidyverse, aujourd’hui j’utilise Python avec Pandas et surtout Pyspark. Il y a de grosses similarités dans la syntaxe, mais j’ai une forte préférence pour Python. Sinon je travaille beaucoup avec SQL actuellement pour la partie Data Analyse. Toutes les query sont en SQL, et les traitements derrière en Python.

Pour la partie BI, j’utilise Tableau, qui me permet de créer les dashboards pour les commerciaux et leur donner des accès directs à la donnée traitée. Tableau a l’intérêt de pouvoir créer des dashboards assez facilement, simples d’utilisation pour les gens qui ne codent pas, même s’il a des points qui me déplaisent. J’aimais bien Shiny R quand je faisais du R, pratique pour faire des petites applications et de la dataviz. Quand on passe à Tableau on a l’avantage d’un outil standard, mais dont le framework est très rigide. En toute honnêteté, je ne suis pas encore entièrement acquis à Tableau : je vois l’intérêt de l’outil en l’absence de business analyst calé en code, mais pour un data scientist les outils de dashboarding de Databricks pourraient bien être suffisants… affaire à suivre ! Enfin Gitlab est un outil important, même si les Data engineers l’utilisent plus que moi.

Comment se passe une journée classique ?

Généralement, je commence ma journée en ayant déjà une idée assez claire de ce sur quoi je vais devoir travailler, pas le temps de s’ennuyer ! Le point matinal peut ensuite complètement redistribuer les priorités, une urgence peut surgir. Je jongle alors entre les problèmes demandant une prise en charge immédiate et l’avancement des projets plus long terme, on ne peut pas se permettre de laisser traîner trop longtemps ces derniers sinon on ne les termine jamais. Le but à terme c’est d’avoir le moins possible de problèmes demandant une intervention humaine, c’est-à-dire de libérer du temps pour développer de nouvelles choses plutôt que réparer ce qui est déjà là. Cela suppose donc d’automatiser tout ce qui peut l’être, pour se consacrer à la veille technique et faire évoluer l’outil.

Il y a aussi l’encadrement des alternants ou des stagiaires. Je l’ai déjà dit mais j’adore enseigner, donc j’apprécie vraiment de pouvoir passer du temps à faire du mentoring, et les aider à construire un projet qui soit valorisable pour leur diplôme et leur CV, tout en étant aussi utile à l’entreprise. C’est une tâche plus exceptionnelle, qui crée de la valeur, évidemment d’une façon différente que le développement d’un outil pour l’entreprise.

Et pour terminer, une journée exceptionnelle ?

La journée catastrophe : la prod est tombée, tout le monde est sur le pied de guerre pour savoir où ça se passe. Il y a des indices dans la donnée qui nous aident à comprendre la temporalité et l’origine de l’incident, donc on cherche. Et ensuite, on livre un rapport détaillé et on guide les ingénieurs dans les réparations. On a un genre de rôle d’éclaireur, on doit trouver sur quel événement tout a cassé. Autre situation, parfois un client a des réclamations et là aussi, il faut aller très très vite car les commerciaux ne peuvent pas temporiser éternellement !

En bonus, le talk de Julien lors du TEDxMontrouge :