SmartShop 360

Un e-commerçant B2C (Décoration & Cadeaux) a ses données de vente (ERP) et ses avis clients (marketplaces) dans deux silos sans identifiant commun, empêchant de répondre à « quels best-sellers commencent à avoir une mauvaise réputation ? » ou « quels clients à risque de départ ont été déçus par quels produits ? ». Construire une plateforme qui unifie ces deux sources, réconcilie les référentiels produits, et expose le tout via des KPIs croisés et un agent en langage naturel.

Objectifs techniques :

• Unifier deux jeux de données réels sans clé commune (1M+ transactions Kaggle « Online Retail II » + 1 000 avis HuggingFace) dans un entrepôt PostgreSQL unique
• Réconcilier automatiquement les référentiels produits (MDM) malgré l'absence d'identifiant partagé
• Permettre des analyses en langage naturel sans dépendre d'une seule clé API payante (doit rester utilisable hors-ligne)

Un pipeline ETL (nettoyage → échantillonnage de 30 000 lignes avec seed fixe → calcul Revenue/Margin → détection incrémentale par hash SHA-256) alimente PostgreSQL 16 avec pgvector (6 tables, 4 vues analytiques). Trois couches s'appuient sur cette base : Streamlit (10 écrans, @st.cache_resource/@st.cache_data), un agent Text-to-SQL multi-LLM (Groq → Mistral → OpenAI → Anthropic → repli SQL hors-ligne) avec mémoire conversationnelle persistée en PostgreSQL, et une couche scikit-learn légère pour le scoring produit, la détection de churn et la prévision des ventes.

PostgreSQL a été choisi plutôt que SQLite/DuckDB spécifiquement pour le support natif de pgvector — les embeddings des avis (RAG) et la mémoire conversationnelle de l'agent vivent dans la même base que les données analytiques, donc une seule frontière transactionnelle plutôt qu'un vector store séparé à opérer.

Réconciliation produit (MDM) — sans identifiant commun entre l'ERP et les avis, le matching se fait par TF-IDF sur n-grammes de caractères (char_wb, 2-4) + similarité cosinus (seuil 0.35), avec un repli par rang de volume quand le score est trop faible — 48 fiches produit unifiées (Golden Records) au final.

Qualité des données — un moteur de validation façon Great Expectations (10+ règles, sans dépendance externe) tourne avant chargement ; les règles en error bloquent le pipeline, celles en warning sont journalisées sans le stopper.

Agent conversationnel — chaque question est transformée en SQL par le LLM disponible, exécutée sur 4 vues analytiques pré-calculées, avec un repli automatique sur des requêtes SQL par mots-clés si aucune clé API n'est configurée — la démo reste utilisable entièrement hors-ligne.

Défi — réconcilier deux référentiels produits sans clé commune. Un matching exact est impossible (codes différents, orthographe variable). Solution : TF-IDF sur n-grammes de caractères plutôt que sur les mots entiers, ce qui tolère fautes de frappe et abréviations (« CERAMIC MUG » ↔ « Ceramic-mug ») ; un score cosinus sous le seuil de 0.35 bascule sur un appariement par rang de volume plutôt que d'échouer.

Défi — garder l'agent utilisable sans clé API ni accès réseau. Solution : détection automatique du provider LLM disponible (Groq → Mistral → OpenAI → Anthropic), avec un mode de repli qui répond par des requêtes SQL prédéfinies sur les vues analytiques quand aucune clé n'est fournie — la démo reste fonctionnelle en environnement restreint.

• 1 067 371 transactions réelles ingérées (échantillon de 30 000 traité), 4 042 clients uniques, 1 000 avis clients, 48 fiches produit réconciliées
• 10 écrans Streamlit : dashboard KPI, analyse produit 360°, carte géographique des ventes, comparaison produits, scoring composite, détection de churn (RandomForest), prévision de ventes
• Pipeline couvert par 4 suites pytest (60+ méthodes) et un pipeline CI/CD à 4 jobs (lint, tests unitaires, tests d'intégration avec PostgreSQL éphémère, build Docker)
• Observabilité complète : métriques Prometheus + dashboard Grafana 6 panneaux, alertes email/Slack sur les produits en statut critique