RAG on-premise et air-gap : garder vos données chez vous

La directive NIS2 fait passer le nombre d’organisations françaises soumises à des obligations de cybersécurité d’environ 500 à près de 15 000, réparties sur 18 secteurs (ANSSI). Pour toutes ces entreprises, la question de savoir où une IA lit et traite les documents internes cesse d’être un détail d’infrastructure.

Un RAG on-premise installe le moteur de recherche, la base vectorielle et le modèle de langage sur une infrastructure que l’entreprise maîtrise, sans qu’aucune donnée ne transite par un cloud tiers. En mode air-gap, ce serveur est physiquement coupé d’Internet. C’est la seule architecture qui rend la sortie des données techniquement impossible, pas seulement contractuellement interdite.

Cet article distingue les trois topologies de déploiement, précise quand l’air-gap est réellement nécessaire, et répond à la vraie objection : un modèle exécuté localement est-il assez bon pour un usage professionnel.

Qu’est-ce qu’un RAG on-premise, et en quoi diffère-t-il d’un RAG cloud ?

Un RAG on-premise exécute l’ensemble de la chaîne, de l’ingestion des documents à la génération de la réponse, sur une infrastructure que l’entreprise contrôle, sans appel à un service externe. Un RAG cloud, à l’inverse, envoie les questions et souvent le contenu des documents vers les serveurs d’un fournisseur tiers. La différence ne porte pas sur la qualité des réponses mais sur le chemin que prennent les données : dans le premier cas, elles ne sortent jamais du périmètre choisi.

Il est plus juste de raisonner en spectre qu’en binaire. À une extrémité, le SaaS cloud pur : simple à déployer, mais vos documents alimentent l’infrastructure d’un tiers. Au milieu, l’hébergement dédié souverain : une instance isolée opérée par un prestataire sur des serveurs en Europe. Ensuite, l’on-premise : le système tourne sur l’infrastructure de l’entreprise, derrière son propre pare-feu. À l’autre extrémité, l’air-gap : la machine est coupée de tout réseau externe.

Chaque cran vers la droite réduit la surface d’exposition et augmente l’effort d’exploitation. Le bon choix dépend d’une seule variable : la sensibilité de la donnée que le système va lire. Une organisation qui veut d’abord situer ce que recouvre exactement la souveraineté trouvera le cadre dans ce que recouvre un RAG souverain et pour qui.

Qu’est-ce qu’un déploiement air-gap, et quand est-il vraiment nécessaire ?

Un système air-gap est une machine sans aucune connexion réseau vers l’extérieur : le NIST le définit comme une interface entre deux systèmes qui ne sont pas connectés physiquement et dont tout échange se fait manuellement, sous contrôle humain (CNSSI 4009-2015). Concrètement, aucune requête ne peut sortir du serveur, parce qu’aucun câble ni aucune interface ne le relie à Internet. C’est le niveau d’isolement le plus strict d’un RAG.

L’air-gap répond à un besoin réel, mais étroit. Il s’impose là où l’isolement physique du système d’information fait déjà partie des exigences de sécurité : défense, environnements classifiés, certaines infrastructures critiques, laboratoires sur des données protégées. Pour ces contextes, le RAG ne fait qu’hériter d’une contrainte qui existait avant lui.

Le piège inverse existe aussi. Beaucoup d’organisations sensibles n’ont pas besoin d’un air-gap complet : un déploiement on-premise derrière leur pare-feu, sans exposition publique, couvre déjà l’essentiel du risque. Couper le serveur d’Internet a un coût opérationnel qui ne se justifie que si la menace le commande. La bonne question n’est pas « quel est le niveau maximal » mais « quel est le niveau que ma donnée exige réellement ».

Pourquoi un hébergement « en France » ne suffit-il pas à garder vos données chez vous ?

Un hébergement « en France » ne garantit pas la souveraineté quand le prestataire relève du droit américain. Le CLOUD Act, adopté aux États-Unis en 2018, autorise les autorités américaines à réclamer les données détenues par une entreprise de droit américain ou l’une de ses filiales, quel que soit le lieu physique de stockage, y compris un centre de données situé en Europe. La localisation géographique du serveur ne referme donc pas, à elle seule, le périmètre.

