Le contrôle ne se promet pas

Un fournisseur peut promettre de ne pas livrer vos données. Il peut inscrire cette promesse dans un contrat. Il peut construire un centre de données dans votre pays, nommer des dirigeants locaux et qualifier son service de souverain.

Puis quelqu’un lui demande ce qui se passe si un autre gouvernement émet une demande légale.

Le 10 juin 2025, devant une commission d’enquête du Sénat, Anton Carniaux, directeur des affaires publiques et juridiques de Microsoft France, s’est vu demander s’il pouvait garantir que les données confiées à Microsoft par le biais de la commande publique française ne seraient jamais transmises aux autorités américaines sans l’accord explicite des autorités françaises.

Sa réponse fut brève : « Non, je ne peux pas le garantir. » Il a ajouté que, selon Microsoft, un tel transfert ne s’était pas produit dans les situations évoquées. ¹

Cette réponse ne prouvait pas que Microsoft avait livré des données. Elle montrait la limite d’une garantie.

C’est là que le mot souverain devient intéressant.

Si une capacité dépend de la permission de quelqu’un d’autre, elle peut être protégée, encadrée ou résiliente. Mais les limites de son indépendance restent à établir.

1. Une réponse honnête au mauvais moment

Lors de l’audition du 10 juin, Anton Carniaux a décrit les procédures de Microsoft pour examiner et contester les demandes. Il a démenti que Microsoft ait coupé les services cloud de la Cour pénale internationale. Le compte rendu doit se lire comme un témoignage, et non comme la preuve d’une coupure plus large qui a été alléguée. ¹

Quand on lui a demandé de garantir que des données ne seraient jamais divulguées sur demande américaine valable sans l’accord des autorités françaises, il a refusé de donner une garantie qu’il n’aurait pas pu tenir.

Ce n’est pas l’aveu d’un transfert passé. Ce n’est pas non plus la preuve que chaque produit ou configuration de Microsoft présente la même exposition.

C’est la rencontre de deux langages.

Le premier est celui du marketing : le service est sûr, local, conforme, résilient, souverain.

Le second est celui de l’autorité : un gouvernement donné peut utiliser un instrument juridique donné contre une entité juridique donnée, et cette entité peut être tenue d’agir.

La loi américaine est d’une franchise inhabituelle. Le titre 18, section 2713, introduit par le CLOUD Act, régit les obligations de divulgation portant sur ce qui se trouve en la possession, sous la garde ou sous le contrôle d’un fournisseur concerné, que ces éléments soient situés aux États-Unis ou ailleurs. ²

La loi ne dit pas que chaque serveur en Europe est automatiquement ouvert aux agences américaines. Mais installer un serveur sur le sol européen ne fait pas non plus disparaître toutes les obligations juridiques américaines qui s’y rattachent.

Les lignes directrices définitives du Comité européen de la protection des données, adoptées en juin 2025 sur l’article 48 du RGPD, traitent à part des conditions dans lesquelles les organisations peuvent répondre légalement aux demandes d’autorités de pays tiers. C’est précisément à cause de cette interface juridique que la juridiction ne se réduit pas à une épingle sur une carte. ³

La question pratique n’est ni « Faisons-nous confiance aux Américains ? » ni « Faisons-nous confiance aux Européens ? ».

C’est : quels acteurs disposent de droits opposables ou de moyens concrets pour faire advenir un résultat, et qu’est-ce qui les en empêche ?

2. Une promesse peut compter sans être absolue

Une analyse sérieuse doit décrire loyalement ce que Microsoft a réellement construit et promis.

En avril 2025, Microsoft a annoncé cinq engagements numériques envers l’Europe, dont une gouvernance européenne de l’exploitation, des capacités supplémentaires, des engagements de protection des données et la promesse de contester tout ordre de suspendre l’exploitation de son cloud en Europe. Son bilan de 2026 indique que l’engagement de résilience figure désormais dans des contrats avec des gouvernements européens et la Commission. Ce sont des dispositions commerciales et juridiques substantielles, pas rien. ⁴⁵

