Comment l’IA hybride répond aux exigences de souveraineté

L’IA souveraine est une décision de contrôle des dépendances

La question d’infrastructure clé pour l’IA souveraine est de savoir quelles dépendances une organisation peut autoriser en dehors de son propre environnement. Les données peuvent devoir rester locales même si certaines opérations logicielles restent connectées à un fournisseur. Dans le cas le plus strict, l’environnement peut devoir être isolé par air gap : physiquement ou logiquement séparé des réseaux externes, y compris l’internet public.

Google affirme que trois risques motivent ces choix :

Risque	La formulation de Google
Risque juridictionnel	Réglementation, préoccupations liées à la propriété intellectuelle et demandes étrangères d’accès aux données
Dépendance économique	Dépendance à l’égard de fournisseurs d’infrastructure étrangers
Perturbation géopolitique	Perturbation affectant des services critiques

Google indique que ces pressions comptent particulièrement dans les secteurs publics, de la défense, de la santé, de la finance et des infrastructures critiques, où la perte d’accès ou de contrôle peut avoir de graves conséquences. L’entreprise a un intérêt commercial à présenter les choses ainsi, car elle vend une infrastructure conçue pour répondre aux exigences de souveraineté.

Ces exigences créent un spectre d’architectures. Déplacer l’IA sur du matériel contrôlé par le client peut permettre une exécution locale tout en conservant des dépendances vis-à-vis des logiciels du fournisseur, des mises à jour ou de la gestion du cycle de vie.

L’IA hybride répartit les charges de travail selon les exigences de contrôle

Une enquête de Google menée auprès de plus de 1 400 responsables IT seniors a révélé que 52 % des organisations utilisent une approche hybride du cloud pour l’IA, combinant des systèmes on-premises et des environnements multicloud. Elle a également montré que 48 % donnent la priorité à une infrastructure dotée de contrôles de résidence des données afin de soutenir la conformité aux lois locales sur la sécurité des données. Google a un intérêt commercial dans la demande d’infrastructure hybride cloud, car l’entreprise vend ce type d’infrastructure.

Parmi les répondants de Google, le déploiement mixte et la résidence des données sont des priorités actuelles. Pour les dirigeants, cela renvoie à deux décisions d’architecture distinctes : où les données sensibles sont stockées et traitées, et quelles charges de travail peuvent utiliser une infrastructure externe et des services d’IA.

Un déploiement hybride peut séparer les charges de travail en fonction de ces exigences. Une charge de travail réglementée peut rester dans un environnement local contrôlé, tandis qu’une autre peut utiliser des ressources distantes lorsque ses exigences le permettent. La politique d’infrastructure peut alors être définie au niveau de la charge de travail.

Certaines exigences de souveraineté imposent une frontière plus stricte.

Le spectre de la souveraineté inclut l’isolement complet

Google Distributed Cloud illustre la différence entre une infrastructure locale connectée à un fournisseur et une infrastructure conçue pour l’isolement. Google vend les deux modèles de déploiement et bénéficie donc commercialement de l’adoption de l’une ou l’autre approche par les organisations.

Google décrit son déploiement connecté comme fonctionnant sur le matériel existant du client avec un cycle de vie logiciel géré par Google. Cela permet une exécution locale tout en conservant une connexion au fournisseur pour les opérations de cycle de vie.

Google décrit son déploiement isolé par air gap comme entièrement déconnecté de Google Cloud et de l’internet public. L’entreprise indique que l’environnement on-premises fournit l’infrastructure pour les charges de travail d’IA, l’accès aux modèles Gemini et aux modèles ouverts, ainsi que des services d’inférence.

Cette distinction est importante pour les organisations qui doivent fonctionner sans connectivité à l’internet public. Une installation connectée conserve des dépendances réseau et opérationnelles que la conception air gap de Google vise à supprimer.

Google affirme également que son système air gap ne peut pas être arrêté à distance par l’entreprise. Il s’agit d’une affirmation de Google à propos d’un produit qu’elle vend. Les gouvernements et autres organisations préoccupés par leur dépendance à des fournisseurs technologiques étrangers devraient préciser dans leurs achats le niveau requis de contrôle du fournisseur, puis vérifier si les contrôles contractuels et techniques répondent à cette exigence.

Un déploiement local peut conserver des dépendances vis-à-vis du fournisseur

L’emplacement physique ne répond qu’à une partie de la question de la souveraineté. Un système d’IA exécuté dans un centre de données privé peut encore dépendre d’un fournisseur pour les logiciels, les modèles, la gestion du cycle de vie, les mises à jour ou le support.

Ces termes décrivent des propriétés différentes. « On-premises » signifie que l’infrastructure fonctionne sur le site du client. « Air-gapped » signifie que l’environnement est isolé des réseaux externes. « Souverain » décrit les contrôles qu’une organisation exige sur ses données et ses systèmes. « Indépendant » implique une capacité plus large à fonctionner sans dépendance critique à un fournisseur externe.

Ces distinctions modifient les achats. Les dirigeants doivent préciser quelles données peuvent quitter l’environnement, quelles connexions réseau peuvent exister, qui réalise les opérations de cycle de vie, comment les mises à jour entrent dans les systèmes contrôlés et quels contrôles restent à la disposition du fournisseur.

Ces exigences doivent pouvoir être testées. Une organisation centrée sur des règles nationales de résidence des données peut autoriser des services de cycle de vie gérés par le fournisseur. Un opérateur dont le modèle de menace inclut une perte prolongée de connectivité externe peut exiger que le système continue de fonctionner en isolement. Une organisation préoccupée par le contrôle exercé par un fournisseur externe devrait identifier quels mécanismes techniques et contractuels permettent à un fournisseur de modifier, désactiver ou mettre à jour les systèmes déployés.

Points clés à retenir pour les dirigeants

Définir les dépendances IA acceptables : L’IA souveraine exige plus que des données locales. Les dirigeants doivent préciser quelles dépendances externes, y compris les logiciels du fournisseur, les mises à jour, la gestion du cycle de vie et l’accès réseau, leur modèle de risque autorise.
Séparer les charges de travail selon les exigences de contrôle : L’IA hybride permet aux organisations de conserver les charges de travail réglementées dans des environnements contrôlés tout en utilisant ailleurs des ressources distantes. Définissez les politiques de résidence des données et d’infrastructure au niveau de la charge de travail.
Adapter l’isolement au modèle de menace : L’IA connectée on-premises et l’IA isolée par air gap offrent des niveaux de contrôle sensiblement différents. Les organisations qui doivent résister à une perte d’internet ou limiter l’accès du fournisseur devraient exiger et vérifier des capacités d’isolement.
Tester la dépendance au fournisseur dans les achats : Une infrastructure on-premises peut encore dépendre d’un fournisseur externe pour les modèles, les logiciels, les mises à jour et le support. Les achats doivent définir et tester qui peut accéder aux systèmes, les modifier, les mettre à jour ou les désactiver, ainsi que leur mode de fonctionnement lorsqu’ils sont déconnectés.