C’est ici que l’architecture prend le pas sur le contrat. Une clause de résidence des données se plaide ; une donnée qui n’a physiquement aucun chemin pour sortir se vérifie sur un schéma. Un RAG on-premise dont le modèle s’exécute localement transforme l’interdiction contractuelle de transfert en impossibilité technique : il n’y a pas de service tiers à appeler, donc rien à transmettre.

Cette bascule change la nature de la conversation avec un DPO ou un RSSI. On ne leur demande plus de faire confiance à un engagement, on leur montre un diagramme réseau où la donnée ne franchit aucune frontière. La démonstration détaillée de ce raisonnement se trouve dans l’architecture qui rassure le DPO. Si vous voulez situer vos propres contraintes avant d’arbitrer, voyons ensemble en 30 minutes où vit votre connaissance et ce que la réglementation impose à votre secteur.

Un modèle de langage exécuté localement est-il assez performant ?

Oui, pour un usage documentaire, un modèle ouvert exécuté localement est aujourd’hui suffisant, à condition de bien mesurer ce qui compte dans un RAG. Les meilleurs modèles ouverts de génération 70B atteignent 65 à 80 % sur des classements de référence comme MMLU et HumanEval, contre 85 à 90 % pour les modèles cloud de premier plan (PromptQuorum, 2026). L’écart existe, mais il porte sur des tâches généralistes, pas sur la restitution d’un passage retrouvé dans vos documents.

C’est la nuance décisive. Dans un système RAG, le modèle ne répond pas de mémoire : il reformule des passages que le moteur de recherche a déjà récupérés dans votre base. La qualité finale dépend donc d’abord de la pertinence du retrieval et du reranking, ensuite seulement de la puissance brute du modèle. Un modèle local correct, alimenté par un bon moteur de recherche sur vos sources, bat un modèle cloud surpuissant qui n’a pas accès à vos documents.

La trajectoire va dans le bon sens. Un modèle ouvert comme Llama 3.3 70B, sorti en 2025, atteint sur la plupart des tests le niveau de GPT-4 tel qu’il était en 2023, et la qualité des modèles ouverts progresse d’environ une génération par an (PromptQuorum, 2026). L’argument « le local n’est pas assez bon » décrit une situation déjà dépassée. Reste que la vraie sécurité sur un dossier ne tient pas à la puissance du modèle mais à sa capacité à s’abstenir, un point traité dans ce que veut dire « zéro hallucination » en pratique.

Comment se déploie un RAG on-premise ou air-gap en pratique ?

Un RAG on-premise se déploie sous forme d’une architecture conteneurisée installée sur l’infrastructure du client, avec un modèle de langage servi localement plutôt qu’appelé dans le cloud. Le démarrage passe par un audit des sources, la définition des espaces par équipe et le branchement des premiers connecteurs, avant l’ingestion et la vectorisation initiales. Une solution éprouvée devient utilisable en moins de deux semaines, sans réorganiser au préalable la documentation existante.

Le socle technique tient dans un seul réseau isolé : une base vectorielle pour stocker les représentations des documents, un moteur de recherche sémantique, un modèle ouvert servi en local, le tout orchestré par conteneurs. Rien de tout cela n’a besoin d’un service externe pour fonctionner, ce qui est précisément la condition qui rend l’air-gap possible.

En mode air-gap, un seul point change : les mises à jour et l’ingestion de nouvelles sources ne passent plus par le réseau mais par des transferts contrôlés, cohérents avec la définition même de l’isolement physique. On échange un peu de commodité opérationnelle contre une garantie que rien ne sort. Pour une IA branchée sur les documents les plus sensibles d’une organisation, c’est souvent l’arbitrage recherché. Le principe complet de bout en bout est développé dans le guide de l’IA souveraine en entreprise.

Quels compromis accepte-t-on avec une architecture air-gap ?

Une architecture air-gap échange la connectivité contre l’isolement, et ce compromis a trois conséquences concrètes. Les mises à jour du modèle et l’ingestion de nouvelles sources se font par transferts contrôlés au lieu d’une synchronisation automatique. L’infrastructure suppose un serveur dédié, souvent doté d’un accélérateur graphique, plutôt qu’un abonnement mutualisé. Et l’exploitation demande une compétence interne ou un accompagnement, là où un SaaS cloud délègue tout au fournisseur.

