Ce que la fin d'EWS chez Microsoft implique pour la synchronisation des calendriers

Exchange Web Services commence à être désactivé le 1er octobre 2026 et s'éteint définitivement le 1er avril 2027. Voici ce qui cesse réellement de fonctionner, ce qui n'est pas concerné, et les deux paramètres de tenant qui déterminent dans quel camp vous vous trouvez.

Microsoft met fin à Exchange Web Services (EWS) dans Exchange Online. La désactivation débute à l'échelle mondiale le 1er octobre 2026 et EWS est totalement coupé le 1er avril 2027. La synchronisation de calendriers qui repose sur Microsoft Graph n'est pas concernée. Ce qui cesse de fonctionner, c'est le libre/occupé inter-tenants entre organisations partenaires, les boîtes aux lettres sous licences Kiosk, F1 et F3, ainsi que toute application tierce appelant encore EWS.

Le calendrier, dates à l'appui

Quatre événements se produisent à quatre dates différentes. Ils sont fréquemment présentés comme un seul, d'où le fait que tant d'administrateurs aient la mauvaise échéance en tête.

Microsoft a annoncé pour la première fois en 2018 qu'EWS ne recevrait plus d'évolutions fonctionnelles, et a fixé en 2023 la date de désactivation d'octobre 2026. L'incident Midnight Blizzard de janvier 2024 impliquait EWS et a élargi le périmètre des applications tierces aux produits de Microsoft eux-mêmes, ce qui explique qu'Outlook, Office, Teams et Dynamics 365 en soient également détachés.

Les deux paramètres qui déterminent tout

La désactivation d'EWS est pilotée par deux propriétés au niveau du tenant, et c'est leur interaction qui prend les organisations au dépourvu.

EWSEnabled

Cette propriété admet trois valeurs : True, False et Null. Null est la valeur par défaut aujourd'hui, et elle se comporte actuellement comme True. Le 1er octobre 2026, à mesure que le déploiement atteint votre tenant, Null est remplacé par False. Ce simple changement bloque EWS pour toutes les applications du tenant d'un seul coup.

Si vous disposez encore d'une application qui a réellement besoin d'EWS entre octobre 2026 et avril 2027, vous devez définir explicitement EWSEnabled sur True. Conserver la valeur par défaut ne revient pas à laisser les choses en l'état.

EWSAllowedAppIDs

Définir EWSEnabled sur True ne suffit plus à lui seul. À partir du 1er octobre 2026, il vous faut également une liste d'autorisation renseignée nommant les App ID habilités à appeler EWS. S'il manque l'une des deux moitiés, EWS s'arrête pour tout ce qui en dépend.

Microsoft pré-remplit cette liste avant septembre 2026 pour les tenants qui n'en ont pas constitué une, en se fondant sur l'usage observé de chaque tenant. C'est utile, mais elle est construite à partir de ce que votre tenant a appelé récemment. Une application qui s'exécute une fois par trimestre, ou restée inactive pendant la période d'observation, peut donc manquer à une liste que vous croyez complète.

Comment vérifier votre propre tenant

Connectez-vous à Exchange Online PowerShell et relevez l'état actuel avant de planifier quoi que ce soit :

Get-OrganizationConfig | Format-List EWSEnabled, EWSAllowedAppIDs, EWSApplicationAccessPolicy, EWSAllowList, EWSBlockList

Déterminez ensuite si quelque chose appelle réellement EWS. Les rapports d'utilisation EWS du centre d'administration Microsoft 365 montrent le trafic réel par application, ce qui est plus fiable que de mener l'enquête en interne.

Si vous partagez vos disponibilités avec des organisations partenaires, vérifiez les trois configurations qui reposent sur EWS en arrière-plan :

Get-OrganizationRelationship | Format-List Name, DomainNames, FreeBusyAccessEnabled
Get-AvailabilityAddressSpace | Format-List Name, ForestName, AccessMethod
Get-SharingPolicy | Format-List Name, Domains, Enabled

Si les trois commandes ne renvoient rien, le volet inter-tenants ne vous concerne pas. Microsoft a envoyé la notification du centre de messages à tous les tenants : un très grand nombre d'administrateurs ont donc reçu une alerte au sujet d'une fonctionnalité qu'ils n'utilisent pas.

Ce qui cesse de fonctionner, et ce qui n'est pas concerné

La distinction qui compte est de savoir si un outil dialogue avec Exchange Online via EWS ou via Microsoft Graph. Graph est l'API de remplacement et n'est nullement affectée par les dates ci-dessus.

Cela affecte-t-il CalendarBridge ?

