La prévision annoncée H+1 travaille en réalité à trois heures d'écart

lenaic commented

2026-09-08 13:03:30 +00:00

Owner

Exigence couverte

EF-07 · Prévision de la consommation à l'heure suivante. EF-04 · série exploitable. ENF-08 · observabilité.

Épreuve servie

EC06 · IA et automatisation

Charge estimée

une demi-journée

Ce qu'on veut obtenir

La prévision H+1 ne dispose jamais de l'heure précédente. Mesuré en production le 08/09 à 12 h 58 :

maintenant                       12:58
dernier seau de mesure_horaire   10:00     179 minutes de retard
prévision émise à 12:35, visant  13:00

Le modèle porte une colonne retard_1h_kw censée contenir la moyenne de l'heure précédant la cible. Elle contient en fait celle de 10 h pour prédire 13 h. C'est un H+3 étiqueté H+1.

Ce n'est pas une panne : c'est la somme de trois délais, tous voulus séparément, jamais additionnés sur une feuille.

Où passe le temps

Un seau H:00 se referme à (H+1):00. Il devient lisible à (H+2):00.

end_offset => interval '1 hour' (migration 0016) : à chaque passage, la fenêtre s'arrête une heure avant maintenant. Un seau clos à (H+1):00 n'entre donc dans la fenêtre qu'au passage de (H+2):00.
schedule_interval => interval '1 hour' : ce passage n'a lieu qu'une fois par heure, d'où une oscillation entre 2 h et 3 h selon le moment où on regarde.
La chaîne ETL horaire (:00, :17, :27) : les minutes de l'heure H n'arrivent dans public.mesure qu'à (H+1):27. Ce délai-là est absorbé aujourd'hui, parce que le rafraîchissement passe encore plus tard. Il redeviendra bloquant dès qu'on accélérera le reste.

Le plancher

Une prévision émise AVANT le début de l'heure visée ne pourra jamais utiliser l'heure qui la précède immédiatement, puisque celle-ci est encore en train de se remplir. Le meilleur atteignable est donc deux seaux d'écart, pas un.

On peut passer de trois ou quatre seaux à deux. Aller jusqu'à un seul exigerait d'émettre la prévision APRÈS le début de l'heure visée, ce qui échange l'avance contre la précision. Cet arbitrage-là n'est pas tranché ici : il est posé pour EC06.

Ce que ça coûte aujourd'hui

L'ADR 0013 note que le modèle perd contre la persistance sur SITE003, 10,11 contre 5,67. Un exercice à trois heures d'écart est nettement plus dur qu'un exercice à une heure, pour le modèle comme pour la référence. La comparaison reste valide, les deux subissent le même écart, mais la performance annoncée n'est pas celle du problème qu'on croit résoudre.

Critères d'acceptation

La cadence ETL passe de l'heure au quart d'heure : silver à :00 :15 :30 :45, gold et load décalés derrière, verrou flock conservé
Une migration remplace la politique de mesure_horaire : end_offset à 15 minutes, schedule_interval à 15 minutes, start_offset inchangé à 3 jours
Le seau clos à (H+1):00 est lisible au plus tard à (H+1):15, vérifié en production
Le commentaire de la 0016 qui justifie end_offset => 1 hour est réécrit : il explique pourquoi une heure était prudent et pourquoi le quart d'heure suffit maintenant que le chargement est plus rapide
Aucun seau incomplet n'est matérialisé : la fenêtre ne retient que les seaux entièrement contenus
prevoir.sh et recommandations-hourly.sh restent horaires, leur décalage derrière le chargement est revérifié
Le retard mesuré est publié en métrique et lisible dans Grafana, pour qu'une régression se voie

Comment on le vérifie

Avant et après, la même requête en production :

select now(), max(heure), round(extract(epoch from (now() - max(heure)))/60) as retard_min
  from public.mesure_horaire where moyenne_kw is not null;

Attendu après : moins de 80 minutes en tout point de l'heure, contre 120 à 180 aujourd'hui.

Puis, sur la prévision suivante, contrôler que reference_kw reprend bien le seau H-2 de la cible et non H-3 ou H-4.

Hors périmètre

Le choix d'émettre la prévision avant ou après le début de l'heure visée. C'est un arbitrage produit, il appartient à EC06 et se tranche avec Justine et Olivier.

Le rafraîchissement automatique de l'écran, qui est le #196. Une donnée plus fraîche derrière une page qu'il faut recharger à la main ne se voit qu'à moitié.

