Ollama et Open WebUI installés, modèles téléchargés – le chat fonctionne. Mais si tu veux interroger tes propres documents sans les envoyer sur un serveur externe, il faut aller un cran plus loin : configurer le RAG. Cet article fait partie de deux séries :
la série des articles sur Linux et des logiciels installés en containers Docker : projets Ubuntu
La série des articles sur la création d’une IA locale dans mon bureau : Créer une IA locale
C’est quoi le RAG ?
RAG est l’acronyme de « Retrieval-Augmented Generation » – en français, génération augmentée par récupération. L’idée est simple : plutôt que de demander au modèle de répondre uniquement à partir de ce qu’il a appris pendant son entraînement, on lui fournit des passages extraits de tes propres documents. Le modèle s’appuie sur ces passages pour construire sa réponse.
En pratique, ça change tout : tu peux créer un assistant qui connaît ta documentation interne, tes notes, tes rapports – et qui répond en citant ses sources. Et si c’est fait dans un système local, rien ne sort vers l’extérieur.
Le rôle de l’embedding
Pour que le RAG fonctionne, le système doit être capable de trouver rapidement les passages pertinents dans tes documents avant de les transmettre au modèle. C’est le rôle de l’embedding – qu’on pourrait traduire par vectorisation sémantique, même si ce terme n’est pas d’usage courant.
Un modèle d’embedding lit chaque paragraphe de tes documents et le convertit en une liste de coordonnées mathématiques – un vecteur. Deux paragraphes qui parlent du même sujet auront des coordonnées proches, même s’ils n’utilisent pas les mêmes mots. Quand tu poses une question, ta question est convertie de la même façon, et le système trouve en quelques millisecondes les paragraphes les plus proches.
Le LLM ne reçoit alors que ces quelques paragraphes pertinents – pas l’intégralité du document. Sur un CPU sans carte graphique dédiée, c’est ce qui rend le système utilisable : le modèle n’a que quelques lignes à lire pour formuler sa réponse.
Les modèles testés dans cet article : qwen2.5:3b comme LLM, nomic-embed-text comme modèle d’embedding
Étape 1 – Télécharger le modèle d’embedding
nomic-embed-text est un modèle léger (~270 Mo), rapide sur CPU, avec une fenêtre de contexte de 8192 tokens – ce qui permet de découper les documents en morceaux suffisamment grands pour conserver le sens.
nomic-embed-text doit apparaître dans la liste aux côtés de tes modèles LLM.
Étape 2 – Configurer l’embedding dans Open WebUI
Dans Open WebUI, connecte-toi avec ton compte administrateur, puis va dans Panneau d’administration > Réglages > Documents.
Dans la section Embedding :
Moteur de modèle d’embedding : sélectionne Ollama
Modèle d’embedding : saisis nomic-embed-text
Clique sur Enregistrer.
Open WebUI délègue désormais toute la vectorisation à Ollama. Les deux modèles – LLM et embedding – tournent sur le même moteur, sans duplication de ressources.
Étape 3 – Créer une base de connaissances
Une base de connaissances est un ensemble de documents indexés sur un thème donné. C’est l’équivalent local d’un Projet Claude ou d’un Gem Gemini – sans que rien ne sorte de ta machine.
Dans Open WebUI, va dans Espace de travail > Connaissances, puis crée une nouvelle base avec un nom explicite (par exemple « Réglementation formation » ou « Documentation projet X »).
Glisse-dépose tes fichiers PDF ou TXT dans la zone dédiée. Le CPU va s’activer quelques secondes – c’est nomic-embed-text qui indexe et vectorise les documents en arrière-plan. Une fois l’indexation terminée, la base est prête.
Quelques points à garder en tête :
Les modèles texte uniquement (qwen2.5:3b, llama3.1, mistral) ne peuvent pas traiter des images – seul le texte extrait des PDF est utilisable
Pour les très longs documents (plus de 50-100 pages), laisse le CPU terminer l’indexation avant d’en ajouter d’autres
Étape 4 – Créer un agent associé à la base
La base de connaissances seule ne fait rien – il faut lui associer un agent, c’est-à-dire un modèle configuré avec un comportement précis.
Dans Espace de travail > Modèles, clique sur Créer un modèle, puis :
Donne-lui un nom explicite (par exemple « Assistant formation »)
Modèle de base : sélectionne qwen2.5:3b
Dans la section Connaissances, associe la base créée à l’étape précédente
Rédige un system prompt
Le system prompt est crucial. Sans instruction claire, le modèle complète avec ses connaissances générales plutôt que de s’appuyer sur tes documents. Un exemple efficace :
« Tu es l’assistant de [ton rôle]. Tu réponds uniquement à partir des documents fournis dans ta base de connaissances. Si une information n’y figure pas, dis-le clairement sans inventer. Ne complète jamais avec tes connaissances générales. »
Sauvegarde. L’agent est prêt.
Ce que ça fait vraiment
Les tests sur cette configuration (Mini PC Ubuntu, Intel i5, 16 Go de RAM) donnent des résultats concluants sur des documents de quelques pages à une vingtaine de pages. Le modèle cite ses sources, répond aux questions dans le périmètre des documents, et indique clairement quand une information est absente.
Quelques limites à connaître :
Documents texte uniquement. Les modèles testés ici (qwen2.5:3b et les autres) ne traitent pas les images. Envoyer une image depuis Open WebUI produit une erreur. Seul le texte extrait des PDF est utilisable par le RAG.
Les PDF scannés nécessitent une étape supplémentaire. Le moteur d’extraction par défaut d’Open WebUI ne sait pas lire un PDF image (un scan sans couche texte). Si tu essaies d’en déposer un dans une base de connaissances, tu obtiendras une erreur silencieuse ou un document vide. La solution est d’ajouter Tika – un service Apache open source – comme moteur d’extraction. Tika s’installe en container Docker séparé et se connecte à Open WebUI via le réseau Docker. Ce point fait l’objet d’un article à venir dans cette série.
Le system prompt fait la différence. Sans instruction explicite de rester dans les sources, le modèle complète avec ses connaissances générales – les réponses paraissent correctes mais ne s’appuient pas sur tes documents. L’instruction « réponds uniquement à partir des documents fournis » change significativement le comportement.
Les réponses ne sont pas déterministes. Le même modèle, la même question, des sessions différentes peuvent produire des réponses légèrement différentes. C’est une caractéristique fondamentale des LLM, pas un dysfonctionnement – et une bonne raison de tester systématiquement après chaque modification de configuration.
Pour aller plus loin
Cet article fait partie d’une série sur l’IA locale : Créer une IA locale et l’installation de logiciels en containers Docker sous ubuntu : Créer une IA locale
Ollama et Open web UI installés, modèles téléchargés – reste à savoir lequel utiliser au quotidien. Un prompt unique soumis aux 4 modèles permet de les départager rapidement sur ce qui compte : logique, maîtrise du français, et comportement de la machine.
La configuration de test
Mini PC sous Ubuntu, processeur Intel i5, 16 Go de RAM
Le même prompt a été soumis à chacun des 4 modèles, sans modification :
« Résous ce problème de logique étape par étape : Trois personnes (Alice, Bob et Charlie) ont chacune une couleur de pull différente (Bleu, Rouge, Vert). Alice dit qu’elle ne porte pas de bleu. Charlie porte un pull vert. Quelle est la couleur du pull de Bob ? Ensuite, traduis cette expression anglaise de manière naturelle en français : ‘It is raining cats and dogs’. Enfin, écris une seule phrase poétique sur la pluie. »
Ce prompt évalue quatre critères en une seule passe :
Logique : résoudre l’énigme par déduction (solution attendue : Bob = Bleu)
Traduction idiomatique : éviter la traduction littérale, trouver l’équivalent naturel en français
Créativité : qualité et fluidité de la phrase poétique
Comportement machine : vitesse d’affichage, charge CPU et RAM observées via htop
Conditions du test : avant chaque modèle, vérification qu’aucun autre modèle n’est chargé en RAM (sudo docker exec ollama ollama ps), et arrêt forcé si nécessaire (sudo docker exec ollama ollama stop <nom_du_modele>). Le chronométrage est fait à la main, du moment où le prompt est envoyé jusqu’à la fin de l’affichage de la réponse. Les modèles sont testés du plus léger au plus lourd.
Traduction : correct mais en retrait. Il propose « Il pleut très fort » – ce qui est juste, mais banal. Lors d’une session précédente avec ce même modèle, il avait spontanément proposé quatre variantes idiomatiques (« Il pleut à torrents », « Il pleut à verse », « Il pleut comme jamais ») – une performance nettement meilleure. C’est un rappel utile : les LLM ne sont pas déterministes, la même question peut produire des réponses différentes d’une session à l’autre.
Poésie : correct, avec une image intéressante. « L’onde silencieuse des gouttes, qui chuchotent à travers le ciel. »
Machine : très bon comportement. Affichage quasi instantané, charge CPU modérée, RAM peu sollicitée. La machine reste disponible pendant et après le test.
gemma2:2b – Le petit modèle décevant
Durée : 30 secondes
Logique : faux. Il identifie correctement que Charlie porte le vert et qu’Alice ne porte pas le bleu, mais ne parvient pas à conclure correctement – il introduit même une couleur inexistante dans l’énoncé. C’est la limite des modèles à 2 milliards de paramètres : la surface cognitive est insuffisante pour enchaîner plusieurs étapes de déduction avec une négation.
Traduction : échec. Il traduit « It is raining cats and dogs » par « Il pleut des chats et des chiens » – traduction littérale, qui perd tout le sens de l’expression.
Poésie : il répond en anglais (« The sky weeps a soft, silver song »), ignorant la consigne en français.
Machine : comportement moyen. Plus lent que qwen2.5:3b malgré sa taille inférieure – l’architecture de Gemma est plus gourmande en ressources CPU relativement à sa taille.
llama3.1 (8B) – Le raisonneur qui déraille
Durée : 2 minutes 17 secondes
Logique : faux. Le modèle développe un raisonnement structuré en plusieurs étapes, mais arrive à une conclusion erronée : il annonce Bob = Rouge, alors que la bonne réponse est Bob = Bleu. C’est d’autant plus surprenant que le raisonnement intermédiaire est correct – il identifie bien que Charlie = Vert et qu’Alice ne porte pas de bleu – mais la conclusion finale ne suit pas.
Traduction : parfait. « Il pleut des cordes » – sans hésitation, avec en complément « il pleut à verse ».
Poésie : correct. « La pluie tombant avec insistance et régularité est comme une promesse de renouveau. »
Machine : lourd. Affichage lent, charge CPU élevée sur les 8 coeurs, RAM fortement sollicitée. La machine reste saturée après le test et nécessite un arrêt forcé du modèle via sudo docker restart ollama pour revenir à la normale.
mistral (7B) – Les pieds dans le tapis
Durée : 1 minute 39 secondes
Logique : raisonnement contradictoire. Mistral part d’une bonne intuition mais son développement est incohérent : il affirme qu’Alice ne peut pas porter le vert alors que l’énoncé ne dit rien de tel, et conclut finalement Bob = Bleu – la bonne réponse – mais pour de mauvaises raisons. Un résultat juste obtenu par un chemin faux.
Traduction : mauvais, à deux titres. D’abord il donne la traduction littérale « Il pleut des chats et des chiens », puis tente de se rattraper en expliquant que « cela pleut beaucoup ». Cette formulation « cela pleut » est un calque direct de l’anglais « it’s raining » – un francophone écrit « il pleut », jamais « cela pleut ». Pour un modèle développé en France et réputé pour son français, c’est une déception.
Poésie : faute de grammaire. Mistral écrit « Les gouttes de pluie sont les diamants que tombent du ciel » – il aurait fallu écrire « qui tombent ». C’est la surprise du test : un modèle développé en France commet une erreur de syntaxe élémentaire sur sa langue maternelle. Cela illustre l’effet de la quantification – la compression du modèle pour réduire sa taille peut dégrader certaines compétences linguistiques, même sur la langue d’origine.
Machine : critique. Avec Home Assistant et les autres containers actifs en parallèle, la machine a atteint la limite de sa RAM physique et a commencé à utiliser le swap (espace disque utilisé comme mémoire de secours). Un arrêt forcé du container Ollama est nécessaire pour revenir à la normale.
Tableau récapitulatif
Critère
qwen2.5:3b
gemma2:2b
llama3.1 (8B)
mistral (7B)
Logique
Correct
Faux
Faux
Résultat juste, raisonnement faux
Traduction
Correct
Échec
Parfait
Mauvais
Poésie
Correct
Hors consigne
Correct
Faute de syntaxe
Durée
45 sec
31 sec
2 min 17
1 min 39
Impact machine
Léger
Moyen
Lourd
Critique
Ce que ce test apprend sur les LLM locaux
La taille ne fait pas tout. qwen2.5:3b (3 milliards de paramètres) surpasse gemma2:2b (2 milliards) sur tous les critères linguistiques, y compris la traduction en français, alors qu’il est plus grand. L’architecture et les données d’entraînement comptent autant que le nombre de paramètres.
Les LLM ne sont pas déterministes. Le même modèle, le même prompt, des résultats différents d’une session à l’autre. qwen a produit quatre variantes idiomatiques lors d’un premier passage, et une réponse banale lors du second. C’est une caractéristique fondamentale des LLM, pas un bug.
Les grands modèles ont un coût réel sur CPU. Llama 3.1 et Mistral sont utilisables, mais pas sur une machine déjà chargée par d’autres services. Sur un PC dédié uniquement à Ollama, le résultat serait différent.
Recommandation pour ma configuration
Au quotidien : qwen2.5:3b. Rapide, léger, correct en français, il ne sollicite pas la machine. C’est le modèle à utiliser en priorité sur une machine qui fait tourner d’autres services en parallèle.
Pour les tâches complexes : llama3.1 si la machine est disponible et si tu peux attendre – mais en gardant à l’esprit que ses performances en logique se sont révélées décevantes dans ce test.
À désinstaller : gemma2:2b. Ses performances en logique et en français sont insuffisantes, et il n’offre aucun avantage sur qwen2.5:3b.
À utiliser avec précaution : mistral. Son impact sur la RAM est trop important pour une machine partagée, et ses performances en français sont inférieures à ce qu’on pourrait attendre d’un modèle développé en France.
Nota
Ces modèles ne lisent pas les fichiers. Les 4 modèles testés sont des modèles texte uniquement. Envoyer un PDF ou une image depuis Open WebUI produit une erreur – le modèle ne sait pas traiter ce type d’entrée. Deux pistes pour y remédier : le RAG (Retrieval-Augmented Generation), qui permet d’interroger des documents en extrayant leur texte en amont, et les modèles multimodaux, capables de traiter des images directement. Ces deux sujets feront l’objet d’articles séparés.
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.
Article de la série « Mon ordinateur Ubuntu » Actions et articles créés avec l’aide de Claude.ai et 100% testé et ajusté par moi.
Tu veux piloter une ampoule, une télécommande ou un capteur Zigbee depuis Home Assistant ? Ce tutoriel te guide pas à pas pour mettre en place la chaîne complète : Mosquitto comme broker MQTT, Zigbee2MQTT comme passerelle, et Home Assistant comme cerveau de ta domotique.
Ce que tu vas mettre en place
Les appareils Zigbee ne parlent pas directement à Home Assistant. Il faut une chaîne de traduction :
Le dongle Zigbee reçoit les messages de tes appareils Zigbee
Zigbee2MQTT traduit ces messages en MQTT
Mosquitto joue le rôle de boîte aux lettres : il reçoit et redistribue les messages MQTT
Home Assistant lit ces messages et crée automatiquement les entités correspondantes
Chaque composant est installé comme un container Docker, selon le même protocole que les autres services de ta stack.
allow_anonymous true permet la connexion sans authentification. Ce n’est pas un problème car le port 1883 n’est pas exposé vers l’extérieur – il reste confiné au réseau local.
Créer la stack dans Portainer
Dans Portainer, crée une stack « mosquitto » avec ce YAML :
Dans Portainer, crée une stack « zigbee2mqtt » avec ce YAML. Remplace IDENTIFIANT_DU_DONGLE par le nom exact récupéré à l’étape 1, et PORT_EXTERNE par le port disponible identifié à l’étape 2 (8080 ou 8081) :
Point critique : la ligne devices: doit contenir le chemin exact du dongle. C’est le point le plus sensible de l’installation.
Sauvegarder le YAML
sudo nano /home/USER/docker/zigbee2mqtt/docker-compose.yml
# coller le YAML
sudo chown USER:USER/home/ald/docker/zigbee2mqtt/docker-compose.yml
Après démarrage, Zigbee2MQTT est accessible via http://IP_DU_PC:PORT_EXTERNE. Une page d’onboarding s’affiche – c’est normal, c’est le premier démarrage.
Compléter l’onboarding
Sur la page d’onboarding, sélectionne ton dongle dans la liste « Devices found » et clique sur Submit sans modifier les autres valeurs. Zigbee2MQTT génère alors automatiquement sa configuration.
Modifier le fichier de configuration
Après l’onboarding, modifie le fichier de configuration généré :
Apporte ces modifications, sans toucher au reste (network_key, pan_id, channel…) :
Ligne à trouver
Remplacer par
server: mqtt://localhost:1883
server: mqtt://IP_DU_PC:1883
serial: {}
serial: port: /dev/ttyACM0
frontend: enabled: false
frontend: enabled: true
homeassistant: enabled: false
homeassistant: enabled: true
onboarding: true
onboarding: false
Redémarre le container depuis Portainer. Vérifie les logs :
sudo docker logs zigbee2mqtt
Tu dois voir Zigbee2MQTT started! et Connected to MQTT server.
Étape 5 – Connecter Home Assistant à MQTT
Dans Home Assistant : Paramètres > Appareils et services > Ajouter une intégration > MQTT
Remplis les champs :
Broker : IP_DU_PC
Port : 1883
Nom d’utilisateur et mot de passe : laisser vides
Clique sur Valider. Si la connexion réussit, l’intégration MQTT apparaît dans ta liste de services.
Zigbee2MQTT et Home Assistant se découvrent alors automatiquement via MQTT Discovery.
Étape 6 – Appairer un premier appareil pour vérifier
C’est le test de tout ce qui précède ! Dans l’interface Zigbee2MQTT (http://IP_DU_PC:PORT_EXTERNE) :
Clique sur Autoriser l’appairage – le mode appairage est actif pendant 3 minutes
Mets ton appareil en mode appairage selon la procédure du fabricant (pour une ampoule Lidl : allumer et éteindre rapidement 3 fois)
L’appareil apparaît dans Zigbee2MQTT
Va ensuite dans Home Assistant : Paramètres > Appareils et services > MQTT. Ton appareil doit être visible et contrôlable.
Note sur les ampoules Zigbee : une ampoule Zigbee doit rester alimentée en permanence pour rester joignable sur le réseau. Si tu coupes le courant via l’interrupteur mural, elle disparaît du réseau. La bonne pratique est de ne plus utiliser l’interrupteur physique et de contrôler l’ampoule uniquement via Home Assistant ou une télécommande Zigbee.
Ce que tu as maintenant
Un broker MQTT (Mosquitto) qui tourne en container Docker
Une passerelle Zigbee (Zigbee2MQTT) connectée à ton dongle et à Mosquitto
Home Assistant qui découvre automatiquement tous tes appareils Zigbee
Une base solide pour ajouter d’autres appareils : capteurs de température, détecteurs d’ouverture, interrupteurs Zigbee…
La prochaine étape : créer des automatisations pour que tes appareils Zigbee travaillent ensemble.
Il y avait une promo dans ma grande surface locale et La caméra Avidsen HomeCam 3PTZ (réf. 127165) était à 29.90 €. Je me suis dit que c’était l’occasion de tester l’utilisation d’une caméra de surveillance chez moi. Cette caméra est compatible avec l’écosystème Tuya. En passant par l’application Smart Life plutôt que l’app Avidsen native, tu peux l’intégrer directement dans Home Assistant et centraliser sa gestion avec le reste de ta domotique.
Ce qu’il te faut
La caméra Avidsen HomeCam 3PTZ
Une prise de courant à proximité et un réseau Wi-Fi 2,4 GHz
Un smartphone avec l’application Smart Life (Tuya)
Un ordinateur pour créer le compte développeur Tuya
Une instance Home Assistant fonctionnelle
Optionnel : une carte microSD classe 10 (ou U3), de préférence certifiée « Endurance », pour l’enregistrement local. Les caméras de sécurité réécrivent en boucle et usent rapidement les cartes standard.
1. Installer Smart Life et connecter la caméra
Télécharge l’application Tuya Smart Life sur ton smartphone. Crée un compte, puis ajoute la caméra en suivant les instructions de l’app : elle te demandera le mot de passe de ton Wi-Fi 2,4 GHz. Une fois connectée, tu peux piloter la caméra depuis n’importe où via l’application.
Utilise Smart Life plutôt que l’application Avidsen : elle offre plus de fonctionnalités et surtout elle est compatible avec Home Assistant.
2. Créer un compte développeur Tuya IoT
Depuis les dernières versions de Home Assistant, l’intégration Tuya officielle nécessite un compte développeur gratuit.
Crée un compte – utilise le même pays que celui configuré dans Smart Life.
Une fois connecté, va dans Cloud > Cloud Project > Cloud Project Management, puis clique sur Next.
Remplis le formulaire :
Project Name : Home Assistant
Industry : Smart Home
Development Method : Smart Home
Data Center : Central Europe Data Center (pour la France)
Clique sur Create, puis sur la page suivante laisse les API par défaut et clique sur Authorize.
3. Récupérer tes identifiants et lier Smart Life au projet
Sur la page de ton projet (onglet Overview), note ces deux informations – tu en auras besoin plus tard :
Access ID / Client ID
Access Secret / Client Secret
Ensuite, lie ton application Smart Life au projet :
Dans ton projet, clique sur l’onglet Devices, puis sur Link Tuya App Account.
Clique sur Add App Account – un QR code s’affiche.
Sur ton smartphone, ouvre Smart Life, tape sur le « + » en haut à droite, puis sur Scanner.
Scanne le QR code affiché sur ton ordinateur et valide sur le téléphone. Pour faire ça, il faut que tu ouvres l’application Smart Life dans ton téléphone. Tu te mets sur l’onglet Accueil (l’icône de maison en bas à gauche). Clique sur le petit bouton « + » tout en haut à droite de l’écran : un petit menu déroulant va s’ouvrir. clique sur l’icône de Scanner de QR Code.
Ta caméra apparaît maintenant dans la liste des appareils de la plateforme Tuya.
4. Activer l’intégration dans Home Assistant
Dans Home Assistant, va dans Paramètres > Appareils et services.
Clique sur Ajouter l’intégration et cherche Tuya.
Remplis le formulaire avec ton Access ID, ton Access Secret, et ton code utilisateur Smart Life.
Le code utilisateur se trouve dans l’app Smart Life : icône hexagone en haut à droite > Compte et Sécurité > Code Utilisateur. C’est un code court, respecte bien la casse.
Valide, scanne le QR code qui s’affiche, et confirme à nouveau.
Home Assistant importe automatiquement ta caméra. Tu peux accéder au flux vidéo et aux réglages directement depuis ton tableau de bord.
Pour aller plus loin
Contrôle PTZ depuis Home Assistant L’intégration Tuya affiche le flux vidéo mais ne crée pas toujours les contrôles de rotation. Tu peux y remédier avec des scripts YAML ou en installant la carte WebRTC Camera via HACS.
Alertes et notifications Avec l’application Home Assistant Companion sur ton téléphone, tu peux créer une automatisation YAML qui se déclenche sur détection de mouvement ou de son – et envoie une notification actionnable directement sur ton mobile.
Enregistrement vidéo La carte microSD gérée par Smart Life reste la solution la plus fiable pour l’enregistrement continu ou sur détection, en haute définition. Home Assistant gère les alertes ; Smart Life gère l’historique vidéo.
Ubuntu propose un outil officiel pour passer d’une version à la suivante sans tout effacer. Ce guide te montre comment faire, étape par étape, depuis le terminal.
Étape 1 : Sauvegarder tes données (recommandé)
Avant toute mise à niveau majeure du système, sauvegarde tes fichiers importants – documents, photos, fichiers de configuration – sur un disque externe ou dans le cloud.
Étape 2 : Mettre à jour le système actuel
Ta version actuelle d’Ubuntu doit être totalement à jour avant de lancer la mise à niveau.
Ouvre ton terminal (Ctrl + Alt + T) et lance cette commande :
apt update : actualise la liste des paquets disponibles (un « paquet », c’est l’équivalent d’une application ou d’un composant système sous Linux).
dist-upgrade : installe les mises à jour en gérant intelligemment les changements de dépendances (les dépendances, ce sont les composants dont un logiciel a besoin pour fonctionner).
autoremove : supprime les anciens paquets devenus inutiles.
Une fois terminé, redémarre ton ordinateur pour appliquer les changements – notamment si le noyau Linux (le coeur du système) a été mis à jour :
sudo reboot
Étape 3 : Configurer le type de mise à niveau souhaité
Ubuntu doit savoir quel type de version tu recherches. Ouvre le fichier de configuration avec cette commande :
sudo nano /etc/update-manager/release-upgrades
Repère la ligne qui commence par Prompt=. Tu as deux options :
Prompt=lts – recommandé
Te met à jour uniquement vers la prochaine version LTS (Long Term Support, support à long terme). Par exemple, de la 22.04 LTS à la 24.04 LTS, soit un changement tous les 2 ans environ.
Sécurité : maximale, tu reçois toutes les mises à jour de sécurité pour ta version actuelle.
Stabilité : maximale, tu changes de version du système rarement, ce qui réduit le risque de casser tes logiciels ou ta configuration.
Prompt=normal
Te propose toutes les versions stables, y compris les versions intermédiaires sorties tous les 6 mois.
Tu seras obligé de faire une mise à niveau majeure tous les 6 mois, car ces versions intermédiaires ne sont maintenues que pendant 9 mois. Passé ce délai, tu te retrouves avec un système obsolète et non sécurisé.
Changer de version deux fois par an augmente le risque de rencontrer des bugs ou des incompatibilités matérielles.
Modifie si nécessaire, puis sauvegarde avec Ctrl + O (puis Entrée) et quitte avec Ctrl + X.
Étape 4 : Lancer la mise à niveau
Maintenant que tout est prêt, lance l’outil officiel de mise à niveau d’Ubuntu :
sudo do-release-upgrade
Si aucune mise à niveau n’est détectée
Les versions LTS ne proposent parfois la mise à jour automatique qu’après la sortie de leur première version corrective (par exemple, la 24.04.1 plutôt que la 24.04). Dans ce cas, tu peux forcer la recherche avec l’option -d :
sudo do-release-upgrade -d
⚠️ Attention : l’option -d donne accès aux versions en accès anticipé, pas encore totalement stabilisées. À n’utiliser que si tu sais ce que tu fais et que tu as bien sauvegardé tes données au préalable.
Étape 5 : Suivre le processus et patienter
Le terminal t’affiche un résumé des changements prévus – paquets à installer, paquets à supprimer, taille du téléchargement – et te demande de confirmer avec o (pour Oui).
Pendant tout le processus :
Ne ferme pas le terminal.
Ne coupe pas ta connexion internet.
Si le système te demande si tu veux conserver tes fichiers de configuration modifiés ou installer les versions des nouveaux paquets, appuie sur Entrée pour garder le choix par défaut – c’est généralement la bonne option.
Cas particulier : connexion à distance via SSH
Si tu gères l’ordinateur à distance via SSH, do-release-upgrade ouvre automatiquement un port de secours (généralement le port 1022) en cas de coupure de connexion. Suis simplement les instructions affichées à l’écran.
Une fois le processus terminé, le terminal t’invite à redémarrer. Tu peux ensuite vérifier ta nouvelle version avec :
bash
lsb_release -a
Félicitations, tu es sur la nouvelle version stable d’Ubuntu !
Commentaires récents