L’essentiel
Si votre produit ou vos outils internes lisent les boîtes aux lettres, calendriers ou contacts d’Exchange Online via EWS, ils ont désormais une date de péremption ferme : le 1er avril 2027. D’ici là, un administrateur du tenant ne peut les maintenir en vie qu’en inscrivant votre application sur une liste d’autorisation, et à partir du 10 octobre 2026, « EWS activé » sans cette liste ne fonctionne plus.
Ce n’est pas un correctif de sécurité qui s’applique en un après-midi, mais une migration d’API : les appels SOAP d’EWS doivent être réécrits pour Microsoft Graph, avec de nouvelles autorisations, de nouvelles règles de limitation et d’autres structures de données. Les équipes qui gèrent des intégrations de messagerie ou de calendrier doivent la traiter comme un projet de développement d’API à échéance fixe, pas comme un simple changement de configuration.
Qu’est-ce qui a changé le 1er octobre ?
EWS est l’API SOAP apparue avec Exchange Server 2007, devenue le moyen standard pour les outils tiers de dialoguer avec Exchange. Microsoft a cessé de la faire évoluer en 2018 et a annoncé son retrait d’Exchange Online en 2023. Le 1er octobre 2026, l’équipe Exchange a annoncé que la dépréciation « commence aujourd’hui » et détaillé les premières mesures.
Le changement clé : activer EWS n’est plus une autorisation générale. Un administrateur qui règle EWSEnabled sur True doit aussi tenir à jour EWSAllowedAppIDs, la liste des identifiants d’applications autorisées à appeler EWS. Tout ce qui n’y figure pas est refusé. Selon Microsoft, les modifications de la liste prennent 24 heures, et celles d’EWSEnabled généralement moins d’une heure, mais jusqu’à quatre.
Quel est le calendrier du retrait d’EWS ?
Microsoft déploie le changement par étapes, en commençant par son cloud mondial multi-tenant ; les tenants des autres clouds reçoivent leur propre calendrier via le Centre de messages.
- 2 octobre 2026 : Microsoft recense les tenants avec EWSEnabled = True mais sans liste d’autorisation.
- 8–9 octobre : pour ces tenants, Microsoft crée EWSAllowedAppIDs et la remplit avec les AppID ayant appelé EWS au cours des 60 derniers jours.
- À partir du 10 octobre : la liste d’autorisation est obligatoire dès qu’EWS est activé.
- Deuxième phase : les tenants qui n’ont jamais touché au paramètre EWSEnabled sont sélectionnés par vagues, prévenus 7 jours à l’avance dans le Centre de messages, puis passés à EWSEnabled = False. Microsoft pré-remplit d’abord leur liste à partir de 60 jours d’utilisation, afin qu’un administrateur puisse réactiver EWS si nécessaire.
- 1er avril 2027 : EWS est arrêté définitivement. Comme le rapporte The Register, il n’y aura aucune exception : ni EWSEnabled ni la liste d’autorisation ne rétabliront l’accès.
Quelles applications et quelles équipes sont concernées ?
Tout ce qui appelle EWS sur Exchange Online : synchronisation de la messagerie dans les CRM et outils de support, outils de calendrier et de réservation de salles, solutions d’archivage et de sauvegarde, connecteurs d’e-discovery et de conformité, outils de migration, sans oublier les nombreux scripts internes écrits il y a des années puis oubliés. Certains logiciels Microsoft sont aussi concernés : selon l’équipe Exchange, Outlook pour Windows doit être au moins en build 16.0.20430.20092 (août 2026), Outlook classique pour Mac a besoin de l’AppID « Microsoft Office » dans la liste, Excel Power Query fait l’objet de recommandations dédiées, et une mise à jour de Power BI est encore attendue.
Le plus difficile, comme l’a confié un éditeur d’intégrations à The Register, est que beaucoup d’organisations n’ont pas d’inventaire complet de ce qui appelle EWS. Les données d’utilisation sur 60 jours, que Microsoft utilise pour pré-remplir les listes, sont un bon point de départ, mais les traitements trimestriels ou annuels risquent de ne pas y apparaître.
Ce que cela change pour les équipes logicielles aux États-Unis et en Europe
D’abord, les éditeurs SaaS portent le risque pour leurs clients. Si votre produit se connecte aux tenants Microsoft 365 de vos clients via EWS, chaque administrateur client doit désormais autoriser votre AppID, et chez chacun de ceux qui ne le feront pas, votre intégration tombera. C’est une charge de support aujourd’hui et un risque d’attrition en avril 2027.
Ensuite, Graph n’est pas un remplacement à l’identique. Graph repose sur REST et sur d’autres périmètres d’autorisation : les clients doivent donc donner un nouveau consentement administrateur. La limitation, la pagination et les notifications de changement fonctionnent autrement qu’avec EWS, et certaines opérations EWS n’ont pas d’équivalent exact dans Graph. Chaque appel doit être cartographié, et chaque lacune appelle un choix de conception.
Enfin, les autorisations sont une question de conformité. Passer à Graph est l’occasion de remplacer un accès large aux boîtes aux lettres par des périmètres plus étroits et des stratégies d’accès applicatif. Pour les équipes FinTech ou HealthTech soumises au RGPD, à HIPAA ou à des audits SOC 2, un accès au moindre privilège aux données de messagerie se défend bien mieux que l’ancienne usurpation d’identité avec accès complet.
Qu’est-ce que cela signifie pour les entreprises en France ?
En France, une bonne part des intégrations Exchange a été mise en place par des ESN et des intégrateurs – connecteurs de GED, de CRM, d’archivage ou de téléphonie –, souvent dans le cadre de projets terminés depuis longtemps. Pour une DSI, la première étape consiste donc à interroger ses prestataires et éditeurs : quelle solution appelle encore EWS, et quelle est leur feuille de route vers Graph ? Côté conformité, la bascule n’est pas neutre : de nouveaux droits d’accès aux boîtes aux lettres touchent des données personnelles au sens du RGPD, ce qui justifie de mettre à jour le registre des traitements et, si un sous-traitant accède aux données, les clauses contractuelles qui l’encadrent ; le DPO doit être associé tôt. Si les messageries contiennent des données personnelles sensibles et que la migration modifie sensiblement les traitements, l’opportunité d’une analyse d’impact (AIPD) doit être évaluée au regard des lignes directrices de la CNIL. Planifier ces étapes dès maintenant évite de découvrir un blocage juridique à quelques semaines du 1er avril 2027.
Que faire maintenant
- Recenser chaque appelant EWS. Récupérez le rapport d’utilisation d’EWS dans le Centre d’administration Microsoft 365 et croisez-le avec une recherche dans votre code des bibliothèques et points de terminaison EWS, y compris les traitements rarement exécutés.
- Vérifier la liste d’autorisation. Assurez-vous que chaque application encore nécessaire figure dans EWSAllowedAppIDs avant le 10 octobre ; les modifications prennent jusqu’à 24 heures.
- Surveiller le Centre de messages. Si votre tenant n’a jamais défini EWSEnabled, l’avertissement de 7 jours sera le seul préavis avant la désactivation d’EWS.
- Cartographier les opérations EWS vers Graph. Listez chaque appel, son équivalent Graph et chaque lacune ; décidez tôt comment traiter ces lacunes.
- Préparer consentements et autorisations. Préparez de nouvelles inscriptions d’applications dans Entra ID et des périmètres Graph restreints, et indiquez aux clients ce qu’ils devront approuver.
- Fixer une échéance interne. Visez la fin de la migration et des tests bien avant le 1er avril 2027, en gardant du temps pour le déploiement chez les clients.
Questions fréquentes
Quand Exchange Web Services cessera-t-il de fonctionner dans Exchange Online ?
Microsoft a lancé le retrait progressif le 1er octobre 2026. À partir du 10 octobre 2026, les tenants qui gardent EWS actif doivent inscrire les applications autorisées dans EWSAllowedAppIDs. Le 1er avril 2027, EWS sera définitivement désactivé dans Exchange Online pour tous les tenants, et aucun paramètre ne permettra de le rétablir.
Le retrait d’EWS concerne-t-il Exchange Server sur site ?
Non. Le retrait s’applique à Exchange Online. EWS dans Exchange Server sur site n’est pas supprimé par ce changement, mais les fonctions hybrides qui reposent sur EWS dans Exchange Online sont touchées, et Microsoft a publié des recommandations spécifiques à leur sujet.
Qu’est-ce qu’EWSAllowedAppIDs ?
Une liste d’autorisation, au niveau du tenant, des identifiants d’applications qui peuvent continuer d’appeler EWS pendant la période de retrait. À partir du 10 octobre 2026, régler EWSEnabled sur True ne suffit plus : les applications absentes de la liste sont bloquées. Les modifications de la liste prennent jusqu’à 24 heures.
Qu’est-ce qui remplace EWS ?
Microsoft Graph est l’API de remplacement pour la messagerie, le calendrier et les contacts dans Exchange Online. La plupart des opérations EWS ont un équivalent Graph, mais certaines lacunes subsistent : chaque intégration doit donc être cartographiée appel par appel avant la migration.
Peut-on simplement ajouter son application à la liste et attendre ?
Seulement jusqu’au 1er avril 2027. La liste d’autorisation donne du temps pour migrer, elle ne prolonge pas EWS au-delà de la date finale. Les équipes qui s’appuient dessus doivent planifier dès maintenant le passage à Microsoft Graph et terminer les tests bien avant l’échéance.
Sources
Microsoft Exchange Team — EWS Deprecation Is Here: What This Means To You (October 1, 2026)
Microsoft Exchange Team — Introducing EWSAllowedAppIDs: Preparing for the final phase of EWS retirement
The Register — Exchange Web Services enters the final stretch before Microsoft pulls access
TechRadar — Microsoft starts the countdown for the end of Exchange Web Services