Matomo envoie du courrier. Les rapports PDF planifiés le lundi matin, les alertes quand le trafic s'effondre, la réinitialisation de mot de passe dont un collègue a besoin à un moment gênant. Tout cela part par SMTP, configuré dans les Réglages généraux, avec un nom de serveur, un identifiant et un mot de passe posés dans le fichier de configuration.
Sur Microsoft 365, cet arrangement touche à sa fin. L'authentification de base pour la soumission SMTP — identifiant et mot de passe transmis à chaque connexion — est en train d'être retirée d'Exchange Online par étapes : Microsoft la désactive déjà par défaut pour les locataires qui ne l'utilisent pas, et prévoit de la couper par défaut pour tous les locataires restants d'ici la fin de 2026. Le jour où cela arrive sur votre locataire, Matomo cesse d'envoyer, et la première chose que vous remarquez est un rapport qui n'est jamais arrivé.
La solution de contournement la plus répandue est pire qu'il n'y paraît
La réponse habituelle est l'OAuth délégué : connecter le plugin à un compte Microsoft, valider un écran de consentement, et le plugin conserve un jeton d'actualisation qui lui permet d'envoyer au nom de cette personne.
Ça fonctionne. Mais ça introduit aussi un être humain dans votre infrastructure. Ce compte a besoin d'une licence. Il a besoin d'un mot de passe et d'une MFA. Si la personne part, si son mot de passe change, ou si le jeton d'actualisation expire — et les jetons d'actualisation expirent —, vos rapports analytiques s'arrêtent silencieusement et personne ne s'en aperçoit avant qu'on ne demande où sont passés les chiffres. Vous avez remplacé un mot de passe stocké par un jeton stocké appartenant à un salarié, ce qui est un problème différent, pas un problème résolu.
Les permissions d'application suppriment l'humain entièrement
Missivus emprunte l'autre voie que propose Microsoft. Plutôt que d'agir au nom d'une personne, il s'authentifie comme une application.
Une inscription d'application dans Entra ID détient un secret client ou un certificat. Elle reçoit la permission d'application Mail.Send — pas la permission déléguée — avec consentement administrateur. Elle envoie vers une boîte aux lettres partagée, qui sur Microsoft 365 ne nécessite aucune licence. Il n'y a ni utilisateur, ni connexion, ni invite MFA, ni jeton d'actualisation, ni mot de passe de boîte aux lettres nulle part dans votre installation Matomo ou sa base de données. L'identifiant est un secret d'application que vous faites tourner selon votre propre calendrier, et le faire tourner consiste à coller une nouvelle valeur dans un seul champ.
Le détail que presque tout le monde rate
Voici le détail qui compte, et la raison pour laquelle ce plugin existe plutôt qu'un simple extrait de configuration.
Accorder Mail.Send en tant que permission d'application donne à cette application la capacité d'envoyer au nom de toutes les boîtes aux lettres de votre locataire. Par défaut. Ce n'est pas un détail mineur — c'est une capacité d'envoi au nom de n'importe qui, à l'échelle de tout le locataire, confiée à un service principal, et un grand nombre de tutoriels s'arrêtent précisément là en considérant l'affaire close.
La restriction est une étape à part, dans un endroit différent, dans un autre outil d'administration : une stratégie d'accès aux applications dans Exchange Online — le nouveau RBAC for Applications de Microsoft remplit le même rôle et c'est la direction vers laquelle Microsoft oriente les administrateurs —, appliquée via PowerShell, en limitant cette application à un unique groupe de sécurité à extension messagerie ne contenant que la boîte aux lettres qu'elle est autorisée à toucher. Tant que vous ne l'avez pas exécutée, le périmètre couvre tout. Une fois exécutée, vous vérifiez avec Test-ApplicationAccessPolicy et confirmez que l'accès est refusé pour une boîte aux lettres qui devrait être hors de portée — parce qu'une restriction que vous n'avez pas testée est une restriction que vous supposez seulement exister.
Missivus fournit le PowerShell pour cette étape dans le cadre de son installation plutôt que de la laisser comme un exercice, et le plugin ne considère pas une configuration comme terminée sans elle.
Ce que cela ne fait pas
C'est réservé à Microsoft 365. Si vous utilisez Google Workspace ou votre propre serveur de messagerie, ce n'est pas pour vous et le SMTP convient très bien.
Il n'envoie que du courrier sortant, rien d'autre. La permission d'application est Mail.Send — l'application ne peut lire aucune boîte aux lettres, et ne le devrait pas.
Et il fait transiter votre courrier Matomo par l'infrastructure de Microsoft, une société américaine opérant sous hébergement UE. Si c'est la mauvaise réponse pour vos données, c'est aussi la mauvaise réponse ici, et nous préférons le dire plutôt que de le passer sous silence.
Se le procurer
Missivus for Matomo est disponible sur le Matomo Marketplace, sous licence GPLv3, gratuitement. Le guide d'installation — inscription de l'application, octroi de la permission, stratégie d'accès, vérification — se trouve sur missivus.com/setup.
Si vous préférez ne pas toucher vous-même à Entra ID et au PowerShell Exchange, nous nous chargeons de l'installation et vous livrons une configuration opérationnelle. C'est la partie payante ; le plugin, lui, ne l'est jamais.
Questions fréquentes
- Cela fonctionne-t-il en dehors de Microsoft 365 ?
- Non. C'est réservé à Microsoft 365 ; sur Google Workspace ou un serveur de messagerie auto-hébergé, le SMTP reste la bonne réponse.
- L'application peut-elle lire notre messagerie ?
- Non. La permission accordée est uniquement `Mail.Send`. L'application peut envoyer du courrier sortant et ne peut lire aucune boîte aux lettres.
- Que se passe-t-il quand le secret client expire ?
- L'envoi s'arrête jusqu'à ce que le secret soit remplacé. Le faire tourner consiste à coller une nouvelle valeur dans un seul champ, et la date d'expiration est fixée par vous à la création du secret.