Configurer les e-mails avec OAuth2 Microsoft dans Dolibarr

Mettre en service l'envoi d'e-mails Dolibarr avec Microsoft 365 en OAuth2 : côté Microsoft, côté administration Dolibarr, puis côté utilisateur.

DolibarrMails
Dolibarr × Microsoft 365
01 / 11
— Procédure de mise en service

Messagerie
Dolibarr ×
Microsoft 365
en OAuth2.

Trois phases, trois intervenants, dans l’ordre.

Édition Septembre 2026
Audience IT client + admin Dolibarr + utilisateurs
Statut Validé sur 2 déploiements
02 / 11
Les grandes étapes

Trois phases :

Chaque phase a un intervenant unique et une condition de sortie claire. Elles doivent être faites dans cet ordre : la phase 2 a besoin des clés de la phase 1, la phase 3 a besoin de la connexion créée en phase 2.

Les trois phases de mise en service Phase 1 côté Microsoft Azure produit les clés, phase 2 côté administration Dolibarr crée une connexion OAuth par utilisateur, phase 3 côté utilisateur génère le jeton. PHASE 1 Microsoft / Azure Application, clés, SMTP AUTH, DNS. IT CLIENT · 1 FOIS clés PHASE 2 Dolibarr, admin Une connexion OAuth par utilisateur, avec les mêmes clés. INTÉGRATEUR · 1 FOIS / USER service PHASE 3 Utilisateur Fiche utilisateur → onglet MultiSMTP → générer un token. CHACUN POUR SOI · 1 MIN La phase 3 est incompressible : en mode délégué, Microsoft exige que chaque personne s’authentifie pour son propre compte.
  1. Microsoft 365 : ce que Dolibarr attendIT client
  2. Dolibarr, côté administration : connexions OAuth~5 min / user
  3. Côté utilisateur : génération du jeton~1 min
03 / 11
Partie 1

Côté Microsoft 365.

L’état attendu du côté Microsoft. La mise en œuvre relève de l’administrateur Microsoft 365 du client ; notre rôle est de spécifier et de vérifier.

Qui agitAdministrateur Microsoft 365 du client
FréquenceUne fois par locataire
Notre rôleSpécifier, puis vérifier
Nous recevonsClient ID · Tenant ID · Secret · adresse
Partie 1 · Microsoft 04 / 11
Spécification

Ce que Dolibarr attend de Microsoft 365.

Cette page décrit l’état attendu du côté Microsoft. La mise en œuvre relève de l’administrateur Microsoft 365 du client.

Exigence
Ce qu’elle conditionne côté Dolibarr
Précision utile
Messagerie en ligne
La procédure entière. Elle suppose une messagerie hébergée dans Exchange Online.
Un Exchange Server installé sur site, ou une configuration hybride dont la boîte reste sur site, n’est pas couvert par ce guide.
Compte expéditeur
Toute expédition. Un compte utilisateur ou une boîte partagée, disposant d’une licence Exchange Online active.
Une boîte partagée n’a pas de jeton propre : prévoir un compte nominatif disposant du droit « Send As ».
SMTP AUTH activé
L’authentification de l’envoi. Attendu actif au niveau de l’organisation et de la boîte.
SmtpClientAuthenticationDisabled à false. Ce réglage gouverne aussi XOAUTH2 : passer en OAuth2 n’en dispense pas.
Application inscrite
La connexion OAuth. Une seule inscription pour toute l’instance Dolibarr, type Web.
L’URI de redirection doit reprendre au caractère près celle affichée par le module OAuth de Dolibarr.
Secret client
L’authentification de l’application. Un seul secret, partagé par tous les utilisateurs.
Son échéance est à suivre côté client : ce jour-là, l’envoi s’arrête pour tous les utilisateurs en même temps.
Autorisations d’API
Aucune à déclarer. Les droits SMTP et IMAP sont des scopes dynamiques, demandés par Dolibarr à la génération du jeton.
Ne pas cocher les entrées homonymes proposées sous Microsoft Graph : elles ne donnent pas accès au protocole SMTP.
Consentement
La génération des jetons par les utilisateurs, en phase 3.
Chaque utilisateur consent pour lui-même. Si la politique du locataire l’interdit, un consentement organisationnel doit couvrir SMTP.Send et IMAP.AccessAsUser.All sur Office 365 Exchange Online, ainsi que offline_access openid profile email User.Read sur Microsoft Graph.
Réseau et DNS
La remise effective des messages.
Port 587 sortant ouvert vers smtp.office365.com en STARTTLS, sans relais intermédiaire. SPF, DKIM et DMARC en place sur le domaine d’envoi.
À nous transmettre

