Installer Open WebUI
sur Windows, Mac ou Linux en 2026

Docker dans 90% des cas, pip pour les développeurs Python avancés. Docker isole complètement Open WebUI de votre système, garantit la reproductibilité sur tous les OS, et rend les mises à jour atomiques (un docker pull, un redémarrage). Si quelque chose ne va pas, supprimez le conteneur et recommencez — pas de résidus dans votre système.

pip (installation native Python) consomme moins de RAM (~150 MB de moins) et peut être plus rapide sur les machines modestes. Mais elle mélange les dépendances avec vos autres projets Python, peut conflicuter avec d’autres packages, et les mises à jour peuvent être moins propres. Réservez pip aux développeurs qui savent gérer les environnements virtuels Python.

Un cas particulier où pip est préférable : si vous développez des plugins ou des extensions pour Open WebUI, travailler avec un environnement Python natif facilite le debugging. Pour tous les autres cas d’usage (utiliser Open WebUI, pas le développer), Docker est la meilleure option.

Oui, Open WebUI lui-même fonctionne sur n’importe quelle machine. La contrainte GPU concerne Ollama et les modèles LLM : sans GPU, les modèles tournent sur le CPU, ce qui est 5 à 50 fois plus lent selon le modèle et le CPU.

En pratique sans GPU : les modèles 7B quantifiés (Llama 3.2 3B, Mistral 7B Q4) génèrent 2 à 10 tokens par seconde sur un CPU Intel ou AMD récent. C’est lent mais utilisable pour un usage personnel non-temps-réel. Sur Apple Silicon (M1, M2, M3), le GPU intégré unifié accélère significativement les inférences — les Mac M-series sont excellents pour Ollama sans GPU dédié.

Si vous n’avez pas de GPU NVIDIA mais voulez des performances correctes, un Mac avec Apple Silicon (M2 minimum, 16 GB RAM) est le meilleur investissement en 2026 pour l’IA locale. L’architecture unifiée mémoire donne des performances proches d’un GPU NVIDIA milieu de gamme pour les modèles 7B à 13B.

Open WebUI peut être installé sur certains Chromebooks via Linux (Crostini), la couche Linux disponible sur les Chromebooks récents. La démarche : activez Linux dans les paramètres du Chromebook, installez Docker dans cet environnement Linux, et lancez Open WebUI normalement.

Les limitations sont significatives sur Chromebook : la RAM disponible pour Linux est généralement limitée (2 à 4 GB), les modèles LLM 7B nécessitent 8 GB minimum, et les performances CPU des Chromebooks d’entrée de gamme sont insuffisantes pour un usage confortable. Sur un Chromebook haut de gamme avec 16 GB de RAM (Pixelbook, Framework Chromebook), c’est faisable.

Ma recommandation : si vous avez un Chromebook comme seul ordinateur, connectez Open WebUI à une API cloud externe (OpenAI, Groq) plutôt que d’essayer de faire tourner des modèles en local. Vous bénéficiez de l’interface d’Open WebUI sans la contrainte hardware.

Par défaut, Open WebUI écoute sur localhost:3000 et n’est accessible que depuis la machine où il tourne. Pour y accéder depuis d’autres appareils du réseau local, ajoutez -e WEBUI_URL=http://VOTRE_IP_LOCALE:3000 à la commande Docker et remplacez -p 3000:8080 par -p 0.0.0.0:3000:8080.

Pour trouver votre IP locale : ipconfig sur Windows (valeur IPv4), ifconfig sur Mac/Linux (valeur inet), ou regardez dans les paramètres réseau. Exemple : http://192.168.1.42:3000 accessible depuis n’importe quel appareil sur votre réseau WiFi.

Important : cette configuration expose Open WebUI sur votre réseau local sans HTTPS. Pour un usage familial en réseau local privé, c’est acceptable. Pour un usage professionnel ou un accès depuis Internet, configurez un reverse proxy avec HTTPS (Caddy ou Nginx + Let’s Encrypt). Ne laissez jamais Open WebUI accessible sur Internet sans authentification et HTTPS.

Avec Docker, la mise à jour prend 3 commandes : docker pull ghcr.io/open-webui/open-webui:main pour télécharger la nouvelle image, docker stop open-webui pour arrêter le conteneur actuel, docker rm open-webui pour supprimer l’ancien conteneur, puis relancez la commande docker run originale. Vos données sont dans le volume open-webui et ne sont pas affectées.

Un script de mise à jour automatique plus propre : docker stop open-webui && docker rm open-webui && docker pull ghcr.io/open-webui/open-webui:main && docker run [vos paramètres]. Sauvegardez ce script dans un fichier update.sh pour un usage répété.

Bonne pratique : vérifiez le changelog GitHub avant chaque mise à jour majeure. Les mises à jour mineures (bugfixes) sont généralement sûres à appliquer immédiatement. Les mises à jour majeures peuvent changer des comportements ou nécessiter une migration de configuration.

