Dépréciation d’EWS et signatures mail : ce qui casse vraiment

Exchange Web Services est désactivé par étapes entre octobre 2026 et avril 2027. Si votre outil de signature mail en dépend, il cessera de fonctionner à un moment donné dans cette fenêtre — et Microsoft Graph, le remplaçant recommandé, ne sait pas du tout gérer les signatures.

En bref : EWS n’est pas coupé en un seul jour. Microsoft commence à le désactiver partout en octobre 2026 et achève l’arrêt en avril 2027. Les éditeurs de signatures qui reposent sur EWS n’ont aucune voie de migration équivalente, car Graph n’a jamais pris en charge les signatures et ce n’est pas prévu. Les remplaçants réalistes sont un complément Outlook, une règle de flux de messagerie ou un relais de messagerie sortant — et ils ne sont pas équivalents.

Le calendrier, sans approximation

Une bonne partie des contenus qui circulent en ce moment sur le sujet affirme que tout casse le 1er octobre 2026. Ce n’est pas ce que dit la documentation de Microsoft, et la différence compte si vous planifiez une migration.

Le mécanisme est un paramètre de locataire appelé EWSEnabled. La plupart des locataires ne l’ont jamais défini : il reste donc à Null. Quand le déploiement atteint un locataire, Null devient False, et toutes les applications EWS de ce locataire cessent de fonctionner d’un coup. Comme le déploiement est progressif et non simultané, deux organisations avec le même abonnement peuvent perdre EWS à plusieurs mois d’intervalle.

C’est un sursis, pas une solution. Cela maintient une application précise en vie pendant la période de déploiement progressif, mais ne survit pas à avril 2027.

Pourquoi Graph ne règle pas le problème

Les recommandations de Microsoft pour migrer depuis EWS sont cohérentes et raisonnables : passer à Microsoft Graph. Pour les calendriers, les contacts, les e-mails et la plupart des opérations sur les boîtes aux lettres, il existe des correspondances directes, et Microsoft publie les équivalences opération par opération.

Les signatures sont l’exception, et il vaut la peine d’être précis sur la raison.

Graph n’a jamais exposé d’API pour lire ou écrire les signatures Outlook. Ce n’est pas une lacune en attente d’une préversion. Microsoft publie une feuille de route des fonctionnalités d’EWS que Graph ne couvre pas encore — importation et exportation de boîtes aux lettres, dossiers publics, importation/exportation des groupes Microsoft 365, archive sur place, delta des événements périodiques, pense-bêtes, configuration utilisateur et un ensemble d’API d’administration. La gestion des signatures ne figure pas sur cette liste, car les signatures n’ont jamais été un objet de boîte aux lettres à part entière dans EWS, comme l’étaient les calendriers. Elles vivent avec le client Outlook.

La conséquence pratique : un éditeur de signatures qui migre d’EWS vers Graph ne porte pas une intégration. Il choisit un mécanisme de déploiement entièrement différent, avec une autre couverture et d’autres modes de défaillance. Quand on vous dit qu’un outil est « prêt pour Graph », la question à poser est de savoir vers lequel des mécanismes ci-dessous il est réellement passé.

Toutes les options restantes, comparées honnêtement

Il existe quatre façons d’ajouter une signature aux e-mails sortants de Microsoft 365 après EWS. Aucune n’est strictement meilleure que les autres : chacune fait des compromis différents.

Ce que recouvre vraiment « visible dans les Éléments envoyés »

Les règles de flux de messagerie et les relais apposent tous deux la signature après que le message a quitté le client. L’utilisateur rédige sans la voir, et la copie dans ses Éléments envoyés ne la contient pas. Cela semble cosmétique et ne l’est pas : c’est la source de tickets de support la plus fréquente dans les déploiements de signatures, car les utilisateurs ne peuvent pas savoir si cela a fonctionné. Toute évaluation qui fait l’impasse là-dessus aboutira à un outil dont vos collaborateurs se méfient.

Les compléments et les approches côté client affichent la signature dans la fenêtre de rédaction, et c’est pourquoi ils perdurent malgré le coût de la matrice de clients.

Ce qu’implique réellement le routage sortant

Le relais est l’option la plus souvent mal comprise, généralement dans le sens où il paraît plus intrusif qu’il ne l’est.

L’insertion de la signature ne nécessite que le routage sortant. Dans Microsoft 365, c’est un connecteur sortant Exchange Online ; dans Google Workspace, c’est le paramètre de relais SMTP ou de routage. Ni l’un ni l’autre ne touche aux enregistrements MX. La réception n’est pas affectée. Les deux sont réversibles en quelques minutes depuis une console d’administration. C’est déjà ainsi que fonctionnent Exclaimer et Opensense, et c’est un changement plus modeste que ne le laisse entendre la formule « faire passer vos e-mails par un tiers ».

Le vrai coût est ailleurs, et mérite d’être dit clairement : vous acceptez une dépendance dans votre flux de messagerie. Si l’opérateur du relais tombe en panne, votre organisation ne peut plus envoyer d’e-mails. C’est un véritable engagement opérationnel du côté de l’éditeur — une astreinte 24 h/24, 7 j/7, pas une file d’attente de support — et c’est une question légitime à poser à tout éditeur qui le propose. C’est aussi pourquoi nous préférerions que vous ne commenciez pas par là.

Ce que nous suggérons vraiment

