Installer Ollama et Open WebUI : le guide complet pour votre LLM auto-hébergé en 2026

Adaptation en français : cet article est une traduction-adaptation de notre article original en anglais, Self-Hosted LLM in 2026: The Complete Ollama + Open WebUI Setup Guide, publié sur selfhostlab.io.

Un LLM auto-hébergé associe Ollama, qui télécharge et fait tourner des modèles ouverts comme Llama ou Gemma directement sur votre propre matériel, à Open WebUI, qui habille ce modèle d’une interface façon ChatGPT avec comptes utilisateurs et historique de conversation. Ce guide installe les deux de zéro, récupère votre premier modèle, puis verrouille l’ensemble : un assistant IA privé et opérationnel en bien moins d’une heure.

Vous cherchez d’abord la vue d’ensemble ? Cet article est le guide d’installation pratique, Ollama et Open WebUI, du début à la fin, rien d’autre. Envie d’explorer plus large d’abord, agents, recherche photo, assistants vocaux ? Notre panorama des meilleurs outils d’IA auto-hébergée couvre tout ça et montre où ces deux outils viennent s’insérer dans l’ensemble.

Ce qu’il vous faut avant de commencer

Rien d’exotique n’est nécessaire. N’importe quelle machine 64 bits sous macOS, Windows ou Linux vieille d’une dizaine d’années suffit, y compris un mini PC ou un desktop recyclé qui fait déjà tourner Jellyfin ou un NAS ; Apple Silicon comme Intel conviennent aussi bien, tout comme des cartes ARM telles qu’un Raspberry Pi. Docker reste optionnel mais simplifie les mises à jour et le nettoyage : nous couvrons l’installateur natif et la voie Docker à chaque étape. Prévoyez au moins 10 à 20 Go d’espace disque libre avant de récupérer votre premier modèle : les fichiers de modèles sont volumineux, et Ollama conserve chaque version téléchargée jusqu’à ce que vous la supprimiez vous-même.

De quel matériel un LLM auto-hébergé a-t-il vraiment besoin ?

C’est la taille du modèle, pas sa licence ni sa marque, qui détermine s’il tournera à une vitesse confortable sur votre matériel. Voici la répartition concrète, avec une commande réelle à tester pour chaque palier.

Palier	À tester en premier	RAM (CPU seul)	VRAM GPU	Adapté à
Petit (1 à 3 milliards de paramètres)	`ollama run llama3.2:3b`	8 Go	Aucun besoin	Tests rapides, matériel ancien, un Raspberry Pi de récup
Moyen (7 à 8 milliards de paramètres)	`ollama run llama3.1:8b`	16 Go	8 Go et plus	Le point idéal pour la plupart des homelabs au quotidien
Grand (13 à 14 milliards de paramètres)	`ollama run qwen2.5:14b`	32 Go	16 à 24 Go	Aide au code, documents longs, réponses plus nuancées
Frontier (70 milliards de paramètres et plus)	`ollama run llama3.3:70b`	64 Go et plus	24 à 48 Go et plus, ou plusieurs GPU	Qualité proche du cloud, machine dédiée

En cas de doute, commencez petit. Chaque modèle de la bibliothèque Ollama affiche sa propre consommation de RAM avant même le téléchargement, et changer de modèle plus tard tient en une seule ligne de commande, pas une réinstallation.

Étape 1 : installer Ollama

Ollama s’installe de la même façon sur un simple laptop ou sur un serveur homelab : une seule commande, aucune dépendance à chasser au préalable.

macOS et Linux

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

Si vous préférez éviter le terminal, la page de téléchargement d’Ollama propose directement l’installateur .dmg pour macOS.

Windows

irm https://ollama.com/install.ps1 | iex

Lancez cette commande depuis PowerShell, ou téléchargez l’installateur OllamaSetup.exe si vous préférez un assistant d’installation Windows classique.

Docker

Vous préférez garder Ollama conteneurisé ? L’image officielle gère les configurations CPU seul et GPU avec une commande quasi identique.

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Un GPU Nvidia sous la main ? Installez d’abord le NVIDIA Container Toolkit, puis ajoutez --gpus=all à la commande ci-dessus. Les cartes AMD utilisent la même image avec un tag :rocm et des options --device. La documentation Docker d’Ollama détaille les deux cas.

