Clé API Ollama : pourquoi elle n’existe pas et quoi utiliser à la place

Une installation locale d’Ollama ne comporte aucune clé API ni aucun moyen intégré pour en définir une. Le serveur HTTP qu’il exécute à l’adresse http://localhost:11434 répond à toute requête qui lui parvient. Les personnes recherchant une « clé API Ollama » ont généralement besoin de l’un des trois éléments suivants : une valeur à saisir dans le champ obligatoire de clé d’une application cliente, un moyen de sécuriser une instance accessible depuis d’autres machines, ou une clé pour le service cloud hébergé d’Ollama — le seul endroit où une clé réelle existe. Ce guide couvre ces trois cas.

Pourquoi Ollama local est livré sans authentification

Par défaut, Ollama se lie à l’adresse de bouclage 127.0.0.1 sur le port 11434. Seuls les processus s’exécutant sur la même machine peuvent s’y connecter ; une clé API n’apporterait donc qu’une gêne supplémentaire sans renforcer la sécurité : tout programme local capable de lire un fichier contenant une clé pourrait tout aussi bien appeler directement l’API. Il s’agit du même modèle de confiance utilisé par la plupart des serveurs de développement locaux.

La conséquence : il n’existe aucune OLLAMA_API_KEY variable, aucune option de clé ni de mot de passe n’est prévue dans la configuration. À l’heure où ces lignes sont rédigées, le serveur Ollama local ne comporte aucun mécanisme d’authentification intégré — sécuriser une instance accessible depuis le réseau relève entièrement de votre responsabilité, comme expliqué ci-dessous. Si vous êtes encore en cours de configuration, commencez par notre Guide d’installation d’Ollama ou l’ensemble plus large des Guide complet d’Ollama.

Que saisir dans le champ clé API des clients compatibles OpenAI

Ollama expose des points de terminaison compatibles avec l’API OpenAI sous l’adresse /v1, ce qui explique pourquoi les interfaces de discussion (chat UI), les assistants de programmation et les kits de développement logiciel (SDK) officiels OpenAI peuvent communiquer avec lui. Ces SDK refusent de créer un client sans qu’une clé API non vide soit fournie — cette vérification s’effectue côté client, avant même l’envoi de toute requête. Ollama ignore ensuite entièrement l’en-tête Authorization reçu, si bien que n’importe quelle chaîne de caractères convient. Par convention, on utilise ollama.

Python, à l’aide du SDK OpenAI officiel :

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",  # requis par le SDK, ignoré par Ollama
)

response = client.chat.completions.create(
    model="llama3.2",
    messages=[{"role": "user", "content": "Hello"}],
)
print(response.choices[0].message.content)

JavaScript / TypeScript :

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "http://localhost:11434/v1",
  apiKey: "ollama",
});

const response = await client.chat.completions.create({
  model: "llama3.2",
  messages: [{ role: "user", content: "Hello" }],
});
console.log(response.choices[0].message.content);

Le modèle doit déjà avoir été téléchargé (ollama pull llama3.2) ; sinon, la requête échouera avec une erreur « modèle introuvable ». Si vous hésitez sur la commande à exécuter, consultez nos sélections des Meilleurs modèles locaux pour Ollama.

Ajouter une authentification réelle à l’aide d’un proxy inverse

Comme Ollama ne peut pas valider les clés lui-même, la méthode standard consiste à laisser Ollama écouter uniquement sur l’interface locale (loopback) par défaut, et à placer un proxy inverse devant lui. Ce proxy gère la terminaison TLS, vérifie un jeton (token) et transmet aux requêtes valides vers 127.0.0.1:11434. Voici une configuration minimale nginx exigeant un jeton porteur (bearer token) :

server {
    listen 443 ssl;
    server_name ollama.example.com;
    # lignes ssl_certificate et ssl_certificate_key omises

    location / {
        if ($http_authorization != "Bearer YOUR-LONG-RANDOM-TOKEN") {
            return 401;
        }
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_read_timeout 600s;
    }
}

