Profil hybride : culture financière (Master Économie Appliquée + alternance Business Analyst) et ingénierie de données. Ce profil n'est pas une collection de projets isolés — c'est un écosystème connecté où chaque brique réutilise la précédente, de la base opérationnelle jusqu'au cloud.
| Tu as... | Regarde... |
|---|---|
| 2 minutes | Le diagramme juste en dessous — il raconte tout le portfolio en un coup d'œil |
| 15 minutes | Projet 07 (la fondation) → Projet 10 (le pipeline qui l'automatise) → Projet 05 (la pièce maîtresse IA) |
| Envie de "sentir" comment tout s'articule | Projet 14 — clique sur n'importe quel indicateur et remonte, niveau par niveau, jusqu'à la donnée brute |
| Vue par compétence | Le tableau Projets ci-dessous, classé Data Analyst / Data Engineer / IA-LLM |
Un seul socle (la base du Projet 07, en ambre ci-dessous) irrigue tout le reste. Chaque flèche est une vraie dépendance technique — pas juste un ordre de lecture.
flowchart LR
classDef petrol fill:#137A8B,color:#fff,stroke:#0d5964,stroke-width:1px
classDef ambre fill:#E4A93C,color:#1a1a1a,stroke:#b8822b,stroke-width:1px
classDef neutre fill:#eef1f2,color:#1a1a1a,stroke:#c7cdd0,stroke-width:1px
P07["07 · Base PostgreSQL<br/>OLTP e-commerce, 3NF"]
P08["08 · Bibliothèque SQL<br/>fenêtres, cohortes, RFM"]
P09["09 · Dashboard Power BI<br/>étoile, DAX, RLS"]
P10["10 · Pipeline ELT<br/>dbt + Prefect"]
P11["11 · Gouvernance<br/>dictionnaire + lignage"]
P13["13 · Entrepôt BigQuery<br/>même étoile, cloud"]
P14["14 · Filiation<br/>traçabilité interactive"]
P07 --> P08 --> P09
P07 --> P10 --> P09
P10 --> P11
P07 -.-> P11
P07 --> P13
P10 --> P14
P11 -.-> P14
class P07 ambre
class P09,P13 petrol
class P08,P10,P11,P14 neutre
Le même schéma dimensionnel tourne deux fois : une fois en local (Power BI ↔ PostgreSQL, Projet 09) et une fois dans le cloud (Power BI ↔ BigQuery, Projet 13) — la modélisation ne dépend pas de l'infrastructure qui la porte.
📐 Le motif qui revient dans presque tous les projets : l'architecture "medallion"
flowchart LR
SRC[("Sources<br/>API, CSV, base OLTP")] --> RAW[("raw<br/>copie fidèle, non transformée")]
RAW --> STG[("staging<br/>nettoyage, typage, renommage")]
STG --> MARTS[("marts<br/>étoile : faits + dimensions")]
MARTS --> BI["Power BI / Streamlit<br/>restitution"]
Chaque couche a un seul rôle : raw garde une copie fidèle de la source
(traçabilité, on peut toujours rejouer) ; staging nettoie et type sans
changer le sens métier ; marts expose un modèle prêt pour l'analyse.
Séparer ces couches évite qu'une transformation cassée corrompe la donnée
source — utilisé dans les projets 04, 10, 11 et 13.
Qu'est-ce qu'un schéma en étoile ?
Une table de faits (les événements mesurables — ex. une vente) entourée de tables de dimensions (le contexte — client, produit, date). On dénormalise volontairement pour que les outils BI calculent vite et que le modèle se comprenne sans formation. Utilisé dans les projets 04, 09 et 13.
ETL vs ELT — quelle différence ?
ETL transforme les données avant de les charger. ELT charge d'abord la donnée brute, puis transforme dans l'entrepôt (avec dbt, par exemple) — plus flexible : on garde toujours la source pour rejouer une transformation différente sans tout ré-extraire. C'est l'approche des projets 04, 10 et 13.
Pourquoi tester ses données comme du code ?
Un test dbt (unicité, non-nullité, intégrité référentielle) casse le pipeline si une hypothèse sur la donnée n'est plus vraie — plutôt que de laisser un dashboard afficher un chiffre faux en silence. Sur ce portfolio : 28 tests (Projet 10), 28 tests (Projet 11), 12/12 tests (Projet 13).
RAG, en une phrase
Retrieval-Augmented Generation : avant de répondre, le modèle cherche les passages pertinents dans les documents (recherche vectorielle), puis génère sa réponse uniquement à partir de ces extraits, avec citations et un refus explicite si l'info n'y est pas. Ça réduit drastiquement les hallucinations — Projet 05, rappel de récupération mesuré à 100 %.
Le principe du moindre privilège (IAM)
Un compte de service ne reçoit que les droits strictement nécessaires à sa tâche — jamais un rôle "Owner" par défaut. Sur le Projet 13, le compte
dbt-loader n'a que bigquery.dataEditor +
bigquery.jobUser, aucun accès au reste du projet cloud.
01 · Analyse des ventes e-commerce (Olist) — données réelles Kaggle, ~100k commandes
Problème : une baisse de CA constatée — est-ce la qualité de service qui s'est dégradée, ou autre chose ? Méthode : nettoyage SQL, 7 requêtes KPI, dashboard Power BI (étoile, 15 mesures). Résultat : la baisse n'est pas liée à la qualité (délais raccourcis pendant la baisse) — le vrai problème est la rétention : 97 % des clients ne commandent qu'une fois.
02 · Nettoyage & qualité de données (NYC 311) — 50k lignes, API réelle
Problème : des données d'incidents municipaux avec des villes mal saisies, des catégories manquantes, des dates aberrantes. Méthode : module Pandas réutilisable + vue SQL, 8 règles de qualité testées. Résultat : 8/8 tests PASS — villes non standardisées 46 280 → 0, catégories manquantes 54 → 0.
03 · Suivi de prix de jeux vidéo + web app — déployée en ligne
Problème : repérer les meilleures affaires jeux vidéo sans dataset propre existant. Méthode : collecte API CheapShark (choix éthique vs scraping fragile) → SQLite, app Flask avec filtres réactifs et graphique Chart.js. Résultat : app déployée sur Render, rafraîchissement automatique quotidien des prix via GitHub Actions.
06 · Automatisation de reporting Excel — gain de temps chiffré
Problème : un rapport Excel mensuel refait à la main à chaque fois. Méthode : génération programmatique (openpyxl) — mise en forme, 4 feuilles, graphiques natifs — depuis la base du Projet 07 ; mini-app Streamlit pour le lancer sans coder. Résultat : ~38 h/an gagnées, documenté et chiffré.
08 · Bibliothèque SQL analytique — 16 requêtes métier commentées
Problème : démontrer une maîtrise SQL au-delà du SELECT simple.
Méthode : fonctions fenêtres, cohortes de rétention, segmentation RFM,
CTE récursive — chaque requête commentée avec sa logique métier.
Résultat : bibliothèque réutilisable, note d'optimisation des
performances incluse.
09 · Dashboard exécutif Power BI — modèle en étoile complet
Problème : donner une vue fiable et unique de la performance commerciale. Méthode : modèle en étoile propre, 17 mesures DAX (time intelligence YoY/YTD/MoM), sécurité au niveau des lignes (RLS). Résultat : dashboard 2 pages, drill-down, documentation in-situ du modèle.
⭐ 15 · Reporting de gestion — écarts Budget/Réel, méthode Prix/Volume/Mix (déplié)
Problème : "CA réel 70,3 M€, Budget 71,6 M€" ne dit rien à un directeur
commercial — a-t-on vendu moins, moins cher, ou pas les bonnes catégories ?
Méthode : décomposition Prix/Volume/Mix (méthode standard de contrôle de
gestion), identités algébriques vérifiées par assert (pas de chiffre publié
sans preuve qu'il boucle), commentaires de clôture générés par département.
Résultat : écart total -1,9 % expliqué département par département —
deux départements compensent en partie les deux autres, invisible sur le seul
total consolidé.
⭐ 16 · Business case — investissement — NPV/IRR/sensibilité (déplié)
Problème : un fournisseur promet de réduire les annulations de commande — combien ça vaut vraiment, et à partir de quand ? Méthode : constat mesuré sur données réelles (7,18 % d'annulation), NPV/IRR (bissection, sans dépendance financière externe)/payback, grille de sensibilité 2 variables, mémo de décision écrit avec recommandation conditionnelle. Résultat : NPV +36 081 €, IRR 22,4 %, mais marge de sécurité étroite — la sensibilité identifie le point de bascule et motive un go conditionnel (test A/B avant déploiement complet) plutôt qu'un feu vert aveugle.
17 · Rentabilité produit/client — allocation ABC costing
Problème : un produit rentable en marge brute peut détruire de la valeur
une fois les coûts indirects réellement alloués — invisible dans une
répartition au prorata du CA.
Méthode : 3 pools de coûts indirects (logistique, paiement, SAV), chacun
sur son véritable inducteur (nb de lignes, montant réel par méthode de
paiement, nb de commandes) ; réconciliations CA produit/client vérifiées par
assert contre le total mesuré en base.
Résultat : 9 produits sur 2000 à marge nette négative malgré une
marge brute positive, seuil de rentabilité isolé (~12,80 €/ligne) ; signal
client honnêtement rapporté comme absent sur ce jeu de données plutôt que
forcé.
Voir aussi projet-baptiste-valentin (projet binôme) : data platform de pilotage d'entreprise avec modèle Réel/Budget/Forecast complet, 4 tableaux de bord dont un "Pilotage CG" et un PDG/FinOps.
07 · Base de données e-commerce (PostgreSQL) — la fondation du portfolio
Problème : construire un socle opérationnel réutilisable par tous les
autres projets.
Méthode : modélisation relationnelle 3NF, contraintes d'intégrité, index
ciblés, conteneurisé Docker.
Résultat : requêtes ~26× plus rapides (EXPLAIN ANALYZE avant/après),
base réutilisée par 6 autres projets du portfolio.
04 · Entrepôt de données multi-sources — DuckDB local
Problème : croiser 3 sources hétérogènes (base transactionnelle, calendrier,
météo) sans infra cloud.
Méthode : entrepôt DuckDB + dbt-duckdb, orchestration Prefect en une
commande.
Résultat : 10 modèles dbt, 11 tests PASS, dim_date fusionne
calendrier et météo.
10 · Pipeline ELT automatisé — architecture medallion
Problème : automatiser la chaîne complète source → entrepôt sans tout recharger à chaque fois. Méthode : extraction incrémentale par watermark (public → raw), dbt (staging → marts en étoile), orchestration Prefect. Résultat : 28 tests dbt PASS, validé sur données réelles (+928 lignes incrémentales, 0 doublon au 2ᵉ passage).
11 · Gouvernance & qualité des données — dictionnaire + lignage
Problème : sans gouvernance, personne ne sait ce que signifie une colonne ni qui est responsable d'une table. Méthode : dictionnaire raw/staging/marts, conventions de nommage, tests dbt, lignage généré automatiquement. Résultat : 28 tests qualité PASS, ownership et SLA documentés par table.
⭐ 14 · Filiation — documentation vivante et interactive de traçabilité
Problème : le lignage dbt (Projet 11) est exact mais lu par des
data engineers — pas par quelqu'un qui demande juste "d'où vient ce chiffre ?".
Méthode : page cliquable qui remonte un indicateur/colonne/table jusqu'à
sa donnée brute ; jeu de données réel introspecté depuis le Projet 10
(manifest.json/catalog.json/run_results.json, rien d'inventé), script
Python rejouable après chaque dbt run.
Résultat : 13 nœuds (5 sources + 8 modèles), 28 tests dbt réels
affichés avec leur statut, lecture seule + renvoi vers le système source
(gouvernance, pas d'édition directe en base).
12 · Dédoublonnage & golden record — entity resolution
Problème : deux sources clients avec doublons, fautes de frappe et variantes de noms — aucun identifiant fiable. Méthode : standardisation, fuzzy matching (rapidfuzz), union-find pour regrouper les doublons, règles de survivorship. Résultat : 1280 → 813 golden records, précision 97,2 % / rappel 95,9 % / F1 96,5 % — mesuré contre une vérité terrain connue.
⭐ 13 · Entrepôt central BigQuery — le même modèle, dans le cloud (déplié — la preuve cloud du portfolio)
Problème : est-ce que la modélisation dimensionnelle du Projet 09 tient
la route hors d'un environnement local ?
Méthode : extraction dlt (PostgreSQL → BigQuery raw), dbt-bigquery
(staging → marts, même étoile que le Projet 09), IAM à privilège minimal,
Power BI branché sur marts.
Résultat : 12/12 tests dbt PASS, compte de service sans rôle Owner,
modèle documenté in-situ.
⭐ 05 · Assistant d'analyse financière (RAG/LLM) — la pièce maîtresse IA (déplié — le projet le plus démonstratif)
Problème : un LLM seul hallucine des chiffres financiers plausibles mais faux — inacceptable sur ce sujet. Méthode : récupération vectorielle locale (embeddings, sans clé API) + génération Claude, avec garde-fous (ancrage strict, citations obligatoires, refus explicite mesuré). Résultat : rappel de récupération 100 % (7/7) sur un jeu d'évaluation à vérité terrain connue, garde-fous documentés et testés.
| Pratique | Comment elle est appliquée ici |
|---|---|
| Un repo = un projet | 17 dépôts indépendants, chacun avec un README structuré (problème → méthode → résultats chiffrés → reproduction) |
| Tests systématiques, vérifiés par CI | dbt tests (unicité, non-nullité, intégrité référentielle) sur les projets 04/10/11/13 ; tests qualité Python sur les projets 02/12/14 ; asserts d'identité/réconciliation comptable sur les projets 15/16/17 ; 13 des 17 dépôts ont une CI GitHub Actions qui rejoue le pipeline à chaque push — badge cliquable dans chaque README concerné, pas juste une affirmation |
| Documentation vivante | Journal de bord par projet, descriptions in-situ dans les modèles Power BI, dictionnaires de données générés (pas de doc qui se périme dans un coin) |
| Secrets jamais commités | .gitignore systématique, clés de service hors repo, tout secret lu depuis l'environnement (ANTHROPIC_API_KEY, GOOGLE_APPLICATION_CREDENTIALS) |
| Moindre privilège | Comptes de service à droits scopés (IAM BigQuery : dataEditor + jobUser, jamais Owner) |
| Reproductibilité | Scripts rejouables (load_postgres_to_bq.py, fetch_deals.py, build_index()), environnements Docker/venv versionnés |
| Garde-fous coûts cloud | Région unique, colonnes explicites (jamais de SELECT *), staging en vues / marts en tables matérialisées |
| Commits descriptifs | Convention feat: / docs: / fix:, message = contexte + résultat chiffré, jamais juste "update" |
Chaque dépôt suit le même plan — problème métier → méthode → résultats
chiffrés → comment rejouer — un dossier docs/, du code versionné, et une
CI qui vérifie ce qu'il avance plutôt que de se contenter de l'affirmer.
Retrouve le point de départ recommandé plus haut, dans
« Par où commencer ».
Charte commune « Petrol & Ambre » appliquée à tous les dashboards et
documents du portfolio : #137A8B (signature), #E4A93C
(accent), déclinée en thème Power BI réutilisable — un détail qui compte
autant que le code pour donner une impression de cohérence sur 17 projets.
Merci d'être passé·e voir. Discutons-en →
