Pour générer des cas d’usages « métier » à partir de la donnée, il existe plusieurs stratégies. On parle de Data Mesh, Data Driven ou encore de Data Centric. Mais quelle approche viser ? Si l’approche Data Centric reste la plus pertinente, elle est entièrement complémentaire de l’approche Data Mesh. Interview croisée avec deux experts data chez JEMS.

Bonjour messieurs, est ce que vous pouvez vous présenter ?

Pascal DURY : Je suis vice-président chargé des questions de data management et de gouvernance. J’accompagne nos clients sur tout ce qui est détermination des organisations autour de la gouvernance de la donnée.

Anthony LIBOR :  Bonjour, je suis vice-président autour des offres IA et Analytics et j’aide nos clients dans le cadre de leur transformation SI et Data, pour servir leurs nouveaux usages autour de la donnée.

Pourriez-vous nous rappeler la différence entre Data Mesh et Data Centric ?

Anthony : L’approche Data Mesh, c’est un découpage d’une data platform par domaine métier. C’est très utile dans les grosses organisations où l’on est obligé d’avoir une approche itérative, et où on est tiré par les cas d’usage métier. Le Data Mesh favorise la distribution des responsabilités puisqu’en face d’un domaine de donnée, on va pouvoir définir des propriétaires et des processus. L’approche Data Centric vient en complément.

Pascal : Pour compléter ce que ce que dit Anthony, le Data Mesh, reprend les éléments de la conception Domain Driven Design. Ce n’est pas nouveau, c’est un rebranding de choses qui existent depuis quelques années déjà à savoir identifier les données et les organiser selon une vision en domaine où chaque domaine est responsable de son périmètre (RH, marketing production, etc.).

Qu’est-ce qu’une approche Data Centric ?

Pascal : L’approche Data Centric considère que la donnée n’est pas qu’un consommable, mais un actif de l’entreprise. Elle considère que chaque entreprise possède un asset data réutilisable et indépendant des usages pour lesquels il est destiné. Elle vise à standardiser l’information pour qu’elle puisse servir toutes les typologies d’usage aussi autour de la donnée, les tableaux de bords, les performances, l’usage de prédiction avec l’IA etc..

Faut-il avoir une approche Data Mesh puis Data Centric ou l’inverse ?

Pascal : Les deux sont complémentaires. Je m’explique : dans la terminologie JEMS être Data Driven, c’est prendre des décisions dirigées par la donnée ; je prends des données à leur source, je les applique pour mon cas d’usage et je les consomme. Et je referais la même chose demain pour un autre cas d’usage. C’est bien mais inefficace sur du long terme car on considère la donnée comme un consommable pas comme un actif clef de l’entreprise. Si vous adoptez une approche Data Mesh sans avoir d’approche Data Centric, les limitations seront les mêmes.

Il faut donc être Data Centric puis Data Mesh et éviter un maximum l’approche consumériste Data Driven.

On crée l’asset data qui sera ensuite consommé dans les usages par nature plus ou moins organisés en domaines. Si votre asset data est énorme, avoir une seule équipe pour le gérer devient très difficile et on va perdre en agilité. On va donc distribuer l’asset dans les différents domaines. On aura des objets qui seront transverses entre un ou deux domaines, voire entre tous les domaines, et d’autres qui seront mono-domaines : c’est l’approche Data Mesh.

Anthony : Je ne suis pas tout à fait d’accord.  Quand on construit une data platform on est forcément drivé par les cas d’usage issus des métiers.  Pour des raisons de financement principalement. On va organiser la donnée tel qu’on le fait de manière habituelle, par couche en suivant une organisation par domaine métier. C’est donc similaire à l’approche Data Mesh !

En revanche, il faut faire cet effort de capitalisation tout de suite pour penser des objets qui auront le maximum de réutilisabilité, et qui pourront être eux-mêmes enrichis par d’autres domaines. Et là oui je te rejoins : il faut avoir une approche Data Centric dès le départ, c’est la meilleure stratégie possible.

En termes de coût quelle est la meilleure approche ?

Pascal : Alors, il y aura un surcoût de passer du Data Mesh, puis Data Centric. Un surcoût qui est le même que quand on passe de Data Driven au Data Centric, c’est la même chose.

On a des exemples d’entreprises qui ont eu cette démarche et s’apercevaient qu’à long terme, l’approche Data Driven ne convenait pas et qui ont repris toute leur architecture de données. Je pense à Renault qui a reconstruit tout son architecture de données sur une approche de Data Centric à partir de laquelle ils construisent leur Data Products.

Quel dernier conseil pourriez-vous donner ?

Pascal: Le Data Mesh exige de poser les bases solides d’une gouvernance de la donnée. Dire que les métiers prennent la responsabilité de s’organiser comme ils le veulent, c’est planter les graines de l’anarchie au sein du système data. Dans 3 ans, on reviendra en arrière parce que ça ne marche pas.

Le Data Mesh, c’est l’application d’une gouvernance fédérée. Gouvernance fédérée, ça veut dire qu’au niveau central, on définit un cadre, les règles du jeu : ce qu’on peut faire et tout ce qu’on n’a pas le droit de faire. Une fois définies, les domaines utilisent ces règles et appliquent celles qui les concernent, adaptent certaines à leurs spécificités et on a quelque chose qui va fonctionner. C’est fondamental.

Anthony:  La tendance d’évolution des SI, avec l’apparition des architectures de Microservices c’est de s’inscrire dans une démarche de modularité et d’élémentarité des composants qu’on met en place pour servir des usages type comme l’IA ou des applications digitales qui vont consommer des données issues de plateformes data.

Mon conseil, c’est de s’inscrire dans une vision marketplace du patrimoine de données, où l’on va construire des comptoirs de données, modulaires, qui vont servir ces usages.
Mais pour avoir le meilleur Time to Market, il faut faire ce travail de capitalisation et de réutilisabilité de l’asset en déterminant les bons objets d’entreprises.

« Le produit a une durée de vie limitée. Votre asset data n’en a pas, il est immortel. »