Le 23 septembre 2026, Microsoft a annoncé le retrait d’Azure Communication Services (ACS) comme offre autonome. Dans son guide officiel de retrait et de changements incompatibles, ACS Email figure explicitement parmi les services retirés le 30 septembre 2028. Pour les applications qui envoient confirmations, factures ou alertes à des clients, il s’agit d’une vraie migration de plateforme, et non d’une simple mise à jour de SDK.
Le risque serait de choisir trop vite « un autre SMTP ». ACS Email associe envoi, domaines vérifiés, quotas, événements de livraison et journaux Azure. Une application peut dépendre autant de ses événements de rebond que de l’API d’envoi. Il faut donc reconstruire la chaîne complète du message : déclenchement métier, file d’attente, fournisseur, authentification du domaine, retour de livraison et traitement des échecs.
À retenir : ACS Email reste opérationnel pendant la transition, mais Microsoft recommande de migrer avant le 30 septembre 2028. High Volume Email de Microsoft 365 cible l’interne ; Exchange Online cible d’abord les échanges des utilisateurs. Pour des emails transactionnels externes, évaluez un fournisseur d’envoi applicatif selon votre flux réel.
1. L’annonce : retrait d’ACS Email ou changement d’ACS ?
Microsoft emploie deux catégories distinctes. Retrait signifie qu’un produit ne sera plus disponible après la date annoncée. Breaking change signifie qu’un composant reste disponible, mais que l’application ou son usage doit évoluer vers un scénario pris en charge. Le tableau Microsoft classe ACS Email, SMS, Chat, Rooms, Job Router et d’autres éléments dans les retraits ; les SDK voix/vidéo, Call Automation, diagnostics et enregistrement relèvent plutôt des changements incompatibles. Cette seconde famille est orientée vers des scénarios liés à Teams. Elle ne prolonge pas ACS Email.
Le 30 septembre 2028 est la date de fin annoncée pour les services retirés. Avant cette échéance, les ressources existantes continuent de fonctionner et Microsoft maintient le support selon les conditions applicables, en privilégiant corrections de sécurité, stabilité et incidents. La documentation indique que les domaines email vérifiés restent utilisables durant cette période ; les demandes d’augmentation de quota peuvent encore être examinées au cas par cas. Ce n’est toutefois pas une promesse de nouvelles fonctions. Après la date de retrait, les appels API et SDK dépendant d’un service retiré peuvent échouer.
Le guide Microsoft est mis à jour au fil de la transition : vérifiez-le au moment de planifier un nouvel onboarding ou une extension. Pour une architecture créée aujourd’hui, deux années de fonctionnement restant à ACS Email ne justifient généralement pas d’y introduire une nouvelle dépendance durable. Pour un système en production, en revanche, une migration contrôlée vaut mieux qu’un basculement précipité.
2. Quel périmètre applicatif faut-il inventorier ?
Cherchez tous les usages de la ressource Communication Services et de la ressource Email Communication Service liée aux domaines d’envoi. Les envois peuvent provenir de REST, des SDK ou de SMTP. Une équipe qui ne recherche que des appels SendAsync laissera de côté les logiciels métier configurés avec un hôte SMTP. Le panorama Microsoft d’ACS Email et sa documentation SMTP décrivent ces voies.
L’inventaire doit associer chaque flux à une application et à un propriétaire : confirmation de commande, réinitialisation de mot de passe, notification de rendez-vous, facture, alerte d’exploitation, rapport périodique ou campagne. Distinguez interne au tenant, externe individuel et envoi de masse. Mesurez le volume quotidien, la pointe horaire, la saisonnalité, la criticité et le délai maximal de remise acceptable. Cent messages par jour dont certains sont des codes de connexion urgents ne se conçoivent pas comme cent mille rapports nocturnes.
Recensez aussi les domaines et sous-domaines, expéditeurs From, adresses de réponse, modèles de message, pièces jointes, identifiants techniques, secrets et méthodes de rotation. Notez les règles de confidentialité et de résidence des données. Une API simple à remplacer peut cacher une dépendance forte à un domaine, à une clé Azure Key Vault ou à une journalisation centralisée dans Azure Monitor.
Le chemin retour compte autant que l’envoi
ACS peut publier des événements de livraison via Event Grid, avec des états tels que Delivered, Bounced, Suppressed ou Failed. Les journaux email Microsoft détaillent les statuts au niveau du message et du destinataire. Si un ERP désactive automatiquement une adresse après un rebond permanent, ce traitement doit migrer avec l’envoi. Delivered indique une remise au serveur destinataire, pas une garantie de présence dans la boîte de réception.
Cartographiez les consommateurs d’événements : webhooks, Functions, Event Hubs, tableaux de bord, alertes et suppression des adresses invalides. Conservez les identifiants de corrélation entre événement métier, demande d’envoi et statut final. Sans cette carte, un nouveau fournisseur peut accepter les messages tout en faisant disparaître le diagnostic et le nettoyage de la base de destinataires.
3. Les options Microsoft : HVE et Exchange Online ont un périmètre précis
Le guide cite Microsoft 365 High Volume Email (HVE) pour des envois internes au tenant, par exemple des notifications de systèmes à des employés. C’est une option à étudier lorsque tous les destinataires sont internes et que le modèle SMTP et les conditions de HVE conviennent. Ce n’est pas une réponse au besoin d’envoyer des confirmations à des clients externes ; l’article Microsoft Learn sur HVE en précise le périmètre.
Exchange Online peut servir certains flux applicatifs limités liés à une boîte métier et à des échanges de personnes. Il sait envoyer par SMTP, relais ou Microsoft Graph selon le montage, mais ses licences, contrôles anti abus et limites de destinataires restent ceux d’un service de messagerie collaborative. Le TERRL Exchange Online compte les destinataires externes au niveau du tenant. Une confirmation client de faible volume peut être envisageable ; déplacer toutes les notifications et campagnes ACS vers plusieurs boîtes Microsoft 365 n’est pas une stratégie de remplacement.
Ne confondez pas SMTP relay dans Microsoft 365 avec un ESP externe : si le message sort par Exchange Online, les limites applicables continuent de jouer. Notre analyse de l’architecture marketing sous Microsoft 365 explique pourquoi une boîte ne remplace pas un moteur de diffusion. De plus, déplacer un flux vers Exchange Online change la responsabilité du suivi des rebonds et des événements, pas seulement les identifiants de connexion.
4. Fournisseurs transactionnels : que comparer ?
Pour un flux application vers destinataire externe, une plateforme transactionnelle est souvent le point de départ. Microsoft cite des partenaires de sa place de marché, notamment Infobip et Telesign, mais ce tableau n’est pas une liste exhaustive ni une obligation d’achat. Twilio SendGrid, Brevo, Mailgun et Amazon SES sont également des pistes à évaluer. Ce sont des produits et contrats différents : une mention de marque ne garantit ni la disponibilité d’une région, ni un quota, ni une fonctionnalité dans votre offre.
| Option | Interface à étudier | Retours de livraison | Point d’attention architectural |
|---|---|---|---|
| SendGrid | API HTTP et SMTP | Event Webhook | Plan, domaine, IP et rétention des événements à valider |
| Brevo | API transactionnelle et SMTP | Webhooks transactionnels | Séparer transactionnel et marketing ; vérifier offre et région |
| Mailgun | API HTTP et SMTP | Événements / webhooks à tester | Domaine et région de traitement à contractualiser |
| Amazon SES | API AWS et SMTP | Publication d’événements via configuration sets | Gestion AWS des identités, quotas, rôles et destinations |
| Partenaire Microsoft Marketplace | Selon fournisseur | Selon fournisseur | Contrat, support, données et éventuelle intégration Azure |
| Exchange Online | Graph, SMTP ou relais selon scénario | Traces de messagerie, NDR | Boîtes et limites tenant ; pas d’ESP transactionnel général |
Les docs SendGrid, Brevo, Mailgun et Amazon SES confirment les principales interfaces. Le tableau décrit des familles de capacités, pas une garantie pour tous les plans commerciaux. Faites valider chaque point dans l’offre envisagée, en particulier les webhooks, les limites et la résidence des données.
API ou SMTP ?
L’API offre généralement des identifiants de message, des catégories et des erreurs structurées qui facilitent la corrélation. Elle exige de remplacer le client ACS ou son SDK et de gérer l’authentification du nouveau fournisseur. SMTP peut accélérer la migration d’une application ancienne qui n’expose qu’un serveur et des identifiants, mais l’acceptation SMTP n’est pas une preuve de remise finale. Dans les deux cas, les statuts asynchrones doivent rejoindre le système métier.
Évitez d’enfermer directement chaque application dans un nouveau SDK. Un adaptateur interne d’envoi peut définir un contrat stable : messageId, type de notification, domaine, destinataire, gabarit, priorité et clé d’idempotence. Le connecteur du fournisseur devient remplaçable ; la politique de reprise, de suppression et de traçabilité reste sous votre contrôle.
Réputation, IP et authentification
Une IP dédiée n’est pas automatiquement meilleure qu’un pool partagé. Elle donne davantage de contrôle et de responsabilité sur la réputation, avec un besoin de chauffe et de volume régulier. Un faible volume irrégulier peut mieux fonctionner sur une infrastructure partagée bien gérée. Vérifiez si l’option existe dans le plan, qui gère la montée en charge et si une migration d’IP est possible. Ne publiez pas d’hypothèse de débit fondée sur le tarif affiché.
Pour chaque domaine d’envoi, préparez DKIM, un SPF qui autorise les services réellement émetteurs et DMARC avec contrôle de l’alignement. L’adresse visible From, le domaine d= de DKIM et le domaine d’enveloppe utilisé par SPF peuvent différer. Il faut tester des messages réels après bascule ; recopier les DNS ACS à l’identique vers un nouvel ESP ne suffit pas. Notre guide SPF, DKIM et DMARC détaille ces contrôles.
Rebonds, webhooks et observabilité
Comparez les catégories d’événements plutôt que le seul mot « webhook » : accepté, remis au serveur, différé, rejeté, rebond permanent, plainte, désabonnement et suppression. Déterminez ce qui déclenche une nouvelle tentative, un incident ou l’arrêt définitif des envois à une adresse. Un webhook doit être authentifié, dédupliqué et rejoué en cas de panne ; ses données personnelles doivent avoir une durée de conservation définie.
Intégrez les événements dans votre observabilité Azure si l’exploitation reste sur Azure : ingestion dans Event Hubs, Function ou autre composant adapté, puis métriques et alertes. Mesurez le temps entre événement métier et remise, pas seulement le nombre de requêtes API réussies. Prévoyez un identifiant commun qui permet au support de retrouver le parcours d’un message sans afficher inutilement son contenu.
Volumétrie et coûts
Demandez un quota de départ et une méthode de montée en charge, puis comparez la pointe soutenue, la file d’attente et la reprise après panne. Les campagnes et notifications transactionnelles devraient souvent utiliser des domaines ou sous-domaines séparés pour réduire les interférences de réputation. Vérifiez les limites par seconde, jour, domaine et compte dans le contrat choisi ; elles changent selon fournisseur et niveau de service.
Le coût total comprend envoi, IP éventuelle, stockage des événements, transfert de données, support, dépassements, outils de conformité et temps d’intégration. Un prix par email isolé masque souvent la charge de reconstruction de la télémétrie. Les tarifs évoluent trop vite pour figurer ici comme chiffres intemporels : établissez un comparatif daté à partir des offres réelles et de votre courbe de volume.
5. Une architecture de migration qui résiste aux incidents
Le flux cible peut rester sur Azure sans dépendre d’ACS Email : application → file durable → worker d’envoi → adaptateur ESP → destinataire, avec webhook d’événements → traitement des statuts → supervision. Azure Service Bus, par exemple, peut héberger la file si l’équipe l’exploite déjà ; le choix précis dépend de l’application. Cette séparation absorbe les pics, permet de ralentir le débit et protège le traitement métier d’une indisponibilité du fournisseur.
Définissez des tentatives bornées pour erreurs temporaires, une file d’échec pour revue et une clé d’idempotence lorsque l’application peut rejouer le même événement. Sinon, une panne entre l’acceptation fournisseur et l’enregistrement local peut produire deux confirmations de commande. Séparez les erreurs de configuration permanentes des erreurs temporaires : répéter indéfiniment un rejet d’authentification aggrave l’incident.
La migration des événements est aussi un chantier de données. ACS utilisait Event Grid et Azure Monitor ; le nouvel ESP peut pousser des webhooks avec d’autres catégories et identifiants. Normalisez les statuts vers un modèle interne, conservez l’événement brut pour le diagnostic selon votre politique de rétention, et vérifiez la signature du webhook lorsqu’elle existe. Un statut « envoyé » n’est pas équivalent à « accepté par le serveur destinataire ».
6. Plan de bascule recommandé
- Inventorier ressources ACS, domaines, applications, flux SMTP/API, événements et propriétaires métier. Utiliser les rapports Azure Advisor et les coûts comme points de départ, puis vérifier dans le code et les configurations.
- Classer les flux : interne, transactionnel externe, alerte critique, campagne. Choisir HVE seulement pour l’interne adapté ; réserver Exchange Online aux cas compatibles avec ses limites.
- Comparer deux ou trois ESP sur l’API ou SMTP, les webhooks, les quotas, la région, les contrats et le coût total. Tester les fonctions dans le plan réellement proposé.
- Préparer les domaines : sous-domaine transactionnel si pertinent, DNS DKIM/SPF/DMARC, adresses de réponse, politique de suppression et chauffe de réputation.
- Construire le connecteur et le chemin de retour des événements. Journaliser les identifiants métier et fournisseur sans exposer de secrets ni de contenu personnel superflu.
- Tester codes de connexion, confirmations, factures, alertes, pièces jointes et rebonds. Simuler quota atteint, panne API, retard de webhook et doublon.
- Basculer progressivement par application ou domaine ; garder ACS comme voie de retour temporaire tant que le plan le permet. Comparer taux de remise, latence et plaintes sur des fenêtres significatives.
- Retirer ACS une fois les flux et dépendances de télémétrie supprimés. Documenter le propriétaire du nouveau service et le calendrier de renouvellement du contrat.
Une bascule « en double » doit être conçue avec prudence : envoyer le même message depuis deux fournisseurs à un vrai client crée des doublons. Préférez des destinataires de test, des cohortes exclusives ou des événements de comparaison sans seconde livraison. Vérifiez aussi les liens de suivi et l’adresse de réponse, qui peuvent être réécrits par le nouvel ESP.
Conclusion
La fin d’Azure Communication Services Email est annoncée pour le 30 septembre 2028. Le délai donne de la marge pour choisir une architecture pérenne, mais ACS Email est bien dans la catégorie retrait, contrairement à certains composants voix ou vidéo qui connaîtront des changements incompatibles. Pour les emails transactionnels externes, la bonne alternative est celle qui restitue l’envoi, les événements, la réputation et l’exploitation au niveau requis par l’application.
Ne remplacez pas mécaniquement ACS par Exchange Online : qualifiez d’abord les destinataires, les volumes, les délais et la gestion des rebonds. Un audit de messagerie et de délivrabilité Dharmail peut aider à documenter les domaines et les flux avant de choisir le fournisseur.
Sources
- Microsoft Learn, « Retirement and breaking changes guide for Azure Communication Services ».
- Microsoft Learn, « Overview of Azure Communication Services email ».
- Microsoft Learn, « Azure Communication Services – Email events » et « Email logs ».
- Microsoft Learn, « Manage High Volume Email for Microsoft 365 ».
- Documentations fournisseurs : SendGrid, Brevo, Mailgun, Amazon SES.