Accès distant à Home Assistant en 2026 : tout ce que les tutos ne disent pas

Il y a un moment dans la vie de tout utilisateur de Home Assistant. Vous êtes parti pour le week-end. Votre conjoint écrit : « quelque chose ne marche plus » - les lumières du salon ne réagissent pas. Vous ouvrez l'appli HA sur votre téléphone. Roue qui tourne. Timeout.

Et là, vous réalisez que toute cette belle configuration - 200 appareils ZigBee, 40 automatisations, un tableau de bord peaufiné pendant un mois - n'est accessible que dans le périmètre du Wi-Fi domestique.

Les tutoriels en ligne disent : « configure un VPN » ou « ouvre le port 8123 ». Les deux sont techniquement corrects. Les deux sont une mauvaise idée en 2026 pour la plupart des gens. Pourquoi - c'est l'objet de cet article.

TL;DR pour les pressés#

• La redirection de ports marche, mais expose votre panneau HA aux scanners du monde entier. Sans travail supplémentaire = exposition permanente aux zero-days de HA.
• VPN (WireGuard) est super pour vous, mais mauvais pour la famille - une app séparée sur chaque téléphone, casse lors des changements de réseau.
• Nabu Casa est simple, mais vous enferme dans l'écosystème HA - si vous utilisez aussi Jellyfin ou Grafana, vous avez besoin d'une deuxième solution.
• Tailscale combine avantages VPN et confort, mais nécessite encore un client.
• Tunnel SSH inversé (ce que font des services comme SmartHomeEntry pour la maison) vous donne une adresse HTTPS normale - la famille clique un lien dans le navigateur.
• Si vous êtes derrière un CGNAT (4G/5G mobile, la plupart des offres 5G box, beaucoup de fibres en Europe) - vous avez deux options : tunnel sortant (SSH/Nabu Casa/Tailscale) ou dormir sans accès distant.

Le reste est le « pourquoi ».

À quoi ressemble vraiment votre réseau en 2026 - pas comme dans un tuto de 2018#

Quand quelqu'un vous a dit « ouvre un port sur le routeur », il écrivait probablement avant l'ère CGNAT. Et j'ai passé trop de temps à expliquer aux gens pourquoi leur redirection de ports « ne marche pas », avant de finalement demander : « qui est votre FAI et est-ce de la 4G ? ».

Pourquoi votre FAI ne vous aime plus#

La raison est à la fois technique et politique. Il y a un nombre fini d'adresses IPv4 - environ 4,3 milliards. Le monde a plus de 8 milliards d'appareils connectés. Les opérateurs ont résolu ça de la pire manière pour les bricoleurs : Carrier Grade NAT (CGNAT).

Au lieu de donner à chaque client une IP publique, le FAI vous donne une adresse privée (ex. 100.64.x.x), et tout un groupe de clients partage une seule adresse publique côté opérateur. Tout le sortant fonctionne - sites, e-mail, streaming. Mais personne de l'extérieur ne peut vous joindre. Le port 8123 sur votre routeur ? Du point de vue d'Internet, il n'existe pas. Il ne marchera jamais. Vous pouvez cliquer UPnP à l'infini.

Vous trouverez du CGNAT chez :

• Tous les forfaits mobiles (Orange, SFR, Bouygues, Free Mobile - partout en France) - 100 % des cas.
• La plupart des box 5G fixe (Orange 5G Box, Free 5G Box, similaires) - 95 %+.
• Part croissante des fibres - 20-40 % selon opérateur et région.
• FAI « de quartier » avec upstream partagé.

Comment vérifier : allez sur whatismyip.com depuis chez vous, notez l'IP. Puis dans l'admin du routeur, cherchez « WAN IP ». Si différentes - vous êtes derrière CGNAT. Identiques - vous avez une IP publique.

Conséquence : 90 % des tutos YouTube ne vous concernent plus#

Vous tombez sur une chaîne avec 200k abonnés. Le gars fait de la redirection de ports sur un TP-Link de 2019. Chez lui ça marche - il est en ADSL/câble avec IP publique legacy. Chez vous non, parce que vous êtes en fibre derrière CGNAT. Commentaires : « ça marche pas, je suis nul ? ». Réponse : « redémarre le routeur. »

Sept façons d'avoir HA à distance - classement honnête#

