Microsoft Sovereign Cloud : l'architecture de la confiance fabriquée

Le cloud souverain comme opération de communication géopolitique

Fait établi. Les trois hyperscalers américains, AWS, Microsoft Azure et Google Cloud, détiennent collectivement entre 65 et 70 % du marché européen du cloud d'entreprise, selon les données de Synergy Research Group (Q4 2024). Microsoft revendique une présence en Europe depuis plus de quarante ans, ce que Brad Smith a lui-même rappelé dans son billet de blog du 30 avril 2025, intitulé "Microsoft's commitment to Europe is unwavering". Cette position historique constitue le contexte dans lequel il faut lire les annonces récentes sur l'offre dite "Sovereign Cloud" : Azure Local disconnected, Microsoft 365 Local disconnected, Foundry Local.

Lecture analytique. Ces annonces ne constituent pas une réponse technique à un problème technique. Elles constituent une réponse commerciale à une pression géopolitique datée et identifiable. Le retour de Donald Trump à la Maison-Blanche en janvier 2025, les déclarations répétées sur l'instrumentalisation des relations économiques transatlantiques, et les questions croissantes des directeurs des systèmes d'information (DSI) publics européens sur leur exposition ont créé une demande de réassurance à laquelle Microsoft répond. Le billet de Brad Smith, dans lequel il promet de "contester toute demande gouvernementale concernant l'accès aux données des clients du secteur public ou des entreprises de l'UE, lorsqu'il existe une base juridique pour le faire", est lui-même révélateur : on ne formule pas de telles promesses dans un contexte serein.

Inférence. Ce qui se joue n'est pas une avancée vers la souveraineté numérique européenne mais la mise en scène d'une telle avancée pour préserver un marché. Les deux opérations produisent des effets radicalement différents sur la posture de sécurité réelle des organisations concernées.

L'aveu dissimulé dans le communiqué de presse

Fait établi. La promesse centrale de Brad Smith est formulée ainsi : Microsoft s'engage à "contester toute demande gouvernementale concernant l'accès aux données des clients du secteur public ou des entreprises de l'UE, lorsqu'il existe une base juridique pour le faire." Cette formulation est extraite mot pour mot du billet de blog officiel de Microsoft du 30 avril 2025. Elle est la pierre angulaire de la communication souveraineté de l'entreprise en Europe.

Sa précision est sa limite. Trois régimes juridiques distincts méritent d'être distingués, car un juriste spécialisé noterait à juste titre qu'ils ne fonctionnent pas de la même façon.

Le Cloud Act (Clarifying Lawful Overseas Use of Data Act, 2018, P.L. 115-141) oblige les fournisseurs cloud américains à répondre aux demandes d'accès aux données émises par les autorités américaines, indépendamment du lieu de stockage physique. Il prévoit en théorie un mécanisme de contestation lorsque la divulgation entrerait en conflit avec le droit d'un pays tiers ayant conclu un "executive agreement" avec les États-Unis, mais aucun tel accord n'a été finalisé avec l'Union européenne à ce jour, ce qui rend ce recours inopérant en pratique pour les données européennes.

Les National Security Letters (NSL), encadrées principalement par 18 U.S.C. § 2709 (Electronic Communications Privacy Act, modifié par le USA PATRIOT Act), constituent un régime distinct : elles sont émises par le FBI sans contrôle judiciaire préalable et s'accompagnent d'une interdiction légale de divulgation (gag order) que le destinataire ne peut lever qu'à l'issue d'une procédure judiciaire longue et aléatoire. Ce régime a été partiellement contraint par le USA FREEDOM Act de 2015, qui a introduit une possibilité de contestation différée, mais le secret initial reste la règle.

FISA Section 702 (50 U.S.C. § 1881a) constitue un troisième régime, distinct des NSL : il autorise la NSA à collecter des communications de ressortissants étrangers via des fournisseurs de services de communication électronique américains, sous supervision de la Foreign Intelligence Surveillance Court (FISC). Le champ exact de ce que Microsoft peut contester sous Section 702 fait l'objet d'une jurisprudence encore incomplète, la FISC étant une juridiction secrète dont les décisions sont rarement rendues publiques.

