Front : la donnée est à la minute, la courbe ne sait la montrer qu'à l'heure #257

New issue

Closed

opened 2026-09-09 21:45:28 +00:00 by lenaic · 0 comments

lenaic commented

2026-09-09 21:45:28 +00:00

Owner

Exigence couverte

EF-11 · vue d'un site. EF-07 · la prévision et sa référence restent lisibles à côté du réalisé.

Épreuve servie

EC05 · Data, ETL et BI

Charge estimée

une demi-journée

Ce qu'on veut obtenir

La donnée est à la minute et fraîche de moins de dix minutes ; l'écran, lui,
ne sait la montrer qu'à l'heure. Il y a donc en permanence un écart entre la
tuile de consommation et le dernier bâton de la courbe, entre dix minutes et
une heure et demie selon le moment où l'on regarde.

Mesuré ce soir, à 23 h 37 heure de Paris :

dernière minute mesurée   23:29   (9 min)
dernier seau horaire      22:00   (couvre 22:00-23:00)

Ce n'est pas un retard de la chaîne : une heure ne se résume pas avant d'être
finie. C'est que l'écran n'a aucune fenêtre plus fine qu'une heure. L'API
n'expose que 24h, 7j et 30j, aux pas 1h et 1j, alors que
public.mesure porte la minute et que la tuile de consommation la lit déjà.

Deuxième manque, sur la même courbe : la prévision de l'heure suivante existe
dans le contrat (SerieSiteOut.prevision) et s'affiche en texte sous le
graphique. Elle n'est pas tracée. Un exploitant qui regarde la forme ne voit
pas où elle va.

Critères d'acceptation

Une fenêtre 3h au pas 10min, servie depuis public.mesure et non
depuis l'agrégat horaire
Elle apparaît dans le sélecteur de période, à côté de 24 h, 7 j et 30 j
Les seaux de dix minutes sans aucune valeur rendent null, comme les
seaux horaires depuis le #211 — un trou se creuse, il ne se comble pas
La prévision de l'heure suivante est TRACÉE au-delà du dernier point
mesuré, dans une teinte distincte, et la légende la nomme
La teinte de la prévision se distingue de celle du mesuré et de celle du
reconstitué, aux trois contrastes du socle visuel
Le pas 10min ne change rien aux trois fenêtres existantes

Comment on le vérifie

tests/unit/api/test_dashboard_site_series.py : la fenêtre 3h rend 18 points
au pas de dix minutes, un seau vide rend null, et les fenêtres existantes
gardent leur pas.

services/dashboard/tests/unit/ : le sélecteur porte quatre périodes, la série
tracée comporte un jeu de prévision distinct, et sa teinte n'est ni celle du
mesuré ni celle du reconstitué.

À l'écran, sur un site quelconque : l'écart entre la tuile de consommation et
le dernier point de la courbe tombe sous dix minutes.

Hors périmètre

Rendre l'heure EN COURS dans les fenêtres horaires. Cela demande
materialized_only = false sur l'agrégat continu, ce qui figerait une heure
partielle comme réalisé définitif dans la recopie du #117. À traiter à part,
en bordant d'abord cette recopie.

Changer la cadence de la chaîne. Elle est aux dix minutes depuis le #246 et
c'est ce qui rend ce ticket possible.

### Exigence couverte EF-11 · vue d'un site. EF-07 · la prévision et sa référence restent lisibles à côté du réalisé. ### Épreuve servie EC05 · Data, ETL et BI ### Charge estimée une demi-journée ### Ce qu'on veut obtenir La donnée est à la minute et fraîche de moins de dix minutes ; l'écran, lui, ne sait la montrer qu'à l'heure. Il y a donc en permanence un écart entre la tuile de consommation et le dernier bâton de la courbe, entre dix minutes et une heure et demie selon le moment où l'on regarde. Mesuré ce soir, à 23 h 37 heure de Paris : ``` dernière minute mesurée 23:29 (9 min) dernier seau horaire 22:00 (couvre 22:00-23:00) ``` Ce n'est pas un retard de la chaîne : une heure ne se résume pas avant d'être finie. C'est que **l'écran n'a aucune fenêtre plus fine qu'une heure**. L'API n'expose que `24h`, `7j` et `30j`, aux pas `1h` et `1j`, alors que `public.mesure` porte la minute et que la tuile de consommation la lit déjà. Deuxième manque, sur la même courbe : la prévision de l'heure suivante existe dans le contrat (`SerieSiteOut.prevision`) et s'affiche **en texte** sous le graphique. Elle n'est pas tracée. Un exploitant qui regarde la forme ne voit pas où elle va. ### Critères d'acceptation - [ ] Une fenêtre `3h` au pas `10min`, servie depuis `public.mesure` et non depuis l'agrégat horaire - [ ] Elle apparaît dans le sélecteur de période, à côté de 24 h, 7 j et 30 j - [ ] Les seaux de dix minutes sans aucune valeur rendent `null`, comme les seaux horaires depuis le #211 — un trou se creuse, il ne se comble pas - [ ] La prévision de l'heure suivante est TRACÉE au-delà du dernier point mesuré, dans une teinte distincte, et la légende la nomme - [ ] La teinte de la prévision se distingue de celle du mesuré et de celle du reconstitué, aux trois contrastes du socle visuel - [ ] Le pas `10min` ne change rien aux trois fenêtres existantes ### Comment on le vérifie `tests/unit/api/test_dashboard_site_series.py` : la fenêtre `3h` rend 18 points au pas de dix minutes, un seau vide rend `null`, et les fenêtres existantes gardent leur pas. `services/dashboard/tests/unit/` : le sélecteur porte quatre périodes, la série tracée comporte un jeu de prévision distinct, et sa teinte n'est ni celle du mesuré ni celle du reconstitué. À l'écran, sur un site quelconque : l'écart entre la tuile de consommation et le dernier point de la courbe tombe sous dix minutes. ### Hors périmètre Rendre l'heure EN COURS dans les fenêtres horaires. Cela demande `materialized_only = false` sur l'agrégat continu, ce qui figerait une heure partielle comme réalisé définitif dans la recopie du #117. À traiter à part, en bordant d'abord cette recopie. Changer la cadence de la chaîne. Elle est aux dix minutes depuis le #246 et c'est ce qui rend ce ticket possible.

lenaic referenced this issue from a pull request that will close it,

2026-09-09 21:57:22 +00:00

front+api : une fenêtre de trois heures au pas de dix minutes, et la prévision tracée #258

lenaic referenced this issue from a commit

2026-09-09 21:57:24 +00:00

front+api : une fenêtre de trois heures au pas de dix minutes, et la prévision tracée (#257)