Le 12 octobre 2026, Cloudflare a ajouté une case à cocher qui change la donne pour des milliers d’entreprises européennes : la possibilité de restreindre géographiquement le stockage et le traitement des messages dans son service de files d’attente managées, Cloudflare Queues. Trois juridictions sont désormais disponibles à la création d’une file : eu, us et fedramp. Une fois choisie, l’option est gravée dans le marbre : impossible de la modifier après coup. Ce détail technique, discret dans le changelog de Cloudflare, arrive à un moment où Bruxelles s’apprête à classer AWS et Microsoft Azure comme “contrôleurs d’accès” au sens du Digital Markets Act, et où le marché du cloud souverain européen s’apprête, selon Gartner, à grimper de 83 % en un an. L’addition de ces trois événements dessine un tournant : la conformité RGPD n’est plus une option qu’on active après coup, elle devient un paramètre qu’on fixe à la seconde où une ressource cloud naît.
Qu’est-ce que Cloudflare Queues et pourquoi la juridiction compte
Cloudflare Queues est le service de messagerie asynchrone de Cloudflare, lancé pour permettre aux développeurs de faire transiter des messages entre des Workers sans gérer eux-mêmes un broker Kafka ou RabbitMQ. Concrètement, une application publie un message dans une file, et un ou plusieurs consommateurs le traitent de façon découplée, avec garantie de livraison. Jusqu’ici, la question de savoir où ce message physique transitait restait floue pour l’utilisateur final : Cloudflare opère un réseau mondial de plusieurs centaines de villes, et par défaut, les données pouvaient être acheminées n’importe où dans cette infrastructure.
La nouveauté du 12 octobre change cette logique par défaut. Avec le paramètre jurisdiction fixé à la création, une file “restreinte” ne stocke et ne traite les messages publiés que dans la zone géographique choisie. Pour une entreprise française qui traite des données de santé, de paie ou des informations bancaires, cela signifie qu’elle peut désormais prouver, par construction technique, que ses messages ne quittent jamais le territoire de l’Union européenne. Ce n’est plus une promesse contractuelle noyée dans les conditions générales, c’est un paramètre d’API vérifiable.
Cloudflare positionne explicitement cette fonctionnalité comme une réponse aux exigences du RGPD et du programme américain FedRAMP. La zone fedramp s’appuie sur des centres de données certifiés FedRAMP-Moderate, pensés pour les agences fédérales américaines et leurs sous-traitants. La zone eu, elle, vise directement les entreprises soumises au droit européen. C’est la même logique de “juridiction par construction” que Cloudflare avait déjà testée sur D1, sa base de données SQL serverless, où les développeurs peuvent épingler une base à une région précise pour des raisons de conformité.
Les détails techniques : CLI, API et tarification
Sur le plan pratique, l’activation de la restriction géographique passe par deux canaux. En ligne de commande, le drapeau --jurisdiction s’ajoute directement à la commande de création :
cf queues create --queue-name ma-file-eu --jurisdiction euCôté API REST, l’endpoint de création de file accepte un paramètre jurisdiction qui prend les valeurs eu, us ou fedramp. Une fois la file créée, ce paramètre devient immuable : il n’existe aucune route pour migrer une file existante d’une juridiction à une autre. Pour un changement de politique de résidence des données, il faut créer une nouvelle file et rejouer la migration applicative, ce qui reste une contrainte non négligeable pour les équipes qui n’auraient pas anticipé leurs besoins de conformité dès le départ.
Côté tarification, Cloudflare Queues reste inclus dans l’offre Workers gratuite, avec un quota de 10 000 opérations par jour et la possibilité de créer jusqu’à 10 000 files avec garantie de livraison. Sur l’offre payante Workers Paid, le forfait inclut 1 million d’opérations par mois, chaque opération supplémentaire coûtant 0,40 dollar par million. Une opération correspond à chaque bloc de 64 Ko écrit, lu ou supprimé, et Cloudflare estime qu’un message type consomme généralement trois opérations : une écriture, une lecture, une suppression. Point notable pour les équipes FinOps : aucun frais de sortie de données (“egress”) ni de facturation à la bande passante ne s’applique, ce qui tranche nettement avec les pratiques tarifaires des hyperscalers américains sur leurs services de messagerie équivalents.
Le contexte réglementaire : le RGPD ne suffit plus, Bruxelles veut aller plus loin
Cette annonce de Cloudflare ne tombe pas du ciel. Elle s’inscrit dans un calendrier réglementaire européen particulièrement chargé à l’automne 2026. Selon des informations rapportées par Bloomberg le 2 octobre 2026, la Commission européenne prépare la désignation d’AWS et de Microsoft Azure comme “contrôleurs d’accès” (gatekeepers) au titre du Digital Markets Act (DMA). Une telle décision, attendue pour novembre 2026 selon The Next Web, étendrait pour la première fois les obligations DMA à l’infrastructure cloud, un secteur jusqu’ici épargné par ce texte pensé pour les plateformes numériques grand public.
La Commission a envoyé ses conclusions préliminaires à Amazon et Microsoft en juin 2026, examinant si AWS et Azure remplissent les critères du DMA malgré le fait qu’ils ne dépassent pas nécessairement les seuils quantitatifs habituels du texte. L’enquête cible trois points précis : le verrouillage des clients (“lock-in”), le manque d’interopérabilité entre services cloud concurrents, et l’auto-préférence dont bénéficieraient les géants américains sur leurs propres offres. Si la désignation est confirmée, Amazon et Microsoft auraient six mois pour mettre AWS et Azure en conformité, sous peine d’amendes pouvant atteindre 10 % du chiffre d’affaires mondial annuel, un niveau de sanction comparable à celui déjà appliqué à d’autres grandes plateformes sous le même règlement.
Dans ce climat de surveillance renforcée, une fonctionnalité comme la juridiction de Cloudflare Queues prend une tout autre dimension. Elle permet à un fournisseur cloud de se positionner en amont de la régulation plutôt que de la subir : plutôt que d’attendre une obligation légale de portabilité ou de localisation, Cloudflare propose déjà le contrôle à la source. C’est une différence stratégique avec AWS et Azure, dont les offres de souveraineté reposent davantage sur des architectures dédiées lourdes que sur un simple paramètre configurable à la volée.
AWS European Sovereign Cloud : la démonstration du 24 octobre
Dix jours après l’annonce de Cloudflare, c’est au tour d’AWS de mettre en scène sa propre réponse à la pression réglementaire européenne. Selon un billet publié sur le blog sécurité d’AWS, l’entreprise a programmé pour le 24 octobre 2026 un exercice de plusieurs heures destiné à prouver que son AWS European Sovereign Cloud peut fonctionner de façon totalement indépendante, sans connexion au backbone mondial AWS Global Network. L’European Sovereign Cloud, disponible en version générale depuis le 15 janvier 2026 avec une première implantation en Allemagne, revendique plus de 90 services couvrant l’IA, le calcul, les conteneurs, les bases de données, le réseau, la sécurité et le stockage, pour un investissement total annoncé à 7,8 milliards d’euros.
L’architecture AWS repose sur une séparation physique et logique complète : personnel résident dans l’UE pour les opérations quotidiennes, systèmes de gestion des identités, de facturation et de mesure d’usage indépendants des régions globales, métadonnées clients hébergées exclusivement en Europe, et points de présence réseau souverains dédiés. C’est un modèle beaucoup plus lourd à construire que celui de Cloudflare : là où Cloudflare ajoute un paramètre à une API existante, AWS a dû dupliquer une partie entière de sa pile opérationnelle pour obtenir une indépendance démontrable. Les deux approches répondent au même problème de fond, la défiance croissante des régulateurs et des clients européens envers le Cloud Act américain, mais avec des philosophies d’ingénierie opposées : l’une mise sur la granularité fine au niveau de la ressource, l’autre sur la séparation totale au niveau de l’infrastructure.
Comparatif : les quatre approches de la souveraineté cloud en 2026
Pour situer la démarche de Cloudflare dans le paysage concurrentiel, il est utile de comparer les stratégies de résidence des données des principaux fournisseurs actifs sur le marché européen à la mi-octobre 2026. Le tableau ci-dessous synthétise les approches publiquement documentées.
| Fournisseur | Mécanisme de résidence | Granularité | Immuable après création | Surcoût de sortie |
|---|---|---|---|---|
| Cloudflare Queues | Paramètre jurisdiction à la création | Par file de messages | Oui | Aucun frais d’egress |
| AWS European Sovereign Cloud | Région physiquement séparée (Allemagne) | Par compte/charge de travail migrée | Non, mais migration lourde | Frais de transfert standards AWS |
| Microsoft Azure EU Data Boundary | Frontière de traitement UE pour les données client | Par tenant Microsoft 365/Azure | Non | Frais de transfert standards Azure |
| Google Cloud (via coentreprise avec Thales) | Entité française pour contrôles souverains | Par offre souveraine dédiée | Dépend de l’offre | Frais de transfert standards GCP |
Ce comparatif met en lumière une tendance claire : plus un acteur cloud a bâti son infrastructure avant la vague de régulation européenne, plus la mise en conformité lui coûte en ingénierie. Cloudflare, en tant qu’acteur plus récent sur certains de ses produits de plate-forme comme Queues, peut intégrer la juridiction nativement dans l’API dès la conception. AWS, Azure et Google Cloud, avec des décennies d’infrastructure existante, doivent construire des couches de séparation par-dessus des systèmes déjà déployés à l’échelle mondiale, ce qui explique en partie les investissements à plusieurs milliards d’euros annoncés par chacun.
Un marché du cloud souverain en pleine accélération
Les chiffres de marché expliquent pourquoi chaque fournisseur cloud se précipite sur ce terrain. Selon les prévisions du cabinet Gartner, les dépenses européennes en cloud souverain devraient atteindre 12,6 milliards de dollars en 2026, soit une hausse de 83 % par rapport à 2025, avant de grimper à 23,1 milliards de dollars en 2027. À l’échelle mondiale, le cabinet Precedence Research évalue le marché plus large de la souveraineté cloud à 139,27 milliards de dollars en 2026, avec une projection à 651,43 milliards de dollars d’ici 2035, soit un taux de croissance annuel composé de 18,70 %. Ces deux séries de chiffres, bien que mesurant des périmètres différents (l’une centrée sur l’Europe, l’autre mondiale), convergent vers le même constat : la conformité à la résidence des données n’est plus une niche réglementaire, c’est devenu une ligne budgétaire à part entière dans les directions informatiques.
Ce dynamisme s’explique aussi par l’empilement des textes européens. L’EU Data Act, pleinement applicable depuis le 12 septembre 2025, impose déjà des obligations de portabilité des données et de facilitation du changement de fournisseur cloud, avec l’interdiction progressive des frais de sortie abusifs. Le RGPD, lui, reste la base juridique historique de toute exigence de résidence des données personnelles. L’arrivée potentielle du DMA sur le secteur cloud viendrait ajouter une troisième couche de contrainte, cette fois centrée sur la concurrence et l’interopérabilité plutôt que sur la seule protection des données. Pour une entreprise française, cela signifie qu’un même projet cloud peut désormais devoir cocher simultanément trois cases réglementaires distinctes.
Pourquoi les files de messages sont un angle mort de la conformité
Un point souvent négligé dans les audits de conformité RGPD concerne précisément les files de messages et les systèmes de mise en cache intermédiaires. Une entreprise peut très bien avoir sécurisé sa base de données principale dans une région européenne, tout en laissant transiter les mêmes données personnelles, au format message, par une file d’attente hébergée n’importe où dans le monde pour des raisons de performance ou de coût. Ce trou dans la raquette est exactement ce que la nouvelle option de juridiction de Cloudflare Queues vient combler : elle traite la couche de messagerie asynchrone avec la même rigueur de résidence que la couche de stockage persistant.
Pour les architectes qui conçoivent des pipelines de traitement d’événements, c’est un changement de posture nécessaire. Un système moderne distribué comporte souvent cinq à dix composants différents entre l’ingestion d’une donnée et son stockage final : webhook, file d’attente, fonction serverless, cache, base de données. Si un seul de ces maillons n’applique pas la même politique de résidence que les autres, l’ensemble de la chaîne de conformité se rompt. En alignant Queues sur ce que Cloudflare proposait déjà pour D1, l’entreprise cherche visiblement à proposer une politique de résidence cohérente sur l’ensemble de sa plateforme Workers, plutôt que des garanties fragmentées produit par produit.
Impact pour les entreprises françaises et européennes
Pour les équipes techniques françaises, cette annonce a des conséquences concrètes à plusieurs niveaux. D’abord, sur le plan contractuel : les délégués à la protection des données (DPO) disposent désormais d’un argument technique vérifiable, et non plus seulement d’une clause contractuelle, pour justifier qu’un flux de données reste sur le territoire européen. Ensuite, sur le plan architectural : les équipes qui utilisent déjà Cloudflare Workers pour leurs applications event-driven doivent revoir la création de leurs files existantes, car le changement de juridiction n’étant pas possible a posteriori, toute file créée avant le 12 octobre 2026 reste dans sa configuration d’origine, par défaut non restreinte géographiquement.
Enfin, sur le plan concurrentiel, cette fonctionnalité renforce l’attractivité de Cloudflare face à des alternatives comme AWS SQS ou Azure Service Bus pour les cas d’usage sensibles à la conformité. Un éditeur de logiciels qui vend à des administrations ou à des établissements de santé en France a désormais un argument supplémentaire pour choisir Cloudflare plutôt qu’un service équivalent chez un hyperscaler américain, sans devoir payer le surcoût d’une offre “souveraine” dédiée comme celles proposées par AWS ou Google Cloud via sa coentreprise avec Thales.
Le poids économique de la non-conformité
Le risque financier associé à une mauvaise gestion de la résidence des données ne se limite pas aux seules amendes RGPD classiques. Avec la perspective d’une désignation DMA pour les grands fournisseurs cloud, le plafond de sanction grimpe à 10 % du chiffre d’affaires mondial annuel, un ordre de grandeur qui dépasse largement les 4 % habituellement prévus par le RGPD pour les violations les plus graves. Pour un hyperscaler dont le chiffre d’affaires se compte en centaines de milliards de dollars, même une fraction de ce pourcentage représente des sommes considérables, largement supérieures au coût d’ingénierie nécessaire pour construire une offre de résidence des données crédible.
C’est précisément ce calcul qui pousse l’ensemble du secteur à investir massivement dans ces architectures. Les 7,8 milliards d’euros annoncés par AWS pour son European Sovereign Cloud, ou les investissements comparables de Microsoft et Google Cloud sur leurs propres offres souveraines, doivent être lus comme une prime d’assurance face à un risque réglementaire devenu systémique plutôt que comme un simple geste commercial envers la clientèle européenne.
Contexte historique : d’un RGPD théorique à une résidence des données opérationnelle
Il faut remonter à l’entrée en vigueur du RGPD en mai 2018 pour comprendre la trajectoire qui mène à l’annonce de Cloudflare. À l’époque, le texte imposait des principes généraux de protection des données sans pour autant dicter d’architecture technique précise : les entreprises pouvaient en théorie respecter le RGPD tout en stockant leurs données sur des serveurs américains, à condition de mettre en place des clauses contractuelles types ou d’autres mécanismes de transfert. L’invalidation du Privacy Shield par la Cour de justice de l’Union européenne en 2020 (l’arrêt Schrems II) a commencé à fragiliser cette approche, en jetant un doute sérieux sur la légalité des transferts de données personnelles vers les États-Unis, notamment en raison de la portée extraterritoriale du Cloud Act américain.
Depuis, chaque année a vu se multiplier les offres de cloud dit “souverain”, mais la plupart reposaient sur des architectures lourdes et coûteuses, réservées aux grands comptes capables de négocier des contrats sur mesure. Ce qui change avec l’option de juridiction de Cloudflare Queues, c’est la démocratisation de ce contrôle : n’importe quel développeur, même sur l’offre gratuite de Workers, peut désormais cocher une case et obtenir une garantie de résidence équivalente à ce qui nécessitait auparavant des négociations contractuelles complexes réservées aux grandes entreprises.
Chronologie des événements clés (septembre-octobre 2026)
Le tableau suivant résume la séquence des annonces qui, mises côte à côte, expliquent pourquoi la résidence des données cloud est redevenue un sujet brûlant à l’automne 2026.
| Date | Événement | Acteur | Portée |
|---|---|---|---|
| 12 septembre 2025 | Pleine applicabilité de l’EU Data Act | Union européenne | Portabilité des données, limitation des frais de sortie |
| 15 janvier 2026 | Disponibilité générale de l’AWS European Sovereign Cloud | Amazon Web Services | 90+ services, implantation initiale en Allemagne |
| Juin 2026 | Envoi des conclusions préliminaires DMA | Commission européenne | AWS et Microsoft visés |
| 2 octobre 2026 | Révélation de la préparation d’une désignation gatekeeper | Commission européenne (via Bloomberg) | AWS et Azure |
| 12 octobre 2026 | Lancement des restrictions de juridiction pour Queues | Cloudflare | Zones EU, US, FedRAMP |
| 24 octobre 2026 | Exercice de déconnexion de l’European Sovereign Cloud | Amazon Web Services | Test d’indépendance du backbone mondial |
| Novembre 2026 (prévu) | Décision de désignation gatekeeper DMA | Commission européenne | AWS, Azure |
Ce que cela signifie pour les équipes DevOps et plateforme
Du point de vue purement opérationnel, l’arrivée de ce paramètre de juridiction change la checklist de mise en production pour toute équipe qui déploie des Workers Cloudflare en Europe. Il devient nécessaire d’ajouter une étape de revue de conformité avant la création de chaque nouvelle file de messages, puisque le choix est définitif. Les équipes qui gèrent leur infrastructure via Terraform ou un autre outil d’infrastructure-as-code devront également mettre à jour leurs modules pour exposer ce paramètre, sous peine de voir des files créées par défaut sans restriction géographique, un oubli qui pourrait se révéler problématique lors d’un audit RGPD.
Autre conséquence pratique : les équipes qui opèrent des architectures multi-régions devront documenter précisément quelles files sont restreintes et lesquelles ne le sont pas, car la coexistence des deux régimes au sein d’un même système d’information va devenir la norme pendant une période de transition. Cette complexité additionnelle, bien réelle, reste malgré tout nettement inférieure à celle qu’imposerait une migration complète vers une offre de cloud souverain dédiée comme celle d’AWS ou de Google Cloud.
Les limites de l’approche Cloudflare
Toute la fonctionnalité n’est pas exempte de limites. D’abord, l’immuabilité de la juridiction après création d’une file impose une discipline de conception en amont : une erreur de configuration au moment du déploiement initial ne peut se corriger que par une migration applicative complète, avec les risques de perte de messages en transit que cela implique si elle n’est pas soigneusement orchestrée. Ensuite, Cloudflare ne communique pour l’instant aucun détail sur une éventuelle certification officielle de cette option auprès d’organismes de certification RGPD indépendants, ni sur un calendrier d’extension de la granularité de juridiction à d’autres produits de sa plateforme au-delà de D1 et Queues.
Il faut aussi noter que l’option ne couvre que le stockage et le traitement du message lui-même au sein de l’infrastructure Cloudflare : elle ne garantit rien sur la localisation du Worker qui produit ou consomme ce message, ni sur d’éventuels sous-traitants tiers appelés par ce Worker. La résidence des données, pour être complète, exige donc une cohérence sur l’ensemble de la chaîne applicative, et pas seulement sur le composant file d’attente.
Prévisions pour les prochains mois
- La décision de désignation gatekeeper DMA de la Commission européenne, attendue en novembre 2026, devrait forcer AWS et Azure à publier des engagements précis sur l’interopérabilité et la portabilité, probablement sous la forme d’un calendrier de six mois à compter de la désignation officielle.
- D’autres produits de la plateforme Cloudflare, en particulier les services de stockage d’objets et de cache, devraient recevoir des options de juridiction similaires à celle de Queues au cours des prochains trimestres, suivant la logique déjà amorcée avec D1.
- Les dépenses en cloud souverain en Europe, déjà projetées à 12,6 milliards de dollars en 2026 selon Gartner, devraient continuer leur ascension vers les 23,1 milliards de dollars annoncés pour 2027, portées par l’anticipation réglementaire plutôt que par des obligations déjà en vigueur.
- Les fournisseurs cloud concurrents de Cloudflare, notamment sur le segment serverless et edge computing, devraient annoncer des fonctionnalités de résidence des données comparables dans les mois suivant cette annonce, pour ne pas perdre de terrain commercial auprès de la clientèle européenne sensible à la conformité.
- L’exercice de déconnexion de l’AWS European Sovereign Cloud prévu le 24 octobre 2026 devrait servir de référence pour d’autres hyperscalers souhaitant démontrer, de façon publique et vérifiable, l’indépendance réelle de leurs offres souveraines européennes.
Questions fréquentes
Qu’est-ce que la restriction de juridiction dans Cloudflare Queues ?
C’est une option activée à la création d’une file de messages qui force le stockage et le traitement des messages publiés à rester dans une zone géographique précise : Union européenne, États-Unis, ou centres de données certifiés FedRAMP-Moderate.
Peut-on changer la juridiction d’une file existante ?
Non. Le paramètre est fixé définitivement à la création de la file. Pour changer de juridiction, il faut créer une nouvelle file et migrer les flux applicatifs vers celle-ci.
Cette fonctionnalité est-elle disponible sur l’offre gratuite de Cloudflare Workers ?
Oui. Cloudflare Queues reste inclus dans le forfait Workers Free, avec un quota de 10 000 opérations par jour et jusqu’à 10 000 files avec garantie de livraison.
Combien coûte l’utilisation de Cloudflare Queues au-delà du forfait gratuit ?
Le forfait Workers Paid inclut 1 million d’opérations par mois, puis 0,40 dollar par million d’opérations supplémentaires. Une opération correspond à chaque tranche de 64 Ko écrite, lue ou supprimée, sans frais de sortie de données.
En quoi cette annonce diffère-t-elle de l’AWS European Sovereign Cloud ?
L’offre d’AWS repose sur une région physiquement et logiquement séparée du reste de son infrastructure mondiale, avec du personnel et des systèmes de gestion dédiés en Europe. La juridiction de Cloudflare Queues, elle, est un paramètre configurable au niveau d’une seule ressource, sans nécessiter de région entièrement distincte.
Le Digital Markets Act va-t-il réellement s’appliquer aux fournisseurs cloud ?
La Commission européenne examine actuellement une désignation d’AWS et de Microsoft Azure comme contrôleurs d’accès, avec une décision attendue en novembre 2026. Rien n’est encore définitif, mais les conclusions préliminaires envoyées en juin 2026 laissent penser qu’une désignation est probable.
Cette option de juridiction garantit-elle à elle seule la conformité RGPD ?
Non. Elle sécurise la couche de messagerie asynchrone, mais la conformité RGPD complète exige une cohérence sur l’ensemble de la chaîne applicative, y compris la localisation des fonctions qui produisent et consomment les messages.
D’autres produits Cloudflare proposent-ils déjà une résidence des données similaire ?
Oui. Cloudflare D1, sa base de données SQL serverless, proposait déjà un mécanisme de juridiction comparable avant l’extension de cette logique à Queues le 12 octobre 2026.