Data Mesh, le grand changement architectural en matière de données ? Selon IBM, c’est à Zhamak Dehghani, directrice de la technologie pour la société de conseil en informatique ThoughtWorks, que le concept de data mesh a été promu en tant que solution aux défis inhérents aux structures de données centralisées et monolithiques, telles que l’accessibilité et l’organisation des données.
Emmanuel MARTIN-CHAVE, VP Data de BLABLACAR, revient sur la mise en oeuvre du projet Data Mesh chez le leader mondial du covoiturage. Une nouvelle organisation qui permet ainsi de coller au mieux avec les problématiques métiers et donner aux équipes de l’autonomie de bout en bout sur la chaîne de valeur.
Fondée en 2006, la plateforme communautaire payante de covoiturage compte 100 millions d’utilisateurs, partagent des trajets en covoiturage et en bus dans 22 pays, avec une équipe internationale de 700 personnes et de 45 nationalités différentes.
Julien Merali : Comment est organisé le pôle Data chez BlaBlaCar ?
Emmanuel Martin-Chave : On a six équipes. Il y en a cinq qui sont des équipes pluridisciplinaires orientées métiers, donc ils travaillent en collaboration étroite avec le produit et la tech et il y en a une qui est plus une équipe plateforme qui soutient ces équipes et qui leur permet d’avancer plus vite.
Julien Merali : Quels sont les profils ?
Emmanuel Martin-Chave : Il y a 4 métiers différents : data analyst, data scientist, data engineer et safety engineer.
Julien Merali : Comment gérez-vous la qualité de la donnée ?
Emmanuel Martin-Chave : Depuis un an et demi et après un mode un peu artisanal, on s’est doté de nouveaux outillages et on a changé notre manière de nous organiser aussi d’un point de vue ligne de reporting, nombre d’équipes. Cela a pas mal changé la donne notamment parce que l’on a pu fermer un peu la boucle entre les producteurs de données et les consommateurs.
Du coup, mécaniquement, quand vous consommez ce que vous produisez, la qualité s’améliore.
Julien Merali : Est-ce que cela a été aussi de la démocratisation vis-à-vis des métiers, de la sensibilisation sur la qualité de la donnée ?
Emmanuel Martin-Chave : Oui, mais surtout sur les métiers techniques, notamment les équipes d’engineering parce que le gros de notre activité, c’est une place de marché BtC et les gens ne rentrent pas manuellement de la donnée dans des systèmes informatiques. Cela arrive, mais c’est assez peu représentatif de ce que l’on fait.
Donc, c’est beaucoup de formation d’engineering. En fait, ces données sont utilisées par la suite et du coup, si elles ne sont pas de bonne qualité, on ne prend pas les bonnes décisions. Il y a plein de correctifs à appliquer, etc.
Julien Merali : Alors on a été volontairement un peu provocateur sur le thème “data mesh, pipeau ou réalité ?” Quelle est vous votre définition du data mesh ?
Emmanuel Martin-Chave : C’est une organisation qui donne de l’autonomie et des responsabilités très définies et sur des périmètres restreints volontairement qui ne sont plus organisés par métier mais plus par domaine fonctionnel.
Julien Merali : Cela veut dire que l’on va responsabiliser aussi l’ensemble des métiers dans l’entreprise. On va les rendre davantage autonomes ?
Tout à fait ! Alors après, il y a l’aspect pipeau qui est, jusqu’où on l’implémente. C’est très contextuel. Mais l’idée sous-jacente, c’est effectivement de rendre les équipes métiers propriétaires de leurs données, les équiper sur ces outils-là et du coup, de construire les équipes data en fonction de ça.
Julien Merali : Comment cela se matérialise ?
Emmanuel Martin-Chave : Je crois qu’il y a vraiment une prise de conscience de pourquoi on s’en sert, qu’est-ce qui est important et ce qui l’est moins. Si les gens ne comprennent pas d’où vient la donnée et comment on s’en sert, mécaniquement, ils ne vont pas faire attention à sa qualité. Et après, on va leur dire que l’on ne peut pas prendre de décision parce que la donnée n’est pas terrible.
Julien Merali : Est-ce que finalement, ce n’est pas quelque chose qui existait auparavant et sur laquelle on a simplement mis le mot data mesh dessus ?
Emmanuel Martin-Chave: C’est un peu ma vision des choses. Si je fais le parallèle avec ce qui se passe dans les équipes IT engineering, en data mesh, c’est une organisation en services. C’est du domaine driven design et cela fait des années que l’engineering fait du microservices. L’appliquer à la data a été malin. Mettre un nouveau terme dessus, encore plus.
Je pense qu’il y a pas mal de fondamentaux qui existent déjà.
Julien Merali : Comment l’applique-t-on à la data ? Est-ce que vous avez des cas d’usage ?
Emmanuel Martin-Chave : Je crois que ce qui marche bien, c’est de rassembler les gens de différents métiers pour s’assurer que l’équipe ou la structure va avoir de l’autonomie de bout en bout sur la chaîne de valeur.
En tout cas, pour nous, c’est ce qui a vraiment changé la donne. Et c’est ce qui permet aussi de coller au mieux avec les problématiques métiers : est-ce qu’il faut que l’on construise du reporting ? Est-ce qu’il faut que l’on construise des algorithmes ?
Et ça, on ne peut le faire que si on a une équipe qui prend un flux de bout en bout et qui est proche du métier pour comprendre ses exigences !
Julien Merali : Est-ce que vous vous êtes fait accompagner sur la mise en place de ce projet ?
Emmanuel Martin-Chave : Non, on a tout fait nous-mêmes. L’accompagnement que l’on a eu a été au travers de quelques articles qui décrivaient le sujet, des concepts utiles que l’on ne devait pas réinventer.
Après, on s’est beaucoup inspiré de ce que faisait les équipes engineering chez BlaBlaCar.
Julien Merali : Aviez-vous une équipe gouvernance ?
Emmanuel Martin-Chave : Non et on n’en a toujours pas aujourd’hui. C’est un choix et en partie une contrainte. Un choix parce que c’est ma philosophie. A partir du moment où l’on dit : la gouvernance, c’est l’affaire d’une équipe, cela implique de dire aussi à toutes les autres équipes que ce n’est pas leur problème. Et du coup, c’est beaucoup plus difficile selon moi, d’arriver à avoir une bonne gouvernance.
Après il y avait aussi une contrainte. La data chez BlaBlaCar, c’est une quarantaine de personnes. On serait 300, on organiserait les choses de manière différente.
Julien Merali : Est-ce que cela permet aussi d’avoir davantage de transversalité quand tout le monde est concerné par la data, à la fois producteur et consommateur ?
Emmanuel Martin-Chave : Oui ! Et ce qui est génial en ce moment, c’est que l’on voit apparaître des nouveaux cas d’usage qui viennent de gens à qui on parlait peu avant : ils commencent à la fois à comprendre ce qu’ils peuvent faire avec leurs données et à nous solliciter plus proactivement, par exemple, en nous demandant de leur filer un coup de main ou de décortiquer un problème.
Julien Merali : Si on s’attarde sur la frise chronologique de ce projet de transformation, quand a-t-il commencé ?
Emmanuel Martin-Chave : Mi-2021 où l’on commençait à n’être plus efficace à l’échelle. Fin 2021, c’est pas mal d’onboarding et de discussion avec les managers pour qu’ils adhérent au projet, que l’on se mette d’accord sur quel problème on essaye de résoudre, et que l’on construise une stratégie.
1er semestre 2022, on onboarde les équipes et on fait les changements. Et on opère comme cela depuis mai 2022.
Julien Merali : Est-ce que des KPI’s ont été mis en face, pour mesurer le succès du projet ?
Emmanuel Martin-Chave : Alors on a fait un suivi semi-rigoureux. On avait des KPI,’s par exemple pour savoir à quelle heure on avait fini de rafraîchir toutes les sources de données qui étaient utilisées par le client. Et ça, cela s’est amélioré de manière assez drastique une fois que l’on avait fait ces changements, plus d’autres techniques.
Il y en a d’autres que l’on mesure moins finement mais qui vont être : est-ce que les équipes livrent vite ce qu’elles font ? Est-ce que l’on entend beaucoup de problèmes sur la qualité de la donnée ? Ce sont des choses que l’on mesure mieux.
Et jusqu’en 2021, on avait l’équivalent d’un ETP qui validait la qualité de la donnée. Aujourd’hui on n’en est plus du tout là et c’est l’un des symptômes que le projet marche.
Julien Merali : Cela vous a permis également de lutter davantage contre le problème de fraude !
Emmanuel Martin-Chave : Oui, je pense que cela a été un facteur de succès notamment parce qu’on avait une équipe qui se sentait beaucoup plus responsable du sujet et qui avaient des moyens de bout en bout pour le résoudre.
On l’a fait en collaboration avec d’autres équipes qui venaient nous dire : tiens, il y a tel cas que l’on veut enlever. Et nous, on va construire des règles et les automatiser pour être plus efficace, et traiter les cas le plus tôt, le plus rapidement et à l’échelle.
On opère dans beaucoup de pays. On transporte des millions de passagers tous les mois. Du coup, il faut que l’on soit réactif.
Julien Merali : Aujourd’hui, remarquez-vous une satisfaction des équipes sur le projet ?
Emmanuel Martin-Chave : Dans l’ensemble oui, il y a de la satisfaction. Plus localement, il y a des gens pour qui le paradigme a beaucoup changé et qui sont encore en train de digérer tout ce changement.
Julien Merali : Sur un projet de Data mesh, quels sont les limites, les écueils ?
L’organisation doit d’abord avoir à répondre à un problème. Si on implémente une solution sans comprendre ce que l’on veut résoudre, techniquement, cela va mal marcher.
Concernant les limites : si mon problème n’est pas d’être plus efficace mais par exemple, faire de l’éducation, je ne suis pas sûr que le Data Mesh soit une bonne solution.
Si mon problème est que je n’ai pas d’harmonisation ou de pratiques similaires au sein de mes différentes équipes, le Data Mesh n’aide pas du tout là-dessus. Parce que les différents métiers sont éclatés.
Concernant les écueils, je crois qu’il faut être bien placé sur une courbe maturité / taille d’équipe . Ce qui nous a aidé, c’est la maturité de nos clients : on n’a pas besoin de faire de l’éducation sur la data. Mais aussi la maturité de l’équipe qui comprenait déjà bien son métier, qui avait mis en place la bonne “Slack”, les bons outils.
Et la taille de l’équipe : faire un Data mesh avec 10 personnes, c’est compliqué. Le faire avec 300 personnes, c’est compliqué aussi, mais sur d’autres enjeux.
Julien Merali : Quelles sont vos prochaines étapes ?
Emmanuel Martin-Chave : Là, on a fait tous les changements hiérarchiques, on a créé les nouvelles équipes, etc. On a 5 squads pluridisciplinaires, avec des analysts des scientist, des engineers, chacune affairée à un domaine métier. Par exemple, on en a une qui s’occupe des conducteurs carpool. On en a une autre qui s’occupe des passagers tous types de transport confondus, etc.
Chacune à son manager et elles sont aidées par une équipe plateforme qui va les accélérer.
Ce qui a été intéressant aussi, c’était de voir comment on a créé un peu des frontières entre ces différentes équipes.
Donc pour les prochains projets, ces frontières-là, il va falloir qu’on les réplique sur notre architecture et notre modèle de données. C’est quelque chose que l’on est en train de faire et cela prend du temps. C’est lourd, c’est lent et on voit déjà que le fait de travailler en squad, cela nous permet d’accélérer.
Mais casser notre monolithe et en faire des bouts plus petits que chaque équipe possède entièrement est la prochaine étape.
Julien Merali : Pour les managers qui doivent davantage prendre la main, c’est un véritable changement !
Emmanuel Martin-Chave : Oui, pour eux, le métier change pas mal parce qu’avant, ils étaient responsables d’un métier qu’ils connaissaient et maintenant, ils sont responsables d’une équipe avec plusieurs composantes. Donc cela change leur façon de manager.
Julien Merali : Est-ce qu’il y a des métiers qui ont été impactés en premier ?
Emmanuel Martin-Chave : Clairement, la partie data engineering a été la plus impactée. On a à la fois éclaté leur équipe centrale, changer le paradigme dans lequel il travaillait, plus une grosse migration dans leur roadmap.
Les autres ont eu quasiment tous les avantages en ayant assez peu d’inconvénients.
