fix(tableau) : le bouton ne dit plus « Chiffres à jour » quand rien n'a bougé #1819

Merged

foXaCe merged 1 commit from fix/bouton-releve-en-echec into main

2026-10-17 13:50:24 +02:00

hermes-bot commented

2026-10-17 13:42:48 +02:00

Collaborator

Le demi-mensonge qui restait

Le correctif des jetons (#1815) a réparé la collecte, mais il a laissé le défaut d'affichage qui l'avait cachée pendant des heures.

tableau-bord.py sort en 1 quand « une chaîne a échoué ». Ce code est un succès partiel, et les deux côtés le prenaient pour un succès franc :

le service (etat.rs) ne remontait aucune cause pour lui — la condition était « tout sauf 0 et 1 » ;
le front (lib/cadre/actualiser.js) rendait ok: true dès que le code valait 0 ou 1.

Résultat mesuré le 2026-10-17 : derniere-collecte.json figé à 12:06:38, clics à 12:11:55 et 12:22:27 sans effet, et l'opérateur qui lit « Chiffres à jour » sur des chiffres vieux de six heures.

La règle, maintenant — et elle est falsifiable

Un code de sortie dit ce que le script a fait, jamais que les chiffres ont bougé. C'est la date de collecte qui tranche (progression) : celle que la page affichait avant le relevé, contre celle que /etat annonce après. Quand l'une des deux est illisible, on ne conclut rien (null) — on n'accuse pas à tort un relevé correct.

Ce que dit le relevé	Ce que le bouton dit
code 0, date avancée	« Chiffres à jour » (6 s), comme avant
code 1, date avancée (une chaîne en échec)	l'avertissement du serveur, à la place de « Chiffres à jour »
code 0 ou 1, date non avancée	« Le relevé n'a pas rafraîchi les chiffres… » + la cause

L'avertissement traverse le rechargement par sa propre clé de session (CLE_AVERTISSEMENT_RELEVE), à côté de celle de « Chiffres à jour » — un nombre que la page et les bancs lisent tel quel, qu'un avertissement ne doit pas rendre illisible.

Côté service

Au code 1, la cause vient des erreurs de la collecte : « 2 chaînes en échec, dont : … » (bornée, sans secret). Les trois fonctions de cause sortent dans rust/service/src/causes.rs : etat.rs passait à 604 lignes, au-delà du plafond de 600 lignes (_tableau/garde-fous.json, extension rs), sans dérogation — 604 → 529 lignes, aucune dérogation ajoutée.

Mesure

front : 560 tests, 61 fichiers, 0 échec (npm ci, npx vitest run), 4 tests ajoutés (le cas « code 1 sans progression », le code 1 avec progression, progression, l'avertissement qui traverse le rechargement) ;
Rust : cargo test -p service --locked vert ;
doc : _tableau/LXC-132.md, section « Le bouton ne dit plus « Chiffres à jour » quand rien n'a été rafraîchi ».

## Le demi-mensonge qui restait Le correctif des jetons (#1815) a réparé la collecte, mais il a laissé le défaut d'affichage qui l'avait cachée pendant des heures. `tableau-bord.py` sort en **1** quand « une chaîne a échoué ». Ce code est un succès **partiel**, et les deux côtés le prenaient pour un succès franc : - le service (`etat.rs`) ne remontait aucune `cause` pour lui — la condition était « tout sauf 0 et 1 » ; - le front (`lib/cadre/actualiser.js`) rendait `ok: true` dès que le code valait 0 ou 1. Résultat mesuré le 2026-10-17 : `derniere-collecte.json` figé à 12:06:38, clics à 12:11:55 et 12:22:27 sans effet, et l'opérateur qui lit **« Chiffres à jour »** sur des chiffres vieux de six heures. ## La règle, maintenant — et elle est falsifiable Un code de sortie dit ce que le **script** a fait, jamais que les chiffres ont bougé. C'est la **date de collecte** qui tranche (`progression`) : celle que la page affichait avant le relevé, contre celle que `/etat` annonce après. Quand l'une des deux est illisible, on ne conclut rien (`null`) — on n'accuse pas à tort un relevé correct. | Ce que dit le relevé | Ce que le bouton dit | |---|---| | code 0, date avancée | « Chiffres à jour » (6 s), comme avant | | code 1, date avancée (une chaîne en échec) | l'avertissement du serveur, **à la place** de « Chiffres à jour » | | code 0 **ou** 1, date non avancée | « Le relevé n'a pas rafraîchi les chiffres… » + la cause | L'avertissement traverse le rechargement par sa propre clé de session (`CLE_AVERTISSEMENT_RELEVE`), à côté de celle de « Chiffres à jour » — un nombre que la page et les bancs lisent tel quel, qu'un avertissement ne doit pas rendre illisible. ## Côté service Au code 1, la `cause` vient des `erreurs` de la collecte : « 2 chaînes en échec, dont : … » (bornée, sans secret). Les trois fonctions de cause sortent dans `rust/service/src/causes.rs` : `etat.rs` passait à 604 lignes, au-delà du plafond de 600 lignes (`_tableau/garde-fous.json`, extension `rs`), sans dérogation — **604 → 529 lignes**, aucune dérogation ajoutée. ## Mesure - front : **560 tests, 61 fichiers, 0 échec** (`npm ci`, `npx vitest run`), 4 tests ajoutés (le cas « code 1 sans progression », le code 1 avec progression, `progression`, l'avertissement qui traverse le rechargement) ; - Rust : `cargo test -p service --locked` vert ; - doc : `_tableau/LXC-132.md`, section « Le bouton ne dit plus « Chiffres à jour » quand rien n'a été rafraîchi ».

hermes-bot added 1 commit

2026-10-17 13:42:48 +02:00

fix(tableau): le bouton ne dit plus « Chiffres à jour » quand rien n'a bougé

Tests du tableau (Rust + Svelte) / Front Svelte (_tableau/front) (pull_request) Successful in 1m59s

Details

Tests du tableau (Rust + Svelte) / Rust (_tableau/rust) (pull_request) Successful in 7m25s

Details

27a276cdb2

Le correctif des jetons a réparé la collecte, pas le défaut qui la cachait : tableau-bord.py sort
en 1 quand « une chaîne a échoué », et les DEUX côtés prenaient ce code pour un succès franc — le
service ne remontait aucune cause pour lui (etat.rs), et le front (lib/cadre/actualiser.js) rendait
ok: true dès que le code valait 0 ou 1. L'opérateur lisait donc « Chiffres à jour » pendant que
derniere-collecte.json restait figé six heures (mesuré le 2026-10-17 : figé à 12:06:38, clics à
12:11:55 et 12:22:27 sans effet).

La règle est maintenant falsifiable : un code de sortie dit ce que le SCRIPT a fait, jamais que les
chiffres ont bougé. C'est la date de collecte qui tranche (progression, actualiser.js) :

- code 0, date avancée  : « Chiffres à jour » (6 s), comme avant ;
- code 1, date avancée  : l'avertissement du serveur, à la place de « Chiffres à jour » — il
  traverse le rechargement par sa propre clé (CLE_AVERTISSEMENT_RELEVE), à côté de celle des
  chiffres, un nombre que la page lit tel quel ;
- code 0 ou 1, date non avancée : l'échec et sa cause, « Le relevé n'a pas rafraîchi les chiffres… ».

Quand l'une des deux dates est illisible, on ne conclut rien : on n'accuse pas à tort un relevé
correct.

Côté service, la cause du code 1 vient des erreurs de la collecte — « 2 chaînes en échec, dont : … »,
bornée et sans secret (rust/service/src/causes.rs). Les trois fonctions de cause sortent d'etat.rs,
qui passait au-delà du plafond de 600 lignes (_tableau/garde-fous.json, extension rs) : 604 → 529
lignes, aucune dérogation ajoutée.

Mesuré : front 560 tests verts (61 fichiers), Rust cargo test -p service vert (27 fichiers de bancs).

foXaCe merged commit 1d3a5f5e98 into main

2026-10-17 13:50:24 +02:00

foXaCe deleted branch fix/bouton-releve-en-echec

2026-10-17 13:50:24 +02:00