docs(ml,backend,etl): ordonnance la derive et corrige ce que le depot disait faux

Trois phrases du depot annonçaient une surveillance de derive inexistante, et une quatrieme
disait qu'aucune base PostgreSQL n'etait joignable pour tester le chargement ML. Les quatre
sont maintenant fausses, donc reecrites plutot que laissees en dette.

- ADR 0011 : ou vit le calcul et pourquoi pas dans `ml/`, les deux dedoublonnages qu'impose la
  jointure, et quatre alternatives ecartees avec la contrainte qui les interdit (la metrique
  MLflow n'est pas la meme grandeur, `alert` borne ses valeurs et refuse un site nul, Prometheus
  n'a pas de collecteur, ne rien persister ne repond pas a la question du jury).
- DAG `derive` quotidien, hors du DAG `alertes` : un echec de derive y ferait croire que la
  detection a echoue, et la fenetre de 168 h ne se recalcule pas toutes les heures.
- ML-START : la limite de `--now` est dite au lieu d'etre decouverte en demonstration. Elle ne
  decale que l'instant de reference, pas la fenetre de lecture, donc aucun rattrapage ne peut
  fabriquer de paires prevu/realise sur un jeu fige.
- 50-cicd : pourquoi le job ML installe aussi le backend (le schema n'a qu'une source), et ce
  que coute le filtre de chemins qui l'accompagne.

docs/architecture/50-cicd.md

@@ -155,6 +155,8 @@ dans [10-infra.md](10-infra.md).
 | Typage `mypy` | backend (`app`), ml (strict) | zéro erreur | Bloque |
 | Tests unitaires `pytest` | backend, ml | **`--cov-fail-under=85`** côté backend | Bloque |
 | Tests d'intégration | backend | marqueur `integration`, base réelle | Bloque |
+| Tests d'intégration ML ↔ DB | ml | marqueur `integration`, base réelle migrée par Alembic | Bloque |
+| Chaîne ML → DB → API | ml | marqueur `chaine`, vrais binaires en sous-processus | Bloque |
 | Audit de dépendances `pip-audit` | backend | sur le **verrou figé** | Bloque |
 | Audit de dépendances `npm audit` | frontend | `--audit-level=high` | Bloque |
 | **SAST `bandit`** | backend (`app`), ml (`enervision_ml`) | **MEDIUM et au-dessus** | Bloque |
@@ -254,6 +256,28 @@ Ils ne transitent ni par git ni par GitHub, et le runner, qui travaille dans ce
 à recevoir. Le revers : ils ne sont sauvegardés nulle part ailleurs. Un `.env` perdu se
 régénère, ce qui invalide les sessions et les connexions chiffrées par Airflow.
 
+### Pourquoi le job d'intégration ML installe aussi le backend
+
+Le schéma de la base n'a qu'une source, les six révisions Alembic de `apps/backend/alembic` : le
+backend est propriétaire du schéma, `ml/` n'en est que consommateur. Reconstruire ce schéma à la
+main dans le job ML donnerait un job vert sur une base qui n'est pas la nôtre, exactement l'erreur
+qu'évite déjà le choix de l'image `timescaledb-ha` plutôt qu'un `postgres` nu. Le job installe
+donc les deux environnements uv, applique `alembic upgrade head`, puis joue `-m integration` côté
+`ml/` et `-m chaine` côté backend.
+
+Conséquence sur le déclenchement : les `paths` de `ml.yml` incluent `apps/backend/alembic/**` et
+`apps/backend/app/models/**`. Sans eux, une migration qui renomme une colonne de `reading` ne
+déclencherait pas ce job, le SQL brut du pipeline dériverait du schéma, et **rien ne casserait
+avant la production**. Le prix est qu'une PR touchant seulement une migration lance aussi le lint
+et le typage de `ml/` : environ deux minutes de runner, en parallèle. Même arbitrage que le filtre
+d'`airflow.yml`, qui écoute déjà `ml/**` et `apps/backend/app/**` parce que son image réunit les
+deux.
+
+Le marqueur `chaine` est distinct d'`integration` pour une raison mécanique : le job `integration`
+de `backend.yml` n'installe pas `ml/.venv`, et sélectionnerait sinon un test qui lance les
+binaires du pipeline. Il est aussi exclu d'`addopts`, sans quoi `make test` échouerait sur tout
+poste où `ml/` n'est pas installé.
+
 ## Ce qui manque, et pourquoi
 
 | Manque | Issue | Conséquence assumée |
@@ -267,8 +291,17 @@ régénère, ce qui invalide les sessions et les connexions chiffrées par Airfl
 ## Reproduire la CI en local
 
 `make check` enchaîne formatage, analyse statique, typage et tests du backend, c'est à dire le job
-`verification`. `make ml-check` fait la même chose pour le module ML. Les tests d'intégration
-demandent une base : `make db-up` puis `uv run pytest -m integration`.
+`verification`. `make ml-check` fait la même chose pour le module ML.
+
+Les tests d'intégration demandent une base **migrée**, et `db/init` ne crée `enervision_test` que
+vide :
+
+```bash
+make db-up migrate-test     # la base de test reçoit les six révisions Alembic
+make test-integration       # backend, marqueur `integration`
+make ml-test-integration    # pipeline ML, marqueur `integration`
+make test-chaine            # vrais binaires ML puis relecture par l'API, marqueur `chaine`
+```
 
 Le SAST se rejoue à l'identique : `uvx bandit==1.9.4 --recursive app --severity-level medium
 --confidence-level medium` depuis `apps/backend`, et la même commande sur `enervision_ml` depuis