Deux détails sont essentiels. Générez le jeton à l’aide d’une commande telle que openssl rand -hex 32 plutôt que de l’inventer manuellement. En outre, la valeur élevée de proxy_read_timeout est intentionnelle : les générations en continu peuvent durer plusieurs minutes, et les délais d’attente (timeouts) par défaut des proxys risqueraient de les interrompre en plein milieu de la réponse.

L’aspect élégant de cette approche : les SDK OpenAI envoient déjà la clé sous la forme d’un en-tête Authorization: Bearer <clé>. Configurez simplement votre client pour qu’il pointe vers https://ollama.example.com/v1, définissez la clé API sur le jeton réel, et le champ clé — auparavant ignoré — devient alors un mécanisme d’authentification effectif, sans aucune modification côté client. Caddy et Traefik permettent d’appliquer la même vérification d’en-tête ou une authentification HTTP de base avec seulement quelques lignes de configuration propres ; si vous utilisez déjà l’un de ces outils, privilégiez-le plutôt que d’ajouter nginx.

Modifier l’adresse d’écoute d’Ollama : Windows, macOS, Linux

Un proxy installé sur la même machine ne nécessite aucune modification d’Ollama. Toutefois, si d’autres machines doivent accéder directement à Ollama — par exemple via un proxy hébergé sur un autre hôte, des conteneurs Docker ou des clients du réseau local (LAN) — configurez la variable OLLAMA_HOST=0.0.0.0 afin qu’il écoute sur toutes les interfaces. La méthode de configuration varie selon la plateforme.

Windows

Quittez Ollama depuis la zone de notification (system tray). Ouvrez les Paramètres, recherchez « variables d’environnement », puis sélectionnez « Modifier les variables d’environnement pour votre compte ». Ajoutez une variable nommée OLLAMA_HOST avec la valeur 0.0.0.0, enregistrez les modifications, puis redémarrez Ollama.

macOS

Les versions récentes d’Ollama pour ordinateur de bureau incluent désormais un interrupteur dans l’application permettant d’exposer le service sur le réseau — vérifiez d’abord les paramètres de l’application. Sur les anciennes installations, exécutez la commande launchctl setenv OLLAMA_HOST "0.0.0.0" et redémarrez l’application Ollama.

Linux

Pour le service systemd installé par le script officiel, exécutez sudo systemctl edit ollama.service et ajoutez :

[Service]
Environment="OLLAMA_HOST=0.0.0.0"

Puis exécutez sudo systemctl daemon-reload && sudo systemctl restart ollama.

Une mise en garde avant d’activer ce paramètre : 0.0.0.0 sur une machine disposant d’une adresse IP publique transforme votre GPU en une ressource publique. N’oubliez pas de restreindre l’accès au port 11434 via le pare-feu afin que seuls les hôtes autorisés puissent s’y connecter.

Ollama Cloud : l’endroit où une clé API réelle s’applique

Ollama Cloud exécute également des modèles trop volumineux pour la plupart des configurations matérielles locales, sur les GPU propres aux datacenters d’Ollama. Il constitue la seule composante de l’écosystème dotée de clés API réelles. Deux méthodes d’accès sont disponibles.

Via l’interface CLI locale. Exécuter ollama signin pour associer votre compte ollama.com, puis exécutez des modèles hébergés dans le cloud à l’aide de leurs étiquettes spécifiques — au moment de la rédaction de cet article, par exemple : ollama run gpt-oss:120b-cloud. Les requêtes sont associées à votre compte ; aucune gestion manuelle de clé n’est nécessaire.

Directement via HTTPS. Créez une clé API dans la section « Clés API » des paramètres de votre compte ollama.com, puis envoyez-la sous forme de jeton porteur (bearer token). L’API hébergée reproduit fidèlement l’API locale, avec toutefois https://ollama.com comme URL de base à la place de localhost:11434:

curl https://ollama.com/api/chat 
  -H "Authorization: Bearer $OLLAMA_API_KEY" 
  -d '{
    "model": "gpt-oss:120b",
    "messages": [{"role": "user", "content": "Hello"}],
    "stream": false
  }'

