Réponse directe. En 2026, plusieurs modèles open-weight permettent un déploiement entièrement déconnecté d'Internet (air-gapped) avec une qualité proche des frontière fermés pour de nombreux usages : Llama 3.3, Qwen 3, Mistral, DeepSeek, Phi. Les prérequis matériels vont d'un seul GPU H100 80 Go (modèles 27-70B en INT4) à des configurations 8× GPU H100/H200 (modèles 600B+ comme DeepSeek R1 complet).
Ce guide donne les modèles éligibles, les ordres de grandeur VRAM par modèle, les configurations GPU recommandées par profil de besoin, et la stack logicielle pour servir tout ça sans dépendre du réseau public. Il s'adresse aux DSI et CTO qui évaluent un projet IA souverain ou réglementé.
Air-gapped : qu'est-ce que ça veut vraiment dire
Air-gap signifie que le système hôte n'a aucune connectivité réseau avec Internet (et souvent avec le reste du système d'information). Pas de pull dynamique de modèles depuis Hugging Face, pas de télémétrie, pas de mises à jour automatiques, pas d'API distante.
Différence avec un simple on-premise : un on-premise classique peut avoir un accès Internet contrôlé (proxy, allowlist). Un air-gap exclut tout flux entrant et sortant. Ce qui implique :
- Apporter physiquement les artefacts (modèles, mises à jour, données) sur un support contrôlé.
- Faire tourner localement tout ce qui est nécessaire (registry de modèles, serveur d'inférence, monitoring).
- Renoncer à certaines fonctionnalités cloud (recherche web temps réel, plugins externes, télémétrie éditeur).
Pourquoi déployer une IA air-gappée
Les cas d'usage réels sont précis :
- Défense et souveraineté : environnements classifiés où aucune fuite n'est tolérable.
- Santé et données patients : exploitation de dossiers médicaux sous contrainte HDS, sans risque d'exfiltration.
- Finance et données réglementées : analyse de positions, KYC, lutte anti-fraude sur données ultra-sensibles.
- Secrets industriels et R&D : exploitation de brevets, plans, formules — où une fuite a un coût stratégique majeur.
- Sous-traitants publics : exigences contractuelles d'isolation réseau.
Pour les cas où l'air-gap n'est pas obligatoire mais où la souveraineté et la maîtrise des coûts à fort volume sont les motivations, voir notre article sur l'on-premise et l'indépendance fournisseurs.
Quels modèles peut-on déployer en air-gap
La règle simple : seuls les modèles open-weight peuvent être déployés en air-gap. Les modèles propriétaires (Claude, GPT, Gemini) ne sont accessibles que via API, donc exclus.
Les familles open-weight de référence en 2026 :
- Llama (Meta) — large catalogue 1B / 8B / 70B / 405B. Référence pour l'auto-hébergement, écosystème très mature.
- Qwen (Alibaba) — 7B / 27B / 72B et variantes spécialisées. Excellent multilingue et raisonnement.
- Mistral — Mistral Small / Medium 3.5, Mixtral. Champion européen, fort en français, choix naturel sous contraintes UE.
- DeepSeek — R1, V3 et descendants. Très bon rapport raisonnement/coût ; les plus gros (R1 complet ≈ 671B) demandent une infrastructure conséquente.
- Phi (Microsoft) — petits modèles (3-15B) au rapport qualité/taille exceptionnel pour des tâches cadrées.
- Gemma (Google) — modèles ouverts dérivés de la recherche Gemini, 2B / 9B / 27B.
Vérification critique avant déploiement : lire la licence. La plupart sont permissives (Apache 2.0, MIT) mais Llama a sa propre licence avec quelques restrictions à connaître (plafond utilisateurs, attribution).
Combien de VRAM pour quel modèle (formules + tableau)
La VRAM nécessaire dépend directement de la taille du modèle et de la précision de quantization choisie :
- FP16 (précision « pleine ») : 2 octets par paramètre. Modèle 70B ≈ 140 Go.
- INT8 : 1 octet par paramètre. Modèle 70B ≈ 70 Go.
- INT4 (Q4) : 0,5 octet par paramètre. Modèle 70B ≈ 35 Go.
À cela s'ajoutent 10 à 20 % de surcoût (KV cache, activations, framework). En pratique, l'INT4 (Q4_K_M et variantes via GGUF/AWQ) offre le meilleur compromis qualité/VRAM pour la majorité des usages.
Ordres de grandeur 2026 (en INT4 sauf indication) :
- Phi 3-15B : 2-8 Go → tient sur un GPU consommateur (RTX 4090).
- Llama 8B / Qwen 7B / Gemma 9B : 4-6 Go → RTX 4090 ou A10.
- Qwen 27B / Gemma 27B / Mistral Small 3 : ~15 Go → un GPU pro (A100 40 Go, H100 80 Go en confort).
- Llama 70B / Qwen 72B : ~35-40 Go en INT4 → un seul H100 80 Go suffit ; en FP16 il en faut deux.
- Mistral Large 2 (123B) : ~62 Go en INT4 → un H100 80 Go.
- DeepSeek R1 / V3 (671B) : ~370 Go en Q4 → 4 à 8 GPU 80 Go.
- Kimi K2.5 (1T MoE, 32B actifs) : ~630 Go en INT4 → 8× H100 80 Go.
Pour les bons ordres de grandeur sur 180+ modèles, l'agrégateur willitrunai est une référence pratique (mais à recouper).
Configurations GPU recommandées par profil de besoin
Trois profils types couvrent 90 % des projets d'entreprise :
- POC ou usage interne léger (1 à 5 utilisateurs concurrents, modèles ≤ 30B) : 1× NVIDIA A100 40-80 Go ou 1× H100 80 Go. Permet de servir un Qwen 27B ou un Mistral Small 3 confortablement.
- Production PME/ETI (10 à 100 utilisateurs, modèles 70B en INT4) : 1× H100 80 Go ou 1× H200 141 Go (plus de marge pour le contexte long et la concurrence). Sert un Llama 70B ou Qwen 72B.
- Production lourde / modèles XXL (DeepSeek R1 complet, MoE 1T) : 8× H100/H200 80 Go avec interconnect NVLink. Investissement matériel significatif (plusieurs centaines de k€), à réserver aux besoins vraiment justifiés.
Notre conseil pragmatique chez Genee : commencer par un seul GPU H100 et un modèle 27-72B en INT4. C'est suffisant pour 95 % des cas d'usage PME/ETI, et le coût total (matériel + intégration) reste inférieur au cumul des dépenses API sur 18 mois pour les fortes consommations.
Stack logicielle pour servir en air-gap
Trois serveurs d'inférence dominent 2026 pour les déploiements sérieux :
- vLLM — référence pour la production : haut débit (continuous batching), gestion du KV cache, OpenAI-compatible API. Largement adopté côté grandes entreprises.
- Ollama — orienté simplicité, parfait pour POC et stations individuelles, supporte les modèles GGUF (quantizations).
- Text Generation Inference (TGI) de Hugging Face — bien adapté aux environnements Kubernetes.
Tous fonctionnent sans Internet une fois les modèles téléchargés. La couche au-dessus (API gateway, routing, observabilité, RAG) se construit comme n'importe quelle stack moderne : Python/FastAPI ou NestJS, vector DB locale (Qdrant, Weaviate, ou PostgreSQL + pgvector), monitoring Prometheus + Grafana.
Le reste de l'infra (miroir, supervision, mises à jour)
Un projet air-gap réussi traite tout le cycle, pas seulement l'inférence :
- Miroir local Hugging Face : récupérer les modèles dans une zone de transit, scanner, puis injecter dans la zone air-gap (support physique ou diode unidirectionnelle).
- Registry interne (Harbor, Nexus, ou similaire) pour stocker les modèles versionnés et les images Docker.
- Observabilité offline : stack Prometheus + Loki + Grafana entièrement hébergée en zone air-gap, sans télémétrie sortante.
- Mises à jour : process documenté pour rejouer la chaîne (récupération modèle → scan → import → test → bascule). Une fois par trimestre est un bon rythme pour la plupart des projets.
- Évaluations : suite d'évals de non-régression exécutée à chaque mise à jour pour valider la qualité sur vos cas d'usage.
Limites et arbitrages
L'air-gap a un coût qu'il faut accepter en connaissance de cause :
- Pas de modèles frontière propriétaires : Claude Opus, GPT-5.5, Gemini Ultra ne sont pas disponibles. L'écart de qualité avec les meilleurs open-weight (Llama 70B, Qwen 72B, DeepSeek R1) se réduit chaque trimestre, mais existe encore sur certaines tâches.
- Multimodal limité : la génération d'images/vidéo ou la compréhension fine d'images depuis modèles open est moins mature que côté Gemini Omni ou GPT.
- CAPEX significatif : un H100 coûte 25 à 35 k€, un cluster 8× H200 plusieurs centaines de k€.
- Compétence MLOps : il faut une équipe (ou un partenaire) qui sache configurer vLLM, dimensionner, monitorer, mettre à jour. Sans cette compétence, l'inférence cloud reste plus simple.
- Pas de recherche web temps réel ni de plugins externes — par conception.
Pour la comparaison structurée des deux approches, voir notre comparatif cloud vs on-premise IA 2026.
FAQ — IA on-premise air-gapped en 2026 : quels modèles, quels GPU, quels prérequis
Peut-on déployer Claude ou GPT en air-gap ?
Non. Ce sont des modèles propriétaires accessibles uniquement via API. Pour de l'air-gap, il faut un modèle open-weight : Llama, Qwen, Mistral, DeepSeek, Phi ou Gemma.
Quel est le plus petit modèle utile pour de l'IA en entreprise ?
Pour des tâches cadrées (classification, extraction, résumé, RAG sur base limitée), un Phi 3-15B ou Llama 8B suffit largement et tient sur un GPU consommateur. Pour du raisonnement plus exigeant, viser 27B à 70B en INT4.
Faut-il un H100 ou un H200 ?
Pour la plupart des cas PME/ETI (modèles ≤ 70B en INT4), un H100 80 Go suffit. Le H200 (141 Go) apporte de la marge pour le contexte long et la concurrence — utile si vous prévoyez beaucoup d'utilisateurs simultanés ou des prompts très longs.
Combien coûte un déploiement on-premise air-gap ?
Hors équipe, comptez de 30-50 k€ matériel pour un POC (1× H100, serveur, stockage) à plusieurs centaines de k€ pour une plateforme multi-GPU. À comparer au cumul des dépenses API cloud sur 24-36 mois — souvent rentable au-dessus de ~500 M tokens/mois.
Comment maintenir un déploiement air-gap dans le temps ?
En définissant un process trimestriel : récupérer le nouveau modèle dans une zone de transit, le scanner, l'injecter en zone air-gap, lancer la suite d'évals, basculer si OK. Sans ce process, le système prend de plus en plus de retard sur l'état de l'art.
Peut-on faire du RAG en air-gap ?
Oui, c'est même un des cas d'usage les plus naturels. Toute la chaîne (embeddings, base vectorielle, retrieval, génération) tourne localement sur le même cluster. Voir notre article sur le RAG sécurisé entreprise pour les patterns.