Le centre de données n'est pas un argument juridique

Le centre de données n'est pas un argument juridique

L’adresse sur la brochure

Il y a une phrase qui apparaît dans les appels d’offres cloud avec l’assurance d’un argument déjà conclu : les données seront stockées dans un centre de données européen. La phrase peut être vraie. Elle peut aussi faire bien plus de travail qu’elle ne peut en porter.

Un centre de données a une localisation. Cette localisation importe pour la sécurité physique, la résilience, l’énergie, la connectivité, les règles nationales et la portée pratique d’une autorité locale. Elle dit à un acheteur quelque chose d’utile sur l’endroit où se trouve un certain équipement. Elle ne dit pas, à elle seule, à l’acheteur qui possède le service, qui exploite l’équipement, où les copies sont faites, qui détient les clés, quelles personnes peuvent l’administrer, quelles entreprises sont autorisées à sous-traiter une partie du travail, ni quel système juridique peut contraindre une partie à fournir un accès.

La distinction est facile à énoncer et étonnamment facile à perdre. Un code postal est visible. Le contrôle est réparti. Le code postal s’insère parfaitement dans un tableur d’appel d’offres ; le contrôle arrive comme une chaîne de contrats, d’identités, de comptes de support, de plans de gestion, de clés de chiffrement, de relations d’entreprise, de procédures opérationnelles et d’obligations légales. Le premier est un fait de lieu. Le second est une question de pouvoir.

Le droit européen de la protection des données fait valoir ce point dans un langage de plus en plus précis. Dans l’arrêt Schrems II du 16 juillet 2020, la Cour de justice de l’Union européenne a examiné comment les données personnelles pouvaient quitter l’Espace économique européen tout en conservant un niveau de protection essentiellement équivalent à celui garanti à l’intérieur. La Cour a confirmé les clauses contractuelles types comme un outil de transfert possible, mais a précisé qu’elles ne fonctionnent pas dans le vide. L’exportateur doit examiner le droit et les pratiques de la destination dans les circonstances du transfert, et agir lorsque les garanties ne peuvent pas fonctionner en pratique.

L’arrêt n’a pas dit qu’une frontière est sans importance. Il a dit qu’une frontière est une partie de la question. Les recommandations ultérieures du Comité européen de la protection des données transforment ce principe en méthode : connaître les transferts, identifier l’outil juridique, évaluer le droit et les pratiques qui peuvent l’affecter, ajouter des mesures là où elles peuvent fonctionner, accomplir la procédure requise et maintenir l’évaluation sous revue. Une adresse de serveur apparaît sur cette carte. Elle n’est pas la carte.

Cela dépasse les données personnelles. Le Data Act traite le cloud et les autres services de traitement de données comme des infrastructures dont les clients devraient pouvoir changer. Il aborde également les conditions dans lesquelles une autorité publique d’un pays tiers cherche à accéder à des données non personnelles détenues dans l’Union. Là encore, la réponse juridique se construit à partir d’acteurs, d’objectifs, de garanties, de preuves et de recours. Un bâtiment est impliqué. Un bâtiment ne suffit pas.

La leçon pratique pour une institution européenne est donc directe. Demandez où se trouvent les données. Puis continuez à poser des questions jusqu’à ce que la réponse inclue qui peut les lire, qui peut les modifier, qui peut les arrêter, qui peut les exporter, qui peut être contraint de les divulguer et quelles preuves resteront lorsque les parties seront en désaccord. Si la réponse s’arrête à la porte du centre de données, la partie utile de l’enquête ne fait que commencer.

La résidence concerne le lieu

La résidence des données est une déclaration sur l’endroit où les données sont stockées ou traitées dans le cadre d’un arrangement défini. La définition a besoin d’un périmètre. S’agit-il de la copie principale, de la sauvegarde, de l’index, du cache, de la télémétrie, du site de reprise après sinistre, ou de tous ? Le traitement inclut-il un administrateur qui consulte un enregistrement depuis un autre pays ? Une session de support compte-t-elle ? Que se passe-t-il lorsqu’une équipe d’intervention doit copier une trace de diagnostic ? Une promesse de résidence qui ne dit pas ce qu’elle couvre est une étiquette attrayante attachée à une phrase inachevée.

Les systèmes cloud sont conçus pour déplacer le travail. La réplication peut améliorer la disponibilité. Un second site peut maintenir un service en vie lorsque le premier site est indisponible. Un emplacement périphérique peut réduire la latence. Une équipe de sécurité peut acheminer un journal vers un système d'analyse central. Ce sont des choix d'ingénierie ordinaires, et non des preuves de mauvaise conduite. Ils impliquent toutefois que l'expression « stocké en Europe » nécessite un objet technique qui lui soit rattaché. Quelles données, dans quel état, pour quelle période, sous quelle opération ?

