Home Assistant 2026.10 place les alertes de sécurité sur le tableau de bord principal : construire un système de réponse réellement utilisable

Home Assistant 2026.10 apporte une petite modification d’interface, mais ses conséquences pratiques peuvent être importantes : les alertes configurées dans le tableau de bord Security peuvent désormais apparaître sur le tableau de bord Home principal. C’est utile parce qu’un avertissement n’a de valeur que si la personne qui le voit sait quoi faire ensuite. Une porte restée ouverte, un événement provenant d’un détecteur de fumée, une fuite d’eau ou un capteur hors service ne devrait pas disparaître dans une vue spécialisée que personne ne consulte.

Cette version ne transforme pas Home Assistant en système d’alarme certifié. Elle ne rend pas non plus fiables des capteurs défaillants, des téléphones silencieux ou une mauvaise conception réseau. Elle offre simplement aux alertes du foyer un emplacement plus visible. La bonne réponse n’est donc pas d’afficher chaque appareil en première page, mais de décider quelles conditions justifient une interruption, lesquelles relèvent d’une liste de maintenance discrète et lesquelles nécessitent un dispositif physique indépendant du contrôleur domotique.

C’est l’angle réellement intéressant de la version 2026.10 : considérer le tableau de bord comme le début d’un plan d’intervention, et non comme un mur de tuiles d’état.

Ce qui change dans la version 2026.10

Les notes de version publiées le 7 octobre par Home Assistant indiquent que les alertes configurées pour le tableau de bord Security, par exemple une porte laissée ouverte ou le déclenchement d’un détecteur de fumée, peuvent maintenant apparaître sur le tableau de bord Home. La modification réduit un décalage courant entre la configuration et l’usage quotidien. Une personne peut avoir construit une page de sécurité très soignée, alors que le foyer ouvre généralement la vue Home par défaut.

La nuance est importante. Cette nouvelle présentation ne transforme pas chaque capteur binaire en alerte. Elle fait remonter les alertes que vous avez déjà configurées. La condition sous-jacente, la qualité du capteur, le moyen de notification et la logique d’automatisation déterminent toujours si l’avertissement est exact et utile.

La version inclut aussi d’autres changements sans rapport direct, notamment des informations séparées sur la décharge des batteries dans le tableau de bord Energy et des contrôles supplémentaires pour les tableaux de bord. Ces évolutions peuvent être utiles, mais il ne faut pas les confondre avec la modification des alertes de sécurité. Une alerte visible ne prouve ni que l’appareil est en bon état, ni que la notification a été remise, ni que quelqu’un l’a reconnue.

Pour une première vérification, ouvrez le tableau de bord Home après la mise à niveau et cherchez les alertes actives. Si l’une d’elles apparaît, posez-vous quatre questions :

• Quelle condition exacte l’a déclenchée ?
• Qui doit intervenir ?
• Quelle est l’action immédiate la plus sûre ?
• Comment le foyer saura-t-il que le problème est résolu ?

Si l’une de ces réponses reste floue, l’alerte doit être repensée avant d’ajouter d’autres appareils.

Une alerte est un état, pas une simple notification

L’intégration Alert de Home Assistant est conçue pour les conditions qui restent importantes jusqu’à leur correction ou leur reconnaissance. Ses états documentés distinguent une alerte inactive, une alerte active et une condition active qui a été reconnue. Elle peut répéter les notifications selon des intervalles configurés et envoyer un message de fin lorsque la condition disparaît.

Ce modèle convient mieux à une porte de garage qui reste ouverte qu’à un bref événement de mouvement. Un détecteur de mouvement peut produire un événement utile pour un journal ou une automatisation, mais il ne devrait généralement pas se comporter comme un problème de sécurité persistant. Confondre les événements et les états est l’un des moyens les plus rapides de provoquer une fatigue des notifications.

Une règle simple aide à trancher :

