Microsoft Flex routing

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 ?

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
Attention : selon Microsoft et les retours de terrain, une modification du réglage Flex Routing peut prendre jusqu’à une semaine pour se propager. Si vous décidez de désactiver, ne considérez pas que c’est immédiat : vérifiez ensuite que le réglage est bien appliqué côté tenant.

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 :

  1. 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.
  2. Le paquet part chiffré vers un datacenter hors EU (US, Canada ou Australie selon la capacité disponible).
  3. L’inférence a lieu hors EU : le modèle traite le prompt, le contexte et produit la réponse.
  4. 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.
  5. 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.

Mon retour terrain : beaucoup de DPO et RSSI européens lisent « data at rest stays in the EU » et concluent que tout va bien. Le point dur, c’est le moment de l’inférence — c’est que votre prompt, et donc potentiellement vos documents et mails, sont exposés au modèle dans un datacenter hors EU. C’est ce point-là qui doit être tracé dans vos analyses de transferts.

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.

Attention : aucun de ces points ne nécessite une violation de données pour devenir un problème réglementaire. Un audit, une inspection CNIL ou une simple plainte suffisent. Le Message Center Microsoft n’est plus seulement un canal IT : c’est devenu un canal conformité que quelqu’un dans l’organisation doit suivre.

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

  1. Connectez-vous au Microsoft 365 Admin Center.
  2. Dans la navigation latérale, ouvrez Copilot, puis Settings.
  3. Cliquez sur View all pour afficher les options avancées.
  4. Trouvez l’entrée Flex routing during peak load periods.
  5. Sélectionnez Do not allow flex routing.
  6. 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 :

  1. Connectez-vous au Power Platform Admin Center.
  2. Dans le panneau de navigation, allez dans Manage > Environments.
  3. Sélectionnez l’environnement concerné.
  4. Dans la carte Generative AI features, cliquez sur Edit.
  5. Décochez Allow flex routing during periods of peak load.
  6. 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 :

Mon retour terrain : sur un tenant avec à la fois Microsoft 365 Copilot et des agents Copilot Studio, j’ai vu des équipes désactiver consciencieusement le réglage M365… en oubliant que les agents Copilot Studio en environnement Power Platform restaient sur le défaut hérité. Si vous opérez des deux côtés, vérifiez les deux switches, environnement par environnement.

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.

Mon retour terrain : c’est là le vrai paradoxe. Les clients qui ont payé l’ADR sont précisément ceux qui ont posé un engagement de souveraineté plus strict que la moyenne. Que leur inférence Copilot puisse partir vers les US ou le Canada par défaut, sans revue documentée, c’est précisément ce qu’ils voulaient éviter en signant l’ADR. Ces tenants-là doivent vérifier le réglage en priorité, et tracer la décision dans leur RoPA et leur DPIA.

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 :

  1. Le défaut opt-out : votre tenant est probablement déjà en flex routing actif. Vérifiez avant de conclure quoi que ce soit.
  2. Le délai de propagation : jusqu’à une semaine après modification du réglage. Anticipez si une échéance d’audit approche.
  3. 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.
  4. 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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *