IA air-gapped : faire tourner un LLM sans aucune connexion

Certaines organisations n'ont pas le droit d'envoyer une requête vers un service cloud. Ni chiffrée, ni anonymisée, ni « juste pour tester ». Un opérateur d'importance vitale, une direction de la défense, une salle de marché, un laboratoire pharmaceutique : pour eux, la question n'est pas de savoir quel fournisseur d'IA offre les meilleures garanties contractuelles, mais comment obtenir les bénéfices de l'IA sans qu'aucun paquet ne franchisse la frontière du réseau. C'est le domaine de l'air gap — et, contrairement à une idée répandue, il n'est plus réservé aux budgets d'État.

Qu'est-ce qu'un déploiement d'IA air-gapped ?

Un déploiement air-gapped fait fonctionner un modèle de langage sur des serveurs physiquement isolés de tout réseau externe : aucune connexion Internet, aucune API distante, aucune télémétrie sortante. Les poids du modèle, le moteur d'inférence, les données et les journaux résident entièrement dans le périmètre de l'organisation, et n'en sortent jamais.

La distinction avec l'« IA privée » est nette. Une IA privée peut tourner dans votre datacenter tout en gardant un lien vers Internet pour les mises à jour ou la supervision. Un système air-gapped, lui, n'a pas ce lien. Tout ce qui entre — les poids d'un modèle, un correctif de sécurité — entre par un processus contrôlé et documenté, généralement un support physique, après vérification.

Quand un air gap est-il réellement justifié ?

L'isolement total a un coût, et l'invoquer par précaution générale conduit à des projets lourds pour des bénéfices modestes. Trois situations le justifient sans discussion.

Les opérateurs d'infrastructures critiques — énergie, eau, transport, télécoms — dont les réseaux de supervision industrielle sont déjà, par conception, séparés du monde extérieur. Y brancher une IA reliée à Internet reviendrait à percer le mur qu'on a mis vingt ans à construire.

Les environnements de défense et de renseignement, où la classification des données interdit tout traitement hors d'un périmètre homologué, quelles que soient les garanties du fournisseur.

Les institutions financières et de santé sur leurs traitements les plus sensibles : modèles de risque, données de marché propriétaires, dossiers patients identifiants. Ici la contrainte est souvent moins juridique qu'assurantielle et concurrentielle — une fuite ne se répare pas.

En dehors de ces cas, une IA privée hébergée sur votre infrastructure, avec une sortie Internet maîtrisée, offre l'essentiel des garanties pour une fraction de la complexité. Le bon réflexe est de qualifier le besoin traitement par traitement, pas entreprise par entreprise : la même banque peut légitimement utiliser un service cloud pour la rédaction de comptes rendus et exiger un air gap pour l'analyse de ses positions.

À quoi ressemble une architecture de référence ?

Un système air-gapped fonctionnel tient en cinq couches, et aucune n'est optionnelle.

Le socle matériel. Un ou plusieurs serveurs équipés de GPU, dimensionnés selon la taille du modèle et le nombre d'utilisateurs simultanés. C'est la seule couche vraiment coûteuse, et celle qu'il faut dimensionner en dernier — après avoir choisi le modèle, pas avant.

Le moteur d'inférence. La brique logicielle qui charge les poids du modèle et sert les réponses. Les moteurs matures de l'écosystème ouvert gèrent le traitement par lots, la quantification et le partage de charge entre plusieurs GPU. Ils exposent une interface compatible avec les API standard du marché, ce qui rend vos applications portables : le jour où vous changez de modèle, vos applications ne changent pas.

La couche de connaissance. Un modèle brut ne connaît ni vos procédures ni vos contrats. Une base vectorielle et une chaîne de recherche documentaire — un RAG — apportent vos documents au modèle au moment de la requête. Tout reste interne : l'indexation, les fragments, les embeddings.

La couche d'accès et de traçabilité. Authentification adossée à votre annuaire, filtrage des documents selon les habilitations réelles de l'utilisateur, journalisation de chaque requête et de chaque réponse. Sans elle, vous avez un serveur d'IA, pas un système d'entreprise.

La chaîne de mise à jour. C'est la couche qu'on oublie. Comment introduisez-vous un nouveau modèle, un correctif du moteur d'inférence, une mise à jour de la base vectorielle ? Il faut une procédure écrite : téléchargement sur une zone tampon, vérification d'intégrité, analyse antivirale, transfert physique, recette, bascule, rollback. Un système air-gapped sans chaîne de mise à jour devient obsolète en dix-huit mois.

Quels modèles ouverts choisir ?

Trois familles de modèles ouverts couvrent aujourd'hui la quasi-totalité des besoins d'entreprise, et elles s'évaluent sur trois axes : la qualité de raisonnement, la maîtrise du français et les conditions de licence.

