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

Merged
gabriel merged 1 commit from lenaic/257-courbe-dix-minutes into develop 2026-09-09 22:00:56 +00:00
Owner

Ce que ça change

La donnée est à la minute, l'écran ne savait la montrer qu'à l'heure. Une
quatrième fenêtre, 3h au pas 10min, lit public.mesure au lieu de
l'agrégat horaire. Et la prévision de l'heure suivante est tracée au lieu
d'être seulement écrite sous la courbe.

Closes #257

Preuve

L'écart constaté ce soir en production, à 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)

Une heure ne se résume pas avant d'être finie : ce n'est pas un retard de la
chaîne, c'est l'absence d'une fenêtre plus fine.

243 cas API          14 bancs tests/ci
514 cas front        mypy --strict : 0
ruff : 0             construction Vite : OK

Huit cas ajoutés, quatre de chaque côté.

Relecture

  • Un pair a relu et laissé un commentaire, même court
  • Ses remarques sont traitées, ou une réponse explique pourquoi elles ne le sont pas

Où regarder en priorité

1. La fenêtre courte ne lit PAS le même endroit que les trois autres.
mesure_horaire ne matérialise que des heures complètes, il ne peut donc rien
dire des trois dernières heures — c'est le manque même. La requête lit
public.mesure, la minute, celle que la tuile de consommation affiche déjà.
Les deux sources doivent dire la même chose ; si elles divergent, c'est là qu'il
faut regarder.

2. date_bin et non date_trunc, qui ne sait pas tronquer à dix minutes.
La grille est ancrée sur l'époque : les seaux tombent sur les minutes rondes
quelle que soit l'heure de la requête, donc deux appels à une minute d'écart
rendent les mêmes bornes. Sans ancre, la grille glisserait avec l'horloge.

3. Deux pièges trouvés en chemin, hors énoncé.

  • Le dénominateur de « N points sur M » venait d'un enchaînement de ternaires
    qui supposait qu'un pas vaut l'heure ou le jour. Il aurait annoncé 24 pour
    une fenêtre qui en porte 18. Remplacé par une table, où une fenêtre ajoutée
    sans sa ligne lève au lieu de mentir.
  • La construction des points était recopiée pour chaque requête. Une troisième
    copie aurait fini par diverger sur le traitement du nul, qui est justement ce
    qu'il ne faut pas rater. Factorisée.

4. La teinte de la prévision est un violet, pas un troisième bleu. Le
mesuré et le reconstitué sont deux bleus voisins ; un troisième bleu se
confondrait avec eux pour une deutéranopie avant de s'en distinguer. À
contredire si le socle visuel a une autre idée — c'est la seule couleur de ce
lot qui ne vienne pas de jetons.css.

5. L'écran Comparer n'ouvre pas la fenêtre courte. Sept sites sur trois
heures donneraient cent vingt-six barres groupées. Même raison que les 24 h
exclues au #184, en pire.

6. Le défaut de la vue Parc reste 24 h. « 3 h » ouvre la liste parce que le
sélecteur se lit du court au long, mais la vue Parc répond à « quelle est la
forme du parc », pas à « que fait-il en ce moment ». À contredire si vous
préférez qu'elle ouvre sur la fenêtre courte.

Ce qui n'est pas là

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 #117is null interdit
toute réécriture. À traiter à part, en bordant d'abord cette recopie.

