Tu veux faire tourner un modèle d’IA en local, sans envoyer tes données sur un serveur externe ? Ollama gère les modèles, Open WebUI fournit l’interface – les deux s’installent en quelques minutes via Portainer.
Cette méthode fonctionne sur n’importe quel Ubuntu avec Docker et Portainer, que tu aies ou non d’autres containers en place. C’est pour faire fonctionner des modèles de langage qu’il peut être essentiel de réaliser cette installation sur un ordinateur un peu rapide, et pas trop occupé par d’autres activités. Les LLM consomment de l’espace disque pour leur stockage local (quelques giga octets par modèle) et de la mémoire vive lorsqu’ils sont utilisés (un ordinateur avec 8 Go de RAM minimum est recommandé, 16 Go si tu veux tester des modèles plus puissants).
Ce qu’on installe
Ollama est le moteur qui télécharge et fait tourner les modèles de langage (LLM). Il expose une API locale sur le port 11434. Il fonctionne en ligne de commande. Il ne stocke aucun historique de tes conversations.
Open WebUI est l’interface web qui se connecte à Ollama. Tu y accèdes depuis n’importe quel navigateur sur le même réseau local – PC Windows, tablette, Android. Open WebUI permet de disposer d’une interface de type « chat », pour « discuter » avec le LLM. Et Open WebUI assure le stockage de l’historique des conversations.
Les deux tournent en containers Docker séparés, avec leurs données dans /home/USER/docker/ pour être couverts par la sauvegarde automatique rclone (voir l’article sur la sauvegarde des containers).
Étape 1 – Installer Ollama
Créer le répertoire de config
bash
mkdir -p /home/USER/docker/ollama/config
Ce répertoire accueille tes fichiers de configuration personnalisés (Modelfiles). Les modèles eux-mêmes, qui peuvent peser plusieurs gigaoctets, sont stockés dans un volume Docker interne – ils ne sont pas sauvegardés, et se retéléchargent facilement si besoin.
Déployer la stack dans Portainer
Dans Portainer : Stacks > Add stack, donne le nom ollama, puis colle ce contenu dans le Web editor :
Remplace USER par ton nom d’utilisateur Linux, puis clique sur Deploy the stack.
Le réseau ollama_default est créé automatiquement par la première stack. Open WebUI s’y connecte pour joindre Ollama directement, sans passer par l’IP de la machine. C’est pour cette raison que les deux stacks doivent être déployées dans cet ordre.
Vérifier l’accès
Depuis n’importe quel navigateur sur ton réseau local :
http://IP_DU_PC_LINUX:3000
Tu dois voir l’interface Open WebUI. Le premier compte créé devient automatiquement administrateur – choisis un mot de passe solide.
Étape 3 – Télécharger un premier modèle
Dans Open WebUI, va dans Panneau d’administration > Réglages > Modèles, puis utilise l’option de téléchargement depuis Ollama pour récupérer un modèle.
Pour commencer, qwen2.5:3b est un bon choix : léger (environ 2,2 Go), rapide sur CPU, et d’excellente qualité en français.
Une fois téléchargé, ouvre une nouvelle conversation, sélectionne le modèle dans le menu déroulant en haut, et teste.
Ce qui est sauvegardé
Élément
Emplacement
Sauvegardé
Config et Modelfiles Ollama
/home/USER/docker/ollama/config/
Oui (rclone)
Données Open WebUI (historique, comptes)
/home/USER/docker/open-webui/data/
Oui (rclone)
Modèles LLM
Volume Docker interne
Non – à retélécharger
Les sauvegardes sont faites par rclone si vous avez fait la configuration indiquée plus haut (« ce qu’on installe »)
Tu as configuré SPF, DKIM et DMARC sur ton domaine, mais tu n’es pas certain que tout est bien en place ? Mail-tester.com te donne une réponse immédiate, gratuitement.
Le site génère une adresse e-mail temporaire unique.
Envoie un e-mail depuis ton adresse habituelle (toi@tondomaine.com) vers cette adresse temporaire – utilise un vrai contenu, pas juste un mot ou un caractère isolé.
Clique sur « Vérifier votre note ».
Tu obtiens une note sur 10 avec le détail de chaque point analysé : SPF, DKIM, DMARC, réputation de l’IP, contenu du message, etc.
Interpréter les résultats
9/10 ou 10/10 – ta configuration est saine. Tes e-mails ont toutes les chances d’arriver en boîte de réception.
En dessous de 8/10 – consulte le détail : Mail-tester indique précisément ce qui cloche. Les problèmes les plus fréquents concernent SPF, DKIM ou DMARC mal configurés ou absents.
Si tu dois revoir ta configuration, ces deux articles t’expliquent comment procéder sur OVH avec Google Workspace :
J’ai un thermostat Tado X installé depuis l’automne 2025, qui fonctionne très bien avec l’app officielle. L’idée semblait simple : le faire apparaître dans Home Assistant pour centraliser le pilotage de la maison. En pratique, c’est plus compliqué que prévu – et la documentation disponible sur le sujet est souvent incomplète ou déjà dépassée.
Voici un retour de ce que j’ai testé, ce qui bloque, et ce qu’il faut faire pour y arriver.
Le matériel Tado X, c’est quoi exactement ?
La gamme Tado X est la nouvelle génération (depuis 2024), qui repose sur Matter over Thread – un protocole de domotique local, sans cloud, conçu pour être interopérable entre écosystèmes.
Dans mon cas, deux appareils :
le Wireless Receiver X (branché à la chaudière), qui joue aussi le rôle de Thread Border Router – c’est lui qui crée le réseau Thread dans la maison
le Wireless Temperature Sensor X (la sonde dans la pièce), qui communique avec le Receiver via Thread
C’est la sonde qu’on cherche à intégrer dans Home Assistant. Le Receiver, lui, est piloté automatiquement par la sonde – pas besoin de l’intégrer séparément.
Ce qui ne fonctionne pas (et pourquoi)
L’intégration native Home Assistant Tado
Home Assistant propose une intégration Tado dans son catalogue officiel. Elle fonctionne bien – mais uniquement pour l’ancienne gamme Tado (V3+). Pour la gamme X, la documentation officielle HA le dit clairement : les appareils Tado X ne sont pas supportés par cette intégration. En pratique, l’authentification OAuth se déroule correctement côté Tado, mais HA boucle ensuite sur une erreur « Device login flow status is PENDING ». Le problème vient d’un champ manquant dans la réponse de l’API Tado X (shortSerialNo), que l’intégration HA attend et ne trouve pas.
Matter local (via python-matter-server)
Matter est justement le protocole natif du Tado X – l’approche semblait donc idéale. On installe le container python-matter-server, on configure l’intégration Matter dans HA, et on tente l’appairage via l’app Tado (option « Associer avec une app compatible Matter »).
Le container fonctionne bien. L’intégration Matter dans HA aussi. Mais l’appairage échoue avec un « code erreur 1 ».
La cause est plus profonde : le Tado X utilise Matter over Thread, pas Matter over WiFi. La différence est importante. Matter over Thread nécessite un Thread Border Router (OTBR) exposé sur le réseau local – c’est lui qui fait le pont entre le réseau Thread des appareils et le réseau IP de la maison. Or le Wireless Receiver X de Tado joue ce rôle, mais il ne l’expose pas aux systèmes tiers. Il est exclusivement réservé à l’app Tado.
Sans OTBR indépendant, le matter-server ne peut pas atteindre la sonde Tado X.
Les options qui fonctionnent
Option 1 – Une intégration communautaire via HACS (la plus simple)
C’est l’option recommandée pour démarrer. HACS (Home Assistant Community Store) donne accès à des intégrations communautaires maintenues activement. Deux intégrations supportent la gamme X :
Tado X (par exabird) – spécifiquement conçue pour la gamme X, utilise l’API officielle Tado
Tado CE (par hiall-fyi) – disponible directement dans le catalogue HACS, sans configuration de dépôt personnalisé
Ces deux intégrations passent par le cloud Tado (donc dépendance internet), mais elles gèrent correctement les appareils X là où l’intégration native échoue.
Pour installer HACS sur Home Assistant Container (Docker) :
Redémarre ensuite HA, puis ajoute HACS comme intégration (Paramètres > Appareils et services > + Ajouter). Tu auras besoin d’un compte GitHub gratuit pour l’authentification.
Une fois HACS installé, cherche « Tado X » ou « Tado CE » dans le store et installe l’une des deux.
Point d’attention : depuis janvier 2026, Tado limite les appels API à 100 par jour (quota remis à zéro à 12h CET). Pour un thermostat unique avec une fréquence de polling raisonnable, ça devrait suffire – mais c’est à surveiller.
Option 2 – Un Thread Border Router dédié (Matter local, sans cloud)
C’est la solution la plus locale, mais la plus complexe. Elle nécessite :
Un dongle Thread compatible – le Home Assistant Connect ZBT-1 ou le Sonoff ZBT-1 (20-40 €), à flasher en firmware Thread-only
Le container Docker ghcr.io/ownbee/hass-otbr-docker pour créer un Thread Border Router indépendant
L’activation de l’IPv6 forwarding sur le serveur (quelques lignes dans /etc/sysctl.conf)
La configuration de l’intégration OpenThread Border Router dans HA
Une fois ce réseau Thread en place, l’appairage Matter du Tado X devrait fonctionner via l’app HA mobile.
C’est à envisager si tu as plusieurs appareils Thread/Matter ou si la dépendance au cloud Tado devient un problème.
Option 3 – Attendre
L’équipe Home Assistant travaille activement sur le support natif de la gamme Tado X. Une future mise à jour pourrait résoudre le problème sans action de ta part.
Par où commencer ?
Si tu veux intégrer ton Tado X dans Home Assistant maintenant, commence par l’option 1 (HACS + Tado X ou Tado CE). C’est le meilleur rapport effort/résultat.
Si la dépendance cloud te dérange ou si tu prévois d’ajouter d’autres appareils Matter/Thread, l’option 2 vaut l’investissement – mais prévois du temps pour la mise en place.
De mon côté j’ai choisi l’option 3 – attendre !
Testé en juin 2026 avec Home Assistant Container 2026.5.0, Tado X Wireless Receiver X (firmware 299.1) et Wireless Temperature Sensor X.
Les capteurs d’ouverture Aqara MCCGQ11LM et MOES ZSS-G02-GWM-C fonctionnent de la même façon dans Home Assistant via Zigbee2MQTT. La procédure ci-dessous couvre les deux modèles, avec les différences signalées au fur et à mesure.
Préparation du capteur
Les deux modèles fonctionnent sur pile bouton et ne nécessitent aucune configuration préalable.
Aqara MCCGQ11LM (piles CR1632)
Il n’y a rien à faire à l’installation. Mais si la pile est trop ancienne, ais levier délicatement avec un ongle ou un petit tournevis plat dans la fente sur la tranche inférieure pour ouvrir le boîtier. Insère une pile CR1632, face positive (+) vers le haut. Referme le boîtier en clipsant le couvercle.
MOES ZSS-G02-GWM-C (pile CR2032)
Glisse un ongle ou un petit tournevis dans la fente du boîtier arrière pour l’ouvrir.
Retire la languette en plastique transparent qui bloque la pile.
Dans les deux cas, effectue l’appairage à proximité de ton ordinateur ou de ta box domotique avant de coller le capteur à son emplacement définitif.
Appairage dans Zigbee2MQTT
Ouvre l’interface web de Zigbee2MQTT.
Clique sur Permit join en haut à droite.
Maintiens le bouton du capteur enfoncé environ 5 secondes jusqu’à ce que la LED clignote, puis relâche.
Zigbee2MQTT détecte le capteur en quelques secondes et l’ajoute à la liste.
Renomme-le immédiatement (ex : Capteur Porte Entrée ou Capteur Fenêtre Cuisine) et coche la case pour synchroniser le nom avec Home Assistant.
Astuce Aqara uniquement – Les capteurs Aqara de première génération ont tendance à s’endormir rapidement pendant l’appairage. Pendant les 10 à 20 secondes que dure la détection, appuie brièvement sur le bouton toutes les 2 secondes pour maintenir le capteur éveillé et lui permettre d’envoyer ses informations de configuration.
Installation physique
Le principe est le même pour les deux modèles :
Place le grand boîtier sur la partie fixe (le cadre de porte ou de fenêtre) et le petit aimant sur la partie mobile (le battant).
Aligne les petites lignes gravées sur le côté de chaque pièce l’une en face de l’autre.
Respecte la distance maximale entre les deux éléments : 22 mm pour l’Aqara, 20 mm pour le MOES. Au-delà, le capteur considère la porte comme ouverte même quand elle est fermée.
Entités disponibles dans Home Assistant
Une fois appairé, le capteur apparaît automatiquement dans Home Assistant via l’intégration MQTT. Tu y trouveras :
binary_sensor.contact – état d’ouverture : on pour ouvert, off pour fermé. Dans les paramètres de l’entité, utilise « Afficher en tant que » pour choisir Porte, Fenêtre ou Garage – l’icône s’adapte automatiquement.
sensor.battery – pourcentage de pile restant (peut prendre jusqu’à 24h à se stabiliser après le premier appairage).
sensor.linkquality – force du signal Zigbee (Aqara uniquement).
Allumage automatique à l’ouverture d’une porte (idéal pour un couloir ou un dressing)
alias: "Lumière : Allumage auto sur ouverture porte"
trigger:
- platform: state
entity_id: binary_sensor.capteur_porte_entree_contact
to: "on"
condition:
- condition: state
entity_id: sun.sun
state: "below_horizon"
action:
- service: light.turn_on
entity_id: light.lumiere_couloir
Notification si une fenêtre reste ouverte
alias: "Notification : Fenêtre restée ouverte"
trigger:
- platform: state
entity_id: binary_sensor.capteur_fenetre_cuisine_contact
to: "on"
for:
minutes: 10
action:
- service: notify.mobile_app_votre_telephone
data:
title: "Attention"
message: "La fenêtre de la cuisine est ouverte depuis plus de 10 minutes !"
Remplace les noms d’entités par ceux de tes capteurs dans Home Assistant.
La prise NOUS A7Z fait trois choses à la fois : elle mesure la consommation de l’appareil branché, permet de l’allumer ou l’éteindre à distance, et étend la portée de ton réseau Zigbee en servant de répéteur. Voici comment l’intégrer dans Zigbee2MQTT et Home Assistant.
Préparation et branchement
La prise fonctionne sur secteur, aucune pile n’est nécessaire.
Branche-la sur une prise murale, idéalement à mi-chemin entre ton dongle Zigbee et tes capteurs les plus éloignés pour optimiser son rôle de répéteur. Une fois alimentée, la LED intégrée au bouton clignote lentement : la prise est prête à être appairée.
Appairage dans Zigbee2MQTT
Ouvre l’interface web de Zigbee2MQTT.
Clique sur Permit join (en haut à droite).
Si la LED ne clignote pas déjà rapidement, maintiens le bouton physique enfoncé environ 5 secondes jusqu’à ce qu’elle le fasse, puis relâche.
Zigbee2MQTT détecte la prise automatiquement – elle apparaît sous la marque Nous ou Tuya selon la version du firmware.
Renomme-la de façon explicite (ex : Prise Machine à Laver ou Répéteur Salon) et coche la case pour synchroniser le nom avec Home Assistant.
Rôle de répéteur dans le maillage Zigbee
Dès l’appairage effectué, la prise commence automatiquement à router le trafic Zigbee. Les capteurs à proximité peuvent s’y connecter plutôt que de joindre directement le dongle, ce qui améliore la stabilité de l’ensemble du réseau.
Laisse le réseau entre 24 et 48 heures pour se stabiliser. Tu peux ensuite visualiser les connexions dans l’onglet Schéma (Map) de Zigbee2MQTT.
Entités disponibles dans Home Assistant
La NOUS A7Z expose plusieurs entités dans Home Assistant :
switch.prise_votre_nom – allume ou éteint l’appareil branché
sensor.power – puissance instantanée en Watts (W)
sensor.energy – consommation cumulée en kWh, à ajouter dans le panneau Énergie de Home Assistant pour le suivi des coûts
sensor.current – intensité en Ampères (A)
sensor.voltage – tension en Volts (V)
Exemple : notification de fin de cycle machine
L’entité sensor.power permet de détecter automatiquement la fin d’un cycle de lave-linge ou lave-vaisselle. L’automatisation ci-dessous envoie une notification quand la puissance passe sous 3 W pendant 5 minutes consécutives – ce qui correspond à la fin du cycle.
alias: "Machine à laver : Notification fin de cycle"
trigger:
- platform: numeric_state
entity_id: sensor.prise_machine_a_laver_power
below: 3
for:
minutes: 5
condition:
- condition: state
entity_id: switch.prise_machine_a_laver
state: "on"
action:
- service: notify.mobile_app_votre_telephone
data:
title: "Domotique"
message: "La machine à laver a terminé, tu peux étendre le linge !"
Remplace sensor.prise_machine_a_laver_power et switch.prise_machine_a_laver par les noms exacts de tes entités dans Home Assistant, et mobile_app_votre_telephone par le nom de ton application mobile.
Commentaires récents