Guide technique · 12 min de lecture

Déployer un LLM on-premise.
Architecture, GPU, sécurité.

Quand basculer du cloud propriétaire vers une infra LLM on-premise, comment choisir entre H100, H200 et MI300X, quel runtime utiliser, comment monitorer, et combien ça coûte vraiment sur 3 ans. Retour terrain Validix sur les 12 derniers déploiements.

Auditer ma configurationCalculer le TCO⌘ Mise à jour mai 2026

Déployer un LLM on-premise n'a rien d'exotique en 2026. Les modèles open-weight (Hermes 4, Qwen 3, Llama 3.3, Mistral Large 2) ont rattrapé GPT-4 sur la majorité des tâches métier. Le hardware GPU est disponible, vLLM est mature, l'observabilité OpenTelemetry standardisée. Et pour les secteurs sensibles (banque privée, santé, OIV, défense), c'est devenu la seule architecture qui passe l'audit RSSI.

Ce guide synthétise notre retour terrain Validix sur 12 déploiements LLM on-premise réalisés depuis 2024. Il couvre quand basculer (et quand ne pas), comment choisir le hardware, quel runtime utiliser, comment monitorer, et combien ça coûte vraiment sur 3 ans. Pas de copy marketing. Des chiffres, des retours d'expérience, des arbitrages explicites.

Le on-premise est-il pertinent pour vous ?

Trois critères de bascule. Si vous cochez les trois, on-prem dédié. Si vous cochez deux, cloud souverain géré. Si vous cochez un ou zéro, restez sur le cloud propriétaire.

Critère 01 — Data

Sensibilité réglementaire

Vos données sont soumises à RIN (banque), FINMA (Suisse), HDS (santé), LPM (OIV) ou secret professionnel. Dans ces cas, le DPA d'OpenAI ne suffit pas — vous devez prouver que la donnée n'a jamais quitté votre périmètre.

Critère 02 — Volume

Volumétrie soutenue

Vous avez plus de 5 millions de tokens/jour soutenus, ou plus de 200 utilisateurs intensifs. À ce niveau, le break-even cloud-vers-on-prem se franchit autour du 14e mois. En dessous, le cloud est moins cher.

Critère 03 — Lock-in

Indépendance stratégique

L'IA fait partie de votre cœur de métier (pas un outil de productivité périphérique) et vous refusez d'en confier le pilotage à un fournisseur tiers — surtout américain soumis au CLOUD Act.

Trois couches indépendantes.

Chaque couche est pilotable et remplaçable. Les modèles évoluent vite, l'orchestration est stable, les outils suivent les besoins métier.

Couche 01 — Modèles

Inférence sur GPU dédié

Runtime vLLM (recommandé 2026), TGI (HuggingFace), TensorRT-LLM (perf max NVIDIA), ou llama.cpp (edge). Modèle quantizé Q4_K_M pour minimiser la VRAM, ou FP8/BF16 pour les serveurs costauds.

Couche 02 — Orchestration

Multi-tenant et observabilité

Praeon ou un orchestrateur custom. RBAC par tenant, traces OpenTelemetry, kill-switch par API, sandbox d'exécution code. Conteneurisé Docker + Traefik, rollback en 30 secondes.

Couche 03 — Outils

Connecteurs MCP

Model Context Protocol pour connecter M365, Salesforce, ERP, etc. Wrappers MCP custom pour les API maison. Sandbox Python/JS pour les actions à risque.

Sous-couche — Stockage

Vectoriel + objet

pgvector ou Qdrant pour le RAG, MinIO ou Ceph pour les artefacts. Stockage chez le client. Chiffrement au repos AES-256.

Comparatif GPU 2026.

Trois cartes pertinentes en 2026 selon votre budget, votre exigence de perf et votre tolérance à l'écosystème NVIDIA-only.

GPU
NVIDIA H100
NVIDIA H200
AMD MI300X
VRAM
80 GB HBM3
141 GB HBM3e
192 GB HBM3
FP8 Tensor TFLOPS
1979
1979
1307
Bande passante mémoire
3.35 TB/s
4.8 TB/s
5.3 TB/s
Modèles 70B FP8
1 carte (just enough)
1 carte (confortable)
1 carte (confortable)
Prix marché 2026 (achat)
~tarif marché 2026
~tarif marché 2026
~tarif marché 2026
Disponibilité France
Très bonne (OVH, Scaleway, Atos)
Bonne
Moyenne (en croissance)
Écosystème
CUDA, mature
CUDA, mature
ROCm, en rattrapage

Quel GPU pour quel modèle.

