Alternative UE-uniquement à Cloudflare.

Cloudflare est le fournisseur le plus exposé aux États-Unis dans la plupart des stacks « UE » car il se situe devant l'utilisateur - chaque visiteur se connecte à un edge server Cloudflare avant d'atteindre votre origine. Les régions UE de Cloudflare sont des edges situés en UE, mais la société mère est une corporation du Delaware avec un matériel de clés et des logs de trafic contrôlés par les États-Unis. Pour les besoins de Schrems II, Cloudflare devant du trafic de données personnelles est l'un des problèmes les plus défendables à éliminer en premier, car les alternatives - Bunny.net (SI) et KeyCDN (CH) - ont des fonctionnalités comparables avec des situations juridiques bien plus simples.

États-Unis Stack de remplacement, UE uniquement 11 services cartographiés

Planifier un appel Scannez d'abord votre domaine

Fournisseur: Cloudflare
Siège: San Francisco, CA
Juridiction: États-Unis
Régime juridique: CLOUD Act, FISA 702, EO 12333

Une "région UE" n'est pas la souveraineté. Quatre questions tranchent.

La résidence des données indique où se trouvent les bits. La souveraineté indique quel système juridique peut en imposer l'accès. La réponse doit tenir sur les quatre points, sinon la stack n'est pas souveraine.

Résidence

Où les données sont-elles physiquement stockées ?

Pas "dans le cloud" : quel centre de données, dans quel pays, sous quelle juridiction.

Sous-traitants

Qui d'autre est dans votre chemin de données ?

Chaque fournisseur qui touche les données : le CDN, le relais e-mail, le tracker d'erreurs, le pipeline analytics.

Juridiction

Quelles lois peuvent contraindre à la divulgation ?

Un fournisseur dont le siège est aux États-Unis relève de la FISA 702 et du CLOUD Act, même si les données se trouvent à Francfort.

Garde des clés

Qui détient réellement les clés de chiffrement ?

Si le fournisseur cloud détient à la fois les données et les clés, il peut les lire, quel que soit le DPA.

Échoue AWS · Azure · GCP · Région UE

Échoue sur la juridiction et la garde des clés.

Bits en UE, maison mère américaine, sous-traitants américains dans le chemin par défaut, clés gérées par le fournisseur.

Réussit Stack géré par Binadit

Réussit sur les quatre.

Hébergé en UE sur une infrastructure au siège européen. Zéro sous-traitant américain dans le chemin par défaut. Clés détenues par le client ou par un KMS européen. Nommés dans votre DPA Article 28.

Pourquoi les équipes partent Cloudflare

Le schéma que nous observons : une revue de confidentialité ou du DPO identifie Cloudflare comme un sous-traitant américain qui traite chaque requête de visiteur, y compris les adresses IP, les empreintes de navigateur (via Bot Management) et les cookies. Sous Schrems II, il s'agit d'un transfert qui nécessite des mesures supplémentaires - généralement un chiffrement que Cloudflare ne peut pas lire, ce qui annule les fonctionnalités WAF et Bot Management qui justifiaient l'utilisation de Cloudflare. La réponse la plus simple est de basculer vers un fournisseur de juridiction UE où l'analyse juridique se réduit à « aucun transfert ». Bunny.net est la cible standard et la migration représente réellement quelques heures de travail DNS et de configuration.

Cloudflare services et leurs équivalents UE-uniquement

Une migration n'est pas "échanger une boîte contre une autre". La cartographie ci-dessous est ce que nous exécutons pour les clients qui quittent Cloudflare au titre de Schrems II : juridiction UE complète, aucune maison mère américaine dans le chemin des données.

