Comment accélérer le traitement de cas d’usage data toujours plus nombreux ? « En réunissant producteurs et consommateurs de données sur une plateforme », répond Michelin, précurseur sur le data mesh. Joris Nurit, head of data transformation, expose sa stratégie.

>> Cet article est extrait du carnet d’expériences à télécharger : Modernisation des plateformes de données : les meilleurs accélérateurs des grandes entreprises.

Qu’est-ce qui a motivé au départ l’intérêt de Michelin pour le data mesh ?

C’est un contexte. Historiquement, la construction de cas d’usage data, basée sur un framework très – trop ? – structuré, était longue et coûteuse. Parallèlement, les usages de la donnée se multipliaient, notamment à travers des demandes de self-service qui étaient satisfaites via du shadow IT. L’arrivée de l’IA a encore augmenté les besoins.

Voilà pour le volet data. Dans le même temps, Michelin vivait une transformation de ses SI. Nous passions d’un monde plutôt monolithique à des SI distribués, avec des interactions événementielles entre ces systèmes.

C’est donc ce contexte qui nous a amenés à rechercher un moyen de minimiser les overlaps entre ces différents consommateurs et producteurs de données ; deux populations dont la taille est croissante.

A lire aussi : Pour Arkéa, une Data plateforme hybride pensée pour des domaines et produits

Quelles réponses le data mesh apporte-t-il dans un tel écosystème ?

Sans rentrer dans la théorie du data mesh, l’idée de départ est de supporter le développement des échanges et d’accompagner la multiplication des use cases. Pour cela, on demande aux producteurs de se soucier de leurs consommateurs, de leurs données, et des moyens de les rendre accessibles.

Dans un second temps, et même si c’est le premier aspect que nous avons abordé, on définit une réponse technologique à la facilitation de ces échanges. Et c’est l’existence d’une plateforme, dont le but est bien de mettre en relation producteurs et consommateurs.

Cette approche, nous l’appliquons dans notre IT pour différents sujets. Comment ? Notamment en standardisant des mécanismes d’échange, dont l’exposition, le catalogage, l’expérience développeur, les outils… Cela vaut autant pour des cas d’usage industriels que d’ordre citizen.

Quels utilisateurs en priorité cible-t-elle ? Les data scientists ? Les data engineers ? Les citizen ?

Notre priorité a été de répondre aux attentes de nos data engineers et citizen developers / data analysts qui travaillent sur le monde de la data. Ce sont les deux populations que nous souhaitions servir en premier.

La demande des data scientists, en matière d’outillage sur la plateforme, était plus large. Nous ne l’avons pas adressée au départ. La première étape était de fournir du stockage, de la manipulation de données et de la visualisation. À présent, notre plateforme comprend une partie dédiée au data engineering, et une autre à la data science.

L’étape suivante consiste-t-elle à élargir la démarche à d’autres populations d’utilisateurs ? Ou bien les data analystes dans les métiers suffisent ils dans un rôle d’interface ?

Le métier de data analyst est une casquette que nous sommes tous amenés à porter. Il s’agit selon moi de plus en plus d’une compétence dont il faut disposer dans sa palette, et mobilisable à 5 % comme à 100 % du temps.

Notre volonté est de faire en sorte que tout employé Michelin, ait conscience qu’il peut consommer la donnée dans ses activités quotidiennes et endosser cette casquette de data analyst.

Pour cela, les populations utilisatrices doivent disposer d’une autonomie sur la plateforme. Pour chacune donc, un espace d’autonomie et la capacité de bénéficier des réalisations des autres.

Lors d’un précédent entretien, vous jugiez le pilier de la plateforme comme le plus important. Est-ce toujours le cas ?

Pour développer les échanges, il est nécessaire au préalable de bénéficier d’un lieu adapté. Nous avons débuté par la plateforme avec une équipe dont la mission consistait à fournir des services à d’autres équipes qui concevaient des cas d’usage. Pour cela, elle mettait à leur disposition un environnement technique, des workspaces où les développeurs de use cases retrouvaient tous les outils utiles.

Cette approche présente un effet de bord. Par la suite, lorsqu’on met en place une gouvernance métier, c’est tout un existant sur la plateforme qui leur apparaît non gouverné. C’est vrai. C’est la raison pour laquelle, la plateforme ne peut pas consister seulement à apporter des composants techniques.

Sur nos plateformes, nous avons aussi mis en place une organisation IT pour structurer les débuts de cette gouvernance sur les objets réutilisables. Nous avons déployé des rôles de data custodians qui s’assurent que la capture des métadonnées est bien effectuée : règles de nommage, identification des données sensibles, etc.

Une gouvernance IT au départ, et ensuite ?

Ce sur quoi nous travaillons actuellement, c’est sur la gouvernance métier. Elle a été définie et monte rapidement en maturité. Il lui faut à présent reprendre du grip et se lier à la gouvernance IT. Et cela ne signifie pas faire disparaître les data custodians.

L’exigence vis-à-vis des assets techniques demeure. L’IT conserve une responsabilité. Bien sûr, le métier peut l’accompagner et prendre une place croissante dans ce rôle.

Quelles briques technologiques sont fondamentales pour concrétiser la vision du data mesh ?

Une plateforme est une solution à un instant T. Cela ne peut pas être une réponse définitive. Une plateforme évolue constamment pour tenir compte de la maturité des composants et des attentes des utilisateurs.

Pour définir les briques essentielles, il faut en revenir à l’objectif, à savoir permettre des échanges et la création de use cases. Pour concevoir des produits, les utilisateurs ont besoin d’un espace à eux, un workspace personnalisé avec tous les bons outils connectés et sécurisés.

Le cloud et les composants PaaS aident beaucoup pour concevoir des workspaces indépendants, et dont les assets data sont faciles à interconnecter. Ensuite, la plateforme doit fournir les outils permettant l’utilisation (création de data pipelines, data visualization, data science…).

Dans le cas contraire, le premier réflexe de l’utilisateur sera de consommer la donnée ailleurs. Or, l’objectif est bien une consommation sur place pour que d’autres puissent aussi réutiliser les nouveaux assets créés.

Des offreurs poussent aussi la virtualisation comme brique de référence du data mesh. Qu’en pensez-vous ?

Nous regardons la data virtualisation, qui est une réponse adaptée dans certain cas. Mais elle peut se retrouver limitée car elle crée un point unique d’accès à la donnée basé sur la performance sous-jacente des systèmes virtualisés.

Notre priorité est d’aller vers un découplage stockage de la donnée et processing. Aussi, nous avons commencé par du CDC (change data capture) pour copier la donnée sous format fichier et ainsi permettre d’intégrer les données des précédentes solutions BI et applicatives dans notre plateforme.

Une transformation data, ce n’est pas faire table rase du passé et de nos investissements.