### Exigence couverte EF-07 · Prévision de la consommation à l'heure suivante. EF-04 · série exploitable. ENF-08 · observabilité. ### Épreuve servie EC06 · IA et automatisation ### Charge estimée une demi-journée ### Ce qu'on veut obtenir La prévision H+1 ne dispose jamais de l'heure précédente. Mesuré en production le 08/09 à 12 h 58 : ``` maintenant 12:58 dernier seau de mesure_horaire 10:00 179 minutes de retard prévision émise à 12:35, visant 13:00 ``` Le modèle porte une colonne `retard_1h_kw` censée contenir la moyenne de l'heure précédant la cible. Elle contient en fait celle de 10 h pour prédire 13 h. **C'est un H+3 étiqueté H+1.** Ce n'est pas une panne : c'est la somme de trois délais, tous voulus séparément, jamais additionnés sur une feuille. **Où passe le temps** Un seau `H:00` se referme à `(H+1):00`. Il devient lisible à `(H+2):00`. - `end_offset => interval '1 hour'` (migration 0016) : à chaque passage, la fenêtre s'arrête une heure avant maintenant. Un seau clos à `(H+1):00` n'entre donc dans la fenêtre qu'au passage de `(H+2):00`. - `schedule_interval => interval '1 hour'` : ce passage n'a lieu qu'une fois par heure, d'où une oscillation entre 2 h et 3 h selon le moment où on regarde. - La chaîne ETL horaire (`:00`, `:17`, `:27`) : les minutes de l'heure `H` n'arrivent dans `public.mesure` qu'à `(H+1):27`. Ce délai-là est absorbé aujourd'hui, parce que le rafraîchissement passe encore plus tard. Il redeviendra bloquant dès qu'on accélérera le reste. **Le plancher** Une prévision émise AVANT le début de l'heure visée ne pourra jamais utiliser l'heure qui la précède immédiatement, puisque celle-ci est encore en train de se remplir. Le meilleur atteignable est donc deux seaux d'écart, pas un. On peut passer de trois ou quatre seaux à deux. Aller jusqu'à un seul exigerait d'émettre la prévision APRÈS le début de l'heure visée, ce qui échange l'avance contre la précision. Cet arbitrage-là n'est pas tranché ici : il est posé pour EC06. **Ce que ça coûte aujourd'hui** L'ADR 0013 note que le modèle perd contre la persistance sur SITE003, 10,11 contre 5,67. Un exercice à trois heures d'écart est nettement plus dur qu'un exercice à une heure, pour le modèle comme pour la référence. La comparaison reste valide, les deux subissent le même écart, mais la performance annoncée n'est pas celle du problème qu'on croit résoudre. ### Critères d'acceptation - [ ] La cadence ETL passe de l'heure au quart d'heure : `silver` à `:00 :15 :30 :45`, `gold` et `load` décalés derrière, verrou `flock` conservé - [ ] Une migration remplace la politique de `mesure_horaire` : `end_offset` à 15 minutes, `schedule_interval` à 15 minutes, `start_offset` inchangé à 3 jours - [ ] Le seau clos à `(H+1):00` est lisible au plus tard à `(H+1):15`, vérifié en production - [ ] Le commentaire de la 0016 qui justifie `end_offset => 1 hour` est réécrit : il explique pourquoi une heure était prudent et pourquoi le quart d'heure suffit maintenant que le chargement est plus rapide - [ ] Aucun seau incomplet n'est matérialisé : la fenêtre ne retient que les seaux entièrement contenus - [ ] `prevoir.sh` et `recommandations-hourly.sh` restent horaires, leur décalage derrière le chargement est revérifié - [ ] Le retard mesuré est publié en métrique et lisible dans Grafana, pour qu'une régression se voie ### Comment on le vérifie Avant et après, la même requête en production : ```sql select now(), max(heure), round(extract(epoch from (now() - max(heure)))/60) as retard_min from public.mesure_horaire where moyenne_kw is not null; ``` Attendu après : moins de 80 minutes en tout point de l'heure, contre 120 à 180 aujourd'hui. Puis, sur la prévision suivante, contrôler que `reference_kw` reprend bien le seau `H-2` de la cible et non `H-3` ou `H-4`. ### Hors périmètre Le choix d'émettre la prévision avant ou après le début de l'heure visée. C'est un arbitrage produit, il appartient à EC06 et se tranche avec Justine et Olivier. Le rafraîchissement automatique de l'écran, qui est le #196. Une donnée plus fraîche derrière une page qu'il faut recharger à la main ne se voit qu'à moitié.

lenaic added the

labels

2026-09-08 13:03:30 +00:00

lenaic self-assigned this

2026-09-08 13:03:30 +00:00

lenaic referenced this issue from a commit