Data Stories : Le Data Mesh chez Blablacar

Le contexte Data de Blablacar

Chez Blablacar, la data est rattachée à l’Engineering. C’est une entité d’une quarantaine de personnes, répartie en 6 équipes : 5 squads pluridisciplinaires, et une dernière équipe orientée plateforme (nommée Data Ops).

Beaucoup de métiers de la Data sont représentés dans cette entité : Data Analysts, Data Scientists, Software Engineers et Data Engineers. Cela leur permet d’avoir une grande autonomie dans la réalisation de projets de bout en bout.

The Why : La nécessité d’opérer plus efficacement à l’échelle

Commençons par la commencement.

Nous sommes début 2021. À ce moment, l’entité Data est organisée par couches technologiques : une équipe Data Engineering, une équipe Data Science, et ainsi de suite. C’est une approche assez classique dans les entreprises, permettant de créer de véritables pôles d’expertises qui peuvent développer des pratiques et des outils communs.

L’inconvénient est que la stack technique, résultante de cette organisation, était elle-aussi composée de différentes couches technologiques, dont l’interopérabilité et la fluidité de transition pour un même projet devenaient de moins en moins optimales.

La stack est la conséquence de l’organisation (loi de Conway). Une organisation par pôles d’expertises produit une stack par couche technologique.

Ce modèle a petit à petit été remis en cause devant le constat suivant : face à la croissance des besoins business, et donc de l’équipe data, il devenait de plus en plus difficile d’opérer efficacement à l’échelle.

Les équipes data commençaient petit à petit à devenir des goulots d’étranglement, la vitesse de delivery de gros projets augmentait, les priorisations des Use Cases n’étaient pas claires, pas plus que l’ownership de certains sujets comme la Data Quality.

A titre d’exemple, absorber et délivrer de la donnée venant de nouvelles entités était devenu très long et compliqué. De plus en plus de cas d’usage Data Science apparaissaient, notamment avec du streaming, pour lesquels il devenait difficile de faire évoluer l’architecture pour servir ces besoins.

La problématique : opérer plus efficacement à l’échelle

Face à ce problème grandissant, la nécessité d’un changement d’organisation est devenue une évidence.

L’idée d’équipes autonomes liées à des domaines dans lesquels elles opèrent est alors venue assez naturellement.

The How : Le Data Mesh comme source d’inspiration, mais pas la seule

Forcément, face à ces constats, les principes du Data Mesh, décrits dans de nombreux articles et livres, semblent coller parfaitement et apparaître comme une évidence.

Mais un sujet aussi important, qui touche autant à l’aspect humain, ne doit pas être pris à la légère. Appliquer des principes théoriques by the book sans autre source d’inspiration n’apparaît pas comme la bonne solution.

Que faire alors ? Par quoi commencer ? Vers qui se tourner ?

Comme souvent dans les problématiques actuelles en data, la réponse se trouve sous nos yeux. Il n’y a pas meilleure source d’inspiration que les équipes Product & Engineering qui sont juste à côté, car elles ont déjà vécu des transformations similaires par le passé. Il est en effet assez fréquent de retrouver des feature teams pluridisciplinaires en Software Engineering. En outre, les principes du Data Mesh ne sont pas sans rappeler ceux du Domain Driven Design, qui a fait ses preuves depuis des années en Engineering.

L’Engineering a plusieurs années d’avance sur la Data concernant beaucoup de sujets, c’est une grande source d’inspiration.

S’inspirer des challenges organisationnels qu’ils ont rencontré, comprendre les enjeux d’une transformation vers des architectures micro-services et la manière dont on fait collaborer les équipes entre elles, voilà des retours d’expérience précieux pour une réussite de sa transformation d’organisation data !

The What : Chronologie de la transformation vers le Data Mesh

Un tel changement ne doit pas s’opérer en mode Big Bang, mais de manière incrémentale en apprenant au fur et à mesure et en ajustant en temps réel. Chronologiquement parlant, voici les étapes franchies chez Blablacar :

• Q3 2021 : Constat est fait des limites actuelles de l’organisation. S’ensuit une phase de diagnostic du problème et de définition de la vision ;
• Q4 2021 : Onboarding des managers pour créer un alignement sur les problématiques et la vision cible. S’ils ne se sentent pas owners de ce changement, ils ne seront pas moteurs et cela sera un frein au changement ;
• Q1 2022 : Création de deux premières équipes afin d’entamer le changement sans faire de Big Bang et apprendre au fur et à mesure ;
• Q2 2022 : Création des 4 équipes restantes ;
• Fin 2022 : Tous les changements de reporting line sont faits depuis 6 mois, et certaines équipes en sont déjà à leur 3ème trimestre de fonctionnement ;
• 2023 : Continuer les migrations techniques, qu’il avait été décidé de ne faire qu’une fois les changements organisationnels faits, car c’est avant tout un changement culturel et humain.

