Ratigniet Valentin valentinratigniet-byte

Bonjour, je suis Valentin Ratigniet 👋

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.

🧭 Par où commencer ?

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

🧩 L'écosystème

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"

Même démarche à chaque fois, du système source jusqu'à la restitution — le terme technique en gras, ce qu'il veut dire en simple juste en dessous :

flowchart LR
    ERP[("🏭 ERP / système source<br/>AS/400, SQL Server...<br/><i>la vraie techno où naît la donnée</i>")] --> SRC[("🎭 Extraction<br/>API, CSV, base OLTP<br/><i>copie d'une 'base de production' simulée</i>")]
    SRC --> RAW[("📥 raw<br/>copie fidèle, non transformée<br/><i>rien n'est perdu, tout est rejouable</i>")]
    RAW --> STG[("🧹 staging<br/>nettoyage, typage, renommage<br/><i>ETL/ELT via dbt, en SQL testé</i>")]
    STG --> MARTS[("⭐ marts<br/>étoile : faits + dimensions<br/><i>l'entrepôt, une seule source de vérité</i>")]
    MARTS --> BI["📊 Power BI / Streamlit<br/>restitution<br/><i>chacun voit ce qu'il a le droit de voir</i>"]

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.

📚 Concepts clés, expliqués simplement

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.

ERP, c'est quoi exactement ?

Enterprise Resource Planning — le logiciel qui centralise la gestion d'une entreprise (ventes, achats, stocks, compta) sur une même base de données. Sur ce portfolio, un ERP n'est jamais un mock Postgres déguisé : Ventes/Commerce tourne sur un vrai AS/400 (Db2 for i, conventions authentiques), Finance/Compta sur un vrai SQL Server édition Developer — reproduire un ERP, c'est reproduire sa techno, pas seulement sa forme. Projet 19, section docs/outils.md.

dbt, en une phrase

data build tool — transforme la donnée en SQL versionné directement dans l'entrepôt (approche ELT, voir ci-dessus) : chaque transformation est un fichier .sql testable, documenté, avec lignage automatique entre modèles. Pas un script qu'on relance à la main — un vrai projet logiciel appliqué à la donnée. Utilisé dans les projets 04, 10, 13, 18 et 19 (snapshots SCD2, tests, contracts, exposures).

Entrepôt de données (data warehouse)

La base où la donnée nettoyée et modélisée vit pour l'analyse — séparée des bases opérationnelles (ERP, CRM...) qui, elles, servent à faire tourner le métier au quotidien. Structuré en couches : raw (copie brute, jamais modifiée) → staging (nettoyage) → marts (modèle en étoile ou constellation, prêt pour la BI). Projets 04 et 19 (ce dernier avec 3 domaines qui convergent vers un même entrepôt).

Pourquoi une "base de production" simulée ?

Aucune vraie donnée d'entreprise n'est utilisée (confidentialité) — mais la technique est réelle : un simulateur d'usage fait vivre chaque base sur plusieurs mois simulés, pour que le volume et les vrais problèmes (doublons, bloat, formats incohérents) émergent de l'usage plutôt que d'être injectés à la main. Toujours présenté entre guillemets dans les README pour ne jamais laisser penser que c'est une vraie entreprise. Projet 19.

Pourquoi Power BI plutôt qu'un autre outil de visualisation ?

Standard du marché en environnement Microsoft/entreprise française, avec un vrai langage de modélisation (DAX) et une sécurité au niveau des lignes (RLS) native — pas juste des graphiques. "Piloter" veut dire concrètement : un modèle en étoile propre, des mesures DAX qui répondent à une vraie question métier (pas juste des sommes), et un accès restreint par rôle (RH ne voit pas Finance, etc.). Projets 09, 13, 18 et 19 — même toolchain à chaque fois, cohérence de compétence plutôt que survol d'outils différents.

📂 Projets — classés par compétence dominante

📊 Data Analyst — de la donnée brute à la décision

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.

Pratique	Comment elle est appliquée ici
Un repo = un projet	19 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/18 ; tests qualité Python sur les projets 02/12/14 ; asserts d'identité/réconciliation comptable sur les projets 15/16/17 ; RLS testée avec les vrais rôles sur les projets 18/19 ; 15 des 19 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"

Ratigniet Valentin valentinratigniet-byte

Highlights

Bonjour, je suis Valentin Ratigniet 👋

🧭 Par où commencer ?

🧩 L'écosystème

📚 Concepts clés, expliqués simplement

📂 Projets — classés par compétence dominante

📊 Data Analyst — de la donnée brute à la décision

💼 Contrôleur de gestion / Business Analyst — du chiffre à la décision

🏗️ Data Engineer — pipelines & infrastructure

🤖 IA / LLM

✅ Bonnes pratiques appliquées sur tout le portfolio

📊 Activité GitHub

🔗 Une structure commune, projet après projet

🎨 Identité visuelle

Pinned Loading

Uh oh!