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.

ml/README.md

@@ -111,12 +111,23 @@ Depuis la racine du monorepo, via le `Makefile` : `make install-ml`, `make ml-li
 
 ## Ou ecrire les tests
 
-Aucun test ne touche PostgreSQL ni un serveur MLflow distant : `enervision_ml.data.load_from_csv`
-et le chargement CSV de test suffisent a exercer `build_features` sur des donnees reelles ou
-synthetiques, et `enervision_ml.train.train()` accepte un `tracking_uri` SQLite isole (`tmp_path`
-pytest) pour un test de bout en bout sans effet de bord. `enervision_ml.data.load_from_database`
-n'est pas encore couvert : il n'existe aucune base PostgreSQL a interroger en CI ni dans cet
-environnement de developpement pour le moment.
+Deux regimes, separes par le marqueur `integration` que `pytest` ecarte par defaut.
+
+**Sans base** : `enervision_ml.data.load_from_csv` et le chargement CSV de test suffisent a
+exercer `build_features` sur des donnees reelles ou synthetiques, et `enervision_ml.train.train()`
+accepte un `tracking_uri` SQLite isole (`tmp_path` pytest) pour un test de bout en bout sans effet
+de bord.
+
+**Avec base**, sous `integration` : `test_data_integration.py` confronte les neuf colonnes du
+contrat au schema Alembic reel, et `test_score_integration.py` verifie les contraintes de
+`prediction` depuis le code qui ecrit. Les fixtures sont dans `tests/conftest.py`, qui refuse de
+demarrer si `ML_DATABASE_URL` ne vise pas `enervision_test`.
+
+    make db-up migrate-test ml-test-integration
+
+Regle a tenir : **toute requete SQL nouvelle porte un test `integration`**. Le schema vit dans
+`apps/backend/alembic`, pas ici : sans ce garde-fou, une migration qui renomme une colonne casse
+le pipeline en production sans qu'aucun test ne rougisse.
 
 ## Piege a connaitre