La préparation d’une migration SMTP AUTH doit partir du calendrier officiel révisé et des connexions réellement utilisées par vos applications. Les anciennes annonces ne suffisent pas. Un formulaire web, un logiciel de gestion et une boîte professionnelle peuvent dépendre de parcours différents.
Le sujet concerne ici l’authentification de soumission SMTP dans Exchange Online. Il ne signifie pas que le protocole SMTP disparaît, ni que toutes les newsletters doivent changer d’outil.
Le calendrier annoncé par Microsoft
L’annonce du 27 janvier 2026 remplace le précédent calendrier.
| Étape annoncée | Ce que Microsoft prévoit |
|---|---|
| Jusqu’à décembre 2026 | Comportement de SMTP AUTH Basic Authentication inchangé. |
| Fin décembre 2026 | Désactivation par défaut pour les locataires existants, avec possibilité administrative de réactivation. |
| Nouveaux locataires après décembre | Basic Authentication indisponible par défaut ; OAuth est la méthode prise en charge. |
| Second semestre 2027 | Annonce de la date de suppression définitive. |
Ces étapes sont des prévisions officielles à suivre. La dernière ligne annonce une future communication : elle ne fixe pas une suppression définitive au second semestre 2027.
Identifier les systèmes concernés
Commencez par les applications qui envoient via votre environnement Microsoft : site, gestion, notifications internes ou équipements. Demandez au responsable de chaque système sa méthode de connexion.
Ne déduisez pas cette méthode du simple fait qu’une adresse Microsoft apparaît dans le champ d’expéditeur. Une application peut utiliser un autre service de transport. À l’inverse, un outil ancien peut encore dépendre d’une connexion que personne n’a documentée.
Préparez une fiche avec le nom du système, son usage, le responsable, le fournisseur, le parcours d’envoi et les contraintes de mise à jour. Les cas inconnus doivent rester visibles jusqu’à leur clarification.
Comprendre l’objectif d’OAuth
Microsoft distingue l’authentification basique et l’authentification moderne fondée sur OAuth 2.0. Sa documentation Exchange Online décrit notamment les limites de durée et de portée des jetons.
Pour une équipe métier, l’enjeu est d’obtenir une méthode prise en charge par son application et correctement configurée. Il ne s’agit pas simplement de remplacer un mot de passe par une autre chaîne dans un écran.
Demandez au prestataire quel scénario il implémente, quelles autorisations sont nécessaires et comment les accès seront maintenus. Gardez les secrets techniques dans les outils prévus à cet effet, pas dans le compte rendu partagé de la migration.
Vérifier les options de chaque application
Microsoft publie un guide d’authentification IMAP, POP et SMTP par OAuth. Les modalités dépendent du scénario et des capacités du logiciel.
Pour une application maintenue par un éditeur, demandez une confirmation de compatibilité et la procédure de mise à jour. Pour un développement spécifique, faites décrire les modifications, les responsabilités et les tests.
Si le système ne peut pas évoluer, examinez avec le prestataire les alternatives adaptées. Le choix dépendra du besoin et de l’architecture ; il ne faut pas transformer une solution évoquée pour un cas en recommandation générale pour tous les envois.
Exemple fictif : le formulaire d’un cabinet
Imaginons un petit cabinet qui reçoit des demandes de rendez-vous depuis son site. Le formulaire envoie une confirmation par une configuration installée plusieurs années auparavant.
L’équipe ne commence pas par changer l’adresse affichée. Elle demande au prestataire comment la connexion est authentifiée, où le réglage est administré et quelle version du composant est utilisée.
Le prestataire propose une mise à jour et un parcours de test. Le cabinet vérifie la confirmation, la réception interne et les erreurs éventuelles. Ce cas est fictif ; il montre l’intérêt d’un inventaire précis avant une intervention.
Préparer une migration vérifiable
Choisissez un environnement de test lorsque votre application le permet. Définissez les messages à vérifier et les personnes qui pourront constater les résultats.
Le test doit couvrir l’envoi réussi, mais aussi un échec de connexion ou une autorisation insuffisante. Demandez comment l’application rend ces problèmes visibles et qui reçoit l’information.
Conservez les identifiants techniques nécessaires pour rechercher les essais. Si un résultat est incertain, il faut pouvoir distinguer une demande jamais acceptée d’une demande traitée dont la réponse s’est perdue.
Coordonner les équipes et les dates
Attribuez un responsable à chaque application, puis une personne chargée de suivre l’ensemble. Une date générale de migration sans liste de systèmes peut laisser des usages secondaires de côté.
Prévoyez également le support après intervention. Une confirmation d’achat ou de rendez-vous peut être indispensable au parcours client ; son suivi ne doit pas dépendre de la disponibilité fortuite du développeur qui a fait la modification.
Au moment de préparer l’intervention, vérifiez à nouveau l’annonce officielle et la documentation applicable au service. Les calendriers peuvent être révisés, comme Microsoft l’a déjà fait.
Clore le projet avec une preuve de fonctionnement
Un projet de migration est terminé lorsque les parcours concernés ont été vérifiés et que leurs responsabilités sont documentées. La mention « OAuth activé » ne décrit pas à elle seule tout le résultat.
Rassemblez le fonctionnement retenu, les tests, les accès administratifs nécessaires et la procédure de diagnostic. Retirez les anciennes dépendances selon le plan validé par le prestataire.
Votre équipe pourra alors retrouver le bon interlocuteur et la bonne information lors d’une évolution future, au lieu de recommencer l’inventaire depuis le début.