Microsoft décrit aussi une EU Data Boundary pour certains services aux entreprises. Sa propre documentation précise que l’engagement porte sur des catégories de données et des services définis, avec des cas limités où des informations peuvent tout de même être transférées hors du périmètre géographique ou consultées à distance. Cette nuance a sa place à côté du titre. ⁶

Et en février 2026, Microsoft a annoncé la disponibilité mondiale d’Azure Local disconnected operations et de Microsoft 365 Local en mode déconnecté, avec des modèles d’IA locaux pour des clients qualifiés. Une architecture réellement déconnectée peut modifier le risque opérationnel d’une coupure extérieure. Il n’est pas intellectuellement défendable de traiter une installation isolée comme si elle était forcément identique à un SaaS géré à l’échelle mondiale. ⁷⁸

Un acheteur devrait donc distinguer au moins trois situations techniques :

• Cloud public connecté. Infrastructure gérée, avec résidence locale des données et contrôles supplémentaires ; la dépendance à l’exploitation cloud plus large du fournisseur demeure.
• Service exploité localement ou par un partenaire. Des frontières contractuelles et de gouvernance différentes ; le plan de contrôle sous-jacent, les licences, les correctifs et les voies d’accès doivent être examinés de près.
• Déploiement privé déconnecté. Une meilleure capacité à poursuivre certaines charges de travail sans connexion au cloud ; droits d’utilisation des logiciels, approvisionnement en mises à jour, pièces de rechange, support et maintenance à long terme restent à tester.

Ce sont des catégories explicatives, pas un classement ni une certification indépendante de chaque produit Microsoft.

Affirmer que Microsoft ne pourra jamais offrir de capacités souveraines serait aussi léger que de prétendre que tout service Microsoft doté d’un centre de données européen est souverain.

La vraie question est : quel contrôle, dans quelles conditions, pour combien de temps.

3. Le moment où l’Europe a cessé de traiter le mot comme une seule dimension

Le 17 avril 2026, la Commission européenne a annoncé quatre attributions de marchés de cloud souverain, que les entités de l’Union peuvent utiliser dans le cadre d’un dispositif plafonné à 180 millions d’euros sur six ans. Les lauréats sont un partenariat entre Post Telecom, OVHcloud et CleverCloud, STACKIT, Scaleway et un consortium mené par Proximus qui s’appuie sur S3NS, Clarence et Mistral, y compris sur une technologie dérivée de Google Cloud. ⁹

Cette décision est utile parce qu’elle contrarie deux récits simplistes.

L’Europe n’a pas décidé que la souveraineté s’obtient en excluant toute technologie américaine. Elle n’a pas décidé non plus qu’une adresse européenne suffit.

La Commission a appliqué un Cloud Sovereignty Framework. En juin 2026, elle a expliqué que ce cadre repose sur 48 critères définis, regroupés en huit objectifs de souveraineté : stratégique ; juridique et juridictionnel ; données et IA ; opérationnel ; chaîne d’approvisionnement ; technologique ; sécurité et conformité ; durabilité environnementale. ¹⁰

L’approche distingue en outre des Sovereignty Effectiveness Assurance Levels, ou SEAL. La Commission décrit SEAL-2 comme la souveraineté des données, SEAL-3 comme un niveau supérieur d’autonomie technologique ou de résilience, et SEAL-4 comme la pleine souveraineté selon ses définitions. Le minimum exigé pour son appel d’offres de 2026 était SEAL-2 ; les trois offres reposant surtout sur des technologies européennes ont atteint SEAL-3, tandis que le consortium utilisant la technologie Google Cloud a atteint SEAL-2, selon la Commission. ⁹

L’évolution compte. Les acheteurs publics disposent désormais d’un vocabulaire explicite, de gradations et d’une manière documentée d’exiger des preuves.

Mais voici la distinction à laquelle je tiens : un cadre d’achat mesure un fournisseur à l’aune de critères définis. Il ne prouve pas que tout scénario situé hors de ces critères est impossible, ni qu’une évaluation faite aujourd’hui ne deviendra pas caduque après un rachat, une nouvelle réglementation ou une refonte de la plateforme.

