Fin d'EWS dans Exchange Online au 1er avril 2027 : migrer vos intégrations vers Microsoft Graph

Microsoft a commencé à désactiver Exchange Web Services (EWS) dans Exchange Online. Les premières mesures d'application interviennent ce mois-ci, les tenants qui n'ont jamais touché à leurs paramètres EWS seront ensuite désactivés un par un, et à partir du 1er avril 2027, EWS disparaît pour tous les tenants Microsoft 365. Microsoft a clairement indiqué qu'il n'y aurait aucune exception au-delà d'avril 2027.

Si un outil développé par votre entreprise dialogue avec des boîtes aux lettres Microsoft 365 via EWS, il cessera de fonctionner au plus tard à cette date, et peut-être bien avant. Les suspects habituels : un CRM qui classe les e-mails des clients dans leurs comptes, un script d'archivage ou de conservation, un écran de réservation de salles de réunion, un système de tickets qui lit une boîte de support partagée, une tâche de reporting qui compte les e-mails par équipe. La solution est une réécriture sur Microsoft Graph, et une partie de ce que permettait EWS n'a aucun équivalent dans Graph.

Ce qui se passe, date par date

Microsoft pilote EWS tenant par tenant via le paramètre EWSEnabled, qui accepte trois valeurs : Null (la valeur par défaut), True et False. À côté, il existe désormais un second paramètre, EWSAllowedAppIDs : une liste d'identifiants d'applications autorisées à continuer d'utiliser EWS. La page Microsoft Learn actuelle donne les grandes lignes : « octobre 2026 : EWS commence à être désactivé globalement pour toutes les organisations » et « avril 2027 : EWS est entièrement désactivé ».

Le détail figure dans le billet de l'équipe Exchange du 1er octobre, EWS Deprecation Is Here. Pour le cloud commercial mondial :

• 2 octobre 2026, en fin de journée, heure du Pacifique : Microsoft relève tous les tenants dont EWSEnabled vaut True sans liste d'autorisation.
• 8 et 9 octobre 2026 : pour ces tenants, Microsoft crée la liste d'autorisation et y inscrit les identifiants des applications qui ont utilisé EWS au cours des 60 jours précédents.
• À partir du 10 octobre 2026 : lorsque EWSEnabled vaut True, la liste d'autorisation est obligatoire. Une application qui n'y figure pas est refusée.
• Seconde phase, ensuite : les tenants encore à Null voient EWSEnabled passer à False, ce qui bloque EWS pour toutes les applications. Chacun reçoit un avertissement 7 jours avant dans le centre de messages, et Microsoft remplit peu avant une liste d'autorisation à partir de 60 jours d'utilisation, pour qu'un administrateur puisse réactiver EWS en passant à True.
• 1er avril 2027 : EWS est « entièrement et définitivement désactivé », et les administrateurs de tenant perdent toute possibilité de modifier EWSEnabled.

Les tenants des autres clouds de Microsoft reçoivent leur propre calendrier par le centre de messages.

La liste d'autorisation vous achète du temps, pas une solution

La liste automatique est construite à partir de 60 jours de trafic, et les propres recommandations de Microsoft du 4 septembre préviennent qu'elle « peut omettre des applications qui s'exécutent rarement ». Un export de fin de trimestre ou une tâche d'archivage de fin d'année n'y figurera pas, et échouera à sa prochaine exécution.

Les modifications de la liste d'autorisation mettent 24 heures à prendre effet, et celles d'EWSEnabled environ une heure. Toute correction apportée après une panne coûte au moins une journée.

Pour savoir où en est votre tenant, un administrateur disposant d'Exchange Online PowerShell peut exécuter :

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

À qui s'adresse cet article, et qui peut s'arrêter là

Exchange Server sur site n'est pas concerné. Microsoft précise que le retrait s'applique « uniquement à Microsoft 365 et à Exchange Online », et qu'« EWS ne change pas dans Exchange Server ». Si toutes vos boîtes aux lettres résident sur vos propres serveurs, vous pouvez vous arrêter ici.

