27 mai : Souveraineté technologique de l’UE en question – GCC High à Francfort hors service

Depuis près de dix ans, la souveraineté des données européennes fait l’objet de débats devant les tribunaux, lors de conférences et dans les clauses contractuelles. Le 27 mai 2026, elle devrait entrer dans le droit des marchés publics de l’UE.

Résumé

1. Bruxelles passe de la rhétorique à l’application. Le 27 mai 2026, la Commission européenne devrait présenter un « Tech Sovereignty Package » qui restreindra l’utilisation de fournisseurs cloud américains par les gouvernements des États membres de l’UE pour les données sensibles du secteur public dans la santé, la finance et la justice.
2. Le CLOUD Act est la cause désignée. En vertu du CLOUD Act de 2018, la justice américaine peut obliger les fournisseurs dont le siège est aux États-Unis à divulguer des données, où qu’elles soient stockées. La résidence des données en Europe ne résout pas ce problème structurel.
3. Les organisations européennes s’y attendaient déjà. Quarante-quatre pour cent considèrent que les garanties de souveraineté des fournisseurs constituent un obstacle, et 32 % ont signalé un incident de souveraineté au cours des 12 derniers mois — les transferts transfrontaliers non autorisés étant le type d’incident le plus fréquent.
4. L’architecture prime sur les contrats. Schrems II a établi il y a neuf ans que les contrats ne peuvent pas prévaloir sur les lois d’accès des gouvernements étrangers. Le package de la Commission applique ce principe pour la première fois au niveau des marchés publics de l’UE.
5. « Une souveraineté prouvable » devient un prérequis pour les marchés publics. Les régulateurs attendront trois éléments : l’application de la résidence au niveau de l’architecture, des preuves exportables, et des procédures testées pour répondre aux demandes d’accès des gouvernements.

Selon un article de CNBC, la Commission européenne prépare un « Tech Sovereignty Package » qui restreindra l’utilisation de fournisseurs cloud américains par les gouvernements des États membres pour les données sensibles du secteur public, en parallèle du Cloud and AI Development Act et du Chips Act 2.0. Ces mesures ne banniront pas totalement les fournisseurs américains, mais limiteront leur utilisation dans la santé, la finance et la justice — précisément les domaines au cœur de la tension RGPD/CLOUD Act depuis 2018.

Des responsables européens ont expliqué à la presse que l’idée centrale est de définir des secteurs devant être hébergés sur des infrastructures cloud européennes. Une fois présenté, le package devra être approuvé par les 27 États membres. C’est la première fois que la Commission fait passer le débat sur la souveraineté du risque théorique à une restriction concrète dans les marchés publics.

Ce qui change le 27 mai, ce n’est pas la loi sous-jacente. Le CLOUD Act américain reste en vigueur. Le RGPD reste en vigueur. Schrems II reste en vigueur. Ce qui change, c’est que les organisations européennes ne pourront plus prétendre qu’un cloud contrôlé par les États-Unis, mais hébergé à Francfort, est équivalent à une solution souveraine. La Commission va rendre cette distinction contraignante pour le secteur public. Le secteur privé suivra, car les standards d’achat font loi.

Ce à quoi la Commission répond réellement

Le Tech Sovereignty Package n’arrive pas par hasard. Il s’agit d’une réponse institutionnelle à une série de révélations qui ont discrètement modifié la perception européenne des fournisseurs cloud américains au cours des 18 derniers mois.

Une audition au Sénat français en 2025 a abouti à un aveu qui a fait écho dans les cercles politiques européens : même avec une résidence des données en Europe, un fournisseur dont le siège est aux États-Unis ne peut garantir que les autorités américaines ne demanderont jamais l’accès aux données de l’UE. Comme le souligne l’analyse de Databalance sur la souveraineté de Microsoft en 2026, la réalité juridique reste inchangée : aucune loi n’annule l’effet extraterritorial du CLOUD Act américain.

Puis est venue l’enquête de ProPublica sur l’autorisation FedRAMP de Microsoft GCC High, publiée en mars 2026. L’enquête a révélé que les examinateurs FedRAMP doutaient de la sécurité globale du système avant de l’autoriser tout de même, invoquant le fait que des agences fédérales l’utilisaient déjà. Comme le rapporte ProPublica, l’équipe a identifié des problèmes fondamentaux pour la gestion des risques, notamment la correction rapide des vulnérabilités et le scan de vulnérabilités.

Les régulateurs européens ont lu cette enquête. Ils ont aussi suivi le Digital Sovereignty Summit de Microsoft à Bruxelles en avril 2026, où l’entreprise a redéfini la souveraineté comme une discipline continue de gestion des risques, et non comme un état acquis — reconnaissant ainsi que les garanties fondées sur la localisation ne suffisent plus.

La Commission codifie désormais ce que les organisations européennes avaient déjà acté sur le terrain.

Les données qui ont anticipé ce moment