Si c’est EWS qui casse chez vous, la tentation est de trouver le remplaçant le plus proche et de passer à autre chose. Nous vous le déconseillerions, pour deux raisons.

D’abord, le déploiement par étapes vous laisse plus de marge que ne le suggère le discours sur le 1er octobre. Si votre locataire n’a pas encore été atteint, vous avez le temps d’évaluer correctement plutôt que de migrer deux fois.

Ensuite, les outils basés sur EWS étaient généralement choisis parce qu’ils écrivaient les signatures sans toucher au flux de messagerie. Si vous les remplacez par un relais, vous changez sensiblement votre profil de risque, et vous devriez le faire délibérément plutôt que dans l’urgence. Un relais est la bonne réponse quand il vous faut un verrouillage sur tous les clients, mobile compris, réponses et transferts inclus. C’est la mauvaise réponse si ce qu’il vous fallait réellement, c’était des signatures exactes et à jour.

À distinguer avant de choisir : le verrouillage (personne ne peut envoyer d’e-mail non conforme) et l’exactitude (les signatures reflètent les fonctions actuelles, le logo actuel, les mentions légales actuelles). La plupart des organisations décrivent un problème de verrouillage et, quand on examine les signatures déployées, ont un problème d’exactitude. Les réponses diffèrent, et celle au problème d’exactitude ne nécessite rien dans le flux de messagerie.

Comment vérifier si votre locataire est concerné

Trois étapes, dont aucune ne nécessite d’éditeur. Suivez-les dans cet ordre, car la première vous indique de combien de temps vous disposez et la deuxième ce que vous casseriez.

1. Lire votre paramètre actuel

Dans Exchange Online PowerShell :

Get-OrganizationConfig | Format-List EwsEnabled,
    EwsApplicationAccessPolicy, EwsAllowList, EwsBlockList
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

La liste d’autorisation n’est renvoyée qu’avec ce second commutateur : sans lui, la propriété apparaît vide même quand une liste existe.

EwsEnabled a trois états, et c’est le troisième qui piège les gens :

La plupart des locataires n’y ont jamais touché : la plupart affichent donc $null. C’est sur ce groupe qu’agit le déploiement d’octobre.

2. Identifier ce qui utilise réellement EWS

Microsoft publie cette information par locataire. Dans le centre d’administration Microsoft 365 : Rapports → Utilisation → Exchange → l’onglet Utilisation d’EWS. Il vous donne, par application, les actions SOAP appelées, le volume d’appels et la date de la dernière activité, et il s’exporte en CSV.

Deux points de ce rapport déterminent si vous obtenez une réponse juste :

• L’utilisation est agrégée chaque semaine, et non chaque jour, et peut mettre jusqu’à 10 jours à apparaître. Une fenêtre de 7 jours peut donc ne rien montrer alors qu’une application est activement utilisée.
• Filtrez sur 90 jours, pas sur 7 ou 30. Tout ce qui tourne une fois par mois — exports de fin de trimestre, tâches d’archivage, synchronisation de signatures qui ne se déclenche qu’à un changement dans l’annuaire — sera invisible sur une fenêtre courte et cassera quand même en octobre.

Le rapport identifie les applications par leur ID d’application Entra plutôt que par leur nom. Retrouvez-les sous Entra ID → Applications d’entreprise dans le centre d’administration Microsoft Entra ; Microsoft publie aussi la liste des ID de ses propres applications. Attendez-vous à en trouver quelques-unes qui appartiennent à Microsoft, et ne les ignorez pas : Microsoft n’exempte pas ses propres applications, donc celle qui apparaît encore (Outlook classique pour Mac, en général) doit elle aussi avoir son ID sur votre liste.

3. Si quelque chose doit garder EWS jusqu’en avril 2027, l’ajouter à la liste d’autorisation

Set-OrganizationConfig -EwsAllowedAppIDs "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,11111111-2222-3333-4444-555555555555"
# a day later, once the list has reached every server:
Set-OrganizationConfig -EwsEnabled $true

Écrivez d’abord la liste et attendez : les modifications de la liste mettent environ 24 heures à s’appliquer, celles d’EWSEnabled environ une heure. La commande remplace toute la liste : incluez donc ce qui y figure déjà. Une liste que vous écrivez vous-même n’est jamais écrasée ; celle que Microsoft écrit pour vous provient de 60 jours d’utilisation et hérite de tous les angles morts du point précédent.

Puis poser une question à votre éditeur de signatures

Si un outil de signature apparaît dans votre rapport d’utilisation, la question utile n’est pas « êtes-vous prêts pour la dépréciation ? » — tout le monde répond oui. C’est : vers quel mécanisme passez-vous ? Graph ne sait pas gérer les signatures : les réponses honnêtes sont donc un complément Office.js, une règle de flux de messagerie ou un relais sortant, chacun avec les compromis du tableau ci-dessus. Un éditeur qui répond « nous migrons vers Graph » sans nommer l’un d’eux n’a pas répondu à la question.

Si vous êtes sur Google Workspace

Rien de tout cela ne s’applique. EWS est un protocole Exchange : Google Workspace n’est pas du tout concerné par la dépréciation. Les limites propres à Google sont réelles mais d’une tout autre nature, et l’API Gmail prend en charge directement la gestion des signatures comme propriété côté serveur du profil — ce qui atteint le mobile sans rien installer. Nous l’avons décrit dans un article à part.