Migration EWS vers Microsoft Graph

Le calendrier de depreciation

Microsoft bloquera definitivement Exchange Web Services (EWS) pour Exchange Online le 1er octobre 2026, avec une suppression complete le 1er avril 2027. La depreciation affecte plus de 400 millions de licences commerciales Microsoft 365 dans le monde. Microsoft a annonce le retrait pour la premiere fois en septembre 2023 et a resserre le calendrier trois fois depuis.

Selon la page officielle de depreciation de Microsoft, les dates cles sont :

Si vous ne faites rien, votre code base sur EWS retournera des erreurs a partir d'octobre 2026. L'annonce TechCommunity confirme que Microsoft definira EWSEnabled=False sur les tenants qui n'ont pas opte pour l'exemption.

Exchange on-premises : pas concerne

La depreciation d'EWS s'applique uniquement a Exchange Online (Microsoft 365). Exchange Server 2016 et 2019 on-premises conservent un support EWS complet sans date de fin de vie annoncee. Les organisations en Exchange hybride -- que Microsoft estime a environ 40 % des deploiements Exchange en entreprise -- font face a une separation : les boites aux lettres cloud doivent migrer vers Graph API tandis que les boites on-premises continuent d'utiliser EWS.

Cette realite a double protocole signifie que les environnements hybrides necessitent deux flux d'authentification et deux surfaces d'API, ou une couche d'abstraction qui route les requetes vers le bon protocole en fonction de l'emplacement de la boite aux lettres.

Modele d'auth : NTLM/Basic vers OAuth 2.0

Migrer d'EWS vers Microsoft Graph necessite de remplacer NTLM, Kerberos ou Basic Auth par OAuth 2.0 via les enregistrements d'applications Azure AD (maintenant Entra ID). Microsoft a deprecie Basic Auth pour Exchange Online en octobre 2022, et Graph API exige OAuth 2.0 depuis son lancement. Les jetons d'acces expirent toutes les 60 a 90 minutes, et les jetons de rafraichissement durent 90 jours avant de necessiter une reauthentification.

• Enregistrer une application Azure AD avec les scopes Mail.Read, Mail.Send, Calendars.ReadWrite ou autres
• Choisir un flux : authorization code (delegue) pour le contexte utilisateur, client credentials (application) pour les applications daemon/service
• Gerer le cycle de vie des jetons : les jetons d'acces expirent en 60-90 minutes, les jetons de rafraichissement en 90 jours
• Consentement admin : les permissions au niveau application necessitent l'approbation de l'administrateur du tenant

Le code ci-dessous montre la difference entre l'authentification EWS Basic Auth et Graph OAuth 2.0. EWS necessitait aussi peu que 3 lignes pour se connecter, tandis que Graph a besoin d'un enregistrement d'application Azure AD avec les scopes corrects configures avant tout appel API.

# EWS (ancien) - Basic Auth ou NTLM
$cred = Get-Credential
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService
$service.Credentials = $cred
$service.Url = "https://outlook.office365.com/EWS/Exchange.asmx"

# Graph API (nouveau) - OAuth 2.0 avec MSAL
Connect-MgGraph -Scopes "Mail.Read","Mail.Send"
$messages = Get-MgUserMessage -UserId "me" -Top 10

