Les métiers de la data au service du business

Malo Chevillotte (2015) choisit de créer une start-up dès sa sortie d’école. Fort de cette expérience, il s’oriente ensuite vers différents métiers consacrés à l’exploitation des data au service du business.

Variances : Diplômé de l’Ensae en 2015, tu pars voyager pendant quelques mois. A ton retour, tu choisis de co-fonder une start-up, Concrete Metrics. Pourquoi t’être lancé dans l’entrepreneuriat ? Que faisait cette start-up, et qu’est-elle devenue ?

Malo Chevillotte : Ma plongée dans l’entrepreneuriat est principalement due à deux facteurs. Le premier est un goût prononcé pour la création, associé à un fort intérêt pour l’innovation ; un cours sur la création de start-up, suivi à l’ENSAE, m’avait convaincu que j’y trouverais matière à satisfaire ces envies. Le deuxième facteur est une rencontre : un proche venait de finir une formation sur les nouvelles méthodes de modélisation des données dans le secteur du bâtiment. Nous avons décidé de nous associer : mon associé prendrait en charge la prospection commerciale facilitée par sa connaissance du secteur et de ses enjeux, je développerais les produits.

Nous considérions que l’harmonisation en cours dans la modélisation de la donnée du bâtiment (BIM : Building Information Modelling) pouvait être exploitée afin de fournir des prévisions plus précises quant aux dépenses d’exploitation (OPEX) et d’investissement (CAPEX) des détenteurs de portefeuilles d’actifs immobiliers d’une taille conséquente (investisseurs institutionnels ou foncières).

Le grand pari derrière Concrete Metrics était que la fiabilité de nos prédictions allait croître proportionnellement au volume de données que nous traiterions. Mais un critère que nous n’avions pas suffisamment pris en compte dans le développement de notre entreprise était la durée du cycle de vente (très long dans le cas d’acteurs institutionnels) et la difficulté à faire changer d’avis des acteurs économiques qui n’y ont pas d’intérêt immédiat : ces institutions étaient prêtes à financer des missions de consulting alors que nous voulions développer un logiciel, un produit. Après plus d’un an à présenter notre proof of concept nous avions dépensé beaucoup d’énergie et n’avions plus l’envie de réaliser un « pivot » (changement de business model pour une start-up). Nous avons décidé d’arrêter l’aventure.

V : Quels enseignements professionnels et personnels as-tu tirés de cette expérience ?

MC : Mon principal enseignement professionnel peut paraître naïf mais c’est de ne jamais oublier les fondamentaux économiques du marché sur lequel on évolue : qui sont les clients ? quels sont leurs besoins les plus pressants ? combien sont-ils prêts à payer pour le produit/service offert ?

Une start-up est une entreprise qui nait à la suite d’une innovation (scientifique, technique voire organisationnelle) afin de commercialiser un bien ou un service. Mais l’innovation ne réside pas simplement dans le produit proposé, elle doit aussi exister dans la manière dont le produit est vendu (business model). Par exemple, internet a modifié profondément la commercialisation des logiciels : de la vente à l’unité via des CD-Roms, le marché a évolué vers des abonnements mensuels payés par nombre d’utilisateurs via le cloud.

Ce qui caractérise une start-up est l’itération extrêmement rapide dans l’articulation de son offre de valeurs auprès de ses clients avant de trouver la “formule magique” qui permettra la croissance exponentielle. Vue sous cet angle-là, une start-up est une machine à effectuer des tests afin de vite valider ou d’infirmer les hypothèses émises. Un enseignement que j’ai tiré du lancement de Concrete Metrics est la nécessité de lancer le maximum de tests afin de pouvoir les arrêter rapidement si la traction du marché n’est pas assez forte ou, au contraire, les pousser plus loin si l’intérêt des clients est grand.

Au plan personnel, j’ai énormément apprécié la phase de création de produits issus de la compréhension des attentes des prospects/clients : comprendre le besoin de nos interlocuteurs, réfléchir à la forme à donner à la réponse et présenter un produit (pas forcément fini) qui répond en partie à ce besoin est extrêmement gratifiant.

V : Quelle influence cette expérience entrepreneuriale a-t-elle eu sur le métier que tu as exercé ensuite ?

MC : Au sein de Concrete Metrics, j’ai mesuré combien disposer de données directement exploitables était essentiel dans la plupart des entreprises avec lesquelles nous avons travaillé, que ce soit avec la direction générale, les opérationnels ou encore les data analysts et les data scientists. Ce constat m’a naturellement orienté vers le métier de data analyst.

J’ai beaucoup appris sur les besoins data des différents métiers lors de mes expériences en tant que data analyst chez Smart Flows puis chez Meeroo. Deux points que je souhaiterais souligner :

