OpenWebUI : interface ChatGPT-like self-hosted — déploiement 2026

📍 Article principal du cluster : LLM en self-hosted pour PME francophone : OpenWebUI, LiteLLM, vLLM (2026)
Cet article fait partie du cluster cluster-llm-selfhost. Pour la vue d’ensemble architecturale, commencez par le pilier.

Introduction

Vous travaillez dans une PME à Dakar, Abidjan ou Cotonou. Vous avez entendu parler de ChatGPT, mais l’accès est instable, les prix facturés en dollars rognent le budget, et les données clients ne peuvent pas quitter votre infrastructure. OpenWebUI est la réponse : une interface web quasi-identique à ChatGPT, que vous installez sur votre propre serveur en moins de 30 minutes, connectée à des modèles open-source comme Mistral ou Qwen, sans envoyer une seule requête à l’étranger. Ce tutoriel vous guide pas à pas du déploiement Docker à la gestion multi-utilisateurs, en passant par le RAG sur vos documents internes et l’adaptation au contexte technique de l’Afrique de l’Ouest.

Prérequis

• Système : Ubuntu 22.04/24.04 LTS (ou Debian 12). Fonctionne aussi sur Windows/macOS via Docker Desktop.
• RAM minimale : 4 Go pour OpenWebUI seul. 8 Go recommandés si vous co-localisez Ollama sur la même machine.
• Docker : version 24+ et Docker Compose v2. Installation : docs.docker.com/engine/install/ubuntu
• Ollama (optionnel) : si vous souhaitez faire tourner des modèles locaux. Installation séparée via ollama.com
• Niveau : intermédiaire — connaître les bases de la ligne de commande Linux et de Docker.
• Temps estimé : 30 minutes pour un déploiement de base, 1h30 pour la configuration complète avec RAG et multi-utilisateurs.

Étape 1 — Architecture OpenWebUI : comprendre les briques avant de déployer

Avant de lancer la moindre commande, il est utile de comprendre ce que vous allez installer. OpenWebUI n’est pas un modèle d’IA en soi : c’est une interface graphique qui s’intercale entre vous et des moteurs d’inférence. Connaître l’architecture vous évitera des heures de débogage.

OpenWebUI est découpé en deux couches distinctes. Le frontend est une application Svelte compilée en SPA (Single Page Application) : c’est l’interface que l’utilisateur voit dans son navigateur, avec les fils de conversation, la gestion des fichiers et les réglages. Le backend est une API FastAPI (Python) qui orchestre tout : elle reçoit les requêtes du frontend, les route vers le bon moteur LLM (Ollama local, API OpenAI, API Anthropic, ou tout service compatible OpenAI), gère l’authentification, stocke les historiques dans une base SQLite, et pilote ChromaDB pour le RAG.

Cette séparation est importante : vous pouvez tout à fait déployer uniquement OpenWebUI sans Ollama, et vous connecter exclusivement aux API cloud (OpenAI, Mistral, Anthropic). Inversement, vous pouvez avoir Ollama sans OpenWebUI — mais vous perdez alors l’interface graphique et la gestion d’équipe. Les deux composants se complètent mais ne sont pas dépendants l’un de l’autre au niveau du processus.

En termes de stockage, OpenWebUI maintient un volume Docker persistant (/app/backend/data) qui contient la base SQLite (historiques, utilisateurs, paramètres), les fichiers uploadés pour le RAG, et la base vectorielle ChromaDB. Ce volume est le seul élément critique à sauvegarder régulièrement.

Étape 2 — Déployer OpenWebUI via Docker

Docker est le mode de déploiement recommandé par le projet car il isole proprement les dépendances Python et garantit une reproductibilité entre environnements. La commande ci-dessous déploie OpenWebUI en mode autonome, sans Ollama — vous brancherez les backends dans les étapes suivantes.

Ouvrez un terminal sur votre serveur et exécutez :

docker run -d \
  -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Décortiquons chaque argument. Le flag -d lance le conteneur en arrière-plan (daemon mode). Le -p 3000:8080 expose le port 8080 interne du conteneur sur le port 3000 de votre hôte — vous accéderez donc à l’interface via http://votre-ip:3000. L’argument --add-host=host.docker.internal:host-gateway est fondamental : il permet au conteneur Docker de joindre les services qui tournent directement sur l’hôte (comme Ollama), en résolvant le nom host.docker.internal vers l’IP de la machine hôte. Sans cet argument, la connexion à Ollama échouera systématiquement. Le volume -v open-webui:/app/backend/data persiste toutes les données entre les redémarrages du conteneur. Enfin, --restart always garantit que le conteneur redémarre automatiquement après un reboot du serveur.

