dashboard : surveiller, comparer et alerter sur trois ecrans (#184) #207

Merged

olivier merged 7 commits from marvin/184-refonte-tableau-de-bord into develop 2026-09-08 14:39:33 +00:00

Conversation 3 Commits 7 Files changed 49 +2874 -636

marvin commented 2026-09-08 14:09:13 +00:00

Member

Copy link

Ce que la PR fait

Refonte de la surveillance du tableau de bord. L'ecran unique qui melait tout
devient trois ecrans, chacun repondant a une seule question.

Surveiller / comparer / alertes sur des ecrans separes

• Parc (/graphiques) : ou en est le parc maintenant, faut-il agir. Quatre
  mesures de tete, profil des dernieres heures, sites a traiter, etat courant
  des sites. Une seule periode en tete (24 h / 7 j / 30 j) qui commande le
  profil et les micro-courbes ensemble.
• Comparer (/comparaison) : comment les sites se situent sur la duree.
  Sept ou trente jours. Sorti de l'ecran Parc, ou il donnait un second
  selecteur de periode qui ignorait le premier.
• Alertes (/alertes) : les alertes des sites visibles, paginees a vingt,
  la plus severe en tete. Sorties du pied de l'ecran Qualite, ou leur liste
  poussait le reste de la page.

Corrections d'affichage (revue visuelle)

• Alignement a droite des colonnes chiffrees, qu'une collision de specificite
  annulait.
• Capitalisation francaise : plus de « Centre De Donnees ».
• Contenu borne et centre : sur un ecran large il s'etirait jusqu'a 1609 px.
• Les etats vides qui mentaient derriere la modale de reprise de session se
  taisent.

« A traiter » : trois lignes puis defilement

La liste s'etirait sur toute la hauteur de sa rangee des que plusieurs sites
decrochaient. Le compte en tete dit le total.

Verification

• npm run test:unit : 408 tests, tous verts.
• npm run build : ok.

Hors perimetre

Le rafraichissement automatique des ecrans (ticket #196, branche a part).

## Ce que la PR fait Refonte de la surveillance du tableau de bord. L'ecran unique qui melait tout devient trois ecrans, chacun repondant a une seule question. ### Surveiller / comparer / alertes sur des ecrans separes - **Parc** (`/graphiques`) : ou en est le parc maintenant, faut-il agir. Quatre mesures de tete, profil des dernieres heures, sites a traiter, etat courant des sites. Une seule periode en tete (24 h / 7 j / 30 j) qui commande le profil et les micro-courbes ensemble. - **Comparer** (`/comparaison`) : comment les sites se situent sur la duree. Sept ou trente jours. Sorti de l'ecran Parc, ou il donnait un second selecteur de periode qui ignorait le premier. - **Alertes** (`/alertes`) : les alertes des sites visibles, paginees a vingt, la plus severe en tete. Sorties du pied de l'ecran Qualite, ou leur liste poussait le reste de la page. ### Corrections d'affichage (revue visuelle) - Alignement a droite des colonnes chiffrees, qu'une collision de specificite annulait. - Capitalisation francaise : plus de « Centre De Donnees ». - Contenu borne et centre : sur un ecran large il s'etirait jusqu'a 1609 px. - Les etats vides qui mentaient derriere la modale de reprise de session se taisent. ### « A traiter » : trois lignes puis defilement La liste s'etirait sur toute la hauteur de sa rangee des que plusieurs sites decrochaient. Le compte en tete dit le total. ## Verification - `npm run test:unit` : 408 tests, tous verts. - `npm run build` : ok. ## Hors perimetre Le rafraichissement automatique des ecrans (ticket #196, branche a part).

marvin added 5 commits 2026-09-08 14:09:14 +00:00

dashboard: corrige les six défauts d'affichage de la revue visuelle (#184) ... 884e384ded

Six défauts relevés à la revue, indépendants et sans arbitrage.

Alignement des colonnes chiffrées. « .tableau td » pèse une classe et un
type, « .tableau__num » une classe seule : le sélecteur générique gagnait,
et l'alignement à droite ne s'appliquait jamais dans aucun des trois
tableaux. « :where » pèse zéro, ce qui rend la règle par défaut battable.

Échelle du profil horaire. Le viewBox était figé à 720 px pendant que le
SVG s'affichait en « width: 100% » : sur son conteneur réel de 1 529 px
tout était multiplié par 2,12, et les graduations déclarées à 12 px
arrivaient à 25,5 px, à côté d'un graphique Chart.js qui, lui, respectait
sa taille. Le dessin se fait maintenant à la largeur mesurée, facteur 1.

Débordement horizontal sur mobile. Un <table> ignore « width: 1px » : porté
par le tableau équivalent du profil, « .ev-hors-ecran » laissait 1 128 px
de large dans une fenêtre de 375, et la page entière défilait de côté. La
classe passe sur un conteneur, et gagne « clip-path » et « max-width ».

Navigation sous 900 px. Elle était masquée quand elle ne portait qu'un lien
vers l'écran où l'on se trouvait déjà ; depuis, Qualité est arrivé et le
menu du compte ne porte que Profil et Se déconnecter. Il n'existait donc
plus aucun chemin de /graphiques vers /qualite sur un téléphone. Elle passe
en seconde ligne, en onglets qui tiennent la cible tactile minimale.

Séparateur décimal. Trois composants appelaient « toFixed », qui rend le
point anglais : la disponibilité moyenne du parc s'affichait « 98.5 % » sur
l'écran Parc et « 98,5 % » sur l'écran Qualité. Tous passent par
« formaterPct », qui existait déjà.

Capitalisation. « text-transform: capitalize » capitalise chaque mot, règle
anglaise : elle donnait « Centre De Données » et abîmait « ALR-0002 » en
« Alr-0002 ». Remplacée par « capitaliser » dans le glossaire, qui met la
capitale sur la première lettre et sur elle seule.

Les quatre premiers ne se voient pas dans un rendu de test — les styles
d'un composant Vue ne sont pas appliqués sous Vitest. « revue-visuelle.test.js »
les prouve sur la source, comme « paletteSeries.test.js » le fait déjà pour
la palette ; chacun a été vu rougir sur le code d'avant.

Douze fichiers repassent au format du dépôt (prettier --no-semi
--single-quote --print-width 100), qui corrige au passage une indentation
ayant dérivé dans TableauQualite.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQz79FiyjK3wbB1C1qhuTy

dashboard: sépare surveiller et comparer, encode ce qui n'était qu'écrit (#184) ... cb33d0cd4d

L'écran Parc portait deux métiers de rythmes différents : savoir où en est
le parc à cette heure-ci, et comparer les sites sur la durée. D'où deux
sélecteurs de période qui s'ignoraient sur la même page, et 2 064 px de
haut. Ils partent chacun sur leur écran, avec une seule période en tête.

/comparaison porte le graphique multi-sites et son sélecteur. Sa période
commence à 7 j : sept sites sur vingt-quatre heures font 168 barres
groupées, que personne ne lit. Le sélecteur quitte la colonne latérale de
280 px, dont le défilement interne ne montrait que quatre sites sur sept —
une légende dont on ne voit pas la moitié ne remplit pas son office ; il
devient une rangée de jetons, et la pleine largeur revient au graphique.

/graphiques garde la surveillance et gagne ce qui lui manquait :

Le bandeau remplace les quatre pavés. Ils avaient chacun un fond, une ombre
et la hauteur du plus grand : celui des alertes portait quatre lignes, les
trois autres une seule, et finissaient sur 77 px de vide. Des filets
verticaux séparent aussi bien, et chaque mesure porte désormais un second
fait — part de la capacité, référence de persistance, sites mesurés — ce
qui lui donne sa hauteur pour de bon.

« À traiter » remonte les sites en surcharge, en tension ou sans relevé.
Il fallait jusqu'ici parcourir une colonne pour les premiers et changer
d'écran pour les seconds, alors que c'est la question que l'accueil devrait
traiter en premier. Aucun appel de plus : tout vient de /v1/sites.

Le tableau porte le taux de charge en jauge graduée aux trois seuils du
glossaire. models.py le dit de lui-même — « la seule grandeur comparable
entre sites » — et il n'était affiché nulle part : au lecteur de diviser
733 par 800 de tête. Il porte aussi une micro-courbe par site, trie du plus
chargé au moins chargé, et liste tout le parc plutôt que les sites cochés,
puisqu'il n'y a plus rien à cocher ici.

Chart.js écrivait en Helvetica faute de « Chart.defaults.font.family » :
deux typographies par écran, dont une que personne n'avait choisie. Les
réglages communs vivent dans chartReglages.js, et l'axe passe de dix
graduations à cinq.

Le contenu est enfin borné (--ev-contenu-max) : il s'étirait à 1 609 px sur
un écran de 1 920, et les colonnes devenaient des couloirs vides.

Rendu vérifié dans Chrome sur le jeu de fixtures, en 1 920 et en 375 :
l'écran d'accueil passe de 2 064 px à 1 311, sans débordement horizontal.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

dashboard: centre le contenu, et fait taire les vides qui mentent (#184) ... d9411f81ad

Le contenu était borné mais calé à gauche : tout le blanc s'accumulait
contre le bord droit de la fenêtre. « margin-inline: auto » le répartit, et
la règle vaut pour les six écrans — les quatre qui n'étaient pas encore
bornés le sont aussi.

Au passage, un défaut vu en vrai derrière la modale de reprise : la page
annonçait « Aucun site dans le parc » alors que les sites existent et que
c'est la session qui est tombée. Qui ferme la modale, ou la lit de biais,
repartait avec une information fausse sur son parc. Trois écrans le
faisaient — Parc, Comparer, et les deux blocs de Qualité, qui disaient
« Aucun site visible » et « Aucune alerte sur les sites visibles ».

Un parc vide se dit, une session finie se tait : c'est la règle que
GraphiquesView portait déjà en commentaire pour ses messages d'erreur, sans
que l'état vide la suive.

Le test correspondant signale lui-même l'expiration au dépôt de session :
son double de « listerSites » court-circuite la couche API, qui est
l'endroit où un 401 le fait en vrai. Vu rougir sans le correctif.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

dashboard: borne le triage à trois lignes, pagine les alertes (#184) ... c06ee30246

« À traiter » s'étirait sur toute la hauteur de sa rangée dès que
plusieurs sites décrochaient, poussant le tableau des sites hors de
l'écran. La liste montre trois lignes puis défile ; le compte en tête
dit le total.

« Alertes » sur l'écran Qualité rendait la liste entière : un mauvais
jour, le pied de page partait sous la ligne de flottaison. Vingt par
page, les plus sévères d'abord (elles sont déjà triées en tête), avec
« Précédentes / Suivantes » et l'intervalle affiché. Le découpage est
fait côté client — l'API rend tout, sans paramètre de page.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EL8Yw5fQMitWWyKR4FugX3

dashboard: les alertes passent sur leur propre écran (#184) ... 4ee28e6cbd

Elles vivaient en pied de l'écran Qualité, sous la synthèse et le
tableau par site. Deux défauts à cet endroit : la liste, paginée à
vingt, poussait le reste de la page ; et une alerte est une chose à
traiter, pas un indicateur de qualité de la collecte — elle ne
partageait le domaine que par accident de rangement.

Nouvel onglet « Alertes » (/alertes), quatrième de la barre, avec sa
propre coquille. Il charge le référentiel et les alertes côte à côte —
`ListeAlertes` a besoin du premier pour nommer le site de chaque
alerte. `charger()` de l'écran Qualité n'appelle plus `/v1/alertes` ;
le « Réessayer » de la liste recharge les alertes seules.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EL8Yw5fQMitWWyKR4FugX3

marvin requested review from olivier 2026-09-08 14:11:45 +00:00

marvin self-assigned this 2026-09-08 14:11:48 +00:00

marvin referenced this pull request 2026-09-08 14:19:31 +00:00

dashboard : les ecrans de surveillance se rafraichissent seuls (#196) #209

olivier referenced this pull request from a commit 2026-09-08 14:23:22 +00:00

dashboard: la période de tête commande vraiment le profil et les séries (#184)

olivier added 1 commit 2026-09-08 14:23:22 +00:00

dashboard: la période de tête commande vraiment le profil et les séries (#184) ... f104dd0f43

Deux défauts relevés en relecture de la #207, tous deux sur la période que
cette PR met en tête de chaque écran.

Les séries survivaient au changement d'écran. Chaque vue pose sa fenêtre puis
recharge le référentiel, qui ne relançait une série qu'en l'absence d'entrée :
les points 24 h de l'écran Parc restaient donc en place sur /comparaison, sous
une étiquette « 7 j », et réciproquement les micro-courbes du tableau du parc
montraient sept jours sous un en-tête « 24 h ». Chaque entrée de `series`
retient maintenant la fenêtre pour laquelle elle a été demandée, et c'est cette
marque — non la simple présence de l'entrée — qui décide du rechargement.

ProfilHoraireParc restait écrit pour 24 h au pas horaire. Il pouvait l'être
tant que sa courbe était figée à 24 h ; depuis qu'elle suit le sélecteur, un
point journalier passé à `etiquetteAxe(t, '1h')` rendait l'heure de son seau,
soit « 00 h » répété sur les sept ou trente points, sous un titre qui annonçait
« 24 h » et un tableau dont la colonne s'intitulait « Heure (UTC) ». Le titre,
les étiquettes, le résumé et l'en-tête se règlent désormais sur `pas` et
`fenetre` rendus par l'API. L'espacement des étiquettes se calcule au lieu
d'être constant : quatre convenait aux vingt-quatre heures et à elles seules.

Le gabarit de série des tests portait « fenetre: '7j' » quand le magasin
démarre à « 24h » — corrigé pour refléter ce que rend l'API.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

olivier commented 2026-09-08 14:24:00 +00:00

Member

Copy link

Relecture ciblée : deux défauts bloquants, corrigés dans f104dd0

Relecture volontairement resserrée sur ce qui empêche une mise en production : bug de correctness, construction, CI. Le reste (mise en page, capitalisation, pagination, jauges, micro-courbes, navigation sous 900 px) tient et n'appelle rien de ma part.

Vérifié localement sur 4ee28e6 : npm ci, npm run test:unit (408 verts), npm run build avec VITE_API_BASE — tout passe, comme les cinq jobs de la forge. Rien ne bloque la chaîne. Les deux défauts ci-dessous sont des défauts de données affichées, et ils touchent tous deux la période que cette PR met en tête de chaque écran — c'est-à-dire son apport principal.

1. Les séries survivent au changement d'écran, sous la mauvaise étiquette

fenetre est un état unique du magasin, et chaque vue le pose à l'arrivée avant de rappeler chargerSites(). Mais afficherTousLesSites() ne relançait une série qu'en l'absence d'entrée :

if (!series.value[site.site_id]) _chargerSerie(site.site_id)

Les entrées existent déjà après le premier écran, donc rien ne repart. Parcours : /graphiques (24 h) → /comparaison pose 7j → le graphique de comparaison affiche les points horaires de 24 h sous un sélecteur qui indique « 7 j ». Et au retour, les micro-courbes du tableau du parc montrent sept ou trente jours pendant que l'en-tête annonce « 24 h » et que le profil, lui, a bien été rechargé. Deux périodes sur le même écran — exactement le défaut que la PR entend supprimer, déplacé d'un cran.

Reproduit par un test avant correction : après fenetre = '7j' puis chargerSites(), les trois entrées de series portaient encore fenetre: '24h' et mesuresSite n'avait été appelé que trois fois, toutes en 24h.

Correction : chaque entrée de series retient la fenêtre pour laquelle elle a été demandée — pendant son chargement et sur son échec comprises — et c'est cette marque, non la simple présence de l'entrée, qui décide du rechargement. Un remontage sur la même fenêtre ne redemande toujours rien.

2. ProfilHoraireParc reste écrit pour 24 h au pas horaire

Le composant est figé sur '1h' en cinq endroits (titre, étiquettes d'axe, résumé pour lecteur d'écran, en-tête et corps du tableau équivalent), ce qui se tenait tant que profilParc était lui-même figé à 24 h. Depuis que le sélecteur le commande, sur 7j / 30j :

• le titre annonce « Profil horaire du parc, 24 h » au-dessus de trente jours de relevés ;
• etiquetteAxe(t, '1h') sur un point journalier rend l'heure de son seau, donc « 00 h » répété sur tous les points de l'axe et toutes les lignes du tableau ;
• le résumé lu à la place du dessin dit « sur 7 heures », et la colonne s'intitule « Heure (UTC) » ;
• PAS_ETIQUETTE = 4 ne laissait que deux étiquettes sur sept points.

Correction : titre, étiquettes, résumé et en-tête se règlent sur pas et fenetre rendus par l'API (SerieParcOut), pas déduits de la fenêtre demandée — c'est l'API qui décide du pas. L'espacement des étiquettes se calcule (six au plus) et vaut toujours quatre sur 24 h. Le titre devient « Profil journalier du parc, 7 jours » le cas échéant.

Au passage

Le gabarit serie() de graphique.test.js portait fenetre: '7j' quand le magasin démarre maintenant à 24h : la réponse simulée contredisait la requête. Corrigé pour refléter ce que rend l'API, sinon les deux tests « ne relance pas les sites déjà chargés » passaient pour la mauvaise raison.

État

412 tests verts (408 + 4 de non-régression), npm run build ok. Je ne fusionne pas : le correctif touche le magasin et un composant, il vaut un regard de l'auteur avant.

Deux remarques non bloquantes, laissées telles quelles : sur /comparaison, changerFenetre() redemande aussi mesuresParc alors que l'écran n'affiche pas le profil du parc (un appel pour rien, sans effet visible) ; et SitesATraiter formate derniere_releve sans garde, ce qui donnerait « depuis 00:00 » si l'API rendait un jour ce champ nul — le contrat le déclare non nullable aujourd'hui.

## Relecture ciblée : deux défauts bloquants, corrigés dans f104dd0 Relecture volontairement resserrée sur ce qui empêche une mise en production : bug de correctness, construction, CI. Le reste (mise en page, capitalisation, pagination, jauges, micro-courbes, navigation sous 900 px) tient et n'appelle rien de ma part. **Vérifié localement sur `4ee28e6` :** `npm ci`, `npm run test:unit` (408 verts), `npm run build` avec `VITE_API_BASE` — tout passe, comme les cinq jobs de la forge. Rien ne bloque la chaîne. Les deux défauts ci-dessous sont des défauts de *données affichées*, et ils touchent tous deux la période que cette PR met en tête de chaque écran — c'est-à-dire son apport principal. ### 1. Les séries survivent au changement d'écran, sous la mauvaise étiquette `fenetre` est un état unique du magasin, et chaque vue le pose à l'arrivée avant de rappeler `chargerSites()`. Mais `afficherTousLesSites()` ne relançait une série qu'en **l'absence** d'entrée : ```js if (!series.value[site.site_id]) _chargerSerie(site.site_id) ``` Les entrées existent déjà après le premier écran, donc rien ne repart. Parcours : `/graphiques` (24 h) → `/comparaison` pose `7j` → le graphique de comparaison affiche les **points horaires de 24 h** sous un sélecteur qui indique « 7 j ». Et au retour, les micro-courbes du tableau du parc montrent sept ou trente jours pendant que l'en-tête annonce « 24 h » et que le profil, lui, a bien été rechargé. Deux périodes sur le même écran — exactement le défaut que la PR entend supprimer, déplacé d'un cran. Reproduit par un test avant correction : après `fenetre = '7j'` puis `chargerSites()`, les trois entrées de `series` portaient encore `fenetre: '24h'` et `mesuresSite` n'avait été appelé que trois fois, toutes en `24h`. **Correction :** chaque entrée de `series` retient la fenêtre pour laquelle elle a été demandée — pendant son chargement et sur son échec comprises — et c'est cette marque, non la simple présence de l'entrée, qui décide du rechargement. Un remontage sur la même fenêtre ne redemande toujours rien. ### 2. `ProfilHoraireParc` reste écrit pour 24 h au pas horaire Le composant est figé sur `'1h'` en cinq endroits (titre, étiquettes d'axe, résumé pour lecteur d'écran, en-tête et corps du tableau équivalent), ce qui se tenait tant que `profilParc` était lui-même figé à 24 h. Depuis que le sélecteur le commande, sur `7j` / `30j` : - le titre annonce **« Profil horaire du parc, 24 h »** au-dessus de trente jours de relevés ; - `etiquetteAxe(t, '1h')` sur un point journalier rend l'heure de son seau, donc **« 00 h » répété** sur tous les points de l'axe et toutes les lignes du tableau ; - le résumé lu à la place du dessin dit « sur 7 **heures** », et la colonne s'intitule « Heure (UTC) » ; - `PAS_ETIQUETTE = 4` ne laissait que deux étiquettes sur sept points. **Correction :** titre, étiquettes, résumé et en-tête se règlent sur `pas` et `fenetre` **rendus par l'API** (`SerieParcOut`), pas déduits de la fenêtre demandée — c'est l'API qui décide du pas. L'espacement des étiquettes se calcule (six au plus) et vaut toujours quatre sur 24 h. Le titre devient « Profil journalier du parc, 7 jours » le cas échéant. ### Au passage Le gabarit `serie()` de `graphique.test.js` portait `fenetre: '7j'` quand le magasin démarre maintenant à `24h` : la réponse simulée contredisait la requête. Corrigé pour refléter ce que rend l'API, sinon les deux tests « ne relance pas les sites déjà chargés » passaient pour la mauvaise raison. ### État `412 tests verts` (408 + 4 de non-régression), `npm run build` ok. Je ne fusionne pas : le correctif touche le magasin et un composant, il vaut un regard de l'auteur avant. Deux remarques **non bloquantes**, laissées telles quelles : sur `/comparaison`, `changerFenetre()` redemande aussi `mesuresParc` alors que l'écran n'affiche pas le profil du parc (un appel pour rien, sans effet visible) ; et `SitesATraiter` formate `derniere_releve` sans garde, ce qui donnerait « depuis 00:00 » si l'API rendait un jour ce champ nul — le contrat le déclare non nullable aujourd'hui.

olivier added 1 commit 2026-09-08 14:33:12 +00:00

Fusionne develop : la refonte du tableau de bord rencontre les lectures de la zone or ... de29d556d3

Cinq conflits, tous sur le tableau de bord, tous de la même forme : develop a
ajouté un comportement là où la #184 avait renommé ou refait la structure. Rien
n'a été arbitré au profit d'un seul côté — le comportement de develop est
reporté dans la structure de la #184.

- `glossaire.js` : les quatre régimes d'imputation de develop (#199, `measured`
  la mesure et `none` le trou assumé) dans la forme d'écriture de la #184.
  `capitaliser` reste.
- `FicheSite.vue` : les mentions de qualité et de dernière valeur connue (#199)
  et le garde sur l'unité d'une marge nulle, avec la capitalisation française
  et `formaterPct` de la #184.
- `GraphiqueSite.vue` : la prévision absente du #37 garde sa structure, l'écart
  garde le formateur français — c'est-à-dire une virgule décimale, ce que
  `toFixed(1)` ne donnait pas.
- `SyntheseParc.vue` : la #184 a renommé « .pavé* » en « .mesure* » et refait le
  bandeau ; les deux faits que develop y avait ajoutés sont reportés dans la
  nouvelle nomenclature — la mention d'un total partiel (#199) et les deux
  absences distinctes de la prévision (#37).
- `TableauSites.vue` : seuls les imports divergeaient ; les mentions du #199 se
  sont posées d'elles-mêmes dans la colonne « Conso. » refaite.

Un piège au passage, dans le report de la mention de total partiel :
`.mesure__second--partiel` et `.mesure__second` pèsent une classe chacune, donc
c'est l'ordre qui tranche. Posée avant, la teinte de vigilance était écrasée par
l'encre secondaire et rien ne distinguait plus un total partiel — exactement la
collision de spécificité que cette PR corrige sur `.tableau__num`. La règle
passe après, et `revue-visuelle.test.js` le retient.

Trois cas ajoutés : la mention de total partiel n'avait aucun test de son côté,
et elle vient de changer de nom.

425 tests verts, `npm run build` ok.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

olivier commented 2026-09-08 14:33:54 +00:00

Member

Copy link

Conflits résolus : develop fusionné dans la branche (de29d55)

mergeable est repassé à True. Cinq fichiers étaient en conflit, tous sur le tableau de bord, et tous de la même forme : develop a ajouté un comportement là où la #184 avait renommé ou refait la structure. Rien n'a été arbitré au profit d'un seul côté — le comportement de develop est reporté dans la structure de la #184.

Fichier	Ce que develop apportait	Comment c'est résolu
api/glossaire.js	#199 : quatre régimes d'imputation, measured = la mesure, none = le trou assumé	les quatre entrées, dans la forme d'écriture de la #184 ; capitaliser reste
FicheSite.vue	#199 : mention de qualité et de dernière valeur connue ; garde sur l'unité d'une marge nulle	les deux, avec la capitalisation française et formaterPct de la #184
GraphiqueSite.vue	#37 : pas de prévision → pas de ligne, et un message à la place	structure de develop, formateur français de la #184 pour l'écart : toFixed(1) rendait « 2.7 % », pas « 2,7 % »
SyntheseParc.vue	#199 : mention d'un total partiel ; #37 : deux absences distinctes de la prévision	la #184 avait renommé .pavé* en .mesure* et refait le bandeau ; les deux faits sont reportés dans la nouvelle nomenclature
TableauSites.vue	#199 : les deux mentions sous « Conso. »	seuls les imports divergeaient ; les mentions se sont posées d'elles-mêmes dans la colonne refaite

Un piège trouvé en reportant la mention de total partiel

.mesure__second--partiel et .mesure__second pèsent une classe chacune : c'est donc l'ordre des règles qui tranche. Posée avant, la teinte de vigilance était écrasée par color: var(--ev-ink-500) et plus rien à l'écran ne distinguait un total partiel d'un total complet — exactement la collision de spécificité que cette PR corrige par ailleurs sur .tableau__num. La règle passe après, et revue-visuelle.test.js le retient, là où vivent déjà les trois autres cas de ce genre.

Couverture

La mention de total partiel n'avait aucun test du côté de develop, et elle vient de changer de nom : trois cas ajoutés (mention présente sur parc incomplet, absente sur parc complet, ordre de cascade).

Les assertions de develop passent toutes sans être touchées — « dernière connue » (TableauSites.test.js), « aucune prévision servie » (SyntheseParc.test.js), libelleMethode('none') === 'trou assumé' (glossaire.test.js) : le report a bien gardé les comportements qu'elles gardent.

État

425 tests verts (38 fichiers), npm run build ok, aucun marqueur de conflit résiduel, package-lock.json inchangé. La CI tourne sur de29d55 — elle couvre cette fois aussi le Python et l'Ansible que la fusion fait entrer. Je ne fusionne toujours pas : à Marvin de valider le report, en particulier l'arbitrage formaterPct sur l'écart de GraphiqueSite.vue et le placement de la mention partielle sous le pavé « Consommation » plutôt que dans « Disponibilité », qui porte déjà « n/m mesurés ».

## Conflits résolus : `develop` fusionné dans la branche (de29d55) `mergeable` est repassé à `True`. Cinq fichiers étaient en conflit, tous sur le tableau de bord, et tous de la même forme : `develop` a ajouté un **comportement** là où la #184 avait renommé ou refait la **structure**. Rien n'a été arbitré au profit d'un seul côté — le comportement de `develop` est reporté dans la structure de la #184. | Fichier | Ce que `develop` apportait | Comment c'est résolu | |---|---|---| | `api/glossaire.js` | #199 : quatre régimes d'imputation, `measured` = la mesure, `none` = le trou assumé | les quatre entrées, dans la forme d'écriture de la #184 ; `capitaliser` reste | | `FicheSite.vue` | #199 : mention de qualité et de dernière valeur connue ; garde sur l'unité d'une marge nulle | les deux, avec la capitalisation française et `formaterPct` de la #184 | | `GraphiqueSite.vue` | #37 : pas de prévision → pas de ligne, et un message à la place | structure de `develop`, **formateur français de la #184** pour l'écart : `toFixed(1)` rendait « 2.7 % », pas « 2,7 % » | | `SyntheseParc.vue` | #199 : mention d'un total partiel ; #37 : deux absences distinctes de la prévision | la #184 avait renommé `.pavé*` en `.mesure*` et refait le bandeau ; les deux faits sont reportés dans la nouvelle nomenclature | | `TableauSites.vue` | #199 : les deux mentions sous « Conso. » | seuls les imports divergeaient ; les mentions se sont posées d'elles-mêmes dans la colonne refaite | ### Un piège trouvé en reportant la mention de total partiel `.mesure__second--partiel` et `.mesure__second` pèsent **une classe chacune** : c'est donc l'ordre des règles qui tranche. Posée avant, la teinte de vigilance était écrasée par `color: var(--ev-ink-500)` et plus rien à l'écran ne distinguait un total partiel d'un total complet — exactement la collision de spécificité que cette PR corrige par ailleurs sur `.tableau__num`. La règle passe après, et `revue-visuelle.test.js` le retient, là où vivent déjà les trois autres cas de ce genre. ### Couverture La mention de total partiel n'avait **aucun test** du côté de `develop`, et elle vient de changer de nom : trois cas ajoutés (mention présente sur parc incomplet, absente sur parc complet, ordre de cascade). Les assertions de `develop` passent toutes sans être touchées — « dernière connue » (`TableauSites.test.js`), « aucune prévision servie » (`SyntheseParc.test.js`), `libelleMethode('none') === 'trou assumé'` (`glossaire.test.js`) : le report a bien gardé les comportements qu'elles gardent. ### État `425 tests verts` (38 fichiers), `npm run build` ok, aucun marqueur de conflit résiduel, `package-lock.json` inchangé. La CI tourne sur `de29d55` — elle couvre cette fois aussi le Python et l'Ansible que la fusion fait entrer. Je ne fusionne toujours pas : à Marvin de valider le report, en particulier l'arbitrage `formaterPct` sur l'écart de `GraphiqueSite.vue` et le placement de la mention partielle sous le pavé « Consommation » plutôt que dans « Disponibilité », qui porte déjà « n/m mesurés ».

olivier approved these changes 2026-09-08 14:34:36 +00:00

olivier merged commit 5797f13b0a into develop 2026-09-08 14:39:33 +00:00

olivier deleted branch marvin/184-refonte-tableau-de-bord 2026-09-08 14:39:34 +00:00

olivier referenced this pull request from a commit 2026-09-08 14:39:34 +00:00

Merge pull request 'dashboard : surveiller, comparer et alerter sur trois ecrans (#184)' (#207) from marvin/184-refonte-tableau-de-bord into develop

olivier referenced this pull request from a commit 2026-09-08 14:44:51 +00:00

Fusionne develop : la #207 est passée, la branche se réduit à ses 21 fichiers

Sign in to join this conversation.

Reviewers

No reviewers

olivier

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

marvin

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

No description provided.