Open WebUI avec Ollama
connecter les deux en 5 minutes

Il y a trois raisons principales. Première raison : Ollama n’est pas en cours d’exécution. Vérifiez avec ollama list dans votre terminal — si Ollama ne répond pas, démarrez le service avec ollama serve. Sur macOS, l’app menubar doit être visible dans la barre système.

Deuxième raison : le flag –add-host est absent ou incorrect dans votre commande Docker. Sans ce flag, le conteneur Open WebUI ne peut pas atteindre le processus Ollama qui tourne sur votre machine hôte. Sur Linux, utilisez l’IP bridge Docker (172.17.0.1) plutôt que host.docker.internal.

Troisième raison : aucun modèle n’est téléchargé dans Ollama. La connexion peut être établie mais la liste de modèles est vide. Lancez ollama pull llama3.2 dans un terminal pour télécharger un premier modèle. Attendez la fin du téléchargement, puis rafraîchissez l’interface Open WebUI.

Oui, Open WebUI permet de configurer plusieurs connexions Ollama dans Admin Panel → Connections. Vous pouvez avoir une instance Ollama locale (pour les modèles courants) et une instance Ollama distante sur un serveur puissant (pour les grands modèles). Open WebUI agrège les modèles disponibles de toutes les connexions dans un seul menu de sélection.

Cette configuration est utile pour les équipes avec des besoins variés : un laptop qui fait tourner les modèles 7B pour les tâches quotidiennes, et un serveur avec GPU qui gère les modèles 70B pour les analyses complexes. Les utilisateurs choisissent simplement le modèle dans le menu sans se soucier du serveur qui le fait tourner.

La limite : si deux connexions Ollama proposent le même modèle (ex: Llama 3.2 sur deux serveurs), Open WebUI affiche les deux entrées séparément. Pour éviter la confusion, nommez vos connexions Ollama de façon explicite dans la configuration.

Ollama et llama.cpp sont deux outils pour faire tourner des LLMs en local, mais à des niveaux différents. llama.cpp est un moteur d’inférence de bas niveau, écrit en C++, qui peut compiler et exécuter des modèles GGUF directement. C’est très performant et très flexible, mais nécessite des connaissances techniques pour être utilisé.

Ollama est construit par-dessus llama.cpp (entre autres) et ajoute une couche de convivialité : un gestionnaire de modèles avec une bibliothèque en ligne, une API REST, et une CLI simple. Ollama est plus facile à utiliser au quotidien. Open WebUI est conçu pour se connecter à Ollama nativement.

Pour la plupart des utilisateurs en 2026, Ollama est le bon choix — il simplifie la gestion des modèles tout en donnant accès aux mêmes performances que llama.cpp. llama.cpp direct est utile pour les développeurs qui veulent intégrer un LLM dans une application existante ou tirer le maximum des performances hardware.

