Retour d'expérience sur la construction de la Data Platform Mirakl

0:10 Bonjour, je suis ravi d'être avec vous pour vous parler de la construction de la data platform Mirakl. Ce talk n'a pas pour objectif de vous dire comment faire, mais juste humblement de vous expliquer comment nous on a fait, par quelles étapes on est passé, nos succès, nos échecs et ce qui a finalement fonctionné pour nous. Alors d'abord, quelques mots sur moi. Je suis Head of Data chez Mirakl, mais ça fait très longtemps que je travaille chez Mirakl. Ça fait maintenant 7 ans. Je suis passé par des rôles au niveau produit et engineering, donc management d'équipe technique et aussi des responsabilités au niveau produit sur certains périmètres. Et depuis un peu plus d'un an, je suis à temps plein vraiment sur la partie data, même si l'équipe data, en fait, je l'avais créée il y a un peu plus longtemps. Donc quelques mots sur Mirakl. Donc Mirakl, c'est une société qui a 10 ans maintenant. Donc nous, en fait, on est une solution SaaS de marketplace.

1:12 C'est-à-dire qu'on est une solution back-office qui va s'intégrer avec les solutions e-commerce pour les transformer en marketplace. Donc leur permettre d'accueillir des vendeurs tiers qui vont vendre leurs produits sur un site e-commerce. Donc parmi les grosses marketplaces françaises, par exemple, sur lesquelles vous achetez, Alors, il y en a beaucoup, plus de la moitié, où c'est du Mirakl derrière. Mais on a aussi pas mal de clients dans le monde entier. Donc au Canada, on a Best Buy par exemple, Catch Group en Australie, Kroger aux Etats-Unis, Messis, qui a lancé sa marketplace récemment avec Mirakl, et aussi pas mal d'acteurs du B2B. Comme Toyota, par exemple, pour tout ce qui est pièces de leur chariot élévateur, utilise une marketplace Mirakl. Donc c'est ce que je vous expliquais. Mirakl, c'est vraiment une solution back-office qui va faire l'intermédiation entre des vendeurs qui veulent vendre sur un site e-commerce et l'opérateur du site e-commerce. Donc toutes ces intégrations, ça se passe par des API et aussi des outils back-office.

2:15 Donc un back-office pour les vendeurs, un back-office pour les opérateurs qui leur permettent de gérer leur marketplace. Donc, il y a trois ans, notre CEO, Philippe Corot, m'a demandé de créer cette équipe data. Il avait une forte conviction qu'il y avait des choses à faire avec la data qui était brassée par Mirakl. Donc, on a réfléchi pour savoir, c'est vrai qu'on a beaucoup de data, mais... Qu'est-ce qu'on pouvait en faire? Qu'est-ce qu'on pouvait en faire concrètement pour améliorer Mirakl? On est arrivé un petit peu sur ces trois objectifs. Ce sont les objectifs de départ. Automatiser le... plus possible les tâches manuelles au sein de nos marketplaces, donc pour les vendeurs, pour les opérateurs de marketplaces, aider nos clients à doper leur chiffre de vente sur leur marketplace. En fait, Mirakl, on a un modèle qui est aligné sur le succès de nos clients, donc c'est intéressant pour nos clients comme pour nous de faire du chiffre sur ces marketplaces.

3:24 Et très important, garantir la sécurité des utilisateurs et des transactions. Donc quelques exemples de cas d'utilisation qu'on adresse chez Mirakl autour de la data science. Donc il y a tout ce qui est catégorisation automatique de produits. Donc les vendeurs arrivent avec des produits, il faut les classer pour qu'ils soient bien rangés sur le site e-commerce. Donc pour ça, on va s'appuyer sur les données textuelles, les images des produits. Donc assez lié aussi au catalogue, tout ce qui est mapping automatique des catalogues produits. Donc là, les vendeurs arrivent sur les marketplaces avec des fichiers plats en général, où il y a leurs données produits et il faut arriver à automatiquement mapper les données de ces fichiers sur la taxonomie qui est attendue par le e-commerçant. Donc s'adapter à ses catégories, à sa liste de couleurs, à sa liste d'attributs, etc. Un autre exemple là où on va utiliser du NLP sur les messages qui sont échangés entre les clients, les clients finaux de la...

4:30 la marketplace et les vendeurs. Donc ça, ce sont des use cases qui permettent à l'opérateur de la marketplace de monitorer la qualité de service. Donc que les vendeurs se comportent bien, adressent bien les besoins des clients et surtout les plus critiques. Et un dernier exemple, tout ce qui est détection d'anomalies, de comportement des vendeurs. Ce sont des use cases qui sont liés à la sécurité, mais pas que. Ça peut être, par exemple, d'un seul coup, la moitié du catalogue d'un vendeur disparaît. Donc, il faut savoir pourquoi. Donc, on va essayer de détecter. ces anomalies et de remonter le plus d'informations possibles pour expliquer les raisons de cette anomalie afin de la corriger le plus rapidement possible. Donc c'est ce genre de use case qu'on va outiller au sein de notre data platform. Alors, le cycle de vie de ces projets de data science, en général, c'est assez classique. Il y a tout ce qui est définition du use case. On va collaborer avec les équipes produits pour définir quel est le use case, les KPI cibles, quels problèmes on cherche à résoudre.