Ce que ces trois régimes ont en commun, dans la lecture retenue par la doctrine majoritaire en droit public américain : ils créent des obligations auxquelles une entreprise de droit américain ne peut légalement se soustraire, et ils comportent des mécanismes de secret qui limitent ou retardent substantiellement la possibilité de contester. Microsoft l'a lui-même reconnu : en 2013, lors des premières révélations Snowden, l'entreprise a confirmé avoir reçu des NSL auxquelles elle n'avait pu faire aucune réponse publique.

Lecture analytique. Ce n'est pas une critique de Microsoft comme acteur de mauvaise foi. C'est un constat structurel : une entreprise de droit américain, cotée au NASDAQ, dont le siège, les dirigeants et l'essentiel de l'infrastructure capitalistique relèvent de la juridiction américaine, ne peut pas légalement s'exempter des obligations qu'impose cette juridiction. Promettre le contraire constituerait une fausse déclaration contractuelle. Microsoft, à son crédit, ne formule pas une telle promesse. Il en formule une autre, soigneusement construite pour donner l'apparence de la première.

Inférence. Les organisations européennes qui lisent "données restent en Europe, sous législation européenne" et en concluent qu'elles sont protégées des injonctions américaines ont mal lu le contrat. La localisation géographique des données ne modifie pas la juridiction applicable à l'entreprise qui les opère. L'arrêt Data Protection Commissioner v. Facebook Ireland Limited and Maximillian Schrems (C-311/18, 16 juillet 2020, "Schrems II") offre un cadre analytique utile : la CJUE y a jugé que le transfert de données personnelles vers les États-Unis ne pouvait être considéré comme protégé dès lors que la législation américaine, et en particulier FISA Section 702, permettait un accès disproportionné par les autorités américaines sans recours effectif pour les ressortissants européens, invalidant le Privacy Shield sur ce fondement.

Il faut être précis sur ce que cette analogie couvre et ce qu'elle ne couvre pas. Schrems II portait sur des transferts de données personnelles au sens du RGPD vers un pays tiers, il ne portait pas directement sur des infrastructures cloud hébergées en Europe. Les offres Azure Local déconnectées hébergent les données en Europe, ce qui les soustrait formellement à la problématique du "transfert" telle que la CJUE l'a examinée. Le problème résiduel, l'accès possible des autorités américaines via des injonctions sur l'opérateur américain, est structurellement analogue mais juridiquement distinct. Il relève davantage de la question de la responsabilité de traitement et du contrôle effectif que du droit des transferts stricto sensu. Un juriste spécialisé dirait que Schrems II illustre le problème sans l'épuiser dans ce contexte précis.

La dépendance aux correctifs : le talon d'Achille structurel

C'est ici que réside l'argument technique central, celui que les communiqués de presse n'abordent pas.

Fait établi. Un environnement dit "déconnecté" (air-gapped ou semi-air-gapped) n'assure une maîtrise réelle du cycle de vie logiciel que s'il peut produire lui-même ses correctifs de sécurité, en contrôler la chaîne de compilation et en valider l'intégrité de manière indépendante. Tel n'est pas le cas des offres Microsoft concernées. Azure Local disconnected, Microsoft 365 Local et Foundry Local restent des environnements dont les mises à jour de sécurité, incluant les correctifs critiques distribués mensuellement via le "Patch Tuesday", sont produites exclusivement par Microsoft Corporation à Redmond, signées par ses clés de chiffrement privées, et dont l'intégrité ne peut être vérifiée qu'en faisant confiance à l'émetteur. Cette architecture n'est pas une conjecture : elle est documentée dans les spécifications techniques publiques d'Azure Stack HCI et d'Azure Local, accessible sur docs.microsoft.com.

