Choisir la bonne architecture de données pour l’organisation que vous avez réellement

Les décisions relatives à l’architecture des données sont devenues plus déterminantes à mesure que les organisations intensifient leurs efforts en matière d’analytique, d’automatisation et d’IA. Cette pression est compréhensible. Les dirigeants veulent des rapports plus fiables, des informations plus rapides, une meilleure gouvernance et des données plus faciles à utiliser par les équipes et les systèmes. Le problème est que les discussions sur l’architecture moderne des données se laissent souvent entraîner par les tendances avant que l’organisation n’ait répondu à une question plus fondamentale : quel modèle opérationnel pouvons-nous réellement prendre en charge ?

Deux approches reviennent souvent dans ce débat : la data mesh et la data fabric. Elles sont souvent présentées comme des technologies concurrentes. Cette vision est trop simpliste. La data mesh est avant tout un modèle opérationnel fondé sur la responsabilité des domaines et les données en tant que produit. La data fabric est avant tout une architecture d’intégration et de gouvernance qui s’appuie sur les métadonnées, l’automatisation et la connectivité pour faciliter la découverte, la gouvernance et l’utilisation des données dans l’ensemble des systèmes.

Les deux approches peuvent être utiles. Elles peuvent aussi créer des problèmes coûteux lorsqu’elles sont choisies pour de mauvaises raisons. Une initiative de data mesh peut échouer si les équipes de domaine ne sont pas prêtes à gérer des produits de données. Une initiative de data fabric peut échouer si l’organisation considère la plateforme comme une couche magique capable de compenser une mauvaise qualité des données, une responsabilité insuffisante ou une gouvernance floue.

La bonne question n’est pas « Quelle architecture est la meilleure ? » La meilleure question est « Quel modèle correspond à la maturité, à la culture de gouvernance, à la structure des équipes et aux objectifs métier à court terme de l’organisation ? »

La data mesh : la responsabilité comme architecture

La data mesh modifie la responsabilité des données. Au lieu de dépendre d’une équipe data centrale pour collecter, nettoyer, modéliser, documenter et mettre les données à disposition de tous les autres, la data mesh rapproche la responsabilité des domaines métier qui comprennent le mieux ces données.

Dans un modèle de data mesh mature, les équipes de domaine publient les données sous forme de produits. Les données ne sont donc pas simplement déversées dans un environnement partagé. Elles ont un responsable clairement identifié, une documentation, des exigences de qualité, des modalités d’accès et un public défini. L’équipe de domaine doit rendre les données utiles aux autres, et pas seulement les produire pour ses propres besoins opérationnels.

C’est la promesse. Le défi est qu’il ne s’agit pas seulement d’un changement technologique. C’est un changement organisationnel. Flexera décrit la data mesh comme une approche décentralisée qui permet aux équipes spécialisées par domaine de gérer et de posséder leurs données, tandis qu’Alation la considère comme utile lorsque le problème sous-jacent concerne une responsabilité floue, des goulots d’étranglement au sein d’une équipe data centrale ou une qualité des données incohérente entre les domaines. Ce sont de vrais problèmes, mais leur résolution exige plus que l’installation d’un outil. Elle nécessite des équipes de domaine disposant du temps, des compétences, des incitations et du soutien nécessaires pour devenir responsables de leurs données.

C’est là que de nombreuses initiatives de data mesh rencontrent des difficultés. Une équipe dirigeante peut apprécier l’idée de décentralisation, mais les équipes de domaine peuvent présenter des niveaux de maturité des données très différents. L’une peut disposer de solides compétences analytiques et de systèmes opérationnels propres. Une autre peut dépendre de feuilles de calcul, de définitions informelles et de nettoyages manuels. Considérer ces domaines comme également prêts à assumer la responsabilité de produits de données peut accroître l’incohérence au lieu de la réduire.

La data fabric : l’automatisation et la connectivité comme architecture

La data fabric suit une voie différente. Au lieu de commencer par une responsabilité décentralisée, elle se concentre sur la connexion, la gouvernance et l’utilisation des données dans un environnement complexe. Une data fabric peut s’appuyer sur les métadonnées, le catalogage, la traçabilité, les politiques d’accès, l’automatisation et des couches d’intégration pour aider les équipes à trouver et utiliser les données dans les entrepôts, les lacs de données, les applications, les plateformes cloud et les systèmes opérationnels.

Cela peut être intéressant pour les organisations qui doivent accélérer la création de valeur ou dont les données sont réparties entre de nombreux systèmes, mais qui ne sont pas prêtes à adopter un modèle complet de responsabilité par domaine. Atlan décrit la data fabric comme nécessitant moins de bouleversements culturels que la data mesh, mais davantage de sophistication technique. SAP décrit de même la data fabric comme centrée sur la manière dont les données sont connectées, gouvernées et rendues utilisables, tandis que la data mesh se concentre sur la répartition de la responsabilité des données.