Non. CalendarBridge se connecte à Microsoft 365 via Microsoft Graph, en utilisant les portées déléguées Calendars.ReadWrite et User.Read. Aucune dépendance à EWS n'existe : ni la date d'octobre 2026 ni celle d'avril 2027 ne changent donc quoi que ce soit au fonctionnement de vos connexions de synchronisation, et CalendarBridge n'a pas besoin de figurer dans votre liste d'autorisation EWSAllowedAppIDs.

Si vous auditez vos fournisseurs avant l'échéance, c'est la question à poser à chacun d'eux : Graph ou EWS ? Tout outil de calendrier encore sur EWS se heurte à un arrêt brutal en avril 2027, et à une migration à mener d'ici là.

Comment migrer, selon ce dont vous disposez réellement

Il n'existe pas une migration unique. Ce que vous devez faire dépend de laquelle des quatre situations ci-dessus vous concerne, et la plupart des organisations en cumulent plusieurs.

Remplacer le libre/occupé inter-tenants par une synchronisation de calendriers

Le volet inter-tenants est celui qui touche le plus probablement les utilisateurs ordinaires, et il vaut la peine de comprendre l'alternative plutôt que d'opter par défaut pour une migration à l'identique.

La Cross-Tenant Access Policy conserve le modèle actuel : un tenant interroge l'autre en temps réel dès que quelqu'un ouvre l'assistant de planification. Elle préserve les consultations en direct et constitue la bonne réponse si vous avez besoin d'une disponibilité réellement à la seconde près entre organisations. En contrepartie, vous migrez une configuration de confiance inter-tenants, et les deux tenants doivent ensuite la maintenir en bon état.

La synchronisation de calendriers inverse le modèle. Au lieu d'interroger le tenant partenaire, CalendarBridge copie les événements dans un calendrier de votre propre tenant, où ils se comportent comme n'importe quels autres événements. Ils bloquent du temps, apparaissent dans l'assistant de planification et dans Trouver un créneau, et survivent à tout ce qui peut arriver à la relation entre les deux tenants, puisqu'il n'existe aucune consultation en direct susceptible de se rompre.

La synchronisation convient généralement mieux lorsque le besoin est simplement que chacun voie quand ses interlocuteurs sont occupés. La Cross-Tenant Access Policy convient mieux lorsque vous avez besoin d'une exactitude en temps réel ou d'une véritable visibilité bidirectionnelle sur le détail du calendrier d'un partenaire.

La mettre en place pour vous-même

1. Connectez les deux comptes à CalendarBridge. Les comptes Microsoft 365 se connectent via OAuth en utilisant les portées Graph déléguées Calendars.ReadWrite et User.Read : aucun recours à EWS, et aucune entrée requise dans la liste d'autorisation.
2. Créez une synchronisation unidirectionnelle du calendrier partenaire ou secondaire vers le calendrier dans lequel vous travaillez réellement.
3. Dans les paramètres de confidentialité de la connexion de synchronisation, laissez Subject, Description, Location et Attendees décochés afin que chaque copie se réduise à un simple bloc occupé. Cochez également All Private si vous souhaitez que les copies apparaissent comme occupées dans l'Assistant Planification d'Outlook et dans Trouver un créneau de Google.

La mettre en place pour toute l'organisation

Si vous remplacez une Organization Relationship qui desservait une entreprise entière, mieux vaut recourir aux synchronisations gérées plutôt que de demander à chaque utilisateur de configurer la sienne :

1. Créez un compte de groupe avec des licences de synchronisation plutôt que des licences utilisateur.
2. Autorisez l'accès pour les synchronisations gérées dans chaque tenant hébergeant des calendriers dont vous avez besoin. Sur Microsoft 365, il s'agit d'une autorisation d'application accordée par un administrateur du tenant, là encore sur Graph.
3. Connectez les domaines autorisés au compte de groupe, une fois par tenant.
4. Créez les connexions de synchronisation gérées. En dessous de vingt, attribuez-les une par une. À partir de vingt, utilisez une tâche en masse pour importer toute la liste de correspondances en une seule fois.

Comme ce dispositif repose sur des autorisations d'application accordées par l'administrateur de chaque tenant, il ne dépend ni d'une Organization Relationship, ni d'un Availability Address Space, ni d'une Sharing Policy. Aucune des trois configurations migrées en septembre 2026 n'intervient dans la chaîne.

Si vous avez seulement besoin de publier vos disponibilités

