NexTool Solutions

Dans GLPI, "configurer la messagerie" ne se limite pas à pointer vers un serveur SMTP : il faut garantir que l'événement devienne un message, entre dans la file et parte réellement. Dans la maintenance d'environnements clients, la plupart des cas de "GLPI n'envoie plus d'e-mails" n'ont rien de cassé côté SMTP : ce qui a lâché, c'est le vidage de la file ou le cron. Ce guide couvre la configuration complète et, surtout, les points où la remise échoue vraiment.

Le modèle mental : événement, file et envoi

Une notification traverse trois étapes, et chacune échoue différemment :

1. Événement - quelque chose se produit (nouveau ticket, suivi, résolution) et une Notification associe l'événement à un Modèle et aux destinataires.
2. File - le message est écrit dans la table glpi_queuednotifications, il n'est pas envoyé immédiatement.
3. Envoi - l'action automatique queuednotification, déclenchée par le cron, vide la file via SMTP.

Gardez cette séparation en tête : la plupart des incidents que nous traitons se situent à l'étape 3 (la file se remplit et personne ne la vide), pas à l'étape 1 (SMTP). Configurer un SMTP parfait sans sécuriser le cron est la recette classique du "j'ai tout configuré et rien n'arrive".

Configuration de base du SMTP

Dans Configuration > Notifications > Configuration des suivis par courriel (Setup > Notifications), activez les suivis par courriel et renseignez :

• Mode d'envoi : SMTP+TLS dans la plupart des cas - évitez le mail() de PHP en production.
• Serveur et port : l'hôte du relais + 587 (STARTTLS) ou 465 (SSL).
• Identifiant/mot de passe ou OAuth : selon le fournisseur.
• Courriel de l'administrateur et de l'expéditeur : une adresse que le relais est autorisé à utiliser comme expéditeur - ce détail décide si le courriel arrive ou tombe en spam.

Le mot de passe est stocké chiffré (GLPIKey) dans la colonne smtp_passwd. Ne le lisez jamais en SQL : il ressort brouillé et n'aide pas au diagnostic. Pour vérifier le reste de la configuration directement dans la base :

-- Diagnostic de la configuration d'envoi (ne lisez jamais smtp_passwd : il est chiffré)
SELECT name, value
FROM glpi_configs
WHERE context = 'core'
  AND name IN ('smtp_mode','smtp_host','smtp_port','smtp_username',
               'smtp_check_certificate','admin_email','from_email',
               'notifications_mailing','use_notifications');

Si notifications_mailing renvoie 0, les notifications par courriel sont désactivées globalement - aucun réglage SMTP ne compte tant que ce n'est pas activé.

Choisir le mode d'envoi

Voici la matrice que nous utilisons pour choisir le mode selon le scénario :

Gmail et Microsoft 365 via OAuth 2.0

Gmail et Microsoft 365 ont bloqué l'authentification basique (identifiant + mot de passe). La voie prise en charge est OAuth 2.0 (GLPI 10.0.7+). Chez le fournisseur, vous enregistrez une application (Google Cloud Console ou Azure App Registrations), générez un Client ID et un Client Secret, indiquez la redirect URI de GLPI et autorisez. Dans GLPI, choisissez le mode SMTP+OAuth, sélectionnez le fournisseur et collez les identifiants.

Le piège qui consomme le plus de temps sur Microsoft 365 : même avec un OAuth correct, M365 désactive SMTP AUTH par défaut sur la boîte. Sans l'activer, l'authentification passe et l'envoi échoue. Activez-le sur la boîte utilisée :

# Microsoft 365 : active SMTP AUTH sur la boîte utilisée par OAuth (désactivé par défaut)
Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

Sur Gmail/Workspace, le scope est https://mail.google.com/ et, sur les comptes Workspace, l'administrateur peut devoir autoriser l'application. Les comptes avec 2FA acceptent encore un mot de passe d'application en solution de repli, mais Google retire progressivement cette voie.

La file et le cron : là où ça casse vraiment

Voici le détail qui n'apparaît qu'en exploitation. L'action automatique queuednotification peut tourner selon deux modes : GLPI (déclenchée par un accès à l'interface) ou CLI (par cron externe). Sur une instance à faible trafic - le client qui n'utilise GLPI qu'aux heures ouvrées - le mode GLPI fait que les notifications de la nuit ne partent que lorsqu'on ouvre le système le matin. Le symptôme arrive comme "courriel en retard" ou "n'arrive pas". La décision que nous avons standardisée en maintenance : toutes les actions automatiques en mode CLI, avec front/cron.php appelé par un cron externe chaque minute.

# GLPI - vide la file de notifications chaque minute (utilisateur du serveur web)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

# Sous Docker : lance le cron de GLPI en tant qu'utilisateur du serveur web (ajustez nom/chemin)
* * * * * root docker exec -u www-data glpi php /var/www/glpi/front/cron.php >/dev/null 2>&1

Pour voir si la file se vide, regardez ce qui est bloqué sans sent_time :

-- Notifications bloquées dans la file (file pleine = le cron ne la vide pas)
SELECT id, itemtype, recipient, create_time, send_time, sent_time, sent_try
FROM glpi_queuednotifications
WHERE sent_time IS NULL
ORDER BY send_time ASC
LIMIT 20;

Une pile importante et croissante ici, avec un SMTP intact, c'est presque toujours un cron arrêté ou en mode GLPI. Vous pouvez aussi la suivre dans l'interface sous Administration > File d'attente des notifications.

Modèles et variables

Dans Configuration > Notifications > Modèles de notification, vous éditez le corps de chaque événement. Les variables utilisent la syntaxe ##...## :

<!-- Modèle "Nouveau ticket" - corps HTML avec les variables de GLPI -->
<p>Bonjour ##ticket.author##,</p>
<p>Votre ticket <strong>##ticket.id##</strong> a été enregistré :</p>
<ul>
  <li>Titre : ##ticket.title##</li>
  <li>Priorité : ##ticket.priority##</li>
  <li>Suivez-le sur : ##ticket.url##</li>
</ul>

Un modèle peut avoir des versions par langue ; sans la version de la langue du destinataire, GLPI utilise la version par défaut. L'erreur courante ici est de n'éditer que le corps en portugais et de s'étonner que le technicien au profil anglais reçoive l'ancien modèle.

Pièges de terrain

Les symptômes que nous voyons le plus et où enquêter pour chacun :

Un mot sur le dernier cas : par défaut, GLPI ne notifie pas l'auteur de sa propre action. Le technicien qui met à jour le ticket ne reçoit pas l'écho de sa propre mise à jour - c'est le comportement attendu, pas un bug. Le confondre avec "notifications cassées" a déjà coûté une nuit de diagnostic à courir après un problème inexistant.

Au-delà du courriel

Le courriel est asynchrone et se dispute l'attention avec la boîte de réception. Pour que le technicien voie le ticket à l'instant où il change, le courriel n'est pas le meilleur canal. Envisagez la notification en temps réel avec le module Smart Notify (cloche dans la barre) ou l'envoi par WhatsApp et Telegram pour les événements qui ne peuvent pas attendre le prochain cycle de courriel.

Si le courriel de votre GLPI est intermittent - parfois il arrive, parfois non - c'est en général la file et le cron, pas le SMTP. NexTool assure la maintenance de GLPI avec la surveillance de la file de notifications et le cron sous contrôle. Parlez-nous de support et maintenance de GLPI.

Révisé par l'équipe NexTool Solutions.