L'illusion de la souveraineté des données : pourquoi les "zones locales" ne suffisent pas

La géographie d'un mensonge

Dans les salles de conseil vitrées de Francfort, Paris et Amsterdam, une fiction réconfortante s'est installée. C'est la fiction de la "Zone Locale". Elle raconte une histoire simple et rassurante aux DSI comme aux ministres : si vous placez vos données dans un centre de données physiquement situé sur le sol européen (un entrepôt anodin dans la banlieue de Dublin, peut-être, ou un bunker près de Francfort), vous êtes protégé. Vous êtes conforme. Vous êtes souverain.

Cette histoire est racontée par les plus grands "hyperscalers" du monde : Amazon Web Services, Microsoft Azure, Google Cloud. Elle est répétée par les responsables des achats, validée par des consultants coûteux et signée par des équipes de conformité désespérées de cocher une case. C'est le fondement de milliards d'euros de dépenses informatiques à travers l'Union européenne.

C'est aussi, pour le dire crûment, une dangereuse illusion.

En 2025, l'emplacement physique est le facteur le moins important de la souveraineté des données. C'est un vestige d'une époque où les données étaient des documents physiques dans un classeur. À l'ère numérique, le disque physique où reposent vos données peut se trouver dans une baie de serveurs à Dublin, mais si le système de gestion des identités qui en contrôle l'accès fonctionne en Virginie, vous n'êtes pas souverain. Si l'équipe de support qui répare le serveur répond à un responsable à Seattle, vous n'êtes pas souverain. Et si les clés de chiffrement qui verrouillent vos données sont finalement gérables par une entité américaine soumise au CLOUD Act, vous n'êtes certainement pas souverain.

Nous construisons nos infrastructures critiques (nos réseaux énergétiques, nos systèmes de santé, nos registres bancaires, notre logistique de défense) sur des fondations de sable. Nous avons confondu "résidence" et "souveraineté". Et dans un monde d'instabilité géopolitique croissante, cette confusion pourrait nous coûter notre indépendance.

L'anatomie du cloud : le muscle vs le cerveau

Pour comprendre pourquoi le modèle de "Zone Locale" échoue, il faut regarder au-delà des brochures marketing et comprendre l'architecture du cloud public moderne. Nous avons tendance à penser le cloud comme une collection de serveurs (calcul) et de disques durs (stockage). Mais ce ne sont que les muscles. Le "cerveau" du cloud est le plan de contrôle.

Le plan de contrôle est la couche logicielle centralisée qui orchestre tout. Il décide qui peut lancer une machine virtuelle. Il décide qui peut accéder à une base de données. Il gère la facturation. Il pousse les mises à jour logicielles. Il détient les clés maîtresses. Et surtout, pour les principaux hyperscalers américains, ce plan de contrôle est un système global et unifié. Il n'est pas fédéré ; il est centralisé. Et il est presque invariablement contrôlé depuis les États-Unis.

Lorsqu'une banque européenne déploie son système bancaire central dans une région "souveraine" d'un hyperscaler américain, elle loue en fait une chambre dans un immense hôtel. Elle peut verrouiller la porte de sa chambre, certes. Elle peut apporter ses propres meubles. Mais le propriétaire contrôle le système de sécurité du bâtiment, l'électricité, l'eau, les ascenseurs et (surtout) la clé passe-partout qui outrebasse toutes les autres.

Cette centralisation crée deux risques distincts : le risque technique et le risque juridique.

Le risque technique : la dépendance à US-East-1

La vulnérabilité technique de cette architecture n'est pas théorique ; elle a été démontrée maintes et maintes fois. Les ingénieurs cloud expérimentés connaissent la blague : "Quand US-East-1 éternue, Internet s'enrhume." US-East-1 (Virginie du Nord) est la région principale pour de nombreux services AWS, et héberge souvent le plan de contrôle global pour des fonctionnalités spécifiques.

