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.
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.
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 sous Ubuntu :
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.
Commentaires récents