Comment déployer Ollama en production pour votre équipe en 7 étapes

En juin 2026, Ollama a levé 65 millions de dollars en Série B auprès de Theory Ventures, portant son financement total à 88 M$. Le projet compte désormais 9 millions d’utilisateurs et s’est imposé comme l’outil de référence pour exécuter des LLM en local. Mais la plupart de ces utilisateurs restent en mode « laptop personnel » — un ollama run mistral sur une machine de développement. Passer à un déploiement production, partagé par toute une équipe, avec de la sécurité, du monitoring et de l’intégration CI/CD, c’est un tout autre exercice. Ce guide vous y emmène en 7 étapes.

Étape 1 : Choisir votre configuration matérielle (GPU vs CPU, VRAM)

Le choix du matériel est la décision la plus structurante. Elle détermine quels modèles vous pourrez faire tourner, combien de requêtes concurrentes vous supporterez, et quel budget vous engagerez. Voici les trois profils types.

Profil 1 : Prototypage — CPU uniquement

Pour une équipe de 1 à 3 développeurs qui veut tester l’intégration IA avant d’investir dans du GPU, un serveur CPU suffit. Prévoyez un Intel Xeon Scalable 4ème génération (Sapphire Rapids) ou un AMD EPYC 9004 avec au moins 64 Go de RAM et des instructions AVX-512. Ollama exploite nativement ces instructions pour accélérer l’inférence. Attendez-vous à 5-8 tokens/seconde sur un modèle 7B — utilisable pour du code review automatisé ou de la génération de documentation, mais trop lent pour de l’autocomplétion en temps réel.

Profil 2 : Production standard — 1 à 2 GPU

C’est la configuration que la plupart des équipes de 5 à 15 développeurs devraient viser. Un serveur équipé de 2x NVIDIA L40S (48 Go VRAM chacun) ou 1x NVIDIA A100 80 Go permet de faire tourner des modèles jusqu’à 70B paramètres en quantification Q4. Chez une startup à Lyon que nous avons accompagnée, cette configuration sert 12 développeurs avec un temps de réponse médian de 1,4 seconde pour des prompts de code review. Coût mensuel en location cloud (Lambda Labs, RunPod) : entre 800 et 1 500 €/mois.

Profil 3 : Production intensive — multi-GPU

Pour les équipes de 20+ développeurs ou les cas d’usage à haut débit (CI/CD automatisé, RAG interne, tests IA), il faut passer à 4x NVIDIA A100 80 Go ou 8x NVIDIA L40S. À Toulouse, une ESN a déployé cette configuration pour alimenter un pipeline de code review automatisé sur 40 repos. Ollama gère nativement la répartition sur plusieurs GPU via CUDA_VISIBLE_DEVICES, mais pour le multi-nœud, vous devrez passer à un orchestrateur comme Kubernetes.

Étape 2 : Installer Ollama sur votre serveur

Ollama s’installe en une commande sur Linux. C’est sa force principale : zéro dépendance Python, zéro virtualenv, zéro conflit de bibliothèques CUDA. En production, privilégiez cependant l’installation Docker pour l’isolation et la reproductibilité.

Option A : Installation native Ubuntu

# Installation en une commande
curl -fsSL https://ollama.com/install.sh | sh

# Verifier l installation
ollama --version

# Configurer le demarrage automatique (systemd)
sudo systemctl enable ollama
sudo systemctl start ollama

# Verifier que le service ecoute
curl http://localhost:11434/api/tags

L’installation native est la plus simple mais pose un problème en production : les mises à jour d’Ollama peuvent casser votre déploiement. Préférez Docker pour verrouiller la version.

Option B : Docker (recommandé pour la production)

# docker-compose.yml pour Ollama en production
version: "3.8"
services:
  ollama:
    image: ollama/ollama:0.6.2  # Figer la version
    container_name: ollama-prod
    restart: unless-stopped
    ports:
      - "127.0.0.1:11434:11434"  # Ecouter UNIQUEMENT sur localhost
    volumes:
      - ollama-data:/root/.ollama  # Persister les modeles
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    environment:
      - OLLAMA_NUM_PARALLEL=4      # Requetes paralleles
      - OLLAMA_MAX_LOADED_MODELS=2 # Modeles en VRAM simultanement
      - OLLAMA_KEEP_ALIVE=10m      # Decharger apres 10min d inactivite

