Illustration générée par IA — visuel conceptuel.
Pourquoi un changement de box domotique « casse » souvent des usages
Remplacer une box domotique, un contrôleur Zigbee/Thread ou un hub Wi‑Fi ne se résume pas à brancher un nouveau boîtier. Le risque, le jour de la bascule, est presque toujours lié à l’environnement autour du hub :
- scènes / routines non exportables, ou stockées dans un cloud ;
- comptes et intégrations (assistants vocaux, services tiers) liés à l’ancien appareil ;
- réseau radio (Zigbee, Thread…) difficile à migrer sans ré-appairage ;
- accès admin (mots de passe, double authentification) introuvables ;
- absence de sauvegarde restaurable (le fichier existe, mais la restauration échoue).
Ce guide propose une méthode orientée continuité de service : inventaire → sécurisation des accès → sauvegardes → migration en parallèle → bascule → plan de retour arrière → sortie propre de l’ancien hub.
Pour une vision plus globale des approches Smart Home (et de leurs implications de maintenance), vous pouvez aussi parcourir Domotique / Smart Home.
Étape 1 — Choisir une stratégie réaliste : restaurer, migrer, ou reconstruire
Avant tout changement, décidez comment vous voulez « transporter » votre système :
Option A : restauration / migration (quand l’écosystème le permet)
Objectif : conserver le maximum (config, appareils, scènes, automatisations, historiques) en déplaçant le “cerveau” vers un nouvel équipement.
C’est souvent la meilleure option lorsqu’un éditeur fournit une fonction officielle de remplacement/migration. Par exemple, l’app SmartThings documente un processus Replace Hub pour remplacer un hub et transférer des appareils et des routines locales (si votre modèle et votre version d’app le supportent). Voir la documentation SmartThings : SmartThings Enabled Hubs (section Replace Hub).
Option B : reconstruction contrôlée (souvent plus sûre que prévu)
Objectif : repartir sur une base propre, mais en migrant fonction par fonction tout en gardant l’ancien système opérationnel (filet de sécurité).
Cette approche est souvent pertinente quand :
- le système actuel dépend fortement d’un cloud et exporte mal ;
- vous suspectez une configuration « bricolée » au fil des années ;
- vous souhaitez simplifier les scènes/routines (moins, mais mieux testées).
Étape 2 — Faire un inventaire “anti-surprise” (le document le plus utile)
Le meilleur moyen d’éviter une panne « le jour J » est de faire, avant toute manipulation, un inventaire simple mais complet. L’objectif n’est pas d’écrire un roman : c’est de ne pas découvrir trop tard un compte oublié, une intégration cloud critique, ou un pont indispensable.
Inventaire minimum (à tenir sur une page)
- Hub/box actuel : modèle exact, application utilisée, et ce que vous savez de son mode de stockage (local / cloud).
- Radios et protocoles : Zigbee, Thread, Wi‑Fi, Bluetooth, etc.
- Ponts/bridges séparés : éclairage (ex. Hue), volets, chauffage, portail, etc.
- Comptes et accès : e-mails, numéros de téléphone, méthode de récupération, double authentification.
- Automatismes critiques : éclairage extérieur, scénarios nuit, gestion d’absence, notifications fuites, etc.
- Dépendances réseau : IP fixes/réservations DHCP, DNS interne si vous en avez, contrôleur Wi‑Fi, VPN éventuel.
Sur la partie réseau domestique (sauvegardes, restauration, dépendances), l’article Réseau informatique : quelles sauvegardes prévoir pour redémarrer après une panne ? apporte une méthode très complémentaire.
Étape 3 — Sécuriser vos accès (sinon la migration peut être bloquée)
Une migration domotique échoue rarement pour des raisons “radio” le premier jour : elle échoue parce qu’un accès est manquant.
Check rapide “accès et récupération”
- Vous pouvez vous connecter à tous les comptes liés (même si vous ne les utilisez pas souvent).
- Les moyens de récupération (mail / téléphone) sont à jour.
- Vous savez où se trouvent les codes de secours (si 2FA).
- Vous avez un accès local de secours quand il existe (interface web locale, accès console/SSH, etc.).
Point d’attention (exemple documenté Home Assistant) : les sauvegardes peuvent être chiffrées et, dans ce cas, la restauration nécessite la clé. La documentation Home Assistant décrit un “backup emergency kit” à conserver hors du système : Backup emergency kit et Backups.
Étape 4 — Faire des sauvegardes “restaurables” (et le prouver avant le jour J)
Règle pratique : une sauvegarde n’existe que si vous savez la restaurer dans un contexte de panne (nouveau matériel, reset, etc.).
Ce que votre plan de sauvegarde doit couvrir
- Le système : configuration et automatisations.
- Les dépendances : bridges/ponts, clés/jetons, secrets si votre système en utilise.
- Le stockage hors de l’appareil : copie sur PC/NAS/stockage externe (éviter le « tout est sur la box »).
- Les clés nécessaires (si chiffrement).
- Une restauration de test, si possible (VM, matériel secondaire, ou procédure d’onboarding).
Exemple concret (Home Assistant) : restauration pendant l’onboarding
La documentation Home Assistant décrit une restauration possible pendant l’onboarding, utile pour migrer vers un nouvel appareil ou après un reset, et mentionne qu’une restauration d’une installation importante peut prendre du temps ; elle recommande de ne pas couper l’alimentation pendant l’opération : Backups (Restoring a backup).
Étape 5 — Cas critique : Zigbee (coordinateur, réseau, ré-appairage)
Quand une maison est fortement Zigbee, le changement de hub devient souvent un projet à part entière. Le point bloquant n’est pas seulement l’application : c’est la capacité à migrer (ou à reconstruire) le réseau Zigbee sans perdre des heures en ré-appairage improvisé.
Ce qu’il faut comprendre avant de toucher au coordinateur
La documentation Zigbee2MQTT (utile même si vous n’utilisez pas Zigbee2MQTT) explique notamment :
- qu’une partie des informations de réseau vit dans le coordinateur et une autre dans les fichiers du système ;
- que la migration vers un autre adaptateur nécessite des capacités de sauvegarde/restauration officiellement implémentées pour certaines familles d’adaptateurs ;
- que certains changements (clé réseau, PAN ID, parfois canal) peuvent imposer de ré-appairer ;
- que des appareils ayant déjà été reliés à une autre implémentation Zigbee peuvent nécessiter un reset usine pour rejoindre le nouveau réseau.
Sources Zigbee2MQTT : FAQ et Supported Adapters.
Méthode de migration Zigbee (générique, sans dépendre d’une marque)
- Décidez : voulez-vous conserver le réseau Zigbee existant (idéal quand c’est possible) ou repartir sur un nouveau réseau (plus simple conceptuellement, mais souvent synonyme de ré-appairage) ?
- Préparez une fenêtre où vous acceptez que certains capteurs/actionneurs soient temporairement indisponibles (réveils lents, ré-appairage, reset usine).
- Documentez les exceptions : certains périphériques sont plus sensibles (serrures, sécurité, actionneurs critiques).
- Prévoyez un plan B : une procédure de reset usine par type d’appareil (à récupérer dans les manuels fabricants), au cas où le périphérique refuse le nouveau réseau.
Si vous utilisez Zigbee2MQTT : sauvegarde via MQTT
Zigbee2MQTT documente une commande MQTT (zigbee2mqtt/bridge/request/backup) qui crée une sauvegarde du dossier data (hors logs). Documentation Zigbee2MQTT (source projet) : MQTT topics and messages.
Étape 6 — Traquer les dépendances cloud (le piège le plus fréquent)
Le jour où vous retirez l’ancienne box, vous découvrez parfois que :
- les automatisations vivaient dans le cloud (et non localement) ;
- l’accès à distance dépendait d’un service spécifique ;
- des associations (bridge ↔ compte) n’ont pas été “libérées” ;
- une migration existe… mais uniquement si vous la lancez avant le reset.
Règle de décision simple
Si un fabricant propose une fonction officielle de migration/remplacement dans l’application, utilisez-la avant tout reset usine.
Exemple (SmartThings) : processus Replace Hub documenté dans l’app SmartThings : SmartThings Enabled Hubs.
Exemple (Philips Hue) : la page officielle sur le reset du Hue Bridge recommande de retirer le Bridge depuis l’app avant reset afin qu’il ne reste pas connecté au compte Hue. La même page mentionne une migration (dans l’app) dans le cas d’un upgrade vers Hue Bridge Pro. Source : How to reset a Hue Bridge.
Étape 7 — Plan de bascule : J‑1 / Jour J / J+1
Même dans une maison, la bascule se gère comme un mini-projet : préparation, exécution, stabilisation.
J‑1 (pré-bascule)
- Geler les changements (ne plus renommer pièces, ne plus modifier scènes).
- Faire une dernière sauvegarde (et la copier hors de l’appareil).
- Préparer une alimentation stable pour le cœur du système (box/routeur/switch) si votre environnement est sensible aux coupures (un onduleur peut éviter une coupure au mauvais moment).
- Préparer le retour arrière : ancien hub accessible, alimentations/câbles prêts.
Jour J (bascule)
- Capturer un état de référence : captures d’écran (appareils, scènes, pièces) et notes rapides.
- Éviter les conflits : ne pas laisser deux systèmes “piloter” la même fonction critique en parallèle sans l’avoir planifié.
- Migrer/restaurer, ou reconstruire par blocs :
- priorité aux fonctions “vivables” (éclairage principal, accès essentiels, volets, chauffage/climatisation selon votre usage) ;
- ensuite le confort (scènes avancées, multimédia) ;
- ensuite le “nice to have”.
- Faire des tests de modes dégradés (voir la checklist ci-dessous).
J+1 (stabilisation)
- Surveiller les capteurs sur batterie (réveils lents, états qui se resynchronisent).
- Documenter ce qui a changé (nouveaux mots de passe, nouvelle méthode d’accès local, nouvelles IP réservées).
- Mettre à jour un mini “mémo” propriétaire (une page) : quoi faire si l’appli ne répond plus.
Étape 8 — Vérifications “modes dégradés” (table de test rapide)
Objectif : détecter les dépendances cachées. Ces tests sont simples, mais très révélateurs.
| Test | Ce que vous cherchez à valider | Limite / interprétation |
|---|---|---|
| Couper Internet (routeur up) | Les fonctions essentielles continuent (au moins en local) et l’app locale fonctionne si elle est prévue pour | Certains systèmes cloud-first perdront des fonctions : notez précisément lesquelles |
| Redémarrer le routeur | Le hub et les bridges reviennent correctement, sans intervention manuelle | Si les IP changent, cela peut casser des intégrations : notez les dépendances |
| Redémarrer le hub | La maison revient dans un état cohérent (pas d’éclairage bloqué, pas de scène “en boucle”) | Après reboot, certains capteurs sur batterie peuvent mettre du temps à remonter |
| Tester une commande locale “physique” | En cas de panne domotique, les commandes murales / télécommandes critiques restent utilisables | Ce point dépend de votre architecture (domotique filaire vs sans fil, hybridation, etc.) |
Pour situer la logique « fiabilité » et pourquoi une architecture hybride est souvent pertinente, voir aussi Domotique filaire vs sans fil : le guide pour un bâtiment fiable.
Étape 9 — Préparer un retour arrière (même si vous ne l’utilisez pas)
Un plan de retour arrière n’est pas du pessimisme : c’est ce qui permet d’oser une bascule propre, sans improvisation.
Retour arrière minimal (à écrire en 5 lignes)
- Comment rebrancher l’ancien hub (alimentation, réseau, emplacement).
- Ce qui doit être remis “comme avant” côté réseau (SSID Wi‑Fi si vous l’avez changé, réservation DHCP, etc.).
- Comment désactiver le nouveau système pour éviter les conflits (si nécessaire).
- Qui contacter si un équipement critique ne revient pas (installateur, support fabricant, etc.).
Étape 10 — Sortie propre de l’ancien hub (compte, reset, revente)
La migration ne se termine pas quand “ça marche”. Elle se termine quand l’ancien équipement ne crée plus :
- de dépendance (bridge encore lié à un compte) ;
- de risque (accès distant encore actif) ;
- de confusion (deux systèmes en parallèle non documentés).
Bon réflexe : dissocier avant de réinitialiser
Quand le fabricant le recommande, retirez/désassociez d’abord l’équipement depuis l’application (compte), puis lancez le reset usine.
Exemple (Philips Hue) : la page officielle explique qu’avant reset physique du Hue Bridge, il est recommandé de retirer le Bridge depuis l’app pour éviter qu’il reste associé au compte. Source : How to reset a Hue Bridge.
Checklist finale (à copier-coller avant votre jour J)
- [ ] Inventaire : hubs/bridges, protocoles, scènes/routines, intégrations
- [ ] Accès : comptes, récupération, 2FA, droits admin
- [ ] Sauvegarde : complète, copiée hors de la box, restaurable
- [ ] Clés : kit/clé de restauration si chiffrement (quand applicable)
- [ ] Zigbee : stratégie (conserver réseau vs ré-appairage), plan B (reset usine)
- [ ] Bascule : J‑1 / Jour J / J+1 + plan de retour arrière
- [ ] Tests : sans Internet, reboot routeur, reboot hub, commande locale
- [ ] Sortie de parc : désassociation compte + reset usine (si revente/don)
Limites de ce guide (important)
- Il n’existe pas de procédure universelle : chaque fabricant a ses règles (migration possible ou non, export/import, dépendances cloud, etc.). Dès qu’une fonction officielle de remplacement/migration existe, elle prime sur une méthode générique.
- Thread / Matter : les comportements de migration varient fortement selon l’écosystème et les équipements (border router, contrôleur, fabricants d’accessoires). Sans documentation officielle ciblée à votre cas, il est préférable d’éviter les promesses de “migration sans ré-appairage”.
- Écosystèmes spécifiques (Tuya/Smart Life, Aqara, Somfy, Netatmo…) : selon les marques, certaines données (scènes, associations, accès à distance) peuvent être plus ou moins liées à un compte ou à un hub donné. Pour un résultat fiable, il faut vérifier la procédure officielle de votre couple (ancien modèle → nouveau modèle).
Si vous le souhaitez, vous pouvez nous donner la liste précise de vos hubs/bridges actuels et de l’écosystème visé : nous pourrons vous aider à construire une séquence de migration adaptée (et à identifier, en amont, les points non migrables).
