IA en environnement isolé : comment les systèmes d’IA fonctionnent sans accès à Internet ni au cloud

L'IA en air gap est un système d'IA déployé à l'intérieur d'un domaine de sécurité qui n'a aucune connexion réseau physique avec les systèmes externes dont il est séparé, tout transfert au-delà de cette frontière étant effectué par des procédures délibérément contrôlées et non automatisées. Le modèle d'IA, le runtime, les données, les index de récupération, les outils et les dépendances opérationnelles nécessaires à l'inférence doivent donc être disponibles à l'intérieur de l'environnement isolé. L'IA en air gap n'est pas simplement « un modèle local » ou « un serveur sur site » : la propriété déterminante est la frontière réseau et de transfert autour du système complet.

Ce que signifie réellement l'IA en air gap

Le mot IA ne change pas le concept de sécurité de base. Un air gap est une frontière entre domaines de sécurité. L'IA rend simplement le côté isolé plus exigeant sur le plan opérationnel, car les piles d'IA modernes supposent normalement des modèles téléchargeables, des registres de paquets, de la télémétrie, des API, des hubs de modèles et des mises à jour logicielles fréquentes.

L'environnement isolé peut néanmoins contenir de nombreuses machines connectées. Un cluster interne peut avoir des GPU, des serveurs d'application, du stockage, des bases de données, des services d'identité et de surveillance connectés les uns aux autres. L'air gap existe entre cette enclave et le domaine extérieur.

La question pertinente n'est donc pas « Ce GPU a-t-il le Wi-Fi ? » mais « Cet environnement d'IA peut-il échanger des informations avec le domaine externe par un chemin physique ou logique automatisé ? »

L'exemple le plus simple

Imaginez qu'une entreprise souhaite un assistant interne pour des documents techniques confidentiels, mais que l'environnement n'est pas autorisé à envoyer ces documents sur internet.

L'entreprise télécharge un LLM approuvé, un modèle d'embedding, des images de conteneurs et des paquets logiciels dans un environnement de préparation connecté. Après validation, les artefacts approuvés sont transférés dans l'environnement isolé.

À l'intérieur de l'enclave, le serveur de modèles, l'analyseur de documents, la base de données vectorielle, l'application et les services d'identité s'exécutent localement. Les utilisateurs peuvent poser des questions et utiliser le RAG sur des documents internes sans modèle cloud ni registre de modèles public.

Lorsqu'une mise à jour est nécessaire, celle-ci repasse par le processus d'import contrôlé plutôt que d'être téléchargée directement par le serveur d'IA de production.

Où l'exemple simple s'arrête

Un environnement de production en air gap peut être bien plus vaste qu'un seul poste de travail. Il peut inclure Kubernetes/OpenShift, des registres internes, du stockage objet, des fournisseurs d'identité, des bases de données vectorielles, de l'observabilité, une infrastructure de sauvegarde et plusieurs nœuds de service de modèles.

Plus il y a de services à l'intérieur de l'enceinte, plus l'organisation doit reproduire des capacités que les environnements connectés consomment normalement depuis Internet.

L'isolation réseau déplace donc la complexité. Elle réduit la connectivité externe directe mais augmente la gestion des artefacts, des correctifs, des dépendances, de la chaîne d'approvisionnement et des responsabilités opérationnelles à l'intérieur du domaine isolé.

IA isolée vs hors ligne vs locale vs sur site vs privée vs souveraine

Ces termes peuvent se chevaucher mais ne sont pas synonymes. Un serveur Ollama local connecté à Internet est de l'IA locale, pas de l'IA isolée. Une plateforme RAG sur site qui appelle un modèle cloud est une infrastructure applicative sur site avec inférence cloud, pas de l'IA isolée.

Un système isolé est souvent privé par conception car les données restent à l'intérieur de l'enceinte, mais la confidentialité dépend aussi de l'autorisation, de la journalisation, du traitement des données, de la sécurité physique et de la politique opérationnelle.

Isolation stricte vs déploiement déconnecté pratique

Une architecture d'IA isolée pratique

Une architecture complète doit pouvoir démarrer et fonctionner sans résolutions DNS, vérifications de licence, téléchargements de paquets ou appels API vers des services publics, sauf si ces dépendances ont des remplacements internes approuvés.

