Home Assistant : applications ou intégrations, que choisir ?

Dans Home Assistant, applications, intégrations et HACS sont souvent mis dans le même panier alors qu’ils n’agissent pas au même endroit. Comprendre cette différence change beaucoup de choses : installation plus simple, dépannage plus rapide, sauvegardes plus propres et surtout moins de services inutiles qui tournent en permanence.

Depuis Home Assistant 2026.2, les anciens « add-ons » sont officiellement appelés Apps. Le changement de nom n’est pas cosmétique : il aide justement à distinguer les logiciels autonomes des intégrations. La documentation officielle résume cette séparation de la même manière : les Apps tournent à côté de Home Assistant, alors que les intégrations relient Home Assistant aux appareils et services.

Ce guide va plus loin que la définition : on va regarder où tourne chaque brique, comment circulent les données, ce qui se passe en cas de panne et pourquoi MQTT, Zigbee2MQTT, Matter ou Frigate utilisent parfois plusieurs composants à la fois. Pour replacer tout cela dans une installation complète, vous pouvez aussi consulter notre dossier central Home Assistant.

Le schéma mental à retenir : Core au centre, les services autour

Le premier chemin est le plus simple : Home Assistant communique directement avec l’équipement grâce à une intégration. Le second ajoute un logiciel intermédiaire parce qu’une fonction doit tourner en permanence à côté de Core.

1. Une intégration : du code qui s’exécute dans Home Assistant Core

Une intégration n’est pas un petit programme séparé. Elle fait partie de Home Assistant Core, le programme Python qui gère l’état de la maison, le bus d’événements, les actions, les automatisations et l’interface avec les appareils.

Techniquement, une intégration peut :

• créer une entrée de configuration (Config Entry) ;
• enregistrer des appareils dans le Device Registry ;
• créer des entités dans l’Entity Registry : capteurs, lumières, interrupteurs, thermostats, caméras… ;
• écouter ou générer des événements ;
• exposer des actions utilisables dans les scripts et automatisations ;
• communiquer localement avec un appareil, ou à distance via une API cloud.

Les intégrations récentes sont majoritairement configurables depuis l’interface avec un config flow. Home Assistant dispose également d’une Integration Quality Scale avec des niveaux Bronze, Silver, Gold et Platinum. Ce niveau ne dit pas si un produit est « meilleur » qu’un autre ; il indique surtout jusqu’où l’intégration respecte les standards actuels du projet en matière de tests, documentation, diagnostic, configuration et robustesse.

Exemples typiques d’intégrations : ZHA, Shelly, Philips Hue, ESPHome, MQTT, Matter ou Z-Wave. Certaines parlent directement au matériel. D’autres sont des connecteurs vers un serveur distinct.

2. Une application : un conteneur autonome géré par le Supervisor

Les Apps sont disponibles sur Home Assistant OS. Sous le capot, ce sont des images de conteneur exécutées séparément de Home Assistant Core et gérées par le Supervisor. Leur cycle de vie est indépendant : installation, démarrage, arrêt, redémarrage, mise à jour, journalisation et sauvegarde.

C’est une différence importante : une application possède son propre processus, ses propres dépendances et souvent son propre stockage persistant. La documentation développeur Home Assistant prévoit notamment un volume /data pour les données persistantes et un fichier /data/options.json pour la configuration de l’application.

Une App peut aussi demander différentes capacités :

• Ingress pour afficher son interface Web à l’intérieur de Home Assistant sans exposer directement un port ;
• watchdog pour que le Supervisor vérifie son état de santé ;
• accès à l’API Home Assistant ou à l’API Supervisor ;
• accès à certains dossiers partagés, à du matériel USB ou au réseau hôte ;
• un mode de sauvegarde à chaud ou à froid.

Cette séparation apporte un gros avantage architectural : on peut redémarrer Zigbee2MQTT ou Mosquitto sans redémarrer Home Assistant Core. Mais elle ajoute aussi une brique de plus à surveiller.

3. HACS : encore une troisième catégorie

