Architecture de maillage de données : données décentralisées pour l'entreprise

L’entrepôt de données centralisé constitue l’architecture de données dominante de l’entreprise depuis 30 ans. Dans ce modèle, une équipe centrale d'ingénierie des données est propriétaire de l'infrastructure de données de l'entreprise : elle ingère les données des systèmes sources, les nettoie et les transforme, et les transmet aux consommateurs via un entrepôt central ou un lac de données. Les équipes métier demandent de nouvelles données, attendent que les équipes centrales les fournissent et acceptent les décisions prioritaires prises par une seule équipe centrale pour tous les besoins en données de l'organisation.

Ce modèle fonctionnait raisonnablement bien lorsque les volumes de données étaient gérables, les sources de données étaient limitées et le rythme des changements commerciaux était plus lent. Il échoue gravement dans les environnements d'entreprise modernes caractérisés par des milliers de sources de données, des dizaines de cas d'utilisation d'analyses en concurrence pour la bande passante de l'équipe centrale et des équipes commerciales nécessitant un accès aux données mesuré en jours plutôt qu'en trimestres.

Le maillage de données est la réponse architecturale et organisationnelle à ces limitations. Plutôt que de centraliser la propriété des données au sein d'une équipe de plateforme, il distribue la propriété aux domaines métier qui connaissent le mieux les données, c'est-à-dire les équipes qui les produisent. Plutôt que de traiter les données comme un sous-produit des opérations, elle les traite comme un produit avec des consommateurs, des normes de qualité et des niveaux de service.

Points clés à retenir

• Le maillage de données distribue la propriété des données aux équipes de domaine plutôt que de les concentrer dans une équipe de données centrale
• Les quatre principes : propriété de domaine, données en tant que produit, infrastructure de données en libre-service et gouvernance informatique fédérée
• Le maillage de données résout les problèmes d'évolutivité, de qualité et d'agilité des architectures de données centralisées
• La mise en œuvre nécessite à la fois un investissement en plateforme technique et un changement organisationnel important
• La plate-forme d'infrastructure de données en libre-service constitue la base technique. Sans elle, les équipes du domaine ne peuvent pas posséder efficacement les données.
• La gouvernance fédérée garantit la cohérence et la conformité sans recréer des goulots d'étranglement centraux
• Le maillage de données n'élimine pas les équipes de données centrales : il transforme leur rôle de producteur en fournisseur et facilitateur de plateforme.
• La plupart des organisations devraient mettre en œuvre le maillage de données progressivement, en commençant par les domaines les plus problématiques.

---

Le problème des architectures de données centralisées

Pour comprendre pourquoi le maillage de données a suscité autant d’intérêt dans les entreprises, vous devez comprendre les problèmes spécifiques des architectures centralisées à grande échelle.

Le goulot d'étranglement de l'équipe centrale

Dans un modèle centralisé, l'équipe d'ingénierie des données est propriétaire de tous les pipelines de données. L'intégration de chaque nouvelle source de données nécessite un effort d'équipe central. Chaque nouveau cas d'utilisation de l'analyse nécessite du temps de développement par une équipe centrale. Chaque problème de qualité des données doit être diagnostiqué et résolu par l'équipe centrale.

À mesure que l’organisation se développe et que les cas d’utilisation des données prolifèrent, l’équipe centrale devient un goulot d’étranglement. Les équipes commerciales attendent 2 à 6 mois pour les intégrations de données. Les problèmes de qualité des données ne sont pas résolus car les équipes centrales ne disposent pas de contexte de domaine pour diagnostiquer les causes profondes. Les initiatives d'analyse sont retardées par des travaux d'infrastructure de données qui entrent en concurrence avec d'autres priorités.

La file d’attente augmente plus vite que l’équipe ne peut grandir. L'ajout d'ingénieurs de données plus centraux ne résout pas le problème fondamental : cela ralentit temporairement le goulot d'étranglement tandis que le problème architectural sous-jacent demeure.

