fix(ml,backend,frontend): borne la peremption des predictions et isole les erreurs par flux

docs/architecture/00-vue-ensemble.md

@@ -75,7 +75,7 @@ collecteur ne vient le lire.
 | Domaine | Technologie | Emplacement | Statut | Ce qui existe réellement |
 |---|---|---|---|---|
 | Backend | FastAPI, Python 3.14 | `apps/backend` | `En cours` | Factory, configuration, journalisation, 2 sondes de santé, `/metrics`, contrat OpenAPI versionné, routes `sites`, `alerts`, `recommendations`, `stats/summary`, `readings`, `sensors/status` et `predictions` en lecture (endpoints → services → repositories → models) |
-| Frontend | Angular 22, Node 24 | `apps/frontend` | `En cours` | Tableau de bord sur route `/dashboard`, deux services HTTP, graphiques Chart.js, données servies par des fixtures |
+| Frontend | Angular 22, Node 24 | `apps/frontend` | `En cours` | Tableau de bord sur route `/dashboard`, authentification complète (garde de route, intercepteur de jeton), cinq services HTTP, graphiques Chart.js. `stats`/`alerts` sur fixtures, `predictions` branché sur l'API réelle |
 | Base | PostgreSQL 17 + TimescaleDB | `db` | `Fait` | Bootstrap de l'extension, base de test, chaîne Alembic. Schéma applicatif créé (`site`, `dataset`, `reading` en hypertable, `prediction`, `alert`, `recommendation`) |
 | ML | LightGBM, MLflow | `ml` | `En cours` | Pipeline d'entraînement et de scoring (`enervision_ml.train`/`.score`, features par lags/moyennes glissantes partagées entre les deux, baseline de persistance saisonnière, suivi MLflow local), exposé en lecture via `GET /predictions`. Voir [ADR 0005](../adr/0005-modele-prediction-lightgbm.md) et [ML-START.md](../../ML-START.md). Automatisation (Airflow) et surveillance de dérive (EC06, #44/#45) pas encore construites |
 | Infra | Terraform, k3s single-node | `infra/terraform` | `En cours` | Module d'installation du cluster. Jamais appliqué, aucune ressource Kubernetes déclarée |

docs/architecture/20-backend.md

@@ -205,19 +205,6 @@ par exemple `limit` hors bornes). Un datetime sans fuseau dans `start`/`end` est
 l'UTC plutôt que rejeté : le comparer tel quel à `reading.timestamp` (`timestamptz`) échouerait
 côté pilote, en `500` plutôt qu'un refus propre.
 
-`GET /readings` reprend le même gabarit mais s'en écarte sur un point : `reading` est l'hypertable,
-donc la seule table métier pouvant porter des années d'historique, ce que `docs/architecture/
-owasp-traceabilite.md` documentait comme un risque ouvert (API4, aucune pagination plafonnée ni
-fenêtre temporelle maximale). `ReadingService` porte donc une couche de validation absente des
-autres routes de lecture : `start`/`end` sont optionnels (24 dernières heures par défaut si les
-deux sont omis, l'un défaut par rapport à l'autre sinon), l'écart entre les deux est plafonné à 90
-jours (`FENETRE_MAXIMALE`), et `limit`/`offset` (défaut 500, plafond 2000) empêchent qu'une fenêtre
-large mais peu dense reste malgré tout coûteuse. Un dépassement de plafond répond `400` (règle
-métier, portée par le service) plutôt que `422` (réservé à la validation structurelle de FastAPI,
-par exemple `limit` hors bornes). Un datetime sans fuseau dans `start`/`end` est traité comme de
-l'UTC plutôt que rejeté : le comparer tel quel à `reading.timestamp` (`timestamptz`) échouerait
-côté pilote, en `500` plutôt qu'un refus propre.
-
 ### `/health/ready`
 
 Cette sonde porte une garde décrite dans l'[ADR 0001](../adr/0001-postgresql-timescaledb.md) : un

docs/architecture/30-frontend.md

@@ -31,10 +31,11 @@ Ce qui est en place :
 
 Ce qui n'existe pas encore :
 
-- **Aucun endpoint métier réel derrière l'écran du tableau de bord.** `GET /api/v1/stats/summary`,
-  `GET /api/v1/alerts` et `GET /api/v1/predictions` sont servis par l'intercepteur de fixtures ;
-  l'API expose bien ces routes désormais, mais rien ne bascule `useMockFixtures` à `false` en
-  développement pour les consommer réellement.
+- **`stats`/`alerts` restent sur fixtures.** `GET /api/v1/stats/summary` et `GET /api/v1/alerts`
+  sont servis par l'intercepteur de fixtures ; l'API expose bien ces routes désormais, mais rien
+  ne bascule `useMockFixtures` à `false` en développement pour les consommer réellement.
+  `GET /api/v1/predictions` fait exception : jamais mocké, branché sur l'API réelle depuis cette
+  PR (voir plus bas).
 - Aucun état de chargement : tant que la première réponse n'est pas arrivée, la page reste vide.
 - Aucun lint : ESLint n'est pas installé.
 
@@ -85,10 +86,12 @@ sequenceDiagram
   S-->>C: modèle typé
 ```
 
-`mockApiInterceptor` n'intercepte que `/stats/summary`, `/alerts` et `/predictions`, et seulement
-si `environment.useMockFixtures` est vrai. Le drapeau est à `true` en développement, à `false` en
-production : toute autre requête (dont tout ce qui touche `/auth`), et toutes les requêtes en
-production, suivent le chemin réel.
+`mockApiInterceptor` n'intercepte que `/stats/summary` et `/alerts`, et seulement si
+`environment.useMockFixtures` est vrai. Le drapeau est à `true` en développement, à `false` en
+production : toute autre requête, et toutes les requêtes en production, suivent le chemin réel.
+`/predictions` est volontairement exclu de cette liste (contrairement à `stats`/`alerts`) : il
+suit toujours le chemin réel, comme `/auth/*` - en développement, ça veut dire qu'un jeton valide
+et un backend joignable sont nécessaires pour que la section prévisions du dashboard s'affiche.
 
 En développement, `proxy.conf.json` redirige tout `/api` vers `http://localhost:8000`. C'est ce
 qui évite le CORS sur le poste, et c'est pourquoi `environment.development.ts` se contente d'un