Prompt on Thomas

Ollama en entreprise

Sun, 02 Aug 2026 00:00:00 +0000

Souveraineté IA : Pourquoi déployer Ollama sur son propre réseau interne ?

Le risque majeur pour une entreprise aujourd’hui n’est pas l’absence d’IA, mais la “fuite de contexte”.

Chaque fois qu’un employé colle un extrait de code propriétaire, un compte rendu financier ou une stratégie marketing dans un LLM cloud, ces données quittent le périmètre de sécurité de l’entreprise. Elles deviennent, potentiellement, la matière première pour l’entraînement des futures versions du modèle. Pour une DSI, c’est un cauchemar de compliance.

La solution n’est pas d’interdire l’IA — ce qui serait contre-productif — mais de déplacer le moteur. C’est là qu’intervient le déploiement d’un serveur Ollama sur le réseau interne.

Le contrôle total : Au-delà de la confidentialité

Installer Ollama sur un serveur d’entreprise, ce n’est pas simplement “faire tourner un modèle”, c’est reprendre la main sur trois piliers critiques :

1. L’étanchéité des données (Air-gapping) L’avantage premier est mathématique : si le serveur n’a pas d’accès sortant vers le fournisseur de LLM, la donnée ne sort pas. Les documents confidentiels et les données clients restent sur vos propres disques, derrière vos propres pare-feu. Le risque de fuite vers un cloud tiers est réduit à zéro.

2. La fin de la “taxe au token” Le modèle de facturation au token des API cloud est imprévisible. Avec un serveur Ollama, le coût est fixe : c’est le prix du matériel et de l’électricité. L’entreprise repasse d’un coût opérationnel variable (OpEx) à un investissement matériel maîtrisé (CapEx).

3. La latence et la disponibilité Dépendre d’une API externe, c’est accepter des temps de réponse variables et des risques de panne globale. Un serveur local offre une latence stable et une disponibilité totale, même en cas de coupure internet.

L’équation technique : GPU, VRAM et performance

Le déploiement d’un serveur Ollama est avant tout une question de gestion de la mémoire vidéo (VRAM). Pour qu’un LLM soit rapide, il doit être chargé entièrement dans la mémoire du GPU. Si le modèle dépasse la capacité de la VRAM, le système bascule sur la RAM classique (CPU), et la vitesse de génération s’effondre.

L’alternative Apple Silicon : Le Mac Studio comme serveur d’IA

Le Mac Studio (M2 Ultra ou M3 Ultra) propose une approche radicalement différente grâce à l’Unified Memory Architecture (UMA). Contrairement à un PC où la VRAM est limitée à la carte graphique, le Mac Studio permet au GPU d’accéder à la quasi-totalité de la RAM système.

Si vous avez un Mac Studio avec 192 Go de RAM, vous pouvez charger des modèles massifs (comme un Llama 3 70B) que même une RTX 4090 ne pourrait pas ouvrir sans crash. Le GPU “voit” la RAM système comme de la VRAM. C’est la solution “Plug & Play” idéale pour ceux qui veulent de la puissance sans gérer un cluster de serveurs bruyants.

Choisir son modèle : Ne pas viser “le plus gros”

En entreprise, la pertinence prime sur la taille.

Modèles “Lightweight” : Idéaux pour la routine : résumé de mails, classification de tickets. Rapides et économes.
- gemma4:e2b
- qwen3.5:4b
- lfm2.5-2.6b
Modèles “Reasoning” : À réserver aux tâches complexes : analyse de contrats, architecture logicielle. Ils demandent beaucoup plus de VRAM (40 Go+).
- gemma4:31b
- qwen3.5:35b
Modèles spécialisés : Pour assister les développeurs sans envoyer le code sur un cloud tiers.
- codellama:34b

Valider la performance : Le test systématique avec Promptfoo

Comment s’assurer qu’un modèle local est aussi précis que GPT-4 sur vos données ? Tester “à la main” quelques prompts est une loterie. Pour lever l’incertitude, j’utilise Promptfoo (voir post précédent).

C’est un outil d’évaluation qui permet de comparer systématiquement plusieurs modèles sur un même jeu de données. On injecte 50 questions types de l’entreprise et on compare côte à côte les réponses des LLMs qui tournent sur Ollama et de l’API OpenAI.

L’approche est rigoureuse :

Tests de régression : Vérifier qu’une mise à jour de modèle ne dégrade pas la qualité.
Score de précision : Utiliser un LLM “juge” pour noter la pertinence des réponses.
Optimisation : Identifier le prompt qui fonctionne le mieux pour chaque modèle spécifique.

Gouvernance : Du serveur au poste de travail

Pour éviter que le serveur ne devienne un chaos, l’installation d’une interface comme Open WebUI est indispensable. Elle apporte une couche de gouvernance nécessaire :

