Introduction : IA & Data Architecture

35 min Fondamental

Objectifs de cette lecon

  • Comprendre le role du Data Architect dans l'ere de l'IA
  • Identifier les nouvelles composantes infrastructure pour l'IA/ML
  • Cartographier l'ecosysteme AI Data : Feature Stores, MLOps, Vector DBs, LLMs
  • Evaluer la maturite IA de votre organisation

L'IA transforme radicalement le role du Data Architect. Avant, on concevait des pipelines pour alimenter des dashboards. Maintenant, on designe l'infrastructure pour entrainer des modeles, servir des predictions en temps reel, et alimenter des LLMs avec du contexte. Les donnees ne sont plus juste "pour le reporting" - elles sont le carburant de l'intelligence artificielle. Cette phase va vous equiper pour ce nouveau monde.

Le Nouveau Paysage Data pour l'IA

AI Data Architecture - Vue d'ensemble
  TRADITIONAL DATA STACK                    AI-AUGMENTED DATA STACK
  ══════════════════                        ═══════════════════════

  Sources → ETL → DWH → BI                 Sources → ETL → DWH → BI
                                                       │
                                                       ▼
                                            ┌─────────────────────┐
                                            │  AI/ML LAYER        │
                                            │                     │
                                            │ ┌─────────────────┐ │
                                            │ │ Feature Store   │ │
                                            │ │ (Feast, Tecton) │ │
                                            │ └────────┬────────┘ │
                                            │          │          │
                                            │ ┌────────▼────────┐ │
                                            │ │ ML Platform     │ │
                                            │ │ (MLflow, Vertex)│ │
                                            │ └────────┬────────┘ │
                                            │          │          │
                                            │ ┌────────▼────────┐ │
                                            │ │ Vector DB       │ │
                                            │ │ (Pinecone, pgv) │ │
                                            │ └────────┬────────┘ │
                                            │          │          │
                                            │ ┌────────▼────────┐ │
                                            │ │ LLM Gateway     │ │
                                            │ │ (vLLM, TGI)     │ │
                                            │ └─────────────────┘ │
                                            └─────────────────────┘

Les 5 Piliers de l'AI Data Architecture

PilierComposantsRole du Data Architect
Feature StoresFeast, Tecton, HopsworksDesigner les pipelines de features, online/offline stores
MLOpsMLflow, Kubeflow, Vertex AIArchitecture du lifecycle ML : training → serving → monitoring
Vector DatabasesPinecone, Weaviate, pgvectorChoisir le bon store pour les embeddings, indexation ANN
LLM InfrastructurevLLM, TGI, prompt managementServing scalable, RAG pipelines, cost optimization
Knowledge GraphsNeo4j, RDF/SPARQL, ontologiesModeliser les relations, enrichir le contexte pour l'IA

Maturite IA : Ou en est votre Organisation ?

NiveauDescriptionInfrastructure% entreprises
1 - Ad hocQuelques notebooks JupyterAucune, local40%
2 - ExperimentatonPOCs ML, pas en productionCloud basique, pas de MLOps30%
3 - Production1-5 modeles en prodMLflow, feature store basique20%
4 - Scale10+ modeles, real-time servingFull MLOps, monitoring, A/B testing8%
5 - AI-NativeAI integre dans chaque produitPlatform team ML, LLMOps, KG2%

Data Architect (classique)

  • Design data warehouses
  • ETL/ELT pipelines
  • Data governance & quality
  • BI & reporting
  • Batch processing

AI Data Architect (2026)

  • + Feature engineering pipelines
  • + Training data management
  • + Vector stores & embeddings
  • + RAG & LLM infrastructure
  • + Real-time ML serving
Quelle est la difference principale entre un Data Warehouse et un Feature Store ?
Un Data Warehouse stocke des donnees historiques optimisees pour l'analyse humaine (requetes SQL, dashboards, rapports). Un Feature Store stocke des features calculees optimisees pour la consommation par des modeles ML. Il offre deux interfaces : un offline store (pour l'entrainement, format batch) et un online store (pour le serving en temps reel, latence < 10ms). Le Feature Store garantit aussi la point-in-time correctness pour eviter le data leakage dans l'entrainement.

Feature Stores : Concepts & Architecture

50 min Intermediaire

Objectifs de cette lecon

  • Comprendre le concept de Feature Store et son role dans le ML
  • Distinguer offline store vs online store
  • Maitriser la point-in-time correctness
  • Comparer les solutions : Feast, Tecton, Hopsworks, Vertex AI Feature Store

Le Feature Store est au ML ce que le Data Warehouse est au BI : le composant central qui organise et sert les donnees. Sans Feature Store, chaque Data Scientist recalcule les memes features dans son notebook, avec des definitions differentes. C'est le chaos. Avec un Feature Store, les features sont calculees une fois, documentees, versionnees et reutilisables par tous les modeles.

Architecture d'un Feature Store

Feature Store - Architecture Detaillee
  Raw Data Sources                Feature Engineering              Feature Store
  ════════════════                ═══════════════════              ═════════════

  ┌────────────┐                ┌───────────────────┐
  │ Data       │                │ Batch Pipeline     │         ┌────────────────┐
  │ Warehouse  │───────────────→│ (Spark / dbt)      │────────→│ OFFLINE STORE  │
  │ (Snowflake)│                │ Features calcules  │         │ (S3/Parquet/   │
  └────────────┘                │ toutes les heures  │         │  BigQuery)     │
                                └───────────────────┘         │                │
  ┌────────────┐                                              │ → Training     │
  │ Streaming  │                ┌───────────────────┐         │ → Backfill     │
  │ (Kafka)    │───────────────→│ Stream Pipeline    │────────→│                │
  └────────────┘                │ (Flink / Spark SS) │         └────────────────┘
                                │ Features temps reel│
                                └───────────────────┘         ┌────────────────┐
                                                              │ ONLINE STORE   │
  ┌────────────┐                                              │ (Redis/DynamoDB│
  │ API / App  │◄─────────────── Serving (< 10ms) ◄──────────│  /Bigtable)    │
  └────────────┘                                              │                │
                                                              │ → Inference    │
  ┌────────────┐                                              │ → Real-time    │
  │ ML Training│◄─────────────── Historical features ◄────────│                │
  │ (notebook) │                                              └────────────────┘
  └────────────┘

                          ┌─────────────────────┐
                          │ FEATURE REGISTRY     │
                          │ Metadata, lineage,   │
                          │ documentation, stats │
                          └─────────────────────┘

Offline vs Online Store

AspectOffline StoreOnline Store
UsageTraining, batch scoringReal-time inference
LatenceSecondes a minutes< 10 ms
VolumeHistorique complet (mois/annees)Dernieres valeurs uniquement
FormatParquet, BigQuery, SnowflakeRedis, DynamoDB, Bigtable
AccesSQL, Spark, pandasAPI REST/gRPC (key-value)
CoutFaible (cold storage)Eleve (RAM, hot storage)

Point-in-Time Correctness

Le probleme du Data Leakage

Sans point-in-time correctness, un modele peut "voir le futur" pendant l'entrainement. Exemple : si vous predisez le churn au 1er janvier, le modele ne doit pas voir les features calculees au 2 janvier. Le Feature Store garantit que pour chaque exemple d'entrainement, seules les features disponibles a ce moment-la sont utilisees. C'est la raison #1 d'utiliser un Feature Store plutot que des JOINs manuels.

Python
# Point-in-time join : le Feature Store gere automatiquement
# Pour chaque entity_id + event_timestamp, il retourne
# les features les plus recentes AVANT event_timestamp

training_data = store.get_historical_features(
    entity_df=pd.DataFrame({
        "customer_id": ["C001", "C002", "C003"],
        "event_timestamp": [
            datetime(2026, 1, 1),  # Features au 1er janvier
            datetime(2026, 1, 15), # Features au 15 janvier
            datetime(2026, 2, 1),  # Features au 1er fevrier
        ]
    }),
    features=[
        "customer_features:total_purchases_30d",
        "customer_features:avg_order_value_7d",
        "customer_features:days_since_last_order",
    ]
).to_df()

Comparaison des Feature Stores

SolutionTypeOffline StoreOnline StorePrixIdeal pour
FeastOpen sourceFile, BigQuery, Snowflake, RedshiftRedis, DynamoDB, SQLiteGratuitStartups, PME, self-hosted
TectonManagedS3, Snowflake, DatabricksDynamoDB (managed)$$$Enterprise, real-time ML
HopsworksOpen/ManagedHudi/HiveRonDB (MySQL NDB)$ - $$$On-prem, feature pipelines
Vertex AI FSManaged (GCP)BigQueryBigtable$$Equipes full GCP
Databricks FSManagedDelta LakeCosmos DB$$Equipes Databricks
Pourquoi un Feature Store est-il preferable a des JOINs SQL manuels pour le ML ?
3 raisons principales : 1) Point-in-time correctness : evite le data leakage en garantissant que chaque exemple d'entrainement n'utilise que les features disponibles a ce moment-la. 2) Reutilisabilite : les features sont calculees une fois et partagees entre tous les modeles, avec documentation et versioning. 3) Coherence train/serve : les memes features sont utilisees en training (offline) et en inference (online), eliminant le "training-serving skew" qui est une source majeure de bugs en ML.

Feast : Feature Store Open Source

50 min Avance

Objectifs de cette lecon

  • Installer et configurer Feast
  • Definir des Feature Views et des Entities
  • Materialiser des features dans l'online store
  • Recuperer des features pour le training et le serving

Feast est le choix pragmatique pour demarrer avec un Feature Store. Il est open source, supporte les principaux cloud providers, et s'integre bien avec votre stack existant. En 2026, c'est le standard de facto pour les equipes qui veulent un Feature Store sans vendor lock-in. Maitrisez-le et vous aurez une competence tres demandee.

Installation et Structure Projet

Bash
# Installation
pip install feast[redis,snowflake,gcp]

# Initialiser un projet Feast
feast init my_feature_repo
cd my_feature_repo

# Structure generee
my_feature_repo/
├── feature_repo/
│   ├── __init__.py
│   ├── feature_store.yaml    # Configuration
│   ├── entities.py           # Entites (customer, product)
│   ├── features.py           # Feature Views
│   └── data/                 # Donnees sources
└── README.md

Configuration (feature_store.yaml)

YAML
project: ecommerce_features
provider: gcp  # ou aws, local
registry: gs://my-bucket/feast/registry.pb
online_store:
  type: redis
  connection_string: "redis://localhost:6379"
offline_store:
  type: bigquery
entity_key_serialization_version: 2

Definir des Entities et Feature Views

Python
from feast import Entity, FeatureView, Field, FileSource, BigQuerySource
from feast.types import Float64, Int64, String
from datetime import timedelta

# Entite = la cle de jointure (ex: customer_id, product_id)
customer = Entity(
    name="customer",
    join_keys=["customer_id"],
    description="Customer entity for e-commerce"
)

# Source de donnees (BigQuery dans cet exemple)
customer_source = BigQuerySource(
    name="customer_stats_source",
    table="project.dataset.customer_daily_stats",
    timestamp_field="event_timestamp",
    created_timestamp_column="created_timestamp",
)

# Feature View = un ensemble de features pour une entite
customer_features = FeatureView(
    name="customer_features",
    entities=[customer],
    ttl=timedelta(days=3),  # Time-to-live dans l'online store
    schema=[
        Field(name="total_purchases_30d", dtype=Int64),
        Field(name="avg_order_value_7d", dtype=Float64),
        Field(name="days_since_last_order", dtype=Int64),
        Field(name="favorite_category", dtype=String),
        Field(name="lifetime_value", dtype=Float64),
        Field(name="churn_risk_score", dtype=Float64),
    ],
    source=customer_source,
    online=True,  # Materialiser dans l'online store
    tags={"team": "ml-platform", "version": "v2"},
)

Materialisation et Serving

Python
from feast import FeatureStore
import pandas as pd
from datetime import datetime

store = FeatureStore(repo_path="./feature_repo")

# 1. Appliquer les definitions (deploy)
# $ feast apply

# 2. Materialiser dans l'online store (batch)
# $ feast materialize 2026-01-01T00:00:00 2026-02-01T00:00:00

