Architecture sécurisée pour déployer un LLM on-premise

Déployer un LLM on-premise est devenu en 2026 un choix stratégique pour les entreprises avec contraintes de souveraineté (RGPD, EU AI Act), confidentialité IP (code, contrats), conformité sectorielle (santé, défense, finance), ou volume justifiant l'auto-hébergement (>1M requêtes/jour). Cet article documente l'architecture de référence : stack technique (vLLM, TGI, TensorRT-LLM, K8s, Triton), 5 couches d'isolation (réseau, air-gap, GPU, identity, storage), gestion des secrets (Vault, KMS, rotation), supply chain des modèles (signature Sigstore, safetensors, SBOM ML, scan), observabilité GPU (DCGM, Prometheus), conformité (EU AI Act, NIST AI RMF, ISO 42001), avec ordres de grandeur d'investissement (POC à production large) et break-even vs API cloud. Cible : architectes IA / SRE / RSSI structurant un déploiement LLM enterprise interne, équipes sécurité validant les choix infra, décideurs arbitrant cloud vs on-prem.

Pour le threat model qui guide ces choix : threat modeling LLM avec STRIDE adapté. Pour l'architecture RAG sécurisée associée : architecture RAG sécurisée.

Pourquoi on-premise en 2026

Les 5 raisons stratégiques

Les 4 contre-arguments à prendre en compte

Le pattern dominant 2026 : hybride

                ┌────────────────────────────────────┐
                │     App LLM enterprise              │
                └──────────────┬─────────────────────┘
                               │
                ┌──────────────┴──────────────┐
                ▼                             ▼
       ┌─────────────────┐         ┌─────────────────┐
       │  On-premise      │         │  Cloud API      │
       │  Llama 3 / Mistral│        │  GPT-4o/Claude  │
       │                  │         │                  │
       │  Cas sensibles :  │         │  Cas génériques:│
       │  - PII clients    │         │  - assistance   │
       │  - Code R&D       │         │  - traduction   │
       │  - Contrats       │         │  - search       │
       │  - Données santé │         │  - tâches non-   │
       │                  │         │    sensibles    │
       └─────────────────┘         └─────────────────┘

Routing par classification automatique : un classifier décide quel modèle utiliser selon la sensibilité détectée du prompt.

Stack technique de référence

Inference engines

Modèles open-source 2026

Choix critère : qualité requise, RAM/VRAM disponible, license compatible cas d'usage commercial, langues supportées.

Orchestration

# Exemple K8s deployment vLLM avec NVIDIA GPUs
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama-3-70b
  namespace: llm-prod
spec:
  replicas: 4
  selector:
    matchLabels:
      app: vllm-llama-3-70b
  template:
    metadata:
      labels:
        app: vllm-llama-3-70b
    spec:
      nodeSelector:
        node.kubernetes.io/instance-type: gpu-h100-8x
      tolerations:
        - key: "nvidia.com/gpu"
          operator: "Exists"
      containers:
        - name: vllm
          image: vllm/vllm-openai:v0.6.4
          args:
            - "--model"
            - "/models/llama-3-70b"
            - "--tensor-parallel-size"
            - "8"
            - "--max-model-len"
            - "8192"
            - "--gpu-memory-utilization"
            - "0.95"
          ports:
            - containerPort: 8000
          resources:
            limits:
              nvidia.com/gpu: "8"
              memory: "256Gi"
              cpu: "32"
          volumeMounts:
            - name: models
              mountPath: /models
              readOnly: true
          env:
            - name: HF_HUB_OFFLINE
              value: "1"  # No outbound HF API call
      volumes:
        - name: models
          persistentVolumeClaim:
            claimName: model-weights-pvc

Architecture en 5 couches d'isolation