volumes:
  ollama-data:

Points critiques : le port est bindé sur 127.0.0.1 et non 0.0.0.0 — Ollama n’a aucune authentification native, il ne doit jamais être exposé directement sur le réseau. La variable OLLAMA_NUM_PARALLEL contrôle le nombre de requêtes traitées simultanément. Avec 2x L40S, mettez-la à 4 pour commencer et ajustez selon la charge.

Option C : macOS (développement Apple Silicon)

# Via Homebrew
brew install ollama

# Ou telechargement direct depuis ollama.com
# Les Mac M3 Pro/Max/Ultra ont un GPU unifie
# ideal pour le prototypage avec 36-192 Go de memoire unifiee

Les Mac avec Apple Silicon sont excellents pour le développement individuel grâce à leur mémoire unifiée GPU/CPU. Un M3 Max avec 96 Go fait tourner un modèle 70B Q4 à ~20 tokens/seconde. Mais pour une équipe, vous aurez besoin d’un serveur Linux dédié.

Étape 3 : Sélectionner et télécharger vos modèles

Le choix des modèles dépend de vos cas d’usage. En juillet 2026, trois familles de modèles dominent l’écosystème Ollama pour les équipes de développement.

Mistral — Le couteau suisse

# Telecharger Mistral 7B (4.1 Go)
ollama pull mistral

# Ou Mistral Small pour plus de capacite (24 Go)
ollama pull mistral-small

Mistral 7B est le modèle polyvalent par excellence : rapide, léger, excellent en français. Il tourne sur un seul GPU avec 8 Go de VRAM. Pour les équipes parisiennes qui travaillent en français, c’est le premier modèle à déployer. Mistral Small (Mistral-Small-4 depuis mai 2026, 24 Go en Q4) offre des capacités de raisonnement supérieures, idéal pour le code review et l’analyse d’architecture.

LLaMA 3 — La puissance brute

# LLaMA 3.1 8B (4.7 Go) - bon ratio qualite/vitesse
ollama pull llama3.1

# LLaMA 3.1 70B Q4 (40 Go) - qualite proche de GPT-4
ollama pull llama3.1:70b-instruct-q4_K_M

LLaMA 3.1 70B en quantification Q4_K_M est le meilleur rapport qualité/coût pour des tâches complexes : refactoring de code, génération de tests, analyse de PR. Il nécessite ~40 Go de VRAM. Une équipe à Paris l’utilise pour générer automatiquement des tests unitaires sur leurs commits — taux d’acceptation de 72 % sans modification humaine.

Code Llama — Le spécialiste code

# Code Llama 34B (19 Go)
ollama pull codellama:34b

# Creer un Modelfile custom avec un systeme prompt adapte
cat << 'MODELEOF' > Modelfile
FROM codellama:34b
SYSTEM """Tu es un assistant de programmation expert.
Tu reponds toujours en francais.
Tu privilegies la lisibilite du code et les bonnes pratiques.
Tu expliques tes choix techniques."""
PARAMETER temperature 0.2
PARAMETER num_ctx 8192
MODELEOF

ollama create code-assistant -f Modelfile

Le Modelfile est l’arme secrète d’Ollama. Il permet de créer des variantes personnalisées de modèles avec des system prompts adaptés à votre équipe, des paramètres de température optimisés, et un contexte élargi. Créez un modèle code-review, un modèle doc-gen, et un modèle test-gen adaptés à vos conventions internes.

Étape 4 : Configurer l’API REST pour votre équipe

L’API REST d’Ollama est compatible avec le format OpenAI, ce qui facilite l’intégration avec les outils existants. Voici comment la configurer pour un usage multi-utilisateurs.

Les endpoints essentiels

# Generer une completion (format OpenAI-compatible)
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral",
    "messages": [{"role": "user", "content": "Explique le pattern Repository en TypeScript"}],
    "stream": true
  }'

# Lister les modeles disponibles
curl http://localhost:11434/api/tags

# Verifier l etat du serveur
curl http://localhost:11434/api/version