# 3. Recuperer les features pour le TRAINING (offline)
training_df = store.get_historical_features(
    entity_df=pd.DataFrame({
        "customer_id": ["C001", "C002", "C003"],
        "event_timestamp": [
            datetime(2026, 1, 1),
            datetime(2026, 1, 15),
            datetime(2026, 2, 1),
        ]
    }),
    features=[
        "customer_features:total_purchases_30d",
        "customer_features:avg_order_value_7d",
        "customer_features:days_since_last_order",
    ]
).to_df()

print(training_df)
# customer_id | event_timestamp | total_purchases_30d | avg_order_value_7d | ...

# 4. Recuperer les features pour l'INFERENCE (online, < 10ms)
online_features = store.get_online_features(
    features=[
        "customer_features:total_purchases_30d",
        "customer_features:avg_order_value_7d",
        "customer_features:churn_risk_score",
    ],
    entity_rows=[
        {"customer_id": "C001"},
        {"customer_id": "C002"},
    ]
).to_dict()

# Passer directement au modele ML
prediction = model.predict(online_features)

Feast en Production

AspectRecommandation
CI/CDfeast apply dans GitHub Actions a chaque merge
MaterialisationCron job (Airflow/Dagster) toutes les heures ou daily
MonitoringAlertes sur freshness, null rates, distribution drift
VersioningGit pour les definitions, registre Feast pour les metadata
TestingUnit tests sur les transformations, integration tests sur le serving
Quelle est la difference entre feast materialize et feast get-historical-features ?
feast materialize copie les features les plus recentes depuis l'offline store vers l'online store (Redis/DynamoDB) pour le serving en temps reel. C'est un processus batch execute periodiquement. get_historical_features effectue un point-in-time join sur l'offline store pour le training ML - il retourne les features telles qu'elles etaient a chaque timestamp specifie, sans toucher a l'online store.

Feature Engineering Patterns

45 min Avance

Objectifs de cette lecon

  • Maitriser les patterns de feature engineering pour le ML
  • Comprendre les features temporelles, aggregees et embeddings
  • Eviter les pieges courants (leakage, skew)
  • Designer des feature pipelines scalables

80% de la performance d'un modele ML vient des features, pas de l'algorithme. Un bon Data Architect comprend quels patterns de features sont utiles pour quels cas d'usage, et comment les calculer a l'echelle. Ce n'est pas du Data Science - c'est de l'ingenierie de donnees appliquee au ML.

Categories de Features

CategorieExemplesCalculLatence
StatiquesAge, pays, categorie produitLookup directImmediate
Aggregees (window)Achats 30j, panier moyen 7jSQL window / SparkBatch (heures)
TemporellesJours depuis dernier achat, heure du jourCalcul temps reelTemps reel
InteractionsRatio prix/moyenne categorieCross-entity joinBatch
TextuellesTF-IDF, embeddings texteNLP pipelineBatch/Stream
StreamingClics derniere minute, session activeFlink / Kafka StreamsTemps reel

Patterns SQL pour Feature Engineering

SQL
-- Feature engineering SQL pour un Feature Store
-- Calculer les features client pour le churn prediction

WITH customer_orders AS (
    SELECT
        customer_id,
        COUNT(*) AS total_orders_30d,
        AVG(order_total) AS avg_order_value_30d,
        MAX(order_total) AS max_order_value_30d,
        SUM(order_total) AS total_revenue_30d,
        COUNT(DISTINCT product_category) AS unique_categories_30d,
        DATEDIFF('day', MAX(order_date), CURRENT_DATE) AS days_since_last_order,
        -- Recency, Frequency, Monetary (RFM)
        NTILE(5) OVER (ORDER BY DATEDIFF('day', MAX(order_date), CURRENT_DATE)) AS recency_quintile,
        NTILE(5) OVER (ORDER BY COUNT(*)) AS frequency_quintile,
        NTILE(5) OVER (ORDER BY SUM(order_total)) AS monetary_quintile
    FROM orders
    WHERE order_date >= DATEADD('day', -30, CURRENT_DATE)
    GROUP BY customer_id
),
customer_sessions AS (
    SELECT
        customer_id,
        COUNT(*) AS sessions_7d,
        AVG(session_duration_sec) AS avg_session_duration_7d,
        SUM(CASE WHEN device = 'mobile' THEN 1 ELSE 0 END)::FLOAT
            / NULLIF(COUNT(*), 0) AS mobile_ratio_7d
    FROM sessions
    WHERE session_date >= DATEADD('day', -7, CURRENT_DATE)
    GROUP BY customer_id
)
SELECT
    o.customer_id,
    CURRENT_TIMESTAMP AS event_timestamp,
    o.total_orders_30d,
    o.avg_order_value_30d,
    o.days_since_last_order,
    o.recency_quintile * o.frequency_quintile * o.monetary_quintile AS rfm_score,
    COALESCE(s.sessions_7d, 0) AS sessions_7d,
    COALESCE(s.avg_session_duration_7d, 0) AS avg_session_duration_7d,
    COALESCE(s.mobile_ratio_7d, 0) AS mobile_ratio_7d
FROM customer_orders o
LEFT JOIN customer_sessions s ON o.customer_id = s.customer_id;

Pieges a Eviter

Training-Serving Skew

Le training-serving skew arrive quand les features utilisees en training (calculees en batch sur l'historique) different de celles utilisees en inference (calculees en temps reel). Exemple : en training, vous calculez avg_order_value_30d avec une requete SQL parfaite. En production, le meme calcul en streaming donne des resultats legerement differents a cause du windowing. Solution : utilisez un Feature Store qui garantit la coherence train/serve.

Data Leakage

Le data leakage arrive quand votre modele a acces a des informations du futur pendant l'entrainement. Exemples courants : utiliser le churn_date comme feature pour predire le churn, utiliser des features calculees APRES l'evenement cible, ne pas respecter le point-in-time correctness. Solution : toujours utiliser get_historical_features avec un timestamp explicite.

Qu'est-ce que le RFM scoring et pourquoi est-il utile comme feature ML ?
RFM = Recency, Frequency, Monetary. C'est un framework classique du marketing qui segmente les clients selon 3 dimensions : Recency (quand a-t-il achete pour la derniere fois ?), Frequency (combien de fois achete-t-il ?), Monetary (combien depense-t-il ?). En ML, ces 3 features (ou leur score combine) sont extremement predictives pour le churn, la lifetime value, et la propension a l'achat. Elles sont simples a calculer en SQL et stables dans le temps.

MLOps : Data Pipelines pour le ML

50 min Avance

Objectifs de cette lecon

  • Comprendre le lifecycle MLOps du point de vue Data Architect
  • Designer les pipelines de training data management
  • Mettre en place le versioning des datasets
  • Comprendre les feedback loops et les retraining triggers

Le MLOps est le DevOps du Machine Learning. En tant que Data Architect, votre role n'est pas de faire du ML, mais de designer l'infrastructure data qui le rend possible en production : comment les donnees d'entrainement sont gerees, versionnees, validees, et comment les predictions alimentent de nouvelles donnees. C'est un cycle continu, pas un projet one-shot.

Le Lifecycle MLOps

MLOps Lifecycle - Vue Data Architect
  ┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
  │  1. DATA     │     │  2. FEATURE  │     │  3. TRAINING │     │  4. MODEL    │
  │  COLLECTION  │────→│  ENGINEERING │────→│              │────→│  REGISTRY    │
  │              │     │              │     │ • Train/val  │     │              │
  │ • Raw data   │     │ • Feature    │     │   split      │     │ • MLflow     │
  │ • Labeling   │     │   Store      │     │ • Hyperparams│     │ • Version    │
  │ • Versioning │     │ • Transform  │     │ • Metrics    │     │ • Metadata   │
  │ • DVC/lakeFS │     │ • Validate   │     │              │     │ • Artifacts  │
  └──────────────┘     └──────────────┘     └──────────────┘     └──────┬───────┘
                                                                        │
  ┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────▼───────┐
  │  8. RETRAIN  │     │  7. MONITOR  │     │  6. A/B TEST │     │  5. SERVING  │
  │              │◄────│              │◄────│              │◄────│              │
  │ • Trigger    │     │ • Data drift │     │ • Shadow mode│     │ • REST API   │
  │ • Auto/manual│     │ • Model drift│     │ • Canary     │     │ • Batch      │
  │ • New data   │     │ • Performance│     │ • Champion/  │     │ • Streaming  │
  └──────────────┘     └──────────────┘     │   challenger │     └──────────────┘
                                            └──────────────┘
                            ▲                                          │
                            └──────────── Feedback Loop ───────────────┘

Training Data Management

Python (DVC)
# DVC (Data Version Control) - Versionner les datasets ML

# 1. Initialiser DVC dans le repo
# $ dvc init
# $ dvc remote add -d myremote s3://my-bucket/dvc-data

# 2. Tracker un dataset
# $ dvc add data/training_dataset_v3.parquet
# → Cree data/training_dataset_v3.parquet.dvc (pointeur)

# 3. Push vers le remote storage
# $ dvc push

# 4. Recuperer une version specifique
# $ git checkout v2.0  # Version Git du .dvc file
# $ dvc pull            # Telecharge le dataset correspondant

# Pipeline DVC pour reproduire le training
# dvc.yaml
stages:
  prepare:
    cmd: python src/prepare_data.py
    deps:
      - src/prepare_data.py
      - data/raw/
    outs:
      - data/processed/training.parquet

  train:
    cmd: python src/train.py
    deps:
      - src/train.py
      - data/processed/training.parquet
    params:
      - train.n_estimators
      - train.learning_rate
    metrics:
      - metrics.json:
          cache: false
    outs:
      - models/model.pkl

Feedback Loops et Retraining

Trigger de RetrainingDetectionAction
Data driftDistribution des features change (> seuil KS test)Retraining automatique
Concept driftPerformance du modele degrade (accuracy, F1)Retraining + evaluation
ScheduleCron (hebdomadaire, mensuel)Retraining periodique
Nouveau labelVolume de nouveaux labels suffisantRetraining incremental
Evenement businessLancement produit, saison, reglementationRetraining manuel

Data Architect vs ML Engineer vs Data Scientist

Data Scientist : choisit les algorithmes, tuning hyperparams, evaluation modeles.
ML Engineer : deploie les modeles, serving API, monitoring performance.
Data Architect : designe les pipelines data (ingestion → Feature Store → training data), le versioning (DVC/lakeFS), la data quality pour le ML, et l'infrastructure de feedback loops.

Qu'est-ce que le data drift et pourquoi est-ce critique pour les modeles en production ?
Le data drift est le changement dans la distribution statistique des donnees d'entree au fil du temps. Exemple : si un modele de churn est entraine sur des donnees de clients B2C, et que l'entreprise commence a avoir des clients B2B, les features vont changer de distribution. Le modele, entraine sur l'ancienne distribution, va perdre en performance silencieusement. C'est critique car sans monitoring, personne ne s'en rend compte jusqu'a ce que les predictions deviennent inutiles. Solution : monitoring continu (KS test, PSI) et retraining automatique.

Model Registry : MLflow & Weights & Biases

45 min Avance

Objectifs de cette lecon

  • Comprendre le role d'un Model Registry dans le MLOps
  • Configurer MLflow pour le tracking et le registry
  • Gerer les versions de modeles et le lifecycle
  • Comparer MLflow, W&B, Vertex AI Model Registry

Le Model Registry est au ML ce que le registry Docker est aux containers : un endroit centralise pour stocker, versionner et deployer vos modeles. Sans registry, les modeles sont dans des notebooks, sur les laptops des Data Scientists, ou dans des buckets S3 sans organisation. MLflow est le standard open source - c'est gratuit, mature et bien integre.

MLflow - Architecture

MLflow - Composants
  ┌──────────────────────────────────────────────────────────────┐
  │                         MLflow                                │
  │                                                              │
  │  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐    │
  │  │  TRACKING     │  │  MODEL        │  │  PROJECTS     │    │
  │  │               │  │  REGISTRY     │  │               │    │
  │  │ • Experiments │  │ • Versions    │  │ • Packaging   │    │
  │  │ • Runs        │  │ • Stages:     │  │ • Reproducib. │    │
  │  │ • Params      │  │   None →      │  │ • MLproject   │    │
  │  │ • Metrics     │  │   Staging →   │  │   file        │    │
  │  │ • Artifacts   │  │   Production →│  │               │    │
  │  │ • Tags        │  │   Archived    │  │               │    │
  │  └───────────────┘  └───────────────┘  └───────────────┘    │
  │                                                              │
  │  Backend Store: PostgreSQL    Artifact Store: S3/GCS/ADLS    │
  └──────────────────────────────────────────────────────────────┘

MLflow Tracking - Code Example

Python
import mlflow
import mlflow.sklearn
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.metrics import accuracy_score, f1_score, roc_auc_score

# Configuration MLflow
mlflow.set_tracking_uri("http://mlflow-server:5000")
mlflow.set_experiment("churn-prediction")

# Training avec MLflow tracking
with mlflow.start_run(run_name="gbm-v3") as run:
    # Log des parametres
    params = {"n_estimators": 200, "learning_rate": 0.1, "max_depth": 5}
    mlflow.log_params(params)

    # Training
    model = GradientBoostingClassifier(**params)
    model.fit(X_train, y_train)

    # Predictions et metriques
    y_pred = model.predict(X_test)
    y_proba = model.predict_proba(X_test)[:, 1]

    metrics = {
        "accuracy": accuracy_score(y_test, y_pred),
        "f1_score": f1_score(y_test, y_pred),
        "auc_roc": roc_auc_score(y_test, y_proba),
    }
    mlflow.log_metrics(metrics)

    # Log du modele + signature
    from mlflow.models import infer_signature
    signature = infer_signature(X_test, y_pred)
    mlflow.sklearn.log_model(
        model, "churn-model",
        signature=signature,
        registered_model_name="churn-predictor"
    )

    # Log artifacts supplementaires
    mlflow.log_artifact("feature_importance.png")
    mlflow.log_dict({"features": feature_names}, "feature_list.json")

    print(f"Run ID: {run.info.run_id}")
    print(f"Metrics: {metrics}")

Model Registry - Lifecycle

Python
from mlflow import MlflowClient

client = MlflowClient()

# Promouvoir un modele en Staging
client.transition_model_version_stage(
    name="churn-predictor",
    version=3,
    stage="Staging"
)

# Apres validation, promouvoir en Production
client.transition_model_version_stage(
    name="churn-predictor",
    version=3,
    stage="Production"
)

# Charger le modele en production pour le serving
import mlflow.pyfunc
model = mlflow.pyfunc.load_model("models:/churn-predictor/Production")
predictions = model.predict(new_data)

Comparaison Model Registries

SolutionTypeForcesFaiblessesPrix
MLflowOpen sourceStandard, flexible, multi-frameworkUI basique, pas de collaboration nativeGratuit
W&B (Weights & Biases)SaaS/self-hostedUI excellente, collaboration, sweepsPayant pour teams, vendor lock-in$ - $$$
Vertex AI Model RegistryManaged (GCP)Integre GCP, auto-deploymentGCP only$$
SageMaker Model RegistryManaged (AWS)Integre AWS, pipelines natifsAWS only$$
Quels sont les 3 stages du Model Registry dans MLflow ?
Les 3 stages sont : 1) None/Staging : le modele vient d'etre enregistre, il est en cours de validation (tests, reviews). 2) Production : le modele a ete valide et deploye pour servir des predictions reelles. Seul le modele "Production" est utilise par l'API de serving. 3) Archived : l'ancien modele Production, remplace par une nouvelle version. Conserve pour rollback et audit. Ce lifecycle permet un deploiement controle avec validation avant mise en production.

