Ollama : exécuter des LLM en local pour son infrastructure open source

Ollama est un outil open source qui permet d’exécuter des grands modèles de langage (LLM) directement sur sa propre machine ou son serveur, sans dépendre d’API tierces comme OpenAI ou Anthropic. Il expose une API HTTP compatible avec le format OpenAI, ce qui facilite son intégration dans une architecture existante — que ce soit un pipeline RAG, un serveur MCP, ou une interface de chat.

Pour les infrastructures auto-hébergées, Ollama représente une brique clé : confidentialité des données, absence de coût par requête, fonctionnement hors ligne. Cet article présente son installation, son fonctionnement, et les cas d’usage concrets dans une stack open source.

Pourquoi exécuter un LLM en local ?

Les raisons sont multiples selon le contexte. La souveraineté des données est souvent la première motivation : dans les organisations publiques ou les projets sensibles, envoyer des données à un service cloud tiers pose des questions réglementaires (RGPD, confidentialité, hébergement en dehors de l’UE). L’exécution locale élimine ce risque.

La maîtrise des coûts est un autre argument. Les API commerciales facturent à la requête ou au token. Pour un usage intensif — traitement de corpus documentaires, annotation automatique, extraction d’entités — les coûts peuvent rapidement devenir significatifs. Un LLM local tourne à coût marginal nul une fois le matériel amorti.

Enfin, l’intégration dans une infrastructure auto-hébergée est plus naturelle. Ollama s’installe comme un service système, expose une API REST, et s’intègre directement avec des outils comme LangChain, Open WebUI, ou un serveur MCP custom.

Installation d’Ollama sur Linux

L’installation est volontairement simple. Le script officiel gère les dépendances et installe Ollama comme service systemd :

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

Après l’installation, le service tourne sur http://localhost:11434. On télécharge un modèle avec une commande simple :

ollama pull llama3.2
ollama pull mistral
ollama pull nomic-embed-text

nomic-embed-text est un modèle d’embeddings, utile pour les pipelines RAG. llama3.2 et mistral sont des modèles généralistes francophones performants sur du matériel grand public (8 à 16 Go de RAM suffisent pour les versions 7B quantisées).

L’API REST compatible OpenAI

Ollama expose deux types d’endpoints. L’endpoint natif /api/generate est simple et direct :

curl http://localhost:11434/api/generate \
  -d '{"model":"llama3.2","prompt":"Qu'est-ce que CKAN ?","stream":false}'

L’endpoint compatible OpenAI (/v1/chat/completions) permet de substituer Ollama à la place d’OpenAI dans n’importe quelle application qui utilise le SDK officiel Python ou TypeScript. Il suffit de changer la base URL :

from openai import OpenAI

client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
response = client.chat.completions.create(
    model="llama3.2",
    messages=[{"role": "user", "content": "Résume ce document : ..."}]
)

Déploiement avec Docker

Pour une infrastructure conteneurisée, Ollama fournit une image Docker officielle. Voici un docker-compose.yml minimal pour un déploiement CPU (sans GPU) :

services:
  ollama:
    image: ollama/ollama:latest
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    restart: unless-stopped

volumes:
  ollama_data:

Pour exposer Ollama derrière un reverse proxy Nginx avec authentification, on ajoute une directive proxy_pass vers le port 11434 et un bloc auth_basic pour protéger l’accès. En production, il est fortement déconseillé d’exposer l’API Ollama directement sur internet sans protection.

Intégration dans un pipeline RAG

L’un des cas d’usage les plus courants est la construction d’un pipeline RAG (Retrieval-Augmented Generation) entièrement local. Le schéma est le suivant : les documents sont indexés sous forme de vecteurs d’embeddings (générés par nomic-embed-text via Ollama), stockés dans une base vectorielle comme Qdrant ou ChromaDB, puis interrogés au moment de chaque requête utilisateur avant d’envoyer le contexte enrichi au LLM.

Avec LangChain ou LlamaIndex, l’intégration d’Ollama est directe — les deux bibliothèques supportent nativement Ollama comme provider LLM et comme provider d’embeddings. On peut ainsi construire un assistant documentaire entièrement souverain, capable d’indexer des jeux de données CKAN, des PDF d’appels d’offres, ou des corpus réglementaires.

Intégration avec un serveur MCP

Le Model Context Protocol (MCP) permet à un LLM d’appeler des outils externes lors de ses inférences. Ollama peut être utilisé comme backend LLM dans des configurations MCP via des frameworks comme mcp-agent ou des implémentations custom. Le pattern typique : un serveur MCP expose des outils (requête SQL, appel API, lecture de fichier), et Ollama reçoit les résultats de ces outils pour construire sa réponse finale.

Cette architecture permet de construire des agents autonomes qui tournent entièrement en local, sans envoyer de données à un cloud tiers — un avantage majeur pour les cas d’usage à données sensibles.

Interface web avec Open WebUI

Open WebUI est une interface de chat open source conçue pour fonctionner avec Ollama. Elle propose une expérience proche de ChatGPT — gestion de conversations, sélection de modèles, upload de documents — mais entièrement auto-hébergée. Le déploiement se fait via Docker :

docker run -d \
  -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  ghcr.io/open-webui/open-webui:main

Open WebUI supporte également la connexion à des API OpenAI tierces, ce qui permet de basculer entre un modèle local et un modèle cloud selon les besoins, depuis la même interface.

Choix du modèle selon les ressources matérielles

Le choix du modèle dépend directement du matériel disponible. Sur un serveur standard avec 8 Go de RAM et sans GPU dédié, les modèles 7B quantisés (format GGUF Q4) fonctionnent de manière fluide. Sur 16 Go de RAM, on accède aux modèles 13B. Pour des inférences rapides et des cas d’usage en production, un GPU NVIDIA avec support CUDA accélère considérablement les temps de réponse — Ollama détecte et utilise automatiquement le GPU si disponible.

La bibliothèque de modèles disponibles sur ollama.com/library couvre un large spectre : modèles généralistes (Llama, Mistral, Gemma), modèles de code (Codestral, DeepSeek Coder), modèles d’embeddings, et modèles multimodaux capables d’analyser des images.

Points de vigilance en production

Plusieurs aspects méritent attention avant un déploiement en production. La sécurité de l’API est la première priorité : Ollama n’implémente pas d’authentification native, il faut donc le placer derrière un reverse proxy avec contrôle d’accès. La gestion des modèles stockés sur disque (plusieurs Go par modèle) nécessite une stratégie de volume claire. Enfin, les temps d’inférence sur CPU restent significativement plus lents qu’avec un GPU : à évaluer selon les contraintes de latence de l’application.

Pour les environnements Kubernetes, Ollama peut être déployé comme un Deployment avec un PersistentVolumeClaim pour le stockage des modèles, et exposé comme un Service interne accessible aux autres pods de la stack.