Recycler un vieux mini PC en serveur Home Assistant (et le configurer avec un agent IA)

Un mini PC qui traîne dans un tiroir (Intel NUC, HP EliteDesk, Lenovo ThinkCentre Tiny) fait un serveur Home Assistant bien plus confortable qu’un Raspberry Pi : plus de RAM, un vrai SSD, un port Ethernet fiable. Le vrai sujet n’est pas le choix du boîtier, c’est ce qui tourne dessus. Une fois Home Assistant OS installé, la difficulté classique arrive vite : l’éditeur graphique d’automatisations atteint ses limites dès qu’on veut une condition un peu fine, et on se retrouve à écrire du YAML avec des templates Jinja à la main. C’est cette étape-là qu’un agent IA connecté en MCP peut largement simplifier.

Pourquoi un mini PC plutôt qu’un Raspberry Pi

Home Assistant tourne officiellement sur Raspberry Pi (4 ou 5, minimum 2 Go de RAM selon la documentation officielle), mais un mini PC x86-64 recyclé apporte trois avantages concrets pour un usage domotique qui grossit avec le temps :

  • Stockage SSD/NVMe — l’historique des états d’entités (recorder) et les logs génèrent beaucoup d’écritures ; un SSD évite l’usure prématurée d’une carte SD.
  • Marge CPU/RAM — utile dès qu’on ajoute des add-ons gourmands (Frigate pour la vidéo, une base de données externe, un serveur MCP).
  • Fiabilité — alimentation et refroidissement d’un mini PC de bureau sont pensés pour tourner 24/7, contrairement à beaucoup d’adaptateurs USB de Raspberry Pi.

Le hardware reste un détail d’implémentation : n’importe quelle machine x86-64 de la dernière décennie capable de démarrer en UEFI convient, d’après les prérequis matériels documentés par Home Assistant.

Installer Home Assistant OS sur le mini PC

Home Assistant propose plusieurs méthodes d’installation (Container, Core, Supervised), mais Home Assistant OS (HAOS) reste la plus simple sur une machine dédiée : elle gère elle-même le système, le magasin d’add-ons et les sauvegardes automatiques, sans configuration Linux préalable.

Prérequis vérifiés dans la documentation officielle :

  • Machine x86-64 capable de démarrer en UEFI (désactiver le Secure Boot dans le BIOS)
  • Un disque interne (SSD recommandé) qui sera entièrement dédié à HAOS
  • Une clé USB d’au moins 8 Go pour le support d’installation
  • Un câble Ethernet branché au premier démarrage (connexion Internet obligatoire)

Étapes principales (méthode recommandée par la doc officielle, via Ubuntu Live USB) :

# 1. Télécharger l'image HAOS générique x86-64 depuis les releases GitHub
#    (Home Assistant OS, image "generic-x86-64")
# https://github.com/home-assistant/operating-system/releases

# 2. Démarrer le mini PC sur une clé Ubuntu Live USB

# 3. Utiliser l'utilitaire "Disques" d'Ubuntu pour restaurer
#    l'image .img.xz directement sur le disque interne du mini PC

# 4. Éteindre, retirer la clé USB, redémarrer sur le disque interne

Après quelques minutes de premier démarrage (mise à jour automatique), l’interface est accessible sur le réseau local :

http://homeassistant.local:8123

Si la résolution .local ne fonctionne pas sur votre réseau, utilisez directement l’adresse IP attribuée par le routeur (visible dans l’interface de votre box ou via un scan réseau).

Configuration de base une fois HAOS démarré

L’assistant de configuration initial couvre l’essentiel : création du compte administrateur, nom du foyer, position géographique (pour les automatisations basées sur le lever/coucher du soleil), et détection automatique des appareils compatibles sur le réseau (imprimantes, TV, assistants vocaux, etc. via l’intégration mDNS).

Points à traiter dans la foulée :

  • Sauvegardes automatiques — HAOS les gère nativement (Paramètres > Système > Sauvegardes), à programmer vers un stockage réseau ou un cloud dès l’installation terminée.
  • Mises à jour — HAOS, le Supervisor et les add-ons se mettent à jour séparément ; activer les notifications de mise à jour évite de rester bloqué sur une version obsolète.
  • Intégrations — chaque appareil ou service (Zigbee, prises connectées, météo) s’ajoute via Paramètres > Appareils et services > Ajouter une intégration.

Connecter un agent IA via le serveur MCP

Home Assistant expose une intégration officielle MCP Server, basée sur le Model Context Protocol. Elle inverse le rôle habituel : ce n’est plus Home Assistant qui interroge un LLM (comme avec les agents conversationnels intégrés), c’est un client LLM externe — Claude Code, Claude for Desktop, ou un autre outil compatible MCP — qui se connecte à Home Assistant comme serveur de contexte.