5:31 Il y a une phase de discovery. Donc là, c'est plutôt les data scientists qui vont faire l'inventaire des données qu'ils peuvent utiliser pour le use case. Ils vont tester des algorithmes, faire des simulations, faire des dashboards pour présenter les résultats, etc. Et quand on est satisfait du résultat, on passe à la partie industrialisation, où là, il y a des pipelines, donc pipelines de préparation de données, d'apprentissage de modèles, en général, quand on fait appel à du machine learning, et pipelines d'inférence, donc synchrone, asynchrone, ça dépend. Et ensuite, il y a la partie intégration, où une fois qu'on a des algorithmes qui sont capables de faire de l'inférence sur un use case, il va falloir intégrer ça dans le produit. Donc nous, ce sont des applicatifs Java, développeurs microservices avec du React en front. Et suivant que ce soit synchrone ou asynchrone, ça va être des stratégies d'intégration différentes, par API, par message Kafka, par fichier plat, etc. Et enfin, très important, le monitoring. Donc plusieurs... plusieurs monitorings, l'utilisation, le drift des modèles, les KPI, donc est-ce qu'on répond vraiment aux besoins, est-ce qu'on améliore les choses, etc.

6:41 Et éventuellement aussi des boucles de rétroaction. Donc en fonction des actions des utilisateurs, on peut réinjecter ça dans les modèles pour les améliorer. Et en fait, il y a trois ans, j'ai créé cette équipe data. Et assez rapidement, on a cherché des solutions. Alors au début, notre besoin était assez simple. Donc les data scientists, traditionnellement, ils travaillent avec des notebooks. Pour leurs expérimentations locales sur leur machine. Et assez rapidement, il leur faut des capacités de calcul pour faire tourner les algorithmes. Et donc là, en général, dans toutes les équipes data, il y a des data engineers qui vont mettre en place des frameworks pour pouvoir justement donner aux data scientists cette capacité de calcul et pouvoir travailler sur des architectures cibles selon les besoins. Par exemple, nous, on fait pas mal d'images avec les images produits et des use cases pour lesquels, par exemple, il faut du GPU. Et donc, voilà, ce sont des choses qui ne sont pas forcément faciles à provisionner de façon automatique. Et en gros, par relation, on nous a présenté Databricks et on a trouvé leur produit intéressant de ce point de vue-là.

7:45 Justement, c'est une solution qui permet de mettre à disposition de la capacité de calcul, des clusters Spark, on choisit l'architecture, ça tourne sur notre propre cloud. Donc ça, ça nous intéressait et aussi toute la partie notebook collaboratif. où on se disait que plutôt que d'avoir des data scientists qui travaillent tous sur leur coin, sur leur notebook, qui se partagent les notebooks, ce n'est pas forcément évident, etc. Là, on avait un environnement de travail vraiment intégré avec la capacité de calcul directement à côté. Donc c'est pour ça qu'on a pris Databricks au début et en fait quelque part, on s'en servait surtout pour la partie discovery. Quand il a fallu mettre nos premiers use cases de machine learning en prod, je crois que c'était sur la catégorisation, Là, en fait, ce qu'on a fait, c'est qu'on s'est plutôt orienté sur les solutions qui étaient fournies par nos cloud providers. Donc, un de nos cloud providers proposait du Spark Manager.

8:45 Donc, on a fait... On a choisi ça. Pour tout ce qui était sourcing de données, En fait, on ne tapait pas directement sur les systèmes en production, mais on tapait déjà sur le... On avait un Cloud Data Warehouse qui était déjà en place pour des besoins de BI. Il y a une très grosse équipe Customer Success chez Mirakl. Et donc, c'était de l'inférence batch. L'intégration, c'était par Cloud File Storage. Donc, on déposait des fichiers sur des buckets comme ça. C'était récupéré par l'applicatif. C'était de la synchrone et tout allait bien. En fait, tout allait bien jusqu'à une certaine mesure. En fait, à l'usage, on a rencontré pas mal de problèmes d'instabilité des pipelines. Disons qu'on était... pas tout à fait satisfait justement de cette solution de Spark Manager. Et donc on a commencé à tester ce que ça pouvait donner sur Databricks. Et c'est vrai que là, les problèmes de stabilité ont disparu. Alors après, c'est un petit peu normal parce que quelque part, c'est l'éditeur de la solution Spark.