L'évaluation des risques du cloud de l'ENISA, publiée pour la première fois en 2009, reste utile précisément parce qu'elle a refusé de traiter la géographie comme un contrôle complet. Elle identifie les risques liés au stockage dans plusieurs juridictions, aux informations insuffisantes sur les juridictions, à la perte de gouvernance, à la sous-traitance et aux changements de contrôle du fournisseur. Le document est assez ancien pour avoir un faible pour les acronymes que les équipes modernes ne partagent peut-être pas, mais le problème organisationnel n'a pas disparu. Si un client ne peut pas voir où les données sont traitées ou qui est responsable de la prochaine transition, le client ne peut pas prendre une décision de risque fiable.

La résidence peut être une exigence valide. Une archive publique peut avoir besoin que les enregistrements restent dans une zone juridique définie. Un service de santé peut avoir besoin d'un accord de traitement qui limite les endroits où les données sensibles peuvent voyager. Un consortium de recherche peut avoir des obligations liées à un bailleur de fonds ou à un accord de partage de données. Ces exigences devraient être rédigées comme des conditions opérationnelles, avec une méthode pour les vérifier, plutôt que comme un seul nom de pays que chacun est invité à interpréter généreusement.

Il existe également une différence entre une restriction et une garantie. Exiger d'un fournisseur qu'il conserve un stockage principal dans l'Union européenne restreint une classe de mouvement. Cela ne garantit pas qu'aucune personne hors de l'Union ne puisse accéder à un enregistrement, qu'aucune métadonnée ne quitte le territoire, ou qu'aucune obligation légale étrangère ne puisse atteindre un fournisseur. Une restriction peut être utile sans être une garantie. Confondre les deux crée un récit de conformité qui passe une visite de la salle des serveurs et échoue à un examen plus attentif du plan de gestion.

La question utile de la résidence n'est pas simplement « où est-ce ? » C'est « quels emplacements sont possibles pour chaque état de ces données, et qui peut faire changer cet état ? » Un fournisseur devrait être en mesure d'expliquer la réponse en des termes qu'un ingénieur peut mettre en œuvre et qu'un acheteur peut vérifier. Si l'explication dépend d'une exception non documentée, d'une habitude de support, ou d'une promesse que les sous-traitants du fournisseur se comporteront probablement bien, la revendication de résidence n'est pas encore opérationnelle.

Cinq questions cachées dans le mot « où »

Quand les gens demandent où se trouvent leurs données, ils veulent souvent dire plusieurs choses à la fois. Séparer les questions rend une conversation d'achat moins théâtrale et plus utile.

1. Où sont les bits ? C'est la question du stockage physique et logique. Elle inclut les données primaires, les réplicas, les sauvegardes, les caches, les index et les journaux pertinents. Une réponse satisfaisante nomme le périmètre et les conditions dans lesquelles la réponse change.

2. Où se déroule le traitement ? Un enregistrement peut être stocké dans une juridiction et transformé, recherché, classé, chiffré ou déchiffré ailleurs. Le traitement peut être un travail planifié, une action de support, un pipeline de surveillance ou une copie temporaire réalisée pendant la récupération.

3. Qui peut y accéder ? C'est la question de l'identité et de l'exploitation. Elle inclut le personnel, les administrateurs, les sous-traitants, les comptes de service, les intervenants en cas d'incident et les systèmes automatisés. Une personne n'a pas besoin de vivre à côté d'un serveur pour y avoir un accès effectif.

4. Qui peut contraindre cet accès ? C'est la question de la juridiction et de l'autorité légale. Elle suit les organisations et les personnes concernées, les rôles qu'elles occupent, les contrats qu'elles signent et les obligations légales qui peuvent les lier. Une épingle sur une carte ne suffit pas à y répondre.

5. Que peut faire le client quand la réponse change ? C'est la question du contrôle et de la sortie. Le client peut-il restreindre l'accès, faire pivoter les clés, obtenir un enregistrement fiable, restaurer le service, déplacer les données et mettre fin à la relation sans perdre ce qu'il cherchait à protéger ?

Ces questions se chevauchent, mais elles ne sont pas interchangeables. Un fournisseur peut répondre à la première de manière convaincante et mal à la troisième. Un contrat peut répondre à la cinquième sur le papier tandis que l'équipe technique n'a jamais exécuté la sortie. Une filiale locale peut répondre à la question de l'identité de l'entreprise alors que le service dépend de l'infrastructure ou de l'organisation de support de la société mère. La bonne réponse n'est pas de choisir la réponse la plus rassurante. C'est de garder l'ensemble intact.

