Home Assistant 2026.11 modifie le nommage des appareils : que vérifier après la mise à jour

Ce que Home Assistant 2026.11 change réellement

Home Assistant 2026.11 modifie la présentation et l’organisation des appareils et des entités, mais ne réécrit pas entièrement les identifiants utilisés par les automatisations existantes. Cette distinction doit guider tout audit après la mise à jour. Dans un même foyer, les libellés affichés dans les tableaux de bord, les réglages et les pages d’appareils peuvent changer, tandis que les automatisations, scripts, scènes et tableaux de bord qui ciblent des identifiants d’entité existants continuent de faire référence aux mêmes entités. Il faut donc d’abord voir cette version comme une évolution de l’affichage et de l’organisation, puis comme une raison d’examiner les endroits où des noms lisibles sont utilisés directement.

La terminologie compte. Une zone décrit un emplacement dans le logement. Un appareil représente un produit connecté. Une entité correspond à une capacité ou à une donnée exposée par ce produit, par exemple une lumière, un interrupteur, une température ou un capteur de consommation. L’identifiant d’entité est l’identifiant utilisé dans la configuration, par les automatisations et dans les autres références de Home Assistant. Le nom de l’entité, le nom de l’appareil, le nom de la zone et l’ancienne présentation fondée sur friendly_name sont des libellés destinés à l’utilisateur. La nouvelle approche de Home Assistant s’appuie sur ces relations pour fournir davantage de contexte, au lieu d’obliger chaque élément à intégrer son emplacement et les informations sur l’appareil dans un nom unique et indifférencié. L’annonce officielle du nommage dans la version 2026.11 présente cette évolution comme une transition vers des noms façonnés par leur contexte.

C’est ce contexte que les utilisateurs remarqueront le plus probablement après la mise à jour. Un tableau de bord ou un écran de réglages peut afficher une entité avec son appareil ou sa zone, ce qui facilite la distinction entre des éléments similaires dans une installation importante. Dans une autre vue, le contexte ajouté peut sembler répétitif si la pièce ou l’appareil est déjà évident au vu de la disposition de la carte. Les deux situations peuvent être normales. Une chaîne d’affichage différente ne prouve pas, à elle seule, que l’entité a été renommée au niveau de la configuration ni qu’une automatisation a perdu sa cible. La documentation de Home Assistant établit clairement la limite : modifier le nom d’une entité ne modifie pas son identifiant d’entité, tandis que modifier cet identifiant est une opération distincte qui peut nécessiter la mise à jour des références dans les automatisations ou les scripts. La documentation sur la personnalisation des entités recommande également d’affecter les appareils à des zones afin que Home Assistant puisse exploiter cette structure dans les sélecteurs, les boîtes de dialogue et les tableaux.

La version facilite aussi la représentation des produits composés de plusieurs éléments sous forme de hiérarchie. Un produit compatible peut comporter un appareil parent et des appareils enfants associés. Une multiprise en est un bon exemple : la multiprise peut apparaître comme appareil parent, tandis que ses prises individuelles apparaissent comme des sous-appareils avec leurs propres entités, notamment des données de consommation par prise. Cette représentation correspond mieux à la structure physique, mais elle peut modifier l’apparence du registre des appareils après la mise à jour. Ce qui semble être un doublon peut en réalité être une partie d’un produit existant désormais visible. La documentation précise que c’est l’intégration qui détermine si un appareil possède des sous-appareils ; les utilisateurs ne peuvent pas créer ou modifier eux-mêmes cette relation. Le guide de Home Assistant sur les appareils parents explique comment le parent et ses sous-appareils sont affichés ensemble.

Cette nouvelle structure ne signifie pas que toutes les intégrations présenteront immédiatement leurs composants de la même manière. L’annonce de la version indique que la prise en charge des appareils enfants pour Matter et ZHA est encore en cours. Un logement utilisant l’une de ces intégrations peut donc disposer d’une vue parent-enfant moins complète qu’un logement dont l’intégration modélise déjà tous les éléments d’un produit composé de plusieurs parties. Cette différence doit d’abord être considérée comme une question de couverture de l’intégration, avant d’être interprétée comme le signe d’une migration échouée. Le modèle de nommage peut être visible dans l’interface générale alors qu’une intégration donnée continue de mettre en place les relations entre appareils qu’elle doit exposer.