9:48 Donc on peut se dire qu'on a accès aux versions plus récentes avec les bugs fixes, etc. Mais donc en tout cas, quelque chose qui occupait un data scientist quasiment à mi-temps, sur l'année, donc surveiller les pipelines à chaque fois que ça casse, aller voir, investiguer pourquoi, etc. Là, voilà, ça nous a libéré du temps là-dessus. Alors, on avait aussi des problèmes au niveau du monitoring des données. Et ça, en fait, on l'a réglé en utilisant MLflow. Donc, MLflow, c'est une solution open source qui est aussi poussée par Databricks, assez bien intégrée dans la solution. Et donc, ça, c'est une repository de modèles. Donc ça permet vraiment d'archiver les modèles à un endroit unique, de monitorer aussi leur exécution, c'est-à-dire qu'à chaque fois qu'il y a une exécution de modèle, on peut sauvegarder les résultats sous forme d'experiment, ce qui permet de monitorer justement le draft et assez facilement de faire des dashboards qui vont justement donner les KPI, la performance, etc.

10:58 Donc voilà, on sait aussi, on a changé nos pipelines de prod pour passer justement sur du Spark managé par Databricks et avec MLflow. Et aussi, avant on utilisait du parquet standard. Des fichiers par cas standard. On a fait un petit benchmark pour voir les différents formats. Alors, il y avait Iceberg, Woody et Delta Lake. Et on sait, après quelques itères, hésitation entre Woody et DeltaLake. Finalement, on a pris DeltaLake. Alors, à l'époque, il y avait une petite crainte parce que le format n'était pas complètement open source. Il y avait certaines features du format, comme les Z-index, par exemple, qui n'étaient pas dans la version open source, qui n'étaient pas gérées dans la version open source de Spark. Mais depuis, en fait, on n'a plus à avoir ces craintes parce que c'est entièrement open source. Donc voilà.

12:00 Alors, ensuite, en fait, on a eu nos premiers cas, nos premiers use cases d'inférence temps réel. Donc là, justement, c'est sur le use case de mapping que je vous présentais un petit peu avant. Donc là, vraiment, il y a un utilisateur qui est dans le back office Mirakl, qui charge son fichier et il doit mapper ses données. Et donc, l'objectif de l'algorithme de machine learning, c'est de lui faire des propositions. Donc, de mapper ses catégories, ses attributs, ses couleurs, etc. Donc là, il faut réagir en temps réel. Donc, en fait, on a essayé aussi des choses qui étaient fournies par les cloud providers. On n'a pas été entièrement satisfait, surtout par la complexité de mise en œuvre de ces solutions. Finalement, on a essayé des frameworks open source. On est assez satisfait avec un framework qui s'appelait Cortex, qui permettait d'exposer facilement par API des modèles de machine learning. Donc on a commencé à partir là-dessus, c'était pas mal. Donc on a fait un micro-service d'inférence qu'on mettait dans notre... dans nos clusters Kubernetes.

13:03 Et finalement, ce microservice Cortex, on l'a même fait évoluer pour ajouter des stratégies de caching de modèles. Afin d'optimiser les ressources, parce qu'on n'allait pas provisionner un modèle pour chacun de nos clients. L'objectif, c'était, comme ce sont des actions de métier qui n'ont pas lieu tout le temps, c'était de récupérer dynamiquement les modèles d'MLflow, les mettre en cache pour toute la durée d'utilisation de la session, et ensuite de les offloader comme ça. Et donc, on est assez satisfait de cette solution. Donc ce micro-service, on l'a aussi intégré avec MLflow, ce qui fait qu'on garde le bénéfice de toute la partie monitoring, c'est-à-dire qu'on va logger vraiment tous les experiments dans MLflow. Donc l'étape d'après, alors là c'est vraiment... En fait, jusqu'ici on était content de notre solution, mais de plus en plus, plus on multipliait les use cases, plus on s'apercevait qu'on avait quand même pas mal de problèmes au niveau de l'ingestion.

14:04 Donc ce que je vous ai montré, c'est que pour l'ingestion, on se proposait sur des pipelines existants qui avaient été faits par la BI. Donc il y avait une ingestion comme ça par batch dans un cloud data warehouse. Et en fait, c'était cette partie-là vraiment qui commençait à nous limiter, en particulier sur la fiabilité des données. Donc d'un jour à l'autre, il y avait les données, par exemple, nos clients, les appels d'étonnantes, les données d'un tenant qui pouvait ne pas être disponible. ou incomplète et donc c'était un petit peu compliqué pour nos use cases. Il y avait des problèmes de charge au niveau du Cloud Data Warehouse aussi, parce que parfois on avait des algorithmes qui tapaient assez fort sur le Cloud Data Warehouse et ce qui pouvait perturber les activités des équipes Customer Success qui se reposent beaucoup sur la BI. Et aussi, surtout, des problèmes de fraîcheur de données. Donc les données dans le Cloud Data Warehouse étaient ingérées par batch. Et pour certains use cases, comme je vous ai montré par exemple le NLP sur les messages, sont des use cases pour lesquels on a envie de réagir très rapidement, le plus vite possible.