C'est aussi pourquoi les évaluations de souveraineté peuvent devenir confuses. Le mot est censé couvrir la résidence physique, l'indépendance juridique, la compétence opérationnelle, la propriété économique, l'autonomie stratégique et la capacité de partir. Ce sont des ambitions liées. Ce n'est pas une seule propriété. Une institution précise indique de quelle propriété elle a besoin et quelles preuves montreraient qu'elle existe.

La juridiction suit l'autorité

La juridiction n'est pas un nuage mystique entourant un pays. C'est une façon de décrire quelles autorités légales peuvent réglementer, ordonner, enquêter, examiner ou remédier à la conduite des acteurs concernés. Dans un service distribué, les acteurs comptent autant que les lieux. Une entreprise peut être constituée dans un État membre, exploiter des installations dans un deuxième, utiliser une équipe de support dans un troisième et dépendre d'une société mère ou d'un sous-traitant soumis à des obligations ailleurs. Un client qui cherche à comprendre la portée juridique doit suivre la chaîne d'autorité, pas s'arrêter au bâtiment le plus proche.

Cela ne signifie pas que chaque connexion étrangère contrecarre le contrôle européen. Les services européens sont interconnectés par conception. Le commerce transfrontalier, la recherche, le support, le financement et l'infrastructure sont normaux. La question est de savoir si l'institution sait quelle connexion porte quel pouvoir. Un opérateur européen peut être en mesure de refuser une demande ordinaire mais manquer d'autorité pour résister à une instruction contraignante d'une autre organisation. Un sous-traitant peut détenir un identifiant que le mandant n'a pas inclus dans son propre inventaire d'accès. Un processus de support peut permettre un accès à distance même lorsque le contrat de stockage promet une région locale.

L’analyse juridique dépend aussi du type de données et du type de demande. Les données personnelles font entrer en jeu les règles de transfert du RGPD et le cadre des droits fondamentaux. Les données non personnelles ne sont pas dans un vide juridique. La loi sur les données contient des garanties pour certaines demandes émanant d’autorités publiques de pays tiers concernant des données non personnelles détenues dans l’Union. Une demande doit être examinée au regard des conditions du règlement, notamment la nature de la demande et les protections disponibles dans le système juridique du pays tiers. Les deux régimes sont différents, et c’est précisément cette différence qui explique pourquoi un acheteur ne devrait pas les réduire au mot résidence.

L’arrêt de la CJUE dans l’affaire C-311/18 fournit un modèle juridique européen utile. La Cour ne s’est pas demandé si un contrat paraissait assez formel. Elle s’est demandé si la protection garantie par le droit européen resterait essentiellement équivalente dans les circonstances du transfert, en tenant compte du droit et des pratiques susceptibles d’affecter les données. Les clauses contractuelles types peuvent lier les parties qui les signent. Elles ne lient pas une autorité publique qui n’est pas partie au contrat. Lorsque l’environnement juridique compromet les garanties promises, l’exportateur doit réagir.

Cette logique va au-delà du litige particulier. Un contrat est un instrument de répartition privée. La juridiction est le champ dans lequel l’autorité publique peut agir. Le contrat peut indiquer à un fournisseur ce qu’il a promis au client. Il ne peut pas, à lui seul, supprimer un pouvoir public qui s’impose au fournisseur ou à ses collaborateurs. Une bonne gouvernance prend ces deux affirmations au sérieux. Elle utilise les contrats pour fixer des obligations et des mesures techniques pour rendre ces obligations observables, tout en reconnaissant que la portée juridique peut encore modifier les options disponibles.

Il est tentant de transformer cela en une chasse à un seul pays dangereux. C’est moins utile que de cartographier les autorités réelles. Quelle entité est le responsable du traitement ou le sous-traitant ? Quelle entité emploie l’administrateur ? Quelle entité détient les clés de chiffrement ? Quelle entité peut créer une réplique ? Quelle entité reçoit une demande d’assistance ? Quelle autorité pourrait émettre une injonction ? Quel recours le client aurait-il, et devant quelle juridiction ? La carte peut être rassurante. Elle peut ne pas l’être. Dans les deux cas, le résultat a plus de valeur qu’un autocollant indiquant un pays.

La propriété est un titre, pas une clé

La propriété a une véritable force juridique et économique. Elle peut déterminer qui peut vendre un actif, nommer des administrateurs, concéder des licences de propriété intellectuelle, percevoir des revenus ou prendre certaines décisions. Dans un organisme public, elle peut être liée à une responsabilité légale concernant les archives ou les infrastructures. Dans un groupe d’entreprises, elle peut expliquer qui peut voter, fusionner, financer ou remplacer un fournisseur. La propriété a sa place dans une évaluation de souveraineté.