Utilisez une alerte pour une condition qui oblige une personne à prendre une décision ou à rétablir un état sûr. Utilisez une notification pour un événement informatif, urgent dans le temps ou déjà traité par une autre automatisation.

Parmi les conditions qui justifient souvent une alerte persistante, on peut citer un capteur de fuite signalant la présence d’eau, un congélateur restant assez longtemps au-dessus d’une température choisie pour que cela devienne préoccupant, une porte de garage ouverte pendant la nuit, un défaut critique de détecteur de fumée ou une porte de sécurité ouverte alors que la maison est indiquée comme vide.

À l’inverse, une lumière qui s’allume, l’arrivée d’une personne au domicile, un mouvement dans un couloir très fréquenté ou une batterie qui renvoie brièvement une valeur invraisemblable demandent généralement un autre traitement. Ces événements peuvent tout de même alimenter des automatisations, des journaux ou une vue de maintenance moins prioritaire.

Cette distinction protège aussi contre un échec particulièrement gênant : si tout est urgent, le foyer finit par apprendre que la bannière rouge signifie probablement « rien de grave ». Une alerte silencieuse et répétée doit être réservée aux conditions dont le coût augmente tant qu’elles ne sont pas résolues.

Commencer par un inventaire réduit des alertes

Avant de modifier le YAML ou d’acheter de nouveaux capteurs, recensez les conditions du foyer susceptibles de provoquer un dommage réel, une perte matérielle ou un problème sensible au temps. Gardez un inventaire concret et physique. « Sécurité » est trop vague ; « porte arrière ouverte alors que personne n’est à la maison » peut déclencher une action.

Un inventaire pratique peut inclure :

La dernière ligne est souvent oubliée. Un système qui ne peut vous informer d’une fuite que si le concentrateur, le coordinateur radio, le réseau, l’alimentation et le chemin de notification fonctionnent tous est utile, mais ce n’est pas une couche de sécurité complète. Les recommandations de sécurité de Home Assistant conseillent de protéger l’installation, notamment lorsqu’elle est accessible depuis l’extérieur du réseau domestique. C’est une question distincte de la commodité du tableau de bord.

Ne reliez pas une alerte domotique à une action physique dangereuse simplement parce que le logiciel peut la commander. Fermer une vanne, déverrouiller une porte, allumer ou éteindre un chauffage ou désactiver un équipement peut avoir des conséquences qu’un capteur ne comprend pas entièrement. Commencez par la notification et la vérification humaine. N’ajoutez un contrôle automatique que si l’appareil est prévu pour cet usage et si ses modes de défaillance sont compris.

Faire du tableau de bord principal une surface de triage

Le tableau de bord Home principal devrait répondre à la question : « Qu’est-ce qui demande mon attention maintenant ? » Il ne devrait pas reproduire toutes les entités de la maison.

Une disposition sobre peut comporter trois zones :

1. Les alertes actives liées à la sécurité et au foyer.
2. L’état actuel nécessaire pour prendre rapidement une décision.
3. Un lien vers les diagnostics détaillés et l’historique.

La première zone peut afficher une porte extérieure ouverte, la présence d’eau, l’état d’un détecteur de fumée ou un congélateur resté chaud au-delà d’un délai. La deuxième peut indiquer si le domicile est occupé, si le concentrateur est en ligne et quand un capteur critique a été mis à jour pour la dernière fois. La troisième peut mener au tableau de bord Security, aux pages des appareils, aux journaux et aux traces des automatisations.

Cette organisation réduit la tentation d’ajouter une tuile pour chaque batterie, capteur de contact et avertissement d’intégration. Ces informations comptent, mais elles relèvent du travail de maintenance. Le tableau de bord principal est une surface de décision, pas un export d’inventaire.

Le nouveau comportement de 2026.10 rend cette distinction plus visible : une alerte active du tableau de bord Security peut désormais apparaître là où les habitants regardent déjà. C’est pratique lorsque la liste est soigneusement sélectionnée. C’est distrayant lorsqu’elle sert de déversoir à toutes les batteries faibles et à chaque panne de connexion temporaire.