Un test de conception utile consiste à déconnecter le déploiement de tout service externe et à démarrer la pile à froid. Les dépendances cachées ont tendance à apparaître lors du démarrage, du chargement du modèle, de l'authentification, de la résolution des paquets ou de l'initialisation de la télémétrie.

Les modèles doivent être pré-stockés

Les API de modèles cloud sont indisponibles par définition si la charge de travail isolée n'a aucun chemin vers elles. L'enceinte a donc besoin d'artefacts de modèles exécutables localement ou d'un service d'inférence hébergé en interne.

La documentation actuelle de NVIDIA sur l'isolation NIM utilise explicitement un modèle en deux phases : télécharger et préparer les ressources du modèle sur une machine connectée, les transférer, puis exécuter le NIM isolé depuis le stockage local sans accès sortant au registre ni clés API cloud.

Les poids du modèle ne sont qu'une partie de l'ensemble des dépendances. Les tokenizers, fichiers de configuration, adaptateurs, métadonnées de quantification et tout code d'exécution requis doivent également être présents.

Les modèles avec des dépendances de code distant sont un risque pour l'isolation

Certains dépôts de modèles contiennent du code Python personnalisé ou des hooks d'exécution qui récupèrent normalement du code ou des ressources supplémentaires.

La documentation actuelle de Red Hat AI Inference avertit explicitement que certains modèles Hugging Face nécessitant du code distant ne peuvent pas fonctionner normalement dans des environnements déconnectés, car la bibliothèque tente d'accéder au réseau même lorsque le mode hors ligne est configuré.

La leçon pratique est de tester l'intégralité du chemin de chargement d'un modèle hors ligne avant de l'approuver pour un déploiement isolé. « J'ai téléchargé les poids » ne prouve pas que le modèle est autonome.

Les conteneurs, paquets et pilotes deviennent des artefacts locaux de la chaîne d'approvisionnement

Les environnements connectés récupèrent régulièrement des images de conteneurs, des paquets Python, des mises à jour du système d'exploitation et des composants GPU depuis des registres publics. Un environnement isolé du réseau ne peut compter sur aucun de ces services.

Le modèle de déploiement IA déconnecté de Red Hat utilise des registres miroirs internes pour les images de conteneurs et les catalogues d'opérateurs. Les modèles peuvent être mis en miroir en tant qu'artefacts OCI ou transférés vers un stockage persistant.

Pour des piles plus larges, le même schéma s'applique souvent aux paquets de langage, aux dépôts Linux, aux paquets JavaScript et aux binaires internes : les artefacts approuvés entrent une fois par le processus de transfert, puis sont servis depuis des dépôts internes de confiance.

Connaître la facture complète des dépendances

Les miroirs internes sont une infrastructure, pas une commodité

Un déploiement déconnecté devient maintenable lorsque le domaine isolé dispose de sources internes connues pour les artefacts approuvés.

L'approche documentée de Red Hat utilise un registre miroir accessible au cluster déconnecté afin que les charges de travail n'aient pas besoin de registres publics.

La même idée architecturale peut être appliquée aux magasins de modèles et aux dépôts de paquets. L'objectif est de rendre explicites l'origine, la version et l'approbation des artefacts plutôt que de copier manuellement des fichiers aléatoires sur chaque serveur.

Le RAG peut fonctionner entièrement en air-gapped

Le RAG ne nécessite pas l'internet public. Il nécessite un corpus récupérable, un pipeline d'ingestion/indexation et un modèle capable d'utiliser le contexte récupéré.

Dans un environnement air-gapped, le stockage de documents, le parseur/OCR, le modèle d'embedding, l'index vectoriel ou lexical, le reranker et le modèle de génération peuvent tous fonctionner localement.

Ce qui change, c'est l'acquisition des sources. La recherche web en direct et les connecteurs de documents cloud ne sont pas disponibles, sauf si des données équivalentes sont importées via la frontière contrôlée.

Le corpus devient donc un artefact gouverné. Chaque importation doit préserver l'identité de la source, la date/version et la provenance afin que les utilisateurs sachent quelles connaissances le système isolé contient réellement.

Les agents peuvent fonctionner en environnement isolé — mais uniquement avec des outils accessibles

Une boucle d'agent peut s'exécuter entièrement à l'intérieur d'une enclave isolée si le modèle/environnement d'exécution et les outils requis sont locaux ou accessibles sur le réseau interne.

