Le Data Mesh, plus que jamais d’actualité à l’ère de l’IA agentique

L’approche Data Mesh s’impose comme à un prérequis à l’industrialisation de l’IA

Une gestion exclusivement centralisée, au contraire, induit une déconnexion entre les données et leur contexte. Cela dégrade la qualité des métadonnées, poursuit-il. Ce déficit en matière de documentation des données rendrait caduque toute tentative d’interfacer des grands modèles de langage et des bases de données relationnelles.

Par ailleurs, les éditeurs de plateformes de données ont épousé les préceptes du Data Mesh et du DevOps. Des éléments qui influencent leur manière d’intégrer l’IA dans leurs produits, en premier lieu le « Talk-to-Data ». Rappelons qu’ils ont lutté à mettre en place avant l’avènement de ChatGPT. En outre, l’exposition directe des agents IA aux systèmes transactionnels représente un risque que toutes les entreprises ne sont pas prêtes à prendre. Travailler sur des copies de données (appelons un chat un chat) mises en qualité apparaît dès lors comme l’alternative la plus raisonnable.

À lire également :

Projets IA : pourquoi les contrats de données devraient être incontournables

L’intelligence artificielle représente ainsi un « coût d’opportunité ». Elle exige un patrimoine documenté avant toute phase d’automatisation. Cette nécessité impose, d’après le spécialiste, une transition vers des architectures organisationnelles où la responsabilité vis-à-vis de la donnée est ancrée dans l’expertise métier. Une opinion déjà partagée par des entreprises comme La Centrale, AG2R La Mondiale ou Décathlon.

La première étape de la mise en place de la philosophie Data Mesh consiste généralement à délimiter les domaines de données dans l’entreprise. Gaëlle Seret, experte Data en free-lance et ex-« enabler » Data Mesh chez Décathlon, souligne la nécessité de dissocier les structures organisationnelles des domaines fonctionnels réels.

L’illustration de la SNCF fournie par Pierre-Yves Bonnefoy permet de comprendre cette distinction. L’objet « Gare » constitue un point d’infrastructure du réseau ferré, mais également un point de vente pour le commerce et un point horaire pour la circulation.

La cohérence du système repose sur un arbitrage central opéré par l’urbanisme. Il définit un identifiant unique géré par le domaine d’infrastructure, lequel est ensuite enrichi par les autres domaines selon leurs besoins spécifiques.

Pour résoudre les frictions liées à la définition des domaines, la méthodologie dite du triple diamant peut s’appliquer. Elle se compose d’une phase de compréhension du besoin, suivie d’une étape de négociation pour déterminer quel domaine détient la responsabilité légitime de la donnée, avant de conclure par l’industrialisation.

Cette phase de négociation ne devrait pas prendre fin après les préparatifs d’un projet de Data Mesh. Elle serait la clé pour éviter la création de nouveaux silos de données. La mise en place de domaines ne consiste pas à figer des frontières par décret, mais à entraîner les équipes à négocier ces limites en continu, insiste Gaëlle Seret.

Des données aux produits de données, une histoire de livraison

L’approche Data Mesh vise in fine à transformer des données brutes en produits finis, orientés vers l’utilisateur final. Najate Bouad, responsable ingénierie de la plateforme de données sportives et du référentiel produit chez Decathlon Digital, décrit ce processus comme une réponse précise à des usages identifiés, tels que la segmentation client chez un distributeur d’articles de sport.

Trois types de produits de données peuvent être catégorisés : ceux alignés sur les sources, les produits agrégés et enfin les produits alignés sur la consommation (ou le consommateur de ces données).

Les trois experts du Data Mesh, qui intervenaient en mars 2026 lors du DIMS, sommet organisé par Innovation Makers Alliance, insistent sur le respect d’une règle. Les produits alignés sur le consommateur ne doivent pas dépendre directement d’autres produits de même nature. Ils s’appuient plutôt sur des produits alignés sur la source ou des produits agrégés.

Cette contrainte éviterait les interprétations fragmentées et préserve une couche sémantique cohérente, et cela conformément aux principes décrits par Eric Evans, auteur d’un ouvrage de référence sur le Domain-Driven Design publié en 2003.