15:07 Ou alors tout ce qui est monitoring, la sécurité, on a envie vraiment d'avoir des délais de réaction très courts. Donc on voulait vraiment se rapprocher du real time. Donc on s'est dit, ce qu'on va faire c'est... On va faire notre propre ETL, donc ne plus être dépendant du Cloud Data Warehouse et ingérer directement les données dans Databricks. Donc c'est ce qu'on a fait. Alors, au moins, on avait la maîtrise de la fréquence de rafraîchissement des données, c'est-à-dire qu'on pouvait lancer les batchs un peu comme on voulait, mais ça restait du batch. Et donc, entre-temps, l'équipe data a grossi, on a gagné une certaine visibilité au sein de Mirakl, et de plus en plus de besoins se sont fait sentir. Donc les premiers utilisateurs pour nous, c'était les data scientists. Donc ça, ça ne change pas. Donc ils ont besoin d'accéder à des sources de données consolidées, fiables et quasi temps réel.

16:12 Donc on a de nouveaux besoins pour lesquels on avait aussi la nécessité d'intégrer des sources de données externes. Pensez par exemple à des données de marché dont l'e-commerce est très important, savoir si des prix sont compétitifs, des choses comme ça. Et donc moi j'avais un objectif aussi pour l'équipe, c'était d'accélérer accélérer ce que j'appelle le time to feature, c'est-à-dire de la définition du use case avec l'équipe produit jusqu'à la mise en production. Sur les premiers projets, on a vu que ça pouvait être assez long quand même. Alors côté produit et tech, donc simplifier l'intégration des algorithmes de data science, à chaque fois en fait on se réunissait, on se demandait comment on va intégrer celui-là, est-ce que c'est du fichier, est-ce qu'on met à disposition un API, etc. L'équipe produit, sachant que... Toute la littérature, était influencée par toute la littérature autour des data products. Donc ce sont des réflexions aussi.

17:13 Donc on se disait qu'il y a peut-être l'opportunité de lancer justement de nouveaux data products. Il y a des besoins transverses aussi qu'on pourrait adresser avec une approche data. Je pense à tout ce qui est historisation. Donc l'historisation des données dans une application comme Mirakl, ça peut peser assez lourd sur les bases de données. On n'a pas forcément envie d'encombrer les bases de données de prod avec des données historisées, surtout pour certaines entités qui vont être mises à jour à haute fréquence. Je pense par exemple au prix, où il y a des vendeurs qui utilisent des moteurs de repricing. Ils peuvent avoir plusieurs centaines de milliers d'offres. Et sur ces centaines de milliers d'offres, ils vont faire des dizaines de mises à jour de prix par jour. Pour s'aligner sur la concurrence. Et comme ils utilisent tous des solutions, de repricing, vous voyez, ça se met à jouer en cascade. Donc, historiser tout ça dans l'applicatif, ce n'est pas raisonnable. Et on se disait qu'on pouvait fournir aussi, nous, Equidata, une solution pour cette historisation. Après, il y a évidemment tout ce qui est calcul de KPI, etc.

18:17 Pour les équipes Customer Success, eux, ce qui les intéresse, c'est la BI. Et donc, comme nous, on a besoin de données plus fiables, plus fraîches, Eux, c'est pareil. Et aussi, ils étaient intéressés par nos sources de données externes. Et il y a des besoins aussi adressés pour la finance. Alors, pas seulement des besoins. Alors, il y a les besoins pour la facturation de Mirakl, monitorer les usages, faire des nouveaux business models qui se reposent justement sur des métriques d'usage. Mais il y a aussi, par exemple, l'optimisation de nos ressources cloud. C'est un use case aussi intéressant pour une data platform. Donc, ce qui nous a amené, en fait, à discuter avec Databricks et à voir ce qu'ils avaient à proposer là-dessus. Et ce qu'ils nous ont recommandé, c'est un peu de regarder les architectures de type Lakehouse. Donc, essayer de consolider toutes les données dans Databricks, en plusieurs stages. Je ne sais pas si vous êtes familier de cette littérature, mais traditionnellement, il y a plusieurs stages.

19:21 Il y a un stage bronze, où ce sont un peu les données de base, vraiment les données brutes qui viennent des systèmes. Donc c'est la couche qu'il faut fiabiliser au maximum. Donc toutes les données arrivent ici. Elles ne sont pas traitées, elles sont stockées telles quelles. Alors ça peut être aussi bien des données de production, des images, des données issues de tables, etc. Ensuite, il y a une couche silver où on va reconstituer des données de façon exploitable. Et une couche gold où là on va faire vraiment des agrégations destinées aux clients pour la bille. pour les use cases de machine learning, ça peut être de l'enrichissement par du machine learning, etc. Donc, c'est quelque chose qui nous a pas mal parlé. Et il se trouve que je suivais pas mal aussi le blog d'Ypon, que je vous recommande, qui parle pas mal de sujets data platform, etc. Et de Databricks. Et donc, j'en suis venu à discuter avec Ypon, qui avait une expérience comme ça.

