OneXpertise/PlugAnalytics

Watch

Fork 0

generated from srsk7896/pipeline-vibecoding

[Correction] Fausse alerte d'horloge et commande de remise à l'heure erronée (fuseau du serveur ignoré) #3

New issue

Open

opened 2026-09-24 15:26:10 +00:00 by srsk7896 · 0 comments

srsk7896 commented

2026-09-24 15:26:10 +00:00

Owner

Origine : AUDIT_001, constat n° 1 (Élevée), avec le constat n° 3 (Moyenne) qui s'y rattache.

Problème

Pour savoir si l'horloge d'un boîtier est juste, l'outil la compare à l'heure du serveur. Or le conteneur de production tourne en UTC (temps universel), alors que les boîtiers sont réglés à l'heure française.

Pour un boîtier OneOS v5, qui n'indique pas son fuseau, l'outil voit donc 1 h (hiver) ou 2 h (été) d'écart là où il n'y en a aucun. Il affiche une alerte « horloge non à jour » et propose une commande (FEAT-11) qui recule réellement l'horloge du boîtier de 1 ou 2 heures.

Comportement observé

Reproduit par un test jetable lors de l'audit : boîtier v5 affichant Current system time : 24/06/26 14:01:40, à l'heure exacte de Paris (été), et serveur en UTC.

Écart calculé : 2h0m0s, Notable = true.
Remédiation proposée : date 24/06/26 puis time 12:01:40.

En OneOS v6, l'écart est bien calculé, car le boîtier fournit son décalage ±hhmm. En revanche, la commande time … est rédigée à l'heure UTC du serveur, pas dans le fuseau du boîtier.

Comportement attendu

Un boîtier v5 à l'heure de Paris ne déclenche aucune alerte d'horloge, quel que soit le fuseau du serveur.
La commande proposée donne l'heure dans le fuseau du boîtier : fuseau de référence Europe/Paris en v5, décalage lu sur le boîtier en v6.

Étapes de reproduction

Lancer l'application avec TZ=UTC, ou dans l'image Docker publiée (aucune variable TZ, base distroless/static).
Analyser une sortie v5 dont Current system time correspond à l'heure de Paris actuelle.
Constater l'alerte d'horloge et la commande time décalée de 1 à 2 h.

Hypothèse de cause

internal/web/server.go:210 : now := time.Now(), qui prend le fuseau du processus (UTC dans le conteneur).
internal/analysis/analyze.go:117-141 (clockSkew) : en v5, now et l'heure du boîtier sont comparés comme des « heures affichées », sans tenir compte du fuseau.
internal/analysis/remediation.go:40-50 (clockCmd) : now.Format("02/01/06") / now.Format("15:04:05") dans le fuseau du serveur.
Dockerfile : aucune variable TZ, et le binaire n'embarque pas time/tzdata.
Les tests actuels passent parce qu'ils tournent sur un poste réglé à l'heure de Paris.

Hypothèse : la commande OneOS time hh:mm:ss règle l'heure locale du boîtier, ce qui est le fonctionnement habituel. Si elle réglait l'heure UTC, le défaut ne toucherait que la v5.

Proposition / solution

Option la plus simple, sans nouvelle configuration :

Embarquer les fuseaux dans le binaire (import _ "time/tzdata" dans cmd/pluganalytics/main.go) et définir un fuseau de référence unique Europe/Paris, documenté dans _projet/design.md à côté des règles métier versionnées.
Calculer l'heure de référence dans ce fuseau (time.Now().In(paris)) et la transmettre à analysis.Evaluate, ou bien convertir dans clockSkew et buildRemediations.
En v6 (SystemTimeHasTZ = true), rédiger la commande dans le fuseau du boîtier : now.In(eq.SystemTime.Location()).
Afficher la mention « heure boîtier » dans l'en-tête de la colonne d'heure de la liste d'appels (internal/web/templates/diagnostic.gohtml:280), comme le fait déjà le PDF (internal/export/pdf.go:69).
Documenter le fuseau de référence dans le README.md, section Configuration.

Ne pas ajouter de variable d'environnement de fuseau tant qu'aucun besoin hors métropole n'est exprimé.

Critères d'acceptation

Test de table dans internal/analysis : serveur UTC et boîtier v5 à l'heure de Paris, en été et en hiver → Notable = false et aucune remédiation.
Test : boîtier v5 réellement décalé de 20 min → alerte présente, et commande time égale à l'heure de Paris.
Test : boîtier v6 en +0200 → commande time dans ce décalage.
Les tests passent quel que soit le fuseau de la machine (vérifier avec TZ=UTC go test ./...).
La colonne d'heure de la liste d'appels porte la mention « heure boîtier ».
Le README et _projet/design.md mentionnent le fuseau de référence.

Priorité proposée

Haute : en production, toutes les analyses v5 sont concernées, et l'outil donne une consigne qui dégrade le boîtier et fausse les historiques suivants.

Périmètre estimé

Zone concernée : backend (internal/analysis, cmd/pluganalytics), interface (un libellé), documentation
Impact attendu : localisé

Questions ouvertes

Existe-t-il des boîtiers hors fuseau métropolitain (DOM, étranger) dans le parc ? Si oui, il faudra trancher plus tard le comportement en v5, où le fuseau n'est pas détectable.

Labels proposés

type:bug
priority:high
area:backend