A/B Testing Infrastructure & Model Monitoring

45 min Avance

Objectifs de cette lecon

  • Designer l'infrastructure pour l'A/B testing de modeles ML
  • Comprendre les patterns de deployment : shadow, canary, blue-green
  • Mettre en place le monitoring de modeles (drift, performance)
  • Configurer les alertes et le retraining automatique

Deployer un modele sans A/B testing, c'est comme deployer du code sans tests. Vous ne savez pas si le nouveau modele est meilleur que l'ancien. Et deployer sans monitoring, c'est conduire de nuit sans phares. Le Data Architect doit designer l'infrastructure qui permet de deployer des modeles en toute confiance et de detecter les problemes avant qu'ils n'impactent le business.

Patterns de Deployment ML

ML Deployment Patterns
  SHADOW MODE                   CANARY RELEASE              CHAMPION/CHALLENGER
  ═══════════                   ══════════════              ═══════════════════

  ┌─────────┐                  ┌─────────┐                ┌─────────┐
  │ Request │                  │ Request │                │ Request │
  └────┬────┘                  └────┬────┘                └────┬────┘
       │                            │                          │
  ┌────▼────┐                  ┌────▼────┐                ┌────▼────┐
  │ Router  │                  │ Router  │                │ Router  │
  └──┬───┬──┘                  └──┬───┬──┘                └──┬───┬──┘
     │   │                        │   │                      │   │
  ┌──▼┐ ┌▼──┐                 ┌──▼┐ ┌▼──┐               ┌──▼┐ ┌▼──┐
  │v1 │ │v2 │                 │v1 │ │v2 │               │v1 │ │v2 │
  │OLD│ │NEW│                 │95%│ │5% │               │50%│ │50%│
  └─┬─┘ └─┬─┘                 └─┬─┘ └─┬─┘               └─┬─┘ └─┬─┘
    │     │                      │     │                    │     │
  Serve  Log only            Serve  Serve              Serve  Serve
  v1     (compare)           both   both               both   both

Monitoring de Modeles

Type de MonitoringMetriquesOutilsSeuil d'alerte
Data DriftKS test, PSI, chi-squareEvidently, Whylogs, NannyMLPSI > 0.2
Concept DriftAccuracy, F1, AUC degradationMLflow + custom dashboardsDrop > 5% vs baseline
Prediction DriftDistribution des predictionsEvidently, customDistribution shift significatif
Latencep50, p95, p99 latencyPrometheus + Grafanap99 > 100ms
InfrastructureCPU, RAM, GPU utilizationPrometheus, CloudWatchGPU > 80% sustained
Python (Evidently)
# Monitoring du data drift avec Evidently
from evidently.report import Report
from evidently.metric_preset import DataDriftPreset, DataQualityPreset

# Comparer les donnees de reference (training) avec la production
drift_report = Report(metrics=[
    DataDriftPreset(),
    DataQualityPreset(),
])

drift_report.run(
    reference_data=training_data,  # Donnees d'entrainement
    current_data=production_data,  # Donnees recentes en prod
)

# Generer le rapport HTML
drift_report.save_html("drift_report.html")

# Verifier programmatiquement si drift detecte
result = drift_report.as_dict()
dataset_drift = result["metrics"][0]["result"]["dataset_drift"]
if dataset_drift:
    print("ALERT: Data drift detected! Retraining recommended.")
    # Trigger retraining pipeline via Airflow/Dagster
Quelle est la difference entre le shadow mode et le canary release pour le deployment ML ?
Shadow mode : le nouveau modele recoit les memes requetes que l'ancien, mais ses predictions sont uniquement loggees, pas servies aux utilisateurs. On compare les predictions offline. Ideal pour valider un modele sans risque. Canary release : le nouveau modele recoit un petit pourcentage du trafic reel (ex: 5%). Les predictions sont servies aux vrais utilisateurs. On compare les metriques business en temps reel. Plus risque mais donne des metriques business reelles (conversion, revenue).

Quiz : AI/ML Data Infrastructure

20 min Intermediaire

Objectifs de cette lecon

  • Valider vos connaissances sur les Feature Stores
  • Verifier votre comprehension de MLOps et MLflow
  • Tester vos connaissances sur le monitoring ML

Question 1

Quelle est la principale raison d'utiliser un Feature Store plutot que des JOINs SQL manuels ?
A) Les Feature Stores sont plus rapides que SQL
B) Garantir la point-in-time correctness et la coherence train/serve
C) Les Feature Stores coutent moins cher que SQL
D) Les Feature Stores remplacent completement le Data Warehouse

Question 2

Quel store Feast est utilise pour le serving en temps reel (< 10ms) ?
A) Offline Store (BigQuery)
B) Online Store (Redis)
C) Feature Registry
D) Model Registry (MLflow)

Question 3

Qu'est-ce que le training-serving skew ?
A) Un modele qui prend trop de temps a entrainer
B) Un dataset desequilibre entre classes positives et negatives
C) La difference entre les features utilisees en training et celles en inference
D) Un modele qui overfitte sur les donnees de test

Question 4

Quel outil open source est le standard pour le model registry et le tracking d'experiences ML ?
A) Feast
B) MLflow
C) Airflow
D) DVC

Question 5

Quel pattern de deployment ML permet de comparer les predictions SANS servir le nouveau modele aux utilisateurs ?
A) Shadow mode
B) Canary release
C) Blue-green deployment
D) Rolling update

Si vous avez 4/5 ou plus, vous maitrisez les fondamentaux de l'infrastructure AI/ML. La suite va vous plonger dans les technologies les plus excitantes de 2026 : les Vector Databases et les LLMs. C'est la ou l'IA generative rencontre l'architecture data.

Vector Databases : Concepts & Embeddings

50 min Intermediaire

Objectifs de cette lecon

  • Comprendre les embeddings et la recherche vectorielle
  • Maitriser les algorithmes d'indexation ANN (HNSW, IVF)
  • Identifier les cas d'usage des vector databases
  • Comprendre les metriques de similarite (cosine, L2, dot product)

Les Vector Databases sont la revolution silencieuse de 2024-2026. Elles permettent de chercher par "sens" plutot que par mots-cles. Quand vous cherchez "comment reduire les couts cloud" dans une base de docs, une recherche classique ne trouve que les documents contenant ces mots exacts. Une recherche vectorielle trouve aussi "optimiser la facture AWS" ou "strategies FinOps" parce qu'elle comprend le sens semantique. C'est le fondement du RAG et de l'IA generative en entreprise.

Comment fonctionnent les Embeddings

Texte → Embedding → Recherche Vectorielle
  Texte original              Embedding Model            Espace vectoriel
  ══════════════              ═══════════════            ════════════════

  "Data warehouse             ┌──────────────┐          [0.23, -0.45, 0.67, ...]
   pour analytics" ──────────→│ OpenAI       │─────────→  (1536 dimensions)
                              │ text-embedding│
  "Comment reduire            │ -3-large     │          [0.21, -0.48, 0.69, ...]
   les couts cloud" ─────────→│              │─────────→  (similaire! cosine=0.92)
                              │              │
  "Recette de                 │              │          [-0.78, 0.34, -0.12, ...]
   gateau chocolat" ─────────→│              │─────────→  (tres different!)
                              └──────────────┘

  Recherche : query_embedding vs tous les embeddings stockes
  → Retourne les K plus proches voisins (KNN / ANN)

Metriques de Similarite

MetriqueFormulePlageUsage ideal
Cosine Similaritycos(A, B) = A·B / (|A|×|B|)[-1, 1]Texte, documents (plus courant)
Euclidean (L2)d = sqrt(sum((ai-bi)²))[0, +inf]Images, features numeriques
Dot ProductA·B = sum(ai×bi)[-inf, +inf]Recommendations (quand magnitude compte)

Algorithmes d'Indexation ANN

AlgorithmePrincipeRecallVitesseMemoire
HNSWGraphe hierarchique navigableTres eleve (99%+)RapideElevee (en RAM)
IVFPartitionnement en clusters (Voronoi)Bon (~95%)RapideModeree
PQ (Product Quantization)Compression des vecteursMoyen (~90%)Tres rapideFaible
IVF-PQCombinaison IVF + PQBonRapideFaible
Flat (brute force)Recherche exhaustive100%Lent (O(n))Faible

HNSW : l'algorithme dominant

HNSW (Hierarchical Navigable Small World) est l'algorithme le plus utilise en 2026. Il construit un graphe multi-couches : les couches hautes pour la navigation rapide (liens longue distance), les couches basses pour la precision (liens proches voisins). La recherche part du haut et descend progressivement. Complexite : O(log n) pour la recherche, O(n × log n) pour la construction. Trade-off : haute recall mais consomme beaucoup de RAM.

Cas d'usage des Vector Databases

