IA locale en entreprise avec Ollama et Python

Depuis que ChatGPT a débarqué fin 2022, tout le monde veut mettre de l'IA partout. Le problème, c'est que la plupart des solutions passent par le cloud : vos données partent chez OpenAI, Anthropic ou Google, vous payez au token, et vous n'avez aucun contrôle sur ce qui se passe avec vos informations. Pour une PME qui traite des données sensibles (contrats, factures, données clients), c'est un vrai sujet.

La bonne nouvelle : depuis 2024, il existe des LLM open-source suffisamment performants pour tourner en local, sur un serveur que vous contrôlez. Et Ollama rend leur déploiement ridiculement simple.

Pourquoi du local plutôt que du cloud ?

Trois raisons principales :

1. Souveraineté des données. Quand vous envoyez un contrat client à GPT-4 pour le résumer, ce contrat transite par les serveurs d'OpenAI aux États-Unis. Même si OpenAI affirme ne pas utiliser les données API pour l'entraînement, vous n'avez aucune garantie juridique solide. Avec un LLM local, les données ne quittent jamais votre réseau.

2. Coûts prévisibles. GPT-4 Turbo coûte environ 10 $ / million de tokens en entrée. Pour une PME qui traite 500 documents par mois, ça monte vite : 200-500 €/mois facilement. Un serveur avec GPU amorti en 6-12 mois, après c'est gratuit (hors électricité et maintenance).

3. Latence et disponibilité. Pas de dépendance à une API externe. Pas de rate limiting. Pas de panne OpenAI un mardi matin quand vous avez 50 emails à classifier. Le serveur est dans votre salle, il répond en 200ms.

Et il y a un quatrième point que beaucoup sous-estiment : la personnalisation. Avec un modèle local, vous pouvez le fine-tuner sur vos données métier. Un modèle 8B fine-tuné sur 500 exemples de classification d'emails spécifiques à votre secteur surpassera souvent GPT-4 sur cette tâche précise — pour un coût marginal. Essayez de fine-tuner GPT-4 : c'est possible mais cher, et vos données d'entraînement partent chez OpenAI.

Installation d'Ollama en 5 minutes

Ollama s'installe sur Linux, macOS et Windows. La méthode la plus propre pour un serveur d'entreprise, c'est Docker :

# docker-compose.yml pour Ollama avec GPU NVIDIA
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    restart: unless-stopped

volumes:
  ollama_data:

# Lancer et télécharger un modèle
docker compose up -d
docker exec ollama ollama pull llama3.1:8b
# Le modèle fait ~4.7 Go, téléchargement en quelques minutes

Pour un usage sans GPU (CPU uniquement), retirez la section deploy.resources. Ça tournera, mais plus lentement — comptez 10-30 secondes par réponse au lieu de 1-3 secondes avec GPU.

Un point important sur Docker : montez un volume persistent pour les modèles. Ils font entre 4 et 40 Go selon la taille. Vous ne voulez pas les re-télécharger à chaque docker compose down. Le volume ollama_data dans le compose ci-dessus fait exactement ça.

Pour la production, j'ajoute aussi un healthcheck et un reverse proxy nginx devant :

# Test que Ollama repond
curl -s http://localhost:11434/api/tags | python -m json.tool
# Devrait lister les modeles installes

Interroger Ollama depuis Python

L'API d'Ollama est un simple endpoint HTTP. Pas besoin de SDK compliqué :

import requests
import json

def interroger_ollama(prompt, modele="llama3.1:8b", temperature=0.3):
    # Envoie un prompt a Ollama et retourne la reponse complete.
    response = requests.post(
        "http://localhost:11434/api/generate",
        json={
            "model": modele,
            "prompt": prompt,
            "stream": False,
            "options": {
                "temperature": temperature,
                "num_predict": 1024,
            }
        },
        timeout=120,
    )
    response.raise_for_status()
    return response.json()["response"]


# Exemple : classifier un email
email_text = "Bonjour, suite à notre échange, veuillez trouver ci-joint notre commande..."
resultat = interroger_ollama(
    f"Classifie cet email en une seule catégorie parmi : "
    f"commande, réclamation, demande_info, spam, autre.\n\n"
    f"Email : {email_text}\n\nCatégorie :"
)
print(resultat)  # → "commande"

Pour du streaming (affichage progressif), passez "stream": True et itérez sur les chunks :

def interroger_ollama_stream(prompt, modele="llama3.1:8b"):
    response = requests.post(
        "http://localhost:11434/api/generate",
        json={"model": modele, "prompt": prompt, "stream": True},
        stream=True,
        timeout=120,
    )
    for line in response.iter_lines():
        if line:
            chunk = json.loads(line)
            if not chunk.get("done"):
                print(chunk["response"], end="", flush=True)
    print()