Une note aide à décider.

Elle n’exorcise pas la dépendance.

4. Le mot qui manque, c’est preuve

Nous savons déjà que la propriété, la capacité de sortie et la résilience opérationnelle comptent. Mes volumes précédents, The Sovereignty Gap, Open Is Not Sovereign et The Exit Test, abordent ces problèmes sous des angles différents. ¹¹¹²¹³

Cet essai pose une question plus étroite, et peut-être plus inconfortable.

Comment un client devrait-il vérifier les promesses de souveraineté d’un fournisseur avant de lui confier des systèmes critiques ?

Je propose trois étapes. Elles valent pour les fournisseurs européens, suisses, américains, publics et privés.

Promesse

Formulez la promesse comme une proposition observable, avec son périmètre et sa durée. Pas « notre cloud est souverain ». Mais : « Pour cette version du service et cette catégorie de données, toutes les clés de déchiffrement nécessaires pour lire les données du client sont générées et conservées sous l’administration exclusive du client, sans accès permanent du fournisseur. » L’exemple est une question à vérifier, pas une affirmation sur un fournisseur nommé.

Une autre promesse peut porter sur la juridiction, l’exploitation, l’accès au code source, le micrologiciel, l’identité, le réseau ou les pouvoirs des sous-traitants. Les réunir sous un seul adjectif empêche toute vérification sérieuse.

Contrôle

Identifiez qui peut passer outre la frontière promise.

Qui peut changer ou récupérer une clé ? Qui peut modifier le plan de contrôle ? Qui peut désactiver un abonnement ou une licence ? Qui peut couper la gestion des identités ? Qui peut refuser des mises à jour essentielles ? Qui peut imposer un transfert ? Qui contrôle la structure capitalistique d’une société d’exploitation prétendument locale ?

Qu’un fournisseur ne fasse pas d’ordinaire une chose ne signifie pas qu’il ne puisse pas la faire.

Et qu’il puisse la faire n’implique aucun abus. Cela trace une frontière d’autorité qu’il faut mettre en balance avec le modèle de menace.

Preuve

Demandez la preuve la plus solide qui soit proportionnée au risque.

Certaines preuves sont documentaires : lois, documents sur l’actionnariat, registres des sous-traitants, clauses contractuelles, périmètre des audits indépendants, descriptions d’architecture et limites publiées.

D’autres doivent être techniques : clés détenues de manière indépendante, comportement du service en mode déconnecté, procédures de restauration, artefacts signés, journaux d’audit côté client, exercices de bascule menés devant témoins et validation des frontières d’accès administratif.

D’autres encore doivent être organisationnelles : instances de décision nommées, droits de renouvellement, administrateurs distincts, escalade documentée, plans de continuité chiffrés et cycles de revue.

Il ne s’agit pas d’une liste unique valable pour tous les services. Il s’agit d’exiger, pour chaque propriété promise, un moyen de la réfuter.

L’exigence de la méthode est délibérément inconfortable : si le fournisseur cessait de coopérer demain, quelles preuves resteraient utilisables par le client ou par un évaluateur indépendant ?

Cette question n’est pas une accusation. C’est une exigence d’architecture.

5. La preuve doit survivre à un changement de circonstances

Pensez au système documentaire d’un hôpital, à la messagerie d’une commune ou au logiciel de pilotage d’une usine.

Un fournisseur peut sincèrement vouloir exploiter un service pendant des décennies. Un gouvernement peut sincèrement n’avoir aucune intention d’ordonner une interruption. Une équipe technique peut sincèrement ne jamais vouloir modifier ses interfaces de manière incompatible.

Aucune de ces intentions ne constitue une garantie pour l’avenir.

Une institution doit savoir quelles propriétés elle peut faire respecter de manière indépendante et lesquelles dépendent encore d’une continuité commerciale et politique.

La distinction tient en cinq questions d’achat :

