Alternative UE-uniquement à Microsoft Azure.

Microsoft Azure is the cloud most often defended with the words "but we already use Microsoft for everything." That defence does not survive a Schrems II analysis: Microsoft Corporation is a US company, every Azure subsidiary is US-controlled, and Microsoft has explicitly acknowledged in court (Microsoft Ireland, 2018) that it would comply with valid US legal process for data anywhere globally - which is precisely what the CLOUD Act later codified. The "Microsoft Cloud for Sovereignty" and Bleu (Microsoft × Capgemini × Orange) initiatives are interesting but technology-licensed from a US parent. For genuine EU sovereignty, you exit. Below is the map.

United States Stack de remplacement, UE uniquement 14 services cartographiés

Planifier un appel Scannez d'abord votre domaine

Fournisseur: Microsoft Azure
Siège: Redmond, WA
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 Microsoft Azure

Azure exits typically come from one of three triggers: a public-sector tender that explicitly excludes US-jurisdiction processors, a healthcare or financial services audit that flagged Microsoft 365 + Azure as a single concentration risk under DORA, or a CISO who calculated that the licence true-up costs and "free" Azure credits actually translate to vendor lock-in worth six figures. The Azure ecosystem has tighter coupling than AWS - Active Directory, Office 365, Defender, Sentinel are typically all in the mix - which makes the migration more invasive than its AWS equivalent. It is still doable; we have done it.

Microsoft Azure 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 Microsoft Azure au titre de Schrems II : juridiction UE complète, aucune maison mère américaine dans le chemin des données.

Microsoft Azure service	Ce que nous utilisons à la place	Note d'ingénierie
Azure Virtual Machines	Binadit Managed Cloud Platform. Machines virtuelles KVM sur Debian ou Ubuntu, provisionnées avec Terraform et configurées avec Ansible.	La migration IaaS est simple ; le chapitre sur le licensing Windows demande plus de réflexion (BYOL ou passage vers Linux dans la mesure du possible).
Azure Blob Storage	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatible S3.	Le stockage compatible S3 en Europe est la cible de migration ; les changements de SDK sont minimes.
Azure SQL Database	Binadit Managed Cloud Platform. PostgreSQL ou MySQL avec Patroni pour le failover et pgBackRest pour la restauration point-in-time.	Le portage du schéma depuis Azure SQL (variante T-SQL) est la tâche la plus longue ; des outils comme AWS SCT ou pgloader facilitent le travail. C'est souvent l'occasion de revoir les choix d'ORM.
Azure Front Door / 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é.
Azure 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.
AKS (managed Kubernetes)	Binadit Managed Cloud Platform. Kubernetes sur Debian ou Talos, avec réseau Cilium et cert-manager pour les certificats.	Les Helm charts et le YAML se transfèrent proprement ; les addons spécifiques à Azure (Application Gateway Ingress, Azure CNI) doivent être remplacés par des équivalents standards.
Azure Functions	Binadit Managed Cloud Platform. Knative ou OpenFaaS sur votre cluster Kubernetes.	La plupart des workloads Azure Functions tiennent dans un petit cluster Kubernetes UE exécutant Knative.
Azure Active Directory / Entra ID	Binadit Managed Cloud Platform. Keycloak ou Authentik comme fournisseur d'identité, avec OIDC et SAML.	La migration la plus complexe à elle seule. Prévoyez une fenêtre de fonctionnement en parallèle de 3 mois. Les intégrations SSO entre SaaS doivent être remappées.
Azure Service Bus / Event Grid	Binadit Managed Cloud Platform. RabbitMQ, NATS, ou Redis Streams, selon les garanties de livraison.	Les options de queueing managé dans l'espace souverain UE sont limitées ; le self-managed est le standard.
Azure Monitor / Application Insights	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki et Tempo, connectés avec OpenTelemetry.	L'instrumentation OpenTelemetry rend le remplacement mécanique pour le code applicatif.
Azure Cosmos DB	Binadit Managed Cloud Platform. Replica sets MongoDB, ou PostgreSQL avec JSONB lorsque le modèle documentaire est plus mince qu'il n'y paraît.	Il n'existe pas d'équivalent 1:1 pour l'actif-actif multi-région global ; si votre workload a réellement besoin de ce pattern, la conversation est différente.
Defender / Sentinel (security)	Binadit Managed Cloud Platform. Coraza ou ModSecurity avec l'OWASP Core Rule Set, complété par CrowdSec pour le blocage comportemental.	CrowdSec a son siège en France et devient de plus en plus compétitif dans le domaine SIEM/IDS.
Key Vault	Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, avec rotation automatique des leases.	Vault est la solution souveraine de niveau production ; nous l'exploitons pour nos clients.
Microsoft 365 (email, Teams, OneDrive)	Binadit Managed Cloud Platform. Postfix avec DKIM, SPF et DMARC, et Rspamd pour le filtrage.	Souvent la conversation politique la plus difficile, plus que la migration d'infrastructure elle-même. Fréquemment maintenu sur M365 avec une exposition documentée plutôt que migré.

Azure Virtual Machines

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Machines virtuelles KVM sur Debian ou Ubuntu, provisionnées avec Terraform et configurées avec Ansible.
Note d'ingénierie: La migration IaaS est simple ; le chapitre sur le licensing Windows demande plus de réflexion (BYOL ou passage vers Linux dans la mesure du possible).

Azure Blob Storage

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatible S3.
Note d'ingénierie: Le stockage compatible S3 en Europe est la cible de migration ; les changements de SDK sont minimes.