La propriété ne confère pas automatiquement le contrôle opérationnel. Un client peut posséder les données tandis qu’un fournisseur exploite la base de données, gère le système de sauvegarde et contrôle le compte de service. Une institution publique peut posséder un bâtiment tandis qu’un entrepreneur détient les identifiants de maintenance et la seule procédure testée pour restaurer l’équipement. Une entreprise peut posséder le code source tandis qu’un tiers contrôle la clé de signature, l’environnement de compilation, le registre de paquets et l’identité de déploiement. Le titre est réel. La dépendance l’est aussi.

La distinction devient visible dans les verbes. La propriété est un nom dans un contrat. Le contrôle est la capacité d’inspecter, d’exploiter, de modifier, d’arrêter, de récupérer, d’exporter, de supprimer et de prouver. Un processus d’achat qui n’enregistre que des noms peut laisser les verbes importants sans titulaire. Il peut désigner un propriétaire nommé pour la plateforme et ne pas désigner de personne capable de faire pivoter une clé, de supprimer un compte privilégié ou de restaurer à partir d’une sauvegarde sans demander à une organisation qui n’est pas dans la salle.

Il n'y a aucune vertu à exiger une possession maximale. Un hôpital, une université ou une municipalité peut manquer de personnel et de capacités de sécurité pour faire fonctionner chaque couche en toute sécurité. Déléguer une tâche peut être responsable lorsque les limites sont explicites et que le client conserve la capacité de superviser, de tester et de récupérer. Il ne s'agit pas de placer chaque serveur dans un sous-sol public. Il s'agit de décider quels pouvoirs sont essentiels à la mission et de les garder suffisamment proches pour les gouverner.

Cette décision nécessite des preuves. « Le client possède les données » devrait conduire à des questions sur le format d'exportation, la garde des clés, la conservation, la suppression, les journaux d'accès et les autorisations de support. « Le fournisseur est européen » devrait conduire à des questions sur le contrôle de l'entreprise, les sous-traitants, l'infrastructure, l'exposition juridique et la continuité. « Les données sont dans l'Union » devrait conduire à des questions sur l'administration à distance, les répliques, les emplacements de traitement et les demandes légales. Une bonne réponse peut être compliquée. La complication n'est pas un défaut lorsque le système est compliqué.

Le contrôle opérationnel est le droit d'agir

Le contrôle opérationnel se comprend plus facilement par une action que par un adjectif. Prenons un client qui doit révoquer un administrateur. Qui peut effectuer la révocation ? Quel système d'identité l'autorise ? Le fournisseur est-il tenu d'exécuter le changement, ou le client peut-il le faire directement ? L'action couvre-t-elle les comptes de support, les comptes d'urgence et les identifiants dormants ? Un enregistrement prouve-t-il quand la permission a disparu ? Si une action dépend d'un service d'assistance, ce service fait partie du plan de contrôle.

Le même test s'applique aux clés. Le chiffrement peut réduire l'exposition, mais sa gouvernance dépend de qui crée, stocke, fait pivoter, récupère et peut utiliser les clés. Un enregistrement stocké localement peut rester illisible pour une partie qui ne peut pas obtenir la clé. Il peut également devenir inaccessible au client lorsque le seul chemin de récupération repose sur un fournisseur. La garde des clés n'est donc ni un slogan pour la souveraineté ni une gomme magique pour la juridiction. C'est un contrôle concret qui doit être attribué et répété.

Les journaux méritent le même traitement. Un tableau de bord peut montrer l'activité. Les preuves exigent un enregistrement que le client peut conserver, interpréter et contester. Qui écrit le journal ? Un administrateur peut-il le modifier ? La source de temps est-elle fiable ? Couvre-t-il l'accès au support et le traitement automatisé ? Le client peut-il obtenir un export utilisable sans la permission du fournisseur ? Que se passe-t-il lorsque le compte est fermé ? Un journal qui disparaît avec le service est utile pour les opérations et faible pour la responsabilité.

La récupération est le test de contrôle opérationnel le plus difficile car il rend chaque dépendance visible. Un fournisseur peut promettre une sauvegarde, mais la restauration peut exiger une région particulière, une licence indisponible, un ingénieur qui n'y travaille plus ou un secret stocké dans un système séparé. Le client peut posséder le fichier de sauvegarde et ne pas avoir la capacité d'en faire un service fonctionnel. La récupération doit être testée comme une action complète, avec le résultat enregistré et les lacunes attribuées à des personnes capables de les combler.

Arrêter un service est aussi un contrôle. Une institution peut avoir besoin de mettre en pause une intégration, d'isoler un ensemble de données, de suspendre un traitement automatisé ou d'empêcher la création d'une nouvelle réplique. Si seul un fournisseur peut effectuer l'arrêt, l'identité du fournisseur, ses obligations légales, son temps de réponse et son processus de support font partie du risque de l'institution. Cela peut être un arrangement acceptable. Ce n'est pas un arrangement invisible.