Employez des noms qui décrivent la condition dans le langage du foyer. « Porte arrière ouverte en mode Absent » vaut mieux que « binary_sensor.contact_07 ». Ajoutez le lieu et, lorsque c’est pertinent, la durée. Personne ne devrait devoir se souvenir du capteur associé à chaque pièce au moment de décider s’il faut réveiller un autre membre du foyer.

Les délais font partie de la conception de sécurité

De nombreuses conditions domestiques nécessitent un délai avant de devenir une alerte. La porte d’un congélateur peut être ouverte pendant le rangement des courses. La porte du garage peut rester ouverte pendant une séance de bricolage. Un capteur de mouvement peut être actif parce qu’un animal traverse une pièce. Des avertissements immédiats pour toutes ces situations produiraient surtout du bruit.

Le délai doit correspondre à la conséquence, et non à une préférence générale. Un capteur d’eau conçu pour détecter une fuite peut justifier une notification immédiate. Une porte de garage peut accepter une courte période de grâce. Une alerte de température du congélateur peut exiger que la température reste élevée assez longtemps pour distinguer une ouverture de porte d’une panne de l’appareil.

L’intégration Alert de Home Assistant prend en charge des intervalles de répétition et peut utiliser une séquence de délais plutôt qu’un intervalle constant. Sa documentation décrit aussi un état de reconnaissance : une personne peut interrompre le rappel répété alors que la condition est toujours présente. Cette fonction est utile, mais la reconnaissance ne doit pas être considérée comme une résolution. Reconnaître « garage ouvert » signifie que quelqu’un l’a vu ; cela ne signifie pas que le garage est sécurisé.

Une cadence cohérente pourrait ressembler à ceci :

• Premier message immédiat pour une fuite probable ou un événement mettant des vies en danger.
• Court délai pour une porte ou un garage lorsqu’une activité normale est plausible.
• Rappels répétés tant que la condition reste active.
• Message clair de résolution lorsque le capteur revient à la normale.
• Revue de maintenance si l’alerte est reconnue à plusieurs reprises sans correction de la condition.

N’utilisez pas un délai long pour dissimuler un capteur peu fiable. Si le capteur oscille, se déconnecte ou renvoie des valeurs impossibles, corrigez ce problème séparément. Un mauvais signal retardé reste un mauvais signal.

Les notifications ont besoin d’un plan de livraison

Une alerte sur le tableau de bord n’aide que si quelqu’un ouvre le tableau de bord. Une condition sensible au temps nécessite généralement aussi un moyen de notification. Home Assistant prend en charge des intégrations de notification, et la documentation de son application compagnon décrit des notifications actionnables avec des boutons qui renvoient un événement à Home Assistant.

Il devient alors possible de concevoir le message autour d’une réponse plutôt qu’autour d’une alarme vague. Une notification de garage peut, par exemple, proposer « Ouvrir le tableau de bord » et « Marquer comme vu », tandis qu’une alerte de porte peut ouvrir la vue de la caméra correspondante. Une action ne devrait pas exécuter silencieusement une opération risquée au seul motif qu’elle est pratique. Un bouton qui déverrouille une porte ou désactive une alarme mérite une authentification et un traitement attentif.

La chaîne de livraison comporte plusieurs points de défaillance indépendants :

• Le capteur peut être hors ligne ou avoir une batterie épuisée.
• Le concentrateur peut être indisponible.
• Le réseau domestique peut être en panne.
• Les notifications du téléphone peuvent être désactivées ou bloquées par un mode de concentration.
• Le fournisseur de notification peut prendre du retard.
• Le membre du foyer qui reçoit le message n’est peut-être pas la personne responsable à ce moment-là.
• Le message peut être trop ambigu pour permettre une action.