Après une vingtaine de secondes, ouvrez votre navigateur sur http://localhost:3000 (ou http://IP_DU_SERVEUR:3000 si vous déployez sur un VPS). Vous verrez un formulaire d’inscription : le premier compte créé est automatiquement administrateur. Notez bien ces identifiants — ils sont stockés localement dans le volume Docker.

Variante Docker Compose (recommandée pour la production)

Pour un déploiement plus maintenable, créez un fichier docker-compose.yml dans un répertoire dédié (par exemple ~/openwebui/) :

version: '3.8'
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - open-webui-data:/app/backend/data
    environment:
      - WEBUI_SECRET_KEY=changez-moi-par-une-chaine-aleatoire-longue
    restart: always

volumes:
  open-webui-data:

Lancez avec docker compose up -d. La variable WEBUI_SECRET_KEY sert à signer les tokens JWT de session — changez-la impérativement en production avec une chaîne aléatoire de 32+ caractères (par exemple via openssl rand -hex 32). Sans cette précaution, n’importe qui connaissant la clé par défaut pourrait forger des tokens d’authentification valides.

Étape 3 — Connecter Ollama local pour les modèles open-source

Ollama est un moteur d’inférence léger qui télécharge et exécute des modèles LLM open-source (Mistral, Qwen, Llama, Gemma…) directement sur votre machine. L’intégrer à OpenWebUI vous donne une solution entièrement hors-ligne : aucune donnée ne quitte votre serveur, aucun abonnement requis. C’est le scénario idéal pour les PME soucieuses de confidentialité ou opérant dans des zones à connectivité limitée.

Installez d’abord Ollama sur l’hôte (pas dans Docker) via le script officiel :

curl -fsSL https://ollama.com/install.sh | sh

Une fois installé, Ollama expose automatiquement une API HTTP sur le port 11434 de l’hôte. Pour télécharger un premier modèle, par exemple Mistral 7B :

ollama pull mistral

Retournez dans OpenWebUI. Naviguez vers Paramètres Admin → Connexions → Ollama. L’URL à renseigner est http://host.docker.internal:11434 — grâce au flag --add-host que vous avez ajouté au démarrage du conteneur, cette URL résout bien vers Ollama sur la machine hôte. Cliquez sur le bouton de test : vous devriez voir un message de succès et la liste des modèles téléchargés apparaître automatiquement dans le sélecteur de conversation.

Si le test échoue avec une erreur de connexion refusée, vérifiez que le service Ollama est bien actif (systemctl status ollama) et que le pare-feu ne bloque pas le port 11434 en local (ufw allow from 172.17.0.0/16 to any port 11434 pour autoriser le réseau Docker bridge).

Étape 4 — Connecter les API OpenAI ou Anthropic via clé

Même si vous privilégiez les modèles locaux, il est souvent utile de garder un accès aux API cloud pour les tâches exigeant les modèles les plus puissants (analyse contractuelle complexe, rédaction longue, code avancé). OpenWebUI prend en charge nativement les API d’OpenAI et de tout service compatible — y compris Anthropic, Mistral AI cloud, ou votre propre LiteLLM gateway.

Pour OpenAI, deux méthodes existent. La première consiste à injecter la clé au démarrage du conteneur via une variable d’environnement — pratique pour l’automatisation :

docker run -d \
  -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  -e OPENAI_API_KEY=sk-votre-cle-openai \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

