Quand une règle de ticket dans GLPI ne fait pas ce qu'elle devrait, le diagnostic consomme souvent des heures de celui qui administre l'environnement. Le module Rule Inspector de NexTool inverse ce travail : au lieu d'ouvrir les règles une par une dans le gestionnaire, il montre, dans le ticket lui-même, quelles règles de ticket ont été évaluées, lesquelles ont correspondu et pourquoi.
Le problème
Les règles métier de ticket comptent parmi les fonctions les plus puissantes de GLPI : elles affectent des techniciens, définissent la catégorie et le SLA, déclenchent des notifications et ferment même des tickets. Mais quand quelque chose ne marche pas - un ticket arrivé sans technicien, une catégorie non appliquée, un SLA qui n'a jamais pris - le diagnostic se fait à la main. L'administrateur ouvre le gestionnaire de règles, lit critère par critère, vérifie l'ordre d'exécution et tente de reconstituer de mémoire ce qui s'est passé à l'instant où ce ticket est entré. Dans des environnements comptant des dizaines ou des centaines de règles héritées d'années d'exploitation, cela devient une chasse au trésor.
Ce qui aggrave la chose, c'est que la règle qui "ne s'est pas appliquée" a presque toujours correspondu partiellement. Elle a correspondu, mais a perdu face à une règle de rang inférieur ayant l'action "Arrêter le traitement des règles" activée - et à partir de là aucune règle suivante ne s'exécute. Sans un outil qui montre l'évaluation dans le contexte du ticket, ce détail passe inaperçu.
Comment fonctionne Rule Inspector
Une fois le module installé et activé, un onglet Rules apparaît sur chaque ticket. Vous y disposez de :
- Évaluer les règles - un clic évalue toutes les règles de ticket actives dans l'entité du ticket et montre lesquelles ont été appliquées, lesquelles ont correspondu sans s'exécuter et lesquelles ont échoué aux critères, avec le détail de chaque critère évalué.
- Persistance par ticket - le résultat est enregistré sur le ticket. À la réouverture, le bouton devient "Relancer l'évaluation", signalant qu'une évaluation antérieure existe déjà pour comparer.
- Test par ID - sur la page autonome du module, l'onglet Test permet de saisir n'importe quel numéro de ticket et de voir quelles règles sont vraies pour lui, sans ouvrir le ticket.
- Historique filtré par entité - l'onglet Historique liste toutes les évaluations, restreintes aux entités que l'utilisateur peut voir. Aucune fuite de données entre entités.
- Export CSV - l'historique s'exporte en CSV avec une colonne de critères au format
criteria | condition | value, prête pour l'audit et le reporting.
L'évaluation traite jusqu'à 1000 règles à la fois, triées par rang, avec un indicateur visuel quand cette limite est atteinte - pertinent dans les environnements ayant accumulé des règles au fil du temps.
Ce que GLPI stocke en dessous
Pour comprendre pourquoi le diagnostic manuel est pénible, il faut regarder comment les règles se présentent dans la base. La requête ci-dessous liste les règles de ticket actives, par rang, avec leurs critères. Exécutez-la sur un réplica de lecture ou pendant une fenêtre de faible activité :
-- Regles de ticket actives, par rang, avec leurs criteres.
-- criteria et condition sont des codes numeriques, pas du texte lisible.
SELECT r.ranking,
r.name AS regle,
rc.criteria AS critere_cod,
rc.condition AS condition_cod,
rc.pattern AS valeur
FROM glpi_rules r
JOIN glpi_rulecriterias rc ON rc.rules_id = r.id
WHERE r.sub_type = 'RuleTicket'
AND r.is_active = 1
ORDER BY r.ranking, rc.id;Le résultat explique déjà la douleur : criteria pointe vers un champ interne de la règle et condition est un code (par exemple, "est égal à", "n'est pas égal à", "expression régulière"). Lire cela à l'œil nu suppose de décoder table par table et de croiser avec l'ordre de rang. Rule Inspector livre cette même information déjà décodée et, surtout, évaluée face à un ticket réel.
Diagnostic manuel vs Rule Inspector
| Critère | Diagnostic manuel dans GLPI | Rule Inspector |
|---|---|---|
| Où vous enquêtez | Gestionnaire de règles, une par une, ou SQL brut | Onglet Rules dans le ticket lui-même |
| Contexte | Vous simulez les valeurs du ticket de tête | Évalue face au ticket réel, ouvert à l'écran |
| Lecture des critères | Codes numériques à décoder | Format lisible criteria | condition | value |
| Correspondance vs exécution | Difficile à distinguer l'une de l'autre | Sépare appliquées, correspondance sans exécution et échouées |
| Ordre / rang | Reconstituer de mémoire | Évaluées par rang, avec la limite signalée |
| Audit | Export manuel, au cas par cas | Export CSV et historique filtré par entité |
Comment l'activer
- Installez le plugin NexTool sur votre GLPI.
- Allez dans Configuration > NexTool > Modules.
- Activez le module Rule Inspector.
- Synchronisez les permissions depuis le panneau NexTool pour que les bons profils commencent à voir l'onglet Rules sur le ticket.
Pour qui - et quand ne pas l'utiliser
Rule Inspector s'adresse à qui configure et maintient les règles de ticket : administrateurs validant une nouvelle règle, analystes qualité auditant les affectations automatiques, responsables de service desk cherchant pourquoi certains tickets n'obtiennent pas de catégorie ou de SLA, et équipes venant de migrer de version qui doivent confirmer que les règles tiennent toujours.
Ce n'est pas le bon outil si votre environnement n'utilise pas de règles de ticket, ou si la question porte sur un autre type de règle GLPI - dictionnaires de listes déroulantes, règles d'import d'actifs, affectation de droits par LDAP. Le module se concentre sur ce qui s'exécute quand un ticket naît ou change.
Ce que nous avons appris en le maintenant
En maintenance d'environnements comptant beaucoup de règles, le ticket qui "n'a pas été affecté" n'est presque jamais un bug de GLPI : c'est l'ordre de rang. Nous avons ouvert des dizaines de tickets où la bonne règle était parfaitement correcte, mais une règle antérieure - rang inférieur, donc évaluée en premier - avait l'action d'arrêt du traitement et coupait la file avant de l'atteindre. Sans voir l'évaluation dans le contexte du ticket, le client jure que la règle "a disparu", alors qu'en réalité elle n'a jamais eu la chance de s'exécuter. Le deuxième schéma récurrent est l'entité : quelqu'un crée la règle sur l'entité fille en croyant qu'elle vaut partout, mais le ticket est entré par une autre entité et la règle n'était tout simplement pas dans le périmètre. Rule Inspector raccourcit ce diagnostic d'heures à secondes parce qu'il montre, pour ce ticket précis, ce qui a correspondu et ce qui a été bloqué - y compris quand le coupable est une règle d'arrêt trois positions plus haut.
Compatibilité
- GLPI : 10.x et 11.x
- Plan : FREE
- Plugin : NexTool 3.x+
Rule Inspector fait partie de NexTool, plugin modulaire pour GLPI. Découvrez les autres modules ou 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.
