– Marc — 00:00 :
Aujourd’hui, je reçois Hugo Palmer, Manager data chez Blablacar. Hugo est ingénieur en machine learning et travaille chez blablacar depuis 7 ans, d’abord comme contributeur et puis aujourd’hui manager d’une équipe data, blablacar est le leader mondial du covoiturage et exploite aussi un réseau de bus dans toute l’Europe et l’Amérique du Sud. Bonjour Hugo.
– Hugo — 00:17 :
Bonjour Marc.
– Marc — 00:18 :
Alors Hugo, est-ce que tu peux nous présenter blablacar plus en détail?
– Hugo — 00:22 :
Oui, alors blablacar est connu pour son activité de covoiturage en France, mais aussi à l’international. On est présent en tout dans une vingtaine de pays. Il y a quelques années, blablacar, en plus du covoiturage, a développé un réseau de bus dans la plupart de ces marchés. Et on va en plus se mettre à vendre des billets de train dans quelques temps. Blablacar se positionne comme une agence de voyage en ligne pour tous les modes de transport terrestre, hein? Donc à l’exclusion de l’aviation.
– Marc — 00:45 :
Ok alors chez vous, la data à à quoi et à qui ça sert?
– Hugo — 00:50 :
Alors la data chez nous, ça sert à prendre des décisions business, des décisions opérationnelles aussi. Business, je dirais. C’est quelque chose qui date d’il y a très longtemps, donc c’est sur les domaines finances, sur le marketing notamment, dont je vous parlerai un petit peu plus tard, mais aussi des décisions opérationnelles donc potentiellement automatiser certains process qui peuvent être trop rébarbatifs ou qui fonctionnent pas quand l’effet est à la main, par exemple, sur quel canal marketing investir? Sur quelle ligne de bus? Ajouter des bus qui circulent, un enlevé, créer ou supprimer des lignes de bus, ça va aussi servir dans notre réseau de covoiturage à détecter la fraude, à la limiter en temps réel pour montrer directement aux aux différents fraudeurs que ça fonctionne pas en fait dès le début, là où une modération manuelle pourrait prendre trop de temps et donc laisser s’installer des comportements qui fonctionnent pas.
– Marc — 01:42 :
D’accord, et alors comment vous êtes organisé pour gérer la donnée chez blablacar?
– Hugo — 01:48 :
Alors la donnée chez blablacar, elle est gérée principalement par une équipe data centrale qui est découpée en squads. On en reparlera peut être un peu plus tard et qui serve à un domaine fonctionnel chacune. La data est aussi utilisée par des business analyst qui sont plus proches des opérations qui vont aller se servir des dashboards qu’on va produire et donner des Insight business en se basant dessus.
– Marc — 02:10 :
C’est quoi le niveau de maturité de l’équipe d’attache et blablacar?
– Hugo — 02:14 :
Alors aujourd’hui, je crois qu’on est 45 personnes dans l’équipe data, donc ça fait un joli département avec 7 équipes. La data existe chez Blablacar, alors de manière embryonnaire, il y a une dizaine d’années et elle s’est développée progressivement au tout début, on a fait de la Business Intelligence, alors je dis en j’y étais pas encore. Progressivement, on a développé le le data Warehouse, ensuite on a développé des équipes par spécialité, donc des data engineer. Data Analyst et Data Scientist et enfin, il y a à peu près 2 ans, on s’est réorganisé en data mèche, ce qui veut dire qu’on a changé la forme des équipes pour se spécialiser en domaine fonctionnel.
– Marc — 02:53 :
Ouais alors le data Mesh? On va y revenir, ça c’est c’est quelque chose qui nous intéresse. Si on rentre dans le détail, est ce qu’on peut commencer par la journée? À quoi ressemble ta journée?
– Hugo — 03:02 :
Oui, avec plaisir. Alors moi je manage la Squad data pour le marketing en tant que tel, je suis avant tout un manager, un manager people ça. J’anime des cérémonies pour mon équipe, je mets en place des processus pour que mon équipe travaille de manière efficace. J’écoute les retours de mon équipe. Il y a aussi besoin régulièrement de se poser des questions sur les les besoins de staffing à moyen et et long terme pour les faire évoluer. Et chose qui est aussi lié au liée au data mesh. Parce que quand on a une équipe entière qui traite les sujets marketing qu’on a d’un coup des grands besoins parce que les budgets augmentent ou des besoins un peu plus faibles parce que des besoins diminuent, c’est un peu moins facile d’aller allouer plus ou moins de ressources au marketing et du coup, il faut arriver à se projeter sur ça malgré un environnement incertain. Il y a aussi des questions sur les projets quand on lance des projets long terme, j’essaie le plus possible de les laisser gérer par les personnes de mon équipe sous. Mais souvent, il faut aussi se réaligner entre les attentes des clients et les capacités techniques de de l’équipe.
– Marc — 04:03 :
Quel genre de data est ce que tu traites?
– Hugo — 04:05 :
Alors au sein de mon équipe, donc data pour le marketing, on traite quelques données granulaires, c’est à dire qui sont à à la à la maille des actions qui ont été faites sur le site web. Dans le cas où l’utilisateur a accepté du coup qu’on récupère cette donnée. Mais c’est plus beaucoup le cas parce que de plus en plus avec les contraintes de la RGBD on le fait de moins en moins en fait. Et du coup on se met à utiliser de plus en plus de données agrégées. Business agrégé et prendre décision dessus.
– Marc — 04:30 :
Agrégé comment par exemple?
– Hugo — 04:32 :
Ça va être par exemple des tendances jour par jour de l’évolution de notre nombre de réservations, covoiturage de réservation bus, le nombre de nouveaux conducteurs qui vont s’inscrire sur la plateforme par exemple, qui est un des KPI un des keyperformance indicators qu’on regarde beaucoup.
– Marc — 04:47 :
Et alors cette approche macro, on va dire, macroéconomique versus microéconomique, hein, on arrête de s’intéresser à l’utilisateur lui même ici pour des contraintes légales. Qu’est ce que ça change, est ce que ça en termes de performance? Est ce qu’il y a une perte de performance, un gain de performance?
– Hugo — 05:04 :
Alors ce qui se passe pour la mesure de la performance du marketing, c’est qu’on a l’approche traditionnelle qui est basée sur le Tracking des utilisateurs individuels en se basant sur les cookies. Et ça, comme je disais tout à l’heure, c’est de plus en plus limité parce que ça se restreint aux utilisateurs qui ont donné leur autorisation, à ce qu’on se serve de ces données là. Ce qui veut dire qu’en fait on continue d’avoir ces informations, mais pour une proportion des utilisateurs qui diminue fortement cette donnée, elle est toujours fiable, mais seulement sur un échantillon d’utilisateur. Donc on se sert de ces données pour voir les tendances et ensuite on a une approche alternative qui est un peu plus novatrice. Qui consiste à regarder les évolutions macroscopiques, donc de nos KPI principaux, et les corréler avec nos dépenses marketing d’un point de vue assez macro, c’est à dire regarder toutes les dépenses en publicité télé, les dépenses en publicité radio, les dépenses en publicité sur Google Search par exemple. Et du coup ça c’est une approche qui est en fait dual. Donc entre l’approche traditionnelle et l’approche un peu plus récente, un peu alternative et du coup nous ce qu’on cherche à faire, c’est à réconcilier ces 2 approches pour bénéficier de l’approche la plus granulaire possible pour avoir des données fiables à un facteur près et de l’approche plus novatrice pour avoir les bons ordres de grandeur.
– Marc — 06:12 :
Alors est ce que tu peux nous donner un exemple concret de décision business que vous avez pris grâce à la data?
– Hugo — 06:18 :
Alors oui, donc une décision business, on fait de plus en plus d’a B test pour comprendre ce que nous rapporte réellement les différents canaux marketing notamment, on a fait un test sur un réseau social et on s’est rendu compte qu’il nous rapportait moins que ce qu’on pensait initialement. Donc on a pu diminuer les dépenses sur ce réseau tout en les conservant un un niveau minimal et les augmenter au contraire sur un autre canal d’acquisition qui rapportait plus que ce qu’on pensait.
– Marc — 06:41 :
Alors le RGPD qu’est ce que ça vous a amené à à faire comme réorganisation? Est ce que c’est une contrainte ou pas du tout?
– Hugo — 06:49 :
Alors oui, forcément, le le RGPD c’est un cadre légal qui pose des contraintes. Il se trouve que c’est des contraintes qui se comprennent très bien. Il s’agit de faire en sorte que les utilisateurs finaux et le contrôle sur les données que nous on a le droit de processer ou pas. Là dans ce cas particulier, en fait ce que ça fait c’est qu’on est plus capable d’estimer la performance du marketing sur l’intégralité des utilisateurs, mais seulement sur un échantillon donc finalement. Ça ne nous handicape pas tant que ça. Pour comprendre la performance d’économie marketing, parce qu’il y a toujours cet échantillon de personnes qui acceptent.
– Marc — 07:22 :
Vous vous faites du machine learning dans vos usages alors oui,
– Hugo — 07:25 :
Au sein d’équipe data, on a pas mal de cas d’usage du machine learning, on en a pour des sujets de pricing, on en a pour des sujets de détection de la fraude dans le cadre du marketing, on en a aussi notamment sur Google Aids, donc Google Aids. On se positionne sur des mots clés et on va placer des enchères sur des mots clés. Donc tout ça c’est fait de manière plus ou moins automatisée sur Google Eds mais par exemple, quand on va placer une enchère sur un mot clé, Paris Toulouse pas cher. Par exemple. À aller arrêter les publicités de manière dynamique selon nos prévisions de remplissage des covoiturages ou au contraire les réactiver parce qu’on pense que c’est un axe sur lequel on a envie d’aller acquérir des passagers et en fait ça nous permet dans une certaine mesure d’aller équilibrer l’offre et la demande sur la place de marché que le covoiturage d’accord directement en fonction des remplissages. Vous adaptez les dépenses marketing.
– Hugo — 08:16 :
Voilà exactement, c’est à dire qu’on va avoir des arrêts francs quand on a vraiment pas d’offre et ensuite on va avoir tout un phénomène de gradation en fonction de notre prévision de remplissage.
– Marc — 08:27 :
Sur la détection de fraude, on parle de quoi ici? De fraude documentaire, de faux comptes.
– Hugo — 08:33 :
Alors on a malheureusement des personnes qui cherchent à se substituer à blablacar pour faire payer des utilisateurs sur des liens qui sont complètement en dehors du blablacar. Donc le blablacar a mis en place beaucoup, beaucoup de systèmes pour éduquer tous nos utilisateurs sur le fait qu’il ne faut payer que sur la plateforme. Il faut jamais sortir de la plateforme pour aller payer ailleurs. Mais malheureusement il y a toujours des personnes qui essaient, donc on essaie d’être au plus près pour les empêcher de faire ça et on envoie des mails régulièrement à notre base d’utilisateurs pour qu’ils comprennent ce type de fraude. D’accord donc le machine.
– Marc — 09:03 :
Learning là ici vous permet peut-être de. Détecter dans les conversations sans faire appel à un humain qui vient lire les conversations à la à la place, ça fait un premier rideau, en fait, ça fait un premier rideau temps réel et ensuite ça va aller soit bloquer directement, soit autoriser directement, soit mettre dans un poleur d’attente qui lui sera traité par des humains pour des tâches donc plus spécialisées car des cas où l’algorithme n’a pas été capable de conclure par lui même d’accord,
– Marc — 09:31 :
C’est quoi les principaux verrous, obstacles que vous avez pour développer ces algorithmes de machine learning? Autant sur la détection de fraude que sur l’optimisation des enchères sur Google Ads. Alors je pense qu’il y a, il y a une question à laquelle toutes les équipes data se confrontent tôt ou tard, qui est la question du temps réel. On est souvent assez tenté de vouloir faire des choses en temps réel et on sait pas toujours forcément pourquoi. Et là en l’occurrence, on a mis un peu de temps à trouver la bonne architecture de ML Ops qui nous permettent de faire du temps réel de manière efficace. Du coup sur les cas d’usage de la fraude, on l’a fait parce que là ça trouve tout son sens, c’est à dire que si on ne détecte pas un fraudeur en temps réel, on perd les 3/4 de l’efficacité. En fait du fait d’aller le bloquer ou pas parce qu’il a pu faire des choses néfastes pour la plateforme et les utilisateurs. Entre-temps donc ça c’est typiquement un cas où c’est nécessaire d’être en temps réel et donc il faut créer une architecture data qui permette de faire ça. Cependant, la majorité des cas d’usage du machine learning à blablacar aujourd’hui ne se font pas en temps réel parce que ça a un coût qui est très important et qui est pas forcément justifié dans ce cas-là est ce?
– Marc — 10:33 :
Qu’il y a des obstacles non techniques, l’utilisation au déploiement de ce travail.
– Hugo — 10:38 :
Oui, je pense que comme dans toutes les les, les entreprises un peu conséquentes, il faut trouver la bonne manière d’aller exposer des problématiques à des stakeholder plus seniors qui sont plus loin de ces problématiques techniques. Je trouve qu’un sujet assez important, c’est la manière de communiquer sur la performance du machine learning. Assez souvent, on peut être tenté d’imaginer une nouvelle feature produit pour laquelle le machine learning n’est pas forcément nécessaire. Donc par exemple faire du pressing Pseudynamique dans lequel on va augmenter les prix le weekend par exemple. Et rajouter une couche de machine learning, donc faire fluctuer ses prix de manière beaucoup plus dynamique grâce au machine learning et grâce à beaucoup de features supplémentaires, on peut être tenté de communiquer sur la performance de cette feature avec du machine learning, c’est à dire comme étant la différence entre pas de pressing du tout et du pressing avec du machine learning. Alors je pense qu’il est assez important de distinguer la valeur ajoutée par le pressing en tant que tel avec des règles très simples avec des règles business qui peuvent être données sans faire de machine learning juste avec de la data. Analyse assez basique. Et ensuite la performance ajoutée par le fait d’avoir ajouté du machine learning à ses règles business et du coup je pense qu’il est très important quand on communique à des Stay colder senior, de distinguer l’impact de la Feature basique avec l’impact du machine learning. Ajouter à l’étagère à cette feature et ça c’est quelque chose qui est pas forcément intuitif parce qu’on imagine directement la feature avec du machine learning là où en fait il faut arriver à se poser la question, est ce que vraiment le machine learning apporte une valeur ajoutée à cette étude là où est ce que la feature en tant que telle s’auto suffit et que le machine learning apporte une valeur infime à cette feature?
– Marc — 12:16 :
Alors dans cette thématique, est ce que selon toi il y a des choses qu’il faut répéter tout le temps aujourd’hui et qui dans 10 ans 20 ans seront une évidence pour tout le monde?
– Hugo — 12:26 :
Je pense que dans le cadre du marketing en particulier, j’en ai un peu parlé tout à l’heure, mais on part d’un monde. Il y a 5 ou 10 ans où les utilisateurs avaient aucun contrôle sur leurs données personnelles. Depuis 5 ans, on se doit d’être très vigilants sur ces sujets et je pense qu’il faut pas ramer contre le courant sur ces sujets. En fait, il faut développer des méthodes alternatives d’optimisation du marketing qui fonctionnent sans chercher à gagner du temps par rapport aux problématiques légales.
– Marc — 12:48 :
Quelle heure tu peux nous partager pour nous faire gagner du temps?
– Hugo — 12:51 :
J’ai travaillé quelques années au début de ma carrière en tant que Data Scientist et j’ai déjà été sur des projets seul pendant plusieurs mois à ne pas arriver assez à avancer, à travailler trop en silo et je me souviens d’une fois ou 2 où j’ai été mis en pair après avoir travaillé seul et je trouvais que notre efficacité était bien plus importante en travaillant à 2. Donc je pense que le plus souvent possible il faut faire travailler les développeurs data en pair, j’en suis convaincu. Pour les data scientists parce que je l’ai été, mais je pense que ça s’applique aux autres spécialités, aux data engineer ou Data Analysts, aux Analytics Engineer. Évidemment, ça participe à une émulation collective, ça permet de pas se perdre, notamment sur des projets complexes. C’est très vrai pour les juniors, mais je pense que c’est aussi vrai pour les personnes les plus expérimentées, parce que ça leur permet de se challenger l’un l’autre.
– Marc — 13:39 :
Tu penses que c’est quoi qui fait cette stimulation? Est ce que c’est vraiment une question de motivation de travailler à 2? Est ce que tu as vraiment une une addition des compétences intellectuelles qui font qu’il y a plus d’idées? Comment t’expliques ça.
– Hugo — 13:52 : 19:35
Je pense que c’est à la fois sur l’aspect de la motivation que sur l’aspect de ne pas se perdre dans des impasses, sur des projets de R et D, ça peut aller très vite de s’engouffrer dans une impasse. Alors forcément, on sait pas encore que c’est une impasse, sinon on n’irait pas, mais on rentre et ensuite on a un peu ce biais cognitif qui fait qu’une fois qu’on a investi du temps dans une direction, ça nous coûte très cher individuellement d’en sortir parce que ça revient à accepter le temps qui a été perdu. Ouais et ça je crois qu’en fait c’est très dur de s’en sortir tout seul. En revanche, quand on est à 2 sur un sujet. Pour aller dans une impasse, il faut convaincre l’autre d’y aller pour y rester, il faut convaincre l’autre d’y rester et c’est beaucoup plus difficile.
– Marc — 14:29 :
Ouais, intéressant ça. Alors vous vous êtes réorganisé en data mesh? Il y a 2 ans chez Blablacar donc datamis qui est une tendance assez forte actuellement. Est-ce que tu peux nous expliquer en quoi ça consiste exactement?
– Hugo — 14:45 :
Oui, je vais, je vais essayer. C’est effectivement une tendance assez forte dans l’écosystème data. En ce moment, je pense qu’elle s’applique beaucoup à certains types d’entreprises. Après il faut pas y foncer tête baissée, il faut bien comprendre ce dont il s’agit. Alors pour essayer de comprendre. En fait aujourd’hui un spécialiste data qui travaille sur un projet est caractérisé par 2 éléments. Le premier c’est sa spécialité technique, est ce qu’il est, data Analyst, Data Engineer, Data Scientists ou Analytics Engineer notamment. Et la 2ème C’est sa compétence fonctionnelle c’est est ce qu’il travaille pour du marketing dans le cadre de Blablacar pour le covoiturage, pour le bus. Pour l’égal ou on peut imaginer plein de domaines fonctionnels pour lesquels travailler, ce qui fait qu’en fait on a une organisation matricielle avec les spécialités techniques et les spécialités fonctionnelles. L’organisation traditionnelle data, c’est une organisation dans laquelle on est en équipe technique, c’est à dire qu’on est avec des pairs qui font la même chose techniquement que nous. Et ensuite cette équipe technique adresse les différents sujets fonctionnels en les priorisant. Le Datamesh consiste en fait à transposer cette matrice hein, c’est à dire en fait à travailler au sein d’une équipe fonctionnelle. Avec différentes spécialités, donc ça c’est quelque chose qui est assez intéressant parce que ça permet d’avoir un groupe de personnes dont le travail est de répondre à des besoins business spécifiques. Je trouve que c’est intéressant parce que pour les développeurs, ça leur permet d’étendre un peu leur scope. Je trouve qu’après 3-5-7 ans en tant que Data Scientist ou Data Analyst, c’est intéressant de voir ce que font les autres spécialités et l’organisation Data mesh permet cette évolution permet d’aller toucher en fait à ce que c’est que travailler avec un data Scientist, voire même faire un peu son travail. Avec un data engineer ou avec un data analyst.
– Marc — 16:22 :
Alors quel problème ça résout d’être organisé en data mèche?
– Hugo — 16:27 :
Ça permet d’avoir des interactions avec les différents métiers qui est facilité. C’est très utile pour les entreprises qui rajoutent régulièrement des domaines fonctionnels. Alors par exemple des entreprises qui peuvent fonctionner par ce qu’on appelle du aqui hier, c’est à dire aller faire une fusion avec une autre entreprise dans le domaine fonctionnel connexe, mais pas forcément exactement similaire d’aller intégrer une équipe data très facilement au sein de l’écosystème data au fur à mesure que du coup, le groupe se consolide et rajoute des domaines fonctionnels. On a racheté des entreprises qui opèrent des bus il y a quelques années. Si on était en data mèche à la bol qu’on aurait simplement rajouté une équipe data sans toucher aux autres équipes fonctionnelles. Et ça aurait permis de pas bouleverser toutes les équipes data simplement parce qu’on va rajouter une une entité au groupe. Je trouve qu’il y a autre chose dont on s’est un peu rendu compte de chez blablacar, c’est qu’en fait les personnes ont tout de même toujours besoin de continuer à travailler avec leurs repères techniques, c’est à dire que quand on a un data analyse qui est isolé dans une squad fonctionnelle, il va se retrouver à travailler en silo en tant que date analyste et ça c’est une faiblesse du data Mesh Mesh. La manière assez standard pour éviter ce problème, c’est de créer ce qu’on appelle des chapters. Des chapters sont des regroupements techniques de personnes. Qui ont la même spécialité technique, ce qui est intéressant, c’est qu’en fait, pour reprendre l’organisation Matricielle que je décrivais tout à l’heure, en fait, ça crée une double lignée de personnes qui vont donner des directions, donc les managers, les managers qui, au lieu d’être des managers techniques, deviennent des managers fonctionnels. Donc comme moi aujourd’hui, mais aussi ce qu’on appelle les chapter lead qui sont des spécialistes expérimentés de leur spécialité et qui du coup vont créer des programmes transverses à toutes les squads pour permettre à tous les data analyst ou à tous les data scientists de se regrouper au sein d’un forum d’apprendre ensemble. Et de partager des bonnes pratiques et donc ça en fait, ce qui est intéressant, c’est que ça fait monter toute une série de personnes en tant que chapter lead et aujourd’hui, notamment chez Blablacar. On a donc 6 ou 7 managers fonctionnels et on a 4 chapter lead et donc ça ça fait tout un groupe de personnes relativement seniors qui travaillent collégialement. Donc au sein du Stef Data.
– Marc — 18:31 :
Oui, ça ressemble presque à une une sorte de montée en avancement à 2 branches, comme c’est populaire chez pas mal de boîtes comme Google où il y a là celle du contributeur individuel. Qui devient expert technique et celle de celui qui devient manager, qui va du coup cesser de faire de la technique progressivement quoi ouais,
– Hugo — 18:50 :
Exactement en fait, ça permet de donner quelques petites composantes du management au Chapter lead, mais en gardant le gros du People management au sein des managers people de Squad.
– Marc — 18:59 :
Quel problème est ce que ça crée d’être en data meshes?
– Hugo — 19:02 :
Alors je pense que la limite principale, c’est que l’allocation de ressources, elle, est beaucoup moins dynamique que dans le cadre d’une organisation traditionnelle avec des équipes techniques, c’est à dire que si, par exemple. Vous avez le marketing qui a des gros besoins et l’équipe bus qui a des besoins plus faibles en ce moment. Ben en fait y a 2 manières, soit il faut aller faire grossir très vite l’équipe marketing, mais ça un externe, ça prend du temps, soit il faut déplacer des personnes d’une squad à l’autre et ça en fait, ça rajoute un certain frein parce que Ben on peut pas changer de manager 3 ou 4 fois au sein de la même année, on a besoin d’une certaine stabilité en tant que développeur avec ses collègues et aussi avec son manager pour créer des liens. Du coup je pense que cette demande d’une équipe de leadership data qui est très soudée et qui communique bien pour accepter de d’estaffer des personnes d’une équipe. Pour avoir staffé dans une autre.
– Marc — 19:52 :
Qu’est ce que tu préfères dans ce métier de manager dans une équipe data?
– Hugo — 19:56 :
Alors en tant que manager, qui est ce que j’apprends depuis quelques années, ce qui m’intéresse beaucoup, c’est de voir les qualités et les défauts des différentes personnes et d’essayer d’aller arbitrer les différents projets qu’on va prendre et les allouer aux différentes personnes. Faire des paires de développeurs qui travaillent ensemble quand c’est possible et du coup faire s’améliorer les personnes. On dit les faire grandir sur leurs accès d’amélioration, sinon sur le le fait d’être manager dans la data en particulier plutôt que dans d’autres secteurs. Ce que je trouve assez intéressant, c’est qu’il y a un côté qui est intellectuellement insatisfaisant à se poser des questions techniques et à y répondre d’une manière scientifique et pratique à la fois quand on a des questions business et qu’on arrive à à mettre en place toute une méthodologie qui aboutit à quelque chose qui derrière est actionnable, je trouve que ça procure une certaine satisfaction et que ce soit moi qui le fasse ou quelqu’un de mon équipe.
– Marc — 20:47 :
Quels sont les plus gros points de douleurs que tu rencontres?
– Hugo — 20:50 :
Je pense qu’une difficulté, c’est souvent d’articuler entre le court terme et le long terme. À court terme, on peut prendre pas mal de pression, de différence tape-holder de différents clients, de besoin d’avancer sur certains projets et en même temps ce que tu veux en tant que manager, c’est créer une équipe où les gens sont bien les uns avec les autres, hein, qui se développent où les gens ils trouvent leur compte tout simplement. Et ça, ça demande souvent de faire des arbitrages entre limiter la pression et en même temps arriver quand même à un certain niveau de delivery à une certaine qualité de ce qu’on peut produire.
– Marc — 21:22 :
Oui, c’est intéressant, c’est que l’arbitrage court terme, long terme, tu le vois surtout sous un Anglais RH en fait. La rétention de tes Data Scientist, le bonheur de l’équipe et pas tant les projets de long terme versus les projets de court terme comme on a pu pas mal l’entendre cet argument également.
– Hugo — 21:42 :
Disons que c’est quelque chose qu’il faut prendre en compte pour ne pas perdre ses développeurs sur le long terme.
– Marc — 21:47 :
Alors est ce que tu as une anecdote à nous partager?
– Hugo — 21:49 :
Oui, alors par exemple, je pense au au CRM donc l’équipe data pour le marketing s’occupe aussi d’évaluer la performance des campagnes CRM Donc à quoi ça sert d’envoyer des emails, envoyer des push notifications à nos utilisateurs? Comment améliorer ça. Historiquement, donc, il y a assez longtemps, il y avait un groupe de contrôle qui faisait que 10 % des utilisateurs choisis aléatoirement ne recevaient pas de mail, et alors pas de chance. En fait, il y avait une personne haut placée chez blablacar, donc un Seal qui ne comprenait pas pourquoi il recevait aucun mail alors qu’il a loué des budgets conséquents aux équipes CRM Il comprenait pas pourquoi lui il recevait pas ça en fait c’était simplement parce qu’il était dans ses 10 % de contrôle groupe et du coup ce que les les personnes opérationnelles avaient faites à l’époque c’était rajouter un special case, un cas spécial dans toutes les campagnes. De notre outil de CRM pour qu’ils les reçoivent quand même du coup je trouve que c’est amusant. Enfin c’est une anecdote qui montre à la fois la culture de blablacar. On appelle ça bizarre, c’est une culture qui est assez forte, qui consiste à régulièrement faire des covoiturages, prendre le bus nous-mêmes pour se rendre compte ce que c’est qu’être un utilisateur de blablacar au jour le jour et du coup ce qui est illustré par le fait que cette personne très haut placée, bah fait des covoiturages et se sent impliquée dans le produit et et du coup était frustré de pas les recevoir et en même temps bah les nécessités quand tu veux procéder en trial and error, donc essayer changer. Essayer, se tromper et rechanger itérer en fait de la nécessité de mesurer l’efficacité de ce qu’on fait, parce que si on ne mesure pas, en fait on a aucun retour et sur du long terme on fait n’importe quoi.
– Marc — 23:19 :
Est ce que tu as une opinion de partager peut?
– Hugo — 23:22 :
Être sur la gestion de projet, je trouve que le plus possible, il faut permettre aux développeurs de le faire et pas au manager de le faire lui même pour plein de raisons parce que ça permet de dégager du temps au manager et pour se recentrer sur des sujets plus stratégiques et aussi et surtout parce que ça permet aux développeurs data qui. Souvent ont pas des grosses expériences de gestion de projet de se développer sur ça. Soit pour qu’à le long terme ils deviennent PM par exemple ou manager eux-mêmes soit pour simplement rajouter une corde à leur arc.
– Marc — 23:51 :
Et alors si c’était à refaire son sondage? Son passage chez blablacar jusqu’à aujourd’hui, qu’est-ce que tu changerais?
– Hugo — 23:58 :
Moi pendant ma première année et demie chez blablacar, j’étais complètement isolé sur une business unit en tant que data analyste et j’ai mis beaucoup de temps à progresser seul parce que l’équipe data central était pas staffée comme elle l’est aujourd’hui parce qu’ils ont fonctionné de manière assez silotée justement. Et du coup si c’était à refaire, je pense que je me montrerai plus curieux pour aller chercher par moi même des ressources pour progresser. Et je serai aussi plus vocal. Sur le fait que j’avais besoin de menteur à ce moment-là donc peut être un message que je passerai aux aux plus juniors d’entre nous qui veulent apprendre le métier. Si vous vous sentez isolé sur une équipe, c’est d’aller demander de l’aide la plupart du temps c’est pas par méchanceté que les gens viennent pas vous aider, c’est simplement parce qu’ils ont d’autres priorités et qu’ils le feront pas d’eux mêmes.
– Marc — 24:40 :
Alors chez Blablacar, vous avez une équipe de 45 personnes dans la data, c’est assez énorme, c’est c’est conséquent, qu’est ce qu’il y a comme projet sur le feu? Qu’est ce que toi personnellement tu penses encore? Qui peut encore être fait chez blablacar.
– Hugo — 24:55 :
Je pense, il s’agit de de continuer à être curieux, à essayer des choses sur différents domaines d’application. Je pense que notre orga aujourd’hui, elle nous permet d’itérer assez bien sur ces questions et surtout de continuer à essayer et à savoir soit arrêter à temps, soit arrêter tout court les projets quand ils fonctionnent. Pas parce que c’est une réalité dans le monde de la data. Il y a une proportion non négligeable des sujets qui en fait ne délivrent pas leurs promesses et du coup il faut savoir les mettre de côté et après je dirais de manière assez pragmatique dans les prochains mois, il s’agit de venir à bout des grosses migrations techniques sur lesquelles on est en ce moment, on est en train de migrer sur DBT on a mis un peu de temps avant d’y aller mais voilà c’est de continuer à avoir un environnement data qui est à la fois conséquent et à la fois raisonnable. On va pas avoir trop de données qui sont complètement périmées, qui fonctionnent pas, donc c’est investir sur les sujets de gouvernance de la donnée, de cataloging de la donnée.
– Marc — 25:49 :
Et Ben Bon courage, merci Hugo.
– Hugo — 25:52 :
Merci.
– Hugo — 25:52 :
Vous venez d entendre Hugo Palmer, Manager Data chez Blablacar, sur Data Driven One on One.