HACS (Home Assistant Community Store) est une intégration personnalisée qui facilite l’installation et la mise à jour de composants créés par la communauté. Il peut gérer des intégrations personnalisées, des cartes de tableau de bord, des thèmes et d’autres éléments non inclus dans Home Assistant.

Le détail important est celui-ci : une custom integration installée via HACS est chargée par Home Assistant Core, généralement depuis /config/custom_components/. Elle ne bénéficie donc pas de la même séparation de processus qu’une App.

Cela ne rend pas HACS « dangereux » par principe, mais le modèle de confiance est différent. Une intégration HACS exécute du code dans Core. Une App tierce exécute du code dans un conteneur séparé, avec des permissions qui peuvent toutefois être très larges selon sa configuration.

Le cas Zigbee : ZHA et Zigbee2MQTT n’ont pas du tout la même architecture

C’est l’exemple le plus parlant. Avec ZHA, Home Assistant Core gère directement le coordinateur Zigbee via l’intégration. Il n’y a pas besoin de broker MQTT ni de service Zigbee externe.

Avec Zigbee2MQTT, on découpe le système en plusieurs logiciels. Zigbee2MQTT contrôle le coordinateur et traduit les messages Zigbee en MQTT. Le broker MQTT distribue ces messages. Enfin l’intégration MQTT les transforme en appareils et entités Home Assistant.

Ce découpage explique beaucoup de pannes que l’on attribue à tort à Home Assistant. Si les entités MQTT deviennent indisponibles, Core peut très bien fonctionner : le problème peut être le coordinateur, Zigbee2MQTT, le broker, l’authentification MQTT ou simplement la connexion entre les composants.

À l’inverse, ZHA offre une chaîne plus courte. Cela ne signifie pas automatiquement qu’il est « meilleur », mais il y a moins de services indépendants à maintenir. Notre guide Zigbee avec Home Assistant détaille les différences fonctionnelles entre ZHA et Zigbee2MQTT.

MQTT : le broker n’est pas l’intégration

La confusion revient souvent : l’intégration MQTT n’est pas un broker MQTT. L’intégration est le client côté Home Assistant. Le broker est le serveur qui reçoit les publications et les redistribue aux abonnés.

Sur Home Assistant OS, l’App officielle Mosquitto Broker est la solution la plus simple. Home Assistant peut même créer automatiquement les identifiants nécessaires lors de la configuration MQTT. Sur une installation Container, on déploiera plutôt Mosquitto comme conteneur distinct.

Le chemin typique est donc :

équipement → broker MQTT → intégration MQTT → entité Home Assistant.

Cette distinction est fondamentale pour le diagnostic : si MQTT ne reçoit plus rien, supprimer puis recréer l’intégration Home Assistant n’est pas forcément la bonne première action.

Matter : l’exemple officiel d’une App qui travaille avec une intégration

Matter montre parfaitement pourquoi les deux concepts existent. L’intégration Matter expose les appareils dans Home Assistant, mais le contrôleur Matter est exécuté dans un Matter Server séparé. La documentation officielle précise que l’intégration communique avec ce serveur via WebSocket.

Sur Home Assistant OS, Matter Server est géré comme une App. Avec Home Assistant Container, il faut exécuter le serveur Matter séparément puis connecter l’intégration à ce service.

Il faut aussi séparer Matter de Thread. Matter définit la couche applicative et le modèle d’interopérabilité. Thread est un réseau IP maillé basse consommation que certains appareils Matter peuvent utiliser. Pour replacer Zigbee, Thread et Matter dans la même architecture, consultez notre dossier sur les protocoles domotiques.

Frigate, ESPHome, bases de données : trois autres architectures intéressantes

Frigate

Frigate est avant tout un logiciel autonome de vidéosurveillance et d’analyse. Il peut tourner comme App sur Home Assistant OS ou comme conteneur séparé. Home Assistant utilise ensuite une intégration pour récupérer les caméras, capteurs, événements et états utiles. C’est le même principe que Matter ou MQTT : le moteur tourne à côté, l’intégration l’expose dans Core. Notre guide Frigate + Home Assistant montre l’intérêt de cette séparation pour construire une alarme exploitable.

