La souveraineté commence à l'interrupteur

La souveraineté numérique n'est pas un drapeau planté à côté d'un centre de données. C'est la capacité éprouvée d'inspecter, d'arrêter, de modifier, de...

La souveraineté commence à l'interrupteur

A button on a slide is not an off switch

In April 2026, the European Commission awarded an EUR 180 million contract for sovereign cloud to four providers serving the Union’s institutions, bodies, offices and agencies. The tender was run under the Cloud III Dynamic Purchasing System. When the Commission explained the result, it also explained the instrument behind it: a Cloud Sovereignty Framework with a Sovereignty Effectiveness Assurance Level and an overall score built from 48 criteria in eight categories, including strategic, legal and jurisdictional, data and AI, operational, supply chain, technological, security and compliance, and environmental sustainability.

That is a more interesting event than the adjective sovereign normally suggests. A tender has to turn a political word into questions that can be answered by a procurement file. Who can reach the data? Who can operate the platform? What happens when a supplier changes ownership, when a law changes, when a service is withdrawn, or when an institution decides that the arrangement no longer fits? The Commission’s framework does not settle those questions for every buyer. It does something more useful: it admits that they belong in the same room.

The temptation is to treat sovereignty as a place. Put the servers in Europe, sign with a European subsidiary, place the contract under European law, and the problem appears to have been dealt with. Each of those steps can matter. None of them is the whole property. A system can be physically near the people it serves while its decisive keys, technical dependencies, operating authority and legal exposure sit elsewhere. A European address can be true and still be an incomplete answer.

There is a test that makes the gap visible. Ask what happens when the organisation needs to stop. Not because stopping is desirable, and not because a dramatic failure is expected, but because serious institutions have to be able to change course. Can an authorised person suspend the service? Can the organisation inspect the state that will be stopped? Can it preserve evidence? Can it move the workload? Can another team take over without asking the first provider to remain indispensable? If the answer is vague, the sovereignty claim is still a brochure.

This is why sovereignty begins at the off switch. The switch is not a theatrical red button. It is a chain of authority, access, knowledge, equipment, contracts and alternatives. It has to work on a quiet Tuesday, before anybody has prepared a press statement. The rest of this article follows that chain through cloud infrastructure, European policy and the unglamorous engineering of exit.

Five words that are often made to impersonate one another

Ownership is the first impostor. It tells us who holds the shares, appoints the board and receives the economic benefit. Ownership can be important to sovereignty, especially where the owner controls intellectual property, investment decisions or the company’s long-term direction. It is not the same as operational control. A locally owned organisation can depend on a foreign operating platform. A publicly owned service can have no practical ability to change the software that runs it. A subsidiary can be incorporated in one country while its decisive approvals are made somewhere else.

Location is the second. Data residency answers a geographical question: where are particular data, systems or facilities stored or processed under the arrangement? That answer can support legal compliance, resilience planning or a sensible latency budget. It does not answer who can administer the environment, which law can compel a provider, which subcontractors can enter the chain, or what happens when an operator outside the location holds the privileged credentials.

La juridiction est le troisième. Elle concerne l'ordre juridique qui peut atteindre une organisation, son infrastructure ou ses données. Un contrat peut désigner une loi applicable, mais il ne peut pas faire disparaître d'autres pouvoirs juridiques. Un service peut être fourni depuis une installation européenne et impliquer néanmoins un fournisseur soumis à des obligations ailleurs. Il ne s'agit pas de déclarer illégitime tout service transfrontalier. Il s'agit de cesser de traiter un point sur une carte comme une analyse juridique.

L'autorité d'exploitation est le quatrième. C'est la capacité pratique de faire faire quelque chose à un système ou de l'arrêter : approuver une version, faire pivoter une clé, isoler un réseau, restaurer une sauvegarde, modifier une politique, supprimer un administrateur ou transférer la responsabilité à une autre équipe. L'autorité d'exploitation peut être déléguée. Lorsqu'elle est déléguée, la délégation doit être visible, limitée et réversible. Sinon, un contrat donne au client un contrôle nominal tandis que le fournisseur conserve les seules personnes et interfaces capables de l'exercer.

La sortie est le cinquième. C'est la capacité de mettre fin à un arrangement et de poursuivre la fonction nécessaire ailleurs ou sur une infrastructure que l'organisation contrôle. La sortie ne consiste pas simplement à télécharger une base de données. Elle peut impliquer la configuration, les identités, les clés de chiffrement, les modèles, les conteneurs, les journaux d'audit, les files d'attente, les intégrations, les licences, les procédures d'exploitation et le savoir-faire nécessaire pour reconstruire un service fonctionnel. Une promesse d'exportation des données n'est pas une promesse de reprise du service.

