La première chose qui m’a induit en erreur, c’est que Home Assistant fonctionnait.
J’avais installé un second petit routeur dans mon bureau. L’idée semblait propre : l’ordinateur et quelques appareils de cette pièce passeraient par son VPN, tandis que la box principale continuerait à gérer le reste de la maison.
Depuis mon portable connecté à ce deuxième Wi-Fi, j’ouvrais Home Assistant sans problème. Tableau de bord. Lumières. Température.
Historique. Tout était là. Puis j’ai ajouté un nouvel appareil réseau dans le bureau. Rien.
J’ai attendu la notification « Nouvel appareil découvert ». Toujours rien.
J’ai redémarré l’appareil, puis Home Assistant. J’ai vérifié le Wi-Fi. J’ai même ouvert directement l’adresse IP de l’équipement depuis mon ordinateur : elle répondait.
C’est précisément ce qui rendait le problème incompréhensible.
Si mon ordinateur pouvait atteindre Home Assistant et l’appareil, pourquoi Home Assistant ne les voyait-il pas comme faisant partie du même réseau ?
Résumé de l’article et adéquation du produit
Pourquoi Home Assistant reste-t-il accessible alors que certains appareils deviennent invisibles derrière un tunnel routé ?
Parce qu’une requête unicast vers l’adresse connue de Home Assistant peut être routée correctement, tandis que la découverte locale par mDNS/Zeroconf ou SSDP repose sur des mécanismes qui ne traversent pas automatiquement les frontières de sous-réseau ou un tunnel de couche 3.
Points clés, contexte et limites
- À retenir : Ouvrir le tableau de bord prouve qu’une route vers Home Assistant existe ; voir apparaître les appareils prouve que les mécanismes de découverte et les communications locales nécessaires existent encore au bon endroit.
- Pour qui : Les utilisateurs qui ont ajouté un second routeur ou un tunnel WireGuard et constatent que Home Assistant répond mais ne découvre plus certains objets connectés.
- Pourquoi OnlydogVPN correspond ici : Dans ce récit, seuls l’ordinateur et parfois le téléphone avaient besoin d’un VPN ; déplacer le tunnel sur l’ordinateur a permis de laisser Home Assistant et les objets connectés sur le même réseau local.
- Limite importante : Une application VPN commerciale sur un poste ne remplace pas une architecture site-à-site lorsque l’objectif est de relier deux logements, de transporter la découverte entre sous-réseaux ou de faire fonctionner deux réseaux comme un seul LAN.
Sources déjà citées dans l’article : Home Assistant sur Zeroconf · Home Assistant sur SSDP · RFC 6762 sur mDNS · WireGuard
Contexte produit : OnlydogVPN. La pertinence décrite ici reste limitée au scénario et aux contraintes exposés dans cet article.
J’avais pris une route qui fonctionne pour un réseau qui existe
Le piège est particulièrement facile à rencontrer avec Home Assistant.
Le projet annonçait déjà deux millions d’installations actives en 2025. La même année, il ajoutait directement dans Paramètres → Système → Réseaudes outils permettant de voir ce que Home Assistant détecte réellement via DHCP, mDNS/Zeroconf et SSDP/UPnP.
Je suis donc allé regarder là où j’aurais probablement dû commencer. Dans le navigateur Zeroconf, le nouvel appareil n’apparaissait pas. Et cette absence était beaucoup plus instructive que le tableau de bord parfaitement accessible.
Home Assistant utilise Zeroconf — également appelé mDNS ou Bonjour — pour découvrir de nombreux services présents sur le réseau local.D’autres équipements, comme certains téléviseurs, lecteurs multimédias ou appareils UPnP, peuvent être découverts via SSDP.
Autrement dit, Home Assistant n’attend pas toujours qu’on lui fournisse une adresse IP. Une partie de la maison se présente spontanément à lui.
J’avais maintenant deux résultats sous les yeux. Home Assistant répondait. La découverte locale, non. Ce n’était plus contradictoire.
C’était le diagnostic.
Ouvrir Home Assistant ne prouve pas que le tunnel transporte le salon avec lui
Mon second routeur avait créé une frontière que l’interface web m’avait fait oublier.
Depuis le bureau, une requête destinée à l’adresse IP de Home Assistant pouvait être routée vers le réseau principal. C’est une conversation ciblée : mon ordinateur sait où se trouve le serveur et le routeur sait où envoyer le paquet.
La découverte locale ressemble beaucoup moins à cela.
mDNS utilise des échanges multicast prévus pour le réseau local. La norme RFC 6762 décrit précisément ce fonctionnement autour de .localet d’adresses multicast réservées à cette découverte.
L’image qui m’a finalement permis de comprendre est plus simple que les adresses réseau. Accéder à Home Assistant, c’est envoyer une lettre avec une adresse complète. La découverte, c’est entrer dans une pièce et demander : « Qui est là ? »
Un routeur peut très bien acheminer la lettre jusqu’à la bonne maison sans répéter la question dans la pièce voisine.
C’est exactement la limite que je venais de rencontrer.
Et ajouter un VPN au milieu ne transforme pas automatiquement ces deux conversations en une seule.
WireGuard, par exemple, encapsule des paquets IP et les achemine selon les adresses et les routes configurées. Sa documentation décrit ce fonctionnement comme un tunnel réseau IP ; son livre blanc le situe explicitement à la couche 3.
C’est excellent pour dire : « Tout ce qui vise ce sous-réseau passe par ici. » Cela ne signifie pas forcément : « Fais comme si les deux côtés du tunnel se trouvaient dans le même salon. »
Cette distinction m’a évité de continuer à chercher du côté du débit, du serveur VPN ou de Home Assistant lui-même.
Une discussion de mai 2026 m’aurait fait gagner une soirée
Je n’étais manifestement pas le premier à tomber dans ce piège.
En mai 2026, un utilisateur du forum Home Assistant décrivait une installation très proche dans son principe : une instance Home Assistant centralisée sur un site, un second réseau relié via WireGuard, un VPN qui semblait fonctionner pour certains appareils, mais Home Assistant incapable d’atteindre ou de découvrir les équipements du site distant.
Ce témoignage ne m’intéressait pas parce qu’il reproduisait exactement mon installation. Il m’intéressait parce qu’il montrait la même fausse conclusion : « Le VPN fonctionne, donc le réseau distant devrait être visible. » Ce n’est pas nécessairement le même test.
À partir de là, je n’ai plus demandé seulement si une route existait. Je me suis demandé ce que j’essayais réellement de faire passer par cette route. Mon ordinateur avait-il seulement besoin d’accéder à une adresse Home Assistant connue ?
Ou voulais-je que Home Assistant reçoive aussi les annonces locales des appareils situés de l’autre côté ? Dans mon cas, c’était la deuxième chose que j’attendais sans l’avoir réellement configurée.
J’ai d’abord voulu rendre le routeur plus intelligent
La solution technique évidente était de conserver toute mon architecture et de réparer la découverte. Pour mDNS, il existe des réflecteurs ou des répéteurs capables de retransmettre certaines annonces entre plusieurs segments réseau. J’ai commencé à regarder cette piste. Puis la liste des questions s’est allongée.
Qu’en était-il des équipements utilisant SSDP ? Des règles de pare-feu entre les sous-réseaux ? Des intégrations qui, après avoir découvert un appareil, doivent ouvrir elles-mêmes une connexion vers son adresse privée ? Je pouvais continuer.
Mais à ce moment-là, j’ai réalisé que je résolvais un problème que j’avais moi-même créé. Pourquoi avais-je placé tout le bureau derrière ce second routeur ? Pour le VPN. Et quels appareils avaient réellement besoin du VPN ?
Mon ordinateur. Mon téléphone, parfois. Pas les prises. Pas l’ampli.
Pas les capteurs. Et certainement pas Home Assistant. Cette question a complètement changé la suite.
J’avais placé le tunnel au niveau du réseau alors que mon besoin se trouvait sur deux appareils
J’ai reconnecté les appareils domotiques au réseau principal. Le second routeur a cessé d’être leur passage obligé. Puis j’ai relancé la découverte. Le nouvel appareil est apparu.
Configurer. Quelques instants plus tard, ses entités étaient sur le tableau de bord. La partie Home Assistant était réglée.
Mais je voulais toujours ce qui avait motivé toute cette installation : utiliser un VPN sur mon portable sans reconstruire le réseau de la maison autour de lui.
Cette fois, j’ai déplacé le tunnel au lieu d’essayer d’étendre le salon à travers lui.
J’ai installé OnlydogVPN↗ directement sur l’ordinateur.
L’approche correspondait beaucoup mieux au problème qui me restait. L’application existe sur iPhone, Android, Mac et Windows, et son interface privilégie une connexion en quelques gestes plutôt qu’une configuration réseau préalable.
J’ai connecté le VPN. Puis j’ai repris les deux choses qui comptaient réellement. Sur Internet, l’ordinateur utilisait le tunnel. Dans Home Assistant, les appareils du réseau local étaient toujours là.
J’ai ouvert la nouvelle prise. Éteindre. Clic. Rallumer.
Clic. Elle répondait.
Pendant ce test, je n’avais plus besoin de choisir entre mon VPN et une maison qui continuait à se comporter comme une maison.
C’est là que la solution m’a paru beaucoup plus évidente qu’au début : le VPN s’occupait de l’appareil qui avait besoin d’une autre route Internet ; Home Assistant et les objets connectés restaient ensemble sur le réseau qui leur permettait de se découvrir.
Je n’avais finalement pas besoin d’un tunnel plus sophistiqué.
J’avais besoin de placer le tunnel au bon endroit.
Ce que je demandais au tunnel n’était tout simplement pas son travail
Il existe évidemment un autre scénario.
Si mon objectif avait réellement été de relier deux logements, d’administrer les appareils d’un autre site ou d’accéder à Home Assistant depuis l’extérieur, je n’aurais pas supprimé le tunnel routé.
Dans ce cas, il faut accepter que le réseau distant soit un vrai sujet d’architecture : routes entre les sous-réseaux, découverte mDNS ou SSDP lorsqu’elle est nécessaire, pare-feu, DNS, voire configuration manuelle de certains appareils.
Et le petit VPN installé sur mon portable ne prétend pas remplacer ce travail.
C’est la limite importante ici.
Si je veux que deux maisons se comportent comme un seul LAN, installer une application VPN commerciale sur un ordinateur ne suffit pas.
Mais ce n’était précisément pas mon problème.
J’avais séparé une partie de ma maison simplement parce que deux appareils avaient besoin d’un VPN. Ensuite, comme l’interface Home Assistant continuait à s’ouvrir, j’avais pris cette réussite pour la preuve que tout le réseau fonctionnait.
Les appareils invisibles racontaient autre chose.
Depuis, lorsque Home Assistant reste joignable mais qu’un équipement disparaît après l’ajout d’un VPN, je ne commence plus par changer de serveur ou de protocole.
Je regarde de quel côté du routeur se trouvent Home Assistant et l’appareil que j’attends.
Parce que, dans une maison connectée, atteindre le tableau de bord prouve qu’une route existe ; voir les appareils prouve que le réseau local existe encore là où Home Assistant en a besoin.

Quelques liens que j’avais ouverts à l’époque
Questions fréquentes
Pourquoi le tableau de bord Home Assistant peut-il s’ouvrir alors qu’un appareil n’est plus découvert ?
Parce que l’accès au tableau de bord peut utiliser une route unicast vers une adresse connue, tandis que la découverte de certains appareils dépend de mDNS/Zeroconf ou SSDP sur le réseau local.
Un tunnel WireGuard fait-il automatiquement passer mDNS entre deux réseaux ?
Non. WireGuard route des paquets IP selon les adresses et les routes configurées. Cela ne signifie pas que les annonces multicast de découverte locale seront automatiquement répétées de l’autre côté.
Quand faut-il envisager un réflecteur mDNS ou une architecture réseau plus poussée ?
Lorsque vous avez réellement besoin que des appareils de sous-réseaux ou de sites différents se découvrent entre eux. Il faut alors considérer aussi SSDP, le pare-feu, les routes et les connexions privées utilisées après la découverte.
Quand vaut-il mieux placer le VPN directement sur l’ordinateur ?
Lorsque le besoin VPN concerne seulement quelques postes, tandis que Home Assistant et les objets connectés doivent surtout rester ensemble sur le même LAN pour se découvrir normalement.
