Quelle alternative à Open WebUI choisir sur un VPS ?

Quelle alternative à Open WebUI choisir sur un VPS

Les alternatives à Open WebUI sont presque toujours comparées sur un ordinateur portable, où la RAM est peu coûteuse et où aucun service n’écoute sur une adresse publique. Un VPS modifie ces deux faits, ce qui change le classement. Open WebUI reste le choix par défaut dès qu’une deuxième personne se connecte, car il fournit de vrais comptes utilisateur et un panneau d’administration. Les projets plus légers prennent l’avantage lorsque l’interface se dispute le dernier gigaoctet de RAM avec le modèle. Le prix à payer pour cet avantage est l’authentification : ils n’en proposent aucune.

Tout ce qui suit provient de la documentation de chaque projet, consultée en août 2026, revérifiée le 20 octobre 2026, puis vérifiée à nouveau pour Open WebUI, LibreChat, Hollama et OrionChat le 25 octobre 2026. La documentation d’Ollama et les règles de sécurité des navigateurs ont été revérifiées le 29 octobre 2026. Les quatre axes sont ceux qui n’apparaissent que lorsque le serveur est accessible depuis Internet.

Quatre axes qui ne comptent que sur une adresse IP publique

• Mémoire à côté du modèle. Le serveur de modèles est le processus le plus coûteux de la machine. Chaque mégaoctet utilisé par l’interface est un mégaoctet dont le modèle ne peut pas disposer.
• Authentification. Certains de ces projets gèrent des comptes utilisateur et des rôles. D’autres partent du principe qu’ils sont les seuls à fonctionner sur votre ordinateur portable et ne proposent aucune connexion.
• Inférence distante. Une interface toujours configurée pour utiliser 127.0.0.1:11434 s’attend à ce que le modèle soit hébergé sur la même machine. Si vous placez le modèle ailleurs, vous devez utiliser un tunnel qui redirige ce port local vers l’hôte du modèle.
• Maintenance. Un conteneur avec un fichier SQLite ne représente pas le même travail que six conteneurs utilisant MongoDB et une base de données vectorielle en arrière-plan.

Combien de RAM le modèle laisse-t-il à l’interface

L’interface n’est pas le composant le plus volumineux de la machine. C’est le modèle. Les tailles de téléchargement publiées donnent un minimum, car les poids doivent rester en mémoire pendant que le modèle répond. L’utilisation réelle de la mémoire est supérieure à la taille téléchargée une fois le cache de contexte alloué.

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.4"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

Ce sont les chiffres affichés par les pages de la bibliothèque Ollama le 25 octobre 2026. Il s’agit de tailles publiées, pas de mesures. Sur un VPS de 4 GB, qwen3:4b à 2.5 GB laisse moins de 1.5 GB au système d’exploitation et à tout le reste. Le cache de contexte réduit encore cette marge à mesure que la conversation s’allonge. C’est pourquoi la valeur de num_ctx que vous définissez est autant une décision de mémoire qu’une décision de qualité. qwen3:8b à 5.2 GB ne tient pas du tout sur cette machine. C’est une contrainte que les comparatifs d’ordinateurs portables ne couvrent jamais. C’est aussi dans ce cas qu’une interface de chat consommant quelques centaines de mégaoctets détermine si le modèle peut fonctionner. Si vous dimensionnez une machine pour un modèle nettement supérieur à ces tags, le calcul pour un modèle 27B sur un VPS utilisant uniquement le CPU montre à quelle vitesse l’interface cesse d’être le facteur déterminant.

Mesurez plutôt que de faire confiance à un chiffre trouvé dans un comparatif, y compris celui-ci. Exécutez docker stats --no-stream une heure après le début d’une utilisation réelle, et non une minute après le démarrage du conteneur, car la mémoire importante est allouée lors de la première utilisation. Ollama libère également les poids après cinq minutes d’inactivité. Une mesure effectuée entre deux conversations sous-estime donc le pic. Le message suivant doit alors recharger l’ensemble du modèle, sauf si vous gardez le modèle en mémoire avec keep_alive.