Deux options : un conteneur séparé pour chacun (recommandé) ou un conteneur bundle qui inclut les deux (image :ollama). Le conteneur séparé est préférable en production : vous pouvez mettre à jour Open WebUI et Ollama indépendamment, redémarrer l’un sans affecter l’autre, et mieux isoler les ressources.

L’image bundle :ollama est pratique pour un premier test rapide ou un déploiement sur une machine avec peu de ressources. La commande est plus courte et vous n’avez pas à gérer deux conteneurs. L’inconvénient : mettre à jour l’un nécessite de reconstruire tout le bundle.

Pour un déploiement durable (usage personnel ou équipe), utilisez des conteneurs séparés avec Docker Compose. Un fichier docker-compose.yml versionné dans Git qui orchestre Open WebUI + Ollama + leurs volumes est la configuration la plus maintenable et la plus évolutive.

Oui. Open WebUI peut fonctionner sans Ollama si vous le connectez à des APIs externes comme OpenAI, Groq, Together AI, ou n’importe quel endpoint OpenAI-compatible. Dans ce cas, ajoutez -e OPENAI_API_KEY=sk-... à votre commande Docker, et vous pouvez chatter avec GPT-4o depuis l’interface Open WebUI.

Cette configuration perd l’avantage principal d’Open WebUI (la confidentialité des modèles locaux) mais garde les avantages de l’interface : RAG, multi-utilisateurs, gestion des conversations, support MCP. C’est une option valide si vous voulez une interface plus puissante que ChatGPT.com pour vos API keys existantes.

Une configuration hybride est possible : Open WebUI connecté à Ollama en local ET à OpenAI en cloud. Vous choisissez le modèle selon la tâche dans le dropdown de conversation. Les conversations locales restent privées, les conversations cloud passent par OpenAI. C’est la configuration que je recommande pour les power users.

Open WebUI lui-même (le serveur web) consomme environ 300 à 500 MB de RAM. C’est léger. La consommation importante vient d’Ollama et des modèles LLM : un modèle Llama 3.2 3B charge environ 2 GB en RAM, un Mistral 7B charge 4 à 5 GB, un Llama 3.3 70B nécessite 40 GB.

En pratique sur une machine avec 16 GB : Open WebUI (500 MB) + Ollama (300 MB) + Llama 3.2 3B (2 GB) = moins de 3 GB pour l’ensemble. Vous avez largement de la marge. C’est Mistral 7B qui commence à peser : 5 GB pour le modèle + overheads = 6 à 7 GB. Sur une machine avec 8 GB, c’est tendu mais faisable avec le bon modèle.

Le modèle reste chargé en RAM tant qu’Ollama tourne — même entre les conversations. C’est intentionnel pour des temps de réponse rapides. Si vous voulez libérer la RAM (pour faire de la retouche photo ou du jeu vidéo en parallèle), arrêtez le service Ollama : ollama stop nom-du-modele ou sudo systemctl stop ollama sur Linux.

L’installation d’Open WebUI derrière un VPN corporate peut rencontrer des blocages : le proxy peut interférer avec le téléchargement de l’image Docker depuis ghcr.io. La solution standard : configurez Docker pour utiliser votre proxy corporate via les variables d’environnement HTTP_PROXY et HTTPS_PROXY dans la configuration Docker Desktop.

Pour les réseaux d’entreprise avec inspection TLS (man-in-the-middle pour le filtrage), vous devrez peut-être importer le certificat racine de votre entreprise dans Docker. Cette procédure est documentée dans la documentation officielle de Docker et varie selon l’OS.

Dans les environnements très restrictifs (réseau militaire, banking, etc.), il peut être plus simple de télécharger l’image Docker sur un réseau non filtré, la sauvegarder avec docker save, la transférer sur clé USB, et la charger sur la machine cible avec docker load. Cette approche fonctionne sans aucun accès Internet sur la machine de destination.

Ça dépend de l’année et des specs. Sur un MacBook Intel récent (2019-2023) avec 16 GB de RAM, Open WebUI + Ollama fonctionnent bien pour des modèles 3B à 7B, avec des vitesses de génération de 3 à 8 tokens par seconde. Acceptable pour un usage personnel non-temps-réel.

Sur un MacBook avec 8 GB de RAM, c’est très limité. Vous pouvez charger un modèle 3B mais la RAM utilisée par macOS + Docker + Ollama laisse peu de marge. Des ralentissements et du swap sont probables. Testez avec llama3.2:3b d’abord.

Sur un MacBook Apple Silicon (M1 et plus récent), même avec 8 GB de RAM, les performances sont nettement meilleures grâce à l’architecture unifiée. Un M1 8GB génère 10 à 20 tokens/seconde sur un modèle 7B, ce qui est confortable pour un usage quotidien. Un M2 16GB est le setup idéal pour Open WebUI + Ollama en 2026.