ESPHome

Les appareils ESPHome communiquent avec l’intégration ESPHome de Home Assistant. L’outil de compilation et de gestion ESPHome peut, lui, fonctionner séparément. L’important est de ne pas confondre l’outil qui construit ou administre le firmware et l’intégration qui fait apparaître les appareils dans Home Assistant.

MariaDB, PostgreSQL ou services annexes

Une base de données, un reverse proxy, un VPN, un bloqueur DNS ou un éditeur de fichiers sont typiquement des logiciels externes à Core. Ils peuvent être utiles au serveur Home Assistant sans créer directement d’entités. Dans ce cas, une App peut être parfaitement pertinente même sans intégration dédiée.

Home Assistant OS ou Container : le choix change l’administration

En 2026, les deux méthodes d’installation officiellement mises en avant sont Home Assistant OS et Home Assistant Container.

Fonctionnellement, une installation Container peut reproduire presque tous les services. La différence est surtout opérationnelle : sur OS, le Supervisor connaît les Apps et leur cycle de vie ; sur Container, c’est vous qui orchestrez ces services.

Performance : une App consomme des ressources, une intégration partage celles de Core

Une App est un processus séparé. Elle consomme donc sa propre mémoire, son CPU, ses entrées/sorties disque et son trafic réseau. Le Supervisor peut exposer des statistiques d’usage pour chaque App.

Une intégration s’exécute dans le processus Home Assistant Core et partage ses ressources. Un appel réseau trop lent, une bibliothèque défaillante ou une intégration personnalisée mal conçue peut donc avoir un impact plus direct sur Core qu’un service externe correctement isolé. Home Assistant comporte évidemment de nombreux garde-fous, mais la frontière de processus reste importante.

Pour une petite installation, le réflexe utile est simple : ne pas ajouter un service juste parce qu’il existe. Un broker MQTT, une base externe ou Zigbee2MQTT doivent répondre à un besoin réel. Chaque brique apporte des fonctions, mais aussi des mises à jour, des logs, des dépendances et un point de panne supplémentaire.

Fiabilité : penser en « domaine de panne »

Cette manière de raisonner évite les dépannages au hasard. Quand une entité devient indisponible, demandez-vous d’abord où se trouve le premier maillon qui ne répond plus.

Sécurité : Apps et HACS n’ont pas le même modèle de risque

Home Assistant applique un système de permissions aux Apps. Par défaut, les Apps utilisent un mode de protection. Certaines peuvent demander des accès supplémentaires : réseau hôte, périphérique USB, dossiers, API Supervisor ou API Home Assistant.

Une App tierce qui demande des permissions très larges doit donc être traitée comme n’importe quel logiciel serveur : source connue, dépôt maintenu, documentation claire et mises à jour suivies.

Ingress est également intéressant du point de vue sécurité. Lorsqu’une App le prend en charge, son interface peut être ouverte à travers Home Assistant avec l’authentification déjà gérée. Dans beaucoup de cas, il n’est alors pas nécessaire d’exposer manuellement son port Web sur Internet.

Pour HACS, le point de vigilance est différent : une custom integration s’exécute dans Core. Avant d’installer un composant communautaire critique, regardez l’activité du dépôt, les versions récentes, les issues ouvertes et les éventuelles régressions après mise à jour de Home Assistant.

Sauvegardes : ne sauvegardez pas seulement Home Assistant, sauvegardez la chaîne

Sur Home Assistant OS, les sauvegardes peuvent inclure les Apps sélectionnées et leurs données, en plus des répertoires de l’instance. Certaines Apps peuvent même déclarer un mode de sauvegarde hot ou cold, afin d’être arrêtées pendant la sauvegarde si leur cohérence l’exige.