## Ce que ça change La donnée est à la minute, l'écran ne savait la montrer qu'à l'heure. Une quatrième fenêtre, `3h` au pas `10min`, lit `public.mesure` au lieu de l'agrégat horaire. Et la prévision de l'heure suivante est **tracée** au lieu d'être seulement écrite sous la courbe. Closes #257 ## Preuve L'écart constaté ce soir en production, à 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) ``` Une heure ne se résume pas avant d'être finie : ce n'est pas un retard de la chaîne, c'est l'absence d'une fenêtre plus fine. ``` 243 cas API 14 bancs tests/ci 514 cas front mypy --strict : 0 ruff : 0 construction Vite : OK ``` Huit cas ajoutés, quatre de chaque côté. ## Relecture - [ ] Un pair a relu et laissé un commentaire, même court - [ ] Ses remarques sont traitées, ou une réponse explique pourquoi elles ne le sont pas ## Où regarder en priorité **1. La fenêtre courte ne lit PAS le même endroit que les trois autres.** `mesure_horaire` ne matérialise que des heures complètes, il ne peut donc rien dire des trois dernières heures — c'est le manque même. La requête lit `public.mesure`, la minute, celle que la tuile de consommation affiche déjà. Les deux sources doivent dire la même chose ; si elles divergent, c'est là qu'il faut regarder. **2. `date_bin` et non `date_trunc`**, qui ne sait pas tronquer à dix minutes. La grille est ancrée sur l'époque : les seaux tombent sur les minutes rondes quelle que soit l'heure de la requête, donc deux appels à une minute d'écart rendent les mêmes bornes. Sans ancre, la grille glisserait avec l'horloge. **3. Deux pièges trouvés en chemin, hors énoncé.** - Le dénominateur de « N points sur M » venait d'un enchaînement de ternaires qui supposait qu'un pas vaut l'heure ou le jour. Il aurait annoncé 24 pour une fenêtre qui en porte 18. Remplacé par une table, où une fenêtre ajoutée sans sa ligne lève au lieu de mentir. - La construction des points était recopiée pour chaque requête. Une troisième copie aurait fini par diverger sur le traitement du nul, qui est justement ce qu'il ne faut pas rater. Factorisée. **4. La teinte de la prévision est un violet, pas un troisième bleu.** Le mesuré et le reconstitué sont deux bleus voisins ; un troisième bleu se confondrait avec eux pour une deutéranopie avant de s'en distinguer. À contredire si le socle visuel a une autre idée — c'est la seule couleur de ce lot qui ne vienne pas de `jetons.css`. **5. L'écran Comparer n'ouvre pas la fenêtre courte.** Sept sites sur trois heures donneraient cent vingt-six barres groupées. Même raison que les 24 h exclues au #184, en pire. **6. Le défaut de la vue Parc reste 24 h.** « 3 h » ouvre la liste parce que le sélecteur se lit du court au long, mais la vue Parc répond à « quelle est la forme du parc », pas à « que fait-il en ce moment ». À contredire si vous préférez qu'elle ouvre sur la fenêtre courte. ## Ce qui n'est pas là 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 — `is null` interdit toute réécriture. À traiter à part, en bordant d'abord cette recopie.
front+api : une fenêtre de trois heures au pas de dix minutes, et la prévision tracée (#257)
All checks were successful
Intégration / Contrôles statiques du dépôt (pull_request) Successful in 10s
Intégration / Terraform — format, validité et lint (pull_request) Successful in 18s
Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 47s
Intégration / Checkov — audit de la configuration (pull_request) Successful in 18s
Intégration / Workflows — lint et audit de sécurité (pull_request) Successful in 16s
Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 5m58s
be2c065efe
La donnée est à la minute et fraîche de moins de dix minutes ; l'écran ne
savait la montrer qu'à l'heure. Il y avait 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. Mesuré à 23 h 37 : dernière minute 23:29, dernier seau
horaire 22: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'avait aucune fenêtre plus fine.

UNE QUATRIÈME FENÊTRE, `3h`, AU PAS `10min`. Elle est la seule servie depuis
`public.mesure` et non depuis `mesure_horaire` : l'agrégat ne matérialise que
des heures complètes, il ne peut donc rien dire des trois dernières heures,
et c'est précisément le manque. Elle lit la minute, celle que la tuile de
consommation affiche déjà.

`date_bin` et non `date_trunc`, qui ne sait pas tronquer à dix minutes. La
grille est ancrée sur l'époque : les seaux tombent sur les minutes rondes quelle
que soit l'heure de la requête, et deux appels à une minute d'écart rendent les
mêmes bornes. `avg` ignore les nulls, donc un seau entièrement vide rend `null`
et le front y creuse un trou, exactement comme au pas horaire depuis le #211.

LA PRÉVISION EST TRACÉE, plus seulement écrite sous la courbe. Elle existait
dans le contrat et s'affichait en texte ; un exploitant qui regardait la forme
voyait d'où le site venait, jamais où il va. Elle porte l'instant qu'elle VISE,
donc elle se place d'elle-même au bon endroit de l'axe. Teinte propre, un
violet franc : le mesuré et le reconstitué sont deux bleus voisins, et deux
bleus se confondent avant de se distinguer d'un violet pour une deutéranopie.
Un clic dessus n'ouvre pas la traçabilité — elle n'a pas encore eu lieu.

DEUX PIÈGES TROUVÉS EN CHEMIN.

Le dénominateur de « N points sur M » venait d'un enchaînement de ternaires qui
supposait qu'un pas vaut l'heure ou le jour. Il aurait annoncé 24 pour une
fenêtre qui en porte 18. Remplacé par une table : une fenêtre ajoutée sans sa
ligne lève au lieu de mentir.

La construction des points était recopiée à l'identique pour chaque requête.
Une troisième copie aurait fini par diverger sur le traitement du nul, qui est
justement ce qu'il ne faut pas rater. Factorisée.

L'écran Comparer n'ouvre pas la fenêtre courte : sept sites sur trois heures
donneraient cent vingt-six barres groupées. Même raison que les 24 h exclues
au #184, en pire.

Éprouvé : quatre cas API et quatre cas front, 243 cas API, 514 cas front,
quatorze bancs de chaîne, mypy strict, ruff, construction Vite.

Hors périmètre, comme le dit le ticket : rendre l'heure EN COURS dans les
fenêtres horaires, qui demande `materialized_only = false` et figerait une
heure partielle comme réalisé définitif dans la recopie du #117.
lenaic requested review from gabriel 2026-09-09 21:57:30 +00:00
gabriel approved these changes 2026-09-09 22:00:48 +00:00
gabriel merged commit a8072f8520 into develop 2026-09-09 22:00:56 +00:00
gabriel deleted branch lenaic/257-courbe-dix-minutes 2026-09-09 22:00:56 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
g2/enervision!258
No description provided.