Lacune en matière d'expertise dans le domaine

L’équipe centrale de données sait comment créer des pipelines. Ils ne connaissent pas la sémantique métier des données qu’ils traitent. Que signifie un « client » dans le contexte du domaine des ventes par rapport au domaine des services ? Qu'est-ce qui constitue une commande « terminée » dans le domaine de l'exécution ? Quelle est la règle correcte de comptabilisation des revenus pour les ventes de produits par abonnement ?

Les experts du domaine – les équipes commerciales qui produisent les données – possèdent ces connaissances. Ce n’est pas le cas de l’équipe centrale. Ce déficit d'expertise produit des problèmes de qualité des données qui sont difficiles à diagnostiquer et à résoudre, car les réparateurs manquent de contexte pour comprendre les erreurs.

Incohérence et faible confiance

À mesure que les différentes équipes élaborent leurs propres solutions de contournement (extraire les données directement des systèmes sources, créer des magasins de données locaux, gérer les feuilles de calcul au niveau des services), la « source unique de vérité » centrale se fracture. Plusieurs versions de mesures telles que « revenu » et « client actif » prolifèrent au sein des équipes, avec des différences de définition légères mais conséquentes.

Les dirigeants d’entreprise cessent de faire confiance aux données, s’en remettent à leur intuition et résistent à la prise de décision fondée sur les données, non pas parce qu’ils rejettent le concept, mais parce que les données ne sont pas fiables.

---

Les quatre principes du maillage de données

Zhamak Dehghani, qui a inventé le terme « maillage de données » en 2019 alors qu'il travaillait chez ThoughtWorks, l'a défini à travers quatre principes.

Principe 1 : Propriété du domaine des données

Dans le maillage de données, les domaines métiers sont propriétaires de leurs données : production, qualité et publication. Le domaine des ventes possède les données de vente. Le domaine de la chaîne d’approvisionnement possède des données d’inventaire et d’exécution. Le domaine client possède le profil client et les données d’engagement.

La propriété du domaine signifie : l'équipe du domaine est responsable de la qualité des données qu'elle publie, de l'infrastructure de pipeline qui les produit et des niveaux de service qu'elle s'engage à fournir aux consommateurs. Lorsque les données sont erronées, l'équipe du domaine les corrige : elle a à la fois la responsabilité et l'expertise du domaine pour le faire.

Cela ne signifie pas que chaque équipe de domaine devient une équipe d'ingénierie de données. La plate-forme d'infrastructure de données en libre-service (Principe 3) fournit les outils qui rendent la propriété de domaine pratique sans nécessiter une expertise approfondie en ingénierie des données dans chaque domaine.

Principe 2 : Les données en tant que produit

Dans le maillage de données, les données sont traitées comme un produit – avec des consommateurs, des normes de qualité, de la documentation et des niveaux de service, comme n'importe quel autre produit.

Un produit de données est un actif de données limité qui :

