Héberger Ollama sur un VPS en toute sécurité

Ce que vous allez mettre en place

Un seul modèle de langage à poids ouverts, exécuté sur un serveur que vous contrôlez, accessible via une API HTTP et, si vous le souhaitez, depuis une interface de chat dans votre navigateur. Ollama télécharge le modèle, le charge en mémoire et traite les requêtes sur http://127.0.0.1:11434. L’installation tient en une commande. Toute la difficulté se trouve ailleurs : choisir un modèle que votre VPS peut réellement charger en RAM et éviter d’exposer par erreur un serveur d’inférence sans authentification à l’ensemble d’Internet.

Deux avertissements importants pour commencer. Un VPS utilisant uniquement le CPU exécute lentement les petits modèles, et l’API ne fournit aucune authentification intégrée. Ces deux points sont détaillés ci-dessous, car ce sont eux qui posent le plus de problèmes.

La vérification de dimensionnement, en chiffres simples

L’empreinte mémoire d’un modèle correspond approximativement à la taille de ses fichiers, à laquelle il faut ajouter environ un gigaoctet pour le runtime, puis un peu de mémoire supplémentaire pour la fenêtre de contexte. Les tags par défaut de la plupart des modèles Ollama populaires, notamment llama3.2:3b, llama3.1:8b et mistral:7b, utilisent une quantification sur 4 bits (Q4_K_M), qui consomme environ un demi-gigaoctet de RAM par milliard de paramètres. Tous les tags par défaut ne sont pas en Q4 : les petits modèles comme smollm2:135m sont fournis en 16 bits. Vérifiez donc la ligne de quantification sur la page du modèle dans la library avant de faire vos calculs. Le calcul est simple et détermine tout. Le dernier terme est celui que vous définissez vous-même : augmenter num_ctx au-delà de la petite valeur par défaut d’Ollama permet de gérer des prompts plus longs, mais augmente la taille du KV cache en RAM. Définissez donc la longueur du contexte avant de vérifier si le modèle tient en mémoire.

Un modèle 3B comme llama3.2:3b représente un téléchargement d’environ 2 GB et nécessite environ 4 GB de RAM libre pour fonctionner. Un modèle 7B ou 8B comme mistral:7b ou llama3.1:8b occupe environ 5 GB sur disque et nécessite environ 8 GB de RAM, ou 16 GB pour fonctionner confortablement. Un modèle 13B ou 14B nécessite environ 16 GB. Tout modèle compris entre 30B et 70B nécessite une machine équipée de beaucoup de RAM ou, plus réalistement, un GPU. Sur un VPS CPU, il ne tiendra généralement pas en mémoire ou répondra si lentement qu’il sera inutilisable.

Parlons maintenant de la vitesse, car c’est souvent le point sous-estimé. L’inférence sur CPU dépend de la bande passante mémoire, et non de la fréquence d’horloge. Un VPS avec vCPU partagé dispose d’une bande passante modeste. Comptez de quelques tokens à quelques dizaines de tokens par seconde : un modèle 7-8B en Q4 peut atteindre 4 à 10 tokens par seconde, contre 10 à 25 pour un modèle 3B. Un GPU est environ dix fois plus rapide. Ces chiffres sont volontairement approximatifs. La meilleure approche consiste à mesurer les performances de votre propre machine, comme l’explique l’étape d’exécution ci-dessous. Fiez-vous à votre eval rate, et non au chiffre indiqué dans un article, y compris celui-ci.

Conclusion pratique : les petits modèles quantifiés sur CPU sont réellement utiles pour rédiger, résumer et classifier, si vous acceptez leur vitesse. Pour les modèles plus grands ou les traitements plus rapides, prévoyez une instance avec GPU. Si vous préférez voir ces calculs appliqués de bout en bout à un modèle précis, exécuter Nemotron 3.5 Lightning sur un VPS explique quel tag télécharger, quelle quantité de RAM le modèle nécessite réellement et si un fonctionnement uniquement sur CPU est suffisamment rapide.

Pour évaluer un modèle précis sur une machine donnée, estimez ici son empreinte mémoire :