Le but de ces tests n'est pas de se méfier de chaque fournisseur. C'est de remplacer la confiance par une relation qui peut être inspectée. Un fournisseur avec une réponse claire peut expliquer quelles actions il effectue, lesquelles le client effectue et lesquelles nécessitent une coopération. Un fournisseur qui s'appuie sur une seule phrase rassurante n'a pas encore répondu à la question opérationnelle.

Les sous-traitants transforment une réponse en chaîne

Un service est rarement une organisation unique qui fait une seule chose en un seul endroit. Les fournisseurs de cloud utilisent des infrastructures spécialisées, des partenaires de support, des services de surveillance, des opérations de sécurité, de la maintenance matérielle, des opérateurs réseau et d'autres fournisseurs. Certains sont visibles dans le contrat. D'autres apparaissent dans une liste de sous-traitants, une description de service, un avis d'incident ou un flux de support. La chaîne est ordinaire. L'obligation de comprendre la chaîne est également ordinaire.

L'évaluation des risques de l'ENISA met en évidence une défaillance courante : un fournisseur de cloud peut sous-traiter des services à un tiers qui n'offre pas les mêmes garanties, tandis qu'un changement de contrôle peut modifier les conditions du fournisseur. Le rapport n'est pas une spécification d'architecture moderne, et il n'a pas besoin de l'être. Son avertissement durable est organisationnel. Un client ne peut pas prétendre comprendre un service lorsqu'il n'a évalué que la première entreprise nommée sur la facture.

Les recommandations du CEPD sont plus spécifiques pour les données personnelles. La première étape consiste à connaître les transferts, y compris les transferts ultérieurs vers des sous-traitants et des sous-traitants ultérieurs. Un accès à distance depuis un pays tiers peut en soi constituer un transfert, même lorsque l'enregistrement reste dans un centre de données de l'EEE. Un arrangement de support fait donc partie de la cartographie des transferts de données, et non une note de bas de page à traiter après le déploiement.

La visibilité des sous-traitants n'est pas la même chose que le contrôle des sous-traitants. Une liste indique au client qui est impliqué. Le contrôle demande ce que chaque partie peut faire, quelles données elle peut voir, quel outil juridique couvre l'activité, comment un changement est notifié et quel recours existe lorsque la partie cesse de respecter les conditions. La chaîne devrait avoir des limites et des preuves à chaque point de transfert.

Il y a une raison pratique de résister aux chaînes vagues. Lorsqu'un incident se produit, la responsabilité voyage souvent dans la direction opposée aux données. Le client demande au fournisseur. Le fournisseur demande à une équipe de plateforme. L'équipe de plateforme demande à un fournisseur spécialisé. Le fournisseur spécialisé demande à un administrateur dans une autre organisation. Chaque transfert peut ajouter du retard, de l'incertitude et une occasion pour l'enregistrement original de perdre du contexte. Une cartographie des contrôles devrait montrer le parcours avant l'incident, pendant que les personnes impliquées ont encore le temps d'être précises.

Données personnelles : la protection voyage avec l'enregistrement

Le RGPD ne rend pas les données personnelles sûres en les plaçant derrière une porte européenne. Ses règles de transfert sont conçues pour préserver un niveau de protection élevé lorsque les données se déplacent vers un pays tiers. Le CEPD décrit le principe clairement : un niveau de protection essentiellement équivalent devrait accompagner les données où qu'elles aillent, pendant et après le transfert.

Cela ne signifie pas que tout transfert est interdit. Le RGPD contient différents outils et conditions de transfert, notamment les décisions d'adéquation et les garanties de l'article 46. La question juridique est de savoir si l'outil choisi fonctionne dans les circonstances. Les recommandations du CEPD demandent aux exportateurs d'évaluer le droit et la pratique pertinents pour le transfert particulier, d'examiner si l'importateur ou les données peuvent relever de règles problématiques, et de documenter le raisonnement. Si aucune mesure supplémentaire ne peut rétablir le niveau de protection requis, le transfert devrait être évité, suspendu ou interrompu.

Trois détails sont particulièrement faciles à manquer dans une conversation sur la résidence. Premièrement, un transfert ultérieur compte. Un fournisseur peut conserver l'enregistrement principal dans l'EEE et envoyer une copie à un service d'assistance ou d'analyse ailleurs. Deuxièmement, l'accès compte. Un administrateur dans un pays tiers peut être en mesure de lire un enregistrement sans que celui-ci ne soit jamais physiquement déplacé vers le bureau de cette personne. Troisièmement, la responsabilité compte. L'exportateur doit être en mesure de démontrer l'évaluation et de la réexaminer lorsque le service, le droit, les personnes ou les circonstances changent.