Cloudflare service	Ce que nous utilisons à la place	Note d'ingénierie
Cloudflare CDN	Nous mettons en place et exploitons un CDN européen pour vous : Bunny.net ou KeyCDN, avec du caching Nginx et Varnish à votre origine.	Un CDN est l'une des rares couches que nous n'exploitons pas nous-mêmes. Nous choisissons le fournisseur européen, configurons les en-têtes de cache, la stratégie de purge et l'origin shielding, et l'exploitons dans le cadre du service managé.
Cloudflare WAF	Binadit Managed Cloud Platform. Coraza ou ModSecurity avec l'OWASP Core Rule Set, complété par CrowdSec pour le blocage comportemental.	Les règles sont ajustées en fonction de votre trafic plutôt que fournies comme un ensemble par défaut, ce qui empêche un WAF de bloquer silencieusement de vrais clients.
Cloudflare DDoS protection	Binadit Private Infrastructure. Filtrage volumétrique en amont, avec rate limiting et CrowdSec en périphérie applicative.	Les attaques volumétriques sont absorbées en amont de vos serveurs. Les abus de la couche applicative sont traités là où ils peuvent réellement être compris, au plus près de votre trafic.
Cloudflare DNS	Binadit Managed Cloud Platform. PowerDNS ou Knot, en autorité, signés DNSSEC.	Les zones sont exportées et importées sous forme de fichiers de zone standards, ce qui en fait généralement la partie la moins mouvementée d'une migration. Abaissez les TTL une semaine à l'avance.
Cloudflare R2 (storage)	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatible S3.	L'argument zéro-egress de R2 est unique ; chez les fournisseurs EU, l'egress est aussi généralement gratuit ou très faible, donc l'argument coût se transpose.
Cloudflare Workers	Binadit Managed Cloud Platform. Knative ou OpenFaaS sur votre cluster Kubernetes.	La plupart des fonctions que nous migrons s'avèrent être de petits handlers HTTP qui fonctionnent sans problème comme des containers ordinaires, souvent moins chers et sans cold start.
Cloudflare Pages	Binadit Managed Cloud Platform. Nginx servant les assets compilés, déployés depuis GitLab CI.	La principale valeur de Pages est le build pipeline ; cet élément se déplace vers votre fournisseur CI.
Cloudflare Tunnel (Argo)	Binadit Managed Cloud Platform. Tunnels WireGuard, ou un reverse proxy Nginx dans votre propre DMZ.	Netbird a son siège en Allemagne et propose le pattern « sans IP publique » sous juridiction UE. Wireguard en self-managed est la réponse souveraine standard.
Cloudflare Access (zero trust)	Binadit Managed Cloud Platform. WireGuard avec Keycloak ou Authentik devant les services internes.	Pour les applications strictement internes, un reverse proxy protégé par OIDC sur infrastructure européenne est fonctionnellement équivalent.
Cloudflare Stream (video)	Transcodage avec FFmpeg sur l'infrastructure Binadit, diffusé via un CDN EU tel que Bunny.net.	Le transcodage est un workload par lots qui s'exécute sur une capacité que vous possédez déjà. La diffusion se fait en HTTP classique via un CDN que nous configurons pour vous.
Cloudflare Bot Management	Binadit Managed Cloud Platform. CrowdSec pour la détection comportementale, avec rate limiting et pages de challenge en périphérie.	CrowdSec a son siège en France et devient de plus en plus performant. Pour l'e-commerce à fort trafic, DataDome (également français) est l'alternative entreprise.

Cloudflare CDN

Ce que nous utilisons à la place: Nous mettons en place et exploitons un CDN européen pour vous : Bunny.net ou KeyCDN, avec du caching Nginx et Varnish à votre origine.
Note d'ingénierie: Un CDN est l'une des rares couches que nous n'exploitons pas nous-mêmes. Nous choisissons le fournisseur européen, configurons les en-têtes de cache, la stratégie de purge et l'origin shielding, et l'exploitons dans le cadre du service managé.

