contracts : le contrat de prévision H+1 et sa référence publiée #161

Merged

justine merged 4 commits from lenaic/36-contrat-prevision into develop 2026-09-07 11:23:05 +00:00

Conversation 3 Commits 4 Files changed 10 +834 -2

lenaic commented 2026-09-06 16:02:22 +00:00

Owner

Copy link

contracts : le contrat de prévision H+1 et sa référence en base

Rien n'écrit public.prevision. La table est posée depuis la 0011 et aucun
insert du dépôt ne la vise ; services/inference/ porte un README.md de
trois lignes et packages/contracts/ était vide. L'API sert donc une prévision
de jeu et calcule l'EF-08 dessus.

Ce qui manque d'abord n'est pas un modèle, c'est ce qui permet à celui qui le
produira et à celui qui le servira d'avancer sans s'attendre.

Cette fiche est « proposée », et elle le reste

L'ADR 0012 met les options devant les titulaires du #36 et du #37 au lieu
de trancher à leur place : grain horaire sur mesure_horaire, cible H+1 par
site, référence publiée, critère de promotion chiffré, cron par la dérogation de
l'ADR 0008, T4 non requis et pourquoi. Le nom du modèle y est « à confirmer »,
et aucun n'est réservé au registre.

Justine, un point t'appartient et la fiche ne le ferme pas : la variable qui
porte le site. La fiche propose un modèle unique avec le type de site en
variable ; l'identifiant site_id est l'autre candidat. Sur le référentiel réel
le type ne confond que deux paires, SITE001/SITE006 et SITE002/SITE007,
les deux plus proches du parc. Les deux variantes coûtent une ligne : le #36 les
entraîne toutes les deux et garde celle qui gagne à la MAE.

Le T4, lui, est réglé : le #36 a été amendé le 07/09, son premier critère ne
demande plus le GPU ni nvidia-smi. La fiche et le ticket disent la même chose.

