Home Assistant 2026.7 est sorti le 1er juillet 2026 avec trois changements majeurs : les intent triggers (déclencheurs orientés usage) deviennent le comportement par défaut pour les nouvelles automatisations, la gestion Zigbee via ZHA est refondue en profondeur, et le serveur Matter change entièrement de moteur (matter.js, en TypeScript, remplace l'ancien serveur Python). Bonne nouvelle : vos automatisations YAML et vos appareils Matter déjà commissionnés continuent de fonctionner sans intervention. La mise à jour est sûre, à condition de comprendre ce qui a changé avant de toucher à quoi que ce soit — c'est l'objet de ce guide, avec les trois points que la couverture francophone déjà publiée sur cette version n'a pas détaillés.

Intent triggers : migrer ses automatisations sans tout recommencer

Les intent triggers remplacent la logique « entité + état + condition » par des déclencheurs qui décrivent directement une intention : « température sous 18°C », « batterie faible », « prix de l'électricité au plus bas aujourd'hui ». Plus de 200 triggers orientés usage sont disponibles nativement, et les intégrations peuvent désormais exposer leurs propres triggers au niveau du type, pas seulement de l'entité.

Concrètement, une automatisation existante écrite avant HA 2026.7 continue de fonctionner telle quelle : la compatibilité ascendante est garantie, YAML et templates Jinja compris. Rien ne casse au moment de la mise à jour. La différence se joue uniquement sur les nouvelles automatisations que vous créez : là où il fallait avant choisir une entité `sensor.temperature_salon`, une condition `below: 18`, et gérer manuellement les cas `unavailable` ou `unknown` (l'automatisation ne se déclenchait pas, ou pire, se déclenchait à tort sur une valeur nulle), le nouveau trigger orienté usage encapsule cette logique — plus besoin de savoir quel attribut regarder ni de gérer les états indéfinis à la main. C'est l'intégration elle-même qui décide de la bonne façon de traiter ces cas limites, une fois pour toutes.

Exemple concret de migration : une automatisation « chauffage d'appoint si température salon < 18°C » qui utilisait un trigger `numeric_state` sur `sensor.temperature_salon` avec `below: 18` peut être réécrite avec le nouveau trigger orienté zone/pièce, qui suit automatiquement tous les capteurs de température ajoutés ou retirés du salon — sans avoir à modifier l'automatisation à chaque changement de capteur. Avant 2026.7, remplacer un capteur de température par un modèle différent obligeait à retoucher l'automatisation pour pointer vers la nouvelle entité ; avec un trigger orienté zone, le nouveau capteur est suivi automatiquement dès qu'il est assigné à la même pièce.

Le même principe s'applique à la détection de présence : un trigger « présence dans le salon » suit tous les capteurs de mouvement ou de présence rattachés à cette zone, qu'il s'agisse d'un PIR classique ou d'un capteur mmWave ajouté plus tard, sans réécrire l'automatisation. C'est particulièrement utile pour les automatisations liées à un chargeur de véhicule électrique (déclencheur « charge terminée » exposé nativement par l'intégration) ou au suivi du prix de l'électricité (déclencheur « prix au plus bas du jour »), deux cas d'usage cités explicitement dans la release et qui s'appuient sur le même mécanisme de zones et labels.

Pour les automatisations avancées qui dépassent ce que les intent triggers couvrent nativement — logique conditionnelle imbriquée, calculs sur plusieurs capteurs, formatage de notifications — les templates Jinja restent indispensables. Les intent triggers simplifient les cas courants et réduisent la barrière d'entrée pour les nouveaux utilisateurs ; ils ne remplacent pas la logique conditionnelle complexe que maîtrisent déjà les utilisateurs avancés.

Refonte ZHA : ce qui change pour un réseau Zigbee volumineux

La gestion des appareils Zigbee via ZHA est significativement retravaillée dans HA 2026.7 : visibilité et maintenance améliorées pour les réseaux Zigbee comportant de nombreux appareils, sans changement de firmware ni de coordinateur requis de votre côté.

Pour un réseau Zigbee volumineux (50, 100 appareils ou plus), cette refonte cible directement les points de friction habituels : identifier un appareil qui répond mal dans une longue liste plate d'entités sans distinction visuelle, comprendre la topologie du réseau mesh pour savoir si un appareil sert de routeur à ses voisins, et gérer les groupes d'appareils sans dupliquer les automatisations à chaque ajout. Un réseau Zigbee qui grossit au fil des mois — quelques prises la première année, puis des capteurs de présence, des têtes thermostatiques, des interrupteurs muraux — finit par ressembler à une liste ingérable où retrouver un appareil précis prend plus de temps que de le configurer. C'est exactement ce type d'usage que la refonte cible.

Aucun concurrent français couvrant HA 2026.7 n'a détaillé cet aspect à ce jour — la plupart se contentent de mentionner « une refonte de la gestion Zigbee » sans expliquer ce qu'elle change dans l'usage quotidien. Si vous gérez déjà vos appareils Zigbee natifs via ESPHome et un device Zigbee ESP32-C6/H2, cette refonte améliore directement la lisibilité de votre intégration dans ZHA, sans reconfiguration de votre part.

Aucune action n'est requise après la mise à jour : les groupes, scènes et automatisations basées sur vos appareils Zigbee existants restent intacts. La refonte porte sur l'interface de gestion, pas sur le protocole ni sur l'appairage — vos clés réseau, votre canal Zigbee et votre coordinateur ne sont pas affectés.

matter.js : le nouveau serveur Matter et vos appareils déjà commissionnés

Home Assistant 2026.7 remplace le serveur Matter écrit en Python par une implémentation TypeScript nommée matter.js, donnée à l'Open Home Foundation par son créateur Ingo Fischer, qui a rejoint la fondation comme développeur principal Matter. Cette nouvelle implémentation est conforme Matter 1.5.1 et ajoute des capteurs de diagnostic dédiés à l'état de santé de chaque appareil Matter — de quoi voir immédiatement si un appareil décroche du réseau plutôt que de le découvrir seulement quand une automatisation ne se déclenche plus.

Question centrale pour quiconque a déjà commissionné des appareils Matter ou Thread avant cette mise à jour : faut-il tout refaire ? Non. La migration du serveur Python vers matter.js est entièrement automatique au moment de la mise à jour — aucune action manuelle requise, aucun recommissioning nécessaire. Vos appareils Matter restent appairés, vos automatisations qui les utilisent continuent de fonctionner. Ce point n'est clarifié explicitement par aucune des couvertures FR déjà publiées sur cette version, qui se contentent de mentionner le changement de serveur sans préciser son impact réel pour l'utilisateur final.

Ce qui change concrètement pour l'utilisateur : la reconnexion aux appareils Thread est plus rapide après une coupure réseau ou un redémarrage du hub, la révocation de certificats est mieux gérée (utile si vous retirez définitivement un appareil du réseau), et une carte réseau Thread visuelle apparaît directement dans l'interface HA — utile pour diagnostiquer un appareil qui perd sa connexion de façon récurrente ou repérer une zone morte du mesh Thread avant qu'elle ne cause des automatisations manquées. Si vous avez suivi notre guide sur le commissioning Matter via Bluetooth proxy ESPHome, aucune étape de cet article n'est à refaire après la mise à jour. Pour approfondir la coexistence Matter/Thread au-delà de cette release, notre guide Matter et Thread sur Home Assistant reste à jour.

Activity, Update All et panneaux IR/RF : le reste des nouveautés

Trois changements secondaires complètent cette version. Le « Journal de bord » est renommé Activity et redessiné en timeline visuelle avec icônes et couleurs par cause d'activation — plus lisible sur mobile grâce à un affichage condensé qui garde l'essentiel visible sans scroller, alors que l'ancien Journal de bord affichait toutes les colonnes indistinctement sur petit écran. Le bouton « Tout mettre à jour » regroupe désormais les mises à jour par catégorie (core HA, intégrations, applications), en un clic par groupe plutôt qu'un par un — un vrai gain de temps sur une instance avec 20 intégrations HACS actives. Enfin, deux panneaux dédiés apparaissent dans Paramètres pour les appareils infrarouge et radiofréquence — pratique si vous avez suivi notre article sur la télécommande IR physique comme déclencheur d'automatisation, ces appareils sont désormais centralisés dans leur propre section plutôt que noyés dans la liste générale des entités.

Dix nouvelles intégrations rejoignent HA 2026.7, dont Dropbox (sauvegardes HA directement sur votre compte, sans identifiants d'application à configurer), Chef iQ (sondes de cuisson Bluetooth sans hub) et MELCloud Home (climatisation et pompes à chaleur Mitsubishi Electric). Le moteur de rendu des templates gagne environ 40% en performance sur certains scénarios — un gain qui profite directement aux installations avec beaucoup d'automatisations basées sur des templates Jinja complexes ou des tableaux de bord riches en capteurs calculés.

Faut-il mettre à jour maintenant ?

Oui, avec une précaution de base : faites une sauvegarde complète avant toute mise à jour majeure de Home Assistant, comme pour chaque version. La compatibilité ascendante est garantie pour les automatisations YAML, les templates et les appareils Zigbee/Matter existants — rien ne casse mécaniquement. Le seul point de vigilance concerne les intégrations tierces HACS qui interagissent directement avec l'ancien serveur Matter Python : si vous en utilisez une, vérifiez sa compatibilité matter.js avant de mettre à jour un système en production. Pour la grande majorité des installations, cette version s'installe sans friction et apporte un vrai gain d'ergonomie sur les automatisations et la gestion Zigbee — sans nécessiter de reconfigurer quoi que ce soit.

Avant de lancer la mise à jour, trois vérifications suffisent : une sauvegarde récente disponible (locale ou Dropbox depuis cette version), la liste de vos intégrations HACS liées à Matter ou au Zigbee à jour dans leur dernière release, et un créneau calme pour redémarrer si votre installation pilote des automatisations critiques (chauffage, sécurité). Aucune de ces précautions n'est spécifique à 2026.7 — ce sont les mêmes réflexes que pour toute montée de version majeure de Home Assistant.

Si votre installation tourne sur du matériel qui commence à montrer ses limites face à des automatisations plus nombreuses et un rendu de templates plus intensif, c'est aussi le bon moment pour comparer les options : notre guide mini PC N100/N150 vs Raspberry Pi 5 pour Home Assistant détaille les configurations qui encaissent sans broncher une instance chargée.

Questions fréquentes sur Home Assistant 2026.7

Faut-il mettre à jour vers Home Assistant 2026.7 tout de suite ?

Oui, la mise à jour est sûre pour la grande majorité des installations : compatibilité ascendante garantie pour YAML, templates et appareils Zigbee/Matter existants. Faites une sauvegarde avant, comme pour toute mise à jour majeure, et vérifiez la compatibilité matter.js si vous utilisez une intégration HACS tierce liée à Matter.

Mes automatisations YAML vont-elles encore fonctionner après la mise à jour ?

Oui, sans modification. Les intent triggers ne remplacent pas vos automatisations existantes, ils ajoutent une nouvelle façon d'en créer de nouvelles. Vos automatisations YAML et vos templates Jinja actuels continuent de s'exécuter exactement comme avant la mise à jour.

Qu'est-ce que matter.js et pourquoi Home Assistant l'utilise maintenant ?

matter.js est une implémentation TypeScript du serveur Matter, qui remplace l'ancien serveur écrit en Python. Elle apporte la conformité Matter 1.5.1, une reconnexion Thread plus rapide et des capteurs de diagnostic par appareil. La migration est automatique, sans recommissioning nécessaire.

Dois-je reconfigurer mes appareils Zigbee après la mise à jour ZHA ?

Non. La refonte ZHA de 2026.7 porte sur l'interface de gestion (visibilité, maintenance des réseaux volumineux) et non sur le protocole d'appairage. Vos groupes, scènes et automatisations basées sur vos appareils Zigbee existants restent intacts sans aucune action de votre part.

Home Assistant 2026.7 fonctionne-t-il sur HAOS, Container et Core de la même façon ?

Oui, les changements de cette version (intent triggers, ZHA, matter.js) sont au niveau du Core et s'appliquent identiquement quelle que soit votre forme d'installation. Seule la fonctionnalité Dropbox pour les sauvegardes suppose un compte Home Assistant Cloud pour la liaison, sans surcoût d'abonnement supplémentaire.