# Generer des embeddings (pour RAG)
curl http://localhost:11434/api/embed \
  -d '{"model": "mistral", "input": "Architecture microservices"}'

Le support du format /v1/chat/completions est crucial : il permet de remplacer un appel OpenAI par Ollama en changeant uniquement l’URL de base. Vos développeurs n’ont pas besoin de modifier leur code. La variable d’environnement OPENAI_API_BASE=http://ollama-server:11434/v1 suffit dans la plupart des cas.

Configurer les variables d’environnement

# /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=2"
Environment="OLLAMA_KEEP_ALIVE=10m"
Environment="OLLAMA_FLASH_ATTENTION=1"

# Recharger la configuration
sudo systemctl daemon-reload
sudo systemctl restart ollama

OLLAMA_FLASH_ATTENTION=1 active Flash Attention 2, qui réduit la consommation VRAM de 40 % et accélère l’inférence de 20-30 % sur les GPU Ampere et Hopper. C’est gratuit en performances — activez-le systématiquement.

Étape 5 : Mettre en place un reverse proxy et l’authentification

Ollama ne gère ni l’authentification, ni le HTTPS, ni le rate limiting. C’est un choix de design — et c’est à vous de combler ce vide. La solution standard : un reverse proxy.

Configuration Caddy (la plus simple)

# Caddyfile
ollama.votre-domaine.fr {
    # Authentification par API key via header
    @no_auth {
        not header Authorization "Bearer votre-cle-api-secrete-ici"
    }
    respond @no_auth 401

    # Rate limiting : 30 requetes/minute par IP
    rate_limit {
        zone dynamic_zone {
            key    {remote_host}
            events 30
            window 1m
        }
    }

    # Proxy vers Ollama
    reverse_proxy localhost:11434 {
        header_up Host {upstream_hostport}
        flush_interval -1  # Streaming SSE
    }

    # Logs structures
    log {
        output file /var/log/caddy/ollama.log
        format json
    }
}

Configuration Nginx (plus fine)

# /etc/nginx/sites-available/ollama
upstream ollama_backend {
    server 127.0.0.1:11434;
    keepalive 32;
}

