[37] Correctif job prevision #192
No reviewers
Labels
No labels
Compat/Breaking
EC01
EC02
EC03
EC04
EC05
EC06
Kind/BDD
Kind/Back
Kind/Bug
Kind/CICD
Kind/Cloud
Kind/Contenu
Kind/Data
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Front
Kind/IA
Kind/Infra
Kind/Monitoring
Kind/Security
Kind/Testing
Portée/Post-jury
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
ops/alerte
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
g2/enervision!192
Loading…
Reference in a new issue
No description provided.
Delete branch "justine/37-correctif-fenetre-entree"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
##Ce que ça change
La passe d'inférence exigeait ses 24 retards jusqu'à cible − 1 h, une heure que mesure_horaire ne matérialise jamais à temps (end_offset => 1 hour, dernier seau à 3 h 46 sur le serveur) : 7 sites écartés, 0 ligne, à chaque
passe. La fenêtre d'entrée se borne maintenant sur ce que l'agrégat rend vraiment — elle recule jusqu'à 6 h pour trouver 24 heures consécutives, même chiffre et même cause que FRAICHEUR_MAX de R2 — et journalise le décalage
retenu, par site dans la trace et en maximum dans le résumé.
Closes #37
##Preuve
La zone or telle que le serveur la rend (dernier seau matérialisé à 12:00 pour une cible 16:00), passée dans construire_entrees avec l'ancienne tolérance puis la nouvelle :
site SITE001 non prévu — retard manquant : aucune suite de 24 heures consécutives
avant 2026-09-08T16:00:00+00:00, même en reculant de 0 h — l'heure
2026-09-08T15:00:00+00:00 manque
site SITE002 non prévu — retard manquant : (idem)
tolerance 0 h -> 0 prévisibles, 2 écartés | décalages [] | dernière heure connue []
tolerance 6 h -> 2 prévisibles, 0 écartés | décalages [3, 3] | dernière heure connue
['2026-09-08T12:00:00+00:00', ...]
Le résumé de passe correspondant : … 2 sites prévisibles, 0 écartés, décalage max 3 h (toléré 6 h).
Relecture
Ce qui suit le code
docs/runbooks/mis à jour, un geste d'exploitation a changédocs/adr/complété, une décision structurante a été prisedocs/journal.mdcomplété, un incident a été rencontré.env.exampleOù regarder en priorité
Le décalage renomme implicitement les colonnes du modèle. À décalage 3, le modèle reçoit t−4 … t−27 sous les noms retard_1h_kw … retard_24h_kw qu'il a appris. J'ai gardé Entree.retards nominal — le changer ferait lever
model.reference.persistance, qui va chercher le retard 1, et renommerait des colonnes que le modèle enregistré attend. Le décalage vit dans son propre champ et part dans la trace. C'est le compromis du ticket : le modèle est
servi sur des entrées plus vieilles que celles qu'il a apprises, et le seul garde-fou est qu'on le voit.
Deux autres points : tolerance_h est un mot-clé sans défaut (la valeur qui allait de soi était zéro, et c'est elle qui a causé la panne) ; et le décalage se cherche site par site, pour qu'un collecteur muet sur un site ne
vieillisse pas les entrées de tous les autres.
Approuvée. J'ai éprouvé le correctif contre
enervision_prod, à l'instant, plutôt que de relire le raisonnement :Les sept sites trouvent leurs vingt-quatre heures consécutives à décalage 3, sur une tolérance de 6. La passe écrira, et il reste trois heures de marge pour absorber un cycle de rafraîchissement manqué. À décalage 0, aucun site ne passait : c'est bien la panne structurelle que tu décris, pas un aléa.
Ce qui fait la qualité de ce correctif
retardsreste la liste nominale. C'est le point où je m'attendais à trouver le défaut, et il est traité : y écrire les retards effectifs aurait renommé les colonnes que le modèle enregistré attend, et fait leverreference.persistancequi va chercher le retard 1. Le décalage vit à côté, dans son propre champ.tolerance_hn'a pas de valeur par défaut. C'est la meilleure décision du lot : la valeur qui allait de soi était zéro, et c'est précisément elle qui rendait la passe muette sans que rien dans la signature ne le dise. Chaque appelant nomme maintenant ce qu'il tolère.Le décalage est tracé, par site et en maximum. Un modèle servi sur
t−5…t−29alors qu'il a apprist−1…t−24se dégrade en silence. Le silence est ce que tu refuses, pas le décalage, et c'est la bonne façon de poser le compromis.Le décalage se cherche site par site. Un site à jour n'est pas puni du retard d'un autre. Ça n'a l'air de rien et ça évite qu'un seul site en panne fasse taire les six autres.
Une chose à surveiller après la mise en production
R1 juge la fraîcheur de la prévision sur l'instant visé, pas sur ses entrées, avec deux heures de tolérance. Une prévision produite à décalage 5 ou 6 restera donc acceptable pour R1 alors qu'elle repose sur des heures nettement plus vieilles. Ce n'est pas un défaut de ce correctif, c'est la limite du découpage, et ta note de config le dit déjà. À regarder si le décalage observé grimpe au-delà de 3.
Rien ne bloque. Dès que la chaîne est verte, elle part en production avec le reste : c'est le dernier point qui empêchait
public.previsionde se remplir, et donc EF-07 et EF-08 d'être tenues sur le serveur.