Vous avez entendu parler de l’EU Data Boundary à droite à gauche, vous savez vaguement que Microsoft a passé des années à le construire comme un argument de souveraineté pour ses clients européens… et puis, en silence, un réglage par défaut a basculé le 17 avril 2026. Bienvenue dans Flex Routing : votre prompt Copilot peut désormais sortir de l’EU Data Boundary pendant les pics de charge, sans que personne ne le sache.

Cet article décortique ce qui change vraiment, pour qui, et comment décider, avec le cas particulier des tenants ADR qui ont payé pour de la souveraineté locale stricte.
Sommaire
- 1. C’est quoi Flex Routing, concrètement ?
- 2. Le calendrier et le défaut piégeux
- 3. Quelles données sortent réellement de l’EU ?
- 4. L’enjeu conformité : GDPR, NIS2, DORA
- 5. Pas-à-pas : désactiver dans le Microsoft 365 Admin Center
- 6. Le piège Power Platform : un deuxième switch
- 7. Le paradoxe ADR : vous avez payé pour la souveraineté locale, et ?
1. C’est quoi Flex Routing, concrètement ?
Pour rappel, jusqu’ici Microsoft s’était engagé à maintenir le traitement des données des clients Copilot EU et EFTA à l’intérieur de l’EU Data Boundary. Stockage at rest, traitement in transit, inférence du modèle : tout devait rester dans les datacenters européens.
Flex Routing change ça. Concrètement, c’est un mécanisme de load balancing géographique : pendant les pics de demande, l’étape d’inferencing (le moment où le modèle traite votre prompt pour produire une réponse) peut être routée vers des datacenters hors EU. Trois destinations sont nommées par Microsoft.
If flex routing is enabled, LLM inferencing may occur in the United States, Canada, or Australia during times of peak demand.
Source : Flex routing (EU and EFTA) — Microsoft Learn
L’idée côté Microsoft est de préserver l’expérience utilisateur quand les GPU européens saturent. Quand le moteur Azure OpenAI en EU est saturé, plutôt que de faire timeout, Copilot va frapper à la porte des datacenters US, canadiens ou australiens. C’est défendable d’un point de vue ingénierie. C’est moins défendable d’un point de vue souveraineté surtout en opt-out.