Lecture analytique. La dépendance aux correctifs n'est pas un détail opérationnel subordonné. C'est l'un des vecteurs d'attaque les plus documentés sur les infrastructures sensibles. L'affaire SolarWinds (décembre 2020) en offre la démonstration la plus claire : le logiciel Orion avait été compromis au niveau de sa chaîne de compilation entre mars et juin 2020 ; les mises à jour signées et distribuées normalement contenaient une porte dérobée (baptisée "SUNBURST") qui a affecté au minimum 18 000 organisations selon les estimations initiales de FireEye, dont le Trésor américain, le Département d'État, le DHS et des entités de l'OTAN. Le rapport post-incident de la CISA (Alert AA20-352A, 17 décembre 2020) a qualifié l'incident de "grave risque pour le gouvernement fédéral". L'attaque XZ Utils (CVE-2024-3094, mars 2024) a quant à elle montré qu'un acteur malveillant avait passé deux ans à contribuer à un projet open source avant d'y insérer une backdoor dans la bibliothèque de compression liblzma, affectant potentiellement des millions de serveurs Linux.

La leçon commune de ces incidents est précise : la confiance dans un environnement informatique ne peut pas s'arrêter à la frontière du datacenter. Elle doit remonter jusqu'à la chaîne de production du code. Or cette chaîne, pour l'intégralité des produits Microsoft, reste sous contrôle d'une entité soumise à la juridiction américaine.

Inférence. Qu'un environnement Azure Local soit physiquement installé dans un datacenter de Roubaix ou de Francfort ne modifie pas cette réalité : les binaires qui s'y exécutent ont été compilés à Redmond, et leur intégrité dépend de la fiabilité et de l'indépendance de l'émetteur. Ce n'est pas affirmer que Microsoft introduit des portes dérobées dans ses correctifs. C'est affirmer que l'architecture de confiance repose sur une hypothèse, l'intégrité de la chaîne de compilation Microsoft, que l'organisation cliente ne peut pas vérifier de manière indépendante, et que la déconnexion physique du datacenter ne fait rien pour lever.

Ce que "déconnecté" signifie réellement

