Fin programmée pour Exchange Web Services (EWS)
Microsoft confirme la mise hors service progressive d’Exchange Web Services (EWS) dans Exchange Online / Microsoft 365. EWS, API historique utilisée par de nombreuses applications (messagerie, calendriers, contacts, archivage, outils ITSM, solutions de conformité, etc.), va entrer dans une phase de blocage à partir du 1er octobre 2026, puis être désactivée définitivement le 1er avril 2027, sans possibilité d’exception.
Le mécanisme annoncé est important : si la propriété EWSEnabled de votre tenant reste à sa valeur par défaut (Null) au moment du déploiement, Microsoft la fera basculer vers False, ce qui bloquera EWS pour l’ensemble des applications. Pour éviter une coupure « surprise », Microsoft introduit une Allow List AppID (prévue début 2026) permettant d’autoriser uniquement certaines applications EWS ; et recommande, pour ceux qui en ont encore besoin, de renseigner la liste et positionner EWSEnabled=True avant fin août 2026.
Impacts concrets côté entreprise : tout composant dépendant d’EWS risque de tomber en panne (synchronisation de boîtes partagées, création/lecture d’événements, ingestion d’e-mails par un outil tiers, exports eDiscovery, traitements automatisés…). Sur le triptyque Confidentialité / Intégrité / Disponibilité, le risque immédiat est la disponibilité (interruption de processus métier). Mais les effets domino touchent aussi l’intégrité (traitements incomplets, doublons, pertes d’événements) et la confidentialité (contournements opérationnels, redirections manuelles, usages « bricolés »).
Microsoft justifie la retraite d’EWS par l’écart avec les exigences modernes de sécurité, d’échelle et de fiabilité, et met en avant Microsoft Graph comme voie de remplacement pour la majorité des cas d’usage, tout en publiant les écarts de parité restants.
Point d’attention : Microsoft annonce des “scream tests” (coupures temporaires) pour révéler des dépendances cachées, et une communication régulière via le Message Center. Attendre 2026, c’est accepter un risque élevé de découverte tardive.
Enfin, conserver des briques en fin de vie (EOL) ou dépendantes d’un protocole/API retiré n’est pas qu’un sujet technique : c’est une exposition structurelle (surface d’attaque legacy, support éditeur/tiers qui disparaît, non-conformités potentielles, plans de continuité fragilisés). La réponse rationnelle est de cartographier l’usage EWS, prioriser les applications critiques, basculer vers Graph, et n’utiliser l’Allow List que comme filet temporaire de réduction de risque.
Source : Microsoft