Installer Ollama

Deux méthodes propres sont possibles. Le script officiel est la solution la plus simple sur un VPS sans autre couche :

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

Cette commande crée un utilisateur système nommé ollama, installe le binaire dans /usr/local/bin/ollama et enregistre un service systemd nommé ollama.service. Le service démarre au boot et écoute sur 127.0.0.1:11434. Vérifiez qu’il fonctionne :

systemctl status ollama
ollama --version

Si vous utilisez déjà Docker, employez plutôt le conteneur :

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

Notez le préfixe 127.0.0.1: dans le mapping de port. Il lie le port à localhost uniquement. Si vous écrivez -p 11434:11434 à la place, le port est publié sur toutes les interfaces. C’est l’erreur signalée dans la section consacrée à la sécurité. Choisissez une seule méthode d’installation. N’exécutez pas le script et le conteneur en même temps, car deux processus essaieraient d’utiliser le même port.

Télécharger et exécuter votre premier modèle

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull télécharge les couches du modèle sur le disque (environ 2 GB pour celui-ci). run les charge en mémoire et vous place devant une invite >>>. Saisissez une question. Le premier token peut prendre plusieurs secondes, le temps que les poids soient chargés du disque dans la RAM. La réponse est ensuite affichée progressivement. Saisissez /bye pour quitter le chat. Ollama continue de fonctionner en arrière-plan.

Vérifiez ce qui est chargé et la manière dont les ressources sont utilisées :

ollama ps

La colonne PROCESSOR indique la réalité. 100% CPU signifie qu’aucun GPU n’est utilisé. C’est la cause de la lenteur. Mesurez la vitesse réelle avec l’option verbose :

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

La ligne eval rate affichée à la fin indique le nombre de tokens par seconde sur ce matériel. C’est la valeur à prendre en compte pour la planification.

Emplacement des modèles et capacité de stockage à prévoir

Installés par le script et exécutés par le service, les modèles se trouvent dans le répertoire personnel de l’utilisateur ollama :

sudo du -sh /usr/share/ollama/.ollama/models

Lorsqu’ils sont exécutés de manière interactive avec votre propre utilisateur, ils se trouvent dans ~/.ollama/models. Dans le conteneur, ils se trouvent dans le volume nommé ollama. Ce point est important, car les poids quantifiés occupent rapidement beaucoup d’espace : un modèle 3B utilise environ 2 GB, un modèle 7-8B environ 5 GB et un modèle 14B environ 9 GB. Si vous téléchargez quatre modèles pour les comparer, vous aurez consommé 20 GB sans vous en rendre compte. Prévoyez la capacité du disque en fonction des modèles que vous souhaitez conserver, puis supprimez les autres avec ollama rm <model>. Si le même VPS exécute déjà un autre service particulièrement gourmand, comme PhotoPrism ou Immich qui stocke une photothèque, déduisez d’abord cet espace de l’espace libre et considérez ce qui reste comme votre budget réel pour les modèles.

Exécuter le service sous votre contrôle

Le script d’installation a déjà enregistré ollama.service. Le service redémarre donc au boot sans configuration supplémentaire. Le paramètre qu’il est utile de modifier est la durée pendant laquelle un modèle reste chargé en mémoire. Selon l’installation, vous pouvez aussi modifier l’adresse d’écoute. Ces deux paramètres doivent être placés dans un drop-in systemd afin qu’une mise à niveau d’Ollama ne les écrase pas :

sudo systemctl edit ollama.service

Ajoutez ceci sous l’en-tête [Service] affiché par l’éditeur :

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE indique combien de temps un modèle reste en mémoire après la dernière requête (5 minutes par défaut). Augmentez cette valeur sur une machine interrogée toute la journée pour éviter de recharger les poids à chaque requête. Sur une machine disposant de peu de mémoire, définissez-la sur 0 pour libérer la RAM dès la fin d’une requête. Si vous voulez qu’un modèle reste chargé indéfiniment plutôt que pendant une durée fixe, consultez Garder un modèle Ollama chargé en permanence. Cette page explique le champ keep_alive par requête et comment recharger les poids après un redémarrage afin qu’ils soient prêts, plutôt que d’attendre la première requête lente. systemctl edit recharge les fichiers d’unité à votre place. Redémarrez donc le service pour appliquer la modification :

