Ollama enterprise : déployer un LLM open source en production

Déployer un LLM open source en production était encore une tâche complexe il y a deux ans. Il fallait gérer soi-même le chargement des poids, l’optimisation des batchs d’inférence, la gestion de la mémoire GPU, l’exposition d’une API et la compatibilité avec les frameworks d’agents. Les équipes qui essayaient se heurtaient à des problèmes de configuration avant même d’avoir écrit la première ligne de leur agent.

Ollama a résolu ce problème. Depuis sa version enterprise sortie en 2025, il est devenu le runtime de référence pour déployer des LLM open source en production dans les entreprises. Une commande pour télécharger un modèle, une commande pour démarrer le serveur, et l’API compatible OpenAI est prête à recevoir les requêtes de vos agents. En 2026, c’est le standard que VirtuoseWeb utilise sur toutes ses Voies 2 et 3.

Cet article explique concrètement comment déployer Ollama en production : architecture, configuration Docker et Kubernetes, sécurisation, monitoring et intégration avec les principaux modèles open source.

Pourquoi Ollama s’est imposé

Le succès d’Ollama repose sur trois facteurs simples.

La simplicité d’utilisation. Obtenir un modèle en production prend literalement deux commandes : ollama pull gemma4:31b pour télécharger le modèle et ollama serve pour démarrer le serveur. L’API est immédiatement disponible sur le port 11434. Cette friction minimale a permis à des équipes sans expertise MLOps profonde d’opérer des LLM en production.

La compatibilité OpenAI. L’API d’Ollama est compatible avec le format de l’API OpenAI pour les endpoints /api/chat et /api/generate. N’importe quel client, framework ou outil qui supporte OpenAI fonctionne avec Ollama sans modification de code. LangChain, LlamaIndex, les clients MCP, les frameworks d’agents custom — tous se connectent à Ollama comme s’ils parlaient à GPT-4. Cette compatibilité a éliminé la principale friction d’adoption.

Le catalogue de modèles. Ollama maintient un registre de modèles préconfigurés avec les bons paramètres de quantification et de contexte. Gemma 4 4B, 26B et 31B Dense, Mistral Small 4 et Large 2, Llama 4 Scout, Qwen 2.5, DeepSeek R2 : les principaux modèles open source sont disponibles via ollama pull sans avoir à chercher les fichiers GGUF, à configurer les paramètres de tokenisation ou à gérer les dépendances. Le catalogue est mis à jour en continu par l’équipe Ollama et la communauté.

Architecture de déploiement production

Un déploiement Ollama de production est différent d’une installation de développement local. Voici les composantes d’une architecture solide.

Couche d’inférence

Le cœur : un ou plusieurs processus Ollama qui gèrent les requêtes d’inférence sur GPU. Chaque instance Ollama gère un modèle chargé en VRAM. Si vous avez plusieurs modèles à servir simultanément, vous avez plusieurs instances Ollama.

Pour un déploiement standard chez VirtuoseWeb en Voie 3 :

┌─────────────────────────────────────────────────┐
│              Reverse Proxy (Nginx/Caddy)         │
│           TLS termination + Auth (JWT/mTLS)       │
└───────────────────┬─────────────────────────────┘
                    │ Internal network only
        ┌───────────┴──────────┐
        │                      │
┌───────┴───────┐    ┌─────────┴──────┐
│  Ollama #1    │    │   Ollama #2    │
│  Gemma 4 31B  │    │  Mistral L2    │
│  GPU: H100    │    │  GPU: 2×A100   │
└───────────────┘    └────────────────┘

Couche de proxy et d’authentification

Ollama n’implémente pas nativement l’authentification. En production, vous ne l’exposez jamais directement. Un reverse proxy Nginx ou Caddy s’intercale pour :

• Terminer TLS (HTTPS)
• Vérifier les tokens JWT ou les certificats mTLS
• Logger toutes les requêtes
• Limiter le débit par client (rate limiting)
• Acheminer vers le bon processus Ollama selon le modèle demandé

Configuration Nginx minimale pour un déploiement interne :

server {
    listen 443 ssl;
    ssl_certificate /etc/ssl/certs/ollama.crt;
    ssl_certificate_key /etc/ssl/private/ollama.key;

    # Auth via header Bearer JWT
    auth_jwt "Ollama Enterprise" token=$http_authorization;
    auth_jwt_key_file /etc/nginx/jwt_secret.jwk;

    location /api/ {
        proxy_pass http://127.0.0.1:11434;
        proxy_read_timeout 600s;
        proxy_buffering off;
    }
}

Couche de monitoring