Cas d'usage concrets en PME

1. Classification automatique des emails

Un de mes clients reçoit 200+ emails/jour sur une boîte générique contact@. Avant : un employé passait 2h/jour à trier et rediriger. Maintenant : un script Python lit les emails via IMAP, les envoie à Ollama pour classification (commercial, technique, comptabilité, spam), et les redirige automatiquement. Temps gagné : 1h45/jour, soit environ 380h/an.

2. Résumé de documents techniques

Un bureau d'études qui reçoit des cahiers des charges de 40-80 pages. Le LLM local extrait en 30 secondes un résumé structuré : objet, contraintes techniques, budget estimé, délais. Le commercial peut évaluer la pertinence d'un appel d'offres en 2 minutes au lieu de 30.

3. Analyse de contrats

Identifier les clauses à risque dans un contrat fournisseur. Le modèle est prompté pour repérer : pénalités de retard, clauses d'exclusivité, tacite reconduction, limitations de responsabilité. Pas un substitut au juridique, mais un premier filtre qui fait gagner du temps.

4. Génération de réponses commerciales

À partir d'une demande client et du catalogue de l'entreprise, Ollama génère un brouillon de réponse commerciale que le commercial n'a plus qu'à relire et ajuster. J'ai mesuré un gain de 40% sur le temps de rédaction des devis chez un client.

5. Extraction de données structurées

Transformer des bons de commande PDF en données structurées (JSON). Le LLM lit le texte extrait du PDF et en sort les lignes articles, quantités, prix unitaires, conditions de livraison. Fiabilité constatée : 92-95% sur des formats récurrents, ce qui reste suffisant avec une validation humaine rapide.

Pour ce dernier cas, voici un exemple de prompt qui fonctionne bien :

PROMPT_EXTRACTION = (
    "Extrais les informations suivantes de ce bon de commande "
    "et retourne-les en JSON strict :\n"
    "- numero_commande\n"
    "- date_commande\n"
    "- client (nom, adresse)\n"
    "- lignes (reference, designation, quantite, prix_unitaire)\n"
    "- total_ht\n"
    "- conditions_livraison\n\n"
    "Bon de commande :\n{texte_pdf}"
)

result = interroger_ollama(
    PROMPT_EXTRACTION.format(texte_pdf=texte_extrait),
    modele="llama3.1:8b",
    temperature=0.1,  # Temperature basse pour de l extraction
)

La clé pour un bon résultat : une température basse (0.1-0.2) pour de l'extraction, un prompt ultra-structuré avec le format de sortie attendu, et une validation JSON derrière pour rattraper les cas où le modèle hallucine. Sur 1 000 extractions testées, 94% passaient la validation JSON du premier coup, et les 6% restants nécessitaient un retry avec un prompt légèrement reformulé.

RGPD : l'avantage décisif du local

Le RGPD impose que le traitement des données personnelles soit encadré. Quand vous utilisez un LLM cloud, vous êtes dans un schéma de sous-traitance (article 28 du RGPD) avec transfert hors UE (chapitre V). Il faut un DPA (Data Processing Agreement), des clauses contractuelles types, et vous restez responsable en cas de fuite.

Avec un LLM local :

• Pas de transfert de données hors de votre infrastructure
• Pas de sous-traitant supplémentaire à auditer
• Les données restent dans votre périmètre de sécurité existant
• Vous pouvez documenter précisément le traitement dans votre registre RGPD

C'est un argument massif pour les secteurs réglementés : santé, juridique, finance, défense.

J'ai un client dans le secteur médical qui ne pouvait pas utiliser de LLM cloud à cause de la réglementation HDS (Hébergement de Données de Santé). Avec Ollama en local sur un serveur certifié, il a pu déployer un assistant IA pour le résumé de comptes-rendus médicaux en restant parfaitement dans les clous réglementaires. Le DPO a même salué l'approche, ce qui n'arrive pas souvent.

Quel matériel pour quel usage ?

Usage	Modèle recommandé	GPU minimum	RAM GPU	Budget serveur
Classification, extraction simple	Llama 3.1 8B / Mistral 7B	RTX 3060 / T4	12 Go	1 500 — 2 500 €
Résumé, rédaction, analyse	Llama 3.1 70B (quantisé Q4)	RTX 4090 / A6000	24-48 Go	3 000 — 6 000 €
Multi-tâches, haute qualité	Llama 3.1 70B (FP16)	2x A100 / 2x H100	80+ Go	15 000 — 40 000 €

Pour la plupart des PME, un serveur avec une RTX 4090 (24 Go VRAM, ~2 000 €) suffit largement. On fait tourner Llama 3.1 8B à 40+ tokens/seconde dessus, et même le 70B quantisé à 8-12 tokens/seconde, ce qui est très acceptable pour du traitement batch.