Depuis deux ans, les organisations européennes expliquent aux chercheurs que les contrats ne suffisent pas à résoudre leur problème de souveraineté. Kiteworks 2026 Data Security and Compliance Risk: Data Sovereignty in Europe a interrogé 286 professionnels IT et sécurité au Canada, au Moyen-Orient et en Europe, et a mis en lumière ce décalage avec des chiffres précis.

Quatre-vingts pour cent des répondants européens se disent bien ou très bien informés sur les exigences de souveraineté. Pourtant, 32 % ont connu un incident de souveraineté au cours des 12 derniers mois. Le type d’incident le plus fréquent : les transferts transfrontaliers non autorisés, suivis par les enquêtes réglementaires, les violations de données à impact souveraineté et les défaillances de conformité des tiers.

Le rapport Europe Sovereignty tire la conclusion explicitement : la maturité réglementaire réduit, mais n’élimine pas les incidents. Le problème restant est opérationnel, non informationnel — et le résoudre nécessite de l’architecture, pas davantage de sensibilisation. Quarante-quatre pour cent des répondants citent les garanties de souveraineté des fournisseurs comme principal obstacle, le taux le plus élevé de toutes les régions étudiées, remettant en cause l’idée que des data centers européens suffisent à régler le problème.

Vingt-huit pour cent des répondants européens déclarent désormais des budgets annuels de souveraineté supérieurs à 5 millions d’euros. Parmi les organisations de plus de 10 000 salariés, plus de 70 % appartiennent aux plus gros budgets. Les investissements se concentrent sur les leviers permettant un contrôle prouvable : application de la résidence des données, gestion des clés de chiffrement, automatisation des politiques d’accès et exportation des journaux d’audit. Les organisations avaient déjà commencé à investir pour combler le fossé que la Commission s’apprête à formaliser.

Pourquoi « GCC High à Francfort » n’a jamais pu passer ce test

La défense la plus courante des fournisseurs américains pour les charges de travail européennes consiste à proposer une enclave souveraine : un produit cloud américain, opéré dans des data centers européens, par du personnel européen, sous gouvernance européenne. Microsoft GCC High est l’exemple phare pour les charges de travail du gouvernement américain, et ses équivalents commerciaux — Microsoft Cloud for Sovereignty, AWS European Sovereign Cloud, Google Cloud Sovereign Solutions — suivent le même schéma architectural en Europe.

Le Tech Sovereignty Package part du constat que ce modèle ne résout pas le problème structurel. La géographie n’est pas la juridiction, et une enclave opérée par une entité contrôlée par les États-Unis reste soumise au CLOUD Act, quel que soit le pays où se trouvent ses serveurs.

La version technique du problème concerne la gestion des clés. Tant qu’un fournisseur dont le siège est aux États-Unis détient, gère ou peut être contraint de récupérer les clés de chiffrement des clients, la localisation des données n’a plus d’importance opérationnelle. La fonctionnalité Customer Key de Microsoft illustre ce fossé : les clients peuvent apporter leurs propres clés, mais Microsoft conserve des moyens opérationnels de déverrouiller les données pour assurer le service. Cela suffit à satisfaire une demande du CLOUD Act, mais pas un régulateur qui lit attentivement Schrems II.

La Commission s’oriente vers une définition de la souveraineté qui exige trois éléments que le modèle d’enclave ne peut pas garantir simultanément : séparation cryptographique de l’accès fournisseur, immunité juridictionnelle face au droit extraterritorial, et preuves exportables que la résidence a bien été appliquée.

À quoi ressemble « une souveraineté prouvable » quand l’application devient concrète

Le rapport Europe Sovereignty présente la réponse opérationnelle sous forme de trois piliers architecturaux. Le Tech Sovereignty Package fera de chacun d’eux une exigence pour les marchés publics.

Contrôles. Application de la résidence, gestion des clés de chiffrement et politiques d’accès qui empêchent tout mouvement transfrontalier non autorisé au niveau de l’architecture — et non du contrat. Les organisations doivent pouvoir démontrer que les données ne peuvent physiquement pas quitter une juridiction définie sans événement explicite, journalisé et validé par une politique.

Preuves exportables. Journaux d’audit exportables, logs de résidence des données et reporting de conformité permettant de satisfaire les régulateurs à la demande. Cinquante-cinq pour cent des répondants européens prévoient d’investir dans l’automatisation de la conformité dans les deux prochaines années, et 51 % dans les contrôles techniques. L’enjeu commun : la collecte manuelle de preuves ne passe pas à l’échelle sur DORA, NIS 2, le Data Act et le EU AI Act en même temps.