Activer l’intégration

Dans Home Assistant : Paramètres > Appareils et services > Ajouter une intégration, chercher « MCP Server ». L’intégration expose un endpoint /api/mcp en Streamable HTTP, protégé par authentification (token d’accès longue durée ou OAuth selon le client).

Choisir les entités exposées

Avant de brancher un agent IA, définissez précisément ce qu’il peut voir et modifier via la page entités exposées (Assist). C’est le point de contrôle principal : un agent qui a accès à toutes les entités de la maison peut aussi bien lire l’état d’un capteur d’humidité que déclencher une serrure connectée. Limitez l’exposition aux domaines nécessaires à l’usage prévu (capteurs, lumières, chauffage) et laissez de côté ce qui n’a pas besoin de passer par l’IA.

Configurer le client (exemple Claude Code)

Le principe général pour un client compatible MCP :

// Exemple de structure de configuration MCP côté client
// (adapter selon la documentation du client utilisé)
{
  "mcpServers": {
    "home-assistant": {
      "url": "https://votre-instance-ha.exemple/api/mcp",
      "auth": {
        "type": "oauth" // ou token d'accès longue durée
      }
    }
  }
}

La configuration exacte (nom des champs, méthode d’auth) dépend du client MCP utilisé — reportez-vous à sa documentation pour la syntaxe précise, l’intégration MCP Server de Home Assistant ne dictant que le côté serveur.

Ce que ça change concrètement pour les automatisations

L’éditeur graphique d’automatisations de Home Assistant couvre bien les scénarios simples (déclencheur → action), mais montre ses limites dès qu’une condition demande de combiner plusieurs capteurs, des plages horaires variables ou du calcul (comparer un point de rosée plutôt qu’un simple pourcentage d’humidité, par exemple). Ces cas passent presque toujours par du YAML avec des templates Jinja, où une erreur d’indentation suffit à casser l’automatisation.

Avec un agent IA connecté en MCP, le flux change de nature : vous décrivez en langage naturel le comportement souhaité, l’agent lit les entités et leur état réel exposés par Home Assistant, propose (et peut écrire directement) la configuration YAML correspondante. Il peut aussi repérer une entité pertinente que vous n’aviez pas identifiée, ou suggérer une condition plus robuste que ce que vous aviez en tête — l’agent voit l’ensemble des capteurs disponibles, pas seulement ceux auxquels vous pensez spontanément.

Ça ne dispense pas de relire ce qui est généré : un agent IA peut se tromper sur une unité, une plage de valeurs ou le comportement exact d’une intégration tierce. La revue manuelle avant activation reste indispensable, surtout pour tout ce qui touche à la sécurité (accès, ouvertures, chauffage).

+ Les points forts

  • HAOS clé en main — sauvegardes, add-ons et mises à jour gérés nativement, sans administration Linux au quotidien
  • MCP officiel — pas besoin d’un serveur MCP tiers pour connecter un agent IA, l’intégration fait partie de Home Assistant
  • Automatisations complexes accessibles — les conditions qui demandaient du YAML/Jinja à la main deviennent des descriptions en langage naturel
  • Réutilisation de matériel — un mini PC qui aurait fini au recyclage devient un serveur domotique fiable

- Les points faibles

  • Surface d’attaque à surveiller — exposer des entités à un agent IA externe augmente le risque si le token ou l’accès OAuth fuite ; limiter strictement les entités exposées est indispensable
  • Dépendance à un client MCP payant ou externe — Claude Code, Claude for Desktop et les autres clients compatibles ne sont pas gratuits ou pas auto-hébergés
  • Fiabilité du LLM non garantie — une automatisation générée doit être relue, l’agent peut mal interpréter une unité ou une intégration tierce
  • HAOS monopolise le disque — contrairement à Home Assistant Container, HAOS prend la main sur toute la machine ; pas de cohabitation facile avec d’autres services sur le même mini PC

En résumé

Un mini PC recyclé fait un excellent socle matériel pour Home Assistant OS : plus robuste qu’un Raspberry Pi, sans complexité de configuration grâce à HAOS. Le vrai gain se joue ensuite, côté logiciel : brancher un agent IA via l’intégration MCP Server officielle transforme la rédaction d’automatisations complexes, qui demandait du YAML et des templates Jinja, en une conversation en langage naturel — à condition de garder le contrôle sur les entités exposées et de relire ce qui est généré avant de l’activer.


Voir aussi :

  • Coolify — auto-héberger d’autres services sur le même type de machine
  • Dashy — regrouper Home Assistant et vos autres services homelab dans un dashboard unique
  • Uptime Kuma — surveiller la disponibilité de votre serveur Home Assistant