Ce cours est mon support de formation à la data science et au machine learning : un endroit unique où centraliser ce que j'apprends, plutôt qu'une collection de notes éparpillées entre des notebooks, des articles et des marque-pages.

Le cours compte 28 modules, du premier environnement Python jusqu'à un projet complet mis en production, plus trois annexes — un glossaire, une série d'exercices et une bibliographie. Chaque module est une page autonome.

Le format

Le cours suppose des bases solides en mathématiques et en Python — je ne réexplique ni le calcul différentiel, ni l'algèbre linéaire élémentaire. En revanche, tout ce qui est spécifique à la data science est repris depuis le problème qu'il résout, avec des exemples de code exécutables. Chaque notion suit la même trame :

Les modules sont progressifs mais pas strictement séquentiels. L'ordre de lecture conseillé est celui des sept parties ci-dessous ; chaque module renvoie explicitement aux autres quand une notion y a déjà été traitée. Le dernier module reprend l'ensemble sur un projet unique, du scraping à la mise en production.

Quatre façons de le parcourir

Vingt-huit modules, cela ne se lit pas d'affilée. Selon ce qu'on cherche, quatre entrées possibles :

Sommaire

1. Python moderne : typage, décorateurs, itérateurs et outillage
2. Concurrence en Python : GIL, threads, processus, asyncio
3. Boîte à outils numérique : NumPy, pandas, polars, Dask
4. SQL et bases de données
5. Docker, Compose et Kubernetes
6. Exposer un modèle : FastAPI, Pydantic, Jinja
7. Ingénierie des données : formats, pipelines et flux
8. Mathématiques du ML : optimisation, algèbre linéaire, SVD et PCA
9. Statistique inférentielle : estimer, tester, décider
10. Probabilités, inférence bayésienne et quantification d'incertitude
11. Inférence causale : mesurer l'effet d'une action
12. Data science en pratique : du problème au dataset
13. Apprendre avec peu d'étiquettes
14. Machine learning classique
15. Théorie de l'apprentissage : pourquoi ça généralise
16. Deep learning
17. Séries temporelles, signaux et durées de vie
18. Données non tabulaires : texte, images, audio, graphes
19. Processus gaussiens et optimisation bayésienne
20. Apprentissage par renforcement
21. ML pour la simulation et l'ingénierie
22. LLM, embeddings, RAG et adaptation
23. Recherche, ranking et recommandation
24. Décision et action : du score à la décision
25. Passer à l'échelle : GPU, entraînement distribué, performance
26. MLOps : industrialiser un modèle
27. Équité, robustesse, confidentialité et sécurité
28. Projet de A à Z : annonces immobilières, du scraping à la prédiction
29. Glossaire et notations
30. Exercices et auto-évaluation
31. Ressources pour aller plus loin

Ce module ne réapprend pas Python : il installe l'environnement de travail d'un projet de data science, et surtout il explique en détail quatre mécanismes du langage qu'on croise partout dans le code scientifique sans forcément les avoir jamais étudiés — les décorateurs, les dataclasses, les annotations de type et les générateurs — auxquels s'ajoutent, en chemin, les méthodes spéciales et la notation *args / **kwargs. Chacun répond à un problème concret, et je pars du problème.

1. Structure d'un projet Python

Le problème

Un projet de data science commence toujours de la même façon : un notebook, quelques cellules, un résultat. Puis on veut relancer l'analyse sur de nouvelles données, et on s'aperçoit que le résultat dépendait de l'ordre dans lequel les cellules ont été exécutées, qu'une variable a été modifiée à la main entre deux essais, et que la fonction de nettoyage existe en trois versions dans trois notebooks différents. Le code n'est plus reproductible, et personne ne sait laquelle des trois versions a produit le modèle en cours d'utilisation.

La discipline qui évite cela tient en une phrase : dès qu'un bout de code est appelé deux fois, il quitte le notebook et devient un module importable. Le notebook reste ce qu'il est — un brouillon interactif, excellent pour regarder les données — et importe la logique au lieu de la contenir.

La disposition standard

mon-projet/
├── pyproject.toml        # identité du projet, dépendances, config des outils
├── uv.lock               # versions exactes installées (versionné dans Git)
├── README.md
├── src/
│   └── mon_projet/       # le paquet importable : import mon_projet
│       ├── __init__.py   # marque le dossier comme paquet (peut être vide)
│       ├── data.py       # chargement / nettoyage
│       ├── features.py   # transformations
│       └── models.py     # entraînement / inférence
├── notebooks/            # exploration ; aucune logique réutilisable ici
├── tests/
└── data/                 # ignoré par Git (voir section 8)

Pourquoi ce dossier src/ intermédiaire, qui semble n'ajouter qu'un niveau de profondeur ? Parce que sans lui, Python trouve le paquet simplement parce qu'il se trouve dans le répertoire courant. On peut alors avoir des tests qui passent alors que le paquet n'est en réalité pas installable — l'erreur n'apparaît que chez quelqu'un d'autre. Avec src/, le paquet n'est importable que s'il a été réellement installé dans l'environnement : ce qu'on teste est exactement ce qu'on distribuera.

Le fichier pyproject.toml

C'est la carte d'identité du projet, au format TOML (un format de configuration lisible, à mi-chemin entre INI et JSON). Il a remplacé l'ancien trio setup.py / setup.cfg / requirements.txt, et il centralise aussi la configuration des outils de qualité.

[project]
name = "mon-projet"                 # nom de distribution (tirets autorisés)
version = "0.1.0"
requires-python = ">=3.12"          # versions de Python acceptées
dependencies = [                    # ce dont le projet a besoin pour FONCTIONNER
    "numpy>=2.0",
    "polars>=1.0",
    "scikit-learn>=1.5",
]

[dependency-groups]                 # ce dont on a besoin pour DÉVELOPPER
dev = ["pytest>=8", "ruff>=0.6", "mypy>=1.11", "pre-commit>=3.8"]

[build-system]                      # comment fabriquer le paquet installable
requires = ["hatchling"]
build-backend = "hatchling.build"

[tool.ruff]                         # configuration du linter/formateur
line-length = 100

[tool.pytest.ini_options]           # configuration des tests
testpaths = ["tests"]

La distinction entre dependencies et le groupe dev a une conséquence concrète : l'image Docker de production (module 5) n'installe que les premières, ce qui la rend plus légère et réduit sa surface d'attaque.

Le système de build : à quoi sert hatchling ?

La section [build-system] est celle qu'on recopie sans la comprendre. Elle mérite trois minutes, parce qu'elle explique une bonne partie de l'écosystème Python.

Le problème. Un projet, sur le disque, est un répertoire de fichiers .py. Pour l'installer ailleurs — sur le serveur, dans l'image Docker, chez un collègue —, il faut le transformer en paquet : une archive normalisée, avec ses métadonnées (nom, version, dépendances), que pip ou uv sait déposer au bon endroit. Cette transformation s'appelle la construction (build), et elle produit deux formats :

mon_projet-0.1.0-py3-none-any.whl      ← la WHEEL : archive PRÊTE À POSER
  · rien à exécuter, pip décompresse et c'est installé
  · py3-none-any = n'importe quel Python 3, n'importe quel OS
  · pour un paquet contenant du C compilé, on aurait par exemple
    cp312-manylinux_x86_64 : une wheel par plateforme

mon_projet-0.1.0.tar.gz                ← la SDIST : archive des SOURCES
  · contient le code source, il faut construire avant d'installer
  · sert de repli quand aucune wheel ne correspond à la machine

Pourquoi un « backend » séparé. Historiquement, construire un paquet consistait à lancer python setup.py install : un script Python arbitraire, que l'installeur exécutait en croisant les doigts. Impossible de savoir à l'avance ce dont il avait besoin, ni ce qu'il allait faire. Deux propositions d'amélioration (les PEP 517 et 518) ont coupé le problème en deux :

  VOUS          uv pip install .
                     │
                     ▼
  FRONTEND      pip / uv / build          « je veux installer ce projet »
                     │                     il lit [build-system], installe
                     │                     ce qu'il demande dans un
                     │                     environnement isolé, puis
                     ▼                     l'appelle par une interface standard
  BACKEND       hatchling / setuptools    « voici la wheel et la sdist »
                     │                     lui seul sait COMMENT assembler
                     ▼                     le paquet
  ARTEFACTS     dist/*.whl  dist/*.tar.gz

  Le frontend ne sait rien du backend, et réciproquement : c'est ce
  découplage qui permet d'en changer en modifiant deux lignes.

C'est exactement ce que déclarent les deux lignes du pyproject.toml : requires dit ce que le frontend doit installer pour pouvoir construire, build-backend dit quelle fonction appeler ensuite.

Les backends que vous rencontrerez

hatchling            requires = ["hatchling"]
                     build-backend = "hatchling.build"
  Le défaut moderne, et celui que pose « uv init ». Zéro configuration
  pour un projet Python pur, versionnage dynamique, inclusion de fichiers
  simple à déclarer. C'est le choix par défaut à ne pas remettre en cause
  tant qu'on n'a pas une raison précise.

setuptools           requires = ["setuptools>=68"]
                     build-backend = "setuptools.build_meta"
  L'historique, toujours le plus répandu. Indispensable si le projet
  contient des extensions C à compiler à l'ancienne, ou si l'on hérite
  d'un setup.py existant. Plus verbeux, mais rien ne lui résiste.

poetry-core          requires = ["poetry-core>=1.9"]
                     build-backend = "poetry.core.masonry.api"
  Le backend de Poetry. On le croise dans les projets gérés par Poetry ;
  il impose sa propre section [tool.poetry] plutôt que [project].

flit-core            requires = ["flit_core>=3.9"]
                     build-backend = "flit_core.buildapi"
  Minimaliste, pour une bibliothèque d'un seul module sans dépendance
  de construction. Rien à configurer, rien à régler.

pdm-backend          requires = ["pdm-backend"]
                     build-backend = "pdm.backend"
  Proche de hatchling, avec des crochets d'extension en Python.

── quand le projet n'est PAS que du Python ──

maturin              pour une extension écrite en Rust (pydantic-core,
                     polars et ruff sont construits ainsi)
scikit-build-core    pour du C/C++ avec CMake
meson-python         pour du C/Fortran avec Meson (NumPy, SciPy)

uv build                    # produit dist/*.whl et dist/*.tar.gz
ls dist/
# mon_projet-0.1.0-py3-none-any.whl   mon_projet-0.1.0.tar.gz

unzip -l dist/*.whl         # une wheel est un simple fichier ZIP :
                            # on peut vérifier ce qu'elle contient vraiment

uv pip install dist/*.whl   # installer le paquet construit
uv publish                  # le pousser sur PyPI (ou un dépôt interne)

[tool.uv]
package = false      # projet « applicatif » : uv gère l'environnement
                     # et les dépendances, mais ne construit rien

2. Environnements virtuels et UV

Pourquoi un environnement virtuel

Un seul Python est installé sur la machine, avec un seul jeu de bibliothèques. Deux projets qui ont besoin de versions différentes de pandas ne peuvent donc pas coexister : installer l'un casse l'autre. Un environnement virtuel résout cela en créant un dossier — par convention .venv/ — qui contient sa propre copie de l'interpréteur et ses propres bibliothèques. Chaque projet a son atelier, avec ses outils à lui, et rien de ce qu'on y installe ne déborde sur les autres.

UV en pratique

UV (écrit en Rust par Astral, les auteurs de ruff) remplace à lui seul pip, virtualenv, pyenv, pipx et poetry. Deux différences pratiques : il est un à deux ordres de grandeur plus rapide, et il sait aussi installer les interpréteurs Python eux-mêmes — on n'a plus à se soucier de la version fournie par le système.

# créer un projet : génère pyproject.toml, .venv/ et uv.lock
uv init mon-projet && cd mon-projet

# installer une version précise de Python, sans toucher au Python système
uv python install 3.12
uv python pin 3.12              # fige la version pour ce projet

# ajouter une dépendance : résolution + installation + mise à jour du lock
uv add "polars>=1.0" scikit-learn
uv add --dev pytest ruff mypy pre-commit
uv remove scikit-learn          # retirer proprement

# recréer à l'identique l'environnement d'un collègue, ou celui de la CI
uv sync                         # installe EXACTEMENT ce que dit uv.lock
uv sync --no-dev                # sans les outils de développement (production)

# exécuter dans l'environnement, sans avoir à l'activer
uv run python -m mon_projet.train
uv run pytest
uv run ruff check .

# mettre à jour volontairement
uv lock --upgrade-package polars

# script autonome, dépendances déclarées dans son propre en-tête (PEP 723)
uv run --with pandas,matplotlib analyse.py

Contraintes et lockfile : la différence qui compte

Deux fichiers, deux rôles distincts. Le pyproject.toml déclare des contraintes — « numpy au moins en 2.0 » — c'est-à-dire une intention. Le uv.lock enregistre la solution exacte retenue par le résolveur — numpy 2.1.3, avec l'empreinte cryptographique de chaque fichier téléchargé — c'est-à-dire un état reproductible. Les deux se versionnent dans Git. Résultat : uv sync installe les mêmes octets sur votre machine, sur celle d'un collègue et dans la chaîne d'intégration continue, aujourd'hui comme dans six mois.

C'est la différence avec un requirements.txt produit par pip freeze : celui-ci fige les versions d'une seule plateforme, mélange dépendances directes et indirectes, et ne dit pas lesquelles vous avez demandées.

Et conda ? Il reste utile quand on dépend de bibliothèques système non-Python compliquées à compiler (GDAL, certains solveurs, une MKL configurée finement). Pour un projet de ML standard, UV est plus rapide, plus simple, et son lockfile est nettement plus fiable qu'un environment.yml.

3. Les décorateurs, de zéro

Le problème qu'ils résolvent

Supposons que l'on veuille chronométrer trois fonctions d'entraînement. La solution naïve consiste à copier deux lignes de mesure au début et à la fin de chacune. C'est répétitif, ça mélange la mesure et la logique métier, et le jour où l'on veut aussi journaliser les arguments, il faut repasser partout.

Un décorateur est la réponse de Python à ce problème : une façon d'emballer une fonction dans une autre qui ajoute un comportement avant et après, sans modifier une seule ligne de la fonction d'origine. L'image est celle d'un colis qu'on emballe : le contenu ne change pas, mais tout ce qui passe par l'emballage peut être compté, tracé, mis en cache.

Un détour nécessaire : *args et **kwargs

Le code qui suit s'appuie sur deux notations qu'on croise partout en Python sans toujours les avoir vues expliquées. Elles font une seule chose, dans les deux sens : regrouper plusieurs arguments en un seul objet, ou au contraire répandre un objet en plusieurs arguments.

Côté définition : recevoir un nombre variable d'arguments

Une fonction ordinaire impose sa signature : trois paramètres, trois valeurs. L'étoile lève cette contrainte.

def inspecter(*args, **kwargs):
    print("args   :", args)      # un TUPLE des arguments POSITIONNELS
    print("kwargs :", kwargs)    # un DICTIONNAIRE des arguments NOMMÉS

inspecter(1, 2, 3, alpha=0.1, verbose=True)
# args   : (1, 2, 3)
# kwargs : {'alpha': 0.1, 'verbose': True}

inspecter()
# args   : ()
# kwargs : {}                    # jamais None : toujours un tuple et un dict

# les noms sont une convention, pas une règle : seules les étoiles comptent.
# def f(*valeurs, **options) fonctionne exactement pareil — mais tout le
# monde écrit args et kwargs, alors autant faire comme tout le monde.

L'ordre des paramètres est imposé : d'abord les paramètres normaux, puis *args, puis les paramètres nommés uniquement, puis **kwargs.

def entrainer(donnees, *args, epochs=10, **kwargs):
    ...

entrainer(X, "extra", epochs=50, learning_rate=0.01)
# donnees = X         (positionnel normal)
# args    = ("extra",)
# epochs  = 50        (nommé, capté par son nom AVANT d'atteindre kwargs)
# kwargs  = {"learning_rate": 0.01}

Côté appel : répandre un conteneur en arguments

Les mêmes étoiles, placées à l'appel, font l'opération inverse : elles déballent. C'est l'usage le plus utile au quotidien.

def rmse(y_vrai, y_pred, poids=None):
    ...

paire = (y_vrai, y_pred)
rmse(*paire)                      # équivaut à rmse(y_vrai, y_pred)

params = {"y_vrai": y, "y_pred": p, "poids": w}
rmse(**params)                    # équivaut à rmse(y_vrai=y, y_pred=p, poids=w)

# l'usage qui revient sans cesse : une configuration lue dans un fichier,
# transmise telle quelle au constructeur du modèle
config = {"n_estimators": 500, "learning_rate": 0.05, "max_depth": 6}
modele = LGBMRegressor(**config)  # au lieu de recopier chaque paramètre

# fusionner deux dictionnaires, les valeurs de droite gagnant
defauts = {"n_estimators": 300, "random_state": 42}
final = {**defauts, **config}     # {'n_estimators': 500, 'random_state': 42, ...}

Le cas qui justifie tout le détour : transmettre sans savoir

Quand on écrit une fonction qui en enveloppe une autre, on ignore la signature de celle qu'on enveloppe. *args, **kwargs permet d'accepter n'importe quoi et de le retransmettre intact. C'est précisément ce que fait un décorateur, et c'est aussi la manière habituelle d'écrire une petite surcouche autour d'une bibliothèque :

import matplotlib.pyplot as plt

def courbe(x, y, titre, **kwargs):
    """Trace avec notre style maison, tout en laissant passer
    n'importe quelle option de matplotlib."""
    fig, ax = plt.subplots(figsize=(8, 4))
    ax.plot(x, y, linewidth=2, **kwargs)     # color=, linestyle=, alpha=, label=...
    ax.set_title(titre)
    ax.grid(alpha=0.3)
    return ax

courbe(t, y, "Perte", color="crimson", linestyle="--")
# on n'a pas eu à prévoir color ni linestyle : ils traversent la fonction

def decouper(X, y, *, test_size=0.2, stratifier=True):
    ...

decouper(X, y, 0.3)              # TypeError : 3 positionnels pour 2 attendus
decouper(X, y, test_size=0.3)    # ✓ obligatoirement nommé

premier, *reste = [1, 2, 3, 4]    # premier = 1 ; reste = [2, 3, 4]
debut, *milieu, fin = plis        # utile pour isoler les extrémités
tout = [*liste_a, *liste_b]       # concaténation lisible

Le mécanisme, en trois temps

Premier point à admettre : en Python, une fonction est une valeur comme une autre. On peut la mettre dans une variable, la passer en argument, la renvoyer.

def bonjour(nom):
    return f"Bonjour {nom}"

f = bonjour              # pas d'appel : on manipule la fonction elle-même
print(f("Nils"))         # Bonjour Nils
print(bonjour.__name__)  # bonjour  → une fonction a des attributs

Deuxième point : on peut donc écrire une fonction qui prend une fonction et en renvoie une nouvelle.

import time

def chrono(fonction):                     # reçoit la fonction à emballer
    def emballage(*args, **kwargs):       # la nouvelle fonction qui la remplacera
        debut = time.perf_counter()
        resultat = fonction(*args, **kwargs)   # on appelle l'originale
        duree = time.perf_counter() - debut
        print(f"{fonction.__name__} : {duree:.3f} s")
        return resultat                   # on renvoie SON résultat, inchangé
    return emballage                      # on renvoie l'emballage, pas son appel

def entrainer(n):
    time.sleep(n)
    return "modèle"

entrainer = chrono(entrainer)             # on remplace la fonction par sa version emballée
entrainer(0.5)                            # entrainer : 0.500 s

On retrouve ici *args et **kwargs dans leur rôle le plus caractéristique : l'emballage accepte n'importe quelle signature et la retransmet intacte. Sans eux, le décorateur ne fonctionnerait que pour des fonctions à un seul argument.

Troisième point : la ligne entrainer = chrono(entrainer) est si fréquente que Python lui donne une notation dédiée, le @. Les deux écritures ci-dessous sont rigoureusement équivalentes :

# AVANT : réécriture explicite
def entrainer(n): ...
entrainer = chrono(entrainer)

# APRÈS : la même chose, en une ligne au-dessus de la définition
@chrono
def entrainer(n): ...

import functools

def chrono(fonction):
    @functools.wraps(fonction)            # conserve nom, docstring, annotations
    def emballage(*args, **kwargs):
        ...
    return emballage

Les décorateurs de la bibliothèque standard

On en écrit rarement ; on en utilise constamment. Voici ceux qu'il faut reconnaître :

class Jeu:
    def __init__(self, X, y):
        self.X, self.y = X, y

    @property
    def taille(self):                     # se lit comme un attribut, se calcule à la demande
        return len(self.y)

    @property
    def taux_positifs(self):
        return float(self.y.mean())

jeu = Jeu(X, y)
print(jeu.taille)          # PAS jeu.taille() : le @property fait l'appel pour nous
print(jeu.taux_positifs)

L'intérêt : on expose une valeur calculée avec la même syntaxe qu'un attribut stocké. On peut donc transformer un attribut simple en valeur calculée plus tard, sans casser le code qui l'utilise.

Par défaut, une propriété est en lecture seule : écrire jeu.taille = 1000 lève une erreur. C'est souvent le comportement souhaité — la taille découle des données, la fixer directement n'aurait pas de sens. Quand on veut au contraire autoriser l'écriture, on ajoute un second bloc décoré par @taille.setter, et c'est lui qui devient l'endroit naturel où poser la validation.

class Jeu:
    def __init__(self, X, y):
        self.X, self.y = X, y

    @property
    def taille(self):                     # le LECTEUR : jeu.taille
        return len(self.y)

    @taille.setter                        # l'ÉCRIVAIN : jeu.taille = ...
    def taille(self, n):                  # même nom, c'est obligatoire
        if not isinstance(n, int):
            raise TypeError(f"taille doit être un entier, reçu {type(n).__name__}")
        if not 0 < n <= len(self.y):
            raise ValueError(f"taille attendue entre 1 et {len(self.y)}, reçu {n}")
        self.X, self.y = self.X[:n], self.y[:n]   # on tronque le jeu

jeu = Jeu(X, y)
print(jeu.taille)        # 50000

jeu.taille = 1000        # appelle le setter → le jeu est tronqué
print(jeu.taille)        # 1000

jeu.taille = 5000        # ValueError: taille attendue entre 1 et 1000, reçu 5000
jeu.taille = 12.5        # TypeError: taille doit être un entier, reçu float

Trois points à retenir. D'abord, le nom doit être identique : @taille.setter se lit « le setter de la propriété taille définie juste au-dessus », et les deux méthodes s'appellent taille. Ensuite, aucun code appelant ne change : jeu.taille = 1000 ressemble à une affectation ordinaire, alors qu'une méthode complète s'exécute — c'est tout l'intérêt, on peut ajouter la validation après coup sans toucher au reste du programme. Enfin, sans setter, la même ligne produit un message parfaitement clair :

jeu.taille = 1000
# AttributeError: property 'taille' of 'Jeu' object has no setter

Le même trio existe pour la suppression, avec @taille.deleter, appelé par del jeu.taille — nettement plus rare.

@staticmethod — une fonction rangée dans la classe

Le problème : une fonction utilitaire appartient logiquement à une classe — elle traite ses données — mais n'a besoin ni de l'instance, ni de la classe. La mettre en dehors éparpille le code ; en faire une méthode normale oblige à écrire un self dont on ne se sert pas.

class Jeu:
    def __init__(self, X, y):
        self.X, self.y = X, y

    @staticmethod                          # pas de self : c'est une fonction normale
    def normaliser(x):                     # qui vit simplement dans la classe
        return (x - x.mean()) / x.std()

# appelable des deux côtés, sans avoir besoin d'un objet
Jeu.normaliser(colonne)                    # sur la classe
jeu.normaliser(colonne)                    # sur une instance : même résultat

Le gain est l'organisation et la lisibilité : quiconque lit Jeu.normaliser sait immédiatement à quel domaine la fonction appartient. Le signal envoyé compte autant que la technique — @staticmethod dit « cette fonction ne touche à l'état d'aucun objet », ce qui la rend triviale à tester.

@classmethod — un constructeur alternatif

Le problème : une classe n'a qu'un __init__, mais on veut souvent la construire de plusieurs façons — depuis un fichier, depuis un dictionnaire, depuis une base. Entasser tous ces cas dans __init__ avec des arguments mutuellement exclusifs donne un constructeur illisible.

import json
from pathlib import Path

class Config:
    def __init__(self, n_estimators, learning_rate):
        self.n_estimators = n_estimators
        self.learning_rate = learning_rate

    @classmethod                           # reçoit la CLASSE (cls), pas l'instance
    def depuis_json(cls, chemin):
        donnees = json.loads(Path(chemin).read_text())
        return cls(**donnees)              # cls(...) construit l'objet

    @classmethod
    def par_defaut(cls):
        return cls(n_estimators=300, learning_rate=0.05)

cfg = Config.depuis_json("params.json")    # se lit comme une intention
cfg = Config.par_defaut()

Pourquoi cls(...) plutôt que Config(...) en dur ? Parce qu'une sous-classe hérite de la méthode : ConfigGPU.depuis_json(...) construira alors une ConfigGPU, et non une Config. C'est exactement ce que font datetime.now(), Path.cwd() ou pd.DataFrame.from_dict() — tous des méthodes de classe.

@functools.cached_property — calculé une fois, puis retenu

Le problème : une @property recalcule à chaque lecture. Sur une valeur coûteuse — une statistique sur un million de lignes —, une boucle qui la lit mille fois la recalcule mille fois.

import functools

class Jeu:
    def __init__(self, X, y):
        self.X, self.y = X, y

    @property
    def moyenne(self):                     # recalculée à CHAQUE accès
        print("calcul…")
        return self.X.mean(axis=0)

    @functools.cached_property
    def correlations(self):                # calculée UNE fois, puis mémorisée
        print("calcul lourd…")
        return np.corrcoef(self.X, rowvar=False)

jeu = Jeu(X, y)
jeu.moyenne; jeu.moyenne          # « calcul… » deux fois
jeu.correlations; jeu.correlations # « calcul lourd… » une seule fois

del jeu.correlations               # pour forcer un recalcul : on supprime le cache

Sous le capot, la valeur est simplement rangée dans l'objet lui-même. Deux conséquences : le cache disparaît avec l'objet — pas de fuite mémoire globale, contrairement à @cache —, mais il devient faux si l'on modifie les données après coup. La règle est donc : cached_property sur des objets qu'on ne modifie plus après construction, ce qui rejoint l'argument des dataclasses figées de la section suivante.

@functools.cache et @lru_cache — mémoriser les appels

Le problème : une fonction pure — même entrée, même sortie — appelée plusieurs fois avec les mêmes arguments refait le même travail. Charger un référentiel depuis le disque à chaque appel dans une boucle est le cas d'école.

import functools
import pandas as pd

@functools.cache                       # cache sans limite de taille
def charger_referentiel(annee: int) -> pd.DataFrame:
    print(f"lecture disque {annee}")
    return pd.read_parquet(f"ref_{annee}.parquet")

charger_referentiel(2025)              # lecture disque 2025
charger_referentiel(2025)              # rien : servi depuis le cache

@functools.lru_cache(maxsize=1024)     # idem, mais borné : au-delà de 1024
def distance(a: str, b: str) -> float: # entrées, la moins récemment utilisée
    ...                                # est évincée (Least Recently Used)

distance.cache_info()      # CacheInfo(hits=812, misses=1024, maxsize=1024, currsize=1024)
charger_referentiel.cache_clear()      # vider explicitement

Deux contraintes, et une mise en garde. Les arguments doivent être hachables : un entier ou une chaîne conviennent, une liste ou un DataFrame non — d'où l'intérêt des configurations immuables. Et le cache vit pour toute la durée du programme : sur une fonction appelée avec des millions d'arguments distincts, @cache est une fuite de mémoire pure et simple, alors que @lru_cache(maxsize=…) plafonne la consommation. En cas de doute, préférez la version bornée.

@contextlib.contextmanager — fabriquer un bloc with

Le problème : certaines actions vont par paires — ouvrir/fermer, démarrer un chronomètre/l'arrêter, changer un réglage/le remettre. Écrire la seconde moitié à la main s'oublie, surtout quand une exception coupe l'exécution au milieu.

import time
from contextlib import contextmanager

@contextmanager
def chronometre(nom):
    debut = time.perf_counter()
    try:
        yield                              # ← ici s'exécute le corps du « with »
    finally:                               # exécuté MÊME si une exception survient
        print(f"{nom} : {time.perf_counter() - debut:.2f} s")

with chronometre("entraînement"):
    modele.fit(X, y)
# entraînement : 12.43 s

Tout ce qui précède le yield s'exécute à l'entrée du bloc, tout ce qui suit à la sortie — et le finally garantit que la sortie a lieu même en cas d'erreur. C'est la version courte de ce qu'on écrirait sinon avec une classe et deux méthodes spéciales, __enter__ et __exit__. On croise le résultat partout : with open(...), with torch.no_grad():, with mlflow.start_run():.

@functools.singledispatch — une fonction, plusieurs types

Le problème : une fonction doit se comporter différemment selon le type qu'elle reçoit. La version naïve est une cascade de if isinstance(...) qui s'allonge à chaque nouveau cas, et qu'il faut modifier pour l'étendre.

from functools import singledispatch
import numpy as np, pandas as pd

@singledispatch                            # cas par défaut
def resumer(donnees):
    raise TypeError(f"type non pris en charge : {type(donnees).__name__}")

@resumer.register                          # le type est lu dans l'annotation
def _(donnees: pd.DataFrame):
    return f"DataFrame {donnees.shape[0]}×{donnees.shape[1]}"

@resumer.register
def _(donnees: np.ndarray):
    return f"tableau {donnees.shape}, moyenne {donnees.mean():.3f}"

@resumer.register
def _(donnees: list):
    return f"liste de {len(donnees)} éléments"

resumer(df)                # DataFrame 1000×12
resumer(np.zeros((3, 4)))  # tableau (3, 4), moyenne 0.000
resumer("abc")             # TypeError: type non pris en charge : str

L'avantage sur la cascade de if : on ajoute un type en écrivant une nouvelle fonction, sans toucher aux précédentes. La répartition se fait sur le type du premier argument seulement — d'où le nom. C'est utile pour une fonction de conversion ou d'affichage exposée à des entrées variées ; au-delà, une hiérarchie de classes est souvent plus claire.

Le même mécanisme se retrouve partout dans l'écosystème : @pytest.fixture et @pytest.mark.parametrize (section 7), @app.get("/items") dans FastAPI (module 6), @task dans les orchestrateurs, @numba.njit pour compiler une boucle, @abstractmethod pour déclarer une méthode qu'une sous-classe doit obligatoirement fournir. Savoir lire un @ comme « cette fonction est emballée par ceci » suffit à comprendre ces bibliothèques.

4. Dataclasses : frozen, slots et le reste

Le problème, en partant du début

Commençons par le besoin. Un entraînement dépend de plusieurs réglages : un chemin de données, un nombre d'arbres, un taux d'apprentissage, une graine aléatoire. On pourrait les trimballer en quatre variables séparées ; on préfère les regrouper dans un seul objet, qu'on passe en un seul argument et qu'on peut sauvegarder tel quel. Écrivons donc la classe la plus simple possible :

class TrainConfig:
    def __init__(self, data_path, n_estimators=300, learning_rate=0.05):
        self.data_path = data_path
        self.n_estimators = n_estimators
        self.learning_rate = learning_rate

cfg = TrainConfig("data/train.parquet")

# 1) je veux VOIR ce que contient cfg
print(cfg)
# <__main__.TrainConfig object at 0x7f3a2c1d5e50>      ← inutilisable

# 2) je veux comparer deux configurations identiques
a = TrainConfig("data/train.parquet")
b = TrainConfig("data/train.parquet")
print(a == b)
# False                                                  ← alors qu'elles sont IDENTIQUES

# 3) je veux dédoublonner une liste de configurations
len({a, b})
# 2                                                      ← deux fois la même, comptée deux fois

Les trois comportements sont décevants, et pour la même raison. Python ne devine rien : quand on lui demande d'afficher un objet ou d'en comparer deux, il pose la question à l'objet lui-même. Si la classe ne répond pas, Python se rabat sur des réponses par défaut qui sont correctes mais sans intérêt : afficher l'adresse mémoire, et considérer que deux objets ne sont égaux que s'ils sont le même objet — pas s'ils contiennent la même chose.

Comment Python « pose la question » : les méthodes spéciales

Le mécanisme est systématique et vaut la peine d'être compris une fois, parce qu'il explique une grande partie du langage. Certaines méthodes ont un nom entouré de deux tirets bas — __init__, __repr__, __eq__ — et on ne les appelle jamais soi-même : c'est Python qui les appelle pour nous, dans des situations précises. On les appelle « méthodes spéciales », ou dunder dans le jargon, pour double underscore.

L'image la plus juste est celle d'un formulaire à remplir. Le langage pose des questions standard ; chaque classe choisit d'y répondre ou non, et Python utilise la réponse partout où elle s'applique :

  VOTRE CODE              PYTHON APPELLE            SI LA CLASSE NE RÉPOND PAS
  ──────────────────────────────────────────────────────────────────────────
  TrainConfig(...)        __init__(self, ...)       objet vide, sans attribut
  print(cfg) / repr(cfg)  __repr__(self)            <...object at 0x7f3a…>
  a == b                  __eq__(self, autre)       comparaison d'IDENTITÉ
                                                    (est-ce le même objet ?)
  {a, b} / dict[cfg]      __hash__(self)            fondé sur l'adresse mémoire
  a < b, sorted([...])    __lt__(self, autre)       TypeError : non ordonnable
  len(jeu)                __len__(self)             TypeError : pas de longueur
  for x in jeu            __iter__(self)            TypeError : non itérable
  jeu[3]                  __getitem__(self, i)      TypeError : non indexable

  Aucune n'est obligatoire. Une classe est simplement plus ou moins
  « équipée » selon celles qu'elle définit.

Deux d'entre elles nous intéressent tout de suite.

def __repr__(self):
    return f"TrainConfig(data_path={self.data_path!r}, n_estimators={self.n_estimators})"
    # !r applique repr() à la valeur : une chaîne apparaît avec ses guillemets,
    #    ce qui évite de confondre le nombre 300 et la chaîne "300"

print(cfg)   # TrainConfig(data_path='data/train.parquet', n_estimators=300)

def __eq__(self, autre):
    if not isinstance(autre, TrainConfig):
        return NotImplemented          # « je ne sais pas comparer » : Python
                                       # essaiera l'autre sens, puis dira False
    return (self.data_path, self.n_estimators) == (autre.data_path, autre.n_estimators)
    # on compare deux TUPLES : Python compare élément par élément, dans l'ordre

a == b       # True, maintenant

D'où vient @dataclass

Écrire ces méthodes n'est pas difficile ; c'est mécanique. Le constructeur recopie chaque argument dans un attribut du même nom, l'affichage énumère les mêmes champs, la comparaison compare les mêmes champs. Trois fois la même liste de noms, recopiée à la main — et donc trois occasions d'oublier de mettre à jour l'une des trois le jour où l'on ajoute un paramètre. C'est exactement ce qu'on veut confier à une machine.

@dataclass est cette machine. C'est un décorateur ordinaire, au sens de la section 3 : il reçoit la classe, lit la liste de ses champs, écrit les méthodes spéciales à votre place, et renvoie la classe complétée. Rien de magique — ce qu'il produit est exactement le code qu'on aurait tapé, et l'on peut d'ailleurs le lire avec inspect.getsource ou en affichant TrainConfig.__init__.

Comparons donc les deux versions.

class TrainConfig:
    def __init__(self, data_path, n_estimators=300, learning_rate=0.05, random_state=42):
        self.data_path = data_path
        self.n_estimators = n_estimators
        self.learning_rate = learning_rate
        self.random_state = random_state

    def __repr__(self):
        return (f"TrainConfig(data_path={self.data_path!r}, "
                f"n_estimators={self.n_estimators}, "
                f"learning_rate={self.learning_rate}, "
                f"random_state={self.random_state})")

    def __eq__(self, autre):
        if not isinstance(autre, TrainConfig):
            return NotImplemented
        return (self.data_path, self.n_estimators, self.learning_rate, self.random_state) == \
               (autre.data_path, autre.n_estimators, autre.learning_rate, autre.random_state)

from dataclasses import dataclass, field
from pathlib import Path

@dataclass
class TrainConfig:
    data_path: Path                        # pas de valeur par défaut : argument obligatoire
    n_estimators: int = 300
    learning_rate: float = 0.05
    random_state: int | None = 42

cfg = TrainConfig(Path("data/train.parquet"), learning_rate=0.1)
print(cfg)        # TrainConfig(data_path=PosixPath('data/train.parquet'),
                  #             n_estimators=300, learning_rate=0.1, random_state=42)
cfg == TrainConfig(Path("data/train.parquet"), learning_rate=0.1)   # True

Quatre lignes déclaratives remplacent une vingtaine de lignes mécaniques, et l'on n'énumère plus les champs qu'une seule fois. Ajouter un paramètre demande désormais d'ajouter une ligne, contre trois endroits à modifier auparavant.

Une remarque importante au passage : ici, les annotations de type ne sont pas décoratives. C'est leur présence qui déclenche la génération du champ — une ligne n_estimators = 300 sans annotation serait ignorée par le décorateur. C'est l'un des rares endroits où le typage a un effet réel à l'exécution (voir la section 5).

Reste à choisir ce que le décorateur doit générer exactement : c'est le rôle de ses options.

Les options utiles

@dataclass(frozen=True, slots=True)
class TrainConfig:
    data_path: Path
    n_estimators: int = 300
    learning_rate: float = 0.05
    features: tuple[str, ...] = ()         # tuple, pas list : voir plus bas

frozen=True — l'objet devient immuable. Toute tentative de modification lève une erreur au lieu de passer inaperçue :

cfg.learning_rate = 0.5
# FrozenInstanceError: cannot assign to field 'learning_rate'

Pourquoi vouloir cela ? Parce qu'une configuration qui change en cours d'exécution est une source de bugs irreproductibles : on lance un entraînement, une fonction modifie discrètement un paramètre au passage, et le résultat ne correspond plus à ce qu'on croit avoir demandé. Une configuration figée est une garantie que ce qu'on a lu au début est ce qui a servi jusqu'au bout. Bénéfice secondaire : un objet immuable est hachable, donc utilisable comme clé de dictionnaire ou argument d'une fonction mise en cache (section 3). Pour obtenir une variante, on ne modifie pas : on copie en changeant ce qu'il faut, avec dataclasses.replace(cfg, learning_rate=0.1).

slots=True — attributs fixés d'avance. Par défaut, chaque objet Python porte un dictionnaire interne (__dict__) qui associe des noms d'attributs à des valeurs, ce qui permet d'en ajouter n'importe quand. C'est souple, mais cela coûte de la mémoire et laisse passer les fautes de frappe :

# sans slots : la faute de frappe crée un NOUVEL attribut, en silence
cfg.learnig_rate = 0.1        # aucune erreur ; le vrai paramètre n'a pas bougé

# avec slots=True : la liste des attributs est figée à la création de la classe
cfg.learnig_rate = 0.1
# AttributeError: 'TrainConfig' object has no attribute 'learnig_rate'

L'économie de mémoire (souvent 30 à 40 % par instance) ne compte que si l'on crée des millions d'objets ; la détection des fautes de frappe, elle, sert tous les jours.

from dataclasses import dataclass, field, asdict, replace

@dataclass(frozen=True, slots=True, order=True, kw_only=True)
class Resultat:
    rmse: float
    modele: str
    # exclu de la comparaison et de l'affichage (par exemple un gros objet) :
    predictions: list = field(default_factory=list, compare=False, repr=False)

    def __post_init__(self):              # appelé après l'init généré : validation
        if self.rmse < 0:
            raise ValueError("un RMSE ne peut pas être négatif")

r = Resultat(rmse=0.42, modele="gbm")     # kw_only : arguments NOMMÉS obligatoires
sorted([r1, r2, r3])                      # order=True : comparaison champ par champ
asdict(r)                                 # → dict, prêt pour json.dumps ou MLflow
replace(r, modele="xgb")                  # copie modifiée (l'original est figé)

Deux cousines à connaître : typing.NamedTuple, plus légère mais limitée à un tuple immuable, et pydantic, qui ressemble beaucoup à une dataclass mais vérifie et convertit les types à l'exécution. La règle de choix : dataclass pour les objets internes au code, pydantic dès que les données viennent de l'extérieur — fichier de configuration, requête HTTP, réponse d'API. C'est le socle de FastAPI, détaillé au module 6.

5. Les annotations de type

Ce que c'est, et ce que ce n'est pas

Une annotation comme def rmse(y: np.ndarray) -> float est une métadonnée. Python ne la vérifie pas à l'exécution : passer une chaîne de caractères à cette fonction ne déclenchera aucune erreur de typage (seulement, plus loin, une erreur incompréhensible). Les annotations servent à trois choses : un vérificateur statique (mypy, pyright) qui lit le code sans l'exécuter et signale les incohérences, l'éditeur qui propose l'autocomplétion et détecte les fautes, et le lecteur, pour qui la signature devient une documentation qui ne peut pas mentir trop longtemps.

from collections.abc import Iterable, Callable, Sequence
from pathlib import Path
import numpy as np
from numpy.typing import NDArray

def charger(chemin: Path) -> pd.DataFrame: ...

def normaliser(x: NDArray[np.float64]) -> NDArray[np.float64]: ...

def selectionner(noms: Sequence[str], seuil: float = 0.5) -> list[str]: ...

# "peut valoir None" : le | remplace l'ancien Optional[...]
def charger_modele(chemin: Path | None = None) -> Modele | None: ...

# une fonction en argument
def appliquer(f: Callable[[float], float], valeurs: Iterable[float]) -> list[float]:
    return [f(v) for v in valeurs]

# un dictionnaire dont on connaît les clés
scores: dict[str, float] = {"rmse": 0.42, "mae": 0.31}

6. Itérateurs et générateurs

Le problème

Un fichier de journaux de 40 Go, une machine avec 16 Go de RAM. La ligne lignes = open("events.jsonl").readlines() échoue par manque de mémoire, parce qu'elle construit la liste complète avant d'en traiter le premier élément. Il faut une façon de produire les données au fur et à mesure : un distributeur qui fabrique à la demande, plutôt qu'un entrepôt qu'on remplit d'abord.

Itérable et itérateur : deux notions distinctes

Un itérable est un objet sur lequel on peut faire une boucle for (une liste, un dictionnaire, un fichier). Un itérateur est l'objet qui garde la position courante et sait donner l'élément suivant. La boucle for cache ce mécanisme : elle demande d'abord un itérateur à l'itérable, puis lui réclame les éléments un par un jusqu'à épuisement.

nombres = [10, 20, 30]

it = iter(nombres)      # on demande un itérateur à l'itérable
print(next(it))         # 10
print(next(it))         # 20
print(next(it))         # 30
print(next(it))         # StopIteration : c'est le signal de fin, que for intercepte

# la boucle ci-dessous est exactement équivalente à ce qui précède
for n in nombres:
    print(n)

Écrire son propre itérateur (la version longue)

Pour comprendre ce que les générateurs automatisent, écrivons d'abord un itérateur « à la main ». Il suffit d'implémenter deux méthodes : __iter__, qui renvoie l'itérateur lui-même, et __next__, qui renvoie l'élément suivant ou lève StopIteration.

class Lots:
    """Découpe une séquence en lots de taille fixe."""

    def __init__(self, donnees, taille):
        self.donnees = donnees
        self.taille = taille
        self.position = 0          # l'ÉTAT que l'itérateur doit mémoriser

    def __iter__(self):
        return self                # l'objet est son propre itérateur

    def __next__(self):
        if self.position >= len(self.donnees):
            raise StopIteration    # plus rien à donner : fin de la boucle
        lot = self.donnees[self.position : self.position + self.taille]
        self.position += self.taille
        return lot

for lot in Lots(list(range(10)), 3):
    print(lot)                     # [0,1,2] puis [3,4,5] puis [6,7,8] puis [9]

Le générateur : le même résultat en quatre lignes

Une fonction qui contient le mot-clé yield ne se comporte plus comme une fonction ordinaire. L'appeler n'exécute rien : cela renvoie un générateur. À chaque next(), le corps s'exécute jusqu'au prochain yield, renvoie la valeur, puis se met en pause en conservant tout son état local — variables et position dans le code. L'appel suivant reprend exactement là où on s'était arrêté.

def lots(donnees, taille):
    for debut in range(0, len(donnees), taille):
        yield donnees[debut : debut + taille]      # pause ici, reprise au prochain appel

for lot in lots(list(range(10)), 3):
    print(lot)                                     # résultat identique

Le générateur écrit pour nous __iter__, __next__, la gestion de l'état et le StopIteration final. Observons la mise en pause pas à pas :

def trace():
    print("  → début du corps")
    yield 1
    print("  → reprise après le premier yield")
    yield 2
    print("  → reprise après le second yield")

g = trace()            # RIEN ne s'affiche : le corps n'a pas encore démarré
print(next(g))         #   → début du corps        puis affiche 1
print(next(g))         #   → reprise après ...     puis affiche 2
next(g)                #   → reprise après ...     puis StopIteration

Application : traiter un fichier plus gros que la mémoire

import json, itertools
from collections.abc import Iterator

def lire_lignes(chemin: str) -> Iterator[dict]:
    """Une ligne en mémoire à la fois, quelle que soit la taille du fichier."""
    with open(chemin, encoding="utf-8") as f:
        for ligne in f:                 # un fichier ouvert EST déjà un itérateur
            yield json.loads(ligne)

def valides(evenements: Iterator[dict]) -> Iterator[dict]:
    """Filtre, sans rien matérialiser."""
    for e in evenements:
        if e.get("prix") and e["prix"] > 0:
            yield e

def par_lots(iterable, taille: int):
    """Regroupe en lots — indispensable pour l'inférence batchée (module 6)."""
    it = iter(iterable)
    while lot := list(itertools.islice(it, taille)):   # := affecte ET teste
        yield lot

# les trois générateurs se chaînent : la mémoire reste en O(taille du lot)
flux = par_lots(valides(lire_lignes("events.jsonl")), 1024)
for lot in flux:
    scores = modele.predict(lot)

Rien n'est exécuté tant qu'on ne consomme pas le flux : c'est l'évaluation paresseuse. Chaque lot traverse les trois étapes à la demande, et la mémoire ne dépend que de la taille du lot. En Python 3.12+, itertools.batched fait le travail de par_lots nativement.

# expression génératrice : comme une compréhension de liste, mais paresseuse
carres = (x ** 2 for x in range(10_000_000))    # rien n'est calculé ni stocké
total = sum(carres)                             # calcul au fil de la consommation

# yield from : déléguer à un autre générateur (aplatissement, composition)
def tous_les_fichiers(dossiers):
    for d in dossiers:
        yield from lire_lignes(d)

# générateur infini : parfaitement légitime, tant qu'on le borne à la consommation
def compteur(debut=0):
    n = debut
    while True:
        yield n
        n += 1

premiers = list(itertools.islice(compteur(), 5))     # [0, 1, 2, 3, 4]

# itertools : groupby, chain, product, accumulate, tee — tous paresseux
for cle, groupe in itertools.groupby(sorted(lignes, key=cle_ville), key=cle_ville):
    print(cle, sum(1 for _ in groupe))

7. Qualité : ruff, pytest, pre-commit

ruff : formatage et analyse statique

ruff remplace flake8, isort, black et une bonne partie de pylint, en une fraction du temps. Deux usages complémentaires : check signale les erreurs probables (import inutilisé, variable jamais lue, comparaison suspecte) et format réécrit le code dans un style unique.

uv run ruff check --fix .        # signale et corrige ce qui peut l'être
uv run ruff format .             # formatage automatique
uv run mypy src/                 # vérification des types

Le formatage automatique n'est pas une coquetterie : il supprime les différences de style dans les diffs, qui polluent les revues et masquent les vrais changements.

pytest : tester du code de data science

La question n'est pas « comment écrire un test » mais « que faut-il tester ». On ne teste pas « le modèle atteint 92 % d'accuracy » — cela dépend des données et relève du suivi en production (module 26). On teste la plomberie : les formes, les cas dégénérés, le déterminisme, les invariants métier.

import numpy as np
import pytest
from mon_projet.features import ajouter_features_temporelles, entrainer

@pytest.fixture                              # une donnée de test réutilisable
def df_exemple():
    return pd.DataFrame({"date": pd.date_range("2025-01-01", periods=30),
                         "valeur": np.arange(30, dtype=float)})

def test_pas_de_fuite_temporelle(df_exemple):
    """Une feature calculée à t ne doit jamais utiliser d'information de t+1."""
    out = ajouter_features_temporelles(df_exemple)
    assert out["moyenne_mobile_7j"].iloc[0] != out["valeur"].iloc[0]

@pytest.mark.parametrize("n_lignes", [0, 1, 1000])     # le test est joué 3 fois
def test_robustesse_aux_tailles(n_lignes):
    """Les cas dégénérés — vide, une seule ligne — cassent souvent."""
    df = generer_df(n_lignes)
    assert len(ajouter_features_temporelles(df)) == n_lignes

def test_deterministe():
    """Même graine, même résultat : sinon rien n'est reproductible."""
    np.testing.assert_allclose(entrainer(seed=0).predict(X), entrainer(seed=0).predict(X))

def test_probabilites_valides():
    p = modele.predict_proba(X)
    assert np.all((p >= 0) & (p <= 1)) and np.allclose(p.sum(axis=1), 1.0)

pre-commit : automatiser les vérifications

Le problème. Les outils précédents ne servent que si on pense à les lancer. En pratique, on oublie, et le code mal formaté ou cassé entre dans l'historique Git ; la chaîne d'intégration continue le signale dix minutes plus tard, et il faut un commit supplémentaire pour corriger.

La solution. Git sait déclencher des scripts à certains moments de son cycle — ce sont les hooks. pre-commit est un outil qui installe un hook déclenché avant chaque commit, lance les vérifications sur les seuls fichiers modifiés, et annule le commit si quelque chose ne va pas. Le code fautif n'entre jamais dans l'historique.

uv add --dev pre-commit
uv run pre-commit install        # écrit le hook dans .git/hooks/pre-commit

# vérifier tout le dépôt (utile la première fois, ou en CI)
uv run pre-commit run --all-files

# mettre à jour les versions des outils déclarés
uv run pre-commit autoupdate

repos:
  # ── hooks génériques, fournis par pre-commit lui-même ──
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v5.0.0
    hooks:
      - id: trailing-whitespace        # supprime les espaces en fin de ligne
      - id: end-of-file-fixer          # garantit un saut de ligne final
      - id: check-yaml                 # valide la syntaxe des fichiers YAML
      - id: check-added-large-files    # REFUSE les fichiers volumineux
        args: ["--maxkb=5000"]         #   → empêche de committer un CSV par erreur
      - id: check-merge-conflict       # détecte les marqueurs de conflit oubliés
      - id: detect-private-key         # refuse une clé privée committée

  # ── lint et formatage ──
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.6.9
    hooks:
      - id: ruff
        args: [--fix]
      - id: ruff-format

  # ── types ──
  - repo: https://github.com/pre-commit/mirrors-mypy
    rev: v1.11.2
    hooks:
      - id: mypy
        additional_dependencies: [numpy, pandas-stubs]

  # ── notebooks : retire les sorties avant commit ──
  - repo: https://github.com/kynan/nbstripout
    rev: 0.7.1
    hooks:
      - id: nbstripout

Deux hooks méritent qu'on s'y arrête. check-added-large-files est la meilleure protection contre l'erreur la plus coûteuse d'un projet data — committer un jeu de données (section 8). nbstripout retire les sorties des notebooks : sans lui, chaque exécution produit un diff de plusieurs milliers de lignes illisibles, et les images encodées font gonfler le dépôt indéfiniment.

Un dernier détail pratique : git commit --no-verify contourne les hooks. C'est utile dans une urgence, et c'est aussi la raison pour laquelle les mêmes vérifications doivent tourner dans la chaîne d'intégration continue, où personne ne peut les contourner (module 26).

8. Git pour un projet data

Le workflow que j'utilise, volontairement minimal : main toujours fonctionnelle, une branche par sujet, une pull request même en solo — elle force une relecture du diff complet, ce qui attrape beaucoup d'erreurs.

git switch -c feat/gradient-boosting     # créer et basculer sur une branche
git add -p                               # relire chaque morceau avant de l'indexer
git commit -m "feat(model): baseline XGBoost, RMSE 0.42 en CV"

git fetch origin
git rebase origin/main                   # historique linéaire AVANT publication
git push -u origin feat/gradient-boosting

git log --oneline --graph -15            # visualiser l'historique
git diff main...HEAD                     # tout ce que la branche apporte

Rebase ou merge ? Rebase tant que la branche est privée : l'historique reste linéaire et lisible. Merge dès qu'elle est partagée : réécrire des commits que quelqu'un a déjà récupérés casse son dépôt. La règle tient en une phrase — ne jamais réécrire un historique déjà publié.

Les messages suivent la convention Conventional Commits (feat:, fix:, refactor:, docs:) : cela permet de générer un changelog et, surtout, de retrouver pourquoi une transformation a été ajoutée six mois plus tard.

C'est le point où l'intuition venant du C ou du calcul parallèle classique induit en erreur. Trois modèles de concurrence coexistent en Python, ils ne servent pas aux mêmes problèmes, et choisir le mauvais peut ralentir un programme au lieu de l'accélérer. Ce module part de zéro : ce qu'est un thread, pourquoi le GIL existe, comment savoir lequel des trois modèles s'applique à votre cas, puis chaque outil avec des exemples complets.

1. Processus, thread, concurrence, parallélisme

Quatre mots qu'on emploie souvent l'un pour l'autre, et qu'il faut séparer une bonne fois.

Un processus est un programme en cours d'exécution, avec sa propre zone de mémoire, isolée de celle des autres. Deux processus ne peuvent pas se marcher dessus : pour échanger des données, ils doivent explicitement se les envoyer.

Un thread (ou fil d'exécution) est une ligne d'exécution à l'intérieur d'un processus. Plusieurs threads d'un même processus partagent la même mémoire : ils voient les mêmes variables. C'est ce qui les rend légers — créer un thread coûte bien moins cher que créer un processus — et c'est aussi ce qui les rend dangereux, puisque deux threads peuvent modifier la même donnée en même temps (section 5).

La concurrence, c'est gérer plusieurs tâches en cours en même temps, sans forcément les exécuter simultanément : un cuisinier qui met l'eau à bouillir, découpe des légumes pendant ce temps, puis revient à sa casserole, est concurrent. Le parallélisme, c'est exécuter réellement plusieurs calculs à la même seconde, ce qui exige plusieurs cœurs : deux cuisiniers. La distinction est décisive : pour une tâche qui passe son temps à attendre, la concurrence suffit ; pour une tâche qui calcule, il faut du parallélisme.

2. Le GIL, énoncé correctement

Ce que c'est

Le Global Interpreter Lock est un verrou interne à CPython, l'implémentation de référence de Python. Sa règle : un seul thread exécute du bytecode Python à un instant donné dans un processus. Les threads existent bien, le système d'exploitation les ordonnance, mais ils se passent ce jeton à tour de rôle au lieu de travailler en même temps.

Pourquoi il existe

Python gère la mémoire par comptage de références : chaque objet sait combien de variables pointent vers lui, et il est détruit quand ce compteur tombe à zéro. Si deux threads modifiaient ce compteur simultanément, il deviendrait incohérent — des objets encore utilisés seraient libérés, d'autres ne le seraient jamais. Le GIL est la solution la plus simple à ce problème : un verrou global plutôt qu'un verrou par objet. Il rend l'interpréteur simple, rapide en mono-thread, et facile à interfacer avec du C. Le prix est celui qu'on connaît.

La conséquence, mesurée

import time
from concurrent.futures import ThreadPoolExecutor

def calcul(n=10_000_000):            # boucle Python pure : CPU-bound
    total = 0
    for i in range(n):
        total += i * i
    return total

debut = time.perf_counter()
[calcul() for _ in range(4)]                       # séquentiel
print(f"séquentiel : {time.perf_counter() - debut:.1f} s")     # ≈ 4,0 s

debut = time.perf_counter()
with ThreadPoolExecutor(max_workers=4) as ex:      # 4 threads sur 4 cœurs
    list(ex.map(lambda _: calcul(), range(4)))
print(f"4 threads   : {time.perf_counter() - debut:.1f} s")    # ≈ 4,1 s — AUCUN gain

Quatre threads sur quatre cœurs ne vont pas plus vite qu'un seul, et sont même légèrement plus lents à cause du coût de bascule entre threads. Voilà l'effet du GIL sur du calcul Python pur.

Les deux exceptions, qui changent tout

Le GIL est relâché — c'est-à-dire rendu aux autres threads — dans deux situations :

• pendant une attente d'entrée/sortie : lecture disque, requête réseau, appel à une base de données. Le thread qui attend une réponse HTTP n'exécute aucun bytecode : il rend le jeton et les autres travaillent.
• pendant l'exécution de code natif qui le relâche explicitement — et c'est exactement ce que font NumPy, SciPy, scikit-learn, PyTorch et polars dans leurs boucles de calcul, écrites en C ou en Rust.

Autrement dit : un produit matriciel NumPy lancé dans quatre threads utilise réellement quatre cœurs, alors que la boucle Python ci-dessus n'en utilise qu'un. Ce n'est pas « les threads sont inutiles en Python », c'est « les threads sont inutiles pour du bytecode Python ».

Depuis Python 3.13 existe un mode expérimental free-threaded (PEP 703) qui supprime le GIL, mais l'écosystème scientifique n'y est pas encore entièrement porté. En 2026, on continue de raisonner avec le GIL.

3. Diagnostiquer : où passe le temps ?

Avant de choisir un outil, il faut savoir si le programme attend ou s'il calcule. C'est la seule question qui compte, et elle se tranche par la mesure, pas par l'intuition.

import time, cProfile

debut_mur = time.perf_counter()     # temps réellement écoulé (horloge murale)
debut_cpu = time.process_time()     # temps de CPU consommé par le processus

mon_traitement()

mur = time.perf_counter() - debut_mur
cpu = time.process_time() - debut_cpu
print(f"mur={mur:.1f}s  cpu={cpu:.1f}s  ratio={cpu/mur:.0%}")

# ratio proche de 100 % → le CPU travaille : CPU-bound     → processus (section 6)
# ratio faible (10-20 %) → le programme attend : I/O-bound → threads ou asyncio
cProfile.run("mon_traitement()", sort="cumtime")   # où exactement, ligne par ligne

4. Les threads, pour attendre

Le module concurrent.futures fournit une interface uniforme pour les threads comme pour les processus. Le vocabulaire : on soumet des tâches à un pool de workers, et chaque soumission renvoie un Future — un objet qui représente « un résultat qui n'existe pas encore ». On l'interroge quand on en a besoin.

from concurrent.futures import ThreadPoolExecutor
import requests

def telecharger(url: str) -> int:
    r = requests.get(url, timeout=10)      # le GIL est relâché pendant l'attente réseau
    return len(r.content)

urls = [f"https://exemple.fr/page/{i}" for i in range(200)]

with ThreadPoolExecutor(max_workers=16) as ex:   # 16 threads ; le with attend la fin
    tailles = list(ex.map(telecharger, urls))    # map : garde l'ORDRE des urls

print(sum(tailles))

Deux cents requêtes séquentielles à 100 ms font 20 secondes ; avec seize threads, environ 1,3 seconde. Le gain vient du fait que les threads passent leur temps bloqués en attente réseau, GIL relâché.

ex.map est le plus simple, mais il renvoie les résultats dans l'ordre des entrées : si la première requête est lente, on attend. Pour traiter chaque résultat dès qu'il arrive, et surtout pour gérer les erreurs proprement, on utilise submit et as_completed :

from concurrent.futures import ThreadPoolExecutor, as_completed

resultats, echecs = {}, {}

with ThreadPoolExecutor(max_workers=16) as ex:
    # on soumet tout, et on garde la correspondance future → url
    futures = {ex.submit(telecharger, url): url for url in urls}

    for fut in as_completed(futures):          # rend la main dès qu'un résultat arrive
        url = futures[fut]
        try:
            resultats[url] = fut.result()      # l'exception éventuelle surgit ICI
        except requests.Timeout:
            echecs[url] = "timeout"
        except Exception as e:                 # ne jamais laisser une tâche tuer la boucle
            echecs[url] = repr(e)

print(f"{len(resultats)} réussites, {len(echecs)} échecs")

Combien de threads ? Pour de l'I/O, on peut largement dépasser le nombre de cœurs — quelques dizaines — puisqu'ils attendent la plupart du temps. La limite vient plutôt de ce qu'accepte le service distant : au-delà, on se fait limiter ou bannir. Un ordre de grandeur raisonnable est 8 à 32, en surveillant les codes 429.

5. Partager de l'état entre threads

Puisque les threads partagent la mémoire, ils peuvent modifier les mêmes variables — et c'est là que surgissent les bugs les plus difficiles à reproduire. Une condition de course (race condition) apparaît quand le résultat dépend de l'ordre, imprévisible, dans lequel les threads s'intercalent.

compteur = 0

def incrementer(n=100_000):
    global compteur
    for _ in range(n):
        compteur += 1        # PAS atomique : lire, ajouter 1, réécrire — 3 étapes

with ThreadPoolExecutor(max_workers=4) as ex:
    list(ex.map(lambda _: incrementer(), range(4)))

print(compteur)              # attendu 400 000 ; obtenu 387 412, 400 000, 392 118...

L'explication : compteur += 1 se décompose en trois opérations. Un thread peut lire la valeur 100, être interrompu, puis un autre lit aussi 100, ajoute 1 et écrit 101 ; le premier reprend, écrit lui aussi 101. Un incrément est perdu. Le GIL ne protège pas de cela : il garantit qu'une seule instruction de bytecode s'exécute à la fois, pas qu'une séquence de trois reste indivisible.

import threading, queue

# 1. un verrou : une seule section critique à la fois
verrou = threading.Lock()
def incrementer_sur(n=100_000):
    global compteur
    for _ in range(n):
        with verrou:          # acquiert, exécute, relâche — même en cas d'exception
            compteur += 1     # correct, mais le verrou coûte cher s'il est très sollicité

# 2. NE RIEN PARTAGER : chaque thread renvoie son résultat, on agrège à la fin
def compter(n):
    total = 0
    for _ in range(n):
        total += 1
    return total              # aucune variable partagée → aucun verrou nécessaire
with ThreadPoolExecutor(4) as ex:
    compteur = sum(ex.map(compter, [100_000] * 4))    # exact, et plus rapide

# 3. une file : la structure conçue pour la communication entre threads
travaux = queue.Queue()       # thread-safe par construction
resultats = queue.Queue()

La deuxième approche est presque toujours la bonne : ne pas partager d'état mutable. Chaque tâche produit un résultat indépendant, et l'agrégation se fait dans le thread principal. Les verrous n'ont leur place que lorsqu'une ressource est intrinsèquement unique — un fichier de log, une connexion. Et il faut savoir qu'ils apportent leurs propres pièges : deux verrous acquis dans des ordres différents par deux threads produisent un interblocage, où chacun attend indéfiniment l'autre.

6. Les processus, pour calculer

Pour du calcul Python pur, la seule échappatoire au GIL consiste à lancer plusieurs processus : chacun a son propre interpréteur, donc son propre GIL. L'interface est identique à celle des threads, ce qui rend le passage de l'un à l'autre presque gratuit — mais les contraintes, elles, sont très différentes.

from concurrent.futures import ProcessPoolExecutor
import random

def simuler(graine: int) -> float:
    """Monte-Carlo en Python pur : CPU-bound, donc les threads seraient inutiles."""
    rng = random.Random(graine)
    return sum(rng.random() ** 2 for _ in range(1_000_000)) / 1_000_000

if __name__ == "__main__":                 # OBLIGATOIRE — explication ci-dessous
    with ProcessPoolExecutor(max_workers=8) as ex:
        resultats = list(ex.map(simuler, range(64), chunksize=4))
    print(sum(resultats) / len(resultats))

Ici, le gain est réel : sur huit cœurs, on approche un facteur sept. Trois contraintes expliquent en revanche la plupart des échecs rencontrés avec les processus.

a. La sérialisation

Les processus ne partagent pas la mémoire : arguments et résultats doivent donc être sérialisés — convertis en octets par le module pickle, transmis, puis reconstruits de l'autre côté. Conséquences concrètes : envoyer un DataFrame de 3 Go à huit workers, c'est le sérialiser huit fois, et le transfert coûte alors bien plus cher que le calcul. Et tout n'est pas sérialisable — les fonctions anonymes (lambda), les fonctions définies dans une autre fonction, les objets tenant un fichier ouvert ou une connexion échouent avec un message souvent obscur.

# ÉCHOUE : une lambda n'est pas picklable
ex.map(lambda x: x ** 2, donnees)

# FONCTIONNE : une fonction définie au niveau du module
def carre(x): return x ** 2
ex.map(carre, donnees)

b. La méthode de démarrage

Deux façons de créer un processus enfant. fork (historique sous Linux) duplique le processus courant : rapide, mais dangereux en présence de threads, car un verrou détenu au moment de la duplication reste verrouillé à jamais dans l'enfant — d'où des blocages inexplicables. spawn (défaut sous Windows et macOS, et sous Linux à partir de Python 3.14) démarre un interpréteur neuf qui réimporte le module.

C'est cette réimportation qui explique le fameux if __name__ == "__main__":. Sans lui, le code de lancement du pool serait réexécuté par chaque enfant, qui créerait à son tour un pool, et ainsi de suite — une bombe à fourche qui sature la machine en quelques secondes.

c. Le coût fixe

Créer un processus coûte quelques dizaines à quelques centaines de millisecondes. Paralléliser des tâches de 5 ms est donc perdant : le temps passé à distribuer dépasse le temps de calcul. C'est le rôle de chunksize, qui regroupe les tâches en paquets pour amortir ce coût. Règle simple : viser des paquets d'au moins une centaine de millisecondes de travail.

Éviter les copies : mémoire partagée et joblib

from joblib import Parallel, delayed

# n_jobs=-1 : tous les cœurs. Les grands tableaux NumPy sont mémoire-mappés
# sur disque et partagés en lecture, pas copiés dans chaque worker.
scores = Parallel(n_jobs=-1, backend="loky", verbose=1)(
    delayed(evaluer_pli)(X, y, pli) for pli in plis
)

delayed est un décorateur (module 1) qui transforme un appel en description d'appel : il capture la fonction et ses arguments sans les exécuter, pour que joblib puisse les distribuer. C'est ce backend que scikit-learn utilise sous le capot pour n_jobs.

Pour un contrôle plus fin, multiprocessing.shared_memory permet d'exposer un même bloc mémoire à plusieurs processus sans copie — utile pour un grand tableau en lecture seule partagé par tous les workers.

7. asyncio, pas à pas

L'idée

asyncio ne parallélise rien : il entrelace. Tout se passe dans un seul thread, piloté par une boucle d'événements — un ordonnanceur qui tient la liste des tâches en attente. Chaque tâche s'exécute jusqu'au moment où elle doit attendre quelque chose ; à cet instant, elle le signale, la boucle la met de côté et donne la main à une autre tâche. Quand la réponse arrive, la tâche reprend là où elle s'était arrêtée.

C'est exactement le comportement du cuisinier de la section 1 : il ne va pas plus vite, mais il ne reste jamais planté devant la casserole. Le gain est le même qu'avec des threads pour de l'I/O, sans le coût d'un thread système par tâche — on tient ainsi des dizaines de milliers de connexions simultanées.

Le vocabulaire minimal

import asyncio

async def tache(nom, duree):        # "async def" → ce n'est plus une fonction ordinaire,
    print(f"{nom} démarre")         #    mais une COROUTINE
    await asyncio.sleep(duree)      # "await" → point de pause : je rends la main
    print(f"{nom} terminée")        #    la boucle en profite pour faire tourner les autres
    return nom

async def main():
    # gather : lancer plusieurs coroutines ENSEMBLE et attendre qu'elles finissent
    resultats = await asyncio.gather(
        tache("A", 2),
        tache("B", 1),
        tache("C", 3),
    )
    return resultats

asyncio.run(main())    # "asyncio.run" → démarre la boucle d'événements et attend main()

# affiche : A démarre, B démarre, C démarre, B terminée, A terminée, C terminée
# durée totale : 3 s (le maximum), et non 6 s (la somme)

Le point à retenir : appeler tache("A", 2) ne l'exécute pas, cela crée un objet coroutine. Rien ne se passe tant qu'une boucle ne le prend pas en charge, via await, gather ou create_task. C'est d'ailleurs l'origine d'un avertissement classique — coroutine was never awaited — qui signifie simplement qu'on a oublié le await.

Un exemple réaliste

import asyncio, httpx          # httpx : l'équivalent asynchrone de requests

async def recuperer(client: httpx.AsyncClient, url: str,
                    sem: asyncio.Semaphore) -> dict | None:
    async with sem:                          # au plus N requêtes EN VOL simultanément
        for essai in range(3):               # petite politique de reprise
            try:
                r = await client.get(url, timeout=10)
                r.raise_for_status()
                return r.json()
            except (httpx.TimeoutException, httpx.HTTPStatusError):
                await asyncio.sleep(2 ** essai)    # attente exponentielle : 1s, 2s, 4s
        return None

async def main(urls: list[str]) -> list[dict | None]:
    sem = asyncio.Semaphore(20)              # le garde-fou : 20 requêtes au maximum
    async with httpx.AsyncClient() as client:     # une seule session, connexions réutilisées
        taches = [recuperer(client, u, sem) for u in urls]
        return await asyncio.gather(*taches)

resultats = asyncio.run(main(urls))
print(sum(r is not None for r in resultats), "réponses valides")

Le sémaphore mérite une explication : c'est un compteur de jetons. async with sem prend un jeton, et le rend à la sortie du bloc ; s'il n'en reste plus, la tâche attend. Sans lui, gather lancerait les 500 requêtes d'un coup, ce qui saturerait le serveur distant et provoquerait des bannissements. C'est la forme asynchrone de la politesse.

valeur = await asyncio.to_thread(fonction_bloquante, argument)

Le second inconvénient est la contagion : une fonction async ne peut être appelée que depuis du code async. Introduire asyncio dans une base de code synchrone finit par colorer toute la chaîne d'appels, et exige des bibliothèques asynchrones de bout en bout (httpx, asyncpg, aiofiles). C'est la raison pour laquelle, pour deux cents requêtes ponctuelles dans un script, un ThreadPoolExecutor reste souvent le choix le plus raisonnable.

8. Le piège de la sursouscription

Une précision de vocabulaire : BLAS (Basic Linear Algebra Subprograms) désigne les bibliothèques d'algèbre linéaire compilées — OpenBLAS, MKL — sur lesquelles reposent NumPy et scikit-learn. Elles sont déjà multi-threadées, et c'est précisément ce qu'on oublie.

# à placer AVANT l'import de numpy : ces variables sont lues au chargement
export OMP_NUM_THREADS=1
export OPENBLAS_NUM_THREADS=1
export MKL_NUM_THREADS=1

# ou, plus finement, sur un bloc de code précis :
from threadpoolctl import threadpool_limits

with threadpool_limits(limits=1, user_api="blas"):
    scores = cross_val_score(modele, X, y, cv=5, n_jobs=8)

# pour vérifier ce qui tourne réellement :
from threadpoolctl import threadpool_info
print(threadpool_info())      # liste les bibliothèques natives et leur nombre de threads

La règle générale : un seul niveau de parallélisme à la fois. Soit on parallélise les plis de validation croisée et le BLAS reste mono-thread, soit on laisse le BLAS travailler et on garde n_jobs=1. Le bon réglage se mesure sur le cas réel, il ne se devine pas.

9. Récapitulatif

Type de charge                Outil                       Parallélisme réel ?
──────────────────────────────────────────────────────────────────────────────
Requêtes HTTP, base de        asyncio + httpx             oui (entrelacement)
données async, scraping
I/O avec une bibliothèque     ThreadPoolExecutor          oui (GIL relâché)
bloquante (requests, open)
Boucles Python pures,         ProcessPoolExecutor         oui (N interpréteurs)
parsing, simulation
Validation croisée,           joblib / n_jobs             oui (backend loky)
recherche d'hyperparamètres
NumPy, PyTorch, polars        ne rien ajouter             oui (BLAS, Rayon)
Boucle Python + threads       —                           NON : le GIL bloque
Données plus grosses          Dask (module 3)             oui (out-of-core)
que la RAM

Ces bibliothèques ne sont pas interchangeables : chacune répond à une contrainte précise de volume, de latence ou de type de calcul. Ce module explique ce qu'elles font réellement sous le capot — parce que c'est ce qui permet de choisir la bonne, et d'écrire du code dix à cent fois plus rapide sans rien changer à l'algorithme.

1. NumPy : pourquoi c'est rapide

Le problème d'une liste Python

Une liste Python de un million de nombres n'est pas un bloc de un million de nombres : c'est un tableau de un million de pointeurs, chacun désignant un objet float alloué ailleurs en mémoire, avec son en-tête, son compteur de références et son type. Additionner deux listes élément par élément oblige donc l'interpréteur, à chaque itération, à suivre deux pointeurs, vérifier les types, déballer les valeurs, additionner, allouer un nouvel objet résultat. Le calcul utile représente une fraction infime du travail.

Un ndarray NumPy est l'inverse : un bloc de mémoire contigu et homogène, plus une description de la façon de le lire. Les valeurs y sont stockées brutes, les unes derrière les autres, sans en-tête ni indirection. Additionner deux tableaux descend alors dans une boucle C compilée, qui traite les éléments à la chaîne en exploitant les instructions vectorielles du processeur.

import numpy as np

a = np.arange(12, dtype=np.float64).reshape(3, 4)
a.shape        # (3, 4)     la forme logique
a.dtype        # float64    le type, identique pour TOUS les éléments
a.strides      # (32, 8)    combien d'octets sauter pour avancer d'un cran…
               #            …sur l'axe 0 (une ligne = 4 × 8 octets) et sur l'axe 1
a.nbytes       # 96         la mémoire réellement occupée
a.flags        # C_CONTIGUOUS : les lignes sont contiguës en mémoire

Les strides sont la notion qui explique presque tout le comportement de NumPy. Les données sont un ruban linéaire ; la forme et les strides disent comment le parcourir. Transposer une matrice, par exemple, ne déplace aucune donnée : il suffit d'inverser les strides.

b = a.T              # transposée
b.strides            # (8, 32) — les strides sont inversés, les données inchangées
b.base is a          # True : b n'est qu'une nouvelle VUE sur la mémoire de a
np.shares_memory(a, b)   # True

np.array([200], dtype=np.int8) + 100      # array([44]) — débordement, aucun avertissement
np.array([200], dtype=np.int16) + 100     # array([300]) — correct

2. Vues et copies

C'est la source d'erreurs numéro un chez qui débute avec NumPy. Le découpage (slicing) renvoie une vue — une autre façon de lire la même mémoire — alors que l'indexation par tableau d'indices ou par masque booléen renvoie une copie.

x = np.arange(10)

v = x[2:5]          # VUE : aucune donnée copiée
v[0] = 999
x[2]                # 999  → x a été modifié sans qu'on l'ait touché

c = x[[2, 3, 4]]    # COPIE (indexation par liste d'indices)
c[0] = -1
x[2]                # 999  → x est intact

m = x[x > 5]        # COPIE (masque booléen)

np.shares_memory(x, v)   # True
np.shares_memory(x, c)   # False

Ce comportement est voulu : une vue est gratuite, alors qu'une copie d'un tableau de 4 Go coûte 4 Go. Mais il impose de savoir dans quel cas on se trouve. La règle pratique : si l'on veut modifier sans affecter l'original, écrire explicitement x[2:5].copy() ; et pour modifier en place une partie d'un tableau, utiliser l'affectation par découpage (x[x > 5] = 0), qui, elle, écrit bien dans l'original.

3. Broadcasting

Le broadcasting permet d'opérer sur des tableaux de formes différentes sans les dupliquer. Les règles tiennent en trois lignes : les formes sont alignées par la droite ; deux dimensions sont compatibles si elles sont égales ou si l'une vaut 1 ; une dimension de taille 1 est « étirée » virtuellement, en mettant simplement son stride à zéro — aucune allocation n'a lieu.

  X        (1000, 50)          X       (1000, 50)         X      (3, 1)
  mu             (50,)   ✓     poids  (1000,)      ✗      Y         (4,)   ✓
  ─────────────────────        ────────────────────       ──────────────────
  résultat (1000, 50)          ERREUR : 50 ≠ 1000         résultat (3, 4)
                               → il faut poids[:, None]        (produit externe)

X = np.random.randn(1000, 50)
mu = X.mean(axis=0)                # (50,)  une moyenne par colonne
Xc = X - mu                        # broadcasting : mu n'est PAS dupliquée 1000 fois

# centrer par LIGNE demande d'ajouter explicitement l'axe manquant
moy_ligne = X.mean(axis=1)         # (1000,)
Xc = X - moy_ligne[:, None]        # (1000,1) contre (1000,50) → compatible
# X - moy_ligne lèverait une erreur : (50,) et (1000,) ne s'alignent pas

4. Vectoriser, vraiment

Une boucle Python sur un tableau NumPy cumule les deux inconvénients : le coût de l'interpréteur et la conversion de chaque élément en objet Python. L'opération vectorisée équivalente reste entièrement dans le code natif.

x = np.random.randn(1_000_000)

# ≈ 400 ms : un million de tours d'interpréteur
out = np.array([v ** 2 + 3 * v if v > 0 else 0.0 for v in x])

# ≈ 4 ms : une seule descente dans le code compilé
out = np.where(x > 0, x ** 2 + 3 * x, 0.0)

# agrégations par axe
X.sum(axis=0)          # somme par colonne        X.mean(axis=1)   # moyenne par ligne
X.argmax(axis=1)       # indice du maximum        np.percentile(X, 95, axis=0)

# sélection et conditions
np.where(cond, a, b)   np.clip(x, 0, 1)   np.select([c1, c2], [v1, v2], defaut)

# einsum : produits et contractions, sans reshape acrobatique
np.einsum("ij,jk->ik", A, B)        # produit matriciel classique
np.einsum("ij,ij->i", A, B)         # produit scalaire ligne à ligne
np.einsum("ii->", A)                # trace

# opérations "sur place" : évitent une allocation (utile sur de gros tableaux)
np.multiply(X, 2, out=X)            # équivalent de X *= 2

# quand l'algorithme est SÉQUENTIEL et ne se vectorise pas : Numba compile la boucle
from numba import njit
@njit                                # décorateur (module 1) : compilation à la volée
def recurrence(x, alpha):
    y = np.empty_like(x)
    y[0] = x[0]
    for i in range(1, len(x)):       # boucle Python… compilée en code machine
        y[i] = alpha * x[i] + (1 - alpha) * y[i - 1]
    return y

5. pandas : le modèle et ses pièges

Le modèle

pandas ajoute à NumPy ce qui manque pour des données réelles : des colonnes de types différents, des étiquettes, et la gestion des valeurs manquantes. Deux objets à connaître : la Series (une colonne : un tableau de valeurs plus un index) et le DataFrame (un dictionnaire ordonné de Series partageant le même index).

L'index est le concept le moins intuitif. Ce n'est pas un simple numéro de ligne : c'est une étiquette, utilisée pour l'alignement automatique. Additionner deux Series ne fait pas correspondre les positions mais les étiquettes — ce qui est puissant et surprenant la première fois :

a = pd.Series([1, 2, 3], index=["x", "y", "z"])
b = pd.Series([10, 20, 30], index=["z", "y", "x"])
a + b        # x: 31, y: 22, z: 13  → aligné par étiquette, pas par position

import pandas as pd

df = (
    pd.read_parquet("data/commandes.parquet")
      .assign(                                    # créer des colonnes
          date=lambda d: pd.to_datetime(d["date"]),
          marge=lambda d: d["prix"] - d["cout"],
      )
      .query("marge > 0")                         # filtrer
      .astype({"categorie": "category"})          # mémoire ÷ 10 sur du texte répété
      .sort_values("date")
)

L'écriture chaînée n'est pas qu'une question de style : chaque étape produit un nouvel objet, ce qui évite les mutations en place et donc les états intermédiaires impossibles à reproduire dans un notebook. Les lambda permettent de référencer le DataFrame tel qu'il est à cette étape, sans variable intermédiaire.

Split-apply-combine

  DataFrame          SPLIT               APPLY              COMBINE
  cat  val      cat=A : [10, 30]      A : mean = 20      cat   val
  A    10       cat=B : [20]          B : mean = 20      A     20
  B    20       cat=C : [5, 15]       C : mean = 10      B     20
  A    30                                                 C     10
  C     5
  C    15

stats = (
    df.groupby(["categorie", pd.Grouper(key="date", freq="ME")])   # ME = fin de mois
      .agg(ca=("prix", "sum"), n=("prix", "size"), marge_moy=("marge", "mean"))
      .reset_index()
)

# transform : renvoie un résultat de MÊME TAILLE que l'entrée (comme une fonction
# de fenêtre SQL, module 4) — indispensable pour normaliser par groupe
df["ecart_a_la_moyenne"] = df["prix"] - df.groupby("categorie")["prix"].transform("mean")

6. polars : expressions et évaluation paresseuse

polars est écrit en Rust sur le format mémoire Apache Arrow. Deux différences de fond avec pandas : son moteur est multi-thread par défaut (pas de GIL à l'intérieur, module 2), et il propose un mode paresseux où la requête est d'abord construite, puis optimisée, puis exécutée — exactement comme un moteur SQL.

import polars as pl

q = (
    pl.scan_parquet("data/commandes_*.parquet")    # scan_ : rien n'est lu pour l'instant
      .filter(pl.col("date") >= pl.date(2025, 1, 1))
      .with_columns(marge=pl.col("prix") - pl.col("cout"))
      .group_by("categorie")
      .agg(
          ca=pl.col("prix").sum(),
          marge_moy=pl.col("marge").mean(),
          n=pl.len(),
      )
      .sort("ca", descending=True)
)

print(q.explain())      # le plan optimisé, comme un EXPLAIN SQL (module 4)
df = q.collect()        # ICI seulement, le calcul a lieu
df = q.collect(streaming=True)    # par morceaux, pour un volume > RAM

L'optimiseur fait deux choses décisives. La projection pushdown : seules les colonnes réellement utilisées sont lues sur le disque — sur un fichier de 50 colonnes dont on en utilise 4, le gain est immédiat. La predicate pushdown : les filtres descendent au plus près de la lecture, parfois jusqu'aux métadonnées des fichiers Parquet, qui permettent de sauter des blocs entiers sans les décompresser.

Le second apport est conceptuel : une expression (pl.col("x").sum()) est un objet réutilisable et composable, qu'on peut nommer, stocker dans une variable et appliquer ailleurs — là où pandas manipule des chaînes de caractères magiques. En pratique : facteur 5 à 20 sur les agrégations et jointures. Le coût de migration est réel (API différente, pas d'index), mais les deux cohabitent, df.to_pandas() et pl.from_pandas() étant peu coûteux grâce à Arrow.

7. Dask, Spark, Ray : passer à l'échelle

Dask découpe un grand DataFrame en partitions — chacune étant un DataFrame pandas ordinaire —, construit un graphe de tâches, puis l'exécute en parallèle sur plusieurs cœurs ou plusieurs machines, en traitant les partitions les unes après les autres (out-of-core) plutôt qu'en chargeant tout en mémoire.

import dask.dataframe as dd

ddf = dd.read_parquet("s3://bucket/annee=2025/*.parquet")   # graphe, rien n'est chargé
resultat = ddf[ddf.montant > 0].groupby("client_id").montant.sum()
out = resultat.compute()          # déclenche le calcul, renvoie une Series pandas

Le point délicat s'appelle le shuffle : toute opération qui redistribue les données entre partitions — un groupby sur une clé non triée, une jointure sur une colonne quelconque, un tri global — oblige à faire transiter les données par le réseau ou le disque. C'est là que passe l'essentiel du temps, et c'est la raison pour laquelle un pipeline distribué mal conçu est plus lent qu'un pipeline local.

• Dask — même API que pandas et NumPy : idéal pour passer d'un poste de travail à un cluster sans réécrire.
• Spark (PySpark) — l'écosystème d'entreprise, très mature, adapté aux vrais téraoctets, avec un coût opérationnel élevé.
• Ray — calcul distribué générique (entraînement, tuning, RL, servage) plutôt que DataFrames.

8. Quel outil pour quelle taille

Volume            Outil recommandé                    Remarque
──────────────────────────────────────────────────────────────────────────────
< 1 Go            pandas ou polars                    tout tient en RAM
1 – 50 Go         polars (lazy) ou DuckDB             la RAM d'une machine moderne
                                                       suffit encore largement
50 – 500 Go       polars streaming, DuckDB, Dask      une grosse machine coûte souvent
                                                       moins cher qu'un cluster mal utilisé
> 500 Go          Spark, Dask sur cluster             la complexité devient justifiée
Tableaux denses   NumPy (+ Numba)                     calcul numérique pur
GPU               PyTorch, CuPy, cuDF                 si le calcul est massivement
                                                       parallèle

9. scikit-learn : l'API qui structure tout

La vraie valeur de scikit-learn n'est pas sa collection d'algorithmes, c'est la régularité de son interface. Trois verbes, et tout objet de l'écosystème s'y conforme :

• fit(X, y) — apprend des paramètres et les stocke dans l'objet, dans des attributs suffixés par un tiret bas (mean_, coef_) ; c'est la convention qui distingue un paramètre appris d'un hyperparamètre fourni ;
• transform(X) — applique la transformation apprise ;
• predict(X) / predict_proba(X) — produit la prédiction.

La conséquence est majeure : un Pipeline qui enchaîne des étapes se comporte lui-même comme un estimateur. La validation croisée réajuste donc toute la chaîne à chaque pli, ce qui constitue la protection la plus efficace contre la fuite de données (module 12) — un StandardScaler ajusté hors du pipeline aurait appris la moyenne du jeu de validation.

from sklearn.compose import ColumnTransformer
from sklearn.ensemble import HistGradientBoostingRegressor
from sklearn.impute import SimpleImputer
from sklearn.model_selection import cross_val_score
from sklearn.pipeline import Pipeline, make_pipeline
from sklearn.preprocessing import OneHotEncoder, StandardScaler

num = ["surface", "n_pieces", "age"]
cat = ["ville", "type_bien"]

pre = ColumnTransformer([
    # chaque groupe de colonnes reçoit son propre traitement
    ("num", make_pipeline(SimpleImputer(strategy="median"), StandardScaler()), num),
    ("cat", OneHotEncoder(handle_unknown="ignore", min_frequency=20), cat),
])

modele = Pipeline([
    ("pre", pre),
    ("gbm", HistGradientBoostingRegressor(max_iter=400, learning_rate=0.05)),
])

scores = cross_val_score(modele, X, y, cv=5, scoring="neg_root_mean_squared_error")
print(f"RMSE = {-scores.mean():.3f} ± {scores.std():.3f}")

from sklearn.base import BaseEstimator, TransformerMixin

class ClipOutliers(BaseEstimator, TransformerMixin):
    """Écrête aux quantiles appris SUR LE TRAIN uniquement."""

    def __init__(self, q=0.01):
        self.q = q                        # hyperparamètre : attribut simple, même nom

    def fit(self, X, y=None):
        self.lo_ = np.quantile(X, self.q, axis=0)      # paramètres APPRIS : tiret bas
        self.hi_ = np.quantile(X, 1 - self.q, axis=0)
        return self                       # fit renvoie toujours self

    def transform(self, X):
        return np.clip(X, self.lo_, self.hi_)

En respectant ces conventions, l'objet s'intègre partout : pipelines, recherche d'hyperparamètres, sérialisation. TransformerMixin fournit gratuitement fit_transform, et BaseEstimator fournit get_params/set_params, indispensables aux recherches sur grille.

10. PyTorch et la différentiation automatique

Un framework de deep learning apporte trois choses : des tenseurs qui vivent sur GPU, la différentiation automatique, et une bibliothèque de couches et d'optimiseurs. Un tenseur ressemble à un ndarray, avec deux attributs en plus : un device (processeur ou GPU) et la capacité d'enregistrer les opérations qu'il subit.

La différentiation automatique est le cœur du système. Pendant le calcul, PyTorch construit un graphe des opérations effectuées ; backward() le remonte en appliquant la règle de dérivation des fonctions composées, et dépose le gradient dans l'attribut .grad de chaque tenseur concerné. On n'écrit donc jamais de dérivée à la main (module 8).

import torch

x = torch.tensor([3.0], requires_grad=True)   # "je veux le gradient par rapport à x"
y = x ** 2 + 5 * x                            # PyTorch enregistre : carré, produit, somme

y.backward()                                  # remonte le graphe
print(x.grad)                                 # tensor([11.]) = 2x + 5 en x = 3  ✓

import torch, torch.nn as nn

device = "cuda" if torch.cuda.is_available() else "cpu"

modele = nn.Sequential(                       # un perceptron multicouche (module 16)
    nn.Linear(10, 64), nn.ReLU(),
    nn.Linear(64, 1),
).to(device)

perte_fn = nn.MSELoss()
opt = torch.optim.AdamW(modele.parameters(), lr=1e-3)

for epoque in range(100):
    for xb, yb in chargeur:                   # mini-lots (module 8)
        xb, yb = xb.to(device), yb.to(device)

        opt.zero_grad(set_to_none=True)       # 1. REMETTRE LES GRADIENTS À ZÉRO
        pred = modele(xb)                     # 2. passe avant
        perte = perte_fn(pred, yb)            # 3. calcul de la perte
        perte.backward()                      # 4. passe arrière : remplit les .grad
        opt.step()                            # 5. mise à jour des poids

    modele.eval()                             # bascule en mode évaluation (dropout off)
    with torch.no_grad():                     # pas de graphe : plus rapide, moins de mémoire
        val = sum(perte_fn(modele(x.to(device)), y.to(device)) for x, y in val_loader)
    modele.train()

PyTorch        impératif, déboguable au pdb, domine la recherche. Le défaut aujourd'hui.
               torch.compile compile le graphe à la volée : confort ET performance.
TensorFlow     encore présent en production, écosystème mobile mûr (TFLite). À apprendre
               si l'existant de l'équipe l'impose.
JAX            fonctions pures et transformations composables (grad, vmap, jit).
               Très utilisé en recherche scientifique et en calcul différentiable.
BoTorch        construit sur PyTorch, pour l'optimisation bayésienne (module 19) :
               optimiser un système dont chaque évaluation coûte cher.

Les données d'un projet ne vivent pas éternellement dans des fichiers CSV posés sur un disque. Dès qu'elles sont mises à jour, partagées, ou dépassent quelques gigaoctets, il faut une base de données. Ce module part du modèle relationnel — ce qu'est une table, une clé, une jointure — puis va jusqu'aux fonctions de fenêtre et aux plans d'exécution, avant d'expliquer ce que les familles NoSQL apportent et ce qu'elles abandonnent en échange.

1. Pourquoi une base de données

Un fichier CSV convient parfaitement à un jeu de données figé qu'une seule personne analyse. Il cesse de convenir dès que l'une de ces situations apparaît :

• Plusieurs écrivains — deux scripts qui écrivent en même temps corrompent le fichier. Une base gère les accès concurrents.
• Mises à jour partielles — modifier une ligne au milieu d'un CSV de 10 Go impose de le réécrire entièrement.
• Recherche sélective — trouver les commandes d'un client demande de lire tout le fichier ; une base indexée y accède directement.
• Cohérence — rien n'empêche un CSV de contenir deux fois le même identifiant, ou une référence vers un client qui n'existe pas. Une base peut le garantir.
• Reprise après incident — si le programme meurt au milieu d'une écriture, une base revient à un état cohérent ; un fichier reste à moitié écrit.

SQL est par ailleurs un langage déclaratif : on décrit le résultat voulu, et le moteur choisit l'algorithme — parcours complet ou index, ordre des jointures, méthode de tri. C'est un renversement par rapport à Python, où l'on décrit la marche à suivre, et cela demande un temps d'adaptation : optimiser une requête SQL consiste à donner au moteur les moyens de bien choisir, pas à lui dicter ses étapes.

2. Le modèle relationnel

Une table est un tableau : des colonnes typées, des lignes. Chaque table a une clé primaire, une colonne (ou un groupe) qui identifie chaque ligne de façon unique. Une clé étrangère est une colonne qui pointe vers la clé primaire d'une autre table : c'est ce qui relie les tables entre elles.

CREATE TABLE clients (
    client_id    INTEGER PRIMARY KEY,          -- identifiant unique
    nom          TEXT NOT NULL,                -- valeur obligatoire
    email        TEXT UNIQUE,                  -- pas deux fois le même
    ville        TEXT,
    cree_le      TIMESTAMP DEFAULT now()
);

CREATE TABLE commandes (
    commande_id  INTEGER PRIMARY KEY,
    client_id    INTEGER NOT NULL REFERENCES clients(client_id),   -- clé étrangère
    date_cmd     DATE NOT NULL,
    montant      NUMERIC(10, 2) CHECK (montant >= 0)               -- contrainte métier
);

CREATE INDEX idx_cmd_client ON commandes(client_id);               -- voir section 8

Deux garanties sont posées ici et méritent d'être soulignées. La clé étrangère interdit d'insérer une commande pour un client inexistant, et empêche de supprimer un client qui a des commandes : c'est l'intégrité référentielle, impossible à obtenir avec des fichiers. La contrainte CHECK refuse un montant négatif au niveau de la base, donc quel que soit le programme qui écrit — bien plus robuste qu'une validation dans un seul script.

La normalisation consiste à ne stocker chaque information qu'à un seul endroit. Si la ville du client était recopiée dans chaque commande, un déménagement obligerait à mettre à jour des milliers de lignes, avec la certitude d'en oublier. La règle pratique : une information qui décrit un client vit dans clients, une information qui décrit une commande vit dans commandes. En analytique, on dénormalise parfois volontairement — on recopie pour éviter des jointures coûteuses — mais c'est une optimisation consciente, pas un point de départ.

3. Les bases de SQL

SELECT   ville, montant                 -- 5. colonnes renvoyées
FROM     commandes                      -- 1. table de départ
JOIN     clients USING (client_id)      -- 2. tables associées
WHERE    date_cmd >= DATE '2025-01-01'  -- 3. filtre sur les LIGNES
ORDER BY montant DESC                   -- 6. tri
LIMIT    10;                            -- 7. nombre de lignes renvoyées

L'ordre d'écriture n'est pas l'ordre d'exécution : le moteur commence par FROM et WHERE, agrège ensuite, et n'applique SELECT puis ORDER BY qu'à la fin. C'est ce qui explique une erreur fréquente — on ne peut pas utiliser dans WHERE un alias défini dans SELECT, puisqu'il n'existe pas encore à ce moment-là.

WHERE montant BETWEEN 100 AND 500          -- bornes incluses
WHERE ville IN ('Grenoble', 'Lyon')        -- appartenance à une liste
WHERE email LIKE '%@exemple.fr'            -- motif ; % = n'importe quelle suite
WHERE email ILIKE '%@Exemple.FR'           -- idem, insensible à la casse (PostgreSQL)
WHERE ville IS NULL                        -- valeur absente : voir section 7
WHERE date_cmd >= now() - INTERVAL '30 days'

-- expressions conditionnelles et conversions
SELECT CASE WHEN montant > 1000 THEN 'grand'
            WHEN montant > 100  THEN 'moyen'
            ELSE 'petit' END AS segment,
       CAST(montant AS INTEGER)  AS montant_entier,
       COALESCE(ville, 'inconnue') AS ville     -- remplace NULL par une valeur
FROM commandes;

4. Jointures

Une jointure associe les lignes de deux tables selon une condition — presque toujours l'égalité d'une clé étrangère et d'une clé primaire. Quatre variantes couvrent tous les cas :

clients            commandes
id | nom           client_id | montant
1  | Alice         1         | 100
2  | Bob           1         | 250
3  | Chloé         4         | 80        ← client 4 : inexistant dans clients

INNER JOIN  → uniquement les correspondances des DEUX côtés
   Alice|100, Alice|250                        (Bob et Chloé disparaissent)

LEFT JOIN   → toutes les lignes de GAUCHE, complétées par NULL à droite
   Alice|100, Alice|250, Bob|NULL, Chloé|NULL  (utile : "qui n'a rien commandé ?")

FULL OUTER JOIN → l'union des deux, avec NULL des deux côtés
   Alice|100, Alice|250, Bob|NULL, Chloé|NULL, NULL|80

CROSS JOIN  → le produit cartésien : chaque ligne avec chaque ligne
   3 × 3 = 9 lignes   (presque toujours le signe d'une condition oubliée)

-- les clients sans aucune commande
SELECT c.nom
FROM clients c
LEFT JOIN commandes o ON o.client_id = c.client_id
WHERE o.commande_id IS NULL;            -- aucune ligne appariée à droite

-- même résultat, souvent plus lisible et aussi efficace
SELECT nom FROM clients c
WHERE NOT EXISTS (SELECT 1 FROM commandes o WHERE o.client_id = c.client_id);

5. Agrégations et fonctions de fenêtre

Un GROUP BY écrase les lignes : une ligne par groupe. C'est ce qu'on veut pour un total par client, pas pour comparer chaque commande à la moyenne de son client.

SELECT client_id,
       COUNT(*)        AS n_commandes,
       SUM(montant)    AS ca_total,
       AVG(montant)    AS panier_moyen,
       MAX(date_cmd)   AS derniere_commande
FROM commandes
WHERE date_cmd >= DATE '2025-01-01'     -- filtre AVANT agrégation (sur les lignes)
GROUP BY client_id
HAVING SUM(montant) > 1000              -- filtre APRÈS agrégation (sur les groupes)
ORDER BY ca_total DESC;

Une fonction de fenêtre calcule une agrégation sans écraser : chaque ligne conserve son identité tout en « voyant » son groupe. C'est l'outil décisif pour le feature engineering temporel (module 12), car il permet de calculer moyennes mobiles, rangs et décalages directement dans la base, sur des volumes qui ne tiendraient pas en mémoire.

SELECT
    client_id,
    date_cmd,
    montant,

    -- rang de la commande dans l'historique du client
    ROW_NUMBER() OVER (PARTITION BY client_id ORDER BY date_cmd) AS n_commande,
    --           └─ OVER : "voici la fenêtre"
    --              └─ PARTITION BY : découpe en groupes (comme GROUP BY, sans écraser)
    --                 └─ ORDER BY : ordre À L'INTÉRIEUR de la fenêtre

    -- montant de la commande précédente du même client : feature de récence
    LAG(montant) OVER (PARTITION BY client_id ORDER BY date_cmd) AS montant_precedent,

    -- écart en jours depuis la commande précédente
    date_cmd - LAG(date_cmd) OVER (PARTITION BY client_id ORDER BY date_cmd) AS delai,

    -- moyenne glissante sur les 3 dernières commandes, celle-ci incluse
    AVG(montant) OVER (
        PARTITION BY client_id ORDER BY date_cmd
        ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
    ) AS moyenne_3,

    -- part de cette commande dans le total du client
    montant / SUM(montant) OVER (PARTITION BY client_id) AS part
FROM commandes;

La clause ROWS BETWEEN … AND CURRENT ROW n'est pas cosmétique : elle garantit qu'aucune information future n'entre dans la feature. C'est la version SQL de la protection contre la fuite temporelle (module 12) — sans elle, la fenêtre par défaut inclurait toutes les lignes du groupe, y compris celles qui viennent après.

ROW_NUMBER()    numérote 1, 2, 3… sans ex æquo
RANK()          ex æquo au même rang, puis saut (1, 2, 2, 4)
DENSE_RANK()    ex æquo au même rang, sans saut (1, 2, 2, 3)
LAG(x, n)       valeur n lignes avant (défaut n=1)
LEAD(x, n)      valeur n lignes après  → à n'utiliser qu'en analyse, jamais en feature
FIRST_VALUE(x)  première valeur de la fenêtre
NTILE(4)        découpe en 4 groupes de taille égale (quartiles)
SUM/AVG/COUNT   les agrégats classiques, en version fenêtrée

6. CTE : structurer une requête

Une Common Table Expression (WITH) nomme une étape intermédiaire. Une requête de 80 lignes avec quatre sous-requêtes imbriquées devient quatre blocs lisibles, testables séparément — il suffit de remplacer la requête finale par un SELECT * FROM etape_2 pour inspecter un résultat intermédiaire.

WITH commandes_2025 AS (
    SELECT * FROM commandes WHERE date_cmd >= DATE '2025-01-01'
),
agregats_client AS (
    SELECT client_id,
           COUNT(*)           AS n_commandes,
           SUM(montant)       AS ca_total,
           MAX(date_cmd)      AS derniere_commande
    FROM commandes_2025
    GROUP BY client_id
),
segments AS (
    SELECT *,
           NTILE(4) OVER (ORDER BY ca_total) AS quartile_ca
    FROM agregats_client
)
SELECT c.nom, s.n_commandes, s.ca_total, s.quartile_ca,
       CURRENT_DATE - s.derniere_commande AS jours_depuis_achat
FROM segments s
JOIN clients c USING (client_id)
ORDER BY s.ca_total DESC;

7. Le piège des NULL

NULL ne signifie ni « zéro », ni « chaîne vide » : il signifie inconnu. Et toute comparaison avec un inconnu donne un inconnu, traité comme faux.

WHERE montant != 100        -- EXCLUT les lignes où montant est NULL (rarement voulu)
WHERE montant = NULL        -- ne renvoie JAMAIS rien : il faut IS NULL

SELECT COUNT(*),            -- compte TOUTES les lignes
       COUNT(montant),      -- compte seulement les montants NON NULL
       AVG(montant),        -- moyenne des NON NULL
       SUM(montant) / COUNT(*)   -- ≠ AVG(montant) s'il y a des NULL !
FROM commandes;

-- NULL se propage dans les calculs
SELECT 100 + NULL;          -- NULL, pas 100
SELECT COALESCE(montant, 0) + 100;   -- la bonne façon : remplacer d'abord

-- après un LEFT JOIN, les colonnes de droite peuvent être NULL : penser à COALESCE
SELECT c.nom, COALESCE(SUM(o.montant), 0) AS ca
FROM clients c LEFT JOIN commandes o USING (client_id)
GROUP BY c.nom;

8. Index et plans d'exécution

Sans index, répondre à WHERE client_id = 42 oblige le moteur à lire toute la table, ligne par ligne. Un index est une structure annexe — le plus souvent un arbre équilibré, un B-tree — qui range les valeurs d'une colonne dans un ordre permettant la recherche dichotomique : on passe d'un coût proportionnel au nombre de lignes à un coût proportionnel à son logarithme. Sur dix millions de lignes, c'est la différence entre lire dix millions d'enregistrements et en lire vingt-trois.

L'index n'est pas gratuit : il occupe de l'espace disque et ralentit les écritures, puisque chaque insertion doit le mettre à jour. On indexe donc les colonnes de jointure, celles des filtres sélectifs et celles des tris fréquents — pas toutes les colonnes.

EXPLAIN ANALYZE
SELECT * FROM commandes WHERE client_id = 42;

-- AVANT l'index :
-- Seq Scan on commandes  (cost=0.00..18334.00 rows=1 width=44) (actual time=42.1 ms)
--   → "Seq Scan" = parcours complet : 18 000 pages lues pour trouver 1 ligne

CREATE INDEX idx_cmd_client ON commandes(client_id);

-- APRÈS :
-- Index Scan using idx_cmd_client  (cost=0.42..8.44 rows=1) (actual time=0.03 ms)
--   → mille fois plus rapide

Deux notions complémentaires : un index composite (client_id, date_cmd) sert les filtres sur client_id seul ou sur les deux, mais pas sur date_cmd seul — l'ordre des colonnes compte, comme dans un annuaire trié par nom puis prénom. Et ANALYZE met à jour les statistiques que le planificateur utilise pour choisir : sur une table qui vient d'être massivement chargée, des statistiques périmées produisent des plans catastrophiques.

9. Transactions et ACID

Une transaction regroupe plusieurs opérations en une unité indivisible : soit tout réussit, soit rien ne s'applique. L'exemple canonique est un virement — débiter un compte et créditer l'autre — où s'arrêter au milieu serait catastrophique. En data science, le cas courant est l'ingestion : charger dix mille lignes et mettre à jour la table de suivi doit être tout ou rien, sinon on ne sait plus ce qui a été chargé.

BEGIN;                                        -- début de la transaction
  INSERT INTO annonces SELECT * FROM import_temporaire;
  UPDATE suivi_ingestion SET derniere_date = CURRENT_DATE;
COMMIT;                                       -- tout est appliqué d'un coup
-- en cas de problème : ROLLBACK;             -- rien n'a eu lieu

Les quatre garanties résumées par l'acronyme ACID : Atomicité (tout ou rien), Cohérence (les contraintes restent respectées), Isolation (une transaction en cours n'est pas perturbée par les autres), Durabilité (une fois validée, elle survit à une coupure de courant). Ce sont ces garanties que l'on perd en travaillant avec des fichiers — et, en partie, avec certaines bases NoSQL (section 11).

10. OLTP, OLAP et DuckDB

                 OLTP (transactionnel)        OLAP (analytique)
Exemples         PostgreSQL, MySQL, SQLite    DuckDB, ClickHouse, BigQuery, Snowflake
Requêtes         nombreuses, très courtes     peu nombreuses, très lourdes
Accès typique    quelques lignes entières     2 colonnes sur 50, des millions de lignes
Stockage         par LIGNES                   par COLONNES
Optimisé pour    écriture, cohérence, ACID    lecture, compression, agrégation
Rôle en data     la source de vérité          l'analyse et l'entraînement

Le stockage en colonnes explique l'essentiel. Dans un stockage par lignes, les valeurs d'une même ligne sont contiguës sur le disque : parfait pour lire ou écrire un enregistrement complet. Dans un stockage par colonnes, ce sont les valeurs d'une même colonne qui sont contiguës : un SELECT AVG(montant) ne lit alors que cette colonne, en ignorant les 49 autres. S'ajoute un effet de compression considérable, puisque des valeurs voisines d'une même colonne se ressemblent (mêmes catégories répétées, dates proches, ordres de grandeur similaires).

DuckDB est l'outil à connaître pour un usage local : pas de serveur à installer, un simple fichier (ou même rien du tout, en mémoire), et il interroge directement des fichiers Parquet ou des DataFrames.

import duckdb

# SQL directement sur des fichiers Parquet, sans import préalable
df = duckdb.sql("""
    SELECT client_id, SUM(montant) AS ca
    FROM 'data/commandes_*.parquet'          -- le joker lit tous les fichiers
    WHERE date_cmd >= '2025-01-01'
    GROUP BY client_id
    ORDER BY ca DESC
    LIMIT 10
""").df()                                    # renvoie un DataFrame pandas

# on peut aussi interroger un DataFrame existant comme une table
con = duckdb.connect("analyse.duckdb")       # base persistante dans un fichier
con.execute("CREATE TABLE annonces AS SELECT * FROM df_polars")
con.execute("COPY annonces TO 'export.parquet' (FORMAT PARQUET)")

11. NoSQL et bases vectorielles

NoSQL ne veut pas dire « sans SQL » mais « pas seulement relationnel ». Chaque famille abandonne quelque chose — le plus souvent les jointures et la cohérence forte — pour gagner autre chose : du débit, de la souplesse de schéma, de la distribution.

Clé-valeur    Redis, DynamoDB     accès O(1) par clé. Cache, sessions, features
                                  servies en ligne. Aucune requête complexe.
Document      MongoDB, Firestore  documents JSON imbriqués, schéma souple. Pratique
                                  quand la structure varie d'un enregistrement
                                  à l'autre ; jointures pauvres.
Colonnes      Cassandra, HBase    écriture massive distribuée, séries temporelles,
                                  télémétrie. Modélisation dictée par les requêtes.
Graphe        Neo4j               les relations sont l'objet premier : détection de
                                  fraude, réseaux, recommandation (module 18).

Le cadre théorique est le théorème CAP : dans un système distribué, une partition réseau finit toujours par se produire (des machines ne se voient plus). Il faut alors choisir entre la cohérence — refuser de répondre plutôt que renvoyer une donnée potentiellement périmée — et la disponibilité — répondre quand même, quitte à être en retard. PostgreSQL privilégie la première, Cassandra la seconde avec une cohérence « à terme ».

Une base vectorielle indexe des embeddings — des vecteurs de quelques centaines de dimensions représentant un texte ou une image — et répond à « quels sont les k vecteurs les plus proches de celui-ci ? ». Les options : pgvector (extension PostgreSQL, à privilégier tant qu'une seule base suffit), FAISS (bibliothèque locale), Qdrant ou Milvus (services dédiés). Le fonctionnement des index approchés et le pipeline RAG complet sont traités au module 22.

12. Interroger une base depuis Python

# 1. SQLite : inclus dans Python, zéro installation, un seul fichier
import sqlite3
with sqlite3.connect("projet.db") as con:
    con.execute("CREATE TABLE IF NOT EXISTS annonces (id INTEGER PRIMARY KEY, prix REAL)")
    con.executemany("INSERT INTO annonces VALUES (?, ?)", lignes)   # insertion par lot
    for ligne in con.execute("SELECT * FROM annonces WHERE prix > ?", (200_000,)):
        print(ligne)

# 2. SQLAlchemy : une interface unique pour PostgreSQL, MySQL, SQLite…
from sqlalchemy import create_engine, text
moteur = create_engine("postgresql+psycopg://user:motdepasse@localhost:5432/ma_base")
with moteur.begin() as con:                      # begin() = transaction automatique
    con.execute(text("UPDATE annonces SET prix = prix * 1.02 WHERE ville = :v"),
                {"v": "Grenoble"})

# 3. Charger directement dans un DataFrame
import polars as pl, pandas as pd
df = pl.read_database_uri("SELECT * FROM annonces", uri="postgresql://…")
df = pd.read_sql("SELECT * FROM annonces WHERE ville = %(v)s", moteur, params={"v": "Lyon"})

Ce module a montré comment interroger des données déjà en place. Le module 7 traite la question d'avant : comment elles y arrivent, sous quel format les stocker, comment organiser un entrepôt pour l'analyse, et comment faire tourner tout cela chaque nuit sans créer de doublons.

« Ça marche chez moi. » Ce module traite l'outil qui a rendu cette phrase obsolète : le conteneur. On part de ce qu'est réellement un conteneur — et de ce qui le distingue d'une machine virtuelle —, puis on construit une image pour un projet Python, on orchestre une pile complète avec Docker Compose, et on termine par ce qu'il faut savoir de Kubernetes pour lire un manifeste et comprendre ce que fait une équipe plateforme.

1. Le problème que Docker résout

Un projet Python ne dépend pas que de Python. Il dépend d'une version de l'interpréteur, de bibliothèques compilées (BLAS, libpq, ffmpeg), de paquets système, de variables d'environnement, parfois d'un pilote GPU et d'une version de CUDA. Un environnement virtuel (module 1) fige les bibliothèques Python ; il ne fige rien de tout le reste. C'est pourquoi le même code fonctionne sur un portable et échoue sur le serveur.

Un conteneur emporte tout ce dont l'application a besoin — code, dépendances Python, bibliothèques système, fichiers de configuration — dans une unité qui s'exécute à l'identique partout où tourne un moteur de conteneurs. Le bénéfice ne se limite pas au déploiement : il rend un résultat reproductible dans six mois, ce qui est exactement ce qu'on cherche en data science (module 26).

2. Conteneur ou machine virtuelle ?

Les deux isolent une application, mais à des niveaux très différents.

        MACHINE VIRTUELLE                       CONTENEUR
  ┌───────────────────────────┐        ┌───────────────────────────┐
  │  App A    │    App B      │        │  App A    │    App B      │
  ├───────────┼───────────────┤        ├───────────┼───────────────┤
  │ Biblioth. │  Biblioth.    │        │ Biblioth. │  Biblioth.    │
  ├───────────┼───────────────┤        ├───────────┴───────────────┤
  │ Noyau OS  │  Noyau OS     │ ←──┐   │   moteur de conteneurs    │
  │  invité   │   invité      │    │   ├───────────────────────────┤
  ├───────────┴───────────────┤    │   │   NOYAU OS DE L'HÔTE      │ ← partagé
  │        Hyperviseur        │    │   ├───────────────────────────┤
  ├───────────────────────────┤    │   │        Matériel           │
  │      Noyau OS hôte        │    │   └───────────────────────────┘
  ├───────────────────────────┤    │
  │        Matériel           │    └── chaque VM embarque un système
  └───────────────────────────┘        d'exploitation complet

Une machine virtuelle simule un ordinateur entier : l'hyperviseur lui présente un processeur, de la mémoire et des disques virtuels, sur lesquels on installe un système d'exploitation complet avec son propre noyau. Isolation très forte, mais coût élevé — plusieurs gigaoctets sur disque, plusieurs centaines de mégaoctets de RAM, des dizaines de secondes de démarrage.

Un conteneur ne simule rien. C'est un processus ordinaire du système hôte, à qui le noyau ment sur ce qu'il voit :

• les namespaces cloisonnent sa vision — il ne voit que ses propres processus, sa propre arborescence de fichiers, ses propres interfaces réseau ;
• les cgroups (control groups) limitent ce qu'il consomme — tant de CPU, tant de mémoire.

Puisqu'il n'y a pas de noyau invité, le coût est celui d'un processus : quelques mégaoctets, un démarrage en quelques dizaines de millisecondes. L'analogie la plus juste : une VM est une maison individuelle avec ses propres fondations ; un conteneur est un appartement dans un immeuble — murs séparés, mais fondations et structure partagées.

3. Image, conteneur, couche, registre

• Une image est un modèle figé, en lecture seule : un système de fichiers complet plus des métadonnées (commande à lancer, variables d'environnement, port exposé). C'est l'équivalent d'une classe.
• Un conteneur est une instance en cours d'exécution de cette image, avec une fine couche inscriptible par-dessus. C'est l'équivalent d'un objet. On peut lancer vingt conteneurs à partir de la même image.
• Une couche (layer) est une strate de l'image, produite par une instruction du Dockerfile. Les couches sont empilées, partagées entre images et mises en cache individuellement — c'est ce qui rend les reconstructions rapides et les téléchargements légers.
• Un registre est un entrepôt d'images : Docker Hub (public), GitHub Container Registry, ou un registre privé d'entreprise.

4. Les commandes du quotidien

# lancer un conteneur (télécharge l'image si nécessaire)
docker run hello-world

# interactif : un shell dans un conteneur Python jetable
docker run -it --rm python:3.12-slim bash
#          │   └─ --rm : supprime le conteneur à la sortie (sinon il s'accumule)
#          └─ -it : mode interactif avec terminal

# en arrière-plan, avec un nom et une redirection de port
docker run -d --name mon-api -p 8000:8000 mon-image:1.0
#          │              └─ port 8000 de la MACHINE → port 8000 du CONTENEUR
#          └─ -d : detached, rend la main immédiatement

# voir ce qui tourne
docker ps                    # conteneurs en cours
docker ps -a                 # y compris ceux qui sont arrêtés
docker stats                 # consommation CPU / mémoire en direct

# lire les journaux
docker logs mon-api          # tout depuis le début
docker logs -f --tail 50 mon-api    # suivre en direct les 50 dernières lignes

# entrer dans un conteneur qui tourne (LE réflexe de débogage)
docker exec -it mon-api bash
docker exec mon-api python -c "import torch; print(torch.cuda.is_available())"

# inspecter en détail (configuration, réseaux, montages)
docker inspect mon-api
docker port mon-api          # quelles redirections de ports sont actives

# construire une image à partir du Dockerfile du répertoire courant
docker build -t mon-api:1.0 .
docker build -t mon-api:1.0 --build-arg VERSION=1.0 -f docker/Dockerfile .

# lister, étiqueter, publier
docker images
docker tag mon-api:1.0 ghcr.io/nils/mon-api:1.0
docker login ghcr.io && docker push ghcr.io/nils/mon-api:1.0
docker pull postgres:16

# arrêter et supprimer
docker stop mon-api && docker rm mon-api
docker rmi mon-api:1.0

# faire de la place (Docker consomme beaucoup de disque avec le temps)
docker system df             # ce qui occupe l'espace
docker container prune       # conteneurs arrêtés
docker image prune -a        # images non utilisées
docker system prune -a --volumes    # grand nettoyage — supprime aussi les VOLUMES

5. Écrire un Dockerfile

Un Dockerfile est une recette : chaque instruction produit une couche. Voici les instructions à connaître, avant l'exemple complet.

FROM python:3.12-slim      image de départ ("slim" = sans les outils de compilation)
WORKDIR /app               répertoire de travail ; le crée si besoin
COPY source destination    copie depuis la machine vers l'image
RUN commande               exécute PENDANT LA CONSTRUCTION (installer des paquets…)
ENV CLE=valeur             variable d'environnement, présente à l'exécution
ARG CLE=valeur             variable disponible seulement pendant la construction
EXPOSE 8000                documentation du port utilisé (ne publie rien par lui-même)
USER app                   change d'utilisateur : ne pas rester root
HEALTHCHECK …              commande que Docker lance pour vérifier la santé
CMD ["uvicorn", "…"]       commande lancée AU DÉMARRAGE du conteneur
ENTRYPOINT ["python"]      exécutable fixe ; CMD fournit alors ses arguments

# ════════ étape 1 : construire l'environnement ════════
FROM python:3.12-slim AS builder

# on récupère le binaire uv depuis son image officielle
COPY --from=ghcr.io/astral-sh/uv:latest /uv /bin/uv

WORKDIR /app
ENV UV_COMPILE_BYTECODE=1 \
    UV_LINK_MODE=copy

# ── couche STABLE : les dépendances ──
COPY pyproject.toml uv.lock ./
RUN uv sync --frozen --no-install-project --no-dev
#   --frozen : interdit de modifier le lock (échoue si désynchronisé)
#   --no-dev : pas de pytest/ruff dans l'image de production

# ── couche VOLATILE : le code ──
COPY src/ src/
RUN uv sync --frozen --no-dev

# ════════ étape 2 : image finale, sans outils de build ════════
FROM python:3.12-slim

WORKDIR /app
# on ne recopie que le résultat : l'environnement et le code
COPY --from=builder /app/.venv /app/.venv
COPY --from=builder /app/src /app/src
ENV PATH="/app/.venv/bin:$PATH"

# un utilisateur non privilégié : si l'application est compromise,
# l'attaquant n'est pas root dans le conteneur
RUN useradd --create-home app && chown -R app /app
USER app

EXPOSE 8000
HEALTHCHECK --interval=30s --timeout=5s --start-period=20s \
  CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"

CMD ["uvicorn", "mon_projet.api:app", "--host", "0.0.0.0", "--port", "8000"]

La construction en deux étapes (multi-stage) est le point clé : compilateurs, caches et fichiers intermédiaires restent dans l'étape jetable, et seul le résultat utile est recopié dans l'image finale. On passe typiquement de 1,2 Go à 200 Mo — ce qui accélère les déploiements et réduit la surface d'attaque.

Deux détails qui comptent : --host 0.0.0.0 est obligatoire, car écouter sur 127.0.0.1 depuis un conteneur signifie « uniquement depuis l'intérieur du conteneur », et la redirection de port ne verrait rien. Et le fichier .dockerignore est indispensable :

.git
.venv
data/
notebooks/
models/
__pycache__/
*.parquet
*.csv
.pytest_cache
.ruff_cache

Sans lui, la commande docker build envoie l'intégralité du répertoire au démon Docker avant même de commencer — y compris les 10 Go de données et l'historique Git.

6. Volumes : faire survivre les données

Un conteneur est éphémère : tout ce qu'il écrit dans son système de fichiers disparaît quand on le supprime. C'est voulu — un conteneur doit être jetable et remplaçable — mais il faut donc un mécanisme pour les données qui doivent survivre. Deux formes de montage :

# VOLUME NOMMÉ : géré par Docker, stocké dans son espace. Pour les DONNÉES.
docker volume create donnees-pg
docker run -d --name pg -v donnees-pg:/var/lib/postgresql/data postgres:16
#                       └─ le volume survit à la suppression du conteneur

docker volume ls
docker volume inspect donnees-pg
docker volume rm donnees-pg          # là seulement, les données disparaissent

# BIND MOUNT : un dossier de la MACHINE est monté dans le conteneur.
# Pour le DÉVELOPPEMENT : le code modifié est visible immédiatement.
docker run -it --rm -v "$(pwd)":/app -w /app python:3.12-slim python script.py

# montage en lecture seule : un jeu de données que le conteneur ne doit pas modifier
docker run -v /data/brut:/data:ro mon-image

La distinction pratique : volume nommé pour ce que produit l'application (base de données, modèles entraînés, fichiers téléversés) ; bind mount pour ce qui vient de la machine (code source en développement, données brutes en lecture seule). Et attention aux permissions : un fichier créé par le conteneur appartient à l'utilisateur du conteneur, ce qui peut donner des fichiers root sur la machine hôte.

7. Réseaux et variables d'environnement

Chaque conteneur reçoit sa propre interface réseau. Trois choses à savoir :

# créer un réseau : les conteneurs qui y sont attachés se voient PAR LEUR NOM
docker network create app-net

docker run -d --name base --network app-net postgres:16
docker run -d --name api  --network app-net -p 8000:8000 mon-api:1.0
# depuis "api", la base est joignable à l'adresse "base:5432" — Docker fournit
# une résolution DNS interne, il n'y a aucune adresse IP à connaître

# publier un port vers l'extérieur : -p HOTE:CONTENEUR
docker run -p 8080:8000 mon-api     # http://localhost:8080 → port 8000 du conteneur
docker run -p 127.0.0.1:8000:8000 mon-api   # accessible uniquement en local

docker network ls
docker network inspect app-net

Sans réseau explicite, les conteneurs sont sur le réseau bridge par défaut, où la résolution par nom ne fonctionne pas : c'est la cause la plus fréquente des « connection refused » entre deux conteneurs.

docker run -e DATABASE_URL="postgresql://user:pass@base:5432/db" mon-api
docker run --env-file .env mon-api         # toutes les variables d'un fichier

# GPU (nécessite le NVIDIA Container Toolkit sur l'hôte)
docker run --gpus all nvidia/cuda:12.4.0-base nvidia-smi

8. Docker Compose

À quoi ça sert

Une application réelle n'est jamais un seul conteneur : une API, une base de données, un cache, parfois un serveur de tâches de fond. Les lancer à la main impose de retenir l'ordre de démarrage, de créer le réseau, de nommer les volumes, de recopier les bonnes variables d'environnement — une longue série de commandes fragiles, à refaire à chaque redémarrage.

Docker Compose décrit toute cette pile dans un fichier unique, versionné avec le code. Une commande démarre l'ensemble, une autre l'arrête. C'est l'outil qui permet à quelqu'un de cloner un dépôt et d'avoir l'application complète qui tourne en une minute — y compris la base de données, avec le bon schéma.

services:

  api:
    build: .                        # construire depuis le Dockerfile local
    # image: ghcr.io/nils/mon-api:1.0   ← en production, on utilise une image publiée
    ports:
      - "8000:8000"                 # exposé sur la machine
    environment:
      DATABASE_URL: postgresql://app:${POSTGRES_PASSWORD}@base:5432/annonces
      REDIS_URL: redis://cache:6379/0
      LOG_LEVEL: info
    depends_on:
      base:
        condition: service_healthy  # attend que la base réponde VRAIMENT
      cache:
        condition: service_started
    volumes:
      - ./src:/app/src              # bind mount : rechargement à chaud en dev
    restart: unless-stopped         # redémarre en cas de crash, sauf arrêt manuel

  base:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}   # lu dans le fichier .env
      POSTGRES_DB: annonces
    volumes:
      - donnees-pg:/var/lib/postgresql/data     # LES DONNÉES SURVIVENT ICI
      - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql:ro   # schéma au 1er démarrage
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d annonces"]
      interval: 5s
      timeout: 3s
      retries: 10
    # pas de "ports:" → la base n'est PAS exposée à l'extérieur, seulement à l'api

  cache:
    image: redis:7-alpine
    command: redis-server --save 60 1 --loglevel warning

volumes:
  donnees-pg:                       # volume nommé, géré par Docker

docker compose up -d              # démarre toute la pile en arrière-plan
docker compose up --build         # reconstruit les images avant de démarrer
docker compose ps                 # état des services
docker compose logs -f api        # suivre les journaux d'un service
docker compose exec api bash      # ouvrir un shell dans le service "api"
docker compose exec base psql -U app annonces      # un client SQL dans la base
docker compose restart api
docker compose stop               # arrête sans supprimer
docker compose down               # arrête ET supprime conteneurs + réseau
docker compose down -v            # … et SUPPRIME LES VOLUMES (donc les données)

docker compose run --rm api pytest         # lancer une commande ponctuelle
docker compose --profile dev up            # démarrer un sous-ensemble de services

Trois points méritent d'être soulignés dans ce fichier. Le healthcheck combiné à depends_on: condition: service_healthy évite l'erreur la plus courante : l'API démarre avant que PostgreSQL n'accepte les connexions et plante immédiatement. L'absence de section ports sur la base signifie qu'elle n'est joignable que depuis le réseau interne — une bonne pratique de sécurité, et suffisante puisque l'API l'atteint par le nom base. Enfin, le script monté dans /docker-entrypoint-initdb.d/ est exécuté automatiquement au tout premier démarrage : c'est ainsi qu'on crée le schéma SQL du module 4 sans intervention manuelle. C'est exactement la structure utilisée dans le projet final (module 28).

9. Kubernetes

Le problème que Compose ne résout pas

Compose orchestre des conteneurs sur une machine. Dès qu'il faut plusieurs machines, la question change de nature : que se passe-t-il si un serveur tombe ? Comment répartir la charge ? Comment déployer une nouvelle version sans coupure ? Comment redémarrer automatiquement ce qui a planté à 3 h du matin ?

Kubernetes (souvent abrégé « K8s ») répond à cela par un principe simple à énoncer : on lui décrit l'état souhaité — « je veux trois exemplaires de cette image, chacun avec 2 Go de mémoire, accessibles derrière une adresse stable » — et il s'emploie en permanence à faire correspondre l'état réel à cette description. Si un serveur meurt, il replace ailleurs les conteneurs perdus, sans intervention. C'est ce qu'on appelle une approche déclarative : on ne donne pas d'ordres, on décrit une cible.

L'architecture, en deux moitiés

PLAN DE CONTRÔLE (le cerveau)          NŒUDS DE TRAVAIL (les bras)
┌────────────────────────────┐         ┌──────────────┐  ┌──────────────┐
│ API server  ← tout passe   │         │   kubelet    │  │   kubelet    │
│              par lui       │◄───────►│      │       │  │      │       │
│ etcd        ← l'état       │         │   ┌──┴───┐   │  │   ┌──┴───┐   │
│              souhaité      │         │   │ Pod  │   │  │   │ Pod  │   │
│ scheduler   ← place les    │         │   │ Pod  │   │  │   │ Pod  │   │
│              pods          │         │   └──────┘   │  │   └──────┘   │
│ controllers ← corrigent    │         │ kube-proxy   │  │ kube-proxy   │
│              les écarts    │         └──────────────┘  └──────────────┘
└────────────────────────────┘

On parle au cluster via l'API server, presque toujours avec la commande kubectl. L'état souhaité est stocké dans etcd. Le scheduler décide sur quel nœud placer chaque pod en fonction des ressources demandées. Les contrôleurs comparent en boucle l'état réel à l'état souhaité et agissent pour combler l'écart — c'est là que se trouve toute l'intelligence du système.

Les objets, du plus petit au plus grand

Pod — la plus petite unité déployable. Un pod contient un ou plusieurs conteneurs qui partagent la même adresse IP et les mêmes volumes ; ils sont toujours placés ensemble sur le même nœud. Dans 90 % des cas, un pod = un conteneur ; les cas à plusieurs conteneurs servent au motif sidecar (un conteneur annexe qui collecte les journaux, par exemple). Point essentiel : un pod est jetable. Il n'a pas d'adresse stable, il peut être détruit et recréé ailleurs à tout moment. On ne crée donc jamais un pod à la main.

ReplicaSet — maintient un nombre donné de pods identiques. Si l'un disparaît, il en recrée un. On ne le manipule pas directement non plus.

Deployment — l'objet que l'on écrit réellement. Il gère un ReplicaSet et, surtout, les mises à jour progressives : lors d'un changement de version, il crée les nouveaux pods, attend qu'ils soient prêts, puis retire les anciens, un par un. Pas de coupure de service, et retour arrière en une commande.

Service — puisque les pods vont et viennent avec des adresses changeantes, le Service fournit une adresse et un nom stables devant un groupe de pods, et répartit la charge entre eux. Trois variantes : ClusterIP (joignable uniquement dans le cluster, le défaut), NodePort (ouvre un port sur chaque nœud), LoadBalancer (demande un répartiteur au fournisseur cloud).

Ingress — l'entrée HTTP depuis l'extérieur : routage par nom de domaine et par chemin, terminaison TLS. C'est le reverse proxy du cluster.

ConfigMap et Secret — la configuration, séparée de l'image : paramètres non sensibles pour le premier, identifiants et clés pour le second. Cela permet de déployer la même image en test et en production avec des réglages différents.

PersistentVolumeClaim — une demande de stockage durable, l'équivalent du volume nommé de Compose.

Job et CronJob — une tâche qui se termine (un entraînement, un import) et sa version planifiée (un ré-entraînement hebdomadaire, module 26).

Namespace — un cloisonnement logique du cluster, pour séparer les équipes ou les environnements.

HorizontalPodAutoscaler — ajuste automatiquement le nombre de répliques selon la charge CPU ou une métrique personnalisée.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: model-api
  labels: { app: model-api }
spec:
  replicas: 3                          # trois exemplaires en permanence
  selector:
    matchLabels: { app: model-api }    # quels pods ce Deployment gère-t-il
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1                      # au plus 1 pod en trop pendant la mise à jour
      maxUnavailable: 0                # aucun pod indisponible : zéro coupure
  template:                            # ── le modèle de pod à créer ──
    metadata:
      labels: { app: model-api }       # doit correspondre au selector ci-dessus
    spec:
      containers:
        - name: api
          image: ghcr.io/nils/model-api:1.4.2    # JAMAIS :latest en production
          ports:
            - containerPort: 8000
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef: { name: db-credentials, key: url }
          resources:
            requests:                  # RÉSERVÉ : sert au scheduler pour le placement
              cpu: "500m"              # 500 millicœurs = 0,5 cœur
              memory: "1Gi"
            limits:                    # PLAFOND : au-delà, le conteneur est bridé (CPU)
              cpu: "2"                 #           ou tué (mémoire : OOMKilled)
              memory: "4Gi"
              nvidia.com/gpu: 1        # un GPU entier (non partageable par défaut)
          readinessProbe:              # "puis-je recevoir du trafic ?"
            httpGet: { path: /health, port: 8000 }
            initialDelaySeconds: 20    # laisse le temps de charger le modèle
            periodSeconds: 10
          livenessProbe:               # "suis-je encore vivant ?" sinon → redémarrage
            httpGet: { path: /health, port: 8000 }
            initialDelaySeconds: 60
            periodSeconds: 30
---
apiVersion: v1
kind: Service                          # l'adresse stable devant les 3 pods
metadata:
  name: model-api
spec:
  selector: { app: model-api }         # sélectionne les pods par leur étiquette
  ports:
    - port: 80                         # port du Service
      targetPort: 8000                 # port du conteneur
  type: ClusterIP

kubectl apply -f deployment.yaml      # applique l'état souhaité (créé ou mis à jour)
kubectl get pods                      # lister ; -w pour suivre en direct
kubectl get all -n mon-namespace
kubectl describe pod model-api-7d9f   # événements : LA commande de diagnostic
kubectl logs -f model-api-7d9f        # journaux ; --previous après un crash
kubectl exec -it model-api-7d9f -- bash
kubectl port-forward svc/model-api 8080:80    # tester en local sans exposer

kubectl rollout status deploy/model-api       # suivre une mise à jour
kubectl rollout undo deploy/model-api         # RETOUR ARRIÈRE immédiat
kubectl scale deploy/model-api --replicas=5
kubectl top pods                              # consommation réelle
kubectl delete -f deployment.yaml

Un modèle entraîné dans un notebook ne sert à personne : il faut que d'autres programmes — ou d'autres humains — puissent lui poser des questions. Ce module construit ce pont : une API HTTP avec FastAPI, des données d'entrée validées avec Pydantic, et une petite page web générée avec Jinja pour donner une interface à ceux qui ne parlent pas JSON.

1. Pourquoi une API

Trois façons de rendre un modèle utilisable. Le script batch : on lit un fichier, on écrit les prédictions dans un autre. C'est simple, robuste, et suffisant dans une majorité de cas — personne n'a besoin d'un score de churn à la milliseconde. La bibliothèque : on publie un paquet Python que les autres importent ; élégant, mais cela impose à tous le même langage et le même environnement. L'API : le modèle tourne quelque part, et n'importe quel programme lui parle par le réseau, quel que soit son langage.

L'API s'impose quand la prédiction doit être fraîche (au moment de l'action, pas la veille au soir), quand plusieurs applications hétérogènes doivent y accéder, ou quand on veut découpler le cycle de vie du modèle de celui des applications qui l'utilisent — remplacer le modèle sans redéployer le site web qui l'appelle.

2. Le minimum vital sur HTTP

Une API web repose sur un échange requête-réponse. Le client envoie une requête : une méthode, un chemin, des en-têtes, parfois un corps. Le serveur renvoie une réponse : un code de statut, des en-têtes, un corps.

MÉTHODES
  GET     lire une ressource, sans effet de bord. Paramètres dans l'URL.
  POST    envoyer des données, créer, déclencher un calcul. Données dans le CORPS.
  PUT     remplacer une ressource     DELETE  supprimer     PATCH  modifier

CODES DE STATUT
  2xx succès        200 OK, 201 Créé, 204 Pas de contenu
  4xx faute du CLIENT   400 requête malformée   401 non authentifié
                        403 interdit            404 introuvable
                        422 données invalides   429 trop de requêtes
  5xx faute du SERVEUR  500 erreur interne      503 indisponible

FORMAT       JSON dans la quasi-totalité des cas : {"surface": 72.5, "pieces": 3}
             En-tête Content-Type: application/json

Pour une prédiction, on utilise POST plutôt que GET : les paramètres sont nombreux et structurés, ce qui tient mal dans une URL, et le corps de requête permet des types imbriqués. On réserve GET aux lectures simples, comme un /health.

3. Pydantic : valider ce qui entre

Le problème

Dès qu'une donnée vient de l'extérieur — une requête HTTP, un fichier de configuration, une réponse d'API tierce — on ne contrôle plus rien. Un client peut envoyer une surface sous forme de chaîne de caractères, oublier un champ, ajouter un champ inconnu, ou envoyer une valeur absurde comme une surface de -40 m². Sans validation, ces valeurs traversent le code et finissent dans le modèle, qui produit alors une prédiction absurde — ou une exception incompréhensible dix fonctions plus loin.

Écrire cette validation à la main donne une cinquantaine de lignes de if imbriqués par point d'entrée, qu'il faut maintenir en double avec la documentation. C'est exactement ce que Pydantic supprime.

Le principe

On décrit la forme attendue des données comme une classe annotée — très proche d'une dataclass (module 1) — et Pydantic s'occupe du reste : il vérifie les types à l'exécution, convertit ce qui peut l'être (la chaîne "72.5" devient le flottant 72.5), refuse le reste avec un message précis, et fournit une description exploitable par les outils.

def predire(donnees: dict):
    if "surface" not in donnees:
        raise ValueError("champ 'surface' manquant")
    try:
        surface = float(donnees["surface"])
    except (TypeError, ValueError):
        raise ValueError("'surface' doit être un nombre")
    if surface <= 0 or surface > 10_000:
        raise ValueError("'surface' hors bornes")
    # … et la même chose pour chacun des douze autres champs

from typing import Literal
from pydantic import BaseModel, Field, field_validator

class Annonce(BaseModel):
    surface: float = Field(gt=0, le=10_000, description="surface habitable en m²")
    n_pieces: int = Field(ge=1, le=20)
    code_postal: str = Field(pattern=r"^\d{5}$")
    type_bien: Literal["appartement", "maison"]        # valeurs autorisées
    etage: int | None = None                           # champ facultatif
    ascenseur: bool = False                            # avec valeur par défaut

    @field_validator("code_postal")
    @classmethod
    def departement_couvert(cls, v: str) -> str:       # règle MÉTIER, pas de type
        if not v.startswith(("38", "69", "73", "74")):
            raise ValueError("département non couvert par le modèle")
        return v

a = Annonce(surface="72.5", n_pieces=3, code_postal="38000", type_bien="appartement")
print(a.surface, type(a.surface))     # 72.5 <class 'float'>  → converti automatiquement

Ce qui se passe à l'instanciation : chaque champ est vérifié, converti si possible, et une erreur groupée est levée si quelque chose ne va pas. Le message est directement exploitable :

Annonce(surface=-5, n_pieces=0, code_postal="7500", type_bien="chalet")

# ValidationError: 4 validation errors for Annonce
#   surface       Input should be greater than 0 [input_value=-5]
#   n_pieces      Input should be greater than or equal to 1 [input_value=0]
#   code_postal   String should match pattern '^\d{5}$' [input_value='7500']
#   type_bien     Input should be 'appartement' or 'maison' [input_value='chalet']

Les quatre erreurs sont signalées d'un coup, avec le champ fautif et la valeur reçue — au lieu d'un KeyError anonyme au milieu du traitement.

from pydantic import BaseModel, Field, ConfigDict, model_validator
from datetime import date

class AnnonceStricte(BaseModel):
    model_config = ConfigDict(
        extra="forbid",        # REFUSE les champs inconnus (défaut : les ignorer)
        frozen=True,           # immuable, comme une dataclass frozen (module 1)
        str_strip_whitespace=True,
    )

    ville: str
    prix: float = Field(gt=0)
    date_publication: date                  # "2026-03-14" → objet date automatiquement
    photos: list[str] = Field(default_factory=list)

    @model_validator(mode="after")          # validation qui porte sur PLUSIEURS champs
    def coherence(self):
        if self.prix > 5_000_000 and not self.photos:
            raise ValueError("un bien à ce prix sans photo est suspect")
        return self

# sérialisation dans les deux sens
a = AnnonceStricte.model_validate(dictionnaire)      # depuis un dict
a = AnnonceStricte.model_validate_json(chaine_json)  # depuis du JSON brut
a.model_dump()                                       # → dict
a.model_dump_json()                                  # → chaîne JSON

4. FastAPI : premier serveur

FastAPI relie tout cela : les routes sont des fonctions Python décorées (module 1), les entrées et sorties sont des modèles Pydantic, et la documentation interactive est générée automatiquement à partir des types.

from fastapi import FastAPI

app = FastAPI(title="API de scoring immobilier", version="1.0.0")

@app.get("/health")              # décorateur : "cette fonction répond au GET /health"
def health() -> dict:
    return {"status": "ok"}      # le dict est converti en JSON automatiquement

uv run uvicorn mon_projet.api:app --reload    # --reload : redémarre à chaque sauvegarde
#                └─ module:objet
# → http://127.0.0.1:8000/health
# → http://127.0.0.1:8000/docs   : documentation interactive, générée toute seule

La page /docs mérite qu'on s'y arrête : elle liste les routes, les schémas d'entrée et de sortie, et permet d'envoyer une requête de test depuis le navigateur. Elle est produite à partir des annotations de type, donc elle ne peut pas se désynchroniser du code — contrairement à une documentation écrite à la main.

from fastapi import FastAPI, Query, Path, HTTPException

@app.get("/annonces/{annonce_id}")                   # 1. dans le CHEMIN
def lire(annonce_id: int = Path(ge=1)) -> dict:
    annonce = base.get(annonce_id)
    if annonce is None:
        raise HTTPException(status_code=404, detail="annonce introuvable")
    return annonce

@app.get("/annonces")                                 # 2. en QUERY : /annonces?ville=Lyon
def chercher(ville: str, prix_max: float = Query(default=1e9, gt=0),
             limite: int = Query(default=20, le=100)) -> list[dict]:
    ...

@app.post("/predict")                                 # 3. dans le CORPS de la requête
def predire(annonce: Annonce) -> Reponse:             # ← modèle Pydantic
    ...

Le troisième cas est le plus intéressant : FastAPI voit que le paramètre est un modèle Pydantic, en déduit qu'il faut le lire dans le corps de la requête, le valide, et renvoie automatiquement un code 422 avec le détail des erreurs si les données ne conviennent pas. Aucune ligne de validation à écrire.

5. Servir un modèle de ML

from contextlib import asynccontextmanager
import anyio, joblib, numpy as np, pandas as pd
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field

MODELE_VERSION = "1.4.2"
etat: dict = {}

@asynccontextmanager
async def lifespan(app: FastAPI):
    # ── exécuté UNE FOIS au démarrage ──
    etat["modele"] = joblib.load(f"models/gbm-{MODELE_VERSION}.joblib")
    yield
    # ── exécuté à l'arrêt ──
    etat.clear()

app = FastAPI(title="API de scoring immobilier", version=MODELE_VERSION, lifespan=lifespan)

class Annonce(BaseModel):
    surface: float = Field(gt=0, le=10_000)
    n_pieces: int = Field(ge=1, le=20)
    code_postal: str = Field(pattern=r"^\d{5}$")
    type_bien: str

class Prediction(BaseModel):
    prix_estime: float
    intervalle_bas: float
    intervalle_haut: float
    version_modele: str

@app.get("/health")
def health() -> dict:
    return {"status": "ok", "modele_charge": "modele" in etat, "version": MODELE_VERSION}

@app.post("/predict", response_model=Prediction)
async def predire(annonce: Annonce) -> Prediction:
    X = pd.DataFrame([annonce.model_dump()])          # le pipeline attend un DataFrame
    try:
        # predict est BLOQUANT : on le sort de la boucle d'événements (module 2)
        y = await anyio.to_thread.run_sync(etat["modele"].predict, X)
    except Exception as exc:
        raise HTTPException(status_code=500, detail="échec de l'inférence") from exc

    prix = float(y[0])
    return Prediction(prix_estime=prix,
                      intervalle_bas=prix * 0.9, intervalle_haut=prix * 1.1,
                      version_modele=MODELE_VERSION)

@app.post("/predict/batch", response_model=list[Prediction])
async def predire_lot(annonces: list[Annonce]) -> list[Prediction]:
    """Un seul appel pour N annonces : bien plus efficace que N appels."""
    X = pd.DataFrame([a.model_dump() for a in annonces])
    y = await anyio.to_thread.run_sync(etat["modele"].predict, X)
    return [Prediction(prix_estime=float(p), intervalle_bas=float(p) * 0.9,
                       intervalle_haut=float(p) * 1.1, version_modele=MODELE_VERSION)
            for p in y]

6. Jinja : une interface web

À quoi sert un moteur de templates

Une API renvoie du JSON, parfait pour un programme, illisible pour un humain. Pour donner un petit formulaire à un collègue non technicien, il faut produire du HTML — et le produire par concaténation de chaînes en Python devient vite ingérable et dangereux (une valeur contenant du code HTML casserait la page, voire injecterait un script).

Un moteur de templates sépare la structure de la page et les données. On écrit un fichier HTML normal, dans lequel on place des marqueurs ; le moteur remplit ces marqueurs avec les valeurs fournies. Jinja est le moteur de référence en Python — celui de Flask, et il s'utilise aussi bien avec FastAPI.

{{ expression }}          affiche une valeur      → {{ annonce.prix }}
{% instruction %}         logique                 → {% if %} {% for %} {% block %}
{# commentaire #}         n'apparaît pas dans la page finale

filtres : une valeur passée dans une transformation
{{ prix | round(2) }}            {{ nom | upper }}
{{ liste | length }}             {{ texte | default("inconnu") }}

<!DOCTYPE html>
<html lang="fr">
<head><meta charset="utf-8"><title>Estimation de prix</title></head>
<body>
  <h1>Estimer le prix d'un bien</h1>

  <form method="post" action="/estimer">
    <label>Surface (m²) <input type="number" name="surface" step="0.1" required></label>
    <label>Pièces <input type="number" name="n_pieces" min="1" required></label>
    <label>Code postal <input type="text" name="code_postal" pattern="\d{5}" required></label>
    <button type="submit">Estimer</button>
  </form>

  {# ce bloc ne s'affiche que si une estimation a été calculée #}
  {% if prix %}
    <p>Prix estimé : <strong>{{ prix | round(0) }} €</strong>
       ({{ (prix / surface) | round(0) }} €/m²)</p>
  {% endif %}

  {% if annonces_comparables %}
    <h2>Biens comparables</h2>
    <ul>
    {% for a in annonces_comparables %}
      <li>{{ a.ville }} — {{ a.surface }} m² — {{ a.prix | round(0) }} €</li>
    {% else %}
      <li>aucun bien comparable trouvé</li>
    {% endfor %}
    </ul>
  {% endif %}
</body></html>

from fastapi import Form, Request
from fastapi.responses import HTMLResponse
from fastapi.templating import Jinja2Templates

templates = Jinja2Templates(directory="templates")

@app.get("/", response_class=HTMLResponse)
def formulaire(request: Request):
    return templates.TemplateResponse("formulaire.html", {"request": request})

@app.post("/estimer", response_class=HTMLResponse)
async def estimer(request: Request,
                  surface: float = Form(...), n_pieces: int = Form(...),
                  code_postal: str = Form(...)):
    annonce = Annonce(surface=surface, n_pieces=n_pieces,
                      code_postal=code_postal, type_bien="appartement")
    X = pd.DataFrame([annonce.model_dump()])
    prix = float((await anyio.to_thread.run_sync(etat["modele"].predict, X))[0])

    # les clés du dictionnaire deviennent les variables disponibles dans le template
    return templates.TemplateResponse("formulaire.html", {
        "request": request, "prix": prix, "surface": surface,
        "annonces_comparables": chercher_comparables(annonce),
    })

Deux mécanismes de Jinja méritent d'être connus. L'échappement automatique : une valeur contenant <script> est affichée comme du texte et non exécutée, ce qui bloque par défaut les injections de code. Et l'héritage de templates : un fichier base.html définit la structure commune avec des {% block contenu %}, et chaque page fait {% extends "base.html" %} puis remplit les blocs — exactement le principe qui évite de dupliquer l'en-tête et le pied de page sur toutes les pages.

7. Tester une API

FastAPI fournit un client de test qui appelle l'application en mémoire, sans démarrer de serveur ni ouvrir de port : les tests sont donc rapides et utilisables en intégration continue.

from fastapi.testclient import TestClient
from mon_projet.api import app

client = TestClient(app)            # déclenche aussi le lifespan (chargement du modèle)

def test_health():
    r = client.get("/health")
    assert r.status_code == 200 and r.json()["modele_charge"] is True

def test_prediction_valide():
    r = client.post("/predict", json={"surface": 72.5, "n_pieces": 3,
                                      "code_postal": "38000", "type_bien": "appartement"})
    assert r.status_code == 200
    corps = r.json()
    assert corps["prix_estime"] > 0
    assert corps["version_modele"] == "1.4.2"

def test_entree_invalide_renvoie_422():
    r = client.post("/predict", json={"surface": -5, "n_pieces": 3,
                                      "code_postal": "38000", "type_bien": "appartement"})
    assert r.status_code == 422
    assert "surface" in r.text          # le champ fautif est nommé dans la réponse

def test_champ_manquant():
    r = client.post("/predict", json={"surface": 72.5})
    assert r.status_code == 422

8. Mise en production

# en développement
uv run uvicorn mon_projet.api:app --reload

# en production : plusieurs processus workers, chacun avec son propre GIL (module 2)
uv run uvicorn mon_projet.api:app --host 0.0.0.0 --port 8000 --workers 4

# dans un conteneur, la commande du Dockerfile (module 5)
CMD ["uvicorn", "mon_projet.api:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "4"]

Chaque worker charge sa propre copie du modèle : quatre workers avec un modèle de 2 Go consomment 8 Go de RAM. C'est l'arbitrage principal à faire, entre débit et mémoire. Au-delà, on regroupe les requêtes par lots côté serveur (dynamic batching), ce que font Triton ou vLLM (modules 22 et 25).

from fastapi.middleware.cors import CORSMiddleware
from fastapi import Depends, Header, HTTPException
import logging, time, uuid

# 1. CORS : quels sites web ont le droit d'appeler cette API depuis un navigateur
app.add_middleware(CORSMiddleware, allow_origins=["https://mon-site.fr"],
                   allow_methods=["POST", "GET"], allow_headers=["*"])

# 2. authentification simple par clé d'API
def verifier_cle(x_api_key: str = Header(...)):
    if x_api_key != os.environ["API_KEY"]:
        raise HTTPException(status_code=401, detail="clé invalide")

@app.post("/predict", dependencies=[Depends(verifier_cle)])
async def predire(...): ...

# 3. journalisation : identifiant de requête, durée, version du modèle
@app.middleware("http")
async def journaliser(request, call_next):
    rid, debut = str(uuid.uuid4())[:8], time.perf_counter()
    reponse = await call_next(request)
    logging.info("%s %s %s %.1fms", rid, request.url.path,
                 reponse.status_code, (time.perf_counter() - debut) * 1000)
    reponse.headers["X-Request-ID"] = rid
    return reponse

S'y ajoutent, selon le contexte : une limitation de débit (rate limiting) pour éviter qu'un client ne sature le service, et l'exposition de métriques au format Prometheus pour le suivi (module 26). Le Depends utilisé ci-dessus est le système d'injection de dépendances de FastAPI : une fonction déclarée comme dépendance est exécutée avant la route, et son résultat est fourni à celle-ci — c'est le mécanisme standard pour l'authentification, l'ouverture d'une session de base de données ou la lecture de la configuration.

Les modules précédents ont montré comment écrire du code propre, le paralléliser, manipuler des tableaux, interroger une base et livrer une application dans un conteneur. Il manque une pièce, et c'est souvent celle qui occupe le plus de temps en entreprise : faire arriver les données jusqu'au point où l'analyse commence, de façon fiable, répétable et pas trop chère. C'est le métier de l'ingénierie des données. Un modèle ne vaut jamais mieux que la table sur laquelle il s'entraîne, et cette table ne se matérialise pas toute seule.

1. Le problème : le modèle n'est que la partie visible

Une étude souvent citée de Google sur la dette technique du machine learning — on y revient au module 26 — résume la situation par un schéma : dans un système de ML en production, le code du modèle occupe une petite boîte au centre, entourée de boîtes bien plus grosses qui s'appellent collecte, vérification, transformation, stockage, service, surveillance. Le rapport de taille n'est pas une métaphore : c'est le rapport des efforts réels.

La raison est simple. Un fichier CSV posé sur un bureau se charge en une ligne de pandas. Une source de données vivante, elle, arrive en continu, change de schéma sans prévenir, contient des doublons, arrive parfois en retard, parfois deux fois, et doit être relue entièrement le jour où l'on découvre un bug dans une transformation d'il y a trois mois. Tout ce module traite de ces quatre difficultés :

• le volume — comment stocker et relire des données qui ne tiennent plus en mémoire, sans tout relire ;
• le changement — comment survivre à une colonne qui disparaît ou qui change de type ;
• la répétition — comment relancer un traitement sans créer de doublons ni de trous ;
• le temps — comment raisonner sur des événements qui n'arrivent pas dans l'ordre où ils se sont produits.

2. Ligne ou colonne : CSV, Parquet, Arrow

Le problème

Le CSV est universel et illisible par une machine : aucun type (tout est du texte, il faut deviner), aucune compression, aucune structure interne. Lire la colonne prix d'un CSV de 40 Go impose de lire les 40 Go, puis de convertir chaque champ en nombre. Sur un entrepôt où les requêtes touchent cinq colonnes sur deux cents, c'est un gâchis considérable.

L'intuition : deux façons de poser des données sur un disque

Un fichier est une suite d'octets, donc un tableau à deux dimensions doit être aplati. Il y a deux manières de le faire, et tout découle de ce choix.

Table logique
  id | ville     | prix   | surface
  ---+-----------+--------+--------
   1 | Lyon      | 320000 | 68
   2 | Nantes    | 245000 | 54
   3 | Lille     | 198000 | 61

ORIENTÉ LIGNE (CSV, PostgreSQL classique)
  [1,Lyon,320000,68][2,Nantes,245000,54][3,Lille,198000,61]
   └── une ligne entière, puis la suivante
   → lire UN bien : une seule lecture contiguë      ✓ rapide
   → lire TOUS les prix : sauter partout            ✗ lent

ORIENTÉ COLONNE (Parquet, DuckDB, ClickHouse)
  [1,2,3][Lyon,Nantes,Lille][320000,245000,198000][68,54,61]
   └── toute une colonne, puis la suivante
   → lire TOUS les prix : une seule lecture         ✓ rapide
   → lire UN bien entier : quatre lectures          ✗ moins bon

La disposition en colonnes a une seconde vertu, moins évidente et souvent plus décisive que la première : une colonne est homogène. Mille prix à la suite sont mille nombres qui se ressemblent, donc qui se compressent très bien ; mille villes à la suite contiennent quelques dizaines de valeurs distinctes, qu'on remplace par un dictionnaire et des entiers courts. Un CSV mélange types et magnitudes à chaque ligne, ce qui ruine toute compression. En pratique, un CSV de 40 Go devient couramment un Parquet de 3 à 6 Go, sans perte.

import time, pathlib
import numpy as np, pandas as pd

rng = np.random.default_rng(0)
n = 2_000_000
df = pd.DataFrame({
    "id": np.arange(n),
    "ville": rng.choice(["Lyon", "Nantes", "Lille", "Rennes"], n),
    "prix": rng.integers(80_000, 900_000, n),
    "surface": rng.integers(15, 200, n),
})

df.to_csv("biens.csv", index=False)
df.to_parquet("biens.parquet")          # nécessite pyarrow

for f in ("biens.csv", "biens.parquet"):
    mo = pathlib.Path(f).stat().st_size / 1e6
    print(f"{f:16s} {mo:7.1f} Mo")
# biens.csv           78.9 Mo
# biens.parquet       10.2 Mo      → 7,7× plus petit

# lire UNE colonne
t = time.perf_counter()
pd.read_csv("biens.csv", usecols=["prix"])
print(f"csv     : {time.perf_counter() - t:.2f} s")      # ~0.75 s

t = time.perf_counter()
pd.read_parquet("biens.parquet", columns=["prix"])
print(f"parquet : {time.perf_counter() - t:.2f} s")      # ~0.02 s

Le facteur n'est pas un détail d'optimisation : à l'échelle d'un entrepôt, il décide de ce qui est faisable interactivement et de ce qui ne l'est pas.

Et Arrow, alors ?

Confusion fréquente, qui vaut d'être levée nettement. Parquet est un format de disque ; Arrow est un format de mémoire. Parquet est compressé et encodé, donc compact mais inexploitable tel quel : il faut le décoder. Arrow décrit comment un tableau colonne est disposé dans la RAM, non compressé, prêt à être lu par le processeur.

L'intérêt d'Arrow est ailleurs : c'est une convention partagée. Quand polars, DuckDB, pandas 2 et un moteur Java utilisent tous la disposition Arrow, passer une table de l'un à l'autre ne coûte rien — aucune conversion, aucune copie, on se transmet un pointeur. Avant Arrow, chaque échange entre deux outils imposait une sérialisation complète. C'est ce qui explique qu'on puisse interroger en SQL, avec DuckDB, un objet polars présent en mémoire sans rien recopier (module 4).

3. Partitionner : ranger pour ne pas tout lire

Un fichier Parquet unique de 500 Go pose un problème que la compression ne résout pas : toute requête doit l'ouvrir. La solution est de découper les données en répertoires dont le nom porte l'information de filtrage.

annonces/
├── annee=2025/
│   ├── mois=11/
│   │   ├── part-0000.parquet
│   │   └── part-0001.parquet
│   └── mois=12/
│       └── part-0000.parquet
└── annee=2026/
    └── mois=01/
        └── part-0000.parquet

Requête : « les annonces de janvier 2026 »
→ le moteur lit le nom des répertoires, ouvre UN fichier,
  ignore les autres sans les toucher. C'est l'élagage de partitions.

import polars as pl

df.write_parquet("annonces/", partition_by=["annee", "mois"])

# la lecture ne touche que la partition utile
q = (
    pl.scan_parquet("annonces/**/*.parquet", hive_partitioning=True)
      .filter((pl.col("annee") == 2026) & (pl.col("mois") == 1))
      .group_by("ville")
      .agg(pl.col("prix").median().alias("prix_median"))
)
print(q.collect())

4. Lire ce qui n'est pas propre : JSON, logs, expressions régulières

Les données rarement arrivent sous forme de table. Elles arrivent en JSON imbriqué depuis une API, en lignes de journal depuis un serveur, en champs libres saisis par des humains. Trois outils suffisent à couvrir l'essentiel.

Aplatir du JSON imbriqué

import pandas as pd

reponse = [
    {"id": 1, "bien": {"ville": "Lyon", "prix": 320000},
     "options": ["balcon", "cave"]},
    {"id": 2, "bien": {"ville": "Nantes", "prix": 245000},
     "options": []},
]

# json_normalize déplie les dictionnaires imbriqués en colonnes
df = pd.json_normalize(reponse, sep="_")
print(df.columns.tolist())
# ['id', 'options', 'bien_ville', 'bien_prix']

# une liste dans une cellule n'est pas une table : on la déplie en lignes
df_opt = df.explode("options")[["id", "options"]]
print(df_opt)
#    id options
# 0   1  balcon
# 0   1    cave
# 1   2     NaN

Le choix de fond, ici, est de décider ce qui devient une colonne et ce qui devient une ligne. Une liste d'options par annonce peut rester un tableau dans une colonne (Parquet sait le stocker) ou devenir une table séparée avec une ligne par option — la forme normalisée du module 4. La table séparée se joint et s'agrège facilement ; la colonne-tableau évite une jointure. On tranche selon l'usage dominant.

Les expressions régulières, le minimum utile

Une expression régulière est un motif décrivant une famille de chaînes de caractères. C'est l'outil standard pour extraire un champ d'un texte non structuré. Trois quarts des usages tiennent en une poignée de symboles.

\d   un chiffre            \w   lettre, chiffre ou _      .    n'importe quoi
\s   une espace            +    une fois ou plus          *    zéro fois ou plus
?    zéro ou une fois      {2,4} entre 2 et 4 fois        |    ou
[]   un caractère parmi    ()   un GROUPE à capturer      ^ $  début, fin
\.   un point littéral (l'antislash « échappe » le sens spécial)

import re
import pandas as pd

annonces = pd.Series([
    "T3 de 68 m2 - 320 000 EUR - Lyon 3e",
    "Studio 21m2, 148500 EUR, Nantes",
    "Maison 140 m2 | 495 000 EUR | Rennes",
])

# (?P<nom>...) nomme le groupe capturé : il devient le nom de colonne
motif = r"(?P<surface>\d+)\s?m2.*?(?P<prix>[\d\s]+)\s?EUR"
extrait = annonces.str.extract(motif)
extrait["prix"] = extrait["prix"].str.replace(r"\s", "", regex=True)
print(extrait.astype({"surface": int, "prix": int}))
#    surface    prix
# 0       68  320000
# 1       21  148500
# 2      140  495000

5. ETL, ELT, et pourquoi l'ordre s'est inversé

Trois lettres qui décrivent l'ordre des opérations entre la source et l'entrepôt.

ETL — Extract, Transform, Load          (années 1990-2010)
  source ──► serveur de traitement ──► entrepôt
             │ nettoyage, jointures,
             │ agrégations
             └─ AVANT le chargement

  Pourquoi : l'entrepôt était une machine coûteuse et peu extensible.
  On n'y chargeait que le strict nécessaire, déjà propre.
  Conséquence : la donnée brute n'existe plus. Un bug de transformation
  d'il y a six mois est irréparable — on n'a plus la source.

ELT — Extract, Load, Transform          (depuis ~2015)
  source ──► entrepôt (brut) ──► entrepôt (transformé)
                                 └─ transformations EN SQL, dans l'entrepôt

  Pourquoi : le stockage objet coûte ~20 € le téraoctet-mois, et les
  moteurs analytiques passent à l'échelle horizontalement.
  Conséquence : la donnée brute est conservée. On peut TOUT rejouer.

Le basculement n'est donc pas une mode : c'est la conséquence directe de l'effondrement du coût du stockage. Garder la donnée brute pour rien coûte moins cher que de devoir la redemander à la source — quand c'est encore possible. La conséquence pratique, pour vous, est que les transformations s'écrivent désormais en SQL sur l'entrepôt (module 4) plutôt qu'en Python sur une machine intermédiaire, ce qui est aussi plus facile à tester et à relire.

6. Modéliser pour l'analyse : le schéma en étoile

Le problème

Le module 4 a présenté la normalisation : éviter la redondance, une information en un seul endroit. C'est la bonne réponse pour une base transactionnelle, où l'on écrit beaucoup et où toute duplication est un risque d'incohérence. Pour l'analyse, l'objectif est inverse : on écrit une fois, on lit des millions de fois, et chaque jointure supplémentaire coûte. Un schéma parfaitement normalisé impose huit jointures pour répondre à « chiffre d'affaires par région et par mois ».

L'intuition

On sépare les données en deux natures. Les faits sont des événements mesurables, nombreux, qui ne changent pas : une vente, un clic, une annonce publiée. Les dimensions sont les axes selon lesquels on veut découper ces faits : le temps, le client, le produit, la ville. Une table de faits au centre, entourée de tables de dimensions — d'où le nom.

        dim_date                      dim_ville
   ┌──────────────────┐          ┌──────────────────┐
   │ date_id (PK)     │          │ ville_id (PK)    │
   │ jour, mois, année│          │ nom, departement │
   │ jour_semaine     │          │ region, population│
   │ est_ferie        │          └────────┬─────────┘
   └────────┬─────────┘                   │
            │        fait_annonce         │
            │   ┌─────────────────────┐   │
            └──►│ date_id      (FK)   │◄──┘
                │ ville_id     (FK)   │
                │ bien_id      (FK)   │◄──┐
                │─────────────────────│   │
                │ prix        (mesure)│   │   dim_bien
                │ surface     (mesure)│   │ ┌──────────────┐
                │ nb_vues     (mesure)│   └─│ bien_id (PK) │
                └─────────────────────┘     │ type, etage  │
                                            │ dpe, meuble  │
   FAITS : beaucoup de lignes, que des      └──────────────┘
           clés et des mesures numériques
   DIMENSIONS : peu de lignes, beaucoup de colonnes descriptives

-- « prix médian au m2 par région, pour les annonces de 2026,
--    hors jours fériés » : deux jointures, lisible d'un coup d'œil
SELECT v.region,
       PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY f.prix / f.surface)
         AS prix_m2_median,
       COUNT(*) AS n
FROM fait_annonce f
JOIN dim_ville v ON v.ville_id = f.ville_id
JOIN dim_date  d ON d.date_id  = f.date_id
WHERE d.annee = 2026
  AND NOT d.est_ferie
GROUP BY v.region
ORDER BY prix_m2_median DESC;

La table dim_date mérite un mot : la construire explicitement, avec une ligne par jour et des colonnes pré-calculées (trimestre, semaine ISO, jour férié, période de vacances), évite de réécrire cette logique dans chaque requête — et surtout évite qu'elle diverge d'une requête à l'autre.

7. dbt : du SQL versionné, testé, documenté

Le problème

Une fois qu'on transforme en SQL dans l'entrepôt, on se retrouve avec deux cents requêtes qui se lisent les unes les autres, copiées dans une interface web, sans historique, sans tests, et dont personne ne sait dans quel ordre les lancer. On a réinventé le pire du code — sauf qu'on a tout ce qu'il faut pour bien faire : Git (module 1), des tests (module 1), des environnements.

Le principe

dbt (data build tool) applique les pratiques du développement logiciel au SQL analytique. Chaque transformation est un fichier .sql dans un dépôt Git, contenant un simple SELECT. dbt se charge du reste : il déduit l'ordre d'exécution, matérialise les résultats en tables ou en vues, et exécute des tests.

-- Le SELECT seul suffit : dbt l'enveloppe en CREATE TABLE AS.
{{ config(materialized='incremental', unique_key='jour_ville') }}

WITH base AS (
    -- ref() déclare la dépendance : dbt en déduit l'ordre d'exécution
    SELECT * FROM {{ ref('stg_annonces') }}
)
SELECT
    date_trunc('day', publiee_le)           AS jour,
    ville,
    date_trunc('day', publiee_le) || ville   AS jour_ville,
    COUNT(*)                                AS n_annonces,
    APPROX_QUANTILES(prix, 100)[OFFSET(50)] AS prix_median
FROM base
{% if is_incremental() %}
  -- au premier lancement : tout. Ensuite : seulement le nouveau.
  WHERE publiee_le > (SELECT MAX(jour) FROM {{ this }})
{% endif %}
GROUP BY jour, ville

Les accolades doubles sont du Jinja — le moteur de gabarits rencontré au module 6 avec FastAPI, réutilisé ici pour générer du SQL. ref() est le mécanisme central : en écrivant ref('stg_annonces') plutôt que le nom réel de la table, on déclare une dépendance. dbt en construit le graphe complet et sait donc quoi reconstruire, dans quel ordre, et ce qu'un changement casse en aval.

version: 2
models:
  - name: annonces_journalier
    description: "Une ligne par jour et par ville."
    columns:
      - name: jour_ville
        description: "Clé composite jour + ville."
        tests: [unique, not_null]
      - name: prix_median
        tests:
          - dbt_utils.accepted_range:
              min_value: 10000
              max_value: 5000000

dbt run                      # construit tous les modèles, dans l'ordre
dbt run --select stg_annonces+   # ce modèle ET tout ce qui en dépend
dbt test                     # exécute les tests déclarés
dbt build                    # run + test, modèle par modèle : s'arrête
                             # au premier échec, avant de propager l'erreur
dbt docs generate && dbt docs serve   # documentation + graphe navigable

Le gain réel n'est pas la syntaxe, c'est le changement de statut : une transformation devient un objet relu en revue de code, testé automatiquement, dont on connaît les dépendances. Alternatives dans le même esprit : SQLMesh, ou un simple ensemble de scripts SQL orchestrés à la main quand le projet est petit — l'essentiel est le principe, pas l'outil.

8. Orchestration : DAG, idempotence, backfill

Le problème

cron lance un script à heure fixe. Il ne sait pas si le script précédent a réussi, ne réessaie pas, ne prévient personne, et ne garde aucune trace. Dès qu'un traitement en attend un autre, il faut un outil qui connaisse les dépendances : un orchestrateur (Airflow, Dagster, Prefect).

Le modèle commun est le graphe orienté acyclique : des tâches, des flèches de dépendance, et aucun cycle — sinon rien ne pourrait démarrer. L'orchestrateur exécute en parallèle tout ce qui peut l'être, réessaie ce qui échoue, et journalise tout.

  extraire_api ──┐
                 ├──► valider ──► charger_brut ──► dbt_build ──► alerter
  extraire_sql ──┘                                     │
                                                       └──► rafraichir_modele

  · extraire_api et extraire_sql : en parallèle, rien ne les lie
  · valider attend les deux
  · si dbt_build échoue, alerter et rafraichir_modele ne partent pas

Les deux propriétés qui rendent un pipeline exploitable

Elles paraissent techniques ; elles décident en réalité de la quantité de nuits blanches par an.

from datetime import datetime
from airflow.decorators import dag, task

@dag(schedule="0 3 * * *",            # tous les jours à 3 h UTC
     start_date=datetime(2026, 1, 1),
     catchup=True,                    # rejoue les jours manqués
     max_active_runs=1,               # pas deux exécutions concurrentes
     default_args={"retries": 3})
def annonces_quotidien():

    @task
    def extraire(jour: str) -> str:
        """Écrit UNE partition, celle du jour reçu en paramètre."""
        chemin = f"s3://lac/annonces/jour={jour}/"
        # ... extraction ...
        return chemin

    @task
    def charger(chemin: str, jour: str) -> None:
        # idempotent : on efface la partition avant de la réécrire
        execute(f"DELETE FROM brut.annonces WHERE jour = '{jour}'")
        execute(f"COPY brut.annonces FROM '{chemin}'")

    # {{ ds }} = date de la période traitée, pas la date du jour
    jour = "{{ ds }}"
    charger(extraire(jour), jour)

annonces_quotidien()

Notez catchup=True : si l'orchestrateur est arrêté trois jours, il lancera au redémarrage les trois exécutions manquantes, chacune avec sa propre date. C'est la combinaison du paramétrage par la date et de l'idempotence qui rend cela sûr.

9. Le temps, cette source de bugs

Le sujet paraît trivial. Il est responsable d'une proportion remarquable des incidents en production, et il faut trois règles pour s'en prémunir.

from datetime import datetime, timezone
from zoneinfo import ZoneInfo          # standard depuis Python 3.9

# ✗ naïf : aucun fuseau attaché, on ne sait pas ce que ça représente
mauvais = datetime(2026, 10, 25, 2, 30)

# ✓ conscient du fuseau
paris = ZoneInfo("Europe/Paris")
t = datetime(2026, 10, 25, 2, 30, tzinfo=paris)
print(t.astimezone(timezone.utc))      # 2026-10-25 00:30:00+00:00
print(t.utcoffset())                   # 2:00:00 — mais 2 h 30 existe 2 fois !

# la règle sûre : raisonner en UTC, convertir à l'affichage
maintenant = datetime.now(timezone.utc)
print(maintenant.astimezone(paris).strftime("%d/%m/%Y %H:%M"))

10. Par lots ou en flux : Kafka et les fenêtres

Le problème

Traiter par lots signifie attendre. Un pipeline quotidien donne une réponse avec vingt-quatre heures de retard, ce qui convient parfaitement à un tableau de bord commercial et pas du tout à la détection d'une fraude sur une carte bancaire. Le traitement en flux traite chaque événement à mesure qu'il arrive.

L'intuition : le journal

La bonne image pour comprendre Kafka n'est ni une file d'attente ni une base : c'est un journal, au sens d'un registre où l'on écrit à la suite sans jamais raturer. Les producteurs ajoutent des lignes à la fin. Les consommateurs lisent en avançant à leur rythme, chacun mémorisant simplement la ligne où il en est. Rien n'est effacé à la lecture, et un nouveau consommateur peut revenir au début.

Sujet « annonces », 3 partitions

partition 0 : [e0][e1][e2][e3][e4][e5]───►  écriture toujours à la fin
                          ▲         ▲
                   groupe A│  groupe B│     chacun avance à son rythme
                   (offset 3)  (offset 5)

partition 1 : [e0][e1][e2]───►
partition 2 : [e0][e1][e2][e3]───►

· l'ordre n'est garanti QUE dans une partition
· la clé de l'événement décide de sa partition : tous les événements
  d'une même annonce tombent dans la même partition, donc restent ordonnés
· la rétention est une durée (7 jours) ou une taille, pas « jusqu'à lecture »

Cette rétention change tout par rapport à une file classique : on peut rejouer. Un bug dans le consommateur ? On corrige, on remet le curseur trois jours en arrière, on relit. C'est le même principe que la conservation de la donnée brute vue plus haut, appliqué aux événements.

from kafka import KafkaProducer, KafkaConsumer
import json

prod = KafkaProducer(
    bootstrap_servers="localhost:9092",
    value_serializer=lambda v: json.dumps(v).encode(),
    key_serializer=lambda k: k.encode(),
)
# la clé fixe la partition → ordre garanti par annonce
prod.send("annonces", key="a-4821",
          value={"id": "a-4821", "prix": 320000, "ts": "2026-01-12T09:00:00Z"})
prod.flush()

conso = KafkaConsumer(
    "annonces",
    bootstrap_servers="localhost:9092",
    group_id="indexeur",              # le groupe porte la position de lecture
    enable_auto_commit=False,         # on valide APRÈS traitement
    value_deserializer=lambda b: json.loads(b),
)
for msg in conso:
    traiter(msg.value)                # si ça échoue, on ne valide pas
    conso.commit()                    # → le message sera relu au redémarrage

Fenêtres : agréger un flux qui n'a pas de fin

Sur un flux infini, GROUP BY n'a pas de sens : on ne peut pas attendre la fin. On agrège donc sur des fenêtres de temps.

FIXE (tumbling) — se suivent, ne se recouvrent pas
  |--- 10:00-10:05 ---|--- 10:05-10:10 ---|--- 10:10-10:15 ---|
  usage : « nombre d'annonces publiées par tranche de 5 minutes »

GLISSANTE (sliding) — se recouvrent
  |--- 10:00-10:05 ---|
       |--- 10:01-10:06 ---|
            |--- 10:02-10:07 ---|
  usage : « moyenne sur les 5 dernières minutes, rafraîchie chaque minute »

DE SESSION — délimitée par une période d'inactivité
  [clic clic clic] ....30 min de silence.... [clic clic]
  └─ session 1 ─┘                            └─ sess. 2 ┘
  usage : « durée d'une visite », sans durée fixée a priori

11. Qualité : contrats de données et observabilité

Le problème

Un pipeline qui échoue bruyamment est un bon pipeline : on le voit, on le répare. Le vrai danger est le pipeline qui réussit avec des données fausses. Une source change silencieusement le prix d'euros en centimes ; tout s'exécute sans erreur ; le modèle s'entraîne sur des valeurs multipliées par cent et personne ne s'en aperçoit avant trois semaines.

Le contrat de données

La réponse est de déclarer explicitement ce qu'on attend, et de faire échouer l'ingestion quand la réalité s'en écarte. C'est exactement l'idée de Pydantic (module 6), transposée à des tables entières.

import pandera.polars as pa
import polars as pl

class Annonce(pa.DataFrameModel):
    id: str            = pa.Field(unique=True)
    ville: str         = pa.Field(isin=["Lyon", "Nantes", "Lille", "Rennes"])
    prix: int          = pa.Field(gt=10_000, lt=5_000_000)
    surface: float     = pa.Field(gt=5, lt=1_000)
    publiee_le: pl.Datetime

    class Config:
        strict = "filter"     # une colonne inconnue est écartée, pas ignorée

    @pa.check("prix")
    def prix_au_m2_plausible(cls, data) -> bool:
        """Une règle métier que le typage ne peut pas exprimer."""
        return True   # calcul réel : prix / surface entre 500 et 20 000

df = pl.read_parquet("brut/annonces.parquet")
propre = Annonce.validate(df, lazy=True)   # lazy : TOUTES les erreurs d'un coup

Le point important est où placer cette barrière : à la frontière, au moment où la donnée entre dans le système. Valider en sortie, c'est découvrir le problème après l'avoir propagé partout.

12. Quelle architecture pour quelle taille

Le feature store, en deux mots

Un problème très concret survient quand un modèle passe en production. La variable « nombre d'annonces publiées par ce vendeur les 30 derniers jours » est calculée en SQL sur l'entrepôt pour l'entraînement, et réécrite en Python dans l'API pour la prédiction. Deux implémentations de la même idée : elles finissent toujours par diverger — l'une exclut le jour courant, l'autre non. Le modèle reçoit alors en production des valeurs qui ne ressemblent pas à celles vues à l'entraînement, et se dégrade sans qu'aucune alerte ne se déclenche. C'est le décalage entraînement/service.

Un feature store (Feast, Tecton) résout cela en imposant une seule définition, servie de deux façons : en lot pour construire le jeu d'entraînement — en respectant la date, donc sans fuite —, et à la milliseconde pour l'API. Utile à partir de plusieurs modèles partageant des variables ; superflu avant, où une fonction Python unique appelée des deux côtés suffit.

Lakehouse : le compromis actuel

Le lac de données (des fichiers, souple, pas cher) et l'entrepôt (structuré, transactionnel, cher) ont longtemps coexisté, avec des copies dans les deux sens. Les formats de table ouverts — Delta Lake, Apache Iceberg, Apache Hudi — apportent aux fichiers Parquet ce qui leur manquait : des transactions, l'évolution de schéma, et surtout le voyage dans le temps, c'est-à-dire la possibilité d'interroger la table telle qu'elle était il y a deux semaines. Pour la reproductibilité d'un entraînement (module 26), c'est décisif : « ce modèle a été entraîné sur la version 47 de cette table » devient une phrase vérifiable.

< 10 Go, une personne
  fichiers Parquet + DuckDB + scripts Python planifiés par cron
  → n'ajoutez rien d'autre. Cela tient sur un portable et suffit longtemps.

10 Go – 1 To, petite équipe
  stockage objet (S3) partitionné + DuckDB ou PostgreSQL
  + dbt + un orchestrateur léger (Dagster, Prefect)

1 To – 100 To, plusieurs équipes
  entrepôt distribué (BigQuery, Snowflake, ClickHouse)
  + format de table ouvert (Iceberg, Delta) + dbt + Airflow
  + contrats de données à la frontière

> 100 To, ou besoin de latence inférieure à la minute
  ajouter Kafka et un moteur de flux (Flink, Spark Structured Streaming)
  ─ et seulement alors.

La suite du cours quitte la plomberie pour les mathématiques : le module 8 reprend l'optimisation et l'algèbre linéaire dont tout le machine learning découle. On retrouvera l'ingénierie des données au module 28, où le projet de bout en bout construit un pipeline complet — scraping, validation, base PostgreSQL, ingestion idempotente — en appliquant chacune des règles ci-dessus.

Presque tout l'apprentissage automatique se ramène à deux objets : un problème d'optimisation que l'on résout par descente de gradient, et des décompositions matricielles qui révèlent la structure des données. Ce module traite les deux depuis le problème qu'ils posent, avec une insistance particulière sur la SVD et la PCA — les deux outils qui reviennent partout, de la compression à la détection d'anomalies.

1. Apprendre, c'est minimiser un risque

On cherche une fonction \(f_\theta\), paramétrée par \(\theta\), qui prédit \(y\) à partir de \(x\). L'idéal serait de minimiser le risque, c'est-à-dire l'erreur moyenne sur la distribution réelle des données :

Mais cette distribution \(\mathcal{D}\) est inconnue : on n'observe qu'un échantillon. On minimise donc le risque empirique, la moyenne de l'erreur sur les données dont on dispose, complété d'un terme de régularisation qui pénalise la complexité :

Tout le vocabulaire du ML se lit dans cette formule, et il vaut la peine de s'y arrêter. La fonction de perte \(\ell\) encode ce que l'on considère comme une erreur — c'est un choix, pas une donnée. Le surapprentissage est exactement l'écart entre \(\hat R\), que l'on minimise, et \(R\), qui nous intéresse : un modèle peut atteindre un risque empirique nul en mémorisant les données sans rien avoir appris. La régularisation \(\Omega\) — typiquement \(\|\theta\|_2^2\) ou \(\|\theta\|_1\) — restreint l'espace des fonctions accessibles pour réduire cet écart ; le module 10 montre qu'elle équivaut à une croyance a priori sur l'ordre de grandeur des paramètres.

Quadratique   (ŷ - y)²            régression. Pénalise les grandes erreurs au CARRÉ :
                                  un point aberrant tire tout le modèle vers lui.
Absolue (MAE) |ŷ - y|             robuste aux aberrants, non dérivable en 0.
Huber         quadratique près    le compromis : quadratique au centre, linéaire
              de 0, linéaire loin  au-delà d'un seuil δ.
Entropie      -Σ y_k log(ŷ_k)     classification. Pénalise la CONFIANCE dans une
croisée                           erreur, pas seulement l'erreur.
Hinge         max(0, 1 - y·ŷ)     marge (SVM, module 14).
Pinball       asymétrique         régression sur un quantile (module 17).

2. Descente de gradient : le mécanisme

Le gradient \(\nabla \hat R(\theta)\) est le vecteur des dérivées partielles : il pointe dans la direction de plus forte croissance de la fonction. Pour minimiser, on avance donc à l'opposé, d'un pas \(\eta\) appelé taux d'apprentissage :

L'image usuelle est celle d'un randonneur dans le brouillard : il ne voit pas la vallée, mais il sent la pente sous ses pieds et descend dans la direction la plus raide. Deux questions se posent immédiatement, et ce sont les seules qui comptent : quelle taille de pas ? et quand s'arrêter ?

import numpy as np

def descente(X, y, eta=0.01, n_iter=1000):
    """Régression linéaire par descente de gradient, sans bibliothèque."""
    n, p = X.shape
    theta = np.zeros(p)
    historique = []

    for t in range(n_iter):
        residus = X @ theta - y                 # erreur de prédiction
        perte = (residus ** 2).mean()           # risque empirique (MSE)
        gradient = 2 / n * X.T @ residus        # dérivée analytique du MSE
        theta -= eta * gradient                 # LE pas de descente
        historique.append(perte)

        if t > 0 and abs(historique[-2] - perte) < 1e-10:   # critère d'arrêt
            break
    return theta, historique

η trop petit (1e-5)    la perte descend, mais il faudrait 100 000 itérations.
                       Symptôme : courbe presque plate, qui descend encore à la fin.

η bien réglé (1e-2)    décroissance rapide puis plateau. C'est ce qu'on veut.

η trop grand (1.0)     la perte OSCILLE, puis explose vers l'infini ou NaN.
                       Symptôme : perte qui remonte, ou nan au bout de 3 itérations.

  perte │╲                      perte │╲    ╱╲                perte │╲
        │ ╲___                        │ ╲__╱  ╲                     │ ╲
        │     ╲____                   │        ╲_                   │  ╲___________
        └──────────── trop petit      └──────────── trop grand      └──────── correct

Deux garde-fous théoriques valent d'être connus. Si \(\hat R\) est convexe — une seule vallée, pas de minimum local — et si son gradient est \(L\)-lipschitzien, la méthode converge vers le minimum global pour tout \(0 \lt \eta \lt 2/L\), où \(L\) est la plus grande courbure de la fonction. En pratique on ne connaît pas \(L\), d'où la recherche empirique du taux (module 16). Et en deep learning, la fonction n'est pas convexe : on ne cherche plus le minimum global, on se contente d'un bon minimum local — ce qui, empiriquement, suffit largement.

3. Pourquoi ça converge lentement

Pour une fonction quadratique de matrice hessienne \(H\) (la matrice des dérivées secondes, qui décrit la courbure), la vitesse de convergence dépend du conditionnement \(\kappa = \lambda_{\max}/\lambda_{\min}\), rapport de la plus grande à la plus petite valeur propre. L'erreur décroît comme :

Pour \(\kappa = 10\), le facteur vaut 0,82 par itération : la convergence est rapide. Pour \(\kappa = 10^4\), il vaut 0,9998 : il faut des dizaines de milliers d'itérations pour progresser.

  κ ≈ 1 : lignes de niveau CIRCULAIRES     κ ≫ 1 : vallée ALLONGÉE
  le gradient pointe vers le minimum        le gradient pointe vers les PAROIS

        ╭───────╮                          ╭─────────────────────────╮
      ╭─┤   ·───┼─► minimum              ╭─┤ ·╲                      │
      │ ╰───────╯                        │ │   ╲╱╲╱╲╱╲──► minimum    │
      ╰─────────╯                        │ ╰──────────────────────── ╯
                                         ╰───────────────────────────╯
      trajet direct                       zigzag : on rebondit d'une paroi à l'autre
                                          et on avance très peu dans le bon sens

4. SGD, momentum, Adam

Le problème du coût

Calculer \(\nabla \hat R\) demande de parcourir les \(n\) exemples. Avec un million d'images, un seul pas devient hors de prix — et il en faut des milliers. La descente stochastique (SGD) estime le gradient sur un petit lot tiré au hasard :

L'estimation est bruitée mais non biaisée — elle vise juste en moyenne — et surtout mille fois moins coûteuse. On fait donc mille pas approximatifs au lieu d'un pas exact, un échange presque toujours gagnant. Le bruit a même une vertu : il aide à s'échapper des points selles, ces zones plates qui ne sont ni des minima ni des maxima et qui sont omniprésentes en grande dimension — bien plus que les minima locaux, contrairement à une idée reçue.

Momentum : lisser la trajectoire

Pour traverser la vallée allongée de la section précédente sans zigzaguer, on accumule une vitesse, comme une bille lourde qui ne change pas de direction à chaque bosse :

Avec \(\beta = 0{,}9\), le pas effectif est amplifié d'un facteur \(1/(1-\beta) = 10\) dans les directions où le gradient reste constant, tandis que les composantes qui oscillent s'annulent d'un pas sur l'autre. La variante de Nesterov évalue le gradient au point extrapolé plutôt qu'au point courant, ce qui la rend un peu plus stable.

Adam : un taux par paramètre

L'idée des méthodes adaptatives : les paramètres n'ont pas tous la même échelle de gradient, donc pas la même taille de pas idéale. Adam combine le momentum (moment d'ordre 1) et une normalisation par l'amplitude typique du gradient (moment d'ordre 2) :

Le rapport \(\hat m_t / \sqrt{\hat v_t}\) est une sorte de « rapport signal sur bruit » du gradient : un paramètre dont le gradient est constamment dans le même sens avance vite, un paramètre dont le gradient oscille avance lentement. Les corrections de biais \(\hat m, \hat v\) compensent l'initialisation à zéro des moments, qui sous-estimerait fortement les premiers pas. Valeurs usuelles : \(\beta_1 = 0{,}9\), \(\beta_2 = 0{,}999\), \(\varepsilon = 10^{-8}\).

def adam(gradient_fn, theta, eta=1e-3, b1=0.9, b2=0.999, eps=1e-8, n_iter=1000):
    m = np.zeros_like(theta)          # moyenne mobile du gradient
    v = np.zeros_like(theta)          # moyenne mobile du gradient AU CARRÉ

    for t in range(1, n_iter + 1):
        g = gradient_fn(theta)
        m = b1 * m + (1 - b1) * g
        v = b2 * v + (1 - b2) * g ** 2
        m_corr = m / (1 - b1 ** t)    # correction de biais : sans elle, les premiers
        v_corr = v / (1 - b2 ** t)    # pas seraient beaucoup trop petits
        theta -= eta * m_corr / (np.sqrt(v_corr) + eps)
    return theta

AdamW corrige un défaut subtil mais réel : dans Adam, la pénalité \(L^2\) ajoutée à la perte est elle aussi divisée par \(\sqrt{\hat v_t}\), si bien que la régularisation n'est plus uniforme entre paramètres. AdamW découple la décroissance des poids du gradient adaptatif ; c'est aujourd'hui le choix par défaut pour les transformers.

SGD + momentum   converge souvent vers de MEILLEURS minima (meilleure généralisation),
                 mais demande un réglage soigneux du taux et d'un planificateur.
                 Référence en vision, pour des CNN entraînés de zéro.
Adam / AdamW     robuste, marche presque tout de suite. Défaut en NLP, transformers,
                 et sur tout problème aux gradients hétérogènes ou creux.
L-BFGS           second ordre approché : excellent sur les petits problèmes lisses et
                 déterministes (peu de paramètres, pas de mini-lots). Inutilisable en
                 deep learning : mémoire et incompatibilité avec le bruit stochastique.

Planification et écrêtage

Un taux constant finit par empêcher la convergence fine : on tourne autour du minimum sans jamais s'en approcher. On le fait donc décroître. Le schéma cosine annealing avec warmup est devenu standard : quelques centaines de pas de montée linéaire — le temps que les statistiques des moments adaptatifs se stabilisent —, puis une décroissance en cosinus jusqu'à presque zéro.

S'y ajoute le gradient clipping, qui borne la norme du gradient : \(g \leftarrow \min(1, c/\|g\|)\,g\). Un seul lot atypique peut produire un gradient énorme qui projette les paramètres dans une zone absurde et détruit des heures d'entraînement ; l'écrêtage garde la direction mais limite la longueur du pas. Indispensable sur les RNN et les transformers.

opt = torch.optim.AdamW(modele.parameters(), lr=3e-4, weight_decay=0.01)
sched = torch.optim.lr_scheduler.OneCycleLR(opt, max_lr=3e-4,
                                            total_steps=n_epoques * len(chargeur))
for xb, yb in chargeur:
    opt.zero_grad(set_to_none=True)
    perte_fn(modele(xb), yb).backward()
    torch.nn.utils.clip_grad_norm_(modele.parameters(), max_norm=1.0)   # écrêtage
    opt.step()
    sched.step()                                    # le taux évolue à CHAQUE pas

5. Algèbre linéaire : résoudre sans inverser

La règle la plus utile de tout ce module : on n'inverse jamais une matrice. Pour résoudre \(Ax = b\), calculer \(A^{-1}\) puis multiplier coûte environ deux fois plus cher et est numériquement bien moins stable que de résoudre directement le système. L'inverse est un objet mathématique commode, pas un objet numérique.

import numpy as np
from scipy.linalg import cho_factor, cho_solve

# À NE PAS FAIRE
x = np.linalg.inv(A) @ b

# À FAIRE : factorisation LU avec pivot
x = np.linalg.solve(A, b)

# Si A est symétrique définie positive (matrice de covariance, noyau de GP) :
# Cholesky, deux fois plus rapide encore
c, low = cho_factor(A)
x = cho_solve((c, low), b)

# Si le système est surdéterminé (moindres carrés) : QR, sans jamais former AᵀA
beta, residus, rang, valeurs_sing = np.linalg.lstsq(A, b, rcond=None)

LU        A = PLU     systèmes carrés généraux               O(n³/3)
Cholesky  A = LLᵀ     A symétrique définie positive          O(n³/6) — la plus rapide
QR        A = QR      moindres carrés, orthogonalisation     O(2mn²)
Spectrale A = QΛQᵀ    A symétrique : axes et valeurs propres réels
SVD       A = UΣVᵀ    TOUTE matrice, même rectangulaire      la plus informative

Le cas des moindres carrés

La solution analytique \(\hat\beta = (X^\top X)^{-1} X^\top y\) est correcte en mathématiques et dangereuse en calcul : former \(X^\top X\) élève le conditionnement au carré, puisque \(\kappa(X^\top X) = \kappa(X)^2\). Avec des variables corrélées — donc un \(\kappa(X)\) déjà élevé —, la précision s'effondre, et l'on peut obtenir des coefficients aberrants sur des données parfaitement propres. C'est pourquoi lstsq passe par une QR ou une SVD, et pourquoi sklearn.linear_model.LinearRegression appelle scipy.linalg.lstsq plutôt que la formule fermée.

6. La SVD, en détail

La décomposition en valeurs singulières s'applique à n'importe quelle matrice réelle \(A\) de taille \(m \times n\) — carrée ou non, inversible ou non :

avec \(U\) et \(V\) orthogonales (\(U^\top U = I\) : leurs colonnes forment une base orthonormée) et \(\Sigma\) diagonale à coefficients positifs décroissants \(\sigma_1 \geq \sigma_2 \geq \dots \geq 0\), les valeurs singulières.

Intuition géométrique

Toute application linéaire, aussi compliquée soit-elle, se décompose en trois opérations élémentaires : une rotation (\(V^\top\)), une dilatation selon les axes (\(\Sigma\)), une seconde rotation (\(U\)). Autrement dit, l'image de la sphère unité par \(A\) est toujours un ellipsoïde : les \(\sigma_i\) sont les longueurs de ses demi-axes, et les colonnes de \(U\) leurs directions. Une valeur singulière quasi nulle signifie que \(A\) écrase complètement une direction de l'espace — c'est la signature d'une redondance dans les données.

Liens utiles

• \(A^\top A = V \Sigma^\top\Sigma V^\top\) : les \(\sigma_i^2\) sont les valeurs propres de \(A^\top A\), et \(V\) en donne les vecteurs propres. Calculer la SVD directement reste plus stable que diagonaliser \(A^\top A\), pour la raison de conditionnement vue plus haut.
• Le rang de \(A\) est le nombre de \(\sigma_i\) non nuls ; numériquement, le nombre de \(\sigma_i\) au-dessus d'un seuil.
• Le conditionnement vaut \(\kappa = \sigma_1/\sigma_r\) : la SVD le donne donc directement.
• La pseudo-inverse \(A^{+} = V\Sigma^{+}U^\top\) (où \(\Sigma^+\) inverse les \(\sigma_i\) non nuls et laisse les autres à zéro) fournit la solution de norme minimale des moindres carrés, y compris pour un système sous-déterminé.

Approximation de rang faible : Eckart–Young

En ne gardant que les \(k\) premiers termes de la somme :

on obtient la meilleure approximation de rang \(k\) qui existe, au sens des normes de Frobenius et spectrale. Aucune autre matrice de rang \(k\), obtenue par quelque méthode que ce soit, ne fait mieux — et l'erreur commise est connue exactement :

Ce théorème fonde la compression par SVD, la PCA, le débruitage et les systèmes de recommandation par factorisation matricielle (module 23).

import numpy as np, matplotlib.pyplot as plt

img = plt.imread("photo.png").mean(axis=2)          # niveaux de gris, (m, n)
U, s, Vt = np.linalg.svd(img, full_matrices=False)

# combien de composantes pour conserver 95 % de "l'énergie" ?
energie = np.cumsum(s ** 2) / np.sum(s ** 2)
k = int(np.searchsorted(energie, 0.95) + 1)

approx = (U[:, :k] * s[:k]) @ Vt[:k]                # reconstruction de rang k
taux = k * (img.shape[0] + img.shape[1] + 1) / img.size
print(f"k={k} : {taux:.1%} des coefficients d'origine, 95 % de l'énergie conservée")
# une photo 1024×1024 se reconstruit souvent avec k ≈ 60, soit 12 % des données

Où la SVD apparaît

• PCA — section suivante : c'est littéralement une SVD des données centrées ;
• Ridge — la régularisation s'y lit comme un filtrage spectral (voir plus bas) ;
• LSA — réduction d'une matrice terme-document, ancêtre des embeddings (module 22) ;
• Recommandation — factorisation d'une matrice utilisateurs × items très creuse (module 23) ;
• Débruitage et détection d'anomalies — le signal se concentre dans les grandes valeurs singulières, le bruit se répartit sur les petites ;
• Réduction de modèle — la POD des simulations physiques est une SVD de champs (module 21) ;
• LoRA — l'adaptation de LLM par matrices de rang faible repose sur la même intuition (module 22).

Ridge vu par la SVD

En écrivant \(X = U\Sigma V^\top\), la prédiction de la régression ridge devient :

La lecture est limpide : ridge projette \(y\) sur les directions principales et rétrécit chacune d'un facteur \(\sigma_i^2/(\sigma_i^2+\lambda)\), compris entre 0 et 1. Les directions de forte variance (\(\sigma_i^2 \gg \lambda\)) sont conservées presque intactes ; celles de faible variance — précisément celles où l'estimation est instable — sont écrasées. La régularisation n'est donc pas un bricolage numérique : c'est un filtrage spectral qui atténue ce qui est mal déterminé.

7. La PCA, en détail

L'analyse en composantes principales cherche un système d'axes orthogonaux, ordonnés, sur lesquels projeter les données en perdant le moins d'information possible.

Deux formulations équivalentes

Variance maximale. On cherche la direction unitaire \(w\) qui maximise la variance des projections. Avec \(X\) centré et \(C = \frac{1}{n-1}X^\top X\) la matrice de covariance :

Le lagrangien \(w^\top C w - \lambda(w^\top w - 1)\), dérivé et annulé, donne \(Cw = \lambda w\) : les directions principales sont les vecteurs propres de la covariance, et la variance capturée par chacune est sa valeur propre. On itère en imposant l'orthogonalité aux directions déjà retenues.

Erreur de reconstruction minimale. On cherche le sous-espace de dimension \(k\) minimisant \(\sum_i \|x_i - \Pi_k x_i\|^2\), où \(\Pi_k\) est la projection sur ce sous-espace. C'est exactement le problème d'Eckart–Young : la solution est donnée par les \(k\) premiers vecteurs singuliers. Les deux formulations coïncident — maximiser la variance conservée, c'est minimiser ce qu'on jette.

Le lien avec la SVD

Si \(X\) (centré) se décompose en \(U\Sigma V^\top\), alors \(C = \frac{1}{n-1}V\Sigma^2V^\top\). Donc :

• les axes principaux sont les colonnes de \(V\) (les loadings) ;
• les composantes principales (coordonnées projetées, ou scores) valent \(XV = U\Sigma\) ;
• la variance expliquée par l'axe \(i\) vaut \(\sigma_i^2/(n-1)\).

C'est pourquoi toutes les implémentations sérieuses passent par la SVD de \(X\) plutôt que par la diagonalisation de \(X^\top X\) : même résultat, bien meilleure stabilité numérique.

import numpy as np
from sklearn.decomposition import PCA
from sklearn.preprocessing import StandardScaler

X = np.random.randn(500, 20) @ np.random.randn(20, 20)   # données corrélées

# ── version manuelle ──
Xs = StandardScaler().fit_transform(X)          # centrer ET réduire (voir encadré)
U, s, Vt = np.linalg.svd(Xs, full_matrices=False)

scores = U * s                                   # = Xs @ Vt.T : les composantes
var_expliquee = s ** 2 / np.sum(s ** 2)
print(np.cumsum(var_expliquee)[:5])              # part de variance cumulée

# reconstruction avec k composantes, et erreur associée
k = 5
X_reconstruit = scores[:, :k] @ Vt[:k]
erreur = np.linalg.norm(Xs - X_reconstruit) ** 2 / np.linalg.norm(Xs) ** 2
print(f"erreur relative avec {k} composantes : {erreur:.1%}")

# ── version scikit-learn (identique, au signe des axes près) ──
pca = PCA(n_components=0.95)                     # garder 95 % de la variance
Z = pca.fit_transform(Xs)
print(Z.shape, pca.explained_variance_ratio_.sum())
print(pca.components_[0])                        # le premier axe, en fonction des variables

Combien de composantes garder ?

• Variance cumulée — le plus courant : garder 90 ou 95 % de la variance ;
• Coude du scree plot — la rupture de pente du spectre des \(\sigma_i^2\), là où les composantes suivantes n'apportent presque plus rien ;
• Critère de Kaiser — sur données standardisées, garder les valeurs propres supérieures à 1 : une composante doit expliquer plus qu'une variable d'origine ; grossier mais commode ;
• Validation croisée — si la PCA sert d'étape de prétraitement, le nombre de composantes est un hyperparamètre comme un autre, à optimiser sur la performance finale.

Interpréter, et ne pas sur-interpréter

Les loadings (colonnes de \(V\)) disent comment chaque variable d'origine contribue à chaque axe : ils permettent parfois de nommer un axe — « taille globale », « contraste chaud/froid ». Mais une composante principale reste une combinaison linéaire de toutes les variables : elle n'a aucune raison d'avoir un sens physique, et le signe des axes est arbitraire (rien ne distingue \(w\) de \(-w\)). Pour une décomposition interprétable à coefficients positifs, la NMF est souvent plus parlante ; pour séparer des sources indépendantes, c'est l'ICA.

Usages, limites et variantes

Décorréler des variables     les composantes sont orthogonales par construction
Compresser / débruiter       le bruit se disperse dans les petites valeurs propres
Visualiser en 2D             projection sur les 2 axes de plus forte variance
Accélérer un modèle          moins de dimensions = moins de calcul
Détecter des anomalies       erreur de reconstruction élevée = point atypique
Traiter la colinéarité       évite l'explosion de variance des coefficients

Limites. La PCA est linéaire : elle ne capture pas une variété courbe (un rouleau enroulé sur lui-même). Elle est non supervisée : rien ne garantit que les axes de forte variance soient ceux qui prédisent \(y\) — on peut parfaitement jeter la direction la plus informative, ce que corrigent la PLS ou une LDA en classification. Elle est sensible aux valeurs aberrantes, puisqu'une variance se calcule au carré. Et elle détruit l'interprétabilité des variables d'origine.

Variantes utiles : IncrementalPCA (par lots, pour des données hors mémoire), la version randomisée (par défaut dans scikit-learn dès que la matrice est grande), la kernel PCA (version non linéaire par astuce du noyau, module 14), la sparse PCA (axes à peu de variables non nulles, donc lisibles), et pour la visualisation pure, UMAP ou t-SNE — non linéaires, excellents visuellement, mais non paramétriques, non reproductibles d'une exécution à l'autre, et dont les distances entre groupes ne veulent rien dire.

8. Métriques d'évaluation

Une métrique traduit un objectif métier en un nombre à optimiser. Se tromper de métrique, c'est optimiser efficacement la mauvaise chose — et c'est irrattrapable par la suite.

Régression

MSE    moyenne des carrés d'erreur    pénalise fortement les grandes erreurs
RMSE   racine du MSE                  même unité que la cible : interprétable
MAE    moyenne des écarts absolus     robuste aux aberrants ; erreur "typique"
MAPE   erreur relative en %           parlante, mais explose si y proche de 0
                                      et pénalise plus les surestimations
R²     1 - SSE/SST                    part de variance expliquée ; peut être NÉGATIF
                                      si le modèle fait pire que la moyenne

RMSE et MAE ne répondent pas à la même question, et ce n'est pas un détail : minimiser le RMSE conduit à prédire la moyenne conditionnelle, minimiser le MAE la médiane conditionnelle. Sur des données à queue lourde — des prix, des durées — les deux modèles optimaux diffèrent réellement, et le choix doit venir de l'usage.

Classification

Tout part de la matrice de confusion, qui croise vérité et prédiction :

                    prédit positif      prédit négatif
  réel positif      VP (vrai positif)   FN (faux négatif) ← on l'a raté
  réel négatif      FP (faux positif)   VN (vrai négatif)
                    ↑ fausse alerte

La précision répond à « parmi mes alertes, combien sont justes ? », le rappel à « parmi les cas réels, combien ai-je attrapés ? ». Les deux s'opposent par le seuil de décision : le baisser augmente le rappel et dégrade la précision. Le \(F_1\) est leur moyenne harmonique, qui pénalise le déséquilibre entre les deux.

from sklearn.metrics import (classification_report, confusion_matrix,
                             roc_auc_score, average_precision_score,
                             log_loss, brier_score_loss)

p = modele.predict_proba(X_test)[:, 1]
y_pred = (p >= 0.5).astype(int)

print(confusion_matrix(y_test, y_pred))
print(classification_report(y_test, y_pred, digits=3))   # précision, rappel, F1 par classe
print("ROC-AUC :", roc_auc_score(y_test, p))
print("PR-AUC  :", average_precision_score(y_test, p))   # à préférer en déséquilibre
print("log-loss:", log_loss(y_test, p))                  # évalue les PROBABILITÉS
print("Brier   :", brier_score_loss(y_test, p))          # calibration

Deux métriques souvent oubliées et pourtant essentielles : la log-loss \(-\frac{1}{n}\sum_i [y_i\log p_i + (1-y_i)\log(1-p_i)]\), qui évalue les probabilités et non les décisions, et le score de Brier (erreur quadratique sur les probabilités), qui mesure la calibration. Un modèle peut parfaitement ordonner les cas — bonne AUC — tout en annonçant des probabilités fausses, ce qui rend inexploitable toute décision fondée sur un coût attendu (module 24). On corrige par calibration isotonique ou de Platt (module 14).

Enfin, l'accuracy est une métrique piégeuse : sur un problème à 99 % de négatifs, prédire toujours « négatif » donne 99 % d'accuracy et un modèle sans aucune valeur. La bonne démarche part du coût métier : si un faux négatif coûte cent fois un faux positif, ce rapport doit apparaître dans le choix du seuil — c'est l'objet du module 24.

Un modèle donne des nombres ; la statistique inférentielle dit lesquels sont crédibles. C'est ce qui sépare « la variante B a fait +2,3 % » de « la variante B est meilleure ». Ce module traite les p-values et les tests d'hypothèse pour ce qu'ils sont — des outils précis, très souvent mal interprétés — puis la question qui compte vraiment : quand a-t-on le droit de parler de cause ?

1. Échantillon, estimateur, variabilité

On veut connaître une quantité \(\theta\) d'une population — une moyenne, une proportion, un écart — mais on n'observe qu'un échantillon de taille \(n\). On calcule alors un estimateur \(\hat\theta\), et voici le point central : cet estimateur est lui-même une variable aléatoire. Un autre échantillon aurait donné une autre valeur. Toute la statistique inférentielle consiste à quantifier cette variabilité, pour savoir ce que l'on peut affirmer malgré elle.

import numpy as np
rng = np.random.default_rng(0)

# une population dont on connaît la vérité : moyenne 100, écart type 15
population = rng.normal(100, 15, size=1_000_000)

# on tire 10 000 échantillons de 30 individus et on regarde varier LA MOYENNE
moyennes = np.array([rng.choice(population, 30).mean() for _ in range(10_000)])

print(f"moyenne des moyennes : {moyennes.mean():.2f}")       # ≈ 100  → sans biais
print(f"dispersion observée  : {moyennes.std():.2f}")        # ≈ 2.74
print(f"prédiction théorique : {15 / np.sqrt(30):.2f}")      # ≈ 2.74  ✓
print(f"étendue              : {moyennes.min():.1f} à {moyennes.max():.1f}")
# ≈ 89 à 111 : avec 30 individus, une moyenne d'échantillon peut s'écarter
# de 10 points de la vérité, sans que rien ne soit anormal.

Deux résultats suffisent à presque tout. La loi des grands nombres garantit que \(\bar X_n \to \mu\). Le théorème central limite précise à quelle vitesse et sous quelle forme :

Sa portée est remarquable : quelle que soit la forme de la distribution d'origine — asymétrique, discrète, bimodale —, la moyenne d'un échantillon suffisamment grand suit approximativement une loi normale. C'est ce qui rend les outils qui suivent applicables sans connaître la loi des données.

L'erreur type \(\sigma/\sqrt{n}\) décroît en \(1/\sqrt{n}\) : diviser l'incertitude par deux demande quatre fois plus de données, par dix en demande cent fois plus. C'est la contrainte économique de fond de toute expérimentation, et elle explique pourquoi les gains de précision deviennent vite hors de prix.

2. Intervalles de confiance

Plutôt qu'une valeur unique, on donne un intervalle qui reflète l'incertitude. Pour une moyenne :

La loi de Student remplace la loi normale parce que \(\sigma\) est lui-même estimé par \(s\), ce qui ajoute de l'incertitude ; l'écart n'est appréciable qu'en dessous de \(n \approx 30\), au-delà les deux coïncident presque.

from scipy import stats

couverts = 0
for _ in range(10_000):
    ech = rng.normal(100, 15, size=30)
    bas, haut = stats.t.interval(0.95, df=29, loc=ech.mean(),
                                 scale=stats.sem(ech))
    couverts += (bas <= 100 <= haut)          # la vraie valeur est-elle dedans ?

print(f"couverture réelle : {couverts / 10_000:.1%}")    # ≈ 95,0 % ✓

Pour une proportion, l'intervalle normal usuel \(\hat p \pm z\sqrt{\hat p(1-\hat p)/n}\) se comporte mal quand \(\hat p\) est proche de 0 ou 1 : il peut sortir de l'intervalle [0, 1], et sa couverture réelle chute bien en dessous de 95 %. L'intervalle de Wilson corrige cela et devrait être le choix par défaut :

from statsmodels.stats.proportion import proportion_confint
proportion_confint(count=7, nobs=100, method="wilson")    # (0.034, 0.139)
proportion_confint(count=7, nobs=100, method="normal")    # (0.020, 0.120) — trop étroit

3. Le bootstrap

Pour une médiane, un coefficient de Gini, un R², un ratio de métriques — bref dès que la loi de l'estimateur n'a pas de forme analytique commode — il n'existe pas de formule d'intervalle. Le bootstrap résout cela par une idée d'une simplicité déconcertante : l'échantillon est notre meilleure approximation de la population, alors tirons dedans avec remise et regardons varier la statistique. On simule ainsi la variabilité d'échantillonnage sans nouvelle collecte.

import numpy as np
from scipy import stats

rng = np.random.default_rng(0)
x = rng.lognormal(mean=1.0, sigma=1.2, size=200)     # distribution très asymétrique

# ── bootstrap "à la main", pour voir le mécanisme ──
idx = rng.integers(0, len(x), size=(10_000, len(x)))  # 10 000 rééchantillonnages
medianes = np.median(x[idx], axis=1)                  # la statistique sur chacun
ic_percentile = np.percentile(medianes, [2.5, 97.5])  # l'intervalle empirique

# ── version scipy, avec correction BCa (biais + asymétrie) : plus fiable ──
res = stats.bootstrap((x,), np.median, confidence_level=0.95,
                      n_resamples=10_000, method="BCa", random_state=0)
print(ic_percentile, res.confidence_interval)

Le bootstrap est d'une généralité rare, mais il a ses limites : il suppose des observations indépendantes (pour des séries temporelles, il faut un bootstrap par blocs — module 17), il est mauvais pour les statistiques d'extrêmes (un maximum ne se rééchantillonne pas bien, puisqu'aucun tirage ne peut dépasser la valeur observée), et il ne crée pas d'information : sur douze observations, il reste douze observations.

4. Tests d'hypothèse et p-value

La démarche est celle d'un raisonnement par l'absurde probabiliste :

1. poser une hypothèse nulle \(H_0\) — « aucun effet », « les deux moyennes sont égales » ;
2. choisir une statistique de test \(T\) dont on connaît la loi sous \(H_0\) ;
3. calculer sa valeur \(t_{\text{obs}}\) sur les données observées ;
4. évaluer à quel point cette valeur serait surprenante si \(H_0\) était vraie.

Cette dernière quantité est la p-value :

# Situation : groupe A (n=40) et groupe B (n=40), on observe un écart de moyennes.
ecart_observe = b.mean() - a.mean()          # par exemple 1,8

# Sous H0, l'appartenance au groupe n'a AUCUN effet : les étiquettes sont
# interchangeables. On les mélange 100 000 fois pour voir quels écarts
# le hasard seul produit.
ensemble = np.concatenate([a, b])
ecarts_h0 = np.empty(100_000)
for i in range(100_000):
    melange = rng.permutation(ensemble)
    ecarts_h0[i] = melange[40:].mean() - melange[:40].mean()

p = np.mean(np.abs(ecarts_h0) >= abs(ecart_observe))
print(f"p-value (test de permutation) = {p:.4f}")
# La p-value est LITTÉRALEMENT la proportion de mondes "sans effet" dans lesquels
# le hasard produirait un écart au moins aussi grand que celui observé.

Ce test de permutation est intéressant à double titre : il ne suppose aucune loi particulière, et il rend la définition de la p-value concrète — c'est une fréquence, comptée dans un monde où l'hypothèse nulle serait vraie.

Le réflexe sain consiste à toujours rapporter trois choses ensemble : la taille d'effet (l'écart observé, dans son unité métier), son intervalle de confiance, et la p-value. L'intervalle contient à lui seul presque toute l'information utile — un IC qui exclut zéro dit exactement la même chose qu'un test significatif, en plus informatif, puisqu'il indique aussi l'ordre de grandeur de l'effet.

5. Erreurs, puissance, taille d'échantillon

                        H0 vraie en réalité       H0 fausse en réalité
Rejeter H0              ERREUR DE TYPE I (α)      décision correcte
                        "fausse découverte"       (puissance = 1 - β)
Ne pas rejeter H0       décision correcte         ERREUR DE TYPE II (β)
                                                  "on est passé à côté"

\(\alpha\) est choisi (5 % par convention) : c'est le taux de faux positifs qu'on accepte. \(\beta\) se subit, sauf si l'on dimensionne l'expérience à l'avance. La puissance \(1-\beta\) est la probabilité de détecter un effet qui existe réellement ; on la vise à 80 % ou 90 %.

Pour comparer deux moyennes, en notant \(d = |\mu_1-\mu_2|/\sigma\) la taille d'effet de Cohen (un écart exprimé en nombre d'écarts types), la taille par groupe nécessaire pour \(\alpha=5\%\) et une puissance de 80 % est bien approchée par :

Un effet « moyen » (\(d=0{,}5\)) demande donc environ 64 observations par groupe ; un petit effet (\(d=0{,}2\)) en demande 400 ; un très petit effet (\(d=0{,}05\)) en demande 6 400. Cette formule, faite de tête avant de lancer une expérience, évite de collecter des données qui n'avaient aucune chance de conclure.

from statsmodels.stats.power import TTestIndPower

n = TTestIndPower().solve_power(effect_size=0.3, alpha=0.05, power=0.8)
print(f"n = {np.ceil(n):.0f} par groupe")          # 176

# vérification empirique : on simule 10 000 expériences de cette taille
n = 176
rejets = sum(
    stats.ttest_ind(rng.normal(0, 1, n), rng.normal(0.3, 1, n)).pvalue < 0.05
    for _ in range(10_000)
)
print(f"puissance simulée = {rejets / 10_000:.1%}")   # ≈ 80 % ✓

6. Catalogue des tests usuels

Question                              Test                     Fonction
────────────────────────────────────────────────────────────────────────────────────
Moyenne = valeur de référence ?       t à un échantillon       stats.ttest_1samp
Deux groupes indépendants ?           t de WELCH (défaut !)    stats.ttest_ind(
                                                                 equal_var=False)
Avant/après sur les mêmes sujets ?    t apparié                stats.ttest_rel
Idem, sans hypothèse de normalité ?   Mann-Whitney / Wilcoxon  stats.mannwhitneyu
Plus de deux groupes ?                ANOVA / Kruskal-Wallis   stats.f_oneway, kruskal
Deux variables catégorielles liées ?  chi² d'indépendance      stats.chi2_contingency
Idem, petits effectifs (< 5) ?        test exact de Fisher     stats.fisher_exact
Deux proportions (A/B test) ?         test z de proportions    proportions_ztest
Même distribution ?                   Kolmogorov-Smirnov       stats.ks_2samp
Distribution normale ?                Shapiro-Wilk             stats.shapiro
Corrélation linéaire ? monotone ?     Pearson / Spearman       stats.pearsonr, spearmanr

Trois remarques valent mieux qu'un long tableau.

Le test de Welch doit être le défaut pour comparer deux groupes : il ne suppose pas l'égalité des variances, et il ne perd presque rien en puissance quand celles-ci sont effectivement égales. Le test de Student classique, lui, donne des résultats faux quand les variances diffèrent et que les groupes sont de tailles inégales — situation courante.

Les tests de normalité sont contre-productifs sur de grands échantillons : ils rejettent systématiquement pour des écarts sans conséquence pratique, alors que le TCL rend justement le test de Student robuste à la non-normalité dès que \(n\) dépasse quelques dizaines. Un histogramme et un QQ-plot informent mieux qu'une p-value de Shapiro.

Enfin, les tests non paramétriques ne comparent pas des moyennes mais des rangs. Mann-Whitney répond à « une valeur tirée de A a-t-elle tendance à dépasser une valeur tirée de B ? », ce qui n'est pas la même question qu'une différence de moyennes — deux distributions de moyennes identiques mais de formes différentes peuvent donner un résultat significatif.

7. Comparaisons multiples et p-hacking

Tester 20 hypothèses au seuil de 5 % alors qu'aucune n'est vraie donne une probabilité \(1 - 0{,}95^{20} \approx 64\%\) d'obtenir au moins un « résultat significatif ». C'est mécanique, et c'est la raison pour laquelle explorer librement un jeu de données produit toujours quelque chose.

Bonferroni         seuil α/m           contrôle le FWER (probabilité d'AU MOINS
                                       une fausse découverte). Simple, très conservateur.
Holm-Bonferroni    séquentiel          même garantie, uniformément plus puissant :
                                       à préférer systématiquement à Bonferroni.
Benjamini-Hochberg contrôle le FDR     accepte une PROPORTION q de faux parmi les
                                       rejets. Le bon choix quand on teste des
                                       centaines d'hypothèses (génomique, sélection
                                       de variables).

from statsmodels.stats.multitest import multipletests
rejets, p_corriges, _, _ = multipletests(p_values, alpha=0.05, method="holm")
rejets, p_corriges, _, _ = multipletests(p_values, alpha=0.05, method="fdr_bh")

La distinction entre les deux familles est importante. Bonferroni et Holm contrôlent la probabilité de commettre ne serait-ce qu'une fausse découverte : c'est adapté quand une erreur coûte cher (un essai clinique confirmatoire). Benjamini-Hochberg contrôle la proportion de fausses découvertes parmi les résultats déclarés positifs : sur 10 000 gènes testés, on accepte que 5 % des gènes retenus soient des faux positifs, ce qui est infiniment plus puissant et parfaitement raisonnable en phase exploratoire.

8. Corrélation, causalité, confondants

Une corrélation entre \(X\) et \(Y\) admet cinq explications : \(X\) cause \(Y\) ; \(Y\) cause \(X\) ; une variable \(Z\) cause les deux (confondant) ; l'échantillon a été sélectionné d'une façon qui crée l'association (biais de sélection) ; ou c'est le hasard. Rien dans les données seules ne permet de trancher — il faut une hypothèse sur le mécanisme, qui vient de la connaissance du domaine.

L'outil formel est le graphe causal (DAG) : on y dessine les relations supposées, et des règles graphiques disent quelles variables ajuster. Trois structures élémentaires suffisent à comprendre l'essentiel.

CHAÎNE        X ──► M ──► Y        M est un MÉDIATEUR (l'effet passe par lui)
              exemple : traitement → tension → infarctus
              → conditionner sur M SUPPRIME l'effet qu'on cherche à mesurer

FOURCHE       X ◄── Z ──► Y        Z est un CONFONDANT (cause commune)
              exemple : ventes de glaces ◄ chaleur ► noyades
              → il FAUT conditionner sur Z (critère de la porte dérobée)

COLLISIONNEUR X ──► C ◄── Y        C est un EFFET COMMUN
              exemple : talent ► être recruté ◄ apparence
              → conditionner sur C CRÉE une corrélation artificielle entre X et Y
              (parmi les recrutés, les moins talentueux sont les plus beaux :
               c'est un artefact de sélection, pas une réalité)

Le collisionneur est la source de biais la plus contre-intuitive, et la plus fréquente quand on « contrôle par tout ce qu'on a » : ajouter des variables à un modèle n'est pas neutre, cela peut fabriquer des associations qui n'existent pas.

La seule méthode qui élimine tous les confondants d'un coup, connus comme inconnus, est la randomisation : en tirant l'affectation au hasard, on rend le traitement indépendant de tout le reste, y compris de ce qu'on n'a pas mesuré. C'est pour cette raison que l'essai contrôlé randomisé — l'A/B test — est l'étalon-or.

Quand on ne peut pas randomiser, on s'appuie sur des méthodes quasi-expérimentales : différence-en-différences (deux groupes suivis avant et après), variables instrumentales, régression sur discontinuité, appariement sur score de propension. Toutes reposent sur des hypothèses non vérifiables à partir des données seules : elles doivent être argumentées explicitement, pas supposées silencieusement. Le module 11 est entièrement consacré à ces méthodes : ce qu'elles estiment exactement, ce qu'elles supposent, et comment vérifier ce qui est vérifiable.

9. Un A/B test de bout en bout

C'est l'exercice qui mobilise tout ce module. La séquence, dans l'ordre :

1. Définir la métrique principale — une seule, décidée à l'avance. Les autres sont des garde-fous (métriques de non-régression) ou de l'exploration.
2. Fixer l'effet minimal détectable — quel gain justifierait le changement ? Cette valeur vient du métier, pas des données.
3. Dimensionner — en déduire \(n\) et la durée. Couvrir des semaines entières : le comportement du lundi n'est pas celui du samedi.
4. Randomiser au bon niveau — par utilisateur, pas par session, sinon le même individu voit les deux variantes et les observations ne sont plus indépendantes.
5. Vérifier l'équilibre — un test A/A (deux groupes identiques, qui ne doivent rien montrer) et un contrôle du ratio de répartition (sample ratio mismatch) détectent les bugs d'assignation, cause numéro un des résultats invraisemblables.
6. Attendre la fin — regarder les résultats en continu et s'arrêter dès que \(p \lt 0{,}05\) fait exploser le taux de faux positifs bien au-delà de 5 %, parce qu'on multiplie les tests sans les compter. Si l'arrêt anticipé est nécessaire, il faut des méthodes conçues pour cela (tests séquentiels, bornes d'O'Brien-Fleming).
7. Analyser — effet, intervalle de confiance, puis p-value.

import numpy as np
from statsmodels.stats.proportion import proportions_ztest, confint_proportions_2indep

conv = np.array([1183, 1279])        # conversions A, B
n    = np.array([20_143, 20_089])    # visiteurs A, B

stat, p = proportions_ztest(conv, n)
lo, hi = confint_proportions_2indep(conv[1], n[1], conv[0], n[0], method="wald")

taux = conv / n
print(f"A = {taux[0]:.3%}, B = {taux[1]:.3%}")
print(f"écart absolu = {taux[1]-taux[0]:+.3%}  IC95 = [{lo:+.3%}, {hi:+.3%}]  p = {p:.4f}")
# A = 5.873%, B = 6.367%
# écart absolu = +0.494%  IC95 = [+0.031%, +0.957%]  p = 0.0366

La lecture correcte de ce résultat : l'écart estimé est de +0,49 point, et les données sont compatibles avec un gain compris entre +0,03 et +0,96 point. C'est significatif au seuil de 5 %, mais l'intervalle frôle zéro — autrement dit, il reste possible que le vrai gain soit négligeable. La décision dépend donc du coût de mise en œuvre et du gain minimal jugé pertinent (fixé à l'étape 2), pas du seul verdict binaire du test.

Le module 9 traite l'inférence fréquentiste : tests, intervalles de confiance, décisions binaires. Ce module prend l'autre point de vue — traiter les paramètres eux-mêmes comme des variables aléatoires — et aboutit à la question qui manque à la plupart des modèles de machine learning : à quel point cette prédiction est-elle sûre, et pourquoi ? Pour un ingénieur qui doit dimensionner une marge de sécurité, c'est souvent plus important que la précision moyenne.

1. Les lois usuelles comme briques de modélisation

Choisir une loi, c'est faire une hypothèse sur le mécanisme qui a engendré les données. L'essentiel du travail de modélisation probabiliste tient dans ce choix, et il se raisonne à partir du phénomène physique, pas à partir de l'allure de l'histogramme.

Bernoulli / Binomiale   succès-échec ; nombre de succès sur n essais indépendants
Poisson                 comptage d'événements RARES et INDÉPENDANTS dans un
                        intervalle fixe (désintégrations, pannes, arrivées).
                        Propriété : variance = espérance.
Binomiale négative      comptage SURDISPERSÉ (variance > espérance) : le cas réel
                        le plus fréquent, quand le taux varie d'une unité à l'autre.
Exponentielle           temps d'attente entre événements poissoniens. SANS MÉMOIRE :
                        avoir attendu 10 min ne change pas l'attente restante.
Weibull                 durée de vie à taux de défaillance variable : LA loi de la
                        fiabilité (k < 1 mortalité infantile, k > 1 usure) — module 17
Gamma                   somme d'exponentielles ; temps de service ; a priori de précision
Beta                    une proportion inconnue dans [0,1] : l'a priori naturel d'un taux
Normale                 SOMME de nombreux effets indépendants (TCL, module 9)
Log-normale             PRODUIT de nombreux effets : tailles, revenus, durées, prix
Student                 normale à queues épaisses : régression robuste aux aberrants
Dirichlet               une distribution sur des proportions qui somment à 1

2. Vraisemblance, MLE, MAP

La vraisemblance est la probabilité des données observées, vue comme une fonction du paramètre : \(\mathcal{L}(\theta) = p(y \mid \theta)\). Attention au renversement de perspective — ce n'est pas une densité de probabilité en \(\theta\), c'est la même formule lue « à l'envers » : les données sont fixées, le paramètre varie.

L'estimation du maximum de vraisemblance consiste à prendre le \(\theta\) qui rend les données observées les plus probables :

On travaille sur le logarithme pour deux raisons : il transforme un produit en somme (plus stable numériquement, un produit de milliers de probabilités valant zéro en virgule flottante), et il ne change pas l'argmax puisque le logarithme est croissant.

Bruit gaussien homoscédastique   → -log p ∝ (y - ŷ)²        = perte quadratique
Bernoulli                        → -log p = entropie croisée
Poisson                          → -log p = perte de Poisson (comptages)
Student                          → -log p ≈ perte robuste (queues épaisses)
Laplace                          → -log p ∝ |y - ŷ|         = MAE

Autrement dit : choisir une perte, c'est choisir un modèle de bruit. L'expliciter permet de le choisir correctement plutôt que par habitude — si les erreurs de mesure ont des queues épaisses, minimiser un MSE revient à supposer un bruit gaussien qu'on sait faux, et le modèle sera tiré par les aberrants.

En ajoutant un a priori \(p(\theta)\), on obtient l'estimateur du maximum a posteriori :

3. Bayes, avec un exemple chiffré

Le MAP ne retient qu'un point. L'approche bayésienne complète conserve toute la distribution :

L'interprétation est opérationnelle : l'a priori encode ce qu'on sait avant de regarder les données, la vraisemblance ce que les données disent, et l'a posteriori combine les deux en pondérant chacun par sa précision. Avec peu de données, l'a priori domine ; avec beaucoup, il s'efface. C'est un mécanisme de régularisation qui s'adapte automatiquement à la quantité d'information disponible.

4. Conjugaison et A/B test bayésien

Dans quelques cas heureux, l'a posteriori appartient à la même famille que l'a priori : on parle de conjugaison, et le calcul se réduit à une mise à jour de paramètres. Le cas Beta-Binomial est le plus utile :

La lecture est intuitive : \(\alpha\) et \(\beta\) se comportent comme des succès et des échecs « virtuels » observés avant l'expérience. Un a priori Beta(1,1) est uniforme — aucune opinion ; un Beta(30,70) affirme qu'on croit le taux proche de 30 %, avec la force de 100 observations.

import numpy as np
from scipy import stats

# mêmes données qu'au module 9, autre lecture
a_post = stats.beta(1 + 1183, 1 + 20_143 - 1183)      # variante A
b_post = stats.beta(1 + 1279, 1 + 20_089 - 1279)      # variante B

rng = np.random.default_rng(0)
ta, tb = a_post.rvs(200_000, random_state=rng), b_post.rvs(200_000, random_state=rng)

print(f"P(B meilleure que A)         = {(tb > ta).mean():.3f}")      # 0.982
print(f"gain relatif médian          = {np.median((tb - ta) / ta):+.2%}")
print(f"P(gain > 5 %)                = {((tb - ta) / ta > 0.05).mean():.3f}")
print(f"perte espérée si on choisit B = {np.maximum(ta - tb, 0).mean():.5f}")

La dernière ligne est ce qui manque à l'approche fréquentiste : la perte espérée en cas de mauvais choix, exprimée dans l'unité de la métrique. Elle transforme un résultat statistique en critère de décision — on arrête l'expérience quand le risque résiduel devient négligeable devant le coût d'attendre, et non quand une p-value franchit un seuil conventionnel. C'est le pont naturel vers le module 24.

5. MCMC : échantillonner un a posteriori

Dès que le modèle sort des cas conjugués, l'évidence \(p(y) = \int p(y\mid\theta)p(\theta)\,d\theta\) devient une intégrale incalculable : en dimension 50, aucune quadrature ne tient. La solution consiste à renoncer à calculer l'a posteriori pour se contenter d'y échantillonner — ce qui suffit, puisqu'avec des échantillons on obtient moyennes, quantiles, intervalles et probabilités par simple comptage.

Le procédé : construire une chaîne de Markov — une marche aléatoire dont chaque pas ne dépend que du précédent — conçue de sorte que, après une phase de chauffe, la fréquence de passage dans chaque région soit proportionnelle à la densité a posteriori. On laisse la chaîne courir, et les positions visitées sont l'échantillon recherché.

• Metropolis-Hastings — proposer un déplacement, l'accepter avec une probabilité qui compare les densités du point proposé et du point courant. La beauté du procédé : le rapport élimine la constante de normalisation inconnue, celle-là même qu'on ne sait pas calculer. Mais la marche aléatoire explore mal en grande dimension, où presque toutes les directions mènent vers des zones de faible densité.
• Gibbs — mettre à jour chaque coordonnée selon sa loi conditionnelle aux autres. Efficace si ces conditionnelles sont connues, très lent si les paramètres sont fortement corrélés.
• Hamiltonien (HMC) et NUTS — la méthode moderne. On introduit une variable d'impulsion et l'on simule une dynamique physique sur le paysage \(-\log p(\theta\mid y)\), vu comme une énergie potentielle : la « bille » suit les vallées au lieu de tâtonner. Le gradient guide la trajectoire, ce qui permet de parcourir de longues distances avec un taux d'acceptation élevé. NUTS choisit automatiquement la longueur de trajectoire, supprimant le principal réglage manuel. C'est ce qui a rendu l'inférence bayésienne praticable sur des modèles à centaines de paramètres.

6. Modèles hiérarchiques

C'est l'apport le plus utile du cadre bayésien en pratique. Situation typique : estimer un taux par site, par machine ou par client, alors que certains groupes n'ont que trois observations. Deux extrêmes également mauvais :

• Aucun regroupement — un modèle indépendant par groupe : un groupe avec 1 succès sur 1 essai affiche 100 %, ce qui est absurde.
• Regroupement total — une seule estimation globale : on efface toute différence réelle entre groupes.

Le modèle hiérarchique fait le regroupement partiel : les paramètres de groupe sont tirés d'une loi commune dont les paramètres sont eux-mêmes estimés à partir des données.

Chaque estimation de groupe est automatiquement tirée vers la moyenne globale, d'autant plus fortement que le groupe est petit ou bruité — un groupe de 3 observations sera presque ramené à la moyenne, un groupe de 3 000 gardera sa valeur propre. Le degré de rétrécissement n'est pas choisi à la main : il est appris à travers \(\tau\), qui mesure la dispersion réelle entre groupes. C'est exactement l'effet du lissage du target encoding (module 12), mais dérivé du modèle au lieu d'être un paramètre réglé au jugé.

import pymc as pm, arviz as az

with pm.Model(coords={"groupe": noms_groupes}) as modele:
    mu    = pm.Normal("mu", 0, 5)                 # moyenne globale
    tau   = pm.HalfNormal("tau", 2)               # dispersion ENTRE groupes
    sigma = pm.HalfNormal("sigma", 2)             # bruit INTRA-groupe

    # paramétrage NON CENTRÉ : on tire un z standard puis on le décale.
    # Mathématiquement équivalent, mais la géométrie devient beaucoup plus
    # facile à explorer pour NUTS (évite l'entonnoir et les divergences).
    z     = pm.Normal("z", 0, 1, dims="groupe")
    theta = pm.Deterministic("theta", mu + tau * z, dims="groupe")

    pm.Normal("obs", mu=theta[idx_groupe], sigma=sigma, observed=y)

    trace = pm.sample(2000, tune=1000, chains=4, target_accept=0.9)

print(az.summary(trace, var_names=["mu", "tau"]))   # r_hat, ess_bulk, intervalles
az.plot_forest(trace, var_names=["theta"])          # le rétrécissement, visible

7. Inférence variationnelle

MCMC est asymptotiquement exact mais coûteux : chaque itération évalue la vraisemblance sur toutes les données, ce qui devient impraticable sur des millions d'observations ou sur un réseau de neurones. L'inférence variationnelle transforme l'inférence en optimisation : on cherche, dans une famille paramétrée \(q_\phi\) (souvent des gaussiennes indépendantes), celle qui approche le mieux l'a posteriori au sens de la divergence de Kullback-Leibler. Cela revient à maximiser la borne inférieure de l'évidence :

Le premier terme demande de bien expliquer les données, le second de ne pas trop s'écarter de l'a priori : on retrouve la structure « ajustement + régularisation » de tout le cours. Avantage : un problème d'optimisation classique, compatible avec les mini-lots et le GPU (module 8). Inconvénient à connaître : une famille de gaussiennes indépendantes sous-estime systématiquement la variance a posteriori et ignore les corrélations entre paramètres. Les intervalles produits sont donc trop étroits — utilisables pour un ordre de grandeur, pas pour une marge de sécurité.

Les outils : PyMC (le plus accessible), NumPyro (sur JAX, très rapide), Stan (la référence historique). Tous partagent la même logique : on écrit le modèle génératif — comment les données auraient pu être produites — et l'inférence est prise en charge.

8. Aléatoire contre épistémique

Distinction fondamentale, et régulièrement ignorée :

ALÉATOIRE (aleatoric)            ÉPISTÉMIQUE (epistemic)
bruit intrinsèque du phénomène   ignorance du modèle
deux essais identiques donnent   le modèle n'a pas vu de données dans cette région
deux résultats différents
NE diminue PAS avec plus         DIMINUE avec plus de données
de données
ex : dispersion d'une mesure,    ex : prédire hors du domaine d'entraînement,
variabilité d'un matériau        extrapolation, régime jamais observé

La conséquence opérationnelle est directe. Une incertitude aléatoire élevée signifie qu'il faut dimensionner une marge : collecter plus de données n'y changera rien. Une incertitude épistémique élevée signifie que le modèle est hors de son domaine de validité : sa prédiction ne doit pas être utilisée, et c'est un signal pour collecter des données dans cette région (module 13) ou pour se replier sur une procédure de référence (module 24). Confondre les deux conduit soit à sur-dimensionner inutilement, soit à faire confiance à une extrapolation.

9. Quantifier l'incertitude d'un modèle

Régression quantile      entraîner sur la perte pinball aux quantiles 5 % et 95 %.
                         Capture l'incertitude ALÉATOIRE, y compris hétéroscédastique.
                         Disponible dans LightGBM et HistGradientBoosting : le
                         meilleur rapport effort/résultat sur données tabulaires.
Ensembles profonds       entraîner 5 réseaux avec des graines différentes ; la
                         dispersion des prédictions estime l'incertitude ÉPISTÉMIQUE.
                         Simple, robuste, la référence empirique — coût ×5.
MC dropout               laisser le dropout actif à l'inférence et échantillonner.
                         Bon marché, mais approximation grossière.
Sortie probabiliste      faire prédire au réseau moyenne ET variance (perte de
                         log-vraisemblance gaussienne) : sépare les deux incertitudes.
Bayésien complet         poids traités comme variables aléatoires (VI, SWAG).
                         Élégant, coûteux, rarement meilleur qu'un ensemble profond.
Processus gaussien       incertitude exacte par construction (module 19) — mais O(n³).
Prédiction conforme      garantie de couverture sur n'importe quel modèle déjà
                         entraîné (section suivante).

from lightgbm import LGBMRegressor

modeles = {}
for alpha in (0.05, 0.5, 0.95):
    modeles[alpha] = LGBMRegressor(objective="quantile", alpha=alpha,
                                   n_estimators=500).fit(X_tr, y_tr)

bas  = modeles[0.05].predict(X_te)
med  = modeles[0.50].predict(X_te)
haut = modeles[0.95].predict(X_te)

couverture = np.mean((y_te >= bas) & (y_te <= haut))
print(f"couverture empirique : {couverture:.1%}")   # visée : 90 %
# largeur variable selon les points : c'est le signe d'un bruit hétéroscédastique

10. Prédiction conforme

La prédiction conforme est, à mon sens, la technique la plus sous-utilisée du domaine. Elle fournit un intervalle de prédiction avec une garantie de couverture valable à échantillon fini, sans aucune hypothèse sur la distribution des données ni sur le modèle — seulement l'échangeabilité des observations, c'est-à-dire le fait que l'ordre n'a pas d'importance.

La version par découpage tient en trois étapes. On met de côté un jeu de calibration, disjoint de l'entraînement. On y calcule les scores de non-conformité \(s_i = |y_i - \hat f(x_i)|\) — à quel point le modèle s'est trompé sur chaque point. On prend le quantile empirique \(\hat q\) d'ordre \(\lceil (n+1)(1-\alpha)\rceil / n\). L'intervalle \(\hat f(x) \pm \hat q\) vérifie alors, pour un nouveau point :

L'intuition : si le modèle s'est trompé de moins de \(\hat q\) sur 90 % des points de calibration, et que le nouveau point est échangeable avec ceux-là, il a 90 % de chances de tomber dans la même marge.

import numpy as np

modele.fit(X_train, y_train)                       # GBM, réseau, n'importe quoi

scores = np.abs(y_calib - modele.predict(X_calib))            # non-conformité
n, alpha = len(scores), 0.1
q = np.quantile(scores, np.ceil((n + 1) * (1 - alpha)) / n, method="higher")

pred = modele.predict(X_test)
bas, haut = pred - q, pred + q
print(f"couverture empirique : {np.mean((y_test >= bas) & (y_test <= haut)):.1%}")
# ≈ 90 %, par construction — quelle que soit la qualité du modèle

Deux raffinements importants. L'intervalle ci-dessus est de largeur constante, ce qui est peu satisfaisant quand le bruit varie : la variante CQR (conformalized quantile regression) conformalise les quantiles prédits par la section précédente, et produit des intervalles adaptatifs tout en conservant la garantie. En classification, on construit des ensembles de classes : sur un cas facile l'ensemble contient une seule classe, sur un cas ambigu il en contient plusieurs — une façon honnête de dire « je ne sais pas trancher », bien plus utile qu'un score de confiance non calibré, et directement exploitable pour décider de transmettre le cas à un humain (module 24).

Le module 9 a montré comment décider si une différence observée est réelle, et il s'est arrêté à une phrase importante : quand on ne peut pas randomiser, il existe des méthodes quasi-expérimentales, qui reposent sur des hypothèses à argumenter. Ce module développe cette phrase. C'est probablement le savoir-faire qui distingue le plus nettement quelqu'un qui sait entraîner un modèle de quelqu'un dont l'analyse fonde une décision : la question « quel est l'effet de cette action ? » n'est pas la question « que va-t-il se passer ? », et aucun modèle prédictif, si bon soit-il, ne répond à la première.

1. Le problème : prédire n'est pas agir

Un exemple auquel on ne coupe pas. Une entreprise constate que les clients ayant contacté le support résilient deux fois moins que les autres. Un modèle de classification le confirme : « a contacté le support » est la variable la plus importante. Conclusion tentante : appelons tout le monde.

Elle est probablement fausse, et pour une raison structurelle. Les gens qui contactent le support sont ceux qui tiennent assez au service pour prendre leur téléphone ; les autres sont déjà partis mentalement. La corrélation est réelle, le modèle n'a pas menti, mais l'intervention — appeler quelqu'un qui n'aurait pas appelé — n'est pas la même chose que l'observation — constater que quelqu'un a appelé.

La difficulté de fond est qu'aucune donnée, si abondante soit-elle, ne tranche seule. Deux mondes qui produisent exactement les mêmes données peuvent réclamer deux décisions opposées. Ce qui tranche, c'est une hypothèse sur le mécanisme, apportée par la connaissance du domaine, et que l'on écrit explicitement pour pouvoir en discuter. L'inférence causale est l'ensemble des méthodes qui rendent cette hypothèse visible et ses conséquences calculables.

2. Les résultats potentiels : écrire ce qu'on cherche

L'intuition

Le cadre dominant, dû à Rubin, part d'une idée simple. Pour chaque individu \(i\), imaginons deux versions du monde :

• \(Y_i(1)\) — ce qui lui serait arrivé s'il avait été traité ;
• \(Y_i(0)\) — ce qui lui serait arrivé s'il ne l'avait pas été.

L'effet du traitement sur cet individu est la différence \(\tau_i = Y_i(1) - Y_i(0)\). C'est exactement ce qu'on voudrait connaître, et c'est exactement ce qu'on ne peut jamais observer : un individu est traité ou ne l'est pas, jamais les deux. On n'observe que

où \(T_i \in \{0,1\}\) indique le traitement. L'autre terme est manquant, définitivement. C'est ce qu'on appelle le problème fondamental de l'inférence causale, et la formulation la plus utile est celle-ci : l'inférence causale est un problème de données manquantes, où ce qui manque est la moitié du tableau.

  individu   T   Y(0)   Y(1)    τ = Y(1)-Y(0)     observé
  ────────────────────────────────────────────────────────
     1       1     ?     420         ?              420
     2       0    310      ?         ?              310
     3       1     ?     380         ?              380
     4       0    295      ?         ?              295

  · la colonne τ est entièrement inconnue, ligne par ligne
  · MAIS sa MOYENNE peut être estimée, si les groupes sont comparables
  → tout le reste du module consiste à rendre les groupes comparables

Ce déplacement — renoncer à l'effet individuel, viser une moyenne — est la clé. On ne saura jamais si ce client aurait résilié ; on peut savoir de combien le taux de résiliation change en moyenne sur une population.

3. ATE, ATT, CATE : de quel effet parle-t-on ?

« L'effet du traitement » recouvre plusieurs quantités distinctes, qu'il faut nommer avant d'estimer, parce qu'elles n'ont ni la même valeur ni la même utilité.

ATE  — Average Treatment Effect            E[Y(1) - Y(0)]
       « et si on traitait TOUT LE MONDE ? »
       la bonne cible pour une politique générale

ATT  — ... on the Treated              E[Y(1) - Y(0) | T = 1]
       « le programme a-t-il servi à CEUX QUI Y ONT PARTICIPÉ ? »
       la bonne cible pour évaluer un dispositif existant

CATE — Conditional ATE                 E[Y(1) - Y(0) | X = x]
       « l'effet pour un individu DE PROFIL x »
       la bonne cible pour cibler — c'est l'uplift du module 24

LATE — Local ATE : l'effet sur le sous-groupe que l'instrument
       a réellement fait changer de comportement (section 9)

La distinction n'est pas académique. Un dispositif de formation professionnelle auquel s'inscrivent surtout les personnes déjà motivées peut avoir un ATT élevé — il aide ceux qui viennent — et un ATE faible — il n'aiderait guère si on l'imposait à tous. Publier l'un pour l'autre est une faute courante, et coûteuse en décision publique.

4. Les trois hypothèses qu'on ne peut pas tester

Estimer un effet causal à partir de données observationnelles exige trois hypothèses. Elles ne se vérifient pas dans les données — c'est leur nature — mais elles se discutent, et une analyse honnête les énonce.

5. L'expérience randomisée, et CUPED

Randomiser rend l'affectation indépendante de tout, y compris de ce qu'on n'a pas mesuré : l'ignorabilité devient vraie par construction, sans hypothèse. C'est pour cela que l'essai contrôlé randomisé — l'A/B test du module 9 — reste l'étalon-or, et que la première question devant tout problème causal est : puis-je randomiser ?

Le problème : la puissance

La randomisation garantit l'absence de biais, pas la précision. Sur une métrique très dispersée — le chiffre d'affaires par utilisateur, où 1 % des utilisateurs font 40 % du total — l'intervalle de confiance reste large même avec un million d'observations. Or l'écart-type entre individus est en grande partie stable dans le temps : un gros acheteur avant l'expérience sera un gros acheteur pendant. Cette part de variance est du bruit prévisible, donc soustrayable.

CUPED : retirer le bruit qu'on peut prédire

L'idée tient en une ligne. Soit \(X\) la valeur de la métrique avant l'expérience. On remplace \(Y\) par

Comme \(X\) est mesuré avant l'affectation, il ne peut pas être affecté par le traitement : soustraire sa contribution ne déplace pas la moyenne du traitement, mais réduit la variance d'un facteur \(1 - \rho^2\), où \(\rho\) est la corrélation entre \(X\) et \(Y\). Avec \(\rho = 0{,}7\), la variance tombe de moitié : on obtient la même précision avec deux fois moins d'utilisateurs, ou le même résultat deux fois plus vite.

import numpy as np
from scipy import stats

rng = np.random.default_rng(0)
n = 20_000
base = rng.lognormal(3, 1, n)              # dépense AVANT l'expérience
groupe = rng.integers(0, 2, n)             # 0 = témoin, 1 = traitement
effet_vrai = 1.5
apres = 0.8 * base + rng.lognormal(3, 1, n) * 0.4 + effet_vrai * groupe

def ic(y, g):
    d = y[g == 1].mean() - y[g == 0].mean()
    se = np.sqrt(y[g == 1].var(ddof=1) / (g == 1).sum()
                 + y[g == 0].var(ddof=1) / (g == 0).sum())
    return d, 1.96 * se

theta = np.cov(apres, base)[0, 1] / base.var(ddof=1)
apres_cuped = apres - theta * (base - base.mean())

d0, m0 = ic(apres, groupe)
d1, m1 = ic(apres_cuped, groupe)
print(f"brut  : effet {d0:5.2f} ± {m0:4.2f}")   # effet  1.62 ± 0.94
print(f"CUPED : effet {d1:5.2f} ± {m1:4.2f}")   # effet  1.55 ± 0.42
print(f"largeur divisée par {m0 / m1:.1f}")     # largeur divisée par 2.3

6. Le score de propension : pondérer ou apparier

Le problème

On n'a pas pu randomiser. Les traités et les non-traités diffèrent sur dix variables : âge, ancienneté, dépense passée, canal d'acquisition. Comparer les moyennes brutes revient à comparer des populations différentes. On voudrait comparer chaque traité à des non-traités « qui lui ressemblent », mais avec dix variables, personne ne ressemble exactement à personne — c'est la malédiction de la dimension.

L'intuition : résumer en un seul nombre

Le résultat de Rosenbaum et Rubin est élégant. Définissons le score de propension

c'est-à-dire la probabilité d'être traité compte tenu du profil. Alors, sous l'hypothèse d'ignorabilité, conditionner sur ce seul nombre suffit : deux individus de même score de propension sont comparables, même si leurs profils diffèrent. Dix dimensions se réduisent à une.

On estime \(e(x)\) par un modèle de classification ordinaire — régression logistique ou gradient boosting du module 14 —, puis on s'en sert de deux façons :

import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn.calibration import CalibratedClassifierCV

# X : covariables mesurées AVANT le traitement ; T : 0/1 ; Y : résultat
modele = CalibratedClassifierCV(LogisticRegression(max_iter=1000), cv=5)
modele.fit(X, T)
e = modele.predict_proba(X)[:, 1]

# 1) positivité : les deux groupes doivent se recouvrir
print("traités   e ∈", np.percentile(e[T == 1], [1, 99]).round(3))
print("témoins   e ∈", np.percentile(e[T == 0], [1, 99]).round(3))
# si les plages ne se recouvrent pas, AUCUNE méthode ne sauvera l'analyse

# 2) écrêtage : un score de 0.001 donnerait un poids de 1000
e = np.clip(e, 0.05, 0.95)
w = np.where(T == 1, 1 / e, 1 / (1 - e))

# 3) vérifier que la pondération a bien équilibré les covariables
def diff_standardisee(x, T, w):
    m1 = np.average(x[T == 1], weights=w[T == 1])
    m0 = np.average(x[T == 0], weights=w[T == 0])
    return (m1 - m0) / np.sqrt((x[T == 1].var() + x[T == 0].var()) / 2)

for j, nom in enumerate(noms_colonnes):
    d = diff_standardisee(X[:, j], T, w)
    drapeau = "  ⚠ déséquilibré" if abs(d) > 0.1 else ""
    print(f"{nom:20s} {d:+.3f}{drapeau}")

ate = np.average(Y[T == 1], weights=w[T == 1]) - \
      np.average(Y[T == 0], weights=w[T == 0])
print(f"ATE estimé : {ate:.3f}")

7. Différences de différences

Le problème

Une région applique une nouvelle réglementation, l'autre non. Comparer les deux régions après coup ne dit rien : elles différaient déjà avant. Comparer la région traitée avant et après ne dit rien non plus : entre-temps, la conjoncture a bougé pour tout le monde.

L'intuition : soustraire deux fois

On combine les deux comparaisons pour éliminer les deux biais. La différence avant/après dans le groupe témoin mesure ce qui se serait passé sans traitement — la tendance commune. On la retranche de la différence avant/après du groupe traité ; ce qui reste est l'effet.

  Y
  │                                        ● traités (observé)
  │                             ●──────────
  │                    ●───────╱      ↕ EFFET ESTIMÉ
  │            ●──────╱    ○ ─ ─ ─ ─ ─   contrefactuel : les traités
  │                            ╱          s'ils avaient suivi la tendance
  │        ○──────○──────○────╱           des témoins
  │                          ○ témoins (observé)
  └────────────────────────┬──────────────────────────► temps
                    intervention

  L'hypothèse, INVÉRIFIABLE : sans traitement, les deux courbes seraient
  restées PARALLÈLES. On ne peut pas la tester après l'intervention —
  mais on peut regarder si elles l'étaient AVANT. C'est le test de
  tendances pré-traitement, et c'est le premier graphique à produire.

import statsmodels.formula.api as smf

# df : une ligne par (unité, période), colonnes traite (0/1), apres (0/1)
# L'interaction porte TOUT l'effet causal recherché.
m = smf.ols("y ~ traite * apres", data=df).fit(
        cov_type="cluster", cov_kwds={"groups": df["unite"]})
print(m.summary().tables[1])
#                    coef    std err     P>|t|
# Intercept        12.400      0.210     0.000   niveau témoins, avant
# traite            3.100      0.290     0.000   écart initial (biais de niveau)
# apres             1.800      0.240     0.000   tendance commune
# traite:apres      2.450      0.330     0.000   ← L'EFFET

# forme plus robuste : effets fixes unité + période, qui absorbent
# toute différence stable entre unités et tout choc commun aux unités
m2 = smf.ols("y ~ traite:apres + C(unite) + C(periode)", data=df).fit(
        cov_type="cluster", cov_kwds={"groups": df["unite"]})

8. Régression sur discontinuité

L'intuition

Certaines décisions reposent sur un seuil arbitraire : une bourse attribuée en dessous d'un revenu, un rattrapage déclenché sous 10 de moyenne, une remise commerciale au-delà d'un montant de panier. Un élève à 9,9 et un élève à 10,1 sont, à toutes fins pratiques, identiques — sauf que l'un reçoit le dispositif et l'autre non. Au voisinage immédiat du seuil, on dispose donc d'une quasi-randomisation offerte par la règle.

  résultat
  │                                      ╭─── ajustement à droite
  │                                 ╭────╯
  │                            ╭────╯
  │                       ╭────╯  ↕ EFFET = saut à la discontinuité
  │              ────────╯
  │        ──────
  │  ──────
  └──────────────────────┬───────────────────────► variable de forçage
                        seuil

  · on ajuste une courbe DE CHAQUE CÔTÉ, séparément
  · l'effet est l'écart des deux ajustements AU seuil, rien d'autre
  · la validité décroît vite quand on s'éloigne : l'effet estimé est LOCAL

import numpy as np, statsmodels.formula.api as smf

seuil, fenetre = 10.0, 1.5
d = df[np.abs(df["note"] - seuil) <= fenetre].copy()
d["centre"] = d["note"] - seuil
d["droite"] = (d["centre"] >= 0).astype(int)

# pentes séparées de part et d'autre : centre * droite
m = smf.ols("resultat ~ centre * droite", data=d).fit(cov_type="HC1")
print(f"effet au seuil : {m.params['droite']:.3f} "
      f"[{m.conf_int().loc['droite', 0]:.3f}, "
      f"{m.conf_int().loc['droite', 1]:.3f}]")

# sensibilité à la fenêtre : un résultat solide bouge peu
for h in (0.5, 1.0, 1.5, 2.0, 3.0):
    dd = df[np.abs(df["note"] - seuil) <= h].copy()
    dd["centre"] = dd["note"] - seuil
    dd["droite"] = (dd["centre"] >= 0).astype(int)
    r = smf.ols("resultat ~ centre * droite", data=dd).fit()
    print(f"  fenêtre {h}: {r.params['droite']:+.3f}  (n = {len(dd)})")

9. Variables instrumentales

Le problème

Un confondant non mesuré subsiste, et aucun ajustement ne le corrigera puisqu'on ne l'observe pas. Exemple canonique : l'effet d'une année d'études supplémentaire sur le salaire. La capacité individuelle influence à la fois la poursuite d'études et le salaire, et elle n'est pas dans les données.

L'intuition : une source de variation innocente

On cherche une troisième variable \(Z\), l'instrument, qui pousse à être traité sans avoir d'effet propre sur le résultat. Elle joue le rôle d'un tirage au sort partiel, fourni par la nature ou l'administration. On n'utilise alors que la part de variation du traitement due à l'instrument — une part dont on sait qu'elle n'est pas contaminée.

          Z ─────────► T ─────────► Y
          │                ▲
          │                │
          └──── ✗ ────►    U (confondant non observé)
                            │
                            ▼  (U influence T ET Y)

  1. PERTINENCE      Z influence réellement T      → TESTABLE (statistique F)
  2. EXCLUSION       Z n'agit sur Y QUE via T      → NON testable, à argumenter
  3. INDÉPENDANCE    Z n'est lié à aucun confondant → NON testable

  Exemples utilisés en économie :
   · distance au lycée le plus proche → poursuite d'études → salaire
   · loterie d'affectation scolaire   → école fréquentée   → résultats
   · mois de naissance (âge légal de sortie) → années d'études → salaire
   · en entreprise : une INCITATION randomisée à utiliser une fonction,
     quand on ne peut pas forcer l'usage → c'est le cas le plus utile

from linearmodels.iv import IV2SLS

# y ~ 1 + controles + [traitement ~ instrument]
res = IV2SLS.from_formula(
    "salaire ~ 1 + experience + [annees_etudes ~ distance_lycee]",
    data=df).fit(cov_type="robust")
print(res.summary)

# LE diagnostic à lire en premier : la première étape
print(res.first_stage)
# F < 10  →  instrument FAIBLE : l'estimation est biaisée et son
#            intervalle de confiance n'a pas la couverture annoncée.
#            Mieux vaut ne rien conclure que publier ce chiffre.

10. Double machine learning et effets hétérogènes

Le problème

On voudrait ajuster sur beaucoup de covariables, avec des relations non linéaires — exactement ce que le gradient boosting du module 14 fait bien. Mais brancher un modèle de ML dans une estimation causale échoue de deux façons. D'abord, la régularisation qui aide à prédire biaise l'estimation de l'effet : elle rétrécit tous les coefficients, y compris celui qui nous intéresse. Ensuite, le surapprentissage : un modèle qui a vu un individu à l'entraînement produit sur lui un résidu artificiellement petit.

L'intuition : régresser le bruit sur le bruit

La méthode de Chernozhukov et coauteurs repose sur une idée ancienne — le théorème de Frisch–Waugh — appliquée avec du ML :

1. prédire le résultat à partir des covariables, \(\hat{m}(X) \approx E[Y \mid X]\), et garder le résidu \(\tilde{Y} = Y - \hat{m}(X)\) ;
2. prédire le traitement à partir des covariables, \(\hat{e}(X) \approx E[T \mid X]\), et garder le résidu \(\tilde{T} = T - \hat{e}(X)\) ;
3. régresser \(\tilde{Y}\) sur \(\tilde{T}\) : la pente est l'effet causal.

Les deux premières étapes retirent tout ce que les covariables expliquent ; ce qui reste dans \(\tilde{T}\) est la part d'affectation au traitement qui ne s'explique pas par le profil — la part « comme si » elle avait été tirée au sort. Deux ingrédients rendent la construction valide :

• L'orthogonalisation — résidualiser des deux côtés rend l'estimation insensible au premier ordre aux erreurs des modèles auxiliaires. Ceux-ci peuvent être imparfaits sans invalider l'effet.
• Le découpage croisé (cross-fitting) — on prédit toujours un individu avec un modèle entraîné sans lui, comme en validation croisée (module 12). C'est ce qui neutralise le surapprentissage.

from econml.dml import LinearDML, CausalForestDML
from sklearn.ensemble import HistGradientBoostingRegressor as HGB
from sklearn.ensemble import HistGradientBoostingClassifier as HGC

# ---- effet moyen, avec ajustement non linéaire sur X
est = LinearDML(model_y=HGB(), model_t=HGC(),
                discrete_treatment=True, cv=5)   # cv = découpage croisé
est.fit(Y, T, X=X, W=W)          # X : modulateurs d'effet ; W : contrôles
print("ATE :", est.ate(X), est.ate_interval(X, alpha=0.05))

# ---- effet PAR INDIVIDU : qui gagne à être traité ?
foret = CausalForestDML(model_y=HGB(), model_t=HGC(),
                        discrete_treatment=True, cv=5, n_estimators=500)
foret.fit(Y, T, X=X, W=W)
cate = foret.effect(X)                     # un effet estimé par individu

print(f"effet médian   : {np.median(cate):+.3f}")
print(f"part d'effets négatifs : {(cate < 0).mean():.1%}")
# → si 30 % des individus ont un effet négatif, traiter tout le monde
#   est une mauvaise politique même si l'ATE est positif.

# quelles variables portent l'hétérogénéité ?
print(foret.feature_importances())

Cette dernière sortie est le pont vers l'action : un effet moyen positif peut masquer un sous-groupe que le traitement dégrade. C'est précisément l'uplift du module 24, qui reprend ce résultat pour décider qui traiter sous contrainte de budget.

11. Et si un confondant manquait ?

Toutes les méthodes observationnelles reposent sur une hypothèse invérifiable. Plutôt que de l'affirmer, on peut mesurer sa fragilité : quelle force devrait avoir un confondant caché pour annuler la conclusion ?

import numpy as np

def valeur_e(rr: float) -> float:
    """Valeur E d'un risque relatif (ou de sa borne de confiance)."""
    if rr < 1:
        rr = 1 / rr
    return rr + np.sqrt(rr * (rr - 1))

print(f"RR = 1.2 → E = {valeur_e(1.2):.2f}")   # 1.69  fragile
print(f"RR = 2.0 → E = {valeur_e(2.0):.2f}")   # 3.41  solide
print(f"RR = 5.0 → E = {valeur_e(5.0):.2f}")   # 9.47  très solide
# On reporte TOUJOURS la valeur E de la borne de confiance la plus
# proche de 1 : c'est le scénario le moins favorable compatible
# avec les données.

Reporter une valeur E change la nature du débat : on ne discute plus de savoir si l'hypothèse est vraie — question sans réponse —, mais de savoir si un confondant de cette force est plausible dans ce domaine. C'est une question à laquelle un expert métier peut répondre.

12. Récapitulatif et erreurs fréquentes

Puis-je randomiser ?
├─ OUI  → A/B test (module 9) + CUPED pour la puissance
│         randomiser par grappes si les unités interagissent
└─ NON  → quelle structure les données offrent-elles ?
   │
   ├─ Un seuil administratif décide du traitement
   │    → RÉGRESSION SUR DISCONTINUITÉ      effet local, très crédible
   │
   ├─ Deux groupes observés avant ET après
   │    → DIFFÉRENCES DE DIFFÉRENCES        hypothèse : tendances parallèles
   │
   ├─ Une variable pousse au traitement sans agir sur le résultat
   │    → VARIABLES INSTRUMENTALES           estime le LATE ; vérifier F > 10
   │
   ├─ Je crois avoir mesuré tous les confondants
   │    → SCORE DE PROPENSION / DOUBLE ML    hypothèse la plus forte
   │      + diagnostic de chevauchement OBLIGATOIRE
   │
   └─ Rien de tout cela
        → décrire, ne pas conclure. Une corrélation présentée comme
          telle vaut mieux qu'un effet causal inventé.

Une dernière remarque, qui vaut pour tout le reste du cours. Un modèle prédictif et un modèle causal ne s'évaluent pas de la même manière : le premier se juge sur des données de test, le second ne se juge sur rien — il n'existe pas de vérité terrain pour un effet causal, puisque le contrefactuel est manquant par construction. C'est pourquoi la crédibilité repose ici sur la conception de l'étude, sur les diagnostics, et sur l'énoncé explicite des hypothèses. Le module 12 reprend maintenant le fil de la pratique : comment passer d'un problème métier à un jeu de données exploitable.

Dans un projet réel, le choix de l'algorithme occupe une fraction marginale du temps et explique une fraction marginale de la performance. Ce qui fait la différence, c'est le cadrage du problème, la qualité des données et la rigueur du protocole d'évaluation. Ce module couvre exactement cette partie-là — celle qu'on n'apprend pas dans les cours d'algorithmes, et qui décide pourtant du sort du projet.

1. Cycle de vie d'un projet

1. Cadrage métier       définir la question, la métrique, l'usage du résultat    ~10 %
2. Collecte / accès     trouver, extraire, joindre les données                   ~20 %
3. Exploration          comprendre les données, détecter les anomalies           ~15 %
4. Préparation          nettoyage, features, encodages                           ~25 %
5. Modélisation         baseline, puis itérations                                ~10 %
6. Évaluation           protocole, métriques, analyse d'erreurs                  ~10 %
7. Déploiement / suivi  mise en production, monitoring, ré-entraînement          ~10 %

Le cycle n'est pas linéaire : l'exploration révèle des problèmes de collecte, l'analyse d'erreurs renvoie au feature engineering, et le déploiement fait apparaître des contraintes de latence qui invalident un modèle. La seule erreur structurelle est de traiter ces étapes comme un tunnel à sens unique, avec une « livraison » à la fin.

2. Cadrage : la cible et la baseline

Définir la cible est plus subtil qu'il n'y paraît. Prédire « le churn » exige de fixer une fenêtre (résiliation dans les 30 jours ? 90 ?), une date d'observation, et le sort des cas ambigus (un client inactif depuis six mois est-il parti ?). Deux définitions également raisonnables peuvent donner des taux de positifs allant du simple au triple, et donc des modèles incomparables. Écrire la définition en une phrase, et la faire valider par le métier, économise des semaines.

Fixer l'unité d'observation : une ligne = un client ? un client-mois ? une transaction ? Ce choix détermine la structure de dépendance des données, donc le schéma de validation (section 8), et il est très coûteux à changer en cours de route.

Établir une baseline, enfin, avant tout modèle. Sans elle, un R² de 0,7 ne veut rien dire — il peut être excellent ou ridicule selon le problème.

from sklearn.dummy import DummyRegressor, DummyClassifier

# régression : prédire toujours la moyenne (ou la médiane)
base = DummyRegressor(strategy="median").fit(X_tr, y_tr)

# classification : prédire toujours la classe majoritaire
base = DummyClassifier(strategy="most_frequent").fit(X_tr, y_tr)

# série temporelle : la valeur de la veille, ou celle de l'an dernier (module 17)
pred_naive = y[:-1]

# et surtout : la RÈGLE MÉTIER existante, si elle existe
pred_regle = np.where(df["anciennete"] < 3, 1, 0)

La baseline donne aussi le coût réel du projet : si une règle à trois conditions atteint 95 % de la performance du modèle, celui-ci ne vaut peut-être pas sa complexité opérationnelle.

3. Exploration : une checklist

Structure      dimensions, types, mémoire, granularité (une ligne = quoi ?)
Cible          distribution, taux de positifs, extrêmes, évolution dans le temps
Manquants      taux par colonne, et STRUCTURE des manquants (section 5)
Doublons       lignes identiques ET doublons sur la clé métier
Cardinalité    colonnes constantes (inutiles), identifiants déguisés (dangereux)
Distributions  asymétrie, multimodalité, valeurs impossibles (âge = 200, prix < 0)
Temps          couverture, trous, saisonnalité, ruptures de collecte
Relations      corrélations entre variables, lien de chaque variable avec la cible
Groupes        déséquilibres entre segments, sous-populations sous-représentées

import polars as pl

df = pl.read_parquet("data/clients.parquet")

print(df.shape, df.estimated_size("mb"))
print(df.describe())                                     # stats par colonne
print(df.null_count())                                   # manquants par colonne
print(df.select(pl.all().n_unique()))                    # cardinalités
print(df.filter(pl.struct(df.columns).is_duplicated()))  # doublons exacts

# valeurs impossibles : toujours confronter aux bornes MÉTIER
print(df.filter((pl.col("age") < 0) | (pl.col("age") > 120)))

# la cible dans le temps : LE graphique qui révèle les ruptures de collecte
print(df.group_by_dynamic("date", every="1w").agg(
          taux=pl.col("cible").mean(), n=pl.len()))

# lien de chaque variable numérique avec la cible
print(df.select(pl.corr(pl.col(c), pl.col("cible")).alias(c)
                for c in colonnes_numeriques))

Les outils de profilage automatique (ydata-profiling, skrub) produisent en une ligne un rapport complet. Utiles pour débroussailler, ils ne remplacent pas le regard métier : seule une connaissance du domaine dit qu'un prix à 0,01 € correspond à un test interne, ou que la valeur « 9999 » est un code de saisie signifiant « inconnu ».

4. Visualisation utile

Trois bibliothèques couvrent tous les besoins : matplotlib (contrôle total, verbeux), seaborn (statistique, concis, excellents défauts), plotly (interactif, précieux pour explorer un nuage dense). Quelques principes qui changent réellement la lisibilité :

• Un histogramme cache autant qu'il montre : le nombre de classes change complètement l'allure d'une distribution. Doubler avec un violin plot ou afficher les points quand l'échantillon est petit.
• Sur des données asymétriques, passer en échelle log — sinon 99 % des points s'écrasent dans le premier centimètre du graphique.
• Contre la surimpression (des millions de points), utiliser la transparence, un échantillon, ou une carte de densité (hexbin).
• Toujours tracer la cible en fonction du temps : c'est le graphique qui révèle les ruptures de collecte, les changements de définition et la dérive (module 26).
• Se méfier des résumés : le quartet d'Anscombe et le « datasaurus » montrent que des jeux de données de moyennes, variances et corrélations identiques peuvent être radicalement différents. Regarder les distributions, pas seulement les statistiques.

import matplotlib.pyplot as plt, seaborn as sns

fig, ax = plt.subplots(2, 2, figsize=(12, 8))

sns.histplot(df["prix"], log_scale=True, ax=ax[0, 0])          # 1. la cible
ax[0, 0].set_title("distribution de la cible (échelle log)")

df.set_index("date")["cible"].resample("W").mean().plot(ax=ax[0, 1])   # 2. le temps
ax[0, 1].set_title("taux de positifs par semaine")

sns.heatmap(df[num].corr(), cmap="RdBu_r", center=0, ax=ax[1, 0])      # 3. corrélations
ax[1, 0].set_title("corrélations entre variables")

sns.boxplot(data=df, x="segment", y="prix", ax=ax[1, 1])               # 4. par groupe
ax[1, 1].set_yscale("log")
plt.tight_layout()

5. Données manquantes

Avant de choisir une méthode, il faut comprendre pourquoi une valeur manque. La typologie de Rubin, qui n'est pas qu'une curiosité théorique :

• MCAR (missing completely at random) — le manque est indépendant de tout : un capteur tombé en panne au hasard. Supprimer les lignes ne biaise rien, on perd seulement de la puissance.
• MAR (missing at random) — le manque dépend des variables observées : les revenus manquent plus souvent chez les jeunes, et l'âge est connu. L'imputation conditionnelle est alors légitime, puisque l'information nécessaire est disponible.
• MNAR (missing not at random) — le manque dépend de la valeur elle-même : les hauts revenus refusent de répondre. Aucune imputation ne corrige cela ; il faut modéliser le mécanisme, ou au minimum documenter le biais.

# le taux de manquants dépend-il des autres variables ? (indice de MAR)
df["revenu_manquant"] = df["revenu"].isna()
print(df.groupby("revenu_manquant")[["age", "anciennete", "cible"]].mean())
# si les moyennes diffèrent nettement → le manque est INFORMATIF

# les manquants sont-ils groupés ? (plusieurs colonnes absentes ensemble)
import missingno as msno
msno.matrix(df); msno.heatmap(df)     # visualise la co-occurrence des manquants

Supprimer les lignes      acceptable si < 5 % et MCAR. Sinon on biaise l'échantillon.
Supprimer la colonne      si > 60-70 % manquants ET aucun signal dans le fait de manquer.
Moyenne / médiane         rapide ; réduit artificiellement la variance et écrase
                          les corrélations. Acceptable comme baseline.
KNN / itératif (MICE)     impute à partir des autres colonnes ; coûteux, bien meilleur.
Valeur sentinelle         -1, "inconnu" : parfait pour les modèles à base d'arbres,
                          qui peuvent isoler cette modalité.
Ne rien faire             HistGradientBoosting, XGBoost et LightGBM gèrent nativement
                          les NaN et APPRENNENT la meilleure direction pour eux.
Indicateur de manque      ajouter une colonne booléenne : le FAIT de manquer est
                          souvent informatif (un client qui ne renseigne pas
                          son revenu n'est pas un client au hasard).

from sklearn.experimental import enable_iterative_imputer   # noqa: F401
from sklearn.impute import IterativeImputer, SimpleImputer

# imputation multivariée : chaque colonne est prédite à partir des autres, en boucle
imp = IterativeImputer(max_iter=10, random_state=0)

# conserver l'information "cette valeur manquait" : ajoute une colonne booléenne
imp = SimpleImputer(strategy="median", add_indicator=True)

6. Feature engineering

C'est l'étape au meilleur rendement sur données tabulaires : une bonne variable bat presque toujours un meilleur algorithme. L'idée générale est d'encoder la connaissance métier sous une forme que le modèle peut exploiter — un arbre ne « devinera » jamais qu'il faut diviser le prix par la surface.

Variables catégorielles

One-hot          une colonne par modalité. Défaut sûr. Explose si cardinalité élevée.
Ordinal          un entier par modalité. Uniquement si un ORDRE existe réellement
                 (S < M < L), ou pour des arbres, qui savent découper n'importe où.
Target encoding  remplace la modalité par la moyenne de la cible. Très puissant sur
                 forte cardinalité (code postal, produit) — et très exposé à la fuite.
Hashing          projette dans un espace de taille fixe. Utile en flux, perd la lisibilité.
Embeddings       représentation dense apprise. Pour les réseaux (module 16).

Le target encoding mérite un développement, car il est à la fois redoutablement efficace et dangereux. Pour une modalité \(c\) comptant \(n_c\) observations, on ne prend pas la moyenne brute — qui vaudrait 0 ou 1 pour une modalité vue une seule fois — mais une moyenne lissée vers la moyenne globale :

Le paramètre \(m\) contrôle la régularisation : une modalité vue trois fois est tirée vers la moyenne globale, une modalité vue mille fois garde sa propre moyenne. C'est exactement le regroupement partiel des modèles hiérarchiques (module 10), en version simplifiée.

Surtout, l'encodage doit être calculé en validation croisée interne : chaque pli encodé avec les statistiques des autres plis. Sans cela, chaque ligne contient un peu de sa propre cible — fuite garantie, avec un score de validation flatteur et un modèle inutilisable en production. sklearn.preprocessing.TargetEncoder fait cela correctement.

Variables numériques et temporelles

import numpy as np, polars as pl

df = df.with_columns(
    # 1. transformations : log pour les queues lourdes (prix, revenus, durées)
    log_prix=pl.col("prix").log1p(),           # log1p gère la valeur 0

    # 2. RATIOS et interactions : souvent l'apport décisif. Les arbres approchent
    #    très mal un ratio (il leur faut des dizaines de coupes), il faut le fournir.
    prix_m2=pl.col("prix") / pl.col("surface"),
    revenu_par_personne=pl.col("revenu") / pl.col("taille_foyer"),
    intensite=pl.col("n_connexions") / pl.col("anciennete_jours"),

    # 3. variables de calendrier
    jour_semaine=pl.col("date").dt.weekday(),
    mois=pl.col("date").dt.month(),
    est_weekend=pl.col("date").dt.weekday() >= 6,

    # 4. variables CYCLIQUES : pour que 23 h soit proche de 0 h
    heure_sin=(2 * np.pi * pl.col("date").dt.hour() / 24).sin(),
    heure_cos=(2 * np.pi * pl.col("date").dt.hour() / 24).cos(),

    # 5. agrégats à fenêtre STRICTEMENT passée (le shift(1) est essentiel)
    depense_moy_30j=pl.col("montant").shift(1).rolling_mean(30).over("client_id"),
    n_achats_7j=pl.col("montant").shift(1).rolling_count(7).over("client_id"),
)

Les agrégats à fenêtre sont le cœur du feature engineering sur données transactionnelles, et c'est exactement ce que font les fonctions de fenêtre SQL (module 4) — souvent plus efficacement, directement dans la base. La discrétisation (transformer l'âge en tranches) capture une non-linéarité pour un modèle linéaire, au prix d'une perte d'information ; elle est inutile pour un modèle à base d'arbres, qui la trouve tout seul.

Sélection de variables

Moins de variables, c'est moins de surapprentissage, moins de coût d'inférence et plus de robustesse. Par ordre de fiabilité croissante : filtres univariés (corrélation, information mutuelle — rapides mais aveugles aux interactions) ; importance par permutation sur un modèle ajusté (module 14) ; élimination récursive (RFE) ; et la régularisation \(L^1\), qui sélectionne en annulant des coefficients. Attention : les méthodes fondées sur la cible doivent, elles aussi, être évaluées à l'intérieur de la validation croisée, sinon la sélection elle-même devient une fuite.

7. Classes déséquilibrées

Fraude à 0,2 %, panne à 1 %, maladie rare : la classe qui intéresse est minuscule. Les réflexes, dans l'ordre de ce qui marche le mieux :

1. Changer de métrique — l'accuracy n'a aucun sens ici ; PR-AUC, rappel à précision fixée, ou coût métier (module 8).
2. Pondérer les classes — class_weight="balanced" ou scale_pos_weight : le modèle paie plus cher une erreur sur la classe rare. Simple, sans distorsion des données.
3. Ajuster le seuil — un modèle produit une probabilité ; le seuil de décision est un choix métier qui se règle sur la courbe précision-rappel, jamais laissé à 0,5 par défaut (module 24).
4. Rééchantillonner — sous-échantillonner la majorité (perte d'information) ou sur-échantillonner la minorité (risque de surapprentissage). SMOTE crée des exemples synthétiques par interpolation entre voisins : séduisant, mais il interpole aussi le bruit, fonctionne mal en grande dimension et avec des variables catégorielles, et la littérature récente montre qu'il apporte rarement mieux qu'une simple pondération.

from sklearn.metrics import precision_recall_curve

# 1 et 2 : métrique adaptée et pondération
modele = LGBMClassifier(scale_pos_weight=(y_tr == 0).sum() / (y_tr == 1).sum())
modele.fit(X_tr, y_tr, eval_metric="average_precision")

# 3 : choisir le seuil sur la courbe précision-rappel, pas à 0,5
p = modele.predict_proba(X_val)[:, 1]
prec, rap, seuils = precision_recall_curve(y_val, p)
# par exemple : le seuil qui garantit au moins 80 % de précision
i = np.argmax(prec[:-1] >= 0.80)
print(f"seuil = {seuils[i]:.3f} → précision {prec[i]:.1%}, rappel {rap[i]:.1%}")

8. Validation croisée : choisir le bon schéma

Un découpage unique train/test est bruité : le score dépend du tirage, et sur un petit jeu l'écart entre deux tirages peut dépasser l'écart entre deux modèles. La validation croisée à \(K\) plis moyenne \(K\) évaluations, chaque observation servant une fois au test. Son écart type entre plis est aussi informatif que la moyenne — un modèle à 0,82 ± 0,01 est préférable à 0,84 ± 0,09.

KFold (K=5)                     TimeSeriesSplit
pli 1  [test][─── train ───]    pli 1  [train][test]·············
pli 2  [train][test][ train ]   pli 2  [── train ──][test]·······
pli 3  [── train ─][test][──]   pli 3  [──── train ───][test]····
pli 4  [─── train ──][test][]   pli 4  [────── train ────][test]·
pli 5  [──── train ────][test]         ↑ on n'entraîne JAMAIS sur le futur

GroupKFold (groupe = client)
client A ██  B ██  C ██  D ██  E ██     un client entier va d'un seul côté :
pli 1    test    train train train      pas de client des deux côtés du découpage

KFold                  données i.i.d., régression                 K = 5 ou 10
StratifiedKFold        classification : conserve les proportions  le défaut en classif
GroupKFold             plusieurs lignes par entité (patient,      un groupe = un seul pli
                       client, bien immobilier)
StratifiedGroupKFold   les deux contraintes à la fois
TimeSeriesSplit        séries temporelles : entraîner sur le      jamais de mélange
                       passé, tester sur le futur
LeaveOneOut            très peu de données                        coûteux, variance élevée
Nested CV              on optimise DES hyperparamètres ET on veut boucle interne = réglage
                       une estimation non biaisée                 boucle externe = évaluation

from sklearn.model_selection import GroupKFold, cross_validate

# données transactionnelles : plusieurs lignes par client → GroupKFold
res = cross_validate(pipeline, X, y, groups=df["client_id"],
                     cv=GroupKFold(n_splits=5),
                     scoring=["roc_auc", "average_precision"],
                     return_train_score=True, n_jobs=-1)

# l'écart train/validation mesure directement le surapprentissage
print(f"train {res['train_roc_auc'].mean():.3f} | "
      f"val {res['test_roc_auc'].mean():.3f} ± {res['test_roc_auc'].std():.3f}")

9. Fuites de données : le catalogue

La fuite (data leakage) est l'erreur la plus coûteuse de la discipline, parce qu'elle est silencieuse : elle produit d'excellents scores en validation et un modèle qui s'effondre en production, quand plus personne ne sait d'où vient le problème.

Prétraitement global     scaler, imputeur, PCA, sélection de variables ajustés sur TOUT
                         le jeu avant le découpage.    → tout mettre dans un Pipeline

Fuite temporelle         une variable utilise de l'information postérieure à la date
                         de prédiction : moyenne calculée sur toute la période,
                         statut final du dossier.      → figer une date de référence

Duplication              la même observation (ou quasi) des deux côtés du découpage :
                         doublons, utilisateur présent plusieurs fois.  → GroupKFold

Cible déguisée           une colonne qui n'existe QUE parce que l'événement a eu lieu :
                         "date de résiliation", "montant remboursé", "motif de panne".

Target encoding naïf     moyenne de cible calculée en incluant la ligne courante.
                         → encodage en validation croisée interne

Fuite par le seuil       choisir le seuil de décision sur le jeu de test.

Sélection répétée        essayer 200 modèles et garder le meilleur score de test :
                         le test devient un jeu d'entraînement déguisé.

Dans presque tous les projets industriels, les données brutes abondent et les données étiquetées manquent : annoter demande un expert, un essai destructif, ou simplement du temps que personne n'a. Ce module rassemble les stratégies qui permettent d'apprendre quand même — et surtout, comment décider où dépenser un budget d'annotation limité.

1. Situer son problème

Le point de départ n'est pas « quelle méthode est la plus moderne » mais « de quoi est-ce que je dispose ».

Un modèle pré-entraîné existe sur un        transfert / fine-tuning       (section 2)
domaine proche
On PEUT annoter, mais c'est cher            apprentissage actif           (section 3)
Beaucoup de données non annotées            semi-supervisé (4),
disponibles                                 auto-supervisé (5)
Des règles métier ou des heuristiques       supervision faible            (section 6)
existent
Les étiquettes existent mais sont bruitées  apprentissage robuste au bruit (section 6)
Un simulateur du phénomène est disponible   données synthétiques, sim2real (section 7)
Quelques exemples seulement, et un gros     few-shot / zero-shot          (section 8)
modèle de fondation accessible

Ces approches se combinent, et l'ordre compte : commencer par le transfert, puis récupérer des représentations auto-supervisées sur les données non annotées dont on dispose, puis annoter activement les cas informatifs. C'est ce pipeline qui donne le meilleur résultat par euro dépensé.

2. Transfert : l'option par défaut

Le principe : un modèle entraîné sur des millions d'images a appris des représentations générales — contours, textures, formes — qui servent bien au-delà de sa tâche d'origine. On récupère ces représentations plutôt que de les réapprendre à partir de 2 000 images.

EXTRACTION DE FEATURES   on fige tout le réseau, on récupère le vecteur de la couche
                         pénultième, on entraîne une régression logistique dessus.
                         Quelques centaines d'exemples suffisent. Très rapide, et
                         souvent MEILLEUR qu'un fine-tuning qui surapprendrait.

FINE-TUNING PARTIEL      on dégèle les dernières couches et on affine avec un taux
                         d'apprentissage 10 à 100× plus faible que d'habitude.
                         Le bon compromis à partir de quelques milliers d'exemples.

FINE-TUNING COMPLET      tout le réseau est réentraîné. Demande beaucoup de données,
                         sous peine d'OUBLI CATASTROPHIQUE : le réseau perd les
                         représentations générales qui faisaient sa valeur.

import torch, torchvision as tv
from sklearn.linear_model import LogisticRegression

modele = tv.models.resnet50(weights="IMAGENET1K_V2")
modele.fc = torch.nn.Identity()          # on retire la tête de classification
modele.eval()

with torch.no_grad():                    # pas de gradient : on n'entraîne rien ici
    F = torch.cat([modele(xb) for xb, _ in chargeur])   # (n, 2048) embeddings

clf = LogisticRegression(max_iter=2000, C=1.0).fit(F.numpy(), y)
# 300 images étiquetées suffisent souvent à dépasser 90 % sur une tâche simple

Deux points de vigilance. La distance entre domaines décide du succès : d'ImageNet vers des photographies industrielles, le transfert fonctionne très bien ; vers des images de tomographie, de microscopie ou de spectrogrammes, nettement moins — les statistiques de bas niveau n'ont rien à voir. Dans ce cas, un pré-entraînement auto-supervisé sur ses propres images non annotées (section 5) est supérieur. Et l'adaptation de domaine traite le cas où l'on a des étiquettes sur un domaine source et aucune sur le domaine cible : on y aligne les distributions de représentations (CORAL, DANN), ou l'on recalibre simplement les statistiques de normalisation sur les données cibles — souvent étonnamment efficace pour un effort minime.

3. Apprentissage actif

Principe : plutôt que d'annoter au hasard, laisser le modèle désigner les exemples dont l'annotation lui apprendrait le plus. La boucle est identique à celle de l'optimisation bayésienne (module 19) — un critère d'acquisition, une évaluation coûteuse, une mise à jour — et l'intuition est la même : on ne mesure pas là où l'on sait déjà.

Moindre confiance       1 - max p(y|x) : les cas où le modèle hésite le plus
Marge                   écart entre les deux meilleures classes. Souvent le meilleur
                        critère simple en classification multiclasse.
Entropie                incertitude globale de la distribution prédite
Désaccord de comité     plusieurs modèles votent ; on annote là où ils divergent.
                        Très bon avec un ensemble profond (module 10).
Diversité / core-set    couvrir l'espace des représentations plutôt que se concentrer
                        sur une seule zone ambiguë
Incertitude épistémique cibler ce que le modèle IGNORE plutôt que ce qui est
                        intrinsèquement bruité — la distinction du module 10 est ici
                        décisive : annoter du bruit pur n'apporte rien.
Espérance de gain       critère théoriquement optimal, coûteux à calculer
d'information

import numpy as np
from sklearn.cluster import KMeans

rng = np.random.default_rng(0)
etiquetes = np.zeros(len(X), dtype=bool)
etiquetes[rng.choice(len(X), 100, replace=False)] = True     # amorçage ALÉATOIRE

for tour in range(10):
    modele.fit(X[etiquetes], y[etiquetes])

    # 1. incertitude : la marge entre les deux classes les plus probables
    P = modele.predict_proba(X[~etiquetes])
    tries = np.sort(P, axis=1)
    marge = tries[:, -1] - tries[:, -2]              # petite marge = cas ambigu

    # 2. on présélectionne les 500 plus ambigus…
    candidats = np.where(~etiquetes)[0][np.argsort(marge)[:500]]

    # 3. …puis on impose la DIVERSITÉ : un représentant par groupe
    km = KMeans(n_clusters=50, n_init=5, random_state=0).fit(Z[candidats])
    lot = [candidats[np.argmin(np.linalg.norm(Z[candidats] - c, axis=1))]
           for c in km.cluster_centers_]

    y[lot] = annoter(X[lot])                          # LA seule étape coûteuse
    etiquetes[lot] = True
    print(f"tour {tour}: {etiquetes.sum()} étiquettes, "
          f"score={modele.score(X_test_aleatoire, y_test_aleatoire):.3f}")

4. Semi-supervisé

On exploite les données non étiquetées pour contraindre le modèle. Deux hypothèses le justifient : les points d'un même groupe dense partagent probablement une étiquette (hypothèse de cluster), et la frontière de décision passe dans les zones de faible densité — elle sépare les paquets plutôt que de les traverser.

• Pseudo-étiquetage — le modèle étiquette lui-même les cas où il est très confiant, et se réentraîne dessus. Simple et souvent efficace, mais il amplifie ses propres erreurs : une erreur confiante devient une étiquette d'entraînement, donc une erreur encore plus confiante. Indispensable de fixer un seuil de confiance élevé (0,95 et plus), de recalibrer les probabilités (module 8) et de vérifier la performance à chaque tour sur un jeu annoté.
• Régularisation par cohérence — exiger que deux versions augmentées de la même donnée reçoivent la même prédiction. C'est l'idée de FixMatch : une augmentation faible produit la pseudo-étiquette, une augmentation forte doit la reproduire. Le modèle apprend ainsi ce à quoi il doit être invariant, sans étiquette humaine. L'une des méthodes les plus efficaces en vision avec très peu d'étiquettes.
• Propagation sur graphe — construire un graphe de voisinage (module 18) et diffuser les étiquettes le long des arêtes, de proche en proche.

Une mise en garde honnête : le semi-supervisé peut dégrader la performance si ses hypothèses ne tiennent pas — classes qui se chevauchent fortement, ou données non étiquetées issues d'une distribution différente (un autre capteur, une autre période). Il faut donc toujours le comparer à la baseline purement supervisée sur le même jeu de test, et accepter de l'abandonner.

5. Auto-supervisé

Ici, on fabrique une tâche à partir des données elles-mêmes, sans aucune étiquette humaine, dans le seul but d'apprendre de bonnes représentations — qu'un petit modèle supervisé exploitera ensuite. C'est ce qui a permis de pré-entraîner sur des corpus gigantesques non annotés, et c'est à l'origine des grands modèles actuels.

• Contrastif (SimCLR, MoCo) — rapprocher dans l'espace de représentation deux vues augmentées d'une même donnée, éloigner celles de données différentes. Le choix des augmentations définit les invariances apprises : si l'on inclut des variations de couleur, le modèle apprendra à ignorer la couleur — ce qui est souhaitable pour reconnaître un objet, catastrophique pour trier des composants par code couleur.
• Masquage (BERT pour le texte, MAE pour l'image) — cacher une partie de l'entrée et la reconstruire. Plus stable que le contrastif, sans besoin de paires négatives.
• Prédiction de contexte — prédire la suite d'un signal, l'ordre de fragments, la rotation appliquée à une image.

C'est l'approche à privilégier quand on possède beaucoup de données brutes spécifiques — des millions de spectres, d'images de production, de journaux machine — et peu d'annotations : un pré-entraînement sur ses propres données bat généralement un transfert depuis un domaine éloigné.

6. Supervision faible et étiquettes bruitées

Supervision faible

Plutôt que d'annoter exemple par exemple, on écrit des fonctions d'étiquetage : des règles, des expressions régulières, des seuils métier, un modèle existant. Chacune est imprécise et ne couvre qu'une partie des données ; prises ensemble, elles se recoupent. Un modèle génératif (approche Snorkel) estime alors la fiabilité de chaque règle à partir de leurs accords et désaccords — sans connaître la vérité — et produit des étiquettes probabilistes pour tout le corpus.

from snorkel.labeling import labeling_function, PandasLFApplier, LabelModel

ABSTIEN, NEGATIF, POSITIF = -1, 0, 1

@labeling_function()
def contient_mot_cle(x):
    return POSITIF if "remboursement" in x.texte.lower() else ABSTIEN

@labeling_function()
def montant_eleve(x):
    return POSITIF if x.montant > 5000 else ABSTIEN

@labeling_function()
def client_historique(x):
    return NEGATIF if x.anciennete_ans > 10 else ABSTIEN

L = PandasLFApplier([contient_mot_cle, montant_eleve, client_historique]).apply(df)
modele_etiquettes = LabelModel(cardinality=2).fit(L)      # estime la fiabilité de chaque règle
y_probable = modele_etiquettes.predict_proba(L)[:, 1]     # étiquettes PROBABILISTES

Trois experts qui écrivent dix règles en une journée produisent souvent l'équivalent de plusieurs semaines d'annotation manuelle — et les règles se documentent, se versionnent et se corrigent, contrairement à des étiquettes figées.

Étiquettes bruitées

Elles sont la norme, pas l'exception : les jeux de référence publics eux-mêmes contiennent quelques pour cent d'erreurs. Les défenses efficaces :

• Pertes robustes — MAE, Huber ou perte symétrique plutôt qu'entropie croisée pure, qui sur-pénalise les exemples mal étiquetés (elle tend vers l'infini quand le modèle contredit fortement l'étiquette).
• Label smoothing — remplacer la cible 1 par 0,9 : le modèle cesse de chercher une certitude absolue, ce qui limite l'effet des étiquettes fausses.
• Co-teaching — entraîner deux réseaux qui s'échangent les exemples de faible perte, considérés comme plus fiables.
• Détecter les erreurs — un modèle entraîné en validation croisée et très confiant en désaccord avec l'étiquette signale un cas à re-vérifier. cleanlab automatise cette recherche.

from cleanlab.filter import find_label_issues
from sklearn.model_selection import cross_val_predict

proba = cross_val_predict(modele, X, y, cv=5, method="predict_proba")
suspects = find_label_issues(labels=y, pred_probs=proba, return_indices_ranked_by="self_confidence")
print(f"{len(suspects)} étiquettes suspectes sur {len(y)}")
# relire les 50 premières à la main : c'est souvent l'heure la mieux investie du projet

Corriger 2 % d'étiquettes fausses rapporte souvent davantage que tout le réglage d'hyperparamètres — et le gain est permanent, puisqu'il porte sur les données et non sur un modèle.

7. Données synthétiques et simulation

Quand un simulateur du phénomène existe — et c'est fréquent en ingénierie (module 21) — il devient une source illimitée de données étiquetées, puisque la vérité terrain est connue par construction. Le problème est le fossé simulation-réalité : un modèle entraîné sur des images de synthèse échoue sur des images réelles à cause de différences subtiles de texture, de bruit et d'éclairage que l'œil humain ne remarque même pas.

• Randomisation de domaine — faire varier massivement, et même de façon exagérée, les paramètres non essentiels du simulateur : textures, éclairages, bruits, frottements, couleurs. Le monde réel devient alors « un cas parmi d'autres » du domaine d'entraînement, et le modèle apprend à ignorer ce qui varie. C'est la technique qui a permis les transferts sim2real les plus convaincants en robotique (module 20).
• Mélange et ajustement — pré-entraîner sur le synthétique, affiner sur un petit jeu réel. Très efficace, et souvent tout ce dont on a besoin.
• Génération par modèle — VAE, GAN, modèles de diffusion, ou LLM pour du texte. Utile pour équilibrer des classes rares, mais un modèle génératif n'invente rien : il recombine ce qu'il a vu. Entraîner massivement sur des données générées appauvrit progressivement la diversité.
• Confidentialité — les données synthétiques sont parfois présentées comme une solution au partage de données personnelles. À manier avec prudence : sans garantie formelle (confidentialité différentielle, module 27), un générateur peut mémoriser et restituer des enregistrements réels.

8. Few-shot et zero-shot

Les grands modèles pré-entraînés ont déplacé la frontière : un LLM (module 22) classe correctement du texte avec trois exemples dans son prompt, CLIP (module 18) reconnaît des catégories décrites en langage naturel sans aucun exemple étiqueté. Pour un prototype ou une tâche à faible volume, c'est souvent la solution la plus rapide — et elle permet surtout de tester la valeur du projet avant d'investir dans l'annotation.

Trois réserves. Le coût par prédiction reste élevé : un appel de modèle par exemple, contre quelques microsecondes pour une régression logistique. La performance plafonne en dessous de ce qu'atteint un petit modèle spécialisé bien entraîné, dès que le domaine est technique. Et la dépendance à un fournisseur externe pose des questions de confidentialité et de reproductibilité (module 27).

La trajectoire raisonnable est donc : démarrer en zero-shot pour valider l'intérêt, utiliser le grand modèle pour pré-annoter en faisant valider par un expert (ce qui divise le temps d'annotation par trois ou quatre), puis distiller le tout dans un petit modèle maison qui sera des milliers de fois moins cher à l'inférence.

9. Décider combien annoter

La question la plus utile du module se pose en euros : faut-il annoter mille exemples de plus, ou changer de modèle ? La courbe d'apprentissage y répond empiriquement — on entraîne sur des fractions croissantes des étiquettes disponibles et on extrapole.

import numpy as np
from sklearn.model_selection import learning_curve
from scipy.optimize import curve_fit

tailles, score_train, score_val = learning_curve(
    modele, X, y, train_sizes=np.linspace(0.1, 1.0, 8),
    cv=5, scoring="average_precision", n_jobs=-1)

# la performance suit typiquement une loi de puissance : erreur ≈ a·n^(-b) + c
def loi(n, a, b, c): return a * n ** (-b) + c
(a, b, c), _ = curve_fit(loi, tailles, 1 - score_val.mean(axis=1), p0=[1, 0.5, 0.05])

for n in (2_000, 5_000, 10_000):
    print(f"{n} étiquettes → erreur prédite {loi(n, a, b, c):.3f}")
# c est l'erreur INCOMPRESSIBLE : si elle est déjà proche du score actuel,
# annoter davantage ne changera rien.

La lecture décide de la suite. Si la courbe de validation monte encore nettement, annoter davantage est le meilleur investissement. Si elle a plafonné loin du niveau souhaité, le problème est ailleurs — variables insuffisantes, étiquettes bruitées, ou tâche intrinsèquement difficile — et mille annotations de plus ne changeront rien. C'est le même raisonnement que le diagnostic biais-variance du module 14, mais exprimé en budget.

Sur données tabulaires — c'est-à-dire l'immense majorité des problèmes industriels — le deep learning ne domine pas. Les méthodes de ce module restent l'état de l'art, s'entraînent en secondes, s'expliquent, et se déploient sans GPU. On les passe en revue par famille, avec pour chacune le mécanisme réel, les cas d'usage, et les raisons de s'en méfier.

1. Biais, variance et capacité

Pour une prédiction en un point \(x\), l'erreur quadratique attendue — moyennée sur tous les jeux d'entraînement possibles — se décompose en trois termes :

Le biais mesure l'erreur systématique due à l'hypothèse de modèle : une droite ne peut pas épouser une parabole, quel que soit le nombre de points. La variance mesure la sensibilité au jeu d'entraînement particulier : un modèle très flexible dessine une courbe différente à chaque échantillon. Le bruit est la part qu'aucun modèle ne peut expliquer, parce qu'elle n'est pas dans les données.

  BIAIS FAIBLE, VARIANCE FAIBLE     BIAIS FAIBLE, VARIANCE FORTE
  (l'idéal)                          (surapprentissage)
        ·:·                                ·      ·
       ·:@:·   groupé, au centre        ·   · @ ·      dispersé autour du centre
        ·:·                              ·    ·   ·

  BIAIS FORT, VARIANCE FAIBLE        BIAIS FORT, VARIANCE FORTE
  (sous-apprentissage)               (le pire des deux)
   ·:·                                ·  ·
  ·:·      @  groupé, mais à côté      · · ·     @   dispersé ET décalé
   ·:·                                  ·   ·

Augmenter la capacité d'un modèle baisse le biais et monte la variance. Le surapprentissage, c'est le régime où la seconde l'emporte : le modèle mémorise le bruit de son échantillon. Le module 15 montre que ce tableau classique se complique en très haute dimension.

2. Modèles linéaires et régularisation

Le modèle \(\hat{y} = \beta_0 + \sum_j \beta_j x_j\) reste le point de départ obligé : rapide, interprétable, statistiquement bien compris, et souvent une baseline difficile à battre quand les variables sont bien construites (module 12).

Ridge (L²)     pénalité λ·Σβ²     rétrécit tous les coefficients, n'en annule aucun.
                                  Idéal en présence de colinéarité : répartit le poids
                                  entre variables corrélées au lieu d'en choisir une.
Lasso (L¹)     pénalité λ·Σ|β|    annule certains coefficients → sélection automatique.
                                  Instable si les variables sont très corrélées : il en
                                  choisit une presque au hasard dans chaque groupe.
Elastic-Net    combinaison        compromis : sélection ET stabilité sur groupes corrélés.

L'intuition géométrique de la différence mérite un dessin. On minimise l'erreur sous la contrainte que \(\beta\) reste dans une boule de rayon fixé. La boule \(L^2\) est ronde : la solution optimale la touche presque toujours en un point où aucune coordonnée n'est nulle. La boule \(L^1\) est un losange, avec des coins pointus sur les axes : le contact se fait fréquemment sur un coin, c'est-à-dire avec des coefficients exactement nuls.

        L² (ridge)                      L¹ (lasso)
   β₂ │    ⌒⌒⌒                     β₂ │      ◆
      │  ⌒  ●  ⌒  ← contact           │    ◆ ●◆   ← contact SUR L'AXE
      │ ⌒( )    ⌒    hors des axes    │  ◆  │  ◆     donc β₂ = 0
      │  ⌒⌒⌒                          │    ◆│◆
      └──────────── β₁                └──────────── β₁

Le module 8 en donne la lecture spectrale pour ridge — un filtrage qui écrase les directions de faible variance — et le module 10 la lecture bayésienne : un a priori gaussien pour ridge, laplacien pour le lasso.

from sklearn.linear_model import RidgeCV, LassoCV, ElasticNetCV
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
import numpy as np

# la standardisation est OBLIGATOIRE : la pénalité s'applique aux coefficients,
# donc à des grandeurs qui doivent être comparables (module 8)
modele = make_pipeline(
    StandardScaler(),
    RidgeCV(alphas=np.logspace(-3, 3, 50)),      # λ choisi par validation croisée
).fit(X, y)

print(modele[-1].alpha_)                          # le λ retenu
coefs = modele[-1].coef_
print(sorted(zip(np.abs(coefs), noms), reverse=True)[:10])   # variables les plus pesantes

3. Régression logistique

Pour la classification, on ne peut pas prédire directement une probabilité avec un modèle linéaire : celui-ci produirait des valeurs hors de [0, 1]. On modélise donc le logarithme de la cote (le rapport « probabilité de succès sur probabilité d'échec ») :

La fonction de droite est la sigmoïde : elle écrase toute la droite réelle dans l'intervalle ]0, 1[, de façon monotone et dérivable. L'estimation se fait par maximum de vraisemblance, ce qui revient — module 10 — à minimiser l'entropie croisée.

L'interprétation des coefficients est directe et c'est ce qui fait la valeur du modèle : \(e^{\beta_j}\) est le facteur multiplicatif sur la cote quand \(x_j\) augmente d'une unité. Un coefficient de 0,7 signifie que la cote est multipliée par \(e^{0{,}7} \approx 2\) : le phénomène devient deux fois plus « probable » au sens de la cote. C'est le modèle de référence quand l'explication compte autant que la performance — scoring de crédit, épidémiologie —, et ses probabilités sont naturellement bien calibrées, ce qui n'est pas le cas d'un gradient boosting.

4. SVM et astuce du noyau

Une machine à vecteurs de support cherche l'hyperplan séparateur qui maximise la marge — la distance aux points les plus proches de chaque classe. L'idée : parmi toutes les frontières qui séparent correctement les données, celle qui laisse le plus de place de part et d'autre est la plus susceptible de bien généraliser.

     ○ ○        │        × ×          ── la frontière
   ○   ○  ┊     │     ┊  ×            ┊  les marges
    ○  ●──┊─────│─────┊──●  ×         ●  les VECTEURS DE SUPPORT : seuls
   ○    ○ ┊     │     ┊ ×  ×             ces points déterminent la solution
     ○      ←── marge ──→   ×            (déplacer les autres ne change rien)

La formulation à marge souple autorise des violations, pénalisées par un paramètre \(C\) :

Le premier terme maximise la marge (une petite norme de \(w\) donne une large marge), le second compte les violations. Seuls les points sur ou à l'intérieur de la marge — les vecteurs de support — interviennent dans la solution, ce qui rend le modèle insensible aux points éloignés de la frontière.

L'astuce du noyau est l'idée élégante. La solution ne dépend des données qu'à travers des produits scalaires \(x_i^\top x_j\). En les remplaçant par une fonction noyau \(k(x_i,x_j)\), on travaille implicitement dans un espace de dimension bien plus grande — voire infinie pour le noyau RBF \(k(x,x') = \exp(-\gamma\|x-x'\|^2)\) — sans jamais calculer les coordonnées dans cet espace. Une frontière non linéaire dans l'espace d'origine devient linéaire dans l'espace induit. On retrouvera exactement ce mécanisme dans les processus gaussiens (module 19).

Réglages : \(C\) contrôle le compromis marge/erreurs (grand \(C\) = peu de tolérance = risque de surapprentissage), \(\gamma\) la portée d'influence d'un point (grand \(\gamma\) = influence très locale = frontière tourmentée). Les deux se règlent ensemble, sur une grille logarithmique.

Limites : le coût est au moins quadratique en nombre d'exemples — au-delà de quelques dizaines de milliers de points, le SVM à noyau devient impraticable ; il exige des variables standardisées (il repose sur des distances) ; et il ne fournit pas de probabilités, celles de predict_proba venant d'une calibration de Platt ajoutée après coup, qui coûte une validation croisée supplémentaire. Il reste excellent quand les exemples sont peu nombreux et les variables nombreuses — chimiométrie, bio-informatique, spectroscopie.

5. Arbres de décision

Un arbre CART partitionne récursivement l'espace par des coupes perpendiculaires aux axes. À chaque nœud, il teste toutes les variables et tous les seuils possibles, et retient la coupe qui rend les enfants les plus « purs ».

Nœud parent : 100 exemples, 50 positifs → Gini = 1 - (0,5² + 0,5²) = 0,500

Coupe candidate A : surface < 60
  gauche  40 exemples, 10 positifs → Gini = 1 - (0,25² + 0,75²) = 0,375
  droite  60 exemples, 40 positifs → Gini = 1 - (0,67² + 0,33²) = 0,444
  impureté pondérée = 0,4×0,375 + 0,6×0,444 = 0,417   → gain 0,083

Coupe candidate B : ville = Lyon
  gauche  50 exemples, 45 positifs → Gini = 0,180
  droite  50 exemples,  5 positifs → Gini = 0,180
  impureté pondérée = 0,180                            → gain 0,320  ← RETENUE

L'indice de Gini \(\sum_k p_k(1-p_k)\) vaut 0 pour un nœud pur et 0,5 pour un nœud parfaitement mélangé (en binaire). L'entropie donne des résultats très proches ; en régression, on minimise la variance intra-nœud.

Avantages : aucun prétraitement (insensible aux échelles et à toute transformation monotone — prendre le logarithme d'une variable ne change strictement rien), gestion naturelle des variables catégorielles et des interactions, lecture directe des règles. Défaut rédhibitoire : un arbre profond mémorise, un arbre court sous-apprend, et surtout l'arbre est instable — changer quelques points d'entraînement peut produire une structure entièrement différente. Cette instabilité est précisément ce que les méthodes d'ensemble vont transformer en atout.

6. Bagging et forêts aléatoires

Le bagging (bootstrap aggregating) entraîne \(B\) modèles sur des échantillons bootstrap — tirés avec remise dans les données d'origine — et moyenne leurs prédictions. Si les modèles étaient indépendants, la variance serait divisée par \(B\) ; en pratique ils sont corrélés puisqu'ils voient presque les mêmes données, et le gain est plus modeste.

La forêt aléatoire ajoute une seconde source d'aléa pour les décorréler davantage : à chaque nœud, seules \(m\) variables tirées au hasard sont candidates (typiquement \(\sqrt{p}\) en classification, \(p/3\) en régression). Chaque arbre devient un peu moins bon individuellement, mais l'ensemble s'améliore nettement — c'est le compromis central de la méthode.

from sklearn.ensemble import RandomForestClassifier
from sklearn.inspection import permutation_importance

rf = RandomForestClassifier(
    n_estimators=500,        # plus il y en a, mieux c'est (on sature) — jamais de
                             # surapprentissage en augmentant ce nombre
    max_features="sqrt",     # LA source de décorrélation
    min_samples_leaf=5,      # le vrai levier de régularisation
    oob_score=True,          # évaluation gratuite (voir ci-dessous)
    n_jobs=-1, random_state=0,
).fit(X_train, y_train)

print(rf.oob_score_)

# importance FIABLE : on mélange une colonne et on mesure la perte de performance
imp = permutation_importance(rf, X_val, y_val, n_repeats=10, n_jobs=-1)
for i in imp.importances_mean.argsort()[::-1][:10]:
    print(f"{noms[i]:25s} {imp.importances_mean[i]:.4f} ± {imp.importances_std[i]:.4f}")

L'échantillonnage bootstrap laisse environ 37 % des points hors de chaque arbre — c'est la limite de \((1-1/n)^n = e^{-1}\). Ces points out-of-bag fournissent une estimation de performance quasi gratuite, sans validation croisée : chaque observation est évaluée par les arbres qui ne l'ont pas vue.

7. Boosting : XGBoost et ses cousins

Là où le bagging construit des modèles en parallèle pour réduire la variance, le boosting les construit en séquence pour réduire le biais : chaque nouveau modèle corrige ce que les précédents ont raté.

F₀ = moyenne(y) = 100          résidus : +20, -15, +5, -10
  ↓ un petit arbre apprend ces RÉSIDUS, pas la cible
F₁ = F₀ + ν·h₁                 résidus restants : +8, -6, +2, -4   (plus petits)
  ↓ un nouvel arbre apprend les résidus RESTANTS
F₂ = F₁ + ν·h₂                 résidus restants : +3, -2, +1, -1
  ↓ …et ainsi de suite, sur des centaines d'arbres
                               ν (learning rate) amortit chaque correction :
                               petit ν = corrections prudentes = plus d'arbres

Le gradient boosting généralise cette idée à n'importe quelle perte dérivable, en remplaçant le résidu par l'opposé du gradient de la perte par rapport à la prédiction courante — d'où le nom :

Avec la perte quadratique, ces pseudo-résidus sont exactement les résidus ordinaires, ce qui fait le lien avec le schéma ci-dessus. XGBoost raffine en utilisant aussi la dérivée seconde (approximation de Newton, module 8) et en intégrant la régularisation directement dans le critère de coupe.

import xgboost as xgb

modele = xgb.XGBClassifier(
    n_estimators=2000,          # volontairement grand : l'early stopping tranchera
    learning_rate=0.05,         # plus il est bas, plus il faut d'arbres : compromis n°1
    max_depth=6,                # 3-8 typiquement ; profondeur = ordre des interactions
                                # capturées (profondeur 3 = interactions à 3 variables)
    min_child_weight=5,         # poids minimal dans une feuille : anti-surapprentissage
    subsample=0.8,              # 80 % des LIGNES par arbre : du bruit utile
    colsample_bytree=0.8,       # 80 % des COLONNES par arbre : décorrélation
    reg_lambda=1.0,             # L² sur les poids des feuilles
    eval_metric="aucpr",
    early_stopping_rounds=100,  # arrête quand la validation ne progresse plus
)
modele.fit(X_train, y_train, eval_set=[(X_val, y_val)], verbose=False)
print(f"meilleur nombre d'arbres : {modele.best_iteration}")

XGBoost     la référence, très réglable, excellent support GPU, écosystème mature.
LightGBM    croissance par FEUILLE (leaf-wise) plutôt que par niveau, et binning en
            histogrammes : nettement plus rapide sur grands jeux. Peut surapprendre
            si num_leaves est trop grand.
CatBoost    gère nativement les catégorielles avec un target encoding ordonné (donc
            sans fuite, module 12), excellents résultats par défaut. Souvent le
            meilleur choix quand il y a beaucoup de variables catégorielles à
            forte cardinalité.

Une bonne pratique : commencer par HistGradientBoostingClassifier de scikit-learn — pas de dépendance supplémentaire, gestion native des valeurs manquantes, performances très proches. Le réglage fin des variantes vient après, et rapporte généralement quelques pourcents, pas un changement de nature.

8. Stacking

Trois façons de combiner des modèles : le vote ou la moyenne (simple, robuste), le blending pondéré (poids optimisés sur un jeu de validation) et le stacking, où un méta-modèle apprend à combiner les prédictions des modèles de base. La condition de réussite est toujours la même : les modèles combinés doivent se tromper différemment. Assembler cinq gradient boosting aux réglages voisins n'apporte rien ; combiner un modèle linéaire, un boosting et un k-NN apporte souvent quelques points.

Le stacking impose une précaution stricte : les prédictions servant à entraîner le méta-modèle doivent être produites hors échantillon, par validation croisée. Sinon le méta-modèle apprend sur des prédictions déjà ajustées sur ces points, et la fuite est garantie. StackingClassifier s'en charge automatiquement.

9. Clustering et détection d'anomalies

k-means minimise l'inertie intra-classe \(\sum_k \sum_{x \in C_k}\|x-\mu_k\|^2\) en alternant deux étapes jusqu'à stabilisation :

1. AFFECTATION : chaque point rejoint le centre le plus proche
2. MISE À JOUR : chaque centre se replace au barycentre de ses points
   → répéter. L'inertie décroît à chaque étape, donc l'algorithme converge
     (vers un optimum LOCAL, qui dépend de l'initialisation → k-means++)

Rapide et simple, mais il suppose des groupes sphériques de tailles comparables, exige de fixer \(k\) à l'avance, et affecte forcément tous les points — y compris les aberrants, qui déplacent les centres.

DBSCAN        groupes de forme quelconque, détecte le BRUIT (points non affectés),
              pas de k à fixer. Mais deux paramètres sensibles (eps, min_samples)
              et souffre en grande dimension.
HDBSCAN       version hiérarchique de DBSCAN : plus robuste, un seul paramètre
              principal. Mon défaut quand la structure des groupes est inconnue.
Hiérarchique  produit un dendrogramme : on choisit le nombre de groupes APRÈS coup,
              en coupant l'arbre. O(n²) : réservé aux petits jeux, mais très parlant.
GMM           mélange de gaussiennes : affectation PROBABILISTE, groupes
              ellipsoïdaux, sélection de k par BIC. Le bon choix quand les groupes
              se chevauchent.

Évaluer un clustering est intrinsèquement ambigu, puisqu'il n'y a pas de vérité terrain. Le coefficient de silhouette compare, pour chaque point, sa distance moyenne à son groupe et au groupe voisin le plus proche : il varie de −1 à 1, et une valeur négative signale un point probablement mal affecté. La méthode du coude sur l'inertie est populaire mais souvent illisible. Le vrai critère reste l'utilité : un clustering est bon s'il produit des segments sur lesquels on peut agir différemment.

Détection d'anomalies : IsolationForest isole les points atypiques par découpes aléatoires — un point anormal se retrouve seul en peu de coupes, ce qui donne un score directement exploitable ; LocalOutlierFactor compare la densité locale d'un point à celle de ses voisins ; et l'erreur de reconstruction d'une PCA (module 8) ou d'un autoencodeur (module 16) fonctionne très bien quand les données ont une structure de faible rang.

10. Recherche d'hyperparamètres

GridSearchCV           exhaustif sur une grille. Explose combinatoirement ; à réserver
                       à 2-3 paramètres peu nombreux.
RandomizedSearchCV     tirage aléatoire. Meilleur que la grille dès 3+ paramètres :
                       seuls quelques-uns comptent vraiment, et l'aléatoire les
                       explore sur bien plus de valeurs distinctes.
HalvingRandomSearchCV  successive halving : beaucoup de candidats sur peu de données,
                       puis on élimine les pires et on affine. Excellent rapport
                       coût/résultat.
Optuna (TPE)           recherche bayésienne : un modèle probabiliste guide les essais.
                       Le meilleur choix quand chaque entraînement est coûteux (module 19).

import optuna

def objectif(essai):
    params = {
        # échelle LOGARITHMIQUE pour les paramètres multiplicatifs
        "learning_rate": essai.suggest_float("learning_rate", 1e-3, 0.3, log=True),
        "num_leaves":    essai.suggest_int("num_leaves", 15, 255, log=True),
        "min_child_samples": essai.suggest_int("min_child_samples", 5, 200),
        "subsample":     essai.suggest_float("subsample", 0.5, 1.0),
        "reg_lambda":    essai.suggest_float("reg_lambda", 1e-3, 10, log=True),
    }
    scores = cross_val_score(LGBMClassifier(**params), X, y, cv=5,
                             scoring="average_precision")
    return scores.mean()

etude = optuna.create_study(direction="maximize",
                            pruner=optuna.pruners.MedianPruner())
etude.optimize(objectif, n_trials=100, n_jobs=4)
print(etude.best_params, etude.best_value)
optuna.visualization.plot_param_importances(etude)   # quels paramètres comptaient

Deux règles pratiques : chercher sur une échelle logarithmique pour les paramètres multiplicatifs (taux d'apprentissage, \(C\), \(\lambda\)), et se rappeler que le gain d'un réglage fin — quelques pourcents — est presque toujours inférieur au gain d'une bonne variable ou de données supplémentaires. Optimiser 200 configurations en regardant le score de test transforme par ailleurs ce test en jeu d'entraînement (module 12).

11. Interprétabilité

• Importance par permutation — mélanger une colonne et mesurer la perte de performance. Global, fiable, agnostique au modèle ; à calculer sur un jeu de validation. Attention aux variables corrélées : mélanger l'une alors que l'autre porte la même information sous-estime les deux.
• PDP et ICE — le partial dependence plot montre l'effet moyen d'une variable sur la prédiction, en faisant varier cette variable pour tous les individus ; les courbes ICE font de même individu par individu et révèlent les effets hétérogènes que la moyenne masque (si la moitié des courbes monte et l'autre descend, le PDP est plat et trompeur).
• SHAP — issu de la théorie des jeux, il attribue à chaque variable sa contribution marginale moyenne sur tous les ordres d'inclusion possibles. C'est la seule méthode à satisfaire des axiomes d'équité (efficacité : les contributions somment à l'écart entre la prédiction et la moyenne ; symétrie ; nullité d'une variable inutile), avec une version exacte et rapide pour les arbres.

import shap

explainer = shap.TreeExplainer(modele)
valeurs = explainer(X_val)

shap.plots.beeswarm(valeurs)        # vue globale : importance ET sens de l'effet
shap.plots.waterfall(valeurs[42])   # pourquoi CETTE prédiction : contribution par variable
shap.plots.scatter(valeurs[:, "surface"], color=valeurs)   # forme de l'effet + interaction

12. Tableau comparatif et pièges

Famille           Forces                         Faiblesses                  Quand
──────────────────────────────────────────────────────────────────────────────────────
Linéaire/logit    interprétable, rapide,         suppose la linéarité,       baseline,
                  calibré, fiable en petit n     sensible à la colinéarité   explication
Régularisé        gère p > n, sélectionne        réglage de λ nécessaire     haute dimension
k-NN              aucun apprentissage,           coûteux en prédiction,      petits jeux,
                  non linéaire                   fléau de la dimension       recommandation
Naive Bayes       très rapide, marche en très    hypothèse d'indépendance    texte,
                  haute dimension                irréaliste                  baseline NLP
SVM noyau         frontières complexes, robuste  O(n²), pas de probas,       n petit,
                                                 opaque, standardisation     p grand
Arbre             lisible, sans prétraitement    instable, peu performant    explication
                                                 seul
Random Forest     robuste, peu de réglage, OOB   modèle volumineux, moins    défaut solide
                                                 précis que le boosting
Gradient boosting meilleur sur tabulaire, gère   plus de réglages, sensible  production
                  les manquants, early stopping  au bruit des étiquettes     tabulaire
Clustering        découverte non supervisée      évaluation ambiguë          segmentation

Tout le cours repose sur un pari implicite : un modèle ajusté sur \(n\) exemples fonctionnera sur des données jamais vues. Rien ne le garantit a priori — un modèle peut parfaitement mémoriser son jeu d'entraînement sans rien avoir appris. Ce module expose ce que la théorie sait démontrer, ce qu'elle n'explique toujours pas (notamment le succès des réseaux profonds), et ce qu'un praticien doit en retenir.

1. Le cadre PAC

Le cadre probablement approximativement correct (Valiant, 1984) formalise l'objectif : avec une probabilité d'au moins \(1-\delta\) sur le tirage de l'échantillon (« probablement »), l'erreur réelle doit être proche de l'erreur empirique (« approximativement correct »). On veut donc borner l'écart de généralisation :

Pour une hypothèse fixée à l'avance, c'est facile : l'erreur empirique est une moyenne de variables aléatoires bornées, et l'inégalité de Hoeffding donne un écart en \(O(1/\sqrt{n})\). Mais c'est justement ce qu'on ne fait pas : on choisit \(h\) après avoir vu les données, en prenant celle qui minimise l'erreur empirique parmi toute une classe \(\mathcal{H}\). Or le maximum d'un grand nombre d'écarts est bien plus grand que chacun d'eux pris isolément — c'est le même phénomène que les comparaisons multiples du module 9. Il faut donc une borne uniforme, valable simultanément pour toutes les hypothèses de la classe :

La structure de ce résultat est l'essentiel : erreur réelle ≤ erreur observée + terme de complexité / \(\sqrt{n}\). Plus la classe de modèles est riche, plus il faut de données pour que l'erreur empirique reste informative. C'est la formalisation exacte du surapprentissage, et la justification théorique de la régularisation (module 8).

2. Dimension VC et complexité de Rademacher

Pour une classe infinie — tous les hyperplans, tous les réseaux d'une architecture donnée —, \(\log|\mathcal H|\) n'a plus de sens. La dimension de Vapnik-Chervonenkis le remplace : c'est le plus grand nombre de points que la classe peut pulvériser, c'est-à-dire séparer correctement quelle que soit la façon de les étiqueter.

3 points non alignés : une droite peut réaliser les 2³ = 8 étiquetages possibles
   ○ ○        ● ○        ● ●        ○ ●
    ○          ○          ○          ●     … toutes les combinaisons sont
  possible   possible   possible   possible    séparables par une droite

4 points : l'étiquetage "en diagonale" (XOR) est IMPOSSIBLE
   ● ○
   ○ ●    aucune droite ne sépare les ● des ○

→ dimension VC d'une droite dans le plan = 3, soit p + 1 avec p = 2 dimensions

La borne devient alors :

La lecture pratique : il faut environ autant d'exemples que de « degrés de liberté effectifs » pour espérer généraliser. La complexité de Rademacher raffine cette idée en mesurant directement la capacité de la classe à s'ajuster à du bruit pur — on remplace les étiquettes par des tirages à pile ou face et on regarde jusqu'où le modèle parvient à les suivre. C'est une définition plus fine, dépendante des données et de leur distribution, donc souvent bien moins pessimiste.

3. Pas de repas gratuit : le biais inductif

Le théorème du no free lunch (Wolpert) énonce que, moyenné sur toutes les fonctions cibles possibles, tous les algorithmes d'apprentissage ont exactement la même performance. Aucun n'est universellement supérieur ; un algorithme qui bat un autre sur une classe de problèmes lui est nécessairement inférieur sur une autre.

Souvent cité comme une curiosité, ce résultat dit en réalité quelque chose de fondamental : apprendre est impossible sans hypothèse préalable. Si toutes les fonctions étaient également plausibles, observer un million de points ne dirait rien du suivant — n'importe quelle valeur resterait compatible avec les données. Ce qui fonctionne en pratique fonctionne parce que le monde réel n'est pas un tirage uniforme parmi toutes les fonctions : il est structuré — régulier, local, hiérarchique, invariant par certaines transformations, parcimonieux.

Modèle linéaire   l'effet de chaque variable est additif et proportionnel
Arbre             la réponse est constante par morceaux ; effets de SEUIL
Noyau RBF         deux points proches ont des valeurs proches ; fonction LISSE
Convolution       l'information est LOCALE et invariante par translation
Attention         des dépendances existent entre positions éloignées
GNN               l'information circule le long des ARÊTES d'un graphe
PINN / contrainte la solution obéit à une équation physique connue
physique

Choisir un modèle, c'est donc parier sur la structure du problème — le module 16 le formule déjà ainsi pour les architectures profondes. La conséquence pratique est nette : la connaissance du domaine est un gain de performance, pas un supplément d'âme. Imposer une symétrie connue, une monotonie ou une loi de conservation (module 21) vaut souvent mieux que dix fois plus de données.

4. Double descente et sur-paramétrisation

La théorie classique prédit une courbe en U : l'erreur de test décroît puis remonte quand la capacité augmente. Les réseaux profonds contredisent apparemment ce tableau — un modèle à des milliards de paramètres, ajusté jusqu'à erreur d'entraînement nulle, généralise très bien. La double descente réconcilie les observations :

  erreur │                    ╱╲  ← pic au SEUIL D'INTERPOLATION
  de test │  ╲               ╱  ╲     (capacité ≈ nombre d'exemples)
          │   ╲___╱╲       ╱     ╲
          │          ╲___╱        ╲________________  ← 2ᵉ descente, souvent
          │                                            SOUS le minimum classique
          └────────────────────────────────────────────────► capacité du modèle
             régime         seuil          régime SUR-paramétré
             classique                     (l'erreur d'entraînement est nulle
             (le U)                         partout dans cette zone)

Au seuil d'interpolation, le modèle atteint tout juste l'erreur d'entraînement nulle : il existe une unique solution qui passe par tous les points, et elle est extrêmement contrainte, donc très instable — d'où le pic. Au-delà, une infinité de paramétrages atteignent une erreur nulle, et l'algorithme d'optimisation en choisit un : il se trouve qu'il choisit systématiquement une solution « simple » au sens d'une norme (section suivante). Autrement dit, ce n'est plus la taille de la classe qui gouverne la généralisation, mais la solution que l'optimiseur sélectionne à l'intérieur de cette classe. La complexité pertinente n'est pas le nombre de paramètres.

5. La régularisation implicite de SGD

Cette sélection a un nom : la régularisation implicite. Deux résultats exacts la caractérisent dans des cas simples.

Sur un problème linéaire séparable avec perte logistique, la descente de gradient converge vers le séparateur à marge maximale — le même que celui du SVM (module 14) — sans qu'aucune régularisation n'ait été écrite. Sur un système sous-déterminé avec perte quadratique, partant de zéro, elle converge vers la solution de norme minimale, exactement celle que donne la pseudo-inverse (module 8).

À cela s'ajoutent des effets bien documentés empiriquement. Le bruit stochastique des mini-lots favorise les minima « plats » — ceux dont le fond de vallée est large — dont on observe qu'ils généralisent mieux que les minima « pointus » : intuitivement, une petite perturbation des poids ou des données y change peu la perte. Un grand taux d'apprentissage empêche de s'installer trop tôt dans une vallée étroite, ce qui explique pourquoi le warmup puis la décroissance (module 8) ne sont pas que des recettes. Et l'arrêt anticipé est lui-même une régularisation, équivalente dans le cas linéaire à une pénalité de type ridge.

La conclusion théorique importante : l'algorithme d'optimisation fait partie du modèle. On n'entraîne pas « une classe de fonctions », on entraîne un couple architecture-optimiseur, et c'est ce couple qui porte le biais inductif.

6. Stabilité, PAC-Bayes, compression

Trois approches modernes donnent des bornes plus informatives que la dimension VC :

• Stabilité algorithmique — si changer un seul exemple d'entraînement modifie peu la fonction apprise, alors l'algorithme généralise. Le résultat est élégant car il porte sur l'algorithme et non sur la classe de fonctions : SGD avec un pas décroissant est stable, ce qui fournit directement une borne. L'intuition est simple : un modèle qui change du tout au tout quand on retire un point mémorise ce point.
• PAC-Bayes — borne l'erreur d'une distribution de prédicteurs par son erreur empirique plus une divergence KL à une distribution a priori (module 10). C'est le cadre qui produit aujourd'hui les bornes non vides les plus serrées pour des réseaux de neurones réels, et il éclaire au passage le lien avec la platitude des minima : un minimum plat tolère du bruit sur les poids, donc autorise une distribution large, donc une faible divergence à l'a priori, donc une meilleure borne.
• Bornes par compression — si un réseau entraîné peut être fortement compressé (élagage, quantification) sans perte de performance, sa complexité effective est faible, et cela se traduit en borne. Ce point de vue relie généralisation et compressibilité, avec un écho direct aux pratiques du module 25.

7. Ce que la théorie n'explique pas

8. Ce qu'on en retient en pratique

• La complexité effective compte, pas le nombre de paramètres. Un grand modèle bien régularisé peut généraliser mieux qu'un petit modèle mal contraint — la double descente l'illustre.
• Le biais inductif est une ressource. Encoder une invariance connue, une contrainte physique ou une structure du domaine vaut souvent mieux que davantage de données.
• L'optimiseur fait partie du modèle. Taille de lot, taux d'apprentissage et arrêt anticipé changent la solution atteinte, pas seulement la vitesse pour y arriver.
• Les garanties théoriques ne sont pas des nombres utilisables. Pour une estimation chiffrée de la performance, la validation croisée (module 12) et un jeu de test intouché restent les seuls outils fiables ; pour une garantie exploitable en production, la prédiction conforme (module 10) donne une couverture démontrable à échantillon fini.
• Le no free lunch a une conséquence méthodologique. Comparer des modèles sans tenir compte du domaine n'a pas de sens universel : un classement sur un benchmark ne transfère pas automatiquement à votre problème, et c'est pourquoi la baseline maison reste la seule référence qui compte.

Le deep learning n'est pas un meilleur machine learning : c'est une famille de modèles qui apprennent leurs propres représentations, ce qui les rend imbattables là où les données brutes sont structurées et abondantes — images, son, texte, signaux — et souvent décevants ailleurs. Ce module couvre les architectures, les recettes d'entraînement qui font réellement la différence, et les PINN, qui relient réseaux de neurones et équations aux dérivées partielles.

1. Quand le deep learning est pertinent

Le deep learning gagne quand...          Le ML classique gagne quand...
──────────────────────────────────────────────────────────────────────────────
données brutes structurées               données tabulaires hétérogènes
(pixels, audio, texte, séquences)        (le boosting reste devant, module 14)
beaucoup de données (10⁴ – 10⁹)          peu de données (10² – 10⁴)
la REPRÉSENTATION est le problème        les variables métier existent déjà
une architecture pré-entraînée existe    l'interprétabilité est exigée
un GPU est disponible                    le coût d'inférence doit rester minimal

La question utile n'est donc pas « quel modèle est le meilleur » mais « existe-t-il un biais inductif adapté à mes données ? » (module 15). Une convolution encode l'invariance par translation ; une attention encode des dépendances à longue portée ; un arbre encode des effets de seuil. Choisir un modèle, c'est choisir l'hypothèse structurelle qui correspond au problème.

2. Du neurone au MLP

Un neurone calcule une somme pondérée de ses entrées, ajoute un biais, et passe le tout dans une fonction non linéaire : \(a = \sigma(w^\top x + b)\). Une couche est un ensemble de neurones qui voient les mêmes entrées, ce qui s'écrit matriciellement \(h = \sigma(Wx + b)\). Un perceptron multicouche (MLP) empile ces couches.

  entrée x        couche 1          couche 2         sortie
  (10 var.)      (64 neurones)     (32 neurones)     (1 valeur)

    x₁ ──┐        ┌─ σ(·) ─┐        ┌─ σ(·) ─┐
    x₂ ──┼─ W₁ ──►│  ...   │─ W₂ ──►│  ...   │─ W₃ ──► ŷ
    ...  │        │        │        │        │
    x₁₀ ─┘        └─ σ(·) ─┘        └─ σ(·) ─┘
                  (10×64 + 64      (64×32 + 32      (32×1 + 1
                   = 704 param.)    = 2 080 param.)  = 33 param.)

Sans la non-linéarité \(\sigma\), la composition de couches affines resterait affine : trois couches vaudraient une seule, et toute la profondeur serait inutile. C'est \(\sigma\) qui donne sa puissance à l'empilement. Le théorème d'approximation universelle garantit d'ailleurs qu'un réseau à une seule couche cachée suffisamment large approche n'importe quelle fonction continue sur un compact — résultat rassurant mais peu opérationnel, car il ne dit rien du nombre de neurones nécessaires ni de la possibilité d'apprendre ces poids. La profondeur, elle, permet d'exprimer certaines fonctions avec exponentiellement moins de paramètres que la largeur.

ReLU        max(0, x)          le défaut. Gradient constant à droite, nul à gauche —
                               d'où les neurones "morts" si le gradient les pousse
                               durablement dans la zone négative.
LeakyReLU   max(αx, x)         corrige les neurones morts avec une pente résiduelle.
GELU        x·Φ(x)             lisse ; le standard dans les transformers.
SiLU/Swish  x·sigmoid(x)       proche de GELU, très utilisé en vision moderne.
tanh        (-1, 1)            centrée ; encore utile dans les RNN et les PINN,
                               car ses dérivées d'ordre 2 sont lisses.
sigmoid     (0, 1)             réservée à la SORTIE binaire. En couche cachée, elle
                               sature et tue le gradient (dérivée ≤ 0,25).
softmax                        sortie multiclasse : produit une distribution.

L'initialisation n'est pas un détail. Trop petite, le signal s'éteint en traversant les couches ; trop grande, il explose. Les schémas de Xavier/Glorot (pour tanh) et He/Kaiming (pour ReLU) choisissent la variance des poids de façon à conserver l'échelle du signal d'une couche à l'autre — \(\operatorname{Var}(w) = 2/n_{\text{entrées}}\) pour He. C'est ce qui a rendu possible l'entraînement des réseaux profonds bien avant les architectures modernes.

3. Rétropropagation

La rétropropagation n'est rien d'autre que la règle de dérivation des fonctions composées, appliquée efficacement. Pour une couche \(z^{(l)} = W^{(l)}a^{(l-1)}+b^{(l)}\), on définit l'erreur locale \(\delta^{(l)} = \partial L/\partial z^{(l)}\) et on la propage vers l'arrière :

L'astuce algorithmique tient en une phrase : en réutilisant les \(\delta\) déjà calculés au lieu de recalculer chaque dérivée depuis le début, le coût du gradient complet est du même ordre que celui d'une passe avant — et non proportionnel au nombre de paramètres, comme le serait une différentiation numérique paramètre par paramètre. C'est ce qui rend l'entraînement de réseaux à des milliards de paramètres possible.

Le produit de matrices sur toute la profondeur explique aussi les pathologies classiques. Si les termes \(W^\top \sigma'\) sont systématiquement inférieurs à 1 en module, leur produit tend vers zéro : le gradient s'évanouit et les premières couches n'apprennent plus rien. S'ils dépassent 1, il explose, et les poids partent à l'infini en une itération. Les trois remèdes structurels sont les connexions résiduelles (section 5), la normalisation (section 4) et l'écrêtage du gradient (module 8).

4. Les recettes d'entraînement

En deep learning, l'écart entre un modèle qui converge et un modèle qui stagne tient rarement à l'architecture. Les leviers, par ordre d'impact :

1. Taux d'apprentissage — de loin le plus important (module 8). Le trouver par une montée exponentielle sur quelques centaines de pas (LR range test), puis prendre un ordre de grandeur en dessous du point de divergence.
2. Normalisation — la batch norm normalise chaque variable sur le lot (efficace en vision, mais dépendante de la taille du lot et délicate en inférence, où l'on utilise des statistiques mémorisées) ; la layer norm normalise sur les variables d'un exemple (indépendante du lot, standard dans les transformers). L'effet principal est un meilleur conditionnement, donc une convergence plus rapide et plus stable.
3. Régularisation — le dropout désactive aléatoirement une fraction des neurones à chaque passage, ce qui force le réseau à ne pas dépendre d'un chemin unique ; le weight decay via AdamW ; et surtout l'early stopping, la plus simple et la plus efficace : on garde les poids du meilleur point de validation.
4. Augmentation de données — en vision, c'est souvent le gain le plus important : recadrages, symétries, variations colorimétriques, mixup, cutmix. On encode ainsi des invariances connues sans annoter davantage (module 13).
5. Taille de lot — grand lot = gradient moins bruité et meilleure utilisation du GPU, mais généralisation parfois moins bonne. Règle empirique : en multipliant le lot par \(k\), multiplier le taux d'apprentissage par \(k\) (ou \(\sqrt{k}\) avec Adam). Si la mémoire manque, l'accumulation de gradient simule un grand lot (module 25).
6. Précision mixte — calculs en 16 bits avec accumulation en 32 bits : mémoire divisée par deux et accélération d'un facteur 2 à 3 sur GPU récent, sans perte mesurable de qualité.

import torch, torch.nn as nn
from torch.amp import autocast, GradScaler

modele = modele.to("cuda")
opt = torch.optim.AdamW(modele.parameters(), lr=3e-4, weight_decay=0.01)
sched = torch.optim.lr_scheduler.OneCycleLR(opt, max_lr=3e-4,
                                            total_steps=n_epoques * len(train_loader))
scaler = GradScaler()
meilleure_val, patience, attente = float("inf"), 10, 0

for epoque in range(n_epoques):
    modele.train()                                   # active dropout et batch norm
    for xb, yb in train_loader:
        xb, yb = xb.to("cuda", non_blocking=True), yb.to("cuda", non_blocking=True)
        opt.zero_grad(set_to_none=True)
        with autocast("cuda", dtype=torch.bfloat16): # précision mixte
            perte = critere(modele(xb), yb)
        scaler.scale(perte).backward()
        scaler.unscale_(opt)                          # avant l'écrêtage
        nn.utils.clip_grad_norm_(modele.parameters(), 1.0)
        scaler.step(opt); scaler.update(); sched.step()

    modele.eval()                                     # désactive dropout
    with torch.no_grad():                             # pas de graphe = plus rapide
        val = sum(critere(modele(x.to("cuda")), y.to("cuda")).item()
                  for x, y in val_loader) / len(val_loader)

    if val < meilleure_val:                           # EARLY STOPPING
        meilleure_val, attente = val, 0
        torch.save(modele.state_dict(), "meilleur.pt")
    else:
        attente += 1
        if attente >= patience:
            break
modele.load_state_dict(torch.load("meilleur.pt"))     # on garde le MEILLEUR, pas le dernier

5. CNN et vision

Une convolution applique un même petit noyau à toutes les positions de l'image. Concrètement, sur une fenêtre 3×3 :

  image (extrait)        noyau 3×3          on multiplie terme à terme
  ┌───┬───┬───┐        ┌───┬───┬───┐       et on somme :
  │ 10│ 10│ 10│        │ -1│  0│  1│
  ├───┼───┼───┤        ├───┼───┼───┤       (10×-1)+(10×0)+(10×1) +
  │ 10│ 10│ 80│   ×    │ -1│  0│  1│   =   (10×-1)+(10×0)+(80×1) +
  ├───┼───┼───┤        ├───┼───┼───┤       (10×-1)+(10×0)+(80×1)
  │ 10│ 10│ 80│        │ -1│  0│  1│       = 140  → un CONTOUR VERTICAL détecté
  └───┴───┴───┘        └───┴───┴───┘
  Ce noyau est un détecteur de contours verticaux. Un CNN n'utilise pas des noyaux
  écrits à la main : il les APPREND, et les premières couches convergent
  spontanément vers des détecteurs de contours et de textures.

Deux propriétés en découlent. Le partage de poids : un noyau 3×3 a neuf paramètres, quelle que soit la taille de l'image — là où une couche dense sur une image 224×224 en aurait des dizaines de millions. Et l'équivariance par translation : un motif déplacé produit une réponse déplacée. C'est le biais inductif exact des images, et la raison pour laquelle un CNN bat massivement un MLP à nombre de paramètres égal.

En empilant des couches, le champ réceptif — la zone de l'image influençant un neurone — s'élargit : deux couches 3×3 voient une zone 5×5, trois couches en voient 7×7. Les premières couches détectent des contours, les suivantes des textures, puis des parties d'objets. Le pooling (ou une convolution à pas 2) réduit la résolution spatiale tout en augmentant le nombre de canaux, ce qui concentre l'information sémantique.

Le tournant architectural est la connexion résiduelle de ResNet : \(y = \mathcal{F}(x) + x\). Le bloc n'apprend qu'une correction à l'identité, ce qui est plus facile que d'apprendre la transformation entière, et le terme \(+x\) ouvre au gradient un chemin direct vers les couches profondes — le gradient passe par l'addition sans être multiplié. C'est ce qui a rendu possible l'entraînement de réseaux de plus de cent couches, et l'idée est si générale qu'on la retrouve dans tous les transformers.

import torch, torchvision as tv

modele = tv.models.resnet50(weights="IMAGENET1K_V2")

for p in modele.parameters():          # 1. on gèle le tronc pré-entraîné
    p.requires_grad = False
modele.fc = torch.nn.Linear(2048, n_classes)   # nouvelle tête, entraînable

# 2. entraîner la tête seule quelques époques, avec un taux élevé (1e-3)
# 3. puis dégeler les derniers blocs et affiner avec un taux 10 à 100× plus faible
for p in modele.layer4.parameters():
    p.requires_grad = True
opt = torch.optim.AdamW([
    {"params": modele.layer4.parameters(), "lr": 1e-5},   # tronc : taux minuscule
    {"params": modele.fc.parameters(),     "lr": 1e-3},   # tête : taux normal
])

6. RNN, LSTM, et leurs limites

Un réseau récurrent maintient un état caché \(h_t = \sigma(W_h h_{t-1} + W_x x_t + b)\), mis à jour pas à pas : à chaque instant, il combine ce qu'il vient de voir et ce qu'il a retenu. Élégant pour les séquences, mais handicapé par deux défauts. Le gradient, propagé à travers le temps, s'évanouit sur les longues dépendances — le même produit de matrices que plus haut, mais sur la longueur de la séquence. Et le calcul est intrinsèquement séquentiel, donc impossible à paralléliser sur la longueur : on ne peut pas calculer \(h_{100}\) sans avoir calculé les 99 précédents.

LSTM et GRU corrigent partiellement le premier point avec des portes — des vannes apprises qui régulent ce qui entre dans la mémoire, ce qui en sort et ce qui est oublié — mais pas le second. Les transformers ont remplacé les RNN presque partout en traitement du langage, précisément parce qu'ils traitent toute la séquence en parallèle. Les RNN gardent un intérêt en inférence à très faible latence sur séquences courtes, et sur les très petits jeux de données temporelles — où, cela dit, un gradient boosting sur variables de décalage reste souvent supérieur aux deux (module 17).

7. Transformers et attention

Le mécanisme d'attention répond à une question simple : pour produire la représentation du mot \(i\), quels autres mots faut-il regarder, et avec quel poids ? Dans la phrase « le chat que le chien poursuivait était noir », comprendre « était » demande de remonter à « chat », six mots plus tôt — et un RNN doit faire transiter cette information par tous les mots intermédiaires.

Chaque position projette son vecteur en trois rôles, par trois matrices apprises : une requête \(Q\) (« ce que je cherche »), une clé \(K\) (« ce que je propose ») et une valeur \(V\) (« ce que je transmets »). L'analogie est celle d'un annuaire : on compare sa requête à toutes les clés, et l'on récupère un mélange des valeurs correspondantes, pondéré par la ressemblance.

1. QKᵀ          produit scalaire entre chaque requête et chaque clé
                → matrice n×n de scores de compatibilité
2. / √d_k       mise à l'échelle. INDISPENSABLE : en dimension d_k, les produits
                scalaires ont une variance ∝ d_k ; sans division, le softmax
                sature (un poids à 1, tous les autres à 0) et le gradient disparaît.
3. softmax      chaque ligne devient une distribution de poids sommant à 1
4. × V          moyenne pondérée des valeurs : voilà la nouvelle représentation

L'attention multi-têtes réalise plusieurs fois cette opération en parallèle dans des sous-espaces différents, chaque tête pouvant se spécialiser (accord syntaxique, coréférence, position relative), puis concatène les résultats. Comme l'opération est invariante à l'ordre — permuter les mots permute simplement les lignes —, il faut injecter la position explicitement : encodages sinusoïdaux à l'origine, positions relatives ou rotatives (RoPE) aujourd'hui.

x = x + MultiHeadAttention(LayerNorm(x))      # connexion résiduelle + pré-normalisation
x = x + FeedForward(LayerNorm(x))             # MLP 2 couches, expansion ×4, GELU

Encodeur seul      BERT — compréhension, classification, embeddings (module 22)
Décodeur seul      GPT — génération, attention CAUSALE (on ne regarde que le passé)
Encodeur-décodeur  T5, traduction — l'architecture d'origine

Le coût : l'attention est quadratique en longueur de séquence, \(O(n^2 d)\), puisqu'on compare chaque position à toutes les autres. C'est ce qui borne la taille du contexte, et ce qui a engendré une industrie entière de variantes — attention creuse, FlashAttention (exacte, mais optimisée pour la hiérarchie mémoire du GPU, module 25), et modèles à espace d'états comme Mamba, linéaires en \(n\). Le bénéfice : chaque position accède directement à toutes les autres, sans le chemin de longueur \(n\) d'un RNN, et l'ensemble se parallélise — c'est ce qui a rendu possible l'entraînement à l'échelle actuelle.

Le Vision Transformer applique la même recette aux images en les découpant en imagettes traitées comme des jetons. Il dépasse les CNN au-delà d'un certain volume de données, mais reste en retrait sur les petits jeux : n'ayant pas le biais inductif de la convolution, il doit apprendre la localité à partir des exemples (module 15).

8. Autoencodeurs et représentations

Un autoencodeur compresse l'entrée dans un espace latent de faible dimension, puis la reconstruit. Avec des couches linéaires et une perte quadratique, il retrouve exactement le sous-espace de la PCA (module 8) ; avec des non-linéarités, il capture des variétés courbes. Usages : réduction de dimension non linéaire, débruitage (on entraîne à reconstruire une entrée propre depuis une entrée bruitée), et détection d'anomalies par erreur de reconstruction — ce qui est mal reconstruit est ce que le modèle n'a jamais vu.

Plus important encore : l'apprentissage auto-supervisé, qui fabrique une tâche à partir des données non annotées — prédire un mot masqué, rapprocher deux vues augmentées d'une même image (module 13). C'est le principe qui a permis de pré-entraîner sur des corpus gigantesques sans annotation humaine, et qui produit les embeddings utilisés en recherche sémantique (module 22).

9. PINN : apprendre sous contrainte physique

Les Physics-Informed Neural Networks répondent à une situation fréquente en ingénierie : on connaît les équations qui régissent le système, mais on a peu de données — ou l'inverse, on a des mesures et un paramètre physique inconnu à identifier. L'idée est d'ajouter le résidu de l'équation dans la fonction de perte : le réseau doit à la fois coller aux données et satisfaire la physique.

Pour une EDP \(\mathcal{N}[u](x,t) = 0\), on approche la solution par un réseau \(u_\theta(x,t)\) et on minimise :

Le point élégant : les dérivées de l'EDP sont obtenues par différentiation automatique du réseau lui-même (module 3), exactement et en tout point — pas de maillage, pas de schéma aux différences finies, pas d'erreur de discrétisation. Les points de collocation où l'on évalue le résidu peuvent être tirés au hasard dans le domaine, et ils ne coûtent aucune donnée expérimentale.

import torch, torch.nn as nn

m, c, k = 1.0, 0.4, 20.0            # paramètres physiques connus

reseau = nn.Sequential(             # tanh : dérivées d'ordre 2 lisses et non nulles
    nn.Linear(1, 64), nn.Tanh(),    # (avec ReLU, la dérivée seconde serait nulle
    nn.Linear(64, 64), nn.Tanh(),   #  partout — inutilisable pour une EDP d'ordre 2)
    nn.Linear(64, 64), nn.Tanh(),
    nn.Linear(64, 1),
)
opt = torch.optim.Adam(reseau.parameters(), lr=1e-3)

def residu(t):
    t = t.requires_grad_(True)
    u    = reseau(t)
    # create_graph=True : on dérivera ENCORE cette dérivée (pour u'' et pour backward)
    u_t  = torch.autograd.grad(u,   t, torch.ones_like(u),   create_graph=True)[0]
    u_tt = torch.autograd.grad(u_t, t, torch.ones_like(u_t), create_graph=True)[0]
    return m * u_tt + c * u_t + k * u          # doit valoir 0 partout

t0 = torch.zeros(1, 1, requires_grad=True)     # conditions initiales : u(0)=1, u'(0)=0
for etape in range(20_000):
    tf = torch.rand(256, 1) * 2.0              # collocation ALÉATOIRE sur [0, 2]

    u0   = reseau(t0)
    u0_t = torch.autograd.grad(u0, t0, torch.ones_like(u0), create_graph=True)[0]

    perte = (residu(tf) ** 2).mean() + (u0 - 1.0) ** 2 + u0_t ** 2
    opt.zero_grad(); perte.backward(); opt.step()

Ce que les PINN apportent : une solution continue et différentiable, donc évaluable et dérivable partout ; l'absence de maillage, avantage décisif en géométrie complexe ou en grande dimension ; l'assimilation naturelle de données expérimentales bruitées ; et surtout la résolution de problèmes inverses — en déclarant un paramètre physique comme entraînable (c = nn.Parameter(torch.tensor(0.1))), le réseau l'identifie à partir de quelques mesures. C'est le cas d'usage où ils sont réellement compétitifs (module 21).

10. Limites

• Appétit en données et en calcul — sans pré-entraînement, un réseau profond sur 2 000 exemples surapprend systématiquement.
• Opacité — l'attribution par gradients ou par SHAP donne des indications, pas une explication vérifiable.
• Incertitude mal calibrée — un réseau est typiquement trop confiant, y compris sur des entrées hors distribution. Remèdes : température de calibration, ensembles profonds, dropout à l'inférence, ou modèles probabilistes (module 10).
• Fragilité — les exemples adverses montrent qu'une perturbation imperceptible peut renverser une prédiction (module 27).
• Reproductibilité — non-déterminisme des noyaux GPU, sensibilité aux graines : deux entraînements identiques ne donnent pas exactement le même modèle (module 26).
• Empreinte — coût énergétique et financier de l'entraînement comme de l'inférence, qui doit entrer dans l'arbitrage (module 25).

Dès que le temps entre en jeu, l'hypothèse d'indépendance des observations — sur laquelle repose tout le reste du cours — tombe. Validation croisée, tests statistiques, feature engineering : tout doit être repensé. Ce module couvre les trois familles de problèmes temporels que l'on rencontre réellement : prévoir une trajectoire, analyser un signal, et estimer une durée avant événement.

1. Ce que le temps change

Autocorrélation   les observations voisines se ressemblent : la taille d'échantillon
                  EFFECTIVE est bien inférieure à n. Un test qui l'ignore déclare
                  significatif ce qui ne l'est pas (module 9).
Non-stationnarité moyenne, variance et saisonnalité évoluent. Le passé lointain
                  peut être trompeur plutôt qu'informatif.
Ordre imposé      entraîner sur le futur pour prédire le passé n'a aucun sens :
                  la validation devient séquentielle (module 12).
Horizon           prévoir à J+1 et à J+30 sont deux problèmes différents, avec des
                  variables et des performances différentes.

2. Décomposition et stationnarité

Une série se lit d'abord comme la somme (ou le produit) de trois composantes : tendance (l'évolution de fond), saisonnalité (le motif qui se répète à période fixe) et résidu (ce qui reste). La décomposition STL, par lissage local, est l'outil de référence : robuste aux valeurs aberrantes, elle accepte une saisonnalité qui évolue lentement.

import polars as pl, pandas as pd
from statsmodels.tsa.seasonal import STL
from statsmodels.tsa.stattools import adfuller, kpss

serie = pd.read_csv("conso.csv", index_col="date", parse_dates=True)["valeur"].asfreq("D")

res = STL(serie, period=7, robust=True).fit()
res.plot()                                   # tendance, saison, résidu

print("ADF  p =", adfuller(serie)[1])        # H0 = racine unitaire (NON stationnaire)
print("KPSS p =", kpss(serie, regression="c")[1])   # H0 = stationnarité

Une série est stationnaire si ses propriétés statistiques ne dépendent pas de la date : même moyenne, même variance, même structure de dépendance à tout moment. Les modèles classiques l'exigent, parce qu'ils estiment des coefficients supposés constants. On s'y ramène par différenciation (\(\nabla y_t = y_t - y_{t-1}\), qui élimine une tendance linéaire), différenciation saisonnière (\(y_t - y_{t-s}\)) ou transformation stabilisante (logarithme si la variance croît avec le niveau).

Utiliser ADF et KPSS ensemble est plus sûr : leurs hypothèses nulles sont inversées, donc un désaccord signale une situation ambiguë qu'il vaut mieux examiner graphiquement plutôt que trancher mécaniquement.

3. Lire une ACF et une PACF

L'autocorrélation (ACF) au décalage \(k\) mesure la corrélation entre la série et elle-même décalée de \(k\) pas. La PACF mesure la même chose en retirant l'effet des décalages intermédiaires — la corrélation directe entre \(y_t\) et \(y_{t-k}\), une fois les \(k-1\) précédents pris en compte.

ACF qui décroît TRÈS LENTEMENT        → série non stationnaire : différencier
ACF avec un pic à 7, 14, 21…          → saisonnalité hebdomadaire
ACF qui se coupe net après q          → processus MA(q)
PACF qui se coupe net après p         → processus AR(p)
ACF et PACF décroissant toutes deux   → ARMA mixte : laisser l'auto-sélection choisir

  ACF │█                               PACF │█
      │█ █                                  │█
      │█ █ █ ▄                              │█ ▄
      │█ █ █ █ ▄ ▂                          │─ ─ ─ ─ ─ ─  ← coupure après 2
      └──────────────► décalage             └──────────────► décalage
      décroissance lente = AR               → AR(2)

from statsmodels.graphics.tsaplots import plot_acf, plot_pacf
plot_acf(serie.diff().dropna(), lags=40)     # sur la série DIFFÉRENCIÉE
plot_pacf(serie.diff().dropna(), lags=40)

4. Modèles classiques : ETS et ARIMA

Lissage exponentiel (ETS) — l'idée tient en une ligne : une moyenne pondérée du passé dont les poids décroissent géométriquement, de sorte que le passé récent compte davantage. Holt-Winters ajoute une tendance et une saisonnalité, chacune avec son propre coefficient de lissage :

où \(\ell\) est le niveau, \(b\) la pente et \(s\) la composante saisonnière. Simple, rapide, et étonnamment difficile à battre sur des séries métier courtes et régulières.

ARIMA(p,d,q) — \(d\) différenciations pour se ramener à la stationnarité, \(p\) termes autorégressifs (le passé de la série) et \(q\) termes de moyenne mobile (le passé des erreurs) :

La partie AR dit « la valeur d'aujourd'hui ressemble à celles d'hier » ; la partie MA dit « l'erreur d'aujourd'hui ressemble à celles d'hier », ce qui capte les chocs dont l'effet se dissipe. SARIMA ajoute les mêmes termes à la fréquence saisonnière, SARIMAX ajoute des régresseurs externes.

from statsforecast import StatsForecast
from statsforecast.models import AutoARIMA, AutoETS, SeasonalNaive

sf = StatsForecast(
    models=[AutoARIMA(season_length=7), AutoETS(season_length=7),
            SeasonalNaive(season_length=7)],      # LA baseline à battre
    freq="D", n_jobs=-1,
)
sf.fit(df)                                        # df : unique_id, ds, y
prev = sf.forecast(h=28, level=[80, 95])          # avec intervalles de prédiction
print(prev.head())

5. Approche ML : variables et gradient boosting

On transforme la prévision en régression tabulaire en construisant des variables exclusivement passées, puis on applique le module 14.

import numpy as np, polars as pl

df = (
    df.sort("date")
      .with_columns(
          # décalages : la valeur d'il y a 1, 7 et 364 jours (même jour de semaine)
          *[pl.col("y").shift(k).over("serie_id").alias(f"lag_{k}") for k in (1, 7, 364)],

          # moyennes glissantes sur le PASSÉ uniquement — le shift(1) est ESSENTIEL
          pl.col("y").shift(1).rolling_mean(7).over("serie_id").alias("ma_7"),
          pl.col("y").shift(1).rolling_mean(28).over("serie_id").alias("ma_28"),
          pl.col("y").shift(1).rolling_std(28).over("serie_id").alias("sd_28"),
          # tendance courte : rapport des deux moyennes
          (pl.col("y").shift(1).rolling_mean(7) /
           pl.col("y").shift(1).rolling_mean(28)).over("serie_id").alias("ratio_7_28"),

          # calendrier et saisonnalité cyclique (module 12)
          pl.col("date").dt.weekday().alias("jour_semaine"),
          (2 * np.pi * pl.col("date").dt.ordinal_day() / 365.25).sin().alias("an_sin"),
          (2 * np.pi * pl.col("date").dt.ordinal_day() / 365.25).cos().alias("an_cos"),
      )
)

Deux décisions structurent ensuite le travail. Stratégie d'horizon : la prévision récursive réinjecte ses propres prédictions pour avancer pas à pas (simple, mais les erreurs s'accumulent) ; la prévision directe entraîne un modèle par horizon (plus coûteux, plus stable au-delà de quelques pas). Validation : uniquement en avançant dans le temps, avec une fenêtre glissante ou extensible, et en respectant un écart égal à l'horizon entre entraînement et test — sans quoi on évalue une situation impossible en production.

6. Deep learning et modèles de fondation

• N-BEATS / N-HiTS — empilements de blocs résiduels, sans composante récurrente ; performances solides et entraînement rapide.
• DeepAR — modèle autorégressif probabiliste entraîné sur un ensemble de séries apparentées : il apprend des motifs partagés, ce qui aide beaucoup les séries courtes.
• Temporal Fusion Transformer — attention sur les séquences (module 16) avec gestion propre des covariables connues à l'avance (calendrier, promotions) et une part d'interprétabilité.
• Modèles de fondation (Chronos, TimesFM, Moirai, TimeGPT) — pré-entraînés sur d'énormes corpus de séries, utilisables en zero-shot. Intéressants pour obtenir une baseline sans entraînement ; pas systématiquement meilleurs qu'un bon modèle spécifique, et à manier avec précaution quand la série contient de l'information confidentielle (module 27).

La bibliothèque nixtla (statsforecast / mlforecast / neuralforecast) donne accès aux trois familles avec la même interface, ce qui permet de les comparer honnêtement — la seule façon de trancher.

7. Prévision probabiliste et évaluation

Une prévision ponctuelle est rarement suffisante : dimensionner un stock ou une réserve d'énergie demande un quantile, pas une moyenne (module 24). On entraîne donc directement sur la perte pinball, qui pénalise asymétriquement selon le quantile visé :

Pour \(\tau = 0{,}9\), sous-estimer coûte neuf fois plus cher que surestimer : le modèle apprend donc à viser haut, et sa prédiction converge vers le quantile 90 %.

MAE / RMSE   interprétables, mais non comparables entre séries d'échelles différentes
MAPE         en pourcentage ; explose si y proche de 0 et pénalise asymétriquement
             (surestimer de 100 % est borné, sous-estimer ne l'est pas)
sMAPE        version symétrique, un peu moins instable
MASE         erreur rapportée à celle de la prévision NAÏVE : < 1 = mieux que naïf.
             LA métrique à préférer pour comparer des séries hétérogènes.
Pinball      évalue un quantile donné
CRPS         évalue toute la distribution prédictive ; se réduit à la MAE pour une
             prévision ponctuelle. La référence en prévision probabiliste.

Et la règle d'or : toujours comparer à la prévision naïve — la dernière valeur, ou la valeur de la même période l'an dernier. Un modèle qui ne bat pas la naïve saisonnière ne sert à rien, et c'est plus fréquent qu'on ne le croit.

8. Espace d'états et filtre de Kalman

Un modèle espace-état sépare ce qu'on cherche à connaître — un état caché \(x_t\) qui évolue selon une dynamique — de ce qu'on observe — \(z_t\), bruité et parfois indirect :

Le filtre de Kalman alterne deux étapes à chaque instant :

PRÉDICTION   x̂ = F·x̂      "d'après mon modèle de dynamique, voilà où je devrais être"
             P  = F·P·Fᵀ + Q   l'incertitude AUGMENTE (le modèle n'est pas parfait)

CORRECTION   K  = P·Hᵀ(H·P·Hᵀ + R)⁻¹     le GAIN : combien croire la mesure ?
             x̂ = x̂ + K(z - H·x̂)          on corrige avec l'écart à la mesure
             P  = (I - K·H)·P             l'incertitude DIMINUE

Si R est grand (capteur bruité) → K petit → on fait confiance au modèle
Si Q est grand (modèle grossier) → K grand → on fait confiance à la mesure

C'est l'estimateur optimal au sens de la variance minimale dans le cas linéaire-gaussien, et il est récursif : coût constant par pas, mémoire constante, quelle que soit la longueur de l'historique. D'où son omniprésence en navigation, en poursuite de cible et en fusion de capteurs. Les extensions traitent le cas non linéaire : EKF (linéarisation locale), UKF (propagation de points sigma, plus stable), et filtres particulaires (Monte-Carlo séquentiel, sans hypothèse gaussienne).

Pour un ingénieur, l'intérêt est double : lisser un signal bruité en temps réel, et estimer des grandeurs non mesurables directement à partir de mesures indirectes — ce qui relie ce module à l'assimilation de données du module 21.

9. Ruptures et anomalies

• Détection de rupture — identifier les dates où le régime change (changement de moyenne, de variance, de tendance). La bibliothèque ruptures implémente PELT et la segmentation binaire ; CUSUM reste la méthode de référence pour une surveillance en ligne. Usage concret : savoir à partir de quand les données sont encore représentatives, donc à partir de quand réentraîner (module 26).
• Anomalies ponctuelles — un point s'écarte fortement de la prévision : on compare le résidu à un intervalle de prédiction plutôt qu'à un seuil fixe, ce qui rend la détection insensible à la saisonnalité (un pic le samedi n'est pas une anomalie si tous les samedis font un pic).
• Anomalies collectives — un motif anormal sur une fenêtre, détectable par distance entre sous-séquences (matrix profile) ou par erreur de reconstruction d'un autoencodeur (module 16).
• Un rappel utile — sur un flux, tester en continu revient à faire des milliers de tests : sans contrôle du taux de fausses alertes (module 9), le système d'alerte devient du bruit et finit ignoré.

10. Analyse spectrale et filtrage

Sur un signal physique — vibration, acoustique, mesure de capteur —, le domaine fréquentiel révèle souvent ce que le domaine temporel cache. La FFT donne le périodogramme, la méthode de Welch le lisse en moyennant des segments (ce qui réduit la variance de l'estimation au prix de la résolution), et la densité spectrale de puissance identifie les composantes périodiques : une fréquence de rotation, une résonance, un harmonique de défaut de roulement.

import numpy as np
from scipy import signal

f, Pxx = signal.welch(x, fs=25_600, nperseg=4096)        # densité spectrale de puissance
pic = f[np.argmax(Pxx)]
print(f"fréquence dominante : {pic:.1f} Hz")

# spectrogramme : évolution du contenu fréquentiel DANS LE TEMPS
f, t, Sxx = signal.spectrogram(x, fs=25_600, nperseg=1024)

# filtrage passe-bande SANS déphasage (filtrage aller-retour)
sos = signal.butter(4, [50, 2000], btype="band", fs=25_600, output="sos")
x_filtre = signal.sosfiltfilt(sos, x)      # filtfilt : phase nulle, ordre doublé

Deux usages en machine learning. D'abord, le spectre fournit d'excellentes variables : énergie par bande, fréquence dominante, kurtosis spectral, coefficients cepstraux — c'est la base de la maintenance prédictive sur signaux vibratoires. Ensuite, le spectrogramme transforme un signal unidimensionnel en image bidimensionnelle, ce qui permet d'appliquer directement un CNN (modules 16 et 18) — l'approche standard en classification audio.

Deux pièges classiques du traitement du signal restent valables ici : le repliement de spectre (respecter Shannon, filtrer avant d'échantillonner, sinon les hautes fréquences se déguisent en basses) et les fuites spectrales (utiliser une fenêtre de Hann plutôt qu'une troncature brutale, qui introduit des discontinuités artificielles). Et pour les phénomènes non stationnaires, la transformée en ondelettes offre un meilleur compromis temps-fréquence que la FFT à fenêtre.

11. Durées de vie, censure et fiabilité

Troisième famille temporelle, et la plus mal traitée en pratique : on veut prédire le temps avant un événement — panne d'un composant, résiliation d'un client, rechute d'un patient. La difficulté s'appelle la censure : à la fin de l'étude, beaucoup d'unités n'ont pas encore connu l'événement.

  unité 1  ├──────────✕                      ✕ = panne observée (durée connue : 8 mois)
  unité 2  ├───────────────────────→         → = toujours en service à la fin
  unité 3  ├────✕                                 (durée INCONNUE, mais ≥ 14 mois)
  unité 4  ├──────────────────→
           └──────────────────────────► temps

  Les EXCLURE   → on ne garde que les pannes précoces → durée de vie SOUS-ESTIMÉE
  Les compter   → on suppose qu'elles tombent en panne à la date de fin d'étude
  comme pannes     → encore sous-estimée
  → il faut une méthode qui utilise l'information "a survécu AU MOINS 14 mois"

Deux fonctions suffisent à tout exprimer — la survie et le taux de défaillance instantané :

\(h(t)\) se lit « sachant que l'unité a tenu jusqu'à \(t\), quel est son risque de tomber maintenant ? » — c'est la quantité qui intéresse un ingénieur fiabiliste, et elle est directement reliée à la survie par l'exponentielle de son intégrale.

Kaplan-Meier      estimation non paramétrique de S(t), gérant la censure.
                  Le point de départ, toujours.
Test du log-rank  comparer deux courbes de survie (deux lots, deux traitements).
Cox (PH)          h(t|x) = h₀(t)·exp(βᵀx) : les covariables agissent de façon
                  MULTIPLICATIVE sur le risque, sans qu'on spécifie h₀.
                  exp(β) se lit comme un rapport de risques.
                  Hypothèse à vérifier : risques proportionnels (résidus de Schoenfeld).
Weibull / AFT     modèle paramétrique : les covariables ACCÉLÈRENT le temps.
                  Permet d'EXTRAPOLER au-delà de la fenêtre d'observation,
                  ce que Cox ne fait pas.
Survie par ML     Random Survival Forest, gradient boosting de Cox, DeepSurv :
                  capturent non-linéarités et interactions.

Le paramètre de forme de la loi de Weibull se lit directement comme un diagnostic de mode de défaillance : \(k \lt 1\) correspond à un taux décroissant (mortalité infantile, défauts de fabrication), \(k = 1\) à un taux constant (défaillances aléatoires, loi exponentielle sans mémoire), \(k \gt 1\) à un taux croissant (usure). C'est la lecture de la courbe en baignoire de la fiabilité, et c'est ce qui permet de distinguer un problème de qualité d'un problème de vieillissement — deux situations qui appellent des actions opposées.

from lifelines import KaplanMeierFitter, CoxPHFitter, WeibullFitter
from lifelines.statistics import logrank_test

# evenement = 1 si la panne a été observée, 0 si l'unité était encore en service
km = KaplanMeierFitter().fit(durees, evenement_observe)
km.plot_survival_function()
print("durée médiane de survie :", km.median_survival_time_)

# comparer deux lots
print(logrank_test(d_lotA, d_lotB, e_lotA, e_lotB).p_value)

cox = CoxPHFitter().fit(df, duration_col="duree", event_col="panne")
cox.print_summary()                      # rapports de risques et intervalles
cox.check_assumptions(df)                # test des risques proportionnels

wb = WeibullFitter().fit(durees, evenement_observe)
print(f"paramètre de forme ρ = {wb.rho_:.2f}")   # < 1 rodage, ≈ 1 aléatoire, > 1 usure

Un modèle ne consomme que des nombres. Tout le travail, sur ces données, consiste donc à construire une représentation — et le choix de cette représentation pèse bien plus lourd que le choix de l'algorithme qui vient après. Ce module traite les quatre modalités que l'on rencontre le plus souvent, avec une insistance particulière sur les graphes, absents de la plupart des cours généralistes alors qu'ils modélisent naturellement beaucoup de systèmes d'ingénierie.

1. Texte : du TF-IDF aux transformers

Le problème

Un modèle attend un vecteur de nombres ; on lui donne « la pompe P-204 fuit au niveau du presse-étoupe ». La première solution historique, le sac de mots, consiste à compter les occurrences de chaque mot du vocabulaire : chaque document devient un vecteur de la taille du vocabulaire, presque entièrement nul. On perd l'ordre des mots, mais on obtient quelque chose d'exploitable immédiatement.

TF-IDF raffine ce comptage en pondérant chaque terme par sa fréquence dans le document et sa rareté dans le corpus :

terme          présent dans      log(N/nₜ)    poids si présent 3 fois
"le"           9 900 / 10 000    0,01         0,03   → quasi ignoré
"pompe"        3 000 / 10 000    1,20         3,60   → informatif
"presse-       12 / 10 000       6,73        20,19   → très discriminant
 étoupe"

BM25 va plus loin sur deux points : il sature la fréquence (le dixième « pompe » n'apporte presque rien de plus que le troisième) et normalise par la longueur du document, pour qu'un rapport de dix pages ne domine pas mécaniquement. C'est la composante lexicale de la recherche hybride des modules 22 et 23.

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression
from sklearn.pipeline import make_pipeline

modele = make_pipeline(
    TfidfVectorizer(
        ngram_range=(1, 2),      # mots seuls ET paires : capture "non conforme"
        min_df=3,                # ignorer ce qui apparaît moins de 3 fois (bruit)
        max_df=0.7,              # ignorer ce qui apparaît dans 70 % des documents
        sublinear_tf=True,       # log(1+tf) : sature les répétitions
        strip_accents="unicode",
    ),
    LogisticRegression(C=1.0, max_iter=1000, class_weight="balanced"),
).fit(textes_train, y_train)

# interprétabilité gratuite : les n-grammes les plus discriminants
noms = modele[0].get_feature_names_out()
poids = modele[-1].coef_[0]
print("en faveur :", [noms[i] for i in poids.argsort()[-15:]])
print("en défaveur :", [noms[i] for i in poids.argsort()[:15]])

Sur le prétraitement, deux remarques. La lemmatisation (ramener « fuyaient » à « fuir », avec spaCy) est utile en français, langue fortement fléchie, là où la racinisation brutale dégrade souvent le sens. Et la suppression des mots vides n'est pas toujours souhaitable : la négation et les mots-outils portent parfois exactement l'information recherchée.

2. Tâches classiques du NLP

• Classification — thématique, sentiment, intention. Métriques du module 8, attention au déséquilibre.
• Reconnaissance d'entités (NER) — extraire personnes, dates, références produit, valeurs avec unités. Évaluation par F1 au niveau de l'entité : une entité partiellement détectée compte comme fausse, ce qui est bien plus sévère qu'une évaluation par jeton.
• Extraction structurée — passer d'un rapport libre à un enregistrement exploitable. Historiquement des règles et des expressions régulières, aujourd'hui souvent un LLM à sortie contrainte (module 22) — mais les règles restent supérieures sur les formats rigides, et elles sont déterministes et gratuites.
• Topic modeling — LDA (modèle génératif bayésien, module 10), NMF (factorisation à coefficients positifs, plus lisible, module 8) ou BERTopic (embeddings + clustering + c-TF-IDF), qui donne aujourd'hui les regroupements les plus interprétables.
• Résumé, traduction, question-réponse — domaine des modèles génératifs ; la difficulté s'y déplace entièrement vers l'évaluation (module 22).

3. Images : au-delà de la classification

Le module 16 traite les CNN et la classification. En pratique, les tâches utiles sont souvent d'un autre type :

Classification        une étiquette par image                  accuracy, F1
Détection d'objets    boîtes + classes (YOLO, DETR)            mAP à IoU 0,5 / 0,5:0,95
Segmentation sém.     une classe par PIXEL (U-Net, DeepLab)    IoU, Dice
Segmentation d'inst.  objets séparés (Mask R-CNN, SAM)         mAP masque
Estimation de pose    points clés                              PCK, OKS
OCR                   texte dans l'image (docTR, Tesseract)    CER, WER
Recherche d'images    similarité par embedding (module 22)     recall@k

  vérité terrain ███████          prédiction  ░░░███████
                                  intersection = 5 pixels
                                  union        = 9 pixels
  IoU  = 5/9 = 0,56               Dice = 2×5/(7+7) = 0,71

  Le Dice est toujours ≥ l'IoU et pénalise moins durement les petits objets :
  c'est pourquoi il est préféré en imagerie médicale et scientifique, où
  l'objet d'intérêt occupe souvent 1 % de l'image.

Pour un profil d'ingénieur, les cas d'usage les plus fréquents ne sont d'ailleurs pas les photographies : segmentation de micrographies pour quantifier une microstructure (taille de grains, porosité, fraction de phase), détection de défauts sur des images de contrôle non destructif, analyse d'images de simulation ou de tomographie. Trois particularités y changent la méthode : les jeux annotés sont très petits (d'où le transfert et une augmentation agressive, module 13), les images sont souvent en niveaux de gris et à haute résolution (d'où le découpage en tuiles, avec recouvrement pour éviter les artefacts de bord), et la sortie attendue est généralement une mesure physique — ce qui déplace l'évaluation du score de segmentation vers l'erreur sur la grandeur mesurée.

4. Audio et signaux perceptifs

La chaîne standard transforme le son en image : découpage en fenêtres qui se recouvrent, FFT sur chaque fenêtre (module 17), passage sur l'échelle de Mel — qui reproduit la résolution non linéaire de l'oreille, plus fine dans les graves —, puis un CNN ou un transformer sur le spectrogramme obtenu. Les MFCC (coefficients cepstraux) restent une représentation compacte utile pour les tâches légères sur processeur.

Trois précautions spécifiques : l'augmentation se fait sur le signal (bruit additif, variation de vitesse, réverbération) et sur le spectrogramme (SpecAugment, qui masque des bandes de temps et de fréquence) ; la découpe train/test doit se faire par locuteur ou par appareil, jamais par extrait, sous peine de fuite (module 12) ; et pour la reconnaissance vocale, un modèle pré-entraîné comme Whisper rend l'entraînement de zéro sans objet dans l'immense majorité des cas.

5. Graphes : représentation et mesures

Un graphe modélise des entités (les nœuds) et leurs relations (les arêtes). Beaucoup de systèmes techniques en sont naturellement : un réseau électrique ou hydraulique, un maillage de calcul, une molécule, un graphe de dépendances logicielles, un circuit, une chaîne d'approvisionnement, un réseau social. Ignorer cette structure et aplatir en tableau revient à jeter l'information la plus spécifique du problème — c'est comme décrire un plan de métro par la seule liste des stations.

Degré                 nombre de voisins : popularité, connectivité locale
Intermédiarité        fréquence d'apparition sur les plus courts chemins entre
(betweenness)         toutes les paires. Identifie les points de passage obligés,
                      donc les points de FRAGILITÉ d'un réseau technique.
PageRank              importance récursive : est important qui est pointé par
                      des nœuds importants
Coefficient de        propension des voisins d'un nœud à être voisins entre eux :
clustering            mesure la "densité locale" du réseau
Communautés           partition en groupes densément connectés (Louvain, Leiden)
Composantes           parties déconnectées : souvent la première chose à regarder
Assortativité         les nœuds semblables se connectent-ils entre eux ?

import networkx as nx

G = nx.from_pandas_edgelist(df, "source", "cible", edge_attr="poids")

print(f"{G.number_of_nodes()} nœuds, {G.number_of_edges()} arêtes, "
      f"densité {nx.density(G):.4f}, {nx.number_connected_components(G)} composantes")

centralite = nx.betweenness_centrality(G, weight="poids")     # points critiques
communautes = nx.community.louvain_communities(G, seed=0)

# CES MESURES DEVIENNENT DES VARIABLES TABULAIRES pour un modèle classique (module 14)
df_noeuds["pagerank"]     = df_noeuds.index.map(nx.pagerank(G))
df_noeuds["degre"]        = df_noeuds.index.map(dict(G.degree()))
df_noeuds["clustering"]   = df_noeuds.index.map(nx.clustering(G))
df_noeuds["intermediar."] = df_noeuds.index.map(centralite)

Les quatre dernières lignes méritent d'être soulignées : dans bien des projets, la meilleure façon d'exploiter un graphe n'est pas d'entraîner un modèle de graphe, mais d'en extraire des variables et de les donner à un gradient boosting. C'est simple, robuste, interprétable, et souvent suffisant. Les plongements de nœuds (node2vec, DeepWalk), qui appliquent l'idée de word2vec à des marches aléatoires sur le graphe, constituent l'étape intermédiaire.

6. Réseaux de neurones sur graphes

Un GNN généralise la convolution à une structure irrégulière. Sur une image, chaque pixel a exactement huit voisins disposés de façon régulière, ce qui permet un noyau fixe ; dans un graphe, un nœud peut avoir deux ou deux mille voisins, sans ordre. Le principe, appelé passage de messages : chaque nœud met à jour sa représentation en agrégeant celles de ses voisins.

        ○ B (h_B)
         ╲                  1. MESSAGE  : chaque voisin envoie ψ(h_A, h_v, e)
   C ○───● A (h_A)          2. AGRÉGATION : on combine les messages reçus par une
         ╱                     opération INVARIANTE PAR PERMUTATION (somme, moyenne,
        ○ D (h_D)               max) — le résultat ne doit pas dépendre de l'ordre
                              arbitraire des voisins
   h_A ← φ(h_A, ⊕{messages de B, C, D})
                           3. MISE À JOUR : on combine avec l'état précédent

   Après K couches, un nœud "voit" son voisinage à distance K.

Les variantes diffèrent par le choix de \(\psi\) et de l'agrégation : GCN (moyenne normalisée par les degrés), GraphSAGE (échantillonnage d'un nombre fixe de voisins, ce qui permet de passer à l'échelle), GAT (pondération des voisins par attention, module 16), MPNN (formulation générale avec attributs d'arêtes, la plus utilisée en chimie).

Nœud     classification ou régression par nœud   détection de fraude, rôle dans
                                                 un réseau, propriété d'un atome
Arête    prédiction de lien                      recommandation, complétion de
                                                 graphe de connaissances
Graphe   propriété du graphe ENTIER              propriété d'une molécule, d'un
         (après agrégation globale)              circuit, d'une structure

Les applications les plus convaincantes sont scientifiques : prédiction de propriétés moléculaires et de matériaux (le graphe atomes-liaisons est la représentation naturelle), simulation physique apprise sur maillage — un maillage de calcul est un graphe, et les GNN y apprennent des opérateurs de propagation, ce qui rejoint le module 21 —, prévision de trafic sur réseau routier, et détection de fraude par anneaux de comptes liés.

7. Multimodal

Combiner plusieurs modalités se fait de trois façons : fusion précoce (concaténer les données brutes, rarement efficace car les échelles et les structures n'ont rien à voir), fusion tardive (un modèle par modalité, puis combinaison des prédictions — simple et robuste), et fusion intermédiaire (concaténer les représentations apprises, le meilleur compromis en général).

Les modèles contrastifs type CLIP vont plus loin en alignant deux modalités dans un espace commun : une image et sa description y sont voisines, ce qui permet la recherche d'images par texte et la classification sans aucun exemple étiqueté (module 13). En contexte industriel, le cas le plus fréquent est la combinaison d'un tableau de mesures, d'un texte libre (rapport d'intervention) et d'une image ou d'un signal. La recette qui marche : encoder chaque modalité en un vecteur, les concaténer, et laisser un gradient boosting faire la synthèse.

8. Annotation et qualité

Sur ces données, la performance est presque toujours limitée par les annotations, pas par le modèle. Quelques principes qui économisent beaucoup de temps :

• Écrire un guide d'annotation avant d'annoter, et le tester sur vingt exemples avec deux annotateurs. Les désaccords révèlent les cas limites que la définition du problème n'avait pas tranchés — et c'est le vrai livrable de cette étape.
• Mesurer l'accord inter-annotateurs (kappa de Cohen, alpha de Krippendorff). Il plafonne la performance atteignable : si deux experts ne sont d'accord qu'à 80 %, aucun modèle n'ira significativement au-delà, et un score de 85 % doit éveiller les soupçons plutôt que la satisfaction.
• Annoter en priorité les cas informatifs plutôt qu'au hasard : c'est l'apprentissage actif du module 13.
• Vérifier les étiquettes existantes : les jeux de référence publics contiennent eux-mêmes des erreurs, et un modèle très confiant en désaccord avec l'étiquette est un excellent détecteur d'annotation fautive (cleanlab, module 13).

Comment optimiser une fonction dont chaque évaluation prend six heures de simulation ou détruit une éprouvette ? La descente de gradient est inutilisable — pas de gradient, et un budget de quelques dizaines d'essais. C'est le domaine de l'optimisation bayésienne, qui construit un modèle probabiliste de la fonction et s'en sert pour décider où essayer ensuite. Pour un profil d'ingénieur, c'est probablement le module dont l'application est la plus immédiate.

1. Le problème : une boîte noire coûteuse

On cherche \(x^\star = \arg\max_{x\in\mathcal{X}} f(x)\) où \(f\) est :

• coûteuse — une évaluation demande des heures de calcul, un essai physique, ou une campagne d'entraînement complète ;
• opaque — pas d'expression analytique, donc pas de gradient exploitable ;
• possiblement bruitée — deux mesures au même point ne donnent pas le même résultat.

Le budget se compte en dizaines d'évaluations, pas en millions. Une recherche par grille gaspille tout sur des zones sans intérêt ; une descente de gradient numérique dépenserait tout son budget à estimer une seule direction (il faut \(d+1\) évaluations pour un seul gradient en dimension \(d\)).

La stratégie gagnante consiste à modéliser \(f\) à partir des points déjà évalués, puis à choisir le prochain point en exploitant ce modèle. Ce modèle de substitution s'appelle un surrogate, et le choix naturel est un processus gaussien parce qu'il fournit, en plus d'une prédiction, une incertitude — exactement l'information nécessaire pour savoir où l'on ne sait pas encore.

2. Processus gaussiens : une loi sur des fonctions

L'idée demande un petit effort d'abstraction. Une loi normale ordinaire tire des nombres. Une loi normale multivariée tire des vecteurs, avec des corrélations entre coordonnées. Un processus gaussien tire des fonctions : on peut le voir comme une loi normale multivariée de dimension infinie, dont chaque « coordonnée » est la valeur de la fonction en un point.

La définition opérationnelle est plus simple : quelle que soit la collection finie de points \(x_1,\dots,x_n\) que l'on choisit, le vecteur \(\big(f(x_1),\dots,f(x_n)\big)\) suit une loi normale multivariée. Le processus est entièrement déterminé par une fonction moyenne (souvent prise nulle après centrage) et une fonction de covariance, le noyau :

Le noyau dit à quel point deux points se « ressemblent » : \(k(x,x')\) grand signifie que \(f(x)\) et \(f(x')\) sont fortement corrélées, donc proches. C'est la seule hypothèse qu'on injecte, et elle suffit.

  A PRIORI : une nuée de fonctions plausibles      APRÈS 3 OBSERVATIONS
  ╱‾╲    ╱╲                                        ╱‾╲    ╱╲
 ╱   ╲╱╲╱  ╲   toutes passent "n'importe où",    ●╱   ╲╱‾╲   ← toutes passent par
╱  ╱╲ ╲  ╱╲ ╲  l'incertitude est uniforme         ╲╱      ╲●    les points observés
 ╲╱  ╲ ╲╱   ╲                                      ╱╲    ╱  ╲   et l'incertitude se
                                                  ●    ╲╱    ╲  resserre AUTOUR d'eux
  ░░░░░░░░░░░░ bande d'incertitude large       ░░░▒▒░░░▒▒▒░░░░  et reste large LOIN

3. Ce que le conditionnement donne

Conditionner une loi normale par une partie de ses coordonnées donne encore une loi normale, dont moyenne et covariance sont explicites. Avec \(K = k(X,X) + \sigma_n^2 I\) la matrice de covariance des points observés et \(k_* = k(X,x_*)\) le vecteur de covariance entre les observations et le point à prédire :

Deux lectures importantes. D'abord, la moyenne prédictive est une combinaison linéaire des observations pondérée par la similarité — c'est exactement une interpolation par fonctions de base radiales, le sujet de mon projet mdisd, mais assortie d'une variance. Ensuite, et c'est la propriété décisive : la variance prédictive ne dépend pas des valeurs observées, seulement de la position des points. L'incertitude est donc grande là où l'on n'a pas mesuré et petite près des mesures, indépendamment de ce qu'on y a trouvé. C'est précisément ce dont l'optimisation bayésienne a besoin pour décider où explorer.

4. Noyaux et hyperparamètres

RBF / gaussien      k = σ²·exp(-‖x-x'‖²/2ℓ²)      fonctions infiniment dérivables :
                                                   très (souvent trop) lisse.
Matérn ν=5/2        polynôme·exp(-√5 r/ℓ)          deux fois dérivable. LE DÉFAUT en
                                                   optimisation bayésienne : réaliste
                                                   pour un système physique.
Matérn ν=3/2                                       une fois dérivable : plus rugueux.
Périodique          exp(-2sin²(π r/p)/ℓ²)          saisonnalité de période connue.
Linéaire            x·x'                           tendance affine.
Blanc               σ²·δ(x,x')                     bruit d'observation.
Somme / produit     k₁+k₂, k₁·k₂                   combiner : tendance + saisonnalité
                                                   + bruit, chacun avec ses paramètres.

La longueur caractéristique \(\ell\) est l'hyperparamètre décisif : elle dit à quelle distance deux points cessent de s'informer mutuellement. Petite, le GP devient nerveux et l'incertitude explose entre les points ; grande, il lisse tout et manque les variations réelles. Avec une longueur par dimension (Automatic Relevance Determination), le modèle apprend lui-même quelles variables comptent — une grande longueur signifie que la sortie est insensible à cette entrée, ce qui constitue au passage une analyse de sensibilité gratuite (module 21).

Les hyperparamètres (\(\ell\), \(\sigma^2\), \(\sigma_n^2\)) s'ajustent en maximisant la vraisemblance marginale :

Le premier terme récompense l'ajustement aux données, le second pénalise la complexité du modèle — une matrice de covariance « permissive », qui autorise beaucoup de fonctions, a un grand déterminant. Le rasoir d'Occam est ici automatique, sans validation croisée : c'est l'un des grands attraits du cadre bayésien (module 10).

import numpy as np
from sklearn.gaussian_process import GaussianProcessRegressor
from sklearn.gaussian_process.kernels import Matern, ConstantKernel, WhiteKernel

noyau = (ConstantKernel(1.0)                          # amplitude σ²
         * Matern(length_scale=np.ones(3), nu=2.5)    # ARD : une longueur par dimension
         + WhiteKernel(noise_level=1e-3))             # bruit d'observation

gp = GaussianProcessRegressor(kernel=noyau, normalize_y=True, n_restarts_optimizer=10)
gp.fit(X, y)                       # optimise les hyperparamètres par vraisemblance

mu, sigma = gp.predict(X_test, return_std=True)
print(gp.kernel_)                  # les longueurs apprises = sensibilité par variable
# une longueur très grande sur une dimension → cette variable n'influence pas la sortie

Le coût est la limite structurelle : la factorisation de \(K\) est en \(O(n^3)\) et la mémoire en \(O(n^2)\). Au-delà de quelques milliers de points, il faut des approximations creuses (points inducteurs, variational GP dans GPyTorch). Pour l'optimisation bayésienne, où \(n\) dépasse rarement quelques centaines, ce n'est pas un obstacle.

5. La boucle d'optimisation bayésienne

1. Évaluer f sur un plan initial (Latin Hypercube ou Sobol, ~10 points par dimension)
2. Répéter jusqu'à épuisement du budget :
      a. ajuster le GP sur TOUTES les observations disponibles
      b. maximiser la fonction d'acquisition α(x) sur le domaine
         (α est bon marché : on peut y lancer un optimiseur classique multi-départs)
      c. évaluer f au point trouvé — LA seule opération coûteuse
      d. ajouter (x, y) aux observations
3. Renvoyer le meilleur point observé

Le déplacement conceptuel est là : on remplace l'optimisation d'une fonction coûteuse par une suite d'optimisations d'une fonction bon marché, construite à partir du GP. Consommer quelques secondes de calcul pour choisir intelligemment un point vaut largement le coup quand ce point coûte six heures de simulation.

6. Fonctions d'acquisition

L'acquisition traduit le compromis exploitation (aller là où le modèle prédit une bonne valeur) / exploration (aller là où il ne sait rien). En notant \(f^+\) le meilleur résultat observé, \(Z = (\mu(x)-f^+-\xi)/\sigma(x)\), \(\Phi\) et \(\varphi\) les fonctions de répartition et de densité normales :

L'amélioration espérée (EI) est l'espérance du gain par rapport au meilleur point connu, sachant que l'on ne perd rien si le nouveau point est moins bon. Sa structure est parlante : le premier terme récompense une moyenne élevée, le second une forte incertitude. C'est le choix par défaut — pas de paramètre à régler (\(\xi\) vaut typiquement 0,01) et un bon équilibre empirique.

      μ(x) prédite        ╱‾‾╲                    ●  points déjà évalués
   ●            ╱‾╲     ╱     ╲       ●          ░  incertitude σ(x)
  ░░░░       ░░╱   ╲░░░╱       ╲░░░░░░░
             ▲              ▲
             │              └── EXPLORATION : zone mal connue, σ grand
             └── EXPLOITATION : moyenne élevée près d'un bon point
  EI équilibre les deux ; UCB laisse régler le curseur par β.

UCB       μ(x) + β·σ(x)     exploration réglable explicitement. Garanties théoriques
                            de regret (GP-UCB). β ≈ 2 en pratique.
PI        P(f(x) > f⁺)      probabilité d'amélioration : trop exploitante, converge
                            souvent vers un optimum local.
Thompson  tirer une fonction du postérieur et l'optimiser. Naturellement
          parallélisable : k tirages donnent k points distincts.
Entropy search  maximise l'information gagnée SUR LA POSITION de l'optimum plutôt
                que sur sa valeur. Plus coûteux, souvent plus efficace.
Knowledge gradient  anticipe le gain sur la meilleure valeur atteignable après
                    l'évaluation.

7. BoTorch en pratique

BoTorch (Meta) est construit sur PyTorch et GPyTorch. Son atout : les acquisitions y sont différentiables et estimées par Monte-Carlo, ce qui permet de les maximiser par gradient et d'en construire des variantes (batch, contraintes, multi-objectif) sans dériver de nouvelles formules analytiques. Ax est la surcouche qui gère la campagne complète.

import torch
from botorch.models import SingleTaskGP
from botorch.fit import fit_gpytorch_mll
from botorch.acquisition import qLogExpectedImprovement
from botorch.optim import optimize_acqf
from botorch.utils.sampling import draw_sobol_samples
from gpytorch.mlls import ExactMarginalLogLikelihood

bornes = torch.tensor([[0.0, 0.0, 0.0], [1.0, 1.0, 1.0]], dtype=torch.double)

X = draw_sobol_samples(bounds=bornes, n=10, q=1).squeeze(1)   # plan initial
Y = simulation_couteuse(X).unsqueeze(-1)                      # à MAXIMISER

for iteration in range(40):
    gp  = SingleTaskGP(X, Y)                       # normalisation gérée en interne
    mll = ExactMarginalLogLikelihood(gp.likelihood, gp)
    fit_gpytorch_mll(mll)                          # hyperparamètres par vraisemblance

    acq = qLogExpectedImprovement(model=gp, best_f=Y.max())
    candidat, _ = optimize_acqf(
        acq, bounds=bornes,
        q=4,                                       # 4 points EN PARALLÈLE
        num_restarts=20, raw_samples=512,          # multi-départs sur l'acquisition
    )

    X = torch.cat([X, candidat])
    Y = torch.cat([Y, simulation_couteuse(candidat).unsqueeze(-1)])

print("meilleur point :", X[Y.argmax()], "valeur :", Y.max().item())

Le paramètre q=4 illustre un cas fréquent en ingénierie : si quatre simulations peuvent tourner en parallèle sur un cluster, on veut quatre points complémentaires, pas quatre fois le même. Les acquisitions « q » de BoTorch traitent cela correctement, en pénalisant la redondance à l'intérieur du lot.

8. Contraintes, multi-objectif, multi-fidélité

• Contraintes coûteuses — quand la faisabilité elle-même doit être simulée (une contrainte mécanique, une température maximale), on modélise chaque contrainte par son propre GP et l'on pondère l'acquisition par la probabilité de faisabilité. Le point proposé est alors celui qui maximise le gain attendu et réalisable.
• Multi-objectif — rendement et coût, précision et latence. On ne cherche plus un optimum mais un front de Pareto : l'ensemble des compromis qu'aucun autre point ne domine sur tous les critères à la fois. L'acquisition de référence est qEHVI (expected hypervolume improvement), qui mesure le gain de volume dominé.
• Espaces mixtes — variables continues, entières et catégorielles mélangées (un choix de matériau, un nombre de couches). Traitées par des noyaux dédiés ou par relaxation continue.
• Multi-fidélité — souvent le gain le plus spectaculaire : on dispose d'un simulateur grossier rapide et d'un simulateur fin coûteux. Un GP multi-tâche apprend la corrélation entre les deux niveaux et n'appelle le coûteux que lorsque c'est décisif. Le même principe s'applique au réglage d'hyperparamètres, où « peu d'époques » est une fidélité basse — c'est l'idée de Hyperband, croisée avec la modélisation bayésienne dans BOHB.

Méthode              Évaluations nécessaires   Parallélisme   Quand l'utiliser
──────────────────────────────────────────────────────────────────────────────────
Grid search          très nombreuses           parfait        2-3 paramètres, pas plus
Random search        nombreuses                parfait        baseline honnête, robuste
Hyperband / ASHA     moyennes                  bon            entraînements interruptibles
TPE (Optuna)         peu                       bon            défaut pratique en ML
GP + EI (BoTorch)    très peu                  bon (batch)    évaluations RÉELLEMENT
                                                              coûteuses, dimension < 20

Un repère honnête : en dessous de 20 ou 30 évaluations disponibles et en dimension modérée, l'optimisation bayésienne par GP domine nettement. Pour régler les hyperparamètres d'un gradient boosting qui s'entraîne en dix secondes, Optuna (TPE) est plus simple et suffisant (module 14). Et la recherche aléatoire reste une baseline étonnamment solide, qu'il faut toujours inclure dans la comparaison.

9. Cas d'usage et limites

Plans d'expériences      choisir les essais physiques suivants (chimie, matériaux,
                         procédés) — chaque essai coûte des jours et des matières
Calibration de modèle    identifier les paramètres d'un modèle physique à partir
                         de mesures (module 21)
Conception assistée      optimiser une géométrie évaluée par CFD ou éléments finis
Réglage coûteux          hyperparamètres d'un gros réseau (des heures par essai)
Contrôle / robotique     réglage de contrôleurs sur système réel, où chaque essai
                         a un coût et un risque
A/B testing adaptatif    allocation séquentielle, à la frontière des bandits (module 24)

En apprentissage supervisé, on dispose de la bonne réponse pour chaque exemple. En apprentissage par renforcement, on ne dispose que d'un signal de récompense, souvent rare et différé, et les décisions influencent les situations futures. Ce module présente le cadre, les algorithmes qui comptent, et — point important — les raisons pour lesquelles il faut souvent y renoncer.

1. Le cadre : agent, environnement, récompense

Un agent observe un état, choisit une action, reçoit une récompense et se retrouve dans un nouvel état. La boucle recommence.

            action a_t
        ┌──────────────────►┐
   ┌────┴─────┐       ┌─────▼──────────┐
   │  AGENT   │       │ ENVIRONNEMENT  │
   └────▲─────┘       └─────┬──────────┘
        │                   │
        └───────────────────┘
      état s_{t+1}, récompense r_{t+1}

  Exemple (maintenance) : état = usure mesurée + heures de fonctionnement
                          actions = {ne rien faire, inspecter, remplacer}
                          récompense = -coût de l'action - coût d'une panne subie

Le formalisme est le processus de décision markovien \((\mathcal{S}, \mathcal{A}, P, R, \gamma)\), dont l'hypothèse centrale est la propriété de Markov : l'état contient toute l'information utile pour prédire la suite, le passé n'apporte rien de plus. Quand ce n'est pas le cas — un capteur ne voit qu'une partie du système —, on parle de POMDP, et l'on empile généralement les dernières observations pour reconstituer un état approché.

L'agent maximise le retour, somme actualisée des récompenses futures :

Le facteur \(\gamma\) joue deux rôles : il garantit la convergence de la somme, et il encode l'horizon temporel. Avec \(\gamma = 0{,}99\), l'horizon effectif est d'environ \(1/(1-\gamma) = 100\) pas ; avec \(\gamma = 0{,}9\), il tombe à 10. C'est un paramètre bien plus structurant qu'il n'y paraît : trop bas, l'agent devient myope et sacrifie l'avenir ; trop haut, l'apprentissage devient instable car les valeurs à estimer deviennent énormes.

2. Fonctions de valeur et équations de Bellman

Une politique \(\pi(a\mid s)\) donne la probabilité de choisir l'action \(a\) dans l'état \(s\) — c'est ce qu'on cherche. On lui associe deux fonctions de valeur :

\(V\) évalue un état (« à quel point est-il bon d'être ici ? »), \(Q\) évalue un couple état-action (« à quel point est-il bon de faire ceci, ici ? »). La différence est décisive : \(Q\) permet de choisir directement, en prenant l'action de plus grande valeur, sans avoir besoin de connaître le modèle de transition.

La récursivité du retour donne l'équation de Bellman, et sa version optimale :

Elle se lit simplement : la valeur d'une action, c'est la récompense immédiate plus la valeur actualisée du meilleur coup suivant. C'est un point fixe d'un opérateur contractant de facteur \(\gamma\) : itérer l'opérateur rapproche donc nécessairement de \(Q^\star\), et la politique optimale s'en déduit par \(\pi^\star(s) = \arg\max_a Q^\star(s,a)\). Tout le RL par valeurs consiste à approcher ce point fixe à partir d'échantillons plutôt qu'avec la connaissance du modèle.

3. Exploration et exploitation

Le dilemme apparaît déjà dans le cas le plus simple, le bandit manchot : plusieurs leviers de récompense moyenne inconnue, et un budget de tirages. Exploiter le meilleur levier connu, c'est risquer de passer à côté d'un meilleur jamais essayé ; explorer, c'est payer des tirages sous-optimaux.

ε-greedy          action aléatoire avec probabilité ε, sinon la meilleure connue.
                  Simple ; on fait décroître ε au fil de l'apprentissage (de 1 à 0,05).
Boltzmann         probabilité ∝ exp(Q/τ) : explore proportionnellement à la qualité,
                  au lieu de tirer uniformément parmi les mauvaises actions.
UCB               Q(a) + c·√(ln t / N(a)) : bonus d'optimisme pour les actions peu
                  testées. Même intuition qu'en optimisation bayésienne (module 19).
Thompson          tirage dans le postérieur sur les récompenses (module 10).
                  Très efficace en bandits, et naturellement parallélisable.
Bonus intrinsèque récompense de curiosité (erreur de prédiction, nouveauté de l'état)
                  pour les environnements à récompense extrêmement rare.

4. Q-learning et SARSA

Quand les états et actions sont peu nombreux, \(Q\) tient dans un tableau. Trois familles pour l'estimer : la programmation dynamique (exacte, mais exige de connaître \(P\) et \(R\) — rarement le cas) ; Monte-Carlo (attendre la fin de l'épisode et moyenner les retours observés — sans biais, mais de forte variance et inapplicable aux tâches continues) ; et les différences temporelles (TD), qui sont la grande idée du domaine.

TD met à jour immédiatement, à partir de l'estimation courante de l'état suivant, sans attendre la fin de l'épisode. C'est du bootstrapping : on apprend une estimation à partir d'une autre estimation — ce qui semble circulaire, mais converge bel et bien, puisque la récompense observée injecte à chaque pas une information réelle.

import numpy as np

Q = np.zeros((n_etats, n_actions))
alpha, gamma, eps = 0.1, 0.99, 1.0

for episode in range(5_000):
    s, _ = env.reset()
    termine = False
    while not termine:
        # ε-greedy : explorer ou exploiter
        a = env.action_space.sample() if np.random.rand() < eps else int(Q[s].argmax())

        s2, r, termine, tronque, _ = env.step(a)

        cible = r + gamma * Q[s2].max() * (not termine)   # 0 si l'épisode est fini
        Q[s, a] += alpha * (cible - Q[s, a])              # l'erreur TD
        s = s2
        termine = termine or tronque

    eps = max(0.05, eps * 0.999)     # on explore de moins en moins

politique = Q.argmax(axis=1)         # la politique gloutonne finale

Sa particularité : le \(\max\) fait apprendre la valeur de la politique optimale, alors même que l'agent se comporte selon une politique exploratrice. C'est un algorithme off-policy, ce qui permet de réutiliser des données anciennes ou produites par un autre agent. SARSA remplace \(\max_{a'}Q(s',a')\) par \(Q(s',a')\) où \(a'\) est l'action réellement choisie : il apprend la valeur de la politique suivie, exploration comprise (on-policy), ce qui le rend plus prudent près des états dangereux.

L'exemple canonique est celui de la falaise : un chemin court longe un précipice, un chemin long en reste éloigné. Q-learning apprend le chemin optimal — le bord — et tombe régulièrement pendant l'apprentissage à cause de l'exploration ; SARSA, qui intègre le risque de l'exploration dans ses valeurs, préfère le chemin sûr. Aucun des deux n'a tort : ils répondent à des questions différentes.

5. Deep RL : DQN

Dès que l'espace d'états devient grand ou continu (des pixels), le tableau est remplacé par un réseau \(Q_\theta(s,a)\). Cette substitution casse les garanties de convergence — on combine approximation de fonction, bootstrapping et apprentissage off-policy, ce que la littérature appelle la « triade mortelle » — et trois mécanismes ont été nécessaires pour stabiliser l'entraînement :

• Replay buffer — stocker les transitions et en tirer des mini-lots au hasard. Cela casse la corrélation temporelle des échantillons successifs (qui violerait l'hypothèse i.i.d. du gradient stochastique) et réutilise chaque expérience plusieurs fois, ce qui améliore l'efficacité en données.
• Réseau cible — la cible \(r + \gamma\max_{a'}Q_{\theta^-}(s',a')\) est calculée avec une copie figée \(\theta^-\), mise à jour périodiquement. Sans cela, on poursuit une cible qui bouge à chaque pas — comme viser une cible fixée à son propre fusil — et l'entraînement diverge.
• Double DQN — l'opérateur \(\max\) surestime systématiquement les valeurs, parce que le maximum d'estimateurs bruités est biaisé vers le haut. On dissocie donc le choix de l'action (réseau courant) et son évaluation (réseau cible).

Autres raffinements utiles : dueling (séparer valeur d'état et avantage de l'action), prioritized replay (rejouer davantage les transitions à forte erreur TD) et n-step returns. DQN et ses variantes ne traitent que les actions discrètes — pour un contrôle continu, il faut passer aux méthodes de politique.

6. Gradient de politique : REINFORCE, PPO

Plutôt que d'estimer des valeurs pour en déduire une politique, on paramètre directement \(\pi_\theta(a\mid s)\) et on monte le gradient de la performance. Le théorème du gradient de politique donne une forme remarquablement simple :

La lecture est intuitive : on augmente la probabilité des actions dont l'avantage \(A = Q - V\) est positif — celles qui font mieux que la moyenne de l'état — et on diminue celle des autres. Le terme \(\nabla \log \pi\) indique dans quelle direction modifier les paramètres pour rendre l'action plus probable ; l'avantage donne le signe et l'ampleur.

La fonction \(V\) joue ici le rôle de baseline : la soustraire ne change pas l'espérance du gradient mais réduit fortement sa variance. Sans elle, toutes les actions d'un épisode réussi seraient renforcées, y compris les mauvaises ; avec elle, seules celles qui ont fait mieux que prévu le sont. C'est ce qui rend la méthode utilisable en pratique.

REINFORCE est la version brute (avantage estimé par le retour Monte-Carlo) : correcte mais très bruitée. Les méthodes acteur-critique ajoutent un second réseau, le critique, qui estime \(V\) et fournit un avantage à faible variance (A2C, A3C, puis GAE pour un compromis biais-variance réglable).

PPO est devenu le défaut pratique. Son idée : réutiliser plusieurs fois un même lot de trajectoires pour faire plusieurs pas de gradient — ce qui améliore beaucoup l'efficacité en données — tout en empêchant la politique de trop s'éloigner de celle qui a produit ces données, sans quoi les gradients calculés ne veulent plus rien dire. En notant \(\rho = \pi_\theta(a|s)/\pi_{\text{old}}(a|s)\) :

L'écrêtage annule le gain marginal dès que le rapport sort de la bande \([1-\epsilon, 1+\epsilon]\) (typiquement \(\epsilon = 0{,}2\)) : au-delà, pousser davantage n'apporte plus rien à l'objectif, donc le gradient s'annule et le pas reste borné. C'est simple, robuste, et c'est l'algorithme utilisé pour l'alignement des LLM par retour humain (module 22).

Algorithme   Actions      On/Off-policy   Points forts
────────────────────────────────────────────────────────────────────────────────
Q-learning   discrètes    off             tabulaire, fondation théorique
DQN          discrètes    off             pixels, jeux Atari, efficace en données
REINFORCE    les deux     on              simple, mais forte variance
A2C / A3C    les deux     on              acteur-critique, bon compromis
PPO          les deux     on              LE défaut : robuste, peu de réglage
SAC          continues    off             entropie maximale, très efficace en données :
                                          le choix pour la robotique et le contrôle
TD3          continues    off             DDPG corrigé de la surestimation

import gymnasium as gym
from stable_baselines3 import PPO
from stable_baselines3.common.env_util import make_vec_env
from stable_baselines3.common.evaluation import evaluate_policy

# 8 environnements en parallèle : le goulot est la SIMULATION, pas le réseau
env = make_vec_env("LunarLander-v3", n_envs=8)

modele = PPO("MlpPolicy", env, learning_rate=3e-4, n_steps=1024,
             batch_size=256, gamma=0.999, verbose=0, seed=0)
modele.learn(total_timesteps=1_000_000)

# évaluer sur PLUSIEURS graines : la variance en RL est notoirement élevée
for graine in range(5):
    moy, ecart = evaluate_policy(modele, gym.make("LunarLander-v3"),
                                 n_eval_episodes=30)
    print(f"graine {graine}: {moy:.1f} ± {ecart:.1f}")

7. Model-based, offline RL, RLHF

• Model-based — apprendre un modèle de la dynamique \(P(s'\mid s,a)\) et planifier dedans (Dyna, MuZero, MPC). Gain considérable en nombre d'interactions réelles, au prix des erreurs du modèle, que la planification a tendance à exploiter : l'agent trouve les failles du simulateur appris plutôt que la bonne stratégie.
• Offline RL — apprendre uniquement à partir d'un jeu de données fixe, sans interagir. C'est le seul cadre réaliste en santé, en finance ou en industrie, où l'exploration est interdite. La difficulté est le décalage de distribution : l'agent surestime des actions jamais observées, puisque rien ne le contredit. Les algorithmes dédiés (CQL, IQL) contraignent la politique à rester près des données.
• RLHF — l'alignement des LLM : on entraîne un modèle de récompense sur des préférences humaines (« cette réponse est meilleure que celle-là »), puis on optimise le modèle de langage par PPO contre cette récompense, avec une pénalité KL pour ne pas trop s'éloigner du modèle initial. Les variantes récentes (DPO, GRPO) court-circuitent en partie cette boucle (module 22).
• Sim2real — entraîner en simulation puis transférer au réel. La randomisation de domaine (module 13) force une politique robuste au décalage entre simulateur et monde réel.

8. En pratique, et pourquoi c'est difficile

Jeux et simulation       Atari, Go, StarCraft — l'environnement est gratuit et parfait
Robotique / contrôle     locomotion, manipulation, drones (avec sim2real)
Systèmes opérés          refroidissement de datacenter, gestion d'énergie, trafic réseau
Recommandation           optimisation d'engagement à long terme (via bandits, module 24)
Alignement de LLM        RLHF, raisonnement par récompense vérifiable
Gestion de portefeuille  allocation séquentielle sous contrainte de risque

C'est le module où la formation d'ingénieur devient un avantage plutôt qu'un détour. La situation est toujours la même : on dispose d'un code de calcul fiable mais coûteux — CFD, éléments finis, neutronique, transport Monte-Carlo — et l'on a besoin de milliers d'évaluations pour propager des incertitudes, optimiser une conception ou piloter un système en temps réel. Le machine learning n'y remplace pas la physique : il en construit une approximation utilisable, et il faut savoir exactement dans quelles limites elle reste valide.

1. Monte-Carlo et réduction de variance

Estimer \(I = \mathbb{E}[f(X)]\) par tirage aléatoire donne \(\hat I_N = \frac1N\sum f(x_i)\), d'erreur type \(\sigma/\sqrt{N}\). La propriété remarquable — et la raison pour laquelle la méthode domine en grande dimension — est que cette vitesse ne dépend pas de la dimension, contrairement à toute quadrature déterministe : une grille de 10 points par axe fait \(10^{d}\) évaluations, soit un million en dimension 6 et un milliard en dimension 9. Le revers de Monte-Carlo : gagner un chiffre significatif coûte cent fois plus de simulations. D'où l'importance des techniques de réduction de variance, qui s'attaquent au numérateur plutôt qu'au dénominateur.

Variables antithétiques   tirer u ET 1-u : la corrélation négative entre les deux
                          annule une partie de la fluctuation. Gain modeste, coût nul.
Variable de contrôle      utiliser une grandeur g corrélée à f dont l'espérance est
                          CONNUE : Î = mean(f) - c·(mean(g) - E[g]). Souvent le
                          meilleur rapport gain/effort — un modèle simplifié ou un
                          métamodèle fait un excellent contrôle.
Échantillonnage           tirer selon une loi q qui concentre les tirages là où f
préférentiel              compte, puis corriger par le poids p/q. INDISPENSABLE pour
                          les événements rares.
Stratification / LHS      découper l'espace et garantir une couverture régulière.
Multi-niveaux (MLMC)      combiner beaucoup de simulations grossières et peu de
                          simulations fines : réduit le coût de plusieurs ordres.

2. Quasi-Monte-Carlo et plans d'expériences

Les suites à faible discordance (Sobol, Halton) remplacent l'aléa par des points délibérément bien répartis : là où un tirage aléatoire laisse des trous et des amas, une suite de Sobol remplit l'espace régulièrement. La convergence passe de \(O(N^{-1/2})\) à \(O((\log N)^d/N)\) — bien meilleure en dimension modérée, l'avantage s'érodant quand \(d\) devient grand.

from scipy.stats import qmc

# hypercube latin optimisé : projection uniforme sur CHAQUE axe pris séparément
plan = qmc.LatinHypercube(d=6, optimization="random-cd", seed=0).random(n=120)

# suite de Sobol : extensible par puissances de 2, excellente uniformité
sobol = qmc.Sobol(d=6, scramble=True, seed=0).random_base2(m=7)     # 128 points

# mise à l'échelle vers les bornes PHYSIQUES des paramètres
X = qmc.scale(plan, l_bounds=[0.1, 300, 1e5, 0.2, 1.0, 0.0],
                    u_bounds=[0.9, 600, 5e5, 0.8, 3.0, 1.0])
print(qmc.discrepancy(plan))              # plus c'est bas, mieux l'espace est couvert

Règle empirique pour un premier plan destiné à construire un métamodèle : environ dix points par dimension d'entrée, puis enrichissement adaptatif (module 19) plutôt qu'un grand plan figé. Et toujours prévoir un jeu de validation tiré indépendamment : valider un métamodèle sur les points qui ont servi à le construire n'a aucun sens, surtout s'il interpole exactement.

3. Propagation d'incertitude et chaos polynomial

Les entrées d'un calcul sont incertaines : propriétés matériaux, conditions aux limites, tolérances géométriques. La propagation consiste à en déduire la loi de la sortie — et pas seulement sa moyenne, car une décision de sûreté porte sur un quantile extrême, pas sur un comportement typique.

Le chaos polynomial (PCE) développe la sortie sur une base de polynômes orthogonaux des variables aléatoires d'entrée :

La base est choisie selon la loi des entrées : Hermite pour des gaussiennes, Legendre pour des uniformes — c'est cette correspondance qui rend les polynômes orthogonaux pour le produit scalaire défini par la loi, et donc qui donne les formules de moments ci-dessus.

L'intérêt est double : moyenne et variance se lisent directement sur les coefficients, sans simulation supplémentaire, et les indices de sensibilité s'en déduisent analytiquement (section suivante). Les coefficients s'obtiennent par projection ou par régression parcimonieuse (LARS), ce qui en fait un cas particulier remarquable de la régression régularisée du module 14. Limites : la taille de la base explose avec la dimension et le degré, et la méthode suppose une réponse régulière — un comportement discontinu (bifurcation, changement de régime) la met en échec, exactement comme un GP à noyau lisse.

4. Analyse de sensibilité globale

Question centrale en ingénierie : quelle part de la variabilité de la sortie chaque entrée explique-t-elle ? Les dérivées partielles ne répondent pas — elles ne valent qu'au point où elles sont calculées, et pour une plage de variation infinitésimale. L'analyse de sensibilité globale décompose la variance totale sur tout le domaine de variation :

\(S_i\) est l'indice du premier ordre : la part de variance qu'on supprimerait en fixant \(X_i\) à sa vraie valeur. \(S_{T_i}\) est l'indice total : effet propre plus toutes les interactions où \(X_i\) intervient.

S_Ti ≈ S_i          la variable agit SEULE, sans interaction → effet additif
S_Ti ≫ S_i          la variable n'agit qu'EN INTERACTION avec d'autres.
                    Attention : la fixer ferait perdre plus que S_i ne le suggère.
S_Ti ≈ 0            la variable n'influence rien → on peut la FIXER, ce qui réduit
                    la dimension du problème (utile pour le module 19)
Σ S_i < 1           la part manquante est due aux INTERACTIONS

exemple :  conductivité  S=0,45  S_T=0,52   → effet principal, peu d'interaction
           débit         S=0,10  S_T=0,44   → agit surtout EN INTERACTION
           épaisseur     S=0,02  S_T=0,03   → négligeable : à fixer

from SALib.sample import sobol as sobol_sample
from SALib.analyze import sobol as sobol_analyze

probleme = {"num_vars": 4,
            "names": ["conductivite", "debit", "epaisseur", "coef_echange"],
            "bounds": [[10, 25], [0.5, 2.0], [1e-3, 5e-3], [200, 900]]}

X = sobol_sample.sample(probleme, 1024)        # N(2d+2) = 10 240 évaluations
Y = np.array([surrogate(x) for x in X])        # sur le MÉTAMODÈLE, pas le code direct

Si = sobol_analyze.analyze(probleme, Y)
print(Si["S1"], Si["ST"])

Le coût — \(N(2d+2)\) évaluations — est la raison pour laquelle on calcule presque toujours les indices de Sobol sur un métamodèle plutôt que sur le code direct. Pour un simple criblage préalable en grande dimension, la méthode de Morris identifie les variables négligeables pour quelques dizaines d'évaluations seulement, et sert à réduire le problème avant l'analyse fine.

5. Métamodèles : construire et valider

Un métamodèle remplace le code de calcul par une fonction bon marché ajustée sur un plan d'expériences. Les familles, et le critère de choix :

Krigeage / GP       interpole exactement, fournit une VARIANCE de prédiction.
(module 19)         Le défaut pour n < quelques milliers de points. Indispensable
                    si l'on veut enrichir le plan de façon adaptative.
RBF                 interpolation par fonctions radiales : simple, robuste, très bon
                    en dimension modérée. Sans incertitude native — c'est exactement
                    ce que j'ai implémenté dans mdisd (voir le projet).
Chaos polynomial    moments et indices de Sobol analytiques. Excellent si la réponse
                    est régulière et la dimension modérée.
Gradient boosting   robuste aux discontinuités et au bruit numérique, mais N'EXTRAPOLE
                    PAS (module 14) : dangereux hors du domaine du plan.
Réseau de neurones  utile quand le plan est très grand (10⁴+) ou la sortie de grande
                    dimension (un champ complet plutôt qu'un scalaire).

6. Réduction de modèle : POD, DMD

Les métamodèles précédents prédisent un scalaire. Quand la sortie est un champ — température en tout point, vitesse sur tout le maillage, soit des millions de valeurs —, on passe par la réduction de modèle. L'observation fondatrice : les solutions d'un système physique paramétré, malgré leur taille apparente, vivent presque toujours dans un sous-espace de très faible dimension.

La POD (décomposition orthogonale aux valeurs propres) consiste à assembler une matrice de snapshots — chaque colonne est un champ solution pour un jeu de paramètres — et à en calculer la SVD (module 8). Les premiers vecteurs singuliers forment une base de modes, et la décroissance des valeurs singulières indique combien en garder. C'est, mot pour mot, une PCA appliquée à des champs physiques : les modes obtenus ont souvent une interprétation directe — structures cohérentes d'un écoulement, modes propres de vibration.

import numpy as np

S = np.column_stack(snapshots)                 # (n_degrés_de_liberté, n_simulations)
moyenne = S.mean(axis=1, keepdims=True)
U, s, Vt = np.linalg.svd(S - moyenne, full_matrices=False)

energie = np.cumsum(s**2) / np.sum(s**2)
r = int(np.searchsorted(energie, 0.9999) + 1)  # souvent r ≈ 10-30 pour 99,99 %
print(f"{S.shape[0]} degrés de liberté réduits à {r} modes")
Phi = U[:, :r]                                 # la base réduite

# coefficients réduits : LA CIBLE d'un surrogate (GP, RBF) sur les paramètres
A = Phi.T @ (S - moyenne)                      # (r, n_simulations)
champ_predit = moyenne + Phi @ coeffs_predits  # reconstruction d'un champ COMPLET

Deux stratégies en découlent. Le ROM non intrusif — celui du code ci-dessus — apprend simplement les coefficients modaux en fonction des paramètres : facile, applicable à un code fermé dont on n'a que les sorties, mais sans garantie physique. Le ROM intrusif (projection de Galerkin des équations sur la base réduite) conserve la structure des équations et offre de meilleures garanties, mais exige d'accéder aux opérateurs du solveur, et la non-linéarité impose des techniques d'hyper-réduction (DEIM). La DMD, elle, extrait des modes associés à des fréquences et des taux de croissance, ce qui en fait l'outil naturel pour analyser une dynamique et prédire à court terme.

La limite commune est claire : ces méthodes supposent une faible dimension effective. Un écoulement fortement turbulent, un problème avec chocs ou fronts mobiles, une bifurcation — et le spectre ne décroît plus. C'est d'ailleurs l'information utile : la décroissance des valeurs singulières mesure la réductibilité du problème, et se calcule avant tout investissement dans un ROM.

7. SciML : opérateurs neuronaux et hybrides

Le module 16 présente les PINN, qui apprennent une solution sous contrainte d'EDP. Les opérateurs neuronaux visent plus haut : apprendre l'application qui envoie une fonction d'entrée (champ de conditions initiales, de coefficients, de géométrie) sur la fonction solution — donc une famille entière de problèmes, résolue en une seule fois.

• DeepONet — deux réseaux, l'un encodant la fonction d'entrée échantillonnée (branch), l'autre les coordonnées d'évaluation (trunk), combinés par produit scalaire. Fondé sur un théorème d'approximation d'opérateurs.
• FNO (Fourier Neural Operator) — effectue la convolution dans l'espace de Fourier en ne gardant que les basses fréquences : le coût passe en \(O(n\log n)\), et le modèle devient indépendant de la discrétisation, donc entraînable sur maillage grossier et évaluable sur maillage fin. Très efficace sur les problèmes à géométrie régulière et périodique.
• GNN sur maillage (module 18) — la bonne réponse quand la géométrie est complexe et non structurée.

Une fois entraînés, ces modèles évaluent une solution en millisecondes contre des heures de calcul — d'où leur intérêt pour l'optimisation de forme, le contrôle en temps réel ou l'exploration paramétrique. Le prix à payer : la précision plafonne bien au-dessus de celle d'un solveur, la généralisation hors du régime d'entraînement est mauvaise, et l'entraînement demande un gros corpus de simulations. L'investissement ne se justifie donc que par un grand nombre d'évaluations futures.

8. Assimilation de données et problèmes inverses

L'assimilation combine un modèle physique et des mesures pour estimer l'état ou les paramètres d'un système. C'est le cadre de la météorologie opérationnelle, du recalage de modèles et de la surveillance en ligne. Le formalisme variationnel (4D-Var) s'écrit comme la minimisation d'une fonctionnelle :

On reconnaît un MAP (module 10) : \(B\) encode la confiance dans l'ébauche a priori, \(R\) la précision des capteurs, et minimiser \(J\) revient à maximiser une densité a posteriori gaussienne. La minimisation demande le gradient par rapport à l'état initial, obtenu par le modèle adjoint — c'est exactement de la différentiation automatique en mode inverse, la même mécanique que la rétropropagation (module 16). D'où l'intérêt actuel des simulateurs différentiables : quand le solveur lui-même est écrit dans un cadre autodifférentiable (JAX, PyTorch), calibrer un paramètre physique devient une optimisation par gradient ordinaire, et l'on récupère gratuitement des décennies d'outillage.

L'alternative séquentielle est le filtre de Kalman d'ensemble (EnKF), qui propage un ensemble d'états au lieu d'une covariance explicite — indispensable dès que la dimension dépasse quelques milliers (module 17).

9. Jumeau numérique et crédibilité

Un jumeau numérique n'est pas une simulation 3D animée : c'est un modèle d'un système physique particulier, synchronisé avec ses mesures, et utilisé pour décider. L'architecture typique assemble tout ce module : un modèle réduit ou un surrogate pour tenir la contrainte temps réel, un mécanisme d'assimilation pour se recaler sur les capteurs, une quantification d'incertitude pour assortir chaque prédiction d'une marge (module 10), et un module de décision (maintenance, pilotage — module 24). Les difficultés réelles sont moins scientifiques qu'opérationnelles : qualité et dérive des capteurs, latence, versionnement du modèle et de ses recalages (module 26), et la question de savoir quand le jumeau doit déclarer qu'il ne sait plus.

Un modèle de langage ne connaît que ce qu'il a vu à l'entraînement, et il l'a appris sous forme de statistiques, pas de faits vérifiables. Tout ce module tourne autour de la même question pratique : comment lui fournir la bonne information au bon moment, et comment l'adapter à un usage précis sans le réentraîner entièrement.

1. Ce qu'est un LLM, mécaniquement

Un grand modèle de langage est un transformer décodeur (module 16) entraîné à une seule tâche : prédire le jeton suivant. Tout le reste — répondre, résumer, traduire, coder — émerge de cette tâche unique appliquée à une quantité colossale de texte.

Le texte est d'abord découpé en jetons par un tokeniseur (BPE ou SentencePiece), qui fusionne itérativement les paires de caractères les plus fréquentes du corpus. Résultat : les mots courants deviennent un jeton unique, les mots rares se décomposent en morceaux.

"maintenance préventive"  →  ["maintenance", " prév", "entive"]     3 jetons
"P-204"                   →  ["P", "-", "204"]                      3 jetons
"anticonstitutionnel"     →  ["anti", "constitu", "tionnel"]        3 jetons

Ordre de grandeur : ~4 caractères par jeton en anglais, ~3 en français.
Conséquence pratique : compter les lettres d'un mot ou faire de l'arithmétique
sur des chiffres est DIFFICILE pour un modèle qui ne voit pas les caractères
mais des blocs — ce n'est pas un défaut de raisonnement, c'est la représentation.

À chaque étape, le modèle produit une distribution de probabilité sur tout le vocabulaire, dont on tire le jeton suivant. Les paramètres d'échantillonnage pilotent ce tirage :

distribution brute :  "pompe" 0,50   "vanne" 0,30   "moteur" 0,15   "chat" 0,05

température = 0     → toujours "pompe" (déterministe) : extraction, classification
température = 0,7   → distribution légèrement piquée : rédaction équilibrée
température = 1,5   → distribution aplatie, "chat" devient possible : créativité
                      (et incohérence)
top-p = 0,9         → on ne garde que les jetons cumulant 90 % de la masse,
                      puis on tire dedans : coupe la traîne absurde

Trois conséquences pratiques de cette mécanique. Le modèle n'a pas de mémoire entre deux appels : l'historique complet est renvoyé à chaque fois, et la « conversation » est une illusion entretenue par le contexte. Il ne sait pas ce qu'il ignore : produire un texte plausible est son objectif, ce qui rend les hallucinations structurelles et non accidentelles. Et son coût est proportionnel au contexte : l'attention est quadratique en longueur (module 16), et la mémoire du cache KV croît linéairement avec le nombre de jetons.

2. Embeddings et similarité sémantique

Un embedding projette un texte dans \(\mathbb{R}^d\) (typiquement \(d\) de 384 à 3072) de sorte que la proximité géométrique traduise la proximité de sens. « fuite au presse-étoupe » et « suintement au niveau du joint » sont éloignés lexicalement — aucun mot commun — mais proches sémantiquement, donc voisins dans cet espace.

La mesure usuelle est le cosinus :

On compare des directions, pas des amplitudes — c'est ce qu'on veut, car la norme d'un embedding dépend surtout de la longueur du texte. Si les vecteurs sont normalisés, cosinus et produit scalaire coïncident, et maximiser le cosinus revient à minimiser la distance euclidienne : d'où les optimisations des bases vectorielles, qui normalisent systématiquement à l'indexation.

Ces représentations sont apprises de façon contrastive (module 13) : on rapproche les paires de textes liés — une question et son passage de réponse — et l'on éloigne les paires non liées. C'est la raison pour laquelle un modèle d'embedding conçu pour la recherche est entraîné différemment d'un modèle de similarité entre phrases, et pourquoi le choix du modèle doit correspondre à l'usage. Le classement MTEB les compare tâche par tâche ; en pratique, un modèle multilingue de taille moyenne suffit largement pour un corpus francophone, et il tourne sur processeur.

3. Index vectoriels : HNSW et IVF-PQ

Chercher les \(k\) plus proches voisins de façon exacte coûte \(O(nd)\) par requête : 10 millions de vecteurs en dimension 1024 font 40 Go de calcul par question. On utilise donc une recherche approchée (ANN), qui échange quelques points de rappel contre plusieurs ordres de grandeur en latence.

HNSW — un graphe de navigation hiérarchique
  couche 2 (peu de nœuds, liens LONGS)   ●───────────────●      "autoroutes"
  couche 1                               ●────●─────●────●      routes nationales
  couche 0 (tous les nœuds, liens courts)●─●─●─●─●─●─●─●─●      rues locales
  On entre par le haut, on descend en suivant toujours le voisin le plus proche
  de la requête. Quelques dizaines de comparaisons au lieu de dix millions.
  + rappel excellent, latence très faible, insertion dynamique
  - mémoire élevée (le graphe s'ajoute aux vecteurs)
  Paramètres : M (degré), ef_construction (qualité), ef_search (rappel/latence)

IVF-PQ — partition + compression
  1. IVF : on partitionne l'espace en cellules par k-means (module 14) ; à la
     requête, on ne visite que les nprobe cellules les plus proches.
  2. PQ : chaque vecteur est découpé en sous-vecteurs, chacun remplacé par
     le code de son centroïde → mémoire divisée par 10 à 50.
  + adapté aux très grands corpus qui ne tiennent pas en RAM
  - rappel moindre, l'index doit être entraîné au préalable

Le choix de l'outil suit surtout le contexte d'exploitation : pgvector si les données vivent déjà dans PostgreSQL (un seul système à opérer, transactions et filtres SQL gratuits — module 4), FAISS pour un index local sans serveur, Qdrant ou Milvus pour du service dédié avec filtrage par métadonnées et montée en charge. Le filtrage est d'ailleurs le critère discriminant réel : restreindre la recherche à un client ou à une période est trivial en SQL, et demande un support spécifique côté base vectorielle pour rester efficace — filtrer après la recherche approchée peut vider entièrement le résultat.

4. RAG : le pipeline complet

La génération augmentée par récupération répond au problème de fond : au lieu d'espérer que le modèle « sache », on lui fournit les passages pertinents dans le contexte et on lui demande de répondre à partir d'eux. Deux bénéfices immédiats : la connaissance devient à jour et modifiable sans réentraînement, et les réponses deviennent sourçables — donc vérifiables.

INDEXATION (hors ligne)
  1. Extraction        PDF, HTML, Word → texte propre (les tableaux sont le point dur)
  2. Découpage         en passages de 200-500 jetons, avec recouvrement de 10-20 %
  3. Enrichissement    ajouter titre, section, date, source à chaque passage
  4. Embedding         vectoriser chaque passage
  5. Indexation        stocker vecteurs + texte + métadonnées

REQUÊTE (en ligne)
  6. Réécriture        reformuler la question, la désambiguïser avec l'historique
  7. Recherche hybride BM25 (lexical) + vectoriel (sémantique), fusion des rangs
  8. Reranking         un cross-encoder re-note les 50 candidats, on garde les 5 meilleurs
  9. Construction      assembler le prompt : consigne + passages + question
 10. Génération        avec citation obligatoire des sources
 11. Garde-fous        vérifier que la réponse s'appuie sur les passages fournis

Deux étapes font l'essentiel de la différence entre un prototype et un système utilisable.

Le découpage. Trop petit, le passage perd son contexte (« il » ne réfère plus à rien, un chiffre n'a plus son unité) ; trop grand, il dilue le signal et gaspille du contexte payant. Découper sur la structure du document — titres, sections, paragraphes — vaut mieux qu'un découpage à taille fixe qui coupe au milieu d'une phrase. Deux techniques efficaces : la fenêtre glissante avec recouvrement, et le small-to-big, où l'on indexe de petits passages précis (bons pour la recherche) mais où l'on renvoie au modèle le bloc parent complet (bon pour la compréhension).

La recherche hybride et le reranking. La recherche vectorielle seule échoue sur les termes rares — références produit, noms propres, codes — que BM25 trouve immédiatement (module 18) ; inversement BM25 échoue sur les reformulations. Les combiner par fusion de rangs réciproques est robuste et ne demande aucun réglage (module 23). Le reranker (cross-encoder) lit ensemble la question et le passage, au lieu de comparer deux vecteurs calculés séparément : il est nettement plus précis, trop coûteux pour parcourir tout le corpus, mais parfait pour reclasser cinquante candidats. C'est l'amélioration au meilleur rapport gain/effort de tout le pipeline.

from sentence_transformers import SentenceTransformer, CrossEncoder
import numpy as np

encodeur = SentenceTransformer("intfloat/multilingual-e5-base")
reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

# indexation (hors ligne) — noter le préfixe "passage:" exigé par ce modèle
V = encodeur.encode([f"passage: {p}" for p in passages], normalize_embeddings=True)

def repondre(question: str, k_dense: int = 50, k_final: int = 5) -> str:
    q = encodeur.encode(f"query: {question}", normalize_embeddings=True)
    candidats = np.argsort(-(V @ q))[:k_dense]           # cosinus = produit scalaire

    scores = reranker.predict([(question, passages[i]) for i in candidats])
    retenus = [passages[i] for i in candidats[np.argsort(-scores)[:k_final]]]

    contexte = "\n\n".join(f"[{i+1}] {p}" for i, p in enumerate(retenus))
    prompt = (
        "Réponds uniquement à partir des extraits ci-dessous. "
        "Cite tes sources par leur numéro. Si l'information n'y figure pas, "
        "réponds exactement : « Je ne trouve pas cette information ».\n\n"
        f"{contexte}\n\nQuestion : {question}"
    )
    return appeler_llm(prompt, temperature=0)

5. Évaluer un système RAG

Un RAG a deux moitiés, et il faut les évaluer séparément — sinon on ne sait pas laquelle réparer.

• Récupération — rappel@k (le bon passage est-il dans les \(k\) renvoyés ?), MRR et NDCG pour le classement (module 23). Si le rappel@10 est mauvais, aucun travail sur le prompt ne sauvera le système : c'est l'indexation ou la recherche qu'il faut corriger.
• Génération — groundedness (chaque affirmation est-elle appuyée par un passage fourni ?), pertinence de la réponse, exactitude par rapport à une référence. Ces critères s'évaluent avec un LLM juge, calibré au préalable sur quelques dizaines d'exemples annotés à la main — sans quoi on remplace une incertitude par une autre.

La démarche qui marche : constituer un jeu de 50 à 100 questions représentatives avec leurs réponses attendues et les passages qui les contiennent, puis mesurer à chaque modification. Sans ce jeu, toute « amélioration » du prompt est une impression. Des outils comme RAGAS ou promptfoo industrialisent cette boucle.

6. Prompt engineering

Un prompt est une spécification exécutable : il gagne à être structuré comme telle. Ce qui fonctionne de façon reproductible :

• Séparer rôle, consigne, contexte et question, avec des délimiteurs nets. Placer les instructions avant un long contexte, et rappeler la question après — les modèles traitent mieux ce qui encadre.
• Donner des exemples (few-shot) : deux ou trois exemples bien choisis valent mieux qu'un paragraphe d'explications, en particulier pour fixer un format de sortie.
• Demander un raisonnement sur les tâches à étapes, mais dans un champ dédié (raisonnement puis reponse) pour pouvoir l'ignorer à l'affichage.
• Imposer une sortie structurée — JSON contraint par un schéma, validé par Pydantic (module 6). C'est ce qui rend un appel de LLM utilisable dans une chaîne de traitement automatisée.
• Prévoir explicitement l'échappatoire — « si l'information n'est pas disponible, réponds exactement X ». Sans cette porte de sortie, le modèle invente, parce que produire du texte plausible est son objectif.
• Découper les tâches complexes en plusieurs appels spécialisés plutôt qu'un prompt monolithique : chacun devient testable séparément.

Et surtout : évaluer. Un prompt se traite comme du code — un jeu de cas de test, une métrique, un suivi des versions. Itérer « au ressenti » sur trois exemples produit des régressions invisibles sur les autres.

7. Fine-tuning : LoRA, QLoRA, DPO

Réentraîner tous les poids d'un modèle de 7 milliards de paramètres demande des dizaines de gigaoctets de VRAM — poids, gradients et états de l'optimiseur, soit environ 18 octets par paramètre (module 25). L'ajustement à faible rang contourne le problème : on gèle les poids \(W\) et l'on n'apprend qu'une correction de rang faible.

Avec \(r\) de 8 à 64, on entraîne moins de 1 % des paramètres, pour une qualité très proche du fine-tuning complet. C'est exactement l'hypothèse de rang faible du module 8 : l'adaptation à une tâche particulière vit dans un sous-espace de petite dimension. Bénéfice secondaire considérable : les adaptateurs pèsent quelques mégaoctets, donc on peut en stocker des dizaines et les charger à la demande sur un même modèle de base. QLoRA ajoute la quantification du modèle de base en 4 bits, ce qui permet d'ajuster un modèle de 7 milliards de paramètres sur une seule carte grand public.

Besoin                                    Solution           Coût
─────────────────────────────────────────────────────────────────────────────────
Connaissance factuelle, à jour, sourcée   RAG                faible, modifiable à chaud
Format de sortie, ton, style              prompt + few-shot  nul
Tâche répétitive au format très strict    LoRA (SFT)         modéré (heures de GPU)
Vocabulaire ou domaine très spécialisé    LoRA, voire        élevé
                                          pré-entraînement continu
Aligner sur des préférences               DPO                modéré, besoin de préférences
Réduire latence et coût                   distillation vers  élevé, mais amorti
                                          un petit modèle

La règle de décision est simple et souvent ignorée : le fine-tuning enseigne un comportement, le RAG fournit une connaissance. Injecter des faits par fine-tuning fonctionne mal — le modèle les mélange et les oublie —, coûte cher à mettre à jour et empêche toute citation de source. À l'inverse, espérer obtenir un format de sortie très particulier uniquement par prompt finit par saturer : quelques centaines d'exemples et un LoRA règlent le problème définitivement.

Sur l'alignement : le SFT (apprentissage supervisé sur des paires question-réponse) apprend « quoi répondre » ; le DPO apprend à partir de préférences (« cette réponse est meilleure que celle-là ») en optimisant directement une perte de classement, sans passer par un modèle de récompense ni par PPO (module 20). C'est plus simple, plus stable, et devenu le défaut pour aligner un modèle ouvert.

8. Servage, coûts, quantification

La quantification réduit la précision des poids : 16 bits → 8 ou 4 bits. Un modèle de 7 milliards de paramètres passe de 14 Go à environ 4 Go en 4 bits, ce qui le rend exécutable sur une carte modeste. La dégradation en qualité est faible avec les schémas modernes (GPTQ, AWQ, GGUF en k-quants), qui préservent plus finement les poids les plus sensibles — c'est presque toujours le bon compromis pour de l'auto-hébergement, et c'est ce que je fais tourner sur mon NAS avec Ollama.

Pour servir plusieurs utilisateurs, vLLM apporte deux mécanismes décisifs. Le PagedAttention gère le cache KV comme une mémoire paginée : au lieu de réserver le contexte maximal pour chaque séquence, on alloue des blocs à la demande — fini le gaspillage dû aux séquences de longueurs différentes. Le continuous batching insère de nouvelles requêtes dans le lot en cours dès qu'une séquence se termine, au lieu d'attendre la fin du lot entier. Le gain en débit est d'un ordre de grandeur par rapport à une boucle naïve.

Côté coûts, deux ordres de grandeur à garder en tête : le prix d'un appel est dominé par les jetons d'entrée dans un RAG (le contexte est long, la réponse courte), et la latence perçue dépend surtout du premier jeton — d'où l'intérêt du streaming, qui affiche la réponse au fil de la génération. Le cache de prompt, proposé par la plupart des fournisseurs, réduit fortement le coût des préfixes répétés (consignes système, exemples few-shot).

9. Sécurité et limites

• Hallucinations — inhérentes à l'objectif d'entraînement. Le RAG les réduit sans les supprimer ; imposer la citation et vérifier l'ancrage de chaque affirmation reste nécessaire.
• Données personnelles — tout ce qui entre dans un prompt part chez le fournisseur du modèle, et tout ce qui est indexé dans un RAG devient interrogeable par ses utilisateurs. D'où l'anonymisation en amont, le cloisonnement des index par droits d'accès appliqué à la récupération, et parfois l'auto-hébergement.
• Non-déterminisme — même à température 0, le résultat peut varier (parallélisme des noyaux GPU, changements de version côté fournisseur). Il faut versionner les modèles utilisés et rejouer les évaluations à chaque changement.
• Dérive silencieuse — une mise à jour du modèle distant peut dégrader un prompt soigneusement réglé, sans aucun signal. Le suivi d'évaluations dans le temps est la seule protection (module 26).

Trouver un document, ordonner des résultats, suggérer un article : ces trois problèmes partagent la même architecture — réduire des millions de candidats à quelques dizaines, puis les ordonner finement. C'est l'un des domaines applicatifs les plus répandus de la data science, et celui où l'écart entre l'évaluation hors ligne et la réalité est le plus grand.

1. L'architecture commune

1. RÉCUPÉRATION (retrieval)      millions → quelques centaines de candidats
   contrainte : quelques millisecondes → modèles simples et INDEXABLES
   moyens : BM25, index vectoriel ANN (module 22), filtres métier, règles

2. CLASSEMENT (ranking)          centaines → dizaines, ordonnées finement
   contrainte : dizaines de millisecondes → modèle riche autorisé
   moyens : gradient boosting de ranking, cross-encoder, réseau profond

3. RE-CLASSEMENT MÉTIER          ce qui est réellement affiché
   diversité, fraîcheur, stocks, marges, équité entre fournisseurs,
   exclusions réglementaires, dé-duplication

Cette séparation est imposée par la latence : on ne peut pas évaluer un modèle coûteux sur un million d'items en 50 ms. Elle a une conséquence souvent négligée : la qualité du système est plafonnée par l'étage de récupération. Un excellent modèle de classement ne peut pas remonter un item que la récupération n'a pas proposé. Quand un système déçoit, c'est donc le rappel de l'étage 1 qu'il faut mesurer en premier — et c'est une mesure simple : sur un jeu de questions annotées, quelle proportion des bons items figure dans les 200 candidats ?

2. Recherche : lexical, sémantique, hybride

Le module 22 présente la recherche dans le cadre du RAG ; les mêmes briques valent pour une recherche destinée à des humains. BM25 (module 18) reste une référence redoutable : il trouve immédiatement les références exactes, les codes produit et les termes rares. La recherche vectorielle gère les reformulations et les synonymes mais échoue sur ces mêmes termes rares, qu'elle n'a souvent jamais vus à l'entraînement.

La combinaison par fusion de rangs réciproques est robuste et sans paramètre à régler :

BM25 renvoie des scores de 0 à 30, le cosinus de -1 à 1 : les additionner
n'a aucun sens, et les normaliser suppose de connaître leurs distributions.
Les RANGS, eux, sont directement comparables.

document A : rang 1 en BM25, rang 8 en vectoriel → 1/61 + 1/68 = 0,0311
document B : rang 3 en BM25, rang 2 en vectoriel → 1/63 + 1/62 = 0,0320  ← devant
Un document bien classé par LES DEUX systèmes remonte, même sans être premier.

Le reste du travail se joue sur la requête et les métadonnées : analyse de la requête (correction orthographique, expansion par synonymes, détection d'intention), filtres (catégorie, date, disponibilité) et gestion des requêtes sans résultat, qui sont le principal motif d'abandon. Sur un corpus technique, un simple dictionnaire de synonymes métier rapporte souvent plus qu'un changement de modèle d'embedding.

3. Learning to rank

Classer n'est pas prédire une valeur : seul l'ordre compte, et les premières positions comptent bien plus que les suivantes — personne ne consulte la page 3. Trois formulations :

• Pointwise — prédire un score de pertinence par item, indépendamment des autres. Simple, mais optimise la mauvaise chose : une erreur en position 1 et une erreur en position 50 pèsent pareil.
• Pairwise — apprendre, pour chaque paire, lequel doit passer devant (RankNet, LambdaRank). Beaucoup plus proche de l'objectif réel.
• Listwise — optimiser directement une métrique de liste comme le NDCG. LambdaMART — gradient boosting (module 14) dont les gradients sont pondérés par le gain de NDCG qu'apporterait l'échange de deux documents — reste l'état de l'art pratique, et est disponible directement dans LightGBM et XGBoost (objective="lambdarank").

La métrique de référence est le NDCG, qui pondère la pertinence par une remise logarithmique sur le rang :

pertinences réelles des 5 résultats affichés : [3, 0, 2, 3, 1]   (0 = inutile, 3 = parfait)

DCG = (2³-1)/log₂(2) + (2⁰-1)/log₂(3) + (2²-1)/log₂(4) + (2³-1)/log₂(5) + (2¹-1)/log₂(6)
    =    7/1,00     +      0/1,58     +     3/2,00     +     7/2,32     +     1/2,58
    = 7 + 0 + 1,5 + 3,02 + 0,39 = 11,91

classement IDÉAL : [3, 3, 2, 1, 0] → IDCG = 7 + 4,42 + 1,5 + 0,43 + 0 = 13,35
NDCG = 11,91 / 13,35 = 0,89

La normalisation par le classement idéal rend les requêtes COMPARABLES entre elles,
ce que ne permettent ni la précision@k ni le MRR.

Les variables d'un modèle de ranking se rangent en trois familles : caractéristiques de la requête (longueur, intention, langue), de l'item (popularité, fraîcheur, qualité, prix) et surtout de l'appariement requête-item (scores BM25 par champ, similarité d'embedding, correspondances exactes, historique de clics sur cette paire). Ce sont ces dernières qui portent l'essentiel du signal.

4. Données de clics et biais de position

Les clics sont la source d'étiquettes la plus abondante — et la plus traîtresse. Un item est cliqué parce qu'il est pertinent, mais surtout parce qu'il était affiché en première position. Les études d'oculométrie montrent un taux de clic en première position cinq à dix fois supérieur à celui de la cinquième, à pertinence égale.

Biais de position    les premiers résultats sont bien plus cliqués, à pertinence égale
Biais de sélection   on n'observe QUE ce qui a été affiché par la politique en place :
                     les bons items jamais montrés restent invisibles pour toujours
Biais de confiance   les utilisateurs font confiance au système et cliquent "par défaut"
Absence de négatif   un non-clic ne signifie pas "non pertinent" : peut-être non VU
                     (d'où l'importance de journaliser ce qui a été réellement affiché)

Entraîner naïvement sur les clics revient donc à apprendre le classement actuel et à le figer : le système se confirme lui-même indéfiniment. Les remèdes : la pondération inverse de propension — chaque clic est pondéré par l'inverse de la probabilité d'examen à cette position, ce qui rend son poids comparable quelle que soit la place occupée —, l'estimation de cette courbe de propension par permutations aléatoires contrôlées sur une petite fraction du trafic, et l'utilisation de signaux moins biaisés que le clic brut : temps de lecture, achat, ou retour en arrière rapide, qui est un signal négatif fort.

5. Filtrage collaboratif et factorisation

L'intuition fondatrice : des utilisateurs qui ont aimé les mêmes choses aimeront les mêmes choses ensuite. Aucune connaissance du contenu n'est nécessaire — seule la matrice d'interactions compte, ce qui est à la fois la force (ça marche sur n'importe quel catalogue) et la faiblesse (ça ne marche pas sur un item neuf).

La factorisation matricielle approche cette matrice très creuse \(R\) par un produit de faible rang \(R \approx P Q^\top\), où chaque utilisateur et chaque item sont représentés par un vecteur latent de dimension \(k\) (typiquement 32 à 256) :

μ        la moyenne globale                    (tout le monde note autour de 3,5)
b_u      le biais UTILISATEUR                  (cet utilisateur note systématiquement bas)
b_i      le biais ITEM                          (ce film plaît à tout le monde)
p_uᵀq_i  l'affinité SPÉCIFIQUE                 (cet utilisateur aime CE genre)

Les seuls biais expliquent souvent la moitié du signal : les inclure avant toute
sophistication est le meilleur premier pas.

C'est l'idée d'approximation de rang faible du module 8, adaptée au cas où la plupart des entrées sont manquantes : on n'ajuste que sur les interactions observées, d'où l'usage de la descente de gradient stochastique ou des moindres carrés alternés (ALS) plutôt que d'une SVD classique, qui exigerait une matrice complète.

6. Retour implicite

Deux réponses. Les méthodes à confiance pondérée (ALS implicite) traitent les non-interactions comme des négatifs de faible poids, et les interactions répétées comme des positifs de poids croissant. Ou bien l'on change d'objectif : BPR (Bayesian Personalised Ranking) n'apprend pas une valeur mais un ordre — il maximise la probabilité qu'un item vu passe devant un item tiré au hasard. L'échantillonnage de ces négatifs est le détail d'implémentation qui décide de la qualité du résultat : tirer uniformément donne des négatifs trop faciles (l'item tiré est évidemment sans intérêt), tirer parmi les items populaires donne des négatifs informatifs.

7. Two-tower et recommandation séquentielle

L'architecture à deux tours est devenue le standard industriel de l'étage de récupération : un réseau encode l'utilisateur et son contexte, un autre encode l'item, et la pertinence est le produit scalaire des deux vecteurs.

   utilisateur + contexte              item + métadonnées
         │                                    │
    [ tour user ]                        [ tour item ]
         │                                    │
      vecteur u  ─────── produit ────────  vecteur i
                        scalaire

  L'astuce : les vecteurs d'items se calculent HORS LIGNE et s'indexent dans une
  base vectorielle (module 22). Une requête en ligne ne demande qu'un encodage
  utilisateur + une recherche ANN. On obtient la souplesse d'un réseau avec la
  latence d'un index — impossible avec un modèle qui croiserait user et item
  dès la première couche.

La recommandation séquentielle (GRU4Rec, SASRec, BERT4Rec) modélise l'historique comme une séquence et prédit l'action suivante — c'est un transformer appliqué à des identifiants d'items (module 16). Elle capture l'intention du moment, ce que la factorisation matricielle, purement statique, ignore complètement : quelqu'un qui vient de consulter trois perceuses n'est pas dans le même état que sa moyenne historique.

Un point à connaître : au-delà du prototype, les gains viennent moins de l'architecture que des variables et de la fraîcheur des données. Un modèle simple réentraîné toutes les heures bat souvent un modèle sophistiqué réentraîné chaque semaine.

8. Évaluer : hors ligne et en ligne

Précision@k / Rappel@k   les basiques, faciles à interpréter
MAP, MRR                 position du premier élément pertinent
NDCG@k                   pertinence graduée avec remise logarithmique : la référence
Couverture (catalogue)   quelle part du catalogue est réellement recommandée ?
Diversité intra-liste    les k items proposés se ressemblent-ils trop ?
Nouveauté / sérendipité  recommande-t-on autre chose que les best-sellers ?
Équité                   entre fournisseurs, auteurs, catégories (module 27)

Le découpage des données mérite une attention particulière : un découpage aléatoire est une fuite (module 12), puisqu'il permet d'entraîner sur le futur d'un utilisateur pour prédire son passé. Il faut découper par date et évaluer sur la période suivante — ou, à défaut, exclure les dernières interactions de chaque utilisateur (leave-last-out).

9. Démarrage à froid, popularité, boucles

• Démarrage à froid — un nouvel utilisateur ou un nouvel item n'a pas d'historique, donc pas de vecteur latent. Solutions : s'appuyer sur le contenu (attributs, embedding du texte ou de l'image, module 18), recommander par popularité contextualisée, poser deux ou trois questions d'amorçage, ou exploiter un bandit pour explorer rapidement (module 24).
• Biais de popularité — les modèles entraînés sur des interactions amplifient les items déjà populaires, ce qui pénalise la longue traîne et appauvrit le catalogue utile. Correctifs : échantillonnage négatif pondéré par la popularité, pénalisation explicite dans la fonction de perte, ou contrainte de couverture au re-classement.
• Boucle de rétroaction — le système ne voit que les conséquences de ses propres recommandations, ce qui rétrécit progressivement l'exposition (modules 24 et 26). Les parades : conserver une part d'exploration aléatoire, maintenir un groupe témoin permanent, et surveiller la diversité dans le temps comme métrique de santé.
• Contraintes système — latence, coût d'indexation, fraîcheur des embeddings, cohérence entre les variables d'entraînement et celles servies en ligne (module 26). C'est là, plus que dans le modèle, que se situent les vraies difficultés d'ingénierie.

Un modèle produit un nombre ; une organisation prend une action. Entre les deux se trouve un espace que les cours de machine learning traversent en une phrase — « on seuille à 0,5 » — et où se perd l'essentiel de la valeur des projets. Ce module traite ce chaînon : coûts d'erreur, contraintes de capacité, effet réel d'une action, et optimisation sous contraintes.

1. Théorie de la décision et seuil optimal

Décider, c'est choisir l'action qui maximise l'utilité espérée. Pour une décision binaire, écrivons le coût attendu de chacune des deux options en fonction de la probabilité \(p\) que l'événement se produise :

si J'AGIS (j'envoie un technicien) :       coût = C_FP × (1-p)     (intervention inutile)
si JE N'AGIS PAS :                          coût = C_FN × p         (panne subie)

agir est préférable quand    C_FP × (1-p)  <  C_FN × p
                    ⟺        C_FP          <  p × (C_FN + C_FP)
                    ⟺        p             >  C_FP / (C_FP + C_FN)

La formule vaut mieux qu'un long discours : si rater une panne coûte cent fois plus qu'une inspection inutile, le seuil optimal est à 1 % — et non à 50 %. Le seuil par défaut de 0,5 n'est justifié que dans le cas très particulier où les deux erreurs coûtent exactement pareil, ce qui n'arrive presque jamais.

La conséquence pratique : obtenir de l'interlocuteur métier le rapport des coûts est une étape de modélisation à part entière. Elle n'exige pas des chiffres exacts — un ordre de grandeur suffit à déplacer le seuil de façon décisive, et la question « est-ce dix fois pire, ou cent fois pire ? » est presque toujours répondable, là où « combien exactement ? » ne l'est pas.

import numpy as np

cout_fp, cout_fn = 50.0, 4_000.0      # inspection inutile / panne subie
p = modele.predict_proba(X_val)[:, 1]

seuils = np.linspace(0.001, 0.5, 500)
cout = [(((p >= s) & (y_val == 0)).sum() * cout_fp +
         ((p <  s) & (y_val == 1)).sum() * cout_fn) for s in seuils]

s_opt = seuils[int(np.argmin(cout))]
print(f"seuil optimal empirique = {s_opt:.3f}")
print(f"seuil théorique         = {cout_fp / (cout_fp + cout_fn):.3f}")
print(f"économie vs seuil 0,5   = {cout[np.argmin(np.abs(seuils - 0.5))] - min(cout):.0f} €")

2. Décider sous contrainte de capacité

Dans la réalité, le seuil n'est souvent même pas le bon objet : une équipe de maintenance peut traiter vingt interventions par semaine, un service client rappeler cent clients par jour. Peu importe alors que trois mille cas dépassent le seuil — on en traitera vingt. La décision devient un problème de sélection sous budget.

Quand chaque action a un coût et un gain variables, c'est un problème de sac à dos : on classe par ratio gain espéré sur coût plutôt que par score brut. Un cas à 80 % de risque coûtant trois jours d'intervention peut passer après deux cas à 50 % coûtant une heure chacun.

Et l'évaluation change de métrique : ni AUC ni F1, mais la courbe de gain cumulé — combien de valeur capturée en traitant les \(k\) premiers — et le lift aux rangs qui correspondent à la capacité réelle.

ordre = np.argsort(-p)                       # du plus risqué au moins risqué
gain_cumule = np.cumsum(gain_reel[ordre])    # valeur réellement capturée
cout_cumule = np.cumsum(cout_action[ordre])

capacite = 20                                # ce qu'on peut traiter par semaine
print(f"gain sur les {capacite} premiers : {gain_cumule[capacite-1]:.0f} €")
print(f"lift@{capacite} = "
      f"{gain_cumule[capacite-1] / (capacite * gain_reel.mean()):.1f}× le hasard")

Un modèle avec une AUC inférieure peut très bien être meilleur sur les 2 % de cas que l'on traitera effectivement — et c'est cela qu'il faut optimiser, pas une métrique globale qui pondère également des cas qu'on ne regardera jamais.

3. Uplift : agir sur les bonnes personnes

Voici l'erreur de raisonnement la plus coûteuse du domaine. Un modèle de churn identifie les clients qui vont partir ; on leur envoie une offre de rétention. Mais certains partiront quoi qu'on fasse, d'autres restaient de toute façon, et certains — c'est documenté — partent parce que l'offre leur rappelle qu'ils peuvent partir. Cibler la probabilité d'événement, c'est confondre prédiction et effet d'une action (module 9).

L'uplift (ou effet de traitement individuel) estime la bonne quantité :

                          Reste si TRAITÉ          Part si TRAITÉ
  Reste si NON traité     SÛRS                     À NE PAS DÉRANGER
                          (gain nul, coût réel)    (l'action NUIT : uplift négatif)
  Part si NON traité      PERSUADABLES             CAUSES PERDUES
                          ← LA SEULE CIBLE UTILE   (gain nul, coût réel)

  Un modèle de churn classique cible "part si non traité", donc il mélange
  les PERSUADABLES et les CAUSES PERDUES — et ignore complètement le fait que
  les "à ne pas déranger" font perdre de l'argent DEUX fois.

Estimer \(\tau\) demande des données expérimentales — un A/B test où une partie de la population n'a pas été traitée (module 9) — ou des hypothèses causales fortes. Les approches usuelles : T-learner (un modèle par bras, différence des prédictions — simple, mais la différence de deux modèles bruités est très bruitée), S-learner (un seul modèle avec le traitement comme variable — risque de le sous-pondérer parmi cent autres), X-learner (meilleur quand les groupes sont déséquilibrés) et les forêts causales (econml, causalml), qui partitionnent l'espace pour maximiser l'hétérogénéité de l'effet plutôt que la pureté de la cible.

from causalml.inference.tree import UpliftRandomForestClassifier
from causalml.metrics import plot_qini, qini_score

modele = UpliftRandomForestClassifier(control_name="controle", n_estimators=300)
modele.fit(X_train, treatment=t_train, y=y_train)      # t = "traite" / "controle"

uplift = modele.predict(X_test)

# évaluation : on ordonne par uplift décroissant et on vérifie que le gain
# INCRÉMENTAL réel suit. Une courbe plate = le modèle ne trouve rien.
print(qini_score(df_test, outcome_col="y", treatment_col="t"))
plot_qini(df_test, outcome_col="y", treatment_col="t")

Le raisonnement vaut bien au-delà du marketing : traiter préventivement un équipement, envoyer un technicien, accorder une remise, prioriser un contrôle. Dans tous ces cas, la question utile n'est jamais « que va-t-il se passer ? » mais « qu'est-ce que mon action change ? ».

4. Bandits contextuels

Quand plusieurs actions sont possibles et que l'on observe le résultat immédiatement, on peut apprendre en agissant plutôt que de figer un test A/B pendant trois semaines. Un bandit contextuel choisit une action selon le contexte, observe la récompense, et met à jour sa politique — c'est le cas particulier du RL (module 20) sans transition d'état : l'action d'aujourd'hui ne change pas la situation de demain. D'où une méthode bien plus simple, plus stable et plus sûre.

ε-greedy          trivial à implémenter, exploration non ciblée
LinUCB            borne supérieure de confiance sur un modèle linéaire du contexte :
                  on essaie ce qui est soit bon, soit mal connu (module 19)
Thompson sampling échantillonner dans le postérieur (module 10) : excellent en pratique,
                  naturellement parallélisable, presque aucun réglage
Bandit + coût     intégrer le coût de chaque action dans la récompense

A/B test          quand il faut une MESURE causale propre à communiquer
Bandit            quand il faut MAXIMISER le résultat pendant l'apprentissage
                  (moins de trafic gaspillé sur les mauvaises variantes)

Deux précautions. Un bandit crée des données biaisées par sa propre politique — les bonnes actions sont sur-représentées — ce qui complique toute analyse a posteriori : il faut journaliser les probabilités de sélection pour permettre une évaluation hors ligne non biaisée par pondération inverse (même mécanique qu'au module 23). Et la non-stationnarité doit être traitée explicitement (oubli exponentiel des observations anciennes), sinon le bandit reste bloqué sur une action devenue mauvaise.

5. Décision sous incertitude : le vendeur de journaux

Le problème du newsvendor illustre parfaitement pourquoi une prévision ponctuelle ne suffit pas. On commande une quantité \(q\) avant de connaître la demande \(D\) ; le surstock coûte \(c_o\) par unité, la rupture \(c_u\).

Commander une unité de plus est rentable tant que :
   (probabilité qu'elle SERVE) × c_u   >   (probabilité qu'elle reste) × c_o
              P(D ≥ q) × c_u           >          P(D < q) × c_o
À l'optimum, égalité :  P(D < q*) = c_u / (c_u + c_o)

La quantité optimale n'est donc pas la demande moyenne, mais un quantile de sa distribution. Si une rupture coûte trois fois un surstock, il faut commander le quantile 75 %. C'est ce qui justifie la prévision probabiliste du module 17 : la distribution complète est l'entrée de la décision, la moyenne n'en est qu'un résumé souvent inadapté. Le même raisonnement gouverne le dimensionnement d'une marge de sécurité, d'une réserve d'énergie, d'un effectif de garde ou d'un stock de pièces de rechange.

6. Recherche opérationnelle

Beaucoup de décisions industrielles ne sont pas des prédictions mais des allocations sous contraintes : planifier une production, affecter des équipes, optimiser des tournées, choisir un plan de maintenance. Le ML estime des paramètres (durées, demandes, probabilités de panne) ; la recherche opérationnelle décide. Ignorer cette seconde moitié conduit à livrer des prédictions que personne ne sait transformer en planning.

from ortools.linear_solver import pywraplp

s = pywraplp.Solver.CreateSolver("SCIP")               # solveur MILP

# VARIABLES DE DÉCISION : x[i,j] = 1 si l'équipe i traite l'intervention j
x = {(i, j): s.BoolVar(f"x_{i}_{j}") for i in equipes for j in interventions}

# CONTRAINTES
for j in interventions:                                # chaque intervention couverte
    s.Add(sum(x[i, j] for i in equipes) == 1)          #   exactement une fois
for i in equipes:                                      # capacité hebdomadaire
    s.Add(sum(duree[j] * x[i, j] for j in interventions) <= capacite[i])
for j in urgentes:                                     # les urgences sont prioritaires
    s.Add(sum(x[i, j] for i in equipes_qualifiees) == 1)

# OBJECTIF : maximiser le risque évité, estimé par le modèle de survie (module 17)
s.Maximize(sum(risque_evite[j] * x[i, j] for i in equipes for j in interventions))

statut = s.Solve()
if statut == pywraplp.Solver.OPTIMAL:
    print(f"valeur optimale : {s.Objective().Value():.0f}")
    plan = [(i, j) for (i, j), v in x.items() if v.solution_value() > 0.5]

Les outils : OR-Tools (Google — solveurs LP/MILP, programmation par contraintes, tournées de véhicules), PuLP ou Pyomo pour la modélisation, HiGHS comme solveur libre performant, Gurobi ou CPLEX en commercial.

Ce qu'il faut retenir du fonctionnement : un problème linéaire continu se résout en temps polynomial, mais l'ajout de variables entières le rend NP-difficile — d'où l'importance de la formulation. Une bonne formulation résout en secondes ce qu'une mauvaise ne résout jamais, parce qu'elle donne au solveur des bornes plus serrées pour élaguer son arbre de recherche. Et quand l'optimalité exacte n'est pas nécessaire, les métaheuristiques (recuit simulé, tabou, algorithmes génétiques) donnent de bonnes solutions rapidement.

7. Prédire puis optimiser : le piège

La démarche standard entraîne le modèle à minimiser une erreur de prédiction, puis optimise la décision à partir des prédictions. Le problème : ces deux objectifs ne sont pas alignés.

Deux routes, coûts réels : A = 10, B = 12. Le modèle doit choisir la moins chère.

modèle 1 : prédit A = 11, B = 13     erreur = 1 sur chaque       → choisit A ✓ CORRECT
modèle 2 : prédit A = 11, B =  9     erreur = 1 sur chaque       → choisit B ✗ FAUX

Même RMSE, décisions opposées. Le RMSE ne voit pas que la seule chose qui
compte est l'ORDRE des deux prédictions, pas leur exactitude absolue.

L'apprentissage orienté décision (SPO+, optimisation différentiable) intègre le problème d'optimisation dans l'entraînement, de sorte que le modèle apprenne à bien prédire là où cela change la décision. C'est un domaine encore jeune, mais l'idée est immédiatement exploitable même sans ces méthodes : évaluer toute chaîne prédiction-décision sur le résultat final — coût total, risque évité, valeur capturée — et non sur la métrique intermédiaire du modèle. C'est le prolongement exact du principe du module 12 : la métrique doit venir de la décision.

8. Humain dans la boucle et effets de bord

• Déléguer partiellement — la bonne architecture est souvent à trois zones : décision automatique quand le modèle est confiant et l'enjeu faible, transmission à un humain quand il hésite, procédure de référence quand l'entrée est hors domaine. Les ensembles conformes du module 10 formalisent exactement ce « je ne sais pas trancher » : quand l'ensemble prédit contient plusieurs classes, on transmet.
• Mesurer le système, pas le modèle — ce qui compte est la performance de l'ensemble humain + modèle. Un modèle un peu moins performant mais dont les erreurs sont détectables par l'opérateur produit un meilleur système qu'un modèle opaque légèrement plus précis.
• Anticiper les boucles de rétroaction (module 26) — un modèle qui déclenche des inspections ne verra plus jamais les pannes qu'il a évitées : ses futures données d'entraînement sont modifiées par ses propres décisions, et il finit par « apprendre » que les cas qu'il signale ne tombent jamais en panne. Conserver une petite fraction de cas traités aléatoirement — un groupe témoin permanent — est ce qui permet de continuer à mesurer honnêtement.
• Prévoir le détournement — dès qu'une décision a des conséquences, les personnes concernées s'adaptent à la règle. Un critère devenu cible cesse d'être un bon critère ; les variables les plus faciles à manipuler doivent donc être écartées des modèles qui décident. C'est le même mécanisme que le détournement de récompense en RL (module 20).

Le module 2 traite la concurrence côté processeur. Ici, il s'agit du matériel qui fait réellement tourner l'apprentissage profond. Le message central tient en une phrase : sur un GPU moderne, la puissance de calcul n'est presque jamais le facteur limitant — c'est la mémoire, sa bande passante et les transferts. Comprendre cela change complètement la façon d'optimiser un entraînement.

1. Anatomie d'un GPU

Un processeur est conçu pour exécuter vite une séquence d'instructions compliquées : quelques cœurs puissants, de gros caches, de la prédiction de branchement. Un GPU est conçu pour l'inverse : exécuter la même instruction sur des milliers de données simultanément. Des milliers de cœurs simples, organisés en multiprocesseurs, exécutent les threads par groupes de 32 appelés warps, en mode SIMT — tous les threads d'un warp exécutent la même instruction au même instant.

if (condition dépendant du thread) { A } else { B }

Dans un warp où la moitié des threads prend A et l'autre B, le GPU exécute
A pour tous (en masquant la moitié), PUIS B pour tous (en masquant l'autre) :
le temps d'exécution est la SOMME des deux branches, pas le maximum.
→ toute divergence de branche à l'intérieur d'un warp sérialise l'exécution.

Les tensor cores, unités dédiées au produit matriciel en précision réduite, fournissent l'essentiel de la puissance annoncée sur les fiches techniques — mais uniquement pour des opérations qui prennent cette forme.

La hiérarchie mémoire est ce qui gouverne les performances réelles :

registres              ~ 0 cycle       quelques Ko par multiprocesseur
mémoire partagée       ~ 20 cycles     ~100 Ko par multiprocesseur, gérée à la main
cache L2               ~ 200 cycles    quelques dizaines de Mo
mémoire globale (HBM)  ~ 500 cycles    des dizaines de Go, ~2-3 To/s de bande passante
mémoire hôte (RAM)     ~ 10 000 cycles via PCIe : ~30 Go/s → 100× plus lent que la HBM

2. Intensité arithmétique et modèle roofline

L'intensité arithmétique — le nombre d'opérations effectuées par octet lu en mémoire — décide du régime dans lequel on se trouve :

  perf │                    ┌──────────────── P_max (limite de CALCUL)
 (FLOP/s)│                 ╱ │
        │              ╱    │      matmul de grande taille (I ≈ 100)
        │           ╱       │      → limité par le CALCUL
        │        ╱          │
        │     ╱  ← pente = bande passante mémoire
        │  ╱ │
        │╱   │ addition, ReLU, normalisation (I ≈ 0,5-2)
        └────┴──────────────────────► intensité arithmétique I
             └── limité par la MÉMOIRE : le GPU attend, ses unités de calcul
                 tournent à vide l'essentiel du temps

Un produit matriciel de grande taille lit \(2n^2\) valeurs et fait \(2n^3\) opérations : son intensité croît avec \(n\), il sature donc le calcul. Une addition élément par élément lit deux valeurs, en écrit une et fait une opération : son intensité est de l'ordre de 0,1 — elle est limitée par la bande passante, et le GPU passe son temps à attendre la mémoire.

3. Précision numérique et calcul mixte

          signe+exposant+mantisse   plage        précision   usage
FP32      1 + 8 + 23                ±10³⁸        ~7 chiffres  référence historique
TF32      1 + 8 + 10                ±10³⁸        ~3 chiffres  matmul FP32 sur tensor cores
FP16      1 + 5 + 10                ±65 504      ~3 chiffres  rapide, mais DÉBORDE facilement
BF16      1 + 8 + 7                 ±10³⁸        ~2 chiffres  même plage que FP32 : stable
FP8       1 + 4 + 3                 restreinte               très grands modèles
INT8      entier                                             inférence quantifiée (module 22)

La ligne à retenir : BF16 sacrifie de la précision, FP16 sacrifie de la plage. Or en apprentissage, les gradients sont souvent minuscules (\(10^{-7}\)) : en FP16 ils tombent à zéro, alors qu'en BF16, dont l'exposant est identique à celui du FP32, ils restent représentables. C'est pourquoi BF16 est devenu le défaut dès que le matériel le supporte.

Le calcul en précision mixte stocke une copie maîtresse des poids en FP32 mais effectue les passes avant et arrière en 16 bits : mémoire divisée par deux, débit multiplié par deux à trois, sans perte mesurable. Avec FP16, le loss scaling est indispensable — on multiplie la perte par un grand facteur pour remonter les petits gradients dans la plage représentable, puis on divise avant la mise à jour.

from torch.amp import autocast, GradScaler

scaler = GradScaler()                      # inutile en bf16, indispensable en fp16
for x, y in loader:
    opt.zero_grad(set_to_none=True)        # set_to_none : moins de trafic mémoire
    with autocast("cuda", dtype=torch.bfloat16):
        perte = critere(modele(x), y)
    scaler.scale(perte).backward()
    scaler.step(opt); scaler.update()

4. Le budget mémoire d'un entraînement

La question « pourquoi ce modèle ne tient-il pas sur ma carte ? » se répond par une addition. Pour \(N\) paramètres entraînés avec Adam en précision mixte :

Poids (bf16)                  2N octets
Copie maîtresse (fp32)        4N
Gradients                     4N
États Adam (m et v, fp32)     8N     ← Adam stocke DEUX moments par paramètre
──────────────────────────────────────
Total "statique"             ~18N octets  → un modèle de 1 Md de paramètres = ~18 Go
                                            AVANT la moindre activation

Activations                  ∝ BATCH × profondeur × longueur de séquence
                             et c'est presque toujours ce qui fait déborder la carte

Les leviers, par ordre de coût croissant :

• Réduire la taille de lot et compenser par accumulation de gradient : on fait quatre passes avant/arrière sans mettre à jour, puis une seule mise à jour. Le lot effectif est identique, la mémoire d'activations divisée par quatre.
• Gradient checkpointing — ne conserver que certaines activations et recalculer les autres pendant la passe arrière. Environ 30 % de temps en plus pour une réduction mémoire d'un facteur cinq à dix : l'échange est souvent excellent.
• Optimiseur moins gourmand — SGD avec momentum coûte 4N au lieu de 8N, Adafactor bien moins encore.
• Distribuer les états d'optimiseur entre plusieurs cartes (ZeRO, section 7).

# accumulation de gradient : lot effectif = 4 × taille du mini-lot
for i, (x, y) in enumerate(loader):
    with autocast("cuda", dtype=torch.bfloat16):
        perte = critere(modele(x), y) / 4          # on moyenne sur les 4 micro-lots
    perte.backward()                                # les gradients S'ACCUMULENT (module 3)
    if (i + 1) % 4 == 0:
        opt.step(); opt.zero_grad(set_to_none=True)

modele.gradient_checkpointing_enable()              # recalcul plutôt que stockage

Par ailleurs, la fragmentation de l'allocateur explique beaucoup d'erreurs de mémoire insuffisante alors qu'il « reste » de la place : la variable d'environnement PYTORCH_CUDA_ALLOC_CONF, réglée sur expandable_segments:True, aide souvent.

5. Profiler avant d'optimiser

from torch.profiler import profile, ProfilerActivity, schedule

with profile(
    activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
    schedule=schedule(wait=1, warmup=1, active=3),   # ignorer les premières itérations
    record_shapes=True, profile_memory=True,
    on_trace_ready=torch.profiler.tensorboard_trace_handler("./logs"),
) as prof:
    for i, (x, y) in enumerate(loader):
        etape_entrainement(x, y)
        prof.step()
        if i > 6: break

print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=15))

Longs trous entre noyaux CUDA     le GPU ATTEND les données → section 6
Beaucoup de temps dans            transferts hôte↔GPU excessifs → réduire les
  aten::copy_                     allers-retours, utiliser pin_memory
Multitude de petits noyaux        candidats à la FUSION → torch.compile
  élément par élément
Appels bloquants                  .item(), print(tenseur), .cpu() DANS la boucle :
                                  chacun force une SYNCHRONISATION et casse le
                                  pipeline asynchrone. Accumuler et n'afficher
                                  qu'en fin d'époque.

6. Le pipeline d'entrée, goulot n° 1

• Plusieurs workers — num_workers à 4-8 par GPU, avec persistent_workers=True et prefetch_factor pour que le chargement recouvre le calcul. C'est du parallélisme de processus (module 2), avec les mêmes contraintes de sérialisation.
• Mémoire épinglée — pin_memory=True plus .to(device, non_blocking=True) permettent un transfert asynchrone par DMA pendant que le GPU calcule. Sans mémoire épinglée, le système doit d'abord recopier dans une zone verrouillée, ce qui sérialise.
• Format de stockage — des millions de petits fichiers écroulent n'importe quel système de fichiers (chaque ouverture est un aller-retour). Regrouper en archives séquentielles (WebDataset, TFRecord) ou en Parquet transforme des accès aléatoires en lecture séquentielle, souvent un facteur dix.
• Décodage — le décodage JPEG et les augmentations sur processeur saturent vite : les déporter sur GPU (NVIDIA DALI, torchvision.io avec décodage matériel) libère le goulot.
• Prétraitement figé — tout ce qui est déterministe (redimensionnement, normalisation, tokenisation) se calcule une fois et se stocke, plutôt qu'à chaque époque.

7. Entraînement distribué

DONNÉES (DDP)     chaque GPU a une COPIE COMPLÈTE du modèle et traite un sous-lot
                  différent ; les gradients sont moyennés par all-reduce.
                  Simple, efficace, LE DÉFAUT — tant que le modèle tient sur une carte.

ZeRO / FSDP       on PARTITIONNE états d'optimiseur, puis gradients, puis paramètres
                  entre les GPU, rassemblés à la demande couche par couche.
                  Permet d'entraîner des modèles bien plus gros que la mémoire d'une
                  carte, au prix de communications supplémentaires.

TENSEUR           une même couche est découpée entre plusieurs GPU (les matrices sont
                  partitionnées). Communication intense à chaque couche : réservé à
                  l'intérieur d'un nœud, où les liens sont rapides (NVLink).

PIPELINE          les couches sont réparties par étages ; les micro-lots circulent.
                  Attention à la "bulle" : les premiers étages attendent pendant que
                  les derniers finissent.

CONTEXTE          découpe la dimension de séquence, pour les très longs contextes.

# lancement : torchrun --nproc_per_node=4 entrainement.py
import os, torch.distributed as dist
from torch.nn.parallel import DistributedDataParallel as DDP
from torch.utils.data.distributed import DistributedSampler

dist.init_process_group("nccl")                  # NCCL : la bibliothèque de
rang_local = int(os.environ["LOCAL_RANK"])       # communication GPU de NVIDIA
torch.cuda.set_device(rang_local)

modele = DDP(modele.to(rang_local), device_ids=[rang_local])
echantillonneur = DistributedSampler(dataset)    # partition SANS recouvrement

for epoque in range(n):
    echantillonneur.set_epoch(epoque)            # sinon le même ordre à chaque époque
    for xb, yb in loader:
        ...                                      # DDP moyenne les gradients
                                                 # automatiquement au backward()
    if rang_local == 0:                          # journaliser et sauvegarder
        torch.save(modele.module.state_dict(), "ckpt.pt")   # .module : le vrai modèle

Trois points de vigilance. L'efficacité de passage à l'échelle n'est jamais de 100 % : la communication (all-reduce) croît avec le nombre de cartes, et huit GPU donnent typiquement un facteur six à sept, pas huit — il faut la mesurer, pas la supposer. Le lot effectif est multiplié par le nombre de GPU, ce qui impose d'ajuster le taux d'apprentissage et le warmup (module 8) ; sinon la convergence se dégrade sans qu'on comprenne pourquoi. Enfin, la reproductibilité demande de gérer les graines par rang et l'ordre de l'échantillonneur.

8. Optimiser l'inférence

En production, le coût cumulé de l'inférence dépasse largement celui de l'entraînement : un modèle s'entraîne une fois et répond des millions de fois. C'est donc là que l'optimisation rapporte le plus. Les leviers, par ordre de rentabilité :

• Regroupement dynamique — traiter plusieurs requêtes ensemble améliore radicalement le débit, car l'inférence d'un petit lot est limitée par la bande passante et non par le calcul (section 2) : charger les poids coûte pareil pour une requête ou pour trente-deux. C'est ce que font vLLM et Triton (module 22).
• Quantification — INT8 ou 4 bits : mémoire divisée, latence réduite, dégradation faible avec les schémas modernes.
• Compilation — torch.compile, ONNX Runtime, TensorRT : fusion de noyaux et spécialisation aux formes d'entrée, souvent un facteur deux sans rien changer au modèle.
• Cache KV — en génération, conserver les clés et valeurs déjà calculées évite de tout recalculer à chaque jeton ; sa gestion mémoire est le principal enjeu du service de LLM.
• Distillation — entraîner un petit modèle à imiter le grand : le gain le plus important quand la charge est massive et stable.
• Ne pas utiliser de GPU — pour un gradient boosting ou un petit réseau, un processeur bien utilisé (ONNX Runtime, threads correctement bornés — module 2) est moins cher et plus simple à exploiter.

L'arbitrage de fond reste latence contre débit : un gros lot maximise le débit et dégrade la latence individuelle, puisque la première requête attend que le lot se remplisse. La bonne cible se déduit du contrat de service, pas d'un réflexe d'optimisation.

9. Coût, énergie, louer ou posséder

Un calcul de coin de table vaut mieux qu'une intuition : coût \(\approx\) prix horaire de l'instance \(\times\) nombre de GPU \(\times\) durée. À quelques euros de l'heure par carte, un entraînement d'une semaine sur huit GPU se chiffre en milliers d'euros — ce qui justifie largement de passer deux jours à profiler avant de lancer. Les instances spot ou préemptibles divisent la facture par deux ou trois, à condition que l'entraînement sache reprendre depuis un point de contrôle, ce qui est de toute façon une bonne pratique.

Sur l'énergie : la consommation se calcule à partir de la puissance des cartes, du PUE du centre de données et de l'intensité carbone du réseau électrique — codecarbon l'automatise. Le choix du fournisseur et de la région pèse davantage que la plupart des optimisations logicielles, et c'est une information qui a sa place dans une model card (module 26).

Enfin, l'arbitrage louer/posséder : au-delà d'une utilisation soutenue, une machine locale devient rentable — c'est ce qui m'a conduit à installer un GPU dans mon NAS pour l'inférence de modèles locaux. Il faut simplement compter le coût complet : matériel, électricité, refroidissement, temps d'administration, et l'impossibilité de changer d'échelle rapidement.

Un modèle en production n'est pas un artefact figé : c'est un système vivant, dont les entrées dérivent, dont les performances se dégradent en silence, et qui doit rester reproductible et réversible. Ce module traite de tout ce qui commence après le notebook — et qui détermine si le projet produit de la valeur ou de la dette.

1. La dette technique du ML

L'article de Sculley et al. (Google, 2015), Hidden Technical Debt in Machine Learning Systems, reste la meilleure entrée en matière. Son constat, resté célèbre par son schéma : le code du modèle occupe une petite boîte au milieu d'un ensemble bien plus vaste — collecte, vérification des données, infrastructure de servage, gestion de configuration, outillage d'analyse, monitoring, gestion des ressources. Tout ce qui entoure le modèle le dépasse largement en volume comme en coût de maintenance.

Deux formes de dette sont propres au ML.

Les frontières floues d'abord. En génie logiciel classique, une interface bien définie isole un module : on peut le modifier sans toucher au reste. Un modèle, lui, crée des dépendances non déclarées entre toutes ses entrées : modifier une source de données change son comportement sans qu'aucune interface ne le signale. Les auteurs résument cela par l'acronyme CACE — Changing Anything Changes Everything. Ajouter une variable modifie les poids de toutes les autres ; retirer une catégorie déplace toutes les frontières de décision.

Les boucles de rétroaction ensuite : un modèle de recommandation influence ce que les utilisateurs voient, donc ce qu'ils cliquent, donc les données de son prochain entraînement (modules 23 et 24). Le système apprend alors de ses propres sorties, et toute dérive devient auto-entretenue.

2. Reproductibilité

Reproductible signifie : à partir du dépôt, on peut régénérer exactement le même modèle. Cela demande de figer quatre choses, et il suffit d'en oublier une pour perdre la propriété.

Code           un commit Git PRÉCIS (et non "la branche main", qui bouge)
Environnement  uv.lock + image Docker taguée par DIGEST (modules 1 et 5)
               — un tag comme :latest ne fige rien
Données        version ou empreinte du jeu utilisé (hash, snapshot, requête figée
               avec sa date). "la table clients" n'est pas une version.
Aléa           graines fixées : Python, NumPy, framework, ET ordre de chargement
               (un DataLoader mélange aussi)

import os, random, numpy as np, torch

def figer_alea(seed: int = 42) -> None:
    os.environ["PYTHONHASHSEED"] = str(seed)      # hachage des chaînes, lu au démarrage
    random.seed(seed)
    np.random.seed(seed)
    torch.manual_seed(seed)
    torch.cuda.manual_seed_all(seed)
    torch.backends.cudnn.deterministic = True     # au prix d'un peu de vitesse
    torch.backends.cudnn.benchmark = False        # sinon cuDNN choisit l'algo le plus
                                                  # rapide, qui varie d'une exécution
                                                  # à l'autre — et change les résultats

Le déterminisme complet sur GPU reste hors d'atteinte pour certaines opérations : les réductions atomiques additionnent les contributions dans un ordre qui dépend de l'ordonnancement des threads, et l'addition flottante n'est pas associative. L'objectif réaliste est donc un modèle équivalent aux fluctuations numériques près, et surtout une traçabilité complète : à partir d'une prédiction, pouvoir remonter au modèle, à son entraînement, à ses données et à son code.

3. Versionner code, données et modèles

Git gère le code, mais pas des fichiers de plusieurs gigaoctets (module 1). DVC résout cela élégamment : le fichier de données part sur un stockage distant (S3, disque réseau, NAS) et Git ne conserve qu'un petit fichier texte contenant son empreinte et son emplacement.

dvc add data/raw/transactions.parquet   # crée transactions.parquet.dvc (quelques lignes)
git add data/raw/transactions.parquet.dvc .gitignore   # Git suit le POINTEUR
dvc remote add -d stockage s3://mon-bucket/dvc
dvc push                                # envoie les DONNÉES sur le stockage distant

# six mois plus tard, pour retrouver un état exact :
git checkout v1.2 && dvc checkout       # le code ET les données correspondantes

Pour les modèles, un registry (MLflow Model Registry, ou un simple bucket versionné avec convention de nommage) associe à chaque version : l'artefact, ses métriques de validation, le commit qui l'a produit, les données utilisées et un état (staging, production, archivé). C'est ce qui rend un retour arrière possible en quelques minutes — la capacité opérationnelle la plus précieuse quand un déploiement se passe mal.

4. Tracking d'expériences

Après deux semaines d'itérations, personne ne se souvient de la configuration qui a produit le meilleur score. Le pire scénario — un excellent résultat qu'on ne sait plus reproduire — disparaît pour quelques lignes de code.

import mlflow

mlflow.set_experiment("prevision-prix")

with mlflow.start_run(run_name="gbm-features-v3"):
    # ── ce qui DÉFINIT l'expérience ──
    mlflow.log_params({"max_depth": 6, "learning_rate": 0.05,
                       "n_features": X.shape[1], "n_train": len(X_train)})
    mlflow.log_param("git_sha", sha_courant())          # le code exact
    mlflow.log_param("data_version", "dvc:8f3a91c")     # les données exactes

    modele.fit(X_train, y_train)

    # ── ce qu'on en retient ──
    mlflow.log_metrics({"rmse_cv": rmse_cv, "rmse_test": rmse_test, "mae_test": mae_test})
    mlflow.log_metric("duree_entrainement_s", duree)
    mlflow.log_artifact("figures/residus.png")          # l'analyse d'erreurs
    mlflow.sklearn.log_model(modele, "modele", registered_model_name="prix-immo")

Ce qu'il faut consigner systématiquement : hyperparamètres, version du code et des données, métriques de validation et de test, durée et coût d'entraînement, et les quelques graphiques d'analyse d'erreurs. L'outil importe peu — MLflow en auto-hébergé, Weights & Biases en service — mais commencer dès le premier jour est essentiel : le tracking est impossible à reconstituer rétroactivement.

5. Packaging et servage

Batch      scoring périodique, résultats écrits en base. Le plus simple, le plus
           robuste, et SUFFISANT dans une large majorité des cas : personne n'a
           besoin d'un score de churn à la milliseconde.
Online     API synchrone (module 6). Contrainte de latence, mise à l'échelle,
           disponibilité. À ne choisir que si la fraîcheur l'exige vraiment.
Streaming  scoring sur flux (Kafka), pour la détection de fraude en temps réel.
Embarqué   ONNX, TFLite, CoreML : inférence sur l'appareil, sans réseau.

Quelques points techniques qui font gagner du temps. ONNX est un format d'échange neutre : on exporte le modèle une fois, on l'exécute partout (C++, Java, navigateur) sans dépendre de Python — utile à la fois pour la performance et pour la longévité, un modèle exporté restant lisible quand la version de scikit-learn qui l'a produit aura disparu. La quantification (module 22) divise taille et latence. Le cache de prédictions est trivial et souvent très rentable quand les mêmes entrées reviennent. Et toute réponse doit porter la version du modèle qui l'a produite.

6. Tester un système de ML

Aux tests logiciels classiques (module 1) s'ajoutent trois familles propres au ML :

• Tests de données — schéma, types, bornes, taux de valeurs manquantes, cardinalités, distributions attendues. Des outils comme Great Expectations ou pandera déclarent ces attentes et cassent le pipeline quand elles sont violées. C'est la protection la plus rentable de tout le dispositif : l'immense majorité des incidents de production vient des données, pas du modèle.
• Tests de modèle — performance minimale sur un jeu de référence figé, comportements attendus sur des cas connus (tests behavioral : invariance à une reformulation, monotonie « à surface égale, plus de pièces ne baisse pas le prix »), absence de régression par rapport à la version en production, équité entre sous-groupes (module 27).
• Tests d'intégration — la chaîne complète, de la donnée brute à la réponse de l'API, sur un mini-jeu versionné dans le dépôt.

import pandera.polars as pa

schema = pa.DataFrameSchema({
    "prix":        pa.Column(float, pa.Check.in_range(10_000, 5_000_000)),
    "surface":     pa.Column(float, pa.Check.in_range(8, 1000)),
    "code_postal": pa.Column(str,   pa.Check.str_matches(r"^\d{5}$")),
    "n_pieces":    pa.Column(int,   pa.Check.in_range(1, 20), nullable=True),
})

df_valide = schema.validate(df)          # lève une erreur DÉTAILLÉE si le contrat
                                         # n'est pas respecté — et arrête le pipeline
                                         # AVANT d'entraîner sur des données corrompues

À chaque commit        lint, types, tests unitaires, tests d'intégration rapides
Sur la branche main    entraînement complet, validation sur jeu figé,
                       COMPARAISON à la version en production
Si validation OK       enregistrement dans le registry en "staging"
Promotion              manuelle ou automatique selon le risque, puis déploiement
                       progressif (section 7)
Toujours               possibilité de revenir en arrière en une commande

7. Déploiement progressif

Un modèle validé hors ligne peut échouer en ligne — décalage de prétraitement, latence, distribution réelle différente. On ne bascule donc jamais 100 % du trafic d'un coup.

• Shadow — le nouveau modèle reçoit le trafic réel et ses prédictions sont enregistrées, mais non utilisées. Aucun risque, et l'on vérifie latence, taux d'erreur et cohérence sur les vraies données. C'est l'étape que l'on saute le plus souvent à tort, alors qu'elle coûte presque rien.
• Canary — 1 %, puis 5 %, puis 25 % du trafic, avec surveillance des métriques techniques et métier à chaque palier, et une règle d'arrêt définie à l'avance.
• A/B test — la seule façon de mesurer l'effet causal du nouveau modèle sur l'indicateur métier (module 9). Un meilleur RMSE hors ligne ne garantit en rien un meilleur résultat en ligne (module 23).
• Retour arrière — préparé, testé, exécutable en une commande. Si le retour arrière n'a jamais été essayé, il ne fonctionne pas : c'est une certitude empirique.

8. Monitoring et dérive

La performance d'un modèle se dégrade avec le temps : c'est la règle, pas l'exception. On distingue trois phénomènes, qui appellent des réponses différentes :

• Dérive des données (covariate shift) — la distribution des entrées \(P(X)\) change : nouvelle clientèle, capteur remplacé, changement d'interface qui modifie les saisies. Le modèle reste valide, mais il est utilisé hors de son domaine habituel.
• Dérive du concept — la relation \(P(Y\mid X)\) elle-même change : les comportements évoluent, une réglementation modifie les règles du jeu. Plus grave, car même un réentraînement ne rattrape le retard qu'après coup, une fois les nouvelles étiquettes disponibles.
• Dérive des étiquettes — la distribution de la cible change (le taux de fraude double).

Pour détecter une dérive sans attendre les étiquettes — qui arrivent souvent avec des semaines de retard —, on surveille les distributions d'entrée. L'indice de stabilité de population compare les proportions par intervalle entre référence et période courante :

import numpy as np

def psi(reference, courant, n_bins=10):
    # les bornes viennent de la RÉFÉRENCE : on mesure le déplacement par rapport à elle
    bornes = np.percentile(reference, np.linspace(0, 100, n_bins + 1))
    bornes[0], bornes[-1] = -np.inf, np.inf
    p = np.histogram(reference, bins=bornes)[0] / len(reference)
    q = np.histogram(courant,   bins=bornes)[0] / len(courant)
    p, q = np.clip(p, 1e-6, None), np.clip(q, 1e-6, None)   # éviter log(0)
    return float(np.sum((q - p) * np.log(q / p)))

# lecture usuelle :  < 0,1 stable | 0,1–0,25 à surveiller | > 0,25 dérive significative
for col in colonnes:
    v = psi(ref[col], prod[col])
    if v > 0.25:
        print(f"ALERTE dérive sur {col} : PSI = {v:.3f}")

On complète par un test de Kolmogorov-Smirnov pour les variables continues et un chi² pour les catégorielles (module 9) — en se rappelant que sur de gros volumes, ces tests détectent des écarts statistiquement significatifs mais opérationnellement négligeables. C'est l'ampleur qui doit déclencher l'alerte, pas la p-value.

1. Santé technique      latence (p50, p95, p99), taux d'erreur, disponibilité, coût
2. Qualité des entrées  taux de manquants, valeurs hors domaine, catégories inconnues
3. Distribution         PSI par variable, dérive des embeddings pour le non-tabulaire
4. Sorties du modèle    distribution des scores, taux de prédictions positives
5. Performance réelle   dès que les étiquettes arrivent : métriques PAR SEGMENT
6. Impact métier        LA mesure qui compte : conversion, coût évité, satisfaction

Les couches 1 à 4 sont disponibles immédiatement ; la 5 arrive en différé ; la 6 exige souvent une expérimentation. Un tableau de bord qui ne montre que la couche 1 donne une fausse impression de contrôle — un modèle peut répondre en 20 ms avec une disponibilité parfaite tout en étant devenu complètement faux.

9. Orchestration et ré-entraînement

Les pipelines (extraction, variables, entraînement, validation, déploiement) sont décrits comme des graphes de tâches et planifiés par un orchestrateur : Airflow (le standard historique, très répandu), Prefect ou Dagster (plus modernes, Dagster étant construit autour des actifs de données, ce qui correspond bien au ML), ou Kubeflow si l'on vit déjà dans Kubernetes (module 5).

Périodique         chaque semaine ou chaque mois. Simple, prévisible, souvent suffisant.
Sur déclenchement  quand le monitoring détecte une dérive au-delà d'un seuil (section 8)
Sur volume         quand N nouvelles observations ÉTIQUETÉES sont disponibles
En continu         apprentissage en ligne. Réservé aux cas qui l'exigent vraiment :
                   difficile à déboguer, très exposé aux boucles de rétroaction.

Un ré-entraînement automatique n'est acceptable qu'avec des garde-fous : validation sur un jeu figé, comparaison obligatoire avec le modèle en place, et refus automatique de promotion si la performance recule. Sans cela, un pipeline automatisé propage en production un modèle entraîné sur des données corrompues — plus vite et plus sûrement qu'un humain ne l'aurait fait.

10. Gouvernance et checklist

La model card documente, en une page : l'usage prévu et les usages exclus, les données d'entraînement et leurs biais connus, les performances globales et par sous-groupe, les limites, et le contact responsable. Ce n'est pas de la bureaucratie : c'est ce qui permet à quelqu'un d'autre — ou à soi-même dans un an — de savoir si le modèle peut être utilisé dans un contexte donné.

Le cadre réglementaire européen ajoute des obligations concrètes, détaillées au module 27 : le RGPD encadre les données personnelles et prévoit un droit à l'explication pour les décisions automatisées ; l'AI Act classe les systèmes par niveau de risque et impose documentation, traçabilité et supervision humaine pour les usages à haut risque. Ces exigences se traitent en amont — journalisation des prédictions, explicabilité, tests d'équité — bien plus facilement qu'après coup.

Un modèle qui décide engage une responsabilité : il peut désavantager systématiquement un groupe, se faire tromper par une entrée manipulée, ou laisser fuiter les données sur lesquelles il a été entraîné. Ces risques ne sont pas des questions de conformité à traiter à la fin : ils se traitent dans la conception, et ils ont chacun des méthodes et des métriques précises.

1. D'où viennent les biais

Un modèle appris reproduit les régularités de ses données d'entraînement — y compris celles qui traduisent des inégalités passées. Les sources, à distinguer parce qu'elles n'appellent pas les mêmes remèdes :

Biais historique        les données reflètent FIDÈLEMENT un monde inéquitable.
                        Un modèle statistiquement "correct" perpétue la situation.
                        Aucune technique statistique ne le corrige : c'est une
                        décision de conception, donc politique.
Biais d'échantillonnage certains groupes sont sous-représentés → variance élevée
                        et performance dégradée POUR EUX (module 14)
Biais de mesure         la variable cible est un PROXY imparfait : "a été arrêté"
                        pour "a commis une infraction", "a été promu" pour "était
                        compétent". Le proxy porte le biais du processus qui l'a produit.
Biais d'agrégation      un modèle unique pour des sous-populations aux relations
                        différentes : il devient optimal pour le groupe majoritaire
                        et médiocre pour les autres.
Biais de déploiement    le modèle est utilisé dans un contexte différent de celui
                        pour lequel il a été validé.

2. Définir l'équité — et leur incompatibilité

« Équitable » n'a pas de définition unique, et c'est le cœur du problème. Les trois familles les plus utilisées, pour un attribut sensible \(A\), une prédiction \(\hat Y\) et une vérité \(Y\) :

Parité démographique    "on sélectionne la même PROPORTION dans chaque groupe"
                        → ignore les différences réelles de qualification
Égalité des chances     "parmi les gens QUALIFIÉS, on en retient la même proportion
                        dans chaque groupe" → personne de méritant n'est désavantagé
Calibration par groupe  "un score de 0,7 signifie 70 % de chances, quel que soit
                        le groupe" → le score veut dire la même chose pour tous

3. Mesurer et atténuer

La première étape est toujours la même, et elle suffit souvent à découvrir un problème : ventiler toutes les métriques par sous-groupe. Une performance globale excellente masque régulièrement un groupe pour lequel le modèle est inutilisable.

from fairlearn.metrics import (MetricFrame, demographic_parity_difference,
                               equalized_odds_difference, selection_rate)
from sklearn.metrics import recall_score, precision_score, accuracy_score

mf = MetricFrame(
    metrics={"accuracy": accuracy_score, "rappel": recall_score,
             "précision": precision_score, "taux_selection": selection_rate},
    y_true=y_test, y_pred=y_pred, sensitive_features=A_test,
)
print(mf.by_group)                 # LE tableau à regarder en premier
print(mf.difference(method="between_groups"))   # l'écart max entre groupes

print(demographic_parity_difference(y_test, y_pred, sensitive_features=A_test))
print(equalized_odds_difference(y_test, y_pred, sensitive_features=A_test))

# et pour les sous-groupes CROISÉS, souvent les plus mal servis :
A_croise = A_test.astype(str) + "_" + age_groupe.astype(str)
print(MetricFrame(metrics=recall_score, y_true=y_test, y_pred=y_pred,
                  sensitive_features=A_croise).by_group)

Les leviers d'atténuation se classent par moment d'intervention : en amont (rééquilibrer l'échantillon, corriger les étiquettes, retirer des variables trop corrélées à l'attribut sensible), pendant (contrainte d'équité dans l'optimisation, réduction lagrangienne, apprentissage adversarial où un discriminateur tente de retrouver l'attribut à partir des représentations), en aval (seuils différenciés par groupe — techniquement très efficace, mais juridiquement délicat, car c'est une différence de traitement explicite).

Deux limites à garder en tête : ces méthodes supposent l'attribut sensible observé, ce qui est rarement le cas ; et corriger selon un attribut peut dégrader l'équité selon un autre, ou selon leur intersection — un modèle équitable « par genre » et « par âge » pris séparément peut être très inéquitable pour un sous-groupe croisé, d'où le calcul ci-dessus.

4. Robustesse et attaques par évasion

La robustesse recouvre deux choses distinctes : la résistance à une variation naturelle des données (dérive, changement de capteur, nouveau segment — module 26) et la résistance à une manipulation délibérée.

Les exemples adverses exploitent une propriété structurelle des modèles à haute dimension : il existe presque toujours une perturbation minuscule \(\delta\), imperceptible pour un humain, telle que la prédiction change complètement. On la trouve par ascension de gradient sur la perte, sous contrainte de norme :

L'intuition : la frontière de décision d'un réseau est proche de presque tous les points, parce qu'en dimension élevée le volume se concentre près des surfaces. Il suffit donc d'un petit déplacement dans la bonne direction — celle du gradient — pour la franchir.

Les défenses : l'entraînement adversarial (inclure ces exemples dans l'entraînement — efficace, mais coûteux et au prix d'un peu de précision nominale), la détection d'entrées anormales, et les méthodes certifiées (lissage aléatoire) qui donnent une garantie prouvée dans un rayon donné, au prix de performances modestes.

En contexte industriel, cela dit, la menace prioritaire n'est généralement pas l'attaque adverse au pixel près, mais le contournement de règles par des acteurs économiques — fraudeurs, spammeurs, optimiseurs de référencement — qui adaptent leur comportement dès qu'ils comprennent le critère. La parade est organisationnelle autant que technique : réentraîner fréquemment, ne pas publier les variables discriminantes, et privilégier des variables coûteuses à manipuler (un historique long plutôt qu'un champ déclaratif).

Enfin, les tests de stress sont l'outil le plus rentable : perturber systématiquement les entrées — bruit, valeurs manquantes, unités changées, catégories inconnues, valeurs extrêmes — et vérifier que le modèle se dégrade de façon progressive et détectable plutôt que de basculer silencieusement.

5. Empoisonnement et chaîne d'approvisionnement

• Empoisonnement des données — un attaquant injecte des exemples dans le corpus d'entraînement, soit pour dégrader la performance, soit pour installer une porte dérobée : le modèle se comporte normalement sauf en présence d'un déclencheur précis (un motif dans une image, une séquence dans un texte). Le risque est réel dès que les données d'entraînement proviennent d'utilisateurs, du web, ou de contributions externes. Défenses : validation et provenance des données (module 26), détection d'anomalies sur le corpus, entraînement robuste, réentraînement depuis des sources vérifiées.
• Vol et inversion de modèle — un accès à l'API permet d'interroger massivement le modèle pour en entraîner une copie (distillation non consentie), ou de reconstruire des informations sur ses données d'entraînement. L'inférence d'appartenance détermine si un individu précis figurait dans le corpus — une fuite de données personnelles à part entière. Limitation du débit, restriction de la granularité des scores renvoyés (arrondir plutôt que donner 15 décimales) et confidentialité différentielle atténuent ces risques.
• Chaîne d'approvisionnement logicielle — point concret et sous-estimé : un fichier de poids au format pickle exécute du code arbitraire à son chargement, par construction. Télécharger un modèle depuis un dépôt public revient donc à exécuter du code inconnu avec les droits de son processus. Préférer le format safetensors (qui ne contient que des tenseurs, sans code), vérifier les empreintes, épingler les versions de modèles et de dépendances (module 1), et scanner les images de conteneurs.

6. Confidentialité et fuite de données

L'anonymisation naïve ne fonctionne pas : la ré-identification par croisement est un résultat classique — quelques attributs quasi-identifiants (code postal, date de naissance, genre) suffisent à isoler une personne dans une population de millions d'individus. Le k-anonymat et ses raffinements (l-diversité, t-proximité) formalisent une protection en exigeant que chaque combinaison d'attributs soit partagée par au moins \(k\) personnes, mais restent vulnérables aux attaques par connaissance auxiliaire.

Un modèle entraîné mémorise aussi une partie de ses données : un réseau de grande capacité peut restituer textuellement des séquences rares de son corpus, ce qui a été démontré à plusieurs reprises sur les modèles de langage — numéros de téléphone, clés d'API, extraits de documents. La règle pratique à retenir : un modèle entraîné sur des données sensibles doit être traité comme une donnée sensible, avec les mêmes contrôles d'accès.

7. Confidentialité différentielle et fédéré

La confidentialité différentielle est la seule garantie formelle du domaine. Un mécanisme \(M\) est \((\varepsilon,\delta)\)-différentiellement privé si, pour deux jeux de données différant d'un seul individu :

Autrement dit : la présence ou l'absence d'une personne ne change quasiment pas la distribution des résultats, donc rien de spécifique à cette personne ne peut en être déduit — quelle que soit la connaissance annexe de l'attaquant, ce qui est la force du cadre. \(\varepsilon\) quantifie le budget de confidentialité : plus il est petit, plus la protection est forte et plus l'utilité diminue.

En apprentissage, DP-SGD applique le principe en deux temps : écrêter la norme du gradient de chaque exemple (pour borner l'influence d'un individu), puis ajouter un bruit gaussien calibré. Le coût est réel — perte de précision, entraînement plus lent, sensibilité accrue aux hyperparamètres — mais c'est la seule approche qui offre une garantie démontrable plutôt qu'une bonne intention. Deux propriétés la rendent utilisable : la composition (les budgets s'additionnent sur plusieurs requêtes, ce qui permet de raisonner sur un pipeline entier) et l'immunité au post-traitement (rien de ce qu'on fait ensuite ne dégrade la garantie).

L'apprentissage fédéré répond à un autre problème : entraîner sans centraliser les données. Chaque participant entraîne localement, seuls les gradients ou les poids sont envoyés et moyennés. Utile en santé, en industrie multi-sites, sur téléphone. Deux nuances importantes : les gradients fuient de l'information sur les données locales — des reconstructions d'images à partir de gradients ont été démontrées —, d'où la nécessité de combiner avec de l'agrégation sécurisée et de la confidentialité différentielle ; et l'hétérogénéité des données entre participants dégrade la convergence, ce qui reste un problème de recherche actif.

8. Risques propres aux LLM

• Injection de prompt (module 22) — le modèle ne distingue pas instructions et données. Le traitement est architectural : privilèges minimaux, validation des sorties, confirmation humaine pour les actions irréversibles.
• Fuite par le contexte — tout ce qui est envoyé dans un prompt quitte le périmètre ; et un index RAG mal cloisonné expose à un utilisateur des documents auxquels il n'a pas droit. Les droits d'accès doivent être appliqués au moment de la récupération — en filtrant l'index par les permissions de l'utilisateur — et non espérés du modèle, qui n'a aucun moyen de les faire respecter.
• Contenus préjudiciables et hallucinations — filtrage en entrée et en sortie, refus explicite prévu dans le prompt, et journalisation pour audit.
• Agents — un modèle capable d'agir (outils, code, achats) transforme une erreur de raisonnement en conséquence réelle. Le principe de moindre privilège et la validation humaine des actions irréversibles ne sont pas négociables.

9. Cadre réglementaire et checklist

Le RGPD encadre le traitement des données personnelles : base légale, minimisation, durée de conservation, droits d'accès et d'effacement, et — article 22 — encadrement des décisions entièrement automatisées produisant des effets significatifs, avec droit à une intervention humaine et à une explication.

L'AI Act européen classe les systèmes par risque : les usages à haut risque (crédit, emploi, éducation, infrastructures critiques, forces de l'ordre) imposent gestion des risques, qualité des données, documentation technique, journalisation, transparence, supervision humaine et robustesse. Ces exigences recoupent très largement les bonnes pratiques du module 26 — ce qui est une bonne nouvelle : les satisfaire ne demande pas un dispositif séparé, mais de faire correctement ce qu'on devrait faire de toute façon, et de le documenter.

Vingt-cinq modules de notions, et maintenant un projet complet où elles servent ensemble. L'objectif : partir d'annonces immobilières publiées sur le web, les collecter, les nettoyer, les stocker dans une base, entraîner un modèle de prédiction de prix, l'exposer derrière une API conteneurisée, et automatiser le tout avec une chaîne d'intégration continue. Rien d'exceptionnel techniquement — c'est précisément l'intérêt : c'est la forme qu'a réellement un projet de data science en entreprise.

1. Cadrage et architecture

La question, avant le code

Le module 12 insiste sur un point : commencer par la décision que le modèle doit éclairer. Ici, elle est simple — ce bien est-il affiché au-dessus ou en dessous de son prix de marché ? Cela fixe tout le reste :

• Cible : le prix affiché en euros. On modélisera en réalité son logarithme (voir section 6).
• Unité d'observation : une annonce à un instant donné.
• Métrique : l'erreur relative compte plus que l'erreur absolue — se tromper de 20 000 € sur un studio ou sur un hôtel particulier n'a pas le même sens. On retient la MAE sur le logarithme du prix, interprétable en pourcentage, complétée par la médiane de l'erreur absolue en pourcentage (module 8).
• Baseline : le prix médian au m² de la commune, multiplié par la surface. Tout modèle qui ne bat pas cela ne sert à rien.
• Contrainte : prédiction en moins de 100 ms, et une estimation de l'incertitude, puisqu'une fourchette est bien plus honnête qu'un nombre unique.

  ┌──────────────┐   JSONL brut   ┌──────────────┐   Parquet    ┌──────────────┐
  │   COLLECTE   │ ─────────────► │  NETTOYAGE   │ ───────────► │  INGESTION   │
  │ httpx async  │  (immuable)    │   polars     │  (validé)    │  PostgreSQL  │
  │  §3          │                │   §4         │              │   §5         │
  └──────────────┘                └──────────────┘              └──────┬───────┘
                                                                       │ SQL
                                                                       ▼
  ┌──────────────┐   image        ┌──────────────┐   pipeline   ┌──────────────┐
  │   CI/CD      │ ◄───────────── │  API FastAPI │ ◄─────────── │ ENTRAÎNEMENT │
  │ GitHub Act.  │   Docker       │   + Docker   │  .joblib     │  LightGBM    │
  │  §8          │                │   §7         │              │   §6         │
  └──────────────┘                └──────────────┘              └──────────────┘

immo-prix/
├── pyproject.toml
├── uv.lock
├── compose.yaml                 # API + PostgreSQL          (module 5)
├── Dockerfile
├── .dockerignore  .gitignore  .pre-commit-config.yaml
├── .github/workflows/ci.yml     # intégration continue      (module 26)
├── sql/
│   ├── 001_schema.sql           # tables, index, vues       (module 4)
│   └── 002_vues.sql
├── src/immo/
│   ├── config.py                # pydantic-settings         (module 6)
│   ├── schemas.py               # modèles Pydantic partagés
│   ├── scrape.py                # §3
│   ├── clean.py                 # §4
│   ├── ingest.py                # §5
│   ├── features.py              # §6
│   ├── train.py                 # §6
│   └── api.py                   # §7
├── tests/
└── data/                        # ignoré par Git
    ├── raw/                     # JSONL horodatés, jamais modifiés
    └── clean/                   # Parquet

2. Choisir une source de données (et le droit)

Le cadre juridique, en clair

Collecter automatiquement des pages web n'est pas neutre juridiquement, et c'est le premier sujet à traiter — pas le dernier.

• Les conditions générales d'utilisation du site s'imposent. La plupart des grands portails immobiliers interdisent explicitement l'extraction automatisée. Passer outre expose à des poursuites, et des décisions de justice françaises et européennes ont déjà sanctionné l'aspiration massive de bases d'annonces.
• Le droit des bases de données (directive européenne de 1996, transposée en France) protège le producteur d'une base contre l'extraction d'une « partie substantielle » de son contenu, même si les données individuelles ne sont pas protégées par le droit d'auteur.
• Le RGPD s'applique dès qu'une donnée permet d'identifier une personne : nom d'un vendeur particulier, numéro de téléphone, photo où l'on distingue quelqu'un. Un prix et une surface ne sont pas des données personnelles ; le contact d'un particulier l'est.
• robots.txt n'a pas de valeur contraignante en soi, mais il exprime la volonté de l'éditeur : l'ignorer affaiblit toute position défendable.
• La charge imposée au serveur peut constituer un trouble en elle-même. Un scraper qui envoie cent requêtes par seconde peut être assimilé à une attaque.

import httpx, polars as pl

def transactions_dvf(code_commune: str, annee: int) -> pl.DataFrame:
    """Transactions réelles issues de l'open data DVF (licence ouverte)."""
    r = httpx.get("https://api.cquest.org/dvf",
                  params={"code_commune": code_commune}, timeout=30)
    r.raise_for_status()
    return (
        pl.DataFrame(r.json()["resultats"])
          .filter(pl.col("date_mutation").str.starts_with(str(annee)))
          .select("date_mutation", "valeur_fonciere", "surface_relle_bati",
                  "nombre_pieces_principales", "type_local", "code_postal", "commune")
    )

3. Collecte : le scraper

Avant d'écrire la moindre requête

from urllib.robotparser import RobotFileParser
from urllib.parse import urljoin

AGENT = "immo-prix-bot/1.0 (+https://nils-malmberg.fr/project7-m28.html)"

def autorise(base_url: str, chemin: str) -> tuple[bool, float]:
    """Lit robots.txt : (le chemin est-il autorisé, délai demandé entre requêtes)."""
    rp = RobotFileParser()
    rp.set_url(urljoin(base_url, "/robots.txt"))
    rp.read()
    delai = rp.crawl_delay(AGENT) or 1.0        # délai demandé, 1 s par défaut
    return rp.can_fetch(AGENT, urljoin(base_url, chemin)), float(delai)

ok, delai = autorise("https://immo-exemple.fr", "/annonces/")
if not ok:
    raise SystemExit("robots.txt interdit cette section : on s'arrête ici.")

Le User-Agent déclaré mérite un commentaire : il est honnête, identifie le projet et donne un moyen de contact. Se faire passer pour un navigateur est techniquement possible et juridiquement indéfendable ; un administrateur qui voit passer un agent identifié peut demander l'arrêt plutôt que bannir en silence.

Récupérer les pages

C'est l'application directe du module 2 : des requêtes HTTP sont des opérations d'entrée/sortie, donc asyncio avec un sémaphore pour brider la charge, et une politique de reprise pour les erreurs passagères.

import asyncio, hashlib, random
from pathlib import Path
import httpx

CACHE = Path("data/cache")
CACHE.mkdir(parents=True, exist_ok=True)

async def recuperer(client: httpx.AsyncClient, url: str,
                    sem: asyncio.Semaphore, delai: float) -> str | None:
    """Renvoie le HTML d'une page, avec cache disque, reprise et politesse."""
    fichier = CACHE / (hashlib.sha256(url.encode()).hexdigest()[:16] + ".html")
    if fichier.exists():                       # cache : on ne redemande jamais deux fois
        return fichier.read_text(encoding="utf-8")

    async with sem:                            # au plus N requêtes simultanées
        for essai in range(4):
            try:
                r = await client.get(url, timeout=20, follow_redirects=True)
                if r.status_code == 429:       # trop de requêtes : on ralentit
                    await asyncio.sleep(float(r.headers.get("Retry-After", 30)))
                    continue
                r.raise_for_status()
                fichier.write_text(r.text, encoding="utf-8")
                # politesse : délai demandé + un peu d'aléa pour ne pas être régulier
                await asyncio.sleep(delai + random.uniform(0, 0.5))
                return r.text
            except (httpx.TimeoutException, httpx.HTTPStatusError) as e:
                if essai == 3:
                    print(f"abandon {url}: {e!r}")
                    return None
                await asyncio.sleep(2 ** essai)      # attente exponentielle : 1, 2, 4 s

Extraire les champs

Le HTML est transformé en données structurées par des sélecteurs CSS. J'utilise selectolax, nettement plus rapide que BeautifulSoup sur de gros volumes, avec une API très proche.

import re
from selectolax.parser import HTMLParser
from pydantic import BaseModel, Field, field_validator

class AnnonceBrute(BaseModel):
    """Ce qu'on extrait d'une page. Pydantic (module 6) fait la validation ici."""
    url: str
    titre: str
    prix_texte: str
    surface_texte: str | None = None
    pieces_texte: str | None = None
    ville: str
    code_postal: str = Field(pattern=r"^\d{5}$")
    description: str = ""
    collecte_le: str                        # horodatage ISO

    @field_validator("titre", "ville")
    @classmethod
    def non_vide(cls, v: str) -> str:
        v = v.strip()
        if not v:
            raise ValueError("champ vide")
        return v

def texte(noeud, selecteur: str, defaut: str = "") -> str:
    """Renvoie le texte d'un sélecteur, ou une valeur par défaut s'il est absent."""
    trouve = noeud.css_first(selecteur)
    return trouve.text(strip=True) if trouve else defaut

def extraire(html: str, url: str) -> AnnonceBrute | None:
    arbre = HTMLParser(html)
    try:
        return AnnonceBrute(
            url=url,
            titre=texte(arbre, "h1.annonce-titre"),
            prix_texte=texte(arbre, "[data-testid='prix']"),
            surface_texte=texte(arbre, "li.critere-surface") or None,
            pieces_texte=texte(arbre, "li.critere-pieces") or None,
            ville=texte(arbre, "span.localisation-ville"),
            code_postal=re.search(r"\b\d{5}\b", texte(arbre, "span.localisation")).group(),
            description=texte(arbre, "div.description"),
            collecte_le=datetime.now(timezone.utc).isoformat(),
        )
    except (ValidationError, AttributeError) as e:
        print(f"page ignorée {url}: {e}")     # structure inattendue → on saute, sans planter
        return None

Deux choix importants ici. D'abord, on extrait le texte brut (prix_texte = "249 500 €") sans le convertir : la conversion est une décision de nettoyage, qui appartient à l'étape suivante et doit pouvoir être corrigée sans recollecter. Ensuite, une page dont la structure a changé produit une erreur de validation attrapée localement : une annonce est perdue, pas l'exécution entière — un site modifie son HTML sans prévenir, et un scraper qui plante sur la première anomalie ne collecte jamais rien.

import json
from datetime import datetime, timezone

async def collecter(urls: list[str], sortie: Path, concurrence: int = 4) -> int:
    ok, delai = autorise("https://immo-exemple.fr", "/annonces/")
    if not ok:
        raise SystemExit("collecte non autorisée")

    sem = asyncio.Semaphore(concurrence)     # 4 requêtes simultanées, pas 400
    n = 0
    async with httpx.AsyncClient(headers={"User-Agent": AGENT}, http2=True) as client:
        # JSONL : une ligne = un objet JSON. Écriture au fil de l'eau, sans tout
        # garder en mémoire — le principe des générateurs du module 1.
        with sortie.open("w", encoding="utf-8") as f:
            taches = [recuperer(client, u, sem, delai) for u in urls]
            for future, url in zip(asyncio.as_completed(taches), urls):
                html = await future
                if html and (annonce := extraire(html, url)):
                    f.write(annonce.model_dump_json() + "\n")
                    n += 1
    return n

if __name__ == "__main__":
    horodatage = datetime.now(timezone.utc).strftime("%Y%m%dT%H%M%S")
    sortie = Path(f"data/raw/annonces_{horodatage}.jsonl")   # fichier HORODATÉ, immuable
    print(f"{asyncio.run(collecter(lire_urls(), sortie))} annonces écrites dans {sortie}")

Le format JSONL (un objet JSON par ligne) est celui qui convient à une collecte : on peut écrire au fil de l'eau, reprendre après interruption sans corrompre le fichier, et le relire en flux avec un générateur. Un unique gros tableau JSON obligerait à tout garder en mémoire et serait invalide si l'exécution s'arrêtait en cours de route.

4. Nettoyage et validation

Les données brutes sont hétérogènes : « 249 500 € », « 249500 EUR », « Nous consulter ». Le nettoyage transforme ce texte en valeurs exploitables et — tout aussi important — documente ce qu'il a jeté. C'est l'application du module 12.

import re
import polars as pl                       # module 3 : lazy, rapide, expressif

def nettoyer(chemin_jsonl: str) -> pl.DataFrame:
    brut = pl.read_ndjson(chemin_jsonl)

    return (
        brut
        # ── 1. extraction numérique depuis le texte ──
        .with_columns(
            prix=pl.col("prix_texte")
                   .str.replace_all(r"[^\d]", "")      # ne garder que les chiffres
                   .cast(pl.Float64, strict=False),    # "Nous consulter" → null
            surface=pl.col("surface_texte")
                      .str.extract(r"(\d+[,.]?\d*)")   # "72,5 m²" → "72,5"
                      .str.replace(",", ".")
                      .cast(pl.Float64, strict=False),
            n_pieces=pl.col("pieces_texte")
                       .str.extract(r"(\d+)")
                       .cast(pl.Int8, strict=False),
        )
        # ── 2. normalisation des chaînes ──
        .with_columns(
            ville=pl.col("ville").str.to_uppercase()
                    .str.replace_all(r"[-']", " ")
                    .str.replace_all(r"\s+", " ").str.strip_chars(),
            departement=pl.col("code_postal").str.slice(0, 2),
            collecte_le=pl.col("collecte_le").str.to_datetime(),
        )
        # ── 3. features dérivées utiles au contrôle qualité ──
        .with_columns(
            prix_m2=pl.col("prix") / pl.col("surface"),
            surface_par_piece=pl.col("surface") / pl.col("n_pieces"),
            a_ascenseur=pl.col("description").str.contains("(?i)ascenseur"),
            a_balcon=pl.col("description").str.contains("(?i)balcon|terrasse"),
        )
    )

def filtrer(df: pl.DataFrame) -> tuple[pl.DataFrame, dict]:
    """Renvoie les données retenues ET le compte de ce qui a été écarté."""
    n0 = len(df)
    rapport = {"initial": n0}

    # ── doublons ──
    df = df.unique(subset=["url"], keep="last")           # même annonce recollectée
    rapport["doublons_url"] = n0 - len(df); n1 = len(df)

    # quasi-doublons : même bien republié sous une autre URL
    df = df.unique(subset=["ville", "surface", "n_pieces", "prix"], keep="first")
    rapport["doublons_contenu"] = n1 - len(df); n2 = len(df)

    # ── valeurs manquantes sur les colonnes indispensables ──
    df = df.drop_nulls(["prix", "surface"])
    rapport["sans_prix_ou_surface"] = n2 - len(df); n3 = len(df)

    # ── aberrants : bornes MÉTIER, pas statistiques ──
    df = df.filter(
        (pl.col("surface").is_between(8, 1000))           # < 8 m² : impossible en France
        & (pl.col("prix").is_between(10_000, 5_000_000))
        & (pl.col("prix_m2").is_between(300, 25_000))     # hors de ces bornes = erreur
        & (pl.col("n_pieces").is_null() | pl.col("n_pieces").is_between(1, 20))
    )
    rapport["aberrants"] = n3 - len(df)
    rapport["retenu"] = len(df)
    rapport["taux_retenu"] = round(len(df) / n0, 3)
    return df, rapport

Dernière étape avant le stockage : une vérification de schéma qui échoue bruyamment si les données ne respectent pas le contrat attendu. C'est le test de données du module 26, et c'est la protection la plus rentable de tout le pipeline.

ATTENDU = {"prix": pl.Float64, "surface": pl.Float64, "n_pieces": pl.Int8,
           "ville": pl.String, "code_postal": pl.String, "collecte_le": pl.Datetime}

def verifier(df: pl.DataFrame) -> None:
    for colonne, dtype in ATTENDU.items():
        assert colonne in df.columns, f"colonne manquante : {colonne}"
        assert df[colonne].dtype == dtype, f"{colonne}: {df[colonne].dtype} ≠ {dtype}"
    assert df["prix"].min() > 0
    assert df["code_postal"].str.contains(r"^\d{5}$").all()
    assert df["prix"].null_count() == 0
    taux_manquants = df["n_pieces"].null_count() / len(df)
    assert taux_manquants < 0.30, f"trop de n_pieces manquants : {taux_manquants:.0%}"

df_propre, rapport = filtrer(nettoyer("data/raw/annonces_20260316T090000.jsonl"))
verifier(df_propre)
print(rapport)   # {'initial': 4820, 'doublons_url': 112, 'doublons_contenu': 340,
                 #  'sans_prix_ou_surface': 87, 'aberrants': 61,
                 #  'retenu': 4220, 'taux_retenu': 0.876}
df_propre.write_parquet("data/clean/annonces_20260316.parquet")

Le format Parquet remplace ici le CSV : il conserve les types (une date reste une date, un entier reste un entier), il se compresse cinq à dix fois mieux, et il se lit par colonnes — ce qui accélère toutes les lectures partielles (module 4).

5. Stockage en base de données

Pourquoi une base, puisqu'on a du Parquet

Le Parquet est parfait pour l'entraînement : un fichier, lu d'un coup, en colonnes. Il l'est beaucoup moins pour le reste : l'API doit chercher des biens comparables en quelques millisecondes, chaque collecte ajoute des lignes et met à jour des annonces existantes, et plusieurs processus y accèdent en même temps. Ce sont exactement les cas où une base s'impose (module 4). On garde donc les deux : PostgreSQL comme source de vérité, Parquet comme export figé pour l'entraînement.

CREATE TABLE IF NOT EXISTS annonces (
    annonce_id     BIGSERIAL PRIMARY KEY,
    url            TEXT        NOT NULL UNIQUE,   -- la clé métier : une URL = un bien
    titre          TEXT        NOT NULL,
    prix           NUMERIC(12,2) NOT NULL CHECK (prix > 0),
    surface        REAL        NOT NULL CHECK (surface BETWEEN 8 AND 1000),
    n_pieces       SMALLINT    CHECK (n_pieces BETWEEN 1 AND 20),
    ville          TEXT        NOT NULL,
    code_postal    CHAR(5)     NOT NULL CHECK (code_postal ~ '^\d{5}$'),
    departement    CHAR(2)     GENERATED ALWAYS AS (LEFT(code_postal, 2)) STORED,
    a_ascenseur    BOOLEAN     NOT NULL DEFAULT FALSE,
    a_balcon       BOOLEAN     NOT NULL DEFAULT FALSE,
    description    TEXT,
    collecte_le    TIMESTAMPTZ NOT NULL,
    maj_le         TIMESTAMPTZ NOT NULL DEFAULT now(),
    prix_m2        NUMERIC(10,2) GENERATED ALWAYS AS (prix / surface) STORED
);

-- index : jointures et filtres les plus fréquents (module 4)
CREATE INDEX IF NOT EXISTS idx_annonces_cp     ON annonces(code_postal);
CREATE INDEX IF NOT EXISTS idx_annonces_date   ON annonces(collecte_le DESC);
CREATE INDEX IF NOT EXISTS idx_annonces_comp   ON annonces(code_postal, surface);

-- historique des prix : une annonce republiée moins cher est un signal fort
CREATE TABLE IF NOT EXISTS historique_prix (
    annonce_id  BIGINT      NOT NULL REFERENCES annonces(annonce_id) ON DELETE CASCADE,
    prix        NUMERIC(12,2) NOT NULL,
    constate_le TIMESTAMPTZ NOT NULL DEFAULT now(),
    PRIMARY KEY (annonce_id, constate_le)
);

-- suivi des exécutions : indispensable pour le monitoring (module 26)
CREATE TABLE IF NOT EXISTS executions (
    execution_id  BIGSERIAL PRIMARY KEY,
    lance_le      TIMESTAMPTZ NOT NULL DEFAULT now(),
    fichier_source TEXT,
    n_collectees  INTEGER,
    n_retenues    INTEGER,
    taux_retenu   REAL,
    rapport       JSONB                  -- le dict de la section 4, tel quel
);

Trois choses méritent d'être remarquées. Les colonnes GENERATED ALWAYS AS … STORED sont calculées par la base : il est impossible d'avoir un prix_m2 incohérent avec le prix et la surface, alors qu'une colonne recopiée par le script aurait dérivé tôt ou tard. Les contraintes CHECK dupliquent volontairement les règles du nettoyage : c'est une seconde barrière, active quel que soit le programme qui écrit. Et la colonne JSONB permet de stocker le rapport de qualité sans figer son schéma — le bon usage du JSON dans une base relationnelle.

L'ingestion : idempotente

Une exécution peut échouer au milieu, être relancée, ou traiter un fichier déjà traité. Le script d'ingestion doit donc être idempotent : le relancer deux fois sur les mêmes données donne exactement le même résultat qu'une seule fois. C'est ce que garantit l'instruction INSERT … ON CONFLICT (un « upsert »).

import json
import polars as pl
from sqlalchemy import create_engine, text
from immo.config import parametres          # pydantic-settings (module 6)

moteur = create_engine(parametres.database_url, pool_pre_ping=True)

UPSERT = text("""
    INSERT INTO annonces (url, titre, prix, surface, n_pieces, ville, code_postal,
                          a_ascenseur, a_balcon, description, collecte_le)
    VALUES (:url, :titre, :prix, :surface, :n_pieces, :ville, :code_postal,
            :a_ascenseur, :a_balcon, :description, :collecte_le)
    ON CONFLICT (url) DO UPDATE SET          -- l'annonce existe déjà : on met à jour
        prix   = EXCLUDED.prix,
        maj_le = now()
    RETURNING annonce_id, (xmax = 0) AS insertion    -- xmax = 0 → c'était un INSERT
""")

def ingerer(chemin_parquet: str, rapport: dict) -> dict:
    df = pl.read_parquet(chemin_parquet)
    lignes = df.to_dicts()

    with moteur.begin() as con:              # TRANSACTION : tout ou rien (module 4)
        n_nouvelles = 0
        for lot in (lignes[i:i + 500] for i in range(0, len(lignes), 500)):
            for ligne in lot:
                res = con.execute(UPSERT, ligne).one()
                n_nouvelles += int(res.insertion)
                # on garde la trace du prix à chaque passage
                con.execute(text("""INSERT INTO historique_prix (annonce_id, prix)
                                    VALUES (:id, :prix)
                                    ON CONFLICT DO NOTHING"""),
                            {"id": res.annonce_id, "prix": ligne["prix"]})

        con.execute(text("""INSERT INTO executions
                            (fichier_source, n_collectees, n_retenues, taux_retenu, rapport)
                            VALUES (:f, :c, :r, :t, CAST(:j AS jsonb))"""),
                    {"f": chemin_parquet, "c": rapport["initial"], "r": rapport["retenu"],
                     "t": rapport["taux_retenu"], "j": json.dumps(rapport)})

    return {"nouvelles": n_nouvelles, "mises_a_jour": len(lignes) - n_nouvelles}

-- prix médian au m² par commune : c'est la BASELINE du modèle (section 1)
CREATE OR REPLACE VIEW v_reference_commune AS
SELECT code_postal,
       COUNT(*)                                             AS n_annonces,
       PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY prix_m2) AS prix_m2_median,
       PERCENTILE_CONT(0.1) WITHIN GROUP (ORDER BY prix_m2) AS prix_m2_p10,
       PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY prix_m2) AS prix_m2_p90
FROM annonces
WHERE collecte_le > now() - INTERVAL '90 days'
GROUP BY code_postal
HAVING COUNT(*) >= 20;            -- pas de référence sur 3 annonces

-- baisses de prix : fonction de fenêtre (module 4)
CREATE OR REPLACE VIEW v_baisses AS
SELECT a.url, a.ville, h.prix AS prix_actuel,
       FIRST_VALUE(h.prix) OVER (PARTITION BY h.annonce_id
                                 ORDER BY h.constate_le) AS prix_initial,
       h.prix / FIRST_VALUE(h.prix) OVER (PARTITION BY h.annonce_id
                                          ORDER BY h.constate_le) - 1 AS variation
FROM historique_prix h JOIN annonces a USING (annonce_id);

6. Modélisation et évaluation

Les features

import numpy as np, polars as pl

def construire_features(df: pl.DataFrame, reference: pl.DataFrame) -> pl.DataFrame:
    """reference = la vue v_reference_commune, calculée sur le passé uniquement."""
    return (
        df.join(reference, on="code_postal", how="left")
          .with_columns(
              # la variable la plus prédictive : le niveau de prix local
              prix_m2_median=pl.col("prix_m2_median").fill_null(
                  pl.col("prix_m2_median").median()),          # commune inconnue
              # non-linéarités simples, utiles aux modèles linéaires (module 14)
              log_surface=pl.col("surface").log(),
              surface_par_piece=pl.col("surface") / pl.col("n_pieces").fill_null(2),
              # indicateur de manquant : le FAIT de manquer est informatif (module 12)
              pieces_manquant=pl.col("n_pieces").is_null().cast(pl.Int8),
              n_pieces=pl.col("n_pieces").fill_null(-1),       # sentinelle pour les arbres
              # saisonnalité : le marché n'est pas le même en août (module 17)
              mois=pl.col("collecte_le").dt.month(),
              mois_sin=(2 * np.pi * pl.col("collecte_le").dt.month() / 12).sin(),
              mois_cos=(2 * np.pi * pl.col("collecte_le").dt.month() / 12).cos(),
          )
    )

COLONNES = ["surface", "log_surface", "n_pieces", "pieces_manquant",
            "surface_par_piece", "prix_m2_median", "a_ascenseur", "a_balcon",
            "mois_sin", "mois_cos", "departement"]

Entraînement

import joblib, numpy as np, polars as pl, mlflow
from lightgbm import LGBMRegressor, early_stopping
from sklearn.compose import ColumnTransformer
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import OrdinalEncoder
from sklearn.metrics import mean_absolute_error

VERSION = "1.0.0"

def preparer(df: pl.DataFrame, date_coupure: str):
    train = df.filter(pl.col("collecte_le") <  pl.lit(date_coupure).str.to_datetime())
    test  = df.filter(pl.col("collecte_le") >= pl.lit(date_coupure).str.to_datetime())
    # cible : le LOGARITHME du prix. L'erreur devient relative, et la distribution
    # fortement asymétrique des prix (module 10) devient à peu près symétrique.
    return (train[COLONNES].to_pandas(), np.log(train["prix"].to_numpy()),
            test[COLONNES].to_pandas(),  np.log(test["prix"].to_numpy()))

def entrainer(X_tr, y_tr, X_te, y_te):
    pre = ColumnTransformer(
        [("cat", OrdinalEncoder(handle_unknown="use_encoded_value", unknown_value=-1),
          ["departement"])],
        remainder="passthrough",
    )
    modele = Pipeline([                       # pipeline COMPLET : protège des fuites
        ("pre", pre),
        ("gbm", LGBMRegressor(n_estimators=3000, learning_rate=0.03, num_leaves=31,
                              min_child_samples=30, subsample=0.8, colsample_bytree=0.8,
                              random_state=42)),
    ])
    modele.fit(X_tr, y_tr,
               gbm__eval_set=[(pre.fit(X_tr).transform(X_te), y_te)],
               gbm__callbacks=[early_stopping(100, verbose=False)])
    return modele

def evaluer(modele, X_te, y_te, baseline_m2, surfaces) -> dict:
    pred_log = modele.predict(X_te)
    prix_reel, prix_pred = np.exp(y_te), np.exp(pred_log)

    return {
        "mae_log":   mean_absolute_error(y_te, pred_log),        # ≈ erreur relative
        "mape_med":  float(np.median(np.abs(prix_pred / prix_reel - 1))),
        "dans_10pct": float(np.mean(np.abs(prix_pred / prix_reel - 1) < 0.10)),
        # LA comparaison qui compte : bat-on la baseline ? (module 12)
        "mape_med_baseline": float(np.median(np.abs(baseline_m2 * surfaces / prix_reel - 1))),
    }

baseline (prix médian au m² × surface)   erreur médiane : 18,4 %
LightGBM                                 erreur médiane :  9,1 %   ← division par deux
                                         62 % des biens estimés à ±10 %
                                         MAE sur log(prix) : 0,118

Deux compléments valent le détour. SHAP (module 14) explique une estimation individuelle : « ce bien est estimé 18 000 € au-dessus de la moyenne du quartier parce qu'il est grand et a un ascenseur » — c'est ce qui rend l'outil utilisable par un humain, bien plus qu'un nombre seul. Et un intervalle de prédiction vaut mieux qu'un point : on peut entraîner deux modèles quantiles supplémentaires (objective="quantile", alpha=0.1 et 0.9), ou conformaliser le modèle existant pour obtenir une couverture garantie (module 10) :

# jeu de calibration disjoint de l'entraînement
scores = np.abs(y_calib - modele.predict(X_calib))
n, alpha = len(scores), 0.1
q = np.quantile(scores, np.ceil((n + 1) * (1 - alpha)) / n, method="higher")
# en log : un écart constant devient un FACTEUR multiplicatif sur le prix
print(f"intervalle à 90 % : ×{np.exp(-q):.2f} à ×{np.exp(q):.2f}")   # ×0,82 à ×1,22

mlflow.set_experiment("immo-prix")
with mlflow.start_run(run_name=f"lgbm-{VERSION}"):
    mlflow.log_params({"n_estimators": 3000, "learning_rate": 0.03,
                       "date_coupure": DATE_COUPURE, "n_train": len(X_tr)})
    mlflow.log_param("git_sha", sha_courant())
    mlflow.log_metrics(metriques)
    mlflow.sklearn.log_model(modele, "modele", registered_model_name="immo-prix")

joblib.dump({"pipeline": modele, "version": VERSION, "colonnes": COLONNES,
             "q_conforme": q, "entraine_le": datetime.now(timezone.utc).isoformat()},
            f"models/immo-{VERSION}.joblib")     # le pipeline ENTIER, pas l'estimateur seul

7. API et conteneurisation

from contextlib import asynccontextmanager
import anyio, joblib, numpy as np, pandas as pd
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field
from sqlalchemy import create_engine, text

etat: dict = {}

@asynccontextmanager
async def lifespan(app: FastAPI):
    artefact = joblib.load("models/immo-1.0.0.joblib")     # chargé UNE fois (module 6)
    etat.update(artefact)
    etat["moteur"] = create_engine(parametres.database_url, pool_pre_ping=True)
    yield
    etat.clear()

app = FastAPI(title="Estimation de prix immobilier", version="1.0.0", lifespan=lifespan)

class Bien(BaseModel):
    surface: float = Field(gt=8, le=1000, description="surface habitable en m²")
    n_pieces: int | None = Field(default=None, ge=1, le=20)
    code_postal: str = Field(pattern=r"^\d{5}$")
    a_ascenseur: bool = False
    a_balcon: bool = False

class Estimation(BaseModel):
    prix_estime: float
    prix_bas: float
    prix_haut: float
    prix_m2_estime: float
    reference_locale_m2: float | None
    n_comparables: int
    version_modele: str

@app.get("/health")
def health() -> dict:
    return {"status": "ok", "modele": etat.get("version")}

@app.post("/estimer", response_model=Estimation)
async def estimer(bien: Bien) -> Estimation:
    # référence locale : une requête SQL indexée, quelques millisecondes (module 4)
    with etat["moteur"].connect() as con:
        ref = con.execute(text("""SELECT prix_m2_median, n_annonces
                                  FROM v_reference_commune WHERE code_postal = :cp"""),
                          {"cp": bien.code_postal}).one_or_none()
    if ref is None:
        raise HTTPException(404, "commune sans référence : pas assez d'annonces")

    X = construire_ligne(bien, prix_m2_median=float(ref.prix_m2_median))
    log_prix = await anyio.to_thread.run_sync(etat["pipeline"].predict, X)   # module 2

    prix = float(np.exp(log_prix[0]))
    q = etat["q_conforme"]
    return Estimation(
        prix_estime=round(prix, -2),
        prix_bas=round(prix * float(np.exp(-q)), -2),
        prix_haut=round(prix * float(np.exp(q)), -2),
        prix_m2_estime=round(prix / bien.surface, 1),
        reference_locale_m2=float(ref.prix_m2_median),
        n_comparables=int(ref.n_annonces),
        version_modele=etat["version"],
    )

services:
  api:
    build: .
    ports: ["8000:8000"]
    environment:
      DATABASE_URL: postgresql+psycopg://immo:${POSTGRES_PASSWORD}@base:5432/immo
    volumes:
      - ./models:/app/models:ro          # le modèle, monté en lecture seule
    depends_on:
      base: { condition: service_healthy }
    restart: unless-stopped

  base:
    image: postgres:16
    environment:
      POSTGRES_USER: immo
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: immo
    volumes:
      - donnees-pg:/var/lib/postgresql/data
      - ./sql:/docker-entrypoint-initdb.d:ro     # schéma appliqué au 1er démarrage
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U immo"]
      interval: 5s
      retries: 10

volumes:
  donnees-pg:

docker compose up -d --build
curl -X POST localhost:8000/estimer -H "Content-Type: application/json" \
     -d '{"surface": 72.5, "n_pieces": 3, "code_postal": "38000", "a_ascenseur": true}'
# {"prix_estime":248300.0,"prix_bas":203600.0,"prix_haut":302900.0,
#  "prix_m2_estime":3425.5,"reference_locale_m2":3180.0,"n_comparables":412,
#  "version_modele":"1.0.0"}

8. CI/CD avec GitHub Actions

Ce qu'on automatise, et pourquoi

Trois automatisations distinctes, à ne pas confondre : la vérification du code à chaque modification (intégration continue), la publication d'une image lorsqu'une version est prête (livraison continue), et l'exécution planifiée de la collecte. GitHub Actions couvre les trois. Le vocabulaire : un workflow est un fichier YAML déclenché par un événement ; il contient des jobs qui tournent chacun sur une machine neuve ; un job enchaîne des steps.

name: CI

on:                                   # QUAND ce workflow se déclenche
  push:
    branches: [main]
  pull_request:                       # sur chaque proposition de modification

jobs:
  qualite:
    runs-on: ubuntu-latest
    services:                         # PostgreSQL éphémère pour les tests d'intégration
      postgres:
        image: postgres:16
        env:
          POSTGRES_USER: immo
          POSTGRES_PASSWORD: test
          POSTGRES_DB: immo_test
        ports: ["5432:5432"]
        options: >-
          --health-cmd pg_isready --health-interval 5s --health-retries 10

    steps:
      - uses: actions/checkout@v4                   # récupère le code

      - name: Installer uv                          # module 1
        uses: astral-sh/setup-uv@v3
        with:
          enable-cache: true                        # cache des dépendances entre exécutions

      - name: Installer les dépendances
        run: uv sync --frozen                       # --frozen : échoue si uv.lock a dérivé

      - name: Lint et formatage
        run: |
          uv run ruff check .
          uv run ruff format --check .

      - name: Types
        run: uv run mypy src/

      - name: Tests
        env:
          DATABASE_URL: postgresql+psycopg://immo:test@localhost:5432/immo_test
        run: uv run pytest -q --cov=src --cov-report=term-missing

      - name: Vérifier que le schéma SQL s'applique
        env:
          PGPASSWORD: test
        run: psql -h localhost -U immo -d immo_test -f sql/001_schema.sql

  image:
    needs: qualite                                  # ne démarre que si la qualité passe
    if: github.ref == 'refs/heads/main'             # uniquement sur main
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write                               # droit de publier l'image
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}     # fourni automatiquement
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: |
            ghcr.io/${{ github.repository }}:latest
            ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha                      # cache des couches Docker
          cache-to: type=gha,mode=max

name: Collecte quotidienne

on:
  schedule:
    - cron: "17 4 * * *"          # tous les jours à 4 h 17 UTC (heure creuse)
  workflow_dispatch:              # et déclenchable à la main depuis l'interface

jobs:
  collecter:
    runs-on: ubuntu-latest
    timeout-minutes: 45           # garde-fou : un scraper bloqué ne tourne pas 6 h
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v3
      - run: uv sync --frozen

      - name: Collecte, nettoyage, ingestion
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}    # SECRET, jamais dans le code
        run: |
          uv run python -m immo.scrape
          uv run python -m immo.clean
          uv run python -m immo.ingest

      - name: Contrôle qualité              # échoue si le taux retenu s'effondre
        run: uv run python -m immo.checks --seuil-taux-retenu 0.75

      - name: Alerter en cas d'échec
        if: failure()
        run: echo "::error::La collecte a échoué — vérifier la structure du site"

9. Ce qui resterait à faire

Le pipeline tourne, mais un projet réel ne s'arrête pas là. Par ordre de priorité :

• Surveillance de la dérive (module 26) — comparer chaque mois la distribution des surfaces, des prix au m² et des communes à celle du jeu d'entraînement (indice PSI), et déclencher un ré-entraînement au-delà d'un seuil. Le marché immobilier dérive lentement mais sûrement.
• Suivi de la performance réelle — les prix affichés ne sont pas les prix de vente. Rapprocher les annonces des transactions DVF publiées quelques mois plus tard permettrait de mesurer l'erreur vraie, et non l'erreur sur le prix demandé.
• Enrichissement géographique — géocoder les adresses, ajouter la distance au centre, aux transports, aux écoles ; ces variables expliquent une grande part du résidu. Les données de l'IGN et de l'INSEE sont ouvertes.
• Texte des annonces (module 18) — « refait à neuf », « travaux à prévoir », « vue dégagée » portent une information réelle, qu'un TF-IDF ou un embedding capterait.
• Découpage par groupe (module 12) — une même annonce republiée sous plusieurs URL peut se retrouver des deux côtés du découpage ; grouper par bien (surface, pièces, localisation) fiabiliserait l'évaluation.
• Interface (module 6) — une page Jinja avec un formulaire et la décomposition SHAP rendrait l'outil utilisable sans passer par curl.

Module  Notion                              Où, dans ce projet
──────────────────────────────────────────────────────────────────────────────
1       src layout, UV, dataclass,          structure du projet, config, écriture
        générateurs, pre-commit             JSONL au fil de l'eau, hooks
2       asyncio, sémaphore, reprise         le scraper (§3)
3       polars, lazy, Parquet               le nettoyage (§4)
4       schéma, contraintes, index,         la base (§5), la vue de référence,
        upsert, fenêtres, transactions      l'historique des prix
5       Dockerfile, Compose, volumes        la pile de développement (§7)
6       Pydantic, FastAPI, lifespan         extraction typée (§3), API (§7)
7       métriques, log-cible                choix de la MAE sur log, évaluation (§6)
9       prédiction conforme                 l'intervalle d'estimation (§6)
10      fuite de données, baseline,         split temporel, référence calculée sur
        manquants, feature engineering      le train seul, indicateurs de manquant
12      gradient boosting, SHAP             le modèle et son explication (§6)
15      saisonnalité                        features cycliques mois_sin/mois_cos
16      texte des annonces                  piste d'amélioration (§9)
24      MLflow, CI/CD, tests de données,    journalisation, GitHub Actions (§8),
        monitoring                          contrôle qualité, dérive (§9)
25      RGPD, CGU, droit des bases          le cadre juridique de la collecte (§2)

Le cours introduit environ deux cents termes, chacun à l'endroit où il devient utile. Cette annexe les rassemble : une définition courte, et le module où la notion est développée. Elle sert à deux choses — retrouver une définition croisée trois modules plus loin, et vérifier avant d'attaquer un module qu'on possède bien le vocabulaire qu'il suppose.

Conventions de notation

Le cours suit les conventions usuelles de la littérature statistique et du machine learning. Elles ne sont pas universelles — un article peut noter les vecteurs en gras, un autre non — mais elles sont cohérentes d'un bout à l'autre de ces pages.

DONNÉES
  n            nombre d'observations (lignes)
  p, d         nombre de variables (colonnes), dimension
  X            matrice des variables explicatives, n lignes × p colonnes
  x_i          l'observation i (un vecteur de taille p)
  y            vecteur des valeurs à prédire ;  y_i  une valeur
  ŷ            valeur prédite (le « chapeau » = estimé, pas observé)
  T            indicateur de traitement 0/1 (module 11)

MODÈLE ET APPRENTISSAGE
  θ, w, β      paramètres du modèle (θ en général, w ou β en linéaire)
  θ̂            estimateur de θ à partir de l'échantillon
  f(x; θ)      prédiction du modèle de paramètres θ
  L, ℓ         fonction de perte (L totale, ℓ sur un exemple)
  R(θ)         risque = perte espérée sur la vraie distribution
  R̂(θ)         risque empirique = perte moyenne sur l'échantillon
  η, α         taux d'apprentissage
  λ            force de régularisation
  ∇            gradient ;  ∇_θ L  = gradient de L par rapport à θ

PROBABILITÉS
  P(A)         probabilité de A
  p(x)         densité de probabilité
  E[X]         espérance ;  Var(X)  variance ;  Cov(X,Y)  covariance
  X ~ N(μ, σ²) X suit une loi normale de moyenne μ et variance σ²
  X ⊥⊥ Y | Z   X et Y sont indépendants conditionnellement à Z
  do(X = x)    intervention : on FORCE X à x (module 11)
  ∝            proportionnel à (la constante de normalisation est omise)

ALGÈBRE ET ANALYSE
  ‖v‖₂         norme euclidienne ;  ‖v‖₁  somme des valeurs absolues
  Aᵀ           transposée ;  A⁻¹  inverse ;  tr(A)  trace
  ⟨u, v⟩       produit scalaire
  argmin f     la valeur qui MINIMISE f (pas le minimum lui-même)
  O(n²)        ordre de grandeur du coût quand n grandit

A – C

• A/B test — expérience où les unités sont affectées au hasard à deux variantes, ce qui rend les groupes comparables et autorise une conclusion causale (module 9).
• ACF, PACF — autocorrélogramme et sa version partielle : les deux graphiques qui révèlent la structure temporelle d'une série et guident le choix d'un modèle ARIMA (module 17).
• Adam — algorithme d'optimisation qui adapte un taux d'apprentissage par paramètre à partir des moments du gradient. Le défaut raisonnable en deep learning (module 8).
• Aléatoire (incertitude) — incertitude irréductible, due au bruit intrinsèque du phénomène. S'oppose à l'incertitude épistémique, qui se réduit avec plus de données (module 10).
• Apprentissage actif — stratégie qui choisit les exemples à faire annoter, plutôt que d'annoter au hasard, pour maximiser le gain par étiquette (module 13).
• Apprentissage auto-supervisé — fabriquer la supervision à partir des données elles-mêmes (masquer un mot, prédire la suite), pour apprendre des représentations sans étiquettes (module 13).
• Arrow — format de représentation d'un tableau colonne en mémoire, partagé entre outils, qui permet de s'échanger des données sans copie. À distinguer de Parquet, qui est un format de disque (module 7).
• ARIMA — modèle classique de série temporelle combinant auto-régression, différenciation et moyenne mobile (module 17).
• ATE, ATT, CATE, LATE — effets moyens d'un traitement : sur toute la population, sur les traités seulement, conditionnellement à un profil, ou sur le sous-groupe qu'un instrument a fait changer de comportement (module 11).
• Attention — mécanisme par lequel chaque élément d'une séquence pondère tous les autres selon leur pertinence. Le cœur du Transformer (module 16).
• AUC / ROC — aire sous la courbe taux de vrais positifs contre taux de faux positifs : la probabilité qu'un positif tiré au hasard reçoive un score supérieur à un négatif (module 8).
• Autoencodeur — réseau qui apprend à reconstruire son entrée à travers un goulot d'étranglement, et dont la couche centrale fournit une représentation compressée (module 16).
• Backfill — rejouer un traitement sur une période passée, par exemple après correction d'un bug. Possible seulement si les tâches sont paramétrées par la date et idempotentes (module 7).
• Bagging — entraîner plusieurs modèles sur des rééchantillonnages des données et moyenner leurs prédictions, pour réduire la variance (module 14).
• Bandit (contextuel) — cadre où l'on choisit une action et n'observe que sa conséquence, ce qui impose d'arbitrer entre explorer et exploiter en continu (module 24).
• Biais (statistique) — écart systématique entre l'espérance d'un estimateur et la vraie valeur. Différent du biais au sens de l'équité (module 27).
• Biais-variance — décomposition de l'erreur d'un modèle en erreur systématique et instabilité. Le cadre qui explique sur- et sous-apprentissage (module 14).
• BF16 — format flottant sur 16 bits conservant la plage d'exposant de FP32 au prix de la précision. Le défaut actuel pour l'entraînement en précision mixte (module 25).
• Boosting — construire des modèles successifs, chacun corrigeant les erreurs des précédents. XGBoost, LightGBM, CatBoost (module 14).
• Bootstrap — rééchantillonner avec remise pour estimer la variabilité d'une statistique sans hypothèse de loi (module 9).
• Broadcasting — règle NumPy qui aligne automatiquement des tableaux de formes différentes lors d'une opération, sans copie explicite (module 3).
• Calibration — propriété d'un modèle dont les probabilités prédites correspondent aux fréquences observées : parmi les cas annoncés à 70 %, environ 70 % se réalisent (module 10).
• Censure — situation où l'on sait qu'un événement n'est pas encore survenu au moment de l'observation, sans connaître sa date future. Le problème central de l'analyse de survie (module 17).
• Clustering — regrouper des observations semblables sans étiquettes : k-moyennes, DBSCAN, mélanges gaussiens (module 14).
• CNN — réseau convolutif, qui exploite la localité et la translation-invariance des images en partageant les mêmes filtres partout (module 16).
• Collisionneur — variable influencée par deux autres. Conditionner dessus crée une corrélation artificielle entre ses causes : la source de biais la plus contre-intuitive (module 9).
• Confondant — variable qui influence à la fois le traitement et le résultat, et qui fabrique une association sans lien causal (module 9).
• Conteneur — unité d'exécution isolée qui partage le noyau de l'hôte, contrairement à une machine virtuelle qui embarque son propre système (module 5).
• Contrat de données — spécification vérifiée automatiquement de ce qu'une table doit contenir : colonnes, types, plages, unicité. Placé à la frontière du système (module 7).
• Cross-fitting — prédire chaque observation avec un modèle entraîné sans elle, pour éliminer le biais de surapprentissage dans une estimation causale (module 11).
• CTE — clause WITH de SQL, qui nomme un résultat intermédiaire et rend une requête complexe lisible (module 4).
• CUPED — technique qui retranche d'une métrique d'expérience la part prédictible par une mesure antérieure, réduisant la variance sans introduire de biais (module 11).

D – I

• DAG — graphe orienté sans cycle. Désigne soit un graphe causal (module 11), soit un graphe de tâches d'orchestration (module 7), soit le graphe de calcul d'un moteur paresseux (module 3).
• Dask — bibliothèque qui découpe un calcul pandas ou NumPy en morceaux traités hors mémoire ou en parallèle (module 3).
• dbt — outil qui traite les transformations SQL comme du code : dépendances déduites, tests, documentation, versionnement (module 7).
• Décorateur — fonction qui prend une fonction et en renvoie une version modifiée. La syntaxe @nom n'est qu'un raccourci de réaffectation (module 1).
• Dérive — évolution dans le temps de la distribution des données (dérive de covariables) ou de la relation apprise (dérive de concept). La première cause de dégradation silencieuse d'un modèle (module 26).
• Descente de gradient — se déplacer pas à pas dans la direction opposée au gradient de la fonction de perte. Le mécanisme d'apprentissage de presque tous les modèles paramétriques (module 8).
• Différences de différences — comparer l'évolution avant/après d'un groupe traité à celle d'un groupe témoin, pour éliminer à la fois les différences de niveau et la tendance commune (module 11).
• Dimension VC — mesure de la capacité d'une famille de modèles : le plus grand nombre de points qu'elle peut séparer de toutes les façons possibles (module 15).
• Double descente — phénomène où l'erreur de test remonte puis redescend quand la capacité du modèle dépasse le nombre d'observations, contredisant la courbe en U classique (module 15).
• Double machine learning — estimer un effet causal en résidualisant résultat et traitement par des modèles de ML, avec découpage croisé (module 11).
• DuckDB — moteur SQL analytique en processus, sans serveur, capable d'interroger directement des fichiers Parquet (module 4).
• Eckart–Young — théorème établissant que tronquer la SVD donne la meilleure approximation de rang donné. Le fondement de la PCA et de la compression (module 8).
• ELT / ETL — charger puis transformer, ou transformer puis charger. Le basculement vers ELT découle de l'effondrement du coût du stockage (module 7).
• Embedding — représentation d'un objet (mot, image, utilisateur) par un vecteur dense où la proximité géométrique traduit une proximité sémantique (module 22).
• Épistémique (incertitude) — incertitude due au manque de données ou de connaissance du modèle. Réductible, contrairement à l'incertitude aléatoire (module 10).
• Erreur type — écart-type d'un estimateur, qui décroît en \(1/\sqrt{n}\). À ne pas confondre avec l'écart-type des individus, qui ne décroît pas (module 9).
• Feature store — service imposant une définition unique des variables, servie à la fois pour l'entraînement et pour la prédiction, afin d'éviter le décalage entre les deux (module 7).
• Filtre de Kalman — estimation récursive de l'état caché d'un système à partir d'observations bruitées (module 17).
• Fonction de fenêtre — en SQL, calcul d'une agrégation sur un sous-ensemble de lignes sans réduire le nombre de lignes renvoyées (module 4).
• Forêt aléatoire — bagging d'arbres de décision, avec tirage aléatoire de variables à chaque nœud pour décorréler les arbres (module 14).
• Fuite de données — présence dans les variables d'une information indisponible au moment de la prédiction réelle. Produit des performances excellentes en validation et nulles en production (module 12).
• Générateur — fonction contenant yield, qui produit ses valeurs une à une sans les stocker. Permet de traiter un flux plus gros que la mémoire (module 1).
• GIL — verrou global de CPython qui empêche deux threads d'exécuter du bytecode Python simultanément. Sans effet sur les attentes d'entrée-sortie et sur le code natif qui le relâche (module 2).
• GNN — réseau de neurones sur graphe, qui construit la représentation d'un nœud en agrégant celles de ses voisins (module 18).
• Gradient boosting — boosting où chaque modèle ajouté approche le gradient de la perte. Le meilleur choix par défaut sur données tabulaires (module 14).
• HNSW — index de recherche approchée de plus proches voisins fondé sur un graphe hiérarchique. La structure derrière la plupart des bases vectorielles (module 22).
• Idempotence — propriété d'un traitement qui, relancé sur la même période, produit le même résultat au lieu de le dupliquer. Ce qui rend un pipeline rejouable (module 7).
• Ignorabilité — hypothèse selon laquelle, à covariables données, l'affectation au traitement est indépendante des résultats potentiels. Invérifiable, et centrale (module 11).
• Index (base de données) — structure auxiliaire accélérant la recherche au prix d'un coût en écriture et en espace (module 4).
• Inférence variationnelle — approcher une loi a posteriori en cherchant, dans une famille simple, la distribution qui s'en rapproche le plus. Plus rapide que MCMC, au prix d'une approximation (module 10).
• Instrument — variable qui influence le traitement sans agir autrement sur le résultat, utilisée pour estimer un effet en présence de confondants non mesurés (module 11).
• IPW — pondération par l'inverse de la probabilité de traitement, qui reconstruit une pseudo-population équilibrée (module 11).
• Itérateur — objet muni de __next__, qui se consomme une fois. À distinguer de l'itérable, qui sait en fournir un nouveau à chaque parcours (module 1).

J – P

• Jinja — moteur de gabarits qui insère des valeurs Python dans un texte à trous. Utilisé pour produire du HTML (module 6) et pour générer du SQL dans dbt (module 7).
• Jointure — opération SQL qui combine deux tables sur une condition. Le piège usuel est la duplication de lignes quand la clé n'est pas unique des deux côtés (module 4).
• Jumeau numérique — modèle d'un système physique, maintenu à jour par ses données de fonctionnement, servant à simuler et à décider (module 21).
• Kafka — journal distribué en écriture seule, partitionné, où les consommateurs avancent à leur rythme et peuvent rejouer l'historique (module 7).
• Kubernetes — orchestrateur déclaratif de conteneurs : on décrit l'état souhaité, le système s'efforce en permanence de l'atteindre (module 5).
• Lac de données — stockage de fichiers bon marché où l'on dépose les données brutes sans schéma imposé. S'oppose à l'entrepôt, structuré et modélisé (module 7).
• Lakehouse — lac de données doté de transactions, d'évolution de schéma et de voyage dans le temps, grâce à un format de table ouvert (Delta, Iceberg) (module 7).
• Learning to rank — apprendre à ordonner une liste plutôt qu'à prédire un score isolé, en optimisant une métrique de position (module 23).
• LoRA, QLoRA — adaptation d'un grand modèle par ajout de matrices de faible rang, en gelant les poids d'origine. QLoRA y ajoute la quantification (module 22).
• LSTM — réseau récurrent muni de portes, conçu pour atténuer la disparition du gradient sur les longues séquences (module 16).
• MAP — estimation du paramètre le plus probable a posteriori. Équivaut au maximum de vraisemblance pénalisé : régulariser, c'est mettre un a priori (module 10).
• MCMC — famille d'algorithmes qui échantillonnent une loi a posteriori par une chaîne de Markov. NUTS en est la variante moderne (module 10).
• Médiateur — variable par laquelle transite l'effet d'un traitement. Conditionner dessus supprime précisément l'effet qu'on cherche à mesurer (module 9).
• Métamodèle — modèle statistique rapide qui remplace une simulation coûteuse, entraîné sur un petit nombre d'exécutions (module 21).
• MLE — maximum de vraisemblance : choisir les paramètres qui rendent les données observées les plus probables (module 10).
• MLflow — outil de suivi d'expériences : paramètres, métriques, artefacts et versions de modèles (module 26).
• Momentum — accumulation d'une moyenne des gradients passés, qui lisse la trajectoire et accélère la descente dans les vallées étroites (module 8).
• Monte-Carlo — estimer une quantité par tirage aléatoire répété. Sa précision décroît en \(1/\sqrt{N}\), indépendamment de la dimension (module 21).
• Normalisation (bases) — organiser un schéma relationnel pour qu'une information ne soit stockée qu'à un seul endroit. S'oppose au schéma en étoile, pensé pour la lecture (module 4).
• Noyau — fonction mesurant une similarité entre deux points, qui permet de travailler implicitement dans un espace de grande dimension. Au cœur des SVM (module 14) et des processus gaussiens (module 19).
• OLTP / OLAP — bases orientées transactions (beaucoup d'écritures courtes) contre bases orientées analyse (peu d'écritures, grosses lectures). Deux architectures opposées (module 4).
• Optimisation bayésienne — optimiser une fonction coûteuse en construisant un modèle probabiliste de ses valeurs et en choisissant le point suivant par une fonction d'acquisition (module 19).
• Orchestrateur — outil qui exécute des tâches selon leurs dépendances, réessaie les échecs et conserve l'historique. Airflow, Dagster, Prefect (module 7).
• PAC — cadre théorique « probablement approximativement correct », qui borne l'écart entre erreur empirique et erreur réelle (module 15).
• Parquet — format de fichier colonne, compressé, typé, doté de statistiques par bloc. Le défaut raisonnable dès qu'un fichier est relu par un programme (module 7).
• PCA — projection sur les directions de variance maximale, obtenue par la SVD des données centrées. Sert à visualiser, compresser et décorréler (module 8).
• PINN — réseau dont la fonction de perte inclut le résidu d'une équation aux dérivées partielles, ce qui contraint la solution par la physique (module 16).
• polars — bibliothèque de manipulation de tableaux fondée sur Arrow, à évaluation paresseuse et parallèle par défaut (module 3).
• Positivité — hypothèse causale exigeant que chaque profil ait une chance non nulle d'être traité et de ne pas l'être. Vérifiable, contrairement à l'ignorabilité (module 11).
• pre-commit — mécanisme exécutant des vérifications automatiques avant chaque commit Git, pour ne jamais versionner du code non formaté (module 1).
• Prédiction conforme — méthode produisant des intervalles de prédiction avec une garantie de couverture valable sans hypothèse sur le modèle ni sur la loi des données (module 10).
• Processus gaussien — loi de probabilité sur des fonctions, qui fournit une prédiction et son incertitude, croissante loin des points observés (module 19).
• Score de propension — probabilité d'être traité compte tenu du profil. Conditionner sur ce seul nombre suffit à rendre les groupes comparables, sous ignorabilité (module 11).
• Pydantic — bibliothèque qui valide et convertit des données d'entrée à partir d'annotations de type, en échouant tôt et avec un message précis (module 6).
• p-value — probabilité d'observer un écart au moins aussi extrême si l'hypothèse nulle était vraie. Ce n'est pas la probabilité que l'hypothèse soit vraie (module 9).

Q – Z

• Q-learning — apprentissage de la valeur de chaque couple état-action par mise à jour itérative, sans modèle de l'environnement (module 20).
• Quantification — représenter les poids d'un modèle sur moins de bits (8 ou 4) pour réduire mémoire et latence, au prix d'une légère perte de qualité (module 22).
• Quasi-Monte-Carlo — remplacer les tirages aléatoires par une suite à faible discrépance, qui couvre l'espace plus régulièrement et converge plus vite (module 21).
• RAG — répondre en récupérant d'abord des documents pertinents, puis en les fournissant au modèle de langage comme contexte (module 22).
• Randomisation — affecter le traitement au hasard, ce qui élimine d'un coup tous les confondants, y compris ceux qu'on n'a pas mesurés (module 11).
• Régression sur discontinuité — exploiter un seuil administratif comme quasi-expérience : les individus juste en dessous et juste au-dessus sont comparables (module 11).
• Régularisation — pénaliser la complexité d'un modèle pour réduire sa variance. Ridge pénalise la norme au carré, Lasso la norme absolue et annule des coefficients (module 14).
• Rétropropagation — application de la règle de dérivation en chaîne qui calcule tous les gradients d'un réseau en un seul parcours arrière (module 16).
• Roofline — diagramme opposant intensité arithmétique et performance atteignable, qui indique si un calcul est limité par le calcul ou par la mémoire (module 25).
• ruff — formateur et analyseur statique Python, très rapide, qui remplace plusieurs outils historiques (module 1).
• Schéma en étoile — table de faits centrale entourée de tables de dimensions, organisation dénormalisée pensée pour minimiser les jointures à la lecture (module 7).
• SCD — dimension à évolution lente : trois stratégies (écraser, historiser par ligne, garder la valeur précédente) pour gérer un attribut qui change dans le temps (module 7).
• SGD — descente de gradient stochastique : estimer le gradient sur un petit lot plutôt que sur toutes les données. Son bruit joue un rôle régularisant (module 8).
• SHAP — attribution de la prédiction d'un modèle à ses variables, fondée sur les valeurs de Shapley. Explique la prédiction, pas la causalité (module 14).
• Simpson (paradoxe de) — inversion d'une conclusion entre les sous-groupes et l'agrégat, due à un confondant (module 9).
• slots — option de classe qui remplace le dictionnaire d'attributs par des emplacements fixes : moins de mémoire, accès plus rapide, pas d'attribut ajouté à la volée (module 1).
• Stationnarité — propriété d'une série dont les caractéristiques statistiques ne dépendent pas du temps. Condition d'application des modèles ARIMA (module 17).
• Streaming — traiter chaque événement à mesure qu'il arrive, plutôt que par lots périodiques. Justifié seulement quand la fraîcheur a une valeur mesurable (module 7).
• SUTVA — hypothèse causale d'absence d'interférence entre unités et d'unicité de la version du traitement. Violée par les effets de réseau (module 11).
• SVD — décomposition d'une matrice en rotation, dilatation, rotation. Le résultat d'algèbre linéaire le plus utile en data science (module 8).
• SVM — classifieur cherchant l'hyperplan de marge maximale, étendu aux frontières non linéaires par l'astuce du noyau (module 14).
• TF-IDF — pondération d'un terme par sa fréquence dans un document et sa rareté dans le corpus. Toujours une baseline solide en recherche textuelle (module 18).
• Transaction ACID — garanties d'atomicité, cohérence, isolation et durabilité d'une base de données (module 4).
• Transfert (apprentissage par) — réutiliser un modèle pré-entraîné sur une grande base et l'adapter à une tâche voisine avec peu d'exemples (module 13).
• Transformer — architecture fondée sur l'attention, qui traite une séquence entière en parallèle plutôt que pas à pas (module 16).
• Uplift — effet individuel d'une action, qui permet de cibler ceux qu'elle fait basculer plutôt que ceux qui auraient agi de toute façon (module 24).
• UTC — référence temporelle sans fuseau ni heure d'été. La seule forme non ambiguë de stockage d'un instant (module 7).
• UV — gestionnaire d'environnements et de dépendances Python, rapide, avec fichier de verrouillage reproductible (module 1).
• Valeur E — force minimale qu'un confondant non mesuré devrait avoir pour annuler un effet observé. Mesure la fragilité d'une conclusion causale (module 11).
• Validation croisée — découper les données en plis, entraîner sur les uns, évaluer sur l'autre, et faire tourner. Le schéma doit respecter la structure des données : temporelle, groupée, stratifiée (module 12).
• Vraisemblance — probabilité des données observées vue comme fonction des paramètres. Le pont entre modélisation probabiliste et optimisation (module 10).
• Vue et copie — en NumPy, une tranche partage la mémoire d'origine (vue) tandis qu'une indexation par masque la duplique (copie). Source classique de modifications inattendues (module 3).
• XGBoost — implémentation historique du gradient boosting, avec régularisation explicite et gestion native des valeurs manquantes (module 14).
• Zero-shot — résoudre une tâche sans aucun exemple étiqueté, en s'appuyant sur les connaissances déjà présentes dans un grand modèle pré-entraîné (module 13).

Lire un cours de data science donne l'illusion de le comprendre. Le test honnête, c'est de reproduire un résultat sans le support sous les yeux — et de se tromper, puis de comprendre pourquoi. Cette annexe rassemble une trentaine d'exercices, un par notion difficile, dans l'ordre des modules. Chacun tient en une à trois heures sur un ordinateur portable ordinaire.

Partie I — Outillage

Exercice 1 — Un décorateur de cache, avec statistiques

Objectif : comprendre qu'un décorateur n'est qu'une fonction qui en renvoie une autre (module 1).

Énoncé : écrivez @memoize qui met en cache les résultats d'une fonction selon ses arguments, et expose fn.hits, fn.misses et fn.vider(). Appliquez-le à une suite de Fibonacci naïvement récursive. Puis comparez à functools.lru_cache et lisez la sortie de cache_info().

Vérification : sans cache, fib(35) prend plusieurs secondes ; avec, moins d'une milliseconde. Vous devez obtenir exactement 36 échecs de cache pour fib(35) — si vous en avez davantage, votre clé de cache est mal construite. Question subsidiaire : que se passe-t-il si un argument est une liste, et pourquoi ?

Exercice 2 — Traiter un fichier plus gros que la mémoire

Objectif : voir concrètement ce qu'apporte un générateur (module 1).

Énoncé : fabriquez un CSV de 2 Go, puis calculez la moyenne et l'écart-type d'une colonne sans jamais charger plus de quelques mégaoctets. Utilisez tracemalloc pour mesurer le pic mémoire réel. Écrivez deux versions : l'une avec pd.read_csv nu, l'autre avec un générateur.

Vérification : la version paresseuse doit rester sous 50 Mo de pic. Calculez l'écart-type en une seule passe (algorithme de Welford) et comparez au résultat de NumPy sur l'ensemble : l'écart relatif doit être inférieur à \(10^{-10}\).

Exercice 3 — Mesurer le GIL plutôt que d'en parler

Objectif : établir soi-même les chiffres du module 2.

Énoncé : prenez une fonction purement calculatoire en Python pur, puis mesurez le temps total pour 8 exécutions dans quatre configurations : séquentiel, 8 threads, 8 processus, et une réécriture vectorisée NumPy sur un seul cœur. Produisez un tableau des accélérations.

Vérification : les threads doivent donner une accélération proche de 1 — voire inférieure. Les processus doivent approcher le nombre de cœurs, moins le coût de démarrage. La version NumPy bat souvent les 8 processus à elle seule : c'est le résultat le plus important de l'exercice.

Exercice 4 — CSV contre Parquet, chiffres à l'appui

Objectif : vérifier les ordres de grandeur du module 7.

Énoncé : téléchargez un jeu de données public d'au moins 500 Mo en CSV. Convertissez-le en Parquet, puis en Parquet partitionné par mois. Mesurez : taille sur disque, temps de lecture d'une colonne, temps d'une agrégation filtrée sur un mois.

Vérification : attendez un facteur 5 à 10 sur la taille, 20 à 50 sur la lecture d'une colonne. Vérifiez ensuite que la requête filtrée ne lit que la partition concernée — en la chronométrant sur un mois puis sur toute l'année.

Exercice 5 — Une image Docker qui ne fait pas 3 Go

Objectif : pratiquer la construction multi-étapes (module 5).

Énoncé : empaquetez un modèle scikit-learn derrière FastAPI dans une image. Contraintes : construction multi-étapes, utilisateur non root, healthcheck, .dockerignore, et le modèle chargé une seule fois au démarrage. Mesurez la taille finale avec docker images.

Vérification : visez moins de 400 Mo. Modifiez ensuite une ligne de code applicatif et reconstruisez : si l'installation des dépendances se relance, l'ordre de vos instructions est mauvais — corrigez-le jusqu'à ce que seule la dernière couche soit reconstruite.

Exercice 6 — Le top 3 par groupe, en SQL

Objectif : les fonctions de fenêtre (module 4).

Énoncé : sur une table de ventes, renvoyez les trois meilleurs produits de chaque catégorie, avec leur rang et leur part du chiffre d'affaires de la catégorie. Écrivez-la deux fois : avec une sous-requête corrélée, puis avec une CTE et ROW_NUMBER(). Comparez les plans d'exécution avec EXPLAIN ANALYZE.

Vérification : les deux requêtes doivent donner le même résultat, mais des plans très différents. Traitez explicitement le cas des ex æquo : RANK, DENSE_RANK et ROW_NUMBER ne renvoient pas la même chose, et savoir lequel choisir est l'objet de l'exercice.

Partie II — Socle mathématique et statistique

Exercice 7 — La PCA sans scikit-learn

Objectif : établir soi-même le lien SVD–PCA (module 8).

Énoncé : à partir d'une matrice de données, centrez-la, calculez sa SVD, et déduisez composantes principales, variance expliquée et projection. Comparez à sklearn.decomposition.PCA.

Vérification : les variances expliquées doivent coïncider à \(10^{-12}\) près. Les vecteurs, eux, peuvent différer d'un signe : comprendre pourquoi ce signe est arbitraire fait partie de l'exercice. Vérifiez aussi que la somme des valeurs singulières au carré, divisée par \(n-1\), redonne la variance totale.

Exercice 8 — Compresser une image par approximation de rang faible

Objectif : rendre le théorème d'Eckart–Young tangible (module 8).

Énoncé : prenez une photographie en niveaux de gris, tronquez sa SVD à \(k = 5, 20, 50, 100\), affichez les reconstructions côte à côte. Tracez l'erreur relative en fonction de \(k\) et le taux de compression correspondant.

Vérification : l'erreur doit décroître exactement comme la racine de la somme des valeurs singulières écartées au carré — vérifiez-le numériquement. Trouvez le \(k\) qui conserve 90 % de l'énergie, et regardez à quoi ressemble l'image : elle est souvent déjà très reconnaissable, ce qui explique pourquoi la PCA fonctionne.

Exercice 9 — Le théorème central limite, vu de ses limites

Objectif : savoir quand l'approximation normale cesse d'être valable (module 9).

Énoncé : échantillonnez dans une loi très asymétrique (exponentielle, puis log-normale de forte variance). Pour \(n = 5, 30, 100, 1000\), tracez la distribution de la moyenne et mesurez le taux de couverture réel d'un intervalle de confiance à 95 % sur 10 000 répétitions.

Vérification : pour l'exponentielle, la couverture s'approche de 95 % dès \(n \approx 30\). Pour une log-normale de paramètre \(\sigma = 2\), elle reste nettement en dessous même à \(n = 1000\) : c'est exactement pourquoi on utilise le bootstrap sur des données de dépense.

Exercice 10 — Calculer la puissance avant l'expérience

Objectif : dimensionner un A/B test (module 9).

Énoncé : par simulation, tracez la puissance d'un test de proportions en fonction de \(n\), pour un taux de base de 5 % et un effet relatif de 2 %, 5 % et 10 %. Confrontez au calcul analytique de statsmodels.

Vérification : pour détecter un effet relatif de 2 % avec 80 % de puissance, vous devriez trouver de l'ordre de plusieurs centaines de milliers d'utilisateurs par groupe. Ce chiffre est le plus utile de tout le module : il explique pourquoi la plupart des A/B tests réellement menés sont sous-dimensionnés.

Exercice 11 — Cent tests A/A

Objectif : voir le p-hacking se produire (module 9).

Énoncé : simulez 100 expériences où les deux groupes sont identiques, et testez 20 métriques dans chacune. Comptez les « résultats significatifs » à 5 %. Appliquez ensuite Bonferroni puis Benjamini-Hochberg, et recomptez.

Vérification : vous devez trouver environ une métrique significative par expérience, alors qu'aucune différence n'existe. Puis : Bonferroni en élimine presque toutes au prix d'une perte de puissance, Benjamini-Hochberg en garde davantage pour un taux de fausses découvertes contrôlé. Regarder ces deux chiffres côte à côte vaut mieux qu'un long développement.

Exercice 12 — Bootstrap contre formule

Objectif : savoir quand la formule cesse d'exister (module 9).

Énoncé : estimez un intervalle de confiance pour la médiane d'une distribution asymétrique — par bootstrap, puis en cherchant une formule analytique. Faites de même pour le rapport de deux moyennes.

Vérification : le bootstrap fonctionne sans effort dans les deux cas ; la formule analytique est pénible pour la médiane et franchement délicate pour le rapport. C'est tout l'intérêt de la méthode. Vérifiez ensuite la couverture réelle de l'intervalle bootstrap par simulation : elle est bonne, mais pas parfaite en petit échantillon.

Exercice 13 — Fabriquer un confondant, puis le neutraliser

Objectif : manipuler soi-même un biais causal (module 11).

Énoncé : générez des données selon un mécanisme que vous choisissez : une variable \(Z\) influence à la fois le traitement \(T\) et le résultat \(Y\), et \(T\) a un effet vrai que vous fixez à 2,0. Estimez l'effet (a) par différence de moyennes brutes, (b) par régression ajustée sur \(Z\), (c) par pondération IPW.

Vérification : (a) doit être franchement biaisé, (b) et (c) doivent retrouver 2,0 à l'erreur d'échantillonnage près. Reprenez ensuite l'exercice en n'observant pas \(Z\) : aucune des trois méthodes ne s'en sort, et c'est le point à retenir. Enfin, ajoutez un collisionneur aux variables d'ajustement et constatez que l'estimation se dégrade — ajouter des variables n'est pas neutre.

Exercice 14 — CUPED sur vos propres données

Objectif : quantifier un gain de puissance (module 11).

Énoncé : simulez une expérience où la métrique est fortement corrélée à sa valeur de la période précédente. Appliquez CUPED et mesurez la réduction de largeur de l'intervalle de confiance pour \(\rho = 0{,}3\), \(0{,}5\), \(0{,}7\), \(0{,}9\).

Vérification : la variance doit être réduite d'un facteur \(1 - \rho^2\). Traduisez ce gain en économie de durée d'expérience : à \(\rho = 0{,}7\), vous devez trouver environ deux fois moins d'utilisateurs nécessaires. Essayez ensuite d'utiliser une covariable mesurée après le début de l'expérience et observez le biais apparaître.

Partie III — Méthode et données

Exercice 15 — Fabriquer une fuite de données volontairement

Objectif : reconnaître le symptôme avant de le subir (module 12).

Énoncé : sur un jeu tabulaire, encodez une variable catégorielle par la moyenne de la cible calculée sur l'ensemble des données, puis validez par validation croisée. Recommencez en calculant l'encodage à l'intérieur de chaque pli, via un Pipeline.

Vérification : la première version affiche un score spectaculaire et faux ; la seconde, un score honnête et plus bas. L'écart entre les deux est la mesure exacte de la fuite. Recommencez avec une normalisation appliquée avant le découpage : le même phénomène se produit, en plus discret.

Exercice 16 — Choisir le bon schéma de validation

Objectif : comprendre que le découpage encode une hypothèse (module 12).

Énoncé : sur des données horodatées, comparez KFold, GroupKFold et TimeSeriesSplit. Mesurez à chaque fois le score de validation, puis le score réel sur une période future conservée à part.

Vérification : KFold doit être nettement optimiste. Quantifiez l'optimisme : c'est cet écart, et non le score de validation, qui indique si votre protocole est honnête.

Exercice 17 — Combien d'étiquettes acheter ?

Objectif : raisonner en coût marginal (module 13).

Énoncé : partez de 100 exemples étiquetés et ajoutez-en par lots de 100, selon deux stratégies : tirage au hasard, et apprentissage actif par incertitude. Tracez les deux courbes d'apprentissage.

Vérification : l'apprentissage actif doit atteindre une performance donnée avec deux à trois fois moins d'étiquettes — mais pas toujours : sur certains jeux il n'apporte rien, et comprendre pourquoi (déséquilibre, bruit d'annotation) vaut le détour. Repérez le point où la courbe s'aplatit : c'est là que l'annotation cesse d'être rentable.

Partie IV — Familles de modèles

Exercice 18 — Voir le compromis biais-variance

Objectif : produire la figure canonique soi-même (module 14).

Énoncé : ajustez des polynômes de degré 1 à 15 sur un petit échantillon bruité issu d'une fonction connue. Tracez erreur d'entraînement et erreur de test en fonction du degré. Répétez sur 200 échantillons et décomposez l'erreur en biais² et variance.

Vérification : l'erreur d'entraînement doit décroître sans cesse, l'erreur de test passer par un minimum. La somme biais² + variance + bruit doit reconstituer l'erreur totale à l'erreur de Monte-Carlo près : c'est la vérification qui prouve que la décomposition a été faite correctement.

Exercice 19 — Reproduire la double descente

Objectif : constater que la courbe en U n'est pas toute l'histoire (module 15).

Énoncé : sur un jeu de taille \(n\) fixée, faites croître la capacité du modèle (nombre de variables aléatoires ajoutées, ou largeur d'un réseau) bien au-delà de \(n\). Tracez l'erreur de test.

Vérification : un pic d'erreur doit apparaître au voisinage du point d'interpolation, suivi d'une seconde descente. Vous n'obtiendrez le phénomène qu'avec une régularisation très faible : chercher pourquoi fait partie de l'exercice.

Exercice 20 — Gradient boosting contre réseau de neurones sur données tabulaires

Objectif : se faire une opinion fondée sur une mesure (modules 14 et 16).

Énoncé : sur trois jeux tabulaires de tailles différentes, comparez LightGBM et un perceptron multicouche correctement réglé. Chronométrez le temps de réglage, pas seulement le score final.

Vérification : le boosting doit gagner sur la plupart des jeux, et surtout gagner beaucoup plus vite. Notez précisément combien de temps vous avez passé à régler chacun : c'est la variable la plus souvent absente des comparaisons publiées.

Exercice 21 — La rétropropagation à la main

Objectif : ne plus considérer l'autodifférenciation comme magique (module 16).

Énoncé : implémentez un réseau à deux couches en NumPy seul — propagation avant, calcul de la perte, gradients écrits à la main, mise à jour. Entraînez-le sur un problème séparable non linéairement.

Vérification : comparez chaque gradient analytique à son approximation par différences finies. L'écart relatif doit être inférieur à \(10^{-6}\) ; s'il ne l'est pas, le bug est dans votre dérivation, et le trouver est précisément l'exercice.

Exercice 22 — Un Transformer minuscule

Objectif : comprendre l'attention par construction (module 16).

Énoncé : implémentez l'attention produit scalaire mise à l'échelle, puis un bloc Transformer complet, et entraînez-le à inverser une séquence de chiffres. Affichez la matrice d'attention apprise.

Vérification : la carte d'attention doit faire apparaître une anti-diagonale nette. Retirez ensuite l'encodage de position et observez l'échec : c'est la démonstration la plus directe de son rôle.

Exercice 23 — Optimisation bayésienne contre recherche aléatoire

Objectif : mesurer le gain à budget égal (module 19).

Énoncé : réglez trois hyperparamètres d'un modèle avec 30 évaluations, par recherche aléatoire puis par optimisation bayésienne. Répétez 20 fois et comparez les distributions du meilleur score atteint.

Vérification : l'optimisation bayésienne doit gagner en médiane, avec un écart qui se creuse quand chaque évaluation devient coûteuse. Sur un espace de recherche petit et peu coûteux, l'écart est souvent négligeable — savoir reconnaître ce cas évite d'ajouter une dépendance pour rien.

Partie V — Domaines et applications

Exercice 24 — Battre la baseline naïve saisonnière

Objectif : la leçon d'humilité des séries temporelles (module 17).

Énoncé : sur une série réelle (consommation électrique, fréquentation, ventes), établissez la baseline « même jour la semaine dernière ». Essayez ensuite ETS, ARIMA, puis un gradient boosting sur variables calendaires et retards.

Vérification : la baseline est difficile à battre, et un ARIMA mal configuré perd contre elle. Évaluez en validation glissante, jamais par découpage aléatoire. Rapportez l'erreur relative à la baseline plutôt qu'en valeur absolue : c'est la seule forme interprétable.

Exercice 25 — Un RAG sur vos propres notes

Objectif : voir où un système RAG échoue (module 22).

Énoncé : indexez une centaine de documents à vous, construisez la chaîne découpage → embeddings → recherche → génération. Constituez 20 questions dont vous connaissez la réponse, et mesurez séparément la qualité de la récupération et celle de la réponse.

Vérification : la plupart des échecs viennent de la récupération, pas du modèle de langage — vérifiez-le en fournissant manuellement le bon passage. Trouvez ensuite une question où le système répond avec assurance et se trompe : c'est le mode de défaillance qui compte réellement en production.

Exercice 26 — Recherche hybride

Objectif : comprendre pourquoi le lexical n'est pas mort (module 23).

Énoncé : sur un corpus avec des jugements de pertinence, comparez BM25 seul, embeddings seuls, et une fusion des deux. Mesurez nDCG@10.

Vérification : l'hybride doit battre les deux. Identifiez les requêtes où chaque approche gagne : le lexical excelle sur les références exactes et les identifiants, le sémantique sur les reformulations. Cette analyse par cas vaut plus que le chiffre global.

Partie VI — Décision, production, responsabilité

Exercice 27 — Le seuil optimal n'est pas 0,5

Objectif : relier score et décision (module 24).

Énoncé : entraînez un classifieur sur un problème déséquilibré. Fixez un coût de faux positif et un coût de faux négatif, puis tracez le coût total en fonction du seuil. Comparez au seuil 0,5 et au seuil qui maximise le F1.

Vérification : le seuil optimal doit être loin de 0,5 dès que les coûts sont asymétriques, et il doit coïncider avec la formule du module 24. Vérifiez aussi que le modèle est calibré avant de l'utiliser : sur un score mal calibré, le seuil théorique est faux.

Exercice 28 — Cibler par uplift, pas par risque

Objectif : la distinction qui change une campagne (modules 11 et 24).

Énoncé : simulez une population contenant les quatre types — convaincables, acquis, perdus, réfractaires. Comparez deux stratégies de ciblage à budget égal : par probabilité de résiliation, et par uplift estimé.

Vérification : le ciblage par uplift doit rapporter davantage, et le ciblage par risque peut même détruire de la valeur s'il touche des réfractaires. Faites varier la proportion de réfractaires et trouvez le point où le ciblage par risque devient contre-productif.

Exercice 29 — Détecter une dérive

Objectif : surveiller un modèle en production (module 26).

Énoncé : implémentez l'indice de stabilité de population (PSI). Simulez trois scénarios : dérive brutale, dérive lente, et dérive de concept sans dérive de covariables. Mesurez le délai de détection de chacun.

Vérification : le PSI détecte bien les deux premiers cas, et pas du tout le troisième — les entrées n'ont pas bougé, seule la relation a changé. C'est la limite fondamentale de la surveillance sans étiquettes, et la raison pour laquelle il faut aussi suivre une métrique de performance retardée.

Exercice 30 — Audit d'équité, et son impossibilité

Objectif : constater empiriquement le théorème d'incompatibilité (module 27).

Énoncé : sur un jeu public comportant un attribut sensible, mesurez parité démographique, égalité des chances et calibration par sous-groupe. Tentez ensuite de satisfaire les trois simultanément.

Vérification : vous n'y arriverez pas, sauf si les taux de base sont identiques entre groupes. Le constat n'est pas un échec technique mais un résultat mathématique : améliorer l'un dégrade mécaniquement un autre, et le choix est politique, pas algorithmique.

Exercice 31 — Profiler avant d'optimiser

Objectif : trouver le vrai goulot (module 25).

Énoncé : profilez une boucle d'entraînement avec le profileur PyTorch. Mesurez le taux d'occupation du GPU. Corrigez ce que le profil révèle, puis re-mesurez.

Vérification : dans la grande majorité des cas, le goulot est le chargement des données, pas le calcul. Un GPU occupé à moins de 50 % le confirme. Après correction — num_workers, pin_memory, préchargement — l'accélération doit être nette. Optimiser le modèle avant d'avoir regardé ce chiffre est la perte de temps classique.

Partie VII — Prolongements du projet final

Le module 28 construit un pipeline complet. Ces variantes le prolongent, chacune ajoutant une contrainte réaliste.

• Sans scraping. Refaites le projet sur les demandes de valeurs foncières publiées en données ouvertes : transactions réelles, notariées, avec les difficultés propres aux données administratives — codes géographiques changeants, doublons de dépôt, valeurs aberrantes légitimes.
• Avec incertitude. Remplacez la prédiction ponctuelle par un intervalle de prédiction conforme (module 10), et exposez-le dans l'API. Vérifiez empiriquement la couverture sur un jeu conservé à part.
• Avec surveillance. Ajoutez un calcul de PSI hebdomadaire sur les variables d'entrée et une étape de CI qui échoue si la dérive dépasse un seuil. Simulez une dérive en filtrant les annonces d'une région.
• Avec une question causale. Le prix au mètre carré est-il causé par la présence d'un ascenseur, ou l'ascenseur accompagne-t-il simplement des immeubles plus récents et mieux situés ? Posez le graphe causal, choisissez une méthode du module 11, et comparez la réponse causale au coefficient du modèle prédictif.
• Avec du volume. Multipliez artificiellement les données par cent et refaites tourner le pipeline. Ce qui casse en premier — mémoire, temps d'ingestion, index manquant — vous apprendra davantage que n'importe quel chapitre sur le passage à l'échelle.

Ce cours condense et réorganise ; il ne remplace pas les sources. Cette annexe indique, pour chaque partie, où aller quand un module a donné envie d'approfondir — avec une recommandation unique par sujet plutôt qu'une bibliographie exhaustive, parce qu'une liste de trente livres ne se lit jamais.

1. Les quatre livres qui couvrent le plus de terrain

• Hastie, Tibshirani, Friedman — The Elements of Statistical Learning (libre). La référence du ML statistique, exigeante mais précise. C'est le livre vers lequel on revient dix ans plus tard. Sa version d'introduction, An Introduction to Statistical Learning (libre, avec une édition Python), couvre les mêmes idées sans la charge mathématique.
• Murphy — Probabilistic Machine Learning, deux volumes (brouillons libres). Le traitement le plus complet et le plus à jour, du point de vue probabiliste. Sert autant de manuel que d'encyclopédie.
• Géron — Hands-On Machine Learning with Scikit-Learn, Keras and TensorFlow. L'exact complément des deux précédents : tout y est code, et les chapitres sur le pipeline de données et le déploiement sont excellents.
• Huyen — Designing Machine Learning Systems. Le livre qui manque à la plupart des cursus : comment un système de ML vit en production. À lire avant, pas après, un premier projet en entreprise.

2. Par partie du cours

Partie I — Outillage (modules 1 à 7)

• Si un seul : Ramalho — Fluent Python. Le livre qui fait passer de « je sais écrire du Python » à « je comprends pourquoi Python se comporte ainsi ». Les chapitres sur les itérateurs, les décorateurs et la concurrence recouvrent exactement les modules 1 et 2.
• Beazley — Python Concurrency (conférences en ligne) : les exposés les plus clairs sur le GIL et asyncio.
• Kleppmann — Designing Data-Intensive Applications. Le meilleur livre sur les systèmes de données : réplication, partitionnement, transactions, flux. Dense et remarquablement pédagogique.
• Reis & Housley — Fundamentals of Data Engineering, pour le panorama des architectures, et Kimball — The Data Warehouse Toolkit, qui reste la référence sur la modélisation dimensionnelle (module 7).
• Documentations officielles : Docker (le guide « get started » est bien fait), Kubernetes concepts, FastAPI (l'un des meilleurs tutoriels toutes technologies confondues), polars user guide, dbt developer hub.

Partie II — Socle mathématique et statistique (modules 8 à 11)

• Si un seul : Strang — Linear Algebra and Learning from Data. Écrit pour ce cas d'usage précis : l'algèbre linéaire dont le ML a besoin, SVD en tête. Le cours vidéo MIT 18.06 du même auteur est libre.
• Boyd & Vandenberghe — Convex Optimization (libre), pour l'optimisation ; Nocedal & Wright — Numerical Optimization pour les méthodes de second ordre.
• Wasserman — All of Statistics, pour la statistique inférentielle en un volume compact ; Efron & Hastie — Computer Age Statistical Inference (libre) pour la perspective historique, bootstrap compris.
• McElreath — Statistical Rethinking (cours vidéo libre). Le meilleur livre pour comprendre l'inférence bayésienne et la pensée causale, sans prérequis excessifs. Gelman et al. — Bayesian Data Analysis (libre) pour la référence complète.
• Causalité : Cunningham — Causal Inference: The Mixtape (libre) est l'entrée la plus accessible ; Hernán & Robins — Causal Inference: What If (libre) est la référence rigoureuse ; Pearl — The Book of Why pour l'intuition des graphes causaux.
• Angelopoulos & Bates — A Gentle Introduction to Conformal Prediction (libre), quarante pages qui suffisent au module 10.

Partie III — Méthode et données (modules 12 et 13)

• Si un seul : Kaggle Learn et les notebooks des compétitions terminées. Rien ne remplace la lecture d'une solution gagnante commentée pour comprendre ce que « travailler ses variables » veut dire.
• Wickham — R for Data Science (libre) : même si le langage diffère, les chapitres sur la structure d'une analyse et sur les données rangées sont transposables tels quels.
• Tufte — The Visual Display of Quantitative Information, pour la visualisation ; la documentation de seaborn pour la pratique immédiate.
• Documentation de scikit-learn, section « User Guide » : l'un des meilleurs cours de ML gratuits, à lire comme un livre plutôt que comme une référence.

Partie IV — Familles de modèles (modules 14 à 19)

• Si un seul : Prince — Understanding Deep Learning (libre). Récent, très bien illustré, avec les exercices et les diapositives. Il a remplacé Goodfellow comme premier livre de deep learning, même si Deep Learning (libre) reste la référence théorique.
• Karpathy — Neural Networks: Zero to Hero (vidéos libres) : construire la rétropropagation puis un Transformer à partir de zéro. Sans doute la meilleure heure investie du module 16.
• Shalev-Shwartz & Ben-David — Understanding Machine Learning (libre), pour la théorie du module 15.
• Rasmussen & Williams — Gaussian Processes for Machine Learning (libre), pour le module 19 ; la documentation de BoTorch pour l'optimisation bayésienne appliquée.
• Sutton & Barto — Reinforcement Learning: An Introduction (libre) pour le module 20, complété par le cours Deep RL de Hugging Face, plus pratique.

Partie V — Domaines et applications (modules 20 à 23)

• Hyndman & Athanasopoulos — Forecasting: Principles and Practice (libre). La référence sur les séries temporelles, claire et directement applicable (module 17).
• Jurafsky & Martin — Speech and Language Processing (brouillon libre) pour le NLP ; Manning, Raghavan & Schütze — Introduction to Information Retrieval (libre) pour la recherche, dont les chapitres sur l'indexation et l'évaluation n'ont pas vieilli (modules 18 et 23).
• Hugging Face — cours NLP et documentation transformers, pour la pratique du module 22.
• Hamilton — Graph Representation Learning (libre), pour les GNN du module 18.
• Smith — Uncertainty Quantification et la documentation de SALib et OpenTURNS, pour le module 21.

Partie VI — Décision, production, responsabilité (modules 24 à 27)

• Si un seul : Huyen — Designing Machine Learning Systems, déjà cité, qui couvre à lui seul une bonne part des modules 24 à 26.
• Kohavi, Tang & Xu — Trustworthy Online Controlled Experiments. Tout ce qu'on apprend en cassant des A/B tests, écrit par ceux qui les ont cassés à grande échelle.
• Molnar — Interpretable Machine Learning (libre), pour l'interprétabilité ; Barocas, Hardt & Narayanan — Fairness and Machine Learning (libre), pour le module 27.
• Documentation de MLflow, DVC, Evidently et fairlearn ; le NIST AI Risk Management Framework et le texte du règlement européen sur l'IA pour le cadre réglementaire.
• Pour le GPU et la performance (module 25) : la documentation PyTorch Performance Tuning et les guides NVIDIA Deep Learning Performance, plus utiles que n'importe quel livre sur ce sujet qui bouge vite.

3. Cours en ligne et vidéos

• 3Blue1Brown — Essence of Linear Algebra, Essence of Calculus, Neural Networks. L'intuition géométrique derrière ce que la prépa a enseigné algébriquement. À regarder avant le module 8.
• Karpathy — Neural Networks: Zero to Hero. Construire, ligne par ligne, un moteur de différentiation automatique puis un modèle de langage.
• fast.ai — Practical Deep Learning for Coders. Approche descendante : on entraîne un modèle utile dès la première leçon, la théorie vient après.
• Stanford CS231n (vision), CS224n (NLP), CS229 (ML) — notes et vidéos libres, d'un niveau supérieur aux cours grand public.
• StatQuest (Josh Starmer) — quand une notion statistique résiste, il en existe presque toujours une explication de dix minutes ici.
• DataTalks.Club — Data Engineering Zoomcamp et MLOps Zoomcamp, gratuits, entièrement pratiques : ils recouvrent les modules 7 et 26.
• MIT 18.06 (Strang) pour l'algèbre linéaire, MIT 6.006 pour les algorithmes.

4. Articles qui ont changé la pratique

Une trentaine de textes suffit à couvrir l'essentiel de ce qui est utilisé aujourd'hui. Ils sont tous librement accessibles.

MÉTHODE ET ÉPISTÉMOLOGIE
  Breiman 2001      Statistical Modeling: The Two Cultures
  Wolpert 1996      No Free Lunch Theorems
  Halevy+ 2009      The Unreasonable Effectiveness of Data
  Sculley+ 2015     Hidden Technical Debt in ML Systems   ← module 26

ML CLASSIQUE
  Tibshirani 1996   Regression Shrinkage and Selection (Lasso)
  Cortes-Vapnik 95  Support-Vector Networks
  Breiman 2001      Random Forests
  Chen-Guestrin 16  XGBoost: A Scalable Tree Boosting System
  Bergstra-Bengio   Random Search for Hyper-Parameter Optimization (2012)

THÉORIE ET GÉNÉRALISATION
  Zhang+ 2017       Understanding Deep Learning Requires Rethinking
                    Generalization
  Belkin+ 2019      Reconciling Modern ML Practice (double descente)

DEEP LEARNING
  Kingma-Ba 2014    Adam
  Ioffe-Szegedy 15  Batch Normalization
  He+ 2016          Deep Residual Learning (ResNet)
  Vaswani+ 2017     Attention Is All You Need
  Devlin+ 2018      BERT
  Brown+ 2020       Language Models are Few-Shot Learners (GPT-3)
  Hu+ 2021          LoRA
  Lewis+ 2020       Retrieval-Augmented Generation
  Hoffmann+ 2022    Training Compute-Optimal LLMs (Chinchilla)

CAUSALITÉ ET INCERTITUDE
  Rosenbaum-Rubin   The Central Role of the Propensity Score (1983)
  Chernozhukov+ 18  Double/Debiased Machine Learning
  Athey-Wager 2019  Generalized Random Forests
  Gneiting-Raftery  Strictly Proper Scoring Rules (2007)
  Guo+ 2017         On Calibration of Modern Neural Networks

APPLICATIONS
  Koren+ 2009       Matrix Factorization for Recommender Systems
  Covington+ 2016   Deep Neural Networks for YouTube Recommendations
  Kipf-Welling 17   Semi-Supervised Classification with GCN
  Raissi+ 2019      Physics-Informed Neural Networks
  Mnih+ 2015        Human-Level Control through Deep RL (DQN)
  Schulman+ 2017    Proximal Policy Optimization

RESPONSABILITÉ
  Dwork+ 2006       Calibrating Noise to Sensitivity (confid. différentielle)
  Goodfellow+ 2015  Explaining and Harnessing Adversarial Examples
  Buolamwini-Gebru  Gender Shades (2018)
  Mitchell+ 2019    Model Cards for Model Reporting
  Gebru+ 2018       Datasheets for Datasets

5. Jeux de données et terrains d'entraînement

• data.gouv.fr — données publiques françaises. En particulier les demandes de valeurs foncières (DVF), qui recensent toutes les transactions immobilières réelles : c'est la source à privilégier pour refaire le projet du module 28 sans scraper quoi que ce soit.
• INSEE et Eurostat — données démographiques et économiques, propres, documentées, avec des identifiants géographiques stables.
• Kaggle — concours et jeux de données. L'intérêt principal n'est pas la compétition mais les notebooks publics et les discussions post-mortem.
• OpenML et UCI Machine Learning Repository — jeux de données standardisés, utiles pour comparer des méthodes sur un terrain connu.
• Hugging Face Datasets — texte, image, audio, avec un chargement uniforme.
• Papers with Code — le lien entre un article, son code et ses résultats de référence.

6. Lire un article, se tenir à jour