20:28 Ils avaient monté des data platforms pour plusieurs entreprises comparables en SaaS. Donc, on a discuté un petit peu des use cases. Au niveau de l'ingestion, ce qu'on voulait mettre en place, c'était du Debesium. Alors, Debesium, c'est une techno qui se branche directement sur les bases de données. Alors, c'est compatible avec plein de bases. Chez nous, c'est essentiellement du Postgres. Mais en gros, ça va se plugger sur le mécanisme de réplication de la base. C'est le cas pour Postgres. Ce qui fait qu'à chaque fois qu'un événement va se passer sur la base de données, le rôle de Debesium, c'est de transformer ça en événement Kafka. Donc nous, ça, ça nous intéressait parce que je ne voulais pas demander en fait à chaque... Honor de microservices, de nous développer des messages Kafka à nous envoyer pour qu'on puisse les intercepter et les mettre dans la data platform. Ils ont tous des roadmaps super chargés et ça ne semblait pas possible à ce moment-là. Donc il fallait qu'on soit un petit peu indépendant et qu'on puisse récupérer la donnée qu'on voulait.

21:30 sans impliquer justement les équipes de développement. Donc c'est ce que nous permettait Debezium. Donc c'est ce qu'on a mis en place sur ce projet. Et donc, en fait, l'architecture de la data platform qu'on a mis en prod récemment, c'est un peu celle-là. En gros, si vous voulez, on a à côté de nos tenues de production, de nos systèmes de production qui sont dans chacun des... On a les trois cloud providers, AWS, GCP et Azure. Donc on a une base de données par tenant. Donc c'est ça la particularité un peu de Mirakl, c'est les données vraiment de chaque client sont segmentées dans leur propre base. Donc on a fait des microservices sur la base de Debezium en standalone, qui vont écouter tous les événements qui se passent sur ces bases, les transformer en messages Kafka. Et c'est à partir de là que nous, on va faire l'ingestion dans la data platform. Donc, on utilise du Spark Streaming.

22:33 Donc, ça va dépiler les messages Kafka, les mettre dans notre stage bronze, donc tel quel, tel qu'ils sont produits par Debezium, sans modification. Ça ingère tous les messages qui se passent sur les bases. À partir de là, en fait, on a aussi en Spark Streaming, on va peupler le stage Silver. Donc le stage silver, là, à partir de là, des données brutes, on reconstitue l'état exact des bases de prod, plus un état historisé. C'est-à-dire que pour chaque modification de ligne, on va la garder dans la table historisée. Donc avec le pattern SCD2 qui permet de faire des queries, en fait, on peut faire une query et retrouver l'état exact de la base à une date donnée. Donc ça, c'est vachement intéressant pour certains use cases. En particulier pour nous, c'est tout ce qui est monitoring des prix. Donc vérifier que des discounts sont de vrais discounts, détecter des anomalies de prix, des choses comme ça.

23:39 C'est vraiment très, très intéressant. Et après, on a un stage gold. Où là, alors juste sur les deux premières étapes, tout est automatique. En fait, dans le système, on a juste à configurer les tables qui nous intéressent en production. Et normalement, justement, le travail qu'on a fait, c'est que tout ça, c'est automatique. Automatiquement, on va se retrouver avec, dans le stage silver, une table snapshot, donc l'état courant de la base, et une table historisée. Avec tous les états. Donc ça, on n'a rien à faire. On a juste... Non, même pas. Rien à faire. Et ensuite, on a le stage gold, où là, en revanche, il y a du développement. Donc, selon les besoins. Donc, pour des besoins BI, on va échanger avec les business analystes. On va se demander qu'est-ce qui vous intéresse, comment vous voulez la donner. Et donc, là, il y a du développement. Alors, c'est soit du SQL. soit du Spark, qui va retraiter les données de façon à les mettre en forme pour des analyses BI. On a par ailleurs d'autres, évidemment à la base nous on faisait ça pour la data science, donc tout ce qui est extraction de features avec des algorithmes ou quoi, ça passe par là.

