Retour visuel quand une commande échoue (dashboard) — 3 pistes — catégorie feature-request-core

Hello ! :waving_hand:

En travaillant sur les correctifs Netatmo (PR #2618), on a constaté qu’une commande qui échoue (ex : consigne de thermostat alors que le service est injoignable) est invisible pour l’utilisateur : l’API répond immédiatement (architecture asynchrone des actions), le dashboard affiche la valeur demandée de façon optimiste, et l’échec ne vit que dans les logs serveur. L’utilisateur croit sa consigne appliquée alors que rien n’est parti.

La #2618 pose le prérequis pour Netatmo (l’erreur se propage désormais jusqu’à l’exécuteur d’action au lieu d’être avalée dans le service), et on aimerait proposer la suite. Trois pistes, de la plus légère à la plus ambitieuse — @pierre-gilles on aimerait ton avis sur le concept avant d’écrire quoi que ce soit :slightly_smiling_face:

Piste A — Réconciliation d’état (recommandée)
En cas d’échec, le serveur émet un événement websocket et le dashboard réaffiche la vraie valeur (annulation de la mise à jour optimiste) avec un indicateur discret et temporaire sur le contrôle concerné (:warning: « Commande non appliquée »). Pas de nouveau canal de notification : juste une UI honnête, là où l’utilisateur regarde. Fonctionne identiquement PC / mobile / tablette puisque l’indicateur vit dans la carte de l’appareil.

Piste B — Message via l’API existante (pattern de la notif de mise à jour 4.58)
Échec → message à l’utilisateur qui a déclenché la commande, via l’API de messages : visible dans Discussion, Telegram, push Gladys Plus. Avec dédoublonnage pour éviter le spam si un service est durablement injoignable.

Piste C — Toast générique
Un petit composant de toast global (websocket ui.notification), alimenté d’abord par les échecs de commande, réutilisable ensuite par d’autres domaines du core. C’est l’option la plus riche mais aussi celle qui ouvre le plus de questions (persistance, historique…).

Notre préférence : A, éventuellement complétée par B — les deux restent petites et n’introduisent pas de « système de notifications » à maintenir. Bien sûr, C est également envisageable en supplément par la suite sans être « obligatoire ». Qu’en penses-tu ?