L'illusion du Sovereign Cloud : pourquoi le véritable contrôle à l'ère de l'IA réside dans la gouvernance de l'identité.

Contexte de l’événement : coûts et leçons de l’expérience européenne du cloud souverain

En janvier 2025, le DORA (règlement sur la résilience opérationnelle numérique) est entré pleinement en vigueur dans l’UE ; la directive NIS2 a été mise en œuvre dans les États membres ; les dispositions relatives aux systèmes à haut risque de l’EU AI Act entreront en vigueur en août 2026. Face à cette triple pression réglementaire, les entreprises européennes – en particulier dans les secteurs financier, des infrastructures critiques et manufacturier – ont massivement migré leurs charges de travail, renégocié leurs contrats et inscrit le cloud souverain dans leurs cadres de risque au niveau du conseil d’administration au cours des deux dernières années.

Les hyperscalers ont réagi rapidement. AWS a lancé son cloud souverain européen en janvier 2026, suivi par Microsoft et Google avec des offres similaires. Le marché semblait mature.

Cependant, lors de la conférence européenne sur l’identité et le cloud (EIC) à Berlin en mai 2026, l’humeur des praticiens a changé de manière notable. L’enthousiasme pour le concept de cloud souverain était passé. Il a été remplacé par une analyse prudente, voire dérangeante, de l’écart entre les slides marketing et la réalité opérationnelle.

Martin Kuppinger, cofondateur et analyste principal de KuppingerCole, a observé : « La souveraineté du cloud occupait une place encore plus importante à l’EIC cette année, mais les discussions se sont divisées sur le besoin et l’endroit où elle est nécessaire. Le consensus est le suivant : la souveraineté n’a pas de valeur en soi ; le niveau requis dépend du cas d’usage et de l’évaluation des risques. Il n’existe pas de modèle binaire de souveraineté. »

Analyse technique : pourquoi le cloud souverain ne résout pas les problèmes de contrôle

Lorsque les entreprises parlent de cloud souverain, elles pensent généralement à la résidence des données – où les données sont stockées. Datacenter en Europe, juridiction européenne. Mais la résidence des données n’est que le début de la conversation, pas la fin.

Les questions plus épineuses concernent le contrôle : qui détient les clés de chiffrement ? Qui peut légalement forcer l’accès et en vertu de quelle loi ? Qui peut voir les métadonnées, les journaux d’accès et la télémétrie des charges de travail ? Lorsque vous exécutez une inférence IA ou un entraînement de modèle sur une plateforme de cloud souverain, qui contrôle le registre des modèles, les pipelines de données d’entraînement et les journaux de sortie ? Lorsqu’un agent IA agit de manière autonome – planifier des charges de travail, configurer des ressources, prendre des décisions d’accès – sur quelle architecture cet agent s’exécute-t-il ? Qui peut observer son comportement ?

Ces préoccupations ne sont pas hypothétiques. Le CLOUD Act de 2018 autorise les autorités américaines à contraindre les entreprises américaines à fournir des données stockées à l’étranger, indépendamment de l’emplacement des serveurs. Les offres européennes de cloud souverain des hyperscalers américains résolvent ce problème par la séparation opérationnelle, des entités juridiques européennes et des clés gérées par le client, mais ces structures sont nouvelles, partiellement testées et varient considérablement d’un fournisseur à l’autre.

Le BSI allemand a encore relevé la barre.Le BSI allemand a encore relevé la barre. En avril 2026, l'agence a publié les *Cloud Computing Autonomy Criteria (C3A)* : le premier cadre rendant la souveraineté cloud opérationnelle au niveau technique, incluant des scénarios de déconnexion, des exigences de résidence des employés, et des clauses spéciales pour la reprise fédérale de l'exploitation cloud dans des scénarios de défense. Bien que formellement non contraignants, ces critères sont largement attendus comme la référence de facto pour les marchés publics fédéraux allemands, et pourraient servir de modèle pour un cadre européen dans le pipeline législatif. Pour les CISO américains, la direction est claire : la définition réglementaire de la souveraineté cloud se resserre, et l'écart entre « les données en Europe » et la « souveraineté opérationnelle » ne fera que se creuser.

L'identité est l'endroit où la souveraineté réside réellement

