Sécurité IA

Local LLM (Llama, Mistral self-hosted) : sécurité opérationnelle

Auto-héberger un LLM (Llama 3, Mistral, Qwen) répond aux exigences de souveraineté et de confidentialité. Mais ce n'est pas "plus sûr par défaut". Voici les vrais risques et la posture opérationnelle.

Aroua Biri 8 min

L'auto-hébergement d'un LLM open source (Llama 3, Mistral, Qwen, DeepSeek, Falcon) est devenu en 2025-2026 une option accessible techniquement et économiquement. Pour des raisons de souveraineté, de confidentialité, de latence ou de coût, beaucoup de SaaS européens basculent leur inférence chez eux plutôt que sur l'API d'un fournisseur. Mais "self-hosted" ≠ "plus sécurisé par défaut". Voici la posture sécurité opérationnelle réaliste.

Pourquoi self-host en 2026

Quatre raisons principales :

  1. Souveraineté : les données ne sortent pas de votre infrastructure. Critique pour HDS, secret bancaire, secret industriel.
  2. Confidentialité : pas de risque de fine-tuning involontaire chez un tiers, pas de DPA tiers.
  3. Coût à l'échelle : à partir de 5-10 millions de requêtes/mois, le self-host devient moins cher que les API.
  4. Latence : pas de round-trip vers un fournisseur cloud distant.

Mais aussi :

  • Customisation : fine-tuning sur vos données.
  • Indépendance : pas de breakage par changement d'API du fournisseur.

Les vraies surfaces d'attaque

Ne pas envoyer ses données à OpenAI ou Anthropic ne supprime pas les risques — ça les déplace.

1. Provenance du modèle

Vous téléchargez un modèle de Hugging Face. Êtes-vous sûr que c'est bien le modèle officiel, et pas une version backdoorée ?

Risques connus :

  • Modèles compromis : reportés en 2024-2025 (faux Llama avec malware en pickle).
  • Fine-tunes malveillants : un modèle communautaire qui semble bon mais a été entraîné pour leak des données.
  • Désérialisation pickle : format historique du PyTorch, exécution de code arbitraire au load.

Contre-mesures :

  • Télécharger uniquement depuis les repos officiels (Meta, Mistral AI, Anthropic, etc. — pas les "community fine-tunes" sans validation).
  • Vérifier les hash SHA256 publiés par l'éditeur.
  • Préférer les formats safetensors au pickle.
  • Utiliser des outils comme ModelScan pour analyser le modèle avant déploiement.

2. Sécurité de l'infrastructure d'inférence

L'inférence tourne typiquement sur :

  • vLLM : framework d'inférence haute performance.
  • TGI (Text Generation Inference) : framework Hugging Face.
  • Ollama : pour développement local.
  • TensorRT-LLM : NVIDIA, pour les déploiements GPU intensifs.

Surfaces classiques :

  • CVE dans le framework : vLLM, TGI ont eu des CVE en 2024-2025. Maintenir à jour.
  • Endpoint API exposé : par défaut, ces frameworks ne demandent pas d'authentification. À ajouter via reverse proxy ou middleware.
  • Resource exhaustion : un prompt très long ou une boucle infinie peut saturer le GPU.

3. Prompt injection (encore)

Un LLM self-hosted reste vulnérable aux attaques de prompt injection. La couche de défense (input filter, output filter) reste à votre charge — voir Constitutional AI vs guardrails.

Note : les modèles open source ont moins de Constitutional AI baked-in. La défense par classifieur est plus importante en self-host.

4. Données d'entraînement et conformité

Si vous fine-tunez sur vos données :

  • Risque de mémorisation : le modèle peut régénérer du PII présent dans le training. Tests de membership inference recommandés.
  • Conformité RGPD : si données personnelles dans le training, le droit à l'effacement devient compliqué (re-fine-tuner sans la donnée = lourd).
  • Provenance : qui a accès aux données d'entraînement, comment sont-elles stockées, qui a poussé le modèle final ?

5. Sécurité des poids du modèle

Vos poids fine-tunés sont un actif stratégique. Un attaquant qui les exfiltre peut :

  • Reverse-engineer vos données d'entraînement (model inversion attacks).
  • Reproduire votre service ailleurs.
  • Identifier des vulnérabilités spécifiques à votre fine-tune.

Contre-mesures : restriction d'accès au stockage des modèles (S3 bucket privé, KMS), pas de download non audité, logs d'accès.

Posture opérationnelle minimale

Architecture

`` [Application] ↓ [Reverse proxy + Auth + Rate limit] ↓ [Pre-filter classifieur] ↓ [Inference server (vLLM/TGI)] ← isolé en réseau, modèle vérifié ↓ [Post-filter classifieur] ↓ [Logs forensiques] ``

Provenance

  • Liste whitelist des modèles autorisés (par hash).
  • Pipeline de validation avant déploiement : scan, test fonctionnel, test sécurité.
  • Modèles signés Sigstore quand l'éditeur le permet (Mistral le fait depuis 2025).

Inférence

  • Frameworks à jour (vLLM ≥ 0.6, TGI ≥ 3.0 en 2026).
  • Pas d'endpoint admin exposé.
  • TLS sur toute communication.
  • Quotas par client/user.

Monitoring

  • Métriques GPU (utilisation, mémoire, queue).
  • Logs structurés des requêtes (sans contenu sensible).
  • Alerting sur patterns suspects (volumes anormaux, prompts pathologiques).

Secrets

  • Pas de credentials de fine-tuning data dans les images Docker.
  • Pas de keys API tiers dans l'environnement d'inférence.

Le piège : "open source = sécurisé"

Faux. Les modèles open source sont auditables (vous pouvez voir leurs poids), mais ils ne sont pas par défaut plus sécurisés que des modèles propriétaires. Au contraire :

  • Moins d'investissement en alignement chez les éditeurs open source.
  • Pas de mises à jour automatiques de safety.
  • Pas de monitoring centralisé des abus.

Self-host nécessite plus de travail sécurité, pas moins.

Quand ne pas self-hoster

  • Faible volume (< 1M requêtes/mois) : l'API est presque toujours moins chère et plus simple.
  • Pas de souveraineté requise : si vos clients acceptent les API hyperscalers, pas la peine.
  • Pas de compétences MLOps interne : self-host demande des skills GPU, networking, MLOps. Sous-traiter ou former.

Articulation avec les fournisseurs cloud

Pour beaucoup d'organisations, le bon mix en 2026 est hybride :

  • API Claude/OpenAI/Mistral pour les usages non-sensibles (UX produit, génération de contenu non confidentiel).
  • Self-host Llama/Mistral pour les usages sensibles (données client, fine-tune privé).

Ce mix permet d'avoir le meilleur de chaque approche sans payer le coût total du self-host complet.

ROI réel

Pour une scale-up faisant 50 millions de tokens/jour :

  • API Claude/OpenAI : ~30-100 k€/mois selon mix de modèles.
  • Self-host (8x H100, ops, monitoring) : ~25-40 k€/mois (CapEx amorti + OpEx).

Le break-even est entre 30 et 100 millions de tokens/jour. En dessous : API. Au-dessus : self-host devient avantageux financièrement.

Mais le ROI ne se résume pas au coût direct. La conformité, la confidentialité, et le contrôle sont des bénéfices non chiffrables qui peuvent décider seuls.

Un sujet connexe chez vous ?

20 minutes pour cadrer ensemble. Aucune offre commerciale envoyée à froid.

Réserver un échange Calendly