La première vérification pratique est simple : comparez les libellés que vous voyez désormais avec les ID d’entité utilisés par quelques automatisations importantes, repérez les produits qui ont gagné des entrées enfants et identifiez les écrans où les noms sont devenus ambigus ou répétitifs. Testez ensuite le fonctionnement réel des appareils les plus importants. Home Assistant 2026.11 modifie le vocabulaire affiché en premier — notamment avec les noms contextuels et l’organisation en appareils enfants —, mais l’audit utile consiste à distinguer ces changements visibles des références d’entité et du comportement des intégrations, qui déterminent si la maison fonctionne toujours correctement.

La limite de compatibilité : ce qui devrait continuer à fonctionner

Home Assistant 2026.11 modifie davantage les noms visibles par les utilisateurs que les identifiants utilisés par le système en interne. Un ID d’entité tel que light.kitchen_ceiling reste la référence stable employée par les automatisations, les scripts, les scènes et la configuration des tableaux de bord. Le nom affiché de l’entité, le nom de l’appareil, le libellé de la zone ou celui d’une carte constituent une couche distincte, qui peut devenir plus contextuelle sans nécessiter la réécriture de toutes les références.

C’est la première vérification de compatibilité à effectuer après la mise à jour. Une automatisation qui cible un ID d’entité existant devrait continuer à atteindre cette entité, et un script ou une scène construit autour de ces ID ne devrait pas cesser soudainement de fonctionner parce que l’interface affiche un nom différent. Il en va de même pour les tableaux de bord dont les cartes ciblent explicitement ces entités. Si une carte affiche désormais « Plafond de la cuisine » au lieu du libellé dont vous vous souvenez, ce changement visuel ne suffit pas à prouver qu’elle a perdu sa cible. Vérifiez l’ID d’entité avant de modifier le YAML ou de recréer une automatisation.

Cette distinction est importante, car Home Assistant affiche désormais davantage de contexte dans les noms, là où les utilisateurs voyaient auparavant un libellé plus uniforme. Une entité peut être comprise par rapport à son appareil et à sa zone, tandis qu’un produit composé de plusieurs éléments peut être représenté par des appareils enfants. Une multiprise, par exemple, peut afficher des appareils enfants distincts ou des entrées correspondant à chacun de ses composants pour les prises, lorsque l’intégration prend en charge ce modèle. Ces entrées peuvent sembler dupliquées par rapport à une ancienne vue du registre des appareils, même si les entités sous-jacentes et leurs ID restent les références utilisées par les automatisations existantes. L’annonce officielle présente cette évolution comme une partie du travail sur les noms et l’organisation, et non comme une obligation de recréer chaque automatisation. (Home Assistant : le nommage dans Home Assistant, façonné par vos retours)

Cette assurance a toutefois une limite importante : la prise en charge des appareils enfants n’est pas uniforme d’une intégration à l’autre. L’annonce précise que la prise en charge de Matter et de ZHA est encore en cours ; des produits similaires comportant plusieurs composants peuvent donc apparaître différemment selon leur mode d’intégration. Un appareil peut être présenté avec une structure parent-enfant, tandis qu’un autre conservera une représentation plus plate. Cette incohérence invite à inspecter l’appareil concerné, pas à supposer que les ID d’entité ont été régénérés.

Le contrôle vocal bénéficie d’une marge de compatibilité distincte. Les anciens noms restent disponibles comme alias pour les intégrations vocales ; les foyers n’ont donc pas besoin de réapprendre immédiatement toutes leurs commandes parce que Home Assistant recommande désormais des noms plus contextuels. C’est utile pour les entités exposées à Assist, Alexa ou Google Assistant. Les alias ne remplacent toutefois pas la vérification de ce qui a réellement été exposé. Si le regroupement visible, l’affectation à une zone ou la structure de l’appareil change, un assistant vocal peut présenter l’entité différemment, même si la commande habituelle reste valide.

La fausse alerte la plus probable est une chaîne d’affichage modifiée. Une carte de tableau de bord, une page de réglages, un sélecteur vocal ou une liste d’appareils peut afficher un nom plus long, plus contextuel, ou fondé sur l’entité plutôt que sur l’appareil. Les utilisateurs peuvent y voir une référence cassée parce que le texte ne correspond plus à une ancienne capture d’écran ou à une notification. Considérez le texte et l’identifiant comme deux résultats de test distincts : « L’interface l’appelle-t-elle comme prévu ? » et « L’automatisation pointe-t-elle toujours vers l’entité voulue ? » sont des questions liées, mais ce ne sont pas les mêmes.