Où ? Quelles données et quelles fonctions de traitement résident physiquement où, et par où transitent les exceptions, les voies de support et les métadonnées ?

Qui ? Quelles entités peuvent exercer une autorité sociale, juridique ou technique sur les couches concernées ?

Comment ? Quels mécanismes réels tracent la frontière – clés détenues par le client, séparation du plan de contrôle, identité indépendante, déconnexion, accès au code source ou gouvernance opposable ?

Prouvez-le. Quelles preuves peut-on examiner, qui peut le faire, à quelle fréquence, avec quels droits d’accès et quelles limites ?

Qu’est-ce qui change ? Quelles hypothèses tombent si le fournisseur est racheté, sanctionné, coupé, contraint, mis en faillite, ou cesse simplement de livrer un produit ?

Ces questions ne supposent aucune préférence pour les fournisseurs locaux. Un fournisseur étranger compétent peut mieux répondre à un modèle de menace donné qu’une offre nationale encore immature. La géographie ne doit pas masquer une sécurité médiocre, et la souveraineté ne doit pas être confondue avec l’excellence dans chaque dimension technique.

L’inverse est vrai aussi : de meilleures fonctions, la fiabilité, des certificats de conformité ou des prix bas ne tranchent pas la question de l’indépendance.

Les lignes directrices du NIST sur les risques de la chaîne d’approvisionnement traitent des problèmes de visibilité et de contrôle qui surgissent lorsque des systèmes dépendent d’organisations extérieures à leur exploitant. Elles offrent une discipline utile, sans certifier aucune promesse de cloud souverain. ¹⁴

6. Les droits comptent ; la répétition aussi

Le règlement européen sur les données contient des mesures destinées à réduire les obstacles contractuels, techniques et commerciaux au changement de service de traitement de données. Il prévoit la suppression des frais de changement à partir du 12 janvier 2027, sous réserve de ses conditions et exceptions. ¹⁵

DORA, qui s’applique à des entités financières définies, exige des stratégies de sortie pour les services TIC soutenant des fonctions critiques ou importantes, ainsi que des tests appropriés et un réexamen périodique. Le règlement ne s’applique pas indistinctement à toute organisation européenne. ¹⁶

Ni un droit au changement ni une clause contractuelle ne rendent un système portable du jour au lendemain. J’ai longuement exploré ce problème dans The Exit Test. ¹¹

Ce qui est nouveau ici, c’est que la preuve du contrôle promis devrait exister tout au long de la relation avec le fournisseur, et non être produite pour la première fois en pleine urgence.

Pour un service critique, l’achat devrait définir :

• un inventaire versionné des promesses de souveraineté et de leurs limites ;
• un responsable désigné pour chaque promesse et chaque élément de preuve ;
• les circonstances dans lesquelles la promesse doit être réévaluée ;
• une assurance indépendante ou des exercices menés devant témoins, proportionnés au risque ;
• un traitement documenté des inconnues et des exceptions ; et
• une trace, au niveau de la direction, des dépendances acceptées en connaissance de cause.

Il s’agit d’une pratique de gouvernance proposée, non d’une affirmation selon laquelle le droit européen imposerait partout ces six points mot pour mot.

Une organisation solide peut accepter sciemment des éléments non souverains. L’échec n’est pas toujours la dépendance. C’est parfois de ne pas savoir quel type de dépendance on a acheté.

7. Ni drapeaux ni cynisme

Le débat sur la souveraineté comporte un danger politique.

Un drapeau peut tenir lieu d’analyse technique. Un exploitant peut avoir son siège en Europe tout en dépendant de logiciels, de clés, d’identités, de micrologiciels ou de capitaux contrôlés ailleurs. Un produit cloud peut être exploité localement alors que des capacités importantes restent dépendantes d’un fournisseur extérieur.

Mais il est tout aussi dangereux de balayer toute amélioration contractuelle ou technique comme de la communication. Une charge de travail déconnectée, une clé contrôlée localement ou une autorité d’exploitation réellement indépendante peuvent réduire des risques réels. Ces protections peuvent être partielles et valoir malgré tout la peine d’être mises en place.