Cloudflare WAF

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Coraza ou ModSecurity avec l'OWASP Core Rule Set, complété par CrowdSec pour le blocage comportemental.
Note d'ingénierie: Les règles sont ajustées en fonction de votre trafic plutôt que fournies comme un ensemble par défaut, ce qui empêche un WAF de bloquer silencieusement de vrais clients.

Cloudflare DDoS protection

Ce que nous utilisons à la place: Binadit Private Infrastructure. Filtrage volumétrique en amont, avec rate limiting et CrowdSec en périphérie applicative.
Note d'ingénierie: Les attaques volumétriques sont absorbées en amont de vos serveurs. Les abus de la couche applicative sont traités là où ils peuvent réellement être compris, au plus près de votre trafic.

Cloudflare DNS

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. PowerDNS ou Knot, en autorité, signés DNSSEC.
Note d'ingénierie: Les zones sont exportées et importées sous forme de fichiers de zone standards, ce qui en fait généralement la partie la moins mouvementée d'une migration. Abaissez les TTL une semaine à l'avance.

Cloudflare R2 (storage)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatible S3.
Note d'ingénierie: L'argument zéro-egress de R2 est unique ; chez les fournisseurs EU, l'egress est aussi généralement gratuit ou très faible, donc l'argument coût se transpose.

Cloudflare Workers

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Knative ou OpenFaaS sur votre cluster Kubernetes.
Note d'ingénierie: La plupart des fonctions que nous migrons s'avèrent être de petits handlers HTTP qui fonctionnent sans problème comme des containers ordinaires, souvent moins chers et sans cold start.

Cloudflare Pages

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Nginx servant les assets compilés, déployés depuis GitLab CI.
Note d'ingénierie: La principale valeur de Pages est le build pipeline ; cet élément se déplace vers votre fournisseur CI.

Cloudflare Tunnel (Argo)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Tunnels WireGuard, ou un reverse proxy Nginx dans votre propre DMZ.
Note d'ingénierie: Netbird a son siège en Allemagne et propose le pattern « sans IP publique » sous juridiction UE. Wireguard en self-managed est la réponse souveraine standard.

Cloudflare Access (zero trust)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. WireGuard avec Keycloak ou Authentik devant les services internes.
Note d'ingénierie: Pour les applications strictement internes, un reverse proxy protégé par OIDC sur infrastructure européenne est fonctionnellement équivalent.

Cloudflare Stream (video)

Ce que nous utilisons à la place: Transcodage avec FFmpeg sur l'infrastructure Binadit, diffusé via un CDN EU tel que Bunny.net.
Note d'ingénierie: Le transcodage est un workload par lots qui s'exécute sur une capacité que vous possédez déjà. La diffusion se fait en HTTP classique via un CDN que nous configurons pour vous.

Cloudflare Bot Management

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. CrowdSec pour la détection comportementale, avec rate limiting et pages de challenge en périphérie.
Note d'ingénierie: CrowdSec a son siège en France et devient de plus en plus performant. Pour l'e-commerce à fort trafic, DataDome (également français) est l'alternative entreprise.

Comment nous migrons depuis Cloudflare

Une migration typique de mid-market se déroule en trois phases. Les chiffres ci-dessous supposent une équipe d'ingénierie de 6 à 10 personnes et une stack applicative modérément complexe.

Jours 1-3

Inventaire & classement des risques

Lister chaque produit Cloudflare utilisé : CDN, DNS, règles WAF, Workers, Pages, R2, Tunnel, Access. Associer chacun à une exposition de données personnelles (touche-t-il des PII ?) et à une complexité de migration. Résultat : liste de priorités, généralement CDN/DNS en premier.
Jours 4-10

Bascule légère (CDN, DNS, R2)

Provisionner des pull zones Bunny pour les mêmes noms d'hôte. Tester avec un nom d'hôte de staging. Basculer le DNS avec une pré-configuration à faible TTL. Migration R2 → Bunny Storage via écriture parallèle. Règles WAF portées manuellement vers Bunny WAF.
Semaines 2-6

