[incident] Les courbes de consommation marquent tout un seau « reconstitué » dès une minute imputée #267

New issue

Open

opened 2026-09-10 13:38:57 +00:00 by marvin · 0 comments

marvin commented

2026-09-10 13:38:57 +00:00

Member

Symptôme observé

Sur la fiche d'un site et sur la courbe du parc, toutes les barres de consommation sortent hachurées « reconstitué (EF-04) », à toutes les fenêtres (24 h, 7 j, 30 j), alors que la quasi-totalité des minutes sont mesurées.

Constaté sur SITE005 (Hôpital Toulouse Purpan) : disponibilité 100,0 %, valeur courante « mesure directe », et pourtant 100 % des barres hachurées. L'exploitant lit « ce site n'est plus mesuré » là où il l'est.

Comment le reproduire

Ouvrir /sites/SITE005, période « 24 dernières heures », puis « 7 derniers jours ».
Chaque barre porte les hachures « reconstitué (EF-04) » ; aucune n'est en bleu plein « mesuré ».
En fenêtre 24 h, cliquer une barre : le panneau de traçabilité montre valeur brute = valeur retenue, méthode measured pour la plupart des minutes de l'heure.

Cause trouvée

services/api/enervision_api/dashboard/repository.py : les trois requêtes de série (SQL_SERIE_DIX_MINUTES, SQL_SERIE_HEURE, SQL_SERIE_JOUR) posaient imputee avec bool_or(methode_imputation in ('interpolated','forward_fill')) sur tout le seau. Une seule minute imputée sur 60 (barre horaire) ou sur 1 440 (barre journalière) marquait le seau entier. Un capteur légèrement instable mais à 100 % de disponibilité ressort donc « reconstitué » partout, à toutes les échelles.

Correction appliquée

Les requêtes remontent le nombre de minutes reconstituées du seau (count(*) filter (...)), et une fonction _seau_impute tranche : le seau est « reconstitué » quand ses minutes reconstituées atteignent au moins la moitié de ses minutes retenues (SEUIL_SEAU_IMPUTE = 0.5, constante unique). En deçà, la barre reste « mesuré » ; le détail minute par minute reste lisible dans l'infobulle et le panneau de traçabilité (EF-04). Le contrat de sortie (imputee: bool) et le front sont inchangés.

Critères de clôture

Un seau dont moins de la moitié des minutes retenues sont imputées sort imputee=false.
Un seau dont la moitié ou plus des minutes retenues sont imputées sort imputee=true.
Un seau sans aucune minute retenue (trou, #211) sort imputee=false.
Le seuil est une constante unique côté API, pas une valeur répétée par requête.
Les quatre fenêtres (3 h au pas dix minutes, 24 h au pas horaire, 7 j et 30 j au pas jour) appliquent la même règle.

Vérification

pytest tests/unit/api/test_dashboard_site_series.py -v — cas test_une_minute_imputee_isolee_ne_signale_pas_le_seau
pytest tests/integration/test_lectures_tableau_de_bord.py -v — cas paramétré test_le_seau_est_impute_a_partir_de_la_moitie_de_ses_minutes

Exigence

EF-04 — « la valeur brute et la méthode restent lisibles à côté de la série ». Épreuve EC05.

Temps perdu

0 h 45

## Symptôme observé Sur la fiche d'un site et sur la courbe du parc, toutes les barres de consommation sortent hachurées « reconstitué (EF-04) », à toutes les fenêtres (24 h, 7 j, 30 j), alors que la quasi-totalité des minutes sont mesurées. Constaté sur SITE005 (Hôpital Toulouse Purpan) : disponibilité 100,0 %, valeur courante « mesure directe », et pourtant 100 % des barres hachurées. L'exploitant lit « ce site n'est plus mesuré » là où il l'est. ## Comment le reproduire 1. Ouvrir `/sites/SITE005`, période « 24 dernières heures », puis « 7 derniers jours ». 2. Chaque barre porte les hachures « reconstitué (EF-04) » ; aucune n'est en bleu plein « mesuré ». 3. En fenêtre 24 h, cliquer une barre : le panneau de traçabilité montre `valeur brute = valeur retenue`, méthode `measured` pour la plupart des minutes de l'heure. ## Cause trouvée `services/api/enervision_api/dashboard/repository.py` : les trois requêtes de série (`SQL_SERIE_DIX_MINUTES`, `SQL_SERIE_HEURE`, `SQL_SERIE_JOUR`) posaient `imputee` avec `bool_or(methode_imputation in ('interpolated','forward_fill'))` sur tout le seau. Une seule minute imputée sur 60 (barre horaire) ou sur 1 440 (barre journalière) marquait le seau entier. Un capteur légèrement instable mais à 100 % de disponibilité ressort donc « reconstitué » partout, à toutes les échelles. ## Correction appliquée Les requêtes remontent le nombre de minutes reconstituées du seau (`count(*) filter (...)`), et une fonction `_seau_impute` tranche : le seau est « reconstitué » quand ses minutes reconstituées atteignent au moins la moitié de ses minutes retenues (`SEUIL_SEAU_IMPUTE = 0.5`, constante unique). En deçà, la barre reste « mesuré » ; le détail minute par minute reste lisible dans l'infobulle et le panneau de traçabilité (EF-04). Le contrat de sortie (`imputee: bool`) et le front sont inchangés. ## Critères de clôture - Un seau dont moins de la moitié des minutes retenues sont imputées sort `imputee=false`. - Un seau dont la moitié ou plus des minutes retenues sont imputées sort `imputee=true`. - Un seau sans aucune minute retenue (trou, #211) sort `imputee=false`. - Le seuil est une constante unique côté API, pas une valeur répétée par requête. - Les quatre fenêtres (3 h au pas dix minutes, 24 h au pas horaire, 7 j et 30 j au pas jour) appliquent la même règle. ## Vérification - `pytest tests/unit/api/test_dashboard_site_series.py -v` — cas `test_une_minute_imputee_isolee_ne_signale_pas_le_seau` - `pytest tests/integration/test_lectures_tableau_de_bord.py -v` — cas paramétré `test_le_seau_est_impute_a_partir_de_la_moitie_de_ses_minutes` ## Exigence EF-04 — « la valeur brute et la méthode restent lisibles à côté de la série ». Épreuve EC05. ## Temps perdu 0 h 45

marvin added the

labels

2026-09-10 13:39:05 +00:00

marvin referenced this issue from a commit

2026-09-10 14:03:25 +00:00

api : une barre de conso n'est « reconstituée » qu'à partir de la moitié de ses minutes (#267)

marvin referenced this issue from a commit