Oui, c’est même l’une des configurations les plus courantes en production en 2026. Ollama s’installe sur Linux en une ligne de commande (curl -fsSL https://ollama.com/install.sh | sh) et fonctionne comme un service systemd en arrière-plan. Aucune interface graphique n’est nécessaire.

Open WebUI en Docker sur le même serveur se connecte à Ollama via l’API REST. Les utilisateurs accèdent à Open WebUI depuis leur navigateur sur une autre machine — le serveur est headless (sans écran ni clavier), accessible uniquement via SSH et navigateur web.

C’est le setup idéal pour une PME : un mini-serveur (ou un VPS) Linux dans un coin, Ollama + Open WebUI en Docker, accessible par toute l’équipe depuis leur navigateur. Le serveur peut être administré à distance via SSH. Aucune interaction physique nécessaire après l’installation initiale.

Dans Admin Panel → Settings → Interface, vous pouvez définir le modèle par défaut sélectionné à l’ouverture d’une nouvelle conversation. Chaque utilisateur peut également choisir son propre modèle par défaut dans ses paramètres personnels.

Pour forcer un modèle par défaut pour tous les utilisateurs (par exemple si vous voulez que l’équipe utilise Mistral 7B par défaut), configurez-le dans les paramètres administrateur. Les utilisateurs peuvent toujours changer de modèle dans le menu déroulant de chat, mais le modèle par défaut s’applique à chaque nouvelle conversation.

Une bonne pratique pour les équipes : définissez le modèle le plus équilibré (Mistral 7B ou Llama 3.2 7B) comme défaut, et réservez les grands modèles (70B) pour les conversations spécifiques qui le nécessitent. Ça évite de charger inutilement le grand modèle pour des tâches simples et réduit les temps de réponse.

Oui, via deux approches. La première : si Ollama supporte le modèle (ce qui est le cas pour la majorité des modèles populaires Hugging Face en format GGUF), vous l’importez directement dans Ollama avec ollama pull hf.co/username/model-name. Ollama télécharge et convertit automatiquement.

La deuxième approche : pour les modèles non supportés par Ollama, vous pouvez utiliser un serveur d’inférence compatible API OpenAI comme vLLM, LM Studio en mode serveur, ou text-generation-inference de Hugging Face. Configurez ce serveur comme une connexion externe dans Open WebUI (Admin Panel → Connections → OpenAI API) et entrez l’URL du serveur local.

En pratique, 90% des modèles populaires sur Hugging Face sont disponibles directement via Ollama, ce qui est de loin la méthode la plus simple. Pour les modèles très récents ou très spécialisés qui ne sont pas encore sur Ollama, la méthode du serveur externe fonctionne mais demande plus de configuration.

Ollama en veille (aucune requête en cours) consomme peu de ressources : environ 50 à 100 MB de RAM et quasiment 0% de CPU. Le processus ollama serve tourne en arrière-plan mais reste inactif jusqu’à une requête.

Quand un modèle est chargé en mémoire (après une première requête), il reste en RAM pendant un délai de 5 minutes par défaut avant d’être déchargé. Ce comportement est configurable via la variable OLLAMA_KEEP_ALIVE. Pour libérer la RAM immédiatement après chaque conversation, définissez OLLAMA_KEEP_ALIVE=0. Pour garder le modèle chargé en permanence (temps de réponse optimal), définissez OLLAMA_KEEP_ALIVE=-1.

Sur une machine personnelle partagée entre Ollama et d’autres applications (retouche photo, jeu vidéo, développement), la configuration OLLAMA_KEEP_ALIVE=0 est recommandée pour ne pas monopoliser la RAM entre les sessions IA.

Trois leviers principaux. Premier levier : la RAM disponible. Plus vous avez de RAM, plus vous pouvez charger de grands modèles entièrement en mémoire. Un modèle qui déborde sur le swap disque est 10 à 100 fois plus lent qu’un modèle en RAM.

Deuxième levier : le choix du modèle et du niveau de quantification. Un modèle Q4_K_M (quantification 4-bit medium) est 2 à 4 fois plus rapide qu’un modèle Q8 (8-bit) avec une perte de qualité faible. La commande ollama pull mistral:7b-instruct-q4_K_M télécharge la version optimisée vitesse.

Troisième levier : le hardware. Apple Silicon (M1/M2/M3) est le hardware le plus efficace pour Ollama en 2026 — l’architecture mémoire unifiée permet au GPU Apple de traiter les tokens beaucoup plus vite qu’un CPU Intel ou AMD de même gamme. Un M2 Pro génère 30 tokens/seconde sur un modèle 7B, là où un Intel i7 moderne tourne à 5-8 tokens/seconde.

Open WebUI permet de sélectionner plusieurs modèles pour une même requête dans le mode ‘Arena’ (comparaison côte à côte). Vous envoyez le même message à Llama 3.3 et Mistral 7B simultanément et comparez leurs réponses. Utile pour évaluer la qualité de différents modèles sur vos cas d’usage spécifiques.

Dans le mode conversation normal, vous ne choisissez qu’un seul modèle par message. Vous pouvez cependant changer de modèle en cours de conversation via le menu déroulant — le contexte de la conversation est transmis au nouveau modèle qui reprend là où l’autre s’est arrêté.

Le mode Arena est particulièrement utile quand vous hésitez entre deux modèles pour un usage particulier. Testez vos 5 prompts les plus représentatifs de votre usage, comparez côte à côte, et choisissez en connaissance de cause. C’est beaucoup plus fiable que de lire des benchmarks génériques qui ne correspondent pas à vos cas d’usage réels.

Non, Open WebUI récupère dynamiquement la liste des modèles disponibles à chaque nouvelle conversation. Si vous ajoutez un modèle dans Ollama (ollama pull nouveau-modele) pendant qu’Open WebUI tourne, le nouveau modèle apparaît dans le menu de sélection sans redémarrage.

Parfois, le menu de modèles ne se rafraîchit pas immédiatement dans l’interface. Un simple rechargement de la page (F5 ou Cmd+R) force la récupération de la liste mise à jour. Dans de rares cas, cela peut prendre 1 à 2 minutes selon la configuration.

En revanche, si vous changez la configuration de connexion Ollama dans Admin Panel (URL, port), ou si vous ajoutez une nouvelle connexion Ollama, vous devez vérifier manuellement la connexion en cliquant sur le bouton Verify dans les paramètres. Cette vérification force Open WebUI à rafraîchir son état de connexion complet.