"Le Data Mesh : une gestion décentralisée de la data qui crée de la valeur."

Bonjour à tous, je suis Emmanuel Malherbe, directeur du Centre de Recherche Artefact et j’ai le plaisir d’animer les Data Coffees. Le principe, je le rappelle, est un sujet, un expert en Artefact, et aujourd’hui on parle du maillage de données avec Killian.

Bonjour Kilian, vous allez donc nous parler du Data Mesh, d’un point de vue de consultant Data ?

Absolument, alors laissez moi me présenter, je m’appelle Killian Gaumont, je suis manager conseil chez Artefact, et mon métier est d’accompagner mes clients vers la transition de la data et notamment vers ces nouveaux modèles que représente aujourd’hui le Data Mesh, dont je vais vous parler aujourd’hui.

Et donc globalement pour vous c’est quoi le Data Mesh ?

Donc effectivement aujourd’hui dire ce qu’est le Data Mesh consiste déjà à commencer par dire ce qu’il n’est pas. Car le Data Mesh est un nouveau modèle qui a vu le jour dans les organisations, notamment dans le but de démanteler l’usage des données aujourd’hui. On s’est rendu compte dans l’histoire aujourd’hui des différentes organisations qui traitent des données, c’est que les données ont été cloisonnées au sein d’entités de données qui les traitent, et qui les traitent pour des usages métiers.
Aujourd’hui l’utilisation du Data Mesh vise notamment à mettre en place une organisation où la manière dont la responsabilité des données est décentralisée. Qu’est-ce que ça veut dire? Cela veut dire qu’on va notamment confier à l’entreprise la responsabilité de traiter ses données pour son propre usage, donc c’est vraiment la promesse du maillage de données, qui est de ne pas avoir d’entités trop cloisonnées, trop centralisées qui deviendront au fur et à mesure nous constatons chez un certain nombre de nos clients, nous dirons des goulots d’étranglement pour le traitement de ces données, et d’offrir aux différents acteurs du métier la possibilité de traiter eux-mêmes leurs données pour leurs propres usages.

Vous parlez d’entité et de silo, je vais sortir un mot-clé récurrent, le domaine Data, c’est quoi ?

Aujourd’hui le domaine Data est né avec le modèle de maillage de données. Comment le définit-on aujourd’hui ? Cela vient notamment du fait que toutes les données aujourd’hui que l’entreprise produit sont assez vastes, c’est-à-dire qu’aujourd’hui ce sont les données que nous produisons et que nous utilisons à des fins métiers il y a beaucoup de choses. Donc en fait une organisation aujourd’hui afin de pouvoir mieux structurer ses données dans le but d’avoir un usage proche de celui de la profession, nous avons créé la notion de domaine, de domaine de données, qui vise notamment à délimiter les données dans un périmètre de données d’un point de vue fonctionnel où l’on positionnera différents responsables de traitement de ces données par rapport à l’utilisation faite par l’entreprise. Donc, en fait, un domaine de données est une distribution de personnes et de données ; nous pouvons prendre notamment les données des produits, les données de transaction d’une entreprise ; nous allons les délimiter et placer les responsabilités au-dessus de ces périmètres.

Alors sans forcément divulguer le nom des clients, auriez-vous des exemples de domaines spécifiques ?

Oui, tout à fait, donc c’est une des missions que nous avons réalisées plusieurs fois chez Artefact, dans la définition des domaines vraiment, donc nous l’avons fait pour certains acteurs, notamment dans les télécoms ou la grande distribution. Un exemple de domaine qui revient souvent est les domaines de données produit, où l’on viendra lister l’intégralité du catalogue produit d’un client et toutes les principales métriques à des fins commerciales qui seront ensuite utilisées dans ce contexte. Il est donc très important de bien définir ces domaines pour l’ensemble de l’organisation, car d’une part cela va responsabiliser certaines personnes pour définir l’usage, et d’autre part cela viendra notamment poser une carte et un vocabulaire commun dans le métier. Parce que souvent, lorsque nous parlons d’informations et de données, le principal problème auquel nous sommes confrontés au début est ce que nous appelons les choses, et donc le premier objectif d’un domaine est de cartographier et de définir comment les choses sont appelées au sein de l’organisation.

Comment le définissons nous, ou en d’autres termes comment divise-t-on l’organisation ?