> Origine : AUDIT_001, constat n° 1 (Élevée), avec le constat n° 3 (Moyenne) qui s'y rattache. ## Problème Pour savoir si l'horloge d'un boîtier est juste, l'outil la compare à l'heure du **serveur**. Or le conteneur de production tourne en **UTC** (temps universel), alors que les boîtiers sont réglés à l'heure française. Pour un boîtier OneOS v5, qui n'indique pas son fuseau, l'outil voit donc 1 h (hiver) ou 2 h (été) d'écart là où il n'y en a aucun. Il affiche une alerte « horloge non à jour » et propose une commande (FEAT-11) qui **recule réellement l'horloge du boîtier** de 1 ou 2 heures. ## Comportement observé Reproduit par un test jetable lors de l'audit : boîtier v5 affichant `Current system time : 24/06/26 14:01:40`, à l'heure exacte de Paris (été), et serveur en UTC. - Écart calculé : `2h0m0s`, `Notable = true`. - Remédiation proposée : `date 24/06/26` puis `time 12:01:40`. En OneOS v6, l'écart est bien calculé, car le boîtier fournit son décalage `±hhmm`. En revanche, la commande `time …` est rédigée à l'heure UTC du serveur, pas dans le fuseau du boîtier. ## Comportement attendu - Un boîtier v5 à l'heure de Paris ne déclenche **aucune** alerte d'horloge, quel que soit le fuseau du serveur. - La commande proposée donne l'heure **dans le fuseau du boîtier** : fuseau de référence `Europe/Paris` en v5, décalage lu sur le boîtier en v6. ## Étapes de reproduction 1. Lancer l'application avec `TZ=UTC`, ou dans l'image Docker publiée (aucune variable `TZ`, base `distroless/static`). 2. Analyser une sortie v5 dont `Current system time` correspond à l'heure de Paris actuelle. 3. Constater l'alerte d'horloge et la commande `time` décalée de 1 à 2 h. ## Hypothèse de cause - `internal/web/server.go:210` : `now := time.Now()`, qui prend le fuseau du processus (UTC dans le conteneur). - `internal/analysis/analyze.go:117-141` (`clockSkew`) : en v5, `now` et l'heure du boîtier sont comparés comme des « heures affichées », sans tenir compte du fuseau. - `internal/analysis/remediation.go:40-50` (`clockCmd`) : `now.Format("02/01/06")` / `now.Format("15:04:05")` dans le fuseau du serveur. - `Dockerfile` : aucune variable `TZ`, et le binaire n'embarque pas `time/tzdata`. - Les tests actuels passent parce qu'ils tournent sur un poste réglé à l'heure de Paris. Hypothèse : la commande OneOS `time hh:mm:ss` règle l'heure **locale** du boîtier, ce qui est le fonctionnement habituel. Si elle réglait l'heure UTC, le défaut ne toucherait que la v5. ## Proposition / solution Option la plus simple, sans nouvelle configuration : 1. Embarquer les fuseaux dans le binaire (`import _ "time/tzdata"` dans `cmd/pluganalytics/main.go`) et définir un fuseau de référence unique `Europe/Paris`, documenté dans `_projet/design.md` à côté des règles métier versionnées. 2. Calculer l'heure de référence dans ce fuseau (`time.Now().In(paris)`) et la transmettre à `analysis.Evaluate`, ou bien convertir dans `clockSkew` et `buildRemediations`. 3. En v6 (`SystemTimeHasTZ = true`), rédiger la commande dans le fuseau du boîtier : `now.In(eq.SystemTime.Location())`. 4. Afficher la mention « heure boîtier » dans l'en-tête de la colonne d'heure de la liste d'appels (`internal/web/templates/diagnostic.gohtml:280`), comme le fait déjà le PDF (`internal/export/pdf.go:69`). 5. Documenter le fuseau de référence dans le `README.md`, section Configuration. Ne pas ajouter de variable d'environnement de fuseau tant qu'aucun besoin hors métropole n'est exprimé. ## Critères d'acceptation - [ ] Test de table dans `internal/analysis` : serveur UTC et boîtier v5 à l'heure de Paris, en **été et en hiver** → `Notable = false` et aucune remédiation. - [ ] Test : boîtier v5 réellement décalé de 20 min → alerte présente, et commande `time` égale à l'heure de Paris. - [ ] Test : boîtier v6 en `+0200` → commande `time` dans ce décalage. - [ ] Les tests passent quel que soit le fuseau de la machine (vérifier avec `TZ=UTC go test ./...`). - [ ] La colonne d'heure de la liste d'appels porte la mention « heure boîtier ». - [ ] Le README et `_projet/design.md` mentionnent le fuseau de référence. ## Priorité proposée **Haute** : en production, toutes les analyses v5 sont concernées, et l'outil donne une consigne qui dégrade le boîtier et fausse les historiques suivants. ## Périmètre estimé - Zone concernée : backend (`internal/analysis`, `cmd/pluganalytics`), interface (un libellé), documentation - Impact attendu : localisé ## Questions ouvertes - Existe-t-il des boîtiers hors fuseau métropolitain (DOM, étranger) dans le parc ? Si oui, il faudra trancher plus tard le comportement en v5, où le fuseau n'est pas détectable. ## Labels proposés - `type:bug` - `priority:high` - `area:backend`

No labels

No milestone

No project

No assignees

1 participant

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

OneXpertise/PlugAnalytics#3

No description provided.

Rows
Columns