Gestion des accès : Contrôler qui utilise quel modèle.
Historique partagé : Créer des bibliothèques de prompts optimisés pour les tâches métiers.
Sécurité : L’utilisateur final n’accède qu’à l’interface de chat, jamais au système de fichiers du serveur.

Conclusion : La souveraineté comme avantage compétitif

L’époque où l’IA était réservée aux géants du cloud est terminée. Aujourd’hui, une entreprise peut déployer son propre cerveau numérique sur un Mac Studio ou un serveur Linux avec Ollama, et reprendre le contrôle total de ses données.

Le passage au local n’est pas un retour en arrière technologique, c’est une stratégie de maturité. C’est choisir la confidentialité plutôt que la commodité, et la stabilité des coûts plutôt que la dépendance aux abonnements. En combinant Ollama, Open WebUI et la rigueur d’un testing via Promptfoo, l’entreprise ne se contente pas d’utiliser l’IA : elle la possède.

Promptfoo - Testez vos LLMs

Sun, 12 Jul 2026 00:00:00 +0000

Stop au “Vibe Check” : Benchmarker ses LLMs systématiquement avec Promptfoo

Le “vibe check” est l’ennemi du déploiement stable.

Quand on passe d’un modèle à un autre (par exemple de GPT-4o à Claude 3.5 Sonnet) ou qu’on ajuste un prompt système, on a l’impression que “ça marche toujours”. Mais sans métriques, on ne sait pas si on a corrigé un bug dans un coin tout en créant une régression majeure ailleurs.

Pour sortir de l’intuition, j’utilise promptfoo. C’est un outil CLI qui permet de tester des prompts sur plusieurs modèles en parallèle et de valider les sorties via des assertions.

Voici la méthode pour monter un benchmark robuste en moins de 30 minutes.

1. La stratégie : Le Framework d’Expertise Multi-Dimensionnel

L’erreur classique est de créer une liste plate de questions. Pour un benchmark qui a du sens, il faut segmenter par domaines d’expertise et par niveaux de difficulté.

Je divise mes tests en trois paliers :

L1 (Baseline) : Tâches standards. On vérifie que le modèle connaît la base.
L2 (Stress) : Contraintes complexes ou demandes contre-intuitives. On teste la capacité d’application.
L3 (Edge) : Cas limites, paradoxes ou contraintes extrêmes (ex: lipogrammes). On cherche le point de rupture.

Pour chaque domaine (Coding, Raisonnement, Rédaction), je crée un jeu de données qui suit cette progression.

2. La plomberie : Architecture des fichiers

L’idée est de séparer la configuration (le “comment”) des données (le “quoi”).

La structure :

benchmark/
├── promptfooconfig.yaml   # Configuration des modèles et prompts
└── tests/
    ├── software_engineering.csv  # Données de test domaine A
    └── complex_reasoning.csv     # Données de test domaine B

Dans les fichiers CSV, j’utilise des colonnes expertise, prompt et assert. Promptfoo injecte automatiquement ces variables dans le template de prompt.

expertise,prompt,assert
Software Engineering,"Implement a function in Python to find the first non-repeating character in a string. Return the index.","contains('O(n)')"
Software Engineering,"Create a JSON schema for a 'Book' object that includes title, author, ISBN-13, and a list of genres.","contains('ISBN-13')"

3. Implémentation technique

Voici le cœur du système. Le fichier promptfooconfig.yaml définit le template et les providers.

prompts:
  - "You are a world-class expert in {{expertise}}. Please provide a professional response to: {{prompt}}"

providers:
  - "ollama:chat:oamazonasgabriel/lfm2.5-2.6b:q4_k_m-8gbGPU"
  - "ollama:chat:qwen3.5:4b"

tests:
  - tests/software_engineering.csv
  - tests/complex_reasoning.csv

Le secret des assertions : Ne vous contentez pas de vérifier si un mot est présent (contains). Pour les niveaux L2 et L3, utilisez le llm-rubric. C’est un “modèle juge” qui évalue la réponse selon des critères précis.

Exemple d’assertion pour un test de code L3 : llm-rubric: "La réponse doit utiliser std::atomic, gérer le problème ABA et ne contenir aucun mutex."

4. Exécution et Analyse

Le workflow est simple :

promptfoo eval : Lance tous les tests sur tous les modèles.
promptfoo view : Ouvre une interface web.

L’interface affiche un tableau comparatif. En un coup d’œil, on voit quel modèle échoue sur les cas L3 et lequel est le plus stable sur les L1. C’est là que le choix du modèle devient une décision d’ingénierie et non une préférence personnelle.

Conclusion

Passer du “je pense que ça marche” au “ce modèle a un score de 85% sur mon jeu de test L2” change totalement la manière de construire des produits AI. Le benchmark n’est pas une étape finale, c’est un garde-fou permanent.

Idée de prochaine étape : Intégrer ce benchmark dans une CI/CD pour bloquer tout déploiement si le score de régression dépasse 5%.