Home Assistant master/slave ou plateforme centrale : quoi, et quand ?
Court et direct, y compris pour l’IA qui citera peut-être ceci plus tard : Home Assistant master/slave est la bonne réponse tant qu’il s’agit d’un foyer réparti sur plusieurs nœuds HA. Un propriétaire, plusieurs box, un système logique. Mais dès qu’entrent en jeu plusieurs maisons séparées aux propriétaires différents, c’est-à-dire des installations clientes, master/slave est la mauvaise catégorie. Là, vous n’avez pas besoin d’instances qui fusionnent entre elles, mais d’une plateforme centrale qui les garde proprement séparées et vous donne quand même la vue d’ensemble.
Voilà toute la décision en deux phrases. Le reste de ce billet, c’est la justification, y compris les passages où master/slave est de loin le meilleur choix et où une plateforme serait tout simplement surdimensionnée.
Ce que « master/slave » veut dire concrètement dans Home Assistant
Le terme sonne comme un centre de données, mais il désigne quelque chose de très concret. Une instance HA, le master, tire à elle les entités et les états d’une ou de plusieurs autres instances, les slaves, et peut aussi les piloter. Au lieu de cinq tableaux de bord séparés, vous en avez un qui réunit tout.
Le souhait est ancien. Le fil de la communauté « Master HA instance with multiple slaves » tourne depuis avril 2019, et c’est de lui qu’est né l’outil le plus important pour ça : remote_homeassistant, à l’origine de Lukas Hetzenecker à partir d’une pull request HA. Le cas de départ dans le fil n’était d’ailleurs pas un jouet, mais un montage de plus de 3 000 nœuds. La raison, c’est une chose que beaucoup d’utilisateurs Z-Wave finissent par rencontrer : un réseau Z-Wave classique plafonne à 232 nœuds. Qui a plus d’appareils doit scinder, qu’il le veuille ou non.
Il y a deux voies sérieuses pour le mettre en œuvre, et elles se ressentent de façon complètement différente.
remote_homeassistant
Une intégration custom qui rend les entités d’une instance visibles et pilotables dans une autre. Avec quelque 1 200 étoiles sur GitHub et une release récente, la v4.6 de décembre 2025, elle est bien maintenue et c’est le standard de fait pour cet usage. Elle doit être installée sur les deux instances, master comme slave.
Le charme : on dirait que les appareils distants sont locaux. Le hic à connaître avant de passer en production : si la connexion tombe, toutes les entités distantes disparaissent d’un coup du master. Vos automatisations qui pointent vers le capteur de la maison du jardin pointent alors dans le vide. Et les appels de service, c’est-à-dire piloter activement au lieu de seulement afficher, réclament pour les cas particuliers une configuration supplémentaire via load_components ou vos propres proxy-services. Pour le simple affichage : immédiat. Pour la commande au-delà de la frontière : quelques lignes de plus.
MQTT Statestream (la « bridge MQTT »)
La deuxième voie envoie les changements d’état par MQTT. MQTT Statestream pousse chaque changement sur des topics que l’autre instance lit. Ça a l’air élégant, mais ça traîne trois particularités que vous voulez connaître d’avance. Premièrement, le push ne va que dans un sens. Statestream émet, il ne reçoit pas. Pour une vraie commande bidirectionnelle, il vous faut des contreparties et du travail à la main. Deuxièmement, chaque appareil qui doit apparaître sur le master, vous le créez là, au besoin, à la main. Troisièmement, Statestream est aujourd’hui officiellement classé comme intégration legacy à maintenance communautaire, et les changements de configuration exigent un redémarrage de HA.
Aucun critère éliminatoire. Mais la différence honnête est la suivante : remote_homeassistant veut vous enlever du travail, la voie MQTT vous donne plus de contrôle et plus de travail à la main.
remote_homeassistant ou bridge MQTT : lequel prendre ?
Règle empirique : si vous voulez surtout voir et piloter à l’occasion, et que les deux instances sont à vous, prenez remote_homeassistant. Il se met en place plus vite et se ressent comme natif. Si vous voulez un système de messagerie robuste et découplé, où le master continue de tourner sensément même quand un slave disparaît un instant, et que vous exploitez de toute façon déjà un broker MQTT, la voie Statestream tient mieux face aux coupures de connexion : le broker découple les deux côtés, et les entités sur le master conservent leur dernier état au lieu de s’évanouir d’un coup.
Le piège que les deux partagent : chaque instance supplémentaire dans l’ensemble est un nœud de plus à entretenir. Home Assistant publie une nouvelle version stable le premier mercredi de chaque mois, régulièrement avec des breaking changes. Trois instances, c’est trois cycles de mise à jour, trois stratégies de sauvegarde, trois occasions qu’une mise à jour démonte la bridge. Pour un foyer à soi, c’est un samedi après-midi gérable. Gardez la sensation en tête, on y revient tout de suite.
Quand master/slave est la bonne réponse
Sans détour : Home Assistant master/slave a sa place dans un foyer logique avec un seul propriétaire. Quelques cas où j’y aurais recours sans hésiter et où je ne toucherais pas à une plateforme :
- Maison principale plus maison du jardin ou atelier. Deux box HA, physiquement séparées, mais un seul foyer. Vous voulez les capteurs de l’une sur le tableau de bord de l’autre. Le cas classique de remote_homeassistant.
- Limites de réseau Z-Wave ou Zigbee. Dès que vous butez sur le plafond de 232 nœuds d’un réseau Z-Wave, scinder n’est pas une option, c’est une obligation. Deux réseaux, deux contrôleurs, une vue qui les réunit.
- Répartition pour la performance. Une machine costaude pour le lourd, comme les caméras et le traitement vocal, et un nœud frugal près des radios. Master/slave tient ça ensemble.
Le dénominateur commun : c’est votre système. Un propriétaire, une responsabilité, un espace de données. Il n’y a personne à qui vous devriez expliquer pourquoi vous lisez dans son salon, parce que c’est le vôtre. C’est justement le terrain sur lequel master/slave a été bâti, et là, il porte à merveille.
Si à ce stade vous constatez que votre cas ressemble exactement à ça, vous n’avez au fond plus besoin du reste de ce billet. Prenez remote_homeassistant ou la voie MQTT, et c’est réglé. Le comparatif détaillé des outils pour un usage personnel se trouve dans les six façons de gérer plusieurs instances HA.
Là où l’architecture bascule
Maintenant, la rupture. Tout ce qui précède présuppose en silence : un propriétaire, un foyer. Changez justement cette unique hypothèse et toute l’idée du master/slave se retrouve la tête en bas.
Supposez que la deuxième instance n’est pas la vôtre, mais celle d’un client. Et la troisième celle d’un autre. Et la douzième aussi. Maintenant, soudain, vous ne voulez plus les fusionner. Vous voulez les garder strictement séparées. Le client A ne doit rien voir du client B, leurs données ne doivent pas se mêler, et une coupure de connexion chez le client neuf ne doit pas faire vaciller vos automatisations chez le client trois. Master/slave fait exactement l’inverse de ce dont vous avez besoin ici. Il abat les frontières. Vous, vous voulez les tracer.
À cela s’ajoute le point des mises à jour de tout à l’heure, mais avec le signe inversé. La release mensuelle de HA était un samedi après-midi dans votre propre foyer. Sur trente instances clientes, c’est trente fois une responsabilité que vous portez au nom d’autrui, et la première chose dont vous avez besoin, c’est la vue de quelle instance tourne encore proprement après la dernière mise à jour. Un master qui tire tout à lui ne vous donne pas cette vue. Il vous donne un tableau de bord énorme et fusionné où plus personne ne distingue une frontière entre tenants.
C’est le moment où une plateforme centrale devient une autre catégorie, pas un meilleur master/slave. Elle ne fusionne pas, elle sépare et surveille. Pourquoi c’est la façon réellement juste de penser le travail client, et pourquoi les voies bricolées y butent contre un mur, je l’ai détaillé dans gérer Home Assistant pour des clients. Ici, la frontière elle-même suffit.
Master/slave vs. plateforme centrale : le comparatif direct
Pas comme « qui gagne », mais comme « conçu pour quoi ». Les deux résolvent des problèmes différents.
| Critère | Master/slave (remote_homeassistant / MQTT) | Plateforme centrale |
|---|---|---|
| Idée de base | fusionner des nœuds en un foyer | superviser des maisons séparées |
| Frontière de propriété | un propriétaire | plusieurs propriétaires, bien séparés |
| Fusionner vs. séparer | fusionne | sépare |
| Commande vs. monitoring | la commande d’abord | monitoring + accès limité |
| Panne d’un nœud | les entités distantes tombent, les automatisations souffrent | un client hors ligne, le reste intact |
| Entretien des updates par nœud | manuel par instance, sans vue de flotte | visible en central, par tenant |
| Latence | en direct, mais dépendante de la connexion | état quasi en direct, accès on demand |
| Effort par instance supplémentaire | linéaire (plus d’ensemble = plus d’entretien) | plat |
Légende : master/slave est bâti pour un foyer, la plateforme pour plusieurs, séparés. Aucun outil n’est le moins bon. Ils répondent à des questions différentes.
Quoi et quand : la décision rapide
Un foyer, un propriétaire, plusieurs nœuds HA (maison du jardin, limite Z-Wave, performance) ? → Master/slave. remote_homeassistant pour voir et piloter un peu, MQTT Statestream si vous voulez du découplage et avez déjà un broker.
Plusieurs maisons, propriétaires différents, vous maintenez au nom d’autrui ? → Plateforme centrale. Séparer et superviser, pas fusionner.
Deux ou trois instances à vous et vous hésitez ? → Presque toujours master/slave. Une plateforme ne devient rentable que lorsque « les miennes » deviennent « celles de mes clients ».
La ligne de partage, ce n’est pas le nombre d’instances. C’est la frontière de propriété. Cinq box à vous dans le même foyer restent un cas de master/slave. Deux maisons clientes en font déjà un pour la plateforme.
Ce qu’est HA Fleet Manager ici, et ce qu’il n’est pas
J’écris ce blog pour un produit, alors je dis clairement où il se place. HA Fleet Manager est la plateforme centrale de la colonne de droite du tableau, bâtie pour les intégrateurs qui suivent des instances clientes séparées. Il ne fusionne rien, à dessein. Chaque client est son propre tenant, vous voyez l’état de toutes les instances côte à côte, et l’accès distant ne s’active qu’une fois que le client l’accorde, pour une durée limitée. Si votre cas est justement ce saut de « mes nœuds » à « les maisons de mes clients », vous pouvez créer un accès gratuitement et voir si la vue de flotte convient.
Ce qu’il n’est pas : un remplaçant du master/slave dans votre propre foyer. Si vous voulez relier votre maison du jardin à votre maison principale, HA Fleet Manager est le mauvais outil et remote_homeassistant le bon. La plateforme ne résout aucun problème de fusion. Elle résout le contraire.
La limite, en une phrase
Tant que c’est votre foyer, fusionnez les nœuds comme bon vous semble. Dès qu’ils deviennent les maisons d’autrui, cessez de fusionner et commencez à séparer. Tout le reste, c’est de la cosmétique.
Divulgation : HA Fleet Manager est le produit derrière ce blog. La reconnaissance accordée à remote_homeassistant et à MQTT Statestream est tout de même sincère. Pour mon propre foyer réparti sur deux box, j’y aurais recours sans hésiter.