Si vous avez déjà un serveur correct (type Dell PowerEdge), vous pouvez souvent ajouter une carte GPU pour 1 500-3 000 € et c'est réglé. Pas besoin de racheter toute l'infra.

Limites honnêtes

Soyons clairs sur ce qu'un LLM local 8B ne fait pas aussi bien que GPT-4 ou Claude :

• Raisonnement complexe multi-étapes : les petits modèles se perdent vite
• Génération de code long et complexe : ça reste moyen
• Compréhension de contextes très longs (100+ pages) : la fenêtre de contexte est limitée
• Multilingue avancé : les modèles 7-8B sont meilleurs en anglais qu'en français

Mais pour les tâches répétitives et structurées (classification, extraction, résumé court, reformulation), un modèle 8B local fait le job dans 85-90% des cas. Et quand il se trompe, vous avez un humain dans la boucle pour corriger.

Un point technique que je veux souligner : la qualité des modèles open-source progresse à une vitesse folle. Llama 3.1 8B en 2024 est meilleur que GPT-3.5 était en 2023 sur la plupart des benchmarks. Mistral 7B, Phi-3, Qwen2... la compétition est rude et le consommateur en profite. Ce qui n'était pas viable en local il y a 18 mois l'est devenu. Et dans 18 mois, les modèles 8B rivaliseront probablement avec GPT-4 sur les tâches ciblées.

Dernier conseil pratique : commencez avec Llama 3.1 8B. C'est le meilleur rapport qualité/taille/vitesse du moment en français. Si la qualité ne suffit pas, passez à Llama 3.1 70B quantisé (Q4_K_M) — ça tient dans 24 Go de VRAM et c'est significativement meilleur. Ne partez pas directement sur du 70B, les temps d'itération seraient trop longs pour du prototypage.

Mise en production : les points à ne pas oublier

Installer Ollama et faire un test, c'est facile. Le mettre en production avec des utilisateurs métier qui dépendent du service, c'est une autre paire de manches. Voici ma checklist :

Monitoring. Ollama expose des métriques basiques, mais j'ajoute toujours un wrapper qui mesure : temps de réponse par requête, nombre de tokens générés, taux d'erreur, utilisation GPU/RAM. Un Prometheus + Grafana simple suffit. L'alerte critique : si le temps de réponse dépasse 30 secondes, c'est que le modèle est tombé ou que la VRAM est saturée.

Queue de traitement. Ne faites jamais d'appels synchrones à Ollama depuis votre application web. Utilisez Celery ou une queue Redis pour découpler. L'utilisateur soumet une demande, reçoit un accusé de réception, et le résultat arrive par notification (email, websocket) quand le LLM a fini. Sinon, les timeouts HTTP vont vous rendre fou.

Fallback. Que se passe-t-il si le serveur Ollama tombe ? Ayez un plan B : soit une queue de retry avec délai exponentiel, soit un fallback vers une API cloud (OpenAI par exemple) pour les cas critiques. L'idée n'est pas de dépendre du cloud, mais d'avoir une roue de secours.

Gestion des prompts. Ne hardcodez pas vos prompts dans le code. Mettez-les dans des fichiers de configuration ou en base de données. Quand vous voulez améliorer les résultats, vous modifiez le prompt sans toucher au code et sans redéployer. J'utilise un modèle Django simple :

# models.py
class PromptTemplate(models.Model):
    nom = models.CharField(max_length=100, unique=True)
    template = models.TextField()
    modele = models.CharField(max_length=50, default="llama3.1:8b")
    temperature = models.FloatField(default=0.3)
    version = models.PositiveIntegerField(default=1)
    actif = models.BooleanField(default=True)

Ça permet aussi de versionner les prompts et de faire de l'A/B testing : deux versions du même prompt tournent en parallèle, on compare les résultats, on garde le meilleur.

Par où commencer ?

Mon conseil : identifiez une tâche répétitive qui prend du temps à vos équipes, installez Ollama sur une machine existante (même sans GPU pour tester), et faites un POC en 2-3 jours. Si les résultats sont concluants, on passe à l'industrialisation avec un vrai serveur et un pipeline de production.

C'est le type de mission que je propose : audit des processus automatisables, POC rapide, puis industrialisation. Le POC prend généralement 3 à 5 jours, et à la fin vous avez un prototype fonctionnel et une estimation chiffrée du ROI. Si le ROI est là, on passe à la suite. Sinon, vous avez dépensé 5 jours de prestation pour savoir que ce n'était pas pertinent — c'est toujours mieux que 3 mois de développement pour arriver à la même conclusion. Détails sur mes prestations d'automatisation ici.