Un appareil connecté en cloud envoie ses commandes et son état vers les serveurs de son fabricant, qui les renvoie ensuite au logement. Un appareil piloté en local reçoit ses ordres directement sur le réseau domestique. Avec Home Assistant, cette distinction est concrète : le système tourne sur votre propre matériel, et les appareils qui le permettent sont joints sur le réseau local, sans passer par le cloud du fabricant. C’est ce choix qui détermine ce qui continue de fonctionner lorsque la connexion internet est coupée.
Cloud et local : quelle différence ?
Dans une installation cloud, chaque action transite par les serveurs du fabricant : l’ordre part de l’application ou de l’assistant vocal, atteint les serveurs, puis revient vers l’appareil. Dans une installation locale, l’ordre circule uniquement dans le logement, entre le système de contrôle et l’appareil.
Flux de données vers les serveurs du fabricant
Avec une application propriétaire, la commande et l’état de l’appareil peuvent donc sortir du logement. Home Assistant suit une logique inverse : il tourne sur votre matériel et stocke vos données localement. Aucun compte n’est nécessaire pour l’utiliser, et Home Assistant lui-même ne transmet pas vos appareils ni vos données à un tiers (Home Assistant, 2026), sauf si vous activez Home Assistant Cloud ou des intégrations cloud de fabricants tiers. Un compte n’est lié qu’au service optionnel Home Assistant Cloud.
Commande locale et protocoles sans internet
Les automatismes basés sur Zigbee, Z-Wave, Matter, Thread ou ESPHome ne dépendent alors que du matériel présent dans le logement.
| Critère | Cloud du fabricant | Local avec Home Assistant |
|---|---|---|
| Parcours d’une commande | Serveurs du fabricant, puis appareil | Réseau local, jusqu’à l’appareil |
| Connexion internet requise | Oui | Non pour Zigbee, Z-Wave, Matter, Thread et ESPHome |
| Accès à distance | Assuré par le service du fabricant | Optionnel, via Home Assistant Cloud |
Latence et dépendance à la connexion
Une commande cloud effectue un aller-retour vers des serveurs distants. Sa réactivité dépend donc de la qualité de la connexion internet et de la disponibilité du service du fabricant. Une commande locale reste dans le logement et ne subit pas cet aller-retour.
Home Assistant garde-t-il vraiment mes données chez moi ?
Oui. Home Assistant fonctionne sur votre propre matériel et y stocke vos données. Le système ne repose donc pas sur un serveur distant pour fonctionner : tant que l’hôte tourne chez vous, la base de données, l’historique et les automatisations restent sur ce matériel.
Un stockage sur votre propre matériel
Home Assistant s’exécute sur un appareil que vous contrôlez, qu’il s’agisse d’un mini-ordinateur, d’un Raspberry Pi ou d’un serveur domestique. C’est sur cet hôte que sont enregistrés la configuration, l’historique des états et les règles d’automatisation. Aucune de ces données n’a besoin d’un serveur externe pour être créée ou consultée.
Le principe est simple : le matériel local est le seul lieu de stockage par défaut. Pour vérifier cette architecture sur votre installation, contrôlez que l’interface ne demande aucune connexion à un compte en ligne au démarrage, et que vous pouvez accéder à votre tableau de bord depuis le réseau domestique sans identifiants distants.
Une communication directe avec les appareils
Quand l’appareil le permet, Home Assistant le joint directement sur le réseau local, sans passer par le cloud du fabricant. Les protocoles Zigbee, Z-Wave, Matter, Thread et ESPHome ne nécessitent pas de connexion internet (Home Assistant, 2026). Un capteur Zigbee ou un interrupteur Z-Wave peut donc continuer à être piloté alors que votre box est hors ligne.
| Élément | Connexion internet requise |
|---|---|
| Zigbee | Non |
| Z-Wave | Non |
| Matter | Non |
| Thread | Non |
| ESPHome | Non |
Ce que le service optionnel Home Assistant Cloud change
Home Assistant Cloud est un service optionnel. Il assure l’accès distant, la liaison avec Alexa et Google Assistant, la voix, les sauvegardes hors site, les webhooks et le WebRTC pour les caméras (Home Assistant, 2026). Parmi les services de Home Assistant, c’est celui qui fait transiter des données par une infrastructure extérieure à votre domicile. Les intégrations cloud de fabricants tiers en créent aussi. Sans souscription ni connexion à ce service, ces flux n’existent pas.
Vérifier que l’appareil fonctionne en local
Un appareil fonctionne réellement en local lorsqu’il reste commandable et continue de remonter son état pendant une coupure internet. L’étiquette « sans cloud » ne précise pas le chemin de communication utilisé, donc ce test doit être fait sur le terrain.
Test de coupure internet sur le réseau du logement
- Noter l’état actuel de l’appareil dans Home Assistant (allumé ou éteint, température, etc.) ainsi que l’heure.
- Couper l’accès internet du logement en débranchant le lien WAN de la box ou du modem, sans arrêter le réseau local.
- Vérifier que Home Assistant reste joignable depuis un appareil du réseau local, à son adresse IP locale.
- Envoyer une commande à l’appareil depuis Home Assistant, puis contrôler qu’il l’exécute et que son état se met à jour.
- Rétablir la connexion et comparer les résultats.
| Vérification | Résultat si l’appareil est local |
|---|---|
| Interface Home Assistant accessible via l’IP locale | Oui |
| Commande envoyée depuis Home Assistant | Exécutée, état mis à jour |
| Commande depuis l’application du fabricant | Échec attendu si elle transite par le cloud |
Classe IoT de l’intégration : local push ou polling
Chaque intégration déclare une classe IoT dans sa documentation officielle sur le site de Home Assistant. Pour ce test, quatre valeurs sont à distinguer :
- local_push : l’appareil envoie lui-même ses changements d’état à Home Assistant sur le réseau local.
- local_polling : Home Assistant interroge l’appareil à intervalle régulier, toujours sur le réseau local.
- cloud_push : les changements d’état passent par un serveur du fabricant.
- cloud_polling : Home Assistant interroge un serveur du fabricant.
Automatisation déclenchée sans internet
Créer une automatisation simple qui n’utilise que des éléments locaux, par exemple un capteur de mouvement qui allume une ampoule, ou une minuterie qui commande une prise. Pendant la coupure, provoquer le déclencheur (passer devant le capteur, attendre l’heure programmée) et vérifier que l’action s’exécute. Si l’automatisation fonctionne hors ligne alors que la commande depuis l’application du fabricant échoue, le chemin local est confirmé pour cet appareil.
Journal vérifié
Pendant le test, consulter Paramètres > Système > Journaux dans Home Assistant. Repérer les erreurs de connexion ou les délais d’attente liés à l’appareil : leur présence pendant la coupure indique une dépendance au cloud. Ensuite, ouvrir l’historique de l’entité pour comparer les horodatages des changements d’état avec les heures de coupure et de rétablissement notées au départ. Des changements d’état enregistrés pendant la coupure, sans erreur associée, sont un indice de fonctionnement local. Ils doivent être recoupés avec la commande exécutée à l’étape 4 et l’automatisation testée hors ligne.
Désactiver Home Assistant Cloud
Le désactiver revient à empêcher son chargement dans la configuration et à ne pas se connecter à un compte. Deux méthodes existent : retirer l’intégration cloud du démarrage, ou couper uniquement l’accès distant par une action. Elles ne produisent pas le même effet.
Retirer default_config dans configuration.yaml
L’intégration cloud est chargée par défaut via default_config. Pour empêcher ce chargement :
- Ouvrez le fichier
configuration.yamlde votre instance. - Enregistrez une copie de sauvegarde du fichier.
- Retirez la ligne
default_config:ou mettez-la en commentaire avec#. - Redémarrez Home Assistant pour appliquer la modification.
Avant de retirer cette ligne, consultez la documentation officielle de votre version pour connaître les autres intégrations qu’elle charge. Ajoutez explicitement celles dont vous avez besoin, afin de ne pas perdre de fonctions locales par inadvertance.
Ne créer aucun compte
La désactivation complète suppose de ne créer aucun compte et de ne jamais se connecter au service. Sans connexion, aucun identifiant cloud n’est lié à l’instance. Si un compte a déjà été créé, vérifiez son statut dans les paramètres de Home Assistant en vous reportant à la documentation de votre version.
Couper l’accès distant avec cloud.remote_disconnect
L’action cloud.remote_disconnect coupe uniquement l’accès distant. Elle ne modifie pas le reste de la configuration et s’exécute comme toute action Home Assistant, par exemple depuis un script ou une automatisation.
| Méthode | Effet | Usage recommandé |
|---|---|---|
| Retrait de default_config | L’intégration cloud n’est plus chargée au démarrage | Désactivation durable du service |
| Action cloud.remote_disconnect | Coupe l’accès distant, configuration inchangée | Arrêt ponctuel de l’accès à distance |
Que perd-on sans le cloud ?
Retirer Home Assistant Cloud supprime les services qu’il assure : l’accès distant, le pont vocal vers Alexa et Google Assistant, la voix, les sauvegardes hors site, les webhooks et le WebRTC pour les caméras. Le reste de l’installation continue de fonctionner, car Home Assistant stocke ses données et exécute ses automatisations sur votre propre matériel. Cette perte concerne donc des services annexes, pas le cœur de la domotique locale.
| Fonction | Avec Home Assistant Cloud | Sans cloud |
|---|---|---|
| Commandes vocales Alexa et Google Assistant | Passent par le service Home Assistant Cloud | Ne passent plus par ce service ; vérifier dans la documentation de chaque intégration si une voie locale existe |
| Visualisation des caméras (WebRTC) | Flux établi via le cloud | Pas de flux WebRTC par ce canal ; le visionnage reste possible sur le réseau local selon le type de caméra |
| Sauvegardes hors site | Copies automatiques chez le fournisseur | Aucune copie externe automatique |
Assistants vocaux
Les commandes vocales sont la fonction la plus visible. Dans la configuration par défaut, Alexa et Google Assistant envoient leurs requêtes à Home Assistant via le cloud. Sans ce service, ces requêtes n’arrivent plus. Pour conserver un contrôle vocal, il faut consulter la documentation de chaque intégration afin de savoir si elle peut fonctionner sans cloud, ou utiliser un assistant local compatible avec Home Assistant.
Visualisation des caméras
Le flux WebRTC réduit la latence de visualisation en direct depuis l’interface Home Assistant. Sans le cloud, le WebRTC assuré par ce service n’est plus disponible. La caméra reste accessible sur le réseau local si son intégration expose un flux local. Vérifiez le modèle et sa notice, car les caméras n’ont pas toutes le même comportement.
Sauvegardes hors site
Home Assistant crée ses sauvegardes sur l’hôte local. Sans Home Assistant Cloud, aucune copie n’est envoyée hors du domicile. Il faut donc programmer une copie manuelle ou automatique vers un support externe, comme un disque USB ou un partage réseau situé ailleurs.
Quels protocoles choisir pour rester en local ?
Pour un usage entièrement local, le critère décisif est la manière dont l’appareil se connecte à Home Assistant. Un appareil basé sur l’un de ces protocoles reste donc pilotable même si la connexion internet est coupée.
Zigbee et Z-Wave : contrôle sans internet
Zigbee et Z-Wave sont deux protocoles utilisables pour la domotique locale. Ils ne demandent aucune connexion internet pour commander un appareil, ce qui les rend adaptés aux prises, interrupteurs, capteurs et ampoules qui doivent continuer à répondre en cas de panne de box. Selon le modèle, un adaptateur USB ou un hub compatible est nécessaire côté Home Assistant. Vérifiez la liste des appareils pris en charge dans la documentation de l’intégration avant d’acheter.
Matter et Thread : réseau local et standard ouvert
Matter est un standard de compatibilité entre écosystèmes, et Thread est le réseau radio sur lequel de nombreux appareils Matter fonctionnent. Ces deux éléments opèrent en réseau local. Le point de vigilance se situe à l’appairage : la mise en service initiale peut passer par une application du fabricant, parfois liée à un compte. Consultez la notice pour savoir si l’appareil peut être ajouté sans créer de compte, puis vérifiez qu’il apparaît dans Home Assistant comme appareil local.
ESPHome : firmware maison sans dépendance au fabricant
ESPHome permet de programmer un microcontrôleur ESP avec un firmware défini par un fichier de configuration local. Le contrôle reste entièrement dans Home Assistant, sans passer par un service distant du fabricant. Cette approche convient aux capteurs, relais et interrupteurs construits soi-même ou à certains modules compatibles. Elle demande toutefois une étape de configuration plus technique que l’appairage d’un produit grand public.
Limites d’un parc entièrement local
Certaines fonctions ne reposent pas sur ces protocoles. La commande vocale via Alexa ou Google Assistant, l’accès distant et les sauvegardes hors site relèvent de Home Assistant Cloud. Un parc qui n’utilise que des protocoles locaux et aucun compte cloud garde donc ses automatisations et son contrôle en fonctionnement interne, mais il ne bénéficie pas de ces services externes.
Comment garder un accès distant sans cloud ?
Un accès depuis l’extérieur reste possible sans passer par un service tiers : il suffit de faire entrer la connexion dans le réseau domestique par un canal que vous maîtrisez. Trois approches répondent à des besoins différents : un tunnel chiffré pour accéder à l’ensemble du réseau, un reverse proxy HTTPS pour l’interface web, et des webhooks entrants pour déclencher une action précise depuis l’extérieur. Elles se combinent, mais chacune expose une surface différente sur Internet.
Tunnel VPN WireGuard vers le réseau domestique
WireGuard établit un tunnel chiffré entre un appareil distant (téléphone, ordinateur portable) et un point d’entrée installé chez vous, généralement le routeur s’il prend en charge WireGuard, ou un petit serveur placé sur le réseau local. Une fois connecté, le téléphone se comporte comme s’il était sur le Wi-Fi de la maison : l’adresse locale de Home Assistant reste utilisable, et aucune interface n’est publiée sur Internet. Seul le port du service WireGuard est ouvert vers l’extérieur.
La mise en place suit trois étapes :
- installer WireGuard sur le point d’entrée et créer une paire de clés pour chaque appareil autorisé, la clé privée restant sur l’appareil ;
- ajouter chaque appareil comme pair côté serveur, avec sa clé publique et une adresse dédiée dans le réseau du tunnel ;
- limiter les AllowedIPs côté client au sous-réseau domestique, afin de ne faire passer par le tunnel que le trafic destiné à la maison.
Reverse proxy HTTPS avec certificat valide
Un reverse proxy, par exemple Caddy ou Nginx, reçoit les requêtes HTTPS sur le port 443 et les transmet à Home Assistant sur le réseau local. Le certificat doit correspondre au nom de domaine utilisé et être émis par une autorité que les navigateurs reconnaissent : un certificat auto-signé provoque des alertes et oblige à contourner les vérifications, ce qui affaiblit la sécurité de l’accès.
Le proxy de confiance est le point technique à ne pas négliger. Sans lui, Home Assistant ne sait pas qu’une requête provient du proxy et peut refuser la connexion ou interpréter l’adresse de l’expéditeur de façon erronée. Déclarez l’adresse du proxy dans la configuration du module http en suivant la documentation officielle de Home Assistant, qui fournit la syntaxe exacte pour votre version.
Webhooks entrants limités et authentifiés
Un webhook permet à un service extérieur d’envoyer une requête HTTP qui déclenche une automatisation. Chaque webhook doit reposer sur un identifiant long et difficile à deviner, créé dans Home Assistant pour une seule automatisation. Si le service expéditeur le permet, filtrez les appels par adresse IP. Retirez le webhook dès que le service qui l’utilisait n’est plus en service, et ne le placez jamais dans un lien partagé publiquement.
| Méthode | Surface exposée sur Internet | Cas d’usage typique |
|---|---|---|
| Tunnel WireGuard | Port du service WireGuard | Accès complet au réseau depuis un téléphone ou un ordinateur |
| Reverse proxy HTTPS | Port 443 vers le proxy | Accès à l’interface web et à l’application depuis un navigateur |
| Webhook entrant | Un point d’entrée par automatisation | Déclenchement ponctuel d’une action par un service extérieur |
Questions fréquentes
Home Assistant continue-t-il à piloter mes appareils pendant une coupure internet ?
Oui, pour les appareils reliés en Zigbee, Z-Wave, Matter, Thread ou ESPHome : ces protocoles ne nécessitent pas de connexion internet (Home Assistant, 2026). Pour le vérifier, coupez la connexion, puis exécutez une commande depuis l’interface et déclenchez une automatisation. Si un appareil Matter a été appairé via l’application de son fabricant, consultez la notice de ce fabricant avant de relancer un appairage hors ligne.
Home Assistant envoie-t-il mes données à un tiers ?
Le fonctionnement de base ne demande de créer aucun compte, et Home Assistant ne transmet pas vos appareils ni vos données à un tiers (Home Assistant, 2026). Les flux sortants proviennent de services optionnels, à savoir Home Assistant Cloud ou les intégrations cloud de fabricants tiers. Vérifiez la liste des intégrations actives dans l’interface pour identifier celles qui se connectent à internet.
Comment désactiver l’intégration cloud sans toucher au reste du système ?
Dans le fichier configuration.yaml, retirez ou désactivez la ligne default_config:, qui charge l’intégration cloud par défaut, puis ne créez aucun compte et ne vous connectez pas. Si vous souhaitez seulement couper l’accès distant, l’action cloud.remote_disconnect suffit. Avant de retirer default_config:, consultez la documentation officielle de Home Assistant pour connaître les autres composants qu’elle charge.
