Ollama en entreprise : guide d'installation et d'utilisation

#Pourquoi Ollama s'impose en entreprise

La démocratisation des modèles de langage (LLM) open source a créé un besoin nouveau : un outil simple pour les faire tourner en local, sans maîtriser les subtilités de PyTorch, CUDA ou des formats de modèles. Ollama remplit exactement ce rôle. Lancé en 2023, il s'est imposé comme le runtime LLM local le plus populaire avec plus de 150 000 étoiles GitHub et des millions de téléchargements mensuels.

Son succès repose sur trois piliers. D'abord, la simplicité : ollama run llama3.1 suffit pour télécharger et lancer un modèle. Ensuite, la compatibilité : son API REST reprend le format OpenAI, ce qui rend la migration quasi transparente. Enfin, la souveraineté : les données ne quittent jamais votre machine — un argument décisif pour les entreprises soumises au RGPD ou qui manipulent des données sensibles.

Mais attention : Ollama en mode développeur sur un laptop et Ollama en production dans une ETI de 500 personnes, ce n'est pas le même projet. Cet article couvre les deux — de l'installation initiale à l'architecture de production sécurisée.

#Installation : Docker vs bare metal

#Installation bare metal (macOS, Linux, Windows)

Ollama s'installe en une ligne sur macOS et Linux :

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

Sur macOS, une application native est également disponible. Sur Windows, un installeur MSI existe depuis fin 2024. Une fois installé, Ollama fonctionne comme un service système qui écoute sur localhost:11434.

Pour un poste développeur ou un PoC rapide, c'est suffisant. Pour un usage en production, le bare metal pose des problèmes de reproductibilité, d'isolation et de mise à jour — d'où l'intérêt de Docker.

#Installation Docker (recommandée en entreprise)

Le déploiement Docker est la méthode que Nehos recommande pour tout usage au-delà du PoC individuel. Voici la configuration de référence :

# docker-compose.yml
services:
  ollama:
    image: ollama/ollama:latest
    ports:
      - "11434:11434"
    volumes:
      - ollama-data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    restart: unless-stopped

volumes:
  ollama-data:

Pré-requis : Docker Engine avec NVIDIA Container Toolkit installé pour le support GPU. Sur un serveur sans GPU NVIDIA, Ollama utilisera le CPU (beaucoup plus lent, mais fonctionnel pour les modèles <7B).

Une fois le conteneur lancé, chargez vos modèles :

docker exec -it ollama ollama pull llama3.1
docker exec -it ollama ollama pull mistral
docker exec -it ollama ollama pull phi3:14b

#Modèles supportés : le catalogue 2026

Ollama supporte tous les modèles au format GGUF (le standard de quantification pour l'inférence CPU/GPU de llama.cpp). Le catalogue officiel inclut plus de 200 modèles, dont les incontournables :

Vous pouvez également importer des modèles custom depuis Hugging Face au format GGUF : ollama create mon-modele -f Modelfile. C'est la méthode utilisée pour déployer des modèles fine-tunés sur vos données métier.

#L'API compatible OpenAI : migration transparente

Depuis la version 0.3, Ollama expose une API REST compatible avec le format OpenAI. Concrètement, si votre application utilise le SDK OpenAI (Python, Node.js, Go), il suffit de modifier deux paramètres pour basculer vers Ollama :

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # requis syntaxiquement, non vérifié
)

response = client.chat.completions.create(
    model="llama3.1",
    messages=[{"role": "user", "content": "Résume ce contrat en 5 points."}]
)

Cette compatibilité est stratégique : elle permet de prototyper sur API OpenAI puis de migrer vers Ollama en local sans réécrire le code applicatif. C'est exactement l'approche décrite dans notre article LLM on-premise vs API cloud.

Les endpoints supportés incluent /v1/chat/completions, /v1/completions, /v1/embeddings et /v1/models. Le streaming SSE (Server-Sent Events) est supporté, ce qui permet des réponses en temps réel dans un chatbot.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#Open WebUI : l'interface ChatGPT pour Ollama

Ollama seul est un outil en ligne de commande. Pour un usage multi-utilisateurs en entreprise, il faut une interface web. Open WebUI est la référence open source — c'est une application web qui se connecte à Ollama et offre une expérience similaire à ChatGPT :

• Gestion multi-utilisateurs avec authentification (LDAP, OAuth, SAML)
• Historique des conversations par utilisateur
• Upload de documents pour du RAG intégré
• Choix du modèle via dropdown
• Prompts système personnalisables par workspace
• Export des conversations

