Alternative UE-uniquement à Microsoft Azure.

Microsoft Azure est le cloud le plus souvent défendu avec les mots « mais nous utilisons déjà Microsoft pour tout ». Cette défense ne résiste pas à une analyse Schrems II : Microsoft Corporation est une entreprise américaine, chaque filiale Azure est contrôlée par les États-Unis, et Microsoft a explicitement reconnu devant les tribunaux (Microsoft Ireland, 2018) qu'elle se conformerait à toute procédure légale américaine valide pour des données situées n'importe où dans le monde - ce que le CLOUD Act a ensuite précisément codifié. Les initiatives « Microsoft Cloud for Sovereignty » et Bleu (Microsoft × Capgemini × Orange) sont intéressantes mais reposent sur une technologie sous licence d'une maison mère américaine. Pour une véritable souveraineté européenne, il faut en sortir. Voici la feuille de route.

États-Unis 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: É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 Microsoft Azure

Les sorties d'Azure proviennent généralement de l'un de ces trois déclencheurs : un appel d'offres du secteur public excluant explicitement les processeurs sous juridiction américaine, un audit dans la santé ou la finance ayant signalé Microsoft 365 + Azure comme un risque de concentration unique au titre de DORA, ou un CISO ayant calculé que les coûts de true-up des licences et les crédits Azure « gratuits » se traduisent en réalité par un vendor lock-in à six chiffres. L'écosystème Azure présente un couplage plus fort qu'AWS - Active Directory, Office 365, Defender, Sentinel sont généralement tous impliqués - ce qui rend la migration plus invasive que son équivalent AWS. C'est néanmoins faisable ; nous l'avons déjà fait.

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.

Semaines 1-3

Audit et mapping d'identifiants

Inventoriez les services Azure, les dépendances Entra ID, les intégrations SSO et les licences. La couche identité est la traîne la plus longue. Résultat : un plan par phases avec la migration SSO scopée séparément.
Semaines 3-6

Edge, monitoring, dépendances secondaires

Remplacer Front Door, Azure DNS, App Insights et Blob Storage. Pré-configurer le calcul dans l'UE et répliquer la base de données. Migrer le CI/CD hors d'Azure DevOps si applicable.
Semaines 6-18

Bascule Compute, DB, identité

Workloads AKS vers K8s européen managé. SQL Database vers PostgreSQL avec réplication logique pour une bascule en direct. Migration d'identité en run parallèle ; basculement du SSO application par application.

TCO sur 5 ans des sorties Azure que nous avons réalisées : généralement 25-45% moins cher, les économies les plus importantes provenant de l'évitement du true-up de licences et de la bande passante/egress. À noter : si votre équipe utilise Microsoft 365 et compte le conserver, la migration de la couche d'identité ne se découple que partiellement - cette décision relève du niveau du conseil d'administration.

Questions fréquemment posées

Voir toutes les questions fréquemment posées

Microsoft Cloud for Sovereignty résout-il le problème Schrems II ?

Cela améliore la documentation mais ne change pas la juridiction sous-jacente : Microsoft Corporation reste la société mère. Pour les charges de travail où l'analyse dépend de la juridiction de la société mère (c'est-à-dire la plupart des charges de travail réglementées après Schrems II), cela ne suffit pas en soi.

Qu'en est-il de Bleu ?

Les offres souveraines sous licence, où une entité de l'UE exploite une technologie américaine sous licence, sont pseudo-souveraines - exploitées par des entités basées dans l'UE sous licence d'un partenaire technologique américain. Elles peuvent satisfaire des exigences réglementaires spécifiques (notamment la certification française SecNumCloud pour Bleu) mais héritent d'une pile technologique qu'elles ne peuvent pas maintenir de façon indépendante. Pour la plupart des acheteurs, une pile UE native reste la réponse architecturalement la plus simple.

Pouvons-nous quitter Azure tout en conservant Microsoft 365 ?

Oui, et beaucoup de nos clients adoptent cette approche hybride. Le compromis est que les données personnelles circulant via M365 (contenu des e-mails, fichiers OneDrive, chats Teams) restent sous traitement Microsoft. Documentez-le dans votre DPA, appliquez des mesures supplémentaires (chiffrement au repos avec des clés détenues dans l'UE pour les dossiers sensibles), et conservez l'infrastructure des données clients sur la pile souveraine.

Comment cela affecte-t-il notre Microsoft Enterprise Agreement ?

Les EA existants ont généralement des durées annuelles ou pluriannuelles ; l'objectif de la migration est d'arrêter le prochain renouvellement ou de le redimensionner, pas de rompre le contrat en cours. Votre account manager fera des concessions dès qu'il entendra "nous évaluons des alternatives souveraines". Utilisez cet argument.

Active Directory est-il remplaçable en pratique ?

Remplaçable par étapes. Keycloak gère bien OIDC/SAML/SCIM ; pour l'authentification de domaine Windows sur postes physiques, Samba 4 avec FreeIPA constitue la voie open-source établie. La transition s'accompagne généralement d'une simplification « poste de travail moderne » - moins de SSO par application, davantage de OIDC standard.

Combien de temps dure une sortie d'Azure ?

Pour une charge de travail de taille moyenne (50 à 200 VMs, 1 à 2 bases SQL, AKS, Entra ID) : 16 à 24 semaines de délai. Avec un partenaire d'infrastructure managée orchestrant le projet : 10 à 16 semaines. La couche identité constitue le risque planning, pas le 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