Ollama : exécuter des LLM en local sur vos serveurs

Ollama : l’IA générative sans quitter votre infrastructure

Coller un extrait de journal, un script interne ou un document client dans un assistant d’IA hébergé dans le cloud est devenu un réflexe pour beaucoup d’équipes. C’est aussi un angle mort pour la sécurité : ces données quittent le périmètre de l’entreprise, transitent par un fournisseur tiers et échappent en partie à votre politique de classification. Pour un DSI ou un RSSI, la question n’est plus de savoir si les collaborateurs utilisent l’IA générative, mais où et comment elle s’exécute.

Ollama répond à ce besoin en permettant de télécharger et d’exécuter des grands modèles de langage (LLM) directement sur un poste de travail ou un serveur, sans dépendre d’un service externe. Dans cet esprit, il complète des outils comme LM Studio, qui exécute lui aussi des modèles d’IA générative en local, mais avec une approche résolument orientée ligne de commande, service système et API.

Qu’est-ce qu’Ollama ?

Ollama est un projet open source publié sous licence MIT et développé sur GitHub (dépôt ollama/ollama). Il fournit un moteur d’exécution, un outil en ligne de commande et une API HTTP pour faire tourner des modèles ouverts tels que Llama, Gemma, Mistral, Qwen ou DeepSeek. Les modèles sont récupérés depuis la bibliothèque publique d’Ollama, à la manière d’images de conteneurs, puis exécutés localement sur le CPU ou le GPU de la machine.

Selon la documentation officielle, lorsque vous travaillez en local, les prompts et les données ne sont pas vus par l’éditeur. Ollama propose aussi des modèles hébergés dans son propre cloud : cette fonction peut être désactivée explicitement avec la variable OLLAMA_NO_CLOUD=1, ce qui est recommandé dans un contexte où la confidentialité est l’objectif principal.

Architecture et fonctionnement

Ollama repose sur une architecture client-serveur simple :

Le serveur (ollama serve) tourne en tâche de fond, généralement comme service système. Il charge les modèles en mémoire, gère la file d’attente des requêtes et expose une API REST sur le port 11434.
Le moteur d’inférence s’appuie sur llama.cpp, la bibliothèque de référence pour exécuter des modèles quantifiés (format GGUF) efficacement sur du matériel grand public, avec accélération GPU lorsque c’est possible.
Le client CLI (ollama run, ollama pull…) dialogue avec le serveur via cette même API.
Le stockage des modèles se situe par défaut dans ~/.ollama/models sous macOS, /usr/share/ollama/.ollama/models sous Linux et dans le profil utilisateur sous Windows. La variable OLLAMA_MODELS permet de le déplacer vers un volume dédié.

Par défaut, le serveur écoute uniquement sur 127.0.0.1:11434. Un modèle reste chargé en mémoire 5 minutes après la dernière requête (paramètre OLLAMA_KEEP_ALIVE), et la fenêtre de contexte par défaut est de 4 096 tokens, ajustable via OLLAMA_CONTEXT_LENGTH ou le paramètre num_ctx. Côté concurrence, OLLAMA_NUM_PARALLEL fixe le nombre de requêtes traitées simultanément par modèle (1 par défaut) et OLLAMA_MAX_LOADED_MODELS le nombre de modèles chargés en parallèle ; les requêtes excédentaires sont mises en file d’attente (512 par défaut, via OLLAMA_MAX_QUEUE).

Installation

Ollama est disponible pour Linux, macOS et Windows, ainsi que sous forme d’image officielle ollama/ollama pour Docker. Sous Linux et macOS, un script d’installation officiel configure le binaire et, sous Linux, un service systemd dédié exécuté par l’utilisateur ollama. Sous Windows, un installeur PowerShell (ou OllamaSetup.exe) est proposé. Comme pour tout script téléchargé puis exécuté, prenez le temps de le relire avant de le lancer sur un serveur de production.

En conteneur, le volume ollama conserve les modèles téléchargés entre deux redémarrages. Pour une carte NVIDIA, l’option --gpus=all nécessite le NVIDIA Container Toolkit sur l’hôte ; pour AMD, une image ollama/ollama:rocm est fournie.

# Linux / macOS : script d'installation officiel
curl -fsSL https://ollama.com/install.sh | sh

# Windows (PowerShell)
irm https://ollama.com/install.ps1 | iex

# Docker - CPU uniquement
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

# Docker - GPU NVIDIA (NVIDIA Container Toolkit requis)
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

# Docker - GPU AMD (ROCm)
docker run -d --device /dev/kfd --device /dev/dri -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama:rocm

# Lancer un modèle dans le conteneur
docker exec -it ollama ollama run llama3.2

Prise en main : modèles, CLI et Modelfile

L’usage quotidien d’Ollama tient en quelques commandes : ollama pull télécharge un modèle, ollama run ouvre une session interactive (en téléchargeant le modèle si nécessaire), ollama ls liste les modèles présents, ollama ps affiche ceux chargés en mémoire, ollama stop en décharge un et ollama rm le supprime du disque.

Le choix du modèle dépend directement de vos ressources : un petit modèle quantifié tourne correctement sur un portable récent, alors qu’un modèle de plusieurs dizaines de milliards de paramètres exige un GPU doté de beaucoup de VRAM. La commande ollama ps indique notamment si le modèle est chargé sur le GPU, sur le CPU ou réparti entre les deux, ce qui explique souvent des écarts de performance importants.