Forcément, au moment de faire des choix dans sa transformation, beaucoup de questions se posent ! Revenons sur quelques-unes qui sont sur beaucoup de lèvres.

Comment choisir par quelles équipes commencer ?

On aimerait tous avoir un plan tout tracé et qui fait parfaitement sens ! La réalité est souvent plus pragmatique.

BlaBlaCar a choisi de commencer par les domaines qui semblaient les plus simples à rendre indépendants. Mais aussi de prendre en considération des mouvements internes qui étaient déjà prévus et qui ont accéléré certains changements plutôt que d’autres. Les dernières équipes à avoir été créées étaient celles dont les domaines étaient plus imbriqués et difficiles à bien isoler.

Faut-il travailler sur tous les piliers du Data Mesh en même temps ?

La réponse est propre à chaque organisation et à ses priorités.

Chez BlaBlaCar, ça n’a pas été le cas. En l’occurence, le pilier Data As A Product est peut-être celui où il y a eu le moins d’investissement à ce stade de la transformation. Typiquement, il n’y a pas de PO Data par domaine chez Blablacar !

Certains puristes pourront alors s’exclamer que cette organisation n’est pas un Data Mesh ! Et ils auront peut-être raison… en théorie. Au final, ce qui compte n’est pas d’avoir respecté à la lettre des principes théoriques, mais de faire les choix qui ont le plus de sens à ce moment pour répondre au besoin.

BlaBlaCar n’a pas de PO/PM dédié au sein des équipes data

De même, l’autonomie des squads au point de gérer elles-mêmes leurs pipelines d’ingestion n’a pas été poussée aussi loin. Certaines activités sont encore centralisées, car dans leur contexte il apparaissait plus simple de garder un certain nombre de choses mutualisées. Cela aurait rajouté trop de changements d’un seul coup pour les squads, qui en avaient déjà beaucoup à absorber sans cela.

Y a-t-il des changements à opérer en dehors de la data, notamment côté Business ?

Encore une fois, la réponse dépendra du contexte.

Chez BlaBlaCar, il y a eu très peu d’impact organisationnel en dehors de la data, car nous ils ont opéré le changement d’organisation data de telle sorte qu’elle soit le miroir de l’organisation en domaines d’un point de vue métier. Ils restent donc une unité data à part entière (alors que dans la littérature, il faudrait qu’elle soit complètement intégrée dans les domaines) dans l’organigramme de l’entreprise, mais ont un fonctionnement totalement calqué sur les grands domaines métier de l’entreprise.

Adopter une organisation en miroir des domaines métier pour faciliter la transformation et limiter l’impact sur les autres équipes

Zoom sur quelques détails d’implémentation

La gouvernance fédérée

Afin de garder une cohérence et des pratiques communes au sein d’une même expertise technique malgré ce nouveau découpage, BlaBlaCar a créé des Chapters, des communautés de pratiques par expertise où chacun peut se retrouver, se faire challenger sur ses choix et apprendre de ses pairs.

Ces Chapters ont un lien direct avec la notion de gouvernance fédérée du Data Mesh, avec un ou plusieurs membres de chaque Chapter au sein de l’équipe de gouvernance. Ils sont les garants de l’harmonisation des pratiques malgré la dispersion des personnes au sein des différentes équipes.

L'autonomie et les frontières entre les squads ont besoin d'un contrepoids : une gouvernance fédérée et des pratiques communes.

D’un point de vue gestion d’entreprise, c’est aussi un moyen pour BlaBlaCar d’éviter que les managers gèrent trop de responsabilités. Avoir des Chapter Leads est donc aussi un moyen de responsabiliser des contributeurs individuels.

Cette task force de gouvernance gère des sujets qui touchent à la fois à la gouvernance de la donnée (cataloging, quality, lineage, etc.) ainsi qu’à la gouvernance des équipes (règles de fonctionnement et de synergies entre les équipes) ou des périmètres (déplacement des frontières, création de nouveaux domaines).

La Data Platform et son équipe

À date, BlaBlaCar garde une équipe data centrale, nommée Data Ops. Elle fournit l’infrastructure et les services nécessaires aux autres équipes, et crée également certains patterns d’ingestion pour les consommateurs que sont les Data Engineers dans les squads.

L’ingestion de la donnée de production est gérée par l’équipe centrale, mais les transformations sont de la responsabilité des squads.

Au quotidien, l’équipe Data Ops se synchronise avec le Chapter Data Engineering qui représente toutes les squads, ce qui permet de parler d’une même voix concernant toutes les contraintes potentielles au niveau des squads. Cela permet de converger assez vite vers des solutions.

Dans l’implémentation, notamment en ce qui concerne les migrations techniques, l’équipe Data Ops les prépare, et communique auprès des squads lorsqu’ils peuvent les effectuer.

Avec la taille actuelle de l’entité data, ce fonctionnement est tenable sans que cette équipe centrale soit un goulot d’étranglement. Au fur et à mesure que l’équipe grandira et gagnera en maturité, certaines parties seront probablement redistribuées dans les squads.