sudo systemctl restart ollama

Le point de sécurité le plus important

Par défaut, Ollama est lié à 127.0.0.1:11434. Seuls les processus exécutés sur le VPS peuvent donc y accéder. Ce comportement par défaut est correct. Conservez-le.

L’API n’utilise aucune authentification. Aucune. Il n’y a ni clé d’API, ni connexion, ni limite de débit. La seule allow-list disponible, OLLAMA_ORIGINS, contrôle uniquement les origines des navigateurs autorisées à l’appeler (CORS). Elle n’empêche pas une commande curl ou un script exécuté sur une autre machine d’y accéder. Toute personne pouvant atteindre le port 11434 peut exécuter n’importe quel modèle que vous avez téléchargé, en télécharger de nouveaux, les supprimer et maintenir votre CPU ou votre GPU à pleine charge indéfiniment. Des scanners comme Shodan répertorient des instances Ollama exposées par milliers. Une instance exposée est généralement découverte et exploitée en quelques heures.

Voici donc l’unique erreur à ne jamais commettre : ne définissez pas OLLAMA_HOST=0.0.0.0 et n’ouvrez pas le port 11434 dans votre firewall. Vous exposeriez un serveur d’inférence sans authentification à l’ensemble d’Internet. Aucune configuration ne rend sûre l’exposition brute de 11434 sur 0.0.0.0, car aucun des paramètres documentés d’Ollama n’ajoute d’authentification à l’API locale et une allow-list d’origines n’est pas une connexion. Cette règle concerne ce service précis. Elle n’interdit pas d’ouvrir un port dans tous les cas : un relais RustDesk auto-hébergé pour le bureau à distance doit accepter du trafic public pour fonctionner, et cela est acceptable parce qu’il fournit sa propre authentification par clé ainsi qu’une liste courte et documentée de ports. Ollama ne fournit rien de comparable.

Il existe trois moyens sûrs d’accéder au modèle depuis une autre machine :

• Le conserver en local. Si le seul appelant est un autre programme exécuté sur le même VPS, un script cron, un bot ou un serveur MCP qui relie vos outils au modèle, laissez la liaison sur 127.0.0.1 et faites appeler http://127.0.0.1:11434 par ce programme. Rien n’est exposé et aucune autre configuration n’est nécessaire.
• Passer par un tunnel privé. Ajoutez le VPS à un VPN WireGuard que vous hébergez vous-même, définissez OLLAMA_HOST sur l’adresse du tunnel, par exemple 10.8.0.1, et non 0.0.0.0, et autorisez uniquement les pairs du VPN à se connecter. Internet ne voit toujours rien sur le port 11434.
• Placer un reverse proxy avec authentification devant le service. Terminez TLS et exigez un mot de passe ou un token dans nginx, Traefik ou Caddy, puis transmettez les requêtes vers 127.0.0.1:11434. Ollama conserve sa liaison localhost ; seul le proxy écoute sur le port public. C’est le même principe que placer un certificat Let’s Encrypt sur nginx devant n’importe quel service local.

C’est exactement ce que vous permet ensuite l’interface de chat, avec une véritable connexion utilisateur.

Ajouter une interface de chat avec Open WebUI, derrière TLS

Open WebUI est une interface de chat auto-hébergée. Exécutez-la dans Docker et configurez-la pour utiliser l’instance Ollama locale :

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Le paramètre --network=host est essentiel sur un VPS Linux. Il place le conteneur dans l’espace de noms réseau de l’hôte. Ainsi, 127.0.0.1 dans le conteneur correspond à la propre interface loopback de l’hôte, et le conteneur peut joindre Ollama via 127.0.0.1:11434 sans qu’Ollama écoute sur une autre interface. La configuration avec un réseau bridge que vous trouverez ailleurs, --add-host=host.docker.internal:host-gateway avec OLLAMA_BASE_URL=http://host.docker.internal:11434, ne fonctionne pas ici : ce nom se résout vers la passerelle du bridge Docker, et un service lié à 127.0.0.1 sur l’hôte n’est pas accessible depuis le bridge. Open WebUI reste donc bloqué et indique qu’il ne peut pas se connecter à Ollama.