Un outil qui dépend de GitHub, d'une recherche web publique, d'un e-mail cloud ou d'une API SaaS externe échouera, sauf si l'architecture fournit un équivalent interne approuvé ou un processus d'échange asynchrone contrôlé.

C'est pourquoi la conception d'agents en environnement isolé doit commencer par un inventaire des capacités : chaque point de terminaison d'outil doit être classé comme interne, importé, indisponible ou délibérément exclu.

Le MCP ne contourne pas l'isolement

Le MCP peut exposer des outils et des ressources locales au sein d'un environnement d'IA isolé, mais le protocole ne crée pas de connectivité à travers la frontière de sécurité.

Un serveur MCP local qui lit des documents internes peut fonctionner parfaitement hors ligne. Un serveur MCP distant sur l'internet public ne peut pas être atteint depuis une enclave strictement isolée.

Le même principe s'applique à tout protocole de connexion : l'interopérabilité est distincte de l'autorité réseau.

L'identité et l'authentification doivent également fonctionner hors ligne

Une application d'IA peut être hébergée localement tout en dépendant d'un fournisseur d'identité cloud. Cette dépendance cachée empêche un fonctionnement véritablement déconnecté.

Les conceptions isolées nécessitent donc une architecture d'identité qui fonctionne à l'intérieur de l'enclave : annuaire local, fournisseur d'identité interne, PKI interne, informations d'identification de service locales ou tout autre mécanisme approuvé.

L'autorisation reste nécessaire même en l'absence d'internet. L'isolement ne remplace pas le RBAC, l'isolation des locataires ni le principe du moindre privilège.

Le temps, les certificats et les magasins de confiance deviennent des dépendances locales

De nombreux systèmes d'authentification et de journalisation dépendent d'une heure fiable. Les certificats expirent. Les magasins de confiance changent. Les artefacts signés nécessitent une validation.

Une enclave déconnectée doit donc disposer d'une synchronisation horaire interne et d'un cycle de vie des certificats et de la confiance qui ne dépend pas de l'accès aux services publics lors du fonctionnement ordinaire.

Ce sont des préoccupations d'infrastructure ordinaires qui ne deviennent visibles que lorsqu'une architecture est testée sans accès à internet.

La télémétrie et les rapports de plantage nécessitent une politique explicite

De nombreuses bibliothèques modernes tentent d'effectuer des analyses, des vérifications de mise à jour ou des rapports d'erreurs par défaut.

Dans un environnement isolé, ces appels devraient être soit désactivés, soit redirigés vers une observabilité interne. Des tentatives de télémétrie échouées à répétition peuvent créer des délais, des journaux bruyants et un comportement de démarrage inattendu.

Un déploiement en air-gapped devrait savoir quels composants tentent une sortie réseau même si le pare-feu les bloquait.

Les systèmes air-gapped ont toujours besoin de correctifs

L'isolation réseau n'empêche pas les logiciels de développer des vulnérabilités. Elle change seulement la façon dont les correctifs atteignent le système.

Le NIST présente la gestion des correctifs comme une maintenance préventive : les organisations doivent toujours identifier, acquérir, prioriser, installer et vérifier les correctifs et mises à jour.

Les opérations air-gapped nécessitent donc une cadence d'importation reproductible pour les paquets du système d'exploitation, les images de conteneurs, les pilotes, les environnements d'exécution d'IA et les mises à jour de sécurité. Le compromis se situe entre la stabilité de l'isolation et l'exposition aux vulnérabilités due à des logiciels obsolètes.

Un chemin de mise à jour contrôlé

La frontière de transfert est l'interface opérationnelle la plus sensible

Si des informations externes doivent entrer dans un système air-gapped, le canal d'importation devient un point de contrôle de sécurité majeur.

Le cadre de cybermenace technique de cybersécurité de la NSA reconnaît explicitement la réplication via des supports amovibles comme un chemin que les adversaires peuvent utiliser pour pénétrer dans des réseaux déconnectés ou air-gapped.

C'est pourquoi la gestion contrôlée des supports, l'inspection, la provenance, le chiffrement lorsque nécessaire, l'analyse des logiciels malveillants et la séparation des rôles peuvent être aussi importants que la pile d'IA elle-même.

Les supports amovibles ne sont pas un conduit neutre

