Sébastien DavidVotre DSI ou votre équipe data vous parle de « data mesh ». Le terme sonne comme un énième concept technique, et la demande de budget qui l'accompagne mérite d'être comprise. Bonne nouvelle : si vous dirigez une fonction finance, vous connaissez déjà l'essentiel du modèle.
Le problème que le data mesh veut résoudre
Pendant des années, le modèle dominant a été le suivant : une équipe data centrale collecte les données de toute l'entreprise dans un entrepôt unique (data warehouse ou data lake) et produit les analyses pour tout le monde.
Cela fonctionne tant que l'entreprise reste simple. Puis les demandes affluent de tous les métiers et l'équipe centrale devient un goulot d'étranglement : les délais s'allongent, les données sont mal interprétées par des équipes qui ne connaissent pas le métier qui les produit, et personne n'est clairement responsable de leur qualité.
Transposé à la finance
Imaginez qu'un service central doive produire seul le reporting de toutes les business units, sans contrôleur de gestion sur le terrain. Les chiffres arriveraient tard, et personne ne saurait vraiment les expliquer.
L'idée centrale : l'organisation de votre contrôle de gestion
Le data mesh, formalisé en 2019 par Zhamak Dehghani, propose de répartir la responsabilité des données entre les domaines métier, tout en conservant des règles et des outils communs.
C'est exactement le fonctionnement d'une direction financière décentralisée : des contrôleurs de gestion dans chaque business unit, un référentiel commun (plan de comptes, calendrier de clôture, normes) et une consolidation au niveau du groupe. Personne ne propose de supprimer les contrôleurs locaux, ni de laisser chaque filiale inventer son propre plan de comptes.
Les quatre principes, traduits en langage finance
1. La responsabilité par domaine
Chaque domaine métier (ventes, logistique, RH…) est responsable des données qu'il produit, parce que c'est lui qui les comprend le mieux.
En finance : chaque business unit est responsable de ses chiffres. Le siège ne recalcule pas le chiffre d'affaires d'une filiale.
2. La donnée comme produit
Les données partagées sont traitées comme un produit : documentées, fiables, avec un responsable identifié et des engagements de qualité (fraîcheur, exactitude).
En finance : la liasse de consolidation. Format standard, date de remise, contrôles de cohérence et un signataire responsable.
3. Une plateforme en libre-service
Une équipe centrale fournit les outils communs (stockage, sécurité, catalogue) pour que chaque domaine publie ses données sans tout reconstruire.
En finance : l'ERP et l'outil de consolidation groupe. Chaque filiale les utilise ; aucune ne développe le sien.
4. Une gouvernance fédérée
Quelques règles communes (définitions, sécurité, RGPD, interopérabilité) sont décidées ensemble et appliquées partout, idéalement de façon automatisée.
En finance : les normes comptables et le manuel de procédures groupe. Définis centralement, appliqués localement, audités.
Ce que cela change pour la direction financière
Des chiffres qui ont un propriétaire
« Quel est le bon chiffre de marge ? » La question trouve enfin une réponse : le domaine qui produit la donnée en est responsable, selon une définition partagée.
Un pilotage plus rapide
Les métiers publient eux-mêmes leurs données ; l'équipe centrale n'est plus le passage obligé de chaque nouvelle analyse.
Des coûts plus lisibles
Chaque produit de données a un responsable et des utilisateurs identifiés. Il devient possible de répartir les coûts de plateforme et de mesurer la valeur produite, domaine par domaine.
Une conformité intégrée
Les règles (RGPD, droits d'accès, traçabilité) sont appliquées par la plateforme plutôt que vérifiées après coup, ce qui facilite les audits.
Les coûts et les risques à regarder en face
Le data mesh n'est ni gratuit, ni fait pour tout le monde.
- C'est un changement d'organisation avant d'être un projet technique. Il faut des responsables de données dans les métiers, du temps alloué et un sponsor en direction.
- L'investissement initial précède les bénéfices. La plateforme commune et la gouvernance doivent exister avant que les domaines puissent publier leurs données.
- Le risque de silos est réel. Sans règles communes fermes, chaque domaine crée ses propres définitions, et l'on retrouve le désordre que l'on voulait éviter.
- Il existe une taille critique. Avec peu de domaines et une petite équipe data, la décentralisation coûte plus qu'elle ne rapporte.
Et pour une PME ou une ETI ?
Soyons honnêtes : un data mesh complet est rarement justifié dans une entreprise de taille moyenne. En revanche, plusieurs de ses principes sont utiles dès le départ, et peu coûteux :
- nommer un responsable pour chaque donnée clé (clients, produits, ventes) ;
- écrire une définition commune des indicateurs suivis en comité de direction ;
- traiter les jeux de données partagés comme des produits : documentés, contrôlés, avec un niveau de qualité annoncé ;
- choisir des outils qui permettront de décentraliser plus tard, si la croissance le justifie.
C'est souvent la meilleure approche : adopter les bonnes pratiques du data mesh sans en reprendre toute l'organisation, puis évoluer avec l'entreprise.
Cinq questions à poser avant d'investir
- Quel problème concret voulons-nous résoudre : délais, fiabilité des chiffres, coûts ?
- Combien de domaines métier produisent et consomment réellement des données ?
- Qui, dans chaque domaine, sera responsable des données, et avec quel temps alloué ?
- Quelles règles communes seront non négociables, et qui les fera respecter ?
- Comment mesurerons-nous le succès dans douze mois ?
En résumé
Le data mesh applique à la donnée ce que la finance pratique depuis longtemps : responsabilité locale, règles communes, consolidation fiable. Si les réponses aux cinq questions restent floues, commencez par un diagnostic plutôt que par une plateforme.