Éléments complexes (Workers, Tunnel, Access)

Le code des workers est revu puis soit porté vers Bunny Edge Scripting, soit réécrit en middleware côté origine, soit auto-hébergé sur Knative. Tunnel est remplacé par Netbird ou Wireguard auto-géré. Access est remplacé par Pomerium ou Authelia. Les workloads Pages sont déplacés vers GitLab Pages ou auto-hébergés.

Les migrations de Cloudflare vers Bunny réduisent presque toujours les dépenses mensuelles de 40 à 70 % aux volumes typiques du mid-market. Les exceptions sont les stacks fortement dépendants de Workers (où l'infrastructure auto-hébergée équivalente a un coût fixe plus élevé) et les stacks Pages à fort trafic (où le tier gratuit agressif de Cloudflare est difficile à égaler).

Questions fréquemment posées

Voir toutes les questions fréquemment posées

Cloudflare propose désormais des plans de données exclusivement UE - est-ce que cela résout le problème ?

La « Data Localization Suite » de Cloudflare peut maintenir le trafic UE sur des edges UE et des clés UE, ce qui répond à la question de la résidence des données. Elle ne répond pas à la question de la juridiction : Cloudflare Inc. reste une corporation américaine soumise au CLOUD Act. Pour la plupart des analyses Schrems II, le produit de localisation des données constitue une amélioration mais pas une souveraineté complète.

Le changement de CDN affectera-t-il les performances pour les visiteurs européens ?

Pour les utilisateurs européens en particulier, Bunny.net offre souvent des performances égales ou supérieures à Cloudflare, car leur densité de POP EU est plus élevée par rapport au trafic. Des tests réels sur des migrations e-commerce ont montré des améliorations du TTFB de 10 à 30 ms pour le trafic spécifique à l'EU. Pour les utilisateurs mondiaux (US, APAC), le nombre de POP de Cloudflare est plus important.

Comment gérer le remplacement de Cloudflare Workers ?

Trois schémas selon le Worker : (1) les réécritures de requêtes triviales migrent vers Bunny Edge Scripting sans modification, (2) les Workers qui communiquent avec KV / Durable Objects nécessitent une refonte - la logique migre généralement vers l'origine et utilise Redis ou Postgres, (3) les Workers agissant comme points de terminaison API deviennent de petits services Knative sur infrastructure UE.

Bunny.net est-il une véritable alternative sûre au sens de Schrems II ?

Bunny.net est BunnyWay d.o.o., dont le siège est à Ljubljana, en Slovénie (membre de l'UE). L'entité juridique est entièrement sous juridiction de l'UE. Leur liste publiée de sous-traitants est courte et centrée sur l'UE. Pour Schrems II, l'analyse se résume à « aucun transfert vers un pays tiers », ce qui est nettement plus simple que le scénario de localisation des données de Cloudflare.

Qu'en est-il de Fastly ou d'Akamai ?

Les deux sont basés aux États-Unis. Fastly est à San Francisco ; Akamai est à Cambridge, MA. Même analyse CLOUD Act que pour Cloudflare. Ils ne sont pas plus faciles que Cloudflare pour Schrems II ; ce sont simplement des providers américains différents avec des ensembles de fonctionnalités différents.

Combien de temps dure une migration Cloudflare ?

Pour une charge de travail typique (CDN, DNS, WAF basique, sans Workers) : 1 à 2 semaines. Pour une configuration fortement basée sur Workers ou dépendante de Tunnel : 4 à 8 semaines. Nous pouvons piloter l'ensemble comme une migration managée si vous souhaitez que ce soit fait sans mobiliser la capacité de votre équipe.

Planifiez votre sortie de Cloudflare.

Appel de cadrage de 30 minutes. Nous cartographions votre stack par rapport aux alternatives UE-uniquement, estimons l'effort de migration et vous disons si c'est le bon choix.

Planifier un appel Comparer un autre fournisseur