Les clés USB et autres supports portables peuvent contenir à la fois des artefacts légitimes de modèles/données et du contenu malveillant.

Les directives du NIST sur l'assainissement des supports traitent les supports de stockage comme un objet de cycle de vie de confidentialité qui peut nécessiter un effacement, une purge ou une destruction selon la sensibilité et les besoins de réutilisation.

La procédure exacte de transfert est propre à chaque organisation, mais le principe architectural est stable : les supports franchissant les frontières doivent être gouvernés comme un actif de sécurité, et non traités comme une commodité informelle.

L'air-gapping accroît l'importance de la chaîne d'approvisionnement

Un système isolé reçoit moins d'entrées externes actives, mais chaque binaire, modèle, conteneur et paquet importé devient plus important car l'enceinte peut lui faire confiance pendant longtemps.

Les directives du NIST sur la chaîne d'approvisionnement logicielle mettent l'accent sur la provenance, le risque fournisseur, la gestion des vulnérabilités, la vérification logicielle et les pratiques orientées SBOM. Ces préoccupations deviennent directement pertinentes pour l'importation hors ligne d'artefacts d'IA.

La chaîne d'approvisionnement des modèles mérite la même attention que celle des applications : l'origine du modèle, la licence, le hachage, le format, le code requis, le tokenizer, les adaptateurs et le statut d'évaluation doivent être connus avant l'importation.

La préparation à l'air gap doit être testée, pas supposée

Mis en cache une fois n'est pas synonyme de prêt pour l'air gap

Un système peut sembler hors ligne parce que le modèle et les paquets sont déjà mis en cache à partir d'un accès Internet antérieur.

La suppression des caches ou le déploiement sur un nœud propre peut révéler des fichiers tokenizer manquants, des paquets Python, des manifestes de modèles ou des dépendances de code distant.

La préparation à l'air gap doit donc être validée à partir d'artefacts internes propres, et non uniquement depuis un poste de développeur précédemment connecté.

Quelles menaces subsistent à l'intérieur d'un air gap ?

Ce qu'un air gap améliore réellement

Un véritable air gap peut réduire matériellement les chemins d'attaque qui dépendent d'une connectivité distante directe : commande et contrôle externes, mauvaise utilisation des identifiants cloud, exploitation de services exposés à Internet et exfiltration accidentelle de données via des API sortantes ordinaires.

Il simplifie aussi la résidence des données dans un sens étroit : les données d'inférence ne peuvent pas être envoyées à un service cloud externe s'il n'existe aucun chemin.

Ces avantages sont les plus forts lorsque la frontière de transfert et les contrôles d'accès internes sont également disciplinés. Un processus USB mal géré peut compromettre l'isolation prévue.

Ce qu'un air gap rend plus difficile

IA isolée vs IA privée

L'IA privée concerne principalement le contrôle des données sensibles et du traitement de l'IA. Une plateforme d'IA privée peut être sur site et accéder tout de même à des modèles cloud approuvés ou à des services externes.

L'IA isolée est plus stricte en matière de connectivité. Un système peut être privé sans être isolé, et un système isolé peut encore avoir une mauvaise confidentialité si chaque utilisateur interne a un accès illimité.

L'objectif de sécurité doit déterminer l'architecture : confidentialité, souveraineté, résilience et isolation sont des exigences liées mais distinctes.

IA isolée vs IA souveraine

L'IA souveraine concerne le contrôle de la chaîne de dépendance plus large : données, modèles, infrastructure, opérateurs, juridiction et dépendances stratégiques.

Une isolation peut soutenir la souveraineté en réduisant la dépendance d'exécution externe, mais elle ne garantit pas un contrôle souverain. L'enceinte peut encore dépendre de matériel étranger, de licences de modèles propriétaires ou de fournisseurs de mises à jour externes.

Le prochain article canonique sépare explicitement ces dimensions de contrôle.

Preuves de mise en œuvre originale : ce que le client IA Aaasaasa prouve — et ce qu'il ne prouve pas

Le AI Hub sépare l'agent/client, le fournisseur, le modèle et l'emplacement de connexion. Il prend en charge l'inférence locale Ollama et l'opération Codex avec fournisseur local comme des choix distincts plutôt que de supposer que chaque requête IA va vers un modèle cloud.

