NexTool Solutions

Certains processus engendrent toujours un ticket dérivé - et chaque fois que l'étape est oubliée, le processus échoue en silence. Le module Ticket Flow de NexTool transforme cet enchaînement en automatisation : lorsqu'un ticket remplit un critère, il crée le ticket suivant à partir d'un modèle natif de GLPI, sans intervention humaine.

Le problème

Beaucoup de catégories de ticket suivent toujours le même scénario. Quand un ticket "Contrat de Service" est ouvert, un ticket "Approbation Financière" devrait naître automatiquement. Quand un ticket "Maintenance" est résolu, une "Enquête de Qualité" devrait apparaître. Dans un GLPI standard, cette orchestration vit dans la mémoire du technicien - quand il s'en souvient. Le résultat est connu : étapes sautées, processus incomplets et audit impossible, car il n'existe aucune trace des sous-processus qui auraient dû être ouverts.

Soyons honnêtes sur ce que GLPI fait déjà. Les règles métier de ticket (RuleTicket) sont excellentes pour router, affecter et catégoriser - mais elles agissent sur le ticket même en cours de création ou de mise à jour. Aucune règle native ne crée un nouveau ticket à partir d'un autre. C'est précisément la lacune que Ticket Flow comble.

Comment fonctionne Ticket Flow

Le module permet de configurer des flux qui déclenchent la création d'un nouveau ticket lorsqu'un ticket d'origine remplit un critère. Chaque flux est lié à une catégorie ITIL et à un événement déclencheur, et utilise les modèles de ticket natifs de GLPI pour générer le ticket dérivé :

• 3 déclencheurs configurables - ticket créé, ticket résolu et ticket fermé. Chaque catégorie n'admet qu'un seul flux actif, ce qui supprime toute ambiguïté sur la règle qui s'applique.
• Intégration avec TicketTemplate - le ticket enfant naît d'un modèle natif de GLPI, héritant de la catégorie, du titre, de la description, des groupes et de la priorité déjà configurés dans le modèle.
• Moteur via hooks natifs - l'exécution est automatique via les hooks item_add et item_update de Ticket, sans dépendre d'un cron ni d'une action manuelle.
• Garde anti-boucle - un mécanisme interne empêche le ticket généré de redéclencher le moteur, coupant le risque de récursion infinie.
• Journal d'exécution - chaque déclenchement est enregistré avec un lien vers le ticket d'origine et vers le ticket généré, créant une traçabilité complète.
• Onglet de test - on peut simuler la création d'un ticket à partir d'un modèle sur l'écran de configuration lui-même, avant de mettre le flux en production.

Pourquoi le modèle de ticket est le cœur du flux

Comme le ticket enfant est généré à partir d'un TicketTemplate, la qualité du flux dépend entièrement de la façon dont le modèle est renseigné. Avant de mettre un flux en production, il vaut la peine d'auditer les champs prédéfinis de vos modèles. La requête ci-dessous liste les modèles de ticket et leurs champs prédéfinis - si le champ de groupe ou de responsable est vide, l'enfant naît orphelin :

-- Modeles de ticket et leurs champs predefinis.
-- Ticket Flow recopie ces valeurs dans le ticket enfant.
-- Champ essentiel laisse vide (groupe/responsable) = enfant orphelin.
SELECT tt.id            AS modele_id,
       tt.name          AS modele,
       tp.num           AS champ_num,
       tp.value         AS valeur_predefinie
FROM glpi_tickettemplates tt
LEFT JOIN glpi_tickettemplatepredefinedfields tp
       ON tp.tickettemplates_id = tt.id
ORDER BY tt.name, tp.num;

Chaque ligne est un champ prédéfini du modèle. La valeur de num est l'option de recherche de GLPI (titre, catégorie, groupe demandeur, groupe attribué, priorité). Un modèle sans groupe attribué génère un ticket enfant que personne ne voit dans la file - et le processus se bloque exactement là où il devrait avancer.

Ticket Flow vs fonctions natives de GLPI

Comment l'activer

1. Installez le plugin NexTool sur votre GLPI.
2. Allez dans Configuration > NexTool > Modules.
3. Activez Ticket Flow et cliquez sur Configurer.
4. Dans l'onglet Flux, créez un flux en choisissant la catégorie, le déclencheur et le modèle du ticket enfant.
5. Activez le moteur d'automatisation dans l'onglet des paramètres et validez le comportement dans l'onglet de test avant la production.

Pour qui - et quand ne pas l'utiliser

Ticket Flow s'adresse aux équipes avec des processus structurés où l'ouverture d'un ticket est une condition pour qu'un autre démarre : gestion des changements, achats, projets et processus qualité, où oublier une étape a un impact réel sur l'exploitation et l'audit.

Ce n'est pas le bon outil quand vous avez besoin d'enchaîner des tâches dans le même ticket (un flux de sous-tâches le fait), ni quand la logique consiste simplement à affecter ou catégoriser le ticket lui-même - les règles métier natives s'en chargent déjà. Ticket Flow prend toute sa valeur justement quand un processus doit générer un autre ticket, avec son propre responsable et sa propre échéance.

Ce que nous avons appris en le maintenant

En maintenance, l'erreur numéro un de Ticket Flow n'est jamais dans le moteur : c'est le modèle du ticket enfant sans groupe attribué - l'enfant naît sans responsable et disparaît de la file. La deuxième est d'oublier qu'un seul flux par catégorie reste actif, si bien que deux processus qui dépendent de la même catégorie se disputent la même place. La troisième est la plus sournoise : le déclencheur "fermé" s'active aussi quand GLPI ferme le ticket de lui-même, via la routine de fermeture automatique pour inactivité (le cron d'autoclose). Nous avons vu un client se réveiller avec une fournée de tickets enfants créés dans la nuit, parce qu'un lot de vieux tickets a été fermé par la routine et que chaque fermeture a déclenché le flux. La recommandation que nous avons standardisée : réservez le déclencheur "fermé" aux processus qui doivent vraiment tourner à la fermeture, préférez "résolu" quand l'intention est de réagir à la résolution, et validez toujours le modèle enfant dans l'onglet de test avant d'allumer le moteur.

Compatibilité

• GLPI : 10.0+ et 11.0+
• Plan : PAID
• Plugin : NexTool 3.x+

Ticket Flow fait partie de NexTool, un écosystème de modules pour étendre GLPI sans personnalisation de code. Parlez à l'équipe pour une démonstration.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.