Ces mots vont ensemble, mais ils ne doivent pas être confondus. La propriété sans autorité d'exploitation est un titre de propriété sans clé. La localisation sans juridiction est une adresse postale sans carte de la portée juridique. L'autorité d'exploitation sans sortie est une télécommande attachée à une machine que personne d'autre ne peut réparer. La souveraineté est la relation entre les cinq, mise à l'épreuve au moment où la commodité ne décide plus.

Le test de l'interrupteur d'arrêt

Un test utile de l'interrupteur d'arrêt commence par une instruction délibérément banale : arrêter ce système à une frontière définie, d'une manière définie, sous une autorité identifiée. « Ce système » doit être précis. S'agit-il d'un service, d'un locataire, d'un traitement, d'un flux de données, d'un compte administrateur, d'un point de terminaison de modèle ou d'une capacité opérationnelle entière ? Un fournisseur peut être en mesure de désactiver un point de terminaison tandis que les données, les copies et les chemins privilégiés continuent ailleurs. Un client peut être en mesure de résilier un contrat tout en découvrant que la seule exportation disponible est un ensemble d'enregistrements sans configuration utilisable.

Demandez d'abord qui est autorisé à ordonner l'arrêt. La réponse doit être un rôle, pas la mémoire d'une personne. Un rôle peut être attribué, vérifié et modifié. Il doit avoir un déclencheur clair, une voie d'escalade et une trace de la décision. Dans une institution publique, l'autorité peut être répartie entre la propriété du service, la sécurité, la responsabilité juridique et un officier de permanence. Cette répartition n'est pas un défaut. Elle devient un défaut lorsque chacun suppose que quelqu'un d'autre peut agir.

Demandez ensuite quelle information d'identification ou quel mécanisme effectue réellement l'arrêt. Une procédure documentée qui se termine par « contacter le support » est une voie d'escalade, pas un interrupteur d'arrêt. Le support peut être approprié pour une migration contrôlée, mais un service critique a également besoin d'un moyen local ou contrôlé indépendamment de mettre le système dans un état sûr. Cela n'implique pas que chaque client doive avoir un bouton d'alimentation physique. Cela signifie que l'organisation doit connaître la limite de sa propre autorité, celle du fournisseur et le point auquel une réponse externe est requise.

Demandez ensuite ce qui reste après l'arrêt. Un arrêt sûr peut préserver les journaux, conserver les preuves pendant une période définie, fermer les sessions, révoquer les identifiants, empêcher de nouvelles écritures et garder une copie en lecture seule disponible pour l'investigation. Il peut aussi créer un état dangereux si un processus dépendant continue d'envoyer des données vers un service qui n'est plus surveillé. Arrêter un composant ne revient pas à arrêter la capacité. La carte des dépendances importe plus que la couleur du bouton.

Demandez enfin si l'organisation peut reprendre la fonction sans revenir par défaut à la même dépendance. Un service peut être arrêté pour une action de confinement brève, puis redémarré. Cela est utile. La souveraineté exige aussi une seconde voie : un itinéraire préparé vers un autre fournisseur, un environnement local, un processus manuel connu ou un service volontairement réduit. L'alternative peut être plus lente ou moins élégante. Elle ne peut pas exister seulement comme une phrase dans un registre des risques.

Le test de l'interrupteur comporte donc cinq volets : l'autorité, le mécanisme, les preuves, la dépendance et l'alternative. C'est un test institutionnel, pas une fonctionnalité de produit. Un fournisseur peut offrir d'excellents outils et échouer au test si le client ne peut pas les exercer. Un client peut détenir un contrat et échouer si personne n'a pratiqué la procédure. Une organisation qui a répété le test peut découvrir des faiblesses tôt, quand ce sont encore des problèmes d'approvisionnement et d'ingénierie plutôt que des urgences publiques.

Une carte illustrative, pas un score : survolez les couches pour voir ce que chacune peut et ne peut pas prouver sur le contrôle.

Le contrôle est une pile, pas un autocollant

Imaginez un système comme une pile de pièces. En bas se trouve la couche physique : bâtiments, alimentation électrique, refroidissement, chemins réseau et matériel. Au-dessus se trouvent les couches techniques : micrologiciels, systèmes d'exploitation, virtualisation, stockage, bases de données, identité et code applicatif. Au-dessus de celles-ci se trouvent les couches opérationnelles : personnes, procédures, surveillance, réponse aux incidents et gestion des versions. À leurs côtés court une couche juridique et économique : propriété, contrats, licences, juridiction, financement et capacité d'acheter une alternative.

