api : le tableau de bord quitte entièrement les fixtures (#179) #195

Merged
lenaic merged 3 commits from lenaic/179-reste-des-fixtures into develop 2026-09-08 12:09:55 +00:00
Owner

Ferme #179. repository.py ne lit plus fixtures.py du tout : trente et un renvois hier matin, dix ce midi, zéro maintenant.

Ce qui devient réel

Mesuré contre enervision_prod, pas déduit :

consommation_kw       176,220 kW      au lieu de 104,0 figé
derniere_releve       10h59 aujourd'hui   au lieu du 1er septembre 16h42
disponibilite_pct     80,6 %          lu dans qualite_jour
imputation_pct        dérivé de repartition_methode
consommation_veille   3 619,3 kW      le même seau horaire à J−1
recommandations       2 actives sur SITE003, produites par R1

taux_de_charge_pct et palier deviennent vrais d'eux-mêmes : ce sont des propriétés dérivées de la consommation.

Le champ le plus visible était derniere_releve. L'écran affichait le 1er septembre pendant que la relève tournait à la minute et que la base portait 88 440 lignes pour le seul SITE001. Sur un tableau de bord, la première chose qu'on regarde est l'heure.

Deux champs deviennent facultatifs, de bout en bout

derniere_releve : un site du référentiel jamais mesuré n'en a pas. Lui en inventer une serait pire que de ne rien afficher, et le masquer donnerait un parc plus petit que le parc, plausible donc invisible. Le front rend un tiret — formaterHeure(null) valait 01:00, une heure plausible et fausse.

consommation_veille_kw : le seau de la veille peut manquer. ecart_veille_pct rend alors None, et aussi quand la veille vaut zéro : un parc à l'arrêt ne donne pas un écart infini, il ne donne pas d'écart du tout.

Une constante reste, et c'est délibéré

DISPONIBILITE_CIBLE_PCT sort de fixtures.py mais reste écrite dans le module. Ce n'est pas une donnée, c'est un objectif d'équipe qu'aucune table ne porte. C'était son voisinage avec des valeurs inventées qui la rendait suspecte, pas sa nature.

Trois doubles de test corrigés, et chacun cachait un défaut

  • FakeCurseur rendait ses lignes quelle que soit la requête. Il rendait donc les prévisions à qui demandait le référentiel.
  • Les réponses scriptées ignoraient les paramètres. Le double rendait les recommandations de tout le parc à qui demandait celles d'un seul site : le cas « un site sans recommandation rend une liste vide » passait au vert sur un dépôt qui n'aurait rien filtré.
  • CurseurDouble exigeait son second argument alors que psycopg le rend facultatif. Le double était plus strict que ce qu'il double.

Les fixtures restent, à leur place : le jeu d'essai. Les sept sites, le site muet et les quatre paliers sont inchangés pour les cas, et c'est le point — aucun d'eux n'a eu à bouger, ce qui était le pari du module.

Preuve

1 068 tests unitaires, 1 ignoré
ruff check et format   propres
mypy --strict          23 fichiers, aucune erreur
SQL éprouvé            contre enervision_prod avant d'être écrit

Ce que ça ne fait pas

L'écran ne se rafraîchit pas tout seul. Le front charge sur onMounted et il n'y a aucun setInterval : les valeurs sont celles du chargement de la page. C'était déjà vrai avec les fixtures, ça se remarque maintenant que les données bougent. À traiter à part, ce n'est pas ce ticket.

Ferme #179. `repository.py` ne lit plus `fixtures.py` **du tout** : trente et un renvois hier matin, dix ce midi, zéro maintenant. ## Ce qui devient réel Mesuré contre `enervision_prod`, pas déduit : ``` consommation_kw 176,220 kW au lieu de 104,0 figé derniere_releve 10h59 aujourd'hui au lieu du 1er septembre 16h42 disponibilite_pct 80,6 % lu dans qualite_jour imputation_pct dérivé de repartition_methode consommation_veille 3 619,3 kW le même seau horaire à J−1 recommandations 2 actives sur SITE003, produites par R1 ``` `taux_de_charge_pct` et `palier` deviennent vrais d'eux-mêmes : ce sont des propriétés dérivées de la consommation. **Le champ le plus visible était `derniere_releve`.** L'écran affichait le 1er septembre pendant que la relève tournait à la minute et que la base portait 88 440 lignes pour le seul SITE001. Sur un tableau de bord, la première chose qu'on regarde est l'heure. ## Deux champs deviennent facultatifs, de bout en bout `derniere_releve` : un site du référentiel jamais mesuré n'en a pas. Lui en inventer une serait pire que de ne rien afficher, et le masquer donnerait un parc plus petit que le parc, plausible donc invisible. Le front rend un tiret — `formaterHeure(null)` valait `01:00`, une heure plausible et fausse. `consommation_veille_kw` : le seau de la veille peut manquer. `ecart_veille_pct` rend alors `None`, et aussi quand la veille vaut zéro : un parc à l'arrêt ne donne pas un écart infini, il ne donne pas d'écart du tout. ## Une constante reste, et c'est délibéré `DISPONIBILITE_CIBLE_PCT` sort de `fixtures.py` mais reste écrite dans le module. **Ce n'est pas une donnée, c'est un objectif d'équipe** qu'aucune table ne porte. C'était son voisinage avec des valeurs inventées qui la rendait suspecte, pas sa nature. ## Trois doubles de test corrigés, et chacun cachait un défaut - **`FakeCurseur` rendait ses lignes quelle que soit la requête.** Il rendait donc les prévisions à qui demandait le référentiel. - **Les réponses scriptées ignoraient les paramètres.** Le double rendait les recommandations de tout le parc à qui demandait celles d'un seul site : le cas « un site sans recommandation rend une liste vide » passait au vert sur un dépôt qui n'aurait rien filtré. - **`CurseurDouble` exigeait son second argument** alors que psycopg le rend facultatif. Le double était plus strict que ce qu'il double. Les fixtures restent, à leur place : le jeu d'essai. Les sept sites, le site muet et les quatre paliers sont inchangés pour les cas, et c'est le point — aucun d'eux n'a eu à bouger, ce qui était le pari du module. ## Preuve ``` 1 068 tests unitaires, 1 ignoré ruff check et format propres mypy --strict 23 fichiers, aucune erreur SQL éprouvé contre enervision_prod avant d'être écrit ``` ## Ce que ça ne fait pas **L'écran ne se rafraîchit pas tout seul.** Le front charge sur `onMounted` et il n'y a aucun `setInterval` : les valeurs sont celles du chargement de la page. C'était déjà vrai avec les fixtures, ça se remarque maintenant que les données bougent. À traiter à part, ce n'est pas ce ticket.
lenaic self-assigned this 2026-09-08 11:42:04 +00:00
api: le tableau de bord quitte entièrement les fixtures (#179)
All checks were successful
Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 40s
Intégration / Contrôles statiques du dépôt (pull_request) Successful in 7s
Intégration / Workflows — lint et audit de sécurité (pull_request) Successful in 17s
Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 5m50s
67a6c57fdf
repository.py ne lit plus fixtures.py DU TOUT. Il en portait trente et un
renvois hier matin, dix ce midi, zéro maintenant.

Ce qui devient réel, et la mesure côté production :

  consommation_kw      176,220 kW au lieu de 104,0 figé
  derniere_releve      10h59 aujourd'hui au lieu du 1er septembre 16h42
  disponibilite_pct    80,6 % lu dans qualite_jour
  imputation_pct       dérivé de repartition_methode, la colonne n'existe pas
  taux_de_charge, palier   deviennent vrais d'eux-mêmes, ce sont des dérivés
  consommation_veille  3 619,3 kW, le même seau horaire à J-1
  recommandations      2 actives sur SITE003, produites par R1

Le champ le plus visible était derniere_releve : l'écran affichait le 1er
septembre pendant que la relève tournait à la minute et que la base portait
88 440 lignes pour le seul SITE001. Sur un tableau de bord, la première chose
qu'on regarde est l'heure.

DEUX CHAMPS DEVIENNENT FACULTATIFS, de bout en bout.

  derniere_releve      un site jamais mesuré n'en a pas. Lui en inventer une
                       serait pire que de ne rien afficher, et le masquer
                       donnerait un parc plus petit que le parc. Le front rend
                       un tiret : formaterHeure(null) valait 01:00, une heure
                       plausible et fausse.
  consommation_veille  le seau de la veille peut manquer. ecart_veille_pct rend
                       alors None, et aussi quand la veille vaut zéro : un parc
                       à l'arrêt ne donne pas un écart infini, il ne donne pas
                       d'écart du tout.

DISPONIBILITE_CIBLE_PCT reste une constante, et sort de fixtures.py. Ce n'est
pas une donnée, c'est un objectif d'équipe qu'aucune table ne porte : c'était
son voisinage avec des valeurs inventées qui la rendait suspecte.

Trois doubles de test corrigés, et chacun cachait un défaut :

  FakeCurseur    rendait ses lignes QUELLE QUE SOIT la requête. Il rendait donc
                 les prévisions à qui demandait le référentiel.
  les réponses   ignoraient les paramètres : le double rendait les
                 recommandations de tout le parc à qui demandait celles d'un
                 seul site, et le cas d'un site sans recommandation passait au
                 vert sur un dépôt qui n'aurait rien filtré.
  CurseurDouble  exigeait son second argument alors que psycopg le rend
                 facultatif. Le double était plus strict que ce qu'il double.

Les fixtures restent, à leur place : le jeu d'essai. Les sept sites, le site
muet et les quatre paliers sont inchangés pour les cas, et c'est le point,
aucun d'eux n'a eu à bouger.

Les trois requêtes sont éprouvées contre enervision_prod avant d'être écrites.
1 068 tests, ruff propre, mypy --strict propre sur 23 fichiers.
lenaic requested review from olivier 2026-09-08 11:43:50 +00:00
api: l'écart à la veille compare deux fois le même parc (#179)
All checks were successful
Intégration / Contrôles statiques du dépôt (pull_request) Successful in 8s
Intégration / Workflows — lint et audit de sécurité (pull_request) Successful in 24s
Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 37s
Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 5m54s
7981c13ae0
`synthese_parc` sommait la veille sur TOUS les sites et le jour même sur les
seuls sites mesurés. L'écart rapportait donc une perte de couverture comme une
baisse de consommation.

Le contrat le disait déjà : `consommation_kw` est « la somme des sites mesurés,
les muets exclus », et `consommation_veille_kw` « la même, à la même heure la
veille ». La même — donc sur les mêmes sites.

Sur le parc de production, les chiffres de la relecture du #179 le montrent
seuls : 176,2 kW mesurés contre 3 619,3 kW la veille, soit −95 % affichés en
tête d'écran le jour où six sondes sur sept se taisent. Un chiffre plausible,
donc invisible.

Un cas le tient : la requête de la veille ne doit porter que sur les six sites
mesurés du jeu d'essai, SITE006 étant muet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merge branch 'develop' into lenaic/179-reste-des-fixtures
All checks were successful
Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 39s
Intégration / Contrôles statiques du dépôt (pull_request) Successful in 7s
Intégration / Workflows — lint et audit de sécurité (pull_request) Successful in 19s
Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 5m51s
149ec66ee3
olivier approved these changes 2026-09-08 11:59:30 +00:00
lenaic merged commit 66cacb01b9 into develop 2026-09-08 12:09:55 +00:00
lenaic deleted branch lenaic/179-reste-des-fixtures 2026-09-08 12:09: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!195
No description provided.