Le cadre demande donc au client de comprendre à la fois le chemin technique et le contexte juridique. Un schéma des régions et des flèches est utile. Il ne peut pas remplacer l'évaluation du transfert. Pas plus qu'une promesse contractuelle qu'un fournisseur se conformera, si le client n'a pas vérifié ce que les garanties pertinentes peuvent accomplir face aux lois et pratiques qui peuvent s'appliquer au fournisseur.

Le droit européen de la protection des données a une saine méfiance envers les formules magiques. « Hébergement dans l'UE » peut décrire un fait utile. « Conforme » peut décrire une conclusion qui exige des motifs. « Souverain » peut décrire un objectif politique. Aucun de ces termes ne devrait être autorisé à remplacer les preuves que les données sont protégées, que l'accès est encadré et que la décision peut être défendue.

Données non personnelles : un régime différent, la même discipline

Le règlement sur les données traite d'un ensemble plus large de relations de données et comprend des règles pour les services de traitement de données tels que les services cloud et de périphérie. Il ne remplace pas le RGPD et ne transforme pas chaque décision relative au cloud en évaluation de transfert de protection des données. Il fournit un deuxième rappel européen que la localisation, l'accès, le changement de fournisseur et l'autorité doivent être considérés ensemble.

Pour les données non personnelles détenues dans l'Union, l'explication de la Commission concernant le règlement sur les données décrit des garanties pour certaines demandes ou décisions d'une autorité publique d'un pays tiers. Lorsqu'aucun accord international applicable ne régit l'accès, le règlement fixe des conditions destinées à protéger les intérêts européens, notamment une attention au système juridique du pays tiers et à la proportionnalité de la demande. Les fournisseurs sont tenus de prendre des mesures raisonnables, telles que le chiffrement, les audits ou les dispositifs de certification, pour empêcher tout accès non autorisé et informer les clients dans la mesure du possible.

La formulation importe. Le règlement sur les données ne prétend pas que l'Union peut faire disparaître les systèmes juridiques étrangers. Il crée un cadre pour évaluer et limiter certaines voies d'accès. Un fournisseur doit encore savoir quels systèmes il exploite, quelles données sont détenues, qui peut répondre à une demande et quelles preuves peuvent être fournies au client. Un client doit encore comprendre quelles parties des données sont personnelles, lesquelles ne le sont pas, et quels autres régimes juridiques s'appliquent.

The Act also approaches control through switching. Customers should be able to move between data-processing services, use services in parallel and port exportable data and digital assets. Providers must give information about export formats, interfaces, known limitations and the time needed for the process. The rules on functional equivalence recognise a practical truth: a file that can be downloaded is not necessarily a service that can be recovered.

Switching is often described as a competition measure, and it is one. It is also a sovereignty measure in the operational sense. An institution that can leave has more room to refuse a change it cannot accept. An institution that cannot leave may own a contract and still be governed by the provider's defaults. A legal right to switch is an important start. A rehearsed migration that preserves the data, the configuration and the evidence is the part that makes the right usable.

Contracts, keys and the limits of reassurance

Contracts remain essential. They allocate duties, set notification rules, identify subprocessors, define permitted processing, describe deletion and retention, create audit rights and establish assistance during a transition. The Data Act's cloud-switching provisions reinforce the need for clear contractual terms, exportable data and information about the mechanics of an exit. ENISA's older guidance likewise recommends paying attention to data transfers, change of control, law-enforcement access, breach notifications and liability when evaluating cloud contracts.

A contract is not a runtime control. A clause saying that the customer may export is weaker than an export run against a representative dataset and restored in a second environment. A clause saying that the provider will delete is weaker than an auditable deletion process that covers replicas, caches, backups and derived records. A clause giving an audit right is weaker than logs and evidence the customer can actually obtain. Paper matters. Paper that never meets a working system is politely framed optimism.

Keys provide a similar lesson. Customer-controlled encryption can reduce what a provider or an unauthorised party can read. It does not answer who can compel a person who holds a recovery key, who controls the hardware security module, who can change the key policy, or what happens when the customer loses its own credential. The right design may use split authority, independent custody, carefully scoped access and tested recovery. The wrong design can put the decisive key in a different jurisdiction and call the arrangement local because the database is local.

Legal and technical measures should be designed together. If a contract requires the customer to approve support access, the service should have an approval flow that leaves a record. If the customer needs to prevent onward transfers, the provider should expose the route and enforce the boundary. If a public authority request must be evaluated, the incident process should preserve the request, the legal analysis, the decision, the notification and the response. A legal promise becomes credible when a system can show how it is carried out.