Cas d'usageInputEmbeddingResultat
RAG (chatbot)Question utilisateurTexte → vecteurDocuments pertinents comme contexte LLM
Recherche semantiqueRequete en langage naturelTexte → vecteurDocuments, articles, FAQ similaires
RecommandationsProduit consulteItem → vecteurProduits similaires
Detection d'anomaliesTransactionFeatures → vecteurTransactions les plus differentes
DeduplicationNouveau recordRecord → vecteurRecords quasi-identiques
Pourquoi utilise-t-on des algorithmes ANN (Approximate Nearest Neighbors) plutot que la recherche exacte KNN ?
La recherche exacte KNN a une complexite O(n × d) ou n est le nombre de vecteurs et d la dimension. Pour 10 millions de vecteurs en 1536 dimensions, c'est beaucoup trop lent (secondes). Les algorithmes ANN comme HNSW atteignent une complexite O(log n) en echangeant un peu de precision (recall ~99%) contre une vitesse enormement superieure (millisecondes). En pratique, perdre 1% de recall pour gagner 100x en vitesse est un excellent trade-off pour la plupart des applications.

Pinecone, Weaviate, Milvus & pgvector

45 min Avance

Objectifs de cette lecon

  • Comparer les principales vector databases du marche
  • Comprendre quand utiliser chaque solution
  • Implementer une recherche vectorielle avec pgvector
  • Evaluer les criteres de choix pour votre architecture

Le marche des vector databases est en pleine explosion. Mon conseil : commencez par pgvector si vous avez deja PostgreSQL - c'est gratuit, simple et suffisant pour 90% des cas. N'allez vers Pinecone ou Weaviate que si vous avez des besoins specifiques (>10M vecteurs, latence < 5ms, multi-tenancy complexe).

Comparaison des Vector Databases

SolutionTypeIndexationMax vecteursHybrid SearchPrixIdeal pour
pgvectorExtension PostgreSQLIVFFlat, HNSW~10MOui (avec pg_trgm)GratuitPME, deja sur PostgreSQL
PineconeSaaS manageProprietaireIllimiteOui (sparse+dense)$$$Enterprise, zero-ops
WeaviateOpen source/CloudHNSW100M+Oui (BM25 + vector)Gratuit / $$Recherche semantique avancee
MilvusOpen sourceIVF, HNSW, DiskANN1B+OuiGratuitScale massive, on-prem
QdrantOpen source/CloudHNSW100M+Oui (filtrage)Gratuit / $$Filtrage avance, Rust perf
ChromaDBOpen sourceHNSW~1MBasiqueGratuitPrototypage, dev local

pgvector - Implementation

SQL
-- Installation de pgvector
CREATE EXTENSION vector;

-- Creer une table avec une colonne vector
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    title TEXT,
    content TEXT,
    metadata JSONB,
    embedding vector(1536),  -- OpenAI text-embedding-3-large
    created_at TIMESTAMP DEFAULT NOW()
);

-- Creer un index HNSW (recommande pour < 10M vecteurs)
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 200);

-- Inserer des documents avec embeddings
INSERT INTO documents (title, content, embedding)
VALUES (
    'Guide FinOps',
    'Strategies pour optimiser les couts cloud...',
    '[0.023, -0.045, 0.067, ...]'::vector
);

-- Recherche des 5 documents les plus similaires (cosine)
SELECT
    id, title,
    1 - (embedding <=> query_embedding) AS similarity
FROM documents
ORDER BY embedding <=> '[0.021, -0.048, 0.069, ...]'::vector
LIMIT 5;

-- Hybrid search : vecteur + filtre metadonnees
SELECT id, title,
    1 - (embedding <=> query_embedding) AS similarity
FROM documents
WHERE metadata->>'category' = 'architecture'
  AND created_at > '2026-01-01'
ORDER BY embedding <=> query_embedding
LIMIT 5;

Python - pgvector avec LangChain

Python
from langchain_community.vectorstores import PGVector
from langchain_openai import OpenAIEmbeddings
from langchain.text_splitter import RecursiveCharacterTextSplitter

# Configuration
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
connection_string = "postgresql://user:pass@localhost:5432/vectordb"

# Charger et decouper les documents
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200,
    separators=["\n\n", "\n", ". ", " "]
)
chunks = text_splitter.split_documents(documents)

# Creer le vector store
vectorstore = PGVector.from_documents(
    documents=chunks,
    embedding=embeddings,
    connection_string=connection_string,
    collection_name="architecture_docs",
)

# Recherche semantique
results = vectorstore.similarity_search_with_score(
    query="Comment optimiser les couts Snowflake ?",
    k=5
)
for doc, score in results:
    print(f"Score: {score:.3f} | {doc.page_content[:100]}...")

Quand choisir quelle solution ?

pgvector : vous avez deja PostgreSQL, < 10M vecteurs, equipe SQL. Le choix pragmatique.
Pinecone : vous voulez zero ops, budget disponible, besoin d'echelle automatique.
Weaviate : recherche semantique avancee, hybrid search, multi-modal (texte + image).
Milvus : scale massive (> 100M vecteurs), on-premises, equipe infra capable.
ChromaDB : prototypage rapide, dev local, POCs.

Qu'est-ce que l'hybrid search et pourquoi est-ce important ?
L'hybrid search combine la recherche vectorielle (semantique, par sens) et la recherche par mots-cles (lexicale, BM25/TF-IDF). La recherche vectorielle seule peut manquer des termes techniques precis (ex: "ADR-003" ne sera pas trouve semantiquement). La recherche par mots-cles seule manque les synonymes et le contexte. En combinant les deux (avec un score fusionne), on obtient les meilleurs resultats. Weaviate et Pinecone supportent l'hybrid search nativement. Avec pgvector, on combine vector <=> et pg_trgm.

RAG : Retrieval-Augmented Generation

55 min Avance

Objectifs de cette lecon

  • Comprendre l'architecture RAG et ses composants
  • Maitriser les strategies de chunking
  • Designer un pipeline RAG production-ready
  • Evaluer la qualite d'un systeme RAG

Le RAG est la killer app des Vector Databases. Au lieu d'entrainer un LLM sur vos donnees (couteux, lent, risque de hallucinations), vous lui donnez du contexte pertinent a chaque requete. C'est comme donner a ChatGPT un document de reference avant de lui poser une question. En tant que Data Architect, vous designez le pipeline : ingestion des documents, chunking, embedding, stockage vectoriel, retrieval, et augmentation du prompt.

Architecture RAG

Pipeline RAG - Architecture Complete
  ═══ INDEXATION (offline, batch) ═══

  Documents           Chunking            Embedding           Vector Store
  ┌──────────┐      ┌──────────┐      ┌──────────────┐     ┌────────────┐
  │ PDF, MD,  │─────→│ Split en │─────→│ OpenAI /     │────→│ pgvector / │
  │ HTML,     │      │ chunks   │      │ Cohere /     │     │ Pinecone / │
  │ Confluence│      │ 500-1000 │      │ sentence-    │     │ Weaviate   │
  │ Notion    │      │ tokens   │      │ transformers │     │            │
  └──────────┘      └──────────┘      └──────────────┘     └────────────┘

  ═══ RETRIEVAL & GENERATION (online, par requete) ═══

  Question          Embedding         Recherche          Augmentation       Reponse
  ┌──────────┐    ┌──────────┐     ┌──────────┐      ┌──────────────┐   ┌──────────┐
  │"Comment   │───→│ Meme     │────→│ Top-K    │─────→│ Prompt:      │──→│ Reponse  │
  │ optimiser │    │ embedding│     │ vecteurs │      │ "Contexte:   │   │ fondee   │
  │ Snowflake│    │ model    │     │ similaires│      │  {chunks}    │   │ sur les  │
  │ ?"        │    └──────────┘     └──────────┘      │  Question:   │   │ sources  │
  └──────────┘                                        │  {query}"    │   └──────────┘
                                                      │ → LLM (GPT-4)│
                                                      └──────────────┘

Strategies de Chunking

StrategieDescriptionTaille typiqueQuand l'utiliser
Fixed sizeDecouper tous les N tokens500-1000 tokensContenu homogene (logs, code)
RecursiveDecouper par separateurs hierarchiques (\n\n → \n → . )500-1500 tokensDocuments textuels (le plus courant)
SemanticDecouper quand le sens change (embedding similarity)VariableDocuments complexes, multi-sujets
DocumentUn chunk = un document entierVariableFAQ, fiches produit, articles courts
Parent-childPetits chunks pour retrieval, grands chunks pour contexte200 (child) / 2000 (parent)Meilleure qualite (avance)
Python
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import PGVector
from langchain.chains import RetrievalQA
from langchain.prompts import PromptTemplate

# 1. Chunking avec overlap
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,       # ~250 mots
    chunk_overlap=200,     # 20% overlap pour le contexte
    separators=["\n\n", "\n", ". ", " "],
    length_function=len,
)
chunks = text_splitter.split_documents(raw_documents)
print(f"{len(raw_documents)} docs → {len(chunks)} chunks")

# 2. Embedding et stockage
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = PGVector.from_documents(
    documents=chunks,
    embedding=embeddings,
    connection_string=CONNECTION_STRING,
    collection_name="company_docs",
)

# 3. RAG Chain avec prompt custom
prompt_template = """Tu es un assistant expert en data architecture.
Utilise UNIQUEMENT le contexte ci-dessous pour repondre.
Si tu ne sais pas, dis "Je n'ai pas cette information dans mes sources."

Contexte:
{context}

Question: {question}

Reponse detaillee:"""

PROMPT = PromptTemplate(
    template=prompt_template,
    input_variables=["context", "question"]
)

# 4. Chain RAG complete
llm = ChatOpenAI(model="gpt-4o", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vectorstore.as_retriever(
        search_type="similarity",
        search_kwargs={"k": 5}
    ),
    chain_type_kwargs={"prompt": PROMPT},
    return_source_documents=True,
)

# 5. Utilisation
result = qa_chain.invoke({"query": "Comment optimiser les couts Snowflake ?"})
print(result["result"])
for doc in result["source_documents"]:
    print(f"  Source: {doc.metadata['source']}")

Evaluation d'un Systeme RAG