Mise à jour du 07/09 après la relecture de Justine. L'ADR ferme maintenant
trois manques qu'elle a eu raison de relever : la rejouabilité du CA4 du #36
(graine fixée, fenêtre bornée par deux instants UTC explicites, et surtout le jeu
figé et enregistré comme entrée de l'exécution), l'antériorité d'EF-08, qui
appartient au job à l'émission et non au contrat, et la trace de l'entrée du
CA3 du #37, qui va au journal du job et à l'exécution MLflow, pas dans
public.prevision.

Le piège de la migration 0017

reference_kw ne double pas valeur_reference_kw, qui existe depuis la 0011 :

Colonne	Sens
valeur_reference_kw	le réalisé, recopié depuis la mesure après coup, pour la dérive
reference_kw	une prévision de référence, connue à l'émission

Les confondre donnerait un écart nul par construction, donc une comparaison
EF-07 qui ne compare rien : deux courbes plausibles, dont une fausse. Les deux
colonnes portent désormais leur sens en base, et un cas de test garde le renvoi
croisé.

Le contrat

PrevisionH1 décrit une ligne de la table et refuse ce que la base refuserait
trop tard — dans le journal d'un cron : identifiant hors format SITE000,
instant sans fuseau, horodatage hors du grain horaire. Il est plus strict que
le schéma sur un point, délibérément : la référence y est obligatoire, parce
qu'une prévision publiée seule ne tient pas l'EF-07.

Ce que cette PR ne fait pas

Aucun modèle écrit, rien enregistré dans MLflow, aucun nom réservé, et
services/inference/ est intact. EC06 est l'épreuve qui a le moins de
preuves ; ce qui la sauve est un contrat clair et une heure lundi matin, pas un
train.py que sa titulaire ne saurait pas défendre.

Preuve

ruff, ruff format, mypy --strict sur le nouveau paquet : propres.
pytest tests/unit : 601 tests, 0 échec.

Exigences : EF-07, EF-08. Prépare #36 et #37.

# contracts : le contrat de prévision H+1 et sa référence en base **Rien n'écrit `public.prevision`.** La table est posée depuis la 0011 et aucun `insert` du dépôt ne la vise ; `services/inference/` porte un `README.md` de trois lignes et `packages/contracts/` était vide. L'API sert donc une prévision de jeu et calcule l'EF-08 dessus. Ce qui manque d'abord n'est pas un modèle, c'est ce qui permet à celui qui le produira et à celui qui le servira d'avancer sans s'attendre. ## Cette fiche est « proposée », et elle le reste L'ADR 0012 met les options devant les titulaires du **#36** et du **#37** au lieu de trancher à leur place : grain horaire sur `mesure_horaire`, cible H+1 par site, référence publiée, critère de promotion chiffré, cron par la dérogation de l'ADR 0008, T4 non requis et pourquoi. **Le nom du modèle y est « à confirmer », et aucun n'est réservé au registre.** **Justine, un point t'appartient** et la fiche ne le ferme pas : la variable qui porte le site. La fiche propose un modèle unique avec le **`type` de site** en variable ; l'identifiant `site_id` est l'autre candidat. Sur le référentiel réel le type ne confond que deux paires, `SITE001`/`SITE006` et `SITE002`/`SITE007`, les deux plus proches du parc. Les deux variantes coûtent une ligne : le #36 les entraîne toutes les deux et garde celle qui gagne à la MAE. Le T4, lui, est réglé : le #36 a été amendé le 07/09, son premier critère ne demande plus le GPU ni `nvidia-smi`. La fiche et le ticket disent la même chose. **Mise à jour du 07/09 après la relecture de Justine.** L'ADR ferme maintenant trois manques qu'elle a eu raison de relever : la **rejouabilité** du CA4 du #36 (graine fixée, fenêtre bornée par deux instants UTC explicites, et surtout le jeu figé et enregistré comme entrée de l'exécution), l'**antériorité** d'EF-08, qui appartient au job à l'émission et non au contrat, et la **trace de l'entrée** du CA3 du #37, qui va au journal du job et à l'exécution MLflow, pas dans `public.prevision`. ## Le piège de la migration 0017 `reference_kw` **ne double pas** `valeur_reference_kw`, qui existe depuis la 0011 : | Colonne | Sens | |---|---| | `valeur_reference_kw` | le **réalisé**, recopié depuis la mesure **après coup**, pour la dérive | | `reference_kw` | une **prévision de référence**, connue **à l'émission** | Les confondre donnerait un écart nul par construction, donc une comparaison EF-07 qui ne compare rien : deux courbes plausibles, dont une fausse. Les deux colonnes portent désormais leur sens en base, et un cas de test garde le renvoi croisé. ## Le contrat `PrevisionH1` décrit une ligne de la table et refuse ce que la base refuserait trop tard — dans le journal d'un cron : identifiant hors format `SITE000`, instant sans fuseau, horodatage hors du grain horaire. Il est **plus strict que le schéma sur un point, délibérément** : la référence y est obligatoire, parce qu'une prévision publiée seule ne tient pas l'EF-07. ## Ce que cette PR ne fait pas Aucun modèle écrit, rien enregistré dans MLflow, aucun nom réservé, et `services/inference/` est intact. **EC06 est l'épreuve qui a le moins de preuves ; ce qui la sauve est un contrat clair et une heure lundi matin, pas un `train.py` que sa titulaire ne saurait pas défendre.** ## Preuve `ruff`, `ruff format`, `mypy --strict` sur le nouveau paquet : propres. `pytest tests/unit` : **601 tests, 0 échec**. Exigences : EF-07, EF-08. Prépare #36 et #37.

lenaic added 1 commit 2026-09-06 16:02:23 +00:00

contracts: poser le contrat de prévision H+1 et sa référence publiée ... 80fabec3db

EF-07 demande une prévision d'heure suivante « avec une référence de
comparaison publiée ». Rien ne portait cette référence : `services/inference`
n'a qu'un README, `packages/contracts` était vide, et `public.prevision` est
posée depuis la 0011 sans qu'aucun `insert` du dépôt ne la vise.

Ce commit pose ce qui manque pour que les tickets #36 et #37 démarrent sans
partir d'une page blanche, et rien de plus : aucun modèle, aucune expérience,
aucun modèle enregistré ni promu dans MLflow.

- `docs/adr/0012` est **proposée**, pas acceptée. EC06 se défend
  individuellement ; la fiche met les options devant Justine et Olivier au lieu
  de trancher à leur place. Grain horaire sur `mesure_horaire`, cible H+1 par
  site, référence = persistance (naïf saisonnier en métrique secondaire),
  candidat `HistGradientBoostingRegressor` sur retards, promotion sur MAE à
  trois jours contre la persistance, nom `enervision-prevision-h1` **à
  confirmer**, alias `production`. Le job tourne en cron à l'heure, ce qui
  étend la dérogation de l'ADR 0008 à l'ADR 0001 — la fiche l'assume et le
  borne. Le T4 n'est pas requis, et la fiche dit pourquoi.
- La migration 0017 ajoute `reference_kw` à `public.prevision`. Elle NE DIT PAS
  la même chose que `valeur_reference_kw` de la 0011 : celle-ci est le réalisé
  recopié après coup pour mesurer la dérive, celle-là une prévision de
  référence connue à l'émission. Les confondre donnerait un écart nul par
  construction, donc une comparaison EF-07 qui ne compare rien et qui a l'air
  juste. Les deux colonnes portent désormais un `comment on column` qui renvoie
  à l'autre. Colonne nullable et sans défaut : `prevision` est une hypertable
  comprimée et une migration s'applique au démarrage du serveur, donc aucun
  fragment ne doit être décomprimé.
- `PrevisionH1` est volontairement plus strict que le schéma sur un point :
  `reference_kw` y est obligatoire, parce qu'une prévision publiée sans
  référence ne tient pas EF-07. La règle doit arrêter le producteur, pas la
  migration. Le contrat refuse aussi un identifiant hors format `SITE000`
  (même expression que la contrainte de la 0008), un instant naïf et un instant
  hors grain horaire — un instant sans fuseau décale d'un pas exactement sur
  une prévision horaire, et les courbes restent jolies.
- `packages/contracts` reçoit son `pyproject.toml` en disposition plate, comme
  les services. Sans lui, `deps-services.py` n'installe pas pydantic avant le
  typage et la boucle mypy de `ci.yml` ne voit pas le paquet : il serait le
  seul code du dépôt à n'être ni typé ni installé, sans que rien ne rougisse.
  `pytest.ini` gagne le chemin correspondant.

Vérifications : ruff check et ruff format sur `packages` et les deux répertoires
de tests, mypy strict sur `packages/contracts`, `pytest tests/unit/db
tests/unit/contracts -q` — 50 tests verts.

lenaic added the

Kind/Back

Kind/IA

Priority

High

labels 2026-09-06 16:02:48 +00:00

lenaic requested review from justine 2026-09-07 07:06:38 +00:00

lenaic self-assigned this 2026-09-07 07:25:00 +00:00

justine added 1 commit 2026-09-07 07:57:14 +00:00

Merge branch 'develop' into lenaic/36-contrat-prevision 434e4d0329

justine commented 2026-09-07 07:59:28 +00:00

Member

Copy link

Ce qui ne colle pas avec #36

1. Le T4. C'est le vrai point, et il est plus dur que la PR ne le formule. Ton critère dit « l'entraînement s'exécute en local sur le Tesla T4, jamais dans le cloud », avec nvidia-smi en preuve. L'ADR ne se contente pas de dire que le T4 « n'est pas requis » : le candidat qu'elle propose, HistGradientBoostingRegressor, n'a aucun chemin GPU dans scikit-learn. Accepter la fiche telle quelle rend le critère techniquement inatteignable, pas seulement facultatif. Il faut donc trancher franchement : amender #36 (titre, CA et preuve comprises), ou garder le T4 et changer de candidat. L'argument de l'ADR — l'outil à la taille du problème — se défend très bien devant un jury ; mais il se défend en amendant le ticket, pas en le laissant dire autre chose.

2. La rejouabilité. Ton CA4 demande le même résultat sur les mêmes données. L'ADR écrit elle-même, en contexte, que l'historique « n'est pas réputé déterministe » — puis ne dit rien de la graine, du gel de la fenêtre d'entraînement, ni du figement du jeu. C'est le critère le plus fragile de #36 et la fiche le laisse entier.

3. Un modèle unique vs un modèle par site. La PR te renvoie ce choix, mais la fiche l'a déjà tranché : « un seul modèle pour les sept sites ». Et elle le tranche avec type de site en variable, pas site_id comme l'annonce la description de la PR. Ce n'est pas la même chose : sur sept sites, le type perd l'identité du site. À décider explicitement.

Ce qui ne colle pas avec #37

4. Le CA1 est déplacé sans le dire. #37 demande « le service charge le modèle promu depuis MLflow et répond sous 200 ms ». L'ADR remplace ça par un cron horaire qui écrit en base, l'API lisant la table. C'est probablement le seul montage qui tient les 200 ms — mais alors c'est le cron qui charge MLflow, pas le chemin de requête. À réécrire dans #37, sinon l'écart se lira au jury.
   5. Le CA3 n'a aucun emplacement. « Chaque prédiction journalisée avec son entrée et l'identifiant du modèle » : PrevisionH1 porte modele_version, mais l'entrée (les retards t−1…t−24) n'est ni dans le contrat, ni dans public.prevision, ni dans la 0017, ni mentionnée dans l'ADR. C'est le seul critère de #37 que cette PR laisse sans place.

5. « Avant l'heure concernée » n'est plus garanti nulle part. Le contrat retire volontairement le contrôle emise_le < horodatage — la justification par le rejeu est bonne. Mais EF-08 repose sur cette antériorité, et rien dans le dépôt ne la porte désormais. Il faut dire où elle vit (côté job, au moment de l'émission en ligne).

**Ce qui ne colle pas avec #36** 1. Le T4. C'est le vrai point, et il est plus dur que la PR ne le formule. Ton critère dit « l'entraînement s'exécute en local sur le Tesla T4, jamais dans le cloud », avec nvidia-smi en preuve. L'ADR ne se contente pas de dire que le T4 « n'est pas requis » : le candidat qu'elle propose, HistGradientBoostingRegressor, n'a aucun chemin GPU dans scikit-learn. Accepter la fiche telle quelle rend le critère techniquement inatteignable, pas seulement facultatif. Il faut donc trancher franchement : amender #36 (titre, CA et preuve comprises), ou garder le T4 et changer de candidat. L'argument de l'ADR — l'outil à la taille du problème — se défend très bien devant un jury ; mais il se défend en amendant le ticket, pas en le laissant dire autre chose. 2. La rejouabilité. Ton CA4 demande le même résultat sur les mêmes données. L'ADR écrit elle-même, en contexte, que l'historique « n'est pas réputé déterministe » — puis ne dit rien de la graine, du gel de la fenêtre d'entraînement, ni du figement du jeu. C'est le critère le plus fragile de #36 et la fiche le laisse entier. 3. Un modèle unique vs un modèle par site. La PR te renvoie ce choix, mais la fiche l'a déjà tranché : « un seul modèle pour les sept sites ». Et elle le tranche avec type de site en variable, pas site_id comme l'annonce la description de la PR. Ce n'est pas la même chose : sur sept sites, le type perd l'identité du site. À décider explicitement. **Ce qui ne colle pas avec #37** 4. Le CA1 est déplacé sans le dire. #37 demande « le service charge le modèle promu depuis MLflow et répond sous 200 ms ». L'ADR remplace ça par un cron horaire qui écrit en base, l'API lisant la table. C'est probablement le seul montage qui tient les 200 ms — mais alors c'est le cron qui charge MLflow, pas le chemin de requête. À réécrire dans #37, sinon l'écart se lira au jury. 5. Le CA3 n'a aucun emplacement. « Chaque prédiction journalisée avec son entrée et l'identifiant du modèle » : PrevisionH1 porte modele_version, mais l'entrée (les retards t−1…t−24) n'est ni dans le contrat, ni dans public.prevision, ni dans la 0017, ni mentionnée dans l'ADR. C'est le seul critère de #37 que cette PR laisse sans place. 6. « Avant l'heure concernée » n'est plus garanti nulle part. Le contrat retire volontairement le contrôle emise_le < horodatage — la justification par le rejeu est bonne. Mais EF-08 repose sur cette antériorité, et rien dans le dépôt ne la porte désormais. Il faut dire où elle vit (côté job, au moment de l'émission en ligne).

lenaic referenced this pull request from a commit 2026-09-07 08:57:03 +00:00

docs: l'ADR 0012 ferme la rejouabilité, l'antériorité et la trace de l'entrée (#36 #37)

lenaic added 1 commit 2026-09-07 08:57:04 +00:00

docs: l'ADR 0012 ferme la rejouabilité, l'antériorité et la trace de l'entrée (#36 #37) ... 0be9631802

Trois manques relevés par Justine en relecture de la #161, et qui étaient
réels : la fiche déclarait l'historique non déterministe sans dire comment le
CA4 du #36 est tenu, l'antériorité d'EF-08 ne vivait plus nulle part depuis
que le contrat a retiré emise_le < horodatage, et le CA3 du #37 n'avait aucun
emplacement écrit.

- rejouabilité : random_state fixé, fenêtre bornée par deux instants UTC
  explicites, et surtout le jeu figé et enregistré comme entrée de l'exécution.
  Sans le troisième les deux premiers ne prouvent rien, une réimputation de la
  zone argent suffit à changer le résultat.
- antériorité : elle appartient au job à l'émission en ligne, pas au contrat.
  Le contrat garde son choix, une règle qui interdit le rejeu se contourne en
  trichant sur l'horodatage.
- trace de l'entrée : les vingt quatre retards vont au journal du job et à
  l'exécution MLflow, pas dans public.prevision, qui est une hypertable
  comprimée à une ligne par site et par heure.

Et le choix type de site contre site_id devient un relevé plutôt qu'un débat :
le référentiel ne confond que deux paires, SITE001/SITE006 et SITE002/SITE007,
les deux plus proches du parc. Le #36 entraîne les deux variantes et garde
celle qui gagne à la MAE.

lenaic commented 2026-09-07 08:58:03 +00:00

Author

Owner

Copy link

Relecture utile, et quatre de tes six points étaient justes sans réserve. Ils
sont traités dans 0be9631. Je réponds dans l'ordre, y compris là où je ne te
suis pas.

1. Le T4 : refermé, et par toi

Ton point était exact, mais il est déjà appliqué : le #36 a été amendé à 08h01,
deux minutes après ton commentaire. Le premier critère ne demande plus le Tesla
T4 ni nvidia-smi, il demande un entraînement local sur le serveur de la salle,
avec le motif écrit et la fiche citée. La fiche et le ticket disent enfin la
même chose. Rien à faire de plus.

2. La rejouabilité : tu as raison, la fiche laissait le CA4 entier

Elle déclarait l'historique non déterministe puis ne disait rien de la suite.
Trois verrous ajoutés, et le troisième est le seul qui compte :

• random_state fixé et journalisé dans les paramètres de l'exécution ;
• la fenêtre d'entraînement bornée par deux instants UTC explicites passés
  en paramètres, jamais « les N derniers jours » calculés à l'exécution ;
• le jeu figé et enregistré comme entrée de l'exécution MLflow.

Sans le troisième, les deux premiers ne prouvent rien : la zone or bouge sous
les pieds de l'entraînement, une réimputation de la zone argent suffit à changer
le résultat sans qu'aucun paramètre n'ait bougé. « Les mêmes données » doit se
vérifier, pas s'affirmer.

3. Le type contre l'identifiant : tu as raison, et voilà le chiffre

Tu as raison sur la contradiction, et elle est de moi : la fiche écrit type de site, ma description de PR annonçait site_id. Deux textes de ma main qui
disent l'inverse. La description est corrigée.

Sur le fond, ton « sur sept sites, le type perd l'identité du site » mérite
d'être chiffré, parce que le référentiel réel le borne :

office      SITE001 200 kW    SITE006 180 kW
factory     SITE002 1000 kW   SITE007 950 kW
datacenter  SITE003 800 kW
retail      SITE004 400 kW
hospital    SITE005 600 kW

Cinq types pour sept sites. Le type ne confond que deux paires, et ce sont
les deux plus proches du parc, à 10 % et 5 % de capacité l'une de l'autre. La
perte que tu nommes est réelle et bornée à ça.

Les deux variantes coûtent une ligne. Plutôt que de trancher sur une intuition,
la fiche demande maintenant au #36 d'entraîner les deux et de garder celle qui
gagne à la MAE. Si site_id gagne, tu auras la mesure pour le dire au jury au
lieu d'un avis.

4. Le CA1 du #37 : tu as raison, et tu as même donné la raison

Le cron est le seul montage qui tient les 200 ms, et alors c'est lui qui charge
MLflow. À noter quand même : la fiche ne supprime pas les 200 ms, elle déplace
le chargement du modèle hors du chemin de requête. Le critère n'est pas affaibli,
il change d'endroit. Rédaction proposée dans le #37, tu valides ou tu réécris.

5. Le CA3 : le manque est réel, l'emplacement non

J'accepte le constat. Rien dans le dépôt ne disait où vit l'entrée, et c'est un
oubli de la fiche.

Mais le CA3 dit « journalisée », pas « stockée en base », et la nuance décide de
la réponse. Vingt quatre retards par ligne dans public.prevision, qui est une
hypertable comprimée à une ligne par site et par heure, multiplierait la
largeur d'une ligne servie par cinq environ pour y loger de la preuve de
reproductibilité. On paierait ça sur chaque lecture du tableau de bord, pour une
donnée que personne n'affiche.

La fiche dit donc maintenant : journal du job pour l'inférence, comme le
collecteur écrit le sien, et exécution MLflow côté entraînement. Ni le
contrat ni la 0017 ne bougent. Si tu veux l'entrée en base, dis-le et on en
discute, mais alors ce sera une table à part, pas une colonne de prevision.

6. L'antériorité : tu as raison, et le contrat ne bouge pas

Retirer emise_le < horodatage du contrat reste le bon choix, pour la raison
que tu reprends toi-même : une règle qui interdit le rattrapage se contourne en
trichant sur l'horodatage, ce qui est pire que de ne pas l'avoir.

Mais tu as raison que l'antériorité d'EF-08 ne vivait plus nulle part. Elle vit
dans le job, à l'émission en ligne : une passe horaire refuse d'écrire une
prévision dont l'instant visé est déjà passé, et le dit dans son journal. Un
rattrapage écrit sans cette garde et se reconnaît à ce que son emise_le suit
son horodatage. C'est écrit dans la fiche, et c'est le #37 qui porte le
contrôle.

Ce qui reste

Trois amendements au #37, sur les points 4, 5 et 6. C'est ton ticket, donc je te
propose la rédaction exacte en commentaire là-bas plutôt que de l'éditer. Tu
appliques, tu réécris, ou tu dis non.

tests/ci/test-liens-markdown.sh vert, 144 liens dans 72 fichiers.

Relecture utile, et quatre de tes six points étaient justes sans réserve. Ils sont traités dans `0be9631`. Je réponds dans l'ordre, y compris là où je ne te suis pas. ## 1. Le T4 : refermé, et par toi Ton point était exact, mais il est déjà appliqué : le #36 a été amendé à 08h01, deux minutes après ton commentaire. Le premier critère ne demande plus le Tesla T4 ni `nvidia-smi`, il demande un entraînement local sur le serveur de la salle, avec le motif écrit et la fiche citée. La fiche et le ticket disent enfin la même chose. Rien à faire de plus. ## 2. La rejouabilité : tu as raison, la fiche laissait le CA4 entier Elle déclarait l'historique non déterministe puis ne disait rien de la suite. Trois verrous ajoutés, et le troisième est le seul qui compte : - `random_state` fixé et journalisé dans les paramètres de l'exécution ; - la fenêtre d'entraînement bornée par **deux instants UTC explicites** passés en paramètres, jamais « les N derniers jours » calculés à l'exécution ; - le jeu **figé et enregistré comme entrée de l'exécution** MLflow. Sans le troisième, les deux premiers ne prouvent rien : la zone or bouge sous les pieds de l'entraînement, une réimputation de la zone argent suffit à changer le résultat sans qu'aucun paramètre n'ait bougé. « Les mêmes données » doit se vérifier, pas s'affirmer. ## 3. Le type contre l'identifiant : tu as raison, et voilà le chiffre Tu as raison sur la contradiction, et elle est de moi : la fiche écrit `type de site`, ma description de PR annonçait `site_id`. Deux textes de ma main qui disent l'inverse. La description est corrigée. Sur le fond, ton « sur sept sites, le type perd l'identité du site » mérite d'être chiffré, parce que le référentiel réel le borne : ``` office SITE001 200 kW SITE006 180 kW factory SITE002 1000 kW SITE007 950 kW datacenter SITE003 800 kW retail SITE004 400 kW hospital SITE005 600 kW ``` Cinq types pour sept sites. Le type ne confond que **deux paires**, et ce sont les deux plus proches du parc, à 10 % et 5 % de capacité l'une de l'autre. La perte que tu nommes est réelle et bornée à ça. Les deux variantes coûtent une ligne. Plutôt que de trancher sur une intuition, la fiche demande maintenant au #36 d'**entraîner les deux et de garder celle qui gagne à la MAE**. Si `site_id` gagne, tu auras la mesure pour le dire au jury au lieu d'un avis. ## 4. Le CA1 du #37 : tu as raison, et tu as même donné la raison Le cron est le seul montage qui tient les 200 ms, et alors c'est lui qui charge MLflow. À noter quand même : la fiche ne supprime pas les 200 ms, elle déplace le chargement du modèle hors du chemin de requête. Le critère n'est pas affaibli, il change d'endroit. Rédaction proposée dans le #37, tu valides ou tu réécris. ## 5. Le CA3 : le manque est réel, l'emplacement non J'accepte le constat. Rien dans le dépôt ne disait où vit l'entrée, et c'est un oubli de la fiche. Mais le CA3 dit « journalisée », pas « stockée en base », et la nuance décide de la réponse. Vingt quatre retards par ligne dans `public.prevision`, qui est une hypertable **comprimée** à une ligne par site et par heure, multiplierait la largeur d'une ligne servie par cinq environ pour y loger de la preuve de reproductibilité. On paierait ça sur chaque lecture du tableau de bord, pour une donnée que personne n'affiche. La fiche dit donc maintenant : **journal du job** pour l'inférence, comme le collecteur écrit le sien, et **exécution MLflow** côté entraînement. Ni le contrat ni la 0017 ne bougent. Si tu veux l'entrée en base, dis-le et on en discute, mais alors ce sera une table à part, pas une colonne de `prevision`. ## 6. L'antériorité : tu as raison, et le contrat ne bouge pas Retirer `emise_le < horodatage` du contrat reste le bon choix, pour la raison que tu reprends toi-même : une règle qui interdit le rattrapage se contourne en trichant sur l'horodatage, ce qui est pire que de ne pas l'avoir. Mais tu as raison que l'antériorité d'EF-08 ne vivait plus nulle part. Elle vit dans le **job, à l'émission en ligne** : une passe horaire refuse d'écrire une prévision dont l'instant visé est déjà passé, et le dit dans son journal. Un rattrapage écrit sans cette garde et se reconnaît à ce que son `emise_le` suit son `horodatage`. C'est écrit dans la fiche, et c'est le #37 qui porte le contrôle. ## Ce qui reste Trois amendements au #37, sur les points 4, 5 et 6. C'est ton ticket, donc je te propose la rédaction exacte en commentaire là-bas plutôt que de l'éditer. Tu appliques, tu réécris, ou tu dis non. `tests/ci/test-liens-markdown.sh` vert, 144 liens dans 72 fichiers.

👍 1

lenaic referenced this pull request 2026-09-07 08:58:36 +00:00

[EF-08] Service d'inférence : prévision servie et signal de dépassement #37

lenaic added 1 commit 2026-09-07 11:10:59 +00:00

Merge develop dans la branche du contrat de prévision (#36) ... 8dd45e3f9c

# Conflicts:
#	docs/adr/README.md

justine approved these changes 2026-09-07 11:23:00 +00:00

justine merged commit 1d516ab55f into develop 2026-09-07 11:23:05 +00:00

justine deleted branch lenaic/36-contrat-prevision 2026-09-07 11:23:05 +00:00

justine referenced this pull request from a commit 2026-09-07 11:23:05 +00:00

Merge pull request 'contracts : le contrat de prévision H+1 et sa référence publiée' (#161) from lenaic/36-contrat-prevision into develop

marvin referenced this pull request from a commit 2026-09-07 12:17:41 +00:00

db: la migration des alertes devient la 0018, la 0017 est prise (#168)

olivier referenced this pull request from a commit 2026-09-07 13:13:19 +00:00

Merge branch 'develop' into olivier/36-entrainement-modele (#36)

olivier referenced this pull request from a commit 2026-09-07 13:13:19 +00:00

inference: la fiche de décision est la 0013, pas la 0012 (#36)

lenaic referenced this pull request 2026-09-07 13:48:55 +00:00

Jalon : develop vers main, la chaîne complète et l'application sur le serveur #170

Sign in to join this conversation.

Reviewers

No reviewers

justine

Labels

Clear labels   

Compat/Breaking

Breaking change that won't be backward compatible

  

EC01

Preuve pour l'épreuve Architecture

  

EC02

Preuve pour l'épreuve Management

  

EC03

Preuve pour l'épreuve CI/CD

  

EC04

Preuve pour l'épreuve Cloud

  

EC05

Preuve pour l'épreuve Data et BI

  

EC06

Preuve pour l'épreuve IA

  

Kind/BDD

BDD

  

Kind/Back

Back

  

Kind/Bug

Something is not working

  

Kind/CICD

CICD

  

Kind/Cloud

Cloud

  

Kind/Contenu

Contenu

  

Kind/Data

Data

  

Kind/Documentation

Documentation changes

  

Kind/Enhancement

Improve existing functionality

  

Kind/Feature

New functionality

  

Kind/Front

Front

  

Kind/IA

IA

  

Kind/Infra

Serveur, déploiement, chaîne, supervision

  

Kind/Monitoring

Monitoring

  

Kind/Security

This is security issue

  

Kind/Testing

Issue or pull request related to testing

  

Portée/Post-jury

Périmètre documenté, hors de la fenêtre du 11/09. Repris après le jury. Rien nest supprimé.

  

Priority

Critical

The priority is critical

  

Priority

High

The priority is high

  

Priority

Low

The priority is low

  

Priority

Medium

The priority is medium

  

Reviewed

Confirmed

Issue has been confirmed

  

Reviewed

Duplicate

This issue or pull request already exists

  

Reviewed

Invalid

Invalid issue

  

Reviewed

Won't Fix

This issue won't be fixed

  

Status

Abandoned

Somebody has started to work on this but abandoned work

  

Status

Blocked

Something is blocking this issue or pull request

  

Status

Need More Info

Feedback is required to reproduce issue or to continue work

  

ops/alerte

Alerte d'exploitation (relais Grafana, #42)

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

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

lenaic

2 participants

Notifications

Subscribe

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!161

No description provided.