Demander à un responsable de se connecter à GLPI juste pour approuver un ticket, c'est une friction qui coûte des heures de SLA. Quiconque exploite un centre de services connaît la scène : l'e-mail d'approbation arrive, le responsable le lit sur son téléphone, n'a pas son mot de passe sous la main, et le ticket dort jusqu'à ce que quelqu'un le relance par téléphone.
Le problème
Les circuits d'approbation, la validation de solution et les enquêtes de satisfaction dépendent d'une action de personnes qui ouvrent rarement GLPI : le responsable qui autorise un achat, le client externe qui confirme que le problème est résolu, l'utilisateur final qui évalue le service. Dans GLPI natif, toutes ces actions se déroulent dans l'interface authentifiée. Pour qui n'a pas de compte - ou en a un mais ne se souvient pas du mot de passe - cela devient une vraie barrière.
Le résultat est prévisible : approbations bloquées, tickets figés dans l'attente d'une réponse qui ne vient jamais, et l'équipe qui perd du temps en relances manuelles. L'enquête de satisfaction est le cas extrême : le taux de réponse tombe près de zéro dès qu'une connexion est exigée, car l'utilisateur abandonne tout simplement à l'écran d'authentification. Ce n'est pas un manque d'envie de répondre ; c'est une étape de plus que personne ne veut franchir.
Comment ça marche
Le module Mail Interactions de NexTool ajoute des balises de notification à GLPI. Au moment où l'e-mail est mis en file, le module remplace chaque balise par une URL unique et éphémère. Le destinataire clique, arrive sur une page publique, confirme l'action, et GLPI est mis à jour - sans écran de connexion, sans compte.
- Approuver ou refuser des validations - les balises
##ticket.approve_link##et##ticket.reject_link##se placent dans le modèle de notification de validation. L'approbateur ouvre le lien, saisit éventuellement une justification et confirme. - Valider ou rouvrir la solution -
##ticket.validate_link##clôt le ticket lorsque le demandeur confirme la résolution ;##ticket.reopen_link##le rouvre pour une nouvelle prise en charge. - Enquête de satisfaction en un clic - de
##ticket.satisfaction_link_1##à##ticket.satisfaction_link_10##portent déjà la note présélectionnée ; l'utilisateur clique sur la note directement depuis l'e-mail et, s'il le souhaite, laisse un commentaire. - Tickets, Changements et Problèmes - les mêmes balises existent par type d'élément :
##ticket.*##,##change.*##et##problem.*##(pour Problème, uniquement valider et rouvrir). - Jetons à usage unique et à durée limitée - chaque lien est valable pendant une période configurable (7 jours par défaut) et est invalidé dès la première utilisation, empêchant les clics répétés ou la réutilisation.
- Justification obligatoire, quand c'est pertinent - on peut exiger un commentaire au refus, à la réouverture ou sur les notes de satisfaction sous un seuil, améliorant la qualité de l'enregistrement.
Module vs. GLPI natif
Ce qui change en pratique, par rapport au comportement standard de GLPI :
| Action | GLPI natif | Avec Mail Interactions |
|---|---|---|
| Approuver / refuser une validation | L'approbateur doit se connecter et ouvrir le ticket | Un clic sur le lien de l'e-mail, confirmation sur la page publique |
| Confirmer / rouvrir la solution | Le demandeur agit dans l'interface authentifiée | Lien direct dans l'e-mail de solution proposée |
| Enquête de satisfaction | Répondue dans l'interface ou le portail GLPI | Note présélectionnée, réponse en un clic |
| Utilisateur sans compte GLPI | Ne peut pas agir | Agit via la page publique, sans consommer d'utilisateur |
| Sécurité du lien | Session GLPI authentifiée | Jeton de 256 bits à usage unique, avec expiration et HTTPS |
Un exemple réel : les balises dans le modèle de notification
Les balises se placent dans le corps HTML du modèle de notification de validation (Configuration > Notifications > Modèles de notification). Un extrait typique du corps :
<!-- Modèle : évènement "Validation de ticket" -->
<p>Bonjour ##validation.validator##,</p>
<p>Le ticket <strong>##ticket.title##</strong> (##ticket.id##)
attend votre approbation.</p>
<p style="text-align:center">
<a href="##ticket.approve_link##"
style="background:#22c55e;color:#fff;padding:12px 20px;border-radius:6px">
Approuver
</a>
<a href="##ticket.reject_link##"
style="background:#ef4444;color:#fff;padding:12px 20px;border-radius:6px">
Refuser
</a>
</p>
<p>Les liens expirent dans 7 jours et ne peuvent être utilisés qu'une seule fois.</p>Lorsque l'e-mail est généré, Mail Interactions remplace chaque balise par une URL tokenisée. À titre d'illustration seulement, le format est le suivant :
https://support.votreentreprise.com/plugins/nextool/ajax/module_ajax.php
?module=mailinteractions&file=approve.php
&token=Yc7d...jeton-opaque-de-256-bits...&a=approveLe jeton n'encode rien du ticket : c'est une valeur aléatoire qui n'existe que parce qu'elle a été émise et enregistrée sur le serveur. Impossible de le forger, de le deviner ou de le réutiliser. Les principaux réglages se trouvent dans l'onglet Configurer du module :
# Configuration > NexTool > Modules > Mail Interactions > Configurer
token_ttl_days = 7 # validité du lien, en jours
force_https_links = 1 # toujours générer des URL https://
require_reject_description = 1 # exiger une justification au refus
require_reopen_description = 1 # exiger une justification à la réouverture
satisfaction_max_stars = 5 # échelle de l'enquête (5 ou 10)
satisfaction_require_comment_below = 3 # exiger un commentaire si la note < 3Ce que nous avons appris en exploitation
En exploitant GLPI pour des clients, l'erreur la plus fréquente que nous voyons n'est pas technique, elle est de configuration : placer les balises d'approbation dans le mauvais modèle de notification. Si vous mettez ##ticket.approve_link## dans un modèle qui se déclenche aussi sur d'autres évènements (par exemple "Ticket mis à jour"), le lien finit dans des e-mails où il n'y a aucune validation en attente - et le destinataire reçoit un lien qui ne mène qu'à une page d'erreur. La bonne pratique est d'utiliser ces balises uniquement dans le modèle de l'évènement de validation. C'est simple, mais cela explique une grande partie du support que nous ouvrons à propos de "le lien ne marche pas".
La deuxième leçon vient d'un détail d'infrastructure. Les appliances de sécurité e-mail - Microsoft Safe Links, Mimecast et consorts - préouvrent les liens des messages pour les analyser avant que l'utilisateur ne clique. Si l'approbation était exécutée sur le GET brut du lien, ces robots "approuveraient" le ticket tout seuls, produisant des approbations fantômes. C'est pourquoi le module n'agit jamais au clic : le lien ouvre une page de confirmation et l'action n'est validée que sur un POST avec son propre jeton de formulaire. Le robot qui fait le préchargement voit la page mais ne confirme pas le formulaire, donc le jeton à usage unique reste intact. C'est ce choix d'architecture qui a évité des approbations indues chez un client sous Office 365 d'entreprise - un problème qui n'apparaît qu'en production, jamais dans l'environnement de test.
Un détail fin qui vaut la peine d'être connu : lors de la validation de solution, quand l'entité a un délai de clôture configuré (le solvedelay de GLPI), le module utilise ce délai comme durée de vie du lien, au lieu de la valeur par défaut de 7 jours. Le lien vit alors exactement aussi longtemps que le ticket peut encore être rouvert - ni plus, ni moins.
Comment l'activer
- Ayez le plugin NexTool installé sur votre GLPI 10 ou 11.
- Allez dans Configuration > NexTool > Modules.
- Activez Mail Interactions et cliquez sur Configurer pour définir la durée de vie du jeton, le HTTPS forcé et les règles de justification.
- Dans Configuration > Notifications > Modèles de notification, éditez le modèle de l'évènement de validation (ou de solution/satisfaction) et ajoutez les balises souhaitées dans le corps.
- Déclenchez une validation de test et vérifiez l'e-mail : les liens doivent pointer vers
/plugins/nextool/ajax/module_ajax.phpavec un jeton dans l'URL.
Pour qui - et quand ne pas l'utiliser
Mail Interactions convient à toute organisation qui utilise des circuits d'approbation dans GLPI et souffre de lenteurs parce que les approbateurs accèdent rarement au système. Il est particulièrement utile aux centres de services qui servent des utilisateurs finaux et des clients externes sans compte GLPI - ils valident des solutions et répondent aux enquêtes sans aucune barrière d'accès.
Quand ne pas l'utiliser : si votre politique de sécurité exige que toute approbation soit tracée par une connexion authentifiée avec MFA (conformité financière, approbations à forte valeur), la page publique ne remplace pas ce contrôle - dans ce cas, gardez l'approbation dans la session authentifiée de GLPI. Le module supprime la friction ; il ne remplace pas une signature électronique à valeur juridique.
Compatibilité
- GLPI : 10.0+ et 11.0+
- Plugin : NexTool (module Mail Interactions, base 4.3.4 ou supérieure)
- Éléments pris en charge : Ticket, Changement et Problème (Problème : valider/rouvrir uniquement)
- Offre : à la demande
Prochaine étape
Mail Interactions fait partie de NexTool, un écosystème de modules pour étendre GLPI sans personnalisation de code. Contactez l'équipe pour une démonstration dans votre environnement.
Ce contenu a été produit avec l'aide de l'intelligence artificielle et révisé par l'équipe Nextool Solutions.