Pour éviter une nouvelle création de silos, et faire en sorte que chacun comprenne et apprenne des autres, certaines personnes de l’équipe DataOps peuvent aller (même temporairement) au sein d’une squad et inversement. Cela a deux grandes vertus : garantir que les outils et patterns que fournissent l’équipe Data Ops répondent bien aux besoins des squads qui sont leurs clients, et permettre aux équipiers de découvrir d’autres sujets.

Quels résultats et enseignements ?

L’impact humain de cette transformation

Des feedbacks positifs de la part des squads

Preuve de la pertinence de cette transformation : les squads font aujourd’hui des retours très positifs sur les synergies que cette nouvelle organisation a créé en fonctionnant en équipes pluridisciplinaires, chose qu’il était très difficile de faire fonctionner avant.

La majeure partie du voyage se déroule dans l'esprit des gens. Passer à une architecture distribuée, c'est 80% de changement de mentalités.

La population la plus impactée : les Data Engineers

L’impact du changement le plus difficile à gérer concernait une population en particulier : les Data Engineers.

Ces derniers ont vu la manière dont ils travaillent complètement modifiée, ce qui est un changement lourd à vivre. Les embarquer au plus tôt dans le projet de transformation est probablement l’une des choses qu’ils auraient fait différemment si c’était à refaire.

A bon entendeur !

L’impact du dimensionnement d’équipe par domaine

Autre point de douleur qui a dû être géré : étant donné leur taille d’équipe et le découpage fait, BlaBlaCar se retrouve avec certaines équipes où il n’y a qu’une seule personne sur une expertise donnée, ce qui est difficile à vivre pour certains.

Les Chapters mentionnés plus haut répondent, au moins en partie, à cette problématique.

L’importance d’un bon sponsorship pour une transformation réussie

Une organisation est une réponse à un problème. Le diagnostic de ce problème est donc primordial.

Il ne faut pas partir avec une solution en tête, puis embarquer et évangéliser les stakeholders sur le problème qui découle de cette solution. C’est tout l’inverse ! Une fois que tout le monde a convergé sur le bon problème et qu’un alignement a été créé, il devient tout de suite plus simple d’embarquer les différents interlocuteurs sur la solution à implémenter.

Une organisation existe pour résoudre un (et un seul) problème. Le diagnostic de ce problème est donc primordial.

Et pour avoir ce sponsorship, il n’y a pas de secret : plus vous êtes capables de quantifier le ROI de vos projets, plus vous pourrez avoir du buy-in de la part du management. Savoir quantifier le coût que représente un pipeline mal géré ou une donnée de mauvaise qualité est un élément très important qui pourra permettre de prioriser les changements.

Le lien avec les équipes Produit

L’organisation miroir mise en place a l’avantage de réduire le nombre d’intervenants à contacter pour anticiper les sujets. Une squad travaille notamment avec 2-3 PM côté produit, ce qui facilite les choses. Précédemment, chaque couche technologique était en interaction avec tous les PMs !

Il est important d’avoir construit en amont des bonnes relations avec les équipes Produit et Engineering afin de ne pas découvrir les nouvelles features au dernier moment.

Quelques conseils pour conclure

Cette transformation de BlaBlaCar vers le Data Mesh est avant tout un challenge humain, et il ne faut pas négliger le temps nécessaire pour créer l’alignement qui facilite la transition. Ce n’est donc pas tant un challenge technique (même s’il ne faut pas négliger la difficulté de cette partie) qu’un challenge de change management.

Si vous vous posez la question de savoir si c’est le bon moment pour vous d’envisager une transformation vers le Data Mesh, vous pouvez vous appuyer sur l’heuristique suivante, suite au retour d’expérience de BlaBlaCar :

• Faire une organisation Mesh si vous n’avez qu’une seule squad n’a pas de sens ;
• En-dessous de 3 à 4 squads, il est important de se poser la question de savoir si c’est vraiment nécessaire ;
• Au-delà de 3 à 4 squads et s’il y a un besoin de grande diversité des expertises au sein des squads, cela commence à devenir intéressant car on arrive vite à une organisation à 30-40 personnes.

Le risque est de faire de la distribution trop tôt et donc de créer des silos et une divergence des pratiques si vos équipes ne sont pas encore assez matures. Il est donc important d’avoir déjà des équipes ou des communautés de pratiques communes en amont.

S’il y a bien une chose à retenir, c’est qu’il ne faut pas chercher à implémenter une solution si on ne comprend pas le problème que l’on tente de résoudre.

Le Data Mesh est une solution, mais il est important de faire son propre diagnostic en amont avant de s’y lancer tête baissée.

Les articles et livres sur le sujet sont d’excellents moyens de s’ouvrir les chakras et d’identifier de potentielles solutions, mais cela ne doit pas se faire au détriment du temps à consacrer au bon diagnostic du problème à résoudre.