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/40-data.md

@@ -48,7 +48,8 @@ Statut : `Fait`.
   et refuse de s'appliquer si l'extension TimescaleDB manque.
 - Les révisions suivantes créent les tables liées à l'authentification :
   `app_user`, `login_attempt`, `audit_log` et `refresh_token`.
-- La révision `e6d2026091501` crée les six tables Data et déclare l'hypertable `reading`.
+- La révision `e6d2026091501` crée six des sept tables Data et déclare l'hypertable `reading`.
+- La révision `d3f1a2b7c904` ajoute `drift_report`, la septième.
 - La révision `c0adab96238c` ajoute les tables `password_reset_attempt`
   et `password_reset_token`.
 
@@ -261,8 +262,8 @@ Cette modélisation prend en compte :
 - leurs métadonnées JSON ;
 - les données de l'API Mock.
 
-Elle comprend six tables Data, depuis le stockage des mesures jusqu'aux recommandations proposées
-à l'utilisateur.
+Elle comprend sept tables Data, depuis le stockage des mesures jusqu'aux recommandations
+proposées à l'utilisateur, et jusqu'au suivi de la dérive du modèle.
 
 ### Schéma de données
 
@@ -286,11 +287,18 @@ Chaque table remplit un rôle précis dans le traitement et l'exploitation des d
 | `prediction` | Conserver les prévisions, leur période cible et la référence du modèle utilisé | Traitements ML d'EnerVision |
 | `alert` | Enregistrer les alertes, leur type, leur gravité et leur message | API Mock `/alerts` et détections EnerVision |
 | `recommendation` | Proposer des actions et expliquer la règle qui les motive | Règles métier d'EnerVision |
+| `drift_report` | Suivre l'écart entre prévisions et réalisé, par site et tous sites confondus | Surveillance de dérive d'EnerVision |
 
 Les anomalies historiques décrites dans les JSON sont conservées dans `dataset.metadata`.
 
 Elles servent à l'analyse des données et ne sont pas considérées comme des alertes actuelles.
 
+Les lignes de `drift_report` sont écrites par `app.monitoring.drift`, ordonnancé par le DAG
+`derive`. Une ligne dont le `site_id` est `NULL` porte le résultat global, tous sites confondus :
+c'est pourquoi l'unicité passe par un index sur `coalesce(site_id, '')` et non par une contrainte,
+qui ne dédoublonnerait jamais deux lignes globales. Le calcul, ses seuils et ce qu'il refuse de
+comparer sont dans l'[ADR 0011](../adr/0011-surveillance-de-derive-dans-le-backend.md).
+
 Les lignes de `recommendation` sont écrites par le moteur de règles du backend
 (`app/services/recommendation_rules.py`), déclenché par `POST /api/v1/recommendations/generate`,
 par `make recommendations`, ou par la seconde tâche du DAG `alertes`, à partir des alertes déjà en
@@ -304,6 +312,7 @@ n'ajoute aucune ligne.
 - Les mesures API ne sont pas rattachées à un dataset historique.
 - Une alerte peut être associée à une prévision du même site.
 - Une alerte peut donner lieu à plusieurs recommandations.
+- Un site possède plusieurs rapports de dérive ; un rapport global n'est rattaché à aucun site.
 
 ## Ingestion des données historiques