MetriqueMesureSeuil acceptable
Retrieval Precision@K% de chunks pertinents parmi les K recuperes> 70%
Retrieval Recall@K% de chunks pertinents retrouves sur le total pertinent> 80%
Answer RelevancyLa reponse repond-elle a la question ? (LLM judge)> 85%
FaithfulnessLa reponse est-elle fidele au contexte ? (pas d'hallucination)> 90%
Latence E2ETemps total (embedding + retrieval + LLM)< 5 secondes

Pieges courants du RAG

1. Chunks trop grands : le LLM perd le contexte pertinent dans le bruit. Solution : 500-1000 tokens max.
2. Pas d'overlap : les phrases coupees en plein milieu. Solution : 10-20% overlap.
3. Mauvais embedding model : un modele generique pour du contenu technique specialise. Solution : fine-tuner ou utiliser un modele domain-specific.
4. Top-K trop petit : manque de contexte. Solution : K=5 minimum, tester jusqu'a K=10.
5. Pas de reranking : les premiers resultats ne sont pas toujours les plus pertinents. Solution : ajouter un reranker (Cohere Rerank, cross-encoder).

Quelle est la difference entre RAG et le fine-tuning d'un LLM ?
RAG (Retrieval-Augmented Generation) : a chaque requete, on recupere des documents pertinents et on les passe comme contexte au LLM. Avantages : pas besoin de re-entrainer, donnees toujours a jour, sources citables, cout faible. Fine-tuning : on re-entraine le LLM sur vos donnees specifiques. Avantages : style et ton personnalises, pas besoin de retrieval a chaque requete. En pratique : RAG est recommande pour 90% des cas (FAQ, docs internes, support). Le fine-tuning est reserve aux cas ou vous avez besoin d'un comportement tres specifique (style de communication, terminologie metier tres pointue).

LLM Infrastructure : Serving & Scaling

50 min Avance

Objectifs de cette lecon

  • Comprendre les architectures de serving LLM (vLLM, TGI)
  • Optimiser les couts d'inference LLM
  • Designer un LLM Gateway pour l'entreprise
  • Maitriser le batching, le caching et le routing

Servir un LLM en production est un defi d'infrastructure majeur. Un seul appel GPT-4 coute 10-100x plus qu'une requete SQL. Multipliez ca par des milliers d'utilisateurs et le budget explose. Le role du Data Architect est de designer une infrastructure qui maximise la qualite des reponses tout en controlant les couts : caching intelligent, routing vers le bon modele, batching des requetes.

Architecture LLM Gateway

Enterprise LLM Gateway
  Applications                LLM Gateway                    Models
  ════════════                ═══════════                    ══════

  ┌──────────┐             ┌─────────────────┐          ┌──────────────┐
  │ Chatbot  │────────────→│                 │         │ GPT-4o       │
  └──────────┘             │   LLM Gateway   │────────→│ (complexe)   │
  ┌──────────┐             │                 │         └──────────────┘
  │ Search   │────────────→│ • Auth & Rate   │         ┌──────────────┐
  └──────────┘             │   Limiting      │────────→│ Claude 3.5   │
  ┌──────────┐             │ • Prompt Cache  │         │ (analytique) │
  │ Code     │────────────→│ • Smart Routing │         └──────────────┘
  │ Assistant│             │ • Cost Tracking │         ┌──────────────┐
  └──────────┘             │ • Fallback      │────────→│ Llama 3.1    │
  ┌──────────┐             │ • Guardrails    │         │ (self-hosted)│
  │ API      │────────────→│ • Logging       │         └──────────────┘
  └──────────┘             │ • A/B Testing   │         ┌──────────────┐
                           └─────────────────┘         │ Mistral      │
                                    │                  │ (rapide, EU) │
                           ┌────────▼────────┐         └──────────────┘
                           │ Semantic Cache  │
                           │ (Vector DB)     │
                           └─────────────────┘

Outils de Serving LLM

OutilTypeModeles supportesFeatures clesUsage
vLLMOpen sourceLlama, Mistral, FalconPagedAttention, continuous batching, tres rapideSelf-hosting production
TGI (HuggingFace)Open sourceTous HF modelsFlash Attention, quantization, simpleSelf-hosting, prototypage
OllamaOpen sourceLlama, Mistral, PhiTres simple (1 commande), localDev local, experimentation
LiteLLMOpen source100+ providersInterface unifiee, fallbacks, load balancingLLM Gateway / proxy
OpenAI APISaaSGPT-4o, GPT-4-turboZero ops, haute qualiteProduction, pas de GPU

Optimisation des Couts LLM

Strategies
═══ STRATEGIES D'OPTIMISATION (par impact) ═══

1. SEMANTIC CACHING (economie: 30-60%)
   Stocker les reponses dans un vector DB.
   Si une question similaire arrive (cosine > 0.95),
   retourner la reponse cachee au lieu d'appeler le LLM.
   → Cout: 1 embedding ($0.0001) vs 1 appel GPT-4 ($0.03)

2. SMART ROUTING (economie: 40-70%)
   Questions simples → Modele petit (GPT-3.5, Mistral 7B)
   Questions complexes → Modele puissant (GPT-4o, Claude)
   Classification automatique de la complexite.
   → GPT-3.5: $0.001/req vs GPT-4: $0.03/req

3. PROMPT OPTIMIZATION (economie: 20-40%)
   Reduire la taille des prompts systeme.
   Utiliser des exemples concis (few-shot).
   Limiter le contexte RAG aux chunks les plus pertinents.
   → Moins de tokens = moins cher

4. BATCHING (economie: 15-25%)
   Regrouper les requetes non-urgentes.
   Traitement batch pendant les heures creuses.
   → Meilleur throughput, meilleur prix

5. QUANTIZATION (economie: 50-70% sur GPU)
   Self-hosted: utiliser des modeles quantizes (GPTQ, AWQ).
   Llama 3.1 70B en 4-bit: 40GB VRAM vs 140GB en FP16.
   → Meme GPU, modele 3x plus grand
Qu'est-ce que le semantic caching pour les LLMs et pourquoi est-ce efficace ?
Le semantic caching stocke les paires (question, reponse) dans un vector database. Pour chaque nouvelle question, on cherche d'abord dans le cache si une question semantiquement similaire a deja ete posee (cosine similarity > 0.95). Si oui, on retourne la reponse cachee sans appeler le LLM. C'est efficace car dans une entreprise, 30-60% des questions sont des variantes des memes sujets. Le cout d'un embedding ($0.0001) est 300x moins cher qu'un appel GPT-4 ($0.03). C'est la premiere optimisation a implementer.

Prompt Management & Fine-tuning Pipelines

45 min Avance

Objectifs de cette lecon

  • Mettre en place le versioning et la gestion des prompts
  • Comprendre les pipelines de fine-tuning de LLMs
  • Designer l'infrastructure de donnees pour le fine-tuning
  • Evaluer les modeles avec des benchmarks et datasets

Les prompts sont le "code" de l'IA generative. Comme le code, ils doivent etre versionnes, testes et deployes proprement. Un prompt mal concu peut faire halluciner le meilleur modele du monde. Un prompt bien concu peut faire performer un petit modele comme un grand. En tant que Data Architect, vous designez l'infrastructure de gestion des prompts et des datasets de fine-tuning.

Prompt Management

YAML
# prompts/rag_assistant/v3.yaml
name: "rag_data_architect"
version: "3.2.0"
model: "gpt-4o"
temperature: 0.1
max_tokens: 2000

system_prompt: |
  Tu es un assistant expert en data architecture.
  Regles:
  - Reponds UNIQUEMENT avec le contexte fourni
  - Cite tes sources (nom du document, section)
  - Si tu ne sais pas, dis-le clairement
  - Utilise des exemples concrets
  - Structure ta reponse avec des bullet points

user_template: |
  Contexte:
  {context}

  Question de l'utilisateur:
  {question}

  Instructions supplementaires:
  - Niveau de detail: {detail_level}
  - Langue: francais

metadata:
  author: "data-platform-team"
  created: "2026-01-15"
  tags: ["rag", "data-architecture", "production"]
  tests:
    - "test_no_hallucination"
    - "test_source_citation"
    - "test_language_fr"

Pipeline de Fine-tuning

Fine-tuning Pipeline
  ┌────────────┐    ┌────────────┐    ┌────────────┐    ┌────────────┐    ┌────────────┐
  │ 1. DATA    │    │ 2. FORMAT  │    │ 3. TRAIN   │    │ 4. EVAL    │    │ 5. DEPLOY  │
  │ COLLECTION │───→│            │───→│            │───→│            │───→│            │
  │            │    │ JSONL      │    │ Fine-tune  │    │ Benchmark  │    │ Serve via  │
  │ • Chat logs│    │ format     │    │ API        │    │ datasets   │    │ API / vLLM │
  │ • Expert   │    │ (messages) │    │ LoRA/QLoRA │    │ Human eval │    │            │
  │   answers  │    │ Train/val  │    │ Full FT    │    │ Auto eval  │    │ Monitor    │
  │ • Docs     │    │ split      │    │            │    │            │    │ Costs      │
  └────────────┘    └────────────┘    └────────────┘    └────────────┘    └────────────┘

Format de Donnees Fine-tuning

JSONL
{"messages": [
  {"role": "system", "content": "Tu es un expert Data Architect qui repond de facon concise et technique."},
  {"role": "user", "content": "Quand utiliser Snowflake vs BigQuery ?"},
  {"role": "assistant", "content": "**Snowflake** : SQL standard, separation compute/storage, ideal si multi-cloud ou data sharing. **BigQuery** : serverless natif, ideal si full GCP, ML integre avec Vertex AI. Choisir selon : cloud existant, pattern de workload (concurrency vs burst), et budget (Snowflake = credit-based, BigQuery = pay-per-query)."}
]}
{"messages": [
  {"role": "system", "content": "Tu es un expert Data Architect qui repond de facon concise et technique."},
  {"role": "user", "content": "Comment implementer un Data Mesh ?"},
  {"role": "assistant", "content": "1. **Identifier les domaines** metier (sales, product, marketing). 2. **Definir les data products** par domaine avec SLAs et documentation. 3. **Creer la self-serve platform** (infra commune : data lake, orchestration, CI/CD). 4. **Implementer la federated governance** : standards globaux (naming, quality) + autonomie locale. Prerequis : maturite org, >100 personnes data, domaines clairement definis."}
]}

Evaluation de Modeles

MethodeDescriptionQuand l'utiliser
Benchmark datasetsJeux de test standardises (MMLU, HumanEval)Comparer des modeles generiques
Custom eval set100-500 paires (question, reponse attendue) de votre domaineEvaluer le fine-tuning sur votre cas
LLM-as-JudgeUtiliser GPT-4 pour noter les reponses automatiquementScale evaluation, iterer rapidement
Human evaluationExperts notent les reponses (1-5)Validation finale avant production
A/B testingComparer les metriques business en prodMesurer l'impact reel
Quand faut-il fine-tuner un LLM plutot qu'utiliser du RAG ?
Le fine-tuning est recommande quand : 1) Vous avez besoin d'un style/ton specifique (jargon metier, format de reponse precis). 2) Vous voulez reduire les couts en utilisant un petit modele fine-tune au lieu d'un gros modele generique. 3) Vous avez suffisamment de donnees de qualite (500+ exemples). Le RAG est preferable quand : 1) Les donnees changent frequemment. 2) Vous avez besoin de citer vos sources. 3) Vous n'avez pas assez de donnees pour le fine-tuning. En pratique, la combinaison RAG + fine-tuning est la plus puissante.

Ethical AI & Data Governance pour l'IA

45 min Avance

Objectifs de cette lecon

  • Identifier les biais dans les donnees d'entrainement
  • Comprendre les fairness metrics
  • Implementer la data lineage pour l'explicabilite
  • Designer un AI governance framework

L'IA sans ethique, c'est un risque business majeur. Un modele biaise peut discriminer des clients, un LLM peut divulguer des donnees confidentielles, un algorithme opaque peut violer le RGPD. En tant que Data Architect, vous etes le gardien de la qualite et de l'ethique des donnees qui alimentent l'IA. C'est une responsabilite qui depasse la technique.

Sources de Biais dans les Donnees

Type de biaisDescriptionExempleMitigation
Selection biasDonnees non representativesDataset de recrutement = 90% hommesSampling equilibre, augmentation
Historical biasDonnees refletent des discriminations passeesScores de credit historiquement biaisesFairness constraints dans le modele
Measurement biasQualite de mesure inegale entre groupesReconnaissance faciale moins precise pour certaines ethniesEvaluation par sous-groupe
Label biasAnnotations humaines biaiseesAnnotateurs avec biais culturelsMulti-annotateurs, guidelines claires
Representation biasSous-representation de certains groupesLLM entraine majoritairement en anglaisDonnees multilingues, fine-tuning

AI Governance Framework

AI Governance - 4 Piliers
  ┌─────────────────────────────────────────────────────────────────┐
  │                    AI GOVERNANCE FRAMEWORK                       │
  │                                                                 │
  │  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐      │
  │  │ 1. DATA       │  │ 2. MODEL      │  │ 3. DEPLOYMENT │      │
  │  │ GOVERNANCE    │  │ GOVERNANCE    │  │ GOVERNANCE    │      │
  │  │               │  │               │  │               │      │
  │  │ • Data lineage│  │ • Model cards │  │ • A/B testing │      │
  │  │ • PII detect  │  │ • Bias audit  │  │ • Guardrails  │      │
  │  │ • Consent mgmt│  │ • Explainab.  │  │ • Monitoring  │      │
  │  │ • Data quality│  │ • Version ctrl│  │ • Rollback    │      │
  │  │ • Retention   │  │ • Reproducib. │  │ • Access ctrl │      │
  │  └───────────────┘  └───────────────┘  └───────────────┘      │
  │                                                                 │
  │  ┌─────────────────────────────────────────────────────────┐   │
  │  │ 4. ORGANIZATIONAL GOVERNANCE                             │   │
  │  │ • AI Ethics Board  • Use case approval  • Risk register │   │
  │  │ • Training program • Incident response  • Audit trail   │   │
  │  └─────────────────────────────────────────────────────────┘   │
  └─────────────────────────────────────────────────────────────────┘

Guardrails pour LLMs

Python
# Guardrails basiques pour un LLM en production
from dataclasses import dataclass

@dataclass
class GuardrailConfig:
    max_tokens: int = 2000
    blocked_topics: list = None  # ["politique", "religion"]
    pii_detection: bool = True
    source_required: bool = True
    language: str = "fr"

