Pendant près de vingt ans, Exchange Web Services (EWS) a constitué l’une des principales interfaces permettant aux applications d’interagir avec Exchange : consulter une boîte aux lettres, créer un rendez-vous, déplacer des messages, accéder aux dossiers ou encore intégrer Exchange avec des applications métiers. C’était effectivement les fonctions les plus utilisée mais… c’est bientôt terminé
Voici le calendrier des opérations
- Octobre 2026 : Microsoft commence la désactivation progressive d’EWS dans Exchange Online, tenant par tenant. La documentation Microsoft confirme qu’EWS devait être désactivé dans EXO à partir d’octobre 2026.
- 1er avril 2027 : c’est la date annoncée pour la désactivation complète et définitive d’EWS dans Exchange Online. Les sources récentes décrivent cette échéance comme le final shutdown
Si cette évolution concerne Exchange Online, notez que cela ne signifie pas la disparition d’EWS dans Exchange Server on-premises. Microsoft précise par ailleurs que Microsoft Graph n’est pas pris en charge pour accéder directement à Exchange Server on-premises. Ceci isole encore un peu plus par ailleurs la solution on Premise Exchange server (voir Continuer avec Exchange Server : quelles conséquences ? https://www.itpro.fr/continuer-avec-exchange-server-quelles-consequences)
Et cette différence protocolaire est loin d’être anodine pour les organisations disposant encore d’architectures hybrides.
EWS, une dépendance souvent beaucoup plus importante qu’on ne le pense
Le premier enjeu est probablement le moins visible : savoir qui utilise encore EWS. C’est en tout cas le plus important pour mesurer les « dégâts »
Dans les grandes organisations, EWS peut effectivement se cacher derrière de nombreuses applications :
- applications métiers interrogeant des boîtes fonctionnelles ;
- solutions d’archivage ou de migration ;
- outils de sauvegarde ;
- CRM ou applications de relation client ;
- applications traitant automatiquement certains messages ;
- logiciels de gestion d’agenda ;
- scripts PowerShell ou développements internes historiques ;
- logiciels utilisant des comptes de service ;
- applications utilisant des dossiers publics ;
- intégrations développées il y a parfois dix ou quinze ans.
Une application peut parfaitement fonctionner depuis des années sans que l’équipe Exchange qui l’exploite aujourd’hui sache qu’elle repose sur EWS. La problématique n’est donc pas seulement : « Comment remplacer EWS ? », Elle commence déjà par : « Où utilisons-nous encore EWS ? »
Microsoft met en avant ses EWS Usage Reports et EWS Analyzer pour faciliter l’identification et l’analyse de ces usages comme le monter la figure suvante :
Microsoft Graph : La cible privilégiée
Pour la majorité des applications Exchange Online, la trajectoire recommandée par Microsoft consiste à migrer vers Microsoft Graph. Ce changement dépasse largement le remplacement d’une URL d’API.
EWS repose historiquement sur des Web Services SOAP alors que Microsoft Graph expose des API REST. Microsoft met également en avant une meilleure granularité des autorisations ainsi qu’un modèle de sécurité et de gouvernance plus strict avec Graph.
Pour l’entreprise, cela peut nécessiter de revoir le code, l’authentification, les autorisations accordées aux applications, les bibliothèques utilisées et parfois l’architecture même de l’intégration. De quoi occuper selon l’empreinte EWS pas mal de personnes !
Mais attention Graph n’est pas un clone moderne d’EWS et c’est probablement le point le plus important. Même s’il est tentant de considérer Microsoft Graph comme « EWS en REST », ce n’est pas le cas.
Microsoft travaille toujours sur certains écarts fonctionnels entre EWS et Graph et avertit que lorsqu’une capacité EWS ne figure pas dans sa feuille de route, il ne faut pas partir du principe qu’un équivalent Graph sera disponible avant la désactivation complète d’EWS. Un petit casse-tête pour les développeurs. Ce qu’il faut donc retenir c’est que tous les appels EWS ne seront pas forcément remplacer par des appels Graph API
Les éditeurs tiers constituent une dépendance majeure
Pour un développement interne, l’entreprise maîtrise normalement son calendrier de transformation, mais avec un produit tiers, elle dépend en revanche de la feuille de route de l’éditeur. Un produit de sauvegarde, de migration, de workflow ou d’archivage utilisant EWS devra donc disposer d’une nouvelle méthode d’accès à Exchange Online.
Ce sujet apparaît déjà très concrètement dans l’écosystème. Par exemple, un message récent de BitTitan MigrationWiz annonce la disponibilité d’un projet de migration de boîtes aux lettres basé sur Graph tout en maintenant temporairement des scénarios EWS lorsque certaines capacités nécessaires ne sont pas encore disponibles via Graph.
De ce fait on devrait avoir trois types d’application
- Compatible Graph : L’éditeur dispose déjà d’une version compatible.
- Migration annoncée : Une nouvelle version est prévue mais doit encore être validée.
- Aucune solution cible identifiée : Le produit constitue alors un véritable risque métier.
Attention aux dossiers publics !
Les organisations historiquement utilisatrices d’Exchange ont souvent accumulé des processus autour des « Public Folders ». Microsoft indique travailler notamment sur des capacités d’import/export pour les dossiers publics dans sa feuille de route.
De son côté, BitTitan MigrationWiz avertissait récemment ses clients que ses scénarios de migration de dossiers publics nécessitaient une attention particulière dans le contexte de la disparition d’EWS.
Les entreprises utilisant encore fortement les dossiers publics doivent donc les traiter comme un chantier spécifique, et non comme une simple sous-partie de la migration des applications EWS.
Mais pour quelles raison MS abandonne EWS ?
Microsoft explique que Microsoft Graph propose des politiques de sécurité et de gouvernance plus strictes, notamment grâce à OAuth et à une granularité plus fine des autorisations d’accès aux boîtes aux lettres. La sécurité est d’ailleurs devenue une motivation importante du calendrier. L’incident Midnight Blizzard de janvier 2024 impliquait EWS, a renforcé l’urgence de cette dépréciation.
Le cas délicat des environnements hybrides et Exchange Server SE
Pour les organisations conservant Exchange Server, le sujet devient encore plus intéressant. 😉
Microsoft précise clairement que Microsoft Graph ne prend pas en charge Exchange on-premises. La documentation de migration vers Graph concerne Exchange Online et les scénarios hybrides dans lesquels Graph accède aux ressources cloud, mais Graph ne remplace pas EWS comme API d’accès direct à Exchange Server local.
Cette situation est particulièrement importante dans une trajectoire mêlant Exchange Server SE, Exchange Online et évolution vers un cloud souverain : le choix de l’API devient alors directement lié à la localisation de la boîte aux lettres et à l’architecture cible.
La suppression d’EWS dans Exchange Online est finalement révélatrice d’une transformation plus profonde de Microsoft 365 qui supprime les protocoles historiques pour des api moderne, des méthodes d’authentification basées sur Oauth, des identitées applicatives etc..
Les entreprises qui traiteront uniquement le sujet quelques semaines avant une coupure prendront surtout le risque de découvrir tardivement une application métier oubliée. A l’inverse, celles qui l’abordent comme un programme de rationalisation des accès applicatifs à la messagerie peuvent au contraire en profiter pour supprimer des applications obsolètes, réduire les privilèges, documenter les comptes de service et mieux maîtriser les accès aux données Exchange.
Bon projet !
Laurent TERUIN