Testez volontairement toute la chaîne. Déclenchez une condition de test sans danger, vérifiez le tableau de bord, confirmez la réception sur le téléphone, contrôlez qu’une action fonctionne, puis rétablissez l’état de test. Faites-le sur chaque téléphone censé recevoir une notification critique. Une notification configurée il y a plusieurs mois ne prouve pas qu’elle fonctionne encore aujourd’hui.

Dans la mesure du possible, utilisez une cible notify nommée. La documentation des notifications de Home Assistant avertit que la cible générique notify.notify est un raccourci vers la première action de notification trouvée, ce qui peut rendre la livraison moins lisible quand la configuration grandit. Des cibles explicites facilitent l’audit de l’automatisation et réduisent les surprises après l’ajout d’appareils ou d’intégrations.

Pour les alertes critiques, évitez de compter sur le téléphone d’une seule personne. Décidez si la bonne solution est un deuxième appareil du foyer, un service de notification partagé, une sirène locale ou une vérification manuelle. Le choix dépend de la condition et du foyer. Une notification téléphonique ne remplace pas un détecteur certifié de fumée ou de monoxyde de carbone.

Les notifications actionnables exigent des garde-fous

Les boutons sont puissants parce qu’ils raccourcissent le chemin entre la découverte d’un problème et la réponse. Ils peuvent aussi provoquer des actions accidentelles.

La documentation de l’application compagnon de Home Assistant précise que les actions de notification sont transmises sous forme d’événements et que les automatisations peuvent s’exécuter plusieurs fois. Elle recommande de concevoir soigneusement les identifiants d’action afin qu’une notification ne déclenche pas accidentellement une logique destinée à une autre. Elle demande également de réfléchir à ce qui se passe lorsqu’une notification est effacée ou lorsque l’application est indisponible.

Conséquence pratique : « reconnaître » et « corriger » doivent être deux actions différentes. Reconnaître signifie « quelqu’un a vu ceci ». Corriger signifie « la condition physique a été rétablie ». Si l’alerte est réduite au silence par un bouton, conservez l’état sous-jacent visible sur le tableau de bord et gardez un accès à l’historique de l’appareil.

Pour une alerte liée au contrôle des accès, ajoutez davantage de friction. Une notification qui ouvre une caméra présente généralement moins de risques qu’une notification qui déverrouille une entrée. Si une action peut modifier les personnes autorisées à entrer dans le domicile, une authentification, une courte durée de validité et une confirmation visible sont des protections raisonnables. Ne faites jamais d’une notification téléphonique la seule protection contre un état physique dangereux.

Utilisez des identifiants d’action uniques lorsqu’une automatisation peut envoyer plusieurs notifications apparentées. Gardez le gestionnaire d’action étroit : vérifiez le contexte attendu, contrôlez que la condition existe encore et refusez l’opération si le capteur concerné est devenu indisponible. Une notification ancienne ne doit pas se transformer plusieurs minutes plus tard en commande dont le sens aurait changé.

Prévoir l’indisponibilité des capteurs

Un tableau de bord domotique peut donner une impression de santé tout en cachant des angles morts. Chaque alerte critique devrait conduire à une question correspondante : que se passe-t-il lorsque le capteur cesse de transmettre ?

La réponse n’a pas besoin d’être une nouvelle alarme pour chaque appareil. Elle doit toutefois comporter un signal de maintenance. Un capteur de porte qui n’a pas communiqué depuis plusieurs jours ne devrait pas sembler équivalent à une porte fermée. Un capteur d’eau dont la batterie est morte ne doit pas être interprété comme une preuve que le sol est sec. Une intégration de détecteur de fumée qui perd sa connexion doit être affichée comme indisponible, et non silencieusement considérée comme normale.