La métaphore de la pile n'affirme pas que tous les systèmes ont cinq étages bien nets. C'est une façon de poser une question plus précise que « est-ce souverain ? » Le contrôle peut être fort dans une pièce et faible dans une autre. Une institution peut avoir le droit d'inspecter une application sans avoir aucune visibilité sur le chemin d'administration physique. Elle peut détenir des clés de chiffrement sans pouvoir remplacer le matériel qui maintient le service de clés en vie. Elle peut avoir une clause de sortie contractuelle tout en portant une dépendance opérationnelle envers une équipe que seul le fournisseur emploie.

Il n'y a aucune vertu à prétendre que chaque couche doit être européenne de la même manière. L'économie numérique européenne dépend de chaînes d'approvisionnement internationales, de la recherche, des normes et des marchés. L'autonomie stratégique n'est pas un fantasme d'autosuffisance totale. La définition politique de la Commission européenne parle de la capacité d'agir indépendamment tout en réduisant la dépendance envers les fournisseurs hors UE. Agir indépendamment peut signifier avoir un choix crédible, pas fabriquer chaque composant derrière une clôture nationale.

The practical distinction is between dependence that is visible and bounded, and dependence that is mistaken for control. A buyer can decide that a particular processor, software component or external service is acceptable. The decision should include the reason, the compensating measures, the replacement route and the authority to revisit it. A dependency that is recorded can be governed. A dependency hidden behind a European label will be discovered only when the label stops opening doors.

The stack also explains why a sovereignty score needs more than ownership. The Commission’s 2026 framework places strategic, legal and jurisdictional, data and AI, operational, supply chain, technological, security and compliance, and environmental sustainability criteria beside one another. A list like this does not magically produce a sovereign service. It does acknowledge that control is distributed. That is already a better starting point than a single badge.

For engineers, the stack invites a dependency inventory. For procurement teams, it invites questions about subcontractors, keys, formats, interfaces, support and migration. For lawyers, it invites a map of legal reach that follows the provider and the infrastructure rather than the marketing name. For leaders, it makes a quiet point: the most expensive dependency is often the one that everyone thought had already been dealt with.

Location is useful, and insufficient

A data centre is a real place. Its walls affect physical security, energy use, network latency, labour arrangements and the resilience of a service. A residency requirement can prevent some transfers and can make an audit more concrete. It can also be a sensible expression of a public body’s legal and political responsibility. There is no need to sneer at geography to make the control point.

The mistake is asking geography to answer all the other questions. A server in Rotterdam does not, by itself, tell a buyer who has administrative access. A storage bucket in Milan does not say which telemetry is copied to a support system. A European subsidiary does not disclose the jurisdiction of the group that supplies its control plane. The location of a building and the reach of an organisation are related facts, not interchangeable facts.

The Data Act makes part of this distinction explicit. Article 28 requires providers of data processing services to make available the jurisdiction to which the infrastructure used for a service is subject, together with a general description of measures concerning international governmental access to or transfer of non-personal data where that could conflict with Union or Member State law. The requirement is valuable because it turns a vague assurance into information a customer can put in a file. It is not a guarantee that no authority will ever ask for access, and it is not a replacement for a customer’s own legal and technical assessment.

Location also changes over time. A provider can move a workload, add a subcontractor, introduce a support path, change a control-plane design or alter its ownership. A residency statement that was accurate on the day of signature can become stale. Sovereignty therefore needs a change signal: who is notified, which change triggers review, and who can pause the service while the review happens? Without that signal, a location claim is a snapshot masquerading as a property.

Considérons une organisation de recherche européenne hypothétique qui exige que son jeu de données principal reste au sein de l’Union. Cette exigence peut être satisfaite alors qu’un flux de travail de support envoie des éléments de diagnostic vers un pays tiers, qu’un service d’identité contrôlé par un fournisseur administre le cluster, ou qu’un format propriétaire rende tout remplacement impossible. Aucune de ces possibilités n’est affirmée comme un fait concernant une organisation nommée. Elles sont la raison pour laquelle un contrôle de localisation devrait être associé à une carte des accès, une carte des juridictions et une répétition de sortie.

La déclaration la plus honnête est simple : la localisation peut réduire une catégorie de risques. Elle ne peut pas porter à elle seule l’argument de la souveraineté. Un bâtiment est une couche. Le contrôle est la pile.

La juridiction n’est pas une note de bas de page