La création d’un « Data Product » nécessite de définir ses consommateurs, qu’il s’agisse d’équipes CRM ou de vendeurs en magasin, par exemple. Pour garantir l’utilité opérationnelle, la livraison de données doit être multimodale. Il peut s’agir de déployer une API pour une consultation quotidienne par les vendeurs dans leur application métier et de maintenir des tables au sein de bases de données relationnelles pour les analyses marketing en SQL.

Par ailleurs, un Data Product s’accompagne d’engagements de service (SLAs) stricts. Ils garantiront, par exemple, que 100 % des clients sont segmentés de manière fiable. De plus, Najate Bouad définit l’actif « Data » comme un jeu de données autonome.

Un produit de données répond à des besoins précis et est doté d’un cycle de vie propre (versioning, maintenance, date de fin…). Ces engagements de production et de livraison ont pour but d’assurer la pérennité des cycles de vie des données et leur accessibilité réelle pour les métiers.

Gouvernance fédérée et plateforme leviers de l’interopérabilité

Les adeptes de l’approche Data Mesh prônent la décentralisation de la gestion de données, pas l’absence de contrôle. Au contraire. Sa mise en place exige des mécanismes de contrôle standardisés pour établir et maintenir l’interopérabilité. Néanmoins, ceux-ci doivent opérer comme des accélérateurs de services plutôt que comme des entraves bureaucratiques.

Le contrat de données, ou « Data Contract », sert d’interface de discussion technique entre domaines pour fixer les normes de qualité et les droits d’accès. En parallèle, la plateforme technologique doit agir comme un accélérateur de services et non comme un simple catalogue d’outils disparates.

L’échec des plateformes de données provient souvent de leur conception comme un supermarché technologique complexe. La performance d’une plateforme se mesure à sa capacité à réduire le « Time to First Value » pour les nouveaux produits. C’est son indicateur clé de performance principal.

La complexité des environnements de gestion de données, comme leur absence d’accessibilité par des profils non experts, entraîne un faible taux d’adoption et favorise le Shadow IT chez les métiers. Les utilisateurs pourront ainsi avoir tendance à extraire les données de la plateforme pour les réintégrer ensuite à leurs propres outils.

Pierre-Yves Bonnefoy rappelle que le soutien de la direction est la condition sine qua non du modèle Data Mesh.

Sans une volonté politique de partage et de collaboration entre les domaines, l’architecture organisationnelle s’effondre, jugent les professionnels cités dans cet article. La plateforme doit donc simplifier l’expérience utilisateur pour les profils non techniques afin de devenir un levier d’adoption global.

Les bonnes pratiques pour un déploiement à l’échelle

Le passage à l’échelle du Data Mesh repose sur une hiérarchie stricte des priorités où la technologie demeure secondaire par rapport à la délégation de l’architecture. Rôles et responsabilités sont capitaux.

La transformation réussie, souligne Gaëlle Seret, nécessite de combiner culture, méthodes et outils. Et le rôle des dirigeants est déterminant dans cette transition. Ils portent la responsabilité d’allouer aux équipes le temps nécessaire à la construction d’un langage commun et à la documentation du patrimoine.

Le principal goulet d’étranglement réside d’ailleurs bien souvent dans la capacité des décideurs à comprendre les enjeux de propriété et de contrats d’interface. La formation des dirigeants est donc plus critique que l’investissement technique pour éviter que les domaines ne redeviennent des citadelles imprenables.

La pérennité du modèle, telle qu’analysée lors du DIMS 2026, dépend in fine de la capacité à faire évoluer une organisation monolithique en un écosystème où chaque domaine est comptable de la qualité de ses actifs.

En stabilisant leurs fondations Data, les entreprises peuvent, en principe, sécuriser leur trajectoire vers une automatisation pilotée par l’intelligence artificielle. Elles transforment aussi les données distribuées en moteur pour des stratégies à long terme. En cela, la décentralisation organisationnelle pourrait influencer l’évolution des architectures techniques. Par exemple, l’Agentic Mesh est présenté comme un maillage de plusieurs agents IA capables de collaborer de manière autonome sous une gouvernance partagée.

Actuellement, si l’approche Data Mesh induit une décentralisation organisationnelle, les entreprises (et les éditeurs) s’appuient généralement sur des environnements techniquement distribués, gérés de manière centralisée, segmentés par instance et par rôle. Or, le maintien de la cohérence sémantique entre outils (voire à l’intérieur d’une seule et même plateforme) demeure un chantier en cours.