Guide technique · OIV / défense / banque

Déployer un LLM
en air-gap.

Air-gap = zéro port externe, zéro télémétrie, zéro mise à jour distante automatique. Comment déployer un LLM dans un environnement isolé : architecture, mirror des dépendances, processus de mise à jour. Pour OIV, secret défense, banques privées hardcore.

Cadrer mon déploiement air-gap

Définition stricte.

Un système air-gap n'a aucune connectivité réseau vers internet. Aucun port sortant, aucune télémétrie, aucun pull de dépendances. Toutes les mises à jour se font par support physique contrôlé (clé USB, disque scellé) avec processus formel.

L'air-gap est une mesure de sécurité radicale. Elle est utilisée par : OIV (opérateurs d'importance vitale, listés par Premier Ministre), opérateurs LPM (Loi de Programmation Militaire), services classifiés Confidentiel Défense ou plus, certaines banques privées les plus strictes (en plus de FINMA), labos pharmaceutiques sur recherches sensibles.

Air-gap LLM est plus complexe qu'air-gap traditionnel. Un LLM a besoin de modèles (poids), de dépendances Python (50+ packages), d'une stack ML (CUDA, cuDNN, PyTorch), parfois de bases vectorielles, parfois de connecteurs MCP. Tout doit être mirroré en interne.

Quatre couches isolées.

Couche 01

Réseau isolé

VLAN dédié, aucune route vers internet. Firewall en sortie qui bloque tout (pas même DNS). Interfaces physiques distinctes pour la maintenance (KVM, IPMI sur réseau séparé).

Couche 02

Mirror des dépendances

Registry PyPI privée (devpi, JFrog), registry Docker privée (Harbor), mirror NVIDIA NGC. Maintenue à jour manuellement via supports physiques contrôlés à intervalles réguliers.

Couche 03

Modèles importés physiquement

Poids des modèles importés via clé USB chiffrée (LUKS), checksum vérifié, signature GPG validée. Stockés dans un répertoire en read-only, accessible uniquement aux services concernés.

Couche 04

Logs et observabilité internes

Tracing OpenTelemetry vers une stack interne (Langfuse self-hosted, Prometheus + Grafana). Aucun export vers les fournisseurs cloud (Datadog, Honeycomb) qui supposent une connexion internet.

Mises à jour : la partie la plus délicate.

Sans connectivité internet, toutes les mises à jour passent par un support physique contrôlé. Process formel obligatoire pour ne pas introduire de risque.

  1. Étape 01 — Préparation hors-zone. Téléchargement de la mise à jour (modèle, dépendance, patch sécurité) sur une machine connectée internet, dans un sas réseau isolé. Vérification des signatures cryptographiques, scan antivirus, audit de contenu.
  2. Étape 02 — Transport physique. Copie sur clé USB chiffrée LUKS, scellée. Transport par personnel habilité jusqu'à la zone air-gap. Aucun aller-retour.
  3. Étape 03 — Validation à l'entrée. Sas de réception : vérification physique de la clé, déchiffrement, vérification des checksums, validation par un opérateur habilité différent de celui qui a préparé.
  4. Étape 04 — Mise à jour environnement de test. Application sur un cluster de test (à l'intérieur de l'air-gap). Tests d'intégration, smoke tests. Délai 24-72h.
  5. Étape 05 — Promotion en prod. Si tests OK, application en prod avec rollback préparé. Logs détaillés. Validation par responsable.

Stack que Validix utilise en air-gap.

Runtime LLM
vLLM 0.6+ (paquets pip mirrorés sur registry interne)
Modèles
Hermes 4 70B et Mistral Large 2, importés physiquement, stockés en read-only
Orchestration
Praeon self-hosted, image Docker mirrorée
Observabilité
Langfuse + Grafana + Prometheus, tous self-hosted
GPU drivers
NVIDIA driver 550+, packages CUDA mirrorés
Alternative NVIDIA NIM
NVIDIA NIM supporte air-gap nativement (docs)
MCP servers
Tous self-hosted, sans appel externe
Combien de temps faut-il pour déployer un LLM en air-gap ?
12-18 semaines vs 4-6 pour un déploiement on-prem standard. Le surcoût est principalement dans la mise en place du process de mise à jour, le mirror des dépendances, et la validation par le RSSI. Validix accompagne ces déploiements en prestation longue (typiquement 80-150 K€).
Air-gap permet-il de mettre à jour le modèle ?
Oui mais via le process décrit (transport physique). Délai typique entre la sortie d'un nouveau modèle (Hermes 5 par exemple) et son passage en prod air-gap : 4-8 semaines. C'est plus lent qu'en on-prem connecté mais c'est par design.
Les API MCP fonctionnent-elles en air-gap ?
Oui pour les serveurs MCP qui correspondent à des systèmes internes (votre ERP, votre Confluence, votre LDAP). Non pour les serveurs MCP qui appellent des services externes (cloud-only). Inventaire à faire avant déploiement.
Pourquoi pas Ollama qui supporte l'air-gap ?
Ollama est très bien pour le développement individuel ou des déploiements légers. Pour de la prod multi-tenant avec observabilité, RBAC, kill-switch : vLLM + Praeon est plus robuste.
Quel coût hardware pour un cluster air-gap ?
Identique à un on-prem standard sur le hardware (~80-150 K€ pour 2× H100). Le surcoût est sur la sécurité physique : armoires verrouillées, KVM dédié, DLP, pen-test. Compter +30-50 K€ initial.