La juridiction entre en jeu chaque fois qu’une promesse rencontre un pouvoir. Un contrat peut préciser où les litiges seront entendus et quelle loi régit la relation. Cela importe pour la prévisibilité et l’exécution. Cela ne signifie pas qu’un fournisseur, sa société mère, son personnel ou son infrastructure soient invisibles à tout autre système juridique. La question pour un acheteur n’est pas de savoir si une juridiction peut être nommée. Elle est de savoir quelles voies juridiques peuvent atteindre les personnes, les systèmes et les données concernés, et ce que le fournisseur serait tenu de faire si ces voies étaient utilisées.

Il ne s’agit pas de plaider pour que toute connexion étrangère soit traitée comme interdite. Il s’agit de remplacer le raccourci de la nationalité par une analyse documentée. Un fournisseur peut avoir une société européenne, des opérations européennes et une chaîne d’approvisionnement qui traverse plusieurs frontières. Un acheteur peut accepter cet arrangement parce que le service est résilient, que les contrôles d’accès sont solides, que les données concernées sont limitées et qu’une alternative est prête. La décision est défendable lorsque la dépendance et le risque résiduel sont visibles.

Le mot contrôle demande aussi ici une attention particulière. Un fournisseur peut affirmer que le client contrôle ses données parce que le client choisit les autorisations. Cela peut être vrai au sein du service. Cela ne signifie pas automatiquement que le client contrôle le fournisseur, la trajectoire de maintenance de la plateforme ou la réponse juridique à une injonction externe. Le mot devrait être qualifié : contrôle de l’accès, contrôle des clés, contrôle de la configuration, contrôle des opérations, ou contrôle de la décision commerciale. La précision est moins spectaculaire qu’un logo de souveraineté, mais elle résiste mieux à un audit.

Le cadre de la Commission place les questions juridiques et de juridiction à côté des questions opérationnelles et de chaîne d’approvisionnement. Cet agencement importe. L’exposition juridique ne peut pas être réduite à un paragraphe dans un contrat, et le contrôle technique ne peut pas être réduit à un schéma. Si un système est destiné à soutenir une fonction publique, l’institution a besoin de suffisamment d’éléments pour expliquer à la fois comment il fonctionne et quelles autorités peuvent l’affecter. Les éléments peuvent être incomplets. Ils ne devraient pas être imaginaires.

Un dossier de juridiction pratique devrait identifier les entités juridiques de la chaîne de service, la localisation et le rôle de l’infrastructure concernée, les voies d’accès disponibles pour le personnel du fournisseur et les sous-traitants, les lois applicables et gouvernantes divulguées par le fournisseur, ainsi que la procédure de notification et de réponse aux demandes gouvernementales. Il devrait également indiquer ce que le client fera si les réponses changent. Cette dernière phrase est le point où la souveraineté commence à devenir opérationnelle plutôt que descriptive.

L’expérience d’achat de la Commission

L’achat de cloud souverain de la Commission est utile parce qu’il rend le mot observable. L’explication publique indique que quatre fournisseurs ont été sélectionnés pour un contrat de 180 millions d’euros au service des entités de l’Union. Elle décrit deux mesures complémentaires : un niveau d’assurance d’efficacité de la souveraineté, avec des seuils pour la souveraineté des données, l’autonomie technologique et la souveraineté totale, ainsi qu’un score global fondé sur 48 critères définis regroupés en huit catégories.

Il y a une discipline petite mais importante dans cette formulation. Le cadre est un instrument d'évaluation. Il ne transforme pas un fournisseur en objet souverain par simple déclaration. Un score peut rendre visibles les arbitrages, aider un acheteur à comparer les offres et créer une trace écrite des raisons d'une attribution. Il peut aussi être contourné ou devenir obsolète si personne ne vérifie les preuves qui le sous-tendent. La question pertinente n'est pas de savoir si le cadre est la réponse définitive. Elle est de savoir si les critères survivent au contact avec les opérations.

Prenons la catégorie appelée souveraineté opérationnelle. Elle devrait susciter des questions telles que : qui peut modifier une route réseau, qui peut faire pivoter une clé, qui peut lire un journal d'incidents, à quelle vitesse un client peut reprendre une fonction et quelles actions nécessitent la participation du fournisseur. Ce ne sont pas des qualités abstraites. Elles peuvent être démontrées dans un exercice contrôlé. Si l'exercice est impossible parce que le fournisseur ne peut pas exposer l'état pertinent ou parce que le client n'a pas l'autorité de l'initier, la faiblesse fait partie du score, et non un détail gênant à reléguer en annexe.

