Si vous souhaitez que votre site WordPress envoi les messages de ses formulaires de contact, ses notifications ou ses e-mails système avec une adresse professionnelle hébergée chez Microsoft 365, installer un plugin SMTP ne suffira pas. Microsoft requiert désormais OAuth 2.0 et une application Entra afin de connecter WordPress à une boîte Exchange sans lui communiquer le mot de passe de l'utilisateur.
C'est beaucoup plus propre en matière de sécurité, mais la première configuration est complexe car il faut naviguer entre WordPress, Microsoft 365, Exchange Online et Microsoft Entra, créer une application, récupérer plusieurs identifiants puis faire autoriser cette application par le propriétaire de la boîte Exchange.
Après avoir testé plusieurs solutions, j'ai finalement retenu FluentSMTP.
Pourquoi FluentSMTP ?
Les plugins SMTP pour WordPress ne manquent pas. Parmi les plus connus, on trouve notamment WP Mail SMTP et Post SMTP. Ils fonctionnent très bien, mais leur prise en charge de Microsoft 365 avec OAuth est généralement réservée à leurs offres payantes. C'est précisément ce qui m'a conduit vers FluentSMTP.
FluentSMTP apporte également les journaux d'envoi, les tests d'e-mails et la possibilité de gérer plusieurs connexions. Vous pouvez télécharger FluentSMTP depuis son site officiel : FluentSMTP Il est également disponible directement depuis le répertoire WordPress.org : FluentSMTP sur WordPress.org
Avec FluentSMTP, la connexion Microsoft / Outlook / Office 365 avec OAuth est disponible gratuitement. Il n'existe pas de version Pro destinée à débloquer cette fonctionnalité. Pour un site qui dispose déjà d'une boîte Exchange Online payée par l'entreprise, je trouve difficilement justifiable de souscrire en plus un abonnement annuel à un plugin WordPress uniquement pour permettre au site d'utiliser cette boîte.
WordPress.org ou le site de FluentSMTP ?
Il n'est pas nécessaire de télécharger FluentSMTP depuis le site de l'éditeur pour disposer d'une version plus récente, la version disponible sur WordPress.org est bien maintenue. Je préfère néanmoins donner ici le lien vers le site de FluentSMTP, parce qu'on y retrouve directement le plugin et surtout sa documentation consacrée à Microsoft 365 qui m'a d'ailleurs été très utile pour réaliser la configuration : Configurer FluentSMTP avec Microsoft Outlook / Office 365
L'installation directement depuis Extensions > Ajouter une extension dans WordPress reste donc parfaitement valable.
Avant de commencer : comprendre les différents centres d'administration Microsoft
Une partie de la difficulté ne vient finalement pas de FluentSMTP, elle vient de l'organisation de Microsoft 365 : lorsqu'on découvre Microsoft 365 Business, on pourrait s'attendre à trouver un seul centre d'administration. En réalité, Microsoft répartit les réglages entre plusieurs interfaces.
Le Centre d'administration Microsoft 365 permet notamment de gérer les utilisateurs, les licences et les abonnements.
Le Centre d'administration Exchange concerne la messagerie : boîtes aux lettres, alias, paramètres Exchange, règles de transport, etc.
Microsoft Entra, anciennement Azure Active Directory, gère les identités, les utilisateurs, les rôles et les applications enregistrées.
Enfin, le tenant Microsoft 365 est l'organisation elle-même. Les utilisateurs, les domaines, Exchange et les applications Entra appartiennent à ce tenant.
Quand on débute, on se demande sans arrêt « dans quel centre d'administration est ce réglage ? ». Ce qui m'a fait gagner beaucoup de temps, c'est d'utiliser les barres de recherche présentes dans les différents centres d'administration Microsoft. Elles sont souvent plus efficaces que de parcourir les menus, d'autant que Microsoft modifie régulièrement ses interfaces et que les traductions françaises ne correspondent pas toujours exactement aux termes employés dans les tutoriels anglophones.
Pour FluentSMTP, nous allons surtout utiliser Microsoft Entra.
Installer FluentSMTP
Dans WordPress, installer et activer FluentSMTP. Aller ensuite dans : Réglages > FluentSMTP Lors de la création de la connexion, choisir le fournisseur : Microsoft / Outlook / Office 365. Le nom exact peut légèrement varier suivant la version du plugin.
FluentSMTP demande alors plusieurs informations :
- l'adresse d'expédition ;
- l'Application Client ID ;
- le Client Secret ;
- éventuellement le Directory Tenant ID ;
- et une App Callback URL.
Cette dernière est particulièrement importante, elle ressemble par exemple à ceci :
https://www.monsite.fr/wp-json/fluent-smtp/outlook_callback
Il faut la copier exactement. Nous allons maintenant déclarer cette adresse chez Microsoft.
Créer l'application FluentSMTP dans Microsoft Entra
Se connecter à : Microsoft Entra. Attention à bien être dans le tenant (nom de domaine) concerné. Dans la barre de recherche, rechercher : Inscriptions d'applications. Cliquer ensuite sur + Nouvelle inscription. Donner à l'application un nom suffisamment explicite. Par exemple :
FluentSMTP - monsite.fr
Je conseille vraiment d'indiquer le nom du site. Si plusieurs applications sont créées plus tard dans le même tenant, cela évite de se retrouver avec cinq applications toutes nommées simplement « FluentSMTP ».
Types de comptes pris en charge
Dans Types de comptes pris en charge, sélectionner locataire unique seulement : nom de votre tenant
Pour un site WordPress qui doit utiliser la messagerie Microsoft 365 d’une seule entreprise, c’est le choix le plus logique, l’application FluentSMTP n’a besoin d’être utilisée que par les comptes du tenant dans lequel elle est créée. Il n’est donc pas nécessaire d’autoriser les comptes appartenant à d’autres organisations Microsoft 365 ni les comptes Microsoft personnels.
Configurer l'URI de redirection
Lors de la création de l'application, Microsoft demande une URI de redirection, sélectionner le type :
Web
Puis coller exactement l'App Callback URL fournie précédemment par FluentSMTP :
https://www.monsite.fr/wp-json/fluent-smtp/outlook_callback
La moindre différence dans cette URL empêchera l'authentification de fonctionner correctement. Valider ensuite la création de l'application.
Récupérer le Client ID
Une fois l'application créée, Microsoft affiche sa page de présentation. Rechercher : ID d'application (client), Il ressemble à une longue chaîne composée de lettres, chiffres et tirets comme :
12345678-abcd-1234-abcd-123456789abc
Copier cette valeur, c'est le Client ID que FluentSMTP demande. Attention à ne pas le confondre avec l'ID d'objet.
Créer le Client Secret
Dans l'application Entra, ouvrir Certificats et secrets puis dans Secrets client > Nouveau secret client. Donner un nom explicite au secret comme :
FluentSMTP WordPress
Microsoft demande ensuite de choisir une durée de validité. Le secret possède donc une date d'expiration. Il faudra penser à le renouveler avant cette date. Une fois créé, Microsoft affiche sa valeur. Il faut la copier immédiatement.
C'est très important : Microsoft ne réaffichera plus la valeur complète du secret une fois cette page quittée.
Le secret ressemble à quelque chose comme :
AbC8Q~xxxxxxxxxxxxxxxxxxxxxxxxxxxx
C'est cette Valeur qu'il faut entrer dans FluentSMTP, et non l'identifiant du secret.
Reporter les informations dans FluentSMTP
Retourner dans WordPress puis dans la configuration de la connexion Microsoft de FluentSMTP, renseigner :
Application Client ID :
ID récupéré dans Microsoft Entra
Client Secret :
Valeur du secret créé dans Microsoft Entra
L'App Callback URL reste celle fournie par FluentSMTP. Avec certaines configurations récentes en single tenant, FluentSMTP peut également demander le :
Directory (Tenant) ID
On le trouve lui aussi dans la page de présentation de l'application Microsoft Entra. À ce stade, FluentSMTP connaît l'application Microsoft. Mais il n'a toujours pas l'autorisation d'utiliser la boîte Exchange. C'est l'étape suivante qui est fondamentale.
L'authentification OAuth
FluentSMTP propose ensuite un bouton du type : Authenticate with Office365 & Get Access Token ou une formulation proche. En cliquant dessus, on est redirigé vers Microsoft qui demande alors de choisir le compte qui autorisera FluentSMTP. Et c'est précisément ici qu'il y a un piège.
Un administrateur Microsoft 365 n'est pas forcément une boîte Exchange
Dans mon cas, j'avais réalisé toute la configuration avec mon propre compte administrateur du tenant de mon client. Ce compte possédait tous les droits nécessaires :
- administration générale ;
- gestion d'Exchange ;
- gestion des utilisateurs ;
- gestion des applications Entra.
J'ai donc naturellement utilisé ce même compte pour réaliser l'authentification OAuth. Le token a bien été créé. Mais les e-mails ne partaient pas. La raison était finalement simple, mon compte administrateur ne possédait aucune licence Exchange Online et donc aucune boîte aux lettres. C'est un point particulièrement important à comprendre, avoir tous les droits sur Exchange ne signifie pas posséder une boîte Exchange.
Un administrateur peut créer des utilisateurs, modifier Exchange, configurer une application Entra et administrer entièrement le tenant tout en n'ayant lui-même aucune boîte aux lettres. Or FluentSMTP doit finalement envoyer un message au moyen d'une boîte Exchange réelle.
Qui doit faire l'authentification Microsoft ?
Pour rester dans la configuration la plus simple et la plus fiable, le compte utilisé lors de l'authentification OAuth doit être celui qui possède la boîte Exchange qui servira réellement à envoyer les e-mails du site.
Imaginons que le site doive envoyer avec :
contact@entreprise.fr
Si cette boîte appartient au compte Microsoft 365 du dirigeant, c'est ce compte qui doit effectuer la dernière authentification Microsoft.
Toute la configuration technique peut être réalisée par l'administrateur auparavant création de l'application mais le propriétaire de la boîte intervenir réellement au moment où Microsoft demande de s'authentifier.
On peut préparer toute la configuration puis lui demander simplement de réaliser cette connexion lui-même.
Et si mon compte administrateur avait eu une licence Exchange ?
Je me suis évidemment posé la question après avoir compris pourquoi mon premier essai échouait. Si mon compte administrateur avait lui-même possédé une licence Exchange Online, j'aurais effectivement eu une vraie boîte aux lettres et mon authentification OAuth aurait pu fonctionner. Mais cela aurait permis à FluentSMTP d'utiliser ma boîte Exchange, pas automatiquement celle de mon client.
Le fait d'être Administrateur général ne donne pas le droit à une application OAuth d'utiliser arbitrairement n'importe quelle boîte du tenant comme identité d'expédition. Microsoft permet techniquement des scénarios d'envoi au nom d'une autre boîte avec des permissions spécifiques de type Send As ou Send on Behalf, mais on sort alors du cas simple que je souhaite présenter ici.
Pour une installation classique de FluentSMTP, la règle que je recommande est donc simple : une boîte Exchange licenciée = le compte qui réalise l'authentification OAuth = l'adresse utilisée par FluentSMTP.
Les alias : attention au comportement de FluentSMTP
Microsoft Exchange permet de créer gratuitement plusieurs alias pour une même boîte :
nom.prenom@entreprise.fr
contact@entreprise.fr
no-reply@entreprise.fr
Microsoft permet même d'autoriser l'envoi depuis ces alias dans Outlook. J'ai donc naturellement essayé d'utiliser un alias comme adresse d'expédition dans FluentSMTP. L'envoi fonctionnait, mais le message était finalement envoyé avec l'adresse principale du compte Exchange ayant effectué l'authentification OAuth. Autrement dit, le fait qu'un alias fonctionne parfaitement comme adresse d'envoi dans Outlook ne signifie pas que FluentSMTP l'utilisera de la même manière.
Pour éviter les mauvaises surprises, je conseille donc de considérer que FluentSMTP envoie avec l'adresse principale de la boîte Exchange authentifiée. Si le site doit absolument utiliser une autre adresse comme expéditeur, mieux vaut prévoir cette organisation au niveau des comptes Exchange plutôt que compter sur un alias.
Générer le token
Une fois connecté avec le bon compte, Microsoft présente les autorisations demandées par FluentSMTP, l'utilisateur les accepte et Microsoft retourne ensuite vers WordPress et FluentSMTP récupère l'autorisation OAuth nécessaire. Suivant la version du plugin, FluentSMTP peut afficher un code ou demander une dernière validation.
Une fois la connexion enregistrée, le site peut utiliser la boîte Exchange sans stocker le mot de passe Microsoft 365 du client dans WordPress. C'est l'un des grands intérêts de cette méthode.
Client ID, Client Secret et token : quelle différence ?
Ces trois notions sont faciles à mélanger quand on découvre OAuth. Le Client ID identifie l'application FluentSMTP créée dans Microsoft Entra. Le Client Secret est en quelque sorte le mot de passe de cette application auprès de Microsoft. Le token OAuth représente l'autorisation donnée par l'utilisateur à cette application. On peut résumer le fonctionnement ainsi :
WordPress
↓
FluentSMTP
↓
Application Microsoft Entra
↓
Client ID + Client Secret
↓
Authentification OAuth
↓
Compte possédant une boîte Exchange
↓
Microsoft 365 / Exchange Online
↓
Envoi du message
Une fois ce schéma compris, la configuration devient beaucoup plus logique.
Tester l'envoi
Dans FluentSMTP, aller dans : E-mail de test, sélectionner la connexion Microsoft puis envoyer un message vers une adresse externe. Si tout est correctement configuré, FluentSMTP doit confirmer l'envoi. Je conseille ensuite d'aller voir également Journaux des e-mails qui sont très utiles. Lorsqu'un client indique un jour : « Je n'ai pas reçu le message du formulaire » on peut immédiatement vérifier si WordPress a réellement tenté de l'envoyer et si Microsoft l'a accepté.
C'est nettement plus pratique que de travailler à l'aveugle avec la fonction mail native de WordPress.
Penser à l'expiration du Client Secret
Le Client Secret créé dans Microsoft Entra n'est pas éternel. Il possède une date d'expiration. Je conseille donc de bien noter dans votre agenda la date afin de renouveler le secret :
Application : FluentSMTP - monsite.fr
Client Secret : expire le XX/XX/XXXX
Il faudra créer un nouveau secret avant cette date et remplacer l'ancien dans FluentSMTP. Il n'est pas nécessaire de recréer toute l'application Entra. Au contraire, conserver la même application permet notamment de conserver le même Client ID.
Le renouvellement du Client Secret ne nécessite pas, dans mes tests, une nouvelle authentification du compte Exchange. J’ai créé un nouveau secret dans Microsoft Entra, remplacé sa valeur dans FluentSMTP puis supprimé l’ancien secret. Après expiration du jeton d’accès en cours, FluentSMTP a pu continuer à envoyer les e-mails sans demander une nouvelle connexion au compte Microsoft.
Une configuration complexe la première fois, beaucoup moins ensuite
Au final, FluentSMTP est probablement la partie la plus simple de cette configuration. Ce qui rend la première mise en place déroutante est surtout l'architecture Microsoft et son vocabulaire : tenant, Microsoft 365, Exchange Online, Entra (Azure), App Registration, Client ID, Client Secret, Redirect URI, OAuth, token…
Au début, tout semble appartenir au même outil alors qu'il s'agit en réalité de différentes briques qui travaillent ensemble. Une fois leur rôle compris, le principe est bien sécurisé : WordPress ne connaît jamais le mot de passe de la boîte Exchange.
FluentSMTP se présente auprès de Microsoft à l'aide d'une application Entra et Microsoft autorise cette application à utiliser une boîte Exchange grâce à OAuth. Et surtout, cette intégration peut être réalisée avec FluentSMTP sans payer une licence supplémentaire pour un plugin WordPress.
