Introduction
Imaginez les fiches de caisse d’une boutique en ligne avec des centaines de milliers de lignes, parfois incomplètes ou incohérentes (annulations mélangées aux ventes, prix aberrants). Sans traitement, impossible de répondre sereinement à des questions simples comme, quel est le chiffre d’affaires par pays ? Quels clients achètent le plus ?
J’ai conçu un pipeline automatisé qui prend ce fichier brut, le nettoie, l’enrichit (ajout d’informations tels que les segments clients, les catégories supposées des produits, etc.) et le stocke dans un format adapté à l’analyse à grande échelle. Le tout est reproductible (même commande, même résultat) et contrôlé : si les données ne passent pas les règles de qualité, le traitement s’arrête plutôt que de publier des chiffres faux.
C’est pourquoi j’ai industrialisé la chaîne « données brutes → données prêtes pour le reporting », avec des gains mesurables sur la fiabilité et la vitesse des requêtes.
Le dépôt GitHub contient le code, les notebooks et les instructions d’exécution.
Le contexte métier
Qui ? Une boutique en ligne britannique (jeu de données public Online Retail, période fin 2010 – début 2011).
Le constat : environ 500 000 lignes de transactions, avec des problèmes classiques pour une plateforme de retail en ligne :
- informations manquantes (client, prix, quantité)
- annulations mélangées aux vraies transactions
- valeurs aberrantes (quantités ou prix incohérents)
- structure peu adaptée aux indicateurs métier (CA, segmentation)
Les objectifs :
| Objectif | Pourquoi |
|---|---|
| Fiabiliser le CA et les segments clients | Décisions commerciales basées sur des chiffres cohérents |
| Garantir la qualité à chaque chargement | Éviter de propager des erreurs dans les tableaux de bord |
| Accélérer les requêtes d’analyse | Moins d’attente pour les équipes métier ou data |
| Permettre l’évolution des données | Historique, corrections et mises à jour automatisées |
Ce que j’ai livré
Deux compléments qui se répondent :
- Un pipeline Python exécutable en une commande pour l’industrialisation et l’intégration continue.
- Un notebook pour explorer, documenter et démontrer (profilage, contraintes, comparaison de performances). > Databricks: directement prêt à être exécuté depuis Databricks
Le schéma du traitement des données suit les principes du “Medallion architecture” (bronze → silver → gold), une structure standard en data engineering :
flowchart LR
A["Fichier CSV brut"] --> B["Bronze<br/>copie archivée"]
B --> C["Silver<br/>données nettoyées"]
C --> D["Gold<br/>données enrichies"]
D --> E["Analyses<br/>CA, benchmarks"]- Bronze : on conserve une copie fidèle des données sources (traçabilité).
- Silver : on applique les règles de nettoyage (annulations, valeurs manquantes, formats).
- Gold : on ajoute des colonnes utiles au métier (montant de commande, segment d’achat, continent, catégorie produit, etc.).
Technologies clés : PySpark (traitement distribué), Delta Lake (stockage fiable avec historique et contrôles), tests automatisés sur le nettoyage et la qualité.
Résultats concrets
| Indicateur | Ce que ça signifie |
|---|---|
| ~8 839 lignes d’annulation retirées | Les ventes « annulées » ne faussent plus le CA |
| Temps de requête : ~2,45 s → ~0,90–1,55 s | Requêtes nettement plus rapides grâce au partitionnement (données rangées par pays / continent) |
| ~355 281 lignes intégrées via MERGE | Mise à jour incrémentale possible sans tout réécrire |
| Écart de CA entre versions (8,2 M£ vs 7,7 M£) | Normal car le périmètre plus strict après nettoyage et enrichissement |
Les chiffres de temps varient selon la machine, l’ordre de grandeur reste cependant représentatif. Pour le détail du partitionnement, voir aussi la note de méthode associée.
Les données en entrée
Une ligne = un article sur une facture (quantité, prix, date, client, pays). Principales colonnes :
| Colonne | Signification | Point d’attention |
|---|---|---|
InvoiceNo |
Numéro de facture | Préfixe C = annulation |
StockCode |
Référence produit | 5 caractères en sortie silver |
Description |
Libellé produit | Base pour les catégories de produits |
Quantity / UnitPrice |
Quantité et prix | Contrôlés après nettoyage |
InvoiceDate |
Date et heure d’achat | |
CustomerID |
Identifiant client | Souvent vide en brut |
Country |
Pays de livraison | Forte part Royaume-Uni |
Pour les profils techniques
Prérequis
- Python 3.10+ (testé avec 3.11)
- JDK 11 ou 17 —
JAVA_HOMEdoit pointer vers le dossier JDK sans wildcard (ex. éviterjdk-17.*) - Fichier
data/raw/Online_Retail.csv— UCI Online Retail
Dépendances principales :
python-dotenv
pyspark==3.5.3
delta-spark==3.2.1
pyyaml
pytestPour le notebook : ydata-profiling, pyngrok (optionnel).
Installation et lancement
# 1. Cloner le dépôt et installer les dépendances
pip install -r requirements.txt
# 2. Copier la configuration d’environnement (optionnel)
cp .env.example .env
# 3. Placer le CSV (ou adapter config/dev.yaml)
# data/raw/Online_Retail.csv
# 4. Lancer le pipeline
python -m src.main
# Avec analyses et benchmark partitionné / non partitionné
python -m src.main --analytics
# Environnement prod (chemins S3 dans config/prod.yaml)
python -m src.main --env prodTests
python -m pytest tests/test_cleaning.py tests/test_quality.py -qLe premier lancement peut être lent (démarrage JVM Spark).
Exécution depuis un Notebook
A. Google Colab
- Ouvrir
Online_retail_pipeline.ipynbet exécuter les cellules dans l’ordre. - Adapter le chemin CSV si besoin (historiquement
/Data_OR/Online_Retail.csv).
B. Databricks
- Aller dans le dossier
notebooks-> OuvrirRun pipeline.ipynb-> exécuter les cellules dans l’ordre.
Livrables
1. Notebook (Online_retail_pipeline.ipynb)
| Phase | Contenu |
|---|---|
| Compréhension | Schéma, statistiques, profils YData Profiling, explorations |
Nettoyage (phase1) |
Même logique métier que cleaning.py + table Delta |
Enrichissement (phase2 → phase3) |
Traitement des descriptions, catégorisation |
| Organisation Delta | Contraintes CHECK sur phase3 / phase4 |
| Performance | Table partitionnée, plans d’exécution, mesures de temps |
| Historique | MERGE, DESCRIBE HISTORY, VERSION AS OF |
2. Pipeline Python (src/)
| Composant | Contenu |
|---|---|
| Ingestion | Lecture CSV typée, écriture Delta bronze / silver / gold |
| Nettoyage | Règles métier alignées sur le notebook |
| Qualité | Contrôles automatisés avec rapport et arrêt en cas d’échec |
| Enrichissement | Colonnes analytiques pour la couche gold |
| Analytics | Agrégations CA & benchmark partitionné vs non partitionné |
Comment le pipeline fonctionne
Le programme enchaîne dix étapes dans un ordre fixe et chaque étape a un rôle métier clair.
get_config()-> cherche l’environnementcreate_spark_session()-> crée une session Sparkread_raw_csv()-> importation du CSVwrite_delta→ copie dans dossier bronzeclean_transactions()→ nettoierun_checks(..., scope="cleaning")-> checking du nettoyagewrite_delta→ silverenrich_transactions()-> complète les donnéesrun_checks(..., scope="enriched")puiswrite_delta→ goldrun_analytics()si--analyticsÀ retenir : le pipeline ne se contente pas de transformer les données, il vérifie qu’elles sont exploitables avant de les exposer aux analyses. En cas de problème, une erreur
DataQualityErrorbloque la suite plutôt que de livrer des résultats trompeurs.Détail des règles de nettoyage
C/c)541431)Détail de l’enrichissement
Contrôles qualité
Chaque passage silver / gold produit un rapport (
passed, contraintes, violations). Si une règle échoue, le traitement s’arrête. Ce comportement permet de protéger les indicateurs en aval, car on est certain que les données qui arrivent à l’utilisateur final ont passé les tests (ont le comportement attendu).