Passer au contenu principal
Par défaut, Ollama écoute sur 127.0.0.1:11434, donc seule votre machine peut s’y connecter. En définissant OLLAMA_HOST=0.0.0.0, il écoute sur toutes les interfaces réseau, mais Ollama ne propose aucune authentification intégrée : toute entité atteignant le port 11434 peut utiliser l’API sans aucune vérification. Il est donc préférable de conserver Ollama sur localhost et d’exécuter à côté le connecteur Tokios : ce dernier se connecte à https://api.tokios.com, tandis que vos outils, collègues ou agents peuvent interroger l’endpoint sécurisé situé à 1 depuis n’importe où.
Idéal pour les débutants. Ollama constitue le moyen le plus rapide de faire tourner un modèle local — il suffit de lancer ollama run <model> pour commencer à servir des requêtes. C’est un excellent choix de backend pour Tokios.

Les premières tentatives des utilisateurs — et leurs limites

Chacun de ces outils convient à des usages généraux. Aucun n’a été conçu spécifiquement pour « exposer une API d’inférence locale à Internet », d’où des restrictions documentées qui se manifestent précisément dans ce type de scénario.
Cette configuration fait en sorte qu’Ollama écoute sur toutes les interfaces réseau, pas uniquement sur la boucle locale. Comme il n’existe aucune authentification intégrée, toute entité atteignant le port peut utiliser l’API — lister les modèles, effectuer des inférences, télécharger des modèles — sans aucune vérification. Des chercheurs en sécurité (SentinelLABS/Censys, 2026) ont identifié environ 175,000 serveurs Ollama exposés ainsi à Internet.
La redirection du port 11434 vers votre machine comporte deux problèmes majeurs. Si votre FAI utilise le CGNAT, vous ne disposez pas d’une adresse IP publique stable à rediriger. Même si vous parvenez à ouvrir un port, des outils de scan tels que Shodan et Censys indexent les services exposés en quelques heures ou jours — et, là encore, aucune authentification n’est appliquée à moins d’en mettre une vous-même.
Tailscale répond bien aux besoins d’accès individuel : vos propres appareils rejoignent un réseau privé en maillage (« tailnet ») et peuvent communiquer entre eux en toute sécurité. Toutefois, pour tout usage collectif, les collègues ou les clients SaaS souhaitant interroger votre modèle doivent d’abord rejoindre ce tailnet, ce qui ne correspond pas au modèle classique de clé API publique. Tailscale Funnel permet de publier un service publiquement, mais il se limite à un ensemble fixe de ports et ne permet pas de régler la bande passante.
Cloudflare Tunnel redirige le trafic via le réseau Edge de Cloudflare sans nécessiter de port entrant, ce qui correspond bien à nos besoins. Toutefois, par défaut, Cloudflare met en mémoire tampon les réponses au lieu de les transmettre en flux continu, sauf si celles-ci comportent un en-tête de type de contenu text/event-stream. De plus, les requêtes proxyées sont soumises aux délais d’attente imposés par Cloudflare (environ 100 secondes dans la version gratuite, moins dans certains abonnements) ; ainsi, les générations de longue durée risquent d’être interrompues en cours de transmission.
ngrok se met en place rapidement et convient bien aux démonstrations. Le forfait gratuit limite l’utilisation à 1 Go de données et à 20,000 requêtes par mois ; de plus, les tunnels gratuits affichent une page d’avertissement avant d’accéder à votre service, ce qui reste acceptable pour un lien de démonstration mais moins adapté si des collègues ou des agents doivent interroger l’API de façon régulière.
Rien de tout cela ne vise à critiquer ces outils : ils répondent à d’autres besoins (réseaux en maillage, proxying Edge, création rapide de liens de démonstration). Tokios, lui, a été conçu spécifiquement pour un seul objectif : transformer un point de terminaison de modèle local en une API authentifiée que l’on peut solliciter depuis n’importe où.

La méthode ne permettant que l’envoi de données

1

Lancez Ollama localement, comme d’habitude.

Laissez Ollama sur la version 127.0.0.1 — ne modifiez pas la valeur de OLLAMA_HOST. Téléchargez puis exécutez votre modèle.
Laissez-le écouter les requêtes sur le port http://127.0.0.1:11434 par défaut.
2