Azure SQL Database

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. PostgreSQL ou MySQL avec Patroni pour le failover et pgBackRest pour la restauration point-in-time.
Note d'ingénierie: Le portage du schéma depuis Azure SQL (variante T-SQL) est la tâche la plus longue ; des outils comme AWS SCT ou pgloader facilitent le travail. C'est souvent l'occasion de revoir les choix d'ORM.

Azure Front Door / 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é.

Azure 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.

AKS (managed Kubernetes)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Kubernetes sur Debian ou Talos, avec réseau Cilium et cert-manager pour les certificats.
Note d'ingénierie: Les Helm charts et le YAML se transfèrent proprement ; les addons spécifiques à Azure (Application Gateway Ingress, Azure CNI) doivent être remplacés par des équivalents standards.

Azure Functions

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Knative ou OpenFaaS sur votre cluster Kubernetes.
Note d'ingénierie: La plupart des workloads Azure Functions tiennent dans un petit cluster Kubernetes UE exécutant Knative.

Azure Active Directory / Entra ID

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Keycloak ou Authentik comme fournisseur d'identité, avec OIDC et SAML.
Note d'ingénierie: La migration la plus complexe à elle seule. Prévoyez une fenêtre de fonctionnement en parallèle de 3 mois. Les intégrations SSO entre SaaS doivent être remappées.

Azure Service Bus / Event Grid

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. RabbitMQ, NATS, ou Redis Streams, selon les garanties de livraison.
Note d'ingénierie: Les options de queueing managé dans l'espace souverain UE sont limitées ; le self-managed est le standard.

Azure Monitor / Application Insights

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki et Tempo, connectés avec OpenTelemetry.
Note d'ingénierie: L'instrumentation OpenTelemetry rend le remplacement mécanique pour le code applicatif.

Azure Cosmos DB

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Replica sets MongoDB, ou PostgreSQL avec JSONB lorsque le modèle documentaire est plus mince qu'il n'y paraît.
Note d'ingénierie: Il n'existe pas d'équivalent 1:1 pour l'actif-actif multi-région global ; si votre workload a réellement besoin de ce pattern, la conversation est différente.

Defender / Sentinel (security)

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: CrowdSec a son siège en France et devient de plus en plus compétitif dans le domaine SIEM/IDS.

Key Vault

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, avec rotation automatique des leases.
Note d'ingénierie: Vault est la solution souveraine de niveau production ; nous l'exploitons pour nos clients.

Microsoft 365 (email, Teams, OneDrive)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Postfix avec DKIM, SPF et DMARC, et Rspamd pour le filtrage.
Note d'ingénierie: Souvent la conversation politique la plus difficile, plus que la migration d'infrastructure elle-même. Fréquemment maintenu sur M365 avec une exposition documentée plutôt que migré.

Comment nous migrons depuis Microsoft Azure

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.

Weeks 1-3

Audit & ID-mapping

Inventory Azure services, Entra ID dependencies, SSO integrations and licensing. The identity layer is the longest tail. Output: phased plan with the SSO migration scoped separately.
Weeks 3-6

Edge, monitoring, soft dependencies

Replace Front Door, Azure DNS, App Insights and Blob Storage. Pre-stage EU compute and replicate database. Move CI/CD off Azure DevOps if applicable.
Weeks 6-18

Compute, DB, identity cutover

AKS workloads to managed EU K8s. SQL Database to PostgreSQL with logical replication for live cutover. Identity migration with parallel-run; cut SSO over per application.

5-year TCO on Azure exits we have run: typically 25-45% cheaper, with the largest savings coming from licence true-up avoidance and bandwidth/egress. Bear in mind: if your team uses Microsoft 365 and is staying on it, the identity-layer migration only partially decouples - that decision belongs at board level.

Questions fréquemment posées

Voir toutes les questions fréquemment posées

Does Microsoft Cloud for Sovereignty solve the Schrems II problem?

It improves the documentation story but does not change the underlying jurisdiction: Microsoft Corporation remains the parent. For workloads where the analysis turns on parent-jurisdiction (i.e. most regulated workloads after Schrems II), it is not sufficient on its own.

What about Bleu?

Licensed sovereign offerings, where an EU entity operates US technology under licence, are pseudo-sovereign - operated by EU-headquartered entities under licence from a US technology partner. They can satisfy specific regulatory requirements (notably the French SecNumCloud certification for Bleu) but inherit a stack they cannot independently maintain. For most buyers, a clean EU-native stack is the architecturally simpler answer.

Can we leave Azure but keep Microsoft 365?

Yes, and many of our clients run that hybrid. The trade-off is that personal data flowing through M365 (email content, OneDrive files, Teams chat) remains under Microsoft processing. Document it in your DPA, apply supplementary measures (encryption at rest with EU-held keys for sensitive folders), and keep customer-data infrastructure on the sovereign stack.

How does this affect our Microsoft Enterprise Agreement?

Existing EAs typically have annual or multi-year terms; the migration target is to stop the next renewal or right-size it, not to break the current contract. Your account manager will offer concessions when they hear "we are evaluating sovereign alternatives." Use that.

Is Active Directory replaceable in practice?

Replaceable in stages. Keycloak handles OIDC/SAML/SCIM well; for Windows-domain authentication on physical desktops, Samba 4 with FreeIPA is the established open-source path. The transition typically runs alongside a "modern workplace" simplification - fewer per-app SSOs, more standard OIDC.

How long does an Azure exit take?

For a mid-size workload (50-200 VMs, 1-2 SQL DBs, AKS, Entra ID): 16-24 weeks elapsed time. With a managed-infrastructure partner driving the choreography: 10-16 weeks. The identity layer is the schedule risk, not the compute.

Planifiez votre sortie de Microsoft Azure.

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