Quatre valeurs, et c’est tout

Application (client) ID · Directory (tenant) ID · valeur du secret client · adresse de la boîte expéditrice.

Le secret transite par le gestionnaire de mots de passe convenu, jamais par e-mail ni par ticket.

Le portail où se fait l’inscription de l’application est présenté sous deux noms selon les locataires, Azure ou Microsoft Entra ID : il s’agit du même emplacement.

05 / 11
Partie 2

Dolibarr, côté administration.

Une connexion OAuth par utilisateur, toutes avec les mêmes clés. Ce qui se démultiplie est ici, pas côté Azure.

Qui agitIntégrateur Dolibarr
FréquenceUne fois par utilisateur
EntréeClient ID · Secret · Tenant ID
ProduitUn service OAuth nommé, par utilisateur
Partie 2 · Dolibarr admin 06 / 11
Étape 2.1

L’architecture :

Une application Azure et un secret pour l’instance ; un service OAuth et un jeton par utilisateur.

Élément
Combien
Conséquence directe
Application Azure
Une seule, pour tout le monde
Une seule inscription dessert tous les expéditeurs.
Secret client
Un seul, partagé
À son échéance, l’envoi s’arrête pour tous les utilisateurs simultanément.
Service OAuth Dolibarr
Un par utilisateur, suffixe distinct
Mêmes Client ID, Secret et Tenant ID partout. Seul le suffixe du nom change.
Jeton
Un par utilisateur
Généré par l’utilisateur lui-même, en phase 3.

Configuration e-mail globale

Accueil → Configuration → Emails. C’est ici que sont posés les paramètres serveur dont hériteront toutes les fiches utilisateur.

Méthode = SMTP/SMTPS Hôte SMTP = smtp.office365.com Port = 587 Chiffrement = STARTTLS # Héritées par les fiches utilisateur.

Activer les modules

Configuration → Modules :

OAuth : à activer s’il ne l’est pas. C’est lui qui fournit l’URI de redirection à déclarer dans Azure en phase 1.

MultiSMTP : à activer pour obtenir l’onglet correspondant sur les fiches utilisateur. Sans lui, un seul expéditeur pour toute l’instance.

L’URI de redirection est affichée dans la configuration du module OAuth. Elle doit correspondre au caractère près à celle déclarée dans Azure en phase 1.

Partie 2 · Dolibarr admin 07 / 11
Étape 2.2

Une connexion OAuth par utilisateur.

À répéter pour chaque expéditeur.

  1. Dolibarr
    Créer l’entrée OAuth

    Accueil → Configuration → Modules → OAuth → engrenage. Choisir Microsoft Exchange Online dans la liste, donner un nom identifiant clairement l’utilisateur concerné (le suffixe est ce qui distingue les entrées entre elles), valider.

  2. Dolibarr
    Saisir les clés et cocher les scopes

    Les trois identifiants sont identiques pour toutes les entrées, ils viennent de l’unique application Azure créée en phase 1.

    CLIENT_ID = [Application (client) ID] CLIENT_SECRET = [valeur du secret] TENANT_ID = [Directory (tenant) ID] Scopes = [x] offline_access [x] SMTP.Send [x] IMAP.AccessAsUser.All

    Les trois cases ne sont pas décoratives. Le paramètre state d’OAuth transporte la liste des scopes. Toutes décochées, il part vide et Dolibarr affiche au retour « parameter state is not defined », un message qui ne mentionne à aucun moment les cases.

    Dolibarr affiche ces scopes sous la forme outlook.office.com/… : c’est un alias de outlook.office365.com/…, il n’y a rien à corriger.

  3. Dolibarr
    Préparer la fiche utilisateur

    Fiche de l’utilisateur → onglet MultiSMTP. Renseigner uniquement ce qui lui est propre ; le reste hérite de la configuration globale.

    Authentification = XOAUTH2 Identifiant SMTP = adresse de l’utilisateur Service OAuth = l’entrée créée à son suffixe Serveur = (laisser vide) Port = (laisser vide) TLS = (laisser vide)

    L’adresse d’expéditeur doit être identique à l’identifiant SMTP. Exception : une boîte partagée, dont l’adresse est mise en identifiant alors que le jeton appartient à un compte nominatif ayant les droits « Send As ».

    La fiche est prête. La génération du jeton revient à l’utilisateur : partie 3.