Une fois installé, lancer ollama seul ouvre un menu interactif ; appuyez sur Entrée pour démarrer un modèle, ou passez directement à l’étape suivante.

Étape 2 : récupérer et lancer votre premier modèle

C’est la partie qui exigeait autrefois un environnement Python, une installation CUDA et une après-midi de libre. Ollama réduit tout cela à une seule ligne.

ollama run llama3.2

Le premier lancement télécharge le modèle, plusieurs gigaoctets selon sa taille, puis vous dépose dans une invite de conversation dès qu’il est prêt. Chaque lancement suivant démarre en quelques secondes, puisque le modèle est déjà sur le disque. Le choix par défaut d’Ollama pour un premier essai rapide est Gemma 3 (ollama run gemma3), et la bibliothèque complète sur ollama.com/library en liste des dizaines d’autres : Llama, Qwen, Mistral, DeepSeek, et le modèle à poids ouverts d’OpenAI, gpt-oss, chaque fiche indiquant la RAM nécessaire avant de télécharger quoi que ce soit.

Ce que vous avez à ce stade : un modèle local qui répond à vos questions dans votre terminal, sans que rien ne parte à l’extérieur de votre machine. Tout ce qui suit vise simplement à le rendre plus facile à utiliser au quotidien.

Si vous préférez scripter plutôt que taper dans un terminal, Ollama expose aussi une API REST sur le port 11434 (curl http://localhost:11434/api/chat -d '{...}'), avec des bibliothèques officielles Python et JavaScript sur GitHub, si bien que tout ce que vous construirez plus tard dialogue avec les mêmes modèles déjà en cours d’exécution.

Étape 3 : installer Open WebUI

Une fenêtre de terminal suffit pour tester, mais ce n’est pas ce qu’on confie au reste du foyer, ni ce qu’on utilise depuis son téléphone. Open WebUI transforme vos modèles Ollama en quelque chose qui ressemble à ChatGPT et se comporte comme lui.

docker run -d -p 3000:8080 -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main

Rendez-vous sur http://localhost:3000 une fois le conteneur lancé : si Ollama tourne déjà sur la même machine, Open WebUI le détecte automatiquement. Pour gérer les deux conteneurs ensemble, ou si vous partez d’un serveur neuf, un docker-compose.yml est l’option la plus propre sur la durée :

services:
  ollama:
    image: ollama/ollama
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    depends_on:
      - ollama
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - open-webui:/app/backend/data
    restart: unless-stopped

volumes:
  ollama:
  open-webui:

docker compose up -d

Envie d’un seul conteneur plutôt que deux ? Open WebUI propose aussi une variante d’image :ollama qui embarque les deux ensemble : docker run -d -p 3000:8080 -v ollama:/root/.ollama -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama, ajoutez --gpus=all avant le nom de l’image si vous avez une carte Nvidia. Moins d’éléments à gérer, mais moins de souplesse plus tard si vous voulez changer de backend.

Étape 4 : connecter les deux et créer votre compte administrateur

Si vous avez utilisé le docker-compose.yml combiné ci-dessus, Open WebUI pointe déjà vers Ollama via la variable OLLAMA_BASE_URL. Vous les faites tourner sur deux machines séparées ? Renseignez cette même variable avec l’adresse de votre serveur Ollama, ou ajoutez-la depuis l’interface, sous Settings > Admin Settings > Connections, une fois connecté.

Le premier compte créé dans Open WebUI devient automatiquement Administrateur, avec un contrôle complet sur les utilisateurs et les réglages. Chaque compte suivant reste en attente jusqu’à validation par un admin, un vrai contrôle d’accès que l’API brute d’Ollama n’a pas par elle-même. Le détail mérite qu’on s’y attarde : l’API d’Ollama n’a aucune authentification intégrée, quiconque peut atteindre le port 11434 peut l’utiliser, alors que les comptes d’Open WebUI sont ce qui empêche réellement une installation partagée, foyer ou équipe, de tourner au free-for-all.

Configurer Open WebUI pour un usage quotidien

Quelques réglages transforment une installation qui fonctionne en une installation que vous garderez sur la durée :

Récupérez d’autres modèles directement depuis l’interface : Admin Settings > Models > récupérer un modèle par son nom, sans terminal après le tout premier.
Activez la discussion avec vos documents en glissant un PDF ou un fichier texte dans une conversation ; Open WebUI gère lui-même l’étape de récupération dès qu’un modèle d’embedding comme nomic-embed-text est disponible.
Définissez une variable d’environnement WEBUI_SECRET_KEY permanente, générée avec openssl rand -hex 32, pour ne plus être déconnecté à chaque redémarrage du conteneur.
Invitez d’autres comptes du foyer une fois l’installation éprouvée, puis validez chacun depuis le panneau admin.

Sécuriser et mettre à jour votre stack

N’exposez jamais le port 11434 sur internet. Ollama se lie à votre machine locale par défaut et ne fournit aucune authentification, la documentation d’Ollama est claire sur ce point. Gardez-le accessible uniquement sur votre réseau local, et laissez la connexion d’Open WebUI être la seule porte ouverte à l’extérieur de votre LAN, idéalement via un reverse proxy avec un vrai certificat TLS ou un VPN maillé comme Tailscale, plutôt qu’un port simplement redirigé.

Les deux projets se mettent à jour comme n’importe quoi tournant sous Docker : on récupère la nouvelle image, on retire l’ancien conteneur, on le relance avec le même volume attaché pour ne rien perdre.

docker pull ghcr.io/open-webui/open-webui:main
docker rm -f open-webui
docker compose up -d

Ollama se met à jour tout aussi simplement : relancez le script d’installation sur macOS, Linux ou Windows, il se remplace lui-même en place, ou faites docker pull ollama/ollama puis recréez le conteneur si c’est ainsi que vous le faites tourner. L’option Watchtower d’Open WebUI automatise tout ça si vous préférez ne plus y penser.

Dépannage : les problèmes les plus courants

Une poignée de problèmes explique la plupart des moments « ça ne marche pas » avec cette stack.

Open WebUI n’affiche aucun modèle disponible. Presque toujours une variable OLLAMA_BASE_URL qui pointe vers la mauvaise adresse : localhost dans un conteneur désigne le conteneur lui-même, pas votre machine hôte ni l’autre conteneur. Utilisez le nom du service (ollama) dans Docker Compose, ou host.docker.internal quand Ollama tourne directement sur l’hôte.
Les réponses sont anormalement lentes. Lancez ollama ps pour vérifier si un modèle sollicite bien votre GPU ou s’il est discrètement retombé sur le CPU. Si vous venez d’installer des pilotes GPU ou le Container Toolkit, un redémarrage complet règle souvent des soucis de détection qu’un simple redémarrage de service ne résout pas.
Connexion refusée sur le port 11434. Vérifiez qu’Ollama tourne bien (curl http://localhost:11434/api/tags doit renvoyer une liste JSON) et que rien d’autre, une règle de pare-feu oubliée, un autre service, n’a déjà pris le port.
Les modèles disparaissent après un redémarrage du conteneur. Le volume n’était pas monté, ou l’était sous un nom différent de la dernière fois. Les volumes nommés (ollama:/root/.ollama) persistent d’un redémarrage à l’autre ; les volumes anonymes, non.

Un LLM auto-hébergé, ça vaut vraiment le coup ?

Pour la rédaction courante, les résumés, et les questions que vous préférez ne pas envoyer sur le serveur de quelqu’un d’autre, oui. Un modèle de taille moyenne sur du matériel que vous possédez déjà s’approche suffisamment d’un modèle hébergé pour que la plupart des gens arrêtent de voir la différence après la première semaine. Pour les tâches de raisonnement et de code les plus exigeantes, les modèles hébergés de pointe gardent l’avantage, et ce sera sans doute encore le cas un moment, inutile de prétendre le contraire. Beaucoup de gens qui font tourner exactement cette stack gardent les deux : Ollama et Open WebUI au quotidien, un modèle hébergé conservé pour la poignée de tâches qui en ont vraiment besoin. Rien de dramatique dans ce compromis, juste un arbitrage assumé. Pour un lectorat européen, l’argument confidentialité pèse double : aucun prompt ne transite par un sous-traitant tiers, donc aucune question RGPD à se poser sur l’hébergement de vos données. Si vous hésitez encore face à tout ce que peut recouvrir l’IA auto-hébergée, agents, recherche photo, contrôle vocal, notre panorama des meilleurs outils d’IA auto-hébergée offre la vue d’ensemble. Celui-ci décrit ce qui se passe une fois que vous avez déjà décidé qu’Ollama et Open WebUI sont votre point de départ.

FAQ

Quelle est la différence entre Ollama et Open WebUI ?

Ollama fait tourner le modèle lui-même et expose une API. Open WebUI est l’interface dans le navigateur qui dialogue avec cette API. Vous pouvez utiliser Ollama seul depuis un terminal, mais Open WebUI est ce qui le rend utilisable pour quiconque ne veut pas taper de commandes, en ajoutant par-dessus comptes utilisateurs, historique de conversation et upload de fichiers.

Faut-il un GPU pour faire tourner un LLM auto-hébergé ?

Non, pas pour les petits modèles. Une machine CPU seul avec 8 Go de RAM gère des modèles de 1 à 3 milliards de paramètres sans GPU, simplement plus lentement qu’un chatbot hébergé auquel vous êtes habitué. Un GPU devient intéressant dès que vous voulez que des modèles de 7 milliards de paramètres ou plus répondent instantanément plutôt que juste correctement.

Open WebUI est-il gratuit ?

Oui, gratuit à auto-héberger, utiliser et modifier. Sa licence est passée de BSD-3-Clause à une licence modifiée à partir de la version 0.6.6, qui impose de garder le branding d’Open WebUI visible sauf critères d’exemption précis détaillés sur sa page GitHub, un détail à connaître si la pureté de la licence compte pour vous, mais qui ne change rien à ce que ça coûte de le faire tourner : rien.

Peut-on utiliser Ollama sans Open WebUI ?

Oui, Ollama fonctionne entièrement en ligne de commande ou via son API, seul. Open WebUI est une couche optionnelle par-dessus pour qui préfère un navigateur à un terminal ; la plupart des gens finissent par l’ajouter dès le premier jour de toute façon.

Peut-on accéder à son LLM auto-hébergé depuis son téléphone ou hors de son domicile ?

Oui, via l’interface web d’Open WebUI immédiatement sur votre réseau local, et depuis l’extérieur une fois un reverse proxy ou un VPN maillé comme Tailscale placé devant. Ne redirigez pas le port 11434 lui-même : c’est l’API non authentifiée d’Ollama, pas l’interface protégée par connexion.

Open WebUI peut-il se connecter à des modèles cloud, pas seulement à Ollama ?

Oui. En plus d’Ollama, Open WebUI peut se connecter à OpenAI, Anthropic, toute API compatible OpenAI, et à des moteurs locaux comme llama.cpp ou vLLM, tous depuis la même interface. Beaucoup font tourner un modèle local par défaut tout en gardant un modèle cloud connecté pour les rares tâches qui en ont besoin.

Est-il légal d’auto-héberger un LLM ?

Oui. Ollama, Open WebUI et les modèles ouverts qu’ils font tourner sont des logiciels open source ou source disponible parfaitement légitimes, ni plus ni moins légal que d’installer n’importe quel autre programme sur du matériel qui vous appartient.

Prêt à aller au-delà d’un simple chatbot ? Notre panorama des meilleurs outils d’IA auto-hébergée couvre n8n pour transformer ce même modèle en agent, ainsi que les fonctionnalités IA locales propres à Immich et Home Assistant. Nos rubriques IA auto-hébergée et Homelab regroupent tout le reste de ce dossier au fil de sa publication, et notre rubrique Docker & Containers couvre les bases de conteneurisation sur lesquelles repose ce guide entier.