Les configurations hybrides méritent un examen attentif. Les boîtes aux lettres sur site peuvent continuer à utiliser EWS ; les boîtes aux lettres dans le cloud doivent passer à Graph. Le billet de Microsoft sur l'hybride du 30 septembre traite deux cas qui exigent une action immédiate, dont celui des boîtes aux lettres sur site dont les archives résident dans Exchange Online, pour lequel le conseil est, pour l'instant, de laisser EWS activé et d'inscrire l'application hybride sur la liste d'autorisation.

Les logiciels du commerce relèvent de l'éditeur. Si ce qui appelle EWS est un produit commercial, livrer une version Graph est l'affaire de l'éditeur, et la vôtre consiste à obtenir une date et à installer la mise à jour. Les propres clients de Microsoft ne font pas exception : certains apparaissent encore dans les rapports d'utilisation et ont besoin de la liste d'autorisation jusqu'à leur mise à jour.

Le code maison relève de vous. Les scripts, les services internes, les outils open source personnalisés et les intégrations qu'une agence a construites il y a des années n'ont personne en amont pour les corriger. C'est là que se trouve le travail. Pour donner un ordre de grandeur : exchangelib, une bibliothèque Python qui dialogue avec Exchange via EWS, a été téléchargée 1 174 625 fois sur PyPI le mois dernier. Une partie de ces téléchargements correspond à un usage sur site, mais cela donne une idée de la quantité de code qui parle directement EWS.

Première étape : trouver tout ce qui utilise EWS

Commencez par le rapport d'utilisation d'EWS dans le centre d'administration Microsoft 365 (Rapports, Utilisation, Exchange, puis l'onglet d'utilisation d'EWS). Pour chaque application, il indique l'identifiant d'application Microsoft Entra, chaque action SOAP appelée par cette application, le volume d'appels et la date de dernière activité. Vous pouvez remonter sur 7, 30 ou 90 jours et exporter en CSV.

Trois choses à savoir à son sujet :

• Les données sont agrégées chaque semaine et peuvent mettre jusqu'à 10 jours à apparaître.
• Un identifiant d'application n'est pas un responsable. Rapprochez chaque identifiant des applications d'entreprise dans Microsoft Entra, puis trouvez la personne ou l'équipe qui l'exploite. Attendez-vous à quelques identifiants que personne ne reconnaît.
• La colonne des actions SOAP vous indique l'ampleur de chaque chantier. Une application qui n'appelle que FindItem et GetItem est un travail court. Une application qui appelle SyncFolderItems, Subscribe et ExportItems est un projet.

Même 90 jours ne suffisent pas pour les tâches annuelles : vérifiez donc aussi l'autre côté. Les tâches planifiées et les entrées cron, et les dépôts de code, en recherchant le point d'accès EWS (Exchange.asmx), l'EWS Managed API pour .NET et exchangelib. La page de Microsoft sur la dépréciation renvoie aussi vers un analyseur EWS pour le code .NET (il signale les appels EWS dans Visual Studio et VS Code et propose des équivalents Graph) et vers un tutoriel de refactorisation assistée par IA.

Deuxième étape : décider ce que devient chaque intégration

Chaque application de la liste reçoit l'une de quatre réponses :

1. La retirer. Certaines intégrations n'existent que parce que personne ne les a arrêtées.
2. La mettre à jour. Les produits d'éditeurs reçoivent une mise à jour de l'éditeur. Convenez de la date dès maintenant.
3. La réécrire sur Microsoft Graph. Le choix par défaut pour le code maison.
4. La repenser. Pour tout ce qui repose sur une fonctionnalité que Graph n'aura jamais (voir plus bas).

Microsoft cite aussi Power Platform comme moyen de réimplémenter un flux de travail. Pour un script qui transfère des pièces jointes vers un dossier, cela peut être la réponse la moins coûteuse.

Ce qu'implique réellement une réécriture sur Graph

