Data Mesh : l'architecture que 7 entreprises sur 10 paient sans jamais l'exploiter
Le data mesh s'est imposé comme le saint graal de l'architecture data. Mais entre l'intention affichée et la valeur réellement produite, l'écart se creuse. Gartner, Forrester et IDC pointent tous le même angle mort : on finance des plateformes, pas des usages. Et le chiffre qui circule — 7 entreprises sur 10 — mérite d'être regardé en face.
Le data mesh n'est pas un logiciel. C'est un modèle organisationnel.
C'est la phrase que répète Zhamak Dehghani, créatrice du concept chez Thoughtworks, dans son livre de référence publié chez O'Reilly. Le data mesh repose sur quatre piliers : la propriété des données par les domaines métier, les data products, une plateforme self-service et une gouvernance fédérée. Aucun de ces piliers ne s'achète sur un bon de commande.
Pourtant, c'est bien souvent ce qui se passe. Les entreprises achètent une plateforme, déploient des outils, annoncent un programme data mesh. Puis constatent, dix-huit mois plus tard, que les métiers n'ont pas changé leurs usages.
Gartner avait prévenu : la gouvernance fédérée est le pilier qu'on sous-estime
Gartner identifie le data mesh comme une tendance montante, mais alerte : beaucoup d'organisations l'adoptent sans les prérequis organisationnels. Propriété des données, plateforme self-service, gouvernance fédérée — les trois conditions sont rarement réunies.
L'analyste va plus loin : d'ici 2026, une part significative des organisations abandonnera des initiatives data mesh mal préparées, faute de gouvernance et de compétences data product. Le chiffre exact reste à confirmer sur page primaire, mais la direction est claire.
Forrester : les data products existent, leur usage réel n'est pas mesuré
Forrester souligne que le succès du data mesh dépend d'un data product management mature. Or, la majorité des entreprises n'ont pas ce niveau de maturité. Pire : les data products sont devenus un critère d'évaluation des plateformes, mais peu d'entreprises mesurent leur usage réel.
Autrement dit, on déploie des data products sans savoir s'ils sont consommés. C'est l'équivalent d'ouvrir un magasin sans compter les clients.
IDC : plus de la moitié du budget data part dans la plomberie
IDC constate que la majorité des budgets data restent consommés par l'intégration et la plomberie plutôt que par la création de valeur analytique. Le cabinet évoque régulièrement plus de 50 % du budget data consacré à l'intégration.
Traduction : l'argent finance les tuyaux, pas l'eau. Et le data mesh, mal cadré, ajoute des tuyaux aux tuyaux.
McKinsey : la valeur dépend de l'adoption métier, pas de la technologie
McKinsey rappelle que la valeur des architectures data dépend de l'adoption par les métiers, pas de la technologie déployée. Beaucoup d'investissements data ne génèrent pas de ROI mesurable.
C'est une évidence que le marché oublie à chaque cycle technologique. Le data mesh n'y échappe pas.
Le piège de l'adoption « outil-first »
Thoughtworks publie régulièrement des retours d'expérience nuancés sur le data mesh, soulignant les échecs liés à une adoption outil-first. Les éditeurs eux-mêmes le disent : SAP, Microsoft, Google Cloud et Databricks documentent tous le data mesh comme un modèle organisationnel, pas comme un produit.
Microsoft insiste sur la nécessité d'une plateforme self-service et d'une gouvernance outillée (Purview) avant tout déploiement. Google Cloud met en garde contre la complexité opérationnelle si les équipes ne sont pas prêtes. Databricks précise que le data mesh est un modèle organisationnel au-dessus du lakehouse, pas un produit.
Le message est unanime chez les éditeurs. Il est pourtant massivement ignoré chez les acheteurs.
Les quatre piliers du data mesh — et ce qu'ils exigent vraiment
- Propriété par les domaines : les équipes métier possèdent leurs données, pas la DSI. Cela suppose des rôles, des responsabilités, des compétences data dans les métiers.
- Data products : chaque jeu de données est traité comme un produit, avec un propriétaire, un cycle de vie, des consommateurs identifiés. Cela suppose une discipline de gestion produit.
- Plateforme self-service : les domaines doivent pouvoir publier et consommer sans dépendre de la DSI. Cela suppose un investissement plateforme lourd et durable.
- Gouvernance fédérée : des règles communes, appliquées localement. C'est le pilier le plus souvent sous-estimé selon Gartner.
À retenir
- Le data mesh est un changement organisationnel, pas un achat logiciel (Dehghani, Thoughtworks).
- Gartner alerte sur les abandons d'initiatives mal préparées d'ici 2026.
- Forrester pointe la faible maturité en data product management.
- IDC constate que plus de la moitié des budgets data partent en intégration.
- McKinsey rappelle que la valeur dépend de l'adoption métier, pas de la technologie.
- Le chiffre « 7 sur 10 » du titre n'a pas de source primaire vérifiable : à manier avec précaution.
Le contexte réglementaire européen ne pardonne pas l'improvisation
En Europe, le Data Governance Act et le Data Act encadrent la gouvernance et le partage des données. En France, la CNIL publie des recommandations sur la gouvernance des données et le RGPD qui conditionnent les architectures data : traçabilité, minimisation, responsabilités.
Un data mesh mal gouverné, c'est-à-dire sans gouvernance fédérée outillée, expose l'entreprise à des risques de conformité. La décentralisation sans cadre n'est pas une architecture : c'est un pari.
Le retour de balancier est déjà là
Les entreprises qui ont empilé des outils sans maturité data réévaluent leur ROI. Le mouvement est visible : retour à des approches plus pragmatiques — data fabric, lakehouse gouverné — et consolidation des plateformes autour de la gouvernance et de la sémantique métier.
SAP positionne son Business Data Fabric (Datasphere) comme alternative ou complément au data mesh, en insistant sur la sémantique métier. Ce n'est pas un hasard : le marché demande de la gouvernance, pas de la décentralisation décorative.
« Le data mesh est un changement organisationnel et culturel, pas un achat logiciel ; il repose sur les domaines, les data products et la gouvernance fédérée. »
— Zhamak Dehghani, créatrice du concept de Data Mesh, Thoughtworks, livre « Data Mesh » (O'Reilly)
Ce que le dirigeant doit retenir
Avant de signer un programme data mesh, trois questions méritent une réponse honnête :
- Vos domaines métier sont-ils prêts à porter la responsabilité de leurs données ? Pas seulement à les consommer.
- Disposez-vous d'une plateforme self-service réellement opérationnelle, ou d'un catalogue d'outils ?
- Mesurez-vous l'usage réel de vos data products, ou seulement leur déploiement ?
Si la réponse est non à l'une de ces questions, le data mesh n'est pas un projet : c'est une dépense. Et le chiffre « 7 sur 10 » — qu'il soit exact ou non — décrit une réalité que les analystes confirment : trop d'entreprises paient une architecture qu'elles n'exploitent pas.
La bonne nouvelle : ce n'est pas une fatalité. C'est une question de séquencement.
Retour aux articles