Couche 1, Network segmentation

                    ┌────────────────────────────┐
                    │  Corporate Network (10.0/8) │
                    └──────────────┬─────────────┘
                                   │
                       ┌───────────┼───────────┐
                       │           │           │
                       ▼           ▼           ▼
         ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
         │ App tier     │ │ DMZ          │ │ LLM tier     │
         │ 10.10.0.0/16 │ │ 10.20.0.0/16 │ │ 10.30.0.0/16 │
         │              │ │              │ │              │
         │ - Frontends  │ │ - WAF        │ │ - vLLM       │
         │ - APIs       │ │ - Reverse Pr │ │ - Triton     │
         │ - DBs std    │ │              │ │ - Vault GPU  │
         └──────┬───────┘ └──────────────┘ └──────────────┘
                │                                  ▲
                │   Firewall : tier app peut       │
                └─► appeler tier LLM uniquement    │
                    sur ports précis (gRPC 8000)   │
                    (pas l'inverse)                │

NetworkPolicies K8s :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: llm-tier-ingress
  namespace: llm-prod
spec:
  podSelector:
    matchLabels:
      tier: llm-inference
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              tier: app
      ports:
        - protocol: TCP
          port: 8000
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              tier: monitoring
      ports:
        - protocol: TCP
          port: 9090  # Prometheus scrape
    - to:
        - podSelector:
            matchLabels:
              app: model-storage
      ports:
        - protocol: TCP
          port: 9000  # MinIO / S3-compatible

Couche 2, Air-gap (optionnel haut risque)

Pour défense, santé critique, infra critique :

• Aucune route internet sortante
• Mises à jour modèles via media physique (DVD, support sécurisé) après scan AV/malware
• Patches OS via repo interne mirroré offline
• Logs SIEM en physical extract si SIEM externe

Coût opérationnel : +30-50% en charge équipe. Réservé cas extrêmes.

Couche 3, GPU isolation

Pas de mix workloads tiers et workloads sensibles sur mêmes GPUs.

# Node taints
kubectl taint node gpu-node-01 dedicated=llm-prod:NoSchedule
 
# Pod tolerations
spec:
  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "llm-prod"
      effect: "NoSchedule"

Multi-Instance GPU (MIG) sur H100 / A100 : partition matérielle d'un GPU physique en 7 instances isolées. Permet isolation entre tenants sans dédier 1 GPU complet par tenant. Latency overhead négligeable.

Confidential Computing (2026 émergent) : NVIDIA H100 supporte Trusted Execution Environment GPU. Combiné Intel TDX / AMD SEV-SNP côté CPU, permet exécution chiffrée, admin de l'host ne peut pas voir prompts/réponses en clair en mémoire.

Couche 4, Identity boundary

# ServiceAccount dédié pour vLLM, droits minimaux
apiVersion: v1
kind: ServiceAccount
metadata:
  name: vllm-sa
  namespace: llm-prod
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: vllm-role
  namespace: llm-prod
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["model-encryption-key"]  # only specific
    verbs: ["get"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: vllm-binding
  namespace: llm-prod
subjects:
  - kind: ServiceAccount
    name: vllm-sa
roleRef:
  kind: Role
  name: vllm-role
  apiGroup: rbac.authorization.k8s.io

Couche 5, Storage isolation

Modèles weights = actifs critiques (IP + safety). Storage chiffré :

# StorageClass avec encryption at rest
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: encrypted-llm-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  encrypted: "true"
  kmsKeyId: arn:aws:kms:eu-west-1:...:key/...

Modèle de menace storage :

• Vol disque physique → chiffrement at rest LUKS / KMS
• Compromission node → chiffrement + IAM strict + Confidential Computing
• Insider threat → audit logs accès + segregation duties

Gestion des secrets

Stack Vault + ESO

# External Secrets Operator avec HashiCorp Vault backend
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-backend
  namespace: llm-prod
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "secret"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "vllm-role"
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: model-encryption-secret
spec:
  secretStoreRef:
    kind: SecretStore
    name: vault-backend
  target:
    name: model-encryption-key
  data:
    - secretKey: key
      remoteRef:
        key: llm/encryption-keys
        property: model_aes_256
  refreshInterval: "1h"

Rotation automatique

Vault peut générer dynamiquement des credentials avec TTL court (1-24h). Pour les credentials API si bridge cloud :

path "openai/creds/llm-app-role" {
  capabilities = ["read"]
}

Modèles weights chiffrement

Pour modèles propriétaires fine-tunés :

# Chiffrer weights at rest avec KMS
sops --encrypt \
    --kms arn:aws:kms:eu-west-1:...:key/... \
    --input-type binary \
    model-weights.safetensors > model-weights.safetensors.enc
 
# Au déchiffrage, en mémoire seulement, pendant load

Performances : déchiffrement 70B model → 5-10s overhead au boot. Acceptable pour cold start.

Supply chain modèles

Signature et vérification

# 2026 standard émergent : Sigstore for ML / model-signing
import sigstore_model_signing as sms
 
# Au download
model_path = "/models/llama-3-70b"
signature_path = f"{model_path}.sig"
 
# Vérifier signature
verified = sms.verify(
    model_dir=model_path,
    signature_path=signature_path,
    expected_signer="meta@meta.com",  # Meta's Sigstore identity
)
 
if not verified:
    raise SecurityError("Model signature verification failed")

Format safetensors obligatoire

# JAMAIS charger pickled models depuis source non vérifiée
# .bin / .pt peuvent contenir code arbitraire (pickle exploit)
 
# safetensors = format sécurisé par design (data-only, no code)
from safetensors.torch import load_file
 
state_dict = load_file("/models/llama-3-70b/model.safetensors")

SBOM ML (Software Bill of Materials)

{
  "model_name": "internal-finetune-v2.1",
  "base_model": {
    "name": "meta-llama/Llama-3.1-70B-Instruct",
    "sha256": "0123456789abcdef...",
    "license": "Llama Community"
  },
  "finetuning": {
    "method": "LoRA",
    "datasets": [
      {
        "name": "internal-customer-support-v3",
        "size_examples": 50000,
        "pii_status": "redacted",
        "consent": "explicit"
      }
    ],
    "compute": "8x H100, 48h"
  },
  "tokenizer": "meta-llama/Llama-3.1-70B-Instruct",
  "evaluation": {
    "benchmarks": ["mmlu_5shot", "hellaswag", "internal_eval_v2"],
    "safety_eval": ["llm_guard_v3", "toxicity_real_v1"]
  },
  "training_carbon_kg_co2eq": 280
}

Permet traçabilité complète, conformité EU AI Act (transparence sur datasets training).

Backdoor detection

Modèles peuvent contenir backdoors via data poisoning training. Mitigation :

# Test comportemental sur corpus standard + adversarial
def test_for_backdoors(model, test_corpus):
    # 1. Test cohérence sur corpus standard
    standard_perf = evaluate(model, test_corpus["standard"])
    
    # 2. Test sur prompts variés contenant triggers potentiels
    # (rare tokens, séquences inhabituelles)
    backdoor_perf = evaluate(model, test_corpus["adversarial"])
    
    # 3. Si performance drop massivement sur certains triggers → suspect
    suspect_triggers = []
    for trigger, examples in test_corpus["triggers"].items():
        perf = evaluate(model, examples)
        if perf < standard_perf * 0.5:
            suspect_triggers.append(trigger)
    
    return {
        "standard_perf": standard_perf,
        "suspect_triggers": suspect_triggers,
        "verdict": "clean" if not suspect_triggers else "suspect",
    }

Observabilité GPU et application

Stack DCGM + Prometheus

# DCGM Exporter pour métriques GPU
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dcgm-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: dcgm-exporter
  template:
    metadata:
      labels:
        app: dcgm-exporter
    spec:
      nodeSelector:
        nvidia.com/gpu: "true"
      containers:
        - name: dcgm-exporter
          image: nvcr.io/nvidia/k8s/dcgm-exporter:3.3.0-3.2.0-ubuntu22.04
          ports:
            - containerPort: 9400
          securityContext:
            runAsNonRoot: false
            runAsUser: 0
            capabilities:
              add: ["SYS_ADMIN"]

Métriques GPU clés

Dashboards Grafana spécifiques

• GPU utilization heatmap par node × GPU
• VRAM consumption par modèle déployé
• Inference latency p50/p95/p99 par modèle
• Tokens/sec throughput par GPU
• Cost per inference (calculé : électricité + dépréciation hardware)

Conformité

EU AI Act (entrée en vigueur 2025-2027 progressif)

Pour systèmes haut risque (annex III) :

• Logging exhaustif (Art. 12), couvert par observabilité
• Documentation technique (Art. 11), SBOM ML + threat model
• Human oversight (Art. 14), design produit
• Accuracy / robustness (Art. 15), eval continue + red team
• Cybersecurity (Art. 15), toute cette architecture

On-premise facilite la conformité car contrôle complet de la stack.

NIST AI RMF (US, référence internationale)

Govern / Map / Measure / Manage. On-premise impacte :

• Govern 1.4 (responsabilités identités) → IAM K8s
• Map 1.1 (documentation système) → SBOM + DFD
• Measure 2.7 (cybersécurité) → cette architecture
• Manage 4.1 (gestion incident) → observabilité + SOC

ISO 42001 (AI Management System, 2023)

Standard ISO pour management des risques IA. On-premise facilite implémentation des contrôles techniques requis.

RGPD

Sur EU territory, on-premise dans datacenter EU + chiffrement = compliance facile. Cloud non-EU avec transfert = SCC + DPIA + complications post-Schrems II.

Investissement et break-even

Tiers d'investissement

POC / dev

• Hardware : 1× RTX 4090 24 GB ou L40S 48 GB (~3-10k€)
• OpEx : ~200€/mois (élec, host)
• Capacité : 10k-100k req/jour
• Modèles : 7-13B

Production small (HA)

• Hardware : 4-8× L40S ou 2-4× A100 80 GB (~50-200k€)
• OpEx : 2-5k€/mois
• Capacité : ~1M req/jour
• Modèles : 8-13B + small 70B

Production large (HA, multi-tenant)

• Hardware : 8-16× H100 / H200 (~500k-2M€)
• OpEx : 10-30k€/mois
• Capacité : ~10M req/jour
• Modèles : 70B+ avec tensor parallelism

Break-even vs API cloud

Coût OpenAI API (gpt-4o, prix 2026) :
  - 2.25 € / 1M tokens input
  - 9 € / 1M tokens output

Hypothèse : 1M req/jour, 1k tokens in + 500 tokens out moyens
   = 1B in + 500M out / jour
   = 2250 € + 4500 € = 6750 € / jour
   = 202.5k € / mois
   = 2.4M € / an

On-premise small production équivalent :
   ~ 180k € CapEx (3 ans) + 32.4k €/an OpEx
   = ~90k €/an

Économie : ~2.3M €/an = ratio 27×

À volume élevé, on-prem amortit en mois. À volume faible (< 100k req/jour), API cloud reste plus économique.

Ressources humaines

Total infra équipe : 2-4 ETP pour production sérieuse.

Erreurs courantes

Erreur 1, Mix workloads sur mêmes GPUs

Workloads sensibles + workloads tiers sur même GPU = side-channel risk. GPU isolation obligatoire.

Erreur 2, Modèles téléchargés depuis sources non officielles

Pickle exploits, backdoors. Hugging Face officiel + signature + safetensors.

Erreur 3, Pas de chiffrement modèles

Vol disque = leak IP. KMS at rest + Confidential Computing si haut risque.

Erreur 4, Air-gap sans plan operationnel

Air-gap théorique mais updates ad hoc = patches manqués, security drift. Plan opérationnel formel ou pas d'air-gap.

Erreur 5, Pas de SBOM ML

Audit EU AI Act demande traçabilité. Pas de SBOM = pas conformité. SBOM dès jour 1.

Erreur 6, Pas de monitoring GPU

Throttling thermique non détecté = latence anormale. DCGM + Prometheus obligatoire.

Ce que ça change pour votre dispositif

Une architecture LLM on-premise mature 2026 :

• Stack : K8s + vLLM/TGI + Llama 3 / Mistral + Triton + Vault + Prometheus + DCGM
• 5 couches isolation : réseau, air-gap optionnel, GPU, identity, storage
• Secrets via Vault + ESO + KMS systématique
• Supply chain : Sigstore, safetensors, SBOM ML, backdoor detection
• Observabilité : métriques GPU + métriques app + traces
• Conformité : EU AI Act + NIST AI RMF + ISO 42001 + RGPD facilités

ROI : break-even vs API cloud à ~500k€/an consommation. Indépendance souveraine + IP confidentielle + conformité simplifiée même au-dessous du break-even.

C'est l'architecture de référence pour les organisations qui placent la souveraineté et la confidentialité au cœur de leur stratégie IA. La complexité technique est réelle mais devient gérable avec les outils 2026 (vLLM, K8s ecosystem GPU mature).

Pour aller plus loin : la suite naturelle est l'architecture RAG sécurisée, où le LLM on-premise se combine avec un store vectoriel multi-tenant durci, et où les patterns d'isolation et d'audit s'étendent au pipeline retrieval. Sujet abordé dans une autre ressource du cluster défense.