def apply_guardrails(prompt: str, response: str, config: GuardrailConfig):
    """Verifier la reponse avant de la retourner a l'utilisateur."""
    issues = []

    # 1. PII Detection
    if config.pii_detection:
        pii_patterns = [r'\b\d{3}-\d{2}-\d{4}\b',  # SSN
                       r'\b[A-Z]{2}\d{2}[A-Z\d]{10,30}\b']  # IBAN
        for pattern in pii_patterns:
            if re.search(pattern, response):
                issues.append("PII detected in response")

    # 2. Blocked topics
    if config.blocked_topics:
        for topic in config.blocked_topics:
            if topic.lower() in response.lower():
                issues.append(f"Blocked topic: {topic}")

    # 3. Length check
    if len(response.split()) > config.max_tokens:
        issues.append("Response too long")

    # 4. Source citation check
    if config.source_required and "source" not in response.lower():
        issues.append("No source citation")

    return {"safe": len(issues) == 0, "issues": issues}

RGPD et IA : Points cles

Article 22 : Droit de ne pas etre soumis a une decision entierement automatisee (sauf exceptions).
Article 13-14 : Droit d'etre informe sur la logique du traitement automatise.
Article 17 : Droit a l'effacement ("droit a l'oubli") - comment effacer des donnees d'un modele entraine ?
En pratique : documentez la lineage data, implementez des model cards, et prevoyez des processus de retrait de donnees (unlearning ou retraining).

Comment un Data Architect peut-il contribuer a l'IA ethique ?
Le Data Architect contribue a l'IA ethique en : 1) Data lineage : tracer l'origine de chaque donnee utilisee pour l'entrainement (quand, d'ou, avec quel consentement). 2) Data quality pour le ML : detecter les biais dans les datasets d'entrainement (desequilibre de classes, sous-representation). 3) PII detection : s'assurer que les donnees personnelles sont anonymisees ou exclues. 4) Infrastructure de reproductibilite : DVC, MLflow pour pouvoir auditer chaque modele. 5) Governance framework : policies d'acces aux donnees ML, retention, consentement.

Lab : Construire un Pipeline RAG Complet

60 min Projet

Objectifs de cette lecon

  • Construire un pipeline RAG de bout en bout
  • Implementer l'ingestion, le chunking, l'embedding et le retrieval
  • Ajouter un reranker pour ameliorer la qualite
  • Evaluer le systeme avec des metriques automatiques

Ce lab est votre projet IA pour le portfolio. Un pipeline RAG complet qui interroge une base de documentation technique. C'est exactement ce que les entreprises cherchent : un architecte capable de designer et implementer l'infrastructure IA, pas juste de faire du prompt engineering dans ChatGPT.

Architecture du Lab

Lab RAG Pipeline - Architecture
  ┌────────────┐    ┌────────────┐    ┌────────────┐    ┌────────────┐
  │ Documents  │───→│ Chunking   │───→│ Embeddings │───→│ pgvector   │
  │ (Markdown) │    │ Recursive  │    │ OpenAI     │    │ PostgreSQL │
  │ 50+ docs   │    │ 1000 chars │    │ ada-002    │    │            │
  └────────────┘    └────────────┘    └────────────┘    └──────┬─────┘
                                                               │
  ┌────────────┐    ┌────────────┐    ┌────────────┐    ┌──────▼─────┐
  │ Reponse    │◄───│ LLM (GPT-4)│◄───│ Reranker   │◄───│ Retrieval  │
  │ + Sources  │    │ Generation │    │ (Cohere)   │    │ Top-K=10   │
  └────────────┘    └────────────┘    └────────────┘    └────────────┘

Structure du Projet

Bash
rag-pipeline-lab/
├── README.md
├── docker-compose.yml          # PostgreSQL + pgvector
├── requirements.txt
├── .env.example                # API keys (never commit .env!)
├── docs/                       # Documents sources
│   ├── architecture/
│   ├── runbooks/
│   └── adrs/
├── src/
│   ├── ingest.py              # Ingestion + chunking + embedding
│   ├── retriever.py           # Recherche vectorielle + reranking
│   ├── generator.py           # LLM generation avec prompt
│   ├── pipeline.py            # RAG chain complete
│   └── evaluate.py            # Evaluation automatique
├── prompts/
│   └── rag_assistant_v1.yaml  # Prompt versionne
├── eval/
│   ├── test_questions.json    # Dataset d'evaluation
│   └── results/
├── tests/
│   └── test_pipeline.py
└── Makefile

Code Complet du Pipeline

Python (pipeline.py)
"""Pipeline RAG complet avec reranking et evaluation."""
import os
from langchain_community.vectorstores import PGVector
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.document_loaders import DirectoryLoader, TextLoader
from langchain.chains import RetrievalQA
from langchain.prompts import PromptTemplate

class RAGPipeline:
    def __init__(self):
        self.embeddings = OpenAIEmbeddings(
            model="text-embedding-3-large"
        )
        self.llm = ChatOpenAI(
            model="gpt-4o",
            temperature=0.1,
            max_tokens=2000
        )
        self.connection_string = os.getenv("PGVECTOR_CONNECTION")

    def ingest(self, docs_path: str):
        """Ingerer les documents : charger, chunker, embedder, stocker."""
        # Charger
        loader = DirectoryLoader(docs_path, glob="**/*.md", loader_cls=TextLoader)
        documents = loader.load()
        print(f"Loaded {len(documents)} documents")

        # Chunker
        splitter = RecursiveCharacterTextSplitter(
            chunk_size=1000, chunk_overlap=200,
            separators=["\n## ", "\n### ", "\n\n", "\n", ". "]
        )
        chunks = splitter.split_documents(documents)
        print(f"Split into {len(chunks)} chunks")

        # Embedder et stocker
        self.vectorstore = PGVector.from_documents(
            documents=chunks,
            embedding=self.embeddings,
            connection_string=self.connection_string,
            collection_name="tech_docs",
            pre_delete_collection=True,
        )
        print("Ingestion complete!")
        return len(chunks)

    def query(self, question: str, k: int = 5) -> dict:
        """Interroger le pipeline RAG."""
        retriever = self.vectorstore.as_retriever(
            search_type="similarity",
            search_kwargs={"k": k}
        )
        prompt = PromptTemplate(
            template="""Contexte:\n{context}\n\nQuestion: {question}\n
Reponds en francais, cite tes sources.""",
            input_variables=["context", "question"]
        )
        chain = RetrievalQA.from_chain_type(
            llm=self.llm, retriever=retriever,
            chain_type_kwargs={"prompt": prompt},
            return_source_documents=True,
        )
        return chain.invoke({"query": question})

# Usage
if __name__ == "__main__":
    rag = RAGPipeline()
    rag.ingest("./docs")
    result = rag.query("Comment optimiser les couts Snowflake ?")
    print(result["result"])

Exercice Lab

1. Clonez le squelette du projet et configurez Docker (PostgreSQL + pgvector).
2. Ingerez 20-50 documents Markdown (vos notes de cours, des ADRs, de la documentation).
3. Implementez le pipeline RAG avec reranking.
4. Creez un dataset d'evaluation (20 questions + reponses attendues).
5. Mesurez Faithfulness et Answer Relevancy.
6. Documentez dans le README avec architecture C4 et resultats.

Quiz : Vector Databases & LLMs

20 min Intermediaire

Objectifs de cette lecon

  • Valider vos connaissances sur les vector databases et embeddings
  • Verifier votre comprehension du RAG et du LLM serving
  • Tester vos connaissances sur l'IA ethique

Question 1

Quel algorithme d'indexation vectorielle offre le meilleur rapport recall/vitesse ?
A) HNSW (Hierarchical Navigable Small World)
B) Flat (brute force)
C) PQ (Product Quantization)
D) LSH (Locality Sensitive Hashing)

Question 2

Quelle vector database est recommandee si vous avez deja PostgreSQL et < 10M vecteurs ?
A) Pinecone
B) pgvector
C) Milvus
D) Weaviate

Question 3

Dans un pipeline RAG, quelle est la taille de chunk recommandee pour du texte technique ?
A) 50-100 tokens
B) 500-1000 tokens
C) 5000-10000 tokens
D) Le document entier

Question 4

Quelle technique reduit les couts LLM de 30-60% en evitant les appels redondants ?
A) Semantic caching
B) Quantization
C) Batching
D) Distillation

Question 5

Quel article du RGPD concerne le droit de ne pas etre soumis a une decision entierement automatisee ?
A) Article 17 (droit a l'effacement)
B) Article 22
C) Article 5 (principes de traitement)
D) Article 35 (analyse d'impact)

Si vous avez 4/5 ou plus, vous maitrisez les technologies IA les plus demandees en 2026. La suite va vous plonger dans les Knowledge Graphs - la prochaine frontiere pour enrichir le contexte de l'IA avec des relations semantiques structurees.

Knowledge Graphs : RDF & SPARQL

50 min Avance

Objectifs de cette lecon

  • Comprendre les Knowledge Graphs et leur role dans l'architecture data
  • Maitriser le modele RDF (Resource Description Framework)
  • Ecrire des requetes SPARQL basiques et avancees
  • Identifier les cas d'usage enterprise des Knowledge Graphs

Les Knowledge Graphs sont la couche semantique ultime. Ils representent les donnees sous forme de relations (sujet-predicat-objet), ce qui permet de decouvrir des connexions invisibles dans une base relationnelle. Google Knowledge Graph, Wikidata, les graphes pharmaceutiques - c'est une technologie mature qui connait un renouveau grace a l'IA. Un KG enrichit le contexte du RAG et ameliore considerablement la qualite des reponses LLM.

Qu'est-ce qu'un Knowledge Graph ?

Knowledge Graph - Structure de base
  ┌──────────┐     employe_de     ┌──────────┐     localise_a    ┌──────────┐
  │  Alice   │───────────────────→│ DataCorp │───────────────────→│  Paris   │
  │ (Person) │                    │ (Company)│                    │  (City)  │
  └──────┬───┘                    └──────┬───┘                    └──────────┘
         │                               │
         │ competence                    │ utilise
         ▼                               ▼
  ┌──────────┐                    ┌──────────┐
  │ Snowflake│                    │ Snowflake│
  │ (Tech)   │◄───────────────────│ (Tech)   │
  └──────────┘    est_un          └──────────┘
         │
         │ categorie
         ▼
  ┌──────────┐
  │ Cloud DWH│
  │ (Category│
  └──────────┘

  Triplet RDF : (Sujet, Predicat, Objet)
  Ex: (Alice, employe_de, DataCorp)
  Ex: (Alice, competence, Snowflake)
  Ex: (DataCorp, localise_a, Paris)

RDF - Resource Description Framework

Turtle (RDF)
@prefix ex: <http://example.org/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix schema: <http://schema.org/> .

# Personnes
ex:alice a foaf:Person ;
    foaf:name "Alice Martin" ;
    ex:role "Data Architect" ;
    ex:competence ex:snowflake, ex:dbt, ex:kafka ;
    ex:employe_de ex:datacorp ;
    ex:certifie ex:cdmp, ex:snowpro .

ex:bob a foaf:Person ;
    foaf:name "Bob Dupont" ;
    ex:role "Data Engineer" ;
    ex:competence ex:python, ex:airflow, ex:spark ;
    ex:employe_de ex:datacorp .

# Entreprise
ex:datacorp a schema:Organization ;
    schema:name "DataCorp" ;
    schema:location ex:paris ;
    ex:utilise ex:snowflake, ex:dbt, ex:airflow ;
    ex:industrie "E-commerce" .

# Technologies
ex:snowflake a ex:Technology ;
    ex:categorie "Cloud Data Warehouse" ;
    ex:vendor "Snowflake Inc." .

ex:dbt a ex:Technology ;
    ex:categorie "Transformation" ;
    ex:licence "Open Source" .

SPARQL - Requetes

SPARQL
# Requete 1 : Trouver toutes les competences d'Alice
SELECT ?competence WHERE {
    ex:alice ex:competence ?competence .
}

# Requete 2 : Trouver les personnes qui maitrisent Snowflake
SELECT ?personne ?nom WHERE {
    ?personne ex:competence ex:snowflake ;
              foaf:name ?nom .
}

# Requete 3 : Trouver les technologies open source utilisees par DataCorp
SELECT ?tech ?categorie WHERE {
    ex:datacorp ex:utilise ?tech .
    ?tech ex:licence "Open Source" ;
          ex:categorie ?categorie .
}

# Requete 4 : Recommandation - qui peut aider sur Kafka ?
SELECT ?personne ?nom ?role WHERE {
    ?personne ex:competence ex:kafka ;
              foaf:name ?nom ;
              ex:role ?role .
}

# Requete 5 : Chemin entre Alice et une technologie (graph traversal)
SELECT ?tech ?categorie WHERE {
    ex:alice ex:employe_de ?company .
    ?company ex:utilise ?tech .
    ?tech ex:categorie ?categorie .
    FILTER NOT EXISTS { ex:alice ex:competence ?tech }
}
# → Technologies utilisees par l'entreprise qu'Alice ne maitrise pas encore

Cas d'Usage Enterprise

Cas d'usageDescriptionValeur business
Data Catalog semantiqueRelier datasets, owners, lineage, business termsDecouverte de donnees 5x plus rapide
Recommandation produitGraphe produits-categories-clients-achats+15% conversion cross-sell
Fraud detectionReseau de transactions, comptes, adressesDetection de patterns complexes
Drug discoveryMolecules, proteines, maladies, interactionsReduction temps de recherche
RAG enrichiContexte structure pour les LLMsReponses plus precises et completes
Quelle est la difference fondamentale entre une base relationnelle et un Knowledge Graph ?
Une base relationnelle stocke les donnees dans des tables avec un schema fixe (colonnes predefinies). Les relations sont implicites (JOIN sur foreign keys). Modifier le schema est couteux. Un Knowledge Graph stocke des triplets (sujet, predicat, objet) sans schema fixe. Les relations sont explicites et typees (premiere classe). Ajouter un nouveau type de relation ne necessite aucune migration. C'est ideal pour les donnees heterogenes, les relations complexes (N niveaux de profondeur) et les cas ou le schema evolue frequemment.

Neo4j : Property Graphs en Pratique

50 min Avance

Objectifs de cette lecon

  • Comprendre le modele Property Graph vs RDF
  • Ecrire des requetes Cypher pour Neo4j
  • Modeliser un data catalog comme graphe
  • Integrer Neo4j avec un pipeline data existant

Neo4j est la base de donnees graphe la plus populaire au monde. Son langage Cypher est bien plus intuitif que SPARQL pour la plupart des developpeurs. En tant que Data Architect, Neo4j est votre outil pour modeliser les lineages data, les impacts analysis, les data catalogs semantiques et les reseaux de relations complexes que les bases relationnelles gerent mal.

Property Graph vs RDF

AspectProperty Graph (Neo4j)RDF (SPARQL)
ModeleNoeuds + Relations (avec proprietes)Triplets (sujet, predicat, objet)
LangageCypher (intuitif)SPARQL (verbeux)
SchemaFlexible, optionalOntologies (OWL, RDFS)
ProprietesSur noeuds ET relationsUniquement sur sujets
StandardsProprietaire (mais GQL arrive)W3C standard
PerformanceExcellent pour traversalsBon, optimise pour jointures
Cas idealApplications, recommandations, fraudDonnees ouvertes, linked data, semantique

Cypher - Le SQL des Graphes

Cypher (Neo4j)
// Creer des noeuds et relations
CREATE (alice:Person {name: "Alice", role: "Data Architect", salary: 95000})
CREATE (bob:Person {name: "Bob", role: "Data Engineer", salary: 75000})
CREATE (sf:Technology {name: "Snowflake", category: "Cloud DWH"})
CREATE (dbt:Technology {name: "dbt", category: "Transformation", license: "OSS"})
CREATE (dc:Company {name: "DataCorp", industry: "E-commerce"})

CREATE (alice)-[:WORKS_AT {since: 2024}]->(dc)
CREATE (bob)-[:WORKS_AT {since: 2025}]->(dc)
CREATE (alice)-[:SKILLED_IN {level: "expert"}]->(sf)
CREATE (alice)-[:SKILLED_IN {level: "expert"}]->(dbt)
CREATE (bob)-[:SKILLED_IN {level: "intermediate"}]->(sf)
CREATE (dc)-[:USES]->(sf)
CREATE (dc)-[:USES]->(dbt)
CREATE (alice)-[:MENTORS]->(bob);

// Requete 1 : Trouver les experts Snowflake
MATCH (p:Person)-[s:SKILLED_IN]->(t:Technology {name: "Snowflake"})
WHERE s.level = "expert"
RETURN p.name, p.role;

// Requete 2 : Technologies non maitrisees par Bob mais utilisees par son entreprise
MATCH (bob:Person {name: "Bob"})-[:WORKS_AT]->(c:Company)-[:USES]->(t:Technology)
WHERE NOT (bob)-[:SKILLED_IN]->(t)
RETURN t.name AS tech_to_learn, t.category;

// Requete 3 : Chemin le plus court entre deux personnes
MATCH path = shortestPath(
    (alice:Person {name: "Alice"})-[*]-(bob:Person {name: "Bob"})
)
RETURN path;

// Requete 4 : Recommandation - personnes avec competences similaires
MATCH (alice:Person {name: "Alice"})-[:SKILLED_IN]->(tech)<-[:SKILLED_IN]-(similar)
WHERE alice <> similar
RETURN similar.name, COUNT(tech) AS common_skills
ORDER BY common_skills DESC;

Data Catalog comme Graphe

Data Catalog Knowledge Graph
  ┌──────────┐     contient     ┌──────────┐     source_de    ┌──────────┐
  │ Database │────────────────→│  Table   │────────────────→│  Column  │
  │ Snowflake│                  │ orders   │                  │ order_id │
  └──────────┘                  └────┬─────┘                  └──────────┘
                                     │
                               owner │        lineage
                                     ▼             │
                              ┌──────────┐         │        ┌──────────┐
                              │  Team    │         └───────→│ dbt Model│
                              │  Sales   │                  │ fct_orders│
                              └──────────┘                  └──────────┘
                                                                  │
                                                            consomme_par
                                                                  ▼
                                                           ┌──────────┐
                                                           │Dashboard │
                                                           │ Revenue  │
                                                           └──────────┘
Cypher
// Modeliser un Data Catalog dans Neo4j
CREATE (db:Database {name: "analytics_dwh", type: "Snowflake"})
CREATE (t1:Table {name: "raw_orders", schema: "bronze", row_count: 5000000})
CREATE (t2:Table {name: "stg_orders", schema: "silver"})
CREATE (t3:Table {name: "fct_orders", schema: "gold"})
CREATE (d1:Dashboard {name: "Revenue Dashboard", tool: "Metabase"})
CREATE (team:Team {name: "Sales Analytics"})

CREATE (db)-[:CONTAINS]->(t1)
CREATE (db)-[:CONTAINS]->(t2)
CREATE (db)-[:CONTAINS]->(t3)
CREATE (t1)-[:FEEDS]->(t2)
CREATE (t2)-[:FEEDS]->(t3)
CREATE (t3)-[:CONSUMED_BY]->(d1)
CREATE (t3)-[:OWNED_BY]->(team)

// Impact Analysis : si raw_orders change, qui est impacte ?
MATCH (source:Table {name: "raw_orders"})-[:FEEDS*]->(downstream)
RETURN downstream.name, labels(downstream)[0] AS type;
Quel est le principal avantage de Cypher par rapport a SQL pour les requetes de graphe ?
Cypher represente les patterns de graphe visuellement dans la syntaxe : (alice)-[:WORKS_AT]->(company) se lit comme le dessin du graphe. En SQL, la meme requete necessite des JOINs multiples qui masquent la structure relationnelle. Pour des traversals de profondeur N (ex: "tous les impacts downstream sur 5 niveaux"), Cypher utilise -[:FEEDS*1..5]-> alors que SQL necessite des CTE recursifs complexes. La performance est aussi superieure : Neo4j utilise du index-free adjacency (chaque noeud pointe directement vers ses voisins), donc la traversal est O(1) par relation, pas O(log n) comme un JOIN indexe.

Ontologies & Enterprise Knowledge Graphs

45 min Avance

Objectifs de cette lecon

  • Comprendre les ontologies et les taxonomies
  • Designer un Enterprise Knowledge Graph
  • Integrer un KG avec un pipeline RAG pour enrichir le contexte
  • Connaitre les outils : Protege, TopBraid, Stardog

Une ontologie, c'est le "schema" d'un Knowledge Graph. Elle definit les types d'entites, les relations possibles, et les contraintes. Dans une entreprise, l'ontologie capture le vocabulaire metier : qu'est-ce qu'un "client" ? Qu'est-ce qu'une "commande" ? Comment sont-ils relies ? C'est le Business Glossary ultime, mais en version executable et requetable.

Taxonomie vs Ontologie

ConceptDescriptionExempleComplexite
VocabulaireListe de termes"Client", "Commande", "Produit"Simple
TaxonomieHierarchie de categoriesProduit → Electronique → SmartphoneMoyenne
ThesaurusTaxonomie + synonymes + relations"Client" = "Customer" = "Acheteur"Moyenne
OntologieModele complet avec types, relations, contraintes"Un Client passe des Commandes qui contiennent des Produits"Elevee

KG + RAG : Le Combo Puissant

GraphRAG - Knowledge Graph enrichit le RAG
  Question utilisateur
  "Quels dashboards seront impactes si je modifie la table orders ?"
         │
         ▼
  ┌──────────────┐      ┌──────────────┐      ┌──────────────┐
  │ 1. Vector    │      │ 2. Knowledge │      │ 3. LLM       │
  │    Search    │      │    Graph     │      │    Generate  │
  │              │      │    Traversal │      │              │
  │ Docs sur     │      │              │      │ Combine:     │
  │ "orders" et  │─────→│ orders →     │─────→│ docs + graph │
  │ "impact"     │      │ stg_orders → │      │ context      │
  │              │      │ fct_orders → │      │              │
  │ (semantique) │      │ Dashboard X  │      │ → Reponse    │
  └──────────────┘      │ Dashboard Y  │      │   structuree │
                        │ (structurel) │      └──────────────┘
                        └──────────────┘

GraphRAG : le meilleur des deux mondes

Le RAG classique recupere des chunks de texte par similarite semantique - ideal pour des questions ouvertes. Le Knowledge Graph repond a des questions structurelles - ideal pour le lineage, l'impact analysis, les relations. GraphRAG combine les deux : la recherche vectorielle pour le contexte textuel, et le graph traversal pour les relations structurees. Resultat : des reponses plus precises et plus completes, avec des preuves structurelles en plus du contexte textuel.

Outils pour Knowledge Graphs

OutilTypeUsagePrix
Neo4jProperty Graph DBApplications, data catalog, recommandationsCommunity (gratuit) / Enterprise
StardogEnterprise KGData fabric, virtual graph, ontologies$$$
Amazon NeptuneManaged Graph DBRDF + Property Graph, AWS integre$$
ProtegeOntology EditorCreer et editer des ontologies OWLGratuit (Stanford)
DataHubData CatalogMetadata graph, lineage, governanceOpen source
Apache JenaRDF FrameworkStocker et requeter du RDF (Java)Open source
Comment un Knowledge Graph ameliore-t-il un pipeline RAG ?
Un KG ameliore le RAG de 3 facons : 1) Contexte structure : au lieu de chercher uniquement par similarite textuelle, le KG fournit des faits structures (lineage, hierarchies, relations) qui enrichissent le prompt du LLM. 2) Desambiguation : quand "order" peut etre une commande client ou un ordre de bourse, le KG utilise le contexte relationnel pour choisir le bon sens. 3) Reponses multi-hop : le RAG classique cherche des documents, mais ne peut pas repondre a "quels dashboards sont impactes si je modifie la table X ?" Le KG traverse le lineage pour trouver la reponse structurellement.

Semantic Layer Avance & Data Catalogs

45 min Avance

Objectifs de cette lecon

  • Comprendre la semantic layer comme pont entre data et IA
  • Designer un business glossary executable
  • Integrer Knowledge Graphs avec les Data Catalogs modernes
  • Configurer la linked data et la data federation

La semantic layer est le Saint Graal du Data Architect : une couche unique qui traduit le modele physique des donnees en concepts business comprehensibles par tous - humains ET machines (IA). Quand un analyste demande "le revenue Q4" et qu'un LLM demande la meme chose, ils obtiennent tous les deux la meme reponse, calculee de la meme facon. C'est la coherence semantique a l'echelle.

Semantic Layer + Knowledge Graph + IA

