[{"data":1,"prerenderedAt":225},["ShallowReactive",2],{"seo-verification":3,"blog-open-webui-ollama-vps-ma-fr":6,"promo-bar-likely":224},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-open-webui-ollama-vps-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":164,"ctaBody":165,"ctaButton":166,"ctaUrl":167,"relatedPosts":168},316,"open-webui-ollama-vps",{"fr":10,"en":12,"ar":13,"es":14},"open-webui-ollama-on-vps-multi-user-interface-for-local-llms","واجهة-ويب-open-webui-مع-ollama-على-vps-للفرق","open-webui-ollama-en-vps-interfaz-web-multiusuario-para-llm","Open-WebUI + Ollama sur VPS : interface multi-utilisateurs LLM","Offrez à votre équipe une interface web multi-utilisateurs sur vos modèles Ollama : RAG, gestion de modèles, SSO OpenID Connect, sans dépendance cloud.",18,7,false,"2026-08-30T00:00:00+00:00","2026-11-08T01:13:13+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},1,"Intelligence Artificielle","intelligence-artificielle","bg-purple-500\u002F10 text-purple-400","ia",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fopen-webui-ollama-vps-poster.svg","Ollama sert vos modèles de langage via une API locale. Open-WebUI ajoute la couche interface : une application web complète, avec gestion des utilisateurs, RAG sur vos documents, historique des conversations et authentification SSO. En déployant les deux sur votre VPS, vous donnez à toute votre équipe un accès à des LLM privés sans exposer l'API brute ni exiger de ligne de commande. Ce guide couvre l'installation, le reverse proxy, le SSO et la gestion des droits. Il couvre aussi la recherche web via SearXNG, le dépannage quand elle ne renvoie plus rien, et ce qu'on peut mesurer de l'usage d'une instance d'équipe.",[35,39,49,52,71,74,77,80,83,111,114,117,132,134,137,144,147,149,152,154,161],{"type":36,"title":37,"body":38},"h2","Pourquoi ajouter Open-WebUI à votre serveur Ollama","Ollama expose une API REST compatible OpenAI — efficace pour les développeurs, inaccessible pour les autres membres d'une équipe. Open-WebUI comble cet écart : c'est une interface web complète qui se connecte à Ollama (ou à tout autre fournisseur compatible OpenAI) et transforme un serveur d'inférence en outil collaboratif.\n\nLe dépôt dépasse 155 000 étoiles sur GitHub. Attention à la licence : ce n'est pas du MIT. Le projet publie une licence propre, de type BSD à trois clauses, assortie d'une condition : au-delà de 50 utilisateurs sur 30 jours glissants, il est interdit de modifier ou de retirer la marque « Open WebUI », sauf accord écrit ou licence entreprise. Pour une petite équipe, rien ne change ; au-delà, relisez le fichier LICENSE avant de personnaliser l'interface. De son côté, Ollama a annoncé en juillet 2026 une levée de 65 millions de dollars (Series B), signe que le moteur d'inférence s'installe durablement dans les équipes de développement.\n\nLe projet est maintenu de façon continue et publie des tags stables à un rythme soutenu : la version 0.13.0 date du 3 novembre 2026. Cette cadence a un revers, puisque des comportements par défaut changent d'une version mineure à l'autre (l'appel d'outils natif est devenu le défaut en 0.10.0). D'où l'intérêt de figer un tag et de lire les notes de version avant chaque mise à jour. Open-WebUI couvre des besoins bien au-delà du chat : RAG sur des fichiers locaux, gestion de plusieurs modèles, groupes d'utilisateurs, recherche web et intégration SSO via OpenID Connect.",{"type":40,"title":41,"items":42},"ul","Ce qu'Open-WebUI apporte concrètement à votre stack Ollama",[43,44,45,46,47,48],"**Interface multi-utilisateurs** : chaque membre de l'équipe dispose de son compte, de son historique et de ses conversations — sans accès à l'API brute ni à la ligne de commande.","**RAG natif** : importez des fichiers PDF, Markdown ou Word directement depuis l'interface ; Open-WebUI les indexe et les injecte dans le contexte de chaque conversation.","**Gestion des modèles** : téléchargez, supprimez et activez des modèles Ollama depuis l'interface web, sans passer par `docker exec`.","**SSO OpenID Connect** : connectez Open-WebUI à votre fournisseur d'identité (Keycloak, Authentik, Google Workspace…) pour un accès unifié et une révocation centralisée.","**Groupes et rôles** : définissez qui peut accéder à quels modèles, qui peut télécharger des fichiers, qui a les droits d'administration.","**Aucune dépendance cloud** : tous les tokens, toutes les conversations et tous les fichiers restent sur votre infrastructure.",{"type":36,"title":50,"body":51},"Prérequis matériels et logiciels","Open-WebUI s'exécute en conteneur Docker et se connecte à Ollama via le réseau Docker interne. Les deux peuvent cohabiter sur le même VPS.\n\nPour un usage équipe de 5 à 10 personnes avec des modèles 7B quantisés (Q4), comptez au minimum :\n\n- **8 Go de RAM** (6 Go pour le modèle + marge pour Open-WebUI et le système)\n- **4 vCPU** : l'inférence sur CPU est lente avec moins de cœurs ; passez à 8 vCPU pour un confort d'usage quotidien\n- **30 Go de stockage SSD** minimum, plus l'espace pour vos modèles (un modèle 7B Q4 ≈ 4,5 Go, un modèle 13B ≈ 8 Go)\n- **Docker et Docker Compose** installés\n- Un **nom de domaine** pointant vers votre VPS (nécessaire pour TLS et le SSO)\n- Un **reverse proxy** avec HTTPS — Nginx, Traefik ou Caddy (servi en HTTP sur un domaine ou une IP non locale, Open-WebUI perd des fonctions dans le navigateur : voir le dépannage)\n\nSi Ollama est déjà déployé sur votre VPS (voir l'article \u003Ca href=\"\u002Fblog\u002Fheberger-ollama-vps\">Comment héberger Ollama sur un VPS\u003C\u002Fa>), vous pouvez passer directement à l'installation d'Open-WebUI.",{"type":53,"title":54,"steps":55},"steps","Déployer Open-WebUI et Ollama avec Docker Compose",[56,59,62,65,68],{"title":57,"body":58},"Créer le fichier Docker Compose","Créez un répertoire de travail puis rédigez le fichier de composition :\n\n```bash\nmkdir -p \u002Fopt\u002Fopenwebui && cd \u002Fopt\u002Fopenwebui\n```\n\nContenu de `compose.yml` :\n\n```bash\nservices:\n  ollama:\n    image: ollama\u002Follama:latest\n    container_name: ollama\n    volumes:\n      - ollama_data:\u002Froot\u002F.ollama\n    restart: unless-stopped\n\n  open-webui:\n    image: ghcr.io\u002Fopen-webui\u002Fopen-webui:main\n    container_name: open-webui\n    depends_on:\n      - ollama\n    ports:\n      - \"127.0.0.1:3000:8080\"\n    environment:\n      - OLLAMA_BASE_URL=http:\u002F\u002Follama:11434\n      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY}\n    volumes:\n      - open_webui_data:\u002Fapp\u002Fbackend\u002Fdata\n    restart: unless-stopped\n\nvolumes:\n  ollama_data:\n  open_webui_data:\n```\n\nLa clé `WEBUI_SECRET_KEY` doit être une chaîne aléatoire longue, jamais écrite dans le fichier de composition : générez-la avec `echo \"WEBUI_SECRET_KEY=$(openssl rand -hex 32)\" > .env && chmod 600 .env`. Docker Compose lit ce fichier `.env` du répertoire et remplace `${WEBUI_SECRET_KEY}`.",{"title":60,"body":61},"Démarrer la stack","Lancez les deux services :\n\n```bash\ndocker compose up -d\n```\n\nVérifiez que les deux conteneurs sont actifs :\n\n```bash\ndocker compose ps\n```\n\nOllama peut mettre quelques secondes à démarrer. Open-WebUI attend qu'Ollama soit prêt grâce à `depends_on`, mais si vous observez des erreurs de connexion au premier démarrage, attendez 15 secondes et rechargez.",{"title":63,"body":64},"Télécharger un premier modèle","Depuis le host, téléchargez un modèle via Ollama :\n\n```bash\ndocker exec -it ollama ollama pull llama3.1:8b\n```\n\nVous pouvez aussi le faire depuis l'interface Open-WebUI une fois connecté, dans **Panneau d'administration → Modèles → Télécharger depuis Ollama.com**.",{"title":66,"body":67},"Configurer le reverse proxy Nginx avec HTTPS","Open-WebUI écoute sur `127.0.0.1:3000`. Créez un virtual host Nginx pour l'exposer en HTTPS :\n\n```bash\nserver {\n    listen 443 ssl;\n    server_name openwebui.yourdomain.com;\n\n    ssl_certificate \u002Fetc\u002Fletsencrypt\u002Flive\u002Fopenwebui.yourdomain.com\u002Ffullchain.pem;\n    ssl_certificate_key \u002Fetc\u002Fletsencrypt\u002Flive\u002Fopenwebui.yourdomain.com\u002Fprivkey.pem;\n\n    location \u002F {\n        proxy_pass http:\u002F\u002F127.0.0.1:3000;\n        proxy_set_header Host $host;\n        proxy_set_header X-Real-IP $remote_addr;\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n        proxy_set_header X-Forwarded-Proto $scheme;\n\n        # WebSocket (nécessaire pour le streaming des réponses)\n        proxy_http_version 1.1;\n        proxy_set_header Upgrade $http_upgrade;\n        proxy_set_header Connection \"upgrade\";\n        proxy_read_timeout 300s;\n    }\n}\n```\n\nObtenez le certificat avec Certbot :\n\n```bash\ncertbot --nginx -d openwebui.yourdomain.com\n```\n\nL'entête `Connection: upgrade` et le `proxy_read_timeout` étendu sont indispensables : les réponses des LLM sont diffusées en streaming via WebSocket, et un timeout court coupe la réponse en pleine génération.",{"title":69,"body":70},"Créer le compte administrateur","Ouvrez `https:\u002F\u002Fopenwebui.yourdomain.com` dans votre navigateur. Le **premier compte créé devient automatiquement administrateur** : créez-le dès la mise en ligne, avant que quelqu'un d'autre ne le fasse. Renseignez un e-mail et un mot de passe.\n\nDepuis le panneau d'administration (**icône avatar → Panneau d'administration**), vous pouvez :\n- définir si de nouveaux inscrits sont actifs immédiatement ou en attente de validation ;\n- créer des groupes d'utilisateurs et leur associer des modèles ;\n- configurer le SSO.",{"type":36,"title":72,"body":73},"Configurer le SSO OpenID Connect","Open-WebUI prend en charge nativement l'authentification via OpenID Connect (OIDC). Vous pouvez l'intégrer à Keycloak, Authentik, Authelia, ou tout fournisseur compatible (y compris Google Workspace ou Microsoft Entra).\n\nDans `compose.yml`, ajoutez les variables d'environnement suivantes au service `open-webui` :\n\n```bash\nenvironment:\n  - OAUTH_CLIENT_ID=votre-client-id\n  - OAUTH_CLIENT_SECRET=${OAUTH_CLIENT_SECRET}\n  - OPENID_PROVIDER_URL=https:\u002F\u002Fvotre-idp.example.com\u002F.well-known\u002Fopenid-configuration\n  - OAUTH_PROVIDER_NAME=Mon SSO\n  - ENABLE_OAUTH_SIGNUP=true\n```\n\nComme la clé de session, le secret client se range dans le fichier `.env` (`OAUTH_CLIENT_SECRET=…`), pas dans `compose.yml`. La variable `ENABLE_OAUTH_SIGNUP=true` permet aux utilisateurs qui s'authentifient via SSO d'être créés automatiquement dans Open-WebUI. Mettez-la à `false` si vous souhaitez que l'administrateur provisionne chaque compte manuellement.\n\nL'URL de callback à déclarer dans votre fournisseur d'identité est `https:\u002F\u002Fopenwebui.yourdomain.com\u002Foauth\u002Foidc\u002Fcallback`.\n\nRedémarrez la stack après modification :\n\n```bash\ndocker compose up -d\n```",{"type":75,"body":76},"tip","Pour limiter l'accès SSO à un domaine e-mail spécifique (ex. `@votre-entreprise.com`), configurez la restriction directement dans votre fournisseur d'identité, pas dans Open-WebUI. Keycloak et Authentik permettent tous les deux de filtrer par domaine au niveau du client OIDC — c'est le point de contrôle le plus sûr, car il couvre aussi l'API.",{"type":36,"title":78,"body":79},"Activer le RAG sur vos documents","Open-WebUI intègre un pipeline RAG (Retrieval-Augmented Generation) qui permet d'interroger vos documents locaux dans une conversation. Le traitement se fait entièrement sur votre VPS — aucun document n'est envoyé à un service externe.\n\nPour activer le RAG :\n\n1. Depuis l'interface, cliquez sur le **trombone** dans la zone de saisie d'une conversation, ou utilisez l'onglet **Documents** dans le menu latéral.\n2. Importez un fichier PDF, Markdown, DOCX ou TXT. Open-WebUI le découpe, le vectorise et le stocke dans sa base de données locale.\n3. Dans la conversation, préfixez votre message avec `#` suivi du nom du document pour l'injecter comme contexte.\n\nPour un usage avancé (plusieurs documents, collections thématiques), la section **Espace de travail → Documents** permet d'organiser les fichiers en collections et de les associer à des modèles spécifiques.\n\nPar défaut, Open-WebUI utilise son propre moteur d'embeddings léger. Pour améliorer les performances sur un corpus important, vous pouvez configurer un modèle d'embeddings Ollama dédié (par exemple `nomic-embed-text`) dans **Panneau d'administration → Documents → Modèle d'embeddings**.",{"type":36,"title":81,"body":82},"Ajouter la recherche web avec SearXNG","La recherche web n'est pas embarquée dans Open-WebUI : l'interface interroge un moteur externe, puis injecte les pages trouvées dans le contexte du modèle. SearXNG, un métamoteur auto-hébergé, évite de dépendre d'une clé d'API payante : il interroge pour vous plusieurs moteurs publics et renvoie une liste unique. C'est aussi sa fragilité, détaillée dans la section de dépannage plus bas.\n\nTrois réglages suffisent. Côté SearXNG, ouvrez `settings.yml` et ajoutez `json` à la liste `formats` située sous `search`, à côté de `html` : sans cela, Open-WebUI reçoit une erreur 403. Côté Open-WebUI, ouvrez **Panneau d'administration → Réglages → Recherche web**, choisissez `searxng` et saisissez l'URL de requête, par exemple `http:\u002F\u002Fsearxng:8080\u002Fsearch?q=\u003Cquery>` (variable `SEARXNG_QUERY_URL`). Vous pouvez aussi poser `ENABLE_WEB_SEARCH=true` et `WEB_SEARCH_ENGINE=searxng` dans le `compose.yml`. Si les deux services partagent un réseau Docker, le nom du service sert d'hôte et le port de SearXNG n'a pas à être publié sur Internet.\n\nReste un piège : trois interrupteurs doivent être allumés en même temps, la recherche web globale, la capacité « recherche web » du modèle et le bouton de la conversation en cours. Le moindre oubli donne une réponse sans recherche, souvent sans erreur visible.",{"type":84,"title":85,"headers":86,"rows":90},"comparison","Open-WebUI, AnythingLLM, LibreChat : quelle interface choisir",[87,88,89],"Critère","Open-WebUI","AnythingLLM \u002F LibreChat",[91,95,99,103,107],[92,93,94],"Backend LLM","Ollama natif + tout endpoint OpenAI","OpenAI, Ollama, Azure, LM Studio",[96,97,98],"Gestion des utilisateurs","Intégrée, groupes, OIDC natif","Intégrée (AnythingLLM : espaces isolés)",[100,101,102],"RAG","Natif, sans configuration","Natif, configurable (LanceDB, pgvector)",[104,105,106],"Étoiles GitHub","155 000+ (licence propre, marque protégée)","65 000+ (MIT) \u002F 45 000+ (MIT)",[108,109,110],"Cas d'usage principal","Équipe avec Ollama déjà déployé","RAG multi-sources avancé \u002F Chat multi-backend",{"type":36,"title":112,"body":113},"Dépannage : les erreurs courantes","**`Connection refused` au démarrage d'Open-WebUI.**\nOllama n'est pas encore prêt quand Open-WebUI tente de se connecter. Attendez 20 secondes et relancez `docker compose restart open-webui`. Pour éviter ce problème à chaque redémarrage, ajoutez un healthcheck sur le service Ollama dans `compose.yml`.\n\n**Le streaming s'interrompt après 60 secondes.**\nVotre reverse proxy applique un timeout HTTP par défaut. Ajoutez `proxy_read_timeout 300s;` dans le bloc `location \u002F` de Nginx (ou l'équivalent `timeout` dans Traefik). Les LLM prennent parfois plusieurs minutes pour générer une longue réponse.\n\n**`WebSocket connection failed`.**\nVérifiez que les entêtes `Upgrade` et `Connection` sont bien transmis par le reverse proxy. Sans eux, le streaming SSE\u002FWebSocket est bloqué et les réponses n'arrivent pas en temps réel.\n\n**L'authentification SSO renvoie `redirect_uri_mismatch`.**\nL'URL de callback déclarée dans votre fournisseur d'identité ne correspond pas à celle qu'Open-WebUI envoie. Elle doit être exactement `https:\u002F\u002Fopenwebui.yourdomain.com\u002Foauth\u002Foidc\u002Fcallback` — avec le nom de domaine complet, sans slash final.\n\n**Un utilisateur SSO peut se connecter mais n'a accès à aucun modèle.**\n`DEFAULT_USER_ROLE` vaut `pending` par défaut : tout nouveau compte, SSO compris, attend l'activation d'un administrateur, et `ENABLE_OAUTH_SIGNUP` ne gouverne que la création du compte. Passez leur rôle à `user` dans **Panneau d'administration → Utilisateurs**, ou configurez `DEFAULT_USER_ROLE=user` dans les variables d'environnement.\n\n**Écran qui ne répond pas, `crypto.randomUUID is not a function` dans la console du navigateur.**\nOpen-WebUI est servi en HTTP sur un domaine ou une adresse non locale : le navigateur ne fournit cette fonction qu'en contexte sécurisé (HTTPS ou `localhost`). Terminez la configuration TLS du reverse proxy avant de tester les fonctions d'IA.\n\n**La recherche web ne renvoie rien.**\nVoir la section dédiée plus bas : testez SearXNG seul avant d'accuser Open-WebUI.",{"type":36,"title":115,"body":116},"Dépannage : la recherche web ne renvoie rien","**Symptôme.** La recherche web est activée, mais la conversation affiche `No results found from web search` (une erreur 404 dans le journal d'Open-WebUI), ou le modèle répond sans avoir cherché.\n\n**Ce que dit ce message.** Open-WebUI a bien joint SearXNG, lui a envoyé la requête et a reçu une liste vide. Un cas public l'illustre (issue open-webui #32401, ouverte le 14 octobre 2026 après un passage en 0.12.0) : l'auteur soupçonnait la nouvelle version, la maintenance a d'abord incriminé le modèle, puis, le journal de SearXNG en main, a constaté que DuckDuckGo répondait par un CAPTCHA, Brave par « Too many requests » (moteur suspendu 3 minutes à chaque fois) et Startpage par une redirection vers son CAPTCHA. Tous les moteurs bloqués, donc zéro résultat. Selon la maintenance, ces sites bloquaient l'adresse IP indépendamment de la mise à jour. L'issue a été fermée le jour même sans correctif côté Open-WebUI, et l'auteur a fini par choisir le fournisseur DDGS.\n\nLa méthode à retenir : avant d'accuser la version ou le modèle, interrogez SearXNG seul.",{"type":53,"title":118,"steps":119},"Diagnostiquer une recherche web vide",[120,123,126,129],{"title":121,"body":122},"Interroger SearXNG sans Open-WebUI","Depuis le VPS, lancez `curl -s 'http:\u002F\u002F127.0.0.1:8080\u002Fsearch?q=test&format=json'` en adaptant l'hôte et le port à votre installation (si SearXNG n'est joignable que par le réseau Docker, lancez la commande depuis un conteneur de ce réseau). Trois issues : une erreur 403 signifie que `json` manque dans `formats` ; une liste `results` vide signifie que les moteurs échouent ; une liste remplie signifie que SearXNG fonctionne et que le problème se trouve côté Open-WebUI ou du modèle (voir l'encadré plus bas).",{"title":124,"body":125},"Lire le journal de SearXNG","`docker compose logs --tail 200 searxng` montre ce que chaque moteur a répondu. Cherchez les lignes qui nomment un moteur (duckduckgo, brave, startpage…) avec un CAPTCHA, un refus pour trop de requêtes ou un délai dépassé. Un moteur qui revient à chaque recherche avec la même erreur est bloqué pour l'adresse IP de votre VPS, ce qui arrive plus volontiers à une adresse de centre de données.",{"title":127,"body":128},"Activer ou remplacer des moteurs","Dans `settings.yml`, section `engines`, activez des moteurs généralistes qui ne sont pas bloqués : la maintenance d'Open-WebUI cite Google, Bing, Mojeek et Qwant. Une entrée `name: mojeek` avec `disabled: false` active un moteur présent dans les réglages par défaut ; avec `use_default_settings: true` en tête de fichier, vous ne listez que vos écarts. Redémarrez avec `docker compose restart searxng`, puis rejouez l'étape 1 jusqu'à obtenir des résultats. Multipliez les moteurs : un seul moteur actif retombe vite dans le blocage.",{"title":130,"body":131},"Passer par un fournisseur à clé si l'IP reste bloquée","Si tous les moteurs échouent, un fournisseur par API contourne le problème : Brave Search API, Tavily ou Serper se choisissent dans le même écran d'administration. Pour l'offre gratuite de Brave, réglez `WEB_SEARCH_CONCURRENT_REQUESTS=1`. Le fournisseur DDGS, retenu par l'auteur de l'issue, ne demande pas de clé.",{"type":75,"body":133},"SearXNG renvoie des résultats, mais l'assistant ne cherche jamais ? Depuis la version 0.10.0 (fin juin 2026), l'appel d'outils natif est le mode par défaut : la recherche web devient un outil que le modèle doit appeler lui-même, et un modèle ancien ou petit le saute ou écrit un appel malformé. Choisissez un modèle récent qui gère les outils et vérifiez que Function Calling est sur Native dans les paramètres avancés du modèle ; la maintenance décrit le mode Legacy comme non pris en charge. Si la recherche réussit mais que les pages ne se chargent pas, regardez `WEB_SEARCH_TRUST_ENV` derrière un proxy HTTP, puis `USER_AGENT`.",{"type":36,"title":135,"body":136},"Suivre l'usage d'une instance d'équipe","Savoir qui consomme quoi devient vite une question de budget dès que des développeurs appellent l'instance par l'API. Aujourd'hui, quatre sources se complètent, chacune avec un angle mort :",{"type":40,"title":138,"items":139},"Les quatre sources de mesure",[140,141,142,143],"**Le tableau de bord Analytics** (réglages d'administration, rubrique Analytics) : messages, tokens en entrée et en sortie, par modèle et par utilisateur, avec filtre par groupe et par période ; depuis la 0.12.4, le classement se fait par tokens. Il se calcule à partir de l'historique de messages enregistré dans la base : ce qui n'y est pas enregistré n'y figure pas. `ENABLE_ADMIN_ANALYTICS=False` le masque.","**La vue personnelle** (réglages, onglet Usage, depuis la 0.11.0 de juillet 2026) : chaque utilisateur voit sa propre activité, et rien de celle des autres.","**Le journal d'audit** : désactivé par défaut (`AUDIT_LOG_LEVEL=NONE`). Avec `AUDIT_LOG_LEVEL=METADATA`, Open-WebUI écrit `audit.log` dans son répertoire de données (rotation à 10 Mo) pour les requêtes authentifiées par en-tête `Authorization` ou par cookie : les appels d'API y figurent donc, avec le modèle demandé. Pour obtenir aussi les tokens de chaque réponse (depuis la 0.12.4), retirez `\u002Fchat` de `AUDIT_EXCLUDED_PATHS`, qui vaut `\u002Fchats,\u002Fchat,\u002Ffolders` par défaut. Évitez les niveaux `REQUEST` et `REQUEST_RESPONSE`, qui enregistrent le contenu des conversations, et rejouez un appel de test pour lire l'entrée produite avant de bâtir un décompte dessus.","**Les journaux du reverse proxy** : l'angle le plus simple pour la volumétrie. Avec le format combined de Nginx, `awk '{print $7}' \u002Fvar\u002Flog\u002Fnginx\u002Faccess.log | sort | uniq -c | sort -rn | head` classe les chemins les plus appelés ; ajoutez `$request_time` à votre `log_format` pour repérer les requêtes lentes. Ce journal ne voit ni l'utilisateur ni les tokens, et l'en-tête `Authorization` ne doit jamais y être consigné.",{"type":36,"title":145,"body":146},"Ce que le suivi d'usage ne fait pas encore","La demande d'un suivi qui sépare l'interface de l'API et attribue les appels à chaque clé est ouverte sur le dépôt du projet : issue open-webui #21675, « enh: analytics », créée le 20 février 2026 et toujours ouverte au 7 novembre 2026, avec une centaine de commentaires. Le fil rapporte qu'un utilisateur d'API placé dans un groupe n'apparaît pas dans Analytics, et le 14 octobre une équipe dont les développeurs passent surtout par l'API réclamait encore cette visibilité. Aucune date n'y est annoncée : ne planifiez rien sur cette fonction.\n\nLa maintenance répond qu'un filtre, c'est-à-dire une fonction Python installée dans l'interface, peut compter les requêtes, y compris celles de l'API ; un contributeur précise que les routes en passthrough y échappent. Elle range les plafonds par utilisateur ou par groupe dans le limitage de débit, hors du sujet Analytics. Lire directement la base SQLite `webui.db` reste possible sur une copie, mais son schéma n'est pas un contrat et change d'une version à l'autre. Un contributeur a aussi publié un plugin tiers de quotas : une fonction s'exécute avec les droits du serveur, donc relisez son code avant de l'activer.",{"type":75,"body":148},"Donnez à chaque développeur son compte et sa propre clé d'API plutôt qu'une clé partagée : sans identité distincte, aucune des quatre sources ne peut attribuer l'usage. Si l'API devient le canal principal, une passerelle devant Ollama qui compte les appels à la source (LiteLLM, déjà au catalogue ServOrbit, propose des clés virtuelles et un suivi de dépense) est une piste à tester avant de l'adopter.",{"type":36,"title":150,"body":151},"Sécuriser l'accès à l'API Ollama","Par défaut, Ollama écoute sur `0.0.0.0:11434` dans son conteneur. La configuration `compose.yml` proposée ci-dessus ne publie pas ce port sur l'hôte — seul Open-WebUI y accède via le réseau Docker interne. C'est la posture correcte.\n\nSi vous avez besoin d'accéder à l'API Ollama directement (depuis un IDE, un notebook Jupyter ou une application externe), deux options :\n\n1. **Tunnel SSH** : `ssh -L 11434:localhost:11434 user@votre-vps` — l'API est accessible localement sans exposition publique.\n2. **Reverse proxy avec authentification** : exposez Ollama derrière Nginx avec un `auth_basic` ou un token Bearer, si vous avez des clients qui ne supportent pas le tunnel SSH.\n\nNe publiez jamais le port 11434 directement sur l'interface publique sans authentification : l'API Ollama n'a aucune protection native contre les accès non autorisés.",{"type":75,"body":153},"Pour maintenir Open-WebUI à jour, modifiez l'image de `ghcr.io\u002Fopen-webui\u002Fopen-webui:main` en `ghcr.io\u002Fopen-webui\u002Fopen-webui:v0.13.0` (ou le dernier tag stable) dans votre `compose.yml`. Le tag `:main` suit le développement en continu — pratique pour tester les nouvelles fonctions, moins prévisible en production. Consultez les notes de version sur GitHub avant chaque mise à jour : certaines versions ont introduit des migrations de base de données, d'autres changent des comportements par défaut (l'appel d'outils natif en 0.10.0), et les notes de la 0.12.0 recommandent une mise à jour rapide des déploiements de production pour ses correctifs de sécurité.",{"type":40,"title":155,"items":156},"Fonctions avancées à explorer après le déploiement",[157,158,159,160],"**Pipelines et fonctions** : Open-WebUI permet d'écrire des fonctions Python qui s'intercalent dans le flux de conversation — filtres, enrichisseurs de contexte, connecteurs vers des APIs externes.","**Modèles personnalisés** : créez des « modèles » pré-configurés (instructions système, température, contexte) et partagez-les avec des groupes d'utilisateurs spécifiques.","**Image generation** : connectez Open-WebUI à une instance Stable Diffusion ou ComfyUI locale pour générer des images directement dans le chat.","**Intégration avec des outils externes** : via le protocole MCP (Model Context Protocol), Open-WebUI peut appeler des outils externes — bases de données, APIs REST, recherche web.",{"type":75,"title":162,"body":163},"La documentation officielle","Pour la configuration avancée et les options propres à l'outil, référez-vous à la \u003Ca href=\"https:\u002F\u002Fdocs.openwebui.com\">documentation officielle d'Open-WebUI\u003C\u002Fa>. Ce guide couvre le déploiement de base et les configurations les plus courantes — les paramètres spécifiques à votre environnement (intégration LDAP, configuration de pipelines, tuning des embeddings) se trouvent dans la documentation du projet.","Un VPS prêt pour Open-WebUI et Ollama","Open-WebUI avec Ollama nécessite un VPS avec accès root, Docker, et suffisamment de RAM pour charger vos modèles. Le VPS Cloud ServOrbit offre la scalabilité verticale nécessaire pour passer d'un modèle 7B à un modèle 13B sans migration.","Voir les VPS Cloud","\u002Fvps-cloud",[169,188,206],{"id":170,"slug":171,"slugs":172,"title":176,"excerpt":177,"readTime":178,"views":179,"isPinned":19,"noindex":19,"publishedAt":180,"updatedAt":181,"category":182,"categories":183,"featuredImage":30,"bgImage":31,"posterImage":185,"relatedSolution":186},9,"heberger-anythingllm-vps",{"fr":171,"en":173,"ar":174,"es":175},"how-to-host-anythingllm-on-a-vps","كيفية-استضافة-anythingllm-على-خادم-vps","como-alojar-anythingllm-en-un-vps","AnythingLLM sur VPS : guide complet avec pièges à éviter","Hébergez AnythingLLM sur VPS : Docker, HTTPS, epinglage de version obligatoire. Pièges :latest, Gemini v1.16 et Ollama réseau Docker documentés.",8,0,"2026-06-11T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[184],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-anythingllm-vps-poster.svg",{"categorySlug":27,"appSlug":187},"anything-llm",{"id":189,"slug":190,"slugs":191,"title":195,"excerpt":196,"readTime":197,"views":23,"isPinned":19,"noindex":19,"publishedAt":198,"updatedAt":199,"category":200,"categories":201,"featuredImage":30,"bgImage":31,"posterImage":203,"relatedSolution":204},2,"deployer-dify-vps",{"fr":190,"en":192,"ar":193,"es":194},"deploying-dify-on-a-vps-ai-workflows-under-control","نشر-dify-على-vps-سير-عمل-الذكاء-الاصطناعي-تحت-السيطرة","desplegar-dify-en-un-vps","Déployer Dify sur un VPS : guide de l'installation aux plugins","Installez Dify sur un VPS ServOrbit : prérequis, Docker Compose, plugins offline, limites de l'installation Docker, sauvegarde avant mise à jour, dépannage.",15,"2026-02-11T00:00:00+00:00","2026-10-29T03:10:23+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[202],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-dify-vps-poster.svg",{"categorySlug":25,"appSlug":205},"dify",{"id":207,"slug":208,"slugs":209,"title":213,"excerpt":214,"readTime":215,"views":189,"isPinned":19,"noindex":19,"publishedAt":216,"updatedAt":217,"category":218,"categories":219,"featuredImage":30,"bgImage":31,"posterImage":221,"relatedSolution":222},177,"self-host-langfuse-vps",{"fr":208,"en":210,"ar":211,"es":212},"self-host-langfuse-on-a-vps-llm-observability-no-saas-bill","استضافة-langfuse-على-vps-مراقبة-llm-بلا-فاتورة-saas","alojar-langfuse-en-un-vps","Héberger Langfuse sur un VPS : observabilité LLM sans SaaS","Auto-hébergez Langfuse sur un VPS : traçage, évaluation de prompts et suivi des coûts LLM. Guide complet : installation, nginx, TLS, SDK Python\u002FJS, dépannage.",11,"2026-07-12T00:00:00+00:00","2026-11-04T16:30:26+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[220],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fself-host-langfuse-vps-poster.svg",{"categorySlug":27,"appSlug":223},"langfuse",true,1794270763123]