Nous avons vu de multiples cas où des pannes en Virginie ont mis hors service des services en EU-West (Irlande) ou EU-Central (Francfort). Pourquoi ? Parce que la région locale en Europe ne pouvait pas authentifier les utilisateurs, ou ne pouvait pas provisionner de nouvelles ressources, car elle avait perdu le contact avec le "Vaisseau Mère" aux États-Unis. Si une coupure de fibre, un bug logiciel ou une cyberattaque en Virginie peut arrêter votre entreprise à Berlin, votre entreprise n'est pas souveraine. Vous êtes captif.

La véritable souveraineté exige le "test de la coupure Internet". Si vous deviez couper physiquement les câbles à fibre optique reliant l'Europe aux États-Unis, votre infrastructure numérique continuerait-elle de fonctionner ? Pour la plupart des entreprises européennes fonctionnant sur des clouds américains, la réponse est un terrifiant "Non". Elles perdraient la capacité de se connecter (la gestion des identités et des accès appelle souvent la maison), la capacité de passer à l'échelle (plan de contrôle inaccessible), et potentiellement la capacité de déchiffrer les données (service de gestion des clés inaccessible).

Le risque juridique : le bras long de la loi américaine

La dimension juridique est encore plus frappante que la dimension technique, et c'est là que le marketing de la "Zone Locale" s'effondre complètement. Les États-Unis disposent d'un cadre juridique qui rejette explicitement l'idée d'une souveraineté des données basée sur l'emplacement physique.

Le CLOUD Act

Le US CLOUD Act (Clarifying Lawful Overseas Use of Data Act), adopté en 2018, a changé la donne. Il a été conçu pour résoudre un problème spécifique pour les forces de l'ordre américaines : elles voulaient des données détenues par Microsoft en Irlande, et Microsoft refusait de les remettre, arguant qu'elles relevaient de la juridiction irlandaise. Le CLOUD Act a rendu cet argument caduc.

En vertu du CLOUD Act, les forces de l'ordre américaines peuvent contraindre toute entreprise technologique basée aux États-Unis (ou toute entreprise ayant un "lien suffisant" avec les États-Unis) à remettre les données qu'elle contrôle, quel que soit l'endroit où ces données sont stockées. Peu importe si le serveur est à Paris. Peu importe si la filiale détenant les données est une société à responsabilité limitée irlandaise. Si la société mère est américaine, les données sont à la portée des tribunaux américains.

C'est l'extraterritorialité inscrite dans la loi. Elle traite les entreprises technologiques américaines comme des extensions de l'État américain, avec le pouvoir d'intervenir dans des juridictions étrangères et d'extraire des informations sans passer par le processus traditionnel du traité d'entraide judiciaire (MLAT).

FISA 702 et la surveillance "Upstream"

Au-delà de l'application standard de la loi, il y a le domaine de la sécurité nationale. L'article 702 de la loi sur la surveillance du renseignement étranger (FISA) permet aux agences de renseignement américaines (comme la NSA) de contraindre les fournisseurs de services de communication électronique américains à aider à la surveillance de personnes non américaines situées en dehors des États-Unis.

Il ne s'agit pas d'attraper des criminels ; il s'agit de renseignement étranger. "Renseignement étranger" est un terme large qui peut tout englober, du terrorisme aux négociations commerciales, en passant par les stratégies diplomatiques et les capacités industrielles. En vertu de la FISA 702, un fournisseur de cloud américain peut recevoir l'ordre d'intercepter des communications ou des données. Surtout, il lui est souvent interdit de révéler l'existence d'un tel ordre.

La Cour de justice de l'Union européenne (CJUE) en est bien consciente. Dans l'arrêt historique Schrems II en 2020, la CJUE a invalidé l'accord de transfert de données "Privacy Shield" entre l'UE et les États-Unis. Le raisonnement de la cour était explicite : les lois de surveillance américaines (FISA 702, EO 12333) sont disproportionnées et n'offrent pas aux citoyens européens de droits opposables. Par conséquent, les États-Unis n'offrent pas une "protection adéquate" pour les données personnelles comme l'exige le RGPD.

Nous avons donc une situation où les entreprises européennes utilisent des clouds américains pour stocker des données sensibles, en prétendant qu'elles restent en Europe pour satisfaire la conformité interne, alors que la plus haute juridiction d'Europe a statué que le cadre juridique américain rend ces données non sécurisées. C'est une dissonance cognitive aux proportions épiques. C'est une bombe à retardement de conformité qui attend d'exploser.