• A une propriété claire (l'équipe du domaine)
• Est détectable (les consommateurs peuvent le trouver via un catalogue de données)
• Est documenté (les consommateurs comprennent ce qu'il contient et comment l'utiliser)
• Possède des normes de qualité (l'exactitude, l'exhaustivité et l'actualité sont mesurées et maintenues)
• Dispose de niveaux de service définis (fraîcheur, disponibilité, latence d'accès)
• Possède une interface clairement définie (les consommateurs accèdent aux données via des API ou des interfaces de requête définies, et non en accédant aux systèmes sources)

La mentalité « produit » change la façon dont les équipes de domaine perçoivent les données qu'elles publient. Un pipeline de données est un détail d'implémentation ; un produit de données est quelque chose qui sert les consommateurs et doit être maintenu. Ce changement de cadre entraîne des comportements différents en matière de qualité et de fiabilité.

Principe 3 : Infrastructure de données en libre-service

La propriété des données par domaine n'est pratique que si les domaines disposent d'outils qui rendent accessibles le développement de pipelines de données, la surveillance de la qualité et la publication de produits de données sans nécessiter une expertise spécialisée en ingénierie des données.

La plateforme d'infrastructure de données en libre-service fournit :

• Outils de pipeline de données : développement de pipeline low-code ou basé sur la configuration que les ingénieurs de domaine peuvent utiliser sans expertise approfondie en ingénierie de données.
• Cadres de qualité des données : tests de qualité automatisés, détection des anomalies et tableaux de bord de niveau de qualité que les domaines peuvent configurer et surveiller
• Intégration du catalogue de données : enregistrement automatique des nouveaux produits de données dans le catalogue de données d'entreprise avec extraction de métadonnées
• Contrôle d'accès : gestion des accès basée sur des politiques que les domaines peuvent configurer sans intervention informatique
• Interfaces de consommation : interfaces de requête standardisées (SQL, API) que les consommateurs peuvent utiliser quel que soit le domaine qui a produit les données
• Surveillance et observabilité : surveillance de l'état du pipeline, tableaux de bord de fraîcheur des données et alertes indiquant que les équipes de domaine peuvent fonctionner

La construction de cette plateforme constitue le principal investissement technique dans le maillage de données. Sans cela, le maillage de données décentralise les responsabilités sans permettre la capacité – une recette pour le chaos plutôt que pour l’autonomisation.

Principe 4 : Gouvernance informatique fédérée

Décentraliser la propriété des données ne signifie pas abandonner la gouvernance. Le maillage de données utilise une gouvernance fédérée – des normes définies de manière centralisée que les domaines appliquent localement.

La fonction centrale de gouvernance définit : les normes de qualité des données, les politiques de sécurité et de confidentialité, les normes d'interopérabilité (formats de données communs, normes d'identification), les exigences de conformité réglementaire et le schéma du catalogue de données auquel tous les produits de données doivent se conformer.

Les domaines mettent en œuvre ces normes dans leurs produits de données. La fonction de gouvernance vérifie la conformité par l’application automatisée des politiques plutôt que par un examen manuel.

La gouvernance « informatique » signifie que les politiques de gouvernance sont appliquées automatiquement via le code, et non via des processus d'approbation manuels. Les contrôles d'accès sont appliqués par la plateforme ; les normes de qualité des données sont vérifiées par des tests automatisés ; les politiques de sécurité sont appliquées par l’infrastructure. Cela rend la gouvernance évolutive : elle ne nécessite pas qu'une équipe centrale examine manuellement chaque produit de données.

---

Architecture de maillage de données en pratique

Conception de domaines de données

La conception de domaines de données est le premier défi pratique. Les limites des domaines doivent s'aligner sur les limites des domaines métier : des unités organisationnelles avec une responsabilité claire en matière de données et une propriété du contexte métier.

Modèles de conception de domaine courants :

Domaines opérationnels : associez les unités commerciales existantes : ventes, marketing, finances, opérations, ressources humaines, chaîne d'approvisionnement. Chaque domaine est propriétaire des données produites par ses systèmes opérationnels.

Domaine client : les données de profil client agrégées, souvent détenues par une équipe dédiée aux données client, sont un domaine transversal courant.

Domaines d'analyse : certaines organisations créent des domaines analytiques dédiés qui regroupent les données de plusieurs domaines opérationnels à des fins analytiques spécifiques : un domaine Finance Analytics qui combine les données des ventes, des opérations et des finances.

Les limites des domaines doivent être tracées pour minimiser les dépendances entre domaines : lorsqu'une partie importante des données d'un domaine provient d'un autre domaine, les limites peuvent devoir être redessinées.

Anatomie du produit de données

Un produit de données dans une implémentation de maillage de données comprend généralement :

Données d'entrée : données sources des systèmes opérationnels, consommées via des flux d'événements (Kafka), des appels d'API ou la réplication de bases de données.

Code de transformation : logique de pipeline qui transforme les données sources brutes en produit de données publié. Généralement géré sous forme de code dans le contrôle de version avec déploiement CI/CD.

Interface de sortie : forme sous laquelle les données sont servies aux consommateurs : tables dans une couche de requête partagée, points de terminaison d'API, flux d'événements ou vues matérialisées.

Contrats qualité : normes de qualité définies et testées — taux nuls, exigences de fraîcheur, contrôles d'intégrité référentielle, validations de règles métier.

Métadonnées : définitions de schéma, dictionnaires de données, informations de lignage et documentation opérationnelle — automatiquement enregistrés dans le catalogue de données.

Observabilité : surveillance de l'état du pipeline, tableaux de bord de fraîcheur et suivi des scores de qualité.

Choix de plateforme technique

La pile de mise en œuvre du maillage de données varie considérablement selon l'organisation, la plate-forme cloud et les outils existants :

Catalogue de données : Atlan, Collibra, Alation, DataHub (open source), Google Dataplex, AWS Glue Data Catalog. Fournit la couche de découverte pour les produits de données.

Qualité des données : Great Expectations (open source), Monte Carlo, Soda, Anomalo. Tests automatisés de la qualité des données et détection des anomalies.

Orchestration de pipeline : dbt (transformation de données), Apache Airflow, Prefect, Dagster. Les domaines d’outils de transformation de données et d’orchestration de pipelines utilisent pour créer leurs pipelines.

Couche de requête : Databricks Unity Catalog, Snowflake, BigQuery, Amazon Redshift. Couche de requête analytique partagée que les consommateurs utilisent pour interroger des produits de données provenant de plusieurs domaines.

Gestion des accès : Apache Ranger, AWS Lake Formation, Databricks Unity Catalog. Contrôle d'accès basé sur des politiques entre les domaines.

Diffusion d'événements : Apache Kafka, AWS Kinesis, Google Pub/Sub. Interfaces de produits de données en temps réel pour les consommateurs de streaming.

---

Intégration avec Analytics et Power BI

Les architectures de maillage de données fournissent la base de données appartenant au domaine que consomment les équipes d'analyse. L’interface entre le maillage de données et les outils d’analyse est essentielle.

Maillage de données + Power BI

Dans une architecture de maillage de données, Power BI se connecte aux produits de données de domaine via la couche de requête partagée, généralement un Lakehouse (Databricks, Azure Synapse, Microsoft Fabric) ou un entrepôt de données (Snowflake, BigQuery, Redshift).

Les produits de données de domaine sont publiés sous forme de tables ou de vues dans la couche de requête. Les modèles sémantiques Power BI (ensembles de données) sont construits sur ces produits de données de domaine. Les consommateurs de données (analystes, utilisateurs professionnels) créent des rapports sur les modèles sémantiques sans avoir besoin de comprendre quel domaine a produit les données sous-jacentes.

OneLake de Microsoft Fabric est particulièrement bien adapté aux architectures de maillage de données : il fournit une couche de stockage unifiée où les équipes de domaine peuvent publier leurs produits de données, avec une couche de requêtes partagée que Power BI et d'autres outils analytiques consomment. Les espaces de travail au niveau du domaine dans Microsoft Fabric s’alignent naturellement sur les limites des domaines de maillage de données.

Lignée de données pour l'analyse

L'une des fonctionnalités les plus précieuses d'un maillage de données mature est le traçage des données de bout en bout, c'est-à-dire le suivi de l'origine de chaque chiffre dans un rapport d'analyse via les produits de données, les transformations et les systèmes sources.

Lorsqu’un rapport Power BI affiche un chiffre d’affaires inattendu, le lignage des données permet un diagnostic rapide : de quel produit de données provient la mesure des revenus ? Quel domaine en est propriétaire ? Quelle logique de transformation l’a produit ? Quel système source était l’origine ultime ?

Les outils de catalogue de données dotés de fonctionnalités de traçabilité (Atlan, Collibra, DataHub) offrent cette visibilité sur la traçabilité, ce qui rend le dépannage analytique considérablement plus rapide et plus efficace.

---

Transformation organisationnelle

Le maillage de données est autant une transformation organisationnelle que technique. L'architecture technique peut être construite relativement rapidement ; la transformation organisationnelle prend beaucoup plus de temps.

Changements de rôle

Ingénieurs de données dans les équipes centrales : le rôle passe de la création de pipelines de données de production à la création et à la maintenance de la plate-forme d'infrastructure de données en libre-service. Du producteur au constructeur de plateforme. Il s’agit d’une transition de carrière significative qui nécessite une gestion prudente.

Ingénieurs de données dans les équipes de domaine : nouveau rôle : ingénieurs de données de domaine intégrés dans les unités commerciales, créant et gérant des produits de données de domaine. Ils ont besoin à la fois de compétences en ingénierie des données et de connaissances commerciales du domaine.

Analystes de données : le rôle devient plus puissant : grâce à des produits de données de domaine détectables et de haute qualité, les analystes consacrent moins de temps à l'acquisition et au nettoyage des données, et plus de temps à l'analyse. Cela nécessite de développer des compétences analytiques plus solides parallèlement à des compétences en matière de données.

Propriétaires de produits de données : nouveau rôle : membres de l'équipe de domaine qui possèdent la feuille de route du produit de données, gèrent les relations avec les consommateurs et sont responsables des engagements en matière de qualité des données. Semblable à un rôle de chef de produit, appliqué aux données.

Équipe centrale de gouvernance des données : le rôle passe de la correction de la qualité des données à l'établissement et à l'application de normes de gouvernance. De résolveur de problèmes à décideur politique.

Considérations sur la gestion du changement

La propriété des données de domaine est une responsabilité dont les équipes de domaine ne souhaitent pas toujours. "Nous produisons les données ; pourquoi devrions-nous être responsables de l'ingénierie des données ?" est une réaction courante. La réponse nécessite de démontrer que la propriété de domaine donne aux équipes le contrôle de leur propre destin de données (itérations plus rapides, meilleure qualité et dépendance réduite à l'égard des files d'attente centrales) tout en fournissant les outils en libre-service qui les rendent pratiquement gérables.

L’alignement de la haute direction est essentiel. Le maillage de données exige que les dirigeants de domaine acceptent la responsabilité de la qualité des données parallèlement à leurs responsabilités opérationnelles. Sans cet engagement au niveau de la direction, les équipes du domaine résisteront à la responsabilité même si elles veulent le contrôle.

---

Questions fréquemment posées

Le maillage de données est-il adapté aux petites et moyennes entreprises, ou uniquement aux grandes organisations ?

Le maillage de données est particulièrement avantageux pour les organisations où les goulots d'étranglement de l'architecture de données centrale sont à l'origine de véritables problèmes commerciaux : généralement des organisations comptant plus de 10 domaines de production de données importants, des cas d'utilisation d'analyse importants et une équipe de données centrale qui ne peut pas suivre le rythme de la demande. Pour les petites organisations disposant de moins de sources de données et de besoins d’analyse plus simples, un entrepôt de données centralisé et bien structuré peut être plus approprié. Le maillage de données ajoute une complexité organisationnelle et architecturale qui n'est justifiée que lorsque les problèmes qu'il résout limitent réellement les résultats commerciaux.

Combien de temps prend la mise en œuvre d'un maillage de données ?

Un calendrier réaliste de mise en œuvre du maillage de données pour une grande entreprise : 6 à 12 mois pour la création de la plate-forme d'infrastructure de données en libre-service, 12 à 18 mois pour que les 3 à 5 premiers produits de données de domaine soient opérationnels, 24 à 36 mois pour que le programme couvre la plupart des domaines majeurs. L'organisation doit évaluer de manière réaliste le temps nécessaire au renforcement des capacités des équipes de domaine : intégrer des ingénieurs de données dans les équipes de domaine, former les propriétaires de produits de domaine et faire évoluer la culture des équipes de domaine autour de la propriété des données. La transformation organisationnelle complète vers des pratiques de maillage de données prend généralement 3 à 5 ans, avec une valeur significative délivrée au cours de la première année dès les premières implémentations de domaine.

Quelle est la différence entre un lac de données, un entrepôt de données, un lac de données et un maillage de données ?

Un lac de données est un référentiel de stockage qui stocke les données brutes dans leur format natif. Un entrepôt de données est un magasin de données structuré et intégré optimisé pour les requêtes analytiques. Un data Lakehouse combine l'économie de stockage d'un lac de données avec les performances des requêtes et la gouvernance d'un entrepôt de données. Le maillage de données est une approche architecturale et organisationnelle, et non une technologie de stockage : il décrit la manière dont les données sont détenues, produites et gouvernées. Le maillage de données peut être implémenté sur une base technologique de lac de données, d’entrepôt ou de Lakehouse. La plupart des implémentations de maillage de données modernes utilisent un lac de données (Databricks, Microsoft Fabric, Snowflake) comme couche de requête partagée.

Quel est le lien entre le maillage de données et l'architecture de microservices ?

Le maillage de données applique les principes architecturaux des microservices à la gestion des données, en particulier les idées de propriété de domaine, de contexte limité et de déployabilité indépendante. Tout comme les microservices décomposent une application monolithique en services appartenant au domaine, le maillage de données décompose une plate-forme de données centrale en produits de données appartenant au domaine. L'analogie s'étend à la structure organisationnelle : tout comme les microservices appartiennent à des équipes interfonctionnelles comprenant les développeurs, les opérations et la gestion des produits, les produits de données doivent appartenir à des équipes de domaine interfonctionnelles comprenant des ingénieurs de données, des experts de domaine et des propriétaires de produits de données.

Quels sont les échecs de mise en œuvre du maillage de données les plus courants ?

Les modèles d'échec les plus courants : construire la plate-forme libre-service sans investissement suffisant (les domaines sont confiés à des responsabilités sans outils, créant le chaos) ; ne pas parvenir à obtenir l'adhésion des dirigeants du domaine avant de continuer (les équipes du domaine résistent à l'appropriation sans l'engagement organisationnel de la direction) ; traiter le maillage de données comme une pure initiative technologique (en négligeant la gestion du changement organisationnel qui rend la propriété de domaine durable) ; et tenter de mettre en œuvre un maillage de données dans tous les domaines simultanément (la complexité du changement simultané à l'échelle de l'organisation entraîne généralement des échecs de mise en œuvre - en commençant par 2 ou 3 domaines très difficiles et en prouvant que le modèle avant la mise à l'échelle est systématiquement plus efficace).

---

Prochaines étapes

Le maillage de données représente une refonte fondamentale de l'architecture des données d'entreprise qui répond aux limites d'évolutivité, de qualité et d'agilité des modèles centralisés. For organizations experiencing data bottleneck pain, it offers a path to scalable, domain-appropriate data ownership.

Les services Power BI et d'analyse d'ECOSIRE aident les organisations à concevoir et à mettre en œuvre la couche d'analyse qui repose sur les architectures de maillage de données, en connectant les produits de données de domaine aux outils de business intelligence qui fournissent des informations aux décideurs. Notre équipe peut vous conseiller à la fois sur la stratégie d’architecture de données et sur la mise en œuvre d’analyses qui permettent de transformer l’investissement en maillage de données en valeur commerciale.

Contactez notre équipe d'analyse et d'architecture de données pour déterminer si le maillage de données est la bonne approche pour relever les défis liés aux données de votre organisation.