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.

Nous recevons aujourd’hui Kevin Rosamont Prombo, Data Scientist, formateur R et animateur du Podcast Data Workers.

Après un master en ingénierie mathématiques, Kevin a commencé à travailler sur le traitement de données à la CNAM, avant de partir à Montréal pour continuer son travail sur les données avec des outils statistiques. De retour en Europe, il a rejoint une société de conseil comme consultant statisticien au Luxembourg, où il a exercé auprès de grandes entités du secteur public. Kevin a ensuite continué sa carrière dans une banque privée, avant de passer freelance en 2021.

Kevin consacre maintenant 100% de son activité à la Data Science, sur des missions de conseil ou de formation auprès du secteur public ou de PME. Kevin est également passionné par l’IoT, et il anime le podcast Data Workers où il reçoit des spécialistes de la donnée, Data Scientists, Data Engineers, Digital Marketers, Growth Hackers…

Quelles sont selon toi les missions du Data Scientist ?

A la banque du Luxembourg, je travaillais sur des données client sous forme de tableur. Une partie du travail était consacrée au data cleaning, quand on récolte la donnée en provenance des bases, de nombreuses informations “polluent” la donnée, il faut donc sélectionner ce qui nous est le plus utile, parfois remettre les données dans un autre format, et ensuite on peut travailler sur les modèles. Le périmètre du poste est très différent selon les secteurs d’activité, dans l’industrie 4.0 par exemple, ce sont des missions très différentes (écouter ci-dessous l’épisode 9 du podcast Data Workers sur le Computer Vision avec Sonia Tabti – Lead Data Scientist).

A mon sens, si le Data Analyst va manipuler de la donnée quantitative, l’exploiter dans des tableaux puis la visualiser, on attend du Data Scientist qu’il puisse travailler sur le quantitatif, mais aussi pouvoir faire de l’analyse qualitative ou des données au format vidéo ou au format audio. Par exemple, pouvoir traiter des commentaires, comprendre les motivations derrière un avis ou une note : il doit pouvoir détecter si un client a laissé un avis négatif parce que le produit ne répond pas à ses attentes, ou si c’est parce qu’il a été livré en retard. Enfin, le Data Scientist construit les pipelines pour automatiser la sélection de la donnée, la transformation, appliquer le modèle, et produire des résultats qui seront stockés, puis transmis au product owner ou au service qui a demandé l’étude.

Quelle est la part du travail de modélisation ?

On commence par la phase d’EDA (Exploratory Data Analysis). Cette exploration des données se fait sur des statistiques descriptives : identifier les corrélations entre les différentes variables, les représenter, décider de ce qu’on garde ou pas, repérer les doublons, etc. C’est le travail du pré-modèle. Ensuite, on passe à la modélisation à proprement parler, mais ça ne représente pas plus de 20% du temps.

En fait, notre mission est de pouvoir répondre à une question, ou un problème, soumis par nos interlocuteurs métier. En fonction de la question, des données disponibles pour y répondre, de la possibilité de réponses à choix multiples ou pas, on a déjà identifié 3 ou 4 modèles qui pourraient répondre à ce besoin.

Quand la donnée est nettoyée, on fait tourner ces modèles (Keras, Scikit Learn, Pytorch) de façon automatisée, et on compare les résultats sur 3 ou 4 modèles. Ensuite, on passe à la phase de paramétrage fin (les paramètres qui sont propres au modèle, dans le jargon, on les nomme les hyper-paramètres. Dans le cadre d’une forêt aléatoire, le nombre d’arbres de la forêt est un hyper-paramètre). 

Quels sont les outils que tu utilises ?

La question de l’outillage fait débat depuis un moment. Pour traiter de la donnée sous forme de tableaux, je pense que R est est le meilleur langage. C’est le plus simple et le plus lisible pour manipuler la donnée, c’est conçu pour cela. Et puis il y a Python, qui est très utilisé en programmation en général, et qui dispose maintenant de librairies comme Pandas, conçue pour utiliser et manipuler la donnée. Comme Python est une compétence assez répandue dans les équipes IT, il est plus logique de recruter des Data Scientists qui eux aussi travaillent en Python. L’intégration dans les workflows sera ensuite simplifiée, alors que R est maîtrisé uniquement par les statisticiens.