24:49 Et pour nous ce sont des tables gold. Donc toutes les tables de features pour le machine learning, ça va être des tables gold. Et ce qui fait qu'en fait, tous nos pipelines de machine learning ont On les plug sur des tables gold. Donc, ils vont récupérer les données à partir des tables gold ou parfois silver. On va apprendre les modèles à partir de là. Et tout ce qui est inférence, en fait, ça va aussi cracher les données dans les tables gold. Et ensuite, l'avantage aussi de cette solution, c'est qu'au niveau intégration avec les produits, là on a, disons que les microservices de production de Mirakl peuvent s'intégrer directement à la data platform avec un driver JDBC, ils peuvent interroger les tables et prendre vraiment ce dont ils ont besoin. Et au passage aussi, on a revu un petit peu l'intégration avec le Cloud Data Warehouse.

25:53 Donc comme je vous disais, l'ingestion dans le Cloud Data Warehouse n'était pas très fiable. Et donc on a inversé en fait la dépendance et maintenant c'est la data platform qui alimente le Cloud Data Warehouse. Donc, c'est un petit slide. Alors, Ypron ne m'a pas payé pour ça, mais je le fais avec plaisir parce qu'on a une collaboration. Une collaboration qui fonctionne assez bien. Donc voilà, je vous invite à faire appel à la Data Practice Ypron. C'est une vraie data practice, c'est-à-dire que régulièrement, ils me sortent mes consultants de mission pour qu'ils fassent des journées d'échange. Donc, ça ne fait pas toujours plaisir, mais en même temps, on en tire des bénéfices. Donc, ils ont une expérience multi-cloud et surtout, des compétences très fortes sur la solution Databricks. Alors, le futur. Jusqu'ici, on est content de la data platform, mais du coup, on a plein de projets. Donc, ça a levé certains verrous et ça nous permet de faire pas mal de choses.

26:55 Alors déjà, avant de parler de ce qu'on va faire, des choses formidables qu'on va pouvoir faire à partir de cette data platform, on a encore du pain sur la planche, donc la gestion d'autres produits Mirakl. Mirakl, ce n'est pas un seul produit, en fait, on en a d'autres. Récemment, on a annoncé une solution DATS. dats pour les marketplaces et de retail media. Et donc toutes ces données, il va falloir aussi les ingérer dans la data platform. Alors peut-être qu'on n'utilisera pas forcément la même technologie, peut-être que ce ne sera pas avec des Béziers, peut-être que ce sera directement à partir des messages Kafka, je ne sais pas, il faut qu'on voit. L'ingestion de données externes, alors ça on a déjà commencé, on a déjà des services, par exemple pour tout ce qui est taux de conversion, donc ça c'est très utile pour la BI et pour beaucoup de use case, pour rendre les choses comparables. Donc là par exemple on s'intègre avec Currency Layer directement dans la plateforme, tous les jours on va chercher les nouveaux taux, ce sont des tables delta dedans et donc on peut faire des jointures, des conversions justement pour faire de nouvelles tables gold.

27:58 Les données de marché, donc là on a plusieurs projets aussi pour récupérer des données de trafic sur différentes marketplaces, etc. Après, au niveau Databricks en lui-même, il y a toute la partie gouvernance qu'on a volontairement laissé de côté pour l'instant. Donc le but vraiment c'était d'avancer rapidement et on se dit de toute façon, est-ce qu'on peut le faire plus tard? La réponse est oui. Et donc là on va s'y attaquer. Donc Unity Catalog, ça nous semble une solution assez prometteuse pour faire ça. Donc côté Databricks, c'est la solution qui va permettre de gérer de façon unifiée les utilisateurs sur les différents workspaces. Ça va permettre aussi de mettre de la gouvernance sur les tables. Donc qui a accès à quoi? Plus tard, ils vont même aller jusqu'au releu. Level security, c'est-à-dire qu'on va pouvoir même donner des accès seulement à certains rôles dans une table, etc. Et ça gère aussi toute la traçabilité, parce que quand on commence à avoir beaucoup de transformations, parfois c'est compliqué de savoir d'où vient une erreur.

29:02 Alors l'inférence temps réel, c'est un framework maison. Personnellement, tout ce qui est framework maison, j'ai toujours une petite méfiance par rapport à la maintenance dans le temps. Les gens viennent, repartent, etc. J'aimerais bien avoir une solution un peu plus industrialisée et supportée pour l'inférence. Donc ça, j'attends de voir ce que propose Databricks pour ça. On utilise pas mal Airflow pour tout ce qui est orchestration de nos pipelines. Ça, c'est pareil, c'est une solution tierce. On l'utilise de façon managée, ça coûte de l'argent. Peut-être que c'est plus intéressant avec Databricks depuis qu'ils ont musclé leur moteur de workflow. Donc ça, on ne l'a pas encore évalué, mais on va regarder. Et après, il y a... Pour tout ce qui est Discovery, mais côté équipe produit, Donc, ils ont besoin d'accéder aux données, ils ont besoin de cruncher les données, de calculer leur propre KPI, etc.