Chacune est la bonne réponse dans un contexte spécifique. Le problème des conseils en ligne : personne ne dit dans quel contexte.

1. Redirection de ports + DynDNS#

Comment : ouverture du port 8123 (ou 443 avec reverse proxy) sur le routeur. Domaine type chezmoi.duckdns.org pointant vers l'IP publique, mise à jour par DynDNS.

Quand c'est pertinent : IP publique, domaine à vous, Nginx avec Let's Encrypt maîtrisé, monitoring actif des logs de sécurité.

Pourquoi presque personne ne remplit ces conditions : parce que personne ne surveille les logs. Dans trois mois un CVE tombe pour une intégration HA, vous êtes en vacances. Plus : la plupart configurent une fois et c'est fini - zéro mise à jour, zéro fail2ban, mot de passe toujours admin1234 de 2020.

Verdict : pour 1 % des gens qui font du réseau en pro. Pour le reste, un piège.

2. WireGuard / OpenVPN#

Comment : serveur WG sur HA (add-on), génération de clés, installation de l'app sur chaque appareil du foyer. Chaque téléphone se connecte au réseau comme s'il était sur place.

Pour : accès complet au réseau (pas que HA - aussi NAS, imprimante, caméras), chiffrement solide, zéro coût.

Contre, dont personne ne parle :

• Une app sur le téléphone du conjoint. Nouvel invité = reconfiguration.
• HA mobile en déplacement. Le téléphone passe de 4G à Wi-Fi café, VPN se déconnecte, notifications HA perdues puis arrivent en bloc.
• Batterie. WireGuard est léger, mais VPN always-on mange 5-15 % de batterie par jour.
• Ne marche pas derrière CGNAT. Pas d'IP publique sur le routeur = pas d'IP publique sur le serveur WG dessus.

Quand WireGuard est bon : un seul utilisateur, IP publique, vous faites du réseau en pro et voulez tout gérer (pas que HA).

3. Tailscale#

Comment : réseau overlay. Chaque appareil installe un client Tailscale, qui crée un mesh via leur coordinateur. Problème CGNAT résolu via DERP relay.

Pour : marche partout, même derrière CGNAT. Config minimale. Free tier jusqu'à 6 utilisateurs, appareils illimités.

Contre :

• Une app sur chaque appareil. Même problème que WireGuard - un gardien pour un week-end n'installe pas Tailscale.
• Coordinateur fermé (Headscale existe en OSS, mais projet à maintenir en plus).
• Perfs baissent via DERP - si les deux endpoints sont derrière CGNAT, trafic par serveur Tailscale (parfois en Oregon). Latence pour un utilisateur européen : 180-250 ms.

Quand Tailscale est bon : une ou deux personnes, besoin d'accès à autre chose que HA, acceptation d'un client sur chaque téléphone.

4. Nabu Casa (Home Assistant Cloud)#

Comment : service cloud officiel de Nabu Casa (qui développe HA). Setup : un interrupteur dans les paramètres. Adresse type chainealéatoire.ui.nabu.casa.

Pour : déploiement le plus simple de tout l'article - un switch. Soutient HA financièrement. Fonctionne derrière CGNAT. Alexa, Google Assistant out of the box.

Contre :

• Ne fonctionne qu'avec HA. Jellyfin ? Non. Grafana ? Non. Votre galerie photo sur mini-PC ? Non. Pour le reste, deuxième solution.
• Sous-domaine aléatoire. abc123xyz.ui.nabu.casa, personne ne mémorise.
• Latence. Trafic via relais Nabu Casa, par défaut aux US. Utilisateurs européens : ~150-250 ms en plus.
• Pas de HTTPS sur votre domaine. home.votredomaine.fr impossible.

Quand Nabu Casa est bon : vous utilisez UNIQUEMENT HA, vous valorisez la simplicité, vous voulez soutenir le projet.

5. Cloudflare Tunnel (cloudflared)#

Comment : free tier Cloudflare. cloudflared sur HA, connexion sortante vers Cloudflare, vous configurez dans Zero Trust : home.votredomaine.fr → tunnel.

Pour : gratuit, marche derrière CGNAT, domaine à vous, HTTPS avec cert CF, protection DDoS.

Contre :

