Retrouvez dans cette interview le parcours de Guilhem, Lead Data Scientist chez Host'n'fly, sa vision du métier de Data Scientist, ses conseils en recrutement !
J’ai commencé par une prépa maths à la suite d’un Bac S. Je me suis dirigé vers l'ENSAI qui proposait une formation de 3 ans en cycle ingénieur, très orienté data. Le terme “Data Science” n’existait même pas ou peu. Quand j’ai rejoint l’école en 2013, on parlait d’ingénieur statisticien.
Ce n’était pas la “donnée” qui m’attirait particulièrement, mais plus l’aide à la décision grâce aux mathématiques. Le secteur a commencé à évoluer et j’ai ensuite vu les métiers et les branches se dessiner, dans l’analyse ou dans la construction de modèles par exemple.
Mon premier poste était chez Nickel (anciennement Compte Nickel, le compte en banque simplifié et universel, que l’on peut ouvrir chez le buraliste, racheté par BNP en 2017). J’y suis resté 3 ans, nous étions une cinquantaine quand je l’ai rejoint, dont 2 en Data. Nous étions environ 400 3 ans plus tard dont 4-5 en Data.
Ma première mission était de construire un environnement Data. Le but était de mettre en place un Datawarehouse en collaboration avec l’IT pour être le plus autonome possible, commencer à suivre les activités des différents pôles, et poursuivre sur des projets plus complexes. Je me suis rapidement familiarisé avec les technos, l’idée était d’avoir toute une infrastructure toujours plus robuste pour déverser les données de notre système historique dans Google Cloud Platform qu’on utilisait en Data et qui offrait beaucoup de scalabilité et de potentiel, à moindre coût (modèle pay per use).
La fraude était un sujet qui commençait à être important.
Mon travail a été de fournir un outil de priorisation des alertes de lutte anti-fraude / financement du terrorisme et blanchiment d’argent. Il y avait beaucoup de questions analytiques venant du Back Office qu’il fallait comprendre : quels sont les éléments qui vont me faire penser que c’est une fraude ? Quelle transaction douteuse me semble prioritaire ?
La plus grande difficulté tenait dans le fait que le livrable final (sur lequel on a beaucoup itéré) devait tenir compte de plusieurs contraintes : les choix devaient être compréhensibles par les équipes et les autorités de contrôle, et on devait montrer que les gains en termes de traitement pouvaient être très importants.
Nous avions également un sujet de churn (savoir si un de nos clients va rester chez nous d’une année à l’autre ou non) : pouvoir estimer la probabilité qu’a un client donné de ne plus utiliser notre produit l’année suivante est un sujet passionnant et sur lequel la Data avait beaucoup à apporter, car l’enjeu business était très important.
Sur ces gros sujets, on a utilisé plusieurs d’algorithmes de Machine Learning.
A mon départ, on commençait à être assez matures en Data : on avait passé l’étape “simple” des reportings / utilisation de modèles prédictifs en mode batch, et on avait commencé à mettre en place des micros services Data temps-réel à destination de l’IT, qui pouvait les interroger pour avoir une réponse sur certains problèmes précis.
Le fait d’être autonome sur les problématiques et d’avoir carte blanche m’a beaucoup apporté. J’avais à côté de cela beaucoup de missions de BI (reportings pour différents services / analyses ad hoc), un exercice de vulgarisation / communication était souvent nécessaire. C’était très formateur.
Changement de secteur complet, de la banque au secteur du tourisme !
Host'n'Fly permet de gérer de A à Z la mise en location de votre logement et de générer des revenus pendant votre absence.
J’ai choisi cette entreprise parce que je cherchais vraiment un poste plus proche de la production, une entreprise où la Data était au coeur de son métier, contrairement à une entreprise où la Data est davantage fonction “support” (où le produit peut très bien fonctionner sans)
Selon moi une condition très importante quand on rejoint une entreprise c’est de se reconnaître dans le produit et de l’utiliser : c’était le cas pour Host'n'Fly.
Ma mission principale est de chercher l’optimisation de nos revenus en établissant le pricing de nos appartements, tout en garantissant la satisfaction de nos clients (les personnes mettant leur appartement en location Airbnb). C’est la problématique principale en Data : trouver le bon prix pour générer un maximum de revenus et pour que nos clients soient satisfaits et continuent de nous confier leur logement par la suite.
Il y a en ce moment beaucoup de projets qui passent par des campagnes d’A/B Test. Nous essayons de comprendre comment nos voyageurs réagissent à nos différentes stratégies de pricing, car avec la crise sanitaire, on a décidé de revenir (en tout cas temporairement) à des stratégies plus “simples” et de court terme pour faire nos prédictions (le long terme étant trop incertain). Nous vous invitons à lire notre article sur l’IA à l’épreuve du covid-19 pour tout comprendre. On analyse l’impact de nos features court-terme à posteriori via nos campagnes d’A/B test et on prend des décisions.
Dans un contexte plus “normal”, il y a toujours l’enjeu d’ouvrir de nouvelles villes, de nouveaux marchés. Si historiquement on était très focalisé sur Paris, une décision majeure a été de faire le choix de se développer partout en France (et même en Europe récemment), notamment dans les zones dites “leisure” (stations balnéaires et stations de ski).
C’est un secteur qui va grandir pour nous, étant donné que nous partons de 0 pour construire tous les algorithmes là dessus. Ce nouveau secteur est aussi intéressant mais plus complexe à traiter d’un point de vue data, d’une part parce qu’il y a moins de données, et d’autre part, les prix sont intrinsèquement plus volatiles que sur un marché urbain classique comme Paris (par exemple en haute saison ça peut facilement faire x3 sur les prix). C’est un gros challenge!
Sur cette problématique, les questions auxquelles on doit par exemple répondre en Data : si je souhaite proposer les services d’Host'n'Fly à Biarritz, quel revenu pense-t-on pouvoir tirer d’un appartement donné?
Quel revenu peut-on leur garantir? Une fois qu’ils sont clients, à quels prix on décide de mettre les appartements sur les plateformes à destination des voyageurs? Comment on souhaite faire varier ces prix au cours du temps?
Nous faisons beaucoup d’analyse de comportements notamment par rapport à la crise. On remarque par exemple que les gens prennent des réservations très peu en avance maintenant. On est obligé de s'adapter aussi au niveau de la Data.
Les étapes sont assez classiques : définition des besoins métiers et traduction en problématique Data (quel output veut-on avoir), récolte de la data, analyses exploratoires, cleaning, feature engineering, entraînement / fine-tuning du modèle, évaluation des performances, mise en production, monitoring.
La Data chez HostnFly travaille en collaboration avec les différentes équipes, mais est autonome sur tout le lifecycle. Concernant les livrables, nous travaillons beaucoup en itératif : on cherche rapidement à arriver à un premier résultat pour définir une base, et à l’améliorer ensuite.
En reprenant la problématique de l’estimation de revenus sur de nouveaux marchés, on est en ce moment amenés à repenser notre manière d’aborder le sujet pour la rendre plus scalable. Étant donné le nombre important de futures zones à lancer, on souhaite changer notre approche historique pour passer d’une approche “un algo par ville” à “un algo générique” auto-adaptable pour chaque zone.
Les premières étapes (récolte de la data, analyses exploratoires pour comprendre la data, cleaning) sont vraiment clés car nous avons moins de données à disposition et que celles-ci sont très hétérogènes.
On porte également une attention particulière à la validation des modèles : le plus important pour nous, au-delà des performances pures de l’algo au regard de métriques classiques en Data, c’est que nos output fassent sens d’un point de vue business (ex. Ce serait inexact qu’un studio soit à la fin plus cher qu’une villa par exemple). Aussi, on essaiera rarement d’optimiser à tout prix les performances de l’algo si le gain ne nous paraît pas assez intéressant (rapport gain / temps). L’objectif est d’arriver à une version satisfaisante rapidement, et éventuellement d’itérer ensuite.
On est en somme assez impliqué dans le business development en raison de la nécessité de produire des estimations.
Étant 3 salariés en Data, on est autonome, avec un “backend” data que nous gérons nous mêmes et auquel nous accédons. C’est un mélange entre les trois métiers de Data Analyst, Scientist, Engineer.
Nous avons nos propres modèles qui tournent en production, et qui nous permettent de générer des estimations de revenus. Le backend “IT” s’occupe ensuite de récupérer ces prix et de les pousser sur nos plateformes.
Notre focus quotidien est de s’assurer que pour chaque appartement qui nous est confié pour des dates futures, on arrive à pricer chacune de ses nuits et les mettre à disposition du backend “IT”.
Et si on prend plus de recul, notre “driver” au quotidien est de trouver des moyens d’optimiser au mieux les revenus de nos appartements, pour améliorer notre satisfaction client et donc la pérennité d’Host'n'Fly.
La prise en compte du besoin et sa traduction en problématique Data est majeur, et doit bénéficier à l’entreprise. C’est pour cela que j’adore faire ce métier. Pourtant j’ai pu voir que l’organisation dans d’autres entreprises pouvait être toute autre, où une seule équipe s’occupait de ne faire que les modèles par exemple.
Pouvoir mettre en production son code et ses modèles est très enrichissant et satisfaisant pour un data scientist.
Un Data Scientist qui ne va pas du tout toucher à la production ou qui ne va pas s’intéresser à tout l’aspect mise en production, scalabilité des opérations, sera moins intéressant pour les entreprises à mon sens, en tout cas dans les structures plus petites types startup / PME / datalabs.
Chez Jedha ? Apprenez à mettre en production vos algorithmes de Machine Learning avec notre programme en Data Science puis ajoutez des compétences complètes en Data Engineering & DevOps avec notre formation pour devenir Data Engineer.
Pour moi, le Data Scientist de demain a beaucoup de compétences à son arc, et d’outils à disposition. Et l’enjeu est de déterminer avec lesquelles il va pouvoir résoudre la problématique d’entreprise.
Le côté tech prend un grand tournant dans les compétences qui sont recherchées.
Je trouve qu’il y a de moins en moins d'entreprises où le secteur est segmenté, il y a de plus en plus de Data Labs où les profils recherchés sont des gens multitâches.
Il y a eu aussi beaucoup de changement au niveau du Cloud, 90% des acteurs demandent une compétence sur AWS ou GCP (c’est en tout cas un gros plus affiché dans les offres d’emploi).
Plus la fiche de poste va être longue, plus je serai dubitatif.
Quand il y a écrit “excel” en compétence et un peu de Python, je sais que je ne ferai jamais de Python. La fiche de poste piège pour un data scientist, c’est celle où les langages ‘optionnels’ sont Python / R.
Car ce sont ceux que l’on utilise le plus : peu de chances qu’il y ait beaucoup d’opportunités Data Science dans ce poste, à moins qu’il y ait tout à construire sur place et que l’autonomie soit là.
Ensuite, c’est en fonction de l'appétence de chacun. Si la mission principale du Data Scientist n’est pas précisée (e.g une mission sur l’amélioration de tel algorithme ou de tel produit), cela veut souvent dire que c’est un poste “support”. Les sujets seront peut-être tout aussi passionnants, mais il faut creuser et se renseigner sur les futurs sujets potentiels.
Personnellement, j’ai toujours focalisé mes recherches sur l’apport que la Data avait sur le produit de l’entreprise, et où l’utilisation du cloud en interne est importante. Je regarde aussi si l’environnement technique est précisé. Si c’est AWS, GCP c’est un point positif pour moi. C’est également très rassurant de voir les outils utilisés en interne par exemple, Python, Git, SQL, qui sont les outils les plus utilisés actuellement sur ce genre de poste.