Associez le connecteur Tokios.

Connectez-vous sur tokios.com/console, ouvrez l’onglet Setup puis cliquez sur Start pairing. Tokios affiche alors un code d’appairage unique, tel que TKS-XXXX-XXXX, valable environ 15 minutes.Sur la machine exécutant Ollama, lancez la commande d’installation unique adaptée à votre système d’exploitation.
Windows
macOS
Linux
Avez-vous déjà installé tokios-connector ? Dans ce cas, saisissez directement le code requis.
De retour dans la console, sélectionnez l’appareil approve dans l’onglet Setup ou Connectors. Le jeton du connecteur est transmis via le tunnel après approbation — vous ne le verrez jamais à l’écran ni ne devrez le coller dans un fichier.
3

Configurez le connecteur afin qu’il pointe vers l’API /v1 d’Ollama.

Ollama propose une interface compatible OpenAI à l’adresse /v1, et c’est cette interface que Tokios utilise, et non les points de terminaison natifs d’Ollama (/api). Pour un déploiement à un seul modèle, l’assistant de configuration de la console choisit automatiquement http://127.0.0.1:11434/v1 comme ID de modèle amont. Si vous utilisez plusieurs modèles via un fichier de configuration tokios-connector.json, indiquez manuellement l’ID de modèle amont BaseUrl.
Consultez Configuration du connecteur pour connaître le format complet du fichier prenant en charge plusieurs modèles.
4

Effectuez le déploiement.

Dans l’onglet Models, enregistrez le modèle d’Ollama et choisissez un nom public — par exemple, llama3-tunnel. Ce nom public, et non l’ID de modèle local d’Ollama, est celui que les clients transmettent dans le champ model.
5

Générez une clé API.

Dans l’onglet Keys, cliquez sur Create key. Vous pouvez également limiter son utilisation à certains déploiements grâce à des motifs de noms de modèles (liste séparée par des virgules, * pour autoriser tous les modèles). Copiez immédiatement la clé sk-tok-… ; elle ne s’affiche qu’une seule fois.

Utilisez-la depuis n’importe quel endroit.

Une fois que vous disposez d’un nom de déploiement et d’une clé API, tout client compatible OpenAI ou Anthropic peut accéder à votre modèle d’Ollama, que ce soit depuis une autre machine, l’ordinateur d’un collègue ou un agent hébergé.
Le champ model indique toujours le nom de votre déploiement enregistré (llama3-tunnel ci-dessus), jamais l’ID de modèle amont d’Ollama. Consultez Utiliser Claude Code pour conserver les variables d’environnement d’une session à l’autre.

Tokios contre Ollama Cloud

Ollama propose également Ollama Cloud : il s’agit de modèles hébergés accessibles via ollama run <model>:cloud ou une clé API d’Ollama. Les poids des modèles s’exécutent sur l’infrastructure d’Ollama et sont transmis via votre démon ollama local lorsque vous êtes connecté. Cette solution gérée est intéressante, mais elle s’oppose au auto-hébergement : vos requêtes sont envoyées aux serveurs d’Ollama, et aucun poids local ne peut être contrôlé via un tag :cloud. (Certains modèles de pointe — Kimi, MiniMax, ainsi que les plus grands niveaux de Nemotron — ne sont disponibles sur Ollama qu’en version :cloud, pour cette raison précise.) Tokios s’adresse à l’autre cas de figure : le modèle s’exécute sur votre matériel, et Tokios se contente de mettre en place un point de terminaison authentifié devant celui-ci. Vous conservez ainsi les poids, le chemin des données et les clés. Les deux options peuvent être utilisées simultanément : exécutez des modèles légers en local via Tokios et accédez à un modèle :cloud lorsque nécessaire — toutefois seul le déploiement local garantit que vos données restent sur votre propre matériel.

Questions fréquentes

