Ollama en production : comment déployer l'IA locale dans votre PME

De nombreuses PME ont déjà testé Ollama sur un portable : on l'installe, on télécharge un modèle, on exécute quelques prompts et l'IA tourne localement sans envoyer quoi que ce soit au cloud. Le vrai défi commence quand on veut passer cela en production : qu'il réponde à toute l'équipe, qu'il ne tombe pas en panne, qu'il soit rapide, sûr et intégré. C'est ce passage que nous allons décortiquer.

L'objectif est qu'une PME réelle puisse disposer d'une IA locale fonctionnant 24/7 avec un coût raisonnable et sans dépendre de tiers.

Qu'est-ce qu'Ollama et pourquoi cela intéresse une PME

Ollama est un outil open source qui simplifie l'exécution de grands modèles de langage (LLM) sur votre propre matériel. Vous téléchargez des modèles compatibles — Llama, Mistral, Qwen, Gemma et bien d'autres — et vous les servez via une API locale. Pas besoin de savoir utiliser PyTorch, CUDA ou des conteneurs complexes. En quelques commandes, un modèle est déjà en cours d'exécution.

Pour une PME, cela change la donne :

• Souveraineté des données. Vos conversations, documents et requêtes ne quittent pas votre réseau.
• Coût prévisible. Vous payez le matériel une fois ; ensuite, vous ne payez ni par token ni par utilisateur.
• Aucune dépendance aux fournisseurs. Vous ne dépendez pas qu'OpenAI, Anthropic ou Google changent de prix, de politique ou de disponibilité.
• Intégration simple. L'API REST d'Ollama se connecte facilement à n8n, à vos applications ou à des agents internes.

Ollama n'est pas le modèle en lui-même : c'est le moteur qui le met en marche dans votre environnement.

De l'essai au déploiement en production

La différence entre "j'ai Ollama sur mon portable" et "Ollama en production" est la même qu'entre une voiture d'essai et un véhicule de flotte. En production, vous avez besoin de :

• Disponibilité. Le service doit démarrer seul, survivre aux redémarrages et se remettre d'erreurs.
• Concurrence. Plusieurs employés ou processus peuvent interroger le modèle simultanément.
• Performance stable. Que le temps de réponse soit prévisible, et non pas 2 secondes parfois et 30 secondes d'autres.
• Supervision. Savoir si le service est tombé, si le GPU est à 100 % ou s'il y a des erreurs.
• Gestion des modèles. Pouvoir mettre à jour, changer ou ajouter des modèles sans tout arrêter.
• Sécurité. Que n'importe qui ne puisse pas accéder à votre API locale depuis l'extérieur.

Tout cela se monte avec un matériel modeste et des outils open source. L'important est de le concevoir avant que les utilisateurs ne commencent à en dépendre.

Prérequis matériels réalistes

Pas besoin d'un superordinateur. Il faut savoir quel modèle vous allez exécuter et combien de personnes vont l'utiliser.

La VRAM est le goulot d'étranglement. Un modèle de 7B à 4 bits occupe généralement 4 à 5 Go de VRAM, mais un contexte long peut doubler cette consommation. Si vous traitez des documents volumineux ou maintenez des conversations longues, visez 12 Go de VRAM minimum. Sans GPU, tout fonctionne en CPU, mais la vitesse chute d'un facteur 5 à 20 : utilisable pour des tests, frustrant en production.

Le stockage compte aussi. Les modèles pèsent entre 2 Go et 50 Go. Un disque SSD de 500 Go suffit pour commencer ; 1 To vous donne de la marge pour plusieurs modèles, bases vectorielles et logs.

Modèles recommandés selon le cas d'usage

Ollama permet de télécharger des dizaines de modèles, mais ils ne servent pas tous à la même chose. Voici ceux que nous recommandons habituellement chez Neurosint :

• Llama 3.1 / 3.2 (8B). Équilibre entre qualité et vitesse. Idéal pour le chat interne, la classification d'emails et les agents qui suivent des instructions structurées.
• Mistral 7B / Mixtral 8x7B. Mistral 7B est rapide et raisonne bien en français. Mixtral offre une qualité proche de modèles bien plus grands, mais nécessite plus de VRAM.
• Qwen 2.5 (7B-14B). Excellent pour les tâches multilingues, y compris le français. Utile si votre PME opère en plusieurs langues.
• Gemma 2 (9B). Bonne option pour résumer des textes longs et répondre à des questions sur des documents si vous disposez de suffisamment de VRAM.
• Modèles spécialisés. Pour le code, Code Llama ou DeepSeek Coder ; pour les embeddings, nomic-embed-text ou all-minilm ; pour la vision, Llava si vous avez besoin d'analyser des images.

La clé n'est pas d'utiliser le plus grand modèle, mais le plus adapté. Un modèle de 7B bien configuré résout la majorité des besoins d'une PME. Si vous avez besoin de plus de précision, augmentez la taille ; si vous avez besoin de vitesse, diminuez la quantification.

Architecture de déploiement typique

La façon la plus solide de déployer Ollama dans une PME est avec Docker sur un serveur dédié ou une machine virtuelle. Une architecture de base serait :

1. Serveur physique ou virtuel avec GPU (si possible) dans votre réseau local ou DMZ.
2. Docker et Docker Compose pour lancer Ollama de façon reproductible.
3. Volume persistant pour les modèles, afin qu'ils ne se téléchargent pas à chaque fois.
4. Reverse proxy (nginx, Traefik ou Caddy) qui termine HTTPS et route vers Ollama.
5. Authentification sur le proxy : clé API, OAuth interne ou restriction par IP/VPN.
6. Supervision de base avec logs centralisés et alertes de disponibilité.
7. Sauvegardes du volume de modèles et de la configuration.

