ha-mcp : exposer Home Assistant à un assistant IA sans jeton ni proxy

Le problème concret : un assistant qui parle de votre maison sans y accéder

Un assistant IA connecté à Home Assistant se heurte vite à une limite : il connaît la syntaxe YAML et les concepts d'automatisation, mais il ne voit ni l'état de vos entités ni la liste de vos services. Il produit donc des automatisations plausibles qui référencent des entités inexistantes. Le projet ha-mcp répond à ce manque en exposant Home Assistant via le Model Context Protocol, le format d'outillage utilisé par plusieurs clients IA. Le README annonce 87 outils, regroupés sous les thèmes du contrôle d'appareils, de l'interrogation d'états, de l'exécution de services et de la gestion des automatisations. Le public visé est donc l'utilisateur de Home Assistant qui pilote déjà son instance en YAML ou via l'interface, et qui veut déléguer une partie de cette manipulation à un modèle. Ce n'est pas un outil pour quelqu'un qui n'a pas d'instance Home Assistant en fonctionnement, ni pour un usage de simple consultation : le serveur peut appeler des services, ce qui signifie agir sur le matériel.

Ce qui distingue l'installation in-process des autres modes

Le README décrit quatre façons de faire tourner le serveur : composant personnalisé via HACS, application (add-on), Docker ou uvx/PyPI en stdio, et une variante locale. La méthode recommandée est le composant personnalisé, qui s'exécute dans le processus de Home Assistant. Deux conséquences pratiques en découlent. D'abord, aucune gestion de jeton d'accès longue durée n'est nécessaire, puisque le serveur hérite du contexte de l'instance. Ensuite, la compatibilité annoncée couvre Home Assistant OS, Supervised, Container et Core, avec une parité fonctionnelle présentée comme complète. L'application add-on, elle, n'est disponible que sur OS et Supervised, et le README la classe en second choix. Cette hiérarchie est cohérente : l'add-on ajoute un conteneur séparé et un chemin réseau, là où le composant se contente d'un redémarrage. Le revers est que le composant modifie votre répertoire config/custom_components/ et devient une dépendance de votre installation, avec les contraintes de mise à jour que cela implique.

Le flux de connexion : webhook, port direct et panneau latéral

Une fois l'entrée créée, le serveur démarre et publie une URL de connexion. L'écran Configure de l'entrée l'affiche, et le README indique qu'elle est aussi écrite dans le journal de Home Assistant, avec une notification qui signale le démarrage. Pour un client distant, l'URL prend la forme https://<votre-domaine-ha>/api/webhook/<webhook-id>, en passant par Nabu Casa ou par un reverse proxy déjà pointé sur Home Assistant. En local, l'adresse est http://<hote-ha>:8123/api/webhook/<webhook-id>. Le README mentionne également un accès direct sur le réseau local, à l'adresse http://<ip-ha>:9584/private_<aleatoire>, pour les clients situés sur le meme reseau. Deux réglages structurent ensuite l'exposition. L'option Remote access via webhook, désactivable, supprime tout enregistrement de webhook tout en conservant le port direct et le panneau latéral. L'option Webhook authentication, réglée sur ha_auth, remplace le secret contenu dans l'URL par une authentification avec un compte Home Assistant. Ce second point mérite attention : par défaut, c'est l'URL elle-même qui fait office de credential, ce qui est un choix de conception simple mais qui reporte toute la sécurité sur la confidentialité de la chaîne.

Le panneau HA-MCP et les outils désactivés par défaut

Pendant que le serveur tourne, un panneau HA-MCP réservé aux administrateurs apparaît dans la barre latérale de Home Assistant. Le README lui attribue la gestion des outils, des indicateurs de fonctionnalité, des sauvegardes et des thèmes. C'est là que se règle la surface réelle exposée à l'assistant, et c'est un point à ne pas négliger : 87 outils annoncés ne signifie pas 87 outils actifs. Les outils d'édition de fichiers et de YAML sont présentés comme opt-in, désactivés par défaut. Leur activation nécessite une seconde entrée d'intégration, HA-MCP File & YAML Tools, décrite comme compatible avec tous les types de serveur. Un changement cassant est signalé en tête du README : depuis la version 7.3.0, l'outil ha_config_set_yaml a été déplacé vers la documentation beta. Autrement dit, la capacité d'écriture directe dans la configuration a été retirée du chemin principal. C'est un choix prudent de la part des mainteneurs, mais il faut le savoir avant de concevoir un flux de travail qui en dépendrait.

Une seule méthode d'installation par client, et pourquoi c'est une contrainte réelle