Empreinte mémoire pour les principaux modèles open-weight, en quantization Q4_K_M (recommandé pour la prod : 90 % de la qualité, 25 % de la VRAM).

Modèle
VRAM Q4
VRAM FP8
Throughput vLLM
Llama 3.3 70B
~38 GB (1× H100)
~70 GB (1× H100 limite)
~80 tok/s par utilisateur
Qwen 3 72B (MoE)
~32 GB (1× H100)
~58 GB (1× H100)
~110 tok/s
Mistral Large 2 (123B)
~70 GB (1× H100 limite)
~125 GB (2× H100)
~60 tok/s
Hermes 4 70B
~38 GB (1× H100)
~70 GB (1× H100 limite)
~85 tok/s
Codestral 22B
~12 GB (1× L40S OK)
~24 GB (1× H100 large marge)
~200 tok/s

Le runtime fait la perf.

Quatre options sérieuses en 2026. Notre choix par défaut : vLLM. Détail des arbitrages.

Recommandé · vLLM

Le choix par défaut 2026

PagedAttention, OpenAI-compatible API, support continu batching, vision incluse. Maintenu activement, communauté large. docs.vllm.ai

Solide · TGI

HuggingFace Text Generation Inference

Robuste, bien intégré dans l'écosystème HF, support de tous les modèles publiés sur le Hub. Légèrement moins performant que vLLM en 2026 mais opérationnellement plus simple si vous êtes déjà dans HF.

Niche · TensorRT-LLM

Perf max NVIDIA-only

Compilation TensorRT pour des perfs maximales sur GPU NVIDIA. Complexité opérationnelle élevée (recompile par modèle, par version). À réserver aux cas où la latence est critique.

Edge · llama.cpp

Pour les petits déploiements

Excellent sur CPU, GPU consumer, Apple Silicon. Pour des modèles 7B-13B sur poste de travail ou edge embarqué. Pas pour la prod multi-tenant.

Tracer chaque pas d'agent.

Sans observabilité, un déploiement LLM en prod est un trou noir. Trois piliers : tracing fin (Langfuse, Phoenix), métriques infra (Prometheus + Grafana), logs structurés (ELK, Loki).

PILIER 01 — TRACING APPLICATIF

Chaque appel d'agent loggé : prompt complet, output, tokens consommés, durée, modèle, tool calls. Langfuse est notre choix par défaut (self-hostable, open-source, UI propre). Alternative : Phoenix Arize. Les traces sortent en standard OpenTelemetry GenAI semconv.

PILIER 02 — MÉTRIQUES INFRA

Utilisation GPU (DCGM exporter pour NVIDIA, ROCm SMI pour AMD), mémoire VRAM, queue de requêtes vLLM, latence p50/p95/p99 par modèle. Stack standard : Prometheus + Grafana + alertmanager. Templates Grafana publics fournis par vLLM.

PILIER 03 — LOGS

Logs structurés JSON. Centralisés via Loki (recommandé) ou Elastic. Conservation : 90 jours minimum pour audit RGPD, 1 an pour les agents en banque ou santé. Champ tenant_id obligatoire pour le filtrage et la conformité multi-tenant.

Cinq couches de sécurité minimum.

On-premise ne veut pas dire sécurisé par défaut. Cinq couches doivent être en place avant le go-live, surtout pour les secteurs réglementés.

Couche 01

Data residency stricte

Toutes les données restent dans votre périmètre. Aucune télémétrie outbound vers les fournisseurs de modèles (HuggingFace, Resend, OpenAI). Vérification par tcpdump avant go-live. Voir guide RGPD.

Couche 02

Authentification forte

SSO via OIDC ou SAML. MFA obligatoire pour les tenants "sensibles". Tokens API courts (15 min max), rotation automatique. RBAC par tenant strictement appliqué.

Couche 03

Sandbox d'exécution

Pour les agents qui exécutent du code (Python, JS), gVisor ou Firecracker. Pas d'accès au filesystem hôte, pas de réseau sortant non whitelisté, pas de processus persistant entre invocations.

Couche 04

Red-teaming des prompts

Application systématique du OWASP LLM Top 10 avant go-live. Tests d'injection de prompts, exfiltration via tool calls, jailbreaks. Suite de 100+ tests automatisés à passer.

Couche 05

Air-gap si nécessaire

Pour les OIV/LPM, secret défense, ou banques privées les plus strictes : aucune connectivité internet sortante. Updates des modèles via supports physiques contrôlés. Détail air-gap.

Couche 06 — bonus

Audit annuel

Pen-test externe annuel, audit de code, revue de logs. Pour les Entités Essentielles au sens NIS2, c'est obligatoire — pour les autres, c'est juste sain. Voir NIS2.

