Derrière la mode du data mesh, le véritable enjeu de la décentralisation de la donnée
Habitués à accompagner les grandes entreprises dans leurs stratégies et modalités de gouvernance de la donnée, Thibault Lorrain, Senior Manager, et David Guede, Practice Leader, au sein des équipes Data Technologies chez Converteo, s’arrêtent sur le concept à la mode du “data mesh”. Au fil de cette interview menée par Laurent Nicolas-Guennoc, directeur marketing de Converteo, Thibault et David mettent le data mesh à nu pour montrer ce que ce concept permet réellement, et à quelles conditions.
Le terme de data mesh fait partie de ces expressions à la mode depuis quelques années chez les professionnels du digital et de la data. C’est une mode, ou une vraie tendance ?
Thibault Lorrain – Comme souvent quand un terme de ce type émerge, il faut se départir du bruit ambiant et aller creuser, avec méthode, pour comprendre ce que signifie cette expression.
Le data mesh est décrit pour la première fois par une consultante, Zhamak Dehghani, en 2019, dans un document intitulé “Comment passer d’un datalake monolithique à un data mesh distribué ?”, rédigé alors qu’elle travaillait dans la société américaine Thoughtworks.
Le mot-clé pour Dehghani, c’est “décentralisé”. Un data mesh est une architecture technique et une organisation des équipes fondées sur la décentralisation de la donnée, avec pour parti pris et finalité que cette décentralisation permette de mieux répondre aux utilisateurs de la donnée, aux métiers de l’entreprise.
David Guede – “Mesh” c’est la maille, ou le maillage, en anglais : on cherche à “mailler” l’organisation, à distribuer des responsabilités, l’accès à la donnée aux domaines de l’entreprise où travaillent les utilisateurs qui en ont besoin.
Distribution, domaines, nous y sommes : derrière l’expression récente de data mesh se trouve en réalité toute une littérature informatique qui décrit, comme Eric Evans dès 2003 dans Domain-Driven Design: Tackling Complexity in the Heart of Software, la nécessité de définir les domaines, les contextes spécifiques dans lesquels les logiciels, ou les données, opèrent, de travailler avec les experts de ces domaines -ce qu’on appelle aujourd’hui “le métier”- et de décrire le plus clairement possible les relations et les interactions entre ces différents contextes pour éviter les ambiguïtés et les incohérences.
Autrement dit, pas de “maille” sans “domaine”. Et l’on parle de domaine depuis plus de vingt ans, donc plus qu’une mode, c’est un basique.
A quoi l’approche “datamesh” est censée répondre ?
TL – Elle est un contre-modèle au “monolithe”, qui est une critique là encore bien connue et qui ne date pas d’hier, celle d’une direction informatique qui au motif de se poser en garante de la qualité, de la sécurité, de la fiabilité, dicte les règles du jeu et les processus, choisit la plateforme data, la déploie, en contrôle strictement les accès. Résultat : frustrations des métiers, sentiment que les besoins sont mal compris, ne sont pas traités assez vite…
Des décennies de sociologie des organisations ont toutefois montré que plus ce type de rapport de dépendance est hermétique et s’exerce strictement, plus se crée un terrain propice aux stratégies de contournement.
DG – Ce qu’on appelle parfois le “shadow IT”, l’informatique de l’ombre, le fait pour une équipe de recourir à ses propres outils, à dupliquer des parties d’infrastructure, des données, à définir ses propres règles, est en fait très courant.
Si le métier peut y regagner des marges de manœuvre, ce chacun pour soi ne peut pourtant pas perdurer sans avoir des effets néfastes sur l’organisation : difficultés d’interopérabilité, création de silos, pratiques et règles divergentes, problèmes de fiabilité de la donnée et, bien souvent, multiplication et redondance des coûts.
Comment sortir de ce dilemme entre centralisme et chaos ?
TL – Les gouvernances décentralisées -expression que nous préférons généralement au “datamesh”, car il y a en réalité tout un dégradé d’options possibles et non pas un modèle unique de datamesh – proposent une troisième voie qui doit avant tout redonner de l’autonomie aux métiers, leur permettre de gagner en réactivité.
Concrètement, comme dans toute gouvernance, il faut démarrer le projet par des étapes de formalisation : définir les rôles des équipes techniques et data d’une part, ceux des différents “domaines” ou mailles de l’organisation d’autre part, documenter les conditions de l’interopérabilité entre domaines. Il est notamment indispensable d’uniformiser la définition d’indicateurs, prenons le chiffre d’affaire par exemple, utilisés dans différentes équipes (marketing, finance…) mais pouvant être construits différemment. Notre rôle de tiers conseil dans ces phases de grande remise à plat est, d’expérience, indispensable aux entreprises qui souhaitent réellement créer une démarche de consensus.
DG – Chez Converteo nous défendons par ailleurs la conviction qu’il ne peut pas y avoir de décentralisation réussie de la gouvernance data sans que s’opère un changement culturel qui consiste à appréhender la data comme un produit interne. Pour réconcilier un usage de la donnée qui vient se mouler aux besoins d’équipes différentes, il faut un “produit data” qui soit standardisé, fiable, interopérable.
Afin d’assurer l’interopérabilité, le produit data doit répondre à des exigences très strictes. Une bonne pratique à garder en tête est de standardiser l’information de manière rigoureuse. Des recommandations simples incluent la définition d’un format uniforme pour les dates et l’utilisation maximale des normes ISO. Dans certaines industries, ces standardisations sont poussées à l’extrême avec des noms de champs normalisés et des formats très stricts. Prenons l’exemple du format CDISC dans l’industrie pharmaceutique, qui s’est imposé et a simplifié le travail de tous en favorisant les échanges, tant en interne pour croiser des sources de données qu’en externe pour partager les données avec d’autres partenaires. Une approche intéressante est également d’exploiter plus finement la métadonnée, qui est aujourd’hui trop souvent négligée.
Une exploitation avancée de la métadonnée permet d’aller encore plus loin dans le partage des données à travers les différents domaines et sert de « dictionnaire » universel pour l’entreprise. On ne peut pas parler de produit data sans évoquer les data contracts, un sujet très important chez bon nombre de nos clients. Ces data contracts consistent à établir des règles de partage entre le producteur (responsable de la donnée) et le consommateur (l’équipe data) en définissant dès la collecte les formats et les transformations nécessaires, les données obligatoires ou celles qui peuvent rester vides. Ce cadre permet d’accélérer grandement les phases de standardisation et donc l’exploitation de la donnée de manière transversale au sein d’une entreprise.
TL – Les entreprises qui réussissent le mieux le virage de la décentralisation sont celles qui parviennent à abaisser les barrières à l’usage de la data au sein des métiers, en faisant notamment un effort important sur l’interface d’utilisation, la capacité à rédiger de la documentation simple, claire, abordable à des non-spécialistes.
Ce n’est d’ailleurs pas un hasard si le recours à des profils “Data Product Owner” aux compétences transverses, détenteurs à la fois d’une culture product management et d’expertises data, est un besoin croissant dans les phases d’opérationnalisation de ces nouvelles gouvernances.
Le parallèle avec la décentralisation de l’Etat est je crois assez efficace : les collectivités territoriales ont demandé à avoir les moyens d’exercer les compétences nouvelles qui leur étaient déléguées. Les équipes métiers, les “mailles” de l’entreprise qui réclamaient un accès à la data, doivent elles aussi avoir les bonnes ressources -outils faciles à prendre en main, formation et nouvelles compétences dans les équipes- pour tirer pleinement profit de la décentralisation de la data.
Sources :