C’est ici que le tableau de bord principal et la vue de maintenance se complètent. Placez le danger actif sur le tableau de bord principal. Placez les données anciennes et les batteries faibles dans une section de santé clairement identifiée, assez visible pour ne pas être oubliée. Dans un petit logement, une revue hebdomadaire peut suffire. Dans une installation importante, regroupez les appareils par conséquence et définissez un processus de réparation.

Évitez de masquer les entités indisponibles avec des modèles qui convertissent les valeurs inconnues en « off ». Une automatisation peut alors sembler propre, mais la différence entre sûr, faux et inconnu disparaît. Dans une alerte qui protège des biens ou des personnes, l’inconnu doit rester visiblement différent de la normale.

La conception radio et réseau compte également. Un capteur Thread, Zigbee, Wi-Fi ou Z-Wave peut échouer à cause de la distance, des interférences, du comportement de la batterie, d’un problème de coordinateur ou d’une modification du routeur. Ajouter une deuxième tuile au tableau de bord n’améliore pas la liaison. Testez les capteurs critiques depuis leur emplacement réel, et pas seulement sur un établi à côté du concentrateur.

Garder les appareils de sécurité des personnes indépendants

Home Assistant peut s’intégrer à des détecteurs de fumée et à d’autres équipements de sécurité, mais le contrôleur doit rester une couche d’information supplémentaire, pas l’unique ligne de défense. Utilisez des alarmes approuvées et entretenues, adaptées à la réglementation locale et au bâtiment. Suivez les recommandations du fabricant concernant l’emplacement, les tests, les piles et le remplacement.

Une automatisation domotique peut indiquer quelle pièce a signalé un événement, répéter un message sur les téléphones ou allumer un éclairage pour aider à trouver une sortie. Elle ne doit inciter personne à retarder une évacuation pour résoudre un problème d’application. Si une alarme certifiée retentit, suivez d’abord la procédure d’urgence.

Le même principe s’applique aux équipements électriques et de chauffage. Ne transformez pas une alerte de tableau de bord en chantier sur le câblage secteur. L’installation, la modification ou le contournement des protections d’un équipement électrique fixe doivent être confiés à un professionnel qualifié. Une prise connectée ne convient pas automatiquement à un radiateur, une chaudière, un appareil ou un moteur fortement chargé simplement parce qu’une puissance figure sur son étiquette. Le type de charge, le cycle de fonctionnement, le boîtier, les règles locales et le mode de défaillance ont tous leur importance.

La domotique excelle à fournir du contexte. Elle ne remplace ni un détecteur de fumée, ni un détecteur de monoxyde de carbone, ni une vanne d’arrêt correctement installée, ni un interverrouillage mécanique de sécurité, ni une personne qui connaît le plan d’urgence du foyer.

Une séquence de configuration pratique pour 2026.10

Si vous utilisez déjà Home Assistant, transformez cette évolution en court projet de maintenance.

Commencez par mettre à jour l’installation avec votre procédure habituelle prise en charge, puis lisez les notes de version 2026.10 afin d’identifier les changements incompatibles susceptibles de la concerner. Ne combinez pas une refonte des alertes de sécurité avec plusieurs migrations sans rapport si vous ne pouvez pas tester chaque modification.

Ouvrez ensuite le tableau de bord Security et notez les alertes réellement actionnables. Supprimez ou repensez celles qui n’ont ni responsable clair, ni réponse utile, ni source fiable. Ouvrez alors le tableau de bord Home principal et vérifiez la manière dont les alertes actives y apparaissent. Donnez à chacune un nom compréhensible et vérifiez son emplacement.

Pour chaque condition critique, testez le véritable capteur à son emplacement installé. Confirmez que l’alerte démarre, apparaît sur le tableau de bord principal, envoie la notification attendue, se répète selon la cadence prévue et disparaît après le rétablissement de la condition physique. Si vous utilisez la reconnaissance, vérifiez qu’elle n’efface pas l’état sous-jacent.