Le dépôt note explicitement qu'un environnement d'exécution local peut encore utiliser un modèle cloud, tandis que le chat Direct Ollama est une inférence locale. Cette distinction est directement pertinente pour l'architecture isolée : l'exécution locale ne prouve pas que le modèle ou les dépendances environnantes sont déconnectés.

L'abstraction des fournisseurs, la découverte de modèles locaux et l'inférence locale sont donc des éléments constitutifs d'une architecture produit capable d'isolation, mais la frontière réseau, le miroir de dépendances hors ligne, le processus de transfert contrôlé et l'identité/les opérations hors ligne doivent encore être conçus séparément.

Quand l'IA isolée est-elle justifiée ?

L'isolation devrait être une exigence dérivée d'un modèle de menace ou d'une politique, pas une fonctionnalité de prestige. Elle a une réelle valeur de sécurité lorsque le chemin de connectivité éliminé est lui-même inacceptable.

Pour de nombreux cas d'usage d'entreprise, un réseau privé étroitement contrôlé avec des restrictions de sortie, une inférence locale et des canaux de mise à jour approuvés peut offrir un meilleur équilibre entre sécurité et maintenabilité qu'une stricte isolation physique.

Une séquence de conception d'IA en air gap pratique

Liste de contrôle de l'architecture d'IA en air gap

Modes de défaillance courants de l'IA en air gap

Idées fausses courantes

Limites

Les air gaps stricts ralentissent la fraîcheur des connaissances externes car chaque nouvelle source doit passer par un processus de transfert.

Ils peuvent contraindre le choix du modèle lorsque les licences, les exigences de code distant, les besoins matériels ou les API exclusives au fournisseur ne peuvent pas être satisfaits hors ligne.

Ils augmentent le coût opérationnel car l'infrastructure normalement consommée comme services cloud doit être possédée et maintenue en interne.

Ils peuvent aussi créer une latence de correctif : un contrôle des changements plus fort peut maintenir les systèmes stables tout en retardant la remédiation urgente des vulnérabilités.

L'IA en air gap doit donc être évaluée comme une architecture de sécurité parmi d'autres, et non supposée universellement supérieure.

Qu'est-ce qui changerait cette réponse ?

Le support des fournisseurs pour le fonctionnement déconnecté évolue rapidement. Les nouveaux formats de modèle, les artefacts OCI signés, les mécanismes de licence hors ligne et les registres de modèles intégrés peuvent réduire les frictions opérationnelles.

La distinction entre air gap strict et déploiement déconnecté restera importante même si les fournisseurs continuent d'utiliser les termes de manière vague.

Le principe stable est que les véritables revendications d'air gap dépendent de la frontière du système et du mécanisme de transfert, et non du fait que le LLM s'exécute localement.

Connaissances canoniques associées

L'IA en air gap est un nœud d'architecture de déploiement et de sécurité. L'IA privée, l'IA souveraine et l'abstraction de fournisseur répondent à des questions différentes sur la confidentialité, le contrôle et la dépendance.

MLOps/LLMOps devient plus exigeant dans un environnement déconnecté, car les cycles de vie des modèles, des packages et des mises à jour doivent fonctionner via des dépôts internes et un transfert contrôlé.

Le RAG et l'IA agentique restent des modèles valides à l'intérieur de l'enceinte tant que leurs données et outils sont disponibles en interne.

Questions fréquentes

Glossaire

Conclusion

L'IA en air gap n'est pas un type particulier de modèle. C'est une architecture d'IA fonctionnant à l'intérieur d'un domaine de sécurité délibérément isolé.

Le modèle peut être la partie facile. La préparation à la production dépend de la capacité de chaque dépendance environnante — actifs de modèles, packages, registres, identité, RAG, outils, surveillance, mises à jour et récupération — à fonctionner sans chemin externe automatisé.

La règle fiable la plus courte est la suivante : l'inférence locale prouve où le modèle s'exécute ; les preuves d'air gap prouvent comment le système complet est séparé et comment chaque transfert autorisé franchit cette frontière.

Sources primaires et références d'implémentation actuelles

Les sources ci-dessous établissent la définition de sécurité, les modèles actuels de déploiement d'IA déconnectée et les risques du cycle de vie. L'utilisation du terme « air-gapped » par les fournisseurs est intentionnellement distinguée de la définition plus stricte du NIST.