Alternative UE-uniquement à Google Cloud Platform.
Google Cloud is the smallest of the three US hyperscalers in EU market share but has the strongest data-engineering brand. That brand is the migration challenge: BigQuery, Vertex AI, Spanner and the rest of the GCP catalog are excellent tools, and there is no like-for-like EU sovereign replacement for some of them. The honest answer is that for most mid-market workloads — web applications, APIs, e-commerce — the EU sovereign stack is a clean fit. For specialised data-engineering or ML workloads, the conversation is more nuanced. We will tell you which category yours falls in.
Une "région UE" n'est pas la souveraineté. Quatre questions tranchent.
La résidence des données indique où sont les bits. La souveraineté indique quel système juridique peut contraindre à l'accès. La réponse doit tenir sur les quatre points — sinon la stack n'est pas souveraine.
Où les données sont-elles physiquement stockées ?
Pas "dans le cloud" — quel datacenter, dans quel pays, sous quelle juridiction.
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.
Quelles lois peuvent contraindre à la divulgation ?
Un fournisseur dont le siège est aux États-Unis relève du FISA 702 et du CLOUD Act — même lorsque les données se trouvent à Francfort.
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 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 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 Google Cloud Platform
GCP exits we have scoped tend to come from one of two angles: a regulated workload that started small on GCP and now needs Schrems II compliance to grow, or a B2B SaaS whose enterprise customers (German banks, French government, Dutch healthcare) explicitly required no US-jurisdictional processor in the contract. The 2024 EU-US Data Privacy Framework legal challenges added a third trigger — leadership-level concern about another transfer-mechanism reversal. T-Systems Open Sovereign Cloud is a Google Cloud licensee operated under DT, which improves the documentation but inherits Google technology.
Google Cloud Platform 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 Google Cloud Platform pour des raisons Schrems II — pleine juridiction UE, pas de maison mère US dans le chemin des données.
| Google Cloud Platform service | Alternative UE-uniquement | Note d'ingénierie |
|---|---|---|
| Compute Engine (GCE) | Hetzner Cloud, OVH Public Cloud, IONOS, Scaleway Instances | Per-vCPU pricing dramatically lower on EU providers; reserved instances unnecessary at typical scale. |
| Cloud Storage | OVH Object Storage, Wasabi EU, Bunny Storage, self-hosted Ceph or MinIO | S3-compatible APIs across all of these; SDK changes are minimal. |
| Cloud SQL | OVH Managed Databases, Aiven (FI), self-managed PostgreSQL/MySQL with replication | Logical replication enables zero-downtime cutover. Aiven has a strong EU presence and Schrems II–conscious tooling. |
| GKE (managed Kubernetes) | Scaleway Kapsule, OVH Managed K8s, IONOS K8s, or self-managed Talos / K3s on Hetzner | GKE Autopilot has no direct equivalent; for most workloads, managed K8s is sufficient. Talos on bare metal is our preferred high-trust setup. |
| Cloud Run | Scaleway Serverless Containers, self-hosted Knative on EU K8s | Knative is the upstream of Cloud Run; the migration is essentially a redeploy onto an EU-hosted Knative cluster. |
| BigQuery | ClickHouse on EU infra, DuckDB for analytical workloads, Snowflake EU (note: US parent) | No 1:1 sovereign equivalent at BigQuery scale. ClickHouse self-hosted is the production pattern; for true Schrems II, this is the workload most clients keep on a documented hybrid. |
| Cloud Pub/Sub | NATS, Apache Kafka, RabbitMQ self-hosted on EU compute | Kafka is the standard pattern for high-volume event streams; NATS is lighter-weight. |
| Cloud Functions | Scaleway Serverless Functions, OpenFaaS or Knative on EU K8s | Functions migration is mechanical; cold-start performance on EU sovereign options is competitive. |
| Cloud DNS | Hetzner DNS, Bunny DNS, deSEC | Standard zone migration via AXFR or zone export. |
| Cloud CDN / Cloud Armor | Bunny.net, KeyCDN, OVH Anti-DDoS | Bunny offers WAF rules and DDoS protection at the edge with EU-only POPs option. |
| IAM / Cloud Identity | Keycloak, Authentik, FreeIPA on EU infra | OIDC/SAML migration is well-trodden; Workspace identity is a separate decision. |
| Cloud Operations (Stackdriver) | Self-hosted Prometheus + Grafana + Loki + Tempo, Grafana Cloud EU | OpenTelemetry instrumentation makes the application-side migration trivial. |
| Vertex AI / model APIs | Mistral AI (FR), Aleph Alpha (DE), self-hosted Llama / Qwen / DeepSeek on EU GPUs | Mistral hosts in FR with EU-jurisdictional endpoints. For training, Hetzner / Scaleway GPU instances are competitive. |
| Firestore / Firebase | PostgreSQL with row-level security, Supabase (US parent — flag), self-hosted Pocketbase or Appwrite | Firestore real-time sync is the hardest piece to replace; for document workloads, PostgreSQL + LISTEN/NOTIFY usually fits. |
Comment nous migrons depuis Google Cloud Platform
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.
Audit & data-engineering scope
Inventory GCP services, classify by sovereignty necessity. Special attention to BigQuery and Vertex usage — these define the migration shape. Output: phased plan plus the explicit decision on data-engineering workloads.
Edge, soft dependencies, IAM staging
Cloud DNS, CDN, monitoring and Cloud Storage moved first. Keycloak deployed alongside Cloud Identity for parallel-run. Pre-stage compute on Hetzner / Scaleway.
Core cutover + analytics decision
GCE/GKE workloads cut over with blue-green. Cloud SQL replicated and switched. BigQuery either migrated to ClickHouse or kept on a documented hybrid with personal data scrubbed at the boundary. Vertex AI workloads moved to Mistral or self-hosted equivalents.
5-year TCO on GCP exits we have run: 30–50% cheaper for predictable workloads. The exception is BigQuery-heavy analytics — there the operational saving of GCP often justifies keeping it on a hybrid (with personal-data anonymisation at the boundary) rather than migrating.
Questions fréquemment posées
Does GCP "Sovereign Controls" or T-Systems Open Sovereign Cloud solve the issue?
Sovereign Controls (formerly Google Cloud Sovereign) adds operational separation: EU-resident staff, encryption key control, audit logging. It does not change the underlying jurisdiction — Google LLC remains the technology owner. T-Systems Open Sovereign Cloud uses GCP technology under licence with DT operations; same caveat at the technology layer. For most Schrems II analyses, both are improvements but not full sovereignty.
Can we keep BigQuery and migrate everything else?
Yes, and this is a common pattern. The discipline: scrub or anonymise personal data at the ingestion boundary so what enters BigQuery is no longer subject to GDPR. Document the boundary in your DPA. We have implemented this pattern for several mid-market analytics workloads.
What is the realistic ML/AI alternative?
Mistral AI (FR) for foundation models with comparable quality to GPT-4-class on European jurisdiction. Aleph Alpha (DE) for sovereign-by-design LLM workloads. For training, Hetzner GPU servers or Scaleway H100 instances cover most use cases. The gap vs Vertex AI is in tooling polish, not raw capability.
How does GKE migration compare to AKS or EKS?
Mechanically similar — Helm charts, manifests and CI/CD pipelines transfer cleanly. GKE-specific addons (Workload Identity, GKE-managed cert-manager) need replacement with standard equivalents. Plan 1–2 weeks for the K8s addon migration.
How long does a GCP exit take?
For a mid-market application (GCE, Cloud SQL, GKE, Cloud Storage, no BigQuery): 10–14 weeks elapsed time. With a managed-infrastructure partner: 6–10 weeks. BigQuery in scope adds 4–8 weeks depending on the migration target.
What about Workspace (Gmail, Docs, Drive)?
Workspace is a separate conversation from GCP infrastructure. Many clients run a hybrid: GCP infrastructure replaced, Workspace kept with documented exposure. The mailbox.org migration path for Workspace is well-supported.
Planifiez votre sortie de Google Cloud Platform.
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.