Étude de cas – Moderniser une stack BI pour Son Vidéo

Contexte

Son Vidéo (SVD) est un acteur majeur de la distribution de matériel audio-vidéo.
Comme beaucoup d’organisations en croissance, l’entreprise avait accumulé plusieurs bases de données hétérogènes (MySQL, PostgreSQL, SQL Server), chacune dédiée à un pan de l’activité (ERP, e-commerce, CRM, etc.).

Les analyses étaient réalisées “à la volée” dans Metabase, sans socle de modélisation solide. Résultat :

• Des délais importants pour produire de nouveaux KPI
• Des coûts élevés pour chaque synchronisation supplémentaire
• Une dépendance forte aux équipes techniques

👉 L’objectif était de bâtir une stack BI moderne, économique et évolutive, tout en embarquant l’équipe tech dans une meilleure compréhension des outils et de leurs rôles respectifs.

---

Objectifs

1. Centraliser les données hétérogènes dans un socle unique
2. Mettre en place une synchronisation automatisée et fiable
3. Standardiser la modélisation analytique (KPI, dashboards, pilotage)
4. Maîtriser les coûts à chaque étape, avec une trajectoire d’évolution claire
5. Évangéliser l’équipe tech : clarifier les catégories d’outils (ETL, Data Warehouse, Modeling, Viz) et diffuser les bonnes pratiques
6. Garantir l’auditabilité et la traçabilité du processus de modélisation

---

Architecture proposée

1. Synchronisation des données

Options étudiées :

• Airbyte (ETL open source, flexible, communauté large)
• CloudQuery (infrastructure “as code”)
• AWS DMS (service managé, mais plus coûteux et complexe à contrôler)

Décision : Airbyte en self-hosting sur AWS.
Motivations : solution robuste, faible coût (≈ 50 USD/mois), et facilement extensible.
➡️ Première étape low-cost, avec possibilité d’augmenter la capacité si le volume de données croît.

---

2. Stockage et Data Warehouse

• Phase 1 – PostgreSQL : socle simple et connu de l’équipe, adapté pour débuter.
• Phase 2 – DuckDB : moteur analytique embarqué, très performant et économique, tant que la volumétrie reste contenue.
• Phase 3 – Google BigQuery : passage à un data warehouse managé lorsque les volumes ou les performances dépassent les capacités locales.

👉 Cette trajectoire permet de retarder les investissements lourds tout en préparant une montée en charge fluide.

---

3. Modélisation analytique

Comparatif :

• dbt : SQL-first, adoption facile, large communauté
• SQLMesh : hybride SQL + Python, plus puissant mais demande plus de maturité
• AWS Glue : riche mais plus coûteux et complexe

Décision : dbt en phase initiale → adoption rapide par l’équipe, montée en compétence progressive.
➡️ Option d’évoluer vers SQLMesh si besoin de flexibilité accrue.

---

4. Orchestration

Au départ, pas besoin d’un ordonnanceur complexe :

• Les synchronisations peuvent tourner à heures fixes (cron, jobs simples).
• L’équipe gagne en rapidité de mise en place et en simplicité opérationnelle.

➡️ L’introduction d’un orchestrateur (Airflow, Dagster, Prefect) n’est envisagée que lorsque la volumétrie ou la complexité l’exige (ex. > 100 jobs, dépendances fortes entre pipelines).
Cela permet de ne pas surdimensionner l’infrastructure dès le départ.

---

5. Visualisation et pilotage

• Conservation de Metabase comme front BI
• Mise en place d’un socle standardisé via dbt pour garantir la cohérence des indicateurs et réduire les divergences d’interprétation

---

Gestion évolutive des coûts

Un point clé du projet : chaque choix technique a été pensé en fonction du budget actuel et de la trajectoire future.

• Phase initiale (budget limité) :

  • Airbyte self-hosté
  • dbt en CLI (gratuit)
  • PostgreSQL ou DuckDB comme storage léger
  • Orchestration basique (cron jobs)

• Évolutions prévues :

  • Passage à DuckDB tant que les volumes restent compatibles
  • Migration vers BigQuery lorsque les performances l’exigent
  • Adoption d’Airflow, Prefect ou Dagster uniquement si la complexité le justifie

👉 Cette approche garantit que l’infrastructure reste soutenable financièrement tout en préparant le terrain pour l’avenir.

---

Évangélisation et pédagogie interne