La contrepartie du réseau host est qu’Open WebUI écoute désormais sur le port 8080 de l’hôte, sur toutes les interfaces. Toute redirection -p est ignorée, et Docker affiche un avertissement pour le signaler. Fermez donc 8080 à la fois sur l’hôte et dans le pare-feu du fournisseur, puis faites du reverse proxy TLS l’unique point d’accès public. Lors de la toute première visite, Open WebUI vous demande de créer un compte administrateur. Ce compte constitue votre couche d’authentification : choisissez un mot de passe robuste.

Pour ouvrir le chat depuis votre ordinateur portable en HTTPS, placez un reverse proxy TLS devant 127.0.0.1:8080. Si vous acheminez déjà plusieurs applications Docker sur ce serveur, Traefik avec TLS automatique pour plusieurs applications est la solution la plus adaptée : un seul bloc de labels obtient le certificat et achemine chat.example.com vers Open WebUI. Ce même routage par labels, application par application, sera utilisé par toutes les autres interfaces web du serveur, qu’il s’agisse d’un tableau de bord d’état ou d’une application plus ludique comme Halcyon, qui présente une bibliothèque Jellyfin comme un magasin de location des années 90, chacune avec son propre hostname et sa propre connexion. La règle de la section consacrée à la sécurité reste valable : le proxy gère le port public et la connexion, tandis qu’Ollama reste sur localhost et que le propre 8080 d’Open WebUI reste filtré par le pare-feu.

Utiliser le endpoint compatible avec OpenAI depuis votre code

Ollama expose un sous-ensemble de l’API de chat OpenAI sur /v1. La plupart des bibliothèques clientes OpenAI fonctionnent donc après deux modifications : l’URL de base et une clé factice.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

La api_key est obligatoire pour la bibliothèque cliente, mais Ollama l’ignore. N’importe quelle chaîne convient. model doit correspondre à un modèle que vous avez déjà téléchargé. Un nom inconnu renvoie une erreur 404 avec model 'x' not found. Un appel curl simple suit le même principe :

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

C’est également ainsi que vous connectez le modèle aux outils d’agent et d’éditeur. Si vous développez déjà sur cette machine, un modèle local peut alimenter vos scripts et vos plugins, en complément de Claude Code exécuté sur le VPS dans tmux. Vous gardez ainsi les tâches de rédaction peu coûteuses et privées hors d’une API payante, tandis qu’un modèle hébergé prend en charge le raisonnement complexe.

Modes d’échec, avec les chaînes exactes affichées

Le processus est « Killed » en pleine génération. Vous démarrez un modèle volumineux et le terminal affiche Killed, ou le journal du serveur (journalctl -u ollama) contient une ligne qui commence par llama-server process has terminated. C’est le message utilisé par Ollama 0.40.3, vérifié le 12 octobre 2026 ; les versions antérieures affichaient llama runner process has terminated: signal: killed. Le tueur OOM de Linux a arrêté le processus, car le modèle nécessitait plus de RAM que le serveur n’en possède. Confirmez la cause avec sudo dmesg | grep -i oom : vous verrez une ligne semblable à Out of memory: Killed process .... Utilisez un modèle plus petit ou davantage quantifié, par exemple llama3.2:3b au lieu d’un modèle 13B, ou ajoutez du swap. Ainsi, une charge qui dépasse de peu la RAM physique pourra s’exécuter lentement au lieu de s’arrêter. Le swap transforme un crash immédiat en réponse lente ; il ne rend pas un modèle 70B pratique sur 4 GB. L’arrêt est silencieux, sauf si vous surveillez le terminal. Sur un serveur que vous interrogez à distance, associer une unité OnFailure= à ollama.service, qui envoie une notification à un serveur ntfy que vous hébergez pour recevoir des alertes push, vous informe dès que le processus s’arrête au lieu de vous laisser le découvrir lors de la requête suivante.