Avant d’utiliser R ou Python, SQL est le langage de base pour aller chercher la donnée et extraire uniquement ce dont on a besoin. Il faut en effet trouver l’équilibre entre le volume de données traitées et le temps de calcul : avec plus de données, le modèle sera meilleur, mais on consommera plus de ressources. C’est pour cela que pour lancer les premiers modèles, on essaie généralement d’extraire une base de taille limitée.

Enfin il y a les outils de visualisation. La plupart du temps, nos interlocuteurs n’ont pas le temps de creuser dans la donnée, ils ont besoin de réponses immédiates, claires et facilement lisibles ! Il y a donc différentes possibilités pour traduire la donnée en dashboards : coder en R avec la librairie Shiny, en Python avec du Dash ou Django/Boostrap (je trouve l’usage de ce dernier un peu fastidieux pour créer un dashboard). Il y a aussi des outils plus simples d’usage, comme Tableau, Qlik Sense, Power BI ou Google Data Studio, avec lesquels on peut générer des tableaux de bord interactifs, avec des données temps réel. J’ai pas mal utilisé Qlik Sense, qui est assez proche de Tableau, mais en ce moment j’utilise surtout Google Data Studio, qui a l’avantage d’être gratuit. C’est un argument qui compte pour travailler avec des start-ups ou des PME.

Sur quels cas d’usages as-tu travaillé ?

Sur le secteur public, j’ai eu à traiter des données liées à la circulation, et au nombre d’accidents en fonction des radars. Ce cas consistait à produire chaque mois une carte interactive pour visualiser les zones d’accidents, la proximité avec les écoles, le placement des radars, les vitesses enregistrées, et ainsi évaluer s’il y a une corrélation entre le placement des radars et la diminution des accidents.

Dans le domaine bancaire, j’ai travaillé sur des modèles d’appétence basés sur l’analyse et la persona des clients, ou sur des cas classiques de customer churn. J’ai également participé à un projet visant à améliorer la traçabilité des transactions financières. Au Luxembourg, la Commission de Surveillance du Secteur Financier (CSFF) demande aux établissements bancaires de pouvoir justifier leurs efforts dans la lutte contre le blanchiment. Nous avons donc mis en place des graphiques de visualisation réseau, ce sont des cartes qui permettent de représenter des ensembles et les liens entre différents émetteurs et récepteurs. Le département Compliance peut ensuite identifier plus facilement les mouvements douteux.

En plus de la visualisation, j’ai aussi fait de la modélisation sur des cas de fraude avérés, pour entraîner le modèle à détecter d’autres transactions frauduleuses. Le problème, c’est que le modèle peut détecter uniquement ce qui a déjà été détecté auparavant : il ne peut pas détecter un nouveau type de fraude. Il y a aussi la contrainte des données non équilibrées, le nombre de transactions frauduleuses est très faible par rapport aux légitimes. Comment les détecter quand elles représentent 0,001% de l’ensemble des transactions ? C’est comme chercher une aiguille dans une botte de foin. Pour répondre à ce problème, on peut augmenter le nombre de faux positifs, c’est-à-dire les transactions légitimes mais perçues comme frauduleuses par le modèle, afin de ne pas rater celles qui sont réellement frauduleuses.

Plus récemment, dans mon activité en freelance, je développe une offre de Data Science au service de la croissance des entreprises. Dans le retail par exemple, cela passe par l’étude des paniers pour identifier les achats associés (le cross sell), les achats par lots, etc., pour ensuite mettre en place des stratégies d’up sell ou de cross sell en fonction des informations recueillies.

Pour terminer, comment se passe une journée type ?

Il n’y pas vraiment de journée type, surtout depuis que je suis freelance, mais en tant que salarié, je commençais chaque journée par évaluer les différentes tâches et les modèles sur lesquels je devais travailler. Ensuite, échanger avec Data Engineers et avec le métier : ai-je assez de données ? Est-ce que le métier est satisfait de la première version du modèle ? Le métier de Data Scientist demande de communiquer très régulièrement avec les différents interlocuteurs. Cela permet de travailler de manière agile, d’avoir des retours réguliers et de changer de stratégie rapidement si c’est nécessaire. Ce sont ces échanges qui rythment le travail sur le modèle. En fin de journée, je communique également sur l’état d’avancement du projet.

En freelance, c’est un peu différent, j’ai maintenant d’autres activités comme la formation ou la production de podcasts. Je peux parfois donner des cours toute la journée à l’université, ou bien chercher des personnes à interviewer pour mon podcast. C’est une facette très différente du travail, ce sont souvent des échanges passionnants durant lesquels j’apprends toujours beaucoup !