Nouvelle version du SDK, v0.8.0 avec un nouveau champ « section », et lien vers la documentation obligatoire sur la page de l’intégration
Edit: Template mise à jour pour la v0.8.0
Attention, le store a été mis à jour et est plus strict, il faut maintenant une documentation obligatoire dans les intégrations 
Pensez à faire tourner :
npx github:GladysAssistant/integration-store
Pour voir si votre intégration passe la validation, et corriger votre repo si besoin
(donnez ce message à Claude)
Nouvelle version du SDK : v0.9.0 !
Au programme :
- Gestion des intégrations de type « communication » mono-directionnelle (FreeMobile, Callmebot, ntfy.sh, etc…)
- Gestion des webhooks Gladys Plus pour les intégrations de type Netatmo qui ont besoin d’un webhook Cloud
Ok j’ai mis à jour la PR Gladys avec 3 changements :
1. Bandeau « Votre appareil n’est pas dans la liste ? » — il met désormais en avant Matter et les intégrations externes de la communauté : « chacun peut en créer une et la publier dans le store, elle apparaît alors dans cette liste »,
2. Dépréciation annoncée de Tuya, MELCloud, Telegram et Netatmo — j’ai fait les deux pour que ce soit sans ambiguïté :
- un badge rouge « Bientôt dépréciée » sur leur carte du catalogue (flag
deprecateddans les JSON d’intégrations, rendu dansIntegrationTags) ; - une alerte en haut de la page de chacune des quatre intégrations (composant partagé
DeprecationWarning) : « sera bientôt dépréciée au profit d’une intégration externe équivalente… les deux versions vont co-exister dans le catalogue pendant la transition — vous pouvez continuer à utiliser celle-ci pour le moment ».
3. Erreurs d’authentification au redémarrage (close code 4000) — diagnostic confirmé, et c’était même pire que ça : sans variable d’env JWT_SECRET, le secret est régénéré à chaque boot de Gladys, et comme start() redémarrait le conteneur existant avec le token JWT figé dans son env (signé avec l’ancien secret), l’intégration bouclait sur le refus sans jamais se réparer. Deux corrections :
- le superviseur signe désormais les JWT d’intégration avec son propre secret, généré une fois et persisté en variable (
EXTERNAL_INTEGRATION_JWT_SECRET) — il survit aux redémarrages et aux restaurations de sauvegarde, en cohérence avec les conteneurs qu’il valide ; - auto-réparation dans
start(): avant de redémarrer un conteneur existant,verifyContainerTokeninspecte le token de son env (signature avec le secret courant + bon service + bonnetoken_version) ; s’il est périmé, le conteneur est recréé avec un token frais au lieu d’être redémarré pour rien. Ça répare aussi, dès le prochain boot, les conteneurs créés avant ce correctif.
Pour info @cicoub13 @Terdious @Lokkye :
[
{
"store_slug": "callemand/gladys-airzone-cloud",
"level": "error",
"reason": "docker_image: image is not publicly pullable (registry auth denied, HTTP 403)",
"checked_at": "2026-07-23T15:30:08.198Z"
},
{
"store_slug": "cicoub13/gladys-tp-link",
"level": "error",
"reason": "docs/en.md: file not found — user documentation is mandatory",
"checked_at": "2026-07-23T15:30:08.198Z"
},
{
"store_slug": "Terdious/gladys-netatmo",
"level": "error",
"reason": "docs/en.md: file not found — user documentation is mandatory",
"checked_at": "2026-07-23T15:30:08.198Z"
},
{
"store_slug": "Terdious/gladys-tuya",
"level": "error",
"reason": "docs/en.md: file not found — user documentation is mandatory",
"checked_at": "2026-07-23T15:30:08.198Z"
}
]
Source: https://integration-store-storage.gladysassistant.com/rejected.json
Je dois dire que je suis impressionné de la vitesse de déploiementr de ce nouveau système, du nombre d’intégrations déjà disponible et de la simplicité à tous les niveaux :
- Développement,
- Déploiement,
- Mise à jour,
- Intégration des devices.
Bien sûr, cela aurait été impossible a une telle cadence sans l’IA. Mais décisionnaire (@pierre-gilles) et prompteurs y sont pour beaucoup !!
Les prochains mois sont très prometteurs de ce côté ^^
@pierre-gilles comment ça se passe pour la sauvegarde des intégrations externe si on veut migrer de PC par exemple ?
Je rajouterai aussi des préconisations sur le choix des images Docker pour éviter l’utilisation de grosses images. Préférence pour Alpine qui est ultra léger et très utilisé pour notre cas.
Cela m’amène une autre question. Est ce que Gladys ne devrait pas également vérifier si l’image utilisée n’est pas trop vieille ou sujet à des failles de sécurité ? Juste une information avant d’installer l’intégration.
On peut également rajouter la taille de l’image en plus.
Merci @Terdious pour tous tes développements, effectivement je suis moi aussi très impressionné par la vitesse de développement qu’on peut avoir, c’est fou ça va révolutionner le projet 
Ce week-end, j’étais dans la montagne sans réseau, et pourtant 13 intégrations ont pu être publiées sur le store, impensable dans l’ancien système d’intégrations ^^
C’est cool, on va commencer avec un store déjà rempli !
Les installations seront ré-installées automatiquement, car toutes les données sont stockée en base uniquement
Voici le déroulé exact expliqué par Claude :
Ce qui est dans la sauvegarde. Le backup Gladys Plus est un tar.gz contenant la base SQLite (+ le dossier DuckDB) — et tout ce qui définit une intégration externe est en base : la ligne t_service (image Docker, manifeste, store_slug, version, token_version, statut), la configuration (variables scopées au service, y compris les secrets et tokens OAuth), les appareils, les classes matérielles accordées, les profils de contact, et le secret JWT du superviseur (EXTERNAL_INTEGRATION_JWT_SECRET, persisté en variable justement pour survivre aux restaurations).
Ce qui se passe au démarrage sur la nouvelle machine.
init()réconcilie les conteneurs par label Docker — le commentaire du code cite précisément le cas restauration : lescontainer_iden base sont obsolètes ; comme aucun conteneur n’existe sur le nouveau PC, ils sont remis ànull(externalIntegration.init.js:70-84).- Les intégrations démarrent ensuite par le cycle de vie standard des services. Dans
start(), pas decontainer_id→createIntegrationContainer: l’image Docker est re-téléchargée depuis le registre, un conteneur neuf est créé avec un JWT fraîchement signé (valide, puisque le secret et letoken_versionviennent de la base restaurée), le réseau privé et les sous-conteneurs sont recréés, et la config est repoussée à l’intégration à la connexion. - La règle « STOPPED = ignoré au boot » s’applique comme pour les services internes : une intégration arrêtée avant la sauvegarde reste arrêtée, sans être désinstallée.
Les deux limites à connaître.
- Il faut évidemment Docker et du réseau sur la nouvelle machine : les images ne sont pas dans le backup, elles sont re-pullées (une intégration passerait en ERROR si le registre est injoignable, et redémarrable ensuite).
- Le dossier
/datan’est pas sauvegardé. Chaque intégration a un bind<base>/external-integrations/<selector>→/data(et les volumes des sous-conteneurs vivent dessous). La doctrine veut que les intégrations soient sans état (les états vivent dans Gladys), donc en pratique ça ne devrait rien casser — mais une intégration qui y stocke un état local (ou un sous-conteneur type broker avec persistance) repart de zéro. Si on veut couvrir ça un jour, il faudrait inclure ce dossier dans le backup, avec la question de la taille à trancher.
Bien vu ! je corrige.
C’est le cas du template par défaut, je préconise l’image Node-Alpine qui est super légère
Je pense que, pour une V1, la proposition actuelle est suffisante.
Si un utilisateur est suffisamment à l’aise techniquement pour chercher ce type d’informations, il les retrouvera déjà sur le dépôt GitHub de l’intégration, qui est référencé.
Je pense aussi qu’il faut éviter d’entrer dans des détails trop techniques. L’objectif de Gladys est de proposer un produit propre, accessible au grand public, avec le moins de jargon possible.
Les intégrations externes ont justement été conçues pour être transparentes : l’utilisateur n’a quasiment pas conscience qu’un conteneur externe est en cours d’exécution. L’expérience est volontairement très proche de celle des intégrations natives de Gladys aujourd’hui
J’avance très vite aujourd’hui ! 
J’ai déjà mergé sur la branche master du dépôt Gladys :
- La spécification technique du développement.
- L’ensemble de l’implémentation.
J’ai ensuite publié une nouvelle image de développement :
gladysassistant/gladys:dev
Je l’ai déployée sur mon instance de production. J’ai déjà migré mon intégration MelCloud vers le nouveau système et je suis en train de faire la même chose pour Telegram.
L’objectif est de valider tout ça en conditions réelles pendant quelques jours. Si tout se passe bien, la fonctionnalité sera publiée dans la semaine.
Je suis assez confiant, pour l’instant ça part très bien !
je vais partager cette image sur X
Bon, je suis super content des intégrations externes chez moi !!
Je penses que je vais partir sur une release jeudi soir ! 
Déjà 20 intégrations externes ! 
Quand on sait qu’on n’a eu que 36 intégrations internes en 6 ans de Gladys v4, c’est déjà un rythme incroyable. Et je pense que ça ne fera que s’accélérer à mesure qu’on convaincra de nouveaux développeurs de contribuer.
Je crois qu’on tient vraiment quelque chose !! 
Release DEMAIN SOIR
bon je n’ai pas pu m’empêcher de lire la release note 4.84.0 sur le blog et c’est de la balle 
Petite question pour les intégrations internes, qui existent maintenant en externe, et qui continuent en parallèle : est-ce qu’il y a/aura un outil de « bascule automatique » de l’interne vers l’externe ?
Par exemple avec Telegram, mes infos sont sur l’interne, je clique un bouton et tout passe sur l’externe et me désactive l’interne ? (oh que oui je suis fainéant !! 
)
Salut @mutmut ! Merci pour ton message !!
Non, il n’y a pas de bascule automatique. Mais je te rassure, c’est vraiment très simple :
Tu vas dans l’intégration Telegram actuelle, tu copies ton token, tu désactives l’intégration, puis tu installes la nouvelle intégration externe, tu colles ton token et tu suis le processus d’appairage. 
J’avoue que je préfère que vous (les power users de Gladys) passiez par le processus d’installation “classique” que suivront ensuite tous les utilisateurs. Ça nous permettra d’avoir de vrais retours d’expérience sur l’installation des intégrations externes et d’améliorer le parcours si besoin.