08 / 11
Partie 3

Côté utilisateur.

Une manipulation, une fois, environ une minute. C’est la seule étape que l’intégrateur ne peut pas faire à la place du client.

Qui agitChaque utilisateur, pour son compte
FréquenceUne fois, puis en cas de révocation
OùSa fiche → onglet MultiSMTP
Durée~1 minute
Partie 3 · Utilisateur 09 / 11
Étape 3.1

Générer son jeton.

Trois étapes, environ une minute.

  1. Dolibarr
    Sa fiche utilisateur → onglet MultiSMTP → « Obtenir un nouveau jeton »

    L’utilisateur se connecte à Dolibarr avec son propre compte, ouvre sa fiche, va sur l’onglet MultiSMTP et clique sur le bouton de génération. Une fenêtre Microsoft s’ouvre.

  2. Microsoft
    Se connecter et valider les permissions

    Saisir ses identifiants Microsoft, puis accepter l’écran de consentement. Terminé : le jeton est enregistré, et le refresh token prend le relais ensuite sans nouvelle intervention.

    Vérifier le compte affiché en haut à droite avant de valider : ce doit être celui de l’utilisateur concerné. Le navigateur réutilise la session Microsoft en cours ; si quelqu’un génère le jeton depuis une session ouverte sur un autre compte, ouvrir une fenêtre de navigation privée. Un jeton émis sur le mauvais compte n’envoie rien : Dolibarr remonte une erreur au moment de l’envoi.

  3. Contrôle
    Test d’envoi

    Test envoi vers une adresse externe depuis la configuration e-mail.

10 / 11
Avant d’ouvrir un ticket

Checklist & rôles.

Checklist de mise en service

Phase 1, à obtenir de l’IT client :

☐ Boîte de service avec licence Exchange Online active
☐ SMTP AUTH activé, organisation et boîte
☐ Domaine vérifié, SPF / DKIM / DMARC validés
☐ Application inscrite, URI de redirection identique à celle de Dolibarr
☐ Secret client (échéance suivie par l’IT client)
☐ Aucune autorisation déclarée dans le sélecteur, aucun homonyme Graph coché
☐ Port 587 sortant ouvert, sans relais tiers
☐ Client ID, Tenant ID, secret et adresse expéditrice transmis

Phase 2, Dolibarr (intégrateur) :

☐ Modules OAuth et MultiSMTP activés
☐ Configuration e-mail globale saisie
☐ Une entrée OAuth par utilisateur, mêmes clés partout
☐ Trois cases de scopes cochées sur chaque entrée
☐ Fiches utilisateur : XOAUTH2, identifiant = adresse, serveur / port / TLS vides

Phase 3, Utilisateur :

☐ Jeton généré par l’utilisateur lui-même, en navigation privée
☐ Compte affiché vérifié avant validation
☐ Test envoi réussi vers une adresse externe
☐ Envoi reçu par le destinataire

Répartition des rôles

Qui agit, qui valide, qui est informé, pour éviter les zones grises où chacun pense que c’est l’autre qui s’en occupe.

Tâche
IT client
Intégrateur Dolibarr
Prérequis M365, SMTP AUTH, DNS
Réalise & valide
Consulté
Application Azure & secret
Réalise & valide
Consulté, fournit l’URI de redirection
Consentement organisationnel (si nécessaire)
Réalise & valide (Administrateur général ou d’application cloud)
Consulté, fournit le Client ID et les scopes attendus
Entrées OAuth & fiches MultiSMTP
Informé
Réalise & valide
Génération des jetons
Réalise, chacun pour son compte
Valide
Renouvellement du secret
Réalise & valide
Informé, met à jour toutes les entrées
Diagnostic d’un échec d’envoi
Consulté
Réalise & valide
Lecture du Message Trace
Réalise
Consulté

Réalise = agit concrètement · Valide = a le dernier mot · Consulté = donne un avis avant action · Informé = mis au courant après coup

11 / 11
— Fin du document

Trois phases,
trois responsables,
aucune zone grise.

Microsoft produit les clés, l’administrateur Dolibarr crée les connexions, chaque utilisateur génère son jeton. Quand un envoi échoue, la phase concernée désigne l’intervenant à solliciter.

Procédure validée sur deux locataires, dont un tenant éducation verrouillé :
un utilisateur standard, sans aucun rôle d’administration, génère son jeton et envoie.
Dernière revue : septembre 2026 · Prochaine revue : selon annonces Microsoft