• Domaine à posséder (un .fr coûte 10 €/an).
• Cloudflare peut couper la connexion via règles WAF - fantastique à debug.
• Streaming vidéo (caméras, Jellyfin) viole les CGU de Cloudflare en free tier. Officiellement. Application inégale, mais votre caméra RTSP via cloudflared c'est la roulette russe.
• Setup : pas très complexe, mais nécessite de comprendre DNS, Zero Trust, tunnels. Pas « 60 secondes ».

Quand Cloudflare Tunnel a du sens : domaine déjà possédé, pas de streaming vidéo, stack Cloudflare maîtrisée.

6. ngrok / outils similaires de dev-tunnel#

Comment : ngrok crée un tunnel vers HA, donne xyz.ngrok.io.

Pour : lancement le plus rapide possible, 30 secondes.

Contre :

• Free tier coupe les sessions toutes les 2 heures - URL change.
• ngrok payant cher pour juste HA (10 $/mois pour Hobbyist avec sous-domaine fixe).
• Pas conçu pour prod - démo OUI, HA permanent NON.

Quand ngrok a du sens : montrer HA à un ami lors d'un meetup pendant une heure. Pas d'usage permanent.

7. Tunnel SSH inversé (auto-hébergé ou service managé)#

Comment : agent sur HA ouvre un tunnel SSH sortant vers un serveur relais. Le relais expose HA sur une URL HTTPS fixe. Zéro port ouvert chez vous.

Pour :

• Fonctionne derrière CGNAT (sortant, pas entrant).
• Sous-domaine HTTPS stable - chezmoi.smarthomeentry.com (ou le vôtre en auto-hébergé).
• Famille sans app - tout le monde ouvre un lien dans le navigateur. Grand-mère aussi.
• Supporte tout service HTTP - HA, Jellyfin, Nextcloud, Grafana, ce que vous voulez.
• SSH sortant traverse chaque pare-feu et chaque CGNAT. Toujours.

Contre :

• Dépend du relais. Managé = leur uptime. Auto-hébergé = serveur de plus à maintenir.
• Pas d'accès complet au réseau (contrairement au VPN). Pas de SSH sur le Pi par ce lien. C'est un tunnel HTTP.
• Coûte en version managée (3-8 €/mois pour la maison).

Quand c'est pour vous : famille sans compétences tech, vous voulez « clique un lien, ça marche », CGNAT, plusieurs services (HA + NAS + Jellyfin). La plupart des bricoleurs réels.

SSH inversé - ce que fait vraiment cet agent#

Parce que ça sonne magique, mais ça ne l'est pas. Décortiqué :

Imaginez appeler la réception d'un hôtel en disant : « je rappelle dans 10 secondes, gardez la ligne ». Puis vous rappelez, la réception vous passe à la personne qui attendait déjà. L'appelant n'a jamais eu besoin de connaître votre numéro.

L'agent fait pareil avec TCP :

1. L'agent appelle le relais (SSH sortant, port 22 ou 443). Le routeur ne bloque pas, SSH sortant c'est du trafic normal.
2. L'agent dit au relais : « réserve-moi le port local 20451, et tout ce qui arrive sur chezmoi.smarthomeentry.com, renvoie-le-moi ».
3. Le relais enregistre le mapping en mémoire.
4. Un utilisateur visite chezmoi.smarthomeentry.com - DNS pointe sur le relais.
5. Nginx sur le relais reçoit la requête, regarde le mapping : « ah, ce sous-domaine = tunnel vers agent #42 ». Redirige vers localhost:20451.
6. Port 20451 sur le relais = canal vers l'agent. L'agent prend le trafic, redirige vers localhost:8123 chez vous. HA répond, le trafic repart par le même chemin.

Conséquences clés :

• Votre HA n'est jamais directement accessible depuis Internet. Seule une tranche du relais l'est, et uniquement comme mapping.
• Port 20451 sur le relais écoute sur 127.0.0.1, pas 0.0.0.0. Personne d'externe ne le voit sauf Nginx.
• Clés SSH uniques par tunnel. Compromis d'un agent ne donne pas accès aux autres.
• HTTPS termine sur le relais, pas sur votre HA. Simplifie les certificats (wildcard LE).

Sécurité : trois choses que les tutos ne vous diront pas#

1. HTTPS n'est pas de la sécurité. C'est de la vie privée.#

Chaque tuto dit : « il faut du HTTPS ! ». Vrai. Mais HTTPS protège du sniffing en terrasse - pas du fait que quelqu'un devine votre mot de passe HA. Deux problèmes différents.