2. Le calendrier et le défaut piégeux
Le calendrier officiel, tel que documenté par Microsoft :
- Tenants créés après le 25 mars 2026 : Flex Routing activé par défaut, dès la provision du tenant.
- Tenants existants avant le 25 mars 2026 : Microsoft renvoie vers le Message Center pour connaître le réglage par défaut appliqué à votre tenant.
En pratique, le rollout généralisé pour les tenants existants s’est fait le 17 avril 2026, via les messages MC1269219 et MC1269223 dans le Message Center M365. Plusieurs analyses de cabinets de conformité européens convergent sur cette date.
On 17 April 2026, Microsoft enabled flex routing for all Microsoft 365 Copilot tenants in the EU and EFTA. Most organisations did not notice.
Source : LinkedIn
Le piège classique : ce changement est opt-out, pas opt-in. Microsoft a effectué un changement matériel de la localisation de traitement, par défaut, sans demande de consentement explicite côté admin. C’est le cœur du débat conformité que je détaille dans la section 4.
3. Quelles données sortent réellement de l’EU ?
C’est là qu’il faut être précis, parce que les raccourcis du type « vos données partent aux US » sont à la fois vrais et faux. Microsoft fait une distinction nette entre stockage et traitement :
No matter where LLM inferencing occurs, data will be encrypted in transit and at rest. Data at rest will continue to be stored inside the EU Data Boundary, except for limited pseudonymized data which may be stored outside the EU Data Boundary for security and operational purposes.
Source : Microsoft Learn
Décortiquons concrètement ce qui se passe pendant un appel Copilot routé en flex :
- Le prompt et son contexte sont assemblés en EU : votre question, plus le grounding (mails, fichiers SharePoint/OneDrive, métadonnées Graph) que Copilot va injecter pour répondre.
- Le paquet part chiffré vers un datacenter hors EU (US, Canada ou Australie selon la capacité disponible).
- L’inférence a lieu hors EU : le modèle traite le prompt, le contexte et produit la réponse.
- La réponse revient chiffrée en EU : elle est restituée à l’utilisateur, et les données d’origine restent stockées en EU.
- Des données pseudonymisées peuvent rester stockées hors EU, à des fins opérationnelles et sécurité (logs système, télémétrie).
Le mot-clé, c’est pseudonymisation au sens du RGPD Article 4 (5) : la donnée n’est plus directement attribuable à une personne sans information additionnelle, mais elle reste une donnée à caractère personnel. Microsoft applique chiffrement, masquage, tokenisation et data blurring sur ces logs, mais l’autorité de réidentification reste théoriquement possible.
4. L’enjeu conformité : GDPR, NIS2, DORA
Concrètement, ça donne quoi côté conformité ? Trois cadres se cumulent et chacun a sa lecture du sujet.
RGPD : un transfert vers pays tiers, par défaut
Le traitement de données personnelles dans un pays tiers est un transfert au sens des articles 44 et suivants du RGPD. Il faut une base légale :
- États-Unis : décision d’adéquation via l’EU-U.S. Data Privacy Framework (Article 45 RGPD), sous réserve que Microsoft soit listé et que le transfert tombe dans le périmètre du DPF.
- Canada et Australie : Clauses Contractuelles Types (Article 46(2)(c) RGPD), accompagnées d’un Transfer Impact Assessment (TIA).
Et même quand un mécanisme de transfert s’applique, ça ne dispense pas de tracer la chose proprement. Si votre DPIA mentionne un traitement intra-EU et que l’inférence se passe désormais aux US, votre DPIA est périmée. Si votre privacy policy parle d’un traitement européen, elle est inexacte. Si votre registre des traitements (RoPA, Article 30 RGPD) ne reflète pas ce transfert, c’est un manquement.
NIS2 : la chaîne d’approvisionnement IT
Pour les entités essentielles et importantes au sens NIS2, le risque de la chaîne d’approvisionnement IT est explicitement dans le scope. Un changement matériel de la localisation de traitement chez un fournisseur critique, par défaut, sans revue, c’est exactement le genre de scénario que les obligations de due diligence fournisseurs sont censées détecter.
DORA : résilience opérationnelle financière
Pour les entités financières, DORA impose une due diligence active sur les prestataires TIC critiques. Microsoft 365 Copilot relève typiquement de cette catégorie : un changement de localisation de traitement doit être tracé, évalué et documenté dans le registre des prestataires.
5. Pas-à-pas : désactiver dans le Microsoft 365 Admin Center
Si vous décidez de désactiver, voici le chemin exact. Vous aurez besoin du rôle AI Administrator (ou Global Administrator).
- Connectez-vous au Microsoft 365 Admin Center.
- Dans la navigation latérale, ouvrez Copilot, puis Settings.
- Cliquez sur View all pour afficher les options avancées.
- Trouvez l’entrée Flex routing during peak load periods.
- Sélectionnez Do not allow flex routing.
- Validez.

Résultat technique : tout l’inferencing LLM reste forcé dans l’EU Data Boundary, y compris pendant les pics. Le compromis assumé, c’est une dégradation potentielle de performance ou de disponibilité de Copilot pendant les périodes de surcharge régionale. Pour la plupart des usages bureautiques, c’est acceptable. Pour des usages temps réel exigeants, ça mérite un test.
6. Le piège Power Platform : un deuxième switch
Le piège que beaucoup d’admins ratent : ce premier switch ne couvre peut-être pas tous vos besoins. Le réglage du Microsoft 365 Admin Center couvre Microsoft 365 Copilot et Copilot Chat. Pour les Copilot dans Dynamics 365, Power Platform et Copilot Studio, il existe un deuxième réglage dans le Power Platform Admin Center, géré au niveau de l’environnement.
La dépendance est hiérarchique :
- Si Flex Routing est désactivé côté M365 Admin Center, le réglage côté Power Platform est verrouillé sur off.
- Si Flex Routing est activé côté M365 Admin Center, le réglage côté Power Platform est configurable
Pour le désactiver côté Power Platform :
- Connectez-vous au Power Platform Admin Center.
- Dans le panneau de navigation, allez dans Manage > Environments.
- Sélectionnez l’environnement concerné.
- Dans la carte Generative AI features, cliquez sur Edit.
- Décochez Allow flex routing during periods of peak load.
- Validez.