30:06 L'équipe produit chez nous aime bien Metabase, juste pour les fonctions collaboratives autour de la data. Ça permet de créer des queries, les partager, etc. Et ils aiment bien l'outil. Donc on a vu qu'il n'y avait pas de problème à le brancher directement sur Databricks. Donc c'est probablement ce qu'on va faire. Et donc tout ça, surtout, ça nous permet vraiment de créer de nouveaux data products. Alors il y a plein d'idées, en particulier autour de l'analytics. Donc à partir du moment où on a une data platform, on a des SQL endpoints, ce qui s'appelle SQL Warehouse maintenant, Databricks, qui permet d'y accéder facilement et de façon assez optimisée. En fait, ce sont des endpoints serverless. Donc, c'est facile à scaler, c'est disponible tout de suite. Et quand il n'y a pas de trafic, ils s'éteignent tout seuls, ce qui fait qu'on minimise les coûts. Donc ça, c'est intéressant justement pour faire des data products, donc de l'analytics à destination des vendeurs marketplace, des opérateurs marketplace, peut-être de tiers avec du revenu cher ou quelque chose comme ça avec les propriétaires de la donnée.

31:11 Donc on réfléchit à ce genre de choses. Il y a un truc qui nous intéresse aussi, c'est le delta sharing. Donc ça, c'est la possibilité de partager facilement les données avec un peu qui on veut. Et donc nous, on commencerait évidemment par les opérateurs de la marketplace pour leur donner un accès facile à leurs propres données qui sont en Mirakl. Jusqu'ici, on a une data plateforme, on a des SQL endpoints, ce qui s'appelle SQL Warehouse maintenant, Databricks, qui permet d'y accéder facilement et de façon assez optimisée. En fait, ce sont des endpoints serverless. Donc, c'est facile à scaler, c'est disponible tout de suite. Et quand il n'y a pas de trafic, ils s'éteignent tout seuls, ce qui fait qu'on minimise les coûts. Donc ça, c'est intéressant justement pour faire des data products, donc de l'analytics à destination des vendeurs marketplace, des opérateurs marketplace, peut-être de tiers avec du revenu cher ou quelque chose comme ça avec les propriétaires de la donnée. Donc on réfléchit à ce genre de choses. Il y a un truc qui nous intéresse aussi, c'est le delta sharing.

32:12 Donc ça, c'est la possibilité de partager facilement les données avec un peu qui on veut. Et donc nous, on commencerait évidemment par les opérateurs de la marketplace pour leur donner un accès facile à leurs propres données qui sont en Mirakl. Jusqu'ici, on a une data plateforme, on a des SQL endpoints, ce qui s'appelle SQL Warehouse maintenant, Databricks, qui permet d'y accéder facilement et de façon assez optimisée. En fait, ce sont des endpoints serverless. Donc, c'est facile à scaler, c'est disponible tout de suite. Et quand il n'y a pas de trafic, ils s'éteignent tout seuls, ce qui fait qu'on minimise les coûts. Donc ça, c'est intéressant justement pour faire des data products, donc de l'analytics à destination des vendeurs marketplace, des opérateurs marketplace, peut-être de tiers avec du revenu cher ou quelque chose comme ça avec les propriétaires de la donnée. Donc on réfléchit à ce genre de choses. Il y a un truc qui nous intéresse aussi, c'est le delta sharing. Donc ça, c'est la possibilité de partager facilement les données avec un peu qui on veut. Et donc nous, on commencerait évidemment par les opérateurs de la marketplace pour leur donner un accès facile à leurs propres données qui sont en Mirakl.

33:17 Jusqu'ici, on a une data plateforme, on a des SQL endpoints, ce qui s'appelle SQL Warehouse maintenant, Databricks, qui permet d'y accéder facilement et de façon assez optimisée. En fait, ce sont des endpoints serverless. Donc, c'est facile à scaler, c'est disponible tout de suite. Et quand il n'y a pas de trafic, ils s'éteignent tout seuls, ce qui fait qu'on minimise les coûts. Donc ça, c'est intéressant justement pour faire des data products, donc de l'analytics à destination des vendeurs marketplace, des opérateurs marketplace, peut-être de tiers avec du revenu cher ou quelque chose comme ça avec les propriétaires de la donnée. Donc on réfléchit à ce genre de choses. Il y a un truc qui nous intéresse aussi, c'est le delta sharing. Donc ça, c'est la possibilité de partager facilement les données avec un peu qui on veut. Et donc nous, on commencerait évidemment par les opérateurs de la marketplace pour leur donner un accès facile à leurs propres données qui sont en Mirakl. Jusqu'ici, on a une data plateforme, on a des SQL endpoints, ce qui s'appelle SQL Warehouse maintenant, Databricks, qui permet d'y accéder facilement et de façon assez optimisée. En fait, ce sont des endpoints serverless. Donc, c'est facile à scaler, c'est disponible tout de suite.