Ollama refuse de charger le modèle. La requête échoue immédiatement avec une erreur au lieu de provoquer un crash, et le journal du serveur enregistre model is too large for system memory (Ollama 0.40.3, vérifié le 12 octobre 2026). Les versions antérieures affichaient Error: model requires more system memory (X GiB) than is available (Y GiB) directement à l’invite. C’est la version contrôlée du crash précédent : Ollama a effectué le calcul et s’est arrêté au lieu de laisser le tueur OOM intervenir. Choisissez un modèle dont les besoins sont inférieurs à votre RAM disponible, vérifiez-la avec free -h, réduisez la longueur du contexte ou utilisez un VPS plus puissant. Aucun flag ne permet de faire tenir le modèle : la mémoire nécessaire est réelle.

Le premier token met très longtemps à arriver, puis tout fonctionne normalement. Un modèle froid n’affiche rien pendant cinq à trente secondes, puis diffuse normalement la réponse. Ce délai correspond au chargement initial des poids depuis le disque vers la RAM, et un stockage lent l’allonge. Une fois chargé, le modèle reste en mémoire pendant toute la durée de OLLAMA_KEEP_ALIVE ; la deuxième invite reçoit donc une réponse immédiate. Si ce premier chargement dépasse un timeout quelque part dans la chaîne d’appel, vous obtenez une erreur au lieu d’une réponse lente. Déterminer quelle couche a signalé context deadline exceeded permet de savoir si le client, le proxy ou le chargement lui-même a atteint son délai d’attente. Augmentez cette valeur si ces délais vous gênent et utilisez ollama ps pour vérifier si un modèle est actuellement chargé.

Tout est simplement lent. Vous obtenez dix tokens par seconde ou moins, sans aucune erreur. Il s’agit d’une inférence sur CPU, qui se comporte exactement comme une inférence sur CPU. ollama ps affiche 100% CPU, ce qui signifie qu’aucun GPU n’est disponible. Ce n’est pas un bug, et aucun réglage ne transforme un CPU en GPU, car la principale limite est la bande passante mémoire. Un réglage mérite toutefois d’être testé sur une VM : Ollama choisit le nombre de threads en fonction des cœurs physiques détectés, et un hyperviseur peut les déclarer incorrectement. Dans une session ollama run --verbose, essayez /set parameter num_thread 4 (ou le nombre de vCPU disponibles), relancez la même invite et conservez la valeur qui offre le meilleur eval rate. Au-delà, utilisez un modèle plus petit, acceptez cette vitesse ou passez à une instance équipée d’un GPU. Mesurez votre débit réel avec --verbose avant de conclure que quelque chose ne fonctionne pas. Lorsque l’attente vient de la longueur de la réponse et non du débit, limiter la réponse avec num_predict empêche un modèle trop prolixe de passer plusieurs minutes à générer des tokens que vous n’allez jamais lire.

La connexion est refusée depuis une autre machine. Depuis votre ordinateur portable, vous obtenez curl: (7) Failed to connect to <ip> port 11434: Connection refused. Le comportement est normal : Ollama écoute uniquement sur localhost. Ne le « corrigez » pas en le faisant écouter sur 0.0.0.0, car il s’agit précisément de l’erreur d’exposition décrite plus haut. Accédez au modèle via le VPN ou par l’intermédiaire du proxy avec authentification.

Vous avez exposé 11434 sur Internet. Si vous avez configuré OLLAMA_HOST=0.0.0.0, ouvert le firewall et constatez maintenant des téléchargements de modèles que vous n’avez pas lancés ou un CPU utilisé à 100 % par des clients inconnus, votre serveur a été découvert et utilisé. Il s’agit de l’erreur principale, pas d’un cas marginal. Configurez à nouveau l’écoute sur 127.0.0.1 ou sur l’adresse du VPN, bloquez 11434 dans le firewall et placez une authentification devant le service. Considérez que tout ce qui était accessible à cette adresse pendant l’exposition a été interrogé par des inconnus.

Sauvegardes et mises à niveau