La porte dérobée "Bris de Glace" (Break Glass)

Les fournisseurs de cloud n'ignorent pas cela. Ils savent que c'est un frein à la vente. Ils ripostent donc avec des offres de "Cloud Souverain". Ils revendiquent une "Souveraineté Opérationnelle". Ils disent : "Seul le personnel de l'UE a accès à vos données." Ils mettent en place des structures juridiques aux noms impressionnants, des administrateurs indépendants et des sociétés écrans.

Mais si vous creusez dans les accords de niveau de service (SLA) et les petits caractères de la documentation technique, vous trouverez presque toujours une disposition "Break Glass". C'est une clause qui permet à l'équipe de support mondiale (américaine) d'accéder à l'infrastructure locale en cas d'"incident critique", d'"urgence technique" ou de "menace de sécurité" que l'équipe locale ne peut pas gérer.

Du point de vue de l'ingénierie de sécurité, un mécanisme "Break Glass" est une porte dérobée. C'est un chemin d'accès privilégié qui contourne les contrôles standard. Et qui décide quand briser la glace ? Le fournisseur. Qui définit ce qui constitue un "incident critique" ? Le fournisseur.

Dans une crise géopolitique (une guerre commerciale, peut-être, ou un litige sur des sanctions), ce mécanisme "Break Glass" devient une vulnérabilité stratégique. Un gouvernement étranger pourrait théoriquement contraindre le fournisseur à "briser la glace", non pas pour réparer un serveur, mais pour exfiltrer des données, appliquer des sanctions ou perturber les opérations.

Même sans malveillance, le modèle de support "Follow the Sun" pose un risque. Lorsqu'un problème complexe de corruption de base de données survient à 3 heures du matin à Francfort, l'équipe de support locale peut ne pas avoir l'expertise approfondie pour le résoudre. Ils l'escaladent vers l'équipe d'ingénierie principale. Où se trouve cette équipe ? Généralement à Seattle ou dans la Silicon Valley. Pour résoudre le problème, l'ingénieur de Seattle a besoin de journaux, de vidages mémoire et peut-être d'un accès au volume de données. Au moment où cet accès est accordé, la souveraineté est rompue.

La véritable souveraineté : la définition de Dweve

Chez Dweve, nous pensons que le terme "souveraineté" a été dilué au point de perdre son sens. Nous devons le reconquérir. Nous avons besoin d'une définition rigoureuse de la souveraineté, basée sur l'ingénierie, et non d'une définition légaliste.

Pour nous, un système n'est souverain que s'il répond à trois critères stricts. Ce ne sont pas des "options souhaitables" ; ce sont des tests binaires réussite/échec.