Il n’y a pas d’approche miracle pour commencer, donc effectivement c’est ce qui est important. Nous avons eu plusieurs démarches avec nos différents clients, notamment avec un de nos acteurs télécoms, donc ce que nous avons fait pour définir les domaines de ces organisations : on est parti des systèmes qui produisent l’information, et des processus qui se chargent de la construire, et du coup dans par rapport à ces processus ces systèmes, on arrive à cartographier les différentes personnes, qui sont en face de ces processus et de ces systèmes, et cela commence à constituer une première cartographie, une première délimitation du périmètre des données, une première délimitation du périmètre de données fonctionnelles pour l’entreprise. Il y a une deuxième approche qui est tout à fait possible, c’est partir notamment des usages, c’est-à-dire qu’aujourd’hui l’objectif du Data mesh est de rapprocher la donnée et son usage par rapport au traitement qui est fait, donc on va partir des usages métiers, on va définir avec les différents métiers les différentes entités qui utilisent les données, quels sont les principaux usages qui en sont faits, et à partir de ça on va dire demander une cartographie, un vocabulaire commun en disant ici nous sommes, nous allons avoir telle ou telle métrique.
Prenons un exemple concret, aujourd’hui ce que nous avons souvent défini dans le cadre des organisations de nos clients ce sont les métriques autour des ruptures, les métriques autour de la marge, donc on va demander au business quelles sont les principales métriques qui permettent de définir ces des KPI clés au sein de l’entreprise et nous ajouterons ensuite une cartographie des données qui permet de les constituer et c’est ainsi que nous constituerons progressivement nos domaines.

C’est très clair et je dirais même comme ça ça a l’air très simple, mais je vais quand même poser la question est-ce simple à mettre en place ?

Alors non, ce n’est pas du tout facile aujourd’hui d’organiser le maillage de données, notamment parce qu’on va arriver, contrairement à ce qui se faisait autrefois où tout était centralisé, c’est-à-dire une entité assez restreinte qui gérait et traitait les données, là on va donner beaucoup plus de pouvoir à des entités indépendantes, donc ce n’est finalement pas si simple à mettre en place puisqu’effectivement il va falloir définir des règles, il va falloir définir, une instance qui sera une sorte de constitution pour relier toutes ces entités indépendantes, donc ce n’est pas simple, il n’y a pas de démarche miracle.
Nous l’avons fait avec certains de nos clients. Ce que nous recommandons la plupart du temps, c’est l’approche par petits pas ; alors que veut dire l’approche par petits pas, c’est-à-dire qu’on ne va pas entrer dans un domaine tout de suite, en reprenant tout à zéro. On va prendre un domaine, donc un domaine qui est relativement simple, on ne commencera jamais par des domaines trop compliqués, prenons notamment le domaine stock ou la gestion de l’inventaire de la supply chain chez nos clients, qui sont relativement bons domaines définis. A partir de là, on va commencer à définir les premiers produits de données, c’est-à-dire les premiers usages qui sont faits de ces données là, on va le définir avec les différents métiers, et on va mettre en place notre système, on va dire pour process ces données et c’est là qu’on va s’occuper notamment de la mise en place du maillage et des différents domaines à travers des produits simples à définir, donc on va le faire sur un premier périmètre on va prouver la valeur du modèle sur un domaine précis et ensuite nous pouvons répliquer et mettre à l’échelle sur différents domaines, qui sont d’autres domaines que nous aurons définis au début.

Et donc une fois qu’on a mis en place le Data Mesh pour un domaine, quels sont les critères de succès pour dire qu’on a réussi ?

Très bonne question ; aujourd’hui c’est la question centrale pour la plupart de nos clients chez qui nous avons déployé ce type d’organisation c’est quand est-ce que je sais que j’ai réussi à mettre en place une organisation maillée sur un périmètre restreint. Très souvent ce que nous définissons avec notre client : il y a deux métriques clés où nous allons venir mesurer l’impact que nous avons obtenu, et qui nous permettent de dire si nous sommes plus matures sur cette organisation ; le premier est l’usage, c’est-à-dire qu’aujourd’hui le Data Mesh a pour vocation de rapprocher l’usage des entreprises des données qui sont utilisées et produites dans le cas de l’organisation ; c’est-à-dire qu’aujourd’hui on va venir compter le nombre d’utilisateurs de produits data dans le cadre de ce domaine, c’est-à-dire qu’aujourd’hui ma métrique de marge ou métrique de rupture, j’aimerais savoir combien de personnes aujourd’hui sur un regard quotidien sur cette métrique, qui l’utilise pour prendre des décisions commerciales, c’est la première métrique fondamentale. J’ai produit et traité des données afin qu’elles puissent être utilisées au sein de l’organisation, si ce n’est pas le cas, cela signifie que j’ai jusqu’à présent manqué la mise en œuvre de la tâche. La deuxième métrique vraiment importante que nous allons venir mesurer avec nos clients, c’est le temps de déploiement de l’information, c’est-à-dire qu’aujourd’hui ce qu’on appelle le time to insight en anglais c’est la rapidité avec laquelle le business va y avoir accès à l’information, et notamment si on prend notre exemple de marge ou de taux de rupture, combien de temps il me faut pour avoir cet accès à cette information à n’importe quelle granularité, pour prendre des décisions commerciales, donc c’est un peu différent, notamment en termes d’usage et si les gens l’utilisent aujourd’hui, mais c’est le temps qu’il m’a fallu pour déployer cette information et donc c’est vraiment deux objectifs du maillage de données, c’est 1) être beaucoup plus proche de l’usage, et notamment de l’information tel que l’entreprise veut qu’il soit utilisé et 2) que nous gagnions en vélocité, que nous gagnions du temps de déploiement lorsque nous arrivons à déployer de futurs produits de données.
Si aujourd’hui nous sommes capables de mesurer ces deux métriques clés, nous constatons une augmentation des usages notamment et une réduction du temps de déploiement des informations, cela signifie que nous sommes potentiellement prêts à déployer ce maillage sur un autre domaine et voir comment il travaux.