34:21 Et quand il n'y a pas de trafic, ils s'éteignent tout seuls, ce qui fait qu'on minimise les coûts. Donc ça, c'est intéressant justement pour faire des data products, donc de l'analytics à destination des vendeurs marketplace, des opérateurs marketplace, peut-être de tiers avec du revenu cher ou quelque chose comme ça avec les propriétaires de la donnée. Donc on réfléchit à ce genre de choses. Il y a un truc qui nous intéresse aussi, c'est le delta sharing. Donc ça, c'est la possibilité de partager facilement les données avec un peu qui on veut. Et donc nous, on commencerait évidemment par les opérateurs de la marketplace pour leur donner un accès facile à leurs propres données qui sont en Mirakl. Jusqu'ici, on a une data plateforme, on a des SQL endpoints, ce qui s'appelle SQL Warehouse maintenant, Databricks, qui permet d'y accéder facilement et de façon assez optimisée. Ici, ça fonctionne avec des API. Donc, ce n'est pas forcément flexible. Ils n'ont pas toutes les données qu'ils voudraient. Il faut que ce soit couvert par l'API. Là, on pourrait beaucoup plus facilement, par exemple, crafter des tables gold pour leurs besoins et leur donner accès en delta sharing de façon sécurisée. Donc ça, ça pourrait être aussi un data product intéressant. Voilà. Alors, juste un petit slide pour vous parler des enseignements vraiment que je juge importants par rapport à ces projets chez Mirakl. Alors le premier, c'est que ces projets de data ou de data platform, pour moi, ce sont des projets d'engineering comme les autres. En fait, je n'ai pas traité cette data platform de façon particulière. Il y avait un backlog, on a défini nos clients, la valeur métier de chaque évolution. Au niveau des pratiques de développement, c'est pareil. Alors nous, c'est vrai qu'on est... On est très code-centrique pour tout. On n'aime pas le clic-clic. Donc tout est terraformé. Il y a des tests automatiques. Il y a un workflow de pull request. Où à chaque fois qu'on modifie même une table gold, on fait des shallow copies des données, on teste. On teste les pipelines et on vérifie que c'est bon. Et c'est uniquement quand on merge que la nouvelle version de la table Gold est disponible. Donc voilà, c'est un projet comme les autres, vraiment comme les autres. L'équipe, très important. Alors moi, j'ai trouvé mon bonheur en interne, parce qu'on avait quand même des gens, et chez Ypon. Il y avait une bonne équipe avec des compétences solides. En Databricks, en Spark, etc. Et surtout, et aussi, je veux dire, sur les cloud providers, c'est important. Donc ça, c'est mon point suivant. On a pas mal patiné au début parce qu'on n'avait pas de profil DevOps dédié dans l'équipe. Donc ça, c'était un petit peu compliqué parce que du coup, on se reposait sur les équipes partagées, donc l'équipe SRE, dont la mission première est de garantir la disponibilité de nos applications pour nos clients. Donc nos projets, quelque part, c'est un peu quand ils avaient du Slack Time, où ils pouvaient nous ouvrir des accès à des buckets, nous provisionner des choses, etc. Et donc c'était un peu compliqué, jusqu'à ce qu'on ait notre propre DevOps dans l'équipe. Alors la crainte à l'origine, c'était qu'on n'arrive pas à l'occuper à 100%. La crainte a été assez vite levée. Donc quand il a du temps, qu'il n'est pas sur les projets, en fait, il fait de l'optimisation de coûts. Optimisation de coûts chez les cloud providers, donc très important. Tout ce qui est data, on le sait, ça coûte cher. Mais il y a des moyens d'économiser en faisant en sorte que les données, déjà, par le réseau interne par exemple, en configurant bien son file storage, etc. Il y a plein d'optimisations à faire et ça l'occupe pas mal. En tout cas, il justifie très largement son salaire. Et donc, mon dernier conseil, c'est s'appuyer sur un éditeur spécialisé. C'est vrai que nous, au début, on était un petit peu méfiants. On a essayé de faire les choses pas mal par nous-mêmes. regardant ce qui était disponible chez Cloud Provider. On s'est mangé pas mal de pain. Les solutions ne marchent jamais, en fait, comme votre account manager va vous expliquer. Et quelque part, un éditeur spécialisé, au moins... Ils ont les use case data, les vrais use case data en tête.

35:24 Ils travaillent dessus. Là, c'est une solution qui est faite par les créateurs de Spark. On est assez aligné avec leur vision. C'est vrai qu'au début, nous, on a commencé il y a trois ans avec Databricks. La solution a vraiment beaucoup évolué. À l'époque, je vous ai dit, on l'a pris, nous, pour les notebooks partagés et le compute. Depuis, ils ont rajouté vraiment énormément de fonctionnalités. C'est vrai qu'aujourd'hui, ça suit. Enfin, disons que nos besoins et le roadmap sont assez alignés. Et ça, c'est plutôt agréable. Voilà, je vais m'arrêter là.