Llama, de Meta, reste la référence en termes d'écosystème : outillage abondant, versions quantifiées disponibles, large communauté. Sa licence est permissive mais comporte des clauses spécifiques qu'il faut faire relire par votre direction juridique avant tout déploiement.

Mistral, éditeur français, présente deux avantages pour un contexte francophone : une excellente tenue en français et des modèles conçus pour tourner efficacement sur des configurations modestes. Une partie de sa gamme est publiée sous licence Apache 2.0, la plus simple à gouverner en entreprise.

Qwen, d'Alibaba, s'est imposé sur les tâches de code et de raisonnement, avec une gamme large allant des très petits modèles aux très grands. Le multilingue y est solide, y compris sur l'arabe.

Le réflexe à combattre est celui du plus gros modèle. Sur une tâche cadrée — répondre à partir de vos procédures, classer des documents, rédiger un brouillon —, un modèle de taille moyenne, correctement alimenté par un RAG bien construit, produit régulièrement de meilleurs résultats qu'un très grand modèle mal outillé, pour une facture matérielle sans commune mesure. Choisissez le modèle le plus petit qui passe vos tests, pas le plus grand que votre budget permet.

Combien cela coûte-t-il, en ordres de grandeur ?

Aucun chiffre précis n'a de sens hors contexte : le coût dépend du modèle, du nombre d'utilisateurs, du niveau de redondance et de vos accords fournisseurs. Trois ordres de grandeur, en revanche, structurent la décision.

Un pilote sur un modèle de taille moyenne — de l'ordre de 7 à 14 milliards de paramètres, quelques dizaines d'utilisateurs, un serveur GPU unique — se situe dans la catégorie des projets d'infrastructure courants d'une DSI : un serveur, quelques semaines d'ingénierie. C'est un investissement du même ordre qu'un serveur de virtualisation, pas qu'un programme informatique pluriannuel.

Une production sur un grand modèle — plusieurs dizaines de milliards de paramètres, plusieurs centaines d'utilisateurs, haute disponibilité — change de catégorie : il faut plusieurs GPU haut de gamme, donc plusieurs serveurs, la redondance, l'alimentation et le refroidissement associés. Le poste matériel devient l'essentiel de la facture.

Le coût récurrent, enfin, est systématiquement sous-estimé. Un système air-gapped ne s'auto-administre pas : supervision, mises à jour, réindexation, évaluation de la qualité des réponses, support aux utilisateurs. Comptez ce coût humain dès le dossier d'investissement, sous peine de mettre en service une plateforme que personne ne maintient.

L'arbitrage économique face au cloud, lui, est simple à formuler : le cloud est un coût variable proportionnel à l'usage, l'air gap est un coût fixe amorti sur la durée. Plus l'usage est intense, régulier et durable, plus l'internalisation devient rationnelle — indépendamment même de l'argument de souveraineté.

Quelles contraintes sous-estime-t-on le plus souvent ?

Trois, et elles sont opérationnelles plus que techniques.

La compétence. Exploiter un moteur d'inférence, diagnostiquer une dégradation de latence, requantifier un modèle : ce sont des savoir-faire qui ne s'improvisent pas et qui n'existent probablement pas encore dans vos équipes. Le transfert de compétences doit être un livrable du projet, pas une bonne intention.

L'écart de capacités. Les meilleurs modèles ouverts restent en retrait des meilleurs modèles propriétaires sur les tâches de raisonnement les plus exigeantes. L'écart se resserre, mais il existe. Vos utilisateurs, qui utilisent des assistants grand public le soir, le percevront. Il faut l'annoncer avant le déploiement, pas après.

L'obsolescence. Le rythme de publication des modèles est tel qu'un système figé décroche vite. La chaîne de mise à jour évoquée plus haut n'est pas une formalité de fin de projet : c'est ce qui décide si votre investissement vaut encore quelque chose dans trois ans.

Par où commencer ?

Commencez par la qualification, pas par le matériel. Listez vos traitements, classez-les par sensibilité réelle, et identifiez ceux — souvent moins nombreux qu'on ne le croit — qui exigent véritablement l'isolement total. Pour ceux-là, montez un pilote borné : un cas d'usage, un modèle de taille moyenne, un serveur, un jeu de tests écrit à l'avance. Vous saurez en quelques semaines si la qualité obtenue soutient l'usage visé.

C'est précisément la démarche que nous conduisons dans le cadre de notre offre d'IA souveraine : qualification des traitements, choix du modèle ouvert, architecture d'inférence et chaîne de mise à jour. Les contrôles d'accès et la traçabilité qui l'accompagnent relèvent de la gouvernance de l'IA, et l'articulation avec le cadre marocain est détaillée sur notre page IA souveraine au Maroc. Pour situer votre besoin entre IA privée et air gap complet, parlons-en.