Ces compromis ne sont pas des défauts, ce sont le prix de la garantie. Ils ne se justifient que si la donnée l’exige : imposer un air-gap à une base de connaissances sans enjeu de confidentialité revient à sur-dimensionner. Pour la majorité des organisations sensibles, l’équilibre se trouve un cran avant, sur un déploiement on-premise connecté mais fermé.

Le coût, enfin, se raisonne à l’inverse du cloud. Un abonnement cloud facturé au siège croît avec chaque utilisateur ajouté ; une infrastructure maîtrisée porte un coût largement indépendant du nombre d’utilisateurs. Au-delà d’un certain effectif, l’architecture dédiée cesse d’être seulement un choix de conformité pour devenir aussi un choix économique.

Questions fréquentes

On-premise et air-gap, est-ce la même chose ?

Non. On-premise signifie que le système tourne sur une infrastructure que l’entreprise contrôle, généralement derrière son pare-feu, mais cette infrastructure peut rester connectée à Internet. L’air-gap ajoute une contrainte supplémentaire : la machine est physiquement coupée de tout réseau externe. Tout air-gap est on-premise, mais un déploiement on-premise n’est pas nécessairement en air-gap.

Un RAG en air-gap peut-il quand même être mis à jour ?

Oui. Les mises à jour du modèle, des composants et l’ingestion de nouveaux documents se font par transferts contrôlés, sous supervision humaine, plutôt que par une connexion réseau. C’est cohérent avec la définition de l’isolement physique, où l’échange de données passe par un support ou une procédure maîtrisée. La contrepartie est un peu moins de commodité, en échange d’une garantie que rien ne sort du serveur.

Un hébergement souverain qualifié SecNumCloud équivaut-il à de l’on-premise ?

Non, ce sont deux réponses différentes. SecNumCloud est une qualification de l’ANSSI pour un cloud opéré par un prestataire, avec des garanties d’immunité aux législations extraterritoriales. L’on-premise déplace le système sur l’infrastructure propre de l’entreprise. Le premier vous rend dépendant d’un fournisseur qualifié ; le second vous rend maître du serveur. Les deux sont des chemins légitimes vers la souveraineté, selon que l’on préfère déléguer l’exploitation ou la garder.

Faut-il un serveur avec GPU pour un RAG on-premise ?

En pratique, oui pour la plupart des déploiements. Servir un modèle de langage localement avec des temps de réponse acceptables suppose un accélérateur graphique dédié. C’est l’un des compromis d’une architecture souveraine : on internalise une ressource matérielle que le cloud mutualise. Le dimensionnement se cale sur la taille du modèle retenu et le volume de requêtes attendu.

Quels secteurs sont réellement contraints à l’air-gap ?

L’air-gap strict est surtout imposé dans la défense, les environnements classifiés et certaines infrastructures critiques, où l’isolement physique préexiste à toute question d’IA. Ailleurs, dans la santé, la finance ou le juridique, la contrainte vient de la sensibilité des données et du risque, pas d’une obligation d’isolement total. Un déploiement on-premise fermé y répond généralement, sans aller jusqu’à couper le serveur d’Internet.

Conclusion

Trois idées à retenir. Le déploiement d’un RAG se raisonne en spectre, du SaaS cloud à l’air-gap, et le bon cran dépend de la seule sensibilité de la donnée que le système va lire. Un hébergement « en France » ne suffit pas quand le prestataire relève du droit américain : seule une architecture où la donnée n’a aucun chemin pour sortir transforme l’interdiction en impossibilité. Et l’objection de la performance des modèles locaux est dépassée, parce que dans un RAG c’est la qualité du retrieval sur vos sources qui décide, pas la puissance brute du modèle.

Reste à situer votre cas : quelle donnée, quel niveau d’isolement, quelle infrastructure. Discutons-en sur un premier échange, sans engagement, pour cadrer l’architecture qui respecterait vos contraintes.

Cet article est publié par l’équipe Agify, qui conçoit des agents IA sur mesure pour des organisations aux données sensibles, dont ragify, un agent RAG souverain déployable en France, on-premise ou en air-gap.