Il faut aussi éviter de transformer une question de juridiction américaine en postulat selon lequel les États européens n’exigeraient jamais de divulgation. Les fournisseurs européens sont, eux aussi, soumis au droit. Il ne s’agit pas de choisir une nation qu’on imaginerait sans pouvoir sur les données. Il s’agit d’identifier les voies d’accès légales pertinentes, les conflits de lois, les protections et le contrôle dont dispose le client dans les circonstances précises.

Le langage d’achat le plus solide ne commence pas par la nationalité du fournisseur.

Il commence par la question à laquelle un système doit survivre.

Un cabinet de conseil multinational qui déplace des documents marketing a un modèle de menace. Un système national de communication d’urgence en a un autre. Une archive contenant des données personnelles sensibles en a peut-être encore un autre.

Ils n’ont pas tous besoin d’acheter le même niveau de souveraineté. Ils doivent en revanche savoir quel niveau ils revendiquent.

8. Qu’est-ce qui survit au fournisseur ?

La promesse d’un fournisseur peut être sincère et juridiquement opposable dans son périmètre. Un contrat peut modifier les incitations. Un audit indépendant peut renforcer l’assurance. Une note d’achat peut rendre les solutions comparables. Il ne faut rien jeter de tout cela.

L’erreur consiste à prendre l’un de ces éléments pour la réponse définitive.

Si nous prenons la souveraineté numérique au sérieux, les preuves doivent être assez solides pour survivre à un désaccord sur l’étiquette.

Demandez à l’architecte ce qui fonctionne encore si la connexion disparaît.

Demandez au juriste ce qui se passe quand deux juridictions se contredisent.

Demandez à l’exploitant qui détient l’autorité administrative.

Demandez à l’équipe de sécurité ce qui peut être inspecté de manière indépendante.

Demandez à l’acheteur quel scénario de défaillance justifiait de payer pour ces contrôles.

Et demandez à tous les cinq de signer la même promesse, clairement délimitée.

Alors l’adjectif commence à vouloir dire quelque chose.

Un fournisseur peut promettre la résilience. Il peut promettre de combattre une demande. Il peut promettre d’entretenir l’infrastructure. Ces promesses peuvent compter énormément.

Mais les propriétés les plus lourdes de conséquences de la souveraineté ne sont pas des promesses à admirer. Ce sont des frontières à démontrer.

Le contrôle ne se promet pas. Il se démontre.

Méthode et limites

Date d’arrêt des recherches : 14 octobre 2026. Sources publiques uniquement : cet essai n’a eu accès à aucun environnement client d’un fournisseur, à aucun contrat, à aucune inspection de clés, à aucun exercice de déploiement déconnecté ni à aucun test SEAL indépendant.

• Le témoignage au Sénat porte sur une contrainte juridique possible et sur les procédures décrites par Microsoft ; il ne prouve pas un transfert non autorisé effectif concernant les clients évoqués.
• Selon le compte rendu officiel, l’audition au Sénat a eu lieu le 10 juin 2025 ; certains comptes rendus secondaires donnent une autre date. La source primaire fait foi.
• L’exposition juridique au CLOUD Act varie selon l’entité, l’architecture, les droits d’accès et les circonstances ; une installation entièrement déconnectée et exploitée de manière indépendante ne peut pas être assimilée d’office à un service cloud hyperscale ordinaire.
• Les niveaux SEAL publiés par la Commission résultent de l’application de sa propre méthode ; ce ne sont pas des tests de terrain indépendants réalisés pour cet essai.
• Les institutions de l’UE et la Suisse ont des régimes juridiques et d’achat différents ; le cadre européen peut éclairer une analyse suisse, mais il n’est pas automatiquement du droit suisse.
• « Promesse, contrôle, preuve » est un cadre éditorial propre à l’auteur, et non une norme de certification reconnue ni un substitut à un conseil en achats, en droit ou en sécurité.

Sources