1. Autonomie technique (L'état déconnecté)

Le système doit être capable de fonctionner pleinement sans aucune connexion à un plan de contrôle central et étranger. Cela signifie que le "cerveau" du système (le planificateur, le fournisseur d'identité, le gestionnaire de clés) doit être local au déploiement.

La plupart des piles de cloud public échouent immédiatement à ce test. Elles nécessitent une connectivité constante au plan de contrôle mondial pour la facturation, l'identité et la gestion. Dweve est conçu différemment. Notre architecture privilégie le "edge" et est décentralisée. Chaque cluster Dweve est un univers autonome. Il possède son propre mécanisme de consensus local, son propre magasin d'identités local et sa propre logique de contrôle locale.

Vous pouvez faire fonctionner un cluster Dweve dans un sous-marin, un bunker sécurisé ou une usine déconnectée d'Internet, et il fonctionnera indéfiniment. Il traitera essentiellement l'absence d'Internet comme une partition réseau et continuera de fonctionner. Vous pouvez provisionner de nouvelles ressources, mettre à jour des modèles et gérer les utilisateurs localement. Lorsque la connectivité est rétablie, il peut se synchroniser (si vous le souhaitez), mais il n'en a jamais besoin.

2. Immunité juridique

L'entité qui exploite l'infrastructure doit être immunisée contre les demandes de données extraterritoriales. Cela signifie qu'elle ne peut pas être une filiale d'une entreprise soumise au CLOUD Act ou à la FISA 702. Elle doit être une entité européenne, soumise uniquement au droit européen.

C'est pourquoi Dweve est domiciliée dans l'UE, sans société mère américaine et sans investisseurs américains détenant des participations de contrôle. Nous ne sommes pas anti-américains ; nous aimons l'innovation américaine. Nous sommes pro-souveraineté. Nous ne pouvons pas être contraints par un tribunal étranger de trahir nos clients car nous ne sommes tout simplement pas soumis à leur juridiction.

3. Contrôle cryptographique (HYOK > BYOK)

Le chiffrement ne vaut que ce que vaut la gestion des clés. La norme industrielle "Bring Your Own Key" (BYOK) est un terme trompeur. Dans un modèle BYOK, vous générez une clé et la téléchargez vers le service de gestion des clés (KMS) du fournisseur de cloud. Le logiciel du fournisseur utilise ensuite cette clé pour chiffrer et déchiffrer vos données.

Cela signifie que le fournisseur possède la clé. Elle peut n'être en mémoire que pendant une milliseconde, mais elle est là. Si le logiciel du fournisseur est compromis, ou s'il est contraint de modifier son logiciel pour capturer la clé, vos données sont exposées. Vous faites confiance au fournisseur pour ne pas regarder.

La véritable souveraineté exige le "Hold Your Own Key" (HYOK). Dans ce modèle, les clés ne quittent jamais votre module de sécurité matériel (HSM) qui reste dans vos locaux. Le fournisseur de cloud ne voit jamais la clé. Les opérations cryptographiques se déroulent à l'intérieur d'un environnement d'exécution de confiance (TEE) ou localement.

La couche de stockage de Dweve est construite sur ce principe. Nous ne détenons pas vos clés. Nous ne voulons pas de vos clés. Si nous recevons une ordonnance du tribunal, nous voulons pouvoir dire honnêtement : "Nous ne pouvons pas vous aider. Les données nous sont mathématiquement inaccessibles."

L'impératif stratégique

Cette discussion est souvent présentée comme une question de conformité : comment éviter les amendes RGPD. Mais c'est une vision à court terme. Il s'agit de survie stratégique au 21e siècle.

Nous entrons dans une ère de "mercantilisme technologique". Les nations utilisent les piles technologiques comme des leviers de pouvoir géopolitique. Les chaînes d'approvisionnement sont utilisées comme des armes. Les semi-conducteurs, les modèles d'IA et l'infrastructure cloud sont les nouveaux pétrole, acier et routes maritimes.

L'Europe a appris une leçon douloureuse sur la dépendance énergétique après l'invasion russe de l'Ukraine. Nous avons réalisé trop tard que construire toute notre économie industrielle sur du gaz bon marché provenant d'un fournisseur unique et potentiellement hostile était une erreur stratégique catastrophique. Nous avons dépensé des milliards et subi un choc économique massif pour nous désengager.

Nous risquons maintenant de répéter exactement la même erreur avec notre infrastructure numérique. Nous construisons notre économie numérique (notre IA, nos lacs de données, nos villes intelligentes) sur l'infrastructure propriétaire d'une seule puissance étrangère. S'appuyer sur un plan de contrôle étranger pour son infrastructure critique est une négligence stratégique.

La "Zone Locale" est une illusion confortable. Elle nous permet de prétendre que nous avons résolu le problème sans faire le travail difficile de construire une véritable indépendance. Mais les illusions, aussi réconfortantes soient-elles, finissent par se briser.

Il est temps de construire une infrastructure réelle. Une infrastructure qui tient debout toute seule. Une infrastructure véritablement, techniquement et juridiquement souveraine. C'est la mission de Dweve.

Dweve construit une infrastructure d'IA véritablement souveraine pour les entreprises européennes. Notre architecture réussit les trois tests de souveraineté : autonomie technique (fonctionnement déconnecté), immunité juridique (juridiction UE uniquement) et contrôle cryptographique (gestion des clés HYOK). Pas de portes dérobées "Break Glass". Pas de plans de contrôle étrangers. Pas d'illusions. Une souveraineté réelle, conçue dès la base.