Il en va de même pour les catégories technologiques et de chaîne d'approvisionnement. Un acheteur n'a pas besoin d'exiger un test de pureté impossible. Il doit savoir quelles dépendances sont essentielles, lesquelles peuvent être substituées, lesquelles comportent un verrouillage contractuel ou technique, et à quoi ressemblerait une interruption. « Nous avons une équipe de support européenne » et « nous pouvons poursuivre cette fonction lorsqu'un composant amont critique est indisponible » sont des affirmations différentes. La première concerne les personnes. La seconde concerne la résilience et le choix.

Les marchés publics sont particulièrement bien adaptés à ce travail, car un appel d'offres peut exiger des preuves avant qu'un service ne devienne la solution par défaut. Un appel d'offres peut demander un format portable, un registre des dépendances à jour, une procédure de notification des changements, une répétition de sortie et une matrice d'autorités. Il peut noter les réponses et rejeter un service qui ne peut pas les fournir. Il peut aussi financer la capacité à maintenir l'alternative, car une sortie qui n'existe que dans un document dormant se dégradera.

La publication de la Commission présente son cadre comme une référence pour les organisations publiques et privées. C'est une invitation, pas une approbation selon laquelle chaque organisation devrait copier chaque pondération. Un petit service et une plateforme à l'échelle continentale auront des risques différents. La méthode qui vaut la peine d'être retenue est l'habitude de décomposer la souveraineté en critères, preuves et seuils. Les achats peuvent dire non. C'est l'un des rares pouvoirs qui s'affaiblit après le déploiement.

La sortie est une propriété d'ingénierie

Les contrats cloud décrivent souvent la sortie comme s'il s'agissait d'un paragraphe final poli. Le règlement sur les données la traite comme un processus. L'article 23 exige que les fournisseurs de services de traitement de données suppriment les obstacles qui empêchent un client de résilier un contrat, d'en conclure un nouveau, de transférer les données exportables et les actifs numériques, d'atteindre l'équivalence fonctionnelle le cas échéant, ou de désagréger les services lorsque cela est techniquement faisable. Les articles 25 à 30 précisent ensuite les obligations contractuelles, d'information, de coopération, de frais et techniques.

Les détails sont inhabituellement pratiques. Dans le cas ordinaire, un contrat doit prévoir un délai de préavis maximal de deux mois et une période transitoire obligatoire de 30 jours calendaires au plus, durant laquelle le fournisseur poursuit le service et soutient la continuité. Si le fournisseur affirme que la période de 30 jours est techniquement irréalisable, il doit en informer le client dans les 14 jours ouvrables, justifier cette affirmation et indiquer une période transitoire alternative de sept mois au plus. Le client dispose d'une période de récupération d'au moins 30 jours calendaires après la période transitoire, et le contrat doit traiter de l'effacement après une migration réussie.

L’article 29 fixe également la direction à suivre en matière de frais de changement. À compter du 12 janvier 2027, les fournisseurs ne peuvent plus imposer de frais de changement pour le processus de bascule. Pendant la transition, des frais réduits ne peuvent être imposés que dans les limites fixées par le règlement, et les clients potentiels doivent être informés des frais et pénalités susceptibles de s’appliquer. L’article 30 traite des interfaces ouvertes, des spécifications d’interopérabilité et de l’exportation lisible par machine. Il ne s’agit pas de détails décoratifs. Ce sont les éléments à partir desquels un service de remplacement doit être assemblé.

Un droit légal n’est pas la même chose qu’un chemin bien rodé. Un client peut recevoir une exportation conforme et manquer néanmoins de personnes, d’outils ou de temps pour restaurer le service. Les données peuvent être portables sans que la signification d’un identifiant le soit. Un modèle peut être copié tandis que son ensemble d’évaluation, sa politique de prompt, ses règles d’accès et son historique de surveillance restent en arrière. Un conteneur peut être déplacé alors que les hypothèses d’identité et de gestion des clés l’empêchent de démarrer. La loi améliore le plancher. C’est l’ingénierie qui décide si quelqu’un peut marcher dessus.

C’est pourquoi la sortie doit être testée par couches. Commencez par un échantillon de données exportables et reconstruisez-le dans un environnement séparé. Restaurez ensuite les identités et les permissions avec le moindre privilège. Reconstruisez le service à partir d’une configuration documentée plutôt que de la mémoire d’un ingénieur. Rejouez des charges de travail représentatives et comparez les résultats, y compris les cas qui devraient échouer. Vérifiez que les enregistrements d’audit conservent leur signification. Refaites l’exercice après un changement matériel. Si l’exercice nécessite une intervention non divulguée du fournisseur, consignez cette dépendance au lieu de qualifier l’exercice d’indépendant.

