Sovereign cloud en Europe : la résidence n'est pas la juridiction.

Cette page adopte le point de vue de l'ingénieur. Si votre DPO, votre auditeur ou une étape d'achat vous demande ce que « souverain » signifie réellement en 2026, voici la version qui résiste à l'examen.

Résidence vs souveraineté : la distinction qui change tout

L'industrie du cloud a passé quinze ans à entraîner les acheteurs à poser la mauvaise question. « Où les données sont-elles hébergées ? » est une question de résidence. La réponse peut être techniquement exacte et juridiquement dénuée de sens en même temps, car la souveraineté n'est pas une question de géographie. Elle porte sur les tribunaux qui peuvent contraindre un prestataire à agir.

Une région UE chez un hyperscaler américain, comme AWS Francfort, Azure West Europe ou GCP Belgique, garantit que les données restent dans l'UE. Cela ne soustrait pas la société mère à la juridiction américaine. En vertu du US CLOUD Act (2018), un fournisseur dont le siège est aux États-Unis peut être contraint de divulguer des données clients détenues n'importe où dans le monde, y compris dans les régions UE. FISA 702 impose la même exposition côté surveillance. Le Comité européen de la protection des données a explicitement signalé qu'il s'agit d'un problème Schrems II.

« Souverain » signifie donc trois choses concrètes, toutes à la fois :

1. L'entité juridique détenant vos données n'a pas de maison mère dans un pays tiers soumis à des lois extraterritoriales de divulgation de données.
2. Aucun sous-traitant présent dans le flux de données ne se trouve non plus dans un tel pays.
3. C'est vous, et non le fournisseur, qui contrôlez les clés de chiffrement, ou bien les clés sont détenues par un dépositaire situé hors du pays tiers.

Si vous validez les trois critères, vous avez la souveraineté. Si vous en échouez un seul, vous avez la résidence. La terminologie de votre DPA, de votre politique de confidentialité et de vos pages destinées aux clients doit refléter ce dont il s'agit réellement.

Pourquoi une « filiale UE » n'est pas la réponse

Une solution de contournement courante proposée par les hyperscalers américains est la structure de filiale UE. Microsoft Ireland, AWS EMEA SARL, Google Cloud EMEA Ltd. L'argument est que l'entité européenne est la contrepartie contractuelle sous le droit de l'UE.

Cela ne résout pas le problème juridictionnel. En vertu du CLOUD Act, le critère n'est pas de savoir quelle filiale a signé le contrat. C'est de savoir si la maison mère a la « possession, la garde ou le contrôle » des données. Une filiale UE détenue à 100 % est, par construction, contrôlée par sa maison mère. L'analyse de la CJUE et du CEPD dans l'arrêt Schrems II considère l'exposition de la maison mère comme déterminante.

Ainsi, lorsqu'un fournisseur propose une offre « européenne » exploitée par une filiale UE d'un groupe américain, la bonne question à poser est : « Votre maison mère américaine peut-elle être contrainte de vous ordonner de divulguer des données sans notre consentement ni notre connaissance ? » La réponse honnête est oui.

Le niveau intermédiaire pseudo-souverain

De 2024 à 2026, on a vu une vague de partenariats « souverains » annoncés, généralement un intégrateur système européen licenciant la pile technologique d'un hyperscaler américain et l'exploitant sous gestion européenne. Exemples sur le marché aujourd'hui :

• Offres souveraines sous licence, basées sur la technologie d'un hyperscaler américain, exploitées par une filiale de Europeane Telekom.
• Bleu, un cloud souverain français basé sur la technologie Microsoft Azure, exploité par Capgemini et Orange.
• S3NS, une joint-venture entre Thales et Google en France.

Ces offres peuvent être utiles pour des régimes de conformité spécifiques, mais elles ne sont pas ce qu'une équipe d'ingénierie devrait qualifier de souverain sans réserve. La stack technologique, les mises à jour de la plateforme, les correctifs de sécurité et, surtout, le savoir-faire opérationnel proviennent du partenaire américain. Dans le pire des scénarios, où la partie américaine retire sa coopération ou y est contrainte, l'opérateur européen hérite d'une stack qu'il ne peut pas maintenir de manière autonome.

Pour la plupart des acheteurs, la réponse architecturale la plus claire consiste à construire sur une infrastructure sans aucune dépendance américaine dans la chaîne d'approvisionnement. C'est ce que nous entendons chez Binadit lorsque nous parlons de stack souveraine.

À quoi ressemble réellement une pile souveraine européenne

Voici une architecture de référence concrète pour une application SaaS mid-market ou une charge de travail réglementée fonctionnant entièrement sous juridiction européenne. Aucun de ces éléments n'est exotique ; tous sont de qualité production.