Ecarts de parite fonctionnelle (en date d'avril 2026)

Microsoft Graph API couvre les operations de base pour le mail, le calendrier et les contacts, mais manque encore de parite complete avec EWS dans au moins 4 domaines : acces aux boites aux lettres d'archive, CRUD des dossiers publics, import/export de boites aux lettres, et requetes delta pour les evenements recurrents. Microsoft comble les ecarts selon un rythme de publication trimestriel depuis 2024, mais n'a pas fixe de date pour une parite fonctionnelle complete.

Le tableau ci-dessous associe chaque fonctionnalite EWS a son statut dans Graph API. Les donnees proviennent de la mise a jour TechCommunity de Microsoft et couvrent les 10 fonctionnalites EWS les plus couramment referencees :

Microsoft a publie l'Exchange Admin API comme passerelle temporaire pour certains ecarts. Mais il n'y a pas de date ferme pour la resolution de tous les ecarts de parite.

Trois chemins de migration

Les organisations quittant EWS ont trois options : migrer directement vers Microsoft Graph API, s'inscrire pour une extension temporaire via l'AppID AllowList, ou adopter une couche d'abstraction independante du fournisseur. Le bon choix depend du calendrier, des exigences Exchange hybride, et du nombre de fournisseurs que votre application supporte. La plupart des equipes ont besoin de 2 a 6 mois pour une migration directe vers Graph, selon les recommandations de planification de Microsoft.

Chemin 1 : Migrer vers Microsoft Graph API

Le chemin officiel remplace chaque appel EWS par son equivalent Graph. Microsoft fournit un analyseur de code EWS qui scanne votre base de code et associe les operations EWS aux equivalents Graph API. L'analyseur produit un rapport CSV listant chaque methode EWS, son nombre d'appels et l'endpoint Graph correspondant.

# EWS : Rechercher des emails par sujet
$view = New-Object Microsoft.Exchange.WebServices.Data.ItemView(50)
$filter = New-Object Microsoft.Exchange.WebServices.Data.SearchFilter+ContainsSubstring(
  [Microsoft.Exchange.WebServices.Data.ItemSchema]::Subject, "invoice")
$results = $service.FindItems(
  [Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox, $filter, $view)

# Graph : Meme operation
$messages = Get-MgUserMessage -UserId "me" -Filter "contains(subject, 'invoice')" -Top 50

Avantages : Reste dans l'ecosysteme Microsoft, acces aux fonctionnalites les plus recentes. Inconvenients : Enregistrement d'application Azure AD, gestion des jetons OAuth, pas de support pour les fournisseurs non-Microsoft, ecarts de parite fonctionnelle.

Chemin 2 : AppID AllowList temporaire

L'AllowList prolonge l'acces EWS de 6 mois, d'octobre 2026 au 1er avril 2027. Les administrateurs de tenant doivent enregistrer le client ID de leur application avant aout 2026, sinon l'exemption ne prendra pas effet. La documentation de Microsoft avertit qu'il s'agit d'une extension unique sans possibilite de renouvellement au-dela d'avril 2027.

# Verifier les parametres EWS actuels
Get-OrganizationConfig | Select-Object EwsEnabled, EwsAllowList

# Ajouter votre application a l'AllowList
Set-OrganizationConfig -EwsAllowList @{Add="your-app-client-id"}
Set-OrganizationConfig -EwsEnabled $true

Avantages : Aucune modification de code necessaire immediatement. Inconvenients : Ne fait que retarder le probleme de 6 mois. EWS est supprime definitivement le 1er avril 2027.

Chemin 3 : Utiliser une abstraction unifiee

Une abstraction independante du fournisseur gere le routage EWS et Graph en interne, de sorte que votre code ne change pas lorsque Microsoft retire un protocole. Nylas CLI se connecte a Exchange Online, Exchange on-premises, Gmail, Outlook, Yahoo, iCloud et IMAP via une seule interface. Les memes commandes fonctionnent pour les 6 fournisseurs sans logique specifique au protocole.

# Installer
brew install nylas/nylas-cli/nylas

# S'authentifier (gere OAuth, EWS, Graph en interne)
nylas auth config

# Lire les emails -- fonctionne que la boite soit
# Exchange Online (Graph), Exchange on-prem (EWS), ou Gmail
nylas email list --limit 10

# Rechercher
nylas email search "invoice" --limit 50

# Envoyer
nylas email send \
  --to "colleague@company.com" \
  --subject "Report" \
  --body "The report is ready: <report-download-link>"

Avantages : Pas de code specifique au protocole, pas d'enregistrement d'application Azure AD, fonctionne avec tous les fournisseurs, on-prem et cloud via une seule interface. Inconvenients : Dependance externe. Necessite une cle API Nylas.

Comparaison cote a cote

Les trois approches different en complexite d'authentification, couverture de fournisseurs et effort de migration. EWS supportait 3 methodes d'auth (NTLM, Kerberos, Basic), Graph API exige exclusivement OAuth 2.0, et Nylas CLI gere l'authentification via une seule commande de configuration. Le tableau ci-dessous compare les trois sur 7 aspects operationnels qui influent sur la planification de la migration.

Exchange hybride : le probleme du double code

Les environnements Exchange hybrides doivent maintenir deux chemins de code separes apres octobre 2026 : Microsoft Graph pour les boites aux lettres cloud et EWS pour Exchange Server on-premises. Microsoft Graph ne supporte pas Exchange Server on-premises, ce qui signifie que les organisations avec des deploiements partages ne peuvent pas se consolider sur une seule API Microsoft. Selon la documentation hybride de Microsoft, les configurations hybrides representent une part significative des deploiements Exchange en entreprise.

Cette separation a double protocole impose deux flux d'authentification (Azure AD OAuth pour Graph, NTLM ou Kerberos pour EWS on-prem), deux surfaces d'API, et deux ensembles de gestion d'erreurs dans la meme application. La plateforme Nylas gere ce routage en interne -- elle detecte si une boite aux lettres est cloud ou on-prem et utilise le protocole approprie sans modification de code.

Liste de verification de la migration

Une migration EWS complete touche l'authentification, la surface d'API, la gestion des erreurs et les tests pour tous les types de licences concernes. Microsoft recommande de commencer la migration au moins 3 mois avant la date limite d'octobre 2026 pour tenir compte de l'enregistrement d'application Azure AD, du consentement admin et des cycles de test. Les 6 etapes ci-dessous couvrent le processus de bout en bout, de l'audit a la mise en production.

1. Auditer votre utilisation d'EWS -- Executez l'analyseur de code EWS de Microsoft pour inventorier chaque appel EWS
2. Verifier les ecarts de parite -- Comparez vos operations EWS avec le tableau des ecarts fonctionnels ci-dessus
3. Enregistrer votre application avant aout 2026 -- Si vous avez besoin de plus de temps, ajoutez votre application a l'AllowList
4. Tester d'abord avec les licences F1/F3 -- Elles ont ete bloquees en mars 2026, elles sont donc deja sur le nouveau comportement
5. Planifier pour l'hybride -- Si vous avez un Exchange on-premises, decidez comment gerer la separation a double protocole
6. Surveiller les mises a jour de Microsoft -- Les ecarts de parite fonctionnelle se comblent chaque trimestre

Questions frequemment posees

La depreciation d'EWS souleve des questions sur les delais, l'impact on-premises, les ecarts fonctionnels et les alternatives de migration. Voici les 4 questions les plus courantes des developpeurs qui planifient leur migration, basees sur les sujets abordes dans les forums TechCommunity de Microsoft et la documentation officielle de depreciation.

Quand EWS sera-t-il retire pour Exchange Online ?

Microsoft bloque les requetes EWS des applications non-Microsoft a partir du 1er octobre 2026. Les tenants qui configurent un AppID AllowList avant aout 2026 obtiennent une exemption temporaire. Tout acces EWS est supprime definitivement le 1er avril 2027.

EWS est-il deprecie pour Exchange Server on-premises ?

Non. EWS reste entierement supporte pour Exchange Server 2016 et 2019. La depreciation ne concerne que Exchange Online (Microsoft 365).

Quelles fonctionnalites EWS manquent dans Graph API ?

En date d'avril 2026, Graph API ne dispose pas de l'acces aux boites aux lettres d'archive, du CRUD des dossiers publics, de l'import/export de boites aux lettres, et du support complet des requetes delta pour les evenements recurrents. Microsoft comble les ecarts chaque trimestre mais n'a pas fixe de date pour une parite complete.

Puis-je eviter completement la migration ?

Oui, si vous utilisez une couche d'abstraction. La plateforme Nylas se connecte a Exchange Online, Exchange on-premises et 4 autres fournisseurs via une seule interface. Les depreciations cote fournisseur ne necessitent pas de modifications de code de votre cote.

Prochaines etapes

Apres avoir planifie votre chemin de migration EWS, les guides ci-dessous couvrent des operations Exchange specifiques via le Nylas CLI. Chaque guide inclut des commandes testees, un depannage specifique au fournisseur, et des exemples de code pour les 6 fournisseurs supportes.

• Liste de verification du retrait EWS -- inventoriez les scripts a risque et executez le test de verification Exchange en 2 commandes
• Lister les emails Exchange depuis le CLI -- lisez et recherchez dans les boites Exchange sans EWS ni Graph
• Gerer le calendrier Exchange depuis le CLI -- creez, mettez a jour et supprimez des evenements
• Remplacer Send-MgUserMessage -- migrez depuis les cmdlets Graph PowerShell
• Gerer les emails Office 365 depuis PowerShell -- lisez, recherchez et organisez votre boite M365
• Envoyer un email depuis le terminal -- le guide d'envoi d'email multi-fournisseurs
• Reference complete des commandes -- chaque flag et sous-commande documentes