L’expression équivalence fonctionnelle mérite également de la retenue. Le règlement sur les données la définit autour d’un résultat matériellement comparable pour les fonctions partagées dans le même type de service. Il ne promet pas que deux fournisseurs aient des architectures, des prix, des performances ou un support identiques. Un acheteur doit préciser ce qui doit rester équivalent, ce qui peut se dégrader temporairement et ce qui est autorisé à changer. Une voie de sortie qui préserve toutes les commodités peut être impossible. Une voie de sortie qui préserve la fonction publique peut suffire, à condition que l’institution ait choisi ce compromis à l’avance.

Une séquence de bascule conceptuelle alignée sur les obligations de sortie du règlement sur les données. Il s’agit d’une carte de répétition, pas d’une garantie de conformité juridique.

L’interrupteur appartient à une institution

Il est tentant de placer l’interrupteur dans une démonstration de produit. Appuyez sur une commande, regardez un voyant vert passer au gris, et appelez le système gouvernable. L’autorité réelle est plus maladroite. Elle siège dans une institution avec des descriptions de poste, des délégations, des congés, des priorités concurrentes et des personnes qui ne savent peut-être pas qu’elles sont celles qui sont censées agir.

Cela ne signifie pas que chaque employé devrait pouvoir arrêter chaque système. Cela signifie que l’autorité doit être conçue. Le propriétaire du service décide de la fonction du système. La sécurité peut identifier un déclencheur de confinement. Les équipes juridiques et de confidentialité peuvent identifier les contraintes sur les preuves et l’accès. Les opérations peuvent exécuter la procédure. La direction peut résoudre un conflit entre continuité et retrait. Les rôles peuvent être combinés dans une petite organisation, mais les décisions doivent néanmoins être explicites.

Prenons l’exemple d’un service public régional hypothétique qui s’appuie sur une plateforme hébergée pour traiter des demandes. Nul besoin d’inventer un scénario de panne pour soulever la question de la gouvernance. Si un fournisseur modifie un chemin d’accès critique, qui examine ce changement ? Si la surveillance révèle un comportement inexpliqué, qui peut suspendre les nouvelles soumissions ? Si le contrat est résilié, qui détient l’exportation des données, qui vérifie qu’elle est complète, et qui décide si un processus manuel peut être exécuté en toute sécurité pendant que la solution de remplacement est élaborée ? Une politique qui désigne les responsabilités avant l’arrivée de la pression est plus utile qu’une promesse d’améliorer la coordination après l’incident.

La même discipline s’applique aux systèmes automatisés. Un composant d’IA peut être arrêté tandis que le flux de travail environnant continue de produire des décisions à partir de sorties en cache, de règles de repli ou d’hypothèses humaines. L’organisation doit donc définir l’unité d’autorité. L’interrupteur concerne-t-il le modèle, le service de décision, la file d’attente, l’étape de publication ou l’ensemble du processus ? Un interrupteur ciblé peut être plus sûr qu’un arrêt total, mais seulement si sa limite est connue et si son effet est observable.

La preuve fait partie de l’interrupteur institutionnel. Une action d’arrêt doit laisser une trace indiquant qui a agi, sous quelle autorité, à quel moment, avec quel état observé et quelle étape suivante. Cette trace n’est pas un ornement bureaucratique. Elle permet à l’organisation de distinguer une action de confinement délibérée d’une dégradation silencieuse, et permet à une équipe de repreneurs de comprendre ce qu’elle hérite. C’est la même raison pour laquelle le Data Act demande aux fournisseurs de fournir des informations sur les formats, les procédures et les limitations. Un système qui ne peut pas décrire son état ne peut pas être transféré de manière responsable.

Il y a aussi un enjeu de dignité humaine. Lorsque les organisations affirment qu’un fournisseur est indispensable, elles veulent souvent dire qu’un petit nombre de personnes comprennent l’arrangement. C’est une dépendance de connaissances, pas une fatalité. La documentation, la formation, les opérations en binôme et les exercices réguliers peuvent rendre l’autorité moins personnelle et plus durable. Le résultat peut sembler moins magique. Il est généralement plus résilient.

Un fichier de souveraineté qui survit à une réunion

Un fichier de souveraineté doit pouvoir être lu par un responsable des achats, un ingénieur, un juriste et un dirigeant responsable, sans que chacun doive traduire le document dans son propre langage privé. Il ne doit pas s’agir d’un dossier d’assurance de cent pages qui répond à toutes les questions sauf celle qu’un décideur s’apprête à poser. Un fichier compact peut renvoyer à des preuves plus approfondies tout en rendant visible la limite de contrôle.