• L’actualisation des données : certains services peuvent exprimer un besoin de mise à jour de leurs données à une fréquence plus ou moins importante. Le défi de l’équipe data est d’adapter les pipelines de récupérations des données grâce à un investissement en data engineering pour suivre le rythme et les besoins des opérationnels.
• La nécessaire mise en place d’un langage commun entre les équipes data et les équipes métiers : ce point me semble fondamental car il permet la construction commune par l’interpénétration des langages respectifs. Si les membres de l’équipe data comprennent mieux les enjeux du métier, ils pourront fournir des recommandations plus pertinentes ; en retour, les équipes métiers accorderont une plus grande confiance dans les chiffres qui leur sont fournis et dans la valeur qu’ils tireront de leur exploitation.

V : Depuis presque deux ans, tu travailles en tant que Analytics Engineer. Peux-tu nous décrire en quoi consiste ce métier ?

MC : Avant de décrire en détail mon métier actuel, il est intéressant de le placer dans un contexte plus large. Mettre en place une base de données spécialement dédiée à l’analytics était jusqu’à récemment extrêmement coûteux et donc prohibitif pour des start-up. Ce paradigme a été complètement bouleversé par l’arrivée d’Amazon Redshift en 2012. En effet, Amazon a décidé de commercialiser, via le cloud, l’infrastructure mise en place pour ses analyses internes. Le coût de création et de maintien d’une base de données dédiée à l’analytics a ainsi fortement diminué. Conséquence naturelle, le marché des bases de données dédiées à l’analytics est en très forte croissance ; l’année dernière, une des plus importantes introductions en bourse au Nasdaq fut l’entreprise Snowflake.

Ces innovations dans les technologies de stockage et de calcul ont eu un impact sur la manière de rendre les données exploitables en entreprise et donc, in fine, sur l’organisation des équipes data en charge de cette mission. Une telle équipe rassemble en général quatre types de métiers : data engineer, data analyst, analytics engineer et data scientist.

– Le ou la data engineer s’occupe de deux tâches principales : d’une part monitorer la performance des bases de données et adapter l’infrastructure à l’augmentation du volume des données ou du nombre de requêtes internes ; d’autre part construire les pipelines de transfert des données des sources brutes au data warehouse (autre nom de la base de données pour l’analytics).

– Le ou la data analyst utilise la donnée afin de répondre à des problématiques business complexes (par exemple, quelle est la rentabilité de chacun des canaux d’acquisition de clients et lesquels prioriser …?).

– Le ou la data scientist utilise les données afin d’automatiser certaines tâches via des algorithmes et peut intervenir sur des sujets aussi variés que la reconnaissance d’objets dans des images ou la recommandation de produits dans l’e-commerce.

– L’analytics engineer se concentre sur la phase de création des métriques de suivi de la performance. Ces métriques peuvent être utilisées dans des situations très différentes par des opérationnels qui souhaitent avoir une vue précise de leur performance en quasi-temps réel ou par des data scientists afin de suivre la performance des modèles qu’ils ont mis en production.

Le livrable final fourni par un analytics engineer est un tableau de bord créé avec un outil de business intelligence afin que le client interne ait accès aux métriques qui l’intéressent sous une forme facilement exploitable, sans avoir à se soucier de la fraîcheur des données (qui sont mises à jour dans la base de données). Le livrable intermédiaire que l’analytics engineer crée, et qui est nécessaire pour arriver au livrable final, est une nouvelle table dans le data warehouse ou une nouvelle colonne dans une table existante.

Ces différents métiers ont des outils en commun malgré leurs spécificités : SQL pour toute tâche concernant les bases de données, Python pour toutes les tâches d’analyses et un outil de business intelligence pour la visualisation.

 

La démarche de l’analytics engineer peut se résumer ainsi :

– Comprendre les enjeux de chaque équipe business et définir conjointement les Key Performances Indicators (KPIs) qui leur permettront d’évaluer leur performance

– Comprendre où est la donnée brute existante. Coder un pipeline de récupération et de nettoyage des données pour passer de la donnée brute à de la donnée exploitable disponible dans une base de données

– Proposer des visualisations permettant aux équipes métiers de suivre ces KPIs dans un outil de business intelligence

– Revenir à l’étape 1, valider avec l’interlocuteur business et itérer pour améliorer.

L’analytics engineer est donc une fonction en interaction avec des métiers très variés, qui participe activement à la mise en œuvre de la stratégie et aux prises de décision des entreprises.

Pour conclure, je dirais que tous ces métiers sont récents, les frontières entre eux peuvent être floues et ne cessent d’évoluer. La composante technique de ces métiers est primordiale et les innovations technologiques peuvent entièrement les redéfinir. Les équipes data ont une place centrale dans nombre d’organisations, à la fois comme soutien à la compréhension quantitative de l’activité des différents métiers et comme partenaire dans l’analyse et les choix stratégiques.

Quels sont les langages communs qui permettent le dialogue avec les utilisateurs opérationnels ? Pour quels enjeux organisationnels ? Ces questions nécessitent d’être à l’écoute attentive des évolutions technologiques mais aussi sociétales, voire des nouveaux comportements, de tous ces signaux faibles qu’il peut nous arriver de négliger.

Propos recueillis par Catherine Grandcoing

 

Mots-clefs : data – analytics – business intelligence – start-up – immobilier – software