LLM en Local et RGPD 2026 Souveraineté Totale

Introduction — Le Cloud Act au cœur du problème

Chaque fois que vous saisissez une donnée dans ChatGPT, Claude ou Gemini, cette donnée part sur un serveur américain. Le Cloud Act de 2018 autorise les autorités américaines à exiger l'accès à ces données, même hébergées en Europe, dès lors que le prestataire est une entreprise de droit américain. Pour une entreprise française traitant des données confidentielles — brevets, données patients, dossiers clients, stratégie commerciale — c'est un risque juridique et concurrentiel majeur.

La réponse technique existe : les LLM en local. Héberger son propre modèle de langage sur son infrastructure signifie que vos données ne quittent jamais votre périmètre. Zéro transfert, zéro sous-traitant américain, conformité RGPD article 46 respectée par construction.

En 2026, cette approche est devenue accessible. Les modèles open source ont rattrapé la majeure partie de l'écart de performance avec les API commerciales :

Ce guide pratique vous explique comment déployer un LLM en local ou on-premise sans être data scientist : choix du modèle, configuration matérielle, outil de déploiement, intégration dans vos workflows et conformité RGPD.

Pourquoi un LLM en local ? 5 raisons business

Les 5 arguments décisifs

1. Données confidentielles protégées. Secrets industriels, formules, données brevets, dossiers clients, comptes rendus médicaux : ces données ne doivent jamais transiter hors de votre infrastructure. Un LLM local traite tout en mémoire vive, localement, sans log externe.

2. RGPD et transferts hors UE. L'article 46 du RGPD encadre strictement les transferts de données personnelles vers des pays tiers. Avec un LLM local, il n'y a aucun transfert — la question ne se pose pas. Vous éliminez aussi la nécessité d'un Data Processing Agreement (DPA) avec un sous-traitant IA américain.

3. Coûts prévisibles. L'API GPT-4o coûte 5 à 15 $/million de tokens selon le modèle. Un LLM local ne coûte que de l'électricité après l'investissement matériel initial. Pour les entreprises à fort volume (support client, analyse documentaire, génération de contenus), le ROI est atteint en 3 à 6 mois.

4. Latence réduite à zéro réseau. Pas d'appel API, pas d'attente réseau. Le modèle répond directement depuis la RAM/VRAM locale. Sur un Mac M3 Max, Llama 70B génère à 30 tokens/sec sans aucune latence réseau.

5. Disponibilité totale. Un LLM local fonctionne hors ligne. Coupure internet, maintenance du fournisseur cloud, modifications d'API non annoncées : rien de tout cela ne vous affecte. Vos workflows IA sont résilients.

Les contre-arguments honnêtes

Pour la plupart des cas d'usage entreprise (traitement documentaire, classification, génération de textes standardisés, FAQ interne), les modèles open source sont largement suffisants.

Les modèles open source disponibles en 2026

Le paysage des LLM open source a considérablement évolué. Voici les modèles à connaître en 2026 selon vos besoins :

Tous ces modèles sont disponibles sur Hugging Face et directement téléchargeables via Ollama avec une simple commande.

Ollama : la solution la plus simple pour démarrer

Ollama est l'outil qui a démocratisé les LLM locaux. Il gère tout — téléchargement des modèles, quantification, API REST compatible OpenAI — avec une interface en ligne de commande intuitive. Compatible macOS, Linux et Windows.

Installation en 2 commandes

• macOS / Linux : ouvrez un terminal et exécutez curl -fsSL https://ollama.com/install.sh | sh — l'installateur configure automatiquement le service et les dépendances GPU (CUDA ou Metal).
• Windows : téléchargez l'installateur depuis https://ollama.com/download/windows et exécutez-le. Ollama s'installe en tant que service Windows avec support CUDA automatique si un GPU NVIDIA est détecté.
• Vérifiez l'installation : ollama --version doit retourner la version installée. Le service tourne sur http://localhost:11434 par défaut.

Premiers pas : télécharger et lancer un modèle

Trois commandes suffisent pour avoir un LLM opérationnel :

# Télécharger Mistral 7B (4,1 Go)
ollama pull mistral

# Démarrer une conversation interactive
ollama run mistral

# Lister les modèles disponibles localement
ollama list

Une fois lancé, ollama run mistral ouvre un chat interactif dans le terminal. Tapez votre message, appuyez sur Entrée, le modèle répond en quelques secondes. /bye pour quitter.

API compatible OpenAI

Ollama expose une API REST compatible avec le format OpenAI sur http://localhost:11434/v1/. Vous pouvez donc remplacer https://api.openai.com/v1 par http://localhost:11434/v1 dans n'importe quel client OpenAI existant sans changer le reste du code.

# Exemple appel API direct (curl)
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral",
    "messages": [{"role": "user", "content": "Résume ce contrat en 3 points"}]
  }'

Intégrations natives

Ollama s'intègre directement avec N8N (nœud HTTP Request ou nœud Ollama natif depuis N8N 1.40), Open WebUI (interface graphique complète, voir section suivante), et LangChain / LlamaIndex pour les pipelines RAG.