Commencez par la définition du service. Nommez la fonction, les données, les utilisateurs, les décisions ou actions soutenues, l’interruption acceptable et les conséquences d’une poursuite non sécurisée. Indiquez ce qui est critique et ce qui est simplement pratique. Cela évite que l’organisation négocie la souveraineté pour un tableau de bord tout en négligeant le service d’identité qui permet à quiconque d’y accéder.

Ensuite, consignez la carte des contrôles. Pour chaque composant matériel, identifiez qui le possède, qui l’exploite, qui peut l’inspecter, qui peut le modifier, qui peut l’arrêter et qui peut le remplacer. Utilisez les noms réels des entités et des rôles issus du contrat et du modèle d’exploitation. Si un champ indique « fournisseur » ou « client » sans responsabilité nommée, c’est une invitation à poser une autre question.

Consignez ensuite la carte juridique et juridictionnelle. Incluez les entités contractantes, les entités fournisseurs concernées, les juridictions d’infrastructure divulguées dans le cadre de l’arrangement, les sous-traitants applicables, les voies d’accès et les procédures de notification. Précisez où les informations sont à jour et quand elles doivent être révisées. Une carte datée est plus honnête qu’une phrase d’assurance perpétuelle.

La section de sortie doit contenir un inventaire, pas seulement une intention. Listez les données exportables, les actifs numériques, la configuration, les identités, les clés, les journaux, les modèles, le matériel d’évaluation, les licences et les dépendances qui ne peuvent pas être déplacées. Pour chaque élément, indiquez son format, son propriétaire, sa méthode de récupération, son test de validation et sa règle de conservation ou d’effacement. Si un élément n’est pas exportable, expliquez pourquoi et décrivez le substitut. Il ne s’agit pas de punir un fournisseur pour avoir protégé des secrets commerciaux. Il s’agit d’empêcher que la capacité de travail du client soit confondue avec la machinerie interne du fournisseur.

Enfin, joignez un compte rendu d’exercice. Il doit montrer la date, le périmètre, les participants, les hypothèses, les lacunes observées, les actions correctives et le prochain déclencheur de révision. Un petit exercice de sortie peut être plus instructif qu’un grand plan théorique. L’exercice peut révéler qu’un format est techniquement disponible mais lent à interpréter, qu’une clé est portable mais inutilisable par l’environnement alternatif, ou qu’une autorité existe sur le papier mais n’est pas joignable en dehors des heures de bureau. Ce sont des découvertes résolubles. Elles sont bien plus indulgentes que des surprises.

Le fichier doit également contenir une condition de refus. Quelles preuves feraient que l’organisation refuse le service, retarde le déploiement ou limite les données qu’elle envoie ? C’est là que la souveraineté devient un choix d’approvisionnement plutôt qu’un vœu. Un acheteur n’a pas besoin de rejeter chaque dépendance. Il doit savoir quelle dépendance rendrait le service inacceptable et qui a l’autorité de le dire.

Ce que coûte la souveraineté, et ce que coûte la dépendance

La souveraineté n’est pas gratuite. Les clés contrôlées exigent des personnes et des procédures. Les formats portables peuvent limiter le confort d’une fonctionnalité propriétaire. La capacité redondante coûte de l’argent avant d’être nécessaire. Un fournisseur alternatif peut être moins soigné. Un chemin d’exploitation local peut être plus lent. Une institution publique qui exige des preuves peut recevoir moins d’offres et mettre plus de temps à décider. Ce sont des coûts réels, et les cacher sous un drapeau n’est pas plus honnête que de cacher la dépendance sous une remise.

La comparaison pertinente n’est pas la souveraineté contre un monde sans friction. C’est un coût délibéré contre une dépendance non tarifée. Un service peu coûteux à adopter peut être coûteux à inspecter, coûteux à migrer, ou impossible à suspendre sans conséquences publiques. Un fournisseur techniquement excellent peut quand même créer un risque de concentration si le client ne peut pas changer une interface critique. Un chemin contrôlé localement peut coûter plus cher aujourd’hui et préserver la capacité de choisir demain. Aucun des deux choix n’est automatiquement correct. L’institution doit pouvoir expliquer quel coût elle a accepté.

L’évaluation des risques du cloud de l’ENISA est assez ancienne pour avoir survécu à plusieurs architectures à la mode. C’est en partie ce qui fait son utilité. Son cadre traite l’informatique en nuage comme un modèle économique et technologique avec des avantages et des risques, y compris l’enfermement propriétaire et l’exposition juridique, et recommande d’évaluer ces risques plutôt que de supposer que le nuage est soit une libération, soit un danger. Le même tempérament est nécessaire pour la souveraineté. La question n’est pas de savoir si un arrangement est pur. C’est de savoir si ses dépendances sont connues, bornées et remplaçables assez pour la fonction en jeu.