Testez ensuite le chemin de panne. Déconnectez temporairement un capteur ou simulez son indisponibilité uniquement si le test est sûr et réversible. Vérifiez que le tableau de bord distingue l’indisponibilité de la normale. Assurez-vous que le foyer dispose toujours d’un mécanisme de sécurité indépendant pour le feu, le monoxyde de carbone et les autres risques vitaux.

Enfin, documentez la responsabilité. Une note telle que « la personne qui reçoit cette notification vérifie la porte arrière » vaut mieux qu’une supposition. Si plusieurs personnes partagent le domicile, mettez-vous d’accord sur le sens de « vu », « reconnu » et « résolu ». Si personne ne peut répondre à une alerte, modifiez la conception au lieu d’envoyer davantage de messages.

Un exemple compact suffit à illustrer le principe :

alert:
  garage_open:
    name: "Garage door is still open"
    entity_id: binary_sensor.garage_door
    state: "on"
    repeat:
      - 15
      - 30
      - 60
    can_acknowledge: true
    skip_first: true
    notifiers:
      - household_phone

L’entité, le notificateur, les délais et la condition exacts doivent correspondre à l’installation. Ne collez pas cet exemple tel quel dans un système actif. Les choix importants sont la persistance de la condition, le retard du premier rappel pour laisser place à une activité normale, l’espacement croissant des répétitions et l’utilisation d’une cible de notification explicite.

Ce qu’il faut examiner après une semaine

Un système d’alertes doit être évalué à partir de son comportement, pas de l’apparence ordonnée de sa configuration. Après quelques jours, examinez les alertes déclenchées, la fréquence des répétitions, les réactions du foyer et les alertes reconnues sans correction.

Trois résultats sont particulièrement instructifs :

• L’alerte était rare, exacte et a conduit à une réponse claire.
• L’alerte était techniquement correcte, mais mal synchronisée ou trop vague.
• L’alerte était bruyante, doublonnait un autre avertissement ou dépendait d’un capteur que personne n’entretient.

Conservez le premier cas, affinez le deuxième et supprimez ou repensez le troisième. Un petit ensemble d’alertes fiables vaut mieux qu’une couverture complète qui apprend à tout le monde à ignorer le tableau de bord.

Vérifiez aussi si la nouvelle visibilité sur le tableau de bord principal modifie réellement les habitudes. Le foyer voit-il l’avertissement ? Apparaît-il sur une tablette murale souvent en veille ? Les téléphones sont-ils davantage utilisés que le tableau de bord ? Une notification apporte-t-elle assez de contexte pour décider ? Si la réponse est non, la modification d’interface a révélé un problème de procédure qu’un nouveau capteur ne résoudra pas.

Home Assistant 2026.10 donne aux alertes de sécurité actives une meilleure chance d’être remarquées. L’amélioration durable vient du fait d’associer chaque alerte à une condition réelle, à un responsable réel, à un chemin de livraison testé et à un secours indépendant lorsque les enjeux sont élevés. C’est ainsi qu’un tableau de bord devient utile pendant une journée ordinaire et chargée, au lieu de devenir un écran de plus rempli d’avertissements.

Sources et lectures complémentaires

• Notes de version de Home Assistant 2026.10 — changements de la version d’octobre, notamment l’apparition des alertes actives du tableau de bord Security sur le tableau de bord Home.
• Intégration Alert de Home Assistant — états d’alerte persistants, reconnaissance, intervalles de répétition et messages de fin.
• Notifications actionnables de Home Assistant — boutons, gestion des événements, identifiants d’action et considérations propres aux plateformes.
• Déclencheurs des automatisations Home Assistant — différence entre un événement déclencheur et des conditions qui restent vraies.
• Action de notification de Home Assistant — cibles de notification explicites et comportement de l’action notify générique.
• Sécuriser votre installation Home Assistant — recommandations concernant les comptes et l’accès à distance.
• Discussion communautaire Home Assistant 2026.10 — réactions de la communauté et discussion sur la mise en œuvre de la version.