Alternative UE-uniquement à Cloudflare.

Cloudflare is the most US-exposed vendor in most "EU" stacks because it sits in front of the user - every visitor connects to a Cloudflare edge server before reaching your origin. The EU regions of Cloudflare are EU-located edges, but the parent company is a Delaware corporation with US-controlled key material and US-controlled traffic logs. For Schrems II purposes, Cloudflare in front of personal-data traffic is one of the most defensible problems to remove first, because the alternatives - Bunny.net (SI) and KeyCDN (CH) - have comparable feature sets and dramatically simpler legal stories.

United States 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: United States
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

The pattern we see: a privacy or DPO review identifies Cloudflare as a US subprocessor that processes every visitor request including IP addresses, browser fingerprints (via Bot Management) and cookies. Under Schrems II that is a transfer that needs supplementary measures - typically encryption that Cloudflare cannot read, which defeats the WAF and Bot Management features that were the reason for using Cloudflare. The simpler answer is to swap to an EU-jurisdictional provider where the legal analysis collapses to "no transfer." Bunny.net is the standard target and the migration is genuinely a few hours of DNS and configuration work.

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.

Days 1-3

Inventory & risk-rank

List every Cloudflare product in use: CDN, DNS, WAF rules, Workers, Pages, R2, Tunnel, Access. Map each to a personal-data exposure (does it touch PII?) and migration complexity. Output: priority list, usually CDN/DNS first.
Days 4-10

Soft swap (CDN, DNS, R2)

Provision Bunny pull zones for the same hostnames. Test with a staging hostname. Cut DNS over with low TTL pre-stage. R2 → Bunny Storage migration via parallel-write. WAF rules ported manually to Bunny WAF.
Weeks 2-6

Hard pieces (Workers, Tunnel, Access)

Worker code reviewed and either ported to Bunny Edge Scripting, rewritten as origin-side middleware, or self-hosted on Knative. Tunnel replaced with Netbird or self-managed Wireguard. Access replaced with Pomerium or Authelia. Pages workloads moved to GitLab Pages or self-hosted.

Cloudflare-to-Bunny migrations almost always reduce monthly spend by 40-70% at typical mid-market volumes. The exceptions are Workers-heavy stacks (where the equivalent self-hosted infrastructure has higher fixed cost) and high-traffic Pages stacks (where Cloudflare's aggressive free tier is hard to match).

Questions fréquemment posées

Voir toutes les questions fréquemment posées

Cloudflare has EU-only data plans now - does that solve it?

Cloudflare's "Data Localization Suite" can keep EU traffic on EU edges and EU keys, which addresses residency. It does not address jurisdiction: Cloudflare Inc. remains a US corporation subject to the CLOUD Act. For most Schrems II analyses, the data-localization product is an improvement but not full sovereignty.

Will switching CDN affect performance for European visitors?

For European users specifically, Bunny.net often performs equal or better than Cloudflare because their EU POP density is higher per-traffic. Real-world tests on e-commerce migrations have shown TTFB improvements of 10-30ms for EU-specific traffic. For global users (US, APAC), Cloudflare's POP count is larger.

How do we handle Cloudflare Workers replacement?

Three patterns depending on the Worker: (1) trivial request rewrites move to Bunny Edge Scripting unchanged, (2) Workers that talk to KV / Durable Objects need a re-architect - typically the logic moves to the origin and uses Redis or Postgres, (3) Workers acting as API endpoints become small Knative services on EU infrastructure.

Is Bunny.net a real Schrems II-safe alternative?

Bunny.net is BunnyWay d.o.o., headquartered in Ljubljana, Slovenia (EU member). The legal entity is fully under EU jurisdiction. Their published subprocessor list is short and EU-focused. For Schrems II, the analysis collapses to "no third-country transfer" which is materially easier than Cloudflare's data-localization story.

What about Fastly or Akamai?

Both US-headquartered. Fastly is San Francisco; Akamai is Cambridge, MA. Same CLOUD Act analysis as Cloudflare. They are not Schrems II-easier than Cloudflare; they are different US providers with different feature sets.

How long does a Cloudflare migration take?

For a typical workload (CDN, DNS, basic WAF, no Workers): 1-2 weeks elapsed. For a Workers-heavy or Tunnel-dependent setup: 4-8 weeks. We can run the whole thing as a managed migration if you want it done without burning your team's capacity.

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