Très clair, donc ce sont des métriques de réussite très transparentes mais en termes d’échec j’imagine qu’il y en a aussi, quel est votre point de vue sur les pièges à éviter pour le Data Mesh ?

Absolument, il y a plusieurs écueils, le premier qu’on a vu chez nos clients c’est de vouloir scaler trop vite, c’est quelque chose qui arrive assez souvent, notamment pour faire le lien avec ce que je disais plus haut ; si aujourd’hui vous vous lancez dans le scaling ou le déploiement du modèle de maillage de données dans un autre domaine, vous vous retrouverez avec une organisation qui trouvera des silos, c’est-à-dire qu’en fait vous vous retrouverez dans l’écueil que vous vouliez éviter avant, à savoir plusieurs des silos de données, plusieurs silos d’entités qui traitent les données, donc ce premier écueil, si vous voulez passer trop vite à l’échelle sans avoir prouvé la valeur du modèle et sans avoir prouvé aujourd’hui qui avait vraiment intérêt pour vous à déployer ce modèle. Le 2ème écueil que l’on voit souvent c’est le fait de ne pas avoir assez de règles et de constitution aujourd’hui dans le cadre du maillage, on dit qu’on donne beaucoup plus de responsabilités aux différentes entités pour traiter les données, ce qui dit plus de responsabilités veut dire plus de pouvoir, forcément ça veut dire plus de règles aussi c’est peut-être un peu paradoxal mais le maillage des données n’exclut pas d’avoir une constitution et des règles, alors qu’aujourd’hui notamment le rôle de la gouvernance des données vise notamment à mettre en place les normes, les conventions qui permettent à chaque domaine aujourd’hui, quand ils mettent en production des produits de données ou mettent en production les usages qui seront faits des données, ils le font selon les règles qui ont été définies, parce que sinon on se retrouve avec plein de façons de faire différentes et on trouve des silos, donc l’objectif premier de la gouvernance des données, définir ces règles et cette constitution, c’est très important. Le troisième écueil que l’on peut voir notamment est de penser en mode projet et non en mode produit, pourquoi je cite ça, et vous aurez l’occasion de le voir dans une autre vidéo sur cette plateforme, mais déployer un Data Mesh, c’est effectivement un projet, c’est à dire c’est une transformation, donc au début il y a une arrivée il y a une feuille de route pour y arriver, mais quand on déploie c’est non on va dire on n’est pas fini, on est dans le processus de déployer une organisation qui change complètement l’organisation de l’entreprise, qui vise notamment à accroître l’utilisation des données, c’est donc là que la notion de produit de données il est important de penser que la donnée est un produit qui va être utilisable et réutilisable. Penser aujourd’hui qu’on va déployer un Data Mesh et s’arrêter là, c’est qu’on n’a absolument pas compris quel était le but de cette organisation ; le but de cette organisation est de produire en continu des produits qui sont utilisés par l’entreprise et d’évoluer en fonction de la réutilisation qui en sera faite. Alors ça pour moi c’est vraiment les trois écueils, ne pas penser mode produit quand on reste en mode projet, vouloir absolument scaler trop vite ce qu’on a déjà essayé en résumé voici les trois écueils à éviter.

Merci Kilian c’est un sujet complexe très riche avec beaucoup d’embûches mais cette discussion permet d’y voir plus clair. Merci de votre attention, je vous donne rendez-vous la semaine prochaine pour un nouvel épisode de Data coffee sur notre plateforme média, The Bridge.