Data Mesh : adopter le paradigme de l’architecture de données décentralisée

– Data Warehouse, Data Lake, Data Lakehouse : forces, limites et raisons de l’essoufflement des approches centralisées
– Enjeux actuels des organisations data-driven : volume, diversité des cas d’usage et passage à l’échelle
– Naissance du Data Mesh : le changement de paradigme proposé par Zhamak Dehghani
– Les 4 piliers du Data Mesh : Domain Ownership, Data as a Product, Self-serve Infrastructure, Federated Governance
– Caractéristiques d’une donnée dans le Data Mesh : accessibilité, auditabilité, disponibilité, intégrité

– Domain-Driven Design (rappels) : bounded contexts, ubiquitous language et leur application aux données
– Domain-Oriented Ownership : décentraliser la responsabilité des données vers les domaines métier
– Alignement entre sources de données et domaines de données : critères de découpage
– Les 3 archétypes de data domain : source-aligned, aggregated et consumer-aligned
– Délimitation des domaines : s’assurer que les périmètres sont clairs et les responsabilités non chevauchées

– Caractéristiques d’un Data Product : découvrabilité, adressabilité, fiabilité, interopérabilité, sécurité
– Les 3 archétypes de Data Products : source-oriented, aggregated et consumer-oriented
– Modèle de données versus protocole d’échange : définir les interfaces d’un Data Product
– Data Contracts (notions) : formaliser les engagements entre producteurs et consommateurs de données
– Intégration des Data Products dans un écosystème legacy : cohabitation avec l’existant

– Platform thinking appliqué à la Data Mesh : fournir des capacités en libre-service aux domaines
– Data Mesh Experience Plane : portail de découverte et de consommation des Data Products
– Data Product Experience Plane : outils de création, publication et monitoring des Data Products
– Utility Plane : services transverses (stockage, compute, sécurité, observabilité)
– Principes de conception d’une plateforme self-service : abstraire la complexité technique sans réduire l’autonomie

– Gouvernance centralisée vs fédérée : enjeux et limites de chaque modèle
– Principes de la gouvernance fédérée computationnelle : automatiser les politiques plutôt que les imposer manuellement
– Standards et interopérabilité : définir les règles globales que chaque domaine doit respecter
– Rôles clés : Data Steward, Data Owner et leur articulation dans un modèle fédéré
– Équilibrer autonomie des domaines et cohérence globale du système de données

– Évaluer la maturité de son organisation face au Data Mesh : matrice d’évaluation
– Identifier les domaines métiers prioritaires pour un premier Data Product
– Étapes clés d’adoption : du MVP Data Mesh au déploiement à l’échelle
– Dimensions organisationnelles et culturelles : embarquer les équipes et les data owners
– Construire son plan d’action : jalons, parties prenantes et critères de succès