Si la littérature sur le data mesh est très fournie, elle décrit souvent un état final, rarement comment y parvenir en pratique. La question se pose alors :
Quelle démarche adopter pour transformer le data management et mettre en place un data mesh ?
Dans cette série d’articles, vous trouverez des extraits de notre Guide Pratique du Data Mesh dans lequel nous proposons une démarche itérative de mise en place d’un data mesh au sein de votre organisation. Cette démarche s’articule autour de ses quatre principes clés (domain-oriented decentralized data ownership and architecture, data as a product, self-serve data infrastructure as a platform, and federated computational governance) et s’appuie sur les ressources humaines et technologiques existantes.
- Partie 1: Définir le périmètre de votre projet pilote
- Partie 2: Constituer l’équipe de développement et la plateforme data du projet pilote
- Partie 3: Produire vos premiers Data Products
- Partie 4: Passer à un modèle de gouvernance fédérée
Tout au long de cette série d’articles, et dans le but d’illustrer cette démarche itérative pour la mise en place d’un data mesh, nous nous appuierons sur un exemple : celui de l’entreprise fictive Premium Offices – il s’agit d’une société d’immobilier commercial dont l’activité consiste à acquérir des biens pour les louer à des entreprises
–
La première étape de la démarche présentée dans cette série d’articles pour transformer le data management et mettre en place un data mesh au sein de votre organisation consiste à construire un projet pilote. Celui-ci sera développé sur les 4 principes du data mesh, avec les ressources existantes, c’est-à-dire sans impacter l’organisation.
Pour que votre projet de décentralisation du data management démarre avec succès, vous devez vous concentrer sur deux conditions préalables essentielles : l’existence de domaines bien définis et le choix d’un use case initial.
Identification des domaines
Le premier pré-requis au démarrage du pilote est bien sûr l’identification des domaines – la fédération de domaines autonomes étant au cœur du data mesh.
Cette étape ne présente en général pas de difficulté. En effet, la notion de domaine est déjà largement répandue, et le découpage en domaines est souvent stable – qu’ils soient structurés selon les chaînes de valeur, les grands processus métier ou les capacités opérationnelles de l’organisation. Les domaines disposent parfois de leurs propres équipes techniques, et ont la propriété des systèmes opérationnels qui produisent la majorité des données. La transition consiste donc souvent à redistribuer l’ownership des données selon une structure déjà existante.
EXEMPLE PREMIUM OFFICES
Premium Offices est d’ores et déjà structurée autour de domaines qui reflètent ses grandes capacités, dont en voici trois exemples :
-
Asset - Le domaine chargé d’acquérir et de gérer des biens immobiliers. Pour cela, il s’appuie principalement sur un progiciel de gestion d’actifs.
-
Brokerage
- Le domaine qui s’occupe de la commercialisation des biens à louer et de la gestion des locataires. Pour cela il utilise un progiciel de Tenant Management, et il est responsable du site internet commercial et de la publication des offres sur des places de marché spécialisées.
-
Capital Markets
- Le domaine chargé des emprunts pour financer les achats et d’optimiser le portefeuille d’emprunts. Pour cela, il utilise un autre progiciel spécialisé.
Organisation par domaines – Grandes capacités de Premium Offices
Choix du premier use case
Le choix du use case pour le projet pilote est relativement arbitraire – il peut s’agir de la refonte d’un dashboard existant, d’un nouveau dashboard, de l’ajout de capacité d’intelligence artificielle dans une application ou encore de la commercialisation de certaines données.
Ce premier use case devra cependant posséder quelques caractéristiques qui permettront d’amorcer l’apprentissage dans de bonnes conditions :
🚫 Il doit porter sur un usage, pas uniquement sur un ou plusieurs data products – la valeur intrinsèque d’un data product est nulle, elle se réalise à travers ses usages.
🚫 Il ne doit pas être trop transverse et consommer des données d’un ou deux domaines au plus – un seul dans l’idéal.
🚫 Il ne doit pas être trop simple et consommer plus d’un data product, deux ou trois sont suffisants.
🚫 Il ne doit pas être trop expérimental – l’idée est d’obtenir des résultats concrets rapidement.
EXEMPLE PREMIUM OFFICES
Pour le projet pilote, Premium Offices a choisi de construire un tableau de bord du risque de crédit de ses locataires, afin de mieux anticiper et prévenir les éventuels défauts. Ce tableau de bord doit croiser les données sur les locataires, présentes dans son progiciel, et des données de crédit, acquises auprès d’un fournisseur spécialisé. Ces données sont déjà utilisées au niveau opérationnel, dans le processus d’évaluation d’un nouveau locataire.
En conclusion, la transformation vers le data mesh commence nécessite deux prérequis essentiels : l’identification des domaines et le choix d’un premier use case. En définissant d’emblée le périmètre du projet pilote, les organisations peuvent poser des bases solides pour une gestion des données décentralisée, sans que cela n’ait d’impact sur l’organisation.
Dans le prochain article, nous nous pencherons sur la constitution d’une équipe de développement et d’une plateforme data robuste pour le projet pilote.
Le Guide Pratique du Data Mesh: Mettre en place et superviser un data mesh à l’échelle de l’entreprise
Rédigé par Guillaume Bodet, co-fondateur et CPTO chez Zeenea, ce guide vous apportera une approche pratique pour mettre en œuvre un data mesh dans votre organisation, en vous aidant à :
✅ Entamer votre démarche data mesh avec un projet pilote focalisé
✅ Découvrir des méthodes efficaces pour mettre votre mesh à l’échelle,
✅ Comprendre le rôle essentiel joué par une data marketplace interne pour faciliter la consommation des data products
✅ Découvrir pourquoi Zeenea est un système de supervision robuste du data mesh à l’échelle de l’entreprise