Fait établi. Microsoft décrit Azure Local disconnected operations comme permettant de "faire tourner les infrastructures critiques avec les outils de gestion et de conformité d'Azure, sans avoir besoin d'être relié à son cloud." Cette formulation distingue la connexion réseau en temps réel (dont l'absence est présentée comme la garantie centrale) de la dépendance fonctionnelle à l'écosystème Microsoft, qui n'est pas abordée.

Un environnement Azure Local déconnecté du cloud public Microsoft reste fonctionnellement dépendant de Microsoft pour : les mises à jour du système d'exploitation (Azure Stack HCI / Windows Server) ; les correctifs des composants applicatifs (Exchange Server, SharePoint Server) ; la gestion des licences et des clés d'activation (à renouveler périodiquement) ; les mises à jour des modèles d'IA intégrés via Foundry Local, dont les performances se dégradent sans réentraînement ; et la supervision via Azure Arc, qui reste le plan de contrôle de l'environnement même en mode déconnecté. Ces éléments sont documentés dans la feuille de route publique d'Azure Local sur Microsoft Learn (dernière mise à jour : mars 2025).

Lecture analytique. Chacun de ces flux constitue un moment où du code produit par Microsoft entre dans l'environnement prétendument souverain. La déconnexion réseau permanente n'est d'ailleurs pas une option réaliste pour la majorité des organisations : sans synchronisation régulière avec les services Microsoft de gestion des licences, les environnements passent en "mode dégradé" puis perdent des fonctionnalités critiques. Le terme "déconnecté" décrit dans la pratique une architecture à faible connectivité, non une coupure totale.

Inférence. Le modèle économique de cette offre repose sur une formulation paradoxale : vous maîtrisez votre environnement, mais vous dépendez de nous pour maintenir cette maîtrise. La qualification SecNumCloud de l'ANSSI, le référentiel le plus robuste disponible en droit français pour les prestataires de cloud hébergeant des données sensibles, n'est pas atteignable dans ce cadre. L'ANSSI impose notamment que le prestataire soit en mesure de garantir l'absence de vecteur d'accès non autorisé, ce qu'un opérateur ne peut pas assurer s'il dépend d'un éditeur soumis à des injonctions extraterritoriales confidentielles pour ses mises à jour critiques. Ce point n'est pas contesté publiquement par Microsoft ni par ses partenaires français.

Le précédent PRISM et la mémoire institutionnelle

Fait établi. Les documents publiés par The Guardian et le Washington Post en juin 2013, tirés des archives transmises par Edward Snowden, ont documenté la participation de Microsoft au programme PRISM de la NSA (code name "PRISM", SIGAD US-984XN). Microsoft figurait dans les documents comme le premier fournisseur à avoir intégré le programme, dès 2007, avant Google (2009) et Apple (2012). Des documents ultérieurs publiés par Der Spiegel (décembre 2013) ont précisé que Microsoft avait coopéré avec la NSA pour permettre le contournement du chiffrement de son service Outlook.com. Microsoft a confirmé avoir reçu des National Security Letters mais contesté les modalités de leur exécution devant les tribunaux américains, avec un succès très partiel, les tribunaux ayant généralement validé les obligations de secret.

Lecture analytique. Ce précédent n'est pas invoqué pour établir une intention malveillante persistante. Il est invoqué pour établir un précédent structurel documenté : quand la législation américaine l'a exigé, Microsoft a fourni un accès à des données de clients européens sans en informer ces derniers, pendant plusieurs années. Le Cloud Act de 2018 n'a pas invalidé cette structure ; il l'a codifiée et étendue. La promesse de "contester les demandes lorsqu'il existe une base juridique" doit être lue à la lumière de ce précédent : dans le régime PRISM, la base juridique existait parfaitement, du point de vue américain. Le problème n'est pas l'absence de base juridique américaine. Le problème est le conflit entre cette base juridique américaine et les droits des ressortissants européens.

Inférence. Pour les organisations traitant des données sensibles, le précédent PRISM établit que le scénario d'un accès non déclaré n'est pas une hypothèse théorique : il s'est produit, à grande échelle, pendant plusieurs années, sans que les clients concernés en soient informés. La question n'est pas de savoir si un tel accès se reproduira. La question est de savoir si une architecture de confiance peut raisonnablement s'abstraire de ce précédent.

Le modèle Bleu : une rupture organisationnelle sans rupture technique

Fait établi. Microsoft s'est associé en France à Bleu, coentreprise créée par Orange et Capgemini, pour opérer les services Microsoft 365 et Azure dans un environnement "détenu et exploité de manière indépendante", selon le communiqué conjoint publié en janvier 2023. L'ambition déclarée est de répondre aux exigences de la qualification SecNumCloud. Google a suivi une architecture analogue en s'associant à Thales via la coentreprise S3NS.

Lecture analytique. Bleu est indépendant de Microsoft sur les plans capitalistique et opérationnel. Il n'est pas indépendant de Microsoft sur le plan technique : les logiciels déployés restent les produits Microsoft, dont le code source et les correctifs sont produits par l'entité américaine. La rupture de chaîne est organisationnelle, non technique. Le directeur général de l'ANSSI, Vincent Strubel, a indiqué publiquement en octobre 2023 que les offres de type "cloud de confiance" s'appuyant sur des technologies d'éditeurs non qualifiables SecNumCloud présentaient "un risque résiduel non nul" et que la qualification complète nécessiterait une évolution de l'architecture technique, non seulement organisationnelle. Ces déclarations ont été reprises dans le compte rendu de l'audition de la Commission des affaires économiques du Sénat (session 2023-2024).

Inférence. Le modèle Bleu représente vraisemblablement le meilleur compromis praticable à court terme pour des organisations publiques confrontées à l'absence d'alternative souveraine couvrant l'intégralité de leurs besoins fonctionnels. Il ne constitue pas une solution au problème de fond. Il constitue une gestion de risque partielle, présentée dans la communication commerciale comme une solution complète. Cette différence n'est pas sémantique : elle a des conséquences sur les décisions d'hébergement de données sensibles.

Ce que les défenseurs de l'offre répondent, et pourquoi cela ne suffit pas

Un article à charge qui ignore les contre-arguments sérieux manque à son propre standard épistémique. Les défenseurs de l'offre Microsoft Sovereign Cloud avancent quatre arguments qui méritent d'être examinés honnêtement.

Premier argument : Microsoft a effectivement résisté à des demandes gouvernementales. C'est vrai et documenté. Dans l'affaire United States v. Microsoft Corporation (2018), Microsoft avait refusé de livrer des données stockées en Irlande à la justice américaine, arguant de l'absence de compétence extraterritoriale. La Cour suprême a finalement rendu l'affaire sans objet après l'adoption du Cloud Act, ce qui constitue précisément la limite de cet argument : le Cloud Act a été adopté pour résoudre cette ambiguïté en faveur des autorités américaines. La résistance de Microsoft dans l'affaire irlandaise n'est pas reproductible dans un régime Cloud Act.

Deuxième argument : la déconnexion physique rend l'extraction massive en temps réel impossible. Cet argument est techniquement fondé pour les attaques de type exfiltration réseau continue. Il ne couvre pas les vecteurs identifiés dans cet article : une mise à jour signée contenant une fonctionnalité de collecte serait déployée lors d'une synchronisation périodique, pas en temps réel. La déconnexion permanente totale, la seule qui neutraliserait ce vecteur, est incompatible avec la maintenance opérationnelle des environnements concernés, comme exposé supra.

Troisième argument : aucun opérateur cloud 100 % souverain n'existe à l'échelle des besoins européens. C'est factuellement exact. OVHcloud, Outscale et d'autres prestataires SecNumCloud qualifiés couvrent une fraction du périmètre fonctionnel des hyperscalers. Cet argument justifie un recours pragmatique à des solutions imparfaites, il ne justifie pas de présenter ces solutions comme souveraines. La contrainte de l'offre ne doit pas effacer l'honnêteté sur ce qu'elle ne couvre pas.

Quatrième argument : les données classifiées ne sont de toute façon pas hébergées dans ces environnements. C'est le plus sérieux des contre-arguments, et celui qui devrait structurer le débat plutôt que de l'escamoter. Les offres Microsoft Sovereign Cloud ne visent pas les données classifiées de défense (qui relèvent de systèmes d'information opérationnels souverains, hors de tout cloud commercial). Elles visent les données dites "sensibles non classifiées" des administrations et des opérateurs d'importance vitale. C'est précisément dans cette catégorie que réside l'enjeu : les données de santé, les données fiscales, les communications internes des ministères, les données d'infrastructure critique. Le fait que ces données ne soient pas "classifiées" au sens strict ne les rend pas indifférentes à une collecte étrangère non déclarée.

La fenêtre Overton du cloud souverain

Fait établi. Le projet Gaia-X, lancé en juin 2020 à l'initiative franco-allemande comme architecture d'un espace de données européen souverain, a progressivement intégré en son sein AWS, Microsoft Azure et Google Cloud comme membres participants. En 2022, OVHcloud, Scaleway et plusieurs membres fondateurs ont exprimé publiquement leur désaccord avec cette orientation lors de l'assemblée générale de Gaia-X. Le PDG d'OVHcloud Michel Paulin a déclaré en novembre 2022 que Gaia-X risquait de "devenir un label de conformité que les hyperscalers américains pourraient s'approprier", selon des déclarations reprises par Le Monde Informatique.

Lecture analytique. La participation des hyperscalers américains à la définition des standards européens de souveraineté numérique n'est pas un accident de parcours. Elle est le résultat d'une stratégie d'influence documentée, consistant à élargir suffisamment la définition opérationnelle de "souveraineté" pour qu'elle reste compatible avec leurs architectures existantes. La rhétorique Microsoft sur Azure Local disconnected s'inscrit dans cette logique : elle déplace le débat de la question de la juridiction applicable (non résolue) vers la question de la localisation physique des données (résolue, mais insuffisante au regard de Schrems II).

Inférence. Les décideurs publics européens qui adoptent cette définition élargie ne font pas nécessairement un mauvais choix tactique, l'absence d'alternative crédible à grande échelle est une contrainte réelle, non une excuse rhétorique. Mais ils font un choix qui mérite d'être nommé avec précision : non pas la souveraineté, mais la gestion consciente d'une dépendance résiduelle. Quand le fournisseur définit les termes dans lesquels son offre est évaluée, la robustesse de l'évaluation en dépend.

Ce que la souveraineté exigerait réellement

Fait établi. La qualification SecNumCloud de l'ANSSI, le référentiel le plus exigeant disponible en droit français, impose notamment : que le prestataire ne soit pas soumis à une législation extraterritoriale permettant un accès non autorisé aux données hébergées (critère 19.6 du référentiel SecNumCloud v3.2) ; que le code source des composants critiques soit auditable par l'ANSSI ; et que la chaîne de mise à jour soit maîtrisée. Les seuls prestataires ayant obtenu ou étant en voie d'obtenir cette qualification pour des offres IaaS/PaaS couvrant des usages à grande échelle sont Outscale (Dassault Systèmes), OVHcloud (qualifié SecNumCloud pour son offre SecureZone) et 3DS OUTSCALE. Leur couverture fonctionnelle est significativement inférieure à celle d'Azure ou d'AWS.

Lecture analytique. Cette contrainte est réelle et ne doit pas être minimisée. Elle établit qu'au regard du référentiel SecNumCloud de l'ANSSI, cadre retenu ici comme grille d'évaluation, non comme seule définition possible, les offres Microsoft se situent dans la portion du spectre la moins souveraine compatible avec une communication commerciale utilisant ce terme. Un contradicteur pourrait légitimement arguer qu'il existe d'autres définitions opérationnelles de la "souveraineté réglementée", incluant par exemple des niveaux intermédiaires fondés sur la localisation des données combinée à des audits réguliers, qui placeraient ces offres dans une position moins défavorable. Ce débat de définition est précisément ce que cet article cherche à mettre en évidence, non à trancher par décret. Elle n'établit pas que les offres souveraines disponibles constituent des substituts immédiats et complets. L'enjeu pour les décideurs publics est précisément de naviguer entre ces deux réalités sans se laisser imposer l'une pour nier l'autre.

Inférence. L'enjeu politique réel n'est pas de choisir entre "Microsoft souverain" et l'absence de cloud. Il est d'arbitrer entre des niveaux de risque résiduel documentés, en refusant que le fournisseur impose son propre vocabulaire comme cadre d'évaluation. Ce n'est pas la même chose que rejeter l'offre Microsoft : c'est exiger la clarté sur ce qu'elle couvre et ce qu'elle ne couvre pas.

Conclusion analytique : la confiance fabriquée comme produit

Premier constat (fait établi). Le problème de l'extraterritorialité du droit américain, Cloud Act, FISA Section 702, National Security Letters, n'est pas adressé par les offres Microsoft Sovereign Cloud. La promesse de "contester les demandes lorsqu'il existe une base juridique" est littéralement vraie et structurellement insuffisante : les cas les plus sensibles sont précisément ceux où la base juridique américaine existe et où la contestation est légalement entravée.

Deuxième constat (lecture analytique). La dépendance aux correctifs et aux mises à jour logicielles constitue un vecteur structurel que la déconnexion physique du datacenter ne neutralise pas. L'argument n'est pas que Microsoft insère des portes dérobées dans ses correctifs. L'argument est que l'architecture de confiance repose sur une hypothèse que l'organisation cliente ne peut pas vérifier indépendamment, et que l'histoire récente de la cybersécurité (SolarWinds, XZ Utils) démontre que ce type d'hypothèse peut être exploité.

Troisième constat (inférence). La stratégie de communication des hyperscalers en Europe consiste à occuper le terrain sémantique de la souveraineté avant que les alternatives européennes ne soient en mesure de le disputer crédiblement. Les contre-arguments sérieux (résistance judiciaire partielle, absence d'alternative à grande échelle, périmètre limité aux données non classifiées) méritent d'être pris au sérieux, et ne suffisent pas à valider le terme "souverain" pour qualifier ces offres.

La confiance ne se construit pas par communiqué de presse. Au regard des critères retenus dans cet article, transparence du code, auditabilité de la chaîne de compilation, indépendance juridique de l'opérateur vis-à-vis de toute juridiction extraterritoriale, capacité à refuser une injonction étrangère sans subir de conséquences légales, critères qui correspondent pour l'essentiel au référentiel SecNumCloud v3.2 de l'ANSSI, pas à une définition arbitraire, les offres Microsoft Sovereign Cloud, dans leurs variantes actuelles, ne répondent pas à ce que le terme "souverain" implique dans ce cadre. Un acteur qui préférerait un référentiel plus souple serait en désaccord sur la définition, non sur les faits.