Pour standardiser un usage interne, Ollama propose le Modelfile, un fichier de description inspiré du Dockerfile. L’instruction FROM (obligatoire) désigne le modèle de base, PARAMETER règle des paramètres comme temperature ou num_ctx, SYSTEM définit le message système, et TEMPLATE, MESSAGE ou LICENSE complètent la définition. La commande ollama create produit alors un modèle personnalisé, par exemple un assistant d’analyse de journaux pour votre SOC, réutilisable par toute l’équipe.

Enfin, le serveur expose deux API : l’API native (/api/chat, /api/generate, /api/embed…) et une couche compatible OpenAI sous /v1 (/v1/chat/completions, /v1/completions, /v1/models, /v1/embeddings…). Pour cette dernière, les SDK clients exigent une clé d’API, mais la documentation précise qu’Ollama l’ignore en local : il suffit de pointer base_url vers http://localhost:11434/v1/ pour réutiliser une application existante.

Pour exposer le service à d’autres machines sous Linux, la méthode documentée consiste à surcharger l’unité systemd (systemctl edit ollama.service) en ajoutant Environment="OLLAMA_HOST=0.0.0.0:11434" dans la section [Service], puis à recharger la configuration. Si vous souhaitez revoir la gestion des unités et des journaux, notre cours sur la gestion des services, journaux et tâches planifiées sous Linux détaille ces mécanismes.

# Gestion des modèles
ollama pull llama3.2
ollama run llama3.2
ollama ls
ollama ps
ollama stop llama3.2
ollama rm llama3.2

# Modelfile : assistant interne personnalisé
FROM llama3.2
PARAMETER temperature 0.2
PARAMETER num_ctx 8192
SYSTEM Tu es un assistant SOC. Tu analyses des journaux et réponds en français de façon factuelle.

# Création et utilisation du modèle personnalisé
ollama create assistant-soc -f ./Modelfile
ollama run assistant-soc

# API native
curl http://localhost:11434/api/chat -d '{"model": "llama3.2", "messages": [{"role": "user", "content": "Résume ce journal"}], "stream": false}'

# API compatible OpenAI
curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -d '{"model": "llama3.2", "messages": [{"role": "user", "content": "Bonjour"}]}'

# Exposer le service sur le réseau (Linux / systemd)
sudo systemctl edit ollama.service
#   [Service]
#   Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl daemon-reload
sudo systemctl restart ollama

Ollama face aux alternatives

LM Studio : application de bureau centrée sur l’interface graphique, idéale pour explorer et comparer des modèles sur un poste individuel. Ollama est plus adapté à un déploiement sur serveur, en service ou en conteneur, et à l’automatisation.
llama.cpp : la brique sur laquelle s’appuie Ollama. L’utiliser directement offre un contrôle plus fin (compilation, options d’inférence, serveur intégré), au prix d’une gestion manuelle des modèles et de la configuration.
vLLM : moteur de service orienté débit sur GPU, pensé pour servir de nombreux utilisateurs simultanés en production. Plus exigeant à déployer, il prend le relais quand Ollama atteint ses limites de montée en charge.
LocalAI : autre serveur open source qui expose une API compatible OpenAI et prend en charge plusieurs moteurs et types de modèles (texte, image, audio).

En pratique, Ollama se distingue par sa simplicité : une commande pour installer, une commande pour lancer un modèle, une API immédiatement exploitable par des outils tiers, des notebooks ou des scripts. C’est souvent le meilleur point d’entrée pour une première plateforme d’IA interne.

Bonnes pratiques de sécurité et d’exploitation

Gardez l’écoute locale par défaut. L’API d’Ollama n’intègre pas de mécanisme d’authentification : ne l’exposez jamais directement sur Internet. Si d’autres machines doivent y accéder, placez le service derrière un reverse proxy comme Traefik avec TLS et authentification, et restreignez les flux au pare-feu.
Désactivez le cloud si la confidentialité prime avec OLLAMA_NO_CLOUD=1, afin de garantir que les requêtes restent sur vos machines.
Maîtrisez les origines web : OLLAMA_ORIGINS contrôle les origines autorisées pour les requêtes issues d’un navigateur ; n’ajoutez que celles dont vous avez réellement besoin.
Gérez le proxy sortant correctement : la documentation recommande de définir HTTPS_PROXY (et non HTTP_PROXY) pour les téléchargements de modèles, avec le certificat du proxy installé au niveau système.
Contrôlez l’origine des modèles : privilégiez les modèles officiels de la bibliothèque, vérifiez leur licence (instruction LICENSE du Modelfile) et tenez un inventaire des modèles autorisés.
Dimensionnez la mémoire : la consommation augmente avec OLLAMA_NUM_PARALLEL multiplié par la taille du contexte. Ajustez ces valeurs, ainsi que OLLAMA_KEEP_ALIVE, en fonction de la RAM et de la VRAM disponibles.
Placez les modèles sur un volume dédié via OLLAMA_MODELS, en vous assurant que l’utilisateur ollama y dispose des droits de lecture et d’écriture.
Mettez à jour régulièrement le binaire ou l’image Docker : le projet évolue rapidement et les correctifs concernent aussi la sécurité.

Conclusion

Ollama rend l’IA générative locale accessible à n’importe quelle équipe IT : installation en une commande, gestion des modèles comparable à celle des images de conteneurs, Modelfile pour standardiser les usages et API compatible OpenAI pour brancher les applications existantes. Correctement isolé, mis derrière un reverse proxy authentifié et configuré sans le cloud, il permet d’offrir aux collaborateurs un assistant d’IA sans faire sortir les données sensibles de votre infrastructure. Pour un premier projet, commencez par un petit modèle sur un serveur doté d’un GPU, mesurez les usages réels, puis faites évoluer la plateforme en fonction de la charge.

Partagez cet article !