Open WebUI RAG
interroger vos documents internes en 2026

Open WebUI RAG supporte nativement en 2026 : PDF (y compris multi-pages), Word (.docx et .doc), Markdown (.md), texte brut (.txt), CSV et fichiers tabulaires, et les images via les modèles de vision (PNG, JPEG, WebP). Pour les images, un modèle vision comme llava ou minicpm-v doit être installé et configuré.

Les formats non supportés nativement : Excel (.xlsx), PowerPoint (.pptx), emails (.eml, .msg), et les PDF protégés par mot de passe. Pour Excel et PowerPoint, la solution est d’exporter en CSV ou PDF avant d’uploader. Pour les PDF protégés, vous devez retirer la protection en amont.

Un point important sur les PDF scannés (photographies de documents) : Open WebUI peut les ingérer mais la qualité de l’extraction dépend de la résolution du scan et de la qualité de l’OCR intégré. Pour des PDF scannés de mauvaise qualité, prétraitez avec un outil OCR externe (Tesseract, Adobe Acrobat) avant d’uploader dans Open WebUI.

nomic-embed-text est le modèle d’embedding par défaut d’Open WebUI. Il est rapide, léger (environ 274 MB), et donne de bons résultats sur l’anglais. Sur le français, il est correct mais pas optimisé — il a été entraîné majoritairement sur des données anglophones.

bge-m3 est un modèle d’embedding multilingue développé par le Beijing Academy of AI. Il est plus lourd (600 MB environ) mais offre des performances nettement meilleures sur le français et les autres langues non-anglophones. Si votre base documentaire est majoritairement en français, bge-m3 est le meilleur choix. L’alternative multilingual-e5-large est également excellente sur le français.

Pour changer de modèle d’embedding dans Open WebUI : Admin Panel → Documents → Embedding Model → sélectionnez votre nouveau modèle. Attention : changer le modèle d’embedding nécessite de réindexer tous vos documents existants — les vecteurs générés par nomic-embed-text ne sont pas compatibles avec bge-m3. Prévoyez le temps de réindexation selon la taille de votre base.

Trois leviers principaux. Premier levier : la qualité des documents source. Des documents bien structurés avec des titres clairs, des paragraphes courts et du texte extractible (pas des scans) donnent systématiquement de meilleurs résultats. Reformater vos documents avant de les ingérer est souvent plus efficace que toute optimisation de paramètres.

Deuxième levier : les paramètres de chunking. La taille par défaut de 1500 tokens fonctionne bien pour des textes continus. Pour des FAQ ou des procédures avec des réponses courtes, réduisez à 500-800 tokens pour des chunks plus précis. Pour des textes longs avec des idées qui s’étalent sur plusieurs paragraphes, montez à 2000-2500 tokens pour capturer le contexte.

Troisième levier : le nombre de chunks récupérés (Top-K). Le défaut est 5 chunks. Si vos réponses manquent de contexte, montez à 7 ou 10. Si les réponses mélangent des informations non liées, descendez à 3. Ajustez selon votre cas d’usage — une FAQ courte n’a pas besoin des mêmes paramètres qu’une analyse de contrat long.

Oui, complètement. C’est l’un des avantages majeurs par rapport aux solutions RAG cloud. Si vous utilisez Ollama avec des modèles téléchargés en local, le pipeline RAG complet (embedding, stockage ChromaDB, LLM) tourne entièrement sur votre machine sans connexion Internet.

Les seules dépendances réseau potentielles : si vous configurez Open WebUI pour utiliser une API externe (OpenAI, Groq, Together AI) comme backend LLM ou d’embedding, ces appels sortent de votre réseau. Mais si vous êtes 100% Ollama, vous pouvez couper Internet et tout continue de fonctionner normalement.

Pour les déploiements en environnement ultra-sécurisé ou air-gapped, Open WebUI + Ollama est la seule solution RAG sérieuse du marché en 2026 qui tourne entièrement hors ligne sans modification. Assurez-vous de télécharger tous vos modèles (LLM + embedding) avant de déconnecter le réseau.

Oui, Open WebUI propose un système de permissions sur les collections de documents. Chaque collection peut être configurée en : privée (accessible uniquement au créateur), partagée avec un groupe d’utilisateurs, ou publique (accessible à tous les utilisateurs du serveur).

La gestion des groupes se configure dans Admin Panel → Users → Groups. Vous créez des groupes (ex: ‘Comptabilité’, ‘Support’, ‘Direction’), assignez des utilisateurs à ces groupes, et donnez l’accès à des collections spécifiques à chaque groupe. La collection ‘Archives comptables’ visible uniquement par le groupe Comptabilité, la collection ‘FAQ produit’ accessible à tous.

Pour les équipes de plus de 50 utilisateurs, la gestion des permissions devient plus complexe à maintenir. La recommandation est de créer des collections thématiques plutôt que par utilisateur, et de limiter le nombre de groupes à ce qui est réellement nécessaire. Une structure simple (3 à 5 groupes maximum) est bien plus maintenable qu’une structure granulaire à 20 groupes.

Il n’y a pas de limite technique documentée sur le nombre de documents dans une collection Open WebUI. En pratique, j’ai testé des collections de 500 documents PDF sans problème de performance notable sur un laptop avec 16 GB de RAM. Au-delà de 2000 documents, les temps de réindexation et de recherche peuvent devenir perceptibles.

La limite pratique est souvent liée à la RAM disponible. ChromaDB charge les index en mémoire pour des recherches rapides. Une collection de 1000 documents moyens (200 pages chacun) peut consommer 2 à 4 GB de RAM selon le modèle d’embedding. Sur une machine avec 16 GB, vous avez de la marge confortable.

Pour de très grandes bases documentaires (10 000+ documents), envisagez de diviser en collections thématiques plus petites plutôt qu’une collection monolithique. La recherche dans des collections ciblées est plus précise et plus rapide qu’une recherche dans une immense collection fourre-tout.

Oui, Open WebUI peut ingérer le contenu de pages web via l’URL directement dans l’interface RAG. Entrez l’URL dans la zone d’upload de document, et Open WebUI va fetcher le contenu de la page, l’extraire et l’indexer comme n’importe quel autre document.

La qualité de l’extraction dépend de la structure de la page web. Les pages avec du contenu textuel propre (articles de blog, documentation technique) donnent de bons résultats. Les pages très chargées en JavaScript dynamique ou en contenu interactif peuvent donner des extractions incomplètes, car Open WebUI extrait le HTML statique sans exécuter le JavaScript.

Pour les sites qui nécessitent une authentification ou qui bloquent les bots, l’extraction directe par URL ne fonctionnera pas. La solution est d’exporter le contenu en PDF ou Markdown depuis votre navigateur puis d’uploader le fichier. Pour les documentations techniques, beaucoup de sites proposent une version PDF téléchargeable qui s’intègre parfaitement dans le RAG.

La base RAG d’Open WebUI est stockée dans le volume Docker nommé open-webui. Pour sauvegarder, utilisez : docker run –rm -v open-webui:/source -v $(pwd):/backup busybox tar czf /backup/open-webui-backup.tar.gz /source. Cette commande crée une archive complète qui inclut les vecteurs ChromaDB, vos fichiers uploadés et toute la configuration.

Pour restaurer : créez un volume vide, décompressez l’archive dans ce volume, puis relancez le conteneur Open WebUI qui pointe sur ce volume restauré. La restauration prend quelques minutes selon la taille de la base. Vos collections, documents et conversations sont entièrement récupérés.

Pour la production, scriptez cette sauvegarde en cron quotidien avec rotation sur 30 jours, et copiez les archives vers un stockage externe (S3, Backblaze B2, ou un NAS local). En cas de perte du serveur, vous pouvez recréer toute votre base RAG en 15 minutes depuis la dernière sauvegarde.

En 2026, Open WebUI RAG fonctionne très bien en français sous conditions. Le modèle d’embedding par défaut nomic-embed-text donne des résultats corrects sur le français, suffisants pour de nombreux usages. Pour des performances optimales sur du contenu exclusivement ou majoritairement français, bge-m3 ou multilingual-e5-large sont les meilleurs choix.

Pour le LLM qui génère les réponses, Mistral 7B est la meilleure référence francophone en local en 2026. Llama 3.3 70B (nécessite une machine puissante) et Qwen 2.5 32B sont également très bons en français. Évitez les modèles plus anciens ou trop petits qui ont des faiblesses notables en français.

Un conseil pratique pour le RAG en français : lors de l’upload de documents, assurez-vous que l’encodage est UTF-8 (c’est le cas pour les PDF modernes mais peut poser problème pour d’anciens fichiers Word). Les problèmes d’encodage se traduisent par des caractères mal interprétés dans les chunks, ce qui dégrade la qualité des embeddings et des réponses.

Open WebUI RAG est recommandé quand : la confidentialité des documents est critique (données clients, brevets, documents RH sensibles), vous avez un volume important de documents à moindre coût (pas de token billing sur les embeddings locaux), vous voulez un contrôle total sur l’infrastructure et les données, ou votre organisation a des contraintes légales sur la localisation des données (RGPD, secteur médical, défense).

Les solutions RAG cloud (OpenAI Assistants, Anthropic avec Claude Projects, Notion AI) sont recommandées quand : la simplicité de déploiement prime sur la confidentialité (pas de serveur à gérer), vous avez de petits volumes de documents et un budget, la qualité des modèles cloud est nécessaire pour votre cas d’usage, ou vous n’avez pas de ressources techniques pour maintenir l’infrastructure.

Pour les TPE et PME françaises, le facteur décisif est souvent le RGPD : si vos documents contiennent des données personnelles de clients ou d’employés, les envoyer vers des serveurs américains peut poser des problèmes de conformité. Open WebUI RAG sur un serveur en France élimine ce risque entièrement. Pour les cas sans contrainte réglementaire forte, les solutions cloud sont plus simples à démarrer.