La plupart des opérations EWS ont un équivalent direct dans Graph, et Microsoft tient à jour une correspondance entre EWS et Graph. La correspondance est la partie facile. Les parties difficiles sont celles qu'elle ne montre pas.

Les autorisations se resserrent, et c'est une bonne chose

Une application qui utilise EWS sans utilisateur connecté détient l'autorisation d'application EWS, que Microsoft décrit comme un « accès complet à toutes les boîtes aux lettres ». Graph la scinde en autorisations distinctes : Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read et ainsi de suite.

Vous pouvez aussi limiter les boîtes aux lettres auxquelles une application accède. RBAC for Applications dans Exchange Online attribue une autorisation sur une étendue de gestion ou une unité administrative, et remplace les anciennes Application Access Policies. Un écran de réservation de salles peut lire les calendriers de douze boîtes aux lettres de salles et rien d'autre. Un piège : les droits accordés de cette façon s'ajoutent à tout droit accordé à l'échelle du tenant dans Microsoft Entra ; si Mail.Read y est toujours consenti, votre étendue ne restreint rien. Supprimez le droit accordé dans Entra.

Utilisez autant que possible des certificats plutôt que des secrets client pour l'authentification des applications, et gardez les identifiants hors des scripts et des dépôts de code.

La synchronisation et les notifications se reconstruisent, elles ne se traduisent pas

C'est généralement le plus gros changement pour tout ce qui conserve une copie locale des données des boîtes aux lettres.

Synchronisation. SyncFolderItems correspond à la requête delta sur les messages de Graph, et SyncFolderHierarchy à la requête delta sur les dossiers de messagerie. Le delta sur les messages fonctionne dossier par dossier : une synchronisation complète d'une boîte aux lettres suppose de suivre l'arborescence des dossiers et de stocker un lien delta distinct par dossier. Le filtrage est limité (uniquement sur la date de réception), et les résultats incluent les suppressions, les déplacements hors du dossier et les changements d'état de lecture, même lorsqu'ils ne correspondent pas à votre filtre.

Notifications. Les abonnements EWS en streaming et en push deviennent des notifications de modification Graph, remises à un webhook que vous exploitez ou à Azure Event Hubs ou Event Grid. Un webhook doit être joignable depuis l'infrastructure de Microsoft, ce qui représente un changement d'architecture pour un script qui maintenait une connexion ouverte depuis l'intérieur du pare-feu. Les abonnements pour le courrier, le calendrier et les contacts durent au maximum 10 080 minutes (un peu moins de sept jours), ou 1 440 minutes quand la notification transporte les données : quelque chose doit donc les renouveler. Chaque boîte aux lettres admet au plus 1 000 abonnements actifs, toutes applications confondues.

Le schéma qui tient la route : traiter une notification comme un indice, lancer la requête delta pour voir ce qui a changé, et la lancer aussi à intervalles réguliers pour rattraper ce qu'une notification manquée aurait fait perdre.

Données, identifiants et débit

• Identifiants stockés. Si votre CRM ou votre système de tickets a enregistré des identifiants d'éléments EWS pour relier des e-mails à des fiches, ces liens doivent être convertis. Graph dispose d'une fonction translateExchangeIds précisément pour cela. Planifiez la conversion comme une étape de migration à part entière.
• Recherches. ResolveNames correspond à l'API People, GetUserAvailability à getSchedule, les paramètres d'absence aux paramètres de boîte aux lettres. Des équivalents proches, pas identiques.
• Limitation de débit. Graph limite chaque couple application et boîte aux lettres à 10 000 requêtes par tranche de 10 minutes, quatre requêtes simultanées et 150 Mo de téléversements par tranche de 5 minutes. Une tâche de masse qui faisait tourner des dizaines de fils EWS en parallèle sur une même boîte aux lettres doit être repensée autour de ces chiffres.

Les manques, et ce qui ne viendra jamais