Combien ça coûte, vraiment.

Trois cas d'usage représentatifs. Tous les chiffres en € HT, hors RH (à ajouter selon votre équipe).

Cas A — startup 50 collaborateurs, usage léger
Cloud propriétaire (ChatGPT Enterprise) : ~36 K€/an. On-prem : irrationnel à ce volume. Verdict : restez cloud.
Cas B — ETI 500 collab, usage intensif
Cloud propriétaire : budget significatif. On-prem dédié : investissement initial dimensionné année 1 (matériel + setup), puis récurrent maîtrisé (énergie, ops, support). Break-even : 14 mois. Économie cumulée 3 ans : ~économie cumulée significative.
Cas C — banque privée, données sensibles
Cloud propriétaire : non envisageable (RIN, secret professionnel). On-prem dédié : ~150 K€ année 1, ~55 K€/an ensuite. Cloud souverain géré (OVH, Scaleway) : ~95 K€/an. Verdict : cloud souverain ou on-prem selon volumétrie.
Composantes coût on-prem
Hardware GPU (budget important), serveurs (10-30 K€), réseau et alim (10 K€), licences support NVIDIA/AMD (10-20 K€/an), énergie (~10 K€/an pour 2× H100 24/7), MLOps interne ou prestataire (1 ETP partagé minimum).
Composantes coût cloud
ChatGPT Enterprise : 60 €/utilisateur/mois (≈ tous les coûts inclus). Azure OpenAI : à la consommation, ~3-15 €/M tokens selon modèle. Bedrock : similaire à Azure. Mistral La Plateforme : ~2-8 €/M tokens, plus simple sur le RGPD.

Trois patterns selon votre cible.

Pattern 01

On-prem dédié

Votre datacenter, vos GPU. Air-gap possible. Maîtrise totale, coût initial élevé. Pour banques privées, OIV, défense, santé HDS sensible. Délai déploiement : 8-14 semaines selon hardware.

Pattern 02

Cloud souverain géré

OVHcloud, Scaleway, Outscale, Infomaniak. Multi-tenant chez l'opérateur français mais hébergement EU strict. RGPD natif. Pour 80 % des cas ETI. Délai : 2-4 semaines.

Pattern 03

Hybride

Modèles et données chez le client, orchestration mutualisée chez Validix ou un opérateur. Bon compromis coût/contrôle pour les ETI en croissance. Délai : 4-6 semaines.

Faut-il vraiment déployer en on-premise ou un cloud souverain suffit ?
Cloud souverain (OVH, Scaleway, Outscale, Infomaniak) suffit dans 80 % des cas RGPD. On-prem dédié est nécessaire pour : air-gap secret défense, contraintes RIN/FINMA, ou volumétrie où le break-even cloud-to-prem est franchi (typiquement plus de 5 millions de tokens/jour soutenu).
Combien coûte un setup on-prem minimum pour Llama 3.3 70B ?
2× H100 80 GB ≈ 50-sur devis en achat (2026), ou tarif marché/mois en location. Plus serveur (10 K€), réseau, alimentation, refroidissement, support 3 ans : compter budget infrastructure dimensionné all-in la première année. Année 2 et 3 : ~25 K€/an.
Quel runtime LLM choisir en 2026 ?
vLLM par défaut. TGI si vous êtes déjà dans l'écosystème HuggingFace. TensorRT-LLM seulement si la perf max compense la complexité d'opération (rare). llama.cpp pour l'edge ou les petits modèles.
L'air-gap est-il vraiment nécessaire pour la santé (HDS) ?
Pas forcément. HDS impose certifications hébergeur + chiffrement. Air-gap (zéro port externe) est une couche supplémentaire, parfois exigée par les hôpitaux militaires ou des données ultra-sensibles. La majorité des hôpitaux civils restent sur cloud souverain HDS-certifié.
Comment monitorer les hallucinations en prod ?
Tracing fin (Langfuse + OpenTelemetry), évaluation continue sur un dataset doré (200-500 questions de référence), rapports de confiance par output, escalade humaine sur seuil. La matrice de menaces OWASP LLM Top 10 couvre les principaux risques.
Peut-on faire du fine-tuning on-prem ou faut-il du cloud ?
Fine-tuning LoRA/QLoRA possible sur 1× H100 pour 70B. Full fine-tuning 70B nécessite typiquement 8× H100 — souvent loué chez OVH, Scaleway, ou en GPU-cloud à la demande. Pour la majorité des cas, LoRA suffit (qualité 90-95 % du full fine-tuning, coût 5 %).