Ce message apparaît si vous souhaitez le modifier ici, alors qu’il a déjà été désactivé sur Microsoft 365 Admin Center :

7. Le paradoxe ADR : vous avez payé pour la souveraineté locale, et ?
Petit rappel produit pour situer : Advanced Data Residency (ADR) est un add-on M365 qui apporte un engagement durable de résidence des données dans une Local Region Geography : France, Allemagne, Norvège, Suisse, Suède, etc. C’est l’add-on que beaucoup d’entreprises européennes ont souscrit pour aller au-delà de la promesse « EU Data Boundary » de base, et garantir que leurs données restent dans leur pays.

Concrètement, ça donne quoi avec Flex Routing ?
La documentation Microsoft sur Flex Routing exclut nommément les tenants Multi-Geo du scope EU Data Boundary (donc le réglage n’apparaît pas dans le M365 Admin Center pour eux) :
Les clients qui ont acheté ou utilisé des fonctionnalités multigéographiques ne sont pas dans l’étendue de la limite de données de l’UE pour Microsoft 365, même si leur locataire est répertorié comme étant dans un pays ou une région de l’UE ou de l’AELE. Le paramètre de routage flexible n’est pas disponible dans le Centre d’administration Microsoft 365 pour les clients qui ont acheté ou utilisé des fonctionnalités multigéographiques. L’achat de fonctionnalités multigéographiques n’a pas d’impact sur la disponibilité du paramètre de routage flexible dans le centre d’administration Power Platform.
Source : Microsoft Learn
En revanche, elle ne mentionne aucune exclusion pour les tenants ADR. La conclusion logique : si vous êtes un tenant ADR localisé dans un pays EU/EFTA, vous êtes dans le scope EU Data Boundary, donc dans le scope Flex Routing. Le réglage est affiché, activable, et soumis au même défaut opt-out que les autres tenants.
Le point dur n’est pas que Microsoft ait fait quelque chose d’illégal : les Clauses Contractuelles Types et le DPF peuvent couvrir techniquement le transfert. Le point dur, c’est que la promesse commerciale de l’ADR (résidence locale stricte) et le comportement par défaut de Flex Routing (inférence hors EU possible) ne sont pas alignés.
Conclusion
Voilà, ce que Flex Routing change pour votre tenant Microsoft 365 Copilot. Le sujet n’est pas dramatique en soi, les mécanismes de transfert juridique existent, le chiffrement tient, le stockage at rest reste en EU. Mais le défaut opt-out, sur un sujet où Microsoft avait construit une promesse forte de souveraineté, méritait largement une décision consciente de chaque admin tenant.
Les pièges principaux à retenir :
- Le défaut opt-out : votre tenant est probablement déjà en flex routing actif. Vérifiez avant de conclure quoi que ce soit.
- Le délai de propagation : jusqu’à une semaine après modification du réglage. Anticipez si une échéance d’audit approche.
- Le deuxième switch Power Platform : désactiver côté M365 ne suffit pas si vous opérez des agents Copilot Studio ou des Copilot Dynamics 365.
- Le paradoxe ADR : les tenants qui ont payé pour la résidence locale stricte sont les premiers à devoir trancher cette question, sous peine d’incohérence entre l’engagement commercial et le comportement par défaut.
Foncez vérifier votre tenant aujourd’hui. C’est cinq minutes dans l’admin center, et c’est précisément le genre de point que vous ne voulez pas découvrir le jour d’un audit CNIL ou d’une revue interne sur la souveraineté des données.