The same principle applies to ownership changes. A supplier acquisition, a new parent company, a change in subcontractor or a change in the service's operating region can alter the control map without changing the customer-facing brand. Contracts should require notice and remedies. Technical inventories should be updated. A change ledger should show which powers moved. Governance that exists only at initial signature has a short half-life.

A buyer's control map

A public or private buyer does not need a magical questionnaire. It needs a map that connects claims to evidence. The following questions are a useful starting point because they ask for actions, actors and records rather than a preferred adjective.

Le tableau est volontairement prosaïque. Il est conçu pour survivre au contact d'une équipe d'achat. Il donne aussi à l'acheteur un moyen de comparer les fournisseurs sans prétendre qu'un certificat, un drapeau national ou une visite de centre de données règle tout. Les preuves peuvent être confidentielles. L'exigence d'en avoir ne devrait pas l'être.

Demandez une démonstration de l'action critique, pas seulement une description. Montrez comment un compte privilégié est supprimé. Montrez comment une session de support est approuvée. Montrez ce qu'un client reçoit lorsqu'il demande un export. Montrez comment une réplique est localisée. Montrez ce qu'une demande légale fait au flux de travail d'incident. Montrez comment l'organisation continue lorsque le compte du fournisseur est suspendu. Le but n'est pas de provoquer une panne spectaculaire. C'est de voir si le contrôle existe en dehors du diaporama.

Demandez ensuite qui possède le résultat. Un test sans propriétaire est une représentation. Une lacune sans date est une fonctionnalité permanente. Un contrôle sans enregistrement est une croyance. La carte doit donc nommer la personne ou l'organisme qui accepte le risque, le fournisseur qui doit exécuter l'action et la voie pour contester le résultat. La gouvernance n'est pas une pile de questions. C'est un ensemble de décisions qui ont une destination.

Une expérience de pensée sur une archive européenne

Ce qui suit est une hypothèse clairement étiquetée, pas un rapport sur un client ou un incident réel. Imaginez une archive municipale sélectionnant un service hébergé pour des dossiers de planification numérisés. L'appel d'offres exige un stockage principal dans l'Union européenne et demande un chiffrement, des sauvegardes et un service d'assistance. Trois fournisseurs répondent aux critères. L'un est constitué localement mais s'appuie sur un sous-traitant de support hors de l'Union. Un autre maintient le stockage et le support dans l'Union mais utilise la plateforme d'identité de sa société mère. Un troisième a une opération locale plus petite, une garde de clés claire et un export testé, mais nécessite un niveau de service soigneusement défini car il ne peut pas offrir toutes les fonctionnalités optionnelles.

Le premier fournisseur peut encore être acceptable. Le deuxième peut encore être acceptable. Le troisième peut encore être inadapté à une exigence de disponibilité particulière. Le but de l'expérience de pensée est que la résidence seule ne peut pas choisir entre eux. L'archive doit demander quel accès de support est possible, qui peut faire une copie, quelles entités juridiques peuvent recevoir une ordonnance, comment les clés sont gouvernées, ce que montrent les journaux et si les dossiers peuvent être récupérés ailleurs.

Supposons que l'archive décide que le stockage local est sa condition la plus importante. Elle peut inscrire cette exigence dans le contrat. Elle devrait également définir les objets couverts par la condition, exiger un préavis en cas de changement et demander comment une violation serait détectée. Supposons qu'elle décide que l'assistance à distance n'est autorisée que pour un incident documenté. Le service a besoin d'un circuit d'approbation, d'identifiants à durée limitée et d'un enregistrement consultable. Supposons qu'elle décide que l'archive doit pouvoir partir. La sortie devrait être testée avant que le service ne devienne le seul endroit où quiconque sait lire les documents.

Rien dans cette hypothèse n'oblige l'archive à exploiter un centre de données. Cela l'oblige à comprendre les pouvoirs qu'elle délègue. C'est la différence entre une externalisation responsable et un achat qui déplace le risque dans une pièce où l'acheteur ne peut pas entrer.

Ce que l'Europe peut honnêtement entendre par souverain

La souveraineté européenne dans les infrastructures numériques devrait être décrite en des termes qui résistent à une question embarrassante. Elle peut signifier qu'une institution européenne conserve l'autorité sur les décisions critiques. Elle peut signifier que les dépendances clés sont visibles, encadrées et récupérables. Elle peut signifier que les droits juridiques sont assortis de capacités techniques. Elle peut signifier qu'un acheteur public peut changer, contester, inspecter et continuer à fonctionner lorsqu'un fournisseur ou une loi modifie la voie disponible.