Préparation à la réponse. Procédures testées pour les demandes d’accès gouvernementales, les défaillances de fournisseurs tiers, les Transfer Impact Assessments et les scénarios de conformité Schrems II. Trente-six pour cent des répondants européens citent déjà les évolutions géopolitiques — notamment les changements de politique américaine — comme principale préoccupation. Les organisations qui ont testé ces procédures traverseront la période d’application de la Commission sans remettre en cause leur position d’achat. Celles qui ne l’ont pas fait découvriront le fossé lors de l’audit.

L’approche Kiteworks : une architecture qui tient là où les contrats échouent

C’est le moment architectural pour lequel la gouvernance au niveau des données a été conçue. Kiteworks propose un plan de contrôle sécurisé, fondé sur le principe que la souveraineté ne peut pas être déléguée à une promesse contractuelle du fournisseur. Les options de déploiement — sur site, cloud privé, hybride ou hébergement à locataire unique — permettent aux organisations de conserver le contenu sensible exclusivement dans des infrastructures de l’UE, indépendamment des fournisseurs dont le siège est aux États-Unis et soumis au CLOUD Act.

La plateforme applique trois contrôles qui seront valorisés par le package de la Commission. La gestion des clés de chiffrement peut être assurée par le client dans la juridiction, avec des modules cryptographiques validés FIPS 140-3 et un double chiffrement au repos — au niveau des fichiers et des disques, avec des clés distinctes. Les politiques d’accès sont appliquées au niveau de l’infrastructure via ABAC et RBAC, chaque demande étant authentifiée et autorisée selon des règles basées sur les attributs avant tout accès aux données. Les journaux d’audit infalsifiables sont transmis au SIEM en temps réel, sans limitation ni délai, produisant ainsi les preuves exportables que les régulateurs exigeront de plus en plus.

Le Secure MCP Server et l’AI Data Gateway étendent cette même gouvernance aux interactions des agents IA, afin que la posture de souveraineté de l’organisation ne s’effondre pas lorsque des workflows IA manipulent les mêmes données réglementées. Chaque requête IA est authentifiée, autorisée, chiffrée et journalisée avec les mêmes contrôles au niveau des données que pour les utilisateurs humains — les obligations GPAI de l’EU AI Act et les exigences de résidence du Tech Sovereignty Package étant respectées grâce à cette architecture.

Ce que les organisations doivent faire avant le 27 mai

Première étape : cartographier chaque charge de travail traitant des données personnelles sensibles en fonction de la portée juridictionnelle réelle de son fournisseur cloud, et pas seulement de la localisation du data center. Si l’entité de contrôle a son siège aux États-Unis, la charge de travail est exposée au CLOUD Act, quelle que soit la géographie. Selon le rapport Kiteworks Europe Sovereignty, le constat que 32 % des organisations européennes ont connu un incident de souveraineté l’an dernier constitue le minimum de ce que la Commission examinera.

Deuxième étape : établir la gestion des clés de chiffrement hors de portée du fournisseur pour les charges de travail identifiées à l’étape précédente. Les clés gérées par le client mais détenues par le fournisseur cloud ne constituent pas une gestion des clés. La véritable gestion signifie que le matériel cryptographique est détenu par le client ou un tiers isolé juridiquement, et que le fournisseur ne peut pas y accéder par aucun moyen opérationnel, technique ou légal.

Troisième étape : automatiser la génération des preuves d’audit. Selon le rapport Kiteworks Europe Sovereignty, 55 % des répondants européens prévoient d’investir dans l’automatisation de la conformité. La raison est simple : la réconciliation manuelle des preuves sur DORA, NIS 2, RGPD, le Data Act et l’AI Act n’est pas viable à grande échelle, et le Tech Sovereignty Package ajoutera un sixième ensemble d’obligations que les fournisseurs du secteur public devront respecter.

Quatrième étape : répéter les procédures Schrems II et d’accès gouvernemental. Documentez la procédure à suivre lorsqu’une agence américaine émet un mandat CLOUD Act contre votre fournisseur, lorsqu’un régulateur demande des preuves de mouvement transfrontalier, ou lorsqu’un fournisseur tiers de votre supply chain subit un incident de souveraineté. Le rapport Kiteworks Europe Sovereignty montre que 36 % des répondants européens citent déjà les évolutions géopolitiques comme source d’inquiétude. Les organisations ayant testé leurs procédures absorberont le prochain cycle de révélations sans perturbation.

Cinquième étape : faire de la souveraineté un atout pour les marchés publics. Le rapport Kiteworks Europe Sovereignty révèle que 51 % des répondants européens citent déjà la confiance accrue comme bénéfice de la souveraineté, et 33 % l’avantage concurrentiel. Le Tech Sovereignty Package transformera ce signal en prérequis pour les marchés publics, et de plus en plus pour les achats privés réglementés. Les organisations capables de démontrer la résidence, la gestion des clés et la fourniture de preuves exportables à la demande remporteront les contrats que d’autres perdront.

La Commission a fixé la date. La réponse architecturale est connue depuis neuf ans. Le 27 mai, le reste du marché devra prouver qu’il a suivi le dossier.