Les cartes personnalisées ajoutent une part d’incertitude. Les cartes qui utilisent explicitement un ID d’entité ciblent clairement le bon élément, tandis que celles — ou les modèles — qui déduisent leurs libellés de champs de nommage peuvent afficher autre chose après la mise à jour. Une carte personnalisée peut donc continuer à piloter la bonne lampe, le bon interrupteur ou le bon capteur, alors que son titre, son sous-titre ou son libellé généré automatiquement change. Si une carte semble incorrecte, examinez sa configuration pour déterminer si elle lit un nom explicite, un nom d’appareil ou une valeur de type friendly_name. Ne concluez pas à une défaillance de l’entité sur la seule base d’un changement de libellé visuel : vérifiez l’entité utilisée par la carte et testez la commande.

La même prudence s’impose pour les intégrations qui n’ont pas encore adopté uniformément le modèle des appareils enfants. Un écran peut afficher un appareil parent et ses composants, tandis qu’un autre continue de présenter des entités séparées, sans la même hiérarchie. Les recherches dans le registre peuvent alors retourner des entrées qui semblent redondantes, ou le libellé généré automatiquement pour un tableau de bord peut différer du nom affiché dans les paramètres de l’appareil. Comparez l’ID d’entité, la zone et l’état réel ou le comportement de la commande. S’ils correspondent au matériel visé, la différence est organisationnelle ou visuelle. Dans le cas contraire, ajoutez l’élément à la liste de vérifications de cette intégration.

Un test rapide après la mise à jour suffit pour distinguer la compatibilité de l’apparence. Choisissez une automatisation importante, une carte de tableau de bord et une commande vocale. Vérifiez que l’automatisation fait toujours référence à l’ID d’entité attendu, que la carte commande bien l’appareil voulu et que la commande prononcée atteint la bonne entité. Examinez ensuite tout appareil à plusieurs composants dont l’entrée du registre semble dupliquée, puis notez si son intégration prend en charge les appareils enfants.

La zone sûre reste donc la couche existante des ID d’entité, les anciens noms vocaux étant conservés comme alias. Le risque visible tient surtout à la confusion : chaînes renommées, entrées d’appareils réorganisées, libellés de cartes personnalisées dérivés d’autres champs et prise en charge inégale des appareils enfants peuvent tous donner l’impression d’une panne. En séparant ces catégories, la première inspection devient une vérification ciblée de compatibilité plutôt qu’une reconstruction précipitée.

Les quatre vérifications importantes après la mise à jour

Commencez par les éléments de l’installation où les noms servent de données plutôt que de simples éléments décoratifs. La première vérification concerne le tableau de bord, en particulier les cartes personnalisées. Home Assistant 2026.11 peut modifier le texte affiché par une carte tout en laissant intact l’ID d’entité qu’elle commande. Une carte personnalisée qui lit friendly_name peut donc afficher un libellé différent de celui d’une carte intégrée, ou changer à nouveau après le renommage de l’appareil ou de l’entité. Ouvrez les tableaux de bord les plus utilisés et comparez à la fois le libellé visible et la cible de l’action. Si une carte devient ambiguë, donnez-lui un nom explicite au lieu de renommer les entités uniquement pour améliorer une vue. La documentation de Home Assistant sur le nommage des cartes prend en charge le texte fixe ainsi que des composants distincts pour l’entité, l’appareil, la zone et l’étage.

C’est particulièrement important sur les tableaux de bord qui répètent des capteurs, des interrupteurs ou des lampes. Une carte peut rester parfaitement fonctionnelle alors que son libellé devient trop long, répète le nom de la pièce ou ne permet plus de distinguer deux appareils similaires. Vérifiez les cartes personnalisées qui utilisent des modèles ou des attributs propres à une intégration, puis corrigez la présentation au niveau de la carte lorsque c’est le seul problème. La documentation recommande également d’affecter les appareils à des zones et d’utiliser le nom de la carte pour ajuster ce qui est affiché, plutôt que d’intégrer chaque élément de contexte géographique dans le nom de l’entité. L’organisation sous-jacente reste ainsi exploitable dans les paramètres, les sélecteurs et les autres tableaux de bord, y compris dans la vue en cours de réparation. Les recommandations de Home Assistant sur la personnalisation des entités expliquent cette séparation.

La deuxième vérification concerne les textes générés : modèles, notifications, journaux et messages affichés aux membres du foyer. Recherchez les utilisations directes de friendly_name dans les modèles YAML et ceux créés depuis l’interface. Home Assistant conserve cet attribut pour assurer la compatibilité, mais l’annonce de la version 2026.11 indique qu’il est progressivement abandonné comme source de nommage privilégiée. Utilisez entity_name() lorsque le message désigne une fonction ou un point de données précis, device_name() lorsqu’il décrit le produit physique et area_name() lorsque le contexte pertinent est la pièce. La référence des fonctions de modèle définit ces fonctions et les objets auxquels elles permettent d’accéder.

