Avec le Data Mesh, la donnée décentralisée enfin à l’heure de la maturité ?

La data est un matériau avec lequel on construit des produits, des services, des automatismes, afin de créer davantage de valeur. Parallèlement, la digitalisation des activités et des échanges, la dématérialisation et l’Internet des objets multiplient les sources de données, aussi abondantes que variées. Bref, on a à la fois beaucoup plus de matière première et beaucoup plus de façons de l’exploiter.

Beaucoup plus et, très vite, beaucoup trop ! La traditionnelle gestion centralisée des données, parfaitement adaptées à la BI, se révèle impraticable à l’ère de l’IA. Les Data Lakes monolithiques deviennent si vastes et si complexes qu’il n’est plus humainement possible de savoir précisément ce qu’ils contiennent. Chacun n’utilise que ce qu’il connaît, la collaboration est très difficile, et les croisements de données, où se situent pourtant la valeur, sont impossibles. Résultat : l’immense majorité des données collectées restent en friche, attendant un cas d’usage qui ne viendra jamais.

Dans cette perspective, l’approche Data Mesh, qui propose de scinder le monolithe de données en plusieurs domaines orientés métier, a d’emblée suscité beaucoup d’intérêt, car elle est apparue comme la réponse parfaite à ces enjeux. Malheureusement, les premières initiatives ont souvent suscité la déception. Guère enthousiastes à l’idée de démanteler ce qu’elles avaient si patiemment construit, les équipes data centrales, à qui était généralement confié le projet, ont commencé à bâtir des architectures compliquées à base de référentiels, de passerelles, et d’outils intermédiaires entre les sources de données et les produits finaux. Approches qui se sont souvent révélées inefficientes, mais qui n’étaient pas à proprement parler du Data Mesh.

Un défi : décentraliser sans créer de nouveaux silos

Le défi est donc de décentraliser la donnée pour la rendre plus maniable sans pour autant créer de nouveaux silos. Il faut en particulier veiller à préserver deux capacités clés. Premièrement, la collaboration, pour que les équipes puissent enrichir et exploiter le patrimoine de données avec un effort de coordination minimal. Deuxièmement, l’extensibilité, pour que ce patrimoine, qui ne cesse de s’enrichir, puisse continuer à croître sans que cela pèse sur l’agilité nécessaire pour bâtir les nouveaux usages.

Un impératif : respecter les grands principes du Data Mesh

C’est pourquoi les expériences mitigées ne condamnent pas le Data Mesh, mais soulignent au contraire l’importance de bien appréhender le concept. Rappelons que le Data Mesh est la déclinaison pour la donnée du Domain Driven Design (DDD), une approche de la conception de système qui postule que la valeur d’un système réside dans la réconciliation transverse de ses composantes. Le DDD vise donc à maximiser le découplage entre les composantes technologiques du système ainsi qu’entre les équipes qui les créent, les fabriquent et les maintiennent. Autrement dit, chaque domaine est géré à sa manière par ceux qui le connaissent le mieux et tout le monde se retrouve au niveau des interfaces.

Le Data Mesh, qui peut se définir comme une approche sociotechnique décentralisée pour gérer et accéder aux données analytiques à l’échelle[1], décline la philosophie du DDD en quatre grands principes : un découpage par domaines ; une présentation sous forme de produits ; une plateforme en self-service ; une gouvernance fédérée. La réussite de la mise en œuvre du Data Mesh passe impérativement par une application rigoureuse de ces quatre principes. Si l’un d’eux manque à l’appel, la décentralisation des données sera bancale, incomplète, et n’apportera pas les bénéfices escomptés.

Concrètement, cela se traduit par quatre axes de transformation :

1. Premièrement, évoluer vers un urbanisme plus décentralisé, porté par les cas d’usage. Le patrimoine de données est découpé en domaines dont la gestion est confiée à des équipes indépendantes. C’est à elles qu’il appartient de faire vivre leur domaine, d’en maintenir la qualité et l’homogénéité, et de proposer des produits data clés en main, faciles à appréhender par les non spécialistes extérieurs. Bien entendu, la condition est de préserver l’interopérabilité des domaines. Pour cela, on pourra recourir à une méthodologie commune de modélisation comme Data Vault, qui permet de s’accorder sur des clés de croisement tout en laissant une grande liberté par ailleurs. On débutera de préférence par les domaines les plus matures et dont le retour sur investissement apparaît le plus immédiat.
2. Deuxièmement, mettre en place une gouvernance fédérée. Pour maintenir la cohérence du patrimoine commun, il faut que chacun puisse faire entendre sa voix. C’est à ce niveau que l’on décidera de la création et du découpage des domaines, des règles d’interopérabilité, de l’outillage commun…
3. Troisièmement, mettre en place une plateforme en libre-service. On l’aura compris, le Data Mesh n’est pas une technologie, mais un principe de gestion et de développement collectif. Il doit s’appuyer sur un outillage adapté, capable d’autoriser cette souplesse tout en préservant la cohésion d’ensemble et la capacité à passer à l’échelle. Aujourd’hui, on trouve essentiellement de tels outils, à la fois robustes et faciles à prendre en main, chez les grands acteurs tels que Snowflake et Google Cloud Platform (BigQuery). Dans la logique de maintien de la cohésion d’ensemble, une approche “Infrastructure as Code” (IaC) garantie la standardisation de l’infrastructure des nœuds du Data Mesh et facilite leur maintenance.
4. Quatrièmement, faire évoluer les parties prenantes internes. Il s’agit sans doute du chantier le plus délicat. En premier lieu, l’organisation data centrale va voir son rôle profondément remis en question alors même qu’elle a en général beaucoup investi ces dernières années pour se renforcer. Elle ne doit pas vivre le Data Mesh comme un désaveu ou un déclassement, mais prendre conscience de son importance clé au cœur du dispositif : c’est elle qui peut accompagner les métiers dans leur propre évolution, diffuser les compétences nécessaires, animer la gouvernance fédérée, maintenir le référentiel cœur, ou encore porter les enjeux transverses d’outillage, d’interopérabilité et de sécurité. Côté métier, il faudra sensibiliser, réorganiser, former et impliquer tous les acteurs qui ont une appétence pour la donnée mais qui ne sont aujourd’hui que très peu associées à sa gestion (par exemple, les actuaires dans le secteur de l’assurance).

Le Data Mesh n’est pas nécessaire pour toutes les entreprises. Tant que le modèle centralisé répond aux exigences métiers en délai et qualité de donnée, pas de raison de changer. En revanche, dès que les produits data deviennent trop nombreux, et qu’il est question de créer des leviers opérationnels fondés sur des données, une approche décentralisée est indispensable. Là, le Data Mesh est la meilleure façon de la mettre en œuvre. En un mot, le Data Mesh est l’enabler du « data-driven », et c’est pourquoi ce sont bien les métiers qui doivent en être à l’origine. Ce sont eux qui doivent constater leur impossibilité de développer leurs projets data avec la structure centralisée existante ou même de façon artisanale, en Shadow IT. C’est une transformation à part entière, qui demande l’acculturation des équipes sur les nouvelles possibilités qu’apporte la data, et qui passe par un travail de découverte des cas d’usages en collaboration avec l’IT, et par un transfert progressif des compétences data vers les métiers et les équipes de développement du SI opérationnel.

Les métiers doivent être les demandeurs du Data Mesh, qui doit être implémenté par eux, avec eux et pour eux. Car une chose est claire : personne d’autre qu’eux ne pourra extraire la valeur des données inexploitées.

[1] Source : Data Mesh: Delivering Data-Driven Value at Scale, Zhamak Dehghani