IT/Données
Un modèle de données prêt pour le retail.
Aurélien
Le détaillant
Un détaillant sport de 16 magasins avec un entrepôt Snowflake et des analystes qui font des acrobaties SQL.
Notre détaillant opère 16 magasins en France dans le segment spécialiste multimarque sport — running, fitness, vêtements techniques. L’équipe achat est structurée : 3 personnes côté achat, plus un allocateur dédié, avec environ 7 000 SKU en saison.
Le stack est classique pour le secteur — Ginkoia comme cœur du pilotage retail, Shopify pour l’e-commerce, et Excel comme tissu conjonctif entre le reste. Plus un entrepôt Snowflake déployé deux ans plus tôt.
« Nous avions un entrepôt de données. Il n’était tout simplement pas conçu pour le retail. Chaque analyse commençait par restructurer les données. »
— Responsable des opérations
Contexte
Un entrepôt de données générique qui ne connaissait rien au retail.
2024. Le détaillant sport avait investi dans un entrepôt Snowflake deux ans plus tôt. Les données arrivaient depuis Ginkoia, Shopify et le système d’entrepôt. L’équipe pouvait interroger l’ensemble — mais chaque requête commençait par la même étape pénible : reformater les tables brutes en quelque chose d’adapté au retail.
Qu’est-ce qu’une « transaction » entre le magasin et l’online ? Qu’est-ce qu’un « magasin » quand un site combine vente physique et click-and-collect ? Qu’est-ce qu’une « saison » sur des catégories aux rythmes différents ? Chaque requête répondait à ces questions au cas par cas, et trois analystes donnaient trois réponses différentes.
L’entrepôt stockait tout. Il ne représentait rien.
Le problème
L'entrepôt était techniquement juste et opérationnellement faux.
Snowflake a donné à l'équipe de la flexibilité — chaque table de chaque source, disponible, requêtable, قابل?
Comment nous l'avons fait
Dans la boucle.
Le modèle prêt pour le retail fonctionnait sur la Data Layer, avec les entités canoniques encodées une seule fois et utilisées partout. Voici comment le système fonctionne, de bout en bout.
01 — Définir les entités canoniques.
Le modèle retail de Solya a défini SKU, magasin, transaction, client, saison comme des entités de premier ordre — avec tous leurs attributs et leurs relations.
02 — Cartographier les systèmes sources.
Ginkoia, Shopify et le système d'entrepôt de données ont été mappés au modèle canonique. Chaque enregistrement brut est devenu partie intégrante d'une entité retail.
03 — Normaliser le cross-channel.
Les transactions en magasin, en ligne et en click-and-collect ont été unifiées sous un seul concept. L'attribution cross-channel a été gérée automatiquement.
04 — Accessible à tous les consommateurs.
Les outils d'analytics, les modèles d'IA, les tableaux de bord et les exports consommaient tous le même modèle retail. Même définition, même réponse, à chaque fois.
05 — Maintenir dans le temps.
Quand les systèmes sources évoluaient, les mappings s'ajustaient. Quand de nouvelles entités apparaissaient (drops, collections capsule), elles enrichissaient le modèle proprement.
L'entrepôt de données est resté en arrière-plan. Le modèle retail est devenu la couche de travail.
Les impacts
Un modèle qui parle retail.
Une fois le modèle retail canonique mis en production, les analystes ont cessé de restructurer les données pour commencer à les analyser. Les outils d'IA et de BI consommaient tous la même source de vérité retail.
Jour 1 — Utilisable pour l'analytics et l'IA.
Natif — Des concepts retail, pas des tables génériques.
1 modèle — En remplacement d'un entrepôt de données générique.
Toutes les équipes — Posant des requêtes avec le même vocabulaire retail.
"Nos analystes ont commencé à formuler des questions retail au lieu de faire des acrobaties SQL."
— Responsable des opérations
Découvrez d'autres cas d'usage
Une seule plateforme. Chaque décision retail.
Stocks, allocation, tarification, planification, exécution — réunis dans une seule couche opérationnelle.