Par défaut, Ollama écoute sur le port 11434, limité à 127.0.0.1 (uniquement localhost). Vous pouvez modifier le port et l’adresse d’écoute via la variable d’environnement OLLAMA_HOST ; par exemple, OLLAMA_HOST=0.0.0.0:11435 permet d’écouter sur toutes les interfaces au port 11435. Pour vérifier que Ollama fonctionne, utilisez curl http://localhost:11434.
Définissez la variable d’environnement OLLAMA_HOST=0.0.0.0 (ou OLLAMA_HOST=0.0.0.0:11434) puis redémarrez Ollama. Sur Linux avec systemd, ajoutez Environment="OLLAMA_HOST=0.0.0.0:11434" sous [Service] dans ollama.service puis exécutez systemctl daemon-reload && systemctl restart ollama. Sur macOS, utilisez launchctl setenv OLLAMA_HOST "0.0.0.0:11434". Sur Windows, configurez OLLAMA_HOST dans les variables d’environnement de l’utilisateur puis redémarrez Ollama.
Non. Ollama ne propose aucune authentification intégrée ; il a été conçu pour un usage local et non pour un contrôle d’accès multi-utilisateurs. Les développeurs recommandent de placer un proxy inverse tel que nginx ou Caddy devant Ollama si une authentification est nécessaire. Tokios, quant à lui, permet de générer des clés API sk-tok-… à portée définie sans proxy inverse : il suffit d’associer un connecteur, d’enregistrer un déploiement et de créer une clé ; les appelants s’authentifient alors via https://api.tokios.com au lieu de se connecter directement au port d’Ollama.
Ollama propose des points de terminaison natifs ainsi que des points de terminaison compatibles avec OpenAI. Pour l’API native : curl http://localhost:11434/api/generate -d '{"model": "llama3", "prompt": "Hello"}'. Pour l’interface compatible OpenAI : curl http://localhost:11434/v1/chat/completions -d '{"model": "llama3", "messages": [{"role": "user", "content": "Hello"}]}'. Depuis un poste distant, remplacez localhost par l’adresse IP du serveur (cela nécessite OLLAMA_HOST=0.0.0.0).
Oui. Ollama accepte par défaut les requêtes cross-origin provenant de 127.0.0.1 et 0.0.0.0. Définissez OLLAMA_ORIGINS pour ajouter d’autres origines ; pour les extensions navigateur, utilisez OLLAMA_ORIGINS=chrome-extension://*,moz-extension://*. Cette configuration ne concerne que les clients navigateur ; les clients API utilisant curl ou les SDK ne sont pas soumis aux règles CORS.
Oui. Définissez "stream": true et Tokios renverra des événements envoyés par le serveur au format OpenAI ou Anthropic, selon l’interface API utilisée.
Oui. Créez une clé sk-tok-… distincte pour chaque collaborateur dans l’onglet Keys, puis limitez son champ d’action aux déploiements requis. La révocation d’une clé entraîne immédiatement la perte d’autorisation, ce qui permet de supprimer l’accès sans toucher à Ollama ni au connecteur.
Oui. Enregistrez d’autres déploiements dans l’onglet Models, ou utilisez un fichier de configuration tokios-connector.json pour définir plusieurs ID de modèle amont et routes associées à un seul connecteur. Consultez Configuration du connecteur.
Non. Tokios utilise l’interface Chat Completions d’OpenAI, ce qui lui permet de communiquer avec l’API compatible OpenAI de Ollama, à savoir /v1, et non avec les points de terminaison natifs que sont /api/generate et /api/chat.

Votre modèle ne quitte jamais votre machine ; votre point de terminaison fonctionne partout.

Ollama continue d’opérer exactement comme actuellement sur localhost, sans ports entrants ni API exposée. Le connecteur ne fait que des appels sortants. Tout le reste — authentification, routage, diffusion en continu — se gère via un seul point de terminaison que vous pouvez appeler depuis n’importe quelle machine, collaborateur ou agent auquel vous attribuez une clé API.

Démarrage rapide

Associez un connecteur et enregistrez votre premier modèle en toute simplicité.

Clés API

Créez, définissez les droits d’accès et renouvelez les clés sk-tok-… destinées à vos collègues et agents.

Pilotez le système grâce à un agent de codage

Dirigez Claude Code, Codex, Cline ou Cursor vers votre modèle Ollama via Tokios.