• Compute & storage : compute managé Binadit et matériel dédié, sur infrastructure UE sous juridiction UE.
• Object storage : Ceph ou MinIO, compatible S3, exploité par nous sur la même infrastructure.
• CDN : Bunny.net (SI), KeyCDN (CH), ou auto-géré en périphérie pour un contrôle total.
• DNS : PowerDNS ou Knot, faisant autorité et signé DNSSEC, ou Bunny DNS lorsque vous souhaitez l'associer au CDN.
• Envoi d'e-mails : Mailgun EU (avec précaution, en raison de la maison mère américaine), ou des options entièrement UE comme Postmark EU, Mailpace, Tuta business, ou Postfix auto-hébergé sur la même infrastructure.
• Suivi d'erreurs : GlitchTip ou Sentry auto-hébergé, ou le déploiement en région UE de Sentry avec les compromis documentés.
• Analytics : Plausible (hébergé dans l'UE), Matomo (auto-hébergé ou cloud UE), Pirsch.
• Observabilité : Prometheus + Grafana + Loki auto-hébergés, ou équivalents gérés dans l'UE (Grafana Cloud EU, Last9 avec région UE).
• Gestion des clés : Hashicorp Vault sur infrastructure UE, ou fournisseurs KMS gérés par l'UE ; pour les scénarios à haute confiance, HSM sur site avec BYOK côté cloud.
• CI/CD : GitLab auto-hébergé, Forgejo, Gitea, ou l'instance GitLab.com UE. Jamais le github.com par défaut pour du code touchant des données personnelles sans mesures supplémentaires.

Il ne s'agit pas de dire que l'une de ces solutions est « la » réponse. Il s'agit de montrer que l'ensemble de la stack peut être assemblée avec des prestataires ayant leur siège dans l'UE, et qu'un partenaire d'infrastructure managée peut l'exploiter pour vous, tout comme un partenaire AWS-natif exploiterait AWS.

Le test en quatre questions, en détail

1. Résidence : où, exactement

Pas « dans l'UE », mais dans quel datacenter, dans quel pays, sous quelle juridiction. L'UE n'est pas un régime juridique unique ; le RGPD est harmonisé mais l'autorité de contrôle est locale, tout comme le recours juridique en cas de défaillance d'un fournisseur. Documentez le code pays des emplacements primaire, secondaire et de sauvegarde dans votre DPA.

2. Sous-traitants : chacun d'entre eux

Dans nos audits d'environnements mid-market, la chaîne de sous-traitants non cartographiée est le constat le plus fréquent. L'application est hébergée sur une infrastructure européenne, ce qui est positif. Mais l'API d'optimisation d'images qu'elle appelle est hébergée aux États-Unis. L'email transactionnel est envoyé via un ESP américain. L'outil de suivi des erreurs est le choix par défaut américain. Le widget de support client charge du JavaScript depuis un CDN américain. Chacun constitue un flux de données distinct. Chacun nécessite une base légale si les données transitent vers un pays tiers.

Une stack souveraine exige une liste complète des sous-traitants, incluant les API tierces appelées par votre application et pas uniquement les fournisseurs d'infrastructure. La nôtre est nommée intégralement dans l'accord de traitement des données, et nous vous l'enverrons avant toute signature.

3. Juridiction : qui peut contraindre à la divulgation

La question du processus juridique. Pour chaque entité de votre chaîne de traitement des données, identifiez le siège de la maison mère. Si une maison mère se trouve aux États-Unis, en Chine, en Russie ou dans un autre pays disposant de lois d'accès extraterritorial aux données, cette entité est exposée. Le statut de filiale UE d'une maison mère américaine ne résout pas le problème.

C'est ici que le schéma d'architecture devient un document juridique. Dessinez-le une fois, révisez-le chaque trimestre.

4. Garde des clés : qui peut techniquement lire les données

Le chiffrement au repos est nécessaire mais pas suffisant. La question est de savoir qui détient les clés. Les clés gérées par le fournisseur n'offrent aucune protection si celui-ci est contraint de déchiffrer les données. BYOK (Bring Your Own Key) améliore le discours de conformité ; le fournisseur détient toujours une copie en runtime. HYOK (Hold Your Own Key) est le seul modèle où le fournisseur cloud ne peut physiquement pas lire les données sans un appel actif à votre dépositaire de clés. Choisissez le modèle qu'exige votre analyse de risque.

Le chemin de migration : d'AWS Frankfurt vers une stack souveraine

La crainte de quitter un hyperscaler est généralement plus grande que le projet réel. Une migration type pour le mid-market se déroule en trois phases :

1. Inventaire et audit (1-2 semaines). Cartographiez chaque flux de données, identifiez chaque sous-traitant, classez par exposition aux États-Unis. Résultat : une liste de remédiation classée par risque et complexité de migration.
2. Suppressions rapides (2-4 semaines). Remplacez d'abord les dépendances légères : error tracking, analytics, CDN, DNS, email. Ces changements nécessitent peu ou pas de modification applicative.
3. Migration du cœur (4-8 semaines). Compute, storage, base de données. Utilisez la réplication en streaming pour des déplacements de base de données sans interruption ; utilisez des schémas blue-green ou de basculement DNS au niveau applicatif. La partie difficile est rarement la technologie. C'est la chorégraphie.

Temps total écoulé pour une équipe d'ingénierie de 6 à 8 personnes assurant cette tâche en parallèle de leur activité principale : dix à seize semaines. Avec un partenaire d'infrastructure managée pilotant la migration : quatre à douze semaines. La différence de coût entre l'exploitation de la stack souveraine et celle de l'hyperscaler est, selon notre expérience, neutre à négative pour les charges de travail prévisibles, légèrement supérieure pour les charges de travail irrégulières, et significativement inférieure une fois les coûts de sortie et de bande passante pris en compte.

Le cloud souverain est-il plus cher ? La réponse honnête

Pour 80 % des charges de travail du mid-market, la stack souveraine est moins chère sur cinq ans, principalement parce que les fournisseurs EU ne facturent pas de frais d'egress punitifs et parce que la tarification dédiée et bare-metal est nettement meilleure que celle des types d'instances hyperscaler équivalents. Les cas où la stack souveraine est plus coûteuse sont : les charges de travail très irrégulières qui tirent parti d'un autoscaling en moins d'une seconde, les charges de travail qui dépendent d'un service managé spécifique (DynamoDB, BigQuery, Lambda) sans équivalent propre, et les charges de travail d'entraînement ML nécessitant une génération d'accélérateur spécifique.

Une revue d'ingénierie compétente vous dira en une semaine dans quelle catégorie vous vous trouvez. Si vous en souhaitez une, c'est notre métier.

Vent favorable réglementaire : NIS2, DORA, EHDS et AI Act

L'orientation réglementaire d'ici 2025 à 2027 va vers une responsabilisation plus stricte de la chaîne d'approvisionnement :

• NIS2 (article 21) : les entités essentielles et importantes doivent réaliser des évaluations des risques de la chaîne d'approvisionnement et répercuter contractuellement les obligations de sécurité sur les sous-traitants. Un sous-traitant sous juridiction américaine est difficile à défendre dans cette évaluation sans mesures supplémentaires.
• DORA (en vigueur depuis janvier 2025) : les entités financières doivent tenir un registre des prestataires TIC tiers et une stratégie de sortie pour les prestataires critiques. La notion de risque de concentration vise explicitement la dépendance aux fournisseurs dominants non-UE.
• Espace européen des données de santé (EHDS) : l'utilisation secondaire des données de santé est limitée aux environnements de traitement sous juridiction UE.
• EU AI Act : les systèmes d'IA à haut risque nécessitent une traçabilité de la provenance des données d'entraînement, ce qui est en pratique très difficile avec une API de modèle de fondation américaine.

Aucune de ces réglementations n'interdit les fournisseurs américains. Elles rendent la charge documentaire et les mesures supplémentaires suffisamment lourdes pour que, dans la plupart des cas d'usage, une stack souveraine devienne le choix le moins contraignant.

Ce que nous ne prétendons pas

Par souci d'honnêteté : il existe des charges de travail pour lesquelles une stack souveraine européenne est plus complexe qu'un hyperscaler. Multi-région active-active avec une latence globale inférieure à 50 ms. Entrepôts d'analytique managés spécifiques. Inférence ML à grande échelle sur les derniers accélérateurs. Nous vous indiquerons si votre charge de travail entre dans cette catégorie. Pour 90 % des plateformes SaaS, e-commerce, B2B et des charges de travail réglementées que nous rencontrons, la stack souveraine n'est pas seulement conforme. Elle est aussi plus rapide, moins coûteuse, et plus simple à appréhender.

Où se situe Binadit

Nous sommes un sous-traitant de données au sens de l'article 28, dont le siège est à Rotterdam, aux Pays-Bas. Notre infrastructure repose à 100 % sur des fournisseurs dont le siège est dans l'UE. Notre liste de sous-traitants est nommée intégralement dans l'accord de traitement des données et disponible sur demande. Nous n'acceptons pas de missions qui nécessiteraient un sous-traitant relevant de la juridiction américaine dans le chemin de données par défaut. Lorsqu'une charge de travail en nécessite réellement un (un SaaS tiers sur lequel le client insiste), nous le documentons par écrit, incluons les mesures supplémentaires, et exposons le risque résiduel au DPO avant la signature.

Si cela ressemble au type de partenaire que vous recherchiez, la prochaine étape est un appel de cadrage de 30 minutes.