L’avantage est concret. Une data fabric peut contribuer à réduire le travail d’intégration manuel, à améliorer la cohérence de la gouvernance et à offrir aux équipes un moyen plus unifié d’accéder aux données, sans obliger chaque domaine à devenir dès le premier jour une organisation pleinement mature de produits de données.

Mais la data fabric comporte ses propres risques. Si la plateforme devient l’endroit où doivent être résolus tous les problèmes d’accès aux données, de gouvernance, de transformation et d’intégration, elle peut devenir un nouveau goulot d’étranglement. L’organisation risque de centraliser la complexité sous une appellation plus moderne. Si les métadonnées sont de mauvaise qualité, si les systèmes sources sont désordonnés ou si les responsabilités sont floues, la fabric peut exposer ces problèmes plutôt que les résoudre.

Les deux modèles répondent à des problèmes différents

La manière la plus utile de comparer la data mesh et la data fabric consiste à se demander quel problème l’organisation cherche réellement à résoudre.

Si le principal problème est que la responsabilité des données est floue, que les équipes data centrales sont surchargées, que les équipes de domaine ne font pas confiance aux jeux de données partagés et que les experts métier sont trop éloignés des décisions relatives aux produits de données, la data mesh peut constituer la meilleure orientation à long terme.

Si le principal problème est la fragmentation des systèmes, l’incohérence des accès, la gouvernance manuelle, une traçabilité insuffisante, une faible capacité de découverte et trop de difficultés à déplacer les données entre les environnements, la data fabric peut être la première étape la plus pragmatique.

De nombreuses organisations auront finalement besoin d’éléments des deux approches. SAP décrit ces deux modèles comme distincts mais complémentaires : la data mesh donne davantage de contrôle aux équipes de domaine, tandis que la data fabric fournit une base technique pour connecter et gouverner les données dans toute l’entreprise. Cette vision hybride est souvent plus réaliste que de traiter le choix comme une décision où un seul modèle peut l’emporter.

Toutefois, l’ordre des étapes compte. Une organisation qui n’est pas prête à répartir la responsabilité peut rencontrer des difficultés si elle adopte directement la data mesh. Une organisation qui investit uniquement dans une couche de fabric peut également rencontrer des difficultés si personne n’est responsable de la signification, de la qualité et de l’utilité des données connectées.

Erreurs courantes liées à la data mesh

Les échecs de la data mesh viennent souvent d’une sous-estimation du modèle opérationnel. L’architecture peut sembler élégante lors des réunions stratégiques, mais le travail quotidien est moins séduisant.

Les équipes déploient des outils avant que les équipes de domaine ne comprennent ce que signifie être responsable d’un produit de données.
La direction sous-estime le changement organisationnel nécessaire à une prise de décision distribuée.
L’organisation suppose que la maturité des données est uniforme dans tous les domaines, alors qu’elle l’est rarement.
La gouvernance est décentralisée en apparence seulement, tandis que les approbations et les normes restent bloquées au niveau d’une équipe centrale.
Les équipes métier se voient confier des responsabilités sans disposer de la capacité, de la formation ou des incitations nécessaires pour maintenir des produits de données de haute qualité.

Le résultat peut être frustrant. L’organisation peut penser qu’elle se décentralise, alors qu’elle ne fait que répartir la confusion. Au lieu d’un seul goulot d’étranglement central, elle se retrouve avec des pratiques incohérentes entre les domaines, une documentation inégale, des normes peu claires et un modèle de gouvernance auquel personne ne fait pleinement confiance.

Erreurs courantes liées à la data fabric

Les initiatives de data fabric échouent différemment. Le risque tient moins à une répartition trop rapide de la responsabilité qu’à l’hypothèse selon laquelle la plateforme absorbera toute la complexité sous-jacente.

Les équipes considèrent la data fabric comme une solution universelle aux problèmes de qualité des données sources.
Les métadonnées, la traçabilité et le catalogage sont traités comme des tâches techniques plutôt que comme des fondations de la gouvernance.
L’organisation connecte les systèmes sans préciser qui est responsable des définitions clés, des indicateurs et des exigences de qualité des données.
L’accès devient plus facile, mais la confiance ne s’améliore pas, car les utilisateurs ne savent toujours pas quelles données sont correctes.
La plateforme de data fabric devient une dépendance qui exige des investissements continus, de la rigueur architecturale et une responsabilité opérationnelle.

Une data fabric peut faciliter la navigation dans l’environnement de données. Elle ne peut pas, à elle seule, rendre de bonnes des données de mauvaise qualité. Elle ne peut pas résoudre les divergences de définition du chiffre d’affaires, du client, des stocks, de l’utilisation ou du risque. Ce sont des questions métier et de gouvernance qui nécessitent toujours une responsabilité humaine.

Les critères de sélection qui comptent vraiment

Avant de choisir une orientation, les dirigeants doivent évaluer honnêtement l’organisation. Les critères les plus importants ne sont pas abstraits.