Sans observabilité, vous opérez à l’aveugle. Trois métriques sont essentielles en production :

Latence d’inférence (tokens par seconde) : alerter si elle chute en dessous de 20 tokens/s, symptôme de saturation VRAM ou de swap GPU.

File d’attente des requêtes : Ollama gère une file de requêtes en série par défaut. Si la file dépasse cinq requêtes en attente, c’est le signal qu’il faut ajouter une instance.

Utilisation VRAM : alerter si l’utilisation dépasse 90 %, risque de crash par OOM.

Prometheus avec Grafana est la stack standard. Ollama expose des métriques Prometheus nativement depuis la version 0.5.

Déploiement Docker en production

Docker est la méthode recommandée pour les déploiements on-prem et cloud souverain. Il isole le processus, simplifie les mises à jour et facilite la gestion des dépendances CUDA.

# docker-compose.yml pour Ollama + Gemma 4 31B
version: '3.8'

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama-gemma4
    restart: unless-stopped
    ports:
      - "127.0.0.1:11434:11434"  # Lier uniquement localhost
    volumes:
      - ollama_models:/root/.ollama
    environment:
      - OLLAMA_NUM_PARALLEL=2
      - OLLAMA_MAX_LOADED_MODELS=1
      - OLLAMA_FLASH_ATTENTION=1
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

  model-init:
    image: ollama/ollama:latest
    depends_on:
      - ollama
    command: >
      sh -c "sleep 5 && ollama pull gemma4:31b"
    environment:
      - OLLAMA_HOST=http://ollama:11434

volumes:
  ollama_models:
    driver: local

Variables d’environnement importantes :

Variable	Valeur recommandée	Effet
OLLAMA_NUM_PARALLEL	2-4 selon VRAM disponible	Nombre de requêtes traitées en parallèle
OLLAMA_MAX_LOADED_MODELS	1-2	Modèles chargés simultanément en VRAM
OLLAMA_FLASH_ATTENTION	1	Active Flash Attention 2 (40 % d’économie VRAM)
OLLAMA_KEEP_ALIVE	10m	Durée de rétention du modèle en mémoire
OLLAMA_CONTEXT_LENGTH	8192 ou 32768	Fenêtre de contexte (ajuster selon besoins)

Déploiement Kubernetes

Pour les infrastructures cloud souveraines (Scaleway, OVHcloud) avec Kubernetes, le déploiement est légèrement différent. Le modèle est préchargé dans un PersistentVolume pour éviter de le re-télécharger à chaque restart.

# deployment Kubernetes simplifié
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama-gemma4
  namespace: ai-inference
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ollama-gemma4
  template:
    spec:
      containers:
      - name: ollama
        image: ollama/ollama:latest
        ports:
        - containerPort: 11434
        env:
        - name: OLLAMA_NUM_PARALLEL
          value: "2"
        - name: OLLAMA_FLASH_ATTENTION
          value: "1"
        resources:
          limits:
            nvidia.com/gpu: "1"
        volumeMounts:
        - name: models-storage
          mountPath: /root/.ollama
      volumes:
      - name: models-storage
        persistentVolumeClaim:
          claimName: ollama-models-pvc
      nodeSelector:
        accelerator: nvidia-h100  # Cibler les nœuds GPU

Sur Scaleway Kapsule (leur offre Kubernetes managée), les GPU H100 sont disponibles en tant que node pools avec le plugin device plugin NVIDIA préinstallé. Le déploiement est similaire à ce qui précède.

Modèles supportés et commandes de déploiement

Voici les commandes Ollama pour les principaux modèles utilisés dans les projets VirtuoseWeb :

# Gemma 4 — variantes disponibles
ollama pull gemma4:4b        # Edge, laptop, embarqué
ollama pull gemma4:26b       # Intermédiaire, 2× A100 40 Go
ollama pull gemma4:31b       # Référence enterprise, 1× H100 80 Go

# Mistral
ollama pull mistral-small4   # MoE efficient, 4B actifs / 128 experts total
ollama pull mistral-large:2  # Dense 56B, 2× H100 recommandé

# Llama 4
ollama pull llama4:scout     # Context 10M tokens

# Quantifications Q4 (pour réduire VRAM)
ollama pull gemma4:31b-instruct-q4_K_M  # ~20 Go VRAM, RTX 4090 compatible

Pour lister les modèles disponibles localement et surveiller l’état :

ollama list              # Modèles téléchargés
ollama ps               # Modèles actuellement chargés en VRAM
ollama show gemma4:31b  # Informations détaillées sur un modèle