Open WebUI : toujours le choix par défaut pour plusieurs utilisateurs

Open WebUI s’exécute depuis une seule image et conserve ses données dans un seul volume.

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

La commande du README du projet publie -p 3000:8080, qui écoute sur toutes les interfaces. Le préfixe 127.0.0.1: le limite à loopback. Sur un VPS, ce préfixe est plus important que tout le reste de la ligne, car Docker écrit ses propres règles iptables et un port publié ignore vos règles ufw de refus.

Accédez à la page via un tunnel ou un proxy, décrits plus bas, puis créez le premier compte. Ce compte devient administrateur. L’inscription est alors désactivée jusqu’à ce qu’un administrateur réactive New Sign Ups. Les inscriptions suivantes sont créées avec le rôle pending, la valeur par défaut documentée DEFAULT_USER_ROLE. Ainsi, même un inconnu qui accède à la page ne peut pas utiliser votre modèle tant qu’un administrateur ne l’a pas approuvé.

Open WebUI consomme plus de mémoire que les projets ci-dessous, car il offre davantage de fonctionnalités. Sa page consacrée aux performances indique quels composants sont responsables de cette consommation. Le moteur d’embeddings par défaut charge un modèle sentence-transformers dans le conteneur. La documentation indique environ 500 MB ou plus par processus worker. Définir RAG_EMBEDDING_ENGINE=ollama confie cette tâche au model server que vous exécutez déjà. AUDIO_STT_ENGINE=webapi évite de charger un modèle local de speech-to-text. Avec SQLite et DATABASE_POOL_SIZE non défini, le pool utilise une grande taille interne par défaut. Chaque connexion augmente alors son propre page cache et sa propre memory map. Sur une petite machine, définissez donc DATABASE_POOL_SIZE=8 et DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. L’autocomplétion demande au modèle de générer une complétion pendant que l’utilisateur saisit encore son texte. Elle est désormais désactivée par défaut (ENABLE_AUTOCOMPLETE_GENERATION vaut False). Laissez-la donc désactivée sur une petite machine.

LibreChat : multi-utilisateur, avec une stack en arrière-plan

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

L’interface répond sur le port 3080. LibreChat est à privilégier lorsque vous avez besoin d’un système d’identités plutôt que d’une simple boîte de connexion : sa documentation décrit les connexions LDAP et OAuth2, et son fichier compose par défaut définit également un panneau d’administration pour les utilisateurs, les groupes et les rôles. Le panneau ne fonctionne pas immédiatement. Il refuse de démarrer tant que ADMIN_PANEL_SESSION_SECRET n’est pas défini dans .env. Cette valeur obligatoire doit comporter au moins 32 caractères et n’a aucune valeur par défaut. Générez-en une avec openssl rand -hex 32 si nécessaire. Le panneau s’exécute comme un service distinct, et non dans le processus LibreChat. Il nécessite LibreChat v0.8.5 ou une version ultérieure. Le projet le présente encore comme une fonctionnalité en préversion. Cette fonctionnalité est fournie avec une stack.