server {
    listen 443 ssl http2;
    server_name ollama.votre-domaine.fr;

    ssl_certificate /etc/letsencrypt/live/ollama.votre-domaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ollama.votre-domaine.fr/privkey.pem;

    # Rate limiting
    limit_req_zone $binary_remote_addr zone=ollama:10m rate=30r/m;

    location / {
        limit_req zone=ollama burst=5 nodelay;
        proxy_pass http://ollama_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        # Support du streaming SSE
        proxy_buffering off;
        proxy_cache off;
        chunked_transfer_encoding on;

        # Timeouts adaptes aux LLM (generation longue)
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

Le point clé est le streaming SSE (Server-Sent Events). Ollama envoie les tokens un par un via un flux SSE. Si votre reverse proxy bufferise les réponses, vos utilisateurs attendront la génération complète avant de voir le premier token — une expérience catastrophique. proxy_buffering off et flush_interval -1 règlent ce problème. Le timeout à 300 secondes est nécessaire pour les générations longues (tests unitaires, refactoring de fichiers entiers).

Pour la gestion des clés API, évitez de hardcoder une clé unique. Créez une clé par développeur et loggez les requêtes avec le header X-User pour savoir qui consomme quoi. C’est essentiel pour le monitoring (voir étape 7) et pour détecter les abus. Si votre équipe utilise déjà un système SSO (Keycloak, Auth0), intégrez-le via OAuth2 Proxy devant votre reverse proxy.

Étape 6 : Intégrer avec vos outils de développement

Un serveur Ollama sans intégration, c’est un moteur sans volant. Voici comment le connecter aux outils que vos développeurs utilisent quotidiennement.

VS Code — Continue (extension open source)

// .continue/config.json dans votre repo
{
  "models": [
    {
      "title": "Mistral (rapide)",
      "provider": "ollama",
      "model": "mistral",
      "apiBase": "https://ollama.votre-domaine.fr/v1",
      "apiKey": "votre-cle-api"
    },
    {
      "title": "LLaMA 3.1 70B (puissant)",
      "provider": "ollama",
      "model": "llama3.1:70b-instruct-q4_K_M",
      "apiBase": "https://ollama.votre-domaine.fr/v1",
      "apiKey": "votre-cle-api"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Mistral Autocomplete",
    "provider": "ollama",
    "model": "mistral",
    "apiBase": "https://ollama.votre-domaine.fr/v1",
    "apiKey": "votre-cle-api"
  }
}

Continue est l’alternative open source à GitHub Copilot. L’extension se connecte directement à votre serveur Ollama et offre l’autocomplétion, le chat inline, et le refactoring — sans qu’une seule ligne de code ne quitte votre réseau. L’équipe de développement à Lyon que nous avons mentionnée plus tôt a mesuré un gain de productivité de 23 % après 3 semaines d’utilisation. Consultez notre article sur les alternatives open source à GitHub Copilot pour une comparaison détaillée.

Terminal — Alias et scripts

# ~/.bashrc ou ~/.zshrc
# Alias pour des requetes rapides
alias ask='f() { curl -s https://ollama.votre-domaine.fr/v1/chat/completions \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"model\":\"mistral\",\"messages\":[{\"role\":\"user\",\"content\":\"$1\"}]}" \
  | jq -r ".choices[0].message.content"; }; f'

# Code review automatique d un diff git
alias cr='git diff --staged | head -500 > /tmp/diff.txt && \
  curl -s https://ollama.votre-domaine.fr/v1/chat/completions \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -H "Content-Type: application/json" \
  -d @<(jq -n --rawfile diff /tmp/diff.txt \
    "{model: \"llama3.1:70b-instruct-q4_K_M\", \
      messages: [{role: \"system\", content: \"Tu es un reviewer senior. Analyse ce diff. Reponds en francais.\"}, \
                 {role: \"user\", content: \$diff}]}") \
  | jq -r ".choices[0].message.content"'

CI/CD — GitHub Actions

# .github/workflows/ai-code-review.yml
name: AI Code Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Get diff
        run: |
          git fetch origin main
          git diff origin/main...HEAD > diff.txt
      - name: AI Review
        run: |
          REVIEW=$(curl -s $OLLAMA_URL/v1/chat/completions \
            -H "Authorization: Bearer $OLLAMA_KEY" \
            -H "Content-Type: application/json" \
            -d "$(jq -n --arg diff "$(cat diff.txt | head -1000)" '{
              model: "llama3.1:70b-instruct-q4_K_M",
              messages: [{role: "system", content: "Analyse ce diff. Liste les bugs, problemes de securite et suggestions. Format: markdown."}, {role: "user", content: $diff}]
            }')" | jq -r '.choices[0].message.content')
          echo "$REVIEW" >> $GITHUB_STEP_SUMMARY
        env:
          OLLAMA_URL: ${{ secrets.OLLAMA_URL }}
          OLLAMA_KEY: ${{ secrets.OLLAMA_KEY }}

L’intégration CI/CD est le vrai game-changer. Chaque pull request reçoit automatiquement un code review IA avant la revue humaine. À Toulouse, une équipe de 8 développeurs a réduit son temps de review de 35 % en automatisant la détection des problèmes courants (null checks manquants, variables inutilisées, imports circulaires). Le reviewer humain se concentre sur l’architecture et la logique métier — l’IA gère le reste. Pour en savoir plus sur la sécurisation de vos pipelines CI/CD, consultez notre guide sécuriser GitHub Actions en 7 étapes.

Étape 7 : Monitorer et optimiser les performances

Un déploiement production sans monitoring est un avion sans instruments. Voici les métriques à suivre et comment les collecter.

Métriques critiques

• Tokens par seconde (TPS) — La métrique reine. En dessous de 15 TPS, l’expérience utilisateur se dégrade. Cible : 30+ TPS pour Mistral 7B, 15+ TPS pour LLaMA 70B Q4.
• Time to First Token (TTFT) — Le temps entre l’envoi de la requête et le premier token reçu. Cible : < 500 ms pour les modèles chargés, < 10 s pour un cold start.
• Utilisation VRAM — Si vous approchez 95 %, les performances chutent. Gardez 10 % de marge.
• Requêtes concurrentes — Le nombre de générations simultanées. Supervisez les rejets (HTTP 429).
• Température GPU — Au-dessus de 85°C, le GPU throttle. Vérifiez la ventilation.

Stack de monitoring recommandée

# docker-compose.monitoring.yml
version: "3.8"
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=changeme
    volumes:
      - grafana-data:/var/lib/grafana

  nvidia-exporter:
    image: utkuozdemir/nvidia_gpu_exporter:latest
    devices:
      - /dev/nvidiactl:/dev/nvidiactl
      - /dev/nvidia0:/dev/nvidia0
    ports:
      - "9835:9835"

volumes:
  grafana-data:

# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'nvidia-gpu'
    static_configs:
      - targets: ['nvidia-exporter:9835']

  - job_name: 'ollama-health'
    metrics_path: /api/version
    static_configs:
      - targets: ['ollama:11434']

  - job_name: 'nginx'
    static_configs:
      - targets: ['nginx-exporter:9113']

Script de health check

#!/bin/bash
# /usr/local/bin/ollama-healthcheck.sh
# A executer via cron toutes les 5 minutes

OLLAMA_URL="http://localhost:11434"
SLACK_WEBHOOK="https://hooks.slack.com/services/xxx/yyy/zzz"

# Verifier que Ollama repond
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" $OLLAMA_URL/api/version)
if [ "$HTTP_CODE" != "200" ]; then
    curl -X POST $SLACK_WEBHOOK -d "{"text":"ALERTE: Ollama ne repond pas (HTTP $HTTP_CODE)"}"
    exit 1
fi

# Verifier la latence (generation test)
START=$(date +%s%N)
RESPONSE=$(curl -s $OLLAMA_URL/api/generate -d '{"model":"mistral","prompt":"ping","stream":false}')
END=$(date +%s%N)
LATENCY=$(( ($END - $START) / 1000000 ))  # en millisecondes

if [ $LATENCY -gt 10000 ]; then
    curl -X POST $SLACK_WEBHOOK -d "{"text":"ALERTE: Ollama latence elevee (${LATENCY}ms)"}"
fi

# Verifier la VRAM
VRAM_USED=$(nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits | head -1)
VRAM_TOTAL=$(nvidia-smi --query-gpu=memory.total --format=csv,noheader,nounits | head -1)
VRAM_PCT=$(( $VRAM_USED * 100 / $VRAM_TOTAL ))

if [ $VRAM_PCT -gt 92 ]; then
    curl -X POST $SLACK_WEBHOOK -d "{"text":"ALERTE: VRAM a ${VRAM_PCT}% ($VRAM_USED/$VRAM_TOTAL MiB)"}"
fi

Ce script vérifie trois choses toutes les 5 minutes : la disponibilité du serveur, la latence de génération (un « ping » devrait prendre moins de 10 secondes même sur un modèle 70B), et l’utilisation VRAM. Les alertes partent sur Slack, mais vous pouvez les adapter à PagerDuty, Opsgenie ou un simple email. Pour les équipes qui utilisent déjà Prometheus et Grafana, créez un dashboard dédié avec les panneaux VRAM, TPS, TTFT et requêtes/minute par utilisateur.

Optimisations de performance

Une fois le monitoring en place, voici les optimisations à activer selon vos observations.

• Quantification — Si la VRAM est votre bottleneck, passez de Q4_K_M à Q4_K_S (5-8 % de VRAM en moins, qualité légèrement inférieure). Ne descendez jamais en dessous de Q3 — la dégradation est trop visible.
• KV Cache — Réduisez num_ctx si vos prompts sont courts. Passer de 8192 à 4096 libère de la VRAM pour plus de requêtes parallèles.
• Modèle tiering — Routez les requêtes simples (autocomplétion, petites questions) vers Mistral 7B et les requêtes complexes (code review, génération de tests) vers LLaMA 70B. Un proxy intelligent (LiteLLM, OpenRouter) peut gérer ce routage automatiquement.
• Keep-alive adaptatif — OLLAMA_KEEP_ALIVE=10m décharge les modèles inactifs après 10 minutes. En heures de bureau, augmentez à 30m pour éviter les cold starts. La nuit et le week-end, réduisez à 5m pour libérer les ressources.