Gouvernance fédérée et RGPD : le data product qui vous expose

Le data mesh repose sur un principe puissant : la federated computational governance. Plutôt qu'un comité central qui valide tout, chaque domaine devient responsable de ses data products, dans un cadre commun défini collectivement et appliqué automatiquement par la plateforme.

Ce principe est excellent pour la vitesse et l'autonomie. Il crée pourtant un paradoxe redoutable côté conformité : le RGPD, lui, ne se fédère pas. Le responsable de traitement reste une entité juridique unique, soumise à des obligations globales — licéité, minimisation, limitation des finalités, sécurité. Distribuer la propriété opérationnelle de la donnée sans distribuer correctement les garde-fous réglementaires revient à multiplier les points où la conformité peut décrocher sans que personne ne s'en aperçoive.

Le consultant data mesh est au cœur de ce paradoxe : c'est lui qui conçoit le modèle de gouvernance fédérée. Si ce modèle laisse des angles morts RGPD, la cause racine remonte à sa recommandation.

La distribution de la donnée par domaines fait naître des défaillances de conformité spécifiques, rarement anticipées dans les ateliers d'architecture.

• La perte de finalité. Une donnée personnelle collectée pour une finalité (par exemple, la facturation) est exposée comme data product réutilisable. Un autre domaine la consomme pour du marketing. La finalité initiale est trahie : violation du RGPD, sans qu'aucune ligne de code ne soit en faute.
• La minimisation contournée. Pour rendre un data product « riche » et attractif, une équipe domaine y inclut tous les champs disponibles, dont des données sensibles ou inutiles aux consommateurs. La logique produit pousse à la sur-exposition, à l'inverse du principe de minimisation.
• Le contrôle d'accès éclaté. Chaque domaine gère ses droits. Sans gouvernance centrale des accès, un consommateur peut accumuler, data product après data product, une vue agrégée de données personnelles qu'aucun domaine n'a jamais autorisée globalement.

Ces trois défaillances ont un point commun : elles ne sont pas des bugs, mais des conséquences d'un modèle de gouvernance. C'est-à-dire d'un livrable de conseil.

Imaginons une fuite : un data product exposant des données clients est consommé par un domaine non habilité, et une donnée personnelle se retrouve hors de son périmètre légitime. La CNIL est saisie, ou le client subit une réclamation. Le client mène une analyse de cause racine et conclut que le modèle de gouvernance fédérée ne prévoyait aucun contrôle d'accès transverse ni de mécanisme de propagation de la finalité.

À cet instant, le consultant qui a conçu ce modèle devient une cible. Le préjudice est double : d'un côté, le coût direct de l'incident (notification, remédiation, éventuelle sanction côté client) ; de l'autre, le préjudice immatériel imputé à un défaut de conseil. C'est une zone où deux couvertures se rejoignent.

La cyber-assurance intervient sur le volet incident de sécurité et données personnelles, tandis que la RC Pro couvre la faute de conseil reprochée. Pour un consultant data mesh manipulant en permanence des architectures qui touchent à la donnée personnelle, ces deux briques sont complémentaires, pas redondantes.

La bonne pratique, et la meilleure protection, consiste à faire descendre la conformité dans la définition même de chaque data product. C'est l'esprit de la computational governance : ce qui est déclaré dans des slides n'est pas appliqué ; ce qui est codé dans le contrat du data product l'est automatiquement.

Concrètement, le contrat d'un data product peut porter : la classification des données (personnelle, sensible, anonymisée), la finalité autorisée, la politique d'accès, la durée de conservation, les règles de masquage. La plateforme refuse alors mécaniquement un data product qui exposerait des données sensibles sans masquage, ou un consommateur dont la finalité ne correspond pas à celle déclarée.

Une exigence RGPD écrite dans une note de gouvernance est un vœu. La même exigence inscrite dans le contrat du data product et vérifiée par la plateforme est une garantie. Le consultant doit viser la seconde.

Pour le consultant, recommander ce niveau d'automatisation a un double effet : il protège réellement le client, et il documente que la conformité faisait partie intégrante de votre conception. En cas de litige, c'est la preuve que le RGPD n'a pas été un angle mort de votre mission.

Un consultant data mesh n'est pas le délégué à la protection des données du client. Cette distinction est essentielle pour cadrer votre responsabilité. Votre rôle est d'outiller la conformité dans l'architecture : prévoir les mécanismes de classification, d'accès, de propagation de finalité. La qualification juridique des traitements et leur licéité relèvent du DPO.

Le danger survient quand cette frontière n'est écrite nulle part. Le client, après un incident, soutiendra volontiers que « le consultant data devait s'assurer de la conformité ». Bornez donc votre livrable : précisez que vous fournissez les capacités techniques de gouvernance, et que la définition des finalités, des bases légales et des durées relève du responsable de traitement et de son DPO.

Cette clarté contractuelle ne supprime pas votre exposition — un mécanisme technique défaillant reste votre responsabilité — mais elle empêche que la totalité du risque RGPD du client glisse sur vos épaules.

L'article 25 du RGPD impose la protection des données dès la conception et par défaut. Pour un consultant data mesh, ce texte est à double tranchant. Mal compris, il sert d'angle d'attaque au client : « la protection devait être intégrée dès la conception, et vous étiez le concepteur ». Bien anticipé, il devient au contraire la preuve de votre sérieux.

Concrètement, le privacy by design appliqué au data mesh se traduit par des choix d'architecture précis : pseudonymisation des identifiants directs dans les data products de seconde main, masquage par défaut des champs sensibles, accès restreint au strict nécessaire (privilège minimal), et journalisation des consommations pour permettre l'audit. Ces mécanismes ne sont pas optionnels : ils matérialisent une obligation légale.

• Par défaut. Un data product ne doit pas exposer plus que le minimum nécessaire sans action explicite : la richesse se demande, elle ne se subit pas.
• Dès la conception. Les contrôles sont câblés dans le contrat du data product, pas ajoutés après coup en correctif.
• Auditable. Chaque accès laisse une trace, condition de la démonstration de conformité exigée par le principe d'accountability.

En recommandant explicitement ces dispositifs, vous remplissez votre devoir de conseil et vous constituez la preuve que la conformité était au cœur de votre conception. C'est exactement ce qu'un assureur cherche dans un dossier pour le défendre.

Le consultant data mesh a une particularité : la donnée personnelle est au cœur de presque toutes ses missions. Il ne la traite pas lui-même, mais il conçoit les architectures qui décideront, à grande échelle, de la manière dont elle circule. Son profil de risque combine donc faute de conseil et incident de sécurité.

Une couverture cohérente associe une RC Pro robuste sur le volet conseil et architecture, et une garantie cyber pour les incidents touchant aux données personnelles dont votre conception pourrait être jugée la cause. Vérifiez en particulier la couverture des dommages immatériels et des frais de défense, qui constituent l'essentiel du coût réel d'un litige RGPD.

Notre fiche métier consultant data mesh détaille les garanties adaptées à ce profil et un tarif tenant compte de la taille des programmes que vous accompagnez.