Formation Data Engineering

Du fichier brut au mart exposé.

10 modules, un projet fil rouge. Chaque module : un objectif clair, des slides à présenter, une pratique en conditions réelles.

▶ Commencer le module 01 Voir le programme

flux de donnéesen direct

📄

Sources

CSV · API

🐍

Ingestion

Python

🗄️

Warehouse

DuckDB

🔧

dbt

staging → marts

📊

Mart

BI · export

10 modules·49 leçons·1 projet capstone·100% pratique

1 — Choisis ton métier

Data Engineer, Data Analyst ou Analytics Engineer : on met en avant les modules au cœur de ton métier. Rien n'est masqué — tu peux changer à tout moment.

2 — Choisis ton mode

Autonome ou semi-accompagné. Tu pourras en changer à tout moment.

3 — Suis les modules

Un parcours linéaire, comme un pipeline : chaque étape s'appuie sur la précédente.

01🧭

Module 01·½ journée (3h–4h)

Fondations & mindset data engineering

🎯Donner aux juniors en reconversion les repères mentaux du métier : situer chaque outil/concept dans le paysage data, distinguer les rôles (DE / DA / AE), et comprendre le pipeline de bout en bout (ingestion → transformation → serving) comme une chaîne de production fiable, pas comme une suite de scripts. À la fin, l'apprenant sait dessiner un pipeline, nommer chaque étape, et expliquer "qui fait quoi" — c'est la carte qui rend tous les tracks suivants lisibles.

02🗃️

Module 02·2 jours (environ 14h : 7h live + 7h lab autonome)

SQL pour la data : requêtes analytiques et modélisation sur warehouse

🎯Rendre un junior capable d'écrire des requêtes analytiques de niveau production sur un warehouse (SELECT avancé, JOINs, agrégations, CTEs, window functions), de comprendre et concevoir un star schema (faits/dimensions), et de juger la qualité et la performance de ses requêtes. À la fin, l'apprenant pense en "ensembles de lignes" et non en boucles, structure ses requêtes en couches lisibles avec des CTEs, et sait pourquoi un modèle en étoile est le standard de l'analytique. Pratique 100% sur DuckDB (zéro install, requêtes en secondes sur des fichiers CSV/Parquet).

03🐍

Module 03·1,5 journée

Python pour la data

🎯Écrire du Python pragmatique de data engineer junior : manipuler les structures de base, lire/ecrire CSV/JSON/Parquet, appeler une API pour ingérer, faire des transformations simples en pandas/polars, et livrer un script reproductible dans un venv. Pas de théorie CS — uniquement ce qui sert a faire tourner un pipeline.

04🔧

Module 04·1,5 journée (environ 10h : 6h live + 4h autonomie)

dbt & le warehouse (dbt + DuckDB, pont vers Snowflake)

🎯Savoir transformer de la donnée brute en tables fiables et documentees avec dbt : structurer un projet en couches (sources -> staging -> intermediate -> marts), relier les modèles avec ref(), garantir la qualité avec des tests, choisir les bonnes materializations, gérer l'historique avec les snapshots. L'apprenant pratique tout sur dbt-duckdb (gratuit, local) et comprend conceptuellement comment ces memes notions se traduisent sur Snowflake (warehouses, RBAC, micro-partitions, time travel, cout) pour etre operationnel en mission.

05📊

Module 05·1 journée (5h–6h)

BI & dataviz : du mart à la décision

