Home Assistant 2026.9 ouvre le bus Modbus et resserre la surface de sécurité
Le 2 septembre 2026, Home Assistant 2026.9 modernise Modbus pour choisir un appareil industriel depuis l’interface sans écrire de YAML, et durcit l’instance en transmettant la vraie IP des connexions Cloud pour permettre le bannissement. Mettez à niveau si vous pilotez des équipements Modbus ou si votre instance est exposée.
2 septembre 2026. Home Assistant publie la version 2026.9, et le changement le plus important n’est pas le plus visible. Frenck, qui signe les notes de version, le dit sans détour : Modbus « n’a jamais été la partie la plus clinquante » de la plateforme — mais il pilote en silence onduleurs solaires, pompes à chaleur et compteurs d’énergie, à condition d’écrire soi-même sa table de registres en YAML. 2026.9 supprime ce mur. Dans la foulée, la même version durcit la surface de sécurité de l’instance exposée. Deux chantiers, une seule livraison.
Modbus passe du YAML à l’interface
Modbus est le protocole de facto des équipements industriels et énergétiques : compteurs, onduleurs, pompes à chaleur, systèmes de ventilation. Jusqu’à 2026.9, ajouter un tel appareil dans Home Assistant supposait de connaître son registre et de le décrire à la main. Résultat : une large catégorie de matériel restait hors de portée des utilisateurs non spécialistes.
La version 2026.9 change le modèle. Les intégrations qui savent déjà parler Modbus à un appareil donné partagent désormais une connexion unique au lieu de se battre pour la même liaison série. Concrètement, on choisit son appareil dans l’interface, comme n’importe quel autre périphérique, au lieu d’écrire une map de registres. Le commentaire de Frenck est explicite : « cela n’apparaîtra pas dans une capture d’écran, mais moderniser Modbus est de loin mon changement préféré de cette version ».
Pour le self-hosting appliqué à l’énergie, c’est un vrai déblocage : la barrière qui séparait l’automatisation domestique des équipements industriels tombe. Un onduleur ou un compteur Modbus devient un périphérique ordinaire.
Voir à travers le Cloud : la vraie IP, enfin
La seconde moitié de la version intéresse directement ceux qui exposent leur instance. Jusqu’ici, les tentatives de connexion passant par Home Assistant Cloud apparaissaient toutes comme venant de 127.0.0.1 — un message d’échec de connexion peu utile, qui masquait l’origine réelle. 2026.9 transmet désormais la vraie adresse IP de la source.
La conséquence est directe : il devient possible d’utiliser le bannissement par IP — ajouté à l’interface dans la version précédente — pour bloquer les tentatives malveillantes. Combiné à la double authentification (2FA), cela ajoute une couche de protection réelle à une instance domestique exposée. Un effet de bord utile : on distingue enfin sa propre erreur de mot de passe d’un bot qui « tente sa chance ».
Sécurité : les actions sensibles deviennent admin-only
La version 2026.9 poursuit un durcissement plus discret mais structurant. Installer une mise à jour, ignorer une mise à jour ou effacer une mise à jour ignorée exigent désormais un compte administrateur. Ce sont des actions de configuration, désormais traitées comme les autres actions sensibles de la plateforme.
Même logique côté Z-Wave : les actions de gestion des utilisateurs de serrures et des identifiants (set_user, delete_user, set_credential, delete_credential, etc.) requièrent désormais un compte administrateur. Pour un système qui pilote des serrures de porte, c’est une correction de bon sens : un script lancé par un utilisateur non privilégié ne peut plus modifier les accès physiques.
Les automatisations ne sont pas affectées — elles tournent sans contexte utilisateur — mais un script lancé par un non-admin qui tenterait ces actions échouera désormais. La parade est documentée : le déclencher via une automatisation ou le lancer en tant qu’administrateur.
Le reste : Matter, voix, accessibilité
Le reste de la livraison est dense. La nouvelle carte Matter donne une carte réseau du monde Matter pour visualiser la topologie des nœuds. Le tableau de bord Sécurité gagne des alertes actives et des favoris. Le panneau Sources, partagé entre Historique et Activité, regroupe l’origine des changements, et Activité explique enfin pourquoi une valeur a changé, pas seulement qu’elle a changé.
Côté Cloud, un nouveau moteur de synthèse vocale (fournisseur Soniox) cible spécifiquement les accents, le bruit de fond et les langues non anglaises — disponible via Labs, avec la même garantie d’absence de journalisation ou d’entraînement sur votre audio. Enfin, 13 nouvelles intégrations arrivent, les graphiques deviennent navigables au clavier et par le son, et la version 2026.9.1 a déjà corrigé les premiers correctifs le 5 septembre.
Sous le capot : les changements incompatibles
Comme à chaque version majeure, 2026.9 embarque des changements rétro-incompatibles à connaître avant de mettre à jour. Le plus visible concerne l’aspirateur robot : la propriété dépréciée battery_level a été retirée de l’entité de base. Toutes les intégrations cœur avaient déjà migré en 2026.8 ; une intégration custom qui définirait encore cette propriété ne rapportera plus de niveau de batterie — il faut désormais ajouter un capteur de batterie séparé.
Côté développement, l’intégration Configurator est dépréciée, et l’API WebSocket du registre de périphériques change, avec de nouvelles dépréciations et de nouveaux helpers de validation. Pour un utilisateur final, c’est transparent ; pour qui maintient une intégration custom, c’est un rappel que Home Assistant resserre régulièrement ses contrats d’API, et qu’une intégration non suivie finit par casser au fil des versions majeures.
Ces changements confirment la direction générale de la version : moins de surface implicite, plus de contrôles explicites. La propriété supprimée, l’action restreinte aux administrateurs et l’API dépréciée relèvent du même mouvement — rendre le comportement du système plus prévisible et plus sûr par défaut.
Un enjeu concret : l’autoconsommation énergétique
Derrière la modernisation de Modbus, il y a un cas d’usage qui monte en puissance : l’autoconsommation solaire. Les onduleurs, compteurs et batteries domestiques parlent très majoritairement Modbus, et les piloter dans Home Assistant devient l’étape naturelle pour qui veut optimiser sa consommation ou son injection sur le réseau.
Jusqu’à 2026.9, cette promesse se heurtait à la table de registres : chaque marque, voire chaque modèle, expose ses registres différemment, et la moindre erreur de mapping rendait l’intégration muette. En déléguant la connaissance du protocole aux intégrations qui la possèdent déjà, Home Assistant transforme l’onduleur ou le compteur en simple entité — mesurable, automatisable, scriptable comme n’importe quel capteur.
Le gain n’est pas cosmétique. Il abaisse le coût d’entrée de l’automatisation énergétique domestique à un niveau où l’utilisateur n’a plus besoin d’être électrotechnicien pour faire parler un compteur Modbus avec ses scénarios de charge, de délestage ou d’effacement.
Verdict
Home Assistant 2026.9 est deux versions en une. D’un côté, elle abaisse la barrière d’entrée pour tout un parc d’équipements industriels Modbus ; de l’autre, elle referme des trous dans la surface exposée — vraie IP, bannissement, actions sensibles réservées aux administrateurs.
Si vous pilotez des équipements Modbus (onduleur, compteur, pompe à chaleur), la mise à niveau est évidente : la configuration passe du YAML à l’interface, et l’intégration existante partage désormais proprement la liaison. Si votre instance est exposée ou passe par Home Assistant Cloud, activez le bannissement par IP et la 2FA — la vraie IP transmise rend enfin cette protection exploitable. Si vous gérez des serrures Z-Wave, la restriction des actions d’identifiants aux administrateurs est une raison à elle seule de basculer. Pour les autres, c’est une mise à jour sans urgence mais sans risque, qui ne cesse de renforcer le poste de sécurité.