LLM et agents en air-gap sur votre propre cluster
La moitié IA d'un déploiement air-gap, en détail : où résident les poids, comment la recherche s'ancre sans API d'embeddings, à quoi se connectent les outils d'un agent quand il n'y a rien à joindre, et comment tout cela reste à jour.
Les poids résident sur votre cluster
Les modèles à poids ouverts sont servis depuis du matériel situé dans votre périmètre. Il n'y a aucun point d'inférence externe à joindre, donc aucun point d'inférence externe à perdre.
La recherche s'ancre localement
Embeddings, indexation et recherche s'exécutent tous dans l'environnement, ancrés dans votre propre ontologie et vos documents — aucun service d'embeddings hébergé sur le chemin.
Rien ne rappelle la maison
Aucune vérification de licence, aucune télémétrie, aucun rappel vers un fournisseur de modèles. Les mises à jour arrivent quand vous les apportez, par un canal que vous contrôlez et tracez.
« Ça fonctionne hors ligne » est facile à dire et difficile à tenir. La plupart des piles IA comportent au moins un élément qui a discrètement besoin d'internet — le point d'accès du modèle, un appel d'embeddings, une vérification de licence, une remontée de télémétrie — et vous découvrez lequel le jour où le câble est débranché. Cette page est l'inventaire : chaque partie de l'IA qui irait normalement vers l'extérieur, et ce qu'elle fait à la place.
À lire si vous êtes architecte devant certifier qu'un déploiement IA n'a véritablement aucune dépendance sortante — et le prouver avant l'homologation.
L'IA air-gap exécute la mise à disposition des modèles, la recherche et l'exécution des agents entièrement à l'intérieur d'un réseau sans route vers l'internet public. Des modèles à poids ouverts sont servis depuis votre propre cluster, les embeddings et la recherche sont calculés localement sur votre ontologie et vos documents, les outils des agents ne résolvent que vers des systèmes situés dans le périmètre, et les mises à jour de modèles et de logiciels arrivent par un canal contrôlé que vous exploitez.
Une plateforme n'est air-gap qu'au point où chaque dépendance dispose d'une destination locale. La moitié infrastructure — le cluster, le stockage, l'isolation — est traitée sous [Fondations souveraines](/platform/sovereign-infra/air-gapped). Cette page est l'autre moitié : ce qu'il advient de l'IA elle-même. L'inférence cesse d'être un appel d'API pour devenir une charge de travail que vous planifiez. La recherche ne présuppose plus de service d'embeddings hébergé. L'outillage des agents ne résout plus vers l'extérieur. Évaluation, mises à jour et licences ne rappellent plus la maison. Rien de tout cela n'est un mode dégradé — c'est ainsi que la plateforme est construite, et c'est pourquoi l'ensemble des capacités sur un réseau déconnecté est le même qu'en étant connecté.
IA air-gap dans la plateforme Scrydon
Une architecture souveraine unique et intégrée. Voici où se situe IA air-gap — mis en évidence au sein de la pile complète avec laquelle il fonctionne.
L'AI OS pour les humains et les agents IA
Couche d'ontologie et couche sémantique : un modèle unique et connecté pour vos données, connaissances et processus
Le meilleur des data lakes, des entrepôts de données et de la recherche réuni
Agents IA, flux de travail et automatisations qui s'exécutent à travers vos systèmes
Intégrez via A2A, MCP, systèmes existants et sources de données
Fédération de domaines sécurisée, partage de données de confiance et intelligence au-delà des frontières
Fondations Souveraines
IA air-gap en détail
Orchestration Humain + IA
L'AI OS pour les humains et les agents IA
L'Orchestrateur Humain + IA est le runtime opérationnel au cœur de l'AI OS — également appelé Agentic OS — qui planifie, route et gouverne chaque tâche au sein de votre entreprise, qu'elle soit exécutée par un agent IA, un système existant ou un humain.
La plupart des organisations ont des processus défaillants : encodés dans des systèmes cloisonnés ou enfermés dans la tête des collaborateurs. L'AI OS les rend visibles et exécutables. Il capte l'intention, synthétise le contexte, agit — puis réinjecte chaque résultat dans l'ontologie afin que l'exécution suivante soit plus intelligente. Le tout à l'intérieur de votre périmètre.
L'AI OS ne fonctionne que s'il est digne de confiance. Chaque couche de la plateforme repose sur une infrastructure zero-trust et une fondation d'identité qui fonctionnent de manière cohérente, des déploiements on-premises entièrement air-gap jusqu'aux environnements cloud à grande échelle. La souveraineté n'est pas une fonctionnalité ajoutée par-dessus — c'est la condition dans laquelle tout le reste opère.
- Architecture zero-trust : Vérification continue de chaque requête, chaque utilisateur et chaque charge de travail — aucune confiance implicite, même à l'intérieur du périmètre.
- Identité fédérée : Intégration transparente avec votre IdP existant (SAML, OAuth 2.0, OIDC) pour un contrôle d'accès unifié et régi par des politiques.
- Déploiement air-gap : Exécutez la plateforme complète sans aucune dépendance réseau externe — idéal pour la défense, les infrastructures nationales critiques et les charges de travail classifiées.
- Calcul confidentiel : Chiffrement matériel des données en cours d'utilisation via AMD SEV-SNP et Intel SGX, protégeant les charges de travail même des administrateurs d'infrastructure.
Deployment Options: From Air-gapped to Cloud
Déployez la plateforme Scrydon où cela a du sens pour vous — des environnements air-gap au cloud public — avec souveraineté, conformité et auditabilité intégrées.
Aucune donnée ne quitte votre juridiction. Pas d'IA boîte noire. Aucun compromis sur le contrôle.
C'est la souveraineté par conception.
Quatre éléments qui exigent normalement internet — et ce qu'ils font à la place
Prenez n'importe quelle pile IA et demandez-vous vers quoi elle tend la main. Il y a généralement quatre réponses, et chacune doit être remplacée plutôt que désactivée avant que « air-gap » ne signifie quoi que ce soit. L'inférence est l'évidente : les modèles à poids ouverts sont servis depuis du matériel situé dans le périmètre, de sorte que la génération est une charge de travail que le cluster planifie et non une requête qui le quitte. La recherche est celle qui prend les gens en défaut — une pile peut servir son propre modèle de conversation et malgré tout envoyer chaque fragment de document à un point d'embeddings hébergé ; ici, embedding, indexation et recherche s'exécutent donc localement, ancrés dans votre ontologie et citables vers des enregistrements qui n'ont jamais bougé. L'outillage des agents change moins qu'on ne le croirait : les agents joignent les systèmes via le même Model Context Protocol et se joignent entre eux via le même A2A qu'ailleurs, la seule différence tenant aux destinations qui résolvent. Un runtime dont l'egress est refusé par défaut dès l'origine n'a pas besoin d'un traitement particulier pour un réseau sans aucun egress. Reste le cycle de vie — évaluation, observabilité, audit et mises à jour — et tout cela est produit, conservé et promu à l'intérieur de l'environnement.
Inférence — Des modèles à poids ouverts servis sur votre propre cluster plutôt qu'appelés via une API. La plateforme est agnostique aux modèles : le choix des poids vous appartient et peut changer sans reconstruire ce qui repose dessus.
Recherche — Embedding, indexation et recherche s'exécutent dans le périmètre sur votre ontologie et vos documents, de sorte que les réponses restent ancrées et citables sans que rien ne quitte le réseau.
Outillage des agents — Les agents joignent les systèmes par les mêmes protocoles qu'ailleurs, mais les seules destinations qui résolvent sont celles de votre environnement. Un refus d'egress par défaut, dans un réseau sans egress, n'est que le cas ordinaire.
Cycle de vie — Évaluation, observabilité et audit sont produits et conservés localement. Les mises à jour de modèles et de logiciels arrivent par votre canal approuvé — aucun téléchargement en arrière-plan, aucune dérive silencieuse de version.
Les dépendances qui ne se révèlent qu'une fois le câble débranché
Presque personne ne se propose de bâtir une pile qui a besoin d'internet. Cela arrive par défaut, une dépendance commode après l'autre, et la facture tombe le jour où l'environnement est scellé. L'appel d'embeddings hébergé est le grand classique : le modèle de conversation a été internalisé, le chemin de recherche non, et chaque fragment de document continue de sortir. Les battements de licence viennent ensuite — des vérifications de droits qui valident par le réseau fonctionnent parfaitement en laboratoire et échouent au trentième jour dans une salle protégée, raison pour laquelle les droits ne dépendent pas ici de l'accessibilité. Télémétrie et rapports d'incident sont généralement actifs par défaut et relèvent de la fuite de données bien avant de relever de la vie privée ; en environnement homologué, ils constituent en outre un constat. Quant au registre de modèles, il présuppose discrètement pouvoir récupérer des poids ou un tokeniseur au premier usage, ce qui transforme un démarrage à froid en panne. Si rien de cela ne mord ici, ce n'est pas parce que chaque cas a été repéré puis désactivé. C'est parce que la déconnexion était le cas de conception et non un réglage de celui-ci : il n'y a jamais eu de récupération à désactiver — une distinction traitée du côté infrastructure sous Fondations souveraines.
L'appel d'embeddings hébergé — Une pile peut servir son propre modèle de conversation et malgré tout envoyer chaque fragment de document à un point d'embeddings hébergé. La recherche est le chemin sortant le plus souvent oublié dans un déploiement par ailleurs local.
Le battement de licence — Un logiciel qui valide ses droits par le réseau fonctionne parfaitement en laboratoire et échoue au trentième jour dans une salle protégée. Ici, les droits ne dépendent pas de l'accessibilité.
Télémétrie et rapports d'incident — Des réglages par défaut qui remontent discrètement l'usage sont une question de fuite de données bien avant d'être une question de vie privée. En environnement classifié, c'est aussi un constat d'audit.
Le registre de modèles — Télécharger des poids ou un tokeniseur au premier usage transforme un démarrage à froid en panne. Tout ce qu'il faut pour servir un modèle est présent avant la fermeture de l'environnement.
Comment un environnement déconnecté ne prend pas de retard
L'objection légitime à l'IA déconnectée ne porte pas sur sa capacité à fonctionner — mais sur son vieillissement. Les modèles progressent vite, et un environnement qui ne peut joindre aucun registre est un environnement susceptible de rester sur un modèle vieux d'un an sans que personne ne l'ait décidé. La réponse consiste à rendre la mise à jour délibérée plutôt qu'automatique. Les mises à jour de modèles et de plateforme empruntent le canal que vous exploitez déjà pour tout le reste — support amovible approuvé ou diode de données — préparées, vérifiées et promues à votre rythme. La plateforme étant agnostique aux modèles, adopter un modèle à poids ouverts plus récent est une étape de déploiement et non une migration des agents, de la recherche et des processus qui reposent dessus : le coût du maintien à jour reste donc assez faible pour que vous le fassiez réellement. Avant toute promotion, l'évaluation a lieu dans l'environnement, sur vos propres données et vos propres tâches — un meilleur test qu'un banc d'essai public, et de toute façon le seul disponible ici. Les preuves qui en résultent — traces, évaluations, enregistrements d'audit — sont générées et conservées localement, si bien que les éléments réclamés par une revue d'homologation sont déjà dans la pièce plutôt qu'à collecter ailleurs.
Des mises à jour que vous apportez — Les mises à jour de modèles et de plateforme passent par le canal contrôlé et tracé que vous exploitez déjà — support amovible approuvé ou diode de données — à votre rythme plutôt qu'à celui d'un fournisseur.
Changer de modèle sans tout refaire — La plateforme étant agnostique aux modèles, adopter un modèle à poids ouverts plus récent est une étape de déploiement et non une migration de tout ce qui repose dessus.
Évaluer avant de promouvoir — L'évaluation s'exécute dans l'environnement sur vos propres données, de sorte qu'un nouveau modèle est jugé sur le travail qu'il fera réellement plutôt que sur un banc d'essai public.
Les preuves restent à l'intérieur — Traces, évaluations et enregistrements d'audit sont générés et conservés localement — les preuves d'homologation n'ont jamais à sortir pour être réunies.
Questions fréquentes
Un LLM peut-il vraiment fonctionner en air-gap ?+
Comment le RAG fonctionne-t-il sans connexion internet ?+
Les agents IA fonctionnent-ils encore sans réseau ?+
Comment met-on à jour modèles et logiciels sur un réseau air-gap ?+
Quels modèles pouvons-nous exécuter hors ligne ?+
Un déploiement air-gap nécessite-t-il du matériel dédié ?+
Manque-t-il quelque chose par rapport à un déploiement connecté ?+
En quoi cela diffère-t-il de la page air-gap des Fondations souveraines ?+
Explorer la plateforme
Vous préférez écrire ? Envoyez un e-mail à hello [at] scrydon.com et nous vous répondrons.
Partenaires