Certaines relations inter-tenants n'existent que pour permettre à un tiers de voir quand vos collaborateurs sont libres. Dans ce cas, un flux de calendrier public est plus simple que l'une ou l'autre des options ci-dessus. Choisissez les calendriers, désactivez tous les champs de détail, et partagez le lien obtenu ou l'URL d'abonnement ICS. Le destinataire n'a besoin ni d'un tenant Microsoft 365, ni d'une relation avec le vôtre, ni d'un compte quelconque. Voir comment synchroniser des calendriers sans partager les détails des événements pour la version champ par champ.

Que faire dans les six prochaines semaines

1. Relevez votre état actuel. Exécutez la commande Get-OrganizationConfig ci-dessus et notez la valeur actuelle d'EWSEnabled.
2. Extrayez le rapport d'utilisation. Découvrez ce qui appelle véritablement EWS, plutôt que de vous fier à la mémoire collective.
3. Vérifiez les configurations inter-tenants. Si Get-OrganizationRelationship ne renvoie rien, vous pouvez cesser de vous préoccuper de l'échéance de septembre.
4. Auditez l'attribution des licences. Les utilisateurs Kiosk, F1 et F3 perdent EWS sans dérogation possible. Si l'un d'eux dépend d'un outil basé sur EWS, il lui faut une autre licence.
5. Posez à vos fournisseurs la question de Graph. Obtenez la réponse par écrit, et considérez toute imprécision comme une réponse en soi.

La liste d'autorisation est un pont, pas une destination. Tout ce que vous y ajouterez en octobre 2026 cessera malgré tout de fonctionner en avril 2027 : profitez de cette fenêtre pour migrer, non pour temporiser.

Questions fréquentes

Quand exactement EWS cesse-t-il de fonctionner ?

La désactivation d'EWS débute à l'échelle mondiale le 1er octobre 2026 et EWS est totalement désactivé le 1er avril 2027. Entre ces deux dates, EWS ne peut continuer à fonctionner que si le tenant a EWSEnabled défini sur True et si l'App ID de l'application appelante figure dans la liste d'autorisation EWSAllowedAppIDs. Après le 1er avril 2027, aucun paramètre ne permet de le maintenir en service.

Ma synchronisation de calendriers cessera-t-elle de fonctionner avec la fin d'EWS ?

Uniquement si votre outil de synchronisation utilise EWS. Les outils bâtis sur Microsoft Graph ne sont pas concernés, car Graph est l'API de remplacement et non une victime de cet arrêt. CalendarBridge utilise Microsoft Graph et n'exige aucune entrée dans la liste d'autorisation ni aucune modification de configuration.

Que se passe-t-il si je ne fais rien avant le 1er octobre 2026 ?

Les tenants dont EWSEnabled est encore défini sur Null le voient passer à False à mesure que le déploiement les atteint, ce qui bloque EWS pour toutes les applications du tenant. Null étant la valeur par défaut actuelle, la plupart des tenants qui n'entreprennent rien seront coupés automatiquement.

La fin d'EWS affecte-t-elle le libre/occupé inter-tenants ?

Oui. Le libre/occupé inter-tenants, les MailTips et le partage de calendrier configurés via une Organization Relationship, un Availability Address Space ou une Sharing Policy reposent tous sur EWS. Microsoft les migre vers la Cross-Tenant Access Policy de Microsoft 365, avec un déploiement démarré en août 2026 et achevé au 1er septembre 2026.

Les boîtes aux lettres Kiosk, F1 et F3 peuvent-elles conserver l'accès à EWS ?

Non. À partir du 1er octobre 2026, les requêtes EWS provenant de boîtes aux lettres ne disposant que d'une licence Exchange Online Kiosk, Microsoft 365 F1 ou Office 365 F3 renvoient une erreur HTTP 403. La liste d'autorisation ne les exempte pas. Ces utilisateurs ont besoin d'une licence incluant les droits EWS, telle qu'Exchange Online Plan 1 ou 2, ou Microsoft 365 E3 ou E5.

Comment savoir quelles applications utilisent encore EWS ?

Utilisez les rapports d'utilisation EWS du centre d'administration Microsoft 365, qui indiquent le trafic EWS réel ventilé par application. Microsoft publie également un outil EWS Analyzer permettant d'analyser le code interne à la recherche d'appels EWS.

Sources

Calendrier et mécanismes vérifiés auprès de la documentation de Microsoft : Deprecation of Exchange Web Services in Exchange Online, Exchange Online EWS, Your Time is Almost Up, Introducing EWSAllowedAppIDs et Migrate to Microsoft 365 Cross-Tenant Access Policy. Références du centre de messages : MC1446796, MC1227454, MC1191578.