Sur Home Assistant Container, la situation est différente. Si Mosquitto, Zigbee2MQTT ou Frigate tournent dans d’autres conteneurs, leurs volumes sont hors de Home Assistant. Une sauvegarde Home Assistant ne remplace donc pas la sauvegarde de toute votre stack Docker.

Pour une installation sérieuse, notez au minimum :

• où sont stockées les données persistantes de chaque service ;
• quels ports ou alias réseau sont utilisés ;
• quels périphériques USB sont affectés ;
• quels secrets et certificats sont nécessaires ;
• dans quel ordre les services doivent être restaurés.

Dépannage : la méthode rapide selon le type de composant

Le meilleur réflexe est de ne pas tout redémarrer immédiatement. Un redémarrage global peut masquer le composant fautif. Vérifiez d’abord l’état et les logs de chaque maillon.

Comment choisir : notre arbre de décision

Les erreurs que l’on voit le plus souvent

• Installer une App pour chaque équipement alors qu’une intégration directe suffit.
• Confondre Mosquitto et MQTT : l’un est le broker, l’autre l’intégration.
• Confondre Zigbee2MQTT et ZHA : le premier est un logiciel séparé, le second une intégration dans Core.
• Penser qu’une App crée forcément des entités : elle fournit souvent seulement un service que l’intégration exploitera ensuite.
• Traiter HACS comme un App Store officiel : les composants HACS sont communautaires et ne suivent pas le même processus de validation que les intégrations Core.
• Exposer des ports inutilement alors qu’Ingress peut suffire.
• Sauvegarder Home Assistant mais pas les services externes sur une architecture Container.

FAQ technique

Une App Home Assistant peut-elle créer directement des entités ?

Elle peut produire les données ou fournir l’API nécessaires, mais dans l’architecture normale c’est une intégration Home Assistant qui transforme ces informations en appareils et entités exploitables dans Core.

Peut-on utiliser Zigbee2MQTT sans l’App Zigbee2MQTT ?

Oui. Zigbee2MQTT peut tourner sur une autre machine ou dans un autre conteneur. Home Assistant n’a besoin que d’un accès au broker MQTT et de l’intégration MQTT.

Home Assistant Container peut-il utiliser Matter ?

Oui, mais il ne dispose pas du système d’Apps. Il faut donc exécuter Matter Server séparément et connecter l’intégration Matter à ce serveur.

Une intégration HACS est-elle isolée comme une App ?

Non. Une custom integration HACS est chargée dans Home Assistant Core. C’est précisément pour cela qu’il faut être attentif à sa qualité et à sa compatibilité.

Pourquoi certaines Apps ont-elles besoin d’une intégration et d’autres non ?

Parce qu’une App peut simplement fournir un service auxiliaire : éditeur de fichiers, Samba, VPN ou DNS. Si Home Assistant n’a pas besoin de transformer ce service en appareils ou entités, aucune intégration dédiée n’est nécessaire.

App officielle ou dépôt tiers : que vérifier ?

Pour un dépôt tiers, vérifiez la source, les permissions demandées, la fréquence des mises à jour, la compatibilité avec votre architecture et la politique de sauvegarde. Home Assistant rappelle lui-même que la qualité et la sécurité des Apps tierces ne peuvent pas être garanties.

En pratique : quelle architecture choisir en 2026 ?

Pour la majorité des utilisateurs, la meilleure approche reste de commencer simple. Si une intégration officielle sait gérer correctement votre matériel, utilisez-la. Ajoutez une App lorsqu’un vrai logiciel intermédiaire est nécessaire. Utilisez HACS lorsqu’une fonction communautaire apporte quelque chose que le catalogue officiel ne propose pas.

La question n’est donc pas « application ou intégration ? » comme s’il fallait choisir un camp. La bonne question est : où doit tourner chaque fonction, et comment les données doivent-elles arriver jusqu’à Home Assistant Core ?

Une fois ce modèle compris, MQTT, Matter, Zigbee2MQTT, Frigate et les services externes deviennent beaucoup plus faciles à installer — et surtout à dépanner.