Elle ne devrait pas signifier qu'un service est automatiquement sûr parce que son adresse marketing est européenne. Elle ne devrait pas non plus signifier que toute connexion étrangère est interdite. L'Europe dépend de systèmes transfrontaliers, et une règle qui prétend le contraire sera ignorée ou discrètement contournée. La position mûre est plus exigeante : permettre les dépendances qui servent la mission, les documenter, réduire celles qui portent un pouvoir inacceptable et conserver une sortie pour celles qui ne peuvent pas être rendues dignes de confiance.

Cette position donne également aux fournisseurs européens un test plus équitable. Un fournisseur local ne devrait pas avoir à faire une cérémonie du drapeau pour être pris au sérieux. Il devrait pouvoir montrer ce qu'il exploite, ce qu'il délègue, qui peut y accéder, quelle loi peut s'appliquer, comment les données sont protégées et comment un client peut partir. Un fournisseur mondial devrait répondre aux mêmes questions. La norme est la preuve du contrôle, pas le théâtre de l'origine.

Le mot souveraineté devient utile lorsqu'il change le comportement d'achat. Un ministère peut utiliser les marchés publics pour récompenser un parcours de sortie testé. Un hôpital peut exiger des dispositions clés conformes à ses devoirs cliniques. Une université peut rendre visible la provenance des données de recherche. Un régulateur peut demander l'état d'un système au moment d'une décision. Un fournisseur peut concevoir son service pour que l'autorité du client ne soit pas un paragraphe décoratif. Ce sont des actions institutionnelles, pas un concours de slogans.

Une petite note de notre part

Chez Dweve, notre analyse publique The Sovereignty Illusion: where control really sits, publiée le 29 juin 2026, suit une discipline similaire. Elle sépare propriété, technologie, capital, infrastructure et exposition juridique au lieu de laisser une étiquette européenne représenter les cinq à la fois. Cet article est plus restreint. Il suit la revendication du centre de données dans les couches opérationnelles et juridiques qu'un acheteur doit gouverner.

C'est aussi ainsi que nous préférons décrire notre propre travail. Un système devrait rendre ses limites lisibles : ce qui est local, ce qui est délégué, ce qui est enregistré, ce qui peut être contesté et ce qui peut être modifié. La revendication utile est celle qu'un lecteur peut inspecter. Le reste est de la décoration, et l'Europe a déjà beaucoup d'infrastructures décoratives.

L'argument juridique commence après l'adresse

L'emplacement d'un centre de données mérite d'être connu. Il peut affecter l'accès physique, la résilience, la connectivité, les règles locales applicables et la conception d'un service. C'est peut-être la bonne première question. C'est une mauvaise réponse finale.

La réponse finale doit relier le lieu à l’autorité. Elle doit nommer l’exploitant, les identités, les clés, les sous-traitants, les outils juridiques, les demandes possibles, les preuves et la sortie. Pour les données personnelles, le niveau de protection européen doit rester essentiellement équivalent lors du transfert des données, et les exportateurs doivent évaluer les circonstances plutôt que de répéter une simple affirmation de localisation. Pour les données non personnelles, le Data Act ajoute des règles concernant l’accès étranger et le changement de fournisseur de cloud, ce qui rend là encore le contrôle et la portabilité concrets.

Il n’existe pas de numéro européen unique qui puisse transformer un service complexe en service souverain. Il existe une succession de questions, de tests et de registres. Cette succession est plus lente que d’imprimer « hébergé dans l’UE » sur une brochure. C’est aussi la partie qui reste utile une fois la brochure périmée.

Lorsqu’un acheteur demande où se trouvent les données, répondez précisément quant au lieu. Demandez ensuite qui peut les lire, qui peut agir sur elles, qui peut être contraint, qui peut prouver ce qui s’est passé et qui peut partir. Un centre de données européen peut faire partie d’un dispositif digne de confiance. Il ne peut pas constituer à lui seul l’argument juridique.

Sources

• Recommandations 01/2020 sur les mesures complétant les outils de transfert pour garantir le respect du niveau de protection des données personnelles de l’UE, Comité européen de la protection des données, version finale du 18 juin 2021. La page liée inclut le PDF officiel.
• Affaire C-311/18, Data Protection Commissioner contre Facebook Ireland et Schrems II, Cour de justice de l’Union européenne, arrêt du 16 juillet 2020, EUR-Lex.
• Règlement (UE) 2023/2854, le Data Act, Parlement européen et Conseil, 13 décembre 2023, EUR-Lex.
• Data Act expliqué, Commission européenne, publié en 2025 et consulté le 5 août 2026.
• Évaluation des risques de l’informatique en nuage et le PDF du rapport officiel, Agence de l’Union européenne pour la cybersécurité (ENISA), 2009.
• The Sovereignty Illusion: where control really sits, Dweve, 29 juin 2026.