Avant de modifier le template, identifiez d’abord ce que décrit la phrase. « La consommation électrique est élevée » relève du niveau de l’entité ; « la machine à café est hors ligne » concerne un appareil ; « il fait trop chaud dans la cuisine » concerne une zone. Rendez chaque template modifié avec une véritable entité, puis lisez le résultat comme quelqu’un du foyer l’entendrait ou le verrait. Un template peut s’exécuter correctement tout en produisant un nom de pièce répété ou une formulation qui ne permet plus de distinguer deux appareils similaires. Le bon test ne consiste donc pas seulement à vérifier que le code fonctionne, mais aussi que la notification obtenue reste claire lorsque Home Assistant ajoute des noms contextuels autour de l’objet.

Le troisième contrôle concerne l’utilisation vocale. Examinez les entités exposées à Assist, Alexa ou Google Assistant, puis testez les noms que les occupants emploient réellement. Les entités déjà exposées conservent leurs anciens noms comme alias ; une commande ne doit donc pas être considérée comme cassée simplement parce que le tableau de bord affiche désormais une autre étiquette contextuelle. Considérez toutefois cet alias comme une aide à la compatibilité et recherchez malgré tout les collisions : deux lampes portant le même nom parlé, un appareil parent et une prise enfant aux noms trop proches, ou une entité renommée qui est claire à l’écran mais peu naturelle à prononcer. La documentation de Home Assistant sur les alias vocaux présente les alias comme un moyen d’utiliser plusieurs noms pour une même entité.

Testez la commande prévue ainsi qu’une alternative proche. Demandez à l’assistant de contrôler l’appareil, puis vérifiez qu’une lampe, un interrupteur ou une prise au nom similaire n’a pas été sélectionné. Incluez les serrures, les alarmes, les commandes de garage et les équipements de chauffage ou de climatisation dans cette vérification manuelle : une réponse vocale réussie ne prouve pas que la bonne cible a été choisie. Vérifiez les alias des pièces et des appareils, en plus des noms d’entités, et assurez-vous que seules les entités qui doivent être accessibles à la voix sont exposées.

Le quatrième contrôle concerne le matériel composé de plusieurs éléments. Une multiprise compatible peut désormais apparaître comme un appareil parent avec des appareils enfants distincts pour chacune de ses prises. Comparez le parent à chaque enfant, repérez l’entité principale et vérifiez que chaque prise possède le bon nom et la bonne zone. Un enfant peut être nommé selon sa fonction réelle — par exemple « Bouilloire » ou « Lampe de bureau » — plutôt que conserver une étiquette technique comme « Prise 3 ». L’annonce de la version indique que la prise en charge des appareils enfants est disponible pour Z-Wave, MQTT, ESPHome, certains appareils Tuya et d’autres intégrations, tandis que la prise en charge de Matter et de ZHA est encore en cours. L’organisation peut donc varier jusqu’à ce que davantage d’intégrations adoptent ce modèle.

Pour auditer une petite pièce, imaginez un bureau à domicile où une seule multiprise alimente une lampe de bureau, un écran et un chargeur. Nommez l’appareil physique selon sa fonction, affectez-le à la zone du bureau et désignez comme entité principale celle qui représente le mieux la multiprise. Donnez à chaque prise un nom distinct fondé sur sa fonction, puis inspectez les appareils enfants ou les entités associées créés par l’intégration. Utilisez un nom explicite sur la carte si le nom par défaut répète maladroitement la pièce ou l’appareil. Dans une notification, utilisez device_name() pour désigner la multiprise entière, entity_name() pour une prise donnée et area_name() pour un message concernant le bureau. Enfin, n’exposez à la voix que les prises qui doivent l’être et vérifiez que l’allumage de la lampe ne commande pas l’écran.

Procédez pièce par pièce et laissez les identifiants d’entité inchangés, sauf raison distincte de les modifier. La migration est conçue pour préserver les configurations qui ciblent ces identifiants ; cet audit vise à faire correspondre les noms affichés, générés, prononcés et associés aux appareils enfants avec l’aménagement réel. Des captures d’écran ou des exports des tableaux de bord critiques peuvent faciliter un nettoyage progressif et permettre de revenir en arrière plus simplement, tandis qu’un périmètre réduit aide à retrouver l’origine d’une étiquette ou d’un résultat vocal déroutant.