Intégration avec les frameworks d’agents et MCP

L’API compatible OpenAI d’Ollama est sa principale force d’intégration. Dans le contexte des architectures MCP que nous utilisons chez VirtuoseWeb, les clients MCP se connectent à Ollama en configurant simplement le base URL.

Exemple avec le SDK Python d’Anthropic (en mode compatibilité) :

from openai import OpenAI

# Connexion à Ollama local
client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # Pas de vraie clé, mais champ requis
)

response = client.chat.completions.create(
    model="gemma4:31b",
    messages=[{"role": "user", "content": "Analyse ce bon de commande..."}],
    tools=[...],  # Tool definitions standard OpenAI
    tool_choice="auto"
)

Les frameworks LangChain, LlamaIndex et la plupart des clients MCP supportent nativement la configuration d’un base_url personnalisé. La migration de Claude Managed Agents (Voie 1) vers un déploiement Ollama (Voie 2/3) ne nécessite que de changer cette URL — le code de l’agent reste identique si les tool definitions sont écrites en format standard.

Limites à connaître avant de déployer

Ollama est excellent mais n’est pas parfait. Voici les limites à anticiper.

Les requêtes sont sérielles par défaut. Ollama traite les requêtes l’une après l’autre par modèle chargé. Si cinq agents font des appels simultanés, quatre attendent que le premier soit servi. OLLAMA_NUM_PARALLEL=4 parallélise les inférences mais augmente l’utilisation VRAM proportionnellement. Au-delà de trois agents en parallèle constants, la Voie 2 (Scaleway Managed Inference avec GPU dédiés par agent) offre une meilleure économie.

Le premier chargement est lent. Charger Gemma 4 31B depuis un disque NVMe prend 30 à 90 secondes selon la vitesse du stockage. Après le premier chargement, le modèle reste en VRAM tant que OLLAMA_KEEP_ALIVE n’a pas expiré. Configurez ce paramètre à 24h pour des agents qui tournent en continu.

Pas de haute disponibilité native. Ollama ne gère pas le failover ni le load balancing multi-nœuds nativement. Pour un usage production critique, vous devez ajouter une couche d’orchestration (Kubernetes avec health checks, ou un load balancer applicatif). Sur Scaleway, le Managed Inference gère cette complexité pour vous — c’est l’un des avantages de la Voie 2 par rapport à la Voie 3.

Le monitoring est externe. Ollama expose des métriques Prometheus mais ne fournit pas de dashboard d’observabilité intégré. Prévoyez Grafana ou une alternative pour visualiser l’utilisation GPU, la latence et la file d’attente.

Checklist de déploiement Ollama en production

Étape	Vérification
GPU configuré	Drivers NVIDIA installés, CUDA 12.x, test nvidia-smi
Modèle téléchargé	ollama pull gemma4:31b réussi, modèle listé dans ollama list
Service démarré	ollama serve actif, healthcheck curl http://localhost:11434/api/tags
Reverse proxy actif	TLS terminé, auth configurée, logs activés
Variables env.	OLLAMA_NUM_PARALLEL, OLLAMA_KEEP_ALIVE, OLLAMA_FLASH_ATTENTION définis
Monitoring	Prometheus scraping, alertes latence et VRAM configurées
Test de charge	Simulation de N agents simultanés, vérification des temps de réponse
Backup modèles	Volume persistent créé, stratégie de restauration documentée

Conclusion : Ollama est la fondation de toute Voie 2 ou Voie 3

Ollama n’est pas une alternative à gérer soi-même ses LLM. C’est la couche qui rend cette gestion faisable pour des équipes sans expertise MLOps dédiée. Son API compatible OpenAI, son catalogue de modèles et sa simplicité de configuration ont éliminé la barrière technique qui empêchait les entreprises de déployer des agents IA souverains.

En 2026, tous nos projets Voie 2 et Voie 3 chez VirtuoseWeb utilisent Ollama comme runtime d’inférence. Il est le socle sur lequel nous posons Gemma 4 31B Dense, Mistral Large 2 ou Llama 4 Scout selon les besoins du projet. Sa stabilité en production, validée sur des centaines de déploiements dans la communauté, en fait un choix de confiance pour les entreprises qui veulent garder leurs données sur leur sol.

Si vous envisagez de déployer votre premier agent souverain sur Ollama, notre comparatif des modèles open source vous aidera à choisir le bon modèle pour votre cas d’usage. Et si la question du cloud souverain ou de l’on-prem est centrale pour vous, notre guide sur les voies de déploiement détaille les critères de décision entre Voie 2 et Voie 3.