La réussite ne repose pas uniquement sur la technique. Un effort particulier a été porté sur :

• Clarifier les catégories d’outils :

  • ETL (Airbyte) = transport de données
  • Storage (Postgres / DuckDB / BigQuery) = stockage et calcul
  • Modeling (dbt) = règles métier et KPI
  • Orchestration (cron → Airflow/Dagster) = organisation des jobs
  • Viz (Metabase) = restitution

• Former l’équipe tech :

  • Sessions de présentation des outils
  • Partage de bonnes pratiques (tests dbt, versioning, documentation)
  • Mise en avant de l’auditabilité :
    • Chaque transformation versionnée dans Git
    • Tests automatisés pour la qualité des données
    • Documentation générée automatiquement (dbt docs)
    • Possibilité de retracer l’origine de chaque KPI

➡️ Résultat : montée en compétence collective et adoption durable de la stack.

---

Résultats attendus

• Mise en place d’un nouveau KPI en < 1 journée
• Intégration d’une nouvelle source en quelques heures (au lieu de plusieurs jours)
• Autonomie accrue des métiers pour explorer les données
• Budget respecté grâce à une stratégie “start small, scale later”
• Une équipe technique alignée, ayant une vision claire de chaque outil et de son rôle
• Auditabilité et traçabilité complètes du processus de modélisation : chaque KPI et chaque rapport peut être relié à sa source et ses règles métier

---

Schéma d’architecture (Mermaid)

flowchart LR
  %% Sources
  subgraph S[Sources de données]
    A1[(MySQL - E-commerce)]
    A2[(PostgreSQL - ERP)]
    A3[(SQL Server - EasyLounge)]
    A4[(GA4 / Autres APIs)]
  end

  %% Ingestion
  E[(Airbyte\nETL self-hosté)]
  S --> E

  %% Storage (évolutif)
  subgraph W[Storage / Data Warehouse]
    direction TB
    W1[(PostgreSQL - Phase 1)]
    W2[(DuckDB - Phase 2)]
    W3[(BigQuery - Phase 3)]
  end

  E --> W1
  E --> W2
  E --> W3

  %% Modeling
  M[(dbt - modèles & règles métier)]

  %% Viz
  V[["Metabase
  Dashboards & KPI"]]

  %% Flux principal
  W1 --> M --> V
  W2 --> M
  W3 --> M

  %% Orchestration
  C[["cron jobs
  (départ: faible besoin)"]]
  C -. planifie .-> E
  C -. planifie .-> M

  subgraph O["Orchestration
  (optionnel si complexité/volumes)"]
    direction TB
    O1[Airflow]
    O2[Dagster]
    O3[Prefect]
  end
  O1 -. planifie .-> E
  O1 -. planifie .-> M
  O2 -. planifie .-> E
  O2 -. planifie .-> M
  O3 -. planifie .-> E
  O3 -. planifie .-> M

  %% Auditabilité / Qualité
  subgraph Q[Auditabilité & Qualité]
    direction TB
    Q1[(Git - versioning modèles)]
    Q2[(dbt tests - data quality)]
    Q3[(dbt docs - catalog & lineage)]
    Q4[(Logs ETL & SQL)]
  end
  Q1 -. trace .-> M
  Q2 -. valide .-> M
  Q3 -. documente .-> M
  Q4 -. observe .-> E
  Q4 -. observe .-> M

  %% Notes d'évolution
  classDef phase fill:#eef7ff,stroke:#79a6e8,color:#0b3d91;
  classDef opt fill:#f6fff2,stroke:#7cc576,color:#274e13;
  classDef audit fill:#fff6e5,stroke:#f0a33e,color:#7a4b00;

  class W1,W2,W3 phase;
  class O1,O2,O3 opt;
  class Q1,Q2,Q3,Q4 audit;

---

Remerciements

Un grand merci à Thomas Trividic avec qui j’échange souvent sur ces sujets. Ses retours et conseils sont toujours précieux et ont nourri la réflexion présentée dans cette étude de cas.

Conclusion

Ce projet illustre deux forces majeures :

• La capacité à concevoir une stack BI pragmatique, scalable et économiquement soutenable
• L’aptitude à embarquer et former les équipes pour pérenniser les solutions mises en place, en intégrant la dimension d’auditabilité dès le départ

👉 En tant que freelance, j’apporte non seulement une expertise technique en design d’infrastructure data, mais aussi une approche orientée résultats, qualité et management du changement.