Article

Le Data Mesh n'est pas un problème d'architecture — c'est un problème d'organisation

10 juin 2026Article~6 min de lecture

À chaque fois qu'on parle de Data Mesh, la conversation part vers les schémas, les contrats de données, les API. C'est utile — mais ce n'est pas par là que ça commence. Ce qui détermine si une migration tient la route, c'est la façon dont les équipes se répartissent la responsabilité des données. L'architecture suit.

Pourquoi on parle d'abord de schémas et de contrats

C'est compréhensible : les schémas et les contrats de données sont concrets, mesurables, et donnent l'impression d'avoir un plan. Le découpage en domaines, lui, touche à des questions d'organisation — qui possède quoi, qui répond à qui — qui sont plus inconfortables à aborder en premier. Le but n'est pas d'ignorer la dimension technique, mais de ne pas la traiter comme le point de départ.

Comment l'organisation détermine l'architecture

Dans une plateforme centralisée, une seule équipe connaît (ou est censée connaître) tous les domaines métier. Quand on découpe par domaines, chaque équipe devient responsable de ses propres données — et c'est cette responsabilité, pas le schéma technique, qui définit les frontières des futurs services. Les contrats de données viennent ensuite formaliser des frontières qui existent déjà côté organisation. Si on inverse l'ordre — dessiner les contrats avant de clarifier qui possède quoi — on obtient une architecture élégante sur le papier, mais que personne n'a vraiment les moyens de faire vivre.

Playground

Voir cette dynamique en mouvement

J'ai construit un simulateur interactif qui illustre, étape par étape, comment une plateforme centralisée se redécoupe en domaines autonomes — et ce que ça implique à chaque étape.

Essayer le simulateur

Ce que ça change pour démarrer une migration

En pratique, ça veut dire commencer par cartographier qui possède quoi aujourd'hui — même de façon informelle — avant de dessiner le moindre schéma cible. Le premier domaine à migrer n'est pas forcément celui qui a la dette technique la plus visible, mais celui où la responsabilité métier est la plus claire : c'est là que la nouvelle frontière organisation/architecture aura le moins de friction à s'installer.

Je serais curieux de savoir comment vous abordez ce problème dans votre contexte — par où avez-vous commencé : l'organisation, ou l'architecture ?