Ce qui fonctionne encore quand internet tombe

Nous avons débranché le câble WAN pendant soixante-douze heures et journalisé le comportement de chaque appareil de la maison. Les résultats se séparent nettement, et pas selon les lignes que suggère le marketing.

Mis à jour le 2026-08-25 8 min de lecture Sujet maison connectée sans internet
La face arrière d'un routeur Wi-Fi, le boîtier dont le câble WAN a été débranché pour le test.
TP-Link Archer A6 Router (v4) - Back Side.jpg · auteur : Paowee · CC BY-SA 4.0 · Wikimedia Commons
En bref · vérifié le 2026-08-25

Sur un test de 72 heures câble WAN débranché, dix-neuf appareils sur vingt-trois se sont comportés à l'identique. Les quatre qui ont lâché sont les quatre exigeant un compte fabricant. « Fonctionne hors ligne » a trois sens distincts : la commande locale répond, les automatisations se déclenchent, et l'application atteint l'appareil sur le réseau local.

Ce qu'il faut retenir
  1. Trois sens, pas un. Un appareil peut réussir la commande locale et rater les deux autres.
  2. Les assistants vocaux tombent complètement, la reconnaissance vocale étant un service cloud.
  3. Les prises cloud se figent dans leur dernier état au lieu de se mettre en sécurité.
  4. Les automatisations météo s'arrêtent en silence. Donnez à chacune une branche de repli.

Le protocole du test

Le réseau local est resté debout : switch, point d'accès, hub, tous alimentés et communicants. Seul le lien WAN a été débranché, ce qui correspond à une vraie panne. Soixante-douze heures, avec une vérification scriptée toutes les quinze minutes sur chaque entité de la maison.

Une précision, parce qu'elle est à l'origine de la plupart des confusions en ligne. « Fonctionne hors ligne » a trois sens distincts et les fabricants emploient celui qui les arrange : l'appareil répond à une commande locale, les automatisations se déclenchent encore, et l'application du téléphone marche encore. Un appareil peut réussir le premier et rater les deux autres.

Résultats par appareil

Commande locale le bouton marche encore Automatisations les règles se déclenchent App sur le réseau le téléphone l'atteint appareil Capteurs Zigbee Serrure Thread Hub local Caméra Wi-Fi (RTSP) Assistant vocal Prise cloud Aspirateur robot Applications TV appareils qui passent 4 / 8 4 / 7 4 / 8 fonctionne partiel échoue sans objet
Trois colonnes parce que les fabricants emploient une seule formule pour trois promesses différentes. La ligne surlignée est celle qui compte : l'aspirateur robot répond à son propre bouton et à rien d'autre, donc une fiche produit peut affirmer sans mentir qu'il fonctionne hors ligne alors que toutes les automatisations bâties autour se sont arrêtées.
AppareilCommande localeAutomatisationsApp en LANRemarques
Capteurs ZigbeeouiouiouiAucun changement de comportement
Serrure ThreadouiouiouiImpossible de créer des codes invités
Hub localouiouiouiPerte des conditions météo
Caméra Wi-Fi (RTSP)ouiouiouiEnregistrement local poursuivi
Assistant vocalnonnonnonA refusé toutes les commandes
Prise cloudnonnonnonRelais figé dans son dernier état
Aspirateur robotpartielnonnonBouton de l'appareil seulement
Applications TVnons.o.nonDalle et HDMI intacts
Le résultat principal

Dix-neuf appareils sur vingt-trois se sont comportés à l'identique sans internet. Les quatre qui ont lâché sont les quatre qui exigent un compte fabricant pour fonctionner, c'est-à-dire exactement les quatre qui échouent au test d'achat de notre guide sur la durabilité.

Les défaillances qu'il faut connaître

Les assistants vocaux tombent complètement

La reconnaissance vocale se fait dans le cloud, donc une enceinte hors ligne ne peut pas allumer une lampe située dans la même pièce, reliée au même hub. C'est ce qui surprend le plus dans tout le test. La commande vocale locale existe, mais c'est une construction volontaire, pas un réglage par défaut.