Déploiement Docker avec Ollama :

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    depends_on:
      - ollama
    volumes:
      - open-webui-data:/app/backend/data

Open WebUI inclut également un pipeline RAG natif : les utilisateurs uploadent des PDF ou des documents Word, et le système les indexe automatiquement dans une base vectorielle locale (ChromaDB) pour répondre en contexte. Pour des architectures RAG plus avancées, nous recommandons d'intégrer LangChain ou LlamaIndex — voir notre guide sur l'architecture RAG en entreprise.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#Performances par GPU et quantification

La vitesse d'inférence d'Ollama dépend de trois facteurs : le modèle, le niveau de quantification et le GPU.

La quantification réduit la précision des poids du modèle (de FP16 à INT8 ou INT4) pour diminuer la VRAM nécessaire et accélérer l'inférence. Les niveaux courants :

• Q8 : qualité quasi-identique à FP16, VRAM réduite de ~50 %
• Q4_K_M : bon compromis qualité/vitesse, le plus utilisé en production
• Q4_0 : le plus rapide, légère dégradation qualitative sur les tâches complexes

Benchmarks indicatifs (tokens/seconde en génération, prompt court) :

Pour un chatbot interactif, on vise au minimum 20 tokens/seconde — en dessous, l'expérience utilisateur est dégradée. Pour des traitements batch (analyse de documents, extraction), la vitesse est moins critique.

Pour une comparaison détaillée avec d'autres runtimes, consultez notre comparatif Ollama vs LM Studio vs vLLM.

#Sécurité réseau : les erreurs à ne pas commettre

Par défaut, Ollama écoute sur localhost:11434 — ce qui signifie qu'il n'est accessible que depuis la machine locale. C'est sécurisé par défaut. Les problèmes commencent quand on veut le rendre accessible à d'autres machines du réseau.

Les erreurs fréquentes que nous constatons en audit :

1. Exposer Ollama directement sur 0.0.0.0:11434 sans authentification. Ollama n'a pas de mécanisme d'authentification intégré. Exposer le port revient à donner un accès libre au modèle.
2. Ouvrir le port sur Internet. Des scanners automatiques détectent les instances Ollama exposées en quelques heures. On a vu des cas d'instances publiques utilisées pour du minage de crypto.
3. Ne pas limiter les modèles accessibles. Par défaut, tout utilisateur peut pull n'importe quel modèle depuis le registry Ollama, ce qui consomme de la bande passante et du stockage.

L'architecture sécurisée recommandée par Nehos :

• Ollama écoute uniquement sur 127.0.0.1 ou sur un réseau Docker interne
• Un reverse proxy (Nginx, Traefik, Caddy) avec authentification TLS + token API ou mTLS
• Firewall/iptables pour bloquer l'accès direct au port 11434 depuis l'extérieur
• Open WebUI derrière un SSO d'entreprise (LDAP/OAuth) pour l'accès utilisateur
• Registry modèles verrouillé : utiliser OLLAMA_NOPRUNE=1 et pré-charger uniquement les modèles approuvés

Cette architecture est exactement ce que notre équipe LLMOps met en place lors des déploiements en cloud souverain français.

#Cas d'usage RAG avec Ollama

Ollama s'intègre naturellement dans une architecture RAG locale. Le pipeline type :

1. Ingestion : LangChain ou LlamaIndex parse les documents (PDF, Word, emails) et les découpe en chunks
2. Embedding : Ollama expose des modèles d'embedding (nomic-embed-text, mxbai-embed-large) via son endpoint /v1/embeddings
3. Stockage : les vecteurs sont indexés dans pgvector (PostgreSQL) ou ChromaDB
4. Retrieval + Generation : la requête utilisateur est vectorisée, les chunks pertinents sont récupérés, et Ollama génère la réponse avec le contexte

L'avantage : l'ensemble du pipeline tourne en local. Aucune donnée ne transite par un service externe. C'est la configuration idéale pour les entreprises qui doivent traiter des documents confidentiels (contrats, dossiers patients, données financières) tout en bénéficiant de la puissance d'un LLM.

Nehos déploie cette architecture dans le cadre de ses missions de déploiement IA générative souveraine, avec un accompagnement sur le choix du modèle, le dimensionnement GPU et l'optimisation du pipeline RAG.