Il y a peu d’état à préserver. Les modèles peuvent être téléchargés de nouveau. Les seuls éléments qui méritent une sauvegarde sont donc le volume de données d’Open WebUI, les comptes, l’historique des conversations, les paramètres et tout fichier drop-in systemd que vous avez créé. Sauvegardez le volume avec un conteneur temporaire :

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Mettez à niveau Ollama en réexécutant le script d’installation. Mettez à niveau Open WebUI avec docker pull ghcr.io/open-webui/open-webui:main, puis recréez le conteneur. Attention à un point concernant la branche 0.40 : Ollama 0.40.2 a commencé à mettre à niveau en arrière-plan les modèles téléchargés avec les versions précédentes et conserve les copies originales comme sauvegardes. Ces copies occupent donc davantage d’espace disque jusqu’à leur suppression. La version 0.40.3 (11 October 2026) a suspendu cette mise à niveau en arrière-plan. Vérifiez df -h après une mise à niveau et consultez les notes de version pour connaître la commande qui supprime ces sauvegardes. N’épinglez pas les versions à long terme : la qualité des modèles et le runtime évoluent rapidement. Consultez les notes de version et réévaluez les performances sur votre propre machine au lieu de vous fier aux chiffres du trimestre précédent.

FAQ

Puis-je vraiment exécuter un LLM sur un VPS sans GPU ?

Oui, dans certaines limites. Les petits modèles quantifiés de 3B à 8B paramètres fonctionnent sur CPU et sont réellement utiles pour la rédaction, le résumé et la classification, mais leur exécution est lente : comptez de quelques tokens par seconde à une vingtaine sur un vCPU partagé. Tout modèle à partir de 13B est extrêmement lent ou ne tiendra tout simplement pas en RAM. Pour une vitesse réelle ou des modèles plus volumineux, vous avez besoin d'une instance avec GPU.

De combien de RAM chaque modèle a-t-il besoin ?

Une règle approximative pour les tags 4-bit (Q4) utilisés par défaut par la plupart des modèles populaires : environ 0,5 Go de RAM par milliard de paramètres pour les poids, plus environ 1 Go de surcharge et un peu plus pour le contexte. Ainsi, un modèle 3B nécessite environ 4 Go libres, un modèle 7-8B environ 8 Go, et un modèle 14B environ 16 Go. Vérifiez votre marge disponible avec free -h et gardez de l'espace pour le système d'exploitation et les autres processus sur la machine.

L'API Ollama est-elle authentifiée ?

Non. Ollama ne dispose pas d'authentification intégrée, de clé d'API ou de limitation de débit ; quiconque peut atteindre le port 11434 en a le contrôle total. Son paramètre OLLAMA_ORIGINS limite uniquement les origines de navigateur autorisées à l'appeler, et non qui peut se connecter. C'est précisément pour cette raison qu'il se lie à 127.0.0.1 par défaut et que vous ne devez jamais exposer le port 11434 sur 0.0.0.0 à Internet. Accédez-y localement, via un VPN privé ou par l'intermédiaire d'un reverse proxy qui ajoute une authentification.

Comment ajouter une interface de chat web ?

Exécutez Open WebUI dans Docker avec --network=host afin qu'il partage le loopback de l'hôte et atteigne l'instance native d'Ollama sur http://127.0.0.1:11434, puis placez un reverse proxy TLS devant son port 8080 pour y accéder depuis votre ordinateur. Gardez le port 8080 fermé au niveau du pare-feu afin que le proxy soit l'unique porte d'entrée publique. Le compte administrateur d'Open WebUI fournit l'authentification, et vous définissez son mot de passe lors du premier lancement.

Comment l'appeler depuis ma propre application ?

Utilisez le point de terminaison compatible OpenAI sur http://127.0.0.1:11434/v1. Pointez n'importe quel SDK OpenAI vers cette URL de base, passez n'importe quelle chaîne de caractères en guise de clé d'API puisqu'elle est ignorée, et définissez model sur le nom d'un modèle que vous avez téléchargé. Le code OpenAI existant fonctionne généralement sans modification, hormis l'URL de base et la clé.