La question du cloud européen ne se résume pas à l'emplacement des serveurs
Un lieu peut être exact et laisser pourtant la question ouverte
Il y a un moment bien connu dans toute discussion sur le cloud. Quelqu'un demande où les données seront stockées. Quelqu'un d'autre répond en citant le nom d'une ville européenne. La tension retombe un peu. La réponse peut être parfaitement exacte, et elle peut avoir une grande importance. La géographie influe sur la latence, la sécurité physique, l'électricité, la planification de la résilience, l'emploi, la responsabilité publique et les arrangements juridiques entourant un service. Une autorité publique qui doit conserver certains documents dans un territoire déterminé a de bonnes raisons de poser la question. Les problèmes commencent lorsque le nom de la ville est censé régler toutes les autres questions de l'arrangement.
Un serveur se trouve quelque part. Un service, non. Un service est une relation entre des entités juridiques, des personnes disposant de droits d'administrateur, des composants logiciels, des fournisseurs de matériel, des contrats, des équipes d'assistance, des réseaux, des dispositifs de chiffrement, des sous-traitants et le client qui dépend du résultat. Le bâtiment n'est qu'une partie matérielle de cette relation. Il ne révèle pas qui peut émettre une instruction privilégiée depuis un autre lieu, quel groupe d'entreprises contrôle la société exploitante, quelle juridiction peut atteindre un fournisseur, si un sous-traitant a changé, ni ce que le client peut emporter à la fin du contrat.
Ce n'est pas un argument contre les centres de données européens ou les fournisseurs européens. C'est un argument contre le fait de laisser une réponse utile faire un travail qu'elle ne peut pas faire. La question du cloud européen n'est pas de savoir si un serveur peut être installé sur le sol européen. Elle est de savoir si l'organisation qui utilise le service peut comprendre et exercer un contrôle suffisant sur l'ensemble de l'arrangement pour le travail en jeu. La localisation fait partie de cette réponse. Elle ne peut pas être la réponse entière, pas plus qu'une adresse d'entreprise ne nous dit qui détient les clés de ses comptes.
Cette distinction importe surtout lorsque le cloud accomplit un travail ordinaire et conséquent. Une collectivité locale peut conserver de la correspondance, des dossiers et des informations publiques dans un environnement hébergé. Un fabricant peut détenir des plans et des données opérationnelles. Un groupe de recherche peut détenir un ensemble de données qui ne peut pas être déplacé à la légère. Un hôpital peut utiliser des services qui touchent à des informations personnelles. Aucun de ces exemples n'exige une panne spectaculaire ou un scénario d'espionnage pour devenir sérieux. La question quotidienne est plus simple : qui détient l'autorité pratique sur un système devenu partie intégrante de la capacité de travail de l'organisation ?
Le droit et les orientations européens traitent de plus en plus cette question comme une question de preuve, de rôles et de changement de fournisseur, plutôt que comme une question de vocabulaire rassurant. Le Data Act confère aux clients des droits et impose aux fournisseurs des obligations concernant le changement de fournisseur, les données exportables et les interfaces des services de traitement des données. Le CEPD affirme depuis longtemps que les institutions européennes qui utilisent des services cloud restent responsables de leurs obligations en matière de protection des données. Les travaux d'ENISA sur les risques du cloud désignent l'enfermement propriétaire et le risque juridique comme des éléments à évaluer. Ces instruments ne sont pas identiques et ne créent pas une doctrine unique du cloud. Ensemble, ils indiquent une direction utile : le contrôle doit être décrit, non pas sous-entendu.
L'épingle sur la carte et le plan de contrôle
Le langage du cloud rend souvent la distinction plus difficile à voir. Le mot cloud évoque un système météorologique : vaste, lointain et peut-être inévitable. En pratique, un service cloud comporte un plan de contrôle et un plan de travail. Le plan de travail est l'endroit où une charge de travail s'exécute, où les données sont stockées, où les requêtes sont traitées et où les résultats sont renvoyés. Le plan de contrôle est l'ensemble des mécanismes par lesquels les identités sont gérées, les politiques modifiées, les logiciels mis à jour, la capacité attribuée, l'assistance fournie, les enregistrements récupérés et les systèmes arrêtés ou restaurés. Les deux plans peuvent être techniquement distribués. Les deux peuvent franchir les frontières organisationnelles.
Un relevé de localisation commence généralement par le plan de travail. Il peut indiquer où se trouve un entrepôt de données, une machine virtuelle ou une région particuliers. Ces informations doivent être suffisamment précises pour être utiles. Le relevé doit préciser ce qu'il couvre, quelles catégories de données il concerne, comment les changements sont notifiés, et si les sauvegardes, les journaux, les informations d'assistance et les données dérivées suivent la même règle. Une affirmation qui se contente de mentionner l'Europe, sans délimitation, est un point de départ pour une question plutôt qu'une réponse. L'Europe est un vaste territoire, et l'architecture des services est friande d'exceptions.
Le plan de contrôle pose une série de questions différentes. Qui peut créer ou supprimer un administrateur ? Qui approuve une intervention d'urgence ? Qui exploite le service d'identité ? Qui peut consulter les informations de diagnostic ? Quelle entreprise maintient le logiciel qui fait fonctionner la plateforme ? Quelle entité juridique reçoit une demande d'une autorité ? Quel sous-traitant est autorisé à traiter l'assistance ? Quelle partie peut modifier une description de service ou abandonner une fonctionnalité ? Un client peut se connecter tous les jours et ne disposer d'aucun moyen indépendant de répondre à ces questions.
Cela ne signifie pas que les clients doivent s'attendre à exploiter chaque dispositif physique. Ils ne le peuvent généralement pas, et la plupart n'en ont pas besoin. L'objectif est de rendre la délégation visible. Une exploitation déléguée peut être responsable et efficace lorsque les pouvoirs délégués sont définis, surveillés et réversibles. Elle devient un problème de souveraineté lorsque le client ne dispose que d'une étiquette contractuelle pour le contrôle, tandis que le fournisseur conserve les personnes, les interfaces, les enregistrements et les connaissances techniques nécessaires pour l'exercer. Un contrat inutilisable en pratique est un objet décoratif avec une belle typographie.
Pour un acheteur, la conséquence pratique est simple. Conservez la question de la localisation. Ajoutez la question du contrôle à côté. Demandez où se trouve la charge de travail, puis demandez qui peut modifier ses conditions. Demandez où les données sont traitées, puis demandez qui peut accéder à la voie administrative. Demandez où la sauvegarde est conservée, puis demandez qui peut la restaurer et sous quelle autorité. Les réponses peuvent être satisfaisantes. Elles peuvent révéler une dépendance qui doit être acceptée délibérément. Dans les deux cas, c'est mieux que de découvrir qu'une épingle sur une carte faisait office de modèle d'exploitation.
La propriété n'est pas un détail administratif
La propriété est parfois traitée comme un débat distinct sur les drapeaux, les bourses et la fierté nationale. Elle est plus concrète que cela. La propriété peut déterminer qui nomme le conseil d'administration, qui approuve une vente, qui oriente les investissements, qui détient la propriété intellectuelle, quelles politiques de groupe s'appliquent, et quelle entité décide en dernier ressort si un service reste une ligne de métier. Un client n'a pas besoin d'une règle simpliste selon laquelle une seule structure de propriété est acceptable. Il a besoin de connaître la structure avant de qualifier l'arrangement d'indépendant.
L'organisation de l'entreprise affecte également ce que signifie une promesse de cloud. Une marque peut être locale tandis que le service est exploité par une entité différente. Une filiale européenne peut contracter avec un client européen tandis qu'un groupe situé ailleurs fournit des logiciels essentiels, des opérations de sécurité, de l'assistance, de la facturation, des analyses de données ou une autorité exécutive. Un partenaire local peut apporter une contribution précieuse en matière de mise en œuvre tout en dépendant d'une plateforme qu'il ne peut pas modifier. Aucun de ces arrangements n'est automatiquement inapproprié. Ce sont des arrangements de contrôle différents, et ils ne devraient pas être présentés comme identiques par un logo partagé et un numéro de téléphone local.
The relevant question is not whether a buyer can find a foreign connection somewhere in a long supply chain. Modern technology is interconnected, and purity tests are not a procurement method. The question is where a dependency becomes decisive. Which entity can change the contract? Which entity controls the service's intellectual property? Which entity can make a support commitment? Which entity has the credentials or knowledge needed to recover the function? Which entity can be bought, sanctioned, reorganised or instructed in a way that changes the customer's position? Those are questions about actual leverage.
Ownership also changes. An acquisition, a funding round, a restructuring or an internal transfer can alter the control picture without moving a single server. A location clause written at signature may remain factually correct while the organisational facts around it have changed. That is why a serious cloud file needs a change process. The customer should know which change has to be disclosed, who will assess its effect, what evidence must be updated and which authority can pause a new data flow while the assessment is made. It is not glamorous work. Neither is checking the oil in a car, which is perhaps why people remember it after the engine complains.
In its 2018 cloud guidelines, the EDPS emphasised that EU institutions remain responsible for their data-protection obligations when they use cloud computing services and should secure an equivalent level of protection to other infrastructure models. That is not a demand that every institution own everything. It is a reminder that outsourcing a function does not outsource the duty to understand the arrangement. The duty makes ownership relevant because responsibility cannot be exercised through a diagram that omits the party with the practical power.
Legal reach is not erased by a European address
Jurisdiction is often the most uncomfortable layer because it resists the simple answer. A contract may select a governing law and a court. Those choices matter. They do not make other legal powers disappear. Legal reach may follow an entity, an establishment, a service provider, a corporate group, a person with access, a hardware vendor or the location and nature of particular data. The exact analysis depends on facts and law. A blog post cannot settle it for a real organisation, and a procurement template cannot replace proper advice where the risk is material.
The useful discipline is to separate a legal question from a geographic statement. A data centre in the European Union tells us where equipment is situated. It does not by itself tell us which entities can be compelled, which authorities might make a request, what notification is possible, or whether a provider has obligations under another legal order. Treating the two as equivalent can produce a false sense of closure. The buyer may have satisfied a residency requirement while leaving the legal analysis entirely unperformed.
The EDPB's final guidelines on the interplay between Article 3 GDPR and Chapter V international transfers are helpful precisely because they resist shortcuts. They distinguish the territorial scope of the GDPR from the question whether a processing operation is an international transfer. That distinction does not provide an all-purpose conclusion about every cloud arrangement. It does show why phrases such as EU-based or GDPR-covered cannot carry every legal inference a buyer may want to make. The data-protection analysis follows the actual processing and actors.
Le Data Act introduit une question connexe dans le dossier des services cloud. Son chapitre VII concerne les accès gouvernementaux internationaux illégitimes et le transfert de données non personnelles détenues dans l'Union. Le règlement exige des fournisseurs de services de traitement de données qu'ils prennent des mesures techniques, organisationnelles et juridiques adéquates, y compris des mesures contractuelles, dans les circonstances décrites à l'article 32. Il ne promet pas qu'un fournisseur puisse faire disparaître toute demande externe. Il exige une réponse disciplinée à un conflit qu'aucun terme marketing ne peut faire disparaître par simple incantation.
Pour les clients, le travail immédiat consiste à établir une cartographie des preuves. Identifier l'entité contractante, les entités du fournisseur qui exploitent des parties substantielles du service, les lieux où les données et l'administration sont situées, les juridictions déclarées, la voie de réception et de contestation des demandes, les conditions de notification et les conseils juridiques nécessaires pour la charge de travail concernée. Marquer ce qui est connu, ce qui est déclaré par le fournisseur, ce qui est contractuellement engagé et ce qui reste à investiguer. Une cartographie datée et assortie de lacunes identifiées est plus utile qu'un paragraphe d'assurance permanent.
Le contrôle opérationnel est là où une promesse devient réelle
Le contrôle opérationnel est la capacité de faire faire quelque chose à un système, ou de l'arrêter, par une autorité et un mécanisme définis. Il inclut des choses banales : créer un compte, modifier une politique réseau, faire tourner une clé, restaurer une sauvegarde, approuver une version, isoler un locataire, retirer un administrateur, inspecter un journal et exporter un enregistrement. Aucune de ces actions n'est un certificat de souveraineté. Ensemble, elles montrent si le client et le fournisseur ont une répartition intelligible des responsabilités.
Un arrangement cloud est fragile lorsque chaque action importante se termine par un courriel à une adresse d'assistance générique. L'assistance compte, et une assistance experte peut être l'une des bonnes raisons d'utiliser un service géré. Mais une organisation critique doit distinguer une voie d'assistance d'une voie d'autorité. Une voie d'assistance est la manière dont le fournisseur aide. Une voie d'autorité est la manière dont le client peut initier, approuver, observer et enregistrer une action dont il reste responsable. Les deux peuvent se rencontrer dans un ticket. Elles ne doivent pas être confondues.
Prenons un cas clairement hypothétique. Un consortium de recherche européen utilise un environnement analytique hébergé pour un projet sensible mais licite. Il dispose d'un contrat pour la région européenne et d'une localisation documentée des données. Lors d'une revue interne, le consortium souhaite suspendre un pipeline particulier, conserver les enregistrements associés et empêcher la connexion d'une nouvelle source de données jusqu'à la fin de la revue. Les questions utiles ne sont pas de savoir si un opérateur imaginaire se comporte de manière héroïque. Elles sont de savoir si le consortium dispose d'un rôle nommé capable d'ordonner le changement, si la plateforme expose un mécanisme contrôlé, si l'action est enregistrée et si les flux dépendants sont visibles avant que l'interrupteur ne soit utilisé.
L'hypothèse est volontairement calme parce que l'autorité ordinaire est le sujet. Un service n'a pas besoin de tomber en panne pour que le client ait besoin de contrôle. Une revue de confidentialité, un changement de finalité, une décision d'approvisionnement, un différend contractuel, une préoccupation de sécurité ou un départ de personnel peuvent tous nécessiter une action délimitée. Si personne ne sait qui peut la prendre, ou si le client ne peut pas inspecter ce que l'action a fait, le problème n'est pas que le cloud est mystérieux. Le problème est que le modèle opérationnel n'a jamais été achevé.
Un bon contrôle opérationnel n'est pas nécessairement centralisé. Une grande institution peut répartir les responsabilités entre un propriétaire de service, un rôle de sécurité, une fonction de protection des données, une équipe d'exploitation et un fournisseur. La répartition peut réduire le risque qu'une personne prenne seule une décision préjudiciable. L'important est que la frontière d'autorité soit lisible. Chaque rôle doit savoir ce qu'il peut initier, ce qu'il peut approuver, ce qu'il doit consigner, quand il doit escalader et comment l'organisation se rétablit lorsque la personne habituelle est indisponible. Le cloud n'est pas dispensé de gouvernance parce que son tableau de bord est soigné.
La ligne de sous-traitance fait partie du service
La plupart des services cloud ne sont pas fournis par une seule entreprise utilisant un seul bâtiment et une seule pile logicielle. Ils peuvent impliquer des fournisseurs d'infrastructure, des opérateurs de réseau, des services de sécurité gérés, des partenaires de support, des processeurs de paiement, des mainteneurs de logiciels, des services d'identité, des fabricants de matériel et des sous-traitants spécialisés. Une chaîne complexe n'est pas une preuve d'échec. C'est une raison de décrire la chaîne. Le client doit savoir où commencent les dépendances matérielles, ce qu'elles sont autorisées à faire et comment un changement sera communiqué.
Le vocabulaire de la protection des données, avec ses notions de responsable de traitement et de sous-traitant, est utile ici, mais il ne doit pas devenir un substitut à la compréhension. Une liste de sous-traitants peut identifier les organisations qui traitent des données personnelles pour le compte d'un fournisseur. Elle peut ne pas répondre à toutes les questions opérationnelles concernant la fourniture de logiciels, le support matériel, l'administration à distance, la télémétrie, la réponse aux incidents ou l'autorité de l'entreprise. À l'inverse, un inventaire technique peut identifier des composants mais omettre qui a une obligation contractuelle envers le client. Les deux vues doivent être lues ensemble plutôt que considérées comme des documents concurrents.
Les orientations du CEPD sur le cloud recommandent une répartition claire des responsabilités et une attention particulière aux rôles des parties impliquées dans les services cloud. Cette préoccupation pratique reste vive car des modèles de prestation complexes peuvent créer l'impression que la responsabilité s'est évaporée dans l'architecture. Il n'en est rien. Quelqu'un décide toujours de la finalité d'une opération de traitement. Quelqu'un fixe toujours les conditions techniques. Quelqu'un accepte toujours un sous-traitant. Quelqu'un doit toujours expliquer ce qui s'est passé lorsqu'un système change. La complexité peut expliquer pourquoi la réponse prend du temps. Elle ne rend pas la question déraisonnable.
Il existe un test utile pour la matérialité. Si un fournisseur disparaissait de l'arrangement demain, le service perdrait-il une fonction dont le client a besoin, perdrait-il une propriété de sécurité, perdrait-il l'accès à un enregistrement ou perdrait-il la capacité de migrer ? Si la réponse est oui, ce fournisseur appartient à la cartographie des contrôles. La cartographie n'a pas à exposer chaque résistance ni à rendre publique chaque relation commerciale. Elle doit montrer les dépendances qui modifient la capacité du client à gouverner le travail. Une dépendance cachée n'est pas une abstraction intelligente. C'est une future réunion avec un ton légèrement différent.
Le contrôle des sous-traitants dépend aussi du temps. L'acheteur doit savoir comment les nouveaux sous-traitants et les fournisseurs opérationnels matériels sont introduits, quel préavis est donné, quel processus d'opposition ou d'évaluation s'applique et comment un changement est consigné. Une liste statique vaut mieux que pas de liste. Une liste à jour et consultable est préférable car elle reconnaît qu'un service n'est pas figé à la signature. L'organisation ne peut pas gouverner les dépendances dont on ne lui a pas signalé l'arrivée.
Le matériel a une politique, et une conséquence opérationnelle
Il est tentant d'arrêter l'analyse à l'interface logicielle. Le service fonctionne, le tableau de bord est dans la bonne langue, le contrat mentionne une région européenne, et l'infrastructure qui le sous-tend semble trop éloignée pour être utile. Pourtant, le matériel et sa chaîne de support peuvent être décisifs lorsque la disponibilité, la confidentialité, la maintenance, la réparation, la capacité ou la continuité comptent. La question n'est pas de savoir si un client doit auditer chaque puce. La question est de savoir si le client connaît les dépendances qui rendent le service choisi possible et ce qui se passe lorsque l'une d'elles change.
C'est ici que la distinction entre aspiration souveraine et autosuffisance mérite d'être faite avec soin. L'Europe participe aux chaînes d'approvisionnement mondiales. Aucune organisation sérieuse ne peut fabriquer chaque semi-conducteur, câble, serveur, composant de firmware, système d'exploitation et outil dans un seul périmètre d'achat. Ce ne serait d'ailleurs pas un seuil raisonnable pour chaque charge de travail. La souveraineté pratique est la capacité à reconnaître une dépendance, à poser des conditions autour d'elle, à conserver des alternatives là où elles sont nécessaires et à éviter de prétendre qu'un composant externe indispensable ne l'est pas.
Les dépendances matérielles peuvent affecter le contrôle du cloud par l'allocation de capacité, l'accès à la maintenance, les mises à jour logicielles, les voies de remplacement et les composants de confiance. Elles peuvent aussi affecter la faisabilité d'une migration. Une charge de travail conçue autour d'une fonctionnalité gérée particulière, d'un environnement d'accélérateur spécifique ou d'une intégration non documentée peut n'être techniquement portable que de la même manière qu'un piano est portable lorsque quelqu'un propose de le monter six étages. Le nom est correct. Le plan est incomplet.
L'évaluation des risques du cloud de l'ENISA est désormais une publication plus ancienne, mais sa mise en garde concernant l'enfermement propriétaire, le risque juridique et la perte de contrôle n'est pas devenue désuète. Le vocabulaire technique a changé plusieurs fois depuis sa parution. La question sous-jacente n'a pas changé : que perd le client si le service change, si la relation prend fin ou si une dépendance ne se comporte pas comme prévu ? Une évaluation des risques n'exige pas qu'un acheteur rejette tout service géré. Elle demande à l'acheteur d'attacher des conséquences aux dépendances avant que la dépendance ne devienne une urgence.
Un fichier cloud sensible au matériel peut rester proportionné. Enregistrez l'architecture au niveau qui importe pour la charge de travail. Identifiez les dépendances uniques et les points uniques de connaissance opérationnelle. Énoncez les conditions contractuelles qui affectent la continuité et la migration. Demandez quelle voie de support est nécessaire pour les mises à jour de sécurité ou la récupération. Vérifiez si un environnement de remplacement nécessite les mêmes composants propriétaires. L'objectif n'est pas un catalogue de musée. C'est une image sobre des éléments qui doivent rester disponibles pour que l'organisation continue son travail.
La sortie est une capacité, pas un bouton de téléchargement
La question la plus révélatrice sur le cloud est souvent ce qui se passe lorsque le client veut partir. Partir peut signifier passer à un autre fournisseur, ramener une fonction dans un environnement sur site, changer l'architecture, réduire le service ou l'arrêter. Un client peut parfois exporter une base de données et être tout de même incapable de reprendre le service. La fonction peut aussi dépendre de la configuration, des identités, des clés, des journaux, des permissions, de l'automatisation, des modèles, du matériel d'évaluation, de la lignée des données, des règles d'intégration et des connaissances opérationnelles qui font fonctionner les éléments ensemble.
Le Data Act est exceptionnellement concret sur ce point. Ses dispositions sur le changement de fournisseur exigent que les contrats définissent les droits et obligations relatifs au changement et au portage des données exportables et des actifs numériques. Il établit une période transitoire maximale normale de 30 jours calendaires après le délai de préavis pertinent, tout en permettant une période alternative dans des cas définis d'impossibilité technique, sous conditions. Il traite également des interfaces ouvertes et de l'interopérabilité. Le règlement donne aux acheteurs quelque chose de précieux : une raison juridique de demander la voie avant d'en avoir besoin.
The limits are just as important. The Data Act does not make every digital asset transferable, does not require a provider to disclose protected intellectual property or trade secrets, and does not guarantee functional equivalence at a destination. A provider can meet legal duties while a migration remains difficult. A buyer can have an export right while lacking the people, budget or destination needed to use it. This is why exit should be treated as a capability shared between contract, architecture and organisation, rather than a promise made by one line in an order form.
A credible exit file records the target service type, the data and assets that are exportable, their formats, the procedure for obtaining them, the expected continuity conditions, the retrieval period, the destination assumptions and the parts of the function that cannot simply move. It identifies who will validate that the exported material is usable. It records what logs and evidence must survive. It names the authority that can accept the switch or decide that it is not yet safe to complete. This is less exciting than a migration announcement. It is much more likely to make the announcement true.
Testing matters. A small, bounded exercise can reveal whether a format is merely available or actually usable, whether an identity can be recreated without altering permissions, whether a key can be transferred under the right authority, whether records retain their meaning, and whether a reduced service can continue while the full service moves. This is not a claim that every organisation must rehearse a complete cloud exit every month. The scope should reflect the consequence of interruption. It is a claim that an untested exit is an intention, not yet an option.
What a European cloud assessment should contain
A useful assessment begins by naming the function, not the supplier. What work is the service expected to support? What data, records, rights, continuity needs and public consequences are involved? A low-consequence collaboration tool and a system holding sensitive operational records do not need identical controls. Starting with the workload prevents an organisation from applying a large sovereignty label to a small and specific decision, or from treating a critical service as if it were another office subscription.
Then make a location statement with a boundary. State where the relevant working plane is expected to operate, what data categories it covers, which copies and diagnostics are included, which transfers are allowed, how the position is evidenced and how changes are notified. If the supplier can only make a broad regional statement, record that limitation. A buyer is allowed to distinguish between a precise commitment and a general commercial description. The distinction is not hostile. It is what contracts are for.
Next make an entity and authority map. Record the contracting entity, group entities with a material role, named processors or subprocessors where relevant, the roles that can administer the service, the escalation path, the identity and key arrangements, and the customer authority that remains after outsourcing. Include the legal and technical evidence that supports each entry. Do not write provider or customer where a particular entity, role or mechanism is known. General nouns are very good at concealing specific absences.
Ajoutez une cartographie des dépendances. Elle doit inclure les logiciels, le matériel, le réseau, le support et les dépendances d'intégration concernés, le chemin de changement pour chacun, et les conséquences d'une perte ou d'une altération. Elle n'a pas besoin de prédire l'avenir. Elle doit rendre la conception actuelle contestable. Si une dépendance est acceptable, notez pourquoi. Si elle ne l'est pas, indiquez la condition de refus. Si elle est inconnue, ne résolvez pas l'inconfort en la qualifiant de faible risque. Inconnu est un statut réel, et il mène souvent au prochain travail.
Enfin, joignez le registre de sortie et de revue. Capturez les dispositions contractuelles applicables, les procédures d'exportation, les tests effectués, les lacunes constatées, les actions correctives, la date de revue et les événements qui déclenchent une réévaluation. Le but n'est pas de produire un dossier parfait. Il est d'établir un compte vivant du contrôle qui survit à un changement de personnel, à une mise à jour de service, à un renouvellement de contrat et au jour où quelqu'un doit prendre une décision inconfortable rapidement. Un rapport qui ne peut pas être mis à jour devient de l'histoire avec une facture jointe.
Ce que la commande publique peut demander sans prétendre tout résoudre
Les acheteurs publics ont une raison particulière d'insister sur ces preuves car ils détiennent souvent des responsabilités qui ne s'arrêtent pas à la signature d'un contrat. Ils peuvent être redevables envers les citoyens, soumis aux règles d'accès aux documents publics, responsables de fonctions essentielles ou tenus d'expliquer pourquoi une décision était raisonnable. Cela ne signifie pas que la commande publique peut éliminer toute dépendance étrangère, ni qu'une préférence nationale remplace une évaluation technique. Cela signifie que l'appel d'offres peut poser des questions qui rendent l'arrangement visible avant qu'il ne devienne ancré.
Un appel d'offres proportionné peut demander les entités qui fourniront des parties matérielles du service, les limites géographiques et juridiques revendiquées, le modèle de rôle et d'autorité, le processus de changement de sous-traitant, le parcours de support et d'incident, les preuves conservées pour le client, la procédure d'exportation et de bascule, et les conditions dans lesquelles un client peut suspendre, limiter ou cesser l'utilisation. Il peut noter la qualité des réponses plutôt que récompenser un adjectif. Un fournisseur qui connaît son propre modèle d'exploitation devrait pouvoir l'expliquer sans machine à brouillard.
Il y a des compromis. Plus de preuves peuvent allonger une procédure. Certaines exigences peuvent réduire le nombre d'offres. Un petit fournisseur peut avoir moins de capacité à produire une documentation élaborée même lorsque son modèle de contrôle est solide. Un titulaire peut avoir un excellent service technique mais un chemin de sortie qui nécessite une négociation. Ce ne sont pas des arguments pour sauter les questions. Ce sont les faits dont un acheteur a besoin pour décider quel coût est acceptable : le coût des preuves et des alternatives maintenant, ou le coût de la dépendance plus tard.
Les travaux de la Commission européenne sur la souveraineté du cloud ont rendu cette direction visible en termes de commande publique, mais les acheteurs n'ont pas besoin d'attendre un badge universel. Ils peuvent définir leur propre frontière de risque et exiger des preuves qui lui correspondent. Une bibliothèque publique, une agence de recherche, un service municipal et un opérateur d'infrastructure critique n'utiliseront pas le même seuil. Ils ne devraient pas. Le test est de savoir si les exigences suivent la fonction, sont publiées équitablement, peuvent être évaluées de manière cohérente et préservent la capacité du client à expliquer ce qu'il a choisi.
C'est la promesse plus discrète de la politique cloud européenne. Elle peut déplacer la conversation du théâtre de la nationalité vers la gouvernance des relations. La réponse européenne n'a pas besoin d'être une île technologique scellée. Elle peut être un marché plus adulte dans lequel les affirmations sur la localisation, le contrôle, le droit et la sortie sont des affirmations distinctes, étayées par des preuves distinctes. L'interdépendance ne disparaît pas lorsqu'elle est nommée. Elle devient possible à décider là où elle est tolérable.
Les contrôles ne se répondent pas les uns aux autres
Il vaut la peine de résister à un dernier raccourci. Un chiffrement fort ne répond pas à une question de propriété. Des clés détenues par le client peuvent réduire certains risques d'accès et constituer un contrôle important, mais elles n'établissent pas à elles seules qui exploite le service, qui contrôle la plateforme, quelles informations restent visibles dans les métadonnées, ni si le client peut déplacer la fonction. Une bonne clause de sortie ne répond pas à une question de juridiction. Une maison mère européenne ne répond pas à une question de support matériel. Chaque contrôle a un rôle. Chacun doit être évalué pour le rôle qu'il joue réellement.
C'est aussi pourquoi une décision sur le cloud doit pouvoir dire « pas assez » sans devenir théâtrale. Un acheteur peut estimer que l'engagement de localisation est adéquat mais que le préavis de modification est trop vague. Il peut accepter un sous-traitant tout en exigeant une voie d'autorité plus claire. Il peut accepter une dépendance matérielle étrangère tout en insistant sur un plan de remplacement documenté. Il peut décider qu'un service particulier ne convient pas à une catégorie de données donnée tout en restant adapté à une autre. La nuance n'est pas un échec de décision. C'est la condition pour décider sur la base de preuves plutôt que de reconnaissance de marque.
Le travail devient plus facile lorsque les preuves sont conservées à proximité de la décision. Ne placez pas la déclaration de localisation des données dans un système, le contrat dans un autre, l'examen des accès dans une boîte de réception et le plan de sortie dans la mémoire de quelqu'un. Reliez-les au dossier du service et donnez à ce dossier un responsable. Lorsqu'une exigence change, l'organisation doit pouvoir trouver les preuves, identifier la frontière concernée et décider si le service peut continuer. C'est la gouvernance sous son jour le moins glamour et le plus utile.
Une courte note de notre part
Notre rapport The Sovereignty Illusion utilise cinq prismes pratiques pour une question similaire : propriété, technologie, capital, infrastructure et exposition juridique. C'est notre cadre de recherche, non une classification juridique et non une preuve qu'un service particulier répond aux besoins d'un client. Sa contribution utile est une habitude d'attention. Lorsqu'une affirmation sur le cloud semble complète, demandez lesquels de ces prismes elle a réellement couverts et lesquels restent hors du cadre.
Cette habitude façonne également la manière dont nous décrivons notre propre travail. Une affirmation de souveraineté doit être délimitée par le déploiement, le contrat et la responsabilité d'exploitation, non gonflée en une promesse qu'une page produit ne peut pas tenir. Le client, la charge de travail et le modèle de contrôle convenu décident toujours de ce qui peut honnêtement être dit. Dans un domaine plein de grands mots, la retenue n'est pas un inconvénient marketing. Elle fait partie des preuves.
La question après le nom de la ville
La localisation européenne reste une question qui vaut la peine d'être posée. Elle peut être une exigence légale, une exigence opérationnelle, un choix de résilience, un choix de sécurité physique ou une expression de responsabilité publique. Un acheteur ne devrait pas avoir honte de demander où un système fonctionne. Il devrait simplement poser la question en bonne compagnie. Qui possède l'entité qui compte ? Qui a l'autorité d'exploitation ? Quels ordres juridiques peuvent atteindre l'arrangement ? Quels sous-traitants et composants sont matériels ? Que peut inspecter, arrêter, déplacer et préserver le client ?
Ces questions ne rendent pas l'informatique cloud moins utile. Elles rendent l'utilisation de l'informatique cloud plus délibérée. Elles remplacent une atmosphère de réassurance par un dossier qui peut être examiné. Elles donnent aux fournisseurs une occasion équitable de montrer les contrôles qu'ils ont construits, et aux acheteurs un moyen équitable de distinguer une limite utile d'une affirmation vide. Plus important encore, elles préservent la possibilité de changer de cap avant qu'une dépendance ne se transforme en accusation.
La question du cloud européen ne porte donc pas sur l'emplacement du serveur. Elle porte sur l'emplacement du contrôle lorsque le système doit évoluer. Un centre de données peut faire partie de la réponse. Un contrat européen peut faire partie de la réponse. Un fournisseur européen peut faire partie de la réponse. La réponse ne devient crédible que lorsque l'organisation peut suivre le parcours du lieu vers la propriété, de la propriété vers la portée juridique, de la portée juridique vers l'autorité d'exploitation, et de l'autorité vers une voie de sortie éprouvée. Ce parcours est moins mémorable qu'un drapeau à côté d'un bâtiment. C'est aussi là que le travail commence.
Sources
- Cloud Computing, Contrôleur européen de la protection des données. Utilisé pour la position des orientations du CEPD selon laquelle les institutions de l'UE restent responsables de leurs obligations en matière de protection des données et doivent garantir une protection équivalente.
- EDPB publishes three guidelines following public consultation, Comité européen de la protection des données, 24 février 2023. Utilisé pour la portée et l'objectif des orientations finales sur l'article 3 du RGPD et le chapitre V relatif aux transferts internationaux.
- Regulation (EU) 2023/2854 (Data Act), EUR-Lex. Utilisé pour les dispositions relatives au changement de fournisseur, à l'exportation, à la continuité, à l'interopérabilité et à l'accès des autorités publiques internationales pour les services de traitement de données.
- Cloud Computing Risk Assessment, Agence de l'Union européenne pour la cybersécurité. Utilisé pour le cadre d'évaluation des risques liés à l'enfermement propriétaire, au risque juridique et à la perte de contrôle.
- The Sovereignty Illusion, Dweve. Utilisé uniquement pour le cadre de recherche Dweve à cinq perspectives divulgué.