Maturité des domaines : Les domaines métier peuvent-ils définir, maintenir, documenter et prendre en charge des produits de données avec une cohérence raisonnable ?
Solidité de la gouvernance : L’organisation dispose-t-elle déjà de normes claires en matière de qualité, d’accès, de traçabilité, de confidentialité et de responsabilité ?
Capacité technique : Les équipes peuvent-elles exploiter la plateforme requise et assurer les processus d’automatisation, d’intégration, de catalogage, de supervision et de support ?
Préparation culturelle : L’organisation est-elle à l’aise avec une responsabilité distribuée, ou la prise de décision dépend-elle encore fortement d’un contrôle centralisé ?
Objectifs en matière d’IA et d’analytique : L’organisation a-t-elle besoin de produits de données gouvernés et réutilisables pour des cas d’usage avancés, ou doit-elle d’abord améliorer la connectivité et la découvrabilité ?
Capacité de changement : Quelle ampleur de changement organisationnel l’entreprise peut-elle absorber tout en continuant à assurer ses activités quotidiennes ?

Ces critères ne visent pas à ralentir les progrès. Ils aident à éviter une mise en scène coûteuse. Une stratégie de données qui ignore la maturité finit généralement par se réduire à la mise en œuvre d’un outil. Une mise en œuvre d’outil qui ignore la responsabilité finit généralement par devenir un nouveau projet de nettoyage des données, avec un meilleur tableau de bord.

Comment Ridiculous Engineering envisage cette décision

Chez Ridiculous Engineering, nous considérons l’architecture des données comme un problème de conception à la fois technique et organisationnel. Le schéma, la plateforme, les intégrations et l’automatisation sont importants. La responsabilité, les processus, la gouvernance, les incitations et la capacité des équipes à maintenir ce qui est construit le sont également.

Cela est particulièrement important lorsque les organisations se préparent à des flux de travail assistés par l’IA. Les systèmes d’IA ne sont utiles qu’à hauteur de l’environnement de données qui les entoure. Si les données sont mal gouvernées, définies de manière incohérente, difficiles à retracer ou dispersées entre des systèmes sans responsabilité clairement établie, l’IA ne les transformera pas miraculeusement en informations métier fiables. Elle pourrait simplement produire des réponses plus assurées à partir de données d’entrée fragiles.

Notre rôle consiste à aider les clients à ralentir juste assez pour prendre la bonne décision architecturale avant de s’engager sur une voie coûteuse. Cela peut signifier évaluer la maturité actuelle des données, cartographier les domaines et les responsabilités, identifier les lacunes de gouvernance, évaluer les options de plateforme de données, moderniser les intégrations ou concevoir une feuille de route progressive qui fournit de meilleures données à l’organisation sans lui imposer un modèle de maturité qu’elle n’est pas encore en mesure de prendre en charge.

Parfois, la bonne réponse consiste à évoluer vers un data mesh. Parfois, il faut d’abord investir dans une couche de data fabric. Dans certains cas, l’approche la plus pragmatique est hybride : elle améliore la connectivité et la gouvernance tout en préparant progressivement les équipes de domaine à devenir responsables de produits de données de meilleure qualité au fil du temps.

La décision doit correspondre à la réalité, pas aux aspirations

Data mesh et data fabric ne sont pas des mots magiques. Ce sont différentes façons d’organiser la responsabilité, la gouvernance et l’accès au sein d’un environnement de données complexe. Ils peuvent fonctionner ensemble, mais seulement si l’organisation comprend ce que chaque approche est censée résoudre.

Le danger consiste à choisir en fonction de ses aspirations. Une entreprise peut vouloir être décentralisée tout en continuant à fonctionner avec une prise de décision centralisée et une maturité inégale entre les domaines. Une autre peut souhaiter une data fabric sophistiquée, mais ne pas disposer de la rigueur nécessaire en matière de métadonnées ni de la responsabilité opérationnelle requise pour la maintenir fiable. Dans les deux cas, l’architecture commence à s’éloigner de la réalité.

La meilleure approche est plus honnête. Commencez par déterminer où se situe réellement l’organisation. Comprenez les problèmes de données qui génèrent le plus de frictions. Identifiez les lacunes en matière de responsabilité. Décidez quelles capacités doivent être améliorées en premier. Choisissez ensuite une architecture qui accompagne l’étape suivante de la maturité, plutôt que de prétendre que l’organisation est déjà arrivée à destination.

Si votre organisation évalue un data mesh, une data fabric ou un effort plus large de modernisation des données, Ridiculous Engineering peut vous aider à évaluer les compromis, à concevoir une feuille de route réaliste et à mettre en place les systèmes et les modes de fonctionnement nécessaires pour rendre l’architecture utile en pratique.

La meilleure architecture de données n’est pas celle qui porte le nom le plus à la mode. C’est celle que votre organisation peut exploiter, gouverner, comprendre et améliorer au fil du temps.

Sources et lectures complémentaires : Flexera : data mesh ou data fabric, Alation : data fabric ou data mesh, Atlan : data mesh ou data fabric, SAP : data fabric ou data mesh, Apptad : data mesh ou entrepôt centralisé

Data Mesh ou Data Fabric : la décision de décentralisation qui coûte des millions