Microsoft publie une feuille de route des fonctionnalités EWS encore absentes de Graph. On y trouve l'import et l'export en haute fidélité pour les boîtes d'archives, de dossiers publics et de groupes, l'accès aux archives sur place, les autorisations sur les dossiers via l'Exchange Admin API, et la création de messages autres que des brouillons à partir de MIME. La plupart des échéances visent le quatrième trimestre 2026. Quelques-unes étaient prévues pour le troisième trimestre, désormais terminé : vérifiez ce qui a réellement été livré avant de concevoir autour. L'avertissement de Microsoft lui-même : si une fonctionnalité ne figure pas sur la feuille de route, « ne comptez pas » sur un équivalent Graph avant l'arrêt d'EWS.

Trois fonctionnalités ne viendront jamais dans Graph, c'est confirmé :

• L'accès générique aux dossiers publics (création, lecture, mise à jour et suppression de dossiers et d'éléments).
• L'accès générique aux boîtes aux lettres des groupes Microsoft 365. Graph couvre à la place les conversations, fils et publications de groupe.
• L'accès aux boîtes aux lettres de découverte. Microsoft renvoie à la place vers Purview eDiscovery.

Si un outil dépend de l'une de ces fonctionnalités, porter le code ne suffit pas : les données ou le flux de travail doivent d'abord partir ailleurs, et cela prend plus de temps qu'une réécriture.

Un plan sur six mois

D'aujourd'hui au 1er avril 2027, il reste un peu moins de six mois. Un ordre réaliste :

Octobre 2026 : faire le point. Vérifiez EWSEnabled et la liste d'autorisation. Exportez 90 jours du rapport d'utilisation. Passez en revue la liste remplie par Microsoft, retirez ce qui ne devrait pas y être, et ajoutez les tâches peu fréquentes que vous connaissez. Si votre tenant est encore à Null, envisagez de définir vous-même la liste et True plutôt que d'attendre le passage à False par Microsoft pour découvrir ce qui casse.

Novembre 2026 : tri. Attribuez un responsable et une réponse (retirer, mettre à jour, réécrire, repenser) à chaque identifiant d'application. Analysez le code. Signalez tout ce qui touche aux dossiers publics, aux boîtes aux lettres de groupes ou aux boîtes aux lettres de découverte, et lancez la refonte dès maintenant. Créez les inscriptions d'applications Graph avec des autorisations restreintes.

De décembre 2026 à janvier 2027 : développement. Commencez par l'intégration qui manquerait le plus vite au métier. Construisez une seule fois la tuyauterie de synchronisation et de notification, et réutilisez-la. Convertissez les identifiants stockés.

Février 2027 : faire tourner les deux en parallèle. Tant qu'EWS fonctionne encore, faites tourner l'ancienne et la nouvelle version sur les mêmes boîtes aux lettres et comparez les résultats. À mesure que chacune est validée, retirez son identifiant de la liste d'autorisation. C'est aussi le test : attendez les 24 heures et vérifiez que rien d'autre ne s'est arrêté.

Mars 2027 : désactivez EWS vous-même. Passez EWSEnabled à False bien avant le 1er avril. Tout ce que vous avez oublié échouera pendant que vous pouvez encore réactiver EWS. Après le 1er avril, cette option disparaît. Faites aussi tourner délibérément les tâches trimestrielles et annuelles avant cette date : une tâche qui s'exécute à la clôture du premier trimestre s'exécutera pour la première fois après la disparition d'EWS.

Où trouver de l'aide

Le cas difficile, c'est l'intégration dont le développeur d'origine est parti. Notre service de maintenance de systèmes anciens est conçu pour cela : nous lisons le code existant, réécrivons les parties EWS sur Microsoft Graph (autorisations, synchronisation, notifications, migration des identifiants) et faisons tourner l'ancien et le nouveau en parallèle jusqu'à ce que les chiffres concordent. Si vous avez plutôt besoin d'ingénieurs qui travaillent au sein de votre propre équipe, voyez notre service de renforcement d'équipe.

Si votre rapport d'utilisation est rempli d'identifiants d'applications que personne ne reconnaît, écrivez à office@c9group.dev.