Peu de débats dans le monde de la data génèrent autant de passion — et aussi peu de clarté — que la question data mesh vs data lake. D'un côté, le data lake centralisé, architecture par défaut depuis une décennie. De l'autre, le data mesh, un paradigme décentralisé qui traite la donnée comme un produit et distribue la responsabilité aux équipes métier. Les deux ont des défenseurs passionnés. Les deux ont des limites réelles. Et aucun des deux n'est universellement adapté.
Le problème est que la plupart des organisations abordent ce sujet comme un choix binaire : choisir une architecture, s'engager et espérer que tout ira bien. Cette approche est erronée. La bonne architecture dépend de votre maturité organisationnelle, de votre culture data, de la complexité de votre paysage de domaines métier et — point critique — de votre volonté d'investir dans les capacités de gouvernance et de plateforme que chaque modèle exige.
Cet article propose une comparaison approfondie et engagée des deux architectures. Nous couvrirons ce que chacune implique réellement (au-delà des mots à la mode), quand chacune fonctionne le mieux, les prérequis de maturité nécessaires avant de s'engager, et les chemins de transition pratiques pour les organisations qui évoluent d'un modèle vers l'autre.
Qu'est-ce qu'un data lake, concrètement ?
Un data lake est un entrepôt centralisé qui stocke les données brutes à n'importe quelle échelle — structurées, semi-structurées et non structurées — dans leur format natif. Le principe fondamental est simple : tout ingérer dans un seul endroit d'abord, puis s'occuper de la transformation, du schéma et de la consommation ensuite. Cette approche « schema-on-read » était révolutionnaire quand elle est apparue au début des années 2010, principalement parce qu'elle libérait les organisations des exigences rigides de modélisation en amont des entrepôts de données traditionnels.
Dans une architecture data lake bien implémentée, les données circulent des systèmes sources vers une zone d'atterrissage (souvent appelée couche raw ou bronze), passent par des pipelines de transformation vers des couches curatées (silver et gold), et sont consommées par les analystes, les data scientists et les applications en aval. Une équipe centrale de data engineering est généralement propriétaire des pipelines d'ingestion, de la logique de transformation et de l'infrastructure qui sous-tend l'ensemble.
Les forces de ce modèle sont significatives. La centralisation crée une source unique de vérité. Une équipe dédiée peut imposer des standards de qualité cohérents. Les économies d'échelle s'appliquent — une plateforme bien gérée sert toute l'organisation. Et pour les organisations qui sont au début de leur parcours de maturité data, une équipe centralisée fournit l'expertise et les garde-fous de gouvernance que les équipes métier n'ont tout simplement pas encore.
Mais les faiblesses sont tout aussi significatives, et elles tendent à émerger à l'échelle.
Le problème du goulot d'étranglement du data lake
L'équipe centrale de data engineering devient un goulot d'étranglement. Chaque nouvelle source de données, chaque demande de transformation, chaque changement de schéma passe par la même équipe. Quand vous avez 5 domaines qui demandent des pipelines de données, une équipe centrale de 8 ingénieurs peut gérer. Quand vous avez 25 domaines, chacun avec des besoins évolutifs, la file d'attente s'allonge, l'équipe est plus sollicitée, et le délai entre la demande et la livraison passe de jours à semaines à mois.
Ce goulot d'étranglement crée un second problème : les équipes métier perdent la propriété de leurs données. L'équipe commerciale connaît intimement ses données CRM — les particularités, les règles métier, les cas limites — mais elle n'a aucun contrôle sur la façon dont ces données sont ingérées, transformées ou mises à disposition. L'équipe centrale, manquant d'expertise métier, fait des hypothèses qui produisent des transformations techniquement correctes mais métier-incorrectes. Le résultat est un data lake techniquement opérationnel mais fonctionnellement suspecté.
Et il y a le problème de la gouvernance. Un data lake centralisé concentre les responsabilités de gouvernance dans une seule équipe qui manque souvent du contexte pour prendre des décisions nuancées sur l'accès aux données, les règles de qualité et les politiques de rétention à travers des dizaines de domaines. Les métadonnées qui devraient accompagner chaque jeu de données — lignage, scores de qualité, définitions métier, propriété — sont soit incomplètes, soit maintenues dans un catalogue de données séparé qui dérive par rapport au contenu réel du lac.
Qu'est-ce qu'un data mesh, concrètement ?
Le data mesh est un paradigme architectural et organisationnel proposé par Zhamak Dehghani en 2019. Il repose sur quatre principes :
1. Propriété orientée domaine. Au lieu d'une équipe centrale propriétaire de toutes les données, chaque domaine métier (ventes, marketing, finance, logistique) possède et opère ses propres produits de données. L'équipe du domaine qui produit les données est responsable de leur qualité, de leur documentation et de leur disponibilité.
2. La donnée comme produit. Chaque domaine publie ses données sous forme de produits de données découvrables, auto-descriptifs et fiables avec des SLAs clairs. Pensez-y comme une API interne : bien documentée, versionnée et conçue pour la consommation par d'autres.
3. Plateforme de données en libre-service. Une équipe plateforme centrale fournit l'infrastructure, les outils et les templates que les équipes métier utilisent pour construire et opérer leurs produits de données. La plateforme abstrait la complexité du stockage, du calcul, de la sécurité et du monitoring pour que les équipes métier puissent se concentrer sur leur logique de données.
4. Gouvernance computationnelle fédérée. Les politiques de gouvernance sont définies globalement mais appliquées computationnellement à travers la plateforme. Au lieu de s'appuyer sur des réviseurs humains pour vérifier la conformité, la plateforme automatise l'application des politiques — classification des données, contrôle d'accès, seuils de qualité, règles de rétention — au moment de la publication du produit de données.
La promesse du data mesh est séduisante : il élimine le goulot d'étranglement central, aligne la propriété des données avec l'expertise métier, fait évoluer la capacité organisationnelle de manière linéaire avec le nombre de domaines, et traite la gouvernance comme une capacité de plateforme plutôt qu'un processus bureaucratique.
Le data mesh face à la réalité
La théorie est élégante. La pratique est difficile. Très difficile.
Le data mesh exige un niveau de maturité organisationnelle que la plupart des entreprises n'ont tout simplement pas. Chaque équipe métier a besoin de capacités de data engineering — pas juste un analyste, mais des ingénieurs capables de construire, surveiller et maintenir des pipelines de données en production. Pour une organisation avec 15 domaines, cela représente un minimum de 15 à 30 data engineers supplémentaires, répartis dans l'organisation plutôt que concentrés dans une seule équipe. Le coût en talents seul est considérable.
La plateforme en libre-service est non triviale à construire. Elle nécessite une équipe de platform engineering sophistiquée capable de créer les abstractions, les templates et l'automatisation qui rendent les équipes métier productives sans exiger que chaque équipe soit experte en infrastructure. La plupart des organisations qui tentent le data mesh sous-estiment cet investissement d'un facteur trois à cinq.
La gouvernance fédérée semble moderne et démocratique, mais elle exige des standards globaux cristallins, des mécanismes d'application automatisés et une volonté culturelle de laisser les équipes métier prendre des décisions dans un cadre défini. Dans les organisations avec des fondations de gouvernance faibles, le data mesh ne résout pas les problèmes de gouvernance — il les distribue entre plus d'équipes, les rendant plus difficiles à identifier et à corriger.
Et peut-être le défi le plus sous-estimé : le data mesh exige un état d'esprit produit que beaucoup d'équipes métier n'ont pas. Traiter la donnée comme un produit signifie investir dans la documentation, le versionnement, les SLAs, le feedback consommateur et l'amélioration continue. La plupart des équipes métier sont déjà pleinement occupées par leurs responsabilités principales. Leur demander d'opérer aussi un produit de données sans effectif supplémentaire est une recette pour la négligence.
Quand le data lake est le bon choix
Une architecture data lake centralisée est le meilleur choix quand :
Votre organisation est au début de son parcours de maturité data. Si la plupart des équipes travaillent encore avec des tableurs, des rapports manuels et des bases de données en silos, introduire une architecture décentralisée créera le chaos. Vous avez besoin de centralisation d'abord pour établir les capacités fondamentales : des patterns d'ingestion cohérents, des standards de qualité de base, un catalogue de données partagé et une culture de décision informée par les données. Construisez les fondations avant de distribuer.
Votre paysage de domaines est relativement simple. Si vous avez 5 à 10 domaines clairement définis avec des modèles de données stables et des interactions inter-domaines limitées, une équipe centrale peut les servir efficacement sans devenir un goulot d'étranglement. Le data mesh résout un problème de passage à l'échelle — si vous n'avez pas encore ce problème, vous n'avez pas besoin de cette solution.
Les talents en data engineering sont rares. Sur de nombreux marchés, les data engineers sont chers et difficiles à recruter. Un modèle centralisé concentre votre investissement en talents dans une seule équipe qui sert toute l'organisation. Un modèle décentralisé étale ce même talent, ou vous oblige à en recruter plusieurs fois plus — et le marché du travail peut ne pas le permettre.
La maturité de la gouvernance est faible. Si votre organisation n'a pas encore de propriété claire des données, de standards de qualité définis ou de catalogue de données fonctionnel, vous devez construire cela de manière centralisée avant de distribuer la responsabilité de la gouvernance. La gouvernance fédérée fonctionne quand il y a un centre solide à partir duquel fédérer. Sans ce centre, vous obtenez de la fragmentation déguisée en autonomie.
Quand le data mesh est le bon choix
Une architecture data mesh est le meilleur choix quand :
L'équipe data centrale est un goulot d'étranglement persistant. Si le délai d'accès aux données dépasse systématiquement les seuils acceptables, si le backlog de data engineering a des mois de retard et si les équipes métier construisent des infrastructures data parallèles pour contourner l'équipe centrale, vous avez exactement le problème que le data mesh est conçu pour résoudre. Le goulot d'étranglement est organisationnel, pas technique, et seule une restructuration organisationnelle le corrigera.
Votre paysage de domaines est complexe et en évolution. Les organisations avec 15 à 50+ domaines distincts, chacun avec des modèles de données uniques, des règles métier et des besoins évolutifs, submergeront toujours une équipe centrale. La propriété par domaine devient non seulement bénéfique mais nécessaire — l'équipe centrale ne peut physiquement pas maintenir l'expertise contextuelle requise à travers autant de domaines.
Vous avez une forte capacité de platform engineering. Le data mesh n'est viable que si vous pouvez construire une plateforme en libre-service qui abstrait la complexité de l'infrastructure. Si votre équipe de platform engineering construit déjà des plateformes développeur pour les équipes logicielles, étendre cette capacité aux produits de données est une évolution naturelle. Si vous n'avez pas du tout de platform engineering, le data mesh vous demandera de construire cette capacité from scratch avant qu'une seule équipe métier puisse être productive.
Les équipes métier ont des compétences en data engineering. C'est le facteur déterminant. Le data mesh distribue la propriété, ce qui signifie que les équipes métier doivent avoir la capacité technique de construire et d'opérer des pipelines de données. Si vos équipes métier sont des analystes métier sans compétences d'ingénierie, le data mesh ne fonctionnera pas tant que vous n'aurez pas embarqué des capacités d'ingénierie dans chaque domaine — ce qui représente un engagement organisationnel et budgétaire significatif.
Le chemin hybride : là où la plupart des organisations atterrissent
Voici la vérité que les puristes des deux camps n'aiment pas admettre : la plupart des organisations qui réussissent finissent avec une architecture hybride. Elles centralisent les capacités fondamentales — patterns d'ingestion, plateforme data centrale, cadres de gouvernance, gestion des données de référence — tout en distribuant progressivement la propriété des produits de données spécifiques aux domaines vers les équipes qui sont prêtes.
Cette approche hybride fonctionne parce que la maturité n'est pas uniforme au sein d'une organisation. Votre équipe finance peut avoir de solides compétences en data engineering et des produits de données clairs, tandis que votre équipe RH essaie encore de comprendre comment exporter les données de leur SIRH. Forcer les deux dans le même modèle architectural est dogmatique. Un leader pragmatique rejoint chaque domaine là où il en est et fournit un chemin de maturation clair.
Le schéma pratique ressemble à ceci :
Phase 1 : Fondation centralisée (12-18 mois). Construisez la plateforme data centrale, établissez les standards de gouvernance, implémentez un catalogue de données, et créez les patterns d'ingestion et de transformation que tous les domaines utiliseront. C'est votre phase data lake — et elle est essentielle, même si votre vision à long terme est le mesh.
Phase 2 : Propriété de domaine pilote (6-12 mois). Sélectionnez deux à trois domaines avec la maturité la plus élevée — généralement ceux qui ont déjà des talents en data engineering, des produits de données clairs et un leadership de domaine engagé. Faites-les passer à la propriété de domaine, en utilisant la plateforme centrale comme couche d'infrastructure. Apprenez de ces pilotes avant d'étendre.
Phase 3 : Plateformisation et expansion (12-24 mois). Sur la base des apprentissages pilotes, investissez dans les capacités de plateforme en libre-service qui rendent la propriété de domaine scalable : templates, vérifications de gouvernance automatisées, monitoring et onboarding en libre-service. Embarquez progressivement des domaines supplémentaires à mesure qu'ils développent la capacité nécessaire.
Phase 4 : Opération fédérée (continu). L'équipe centrale évolue d'opérateur à fournisseur de plateforme et curateur de gouvernance. Les équipes métier opèrent leurs produits de données de manière indépendante dans le cadre des garde-fous de la plateforme. La gouvernance est appliquée computationnellement, pas manuellement.
Cette transition n'est ni facile ni rapide. Mais elle est réaliste. Elle respecte le fait que le changement organisationnel est graduel et que l'architecture technique doit évoluer en parallèle de la capacité organisationnelle.
Prérequis de maturité : une évaluation honnête
Avant de choisir une architecture, vous devez évaluer honnêtement où vous en êtes. Voici les dimensions de maturité critiques que les leaders data doivent évaluer.
Maturité de la gouvernance des données. Avez-vous des propriétaires de données définis, des standards de qualité et un catalogue de données fonctionnel ? Si la réponse est non, commencez par la gouvernance centralisée. Vous ne pouvez pas fédérer ce qui n'existe pas.
Distribution des talents en data engineering. Où se situe votre capacité de data engineering ? Si elle est concentrée dans une seule équipe, vous êtes configuré pour un modèle centralisé. Si elle est distribuée entre les domaines (ou si vous avez le budget pour la distribuer), le mesh devient viable.
Capacité de platform engineering. Pouvez-vous construire et maintenir une plateforme de données en libre-service ? Cela requiert une expertise en infrastructure-as-code, des moteurs de templates, des tests automatisés et du monitoring à l'échelle. Si vous provisionnez encore l'infrastructure manuellement, vous n'êtes pas prêt pour le mesh.
Pensée produit de données au niveau des domaines. Les équipes métier comprennent-elles ce qu'est un produit de données ? Ont-elles la capacité et la volonté de posséder leurs données de bout en bout ? C'est une question de préparation culturelle, et c'est souvent la plus difficile à changer.
Appétit pour le changement organisationnel. Le data mesh n'est pas seulement un changement technique — c'est une restructuration organisationnelle qui affecte les structures d'équipe, l'allocation budgétaire, les plans de recrutement et les modèles de responsabilité. Votre direction a-t-elle l'appétit pour ce niveau de changement ?
Si vous êtes faible sur la plupart de ces dimensions, un data lake centralisé est votre architecture de départ — et il n'y a rien de mal à cela. Construisez les fondations, développez les capacités et réévaluez dans 18 à 24 mois. Le pire scénario est d'adopter le data mesh prématurément et de créer un désordre fragmenté plus difficile à corriger que le goulot d'étranglement que vous tentiez de résoudre.
Erreurs courantes dans la décision d'architecture
Ayant travaillé avec des dizaines d'organisations naviguant ce choix, nous voyons les mêmes erreurs se répéter.
Erreur 1 : Choisir en suivant la mode. Le data mesh est le chouchou actuel du secteur. Les conférences, les articles de blog et les pitchs de vendeurs poussent tous vers le mesh. Mais adopter une architecture parce qu'elle est tendance, plutôt que parce qu'elle correspond à votre réalité organisationnelle, est une erreur stratégique qui prend des années à corriger.
Erreur 2 : Sous-estimer l'investissement plateforme. Un data mesh sans plateforme en libre-service mature, c'est juste du chaos. Si vous n'êtes pas prêt à investir 12 à 18 mois d'effort de platform engineering avant que les équipes métier puissent être productives, ne prenez pas le chemin du mesh.
Erreur 3 : Ignorer les mathématiques des talents. La décentralisation multiplie vos besoins en talents. Si vous avez actuellement 10 data engineers dans une équipe centrale servant 20 domaines, passer au mesh signifie que vous avez besoin de 20 à 40 data engineers embarqués dans ces domaines — plus l'équipe plateforme centrale. Si votre budget ne le supporte pas, votre ambition mesh mourra de famine en talents.
Erreur 4 : Traiter cela comme une décision ponctuelle. Votre architecture évoluera à mesure que votre organisation mûrit. La bonne réponse aujourd'hui peut ne plus être la bonne dans trois ans. Intégrez la flexibilité pour évoluer et menez des réévaluations régulières au fur et à mesure que votre maturité progresse.
Erreur 5 : Faire l'impasse sur les fondations de gouvernance. Les deux architectures exigent une gouvernance solide — elles l'implémentent simplement différemment. Si vous sautez la gouvernance pour foncer sur l'infrastructure, vous construirez un système techniquement impressionnant auquel personne ne fait confiance, qu'il soit centralisé ou décentralisé.
Le cadre de décision
Voici un cadre pratique pour prendre cette décision. Notez votre organisation sur chacune des dimensions suivantes (échelle de 1 à 5), puis utilisez le total pour guider votre choix d'architecture.
Sévérité du goulot d'étranglement de l'équipe centrale (1 = pas de goulot, 5 = sévère). Les scores élevés favorisent le mesh.
Nombre et complexité des domaines (1 = peu de domaines simples, 5 = nombreux domaines complexes). Les scores élevés favorisent le mesh.
Distribution des talents en data engineering (1 = entièrement centralisée, 5 = largement distribuée). Les scores élevés favorisent le mesh.
Maturité du platform engineering (1 = aucune, 5 = mature). Les scores élevés favorisent le mesh.
Maturité de la gouvernance (1 = aucune, 5 = mature). Les scores bas favorisent le centralisé ; les scores élevés rendent les deux viables.
Préparation au changement organisationnel (1 = résistant, 5 = agile). Les scores élevés favorisent le mesh.
Si votre total est inférieur à 12, commencez par le centralisé. Entre 12 et 20, poursuivez le chemin hybride avec une fondation centralisée et des domaines pilotes. Au-dessus de 20, vous êtes probablement prêt pour une adoption mesh complète — mais validez avec l'évaluation de maturité avant de vous engager.
Comment Fygurs s'inscrit dans cette démarche
Que vous construisiez un data lake centralisé ou que vous transitionnez vers un data mesh, le processus de planification stratégique est le même : évaluer votre maturité actuelle, identifier les lacunes, prioriser les initiatives et construire une feuille de route. Fygurs est conçu pour supporter exactement ce processus. Notre plateforme pour les leaders data fournit des évaluations de maturité structurées, du scoring d'initiatives et des feuilles de route vivantes qui s'adaptent à mesure que votre architecture évolue.
La décision d'architecture est l'un des choix les plus conséquents qu'un leader data fera. Ne la prenez pas en suivant la mode. Prenez-la en vous basant sur une évaluation honnête de là où votre organisation en est aujourd'hui, où elle doit aller, et ce qu'il faut pour y arriver. C'est le fondement de toute stratégie data solide.