Le thème le plus explicite de l'EIC 2026 est le suivant : l'identité – et non la frontière réseau ou la résidence des données – est l'endroit où la souveraineté cloud soit s'établit, soit s'effondre.

Jason Keenaghan, responsable de la stratégie de gestion des identités chez Thales, le dit directement : « L'identité passe d'une fonction IT à une infrastructure réglementée. La question la plus importante de la prochaine décennie est : qui contrôle ? »

Pour les CISO américains, cette transition est très réelle : la gouvernance des identités passe d'un simple pipeline IT à un plan de contrôle réglementé, qui sera de plus en plus scruté par les auditeurs, les régulateurs et même les clients d'entreprise dans les appels d'offres. « Qui contrôle » n'est plus une question philosophique, mais une question contractuelle.

Le problème est le suivant : vous pouvez placer vos données dans un centre de données à Francfort et utiliser des clés gérées par le client, mais si la gouvernance des identités est faible – vous ne savez pas quels utilisateurs humains, comptes de service et agents IA ont quels accès et à quelles conditions – votre posture de souveraineté est aussi forte que le maillon d'identité le plus faible. Un compte privilégié compromis ne se soucie pas de la résidence des données.

Cela est particulièrement grave pour les charges de travail IA. Les systèmes IA autonomes – des modèles qui agissent de manière autonome, appellent des API, configurent des ressources, accèdent à des données – créent une nouvelle classe d'identités non humaines que la plupart des systèmes IAM des entreprises n'ont jamais été conçus pour gérer. Prenons un exemple concret que j'ai vu chez un client : un agent de déploiement basé sur un LLM, disposant d'un accès permanent au cluster Kubernetes qu'il produit. Il planifie des charges de travail de manière autonome, configure des ressources et prend des décisions d'accès. Si cet agent s'exécute sur une infrastructure cloud souveraine, mais que son identité – identifiants, autorisations, pistes d'audit – n'est pas correctement gouvernée, votre posture de souveraineté est exactement aussi forte que le maillon le plus faible de la chaîne d'accès de cet agent. Si vous exécutez aujourd'hui un agent similaire dans une région cloud américaine, la même zone d'ombre d'identité existe – même si vous n'avez jamais touché à la région cloud souveraine.Sebastian Rohr, consultant IAM et membre d'IDPro, fort de vingt ans d'expérience dans l'architecture de gouvernance des identités, a résumé les exigences pratiques pour la gouvernance des agents d'IA : « Chaque agent nécessite une identité non humaine attribuée. Un modèle de délégation « agir pour le compte » solide doit être établi. Une piste d'audit doit être fournie via l'intégration SIEM. Pas d'informations d'identification à long terme ni de clés API – uniquement des informations d'identification temporaires. Authentification contextuelle et contrôle d'accès fin. Les agents doivent être gérés comme de véritables identités. Et une fois cette base en place : ré-authentification continue basée sur les risques, avec des capacités de révocation en temps réel. Avons-nous toutes ces capacités partout aujourd'hui ? Pas nécessairement – mais concevoir une architecture qui les supporte ? C'est tout à fait possible. »

Pour les agents d'IA, la question pratique est simple : pouvez-vous lister chaque agent fonctionnant dans votre environnement, gérer ses autorisations et révoquer son accès en temps réel ? Si ce n'est pas le cas, vous n'avez pas vraiment le contrôle sur la charge de travail – quel que soit le cloud régional où elle s'exécute.

Analyse d'impact pour l'entreprise : évaluation coûts-avantages du cloud souverain

Pour les RSSI américains gérant des activités, des filiales ou des clients européens, la question pratique n'est pas de savoir si le cloud souverain est philosophiquement correct, mais si le coût et la complexité supplémentaires réduisent suffisamment les risques pour des charges de travail spécifiques. La plupart des organisations avec lesquelles j'ai travaillé sur-appliquent le cloud souverain à des charges de travail qui n'en ont pas besoin, tout en le sous-appliquant à celles qui en ont besoin.

Voici un cadre de travail, issu de deux années de déploiement pratique en Europe, servant d'outil de classification rapide :

| Type de charge de travail | Nécessite un cloud souverain ? | Raison | |-------------------------------|------------------------------------|------------| | Données financières réglementées, PII clients (résidents UE) | Oui | Exigence légale de résidence des données, le cloud souverain offre une protection juridique claire | | Données d'entraînement IA (contenant des informations personnelles sensibles) | Selon le cas | Si les données sont anonymisées et la gouvernance des identités en place, un cloud non souverain peut être envisagé ; le cloud souverain offre une marge juridique supplémentaire | | Environnements de développement/test internes (non production) | Non | Risque plus faible, la prime du cloud souverain n'en vaut pas la peine | | Agents IA prenant des décisions autonomes (impliquant le contrôle d'accès) | Non, mais nécessite une gouvernance des identités forte | Le cloud souverain ne contrôle pas le comportement des agents ; la gouvernance des identités est essentielle | | Reprise après sinistre/sauvegarde (région non sensible) | Non | Rapport coût-bénéfice faible, sauf exigence de conformité claire |

Comme le dit Kuppinger : « Au sein d'une organisation, différents cas d'utilisation ont différents besoins en matière de niveau de souveraineté – c'est la norme, pas l'exception. »

Analyse du marché concurrentiel : réponses des fournisseurs de cloud et des fournisseurs de gouvernance des identités`

Analyse du marché concurrentiel : réponses des fournisseurs de cloud et de gouvernance des identités

Dans le paysage actuel du marché, les fournisseurs de cloud comme AWS, Azure et Google Cloud lancent des produits de cloud souverain pour tenter de répondre aux exigences réglementaires. Cependant, ces produits traitent principalement de la résidence des données et de l’isolement opérationnel, sans résoudre pleinement les problèmes profonds de gouvernance des identités.

Parallèlement, le marché de la gouvernance des identités s’intensifie. Les fournisseurs IAM tels que Thales, SailPoint et CyberArk intègrent la gestion des identités des agents IA dans leurs feuilles de route produit. Les solutions natives Kubernetes comme Spiffe/Spire gagnent également en attention.

Pour les entreprises, la bonne stratégie n’est pas un choix binaire : le cloud souverain et la gouvernance des identités sont complémentaires. Le cloud souverain offre une garantie juridique de résidence des données, tandis que la gouvernance des identités fournit un contrôle opérationnel réel. Investir dans un seul des deux peut entraîner une exposition aux risques.

Tendances sectorielles : la gouvernance des identités devient le nouveau plan de contrôle des charges de travail IA

À en juger par le programme de l’EIC 2026, la tendance est claire : la sécurité IA, le tissu d’identités, la gestion des identités des charges de travail et l’agilité cryptographique sont des sujets brûlants. Le cloud souverain est devenu l’infrastructure par défaut, et les conversations des praticiens se tournent vers ce qui est construit au-dessus et qui contrôle cette couche.

Pour les entreprises américaines, la règle de divulgation de cybersécurité de la SEC (décembre 2023), les directives de sécurité IA de la CISA et les propositions de réglementation IA au niveau des États créent des pressions similaires à celles de l’Europe. Si vous exécutez des charges de travail IA pour des clients européens, exploitez une filiale européenne, ou faites simplement face à la question de savoir où placer les données sensibles d’entraînement IA et les sorties de modèles — vous êtes déjà dans cette conversation. L’expérience européenne est votre aperçu.

CloudTechDaily Insight

L’expérience du cloud souverain en Europe a révélé une leçon cruciale : la résidence des données n’équivaut pas au contrôle opérationnel. Lorsque les agents IA, les comptes de service et les charges de travail automatisées deviennent le cœur de l’infrastructure informatique des entreprises, la gouvernance des identités est le véritable plan de contrôle.

Pour les RSSI et les DSI, cela signifie : ne considérez pas le cloud souverain comme une solution magique de gouvernance. C’est un outil juridique, pas un outil opérationnel. Le véritable investissement doit porter sur l’architecture de gouvernance des identités — capable de gérer les identités humaines et non humaines, de prendre en charge la révocation en temps réel et l’authentification continue basée sur les risques. Sinon, vos charges de travail IA restent exposées aux mêmes risques, quel que soit le cloud où elles s’exécutent.

À l’avenir, la gouvernance des identités deviendra un pilier central de la stratégie informatique des entreprises, aussi important que la sécurité IA, la conformité et l’architecture cloud. Les entreprises qui élèvent d’abord la gouvernance des identités au rang de sujet de conseil d’administration obtiendront un véritable contrôle à l’ère de l’IA. `