Les prises cloud se figent au lieu de se mettre en sécurité

La prise cloud ne s'est pas éteinte, elle est restée dans l'état qu'elle avait au moment de la coupure. S'il s'agit d'un chauffage d'appoint, le mode de défaillance compte. Tout appareil qui commande quelque chose ayant une dimension de sécurité devrait être local, pour cette seule raison.

Les automatisations météo s'arrêtent en silence

C'est la plus subtile. Notre automatisation de volets utilisait une heure de coucher du soleil et une prévision de couverture nuageuse. Sans prévision, la condition n'a jamais été vraie, donc les volets ne se sont simplement jamais fermés et aucune erreur n'a été journalisée. Toute automatisation qui dépend de données externes a besoin d'une branche de repli, pas seulement d'une condition.

# fragile si prevision.nuages < 30 et soleil.elevation < 10 : volets.fermer() # survit à une panne si soleil.elevation < 10 : si prevision.disponible et prevision.nuages >= 30 : pass # soirée lumineuse, on laisse ouvert sinon : volets.fermer() # pas de données : on retombe sur l'heure

Construire pour la panne

  1. Gardez le moteur d'automatisation sur place. Un hub qui évalue ses règles en local est la décision unique qui détermine le résultat de ce test.
  2. Privilégiez Zigbee, Z-Wave et Thread pour tout ce qui compte. Serrures, sondes de fuite, chauffage. Leurs transports ne passent jamais par internet.
  3. Donnez un repli à chaque automatisation qui dépend de données externes. Élévation du soleil, heure locale et dernier état connu restent disponibles hors ligne.
  4. Placez une commande physique sur chaque chemin critique. Une télécommande murale sur pile liée directement à un groupe Zigbee fonctionne même hub éteint.
  5. Testez-le volontairement. Débranchez le WAN un samedi matin, pas pendant une tempête. Vingt minutes vous apprennent l'essentiel de ce que révèle un test de 72 heures.
Le piège qui attrape tout le monde

Le Wi-Fi de votre téléphone. Si le téléphone bascule sur les données mobiles quand le Wi-Fi n'a plus internet, l'application locale n'atteint plus le hub local, et vous en concluez que le hub est tombé. Désactivez « basculer automatiquement vers les données mobiles » avant toute conclusion.

Un Raspberry Pi 4 dans un boîtier noir posé sur un petit switch réseau avec des câbles Ethernet jaunes.
Un Raspberry Pi 4 relié à un switch, un contrôleur local courant. Les automatisations qui y tournent se passent d'internet, mais le téléphone doit rester sur le même Wi-Fi pour l'atteindre.Raspberry Pi 4 on a network switch.jpg · auteur : RAIL P (RAIL.PHOTOGRAPHY) · CC0 · Wikimedia Commons

Les chiffres de ce guide sont disponibles en données ouvertes (CSV et JSON, CC BY 4.0).

Questions fréquentes

Mes éclairages connectés fonctionnent-ils sans internet ?

Les ampoules Zigbee, Z-Wave et Thread oui, à condition que le hub soit local. Les ampoules Wi-Fi d'un fabricant cloud-only, généralement non, même si l'ampoule et votre téléphone sont sur le même réseau.

Peut-on utiliser la commande vocale hors ligne ?

Pas avec une enceinte Alexa ou Google standard. Les chaînes vocales locales exécutées sur le hub fonctionnent hors ligne, au prix d'un vocabulaire plus restreint et de plus de configuration.

Que devient ma serrure connectée pendant une panne ?

Une serrure Zigbee, Z-Wave ou Thread continue de fonctionner au clavier et sur toute programmation locale. Ce qui s'arrête, c'est l'ouverture à distance et la création de nouveaux codes invités, qui ont besoin d'internet.

Un secours 4G sur la box règle-t-il le problème ?

Il le règle entièrement, pour les appareils cloud, et cela vaut la peine d'en avoir un. Mais c'est un coût mensuel qui existe pour contourner un choix de conception. Les appareils locaux n'ont besoin d'aucun lien de secours.

À lire ensuite