La seconde méthode, plus flexible en production, passe par l’interface admin : Paramètres Admin → Connexions → OpenAI API. Vous y collez votre clé et l’URL de base (https://api.openai.com/v1 pour OpenAI natif). Cette approche vous permet de modifier la clé sans redémarrer le conteneur et de basculer facilement entre fournisseurs.

Pour Anthropic (Claude), la procédure est identique mais l’URL de base change selon votre passerelle. Si vous utilisez LiteLLM comme proxy (voir le tutoriel frère consacré à LiteLLM dans ce cluster), renseignez l’URL de votre instance LiteLLM locale — celui-ci traduit automatiquement le format OpenAI vers le format Anthropic. C’est la méthode recommandée pour une PME qui veut un point d’entrée unique gérant plusieurs fournisseurs.

Une fois les connexions configurées, tous les modèles disponibles (locaux Ollama + cloud API) apparaissent dans le même sélecteur de modèle, côte à côte, dans chaque conversation. L’utilisateur final ne voit aucune différence d’interface entre un modèle local et un modèle cloud.

Étape 5 — RAG : interroger vos documents internes

Le RAG (Retrieval-Augmented Generation) est l’une des fonctionnalités les plus précieuses d’OpenWebUI pour les PME : il vous permet de poser des questions en langage naturel sur vos propres documents — contrats, fiches techniques, politiques internes, bases de connaissances — sans jamais envoyer ces documents sur un serveur externe. OpenWebUI intègre ChromaDB comme base vectorielle embarquée, activée par défaut sans aucune configuration supplémentaire.

Pour indexer un document, cliquez sur l’icône de trombone dans la zone de saisie d’une conversation et uploadez votre fichier. OpenWebUI accepte les formats PDF, TXT, DOCX, Markdown, HTML et CSV. Le fichier est automatiquement découpé en chunks sémantiques, converti en vecteurs via le modèle d’embedding configuré (par défaut nomic-embed-text via Ollama, ou le modèle d’embedding OpenAI si vous préférez), puis stocké dans ChromaDB. La prochaine question que vous posez dans cette conversation exploitera les passages pertinents du document comme contexte supplémentaire.

Pour une base de documents partagée entre tous les utilisateurs, utilisez la section Espace de travail → Base de connaissances (Knowledge Base). Vous y créez des collections thématiques — par exemple « Contrats fournisseurs » ou « Documentation technique produit » — que vous alimentez en bulk. N’importe quelle conversation peut ensuite appeler une collection en tapant #nom-de-la-collection dans le champ de saisie.

Du côté administration, les paramètres RAG sont accessibles dans Admin → Paramètres → Documents. Vous pouvez y configurer la taille maximale des fichiers (RAG_FILE_MAX_SIZE), le nombre maximal de fichiers par upload (RAG_FILE_MAX_COUNT), et les extensions autorisées (RAG_ALLOWED_FILE_EXTENSIONS). Pour des corpus importants (plusieurs milliers de documents), il est recommandé de basculer ChromaDB embarqué vers une instance ChromaDB externe ou d’utiliser PGVector si vous disposez déjà d’une infrastructure PostgreSQL.

Étape 6 — Multi-utilisateurs et gestion des permissions (RBAC)

Dans un contexte PME avec plusieurs équipes, la gestion fine des accès est non-négociable. OpenWebUI implémente un système RBAC (Role-Based Access Control) à trois niveaux qui couvre la majorité des besoins organisationnels sans nécessiter de configuration complexe.

Les trois rôles système sont les suivants. Le rôle Admin dispose d’un accès total à toutes les ressources et configurations — gestion des utilisateurs, choix des modèles disponibles, paramètres globaux. Il contourne la plupart des vérifications de permissions par conception. Le rôle User est le rôle fonctionnel standard : il n’a aucun accès implicite, toutes ses capacités doivent être explicitement accordées via les permissions par défaut globales ou via des groupes. Le rôle Pending est l’état initial des nouveaux inscrits quand l’inscription ouverte est activée : zéro accès, en attente d’approbation d’un administrateur. Ce mécanisme vous permet d’ouvrir les inscriptions sans risque d’accès immédiat non contrôlé.

Le modèle de permissions est additif : un utilisateur cumule les droits de son rôle de base et de tous les groupes auxquels il appartient. Il n’y a pas de mécanisme de refus explicite — si un droit est accordé par n’importe quel groupe, il s’applique. Pour restreindre des utilisateurs à certains modèles uniquement, rendez-vous dans Admin → Modèles et configurez la visibilité de chaque modèle par rôle ou par groupe. Par exemple, vous pouvez rendre GPT-4o visible uniquement au groupe « Direction » et Mistral 7B accessible à tous.

Pour créer un nouveau groupe : Admin → Groupes → Nouveau groupe. Donnez-lui un nom (ex : « Équipe commerciale »), ajoutez les membres, puis cochez les permissions souhaitées (accès web search, upload de fichiers, création de modèles personnalisés, etc.). Cette organisation en groupes est préférable à la gestion utilisateur par utilisateur dès que l’équipe dépasse cinq personnes.

Étape 7 — Charger les modèles français : Mistral et Qwen

Les développeurs et PME francophones bénéficient d’une situation favorable en 2026 : plusieurs modèles open-source performants en français sont disponibles sur Ollama sans aucune configuration supplémentaire. Voici les deux incontournables.

Mistral 7B est développé par Mistral AI, une société française basée à Paris. C’est historiquement le modèle open-source le plus efficace par rapport à sa taille, avec d’excellentes performances en français. Sa commande de téléchargement :

ollama pull mistral

Il requiert environ 4,1 Go de stockage et fonctionne sur une machine avec 8 Go de RAM, avec un CPU suffisant pour une inférence lente mais utilisable. Pour une version plus récente et plus polyvalente, mistral-small3.1 améliore le raisonnement et le suivi d’instructions :

ollama pull mistral-small3.1

Qwen2.5 (développé par Alibaba) supporte nativement 29 langues dont le français, avec des performances remarquables sur les tâches de code et d’analyse de texte. Il existe en plusieurs tailles adaptées à différentes configurations matérielles :

# Version 7B — bon équilibre performance/ressources (8 Go RAM)
ollama pull qwen2.5:7b

# Version 3B — pour machines 4 Go RAM uniquement
ollama pull qwen2.5:3b

# Version 14B — pour serveurs 16 Go RAM+, meilleure qualité
ollama pull qwen2.5:14b

Une fois le pull terminé, retournez dans OpenWebUI : les nouveaux modèles apparaissent automatiquement dans le sélecteur sans redémarrage. Vous pouvez tester en démarrant une conversation et en demandant : « Explique-moi le droit OHADA en deux paragraphes » — les deux modèles produiront une réponse en français de bonne qualité. Pour les tâches de raisonnement avancé, Qwen2.5:14b surpasse généralement Mistral 7B mais consomme significativement plus de RAM.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les entreprises et développeurs en Afrique de l’Ouest, OpenWebUI répond à un besoin concret qui va au-delà de la simple curiosité technologique. L’accès à ChatGPT reste inégal selon les pays : certains opérateurs filtrent les connexions vers les serveurs d’OpenAI en période de forte congestion, les abonnements payants en dollars représentent un coût disproportionné pour une PME factuelle en FCFA, et les équipes travaillant sur des dossiers sensibles (droit des affaires, marchés publics, données clients) ne peuvent tout simplement pas confier leurs informations à des serveurs hors-juridiction. OpenWebUI self-hosted résout les trois problèmes simultanément.

Pour l’hébergement, le VPS Hetzner CX22 (2 vCPU AMD, 4 Go RAM, 40 Go NVMe, ~€3.79/mois après la hausse tarifaire d’avril 2026) constitue le plancher viable pour OpenWebUI seul — assez pour l’interface et les appels API cloud, insuffisant pour faire tourner Ollama en parallèle. Si votre équipe utilise principalement les API OpenAI ou Mistral cloud, ce format suffit. Pour les modèles locaux, visez le CX32 (8 Go RAM, ~€8/mois) ou le CAX21 ARM (8 Go, souvent moins cher). Des alternatives africaines commencent à émerger — Africa Cloud (Côte d’Ivoire), Camcloud (Cameroun) — mais leur offre reste limitée en 2026 ; pour les charges LLM, les VPS européens restent le choix pragmatique.

La bande passante est un paramètre critique souvent sous-estimé. Un premier téléchargement de Mistral 7B pèse environ 4 Go : sur une connexion fibre entreprise en capital, comptez 10 à 20 minutes ; sur une connexion ADSL partagée, prévoyez le téléchargement de nuit. Une fois le modèle stocké dans le volume Docker, il n’est plus retéléchargé — l’inférence locale est entièrement hors-ligne. Planifiez également des sauvegardes régulières du volume open-webui-data vers un stockage objet S3-compatible (Scaleway Object Storage propose des tarifs abordables en euros).

Sur le plan réglementaire, l’ARTCI (Autorité de Régulation des Télécommunications de Côte d’Ivoire) et les régulateurs équivalents au Sénégal (ARTP), au Mali (AMRTP) imposent une localisation croissante des données personnelles. Déployer OpenWebUI sur un serveur dont vous contrôlez la localisation vous permet de répondre à ces exigences, à condition de documenter où sont stockés les volumes Docker dans votre politique de traitement des données. Enfin, pour les cabinets juridiques et comptables travaillant avec le droit OHADA, OpenWebUI + Ollama + Qwen ouvre la voie à un fine-tuning sur corpus OHADA (les traités et actes uniformes sont publics sur ohada.com) : un modèle affiné sur ce corpus pourrait répondre à des questions de droit des sociétés avec une pertinence contextuelle inaccessible aux modèles généralistes non spécialisés.

Tutoriels frères

• LiteLLM : proxy unifié pour vos API LLM — déploiement PME 2026 — configurer un point d’entrée unique pour OpenAI, Anthropic, Mistral et Ollama
• vLLM : inférence GPU haute performance sur VPS — tutoriel 2026 — remplacer Ollama par vLLM pour des débits de tokens 3× à 5× supérieurs

Pour aller plus loin

• 🔝 Retour au pilier : LLM en self-hosted pour PME francophone : OpenWebUI, LiteLLM, vLLM (2026)
• Documentation officielle OpenWebUI : docs.openwebui.com
• Dépôt GitHub (étoiles, issues, releases) : github.com/open-webui/open-webui
• Bibliothèque de modèles Ollama : ollama.com/library
• Leaderboard des modèles OpenWebUI (données usage réel) : openwebui.com/leaderboard

FAQ

Q : OpenWebUI est-il gratuit et open-source ?
R : Oui, OpenWebUI est distribué sous licence MIT, entièrement gratuit, sans limitation de fonctionnalités ni de nombre d’utilisateurs. Le code source est disponible sur github.com/open-webui/open-webui. Il n’y a pas de version « cloud payante » officielle imposée — vous hébergez vous-même et gardez un contrôle total.

Q : Peut-on utiliser OpenWebUI sans connexion Internet une fois installé ?
R : Oui, si vous n’utilisez que des modèles locaux via Ollama. Une fois les modèles téléchargés et stockés dans le volume Docker, l’ensemble du système fonctionne entièrement hors-ligne. Les fonctionnalités qui nécessitent Internet sont : les appels aux API cloud (OpenAI, Anthropic), la recherche web intégrée, et les mises à jour de l’image Docker. Pour une PME en zone à connectivité instable, cette résilience est un avantage décisif.

Q : Quelle est la différence entre OpenWebUI et Ollama ?
R : Ollama est uniquement un moteur d’inférence — il télécharge et exécute des modèles LLM, et expose une API HTTP. Il n’a pas d’interface graphique utilisable en équipe. OpenWebUI est l’interface web qui se pose devant Ollama (ou devant n’importe quelle API compatible OpenAI) : gestion des conversations, historiques, RAG, multi-utilisateurs, permissions. Les deux se complètent mais peuvent fonctionner indépendamment.

Q : Comment mettre à jour OpenWebUI vers une nouvelle version ?
R : Avec Docker, la mise à jour se fait en trois commandes qui remplacent l’image sans toucher au volume de données :
docker pull ghcr.io/open-webui/open-webui:main
docker stop open-webui && docker rm open-webui
Puis relancer la commande docker run initiale. Le volume open-webui est préservé — historiques, utilisateurs et paramètres sont intacts. En Docker Compose : docker compose pull && docker compose up -d suffit.

Q : OpenWebUI supporte-t-il l’authentification SSO (LDAP, OAuth, SAML) ?
R : Oui. Depuis les versions récentes 0.8.x, OpenWebUI supporte OAuth2 / OpenID Connect, permettant l’intégration avec Google Workspace, Microsoft Entra ID (anciennement Azure AD), Keycloak ou tout fournisseur d’identité OIDC standard. La configuration se fait dans Admin → Paramètres → Auth → OAuth. Pour les PME utilisant déjà Google Workspace, c’est la méthode recommandée pour éviter la gestion des mots de passe locaux.

Q : Combien d’utilisateurs simultanés OpenWebUI peut-il gérer ?
R : Le goulot d’étranglement n’est pas l’interface mais le backend LLM. OpenWebUI lui-même (FastAPI + SQLite) gère facilement 50 à 100 utilisateurs simultanés sur un VPS modeste. La vraie limite est le nombre de requêtes d’inférence parallèles que votre moteur LLM peut absorber. Avec Ollama sur CPU, comptez 1 à 2 inférences simultanées réalistes ; avec vLLM sur GPU, ce chiffre monte à plusieurs dizaines. Pour une équipe de 10 à 30 personnes avec des usages non simultanés, un VPS 8 Go RAM + Mistral 7B est généralement suffisant.

Q : Mes données de conversation sont-elles en sécurité ?
R : Avec un déploiement self-hosted, vous êtes l’unique responsable de la sécurité. OpenWebUI stocke les conversations dans SQLite sur le volume Docker local — elles ne sont envoyées nulle part sauf si vous utilisez une API cloud (OpenAI, Anthropic). Pour sécuriser l’accès, placez impérativement OpenWebUI derrière un reverse proxy Nginx avec HTTPS (Let’s Encrypt), définissez un WEBUI_SECRET_KEY fort, et restreignez l’accès au port 3000 via UFW si le serveur est exposé publiquement.

Site réalisé par [ITS] ITSkillsCenter