[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 5,
    "notes": "api, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

Le fichier compose par défaut démarre 5 services : api, MongoDB, Meilisearch, pgvector, RAG API. Un sixième service, le panneau d’administration, figure dans le même fichier et rejoint les autres une fois son secret défini. Aucun de ces services n’est le modèle. MongoDB et pgvector nécessitent chacun leur propre mémoire. Sur une machine dotée de 4 GB de RAM, cette mémoire est donc indisponible pour le modèle.

Deux services du fichier publient des ports, et aucun des deux mappings ne précise d’adresse d’écoute : l’API sur le port 3080 et le panneau d’administration sur le port 3000 de l’hôte, valeur par défaut de ADMIN_PANEL_PORT. Ils écoutent donc tous deux sur toutes les interfaces dès qu’ils démarrent. Open WebUI utilise également le port 3000 plus haut. Les deux services entrent donc en conflit sur une même machine dès que le panneau est activé. Modifiez les deux bindings vers 127.0.0.1 dans docker-compose.override.yml avant d’exposer la stack à Internet.

Les mises à niveau passent par une opération git. C’est là que les erreurs surviennent souvent.

docker compose down
git pull
docker compose pull
docker compose up -d

git pull s’arrête avec un conflit si vous avez modifié le fichier suivi docker-compose.yml. La mise à niveau est alors appliquée partiellement. Placez vos modifications dans docker-compose.override.yml, prévu à cet effet par le projet, et conservez les secrets dans .env. Ces deux fichiers ne sont pas suivis par git. git pull les laisse donc inchangés.

Configurez LibreChat pour utiliser votre propre serveur de modèles avec un endpoint personnalisé dans librechat.yaml.

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

Remplacez model-host par l’adresse de la machine qui exécute Ollama. Le champ apiKey doit être présent même si Ollama ignore sa valeur. Un placeholder convient donc. Si LibreChat s’exécute dans Docker et Ollama sur la même machine, localhost désigne le conteneur lui-même. Utilisez donc host.docker.internal à cet endroit.

Hollama et OrionChat : le navigateur fait le travail

Hollama fournit une application web depuis un petit conteneur. Les conversations sont stockées dans le navigateur, pas sur le serveur.

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

La version de cette commande présente dans le README utilise --rm, qui supprime le conteneur à son arrêt. L’interface ne revient donc jamais après un redémarrage.

OrionChat va plus loin et ne comporte aucun composant serveur. Clonez le dépôt et servez le répertoire avec le serveur web que vous utilisez déjà, ou ouvrez index.html depuis le disque. Les clés API sont stockées dans localStorage du navigateur, l’historique des conversations reste dans le navigateur, et l’application supprime les conversations les plus anciennes lorsque leur nombre dépasse 512. L’adresse Ollama d’OrionChat est codée en dur dans son source (js/script.js), à http://localhost:11434, et ses paramètres ne contiennent aucun champ permettant de la modifier.

Aucun des deux projets ne propose de login. Sur un laptop, ce n’est pas un problème. Sur un VPS, cela signifie que la page ne doit jamais être publiée sur 0.0.0.0. Cela implique aussi un point plus facile à manquer : c’est le navigateur, et non le serveur, qui appelle le modèle.

Ce point détermine les cas où ces deux applications sont utilisables. Votre navigateur doit pouvoir joindre Ollama directement. Pour OrionChat, cela signifie toujours localhost:11434 sur la machine qui exécute le navigateur. Sur un VPS, le tunnel SSH ci-dessous est donc son seul accès au modèle. Hollama accepte toute adresse que vous saisissez comme URL de base de la connexion, et son guide d’auto-hébergement explique comment utiliser un serveur Ollama sur un autre appareil : ajoutez l’origine de Hollama à OLLAMA_ORIGINS côté Ollama. Sauf si vous transférez le port avec SSH, Ollama doit donc écouter au-delà de l’interface loopback. De plus, l’API Ollama ne demande ni login ni clé. Deux règles de navigateur en découlent. Une page servie en HTTPS ne peut pas appeler un endpoint HTTP simple sur une adresse IP publique, et la console affiche Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked.. L’interface loopback bénéficie d’une exception distincte : la spécification Mixed Content bloque uniquement les URL qui ne sont pas potentiellement fiables, tandis que la spécification Secure Contexts considère localhost, 127.0.0.0/8 et ::1 comme potentiellement fiables. La même page HTTPS peut donc appeler http://localhost:11434 ou http://127.0.0.1:11434. C’est cette exception qu’utilise le tunnel SSH ci-dessous. Depuis la version 142, Chrome ajoute une étape lorsque la page provient d’un site public tel que https://chat.example.com : une requête vers une adresse loopback ou du réseau local attend que l’utilisateur autorise l’accès au réseau local dans une invite d’autorisation. Chrome exempte également des contrôles de contenu mixte les requêtes HTTP soumises à autorisation vers des endpoints du réseau local lorsque le nom d’hôte est un littéral d’adresse IP privée tel que 192.168.0.1, un nom .local, ou lorsque la requête fetch indique targetAddressSpace: "local". Une page que vous ouvrez à http://localhost via le tunnel est déjà sur l’interface loopback ; cette invite ne s’applique donc pas. Un appel vers toute autre origine est refusé avec has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource tant que vous n’avez pas autorisé cette origine.

La méthode documentée par Ollama pour modifier l’un ou l’autre paramètre consiste à utiliser un override systemd.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

ss doit maintenant afficher 0.0.0.0:11434, alors qu’il affichait auparavant 127.0.0.1:11434. N’effectuez cette modification que si un firewall ou un proxy avec authentification contrôle déjà les personnes autorisées à joindre le port. Un port 11434 ouvert correspond à un serveur de modèles ouvert, et les scanners automatisés atteignent rapidement un nouveau port public. Le tunnel SSH ci-dessous évite entièrement ce problème : la page s’exécute alors sur une origine localhost, qu’Ollama autorise par défaut, et le port ne quitte jamais la machine.

Chaque interface peut-elle utiliser un endpoint Ollama ou vLLM distant

Open WebUI le permet, et la connexion est établie côté serveur. OLLAMA_BASE_URL=http://model-host:11434 le dirige vers Ollama. Pour vLLM, définissez OPENAI_API_BASE_URL=http://model-host:8000/v1 en conservant le /v1 sous lequel vLLM expose son API. Définissez OPENAI_API_KEY uniquement si le serveur a été démarré avec une clé, car le guide vLLM d’Open WebUI n’utilise pas d’authentification dans les autres cas. Les autres serveurs compatibles avec l’API OpenAI utilisent le chemin de base indiqué dans leur propre documentation. Ce n’est pas toujours /v1. OPENAI_API_BASE_URLS accepte plusieurs backends séparés par des points-virgules.

LibreChat le permet via le baseURL de l’endpoint personnalisé présenté plus haut. Cette requête quitte également le serveur. Aucune règle du navigateur ne s’applique donc. La même URL de base et la même clé factice fonctionnent aussi en dehors d’une fenêtre de chat. C’est tout ce qu’il faut pour connecter un agent de code au modèle que vous hébergez déjà.

Hollama peut utiliser n’importe quel endpoint saisi dans ses paramètres. Sa connexion Ollama dispose d’une URL de base modifiable, qui vaut par défaut http://localhost:11434. Hollama propose également une connexion compatible avec l’API OpenAI, http://localhost:8080/v1 par défaut. C’est cette connexion qui permet d’utiliser vLLM. La requête quitte votre navigateur. Tout ce qui est indiqué dans la section précédente s’applique donc aussi ici. OrionChat ne peut être dirigé vers aucun autre endpoint. Ses endpoints sont codés en dur. Ollama est fixé à http://localhost:11434/v1/chat/completions, et son README indique que les requêtes sont envoyées directement vers l’API officielle de chaque fournisseur. Un Ollama distant est accessible uniquement via un tunnel SSH qui le fait répondre sur ce port local. Aucun paramètre ne permet d’utiliser un serveur vLLM.

Séparer l’interface du modèle est le principal intérêt d’un endpoint distant. Placez l’interface sur une petite machine et le modèle sur celle qui dispose de la mémoire nécessaire. C’est également le moment de décider si Ollama ou vLLM doit traiter les requêtes, car leur comportement devient très différent lorsque plusieurs personnes utilisent le modèle simultanément. Si le serveur de modèles n’existe pas encore, commencez par exécuter Ollama sur un VPS. Sur une machine uniquement équipée d’un CPU, lisez la comparaison entre Ollama et llama.cpp avant de choisir votre runner.

Ne publiez jamais une interface de chat sans authentification sur 0.0.0.0

La page de renforcement de la sécurité d’Open WebUI indique que le projet est « conçu pour des réseaux privés et de confiance, comme d’autres infrastructures auto-hébergées telles que les bases de données, les registres de conteneurs et les serveurs CI ». Elle recommande de le placer derrière un VPN ou un reverse proxy avec authentification. Un projet totalement dépourvu d’authentification mérite au minimum les mêmes précautions.

Vérifiez ce qui écoute avant de faire confiance à quoi que ce soit.

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

La ligne 127.0.0.1:3000 est celle que vous recherchez. Une ligne 0.0.0.0:3000 signifie que le service écoute sur toutes les adresses, et Docker permet par défaut à toute adresse IP source externe d’atteindre un port publié. Sauf si une règle de la chaîne DOCKER-USER de Docker ou du firewall de votre fournisseur le bloque, votre interface de chat est accessible depuis Internet. Depuis votre propre machine, la réponse de curl -sI http://YOUR.VPS.IP:3000 à HTTP/1.1 200 OK tranche encore plus directement la question.

Désactiver l’authentification d’Open WebUI avec WEBUI_AUTH=False est un réglage prévu pour un utilisateur unique, sur une machine inaccessible aux autres utilisateurs. Sa documentation précise également que ce réglage ne fonctionne que sur une installation sans utilisateur enregistré. Vous ne pouvez donc pas l’appliquer à une installation qui contient déjà des comptes.

Méthode 1 : écouter sur loopback et utiliser SSH pour y accéder. Publiez chaque port sur 127.0.0.1, puis transférez uniquement ce dont vous avez besoin : ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, et ouvrez http://localhost:3000 sur votre laptop. Rien n’est publié, donc rien ne peut être détecté par scan. Pour OrionChat, transférez le port du modèle dans la même commande avec -L 11434:127.0.0.1:11434 et laissez Ollama écouter sur loopback. Hollama peut accéder directement à Ollama, mais ce même transfert maintient Ollama hors d’Internet, ce qui en fait également la méthode la plus sûre pour Hollama. Cette méthode est seulement aussi sûre que votre configuration SSH. Associez-la donc à un accès SSH par clé uniquement et un sshd renforcé.

Méthode 2 : un reverse proxy qui authentifie la requête avant qu’elle n’atteigne l’application. Laissez l’application sur loopback, laissez le proxy gérer le port 443 et placez un système de single sign-on devant elle. Traefik configuré avec des labels Docker Compose et Authentik comme fournisseur d’identité fournissent à chaque application de la machine une authentification et un certificat uniques. Avec Open WebUI derrière TLS (transport layer security), définissez WEBUI_SESSION_COOKIE_SECURE=true et WEBUI_SESSION_COOKIE_SAME_SITE=strict. Réduisez également JWT_EXPIRES_IN par rapport à sa valeur par défaut de quatre semaines, car la documentation d’Open WebUI indique que, sans Redis, une déconnexion n’invalide pas le token : celui-ci reste utilisable jusqu’à son expiration.

La méthode 2 ne protège pas les projets accessibles uniquement depuis le navigateur. Un proxy placé devant la page ne protège pas le endpoint du modèle. De plus, une requête fetch de cette page vers un autre hostname ne transmet pas votre cookie de session. Le proxy d’authentification placé devant Ollama répond donc par une redirection vers un formulaire de connexion, et le chat échoue. Faites passer le endpoint du modèle par le même hostname que la page, ou utilisez la méthode 1.

Choisir une solution

Si d’autres personnes que vous doivent l’utiliser, déployez Open WebUI. Il gère de vrais comptes, place les nouveaux utilisateurs dans une file d’approbation, et ses mainteneurs publient des recommandations de hardening que vous pouvez appliquer. Si vous avez besoin de LDAP ou d’un panneau d’administration, déployez LibreChat, définissez ADMIN_PANEL_SESSION_SECRET si vous voulez le panneau, puis vérifiez avec docker stats que ses cinq services, six avec le panneau, ainsi que votre modèle tiennent réellement dans les ressources disponibles avant de vous en remettre à cette solution. S’il s’agit d’une seule personne sur une petite machine où le modèle utilise déjà la majeure partie de la RAM, servez Hollama ou OrionChat via un tunnel SSH et laissez le navigateur conserver l’état. Sur un VPS, la mauvaise réponse consiste à publier l’un de ces services sur 0.0.0.0 sans authentification en amont.

FAQ

Open WebUI peut-il être exposé directement sur une adresse IP publique en toute sécurité ?

Sa page de renforcement de la sécurité le décrit comme un logiciel destiné aux réseaux privés de confiance, dans la même catégorie qu’une base de données ou qu’un serveur CI. Il gère bien de véritables comptes : le premier compte devient administrateur, tandis que les suivants restent pending jusqu’à leur approbation. Il est donc bien plus sûr qu’une interface sans authentification. Placez-le tout de même derrière un reverse proxy avec TLS et, si possible, un système d’authentification unique. Publiez le port du conteneur sous la forme 127.0.0.1:3000:8080 afin que les règles iptables de Docker ne l’ouvrent pas à Internet à votre insu.

Quelle alternative à Open WebUI utilise le moins de RAM sur un VPS ?

Les interfaces exécutées dans le navigateur, Hollama et OrionChat, car l’application s’exécute côté client. Le serveur envoie uniquement des fichiers statiques, et OrionChat n’a même pas besoin d’un conteneur applicatif. Open WebUI conserve en mémoire un processus Python, une base de données et, par défaut, un modèle local d’embeddings. Sa documentation indique environ 500 MB ou plus par worker pour le seul modèle d’embeddings. Vérifiez ces valeurs sur votre propre serveur avec docker stats --no-stream, car elles varient selon les fonctionnalités activées.

Ces interfaces de chat peuvent-elles utiliser un serveur Ollama sur un autre hôte ?

Open WebUI et LibreChat le permettent, et leur serveur établit la connexion. Les règles du navigateur ne s’appliquent donc pas. Définissez OLLAMA_BASE_URL pour Open WebUI, ou baseURL dans un endpoint personnalisé pour LibreChat. Pour vLLM ou un autre serveur compatible avec l’API OpenAI, utilisez OPENAI_API_BASE_URL avec le chemin de base documenté par ce serveur. Pour vLLM, ce chemin est /v1. Ajoutez une clé API uniquement si le serveur l’exige. Hollama peut également pointer vers n’importe quelle adresse, mais la requête provient de votre navigateur. L’endpoint doit donc être accessible depuis votre navigateur. OrionChat ne le permet pas : son adresse Ollama est codée en dur à http://localhost:11434. Un Ollama distant ne fonctionne donc qu’au moyen d’un tunnel SSH qui redirige ce port.

Pourquoi mon interface de chat dans le navigateur ne peut-elle pas joindre Ollama ?

Deux causes couvrent presque tous les cas. Ollama écoute par défaut sur 127.0.0.1:11434. Un navigateur installé sur une autre machine ne peut donc pas le joindre directement tant que OLLAMA_HOST n’est pas modifiée ou qu’un tunnel SSH ne redirige pas le port. Ollama accepte par défaut les requêtes cross-origin provenant de localhost, 127.0.0.1 et 0.0.0.0. Une page servie depuis votre propre domaine est donc refusée avec No 'Access-Control-Allow-Origin' header is present on the requested resource tant que cette origine n’est pas ajoutée à OLLAMA_ORIGINS. Si la page utilise HTTPS et que l’endpoint utilise HTTP en clair sur une adresse IP publique, le navigateur bloque la requête comme contenu mixte avant même qu’Ollama ne la reçoive. Les adresses de loopback (localhost, toute adresse de 127.0.0.0/8 telle que 127.0.0.2, ou [::1]) sont exemptées. Chrome exempte également les requêtes HTTP vers le réseau local utilisant des adresses IP privées littérales telles que 192.168.0.1, des noms d’hôte .local ou targetAddressSpace: "local" après l’autorisation d’accès au réseau local. Les exigences CORS d’Ollama restent toutefois applicables. Définissez les deux variables dans une surcharge systemctl edit ollama.service, ou redirigez le port via SSH : le problème disparaîtra.