Exécuter l'IA dans un environnement isolé

Ce que signifie vraiment « isolé »

Isolé signifie que le déploiement n'a aucun chemin vers l'Internet public. Aucun appel d'API de modèle, aucune télémétrie, aucune vérification de licence, aucun téléchargement de paquets à l'exécution, aucune exception. Tout ce dont le système a besoin est copié à l'avance dans votre réseau : images de conteneurs, poids des modèles, modèles d'embedding et toutes les dépendances.

C'est nettement plus strict que « sur site » ou « cloud privé », qui conservent généralement un chemin sortant et en dépendent souvent. C'est une isolation réseau stricte, et elle vaut la difficulté parce qu'elle est démontrable : on la prouve à un auditeur avec une politique réseau, au lieu de la décrire avec un schéma.

Pour l'architecture, cela veut dire que l'isolation doit être la première contrainte, pas une configuration ajoutée plus tard. Presque toutes les décisions de conception ci-dessous en découlent.

Orchestration : la fondation

Commencez par ce qui planifie et dimensionne les charges de travail. Les conteneurs empaquettent chaque composant dans une image portable ; Kubernetes, ou OpenShift comme distribution d'entreprise durcie, orchestre ces images sur vos propres serveurs et GPU.

Le détail critique, c'est le registre. Vous exécutez un registre de conteneurs privé dans votre réseau et vous y copiez chaque image, pour qu'aucun pod ne tente jamais de téléchargement externe. Cela semble trivial, et c'est là que la plupart des tentatives d'isolation échouent en premier, souvent à cause d'une image de base ou d'un sidecar dont personne ne connaissait la présence. OpenShift gagne sa place dans les environnements réglementés avec des contextes de sécurité restreints par défaut, la signature d'images intégrée et des politiques natives : le durcissement décrit plus bas part donc d'une meilleure base.

Service des modèles : poids ouverts, dans le cluster

Comme il n'y a pas de modèle hébergé à appeler, vous servez vous-même des modèles à poids ouverts. Un serveur d'inférence comme vLLM ou Text Generation Inference de Hugging Face tourne comme un service du cluster, avec planification des GPU, regroupement des requêtes et mise à l'échelle automatique.

Les poids sont chargés depuis un stockage sur site préparé à l'avance et jamais récupérés à l'exécution. Dimensionnez les pods GPU selon le modèle et la concurrence dont vous avez réellement besoin, pas selon le plus gros modèle disponible, et n'exposez l'inférence que sur le réseau interne du cluster, pour que rien ne soit joignable depuis l'extérieur de votre réseau, même en principe.

Une récupération qui ne sort jamais

Un modèle n'est utile que dans la mesure de ce sur quoi il peut s'appuyer, donc la pile de récupération doit elle aussi se trouver dans votre réseau : une base vectorielle, un modèle d'embedding servi dans le cluster et un pipeline d'ingestion qui indexe vos documents.

Chaque étape (embedding, stockage, requête) se déroule dans votre réseau, donc les documents sources ne sont transmis nulle part, à aucun moment. C'est la différence entre un chatbot hors ligne générique, d'un intérêt limité, et un système capable de répondre à partir de documents classifiés ou réglementés, ce qui est la raison d'être du déploiement.

Durcissement : rendre le tout défendable, pas seulement isolé

L'isolation vous mène presque au bout. Le durcissement permet de le prouver, ligne par ligne, à quelqu'un dont le métier est de ne pas vous croire.

• Limiter le trafic est-ouest par des politiques réseau, pour que seuls les composants qui doivent se parler le puissent, et qu'un pod compromis ne puisse atteindre ni le modèle ni l'index.
• Imposer la provenance des images par la signature et le contrôle d'admission, pour qu'une image non vérifiée ne puisse pas s'exécuter, même si elle atteint le registre.
• Conserver les secrets dans un magasin scellé du cluster plutôt que dans des variables d'environnement ou des manifestes, où ils finissent dans les journaux et les sauvegardes.
• Activer une journalisation d'audit complète, pour que chaque inférence et chaque changement de configuration soient attribués à une identité et à un moment.

La couche que la plupart des guides omettent

Exécuter le modèle est le problème d'infrastructure, et le plus facile. Le gouverner ne devient pas inutile parce que le réseau est isolé. Un assistant isolé peut encore répondre avec aplomb à partir d'une récupération médiocre, encore montrer les documents d'une unité à une autre, encore écrire un identifiant dans un journal, et encore vous laisser incapable de reconstituer ce qu'il a fait en mars dernier.

Les mêmes contrôles s'appliquent donc dans votre réseau comme à l'extérieur : un seuil de confiance en dessous duquel le système refuse de répondre, l'isolation des documents entre clients ou unités, l'expurgation et un journal complet des interactions. NeuralSeek se déploie dans le même cluster, dans le même conteneur, et fournit cette couche sans un seul appel sortant, y compris la possibilité de comparer les modèles à poids ouverts que vous avez préparés sur vos propres documents plutôt que sur un classement public.

L'infrastructure rend l'IA isolée possible. La gouvernance permet de la mettre en toute sécurité devant quelqu'un.