Il n'est pas nécessaire d'exposer Ollama à internet. Dans la plupart des cas, il suffit qu'il soit accessible depuis votre réseau local ou votre VPN. Si vous voulez que des employés en remote l'utilisent, ils se connectent d'abord au VPN ; vous n'ouvrez pas le port au monde entier.

Pour une haute disponibilité modeste, vous pouvez avoir un second serveur avec un modèle plus petit comme secours, ou configurer un plan de contingence qui, en cas de panne, oriente les requêtes critiques vers un autre modèle ou une file différée.

API REST et intégration avec n8n et des agents

Ollama expose une API REST qui est le pont vers vos flux de travail. Les endpoints les plus utiles sont :

• /api/generate : pour une réponse unique à partir d'un prompt.
• /api/chat : pour des conversations avec historique.
• /api/embeddings : pour convertir des textes en vecteurs et alimenter une base de données vectorielle dans un système RAG.

Un appel de base avec curl ressemble à ceci :

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1",
  "prompt": "Résume ce texte en trois points : ...",
  "stream": false
}'

Dans n8n, vous utilisez le nœud HTTP Request pointant vers votre Ollama interne. À partir de là, vous pouvez construire des flux comme :

• Classer les emails de service client et répondre avec des brouillons.
• Résumer les documents joints et enregistrer le résumé dans votre CRM.
• Générer des descriptions de produits à partir de fiches techniques.
• Alimenter un agent qui consulte votre base de connaissances locale.

Si vous utilisez des frameworks d'agents comme LangChain, LlamaIndex ou CrewAI, la plupart permettent de pointer vers l'endpoint d'Ollama comme s'il s'agissait d'OpenAI. Il suffit de changer l'URL de base et le nom du modèle. Ainsi, vos agents tournent entièrement dans votre infrastructure.

Sécurité : ce n'est pas suffisant d'être local

Faire tourner l'IA localement est un grand pas pour la confidentialité, mais cela ne suffit pas. En production, appliquez ces couches :

• Isolez le réseau. Ollama n'a pas besoin d'accéder à internet pour générer du texte. Coupez son accès sortant sauf pour télécharger des modèles, et faites ces téléchargements depuis une machine de gestion.
• Contrôlez l'accès. N'exposez jamais le port 11434 directement. Utilisez un proxy avec HTTPS et authentification. Limitez par IP ou VPN.
• Principe du moindre privilège. Les agents qui ne font que lire ne doivent pas écrire. Ceux qui écrivent ne doivent pas supprimer. Chaque intégration a sa propre clé.
• Sandbox. Si un agent peut exécuter des actions (envoyer des emails, modifier des bases de données), exécutez ces actions dans un environnement contrôlé avec des permissions strictes.
• Logs et audit. Enregistrez qui interroge quoi, quand et avec quel résultat. Cela sert à détecter des problèmes et à respecter le RGPD.
• Mises à jour. Ollama, le système d'exploitation et les modèles doivent être mis à jour. Les modèles reçoivent aussi des correctifs de sécurité et des améliorations.

N'oubliez pas : un modèle local avec un accès incontrôlé à votre messagerie ou ERP peut être aussi dangereux qu'une API externe mal configurée.

Erreurs courantes qui freinent le déploiement

Chez Neurosint, nous avons vu les mêmes écueils encore et encore. Évitez-les :

• Espérer la vitesse du cloud avec un CPU. Ollama en CPU fonctionne, mais pas pour la production avec des utilisateurs réels. Si le budget le permet, investissez en GPU.
• Choisir un modèle trop grand. Un 70B sur une GPU de 12 Go ralentit tout ou n'entre carrément pas. Mieux vaut un 7B-8B quantifié qui coule.
• Laisser l'API publique. Le port 11434 sans protection est un risque inutile.
• Ignorer la taille du contexte. Des prompts énormes ralentissent la génération et consomment de la VRAM. Réduisez ou résumez le contexte avant de l'envoyer.
• Ne pas valider les sorties. L'IA peut inventer des données. Si le résultat va dans un ERP, CRM ou base de données, ajoutez une couche de validation.
• Oublier la sauvegarde. Un jour, le disque tombe en panne et on se rend compte qu'il n'y avait pas de copie des modèles ni de la configuration.
• Prompt injection. Un utilisateur ou un email malveillant peut rediriger le modèle. Limitez ce qu'il peut faire et validez les instructions.

La plupart de ces erreurs se résolvent avec de bonnes pratiques, pas avec plus de matériel.

Conclusion : l'IA locale est à portée de votre PME

Ollama n'est pas seulement un outil pour faire des tests. Avec le matériel adéquat et une architecture sécurisée, il peut devenir le moteur d'IA de votre PME : service client, automatisation de documents, agents internes, assistants de connaissances.

L'avantage est aussi stratégique : vous contrôlez vos données, réduisez la dépendance au cloud et amortissez un investissement initial en quelques mois, au lieu d'un abonnement qui grandit avec chaque utilisateur.

Commencez petit : un cas d'usage, un modèle 7B en GPU, n8n, et mesurez les économies. Scaler ensuite est une question de répéter la formule.

Chez Neurosint, nous aidons les PME de Bilbao et des environs à concevoir, déployer et sécuriser des infrastructures d'IA locale avec Ollama, n8n et des modèles open source. Si vous voulez passer des essais à la production sans dépendre du cloud, parlons-en.