Si vous utilisez admin/admin - HTTPS ne fait rien. Si vous utilisez dupont_2007 et avez exposé le port 8123 - un bot se connecte en 48 heures.

À faire : activer 2FA dans HA (Menu → Votre profil → Authentification multi-facteurs). Un champ, changement de jeu. Plus un gestionnaire de mots de passe.

2. Les mises à jour HA sont critiques, mais cassent les automatisations#

HA publie une release mensuelle. Chacune contient des fixes sécurité. Si votre installation est sur Internet et que vous mettez à jour tous les six mois « par peur de casser » - vous êtes vulnérable aux zero-days cinq mois d'affilée.

Un tunnel SSH inversé (ou toute solution sans port exposé) réduit le problème, car l'attaquant doit d'abord passer le relais. Ne l'élimine pas.

À faire : activer les updates auto HA Core (Supervisor → Paramètres → Mises à jour). Mensuel. Les breaking changes sont dans les custom components, rarement dans le core.

3. Les logs HA vous disent exactement qui tente de se connecter#

Developer Tools → Logs. Tapez « auth ». Vous verrez :

• Tentatives depuis vos IPs (vous, famille).
• Si HA est exposé : milliers de tentatives depuis 185.x.x.x, 91.x.x.x, 47.x.x.x - bots de scan.

Le second type + pas de 2FA = problème « dans une semaine, un mois, un jour ». SSH inversé l'élimine, car HA est physiquement inaccessible sans passer par le relais.

Redondance : si le relais tombe ?#

Question critique que les articles sponsorisés n'abordent jamais. Réponse honnête.

• Votre HA continue en local. Lumières, automatisations, notifications dans la portée Wi-Fi - tout fonctionne. Le relais est juste la couche d'accès distant.
• Vous perdez l'accès externe. Pas de consultation depuis le bureau. Pas d'alarme vérifiée en vacances.
• L'agent retente toutes les 60 secondes. Relais revient, tunnel revient. Vous n'avez rien à faire.
• Usages critiques (surveillance de senior, alarme) - SSH inversé est un vecteur, panne = pas d'accès. Deuxième canal à côté (bot Telegram depuis HA, SMS via Twilio sur capteur de mouvement).

Ma reco : pour la plupart, risque acceptable. Les pannes de relais représentent peut-être 2-3 heures par an. Comme un hoquet d'upstream chez le FAI.

Performance : combien de ms perd votre widget thermomètre#

Question pratique, parce que 800 ms pour allumer une lampe au lieu de 50 ms, ça frustre.

Mesuré (utilisateur en Europe, relais à Varsovie) :

• Redirection de ports (direct) : 30-80 ms.
• Tunnel SSH inversé (relais UE) : 50-120 ms.
• Nabu Casa (relais US) : 150-250 ms.
• Tailscale DERP relay : 180-300 ms.
• Tailscale P2P (les deux avec IP publique) : 30-80 ms.

Conclusion : l'emplacement du relais compte. Pour un utilisateur européen, un relais UE est presque local. US = dégradation perceptible.

HA mobile - sans compromis#

Cette section écrite par frustration. HA Companion fonctionne bien, mais veut une URL. Et là chaque méthode a ses pièges :

• Redirection + DynDNS : marche, mais l'app perd parfois la connexion au changement de réseau (Wi-Fi → 4G).
• VPN : HA Companion galère avec always-on VPN, surtout en mauvais réseau (hôtel, étranger).
• Nabu Casa : meilleure intégration app (un clic dans config). Setup le plus simple.
• SSH inversé : l'app voit du HTTPS normal. Out of the box. Ajouter chezmoi.smarthomeentry.com, fini.

Push mobiles depuis HA - Nabu Casa gagne via intégration FCM/APNS. Autres options = push à configurer (réalistiquement : bot Telegram comme fallback le moins cher).

Quand NE PAS utiliser SmartHomeEntry (ou SSH inversé en général)#

Puisque j'écris ceci en tant que personne qui construit ce produit, je veux être honnête :

