Le besoin
Aujourd’hui, les widgets du dashboard sont tous développés dans le cœur de Gladys. Une intégration (notamment externe, via le SDK) ne peut pas proposer de widget spécifique à son domaine, alors que c’est souvent là que la donnée prend tout son sens : suivi de production solaire, état d’un robot aspirateur, planning de charge d’une voiture électrique, etc.
La proposition
Permettre à une intégration de déclarer un ou plusieurs widgets via un schéma JSON, sur le même principe que les pages de configuration des intégrations externes. L’intégration décrit quoi afficher (valeurs, graphiques, boutons, états, jauges…), et c’est Gladys qui décide comment l’afficher.
Volontairement, pas de HTML custom ni d’iframe : c’est un choix de philosophie. En restant déclaratif, le cœur de Gladys garantit pour tous les widgets, y compris tiers : la cohérence visuelle, le dark mode, le responsive mobile/tablette, les traductions, les performances et la non-régression quand l’interface évolue. C’est le même modèle que les widgets iOS : purement déclaratifs, et personne ne trouve que l’écosystème manque de richesse 
Les bénéfices
- Les intégrations deviennent complètes : leurs données ont enfin une vraie place sur le dashboard
- L’expérience reste propre et unifiée, quel que soit l’auteur du widget
- Le JSON étant validable, une IA pourra générer ou réparer ces widgets de manière fiable (et à terme, construire un dashboard entier à la demande)
- Le vocabulaire de composants peut s’enrichir progressivement dans le core, sans jamais rien casser, et chaque ajout profite à toutes les intégrations d’un coup
Pistes de réflexion
- Définir le vocabulaire de départ : quels composants de base ? (valeur + unité, graphique historique, bouton d’action, liste d’états…)
- Comment le widget récupère ses données : features d’appareils existantes, ou endpoint exposé par l’intégration ?
- Versionner le schéma pour que les widgets restent compatibles au fil des mises à jour