Le README insiste en encadré : configurez exactement une méthode d'installation par client. Le serveur in-process est décrit comme une installation complète et autonome, qui remplace l'application, Docker et uvx/PyPI. La consigne est explicite : n'en exécutez qu'une, ne faites pas tourner le serveur in-process à côté d'une autre installation. Cette règle n'est pas cosmétique. Deux serveurs exposant les mêmes outils au même client produisent des appels ambigus, et les mainteneurs ont visiblement préféré imposer la contrainte plutôt que de gérer la désambiguïsation. Pour un utilisateur qui a déjà déployé la version Docker, la migration vers le composant implique donc de démonter l'ancien déploiement, pas de le laisser en veille. C'est le genre de détail qui se paie en heures de débogage si on le découvre après coup.

La limite la plus sérieuse : un composant tiers avec accès aux services

Le serveur peut exécuter des services Home Assistant. Cela veut dire qu'un assistant IA connecté peut, selon les outils activés, changer l'état d'appareils physiques. Le README ne décrit ni mécanisme d'approbation par appel, ni journal d'audit des actions déclenchées par le modèle. La seule barrière documentée est l'authentification webhook optionnelle et la sélection des outils dans le panneau. C'est mince pour un composant qui vit dans le processus de Home Assistant. Deuxième limite, moins visible : le projet publie des builds de développement à un rythme élevé. Les trois versions récentes listées sont toutes des v8.4.3.dev, datées du meme jour, à quelques heures d'intervalle. Un utilisateur qui suit la branche master s'expose à un rythme de changement qui n'a rien à voir avec celui d'une intégration officielle. Enfin, le projet est explicitement non officiel, ce qui veut dire que le support vient de la communauté du dépôt et non de l'équipe Home Assistant.

L'alternative : les automatisations natives et l'API REST appelée à la main

L'alternative la plus directe n'est pas un autre serveur MCP, c'est l'API REST de Home Assistant. Elle expose les états et permet d'appeler des services avec un jeton longue durée, et elle existe sans rien installer dans config/custom_components/. La différence d'approche est nette : avec l'API REST, c'est vous qui écrivez l'appel, choisissez l'entité et validez le résultat. Avec ha-mcp, c'est le modèle qui choisit l'outil et les paramètres à partir d'une phrase. Le premier demande de connaître les identifiants d'entités et la structure des services, le second accepte une formulation vague et se charge de la traduction. Le compromis est asymétrique : l'API REST vous laisse un contrôle total et un journal d'appels que vous maîtrisez, tandis que ha-mcp déplace la décision vers le modèle. Si votre besoin se limite à lire des états pour un tableau de bord, l'API REST suffit et évite d'installer un composant supplémentaire. Si vous voulez qu'un assistant compose et modifie des automatisations en langage naturel, l'écart de confort devient réel.

Licence, maintenance et ce qu'il faut vérifier avant d'adopter

Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation et la modification, y compris dans un contexte commercial, à condition de conserver la notice de licence. Ce n'est pas un avis juridique : si vous redistribuez le composant ou l'intégrez à un produit, faites relire les termes par qui de droit. Sur la maintenance, le dépôt n'est pas archivé et la date du dernier push indiquée est le 9 septembre 2026, avec des publications de développement le meme jour. Le README pointe vers une documentation d'installation complète et un assistant de configuration par client sur le site du projet, ainsi qu'une documentation dédiée au serveur in-process et une page beta pour les outils déplacés. La contrepartie de cette activité est l'absence de branche stable évidente dans les éléments fournis : les versions listées sont toutes des builds de développement. Avant d'adopter, vérifiez donc trois points dans votre propre installation : le type d'installation Home Assistant dont vous disposez, puisque l'add-on ne couvre pas Container ni Core, l'état des indicateurs de fonctionnalité dans le panneau HA-MCP, et la présence ou non d'un webhook enregistré selon que vous restez en local ou non.

Conclusion éditoriale

À adopter si vous voulez donner à un assistant IA un accès en lecture et en écriture à une instance Home Assistant sans gérer de jeton longue durée, et si vous acceptez d'installer un composant personnalisé dans votre configuration. À éviter si votre instance est exposée sur Internet sans authentification webhook et si vous ne voulez pas auditer un composant tiers qui peut appeler des services. Avant de brancher un client, vérifiez deux choses dans l'interface : que l'option Remote access via webhook est désactivée si vous restez en local, et que Webhook authentication est réglé sur ha_auth si vous ouvrez l'accès à distance.

Sources officielles

1. homeassistant-ai/ha-mcp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases