Introduction : IA & Data Architecture
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
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
| Pilier | Composants | Role du Data Architect |
|---|---|---|
| Feature Stores | Feast, Tecton, Hopsworks | Designer les pipelines de features, online/offline stores |
| MLOps | MLflow, Kubeflow, Vertex AI | Architecture du lifecycle ML : training → serving → monitoring |
| Vector Databases | Pinecone, Weaviate, pgvector | Choisir le bon store pour les embeddings, indexation ANN |
| LLM Infrastructure | vLLM, TGI, prompt management | Serving scalable, RAG pipelines, cost optimization |
| Knowledge Graphs | Neo4j, RDF/SPARQL, ontologies | Modeliser les relations, enrichir le contexte pour l'IA |
Maturite IA : Ou en est votre Organisation ?
| Niveau | Description | Infrastructure | % entreprises |
|---|---|---|---|
| 1 - Ad hoc | Quelques notebooks Jupyter | Aucune, local | 40% |
| 2 - Experimentaton | POCs ML, pas en production | Cloud basique, pas de MLOps | 30% |
| 3 - Production | 1-5 modeles en prod | MLflow, feature store basique | 20% |
| 4 - Scale | 10+ modeles, real-time serving | Full MLOps, monitoring, A/B testing | 8% |
| 5 - AI-Native | AI integre dans chaque produit | Platform team ML, LLMOps, KG | 2% |
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
Feature Stores : Concepts & Architecture
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
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
| Aspect | Offline Store | Online Store |
|---|---|---|
| Usage | Training, batch scoring | Real-time inference |
| Latence | Secondes a minutes | < 10 ms |
| Volume | Historique complet (mois/annees) | Dernieres valeurs uniquement |
| Format | Parquet, BigQuery, Snowflake | Redis, DynamoDB, Bigtable |
| Acces | SQL, Spark, pandas | API REST/gRPC (key-value) |
| Cout | Faible (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.
# 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
| Solution | Type | Offline Store | Online Store | Prix | Ideal pour |
|---|---|---|---|---|---|
| Feast | Open source | File, BigQuery, Snowflake, Redshift | Redis, DynamoDB, SQLite | Gratuit | Startups, PME, self-hosted |
| Tecton | Managed | S3, Snowflake, Databricks | DynamoDB (managed) | $$$ | Enterprise, real-time ML |
| Hopsworks | Open/Managed | Hudi/Hive | RonDB (MySQL NDB) | $ - $$$ | On-prem, feature pipelines |
| Vertex AI FS | Managed (GCP) | BigQuery | Bigtable | $$ | Equipes full GCP |
| Databricks FS | Managed | Delta Lake | Cosmos DB | $$ | Equipes Databricks |
Feast : Feature Store Open Source
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
# 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)
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
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
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
| Aspect | Recommandation |
|---|---|
| CI/CD | feast apply dans GitHub Actions a chaque merge |
| Materialisation | Cron job (Airflow/Dagster) toutes les heures ou daily |
| Monitoring | Alertes sur freshness, null rates, distribution drift |
| Versioning | Git pour les definitions, registre Feast pour les metadata |
| Testing | Unit tests sur les transformations, integration tests sur le serving |
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
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
| Categorie | Exemples | Calcul | Latence |
|---|---|---|---|
| Statiques | Age, pays, categorie produit | Lookup direct | Immediate |
| Aggregees (window) | Achats 30j, panier moyen 7j | SQL window / Spark | Batch (heures) |
| Temporelles | Jours depuis dernier achat, heure du jour | Calcul temps reel | Temps reel |
| Interactions | Ratio prix/moyenne categorie | Cross-entity join | Batch |
| Textuelles | TF-IDF, embeddings texte | NLP pipeline | Batch/Stream |
| Streaming | Clics derniere minute, session active | Flink / Kafka Streams | Temps reel |
Patterns SQL pour Feature Engineering
-- 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.
MLOps : Data Pipelines pour le ML
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
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 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
# 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 Retraining | Detection | Action |
|---|---|---|
| Data drift | Distribution des features change (> seuil KS test) | Retraining automatique |
| Concept drift | Performance du modele degrade (accuracy, F1) | Retraining + evaluation |
| Schedule | Cron (hebdomadaire, mensuel) | Retraining periodique |
| Nouveau label | Volume de nouveaux labels suffisant | Retraining incremental |
| Evenement business | Lancement produit, saison, reglementation | Retraining 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.
Model Registry : MLflow & Weights & Biases
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 │ │ │ │ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ │ │ 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
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
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
| Solution | Type | Forces | Faiblesses | Prix |
|---|---|---|---|---|
| MLflow | Open source | Standard, flexible, multi-framework | UI basique, pas de collaboration native | Gratuit |
| W&B (Weights & Biases) | SaaS/self-hosted | UI excellente, collaboration, sweeps | Payant pour teams, vendor lock-in | $ - $$$ |
| Vertex AI Model Registry | Managed (GCP) | Integre GCP, auto-deployment | GCP only | $$ |
| SageMaker Model Registry | Managed (AWS) | Integre AWS, pipelines natifs | AWS only | $$ |
A/B Testing Infrastructure & Model Monitoring
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
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 Monitoring | Metriques | Outils | Seuil d'alerte |
|---|---|---|---|
| Data Drift | KS test, PSI, chi-square | Evidently, Whylogs, NannyML | PSI > 0.2 |
| Concept Drift | Accuracy, F1, AUC degradation | MLflow + custom dashboards | Drop > 5% vs baseline |
| Prediction Drift | Distribution des predictions | Evidently, custom | Distribution shift significatif |
| Latence | p50, p95, p99 latency | Prometheus + Grafana | p99 > 100ms |
| Infrastructure | CPU, RAM, GPU utilization | Prometheus, CloudWatch | GPU > 80% sustained |
# 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
Quiz : AI/ML Data Infrastructure
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
Question 2
Question 3
Question 4
Question 5
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
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 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
| Metrique | Formule | Plage | Usage ideal |
|---|---|---|---|
| Cosine Similarity | cos(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 Product | A·B = sum(ai×bi) | [-inf, +inf] | Recommendations (quand magnitude compte) |
Algorithmes d'Indexation ANN
| Algorithme | Principe | Recall | Vitesse | Memoire |
|---|---|---|---|---|
| HNSW | Graphe hierarchique navigable | Tres eleve (99%+) | Rapide | Elevee (en RAM) |
| IVF | Partitionnement en clusters (Voronoi) | Bon (~95%) | Rapide | Moderee |
| PQ (Product Quantization) | Compression des vecteurs | Moyen (~90%) | Tres rapide | Faible |
| IVF-PQ | Combinaison IVF + PQ | Bon | Rapide | Faible |
| Flat (brute force) | Recherche exhaustive | 100% | 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'usage | Input | Embedding | Resultat |
|---|---|---|---|
| RAG (chatbot) | Question utilisateur | Texte → vecteur | Documents pertinents comme contexte LLM |
| Recherche semantique | Requete en langage naturel | Texte → vecteur | Documents, articles, FAQ similaires |
| Recommandations | Produit consulte | Item → vecteur | Produits similaires |
| Detection d'anomalies | Transaction | Features → vecteur | Transactions les plus differentes |
| Deduplication | Nouveau record | Record → vecteur | Records quasi-identiques |
Pinecone, Weaviate, Milvus & pgvector
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
| Solution | Type | Indexation | Max vecteurs | Hybrid Search | Prix | Ideal pour |
|---|---|---|---|---|---|---|
| pgvector | Extension PostgreSQL | IVFFlat, HNSW | ~10M | Oui (avec pg_trgm) | Gratuit | PME, deja sur PostgreSQL |
| Pinecone | SaaS manage | Proprietaire | Illimite | Oui (sparse+dense) | $$$ | Enterprise, zero-ops |
| Weaviate | Open source/Cloud | HNSW | 100M+ | Oui (BM25 + vector) | Gratuit / $$ | Recherche semantique avancee |
| Milvus | Open source | IVF, HNSW, DiskANN | 1B+ | Oui | Gratuit | Scale massive, on-prem |
| Qdrant | Open source/Cloud | HNSW | 100M+ | Oui (filtrage) | Gratuit / $$ | Filtrage avance, Rust perf |
| ChromaDB | Open source | HNSW | ~1M | Basique | Gratuit | Prototypage, dev local |
pgvector - Implementation
-- 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
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.
vector <=> et pg_trgm.RAG : Retrieval-Augmented Generation
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
═══ 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
| Strategie | Description | Taille typique | Quand l'utiliser |
|---|---|---|---|
| Fixed size | Decouper tous les N tokens | 500-1000 tokens | Contenu homogene (logs, code) |
| Recursive | Decouper par separateurs hierarchiques (\n\n → \n → . ) | 500-1500 tokens | Documents textuels (le plus courant) |
| Semantic | Decouper quand le sens change (embedding similarity) | Variable | Documents complexes, multi-sujets |
| Document | Un chunk = un document entier | Variable | FAQ, fiches produit, articles courts |
| Parent-child | Petits chunks pour retrieval, grands chunks pour contexte | 200 (child) / 2000 (parent) | Meilleure qualite (avance) |
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
| Metrique | Mesure | Seuil 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 Relevancy | La reponse repond-elle a la question ? (LLM judge) | > 85% |
| Faithfulness | La reponse est-elle fidele au contexte ? (pas d'hallucination) | > 90% |
| Latence E2E | Temps 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).
LLM Infrastructure : Serving & Scaling
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
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
| Outil | Type | Modeles supportes | Features cles | Usage |
|---|---|---|---|---|
| vLLM | Open source | Llama, Mistral, Falcon | PagedAttention, continuous batching, tres rapide | Self-hosting production |
| TGI (HuggingFace) | Open source | Tous HF models | Flash Attention, quantization, simple | Self-hosting, prototypage |
| Ollama | Open source | Llama, Mistral, Phi | Tres simple (1 commande), local | Dev local, experimentation |
| LiteLLM | Open source | 100+ providers | Interface unifiee, fallbacks, load balancing | LLM Gateway / proxy |
| OpenAI API | SaaS | GPT-4o, GPT-4-turbo | Zero ops, haute qualite | Production, pas de GPU |
Optimisation des Couts LLM
═══ 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
Prompt Management & Fine-tuning Pipelines
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
# 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
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ 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
{"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
| Methode | Description | Quand l'utiliser |
|---|---|---|
| Benchmark datasets | Jeux de test standardises (MMLU, HumanEval) | Comparer des modeles generiques |
| Custom eval set | 100-500 paires (question, reponse attendue) de votre domaine | Evaluer le fine-tuning sur votre cas |
| LLM-as-Judge | Utiliser GPT-4 pour noter les reponses automatiquement | Scale evaluation, iterer rapidement |
| Human evaluation | Experts notent les reponses (1-5) | Validation finale avant production |
| A/B testing | Comparer les metriques business en prod | Mesurer l'impact reel |
Ethical AI & Data Governance pour l'IA
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 biais | Description | Exemple | Mitigation |
|---|---|---|---|
| Selection bias | Donnees non representatives | Dataset de recrutement = 90% hommes | Sampling equilibre, augmentation |
| Historical bias | Donnees refletent des discriminations passees | Scores de credit historiquement biaises | Fairness constraints dans le modele |
| Measurement bias | Qualite de mesure inegale entre groupes | Reconnaissance faciale moins precise pour certaines ethnies | Evaluation par sous-groupe |
| Label bias | Annotations humaines biaisees | Annotateurs avec biais culturels | Multi-annotateurs, guidelines claires |
| Representation bias | Sous-representation de certains groupes | LLM entraine majoritairement en anglais | Donnees multilingues, fine-tuning |
AI Governance Framework
┌─────────────────────────────────────────────────────────────────┐ │ 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
# 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).
Lab : Construire un Pipeline RAG Complet
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
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│ 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
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
"""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
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
Question 2
Question 3
Question 4
Question 5
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
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 ?
┌──────────┐ 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
@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
# 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'usage | Description | Valeur business |
|---|---|---|
| Data Catalog semantique | Relier datasets, owners, lineage, business terms | Decouverte de donnees 5x plus rapide |
| Recommandation produit | Graphe produits-categories-clients-achats | +15% conversion cross-sell |
| Fraud detection | Reseau de transactions, comptes, adresses | Detection de patterns complexes |
| Drug discovery | Molecules, proteines, maladies, interactions | Reduction temps de recherche |
| RAG enrichi | Contexte structure pour les LLMs | Reponses plus precises et completes |
Neo4j : Property Graphs en Pratique
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
| Aspect | Property Graph (Neo4j) | RDF (SPARQL) |
|---|---|---|
| Modele | Noeuds + Relations (avec proprietes) | Triplets (sujet, predicat, objet) |
| Langage | Cypher (intuitif) | SPARQL (verbeux) |
| Schema | Flexible, optional | Ontologies (OWL, RDFS) |
| Proprietes | Sur noeuds ET relations | Uniquement sur sujets |
| Standards | Proprietaire (mais GQL arrive) | W3C standard |
| Performance | Excellent pour traversals | Bon, optimise pour jointures |
| Cas ideal | Applications, recommandations, fraud | Donnees ouvertes, linked data, semantique |
Cypher - Le SQL des Graphes
// 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
┌──────────┐ contient ┌──────────┐ source_de ┌──────────┐
│ Database │────────────────→│ Table │────────────────→│ Column │
│ Snowflake│ │ orders │ │ order_id │
└──────────┘ └────┬─────┘ └──────────┘
│
owner │ lineage
▼ │
┌──────────┐ │ ┌──────────┐
│ Team │ └───────→│ dbt Model│
│ Sales │ │ fct_orders│
└──────────┘ └──────────┘
│
consomme_par
▼
┌──────────┐
│Dashboard │
│ Revenue │
└──────────┘
// 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;
(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
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
| Concept | Description | Exemple | Complexite |
|---|---|---|---|
| Vocabulaire | Liste de termes | "Client", "Commande", "Produit" | Simple |
| Taxonomie | Hierarchie de categories | Produit → Electronique → Smartphone | Moyenne |
| Thesaurus | Taxonomie + synonymes + relations | "Client" = "Customer" = "Acheteur" | Moyenne |
| Ontologie | Modele complet avec types, relations, contraintes | "Un Client passe des Commandes qui contiennent des Produits" | Elevee |
KG + RAG : Le Combo Puissant
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
| Outil | Type | Usage | Prix |
|---|---|---|---|
| Neo4j | Property Graph DB | Applications, data catalog, recommandations | Community (gratuit) / Enterprise |
| Stardog | Enterprise KG | Data fabric, virtual graph, ontologies | $$$ |
| Amazon Neptune | Managed Graph DB | RDF + Property Graph, AWS integre | $$ |
| Protege | Ontology Editor | Creer et editer des ontologies OWL | Gratuit (Stanford) |
| DataHub | Data Catalog | Metadata graph, lineage, governance | Open source |
| Apache Jena | RDF Framework | Stocker et requeter du RDF (Java) | Open source |
Semantic Layer Avance & Data Catalogs
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
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
| Catalogue | Type | Forces | KG integre | Prix |
|---|---|---|---|---|
| DataHub | Open source (LinkedIn) | Lineage auto, extensible, GraphQL API | Oui (graph natif) | Gratuit |
| OpenMetadata | Open source | Simple, APIs REST, bonne UI | Partiel | Gratuit |
| Atlan | SaaS | UI excellente, collaboration, AI features | Oui | $$$ |
| Alation | SaaS/on-prem | Enterprise, ML catalog, governance | Oui | $$$ |
| Unity Catalog | Databricks | Integre Databricks, Delta Sharing | Non | $$ |
Business Glossary comme Code
# 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).
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
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
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
| Composant | Technologie | Role | Semaine |
|---|---|---|---|
| Data Platform | Snowflake + dbt + Dagster | Foundation (Bronze/Silver/Gold) | 1-3 |
| Feature Store | Feast + Redis | Features pour ML (churn, reco) | 4 |
| ML Pipeline | MLflow + scikit-learn | Model training, registry, serving | 5 |
| Vector Store | pgvector | Embeddings pour RAG | 6 |
| RAG Assistant | LangChain + GPT-4o | Assistant documentation interne | 6-7 |
| Knowledge Graph | Neo4j | Data catalog, lineage, glossary | 7 |
| Documentation | C4 + ADRs + README | Portfolio-ready documentation | 8 |
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
Examen Final : IA & Data Architecture
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)
Partie 2 : Vector DBs, RAG & LLMs (4 questions)
Partie 3 : Knowledge Graphs & Semantic (4 questions)
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.