LM Studio : l'interface graphique no-code

LM Studio est l'alternative visuelle à Ollama. Téléchargeable sur https://lmstudio.ai, c'est une application bureau (Windows, macOS, Linux) qui permet de gérer ses LLM locaux sans jamais ouvrir un terminal.

Ce que vous pouvez faire avec LM Studio

• Découverte de modèles : moteur de recherche intégré connecté à Hugging Face — filtrez par taille, architecture, langue, licence commerciale.
• Téléchargement en un clic : sélectionnez la quantification (Q4_K_M recommandé pour l'équilibre qualité/taille) et téléchargez directement depuis l'interface.
• Configuration GPU/CPU : curseur pour choisir combien de couches décharger sur le GPU — optimisation visuelle sans ligne de commande.
• Chat intégré : interface conversationnelle avec historique, réglage de la température, système prompt configurable.
• Mode serveur API : activez le serveur local en un clic — LM Studio expose alors une API compatible OpenAI sur le port 1234.

Limites de LM Studio

LM Studio est excellent pour l'usage individuel et les tests. Pour la production multi-utilisateurs et l'intégration dans des workflows automatisés, Ollama + Open WebUI offre plus de flexibilité et une meilleure gestion des ressources.

Open WebUI : votre ChatGPT local complet

Open WebUI (anciennement Ollama WebUI) est une interface web open source qui transforme votre Ollama local en un clone fonctionnel de ChatGPT. Disponible sur https://github.com/open-webui/open-webui, c'est la solution la plus populaire pour déployer un assistant IA interne en entreprise.

Fonctionnalités principales

• Interface conversationnelle complète — historique des conversations, dossiers, recherche dans l'historique, partage de conversations.
• Multi-modèles — switchez entre Llama, Mistral, Qwen depuis le même chat sans reconfigurer quoi que ce soit.
• RAG intégré — uploadez un PDF ou une page web, posez des questions dessus. Le moteur RAG extrait les passages pertinents et les injecte dans le contexte du LLM. Zéro cloud.
• Gestion multi-utilisateurs — créez des comptes, définissez des rôles (admin, utilisateur), limitez l'accès à certains modèles.
• Prompts système partagés — créez des assistants spécialisés (assistant juridique, rédacteur, analyste) réutilisables par toute l'équipe.
• API compatible OpenAI — vos intégrations existantes fonctionnent sans modification.

Déploiement en 3 minutes avec Docker

docker run -d \
  --name open-webui \
  --network host \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Open WebUI est ensuite accessible sur http://localhost:3000. Le premier utilisateur créé devient automatiquement administrateur.

Configuration matérielle : quel investissement pour quel modèle ?

La performance d'un LLM local dépend principalement de la mémoire disponible (VRAM GPU ou RAM unifiée sur Mac Silicon) et de la bande passante mémoire. Voici les configurations types en 2026 :

Estimation de la VRAM nécessaire par modèle

En quantification 4-bit (format GGUF Q4_K_M recommandé), la règle empirique est : ~0,6 Go de VRAM par milliard de paramètres + 2 Go pour le contexte. Un modèle 7B nécessite donc ~6 Go, un 13B ~10 Go, un 70B ~44 Go.

Déploiement en entreprise avec Docker

Pour un déploiement production multi-utilisateurs, la stack recommandée combine Ollama + Open WebUI + N8N, orchestrés avec Docker Compose, servis derrière un reverse proxy HTTPS.

Architecture cible

Le fichier docker-compose.yml doit définir quatre services :

• ollama — service LLM, port 11434 interne uniquement, volume pour les modèles (ollama-models:/root/.ollama), accès GPU via deploy.resources.reservations.devices
• open-webui — interface utilisateur, port 3000 interne, dépendance sur ollama, volume persistant pour les conversations et documents RAG
• n8n — orchestration des workflows IA, port 5678, volume pour les workflows (n8n-data:/home/node/.n8n), accès à Ollama via le réseau Docker interne
• caddy ou nginx — reverse proxy HTTPS avec Let's Encrypt, expose les ports 80/443, route les domaines vers les services internes

Variables d'environnement essentielles

# Ollama
OLLAMA_MODELS=/root/.ollama/models
OLLAMA_NUM_PARALLEL=2          # requêtes simultanées
OLLAMA_MAX_LOADED_MODELS=2     # modèles en mémoire simultanément

# Open WebUI
OLLAMA_BASE_URL=http://ollama:11434
WEBUI_SECRET_KEY=votre-clé-secrète-longue-et-aléatoire
DEFAULT_MODELS=mistral

# N8N
N8N_BASIC_AUTH_ACTIVE=true
N8N_BASIC_AUTH_USER=admin
N8N_BASIC_AUTH_PASSWORD=mot-de-passe-fort
WEBHOOK_URL=https://n8n.votre-domaine.fr

HTTPS avec Caddy

Caddy est recommandé pour sa gestion automatique des certificats Let's Encrypt. Le fichier Caddyfile se résume à trois lignes par service : le nom de domaine, la directive reverse_proxy vers le service interne, et optionnellement basicauth pour les services sans authentification native.

Backup et monitoring

• Backup modèles : les modèles Ollama sont dans le volume ollama-models. Un script cron quotidien vers S3/MinIO suffit (les modèles changent rarement).
• Backup conversations : le volume open-webui contient une base SQLite — sauvegarde quotidienne recommandée.
• Monitoring : Ollama expose des métriques Prometheus sur /metrics. Grafana + un dashboard "Ollama Performance" permet de surveiller la latence, le débit et l'utilisation GPU.

Intégration dans vos workflows

Un LLM local n'est utile que s'il s'intègre dans vos outils existants. Voici les patterns d'intégration les plus courants :

N8N → Ollama (nœud HTTP Request)

Dans N8N, ajoutez un nœud HTTP Request configuré ainsi :

• Method : POST
• URL : http://ollama:11434/v1/chat/completions (si N8N et Ollama sont sur le même réseau Docker)
• Body : JSON avec model, messages et les paramètres de génération
• Headers : Content-Type: application/json

Depuis N8N 1.40, un nœud Ollama natif est disponible — configurez simplement les credentials (URL + port) et choisissez le modèle dans la liste déroulante.

Make.com → Ollama (webhook)

Make.com peut appeler votre Ollama via un module HTTP Make a Request. Votre Ollama doit être accessible depuis internet (via votre reverse proxy HTTPS). Ajoutez une authentification Bearer token pour sécuriser l'endpoint.

Python (bibliothèque officielle)

import ollama

response = ollama.chat(
    model='mistral',
    messages=[
        {'role': 'user', 'content': 'Résume ce document : ...'}
    ]
)
print(response['message']['content'])

La bibliothèque Python officielle (pip install ollama) supporte le streaming, les embeddings, la gestion des modèles et le function calling.

Application web (JavaScript)

const response = await fetch('http://localhost:11434/v1/chat/completions', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    model: 'mistral',
    messages: [{ role: 'user', content: prompt }],
    stream: false
  })
});
const data = await response.json();
console.log(data.choices[0].message.content);

