Les tickets en double naissent d'un détail simple : quand quelqu'un clique sur "Répondre à tous" dans un fil de support, le collecteur de messagerie de GLPI ne reconnaît pas le message comme faisant partie de la conversation et ouvre un nouveau ticket. Le module Mail Analyzer intercepte ce message avant la création du ticket et décide, à partir des en-têtes de l'e-mail lui-même, s'il s'agit d'un nouveau ticket ou simplement d'un suivi de l'original.
Le problème : le collecteur natif perd le fil
Le collecteur de messagerie de GLPI rattache une réponse au ticket d'origine en lisant le marqueur qu'il insère lui-même dans l'objet des notifications, au format [GLPI #0000123]. Tant que ce marqueur survit dans la réponse, tout fonctionne : le message devient un suivi du bon ticket. Le problème apparaît quand le marqueur est perdu.
Le scénario classique est "Répondre à tous". Un client ouvre le ticket et met son responsable en copie. Le support répond, le responsable décide de commenter et clique sur "Répondre à tous". Son client de messagerie réécrit l'objet (RE:, TR:), coupe le marqueur ou démarre un nouveau message à partir de l'historique - et GLPI, ne trouvant pas le [GLPI #...], ouvre un deuxième ticket pour la même conversation.
Le résultat est connu de quiconque exploite un service desk : deux tickets ou plus pour le même sujet, un historique fragmenté, le risque que deux analystes travaillent en parallèle sans le savoir et un SLA faussé, car chaque doublon compte comme une nouvelle demande. Dans les environnements d'entreprise, où mettre les responsables en copie du fil est une habitude, cela devient des dizaines de doublons par semaine.
Comment fonctionne Mail Analyzer
Le module agit via des hooks dans le cycle de vie du ticket, en interceptant l'e-mail déjà collecté avant qu'il ne devienne un ticket. Au lieu de dépendre uniquement du marqueur de l'objet, il lit les en-têtes standard de messagerie (RFC 5322) et applique une décision hiérarchique en trois stratégies :
- Analyse des References - vérifie si l'e-mail cite un
Message-IDgénéré par GLPI lui-même (formatGLPI_*). S'il le cite, c'est une réponse légitime au ticket et elle devient un suivi. - Analyse de In-Reply-To - si
In-Reply-Topointe vers l'e-mail d'un tiers déjà enregistré par le module, et non vers unMessage-IDde GLPI, le message est identifié comme une chaîne de copie et bloqué. - Vérification du premier e-mail - le repli : si le ticket n'a encore aucun e-mail enregistré, ce message est traité comme l'original et autorisé.
Sur cette base, trois réglages contrôlent le comportement dans les environnements réels :
- Thread-Index - améliore la détection des chaînes dans les environnements Microsoft (Outlook/Exchange), qui utilisent cet en-tête propre en plus de
In-Reply-To. - Block Chain Emails - un mode plus agressif qui bloque activement les réponses de tiers en copie. Recommandé pour les opérations à fort volume, avec parcimonie.
- Modèle de notification - quand un e-mail est bloqué, l'expéditeur reçoit un avis configurable expliquant la raison, ce qui préserve la transparence.
Les en-têtes qui décident
En pratique, la différence entre un suivi et un doublon tient à deux lignes d'en-tête. L'exemple ci-dessous montre les deux cas côte à côte :
# Reponse legitime au ticket : l'en-tete References cite le Message-ID de GLPI (GLPI_*)
# --> Mail Analyzer la traite comme un SUIVI du ticket d'origine
Subject: [GLPI #0004521] Imprimante finance sans toner
Message-ID: <a1b2c3@mail.client.com>
In-Reply-To: <GLPI_7f3a9@support.entreprise.com>
References: <GLPI_7f3a9@support.entreprise.com>
# Un tiers en copie a clique sur "Repondre a tous" :
# In-Reply-To pointe vers l'e-mail d'un AUTRE utilisateur, pas vers un Message-ID de GLPI
# --> Mail Analyzer BLOQUE la creation d'un ticket en double
Subject: RE: Imprimante finance sans toner
Message-ID: <d4e5f6@mail.responsable.com>
In-Reply-To: <a1b2c3@mail.client.com>
References: <a1b2c3@mail.client.com>Fonction du module face au comportement natif
| Situation | Collecteur natif de GLPI | Avec Mail Analyzer |
|---|---|---|
| La réponse garde le marqueur [GLPI #id] dans l'objet | Devient un suivi du ticket | Devient un suivi du ticket |
| Un tiers en copie répond "à tous" et l'objet est réécrit | Ouvre un nouveau ticket (doublon) | Reconnaît la chaîne via References/In-Reply-To et ne duplique pas |
| Environnement Exchange regroupant par Thread-Index | Dépend seulement de l'objet et de In-Reply-To | Utilise aussi le Thread-Index pour relier la conversation |
| E-mail bloqué car issu d'une chaîne de copie | Non applicable | L'expéditeur reçoit une notification configurable |
| Premier e-mail d'un nouveau sujet | Ouvre un ticket | Le reconnaît comme l'original et autorise l'ouverture |
Comment l'activer
- Installez le plugin NexTool dans GLPI et confirmez que la collecte de messagerie (récepteurs) fonctionne déjà.
- Allez dans Configuration > NexTool > Modules.
- Activez le module Mail Analyzer.
- Réglez Thread-Index et Block Chain Emails selon le profil de l'environnement.
- Définissez le modèle de notification pour les e-mails bloqués.
Ce que nous avons appris en maintenance
En maintenance des collecteurs de messagerie chez les clients, l'erreur qui génère le plus de doublons n'est pas une subtilité de GLPI, elle est comportementale : le responsable en copie répond depuis son téléphone, l'application réécrit l'objet et le marqueur disparaît. Avant Mail Analyzer, la "solution" consistait à demander aux gens de ne pas modifier l'objet, ce qui ne marche jamais. Nous avons déplacé la solution à la source, en lisant References et In-Reply-To, que le client de messagerie conserve même quand l'objet change. Le détail qu'on ne voit qu'en exploitation : dans les environnements Exchange, activer le Thread-Index fait une vraie différence, car Outlook regroupe la conversation par cet en-tête et ne garde pas toujours un In-Reply-To propre. Et une recommandation de terrain : activez Block Chain Emails progressivement et toujours avec le modèle de notification configuré, sinon un e-mail légitime d'un tiers est bloqué en silence et personne ne s'en aperçoit avant que le client ne réclame.
Pour qui (et quand ne pas l'utiliser)
Mail Analyzer s'adresse à tout service desk qui ouvre des tickets par collecte de messagerie et fonctionne dans un environnement d'entreprise, en particulier :
- Les entreprises où les responsables et les parties prenantes sont systématiquement mis en copie des fils de support ;
- Les opérations à fort turnover d'analystes, où les doublons passent inaperçus ;
- Les MSP qui servent plusieurs clients et ont besoin d'un historique organisé par entreprise ;
- Les équipes qui dépendent d'un historique consolidé pour l'audit et la conformité.
Il n'y a aucun intérêt à l'activer si vous n'utilisez pas la collecte de messagerie : si les tickets n'arrivent que par le catalogue de services ou un formulaire, il n'y a pas de message à intercepter. Et prudence avec Block Chain Emails dans les petites opérations, où le doublon est rare, car le mode agressif peut bloquer un e-mail de tiers qui devrait bel et bien devenir un nouveau ticket.
Compatibilité
- GLPI : 10.x et 11.x
- Plan : FREE
- Plugin : NexTool 3.x ou supérieur
- PHP : 8.0+
Mail Analyzer fait partie de NexTool, un plugin modulaire pour GLPI. Pour voir le module dans votre scénario de collecte de messagerie, parlez à l'équipe.
Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.