🎯Donner au Data Analyst la couche qui manque entre le mart dbt et le métier : transformer une table de faits propre en métriques de confiance, en agrégats qui font décider (tendances MoM/YoY, parts d'un tout, top-N) et en visualisations honnêtes qui racontent une décision. À la fin, l'apprenant sait définir un KPI sans ambiguïté, l'agréger au bon grain sans double comptage, choisir le bon graphe et résumer trois chiffres clés pour un non-technicien — la valeur visible du DA, posée sur les marts que l'AE a construits.

06🌬️

Module 06·1 journée

Orchestration avec Airflow

🎯Savoir orchestrer un pipeline data avec Airflow : écrire un DAG idempotent, le planifier, gérer les dépendances entre tâches, et déclencher proprement un run dbt — sans se noyer dans la complexité de l'outil.

07⚙️

Module 07·1 journée

Pratiques d'ingenieur: Git/GitHub, CI, Docker

🎯Travailler comme un data engineer en equipe: versionner proprement avec Git, collaborer via Pull Requests et review, automatiser lint et tests dbt en CI avec GitHub Actions, et comprendre Docker/devcontainer pour la reproductibilite. C'est ce qui fait la difference entre un junior qui code seul et un junior employable.

08🚀

Module 08·1 journée

CI/CD avancé : pipelines, environnements et slim CI

🎯Faire passer un data engineer junior d'une CI « echo ok » à un pipeline CI/CD de niveau production : un workflow multi-étapes (jobs reliés par needs + artefacts), des secrets et environnements propres (dev/prod, OIDC, jamais de clé dans le repo), une promotion dev → prod par merge, une slim CI qui ne reconstruit que ce qui change (state:modified+/--defer), et un build & push d'image conteneurisée vers un registry. À la fin, l'apprenant sait industrialiser le repo dbt-docker du capstone : une PR rapide, une prod déployée à l'identique depuis une image taguée.

09📦

Module 09·1 journée

Conteneurisation : empaqueter dbt et Airflow pour qu'ils tournent partout

🎯Passer du « ça marche dans mon devcontainer » à des stacks data conteneurisées et reproductibles : écrire un Dockerfile qui empaquette dbt en image épinglée, faire tourner Airflow avec Docker Compose (postgres metastore + init + webserver + scheduler), régler les configs Airflow qui comptent (executor, parallélisme, connexions, pools), et persister l'état avec des volumes tout en injectant les secrets au runtime. À la fin, l'apprenant sait lire et démarrer les repos dbt-docker / airflow-docker du capstone, et comprend pourquoi une image figée + des volumes + des secrets externes = un environnement identique partout.

10☸️

Module 10·1 journée

Kubernetes pour la data : orchestrer Airflow sur un cluster (conceptuel + démo)

🎯Donner au data engineer junior la NOTION de Kubernetes appliquée à Airflow, sans en faire un administrateur de cluster. À la fin, l'apprenant sait pourquoi on passe de Docker Compose (une machine) à un orchestrateur de conteneurs (un cluster), lit un manifest pod/deployment/service, explique l'arbitrage KubernetesExecutor (un pod par task, élastique) vs CeleryExecutor (workers permanents), déploie Airflow avec le chart Helm officiel en réglant les quelques values.yaml qui comptent, et — de façon optionnelle et non bloquante — voit tout ça tourner sur un mini-cluster kind. Le mot d'ordre : « notion = geste » — on lit et on comprend, on fait UN geste vérifiable, on ne vise pas l'admin de prod (c'est l'équipe plateforme qui opère le cluster).

4 — Valide avec le projet final

Le point d'arrivée du pipeline : tout ce que tu as appris, sur un seul projet.

🚀

Projet fil rouge

Nordwind Commerce — du CSV brut au mart analytique exposé

Fil rouge unique sur toute la formation : l'apprenant reprend la donnée d'une boutique e-commerce fictive (Nordwind, inspirée du célèbre dataset Northwind, francisée) et construit, semaine après semaine, le pipeline data complet qu'un junior doit savoir livrer en entreprise. Chaque module de cours ajoute une brique au MÊME repo GitHub : on ingère des fichiers bruts hétérogènes, on les transforme proprement en dbt sur DuckDB (staging -> intermediate -> marts), on orchestre le tout avec Airflow dans le devcontainer, on documente et on teste, puis on expose la donnée à un utilisateur métier. À la fin, l'apprenant ne rend pas un exercice jetable : il rend un repo versionné, testé, documenté et orchestré — exactement le genre d'artefact qu'on montre en entretien. Le formateur démarre chaque étape en LIVE (démo + explication du POURQUOI), l'apprenant la termine en autonomie asynchrone via une branche dédiée et une PR.

→