Cas d'usage : chatbot documentaire interne sans cloud

Voici un exemple d'architecture complète pour un chatbot sur documents internes, zéro cloud :

1. Ingestion : vos documents (PDF, Word, emails) sont découpés en chunks et vectorisés via ollama embeddings (modèle nomic-embed-text).
2. Stockage vecteurs : ChromaDB (Docker local) stocke les embeddings avec les métadonnées associées.
3. Requête RAG : la question utilisateur est vectorisée → ChromaDB retourne les 5 chunks les plus proches → ils sont injectés dans le prompt avec la question.
4. Génération : Ollama (Llama 70B ou Mistral) génère une réponse fondée uniquement sur les passages pertinents.
5. Interface : Open WebUI avec le RAG activé, ou une interface custom via l'API.

RGPD et conformité : ce que le LLM local change concrètement

Ce que vous éliminez avec un LLM local

Avec un LLM déployé sur votre infrastructure, plusieurs obligations RGPD disparaissent ou se simplifient considérablement :

• Aucun transfert vers pays tiers (article 44-49 RGPD) : les données ne quittent jamais votre infrastructure. L'article 46 (garanties appropriées pour les transferts) est inapplicable — il n'y a pas de transfert.
• Pas de sous-traitant IA à référencer : OpenAI, Anthropic, Google sont des sous-traitants au sens du RGPD si vous leur envoyez des données personnelles. Avec un LLM local, il n'y a aucun sous-traitant IA — pas de DPA (Data Processing Agreement) nécessaire.
• DPIA simplifiée : l'analyse d'impact sur la protection des données (DPIA, obligatoire pour les traitements à risque élevé) est allégée — le risque de transfert hors UE et de fuite chez un tiers est supprimé.
• Cloud Act inapplicable : aucune entreprise américaine n'héberge vos données, donc le Cloud Act (qui permet aux autorités US d'exiger l'accès aux données hébergées par des entreprises américaines) ne s'applique pas à votre traitement IA.

Ce qu'il reste à gérer

Checklist conformité RGPD — LLM local

• Infrastructure hébergée en France ou UE (votre datacenter ou VPS Hetzner/OVH/Scaleway)
• Aucun appel API vers des services américains pour le traitement IA
• Chiffrement des disques contenant les modèles et les conversations
• Authentification obligatoire sur Open WebUI (comptes nominatifs, pas de compte générique)
• Journalisation des connexions et requêtes conservée 12 mois
• Processus de suppression des conversations sur demande utilisateur
• Registre des traitements mis à jour avec le traitement "Assistant IA interne"
• Politique d'utilisation acceptable communiquée aux utilisateurs
• Plan de sauvegarde et de restauration testé trimestriellement
• Mises à jour de sécurité appliquées (Ollama, Open WebUI, OS) dans les 30 jours