Le data mesh est présenté partout comme une architecture technique à déployer. Les deux textes qui ont créé le terme disent autre chose, et c'est ce décalage qui explique la plupart des projets qui s'enlisent.
Il repose sur quatre principes : la propriété décentralisée par domaine, la donnée en tant que produit, l'infrastructure en libre-service, et une gouvernance fédérée et calculatoire.
Un détail de formulation mérite d'être relevé, parce qu'il interdit le panachage. Son auteure présente ces quatre principes comme collectivement nécessaires et suffisants. On ne prend pas le libre-service sans la propriété par domaine, ni la gouvernance fédérée sans les produits de données.
Le diagnostic de départ, qui n'est pas technique
Le point de départ est la séparation entre données opérationnelles et données analytiques, et le constat que cette divergence a produit une architecture fragile.
La cause pointée est une omission : on a appliqué le domain driven design aux systèmes opérationnels, mais on a largement ignoré la notion de domaine dans la plateforme de données. D'un côté des systèmes découpés par métier, de l'autre une plateforme découpée autrement.
Découpée comment, exactement ? En étapes de traitement : ingestion, nettoyage, agrégation, restitution. Et voici le point le plus contre-intuitif de tout le sujet : c'est un découpage orthogonal à l'axe du changement.
La conséquence est mécanique. Activer une seule nouvelle fonctionnalité oblige à modifier tous les composants du tuyau.
Pour rendre la chose concrète, un exemple : dans une ETI de 400 personnes, ajouter un simple indicateur de taux de rachat au tableau de bord commercial oblige à ouvrir un ticket sur l'ingestion, un autre sur le nettoyage et un troisième sur l'agrégation, soit trois équipes différentes, alors que la donnée source existe déjà depuis dix-huit mois dans l'outil de vente.
Le troisième mode de défaillance est humain : des ingénieurs data hyper spécialisés, coupés des unités opérationnelles où la donnée naît et où elle est utilisée. Aucun des trois n'est un problème d'outil.
Découper selon les coutures de l'organisation
La réponse suit du diagnostic. Le data mesh découpe selon les coutures des unités organisationnelles, pas selon la pile technologique.
C'est ce qui rend l'expression « déployer un data mesh » suspecte. On ne déploie pas un découpage organisationnel, on le décide, et l'outillage vient après.
La donnée traitée comme un produit
Deuxième principe, et le plus exigeant. La donnée analytique fournie par un domaine doit être traitée comme un produit, et ses consommateurs comme des clients.
Ce n'est pas une métaphore de communication, puisque le modèle introduit un rôle : le propriétaire de produit de donnée du domaine, mesuré sur la qualité, le délai de consommation et la satisfaction des utilisateurs. Trois indicateurs qui portent tous sur l'usage, aucun sur le volume traité.
Voilà le vrai changement, et il est plus lourd qu'une migration : c'est une inversion du modèle de responsabilité, la redevabilité sur la qualité remontant au plus près de la source de la donnée. L'équipe qui produit la donnée répond de sa qualité, à la place de l'équipe centrale qui la nettoyait après coup.
L'unité de base, et pourquoi elle compte
Les composants d'un data mesh se déduisent d'une définition précise : le produit de donnée est le quantum architectural du data mesh, c'est-à-dire la plus petite unité déployable indépendamment.
Ce critère tranche les débats de périmètre mieux que n'importe quelle liste. Si un produit de donnée ne peut pas être déployé sans coordonner trois autres équipes, ce n'est pas un produit de donnée, c'est un morceau de tuyau qu'on a renommé.
Le libre-service n'est pas un confort
Le troisième principe est souvent traité comme un agrément offert aux équipes. Il est en réalité la condition de faisabilité des deux précédents.
La seule façon pour des équipes de posséder vraiment leurs produits de données est de leur donner une abstraction d'infrastructure de haut niveau. Sans elle, la propriété par domaine se réduit à un transfert de responsabilité sans les moyens correspondants, ce qui est la recette d'un échec rapide.
La gouvernance fédérée, et ce qu'elle remplace
La gouvernance fédérée doit maintenir un équilibre entre centralisation et décentralisation, en tranchant ce qui se décide localement et ce qui se décide globalement.
Elle se comprend mieux par contraste. La gouvernance traditionnelle cherche la valeur par la centralisation des décisions et par une représentation canonique globale, peu ouverte au changement. C'est ce modèle canonique unique qui est abandonné, pas la gouvernance elle-même.
Quand le data mesh ne sert à rien
Le texte fondateur pose lui-même sa propre limite, et cette phrase manque à presque toutes les présentations du sujet. Le modèle centralisé fonctionne pour un domaine simple.
Il échoue dès que l'entreprise a des domaines riches, beaucoup de sources et des consommateurs variés. Le critère de décision n'est donc ni la taille de l'entreprise ni le volume de données, mais la diversité des domaines et des consommateurs.
Le cas d'utilisation type est donc celui d'une entreprise à domaines multiples, dont les données sont produites à beaucoup d'endroits et consommées par des métiers qui n'ont pas les mêmes questions. À l'inverse, une entreprise mono-produit avec trois sources et un service qui consomme les tableaux de bord n'a rien à gagner à fédérer quoi que ce soit : elle a un problème de plateforme, pas d'organisation.
Ce que cela change côté outillage
Une architecture qui déplace la redevabilité vers les domaines demande à l'outil d'informatique décisionnelle autre chose qu'une capacité de calcul : la possibilité que chaque domaine expose et documente ses propres jeux de données sans passer par une équipe centrale.
Notre catalogue recense 26 logiciels de business intelligence publiés, dont 21 offres facturées au mois allant de 11 € à 1 925 € HT.
Sur ce terrain, une seule question sépare vraiment les solutions, et notre comparateur donne de quoi y répondre : chaque domaine peut-il publier, documenter et versionner ses propres jeux de données, ou le catalogue reste-t-il alimenté par les administrateurs de l'outil ?