La gamme de modèles disponibles dans le cloud, les points de terminaison et les limites des forfaits évoluent régulièrement ; référez-vous donc à la documentation officielle d’Ollama Cloud pour connaître les noms actuels des modèles et les quotas en vigueur. Lorsque vous devez choisir entre l’inférence hébergée et le matériel local pour votre charge de travail, notre Calculateur de seuil de rentabilité entre auto-hébergement et API fournit des données chiffrées à ce sujet, ainsi que les Calculateur de VRAM vous indique si un modèle donné est compatible avec votre GPU.

Le vrai danger : une instance non authentifiée exposée sur Internet

L’histoire réelle de la sécurité autour de la clé API Ollama ne concerne pas la chaîne factice présente dans votre script Python, mais bien les milliers de serveurs Ollama que des analyses à grande échelle sur Internet détectent régulièrement en écoute sur le port 11434, sans aucune authentification. Quiconque découvre votre serveur peut exécuter des inférences gratuitement sur votre GPU, énumérer vos modèles via /api/tags, télécharger des modèles jusqu’à saturation de votre disque ou même les supprimer. Par ailleurs, toute future vulnérabilité du serveur devient exploitable sans authentification : CVE-2024-37032, une faille d’exécution de code à distance corrigée en 2024, en est un précédent.

• Conservez la valeur par défaut 127.0.0.1 sauf si un besoin réel d’accès distant l’exige.
• Pour un accès distant personnel, privilégiez un tunnel SSH (ssh -N -L 11434:127.0.0.1:11434 utilisateur@serveur) ou un réseau privé virtuel (VPN) tel que WireGuard ou Tailscale, plutôt que d’ouvrir le port.
• Si l’accès public est indispensable, placez un proxy inverse authentifié et terminant TLS devant le service, comme illustré ci-dessus.
• Gardez Ollama à jour afin de corriger les vulnérabilités connues.

Questions fréquemment posées

Ollama nécessite-t-il une clé API ?

Non. Un serveur Ollama local n’implémente aucune authentification, ni aucune option pour en activer une. Les seules clés API Ollama réelles sont celles d’Ollama Cloud, générées depuis votre compte ollama.com.

Que dois-je saisir dans le champ « clé API » requis par un client ?

N’importe quelle chaîne non vide — ollama par convention. Cette exigence est purement côté client ; Ollama ignore entièrement cet en-tête. Si vous avez déployé un proxy inverse authentifiant devant Ollama, saisissez plutôt le jeton réel de ce proxy, car les clients compatibles OpenAI transmettent la clé sous forme de jeton porteur (bearer token) que le proxy peut vérifier.

Puis-je forcer Ollama lui-même à exiger une clé API ?

Pas à ce jour. Aucune variable d’environnement, aucun indicateur (flag) ni aucune option de configuration n’active l’authentification sur le serveur local, malgré des demandes répétées des utilisateurs. Le recours à un proxy inverse placé devant le serveur constitue la solution reconnue.

Comment obtenir une clé API Ollama Cloud ?

Créez un compte sur ollama.com et générez une clé dans la section « Clés API » des paramètres de votre compte. Envoyez-la sous la forme Authorization: Bearer <clé> avec vos requêtes adressées à https://ollama.com. Pour une utilisation en ligne de commande (CLI), la commande ollama signin associe automatiquement votre machine à votre compte, sans manipulation manuelle de la clé.

Pourquoi le SDK OpenAI génère-t-il une erreur d’authentification avant même d’envoyer une requête ?

Le SDK valide la présence d’une clé API dès la création du client : une clé vide ou absente entraîne donc une erreur locale, même si Ollama n’y prêterait aucune attention. Définissez api_key="ollama" (ou toute autre chaîne) et assurez-vous que l’URL de base se termine par /v1.

Est-il sécurisé d’exposer Ollama sur mon réseau domestique ?

Sur un réseau local domestique fiable, protégé par NAT, exposer Ollama avec OLLAMA_HOST=0.0.0.0 constitue une configuration courante et raisonnable. Vérifiez que votre routeur ne redirige pas le port 11434 vers cette machine, et gardez à l’esprit que tous les appareils connectés au réseau — y compris les téléphones des invités — pourront alors utiliser et gérer vos modèles.