• Admin sys, vous vivez seul, IP publique. Montez WireGuard - gratuit, contrôle total, vous apprenez.
• Uniquement Home Assistant, rien d'autre. Nabu Casa est plus simple et soutient les créateurs HA.
• Streaming 4K de caméras non-stop. Un relais (le nôtre ou Nabu Casa) n'est pas le bon canal pour du 15 Mbps continu. Mieux : redirection de ports + Nginx avec rate-limit.
• Obsession de la latence <50 ms pour le contrôle. Pour une ampoule, 150 ms vont bien. Pour un robot aspirateur aussi. Pour du jeu - pas l'affaire de HA.
• Tout sur votre propre infra sans dépendance externe. Montez votre SSH + Nginx - c'est un projet de week-end plus un VPS à maintenir.

Quand SSH inversé est pour vous : CGNAT (majorité des bricoleurs européens), famille sans patience pour VPN, plusieurs services (HA + NAS + Jellyfin), « clique et ça marche ». Décrit peut-être 70 % des utilisateurs HA en Europe.

Comment faire en 60 secondes (pratique)#

Si vous pensez « OK, SSH inversé a du sens » - voici le setup complet avec SmartHomeEntry.

Étape 1 : création de compte#

Allez sur smarthomeentry.com, choisissez un plan (Lite 5 €/mois pour 1 installation suffit). Sous-domaine nom.smarthomeentry.com provisionné.

Étape 2 : copiez la commande#

Dans le panel de compte, vous obtenez une ligne curl :

curl -fsSL https://get.smarthomeentry.com | sudo bash -s -- --token ABCD1234

Étape 3 : collez dans le terminal HA#

Comment accéder au terminal ? Selon la plateforme :

• HAOS : Menu → Terminal & SSH (add-on communautaire).
• HA Supervised sur Pi : SSH vers [email protected].
• HA Core (Docker) : docker exec -it homeassistant bash.
• HA sur Linux séparé : SSH normal.

Collé, Entrée. L'agent :

• Télécharge le binaire (~8 Mo).
• Génère les clés SSH.
• Écrit l'unit systemd (ou cron / Docker restart selon plateforme).
• Se connecte au relais.

Étape 4 : ouvrez votre lien#

Dans un nouvel onglet, tapez votrenom.smarthomeentry.com. HA charge.

Temps mesuré : 43 secondes du clic « abonner » au dashboard chargé. 60 secondes est conservateur.

Une question sans bonne réponse#

Que se passe-t-il si l'entreprise utilisée comme relais disparaît ? (concerne toutes les solutions managées - Nabu Casa, SmartHomeEntry, Cloudflare, Tailscale.)

Cloudflare, Tailscale : grandes entreprises, risque de panne faible sur 5 ans. Mais changements de politique (comme chez CF free tier) = risque réel.

Nabu Casa : fondation derrière HA, existe tant que HA existe. Risque le plus bas.

SmartHomeEntry et autres managés moyens : risque moyen sur 10 ans.

Atténuation : choisir un service avec agent open-source. Si notre entreprise ferme, et l'agent SmartHomeEntry est public sur GitHub, la communauté reprend ou vous migrez sur un fork. Vendor lock-in minimal.

Si votre solution n'a pas d'agent ouvert - vous payez pour le confort aujourd'hui, mais achetez du risque pour demain.

Lectures suivantes#

• Système spécifique : Home Assistant, Domoticz, Nextcloud, Jellyfin, NAS Synology/QNAP, Grafana.
• Comparaisons plus profondes : Tailscale vs SmartHomeEntry, Alternative à Cloudflare Tunnel, Alternative à ngrok, Alternative à Nabu Casa.
• Installation sur matériel : HA sur Raspberry Pi, HA sur Synology.
• Installateur avec des clients ? Autre article : Comment régler 80 % des tickets depuis votre bureau.

Si vous avez lu jusqu'ici#

Un enseignement : il n'existe pas une bonne solution pour tous. Il y en a plusieurs, chacune bonne dans son contexte. Ceux qui écrivent « toujours X » ou « les VPN c'est mauvais » ont en général peu de clients et beaucoup d'opinions.

Ma recommandation perso pour la majorité des bricoleurs en 2026 : tunnel SSH inversé avec relais managé et agent open-source. Meilleur équilibre « facile à maîtriser » / « la famille ne déteste pas » / « marche partout, y compris derrière CGNAT ». Si vous voulez essayer notre implémentation - setup 60 secondes ici.

Mais si après cet article vous optez pour WireGuard, Nabu Casa, ou votre propre sshd sur VPS - l'article a aussi fait son job. L'objectif : que vous sachiez pourquoi vous choisissez, pas juste quoi.