La redondance est souvent mal comprise comme le fait de posséder deux copies identiques. Parfois, la meilleure alternative est une implémentation différente, un repli manuel ou un service réduit qui préserve la fonction publique la plus importante. Le choix dépend des conséquences d’une interruption. Une charge de travail de recherche peut tolérer un lancement retardé. Un service d’information publique peut avoir besoin d’un chemin de publication statique. Un flux de travail lié à la sécurité peut avoir besoin d’une barrière humaine et d’une procédure testée plutôt que d’un deuxième point de terminaison identique. La souveraineté est la capacité de choisir le repli avant que le système principal ne le choisisse pour vous.

Il y a aussi un coût social. Si seules quelques personnes savent faire fonctionner un système, l’organisation s’est offert une dépendance à leur mémoire. Si la commande publique traite toute rupture avec le fournisseur en place comme irresponsable, elle apprend au marché que la sortie n’est qu’un théâtre. Si les institutions ne financent les alternatives que jusqu’au premier appel d’offres, elles créent une démonstration plutôt qu’une capacité. Payer pour la connaissance d’exploitation, l’interopérabilité et la maintenance est moins enthousiasmant que d’annoncer une plateforme. C’est aussi ce qui permet aux choix de survivre au deuxième cycle budgétaire.

Notre petite note

Chez Dweve, notre rapport public The Sovereignty Illusion défend une thèse voisine à travers cinq portes pratiques : la propriété, la technologie, le capital, l’infrastructure et l’exposition juridique. Ce rapport est notre propre analyse, ni une norme juridique, ni un substitut au cadre de passation de marchés de la Commission ou au Data Act. Sa valeur ici tient simplement à l’habitude qu’il encourage : quand quelqu’un dit qu’un système est souverain, demandez quelle porte porte le contrôle et quelle porte reste ouverte. C’est à cette échelle que nous préférons discuter de notre propre travail, après les preuves et avant le discours de vente.

Le test a lieu avant l’urgence

Le moment le plus révélateur pour la souveraineté est rarement le lancement. Les lancements sont pleins de schémas préparés, d’équipes nommées et de conditions favorables. Le moment révélateur est un changement de cap : un contrat doit prendre fin, un fournisseur doit être contesté, une portée juridique doit être revue, une dépendance doit être remplacée, ou un opérateur doit arrêter une fonction avant que tous les faits ne soient confortables.

C’est pourquoi l’interrupteur d’arrêt est un meilleur point de départ que le drapeau. Il demande de l’autorité plutôt que de l’atmosphère. Il demande ce que l’organisation peut inspecter, et non ce que le fournisseur peut promettre. Il demande si les données et les actifs numériques peuvent être déplacés, si la fonction peut continuer, et si les preuves survivront au déplacement. Il transforme la souveraineté en un ensemble d’actions répétables.

Le cadre 2026 de la Commission européenne montre que la commande publique peut rendre ces actions lisibles. Le Data Act montre que le changement de fournisseur et les informations juridictionnelles peuvent être des obligations plutôt que des faveurs. Les travaux d’ENISA sur les risques nous rappellent que l’enfermement et l’exposition juridique ne sont pas de nouvelles surprises, même quand l’architecture change de nom. Aucune de ces sources ne dit que l’Europe peut fonctionner sans dépendances. Elles offrent quelque chose de plus sérieux : une manière de décider quelles dépendances sont acceptables et ce qui se passe quand elles ne le sont pas.

Une institution européenne n’a pas besoin de posséder chaque puce, d’écrire chaque système d’exploitation ou de construire chaque service pour agir avec souveraineté. Elle doit conserver une capacité crédible à comprendre l’arrangement, à fixer des limites, à modifier les conditions, à arrêter la voie dangereuse et à poursuivre la fonction essentielle. Parfois, cela signifie choisir un fournisseur européen. Parfois, cela signifie une interface ouverte, un détenteur de clés séparé, un second opérateur, une voie manuelle ou un service plus restreint. La réponse appartient au risque et à la responsabilité publique, pas à un slogan.

Avant la prochaine annonce de cloud souverain, posez cinq questions simples. Qui peut arrêter cela ? Qui peut voir ce qui s’est passé ? Qui peut le modifier ? Où peut-il être déplacé ? Qu’est-ce qui peut le remplacer ? Si les réponses sont écrites, testées et détenues, le mot souveraineté fait peut-être un travail utile. Si les réponses s’arrêtent à un logo et une adresse, le système n’a pas encore trouvé son interrupteur d’arrêt.

Sources