La fin d’EWS dans Exchange Online est un sujet applicatif avant d’être un changement de protocole. Une intégration peut sembler secondaire dans l’inventaire Microsoft 365 et pourtant créer les tickets clients, importer les candidatures, lire une boîte de factures ou alimenter une archive. Si elle cesse de fonctionner, l’incident se voit d’abord dans le métier : aucun dossier créé, rendez-vous non synchronisé, document non classé.
Microsoft prépare une désactivation progressive d’Exchange Web Services (EWS). Sa publication « Introducing EWSAllowedAppIDs » présente une liste d’applications autorisées pour traverser la période de transition. Ce mécanisme donne du temps pour migrer ; il n’allonge pas indéfiniment la vie d’EWS. La méthode qui suit s’adresse aux administrateurs Microsoft 365, équipes infrastructure, développeurs et propriétaires d’applications qui doivent conserver les flux utiles tout en supprimant la dépendance.
À retenir : un App ID autorisé peut continuer à appeler EWS pendant la transition si la configuration du tenant le permet. Le projet est terminé seulement lorsque l’application n’appelle plus EWS, que les résultats métier ont été vérifiés et que l’exception a été retirée.
EWS : ce que l’on retire, et pourquoi il est encore là
EWS est l’API historique d’Exchange pour accéder aux messages, dossiers, calendriers, contacts et paramètres de boîte. Les applications lui envoient des opérations SOAP, parfois à travers la bibliothèque EWS Managed API. Il est présent depuis Exchange Server 2007. Microsoft a cessé d’investir activement dans ses API pour Exchange Online et recommande Microsoft Graph pour les applications cloud.
Sa longévité s’explique facilement. Un connecteur RH installé il y a huit ans peut encore surveiller une boîte de recrutement. Un CRM peut transformer les messages entrants en activités. Un outil de ticketing peut lire une boîte de support, déplacer les emails traités et répondre au nom d’un agent. Une solution d’archivage peut extraire messages et pièces jointes ; une application métier peut créer des événements ou consulter des disponibilités. Plusieurs de ces produits ont évolué, mais leur connecteur Exchange est resté en place.
Un scanner multifonction mérite une vérification précise : beaucoup envoient simplement par SMTP et ne sont pas concernés par la fin d’EWS. D’autres connecteurs de capture ou de classement lisent une boîte via EWS. Il faut identifier le protocole réel, pas classer tous les scanners comme des applications EWS. Même distinction pour les outils de sauvegarde, CRM, logiciels RH et archivages : le nom du produit ne suffit pas à déduire son intégration.
La portée annoncée concerne EWS dans Exchange Online. Un serveur Exchange local n’est pas supprimé par ce calendrier, mais une architecture hybride peut dépendre d’appels EWS vers le cloud. Il faut donc localiser chaque appel, son sens et son propriétaire. Le fait qu’Outlook fonctionne pour les utilisateurs n’établit rien sur la santé d’une API utilisée la nuit par un service.
Le calendrier à retenir au 27 août 2026
Microsoft annonce une désactivation par phases à partir d’octobre 2026, tenant par tenant, puis un arrêt définitif le 1er avril 2027 dans Exchange Online. Ce calendrier ne signifie pas que toutes les applications s’arrêtent le 1er octobre au matin. Il signifie que la fenêtre de préparation doit se fermer avant la première vague possible, sans attendre une date individuelle de bascule. L’annonce du calendrier Exchange Team donne le cadre ; suivez les messages du centre d’administration pour votre tenant.
La propriété d’organisation EwsEnabled est essentielle. Avant la phase de retrait, Null est l’état par défaut et permet EWS ; False le bloque ; avec True, une liste d’App IDs configurée peut restreindre les applications autorisées. À partir d’octobre, Microsoft prévoit de faire passer progressivement les tenants laissés à Null à False. Configurer True et une liste qualifiée peut préserver provisoirement certains usages pendant cette phase. Le 1er avril 2027 reste une échéance de retrait, pas une date à laquelle une liste continuerait à garantir l’accès.
Ne confondez pas une liste d’exception et une garantie de continuité. Un App ID manquant, une politique d’accès EWS existante ou un compte privé de permissions peut toujours provoquer un échec. Inversement, autoriser largement tous les App IDs pour faire disparaître une alerte prolonge des dépendances inconnues et complique la migration.
EWSAllowedAppIDs : contrôle temporaire, pas stratégie cible
EWSAllowedAppIDs est une liste d’identifiants d’application Microsoft Entra autorisés à utiliser EWS lorsque le paramétrage EWS correspondant l’impose. Elle s’applique à des App IDs, pas à des noms commerciaux, des adresses email ou de simples User Agents. Elle ne convertit aucun appel SOAP en Microsoft Graph. Elle ne remplace ni le consentement OAuth, ni les autorisations de boîte, ni une politique de sécurité applicative.
Cette distinction compte lorsqu’un éditeur partage un connecteur entre plusieurs clients : l’App ID visible peut être celui de l’éditeur, et non une App Registration créée dans votre tenant. Associez chaque ID à un fournisseur, un produit, un propriétaire interne et un usage mesuré. Si une valeur est inconnue, ne la placez pas dans la liste « par prudence » ; recherchez d’abord ce qu’elle fait et les boîtes auxquelles elle accède.
Les anciennes propriétés EwsAllowList et EwsBlockList reposent sur le User Agent. EWSAllowedAppIDs repose sur l’identité Entra de l’application. Lorsque des contrôles de plusieurs types existent, ils doivent être examinés ensemble. Un App ID autorisé ne rend pas automatiquement valide un User Agent bloqué, et EwsEnabled: False à l’échelle de l’organisation coupe EWS. La documentation Microsoft du contrôle d’accès EWS décrit ces paramètres.
Pour les commandes, privilégiez la lecture et la sauvegarde de l’état initial avant toute modification. Dans Exchange Online PowerShell, relevez EwsEnabled, les politiques User Agent et la liste des App IDs avec Get-OrganizationConfig. Préparez la liste de remplacement entière : un Set-OrganizationConfig -EwsAllowedAppIDs doit être traité comme une modification de configuration à tester, documenter et relire. Les exemples Microsoft utilisent une chaîne d’App IDs séparés par des virgules. N’effectuez pas cette opération à l’aveugle sur le tenant de production.
EWS et Microsoft Graph : une migration de fonctions et d’identités
La migration EWS vers Microsoft Graph n’est pas un remplacement global d’URL. EWS expose des opérations SOAP ; Graph expose des ressources et opérations REST. Microsoft publie une table de correspondance EWS–Graph : FindItem vers la liste des messages, GetItem vers la lecture d’un message, SendItem vers l’envoi, et SyncFolderItems vers la synchronisation delta. Ces correspondances orientent la conception, mais les modèles de pagination, d’identifiants, de notifications, de synchronisation et d’erreurs doivent être retestés dans le cas réel.
Une application qui scrute une boîte de support devra choisir entre delta query et notifications de changement, gérer les reprises après interruption et éviter les tickets doublons. Une application calendrier devra vérifier les fuseaux horaires, récurrences, délégations et droits sur les boîtes partagées. Une application d’archivage devra qualifier précisément les dossiers, métadonnées et fonctions utilisées : la présence d’une API Graph pour les messages courants ne prouve pas une équivalence complète de son flux d’archive. Les écarts fonctionnels se découvrent en rapprochant les actions SOAP observées des exigences métier, puis en testant.
Graph n’est pas l’API d’Exchange Server local. Si une même application dessert des boîtes locales et cloud, elle peut nécessiter deux chemins techniques temporaires ou une évolution de l’architecture. Présentez cette contrainte à l’éditeur dès le cadrage, surtout si la feuille de route du produit promet seulement « OAuth » sans mentionner l’abandon d’EWS.
OAuth n’est pas une migration API. Une application EWS utilisant un jeton OAuth continue d’appeler EWS et reste concernée par le retrait. À l’inverse, une application Graph doit utiliser une App Registration ou une identité de service Microsoft Entra, avec des permissions choisies selon le besoin : permissions déléguées si elle agit avec un utilisateur connecté, permissions d’application pour un traitement sans utilisateur. Microsoft distingue ces modèles dans sa documentation d’authentification EWS–Graph.
Les anciens comptes de service demandent une attention particulière. Un compte qui lit vingt boîtes par EWS et une permission étendue ne doit pas être reproduit mécaniquement avec Mail.ReadWrite sur tout le tenant. Distinguez lecture, écriture, envoi et calendrier. Mail.Send et Mail.ReadWrite sont des droits différents. Quand un accès applicatif est nécessaire, limitez les boîtes visées avec les mécanismes Exchange de RBAC pour les applications, et vérifiez qu’un consentement Entra non borné ne neutralise pas cette portée. Protégez les certificats ou secrets et prévoyez leur rotation.
Tableau de décision par usage
| Usage EWS constaté | Alternative Graph à évaluer | Risque si laissé en l’état | Priorité |
|---|---|---|---|
| Ticketing : lire, déplacer et répondre dans une boîte de support | Messages, dossiers, delta/notifications, Mail.ReadWrite et Mail.Send selon le besoin |
Tickets manquants ou doublons, réponse impossible | Très haute |
| CRM : synchroniser courriers et rendez-vous | Messages et calendriers Graph, permissions ciblées | Historique incomplet, rendez-vous non visibles | Haute |
| RH : dépouiller une boîte de candidatures | Lecture des messages et pièces jointes, delta | Candidatures non traitées, données sensibles exposées | Très haute |
| Archivage ou sauvegarde : extraire des contenus | API Graph adaptées après preuve de couverture fonctionnelle | Lacunes de conservation ou de restauration | Très haute |
| Application métier : créer des rendez-vous ou consulter les disponibilités | Événements et getSchedule selon le scénario |
Planning erroné, processus bloqué | Haute |
| Scanner : envoyer un document par email | Vérifier d’abord s’il utilise SMTP ou EWS ; Graph sendMail si pertinent |
Mauvais diagnostic ou arrêt de la numérisation | Selon dépendance |
| Ancien script de boîte de service | Graph avec identité applicative et portée limitée | Échec silencieux, privilèges excessifs | Haute |
Le tableau est un point de départ, pas une promesse de parité. Pour chaque ligne, notez l’action EWS précise, les boîtes visées, les droits attendus et un test d’acceptation métier. Un scanner SMTP peut rester hors de ce chantier EWS, même si son authentification doit être traitée ailleurs. Sur ce point, notre analyse de la fin de SMTP AUTH Basic pour imprimantes et scanners évite de mélanger les deux projets.
La méthode Dharmail en huit étapes
1. Inventorier les appels, pas seulement les logiciels
Ouvrez le rapport d’usage EWS du centre Microsoft 365. Il expose App ID, action SOAP, volume et date de dernière activité ; les vues couvrent 7, 30 ou 90 jours et un export CSV est disponible. Les données sont agrégées chaque semaine et peuvent mettre jusqu’à dix jours à apparaître. Complétez par les journaux applicatifs, scripts planifiés et contrats éditeurs.
2. Identifier chaque application et son propriétaire
Rapprochez les App IDs des applications d’entreprise et inscriptions d’applications Entra ID. Demandez aux éditeurs le produit, la version, la méthode d’authentification, les boîtes accédées et la date de livraison du connecteur Graph. Attribuez un propriétaire métier et un responsable technique à chaque flux.
3. Qualifier le flux et son impact
Décrivez le déclencheur, les opérations EWS, la fréquence, les données sensibles, les boîtes partagées, les comptes de service et le comportement attendu lors d’une panne. Classez les flux selon impact sur clients, paie, facturation, support et conformité. La priorité doit refléter le coût d’un échec silencieux autant que le volume d’appels. Un traitement annuel peut être plus critique qu’un connecteur bavard.
4. Vérifier les API et les écarts
Mappez chaque action SOAP vers la documentation Graph. Marquez les cas « équivalent direct », « adaptation nécessaire » et « écart à résoudre avec l’éditeur ». Testez particulièrement notifications, synchronisation delta, pièces jointes, calendriers, permissions et archivage. Si le produit ne propose pas Graph, obtenez une feuille de route écrite ou préparez un remplacement. Ne considérez pas une case « authentification moderne » comme preuve de migration.
5. Migrer avec des permissions minimales
Créez ou révisez l’App Registration Entra ID, choisissez délégué ou applicatif, demandez uniquement les permissions Graph nécessaires et limitez la portée aux boîtes justifiées. Remplacez les secrets anciens, documentez le consentement administrateur et le propriétaire de l’identité. Développez ou déployez le nouveau connecteur en parallèle contrôlé, puis coupez l’ancien chemin une fois les résultats comparés.
6. Tester les scénarios métier de bout en bout
Vérifiez en environnement représentatif la création d’un ticket, l’ajout d’un candidat, le classement d’une facture et le calendrier d’un rendez-vous. Testez aussi les échecs : jeton expiré, consentement manquant, throttling, doublon, pièce jointe volumineuse, boîte partagée et reprise après coupure. Comparez les données créées par les deux chemins. Une simple réponse HTTP 200 ne prouve pas que le workflow est correct.
7. Superviser pendant la bascule
Suivez les erreurs applicatives, les files de traitement, les délais de prise en charge et le rapport EWS. Le volume EWS doit décroître jusqu’à zéro pour l’application migrée. Le rapport ayant une latence, gardez aussi une télémétrie côté application. Documentez une marche arrière limitée dans le temps et un point de décision métier ; les exceptions doivent avoir une date d’expiration interne antérieure à l’arrêt définitif.
8. Retirer les exceptions
Quand l’application Graph est stable et qu’aucun appel EWS résiduel n’est observé sur une période couvrant ses cycles d’activité, retirez son App ID de EWSAllowedAppIDs. Révoquez les anciens consentements et identifiants inutiles, désactivez le connecteur EWS, puis mettez à jour la documentation d’exploitation. Répétez jusqu’à ce que la liste soit vide et que le tenant n’ait plus de dépendance EWS. Une liste d’autorisation laissée en place après migration est une dette de sécurité et d’exploitation.
Sécurité et gouvernance : les pièges à éviter
La migration est aussi une occasion de réduire les privilèges historiques. Relevez les permissions EWS comme EWS.AccessAsApp, les consentements Graph existants et les boîtes réellement nécessaires. Un App ID dans EWSAllowedAppIDs n’est pas une approbation de tous ses accès ; il faut toujours contrôler l’identité, la portée et le comportement. Les éditeurs tiers doivent fournir un contact d’escalade et une version prenant en charge Graph avant que l’exception devienne votre seule réponse aux incidents.
Gardez les projets adjacents séparés. La fin d’EWS n’est pas la fin de SMTP, ni un changement SPF, DKIM ou DMARC. En revanche, une migration d’application qui envoie des emails peut modifier son identité d’envoi, ses permissions et son circuit de remise ; testez les messages réellement reçus. Nos articles sur l’architecture d’envoi Microsoft 365, SPF, DKIM et DMARC et DNSSEC, DANE et MTA-STS dans Exchange Online apportent le contexte sécurité email. Les services d’audit de messagerie peuvent aider à rapprocher usages techniques et processus métier.
Conclusion
EWSAllowedAppIDs aide à traverser une phase de retrait ; ce n’est pas une stratégie de migration permanente. Le travail décisif consiste à trouver les appels réels, nommer les responsables, vérifier la couverture Graph, reconstruire les permissions avec une portée défendable et valider les résultats métier. Commencez par le rapport d’usage, mais terminez par la preuve que chaque workflow fonctionne sans EWS et par le retrait des exceptions. C’est ainsi que la fin d’une API ne devient pas l’arrêt d’une application essentielle.
Sources et références
- Microsoft Exchange Team — Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement
- Microsoft Learn — Rapport d’usage EWS
- Microsoft Learn — Migrer les applications EWS vers Microsoft Graph
- Microsoft Learn — Correspondances EWS–Microsoft Graph
- Microsoft Learn — Authentification EWS et Microsoft Graph
- Microsoft Learn — Contrôler l’accès à EWS
- Microsoft Learn — RBAC pour les applications Exchange Online