Qui doit mettre à jour maintenant, et qui devrait préparer le changement

Pour une installation Home Assistant OS standard, avec des tableaux de bord ordinaires et des intégrations prises en charge, la mise à jour est raisonnable dès que vous avez le temps de vérifier le logement. Faites d’abord une sauvegarde, choisissez un créneau maîtrisé et contrôlez ensuite les pièces les plus importantes. Testez les éclairages, les commandes de chauffage ou de climatisation, les serrures, les alarmes et les tableaux de bord utilisés au quotidien. Si tout fonctionne comme prévu, il n’est pas nécessaire de renommer toute l’installation. Les propres recommandations de Home Assistant présentent le nettoyage des noms comme facultatif : les noms existants peuvent rester en place lorsqu’ils sont déjà suffisamment clairs.

Planifiez la mise à jour si les noms sont très présents dans votre interface. Les cartes personnalisées, tableaux de bord conçus manuellement, modèles YAML, notifications mobiles et routines vocales peuvent tous afficher les noms différemment de l’interface standard. Avant la mise à jour, sauvegardez votre installation et faites des captures d’écran ou exportez les tableaux de bord importants. Notez brièvement les commandes et notifications dont les occupants se servent régulièrement. Vous disposerez ainsi d’un point de comparaison après la mise à jour et pourrez distinguer un libellé modifié d’une entité défaillante. Un intitulé différent sur une carte ne prouve pas, à lui seul, qu’une automatisation ou un appareil ne fonctionne plus.

Les installations qui utilisent beaucoup de YAML méritent une vérification plus méthodique. Les modèles qui affichent des noms devraient progressivement utiliser les fonctions dédiées entity_name(), device_name() et area_name() lorsque cela s’y prête. Cela ne signifie pas qu’il faut réécrire toutes les automatisations qui fonctionnent. Laissez les références stables aux ID d’entité en place et examinez sélectivement la couche de présentation : notifications, affichages muraux, messages persistants et réponses destinées à la voix sont les endroits où une ancienne méthode de nommage risque le plus de se faire remarquer. La documentation établit également une distinction importante : modifier le nom d’une entité ne modifie pas son ID, tandis que modifier l’ID lui-même peut nécessiter la mise à jour des automatisations et des scripts. (Personnalisation des entités dans Home Assistant)

Le mélange d’intégrations doit déterminer le niveau de prudence à adopter. Home Assistant peut représenter certains produits composés de plusieurs éléments comme un appareil parent accompagné d’appareils enfants — par exemple une multiprise dont les prises apparaissent séparément — mais cette structure dépend de l’intégration. La prise en charge des appareils enfants par Matter et ZHA est encore en cours, si bien qu’un foyer qui dépend fortement de l’un ou de l’autre ne doit pas supposer que chaque composant apparaîtra de la même façon après la mise à jour. Les utilisateurs de Z-Wave, MQTT et ESPHome devraient eux aussi vérifier leurs appareils réels plutôt que de tirer des conclusions à partir d’une autre intégration. Vérifiez que chaque prise, capteur et commande reste associé à la pièce et au tableau de bord prévus. (Annonce sur le nommage)

Faites une vérification finale concrète. Testez une lumière depuis le tableau de bord et à la voix si le contrôle vocal est utilisé. Vérifiez un thermostat dans la vue de sa pièce ainsi que dans l’automatisation qui en dépend. Confirmez que les serrures et les alarmes sont affectées aux zones attendues et répondent correctement aux commandes manuelles. Pour un produit comportant plusieurs prises ou composants, testez chaque élément séparément au lieu de considérer qu’un appareil parent en bon état garantit le fonctionnement de tous ses enfants. Examinez également les entités exposées à Assist, Alexa ou Google Assistant. Les anciens noms restent disponibles comme alias vocaux, mais un nouveau nom d’affichage contextuel peut tout de même rendre une commande prononcée ambiguë.

La question est donc moins de savoir s’il faut entreprendre un nettoyage complet du nommage que de déterminer si vous avez le temps de vérifier l’installation. Les foyers ordinaires peuvent effectuer la mise à jour avec une sauvegarde et un contrôle pièce par pièce. Les installations personnalisées ou sensibles pour la sécurité devraient planifier le changement, conserver les références des tableaux de bord critiques et tester en priorité les appareils dont les occupants dépendent le plus. Si un libellé est maladroit, renommez-le délibérément ; si l’ID d’entité et l’automatisation fonctionnent toujours, préservez cette base stable.