Le data mesh distribue la propriété des données aux métiers, mais l'accountability RGPD reste, elle, non négociable. Voici une méthode pour concilier les deux, avec une matrice de responsabilités type.
La promesse du data mesh est connue : sortir la donnée analytique du silo d'une équipe centrale pour la confier aux domaines métier, chacun responsable de ses propres produits de données. S'inspirant des principes du Domain-Driven Design, le data mesh distribue la propriété des données entre différents domaines, les équipes analytiques centralisées cédant la place à des équipes orientées domaine responsables de la gestion et du traitement de leurs données, qui peuvent collaborer sur des activités transverses sous la supervision d'une équipe globale.
Mais en 2026, le bilan de cette approche est plus nuancé que le discours initial. La plupart des organisations qui ont annoncé des transformations data mesh n'ont pas livré la vision complète théorisée par Zhamak Dehghani, mais la plupart ont conservé les parties utiles - propriété par domaine, produits de données comme unité de gouvernance, standards fédérés - en abandonnant discrètement les aspects les plus dogmatiques. C'est précisément sur ce point que se joue la compatibilité avec le RGPD : décentraliser la production et l'usage de la donnée, oui ; décentraliser la responsabilité juridique du traitement, non.
Le constat des directions data est sans appel. 76 % des responsables data estiment que leur gouvernance ne suit pas le rythme d'adoption de l'IA, selon l'étude CDO Insights 2026 de Deloitte et Informatica. Cette tension s'explique en grande partie par l'architecture : plus les données circulent entre domaines, plateformes et outils d'IA, plus il devient difficile de savoir qui est responsable de quoi, et de le démontrer en cas de contrôle.
Le RGPD ne connaît pas le data mesh. Il connaît le responsable de traitement, le sous-traitant, et un principe structurant : l'accountability. L'esprit du texte tient en un basculement d'un contrôle a priori, où la CNIL vérifiait avant, à un contrôle a posteriori fondé sur la responsabilité, où l'organisation s'auto-organise et rend des comptes en cas de contrôle. Concrètement, l'article 24.1 impose que le responsable du traitement mette en œuvre des mesures techniques et organisationnelles appropriées pour s'assurer et être en mesure de démontrer que le traitement est effectué conformément au règlement. Deux conséquences directes pour une organisation qui décentralise sa donnée :
La pression réglementaire s'est nettement accentuée. En 2026, avec 87 sanctions CNIL prononcées en 2025, soit une hausse de 107 % par rapport à 2024, et un durcissement massif des contrôles, tenir un registre des traitements exhaustif et à jour n'est plus une option. Les motifs de sanction récurrents recoupent directement les angles morts classiques d'une architecture décentralisée mal gouvernée : durée de conservation excessive, défaut de sécurité, information insuffisante, registre incomplet, analyse d'impact absente ou relation mal encadrée avec un sous-traitant.
Le risque financier est loin d'être symbolique : l'absence de registre expose à des amendes allant jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial. Dans une architecture mesh où dix, vingt ou cinquante domaines produisent et consomment des données personnelles, c'est bien l'entreprise dans son ensemble, et non le domaine fautif, qui porte ce risque.
La littérature sur le data mesh propose une réponse précise à cette tension : la gouvernance fédérée computationnelle. L'idée n'est pas de recréer un comité central qui valide chaque décision, mais d'encoder les règles communes dans la plateforme elle-même. Un groupe de gouvernance transverse aux domaines fixe des standards - interopérabilité, sécurité, confidentialité, classification - qui sont appliqués de façon computationnelle, via des politiques imposées par la plateforme, plutôt que par des réunions de comité.
Cette approche se retrouve dans les outillages du marché. Certaines plateformes de catalogage sont désormais pensées nativement pour ce modèle : leur architecture est pensée pour une gouvernance fédérée par domaines, avec des glossaires, politiques et produits de données par domaine, ce qui les rend pertinentes pour les organisations adoptant une logique de data mesh. D'autres solutions, davantage taillées pour les secteurs régulés, intègrent directement les cadres réglementaires : elles offrent un moteur de gouvernance complet pour les grandes entreprises régulées, avec des modèles de politiques préétablis pour des cadres comme BCBS 239, RGPD ou HIPAA.
Le document technique que l'on fait porter cette gouvernance s'appelle le data contract. Le principe du « juste assez », une gouvernance légère ajustée sur les risques réels, fait des data contracts l'instrument central de la responsabilisation dans une gouvernance distribuée. Un data contract bien construit embarque, pour chaque produit de données, sa base légale, ses catégories de données, ses règles de conservation et ses conditions d'accès — autant d'éléments directement réutilisables pour alimenter le registre des traitements central.
Doctolib illustre concrètement cette bascule. L'entreprise a déployé une architecture mesh à grande échelle, avec une console Data Mesh sur-mesure permettant d'explorer en temps réel les 222 Data Products actuellement déployés, d'analyser le lineage de la donnée et de gérer le cycle de vie des souscriptions. Pour tenir ce niveau de décentralisation sans perdre la maîtrise réglementaire, l'entreprise a fait un choix d'architecture explicite : combiner l'industrialisation de la gouvernance et l'adaptation de l'architecture aux exigences de produits IA natifs, via une stratégie de « platformization » de la conformité RGPD, ISO 27001 et HDS, dont l'objectif est d'extraire la logique de compliance du code applicatif pour l'intégrer directement aux frontières de la plateforme.
Ce cas illustre le principe clé : la conformité ne doit pas dépendre de la discipline individuelle de chaque équipe de domaine, mais être imposée structurellement par la plateforme sur laquelle ces équipes travaillent. C'est ce qui permet de concilier vitesse de livraison des domaines et traçabilité centralisée exigée par le régulateur.
Dans nos missions de cadrage chez les clients qui engagent une transformation de ce type (voir notre offre de conseil en gouvernance data), la première étape concrète consiste à formaliser une matrice de responsabilités croisant les rôles data mesh et les obligations RGPD. Elle distingue quatre familles d'acteurs :
Cette matrice doit être adossée à un registre des traitements unique, alimenté automatiquement par les métadonnées des data contracts de chaque domaine plutôt que remplie manuellement en fin de projet. C'est la seule façon de concilier l'autonomie opérationnelle promise par le mesh et l'exigence de démonstration permanente du RGPD. Le guide de la CNIL sur le registre des activités de traitement détaille d'ailleurs précisément le contenu attendu : nom et coordonnées du responsable et du délégué, finalités, catégories de personnes concernées et de données. Autant de champs qui peuvent, et devraient, être générés depuis les contrats de données des domaines plutôt que reconstitués a posteriori.
Le data mesh n'est pas une solution universelle, et son adoption exige des prérequis organisationnels forts. Il fonctionne lorsque l'organisation dispose d'une capacité d'ingénierie data et logicielle importante, car une véritable démarche mesh exige que chaque équipe de domaine ait des compétences d'ingénierie data. Sans cette maturité technique dans les domaines métier, la décentralisation de la gouvernance se traduit souvent par une multiplication des angles morts réglementaires plutôt qu'une amélioration de l'agilité.
Autre point de vigilance qui monte en puissance en 2026 : l'essor des agents IA complique encore la traçabilité. Les risques identifiés incluent la fuite de données sensibles vers des services tiers non contractualisés, la violation des réglementations RGPD, sectorielles ou contractuelles, des décisions prises sur des données non qualifiées sans traçabilité ni auditabilité, la prolifération de silos et l'impossibilité de gouverner ce qui n'est pas visible. Un domaine qui expose ses données à un agent d'IA générative sans contrat de données explicite crée un trou dans la chaîne de responsabilité, invisible tant qu'un contrôle CNIL ou un incident ne le révèle pas.
Avant d'engager une transformation data mesh, il est donc préférable de cartographier précisément les flux de données personnelles existants et de valider la maturité des équipes de domaine sur les fondamentaux de la gouvernance, plutôt que de décentraliser d'emblée l'ensemble du périmètre analytique. Nos équipes accompagnent ce diagnostic initial dans le cadre de missions de cadrage courtes — n'hésitez pas à nous contacter pour en discuter.
La compatibilité entre data mesh et RGPD repose sur une distinction simple mais structurante : les domaines métier peuvent gagner en autonomie sur la production, la qualité et l'exposition de leurs produits de données, mais la responsabilité juridique du traitement, elle, reste centralisée et incompressible. La gouvernance fédérée computationnelle, matérialisée par des data contracts et une plateforme qui impose les règles plutôt que de les suggérer, est le mécanisme qui permet de tenir les deux objectifs simultanément. C'est un chantier d'architecture autant que de gouvernance, qui mérite d'être cadré avant tout déploiement technique à grande échelle.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus