Data / IA
Ajuster le système d’information «data» aux métiers
Par La rédaction, publié le 05 octobre 2022
Le data mesh, l’architecture cible de la décennie
La prochaine décennie verra les entreprises faire évoluer leurs architectures data pour tendre vers ce que l’on appelle le data mesh. Plus qu’une architecture technique, c’est à un véritable changement d’organisation auquel on va assister.
Après la centralisation des données dans les data lakes des années 2010, l’ère de la décentralisation s’est ouverte en 2021. Les métiers doivent être beaucoup plus impliqués, à la fois dans la collecte et le maintien de la qualité des données, mais aussi dans la stratégie data de leur entreprise. Pour Lounès Achab, lead data cloud practice & cloud solution architect chez Hardis : « Le vrai changement de paradigme amené par le data mesh porte sur deux points : d’une part, ce modèle doit décharger la DSI centrale. L ’architecture data n’est plus totalement centralisée et gérée par une seule équipe. D’autre part, on doit revoir la gouvernance globale de la donnée, qui est au cœur du projet, avec la création d’entités “Produit”. » Gérer la data de chaque entité métiers comme un produit qu’il faut porter et promouvoir auprès des autres métiers, c’est l’idée qui sous-tend le data mesh. Lobna Karoui, stratégiste et architecte data chez Capgemini, souligne : « Les entreprises cherchent aujourd’hui une architecture capable de les aider à faire face au besoin de rapidité du marché, à des volumétries conséquentes et qui puisse renforcer l’accessibilité des données en leur permettant de les partager entre les différentes entités et métiers d’une entreprise. »
Un changement d’approche majeur
Directement inspiré du monde du développement logiciel et des organisations « agile at scale » (comprendre l’agilité à l’échelle), le modèle data mesh constitue un vrai virage dans la manière dont les entreprises vont considérer leurs données. Le principe n’est même plus de considérer la donnée comme un élément tangible (« asset »), mais comme un véritable produit qu’il faut maintenir, faire évoluer et promouvoir en interne ou à l’externe. Chaque entité d’une organisation va gérer un ou plusieurs « produits data » qui vont correspondre à une vue technico-fonctionnelle de leur métier. Un product owner assure la responsabilité de son produit. « Concrètement, on va créer un rôle de data product owner au sein de chaque métier. Les équipes métiers sont responsabilisées vis-à-vis de la donnée et ont un rôle opérationnel à jouer. Pour cela, elles doivent aussi être sensibilisées à la gouvernance et à la qualité de leurs données ainsi qu’à leur exposition », détaille Lounès Achab. Pour l’expert, ce volet organisationnel est au cœur de ce qui va différencier une migration vers une plateforme data fabric d’un réel déploiement de data mesh.
Certaines entreprises préféreront sans doute passer par la case data fabric pour moderniser leurs infrastructures data avant de songer à basculer vers le data mesh. De nombreux éditeurs de logiciels, dont Talend, militent dans ce sens, avec des gains déjà significatifs. Gartner évoque une réduction de 70 % des efforts liés à la gestion des données. « Pour moi, data fabric et data mesh ont tous deux des avantages et des inconvénients, confie Lobna Karoui. Pour certains clients, la data fabric va bien répondre aux besoins et il ne sera pas nécessaire de bouleverser l’organisation comme l’implique le data mesh. Mais chez mes clients du secteur bancaire, la question de passer par la data fabric avant d’aller vers le data mesh ne s’est même pas posée. Leur volonté était vraiment de basculer vers le data mesh le plus rapidement possible avec une démarche très volontariste pour avancer vers cet objectif, définir les domaines puis les produits qui y sont rattachés. »
Pour Yan Truong, responsable du département Big Data, Référentiels et Vision 360 de Malakoff Humanis, ce modèle est prometteur, mais suscite encore beaucoup d’interrogations : « Nous sommes clairement dans une approche qui reste “data factory” avec une collaboration étroite entre la direction SI data et la direction data métiers. Notre organisation agile en mode “squad” par use case/data product embarque des product owners et des utilisateurs référents métiers et n’est donc pas si éloignée de l’approche data mesh. » Dans cette organisation, chaque squad bénéficie d’un espace dédié avec un stack technologique adapté mis à disposition par l’équipe « socle/écosystème data », une structure mixte DSI/métiers. Ces briques technologiques sont compatibles avec la mise à disposition d’une plateforme data en mode self-service et une gouvernance fédérée. « Nous pouvons envisager de sortir de la plateforme data centralisée de type monolithe qui, on doit bien l’avouer, ne règle pas toutes les frustrations des métiers malgré la promesse initiale », ajoute le responsable qui n’estime pas avoir atteint le niveau de maturité suffisant pour aller vers le data mesh. Un projet qui impliquerait la remédiation partielle d’une plateforme data construite récemment. « Le data mesh implique surtout un aspect organisationnel qui est encore plus important et difficile à mettre en œuvre que l’aspect technologique : la constitution d’équipes “data domain”, à savoir des équipes métiers “augmentées” avec une expertise technique. Cela semble en tout cas séduisant sur le papier et représente le Graal de la gouvernance des données, avec une autonomisation et une responsabilisation accrue des métiers sur les données et les data produits associés. À suivre donc … »
Pas véritablement de solutions « data mesh » clé en main
Du côté de l’implémentation technique de ce modèle, il n’existe pas véritablement de solution data mesh clé en main qui couvre l’intégralité des fonctions requises par ce type d’architecture. Si Gartner a publié une étude sur ce qui différencie fonctionnellement les plateformes data fabric et data mesh, on note également que de nombreux composants sont communs.
Pour l’heure, les plateformes data des hyperscalers cloud sont certainement les plus indiquées pour tendre vers le data mesh. C’est la position de Lounès Achab qui souligne : « Si on souhaite disposer d’une plateforme de données centralisée qui puisse être exploitable de manière décentralisée par les métiers, les plateformes cloud de type Google BigQuery, AWS ou Azure sont un bon moyen d’atteindre ce premier objectif. Elles proposent d’avoir une vue centralisée, mais aussi des implémentations décentralisées auprès des métiers tout en restant cohérentes d’un point de vue global. Elles permettent d’atteindre l’objectif de créer des catalogues de données qui sont réellement utilisables par les métiers. » L’atout des plateformes des hyperscalers est d’offrir via leurs marketplaces des écosystèmes de solutions qui vont se greffer sur leurs services data et de coupler simplement le volet stockage à une solution de data catalog, de tableaux de bord ou dataviz.
À l’approche data fabric dont il reprend de nombreuses briques techniques, le concept de data mesh vient ajouter une composante organisationnelle directement inspirée par les organisations dites « agile at scale », transposée au monde de la data (Source : Gartner).
Parmi les entreprises françaises qui ont massivement misé sur Big Query (service web de Google dédié à l’analyse de données) figure Carrefour. Le groupe a fait de son partenariat avec Google le fer de lance de sa transformation digitale. Autre acteur qui revient constamment dans ces projets data de nouvelle génération, Snowflake. Ce fut le choix de Monoprix en 2019 et l’enseigne tire aujourd’hui profit de sa plateforme data 100 % cloud. Damien Pichot, son directeur des opérations et des flux marchandises, souligne un atout de cette plateforme : « Un point vraiment important de Snowflake, c’est le data sharing. Cette fonctionnalité nous donne la capacité d’échanger facilement des données avec nos prestataires. Ainsi, notre plan de contact client n’était mis à jour que deux fois par an car cela représentait deux semaines de travail pour rafraîchir toutes nos données. Les équipes marketing devaient préparer les données et envoyer des milliers de fichiers à nos prestataires. Aujourd’hui ceux-ci se connectent eux-mêmes à Snowflake pour y trouver les données. Avec cette nouvelle approche, nous pouvons mettre à jour les plans de contact une fois par semaine. » L’approche a permis à l’enseigne d’abaisser les coûts d’exploitation de son infrastructure data tout en lui apportant des capacités de partage des données bien supérieures et une possibilité de monétiser ses données, ce qui lui était impossible jusque-là.
TÉMOIN – LOUNÈS ACHAB, lead data cloud practice & cloud solution architect chez Hardis
Responsabiliser les équipes métiers sur la qualité des données
« Actuellement, les équipes qui gèrent les applicatifs produisent et traitent la donnée. Ces données viennent alimenter des pipelines à destination d’autres équipes. Les data fabrics, data lakes et data warehouses sont des approches essentiellement orientées techniques. Ils ne s’adressent qu’aux data analysts et data scientists qui ont la charge de traiter ces données, les nettoyer, les mettre en forme, et enfin développer les use cases. Ces équipes sont généralement du côté digital et n’ont pas nécessairement la connaissance métiers, alors que les équipes métiers ne sont généralement pas sensibilisées à la problématique de la qualité de leurs données, et à l’importance de faciliter l’accès par des tiers. Le data mesh implique d’aller un cran plus loin, avec un product owner qui va responsabiliser les équipes métiers sur la qualité des données qu’elles produisent et sur leur capacité à exposer ces données. C’est un changement d’état d’esprit avec un impact fort d’un point de vue organisationnel sur la fédération et la gouvernance de la donnée. Il y a aussi des conséquences importantes en termes technologiques car les stacks et les architectures que l’on va devoir calquer sur ce modèle vont évoluer pour s’adapter à une gouvernance beaucoup plus décentralisée. Enfin, il faut savoir fédérer toutes ces démarches sur une plateforme technique qui va permettre de déployer une gouvernance à moindre coût. »
TÉMOIN – DAMIEN PICHOT, directeur des opérations et des flux marchandises chez Monoprix
Ce type de projet doit être porté par les métiers et fait pour les métiers
« Au moment de remplacer notre data warehouse on premise, nous avons souhaité créer une rupture et nous remettre en question. Nous avions fixé quatre objectifs : redonner la main aux métiers afin qu’ils soient autonomes, délivrer un service performant, baisser nos coûts de fonctionnement, et créer une plateforme de données unique qui mutualise les données issues du data warehouse et de notre data lake. Cela, afin de répondre aux enjeux business, décisionnel, de machine learning et data science. La réponse était clairement le cloud public. Nous avons été les premiers en France à effectuer une migration d’un data warehouse on premise vers Snowflake, l’usage étant souvent de commencer des nouveaux projets sur ce dernier. Notre architecture data a été lancée lors d’un kick off réunissant tous les métiers de l’entreprise, car il concerne tous les utilisateurs de la data, qu’ils soient au niveau de la supply chain, finance, marketing, achats, etc. Ce n’était pas un projet informatique, mais un projet d’entreprise. Un facteur clé de succès dans ce type de projet est qu’il doit être porté par les métiers et fait pour les métiers. »
