Les annonces d’octobre 2026 de Google, Microsoft, IBM et AWS montrent comment évolue l’infrastructure d’IA souveraine. L’enjeu pratique consiste à déterminer où les modèles s’exécutent, qui contrôle l’environnement et quelles dépendances subsistent.
Une organisation réglementée souhaite qu’un assistant d’IA effectue des recherches dans des rapports confidentiels et des documents internes.
Elle stocke tous ses fichiers dans un pays approuvé. Mais l’assistant envoie des requêtes à un modèle d’IA hébergé ailleurs, utilise un fournisseur d’identité externe et dépend d’administrateurs distants pour la maintenance de son infrastructure.
Les données sont peut-être stockées localement, mais le système d’IA dans son ensemble n’est pas nécessairement sous contrôle opérationnel local.
C’est toute la différence entre la résidence des données et la souveraineté opérationnelle.
La résidence des données concerne le lieu où les informations sont stockées ou traitées. La souveraineté opérationnelle concerne aussi les personnes qui peuvent accéder aux systèmes et les contrôler, le lieu où fonctionnent les services essentiels et ce qui se passe lorsque des dépendances externes deviennent indisponibles.
Les annonces récentes de Google Cloud, Microsoft et IBM, ainsi qu’un exercice opérationnel d’AWS, illustrent la manière dont les fournisseurs traitent différentes parties de ce problème.
1. Les six frontières de l’IA souveraine
Un déploiement d’IA souveraine ne se résume pas à un modèle installé dans un centre de données local.
Prenons l’assistant de recherche documentaire. Pour répondre à une question, il doit authentifier l’utilisateur, récupérer les documents pertinents, éventuellement créer des représentations vectorielles (embeddings) ou y effectuer des recherches, exécuter l’inférence du modèle et enregistrer les événements d’exploitation.
Chaque étape introduit une dépendance potentielle.
Données
Où les documents, les prompts, les embeddings, les réponses, les journaux et les sauvegardes sont stockés et traités.
L’emplacement du stockage ne suffit pas à lui seul si le traitement a lieu ailleurs. Par exemple, si l’assistant envoie le contenu des documents à un service d’embeddings externe, le stockage local des fichiers sources ne garantit pas un traitement local.
Modèle
Où s’exécute l’inférence et si les requêtes atteignent des services de modèles externes.
Plan de contrôle
Qui peut déployer, configurer, modifier ou arrêter l’environnement.
Si l’inférence s’exécute localement mais que le plan de contrôle a besoin qu’un service externe reste disponible, l’application présente une dépendance opérationnelle en dehors de son environnement de traitement.
Identité et clés
Qui gère les permissions, les identifiants et les clés de chiffrement.
Une application hébergée localement peut malgré tout dépendre d’un accès opérationnel à distance.
Exploitation
Qui assure la maintenance, les mises à jour, le support, la surveillance et la reprise.
Déterminez comment fonctionnent les mises à jour, la surveillance, le support du fournisseur et la reprise après sinistre. Identifiez tout service externe nécessaire au fonctionnement normal ou à la restauration.
Continuité
Quels services restent fonctionnels si la connectivité ou les dépendances externes font défaut.
Si la poursuite du fonctionnement sans connectivité externe est essentielle, testez cette condition.
| Frontière | Ce qu’une organisation doit établir |
|---|---|
| Données | Où les documents, les prompts, les embeddings, les réponses, les journaux et les sauvegardes sont stockés et traités |
| Modèle | Où s’exécute l’inférence et si les requêtes atteignent des services de modèles externes |
| Plan de contrôle | Qui peut déployer, configurer, modifier ou arrêter l’environnement |
| Identité et clés | Qui gère les permissions, les identifiants et les clés de chiffrement |
| Exploitation | Qui assure la maintenance, les mises à jour, le support, la surveillance et la reprise |
| Continuité | Quels services restent fonctionnels si la connectivité ou les dépendances externes font défaut |
Ces frontières constituent un cadre d’évaluation architecturale, et non une définition juridique universelle de la souveraineté.
Elles expliquent aussi pourquoi conserver des documents dans une région approuvée ne suffit pas automatiquement à satisfaire les exigences d’une organisation.
Par exemple, si l’assistant envoie le contenu des documents à un service d’embeddings externe, le stockage local des fichiers sources ne garantit pas un traitement local.
Si l’inférence s’exécute localement mais que le plan de contrôle a besoin qu’un service externe reste disponible, l’application présente une dépendance opérationnelle en dehors de son environnement de traitement.
Le caractère acceptable de ces dépendances dépend des exigences juridiques, contractuelles, de sécurité et de continuité propres à l’organisation.
2. Qu’est-ce qui a changé en octobre 2026 ?
Quatre évolutions illustrent des approches différentes de l’infrastructure souveraine et de l’IA.
| Fournisseur | Évolution | Ce qu’elle démontre |
|---|---|---|
| Google Cloud | Extension des capacités d’IA de Google Distributed Cloud air-gapped, notamment Gemini 3.5 Flash et la recherche d’entreprise | Exécution locale des modèles et récupération d’informations dans un environnement isolé |
| Microsoft | Extension des contrôles Sovereign Cloud aux environnements publics, privés et exploités par le client | Choix propres à chaque charge de travail pour l’administration, les clés et le fonctionnement déconnecté |
| IBM | Annonce d’une architecture validée combinant Sovereign Core et Fusion | Intégration de l’infrastructure et d’une gouvernance exploitée par le client |
| AWS | Compte rendu des résultats d’un exercice d’indépendance de l’European Sovereign Cloud mené le 24 octobre | Test de la poursuite du fonctionnement sans certains systèmes mondiaux d’AWS désignés |
Ces évolutions ne sont ni des produits équivalents ni des classements établis de manière indépendante.
Google Cloud : le 20 octobre, Google a présenté Gemini 3.5 Flash sur Google Distributed Cloud air-gapped comme étant en disponibilité générale. Son expérience de recherche d’entreprise reposant sur Gemini était en préversion. Google affirme que le processus de recherche maintient l’indexation, les prompts et la récupération à l’intérieur du périmètre souverain. Il s’agit d’une conception de produit documentée, et non de la preuve que chaque déploiement satisfait automatiquement toutes les exigences de souveraineté.
Source : Google Cloud, 20 octobre 2026
Microsoft : son annonce du 20 octobre décrivait des contrôles couvrant l’accès des opérateurs, la gestion des clés de chiffrement, l’infrastructure exploitée par le client et les environnements connectés ou déconnectés. Les fonctionnalités présentent des niveaux de maturité différents. La gestion externe des clés avec Azure Managed HSM était en disponibilité générale, tandis que la possibilité de faire basculer des charges de travail entre fonctionnement connecté et fonctionnement déconnecté entrait en préversion publique.
Source : Microsoft, 20 octobre 2026
IBM : le 22 octobre, IBM a annoncé une architecture de déploiement validée combinant le logiciel Sovereign Core et l’infrastructure Fusion. Elle vise à simplifier l’intégration du calcul, du stockage, du réseau et de la gouvernance pour les environnements exploités par le client. Un déploiement plus rapide et une exploitation simplifiée sont les avantages annoncés par IBM, et non des résultats démontrés de manière indépendante pour chaque client.
AWS : le 1er novembre, AWS a rendu compte d’un exercice mené le 24 octobre, au cours duquel son European Sovereign Cloud a continué de fonctionner après la déconnexion de deux systèmes mondiaux. Selon AWS, les charges de travail des clients sont restées disponibles.
Il ne s’agissait pas d’un exercice d’isolement physique (air gap). Le trafic normalement acheminé par la dorsale (backbone) du réseau mondial d’AWS a été redirigé via l’internet public. Le test étaye une conclusion plus restreinte sur l’indépendance vis-à-vis de systèmes mondiaux désignés, et non une affirmation d’isolement complet du réseau ou de résilience face à toutes les conditions de défaillance.
Source : AWS Security Blog, 1er novembre 2026
3. Que doivent réellement vérifier les organisations ?
Revenons à l’assistant de recherche documentaire de l’organisation réglementée.
Avant de choisir une plateforme d’IA souveraine, ses équipes d’architecture et de sécurité devraient suivre une requête complète de bout en bout : de l’authentification de l’utilisateur à la récupération des documents, à l’inférence du modèle, à la génération de la réponse et à la journalisation.
L’examen doit établir où s’exécute chaque étape et quelles parties peuvent y accéder ou l’administrer.
Quatre vérifications sont particulièrement utiles.
Vérifier les mouvements de données. Confirmez si les documents, les embeddings, les prompts, les réponses et les journaux restent à l’intérieur de la frontière requise. L’emplacement du stockage ne suffit pas à lui seul si le traitement a lieu ailleurs.
Vérifier l’autorité administrative. Identifiez qui peut modifier les configurations, accéder aux charges de travail, administrer les systèmes d’identité et gérer les clés de chiffrement. Une application hébergée localement peut malgré tout dépendre d’un accès opérationnel à distance.
Vérifier les dépendances opérationnelles. Déterminez comment fonctionnent les mises à jour, la surveillance, le support du fournisseur et la reprise après sinistre. Identifiez tout service externe nécessaire au fonctionnement normal ou à la restauration.
Tester les conditions de défaillance requises. Si la poursuite du fonctionnement sans connectivité externe est essentielle, testez cette condition. Un exercice réussi d’isolement de la dorsale réseau mené par un fournisseur ne peut pas remplacer le test, par un client, d’une application entièrement déconnectée.
Les éléments de preuve attendus peuvent comprendre la documentation d’architecture, les enregistrements de configuration, les journaux d’accès, les engagements contractuels et les résultats de tests observés.
Ce sont les exigences de l’organisation qui déterminent les preuves pertinentes. Tous les systèmes n’ont pas besoin de résister aux mêmes défaillances ni d’interdire les mêmes formes d’accès externe.
4. Une plus grande indépendance a des coûts opérationnels
Des contrôles de souveraineté plus stricts peuvent accroître les responsabilités opérationnelles de l’organisation.
Un environnement d’IA isolé physiquement (air-gapped) peut nécessiter des accélérateurs dédiés, un stockage local, des artefacts de modèles, une infrastructure réseau et un support spécialisé.
Les correctifs logiciels et les mises à jour des modèles doivent être livrés de manière contrôlée dans l’environnement restreint. La surveillance, la sauvegarde et la reprise doivent aussi fonctionner dans les limites d’exploitation autorisées.
Certains services disponibles dans un cloud public connecté peuvent être indisponibles ou fonctionner différemment en mode déconnecté.
Ces coûts comptent, car l’isolement maximal n’est pas automatiquement la meilleure architecture.
Une organisation dont les exigences autorisent des services cloud régionaux contrôlés peut ne tirer qu’un faible bénéfice de l’entretien d’une plateforme d’IA entièrement déconnectée.
Une autre organisation qui traite des informations hautement restreintes peut n’avoir aucune autre option acceptable.
La décision doit découler des exigences, plutôt que partir d’un fournisseur préféré ou d’une étiquette de souveraineté.
5. La souveraineté doit être démontrée, pas présumée
Les évolutions d’octobre montrent des progrès dans l’inférence d’IA locale, l’infrastructure exploitée par le client, les contrôles administratifs et l’indépendance opérationnelle.
Mais elles répondent à des exigences différentes, et les preuves qui les étayent varient.
Un service en disponibilité générale, une fonctionnalité en préversion, une architecture validée par un fournisseur et un exercice opérationnel rapporté ne doivent pas être considérés comme des preuves équivalentes.
Disponibilité générale
Le 20 octobre, Google a présenté Gemini 3.5 Flash sur Google Distributed Cloud air-gapped comme étant en disponibilité générale. La gestion externe des clés avec Azure Managed HSM était en disponibilité générale.
Préversion
L’expérience de recherche d’entreprise de Google reposant sur Gemini était en préversion. La possibilité de faire basculer des charges de travail entre fonctionnement connecté et fonctionnement déconnecté entrait en préversion publique. Les fonctionnalités présentent des niveaux de maturité différents.
Architecture validée
Le 22 octobre, IBM a annoncé une architecture de déploiement validée combinant le logiciel Sovereign Core et l’infrastructure Fusion. Un déploiement plus rapide et une exploitation simplifiée sont les avantages annoncés par IBM, et non des résultats démontrés de manière indépendante pour chaque client.
Exercice rapporté
Le 1er novembre, AWS a rendu compte d’un exercice mené le 24 octobre, au cours duquel son European Sovereign Cloud a continué de fonctionner après la déconnexion de deux systèmes mondiaux.
Il ne s’agissait pas d’un exercice d’isolement physique (air gap). Le trafic normalement acheminé par la dorsale (backbone) du réseau mondial d’AWS a été redirigé via l’internet public. Le test étaye une conclusion plus restreinte sur l’indépendance vis-à-vis de systèmes mondiaux désignés, et non une affirmation d’isolement complet du réseau ou de résilience face à toutes les conditions de défaillance.
Non équivalents
Un service en disponibilité générale, une fonctionnalité en préversion, une architecture validée par un fournisseur et un exercice opérationnel rapporté ne doivent pas être considérés comme des preuves équivalentes.
Pour l’organisation qui construit l’assistant de recherche documentaire, la décision pratique consiste à définir les frontières dont elle a besoin, à choisir une architecture qui les prend en charge et à vérifier les contrôles qui comptent.
L’IA souveraine est une propriété du système déployé dans son ensemble, et non simplement du pays où ses données sont stockées ou de l’étiquette apposée sur son infrastructure.
Références et lectures complémentaires
- Google Cloud, Enabling the next era of sovereign AI. 20 octobre 2026.
- Google Cloud, Managed RAG search inside the sovereign perimeter. 20 octobre 2026.
- Microsoft, Advancing digital sovereignty with greater control and choice. 20 octobre 2026.
- IBM, IBM Sovereign Core on IBM Fusion simplifies sovereign AI deployment. 22 octobre 2026.
- AWS Security Blog, Inside a successful AWS European Sovereign Cloud exercise. 1er novembre 2026.
Revue des sources : 4 novembre 2026. La disponibilité des produits et les affirmations opérationnelles doivent être vérifiées à nouveau avant publication. Cet article décrit des considérations d’architecture, et non une certification de conformité juridique.