Architecture Semantique Moderne
  Consumers                 Semantic Layer              Physical Data
  ═════════                 ══════════════              ═════════════

  ┌──────────┐           ┌──────────────────┐         ┌──────────────┐
  │ Analysts │──────────→│                  │────────→│ Snowflake    │
  │ (Looker) │           │  SEMANTIC LAYER  │         │ (facts, dims)│
  └──────────┘           │                  │         └──────────────┘
  ┌──────────┐           │ • Business terms │         ┌──────────────┐
  │ LLM /    │──────────→│ • Metrics defs   │────────→│ BigQuery     │
  │ Chatbot  │           │ • Relationships  │         │ (logs, events│
  └──────────┘           │ • Access control │         └──────────────┘
  ┌──────────┐           │ • Cache layer    │         ┌──────────────┐
  │ Data     │──────────→│                  │────────→│ PostgreSQL   │
  │ Scientists│          │  dbt Metrics /   │         │ (operational)│
  └──────────┘           │  Cube / Looker   │         └──────────────┘
                         └────────┬─────────┘
                                  │
                         ┌────────▼─────────┐
                         │ KNOWLEDGE GRAPH  │
                         │ (Business terms, │
                         │  lineage, owners)│
                         └──────────────────┘

Data Catalogs Modernes

CatalogueTypeForcesKG integrePrix
DataHubOpen source (LinkedIn)Lineage auto, extensible, GraphQL APIOui (graph natif)Gratuit
OpenMetadataOpen sourceSimple, APIs REST, bonne UIPartielGratuit
AtlanSaaSUI excellente, collaboration, AI featuresOui$$$
AlationSaaS/on-premEnterprise, ML catalog, governanceOui$$$
Unity CatalogDatabricksIntegre Databricks, Delta SharingNon$$

Business Glossary comme Code

YAML
# glossary/business_terms.yaml
terms:
  revenue:
    display_name: "Revenue"
    description: "Total des ventes nettes (hors taxes, hors retours)"
    formula: "SUM(order_total) - SUM(returns) - SUM(taxes)"
    source_table: "gold.fct_orders"
    owner: "finance-team@company.com"
    synonyms: ["chiffre d'affaires", "CA", "sales revenue"]
    related_terms: ["gross_revenue", "net_revenue", "arr"]
    data_type: "decimal"
    unit: "EUR"
    refresh: "daily, 6:00 UTC"
    sla: "available by 7:00 UTC"

  active_customer:
    display_name: "Client actif"
    description: "Client ayant effectue au moins 1 achat dans les 90 derniers jours"
    formula: "customer WHERE last_order_date >= CURRENT_DATE - 90"
    source_table: "gold.dim_customers"
    owner: "marketing-team@company.com"
    synonyms: ["client engage", "utilisateur actif"]
    related_terms: ["churned_customer", "new_customer"]

  churn_rate:
    display_name: "Taux de churn"
    description: "Pourcentage de clients perdus sur une periode"
    formula: "(clients_debut - clients_fin) / clients_debut * 100"
    source_table: "gold.fct_customer_metrics"
    owner: "product-team@company.com"
    granularity: "monthly"

Linked Data : Connecter les Silos

La data federation via Knowledge Graph permet de requeter des donnees de sources differentes comme si c'etait une seule base. Exemple : Neo4j contient le graphe des relations (equipes, projets, technologies), Snowflake contient les metriques (revenue, usage), et le Data Catalog contient les metadata (lineage, qualite). Un KG federe ces 3 sources avec des virtual graph (Stardog) ou des GraphQL federation (DataHub).

Pourquoi un Business Glossary est-il essentiel pour l'IA en entreprise ?
Sans Business Glossary, un LLM ne sait pas que "revenue" signifie SUM(order_total) - SUM(returns) - SUM(taxes) et pas SUM(order_total). Chaque equipe a sa propre definition, et le modele hallucine un calcul incorrect. Un Business Glossary executable (dans la semantic layer) garantit que toutes les definitions sont uniques, documentees et calculees de la meme facon - que ce soit un humain via Looker ou un LLM via Text-to-SQL. C'est le fondement de la coherence semantique necessaire pour l'IA fiable en entreprise.

Projet : AI-Powered Data Platform

60 min Projet

Objectifs de cette lecon

  • Designer l'architecture complete d'une data platform AI-augmented
  • Integrer Feature Store, Vector DB, RAG et Knowledge Graph
  • Produire les deliverables pour le portfolio
  • Planifier l'implementation sur 8 semaines

Ce projet combine tout ce que vous avez appris dans les Phases 1 a 7. C'est votre projet capstone : une data platform complete augmentee par l'IA. Feature Store pour le ML, RAG pour l'assistant interne, Knowledge Graph pour le data catalog. C'est exactement ce que construisent les entreprises leaders en 2026.

Architecture Cible

AI-Powered Data Platform - Architecture Complete
  Sources          Ingestion        Lake/DWH          ML Layer           AI Layer
  ═══════          ═════════        ════════          ════════           ════════

  ┌─────────┐    ┌──────────┐    ┌──────────┐    ┌──────────────┐   ┌──────────┐
  │ APIs    │───→│ Airbyte  │───→│ Snowflake│───→│ Feature Store│──→│ ML Models│
  │ DBs     │    │          │    │ (Iceberg)│    │ (Feast)      │   │ (MLflow) │
  │ Events  │    └──────────┘    │          │    └──────────────┘   └──────────┘
  └─────────┘                    │ Bronze → │
                                 │ Silver → │    ┌──────────────┐   ┌──────────┐
  ┌─────────┐    ┌──────────┐    │ Gold     │───→│ Vector DB    │──→│ RAG      │
  │ Docs    │───→│ Loader   │───→│          │    │ (pgvector)   │   │ Assistant│
  │ Wiki    │    │ Chunker  │    └──────────┘    └──────────────┘   └──────────┘
  │ ADRs    │    └──────────┘
  └─────────┘                    ┌──────────┐    ┌──────────────┐   ┌──────────┐
                                 │ dbt      │───→│ Knowledge    │──→│ Data     │
                                 │ Transform│    │ Graph (Neo4j)│   │ Catalog  │
                                 └──────────┘    │ Lineage,     │   │ Search   │
                                                 │ Business     │   └──────────┘
                                 ┌──────────┐    │ Terms        │
                                 │ Dagster  │    └──────────────┘   ┌──────────┐
                                 │ Orchestr │                       │ LLM      │
                                 └──────────┘                       │ Gateway  │
                                                                    └──────────┘

Composants du Projet

ComposantTechnologieRoleSemaine
Data PlatformSnowflake + dbt + DagsterFoundation (Bronze/Silver/Gold)1-3
Feature StoreFeast + RedisFeatures pour ML (churn, reco)4
ML PipelineMLflow + scikit-learnModel training, registry, serving5
Vector StorepgvectorEmbeddings pour RAG6
RAG AssistantLangChain + GPT-4oAssistant documentation interne6-7
Knowledge GraphNeo4jData catalog, lineage, glossary7
DocumentationC4 + ADRs + READMEPortfolio-ready documentation8

Deliverables Portfolio

Checklist du projet

1. GitHub repo avec README professionnel, docker-compose, Makefile
2. Architecture C4 Level 1 (context) + Level 2 (containers)
3. ADRs : choix Feast vs Tecton, choix pgvector vs Pinecone, choix Neo4j vs RDF
4. dbt project : 10+ models (staging, intermediate, marts) avec tests
5. Feature Store : 5+ features entities avec materialization
6. ML model : 1 model (churn prediction) avec MLflow tracking
7. RAG pipeline : ingestion 20+ docs, recherche vectorielle, evaluation
8. Knowledge Graph : data catalog avec lineage, 50+ noeuds
9. Blog article : "Building an AI-Powered Data Platform"
10. Demo video (optionnel) : 5 min walkthrough

Quel est le plus grand defi d'une AI Data Platform ?
Le plus grand defi est l'integration entre les composants. Chaque outil (Snowflake, Feast, pgvector, Neo4j, MLflow) est excellent individuellement, mais les faire fonctionner ensemble necessite une orchestration soignee (Dagster/Airflow), des interfaces claires (APIs, data contracts), et une gouvernance transversale (lineage de bout en bout, de la source jusqu'a la prediction ML). C'est exactement le role du Data Architect : designer l'integration, pas juste choisir les outils.

Examen Final : IA & Data Architecture

30 min Avance

Objectifs de cette lecon

  • Valider vos connaissances sur les 2 modules de la Phase 7
  • AI/ML Infrastructure et Knowledge Graphs
  • 12 questions couvrant l'ensemble du programme

Dernier examen avant la Phase 8 : Chief Data Architect. Si vous reussissez, vous maitrisez non seulement l'architecture data classique (Phases 1-6) mais aussi l'infrastructure IA moderne. Vous etes pret pour le niveau ultime.

Partie 1 : Feature Stores & MLOps (4 questions)

Q1. Quel est le role principal d'un Feature Store ?
A) Stocker les modeles ML entraines
B) Centraliser les features ML avec coherence train/serve et point-in-time correctness
C) Remplacer le Data Warehouse pour l'analytique
D) Gerer les hyperparametres des modeles
Q2. Quel outil open source est le standard pour le Feature Store ?
A) Feast
B) MLflow
C) DVC
D) Evidently
Q3. Qu'est-ce que le data drift ?
A) Un modele qui prend trop de temps a entrainer
B) Le changement dans la distribution statistique des donnees d'entree au fil du temps
C) La perte de donnees pendant le transfert
D) Un bug dans le code de preprocessing
Q4. Dans MLflow, quel stage indique qu'un modele est deploye pour les predictions reelles ?
A) Staging
B) Production
C) Archived
D) None

Partie 2 : Vector DBs, RAG & LLMs (4 questions)

Q5. Quel algorithme d'indexation vectorielle est le plus utilise en 2026 ?
A) HNSW
B) LSH
C) k-d tree
D) Flat (brute force)
Q6. Dans un pipeline RAG, quel est le role du chunking ?
A) Compresser les donnees pour economiser du stockage
B) Decouper les documents en morceaux adaptees a l'embedding et au retrieval
C) Chiffrer les documents pour la securite
D) Fusionner les documents similaires
Q7. Quelle technique reduit les couts LLM de 30-60% ?
A) Augmenter la temperature
B) Semantic caching via vector database
C) Utiliser toujours GPT-4
D) Doubler le max_tokens
Q8. Quand preferer le RAG au fine-tuning d'un LLM ?
A) Quand les donnees changent frequemment et qu'on veut citer les sources
B) Quand on a besoin d'un style de reponse tres specifique
C) Quand on veut reduire la latence a < 100ms
D) Quand on n'a pas de donnees proprietaires

Partie 3 : Knowledge Graphs & Semantic (4 questions)

Q9. Quel langage de requete est utilise pour interroger Neo4j ?
A) SPARQL
B) Cypher
C) Gremlin
D) GraphQL
Q10. Qu'est-ce qu'un triplet RDF ?
A) (Sujet, Predicat, Objet) - ex: (Alice, employe_de, DataCorp)
B) (Table, Colonne, Valeur) - un modele relationnel
C) (Input, Model, Output) - un pipeline ML
D) (Question, Context, Answer) - un template RAG
Q11. Comment un Knowledge Graph ameliore-t-il le RAG ?
A) En accelerant les embeddings
B) En remplacant le LLM
C) En fournissant du contexte structure (lineage, relations) en plus du contexte textuel
D) En compressant les documents
Q12. Quel est le plus grand defi d'une AI Data Platform ?
A) Choisir le bon LLM
B) Avoir assez de GPU
C) L'integration entre les composants (orchestration, interfaces, gouvernance transversale)
D) Le cout du stockage cloud

Felicitations ! Vous avez termine la Phase 7 : IA & Data Architecture. Vous maitrisez maintenant les technologies qui redefinissent le role du Data Architect en 2026 : Feature Stores, MLOps, Vector Databases, RAG, LLM Infrastructure, Knowledge Graphs et Semantic Layer. Dans la Phase 8, la derniere, vous deviendrez Chief Data Architect : strategie enterprise, organisation des equipes, culture data-driven et tendances futures.

Prochaine etape : Phase 8 - Chief Data Architect

La Phase 8 couvrira : Data Strategy Enterprise (vision, roadmap pluriannuelle), Organization Design (CoE, Data Guild, career ladders), Budget & Business Case (TCO, ROI, COMEX), Data-Driven Culture (data literacy, self-service), et Tendances (composable data, sovereign cloud, green data). Le niveau ultime pour piloter la strategie data d'une organisation.