[EF-10] Le tableau de bord lit la zone or, plus les fixtures

marvin commented

2026-09-08 08:03:32 +00:00

Member

Exigence couverte

EF-10, EF-11, ENF-02, ENF-07

Épreuve servie

EC05 · Data, ETL et BI

Charge estimée

2 j.h

Ce qu'on veut obtenir

dashboard/repository.py rend le jeu figé de fixtures.py depuis le #94. La zone or est peuplée depuis le 07/09 — 358 687 mesures, 5 985 seaux horaires, 1 742 alertes, 7 lignes de qualité — et le tableau de bord affiche toujours des données inventées.

Ce ticket bascule les fonctions dont la source existe en base. Les trois qui dépendent de public.prevision et public.recommandation, vides, restent sur fixtures.

Critères d'acceptation

alertes, tracabilite_site, journal_collecte_site, serie_site et serie_parc lisent PostgreSQL ; aucune ne référence plus fixtures.
Le filtre par site visible est dans la requête SQL, pas appliqué après coup — c'est le contrôle d'accès à la ressource de l'ENF-02.
Les valeurs des courbes viennent de mesure_horaire et ne sont jamais recalculées par l'API ; le drapeau d'imputation, absent de l'agrégat, vient d'une jointure sur public.mesure (EF-04).
Methode porte ses quatre valeurs : sans measured, 89,5 % des lignes réelles font échouer la validation Pydantic.
La prévision est rendue null tant que rien ne la sert, et l'écran l'affiche « — » au lieu de planter.
Les tests unitaires tournent sans PostgreSQL : la connexion factice script ses réponses, la justesse du SQL relève de l'intégration.

Comment on le vérifie

Tests      tests/unit/api/test_dashboard_*.py
Commande   pytest tests/unit/api -v
Preuve     la suite complète au vert, et une capture du tableau de bord
           affichant les 1 742 alertes réelles du 07/09

Hors périmètre

sites(), synthese_parc() et recommandations_site() : elles portent prevision_kw, marge_kw, depassement_prevu et les recommandations, dont les tables sont vides. Elles suivront le #37 (service d'inférence) et l'écriture en base des règles du #39.

Le rattachement d'un type d'alerte à son exigence — spike, anomaly, outage — attend l'arbitrage du PO : les fixtures n'établissaient que threshold → EF-08 et sensor → EF-06, et le glossaire §4 décrit les cinq types sans les rattacher à quoi que ce soit.

### Exigence couverte EF-10, EF-11, ENF-02, ENF-07 ### Épreuve servie EC05 · Data, ETL et BI ### Charge estimée 2 j.h ### Ce qu'on veut obtenir `dashboard/repository.py` rend le jeu figé de `fixtures.py` depuis le #94. La zone or est peuplée depuis le 07/09 — 358 687 mesures, 5 985 seaux horaires, 1 742 alertes, 7 lignes de qualité — et le tableau de bord affiche toujours des données inventées. Ce ticket bascule les fonctions dont la source existe en base. Les trois qui dépendent de `public.prevision` et `public.recommandation`, vides, restent sur fixtures. ### Critères d'acceptation - [ ] `alertes`, `tracabilite_site`, `journal_collecte_site`, `serie_site` et `serie_parc` lisent PostgreSQL ; aucune ne référence plus `fixtures`. - [ ] Le filtre par site visible est dans la requête SQL, pas appliqué après coup — c'est le contrôle d'accès à la ressource de l'ENF-02. - [ ] Les valeurs des courbes viennent de `mesure_horaire` et ne sont jamais recalculées par l'API ; le drapeau d'imputation, absent de l'agrégat, vient d'une jointure sur `public.mesure` (EF-04). - [ ] `Methode` porte ses **quatre** valeurs : sans `measured`, 89,5 % des lignes réelles font échouer la validation Pydantic. - [ ] La prévision est rendue `null` tant que rien ne la sert, et l'écran l'affiche « — » au lieu de planter. - [ ] Les tests unitaires tournent sans PostgreSQL : la connexion factice script ses réponses, la justesse du SQL relève de l'intégration. ### Comment on le vérifie ``` Tests tests/unit/api/test_dashboard_*.py Commande pytest tests/unit/api -v Preuve la suite complète au vert, et une capture du tableau de bord affichant les 1 742 alertes réelles du 07/09 ``` ### Hors périmètre `sites()`, `synthese_parc()` et `recommandations_site()` : elles portent `prevision_kw`, `marge_kw`, `depassement_prevu` et les recommandations, dont les tables sont vides. Elles suivront le #37 (service d'inférence) et l'écriture en base des règles du #39. Le rattachement d'un type d'alerte à son exigence — `spike`, `anomaly`, `outage` — attend l'arbitrage du PO : les fixtures n'établissaient que `threshold` → EF-08 et `sensor` → EF-06, et le glossaire §4 décrit les cinq types sans les rattacher à quoi que ce soit.

marvin added this to the J3 — 11/09 livraison milestone

2026-09-08 08:03:32 +00:00

marvin self-assigned this

2026-09-08 08:03:32 +00:00

marvin added the

labels

2026-09-08 08:03:39 +00:00