Comment Saint-Maclou a rassemblé ses données en vue d’une exploitation temps réel

Guillaume Porquier : Saint-Maclou est un distributeur français de revêtements de sols. Nous appartenons au groupe Adeo aux côtés d’enseignes telles que Leroy-Merlin, Weldom, etc. Adeo appartient majoritairement à l’Association Familiale Mulliez (souvent improprement appelée « groupe Auchan »). Nous sommes basés dans le Nord, à Lezennes, et nous disposons d’un réseau de 132 magasins en France et d’un entrepôt logistique. En dehors de quatre mandataires, nos magasins sont des succursales. Nos 1400 collaborateurs nous permettent de générer un chiffre d’affaires d’environ 200 millions d’euros.

Guillaume Porquier : Comme la cybersécurité, la data est rattachée à la DSI. L’infrastructure est transverse mais il y a des responsables par domaines applicatifs. La plateforme data est gérée par l’équipe data.

Guillaume Porquier : Nous avons encore une certaine quantité de Legacy sur cloud privé. Mais notre stratégie est de migrer au maximum vers le SaaS.

Par exemple, notre ERP est Microsoft Dynamics, actuellement hébergé, mais qui va migrer vers la version SaaS en 2027. Notre WMS est Geode de Sage qui a récemment été migré en SaaS. Nous disposons d’un CRM maison que nous sommes en train de migrer vers Salesforce. L’applicatif de gestion des prestataires en charge de la pose de nos produits chez nos clients a été développé sous ServiceNow, en SaaS.

Guillaume Porquier : Nous avons amorcé une refonte de notre approche de la data en 2023, avant l’arrivée d’un responsable dédié, Salmane Khamlichi. Nous avons à l’époque décidé de mettre en place une base de centralisation de 100 % des données de 100 % du SI opérationnel. Toute la data de l’entreprise devait, de ce fait, être disponible en temps réel dans un datalake.

La donnée est retravaillée dans Snowflake pour qu’elle soit exposée par domaines métiers. A partir de cette donnée hébergée de manière unifiée, des applications ont été mises en œuvres pour redistribuer la donnée pour du décisionnel, de l’IA, etc.

Lorsqu’il s’agit de consommer la donnée, l’idée est de favoriser son usage via la plateforme data plutôt que de mobiliser les applications transactionnelles.

Notre instance Snowflake est sur AWS parce que c’est sur cette plateforme que l’éditeur innove au plus vite et en premier. Pour la visualisation, nous utilisons Qlik Cloud.

Guillaume Porquier : Historiquement, notre BI était sous SQLserver, alimentée par des flux point-à-point sous l’ELT Stambia (l’outil a été racheté en 2021 par Semarchy). Chaque évolution des flux demandait un gros effort. C’était long et compliqué.

Avec la nouvelle plateforme et notre ambition du temps réel, il était indispensable de faire évoluer cette architecture trop complexe et rigide. Et ce, d’autant plus que nous avions déjà des difficultés à identifier les incréments de mises-à-jour de données.

Nous avions donc la volonté de limiter nos efforts et de régler les problèmes techniques existant à l’époque, y compris les problèmes de performance. Nous avons alors recherché les solutions disponibles sur le marché. Et il y en a beaucoup !

Guillaume Porquier : Nous avons recherché une solution lors du deuxième semestre de 2023. Une fois que nous avions choisi le datalake Snowflake, nous nous sommes demandé comment l’alimenter. Nous avons regardé davantage cinq ou six solutions. En finale, nous avons retenu Fivetran et Rivery qui ont été testées toutes les deux.

Nous avons réalisé des pilotes directement en production, sans démonstrateur. En effet, les enjeux sont essentiellement sur les volumes traités et tester suppose donc d’avoir les volumes de la production. Nous voulions surtout vérifier que l’outil ne provoquait pas de surcharge sur les systèmes transactionnels.

Fivetran utilise une technologie baptisée High Velocity Agent. Il s’agit d’un agent placé sur les serveurs de bases de données. Cette approche technique permet une forte performance sur de gros flux, notamment à partir de l’ERP ou du WMS.

En pilote, nous avons programmé une réplication des données toutes les cinq minutes. Aujourd’hui, nous avons mis en place une réplication toutes les quinze minutes : c’est suffisant pour nos besoins et il était inutile d’accroître au-delà la fréquence de rafraîchissement. Il s’agissait de réduire la sollicitation inutile de Snowflake. Côté Fivetran, la licence se base sur la ligne active par mois : la motification de la fréquence entre 5 et 15 minutes n’avait donc aucun impact financier vis-à-vis de cet outil.

Guillaume Porquier : La mise en œuvre de Fivetran a été opérationnelle en quelques semaines pour l’ERP, le CMS, plusieurs bases clients… Une fois validée, la technologie a été appliquée à tous les autres systèmes.

Fivetran a une grande richesse de connecteurs. Il n’y a donc aucune question à se poser pour connecter une nouvelle source de données. Par exemple, nous avons même récupéré les données de SEO de Google en quelques clics !

Salmane Khamlichi : Aujourd’hui, l’équipe data ne se préoccupe plus de la configuration de la collecte de données. Auparavant, cette tâche était chronophage.

Salmane Khamlichi : Nous allons continuer à connecter de nouvelles sources de données au fil des demandes. Par exemple, il y a quelques semaines, nous avons intégré l’ITSM GLPI comme source de données. Nous pouvons aussi rajouter des tables de l’ERP (450 à date).

Maintenant que la plateforme data et l’architecture de collecte sont en place, il s’agit surtout d’en tirer les bénéfices. Au lieu de perdre du temps à collecter les données, nous devons utiliser ce temps pour exploiter les données.

Guillaume Porquier : C’est sans doute vexant pour eux mais, avec les équipes Fivetran, nous ne nous parlons jamais : ça marche ! Au fur et à mesure des projets, nous réduisons l’empreinte de Stambia et la cible est évidemment de décommissionner ce produit. Mais nous n’allons pas lancer des démontages de flux sur des applications destinées à être changées. Nous nous sommes donc donné trois ans pour migrer à 100 %.