Les incidents qui reviennent sont le symptôme d'un problème que personne n'a encore ouvert. Dans GLPI, remarquer que dix tickets Wi-Fi sont tombés sur la même agence en deux semaines, ou que le même équipement revient dans la file pour la quatrième fois, dépend de quelqu'un qui regarde le bon rapport au bon moment. Le module Problem Flow fait cette lecture tout seul et crée le Problème ITIL automatiquement dès que le motif se confirme.
Le problème : le pont entre incident et problème est manuel
Quiconque exploite ITIL sait que les Problèmes sont la cause racine derrière les incidents répétés. GLPI dispose de l'itemtype Problème et permet d'y lier des incidents, mais il ne détecte pas la récurrence : cette partie est humaine. Quelqu'un doit remarquer que plusieurs tickets partagent la même catégorie, le même lieu ou le même équipement, dans la même fenêtre de temps - et seulement alors créer le Problème et lier les incidents.
Cet écart a un coût. L'intervalle entre l'apparition du motif et l'ouverture du Problème se remplit de nouveaux incidents, de reprises et de charge sur la file. Dans les opérations à fort volume, le motif passe souvent inaperçu jusqu'à ce que l'impact soit déjà important - et alors la question du responsable est toujours la même : "pourquoi personne ne l'a vu plus tôt ?".
Comment fonctionne Problem Flow
Le module évalue les tickets déjà résolus et clos et détecte les incidents récurrents avec des règles au format de GLPI : catégorie, lieu, élément associé, type de solution, priorité, source de la demande, groupes, demandeur et texte du titre, de la description ou de la solution. Lorsque le minimum de tickets de la règle est atteint sur la période, un Problème ITIL est ouvert dans GLPI avec les tickets qui l'ont provoqué déjà liés.
- Déclencheurs doubles - l'évaluation s'exécute chaque fois qu'un ticket est résolu ou clos, et aussi par l'action automatique de GLPI, toutes les 6 heures par défaut, assurant la couverture même lors des pics de volume.
- Règles au format de GLPI - chaque règle définit les critères, avec les mêmes opérateurs que les règles natives (y compris "sous", pour les sous-catégories et sous-lieux), le minimum de tickets sur la période, comment regrouper (élément, lieu, catégorie, groupe de techniciens, demandeur ou service), le minimum de demandeurs distincts, l'intervalle minimal entre Problèmes et la création du Problème (titre, gabarit, catégorie, urgence, impact, groupe de techniciens, technicien, groupe observateur). Plusieurs règles coexistent pour couvrir des scénarios différents.
- Un Problème par cause commune - en regroupant par lieu avec un minimum de 5, cinq incidents Wi-Fi à l'agence Centre et cinq à l'agence Nord ouvrent deux Problèmes, un par agence. Le minimum de demandeurs distincts évite qu'une seule personne déclenche l'alerte, et l'intervalle minimal empêche les Problèmes répétés.
- 27 modèles prêts, inactifs - le même équipement en panne à répétition ; Wi-Fi, impression, électricité et téléphonie sur un même lieu ; messagerie, VPN, connexion, sauvegarde, sécurité et certificat numérique ; même catégorie ; solutions de contournement récurrentes ; et tout incident critique. Ils arrivent désactivés : vous n'activez que ce qui a du sens dans votre environnement.
- Solutions de contournement récurrentes - l'un des modèles lit le texte de la solution des tickets : quand la même solution de contournement se répète, elle devient un Problème, le "candidat à l'erreur connue" de l'ITIL.
- Bouton Tester - simule la règle sur les tickets de la période sans rien créer : il montre chaque groupe, le nombre de tickets et de demandeurs comptés face au minimum et l'aperçu du Problème qui serait ouvert.
- Périmètre aligné sur l'ITIL - les 27 modèles prêts ne comptent que les incidents, comme le recommande l'ITIL ; dans une règle à vous, le type de ticket est un critère que vous choisissez.
- Traçabilité complète - pour chaque détection, l'onglet Logs enregistre la règle, le Problème généré, le groupe et les tickets qui l'ont provoqué.
Le motif que le module automatise
Pour comprendre ce que fait Problem Flow, il est utile de voir la détection faite à la main. La requête ci-dessous liste, par catégorie et entité, les incidents résolus ou clôturés sur les 30 derniers jours et met en évidence les groupes ayant cinq occurrences ou plus - précisément les candidats à devenir un Problème. Exécutez-la sur un réplica de lecture ou pendant une fenêtre de faible activité :
-- Detection MANUELLE du motif que Problem Flow automatise :
-- incidents resolus/clotures sur les 30 derniers jours, groupes par categorie et entite.
-- Les groupes ayant 5+ occurrences sont candidats a devenir un Probleme ITIL.
SELECT c.completename AS categorie,
e.completename AS entite,
COUNT(*) AS occurrences
FROM glpi_tickets t
JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
JOIN glpi_entities e ON e.id = t.entities_id
WHERE t.type = 1 -- 1 = Incident
AND t.status IN (5, 6) -- 5 = Resolu, 6 = Cloture
AND t.is_deleted = 0
AND t.solvedate >= NOW() - INTERVAL 30 DAY
GROUP BY t.itilcategories_id, t.entities_id
HAVING COUNT(*) >= 5
ORDER BY occurrences DESC;Le module fait ce travail tout seul, à chaque évaluation et pour chaque règle, et pas seulement par catégorie et entité : n'importe quelle combinaison de critères convient (lieu, élément associé, demandeur, texte de la solution et les autres), avec le comptage séparé selon le regroupement que vous choisissez et sans dépendre de quelqu'un qui pense à lancer le rapport.
Fonction du module face au comportement natif
| Étape de la gestion des problèmes | GLPI natif | Avec Problem Flow |
|---|---|---|
| Détecter la récurrence | Manuel : quelqu'un doit consulter rapports et tableaux de bord | Automatique par règle, avec n'importe quelle combinaison de critères, à la résolution ou à la clôture du ticket et par l'action automatique |
| Calibrer avant d'automatiser | Inexistant : le résultat ne se voit qu'après coup | Le bouton Tester simule la règle sur les tickets de la période sans rien créer |
| Ouvrir le Problème ITIL | Manuel : le technicien le crée et lie les incidents | Ouvert quand le minimum est atteint, avec les tickets liés et les champs définis par les actions de la règle |
| Périmètre de l'analyse | Tout type de ticket, sans critère | Le type de ticket est un critère de la règle ; les 27 modèles prêts ne comptent que les incidents |
| Éviter les Problèmes répétés | Dépend de quelqu'un qui cherche avant d'ouvrir | Intervalle minimal entre Problèmes et tickets déjà liés ignorés |
| Traçabilité de la décision | Dépend d'une note manuelle | Onglet Logs avec la règle, le groupe, les tickets et le Problème généré |
| Preuve de maturité ITSM | Difficile à prouver | Trace enregistrée que le processus est actif |
Comment l'activer
- Avec le plugin NexTool installé sur GLPI 11, allez dans NexTool > Modules et activez Problem Flow.
- Dans l'onglet Règles, choisissez l'un des 27 modèles prêts (ils arrivent inactifs) ou créez votre propre règle.
- Cliquez sur Tester : la simulation s'exécute sur les tickets de la période et ne crée rien.
- Une fois le résultat calibré, activez la règle.
- Suivez l'onglet Logs pour voir quelle règle a ouvert chaque Problème, pour quel groupe et avec quels tickets.
Ce que nous avons appris en maintenance
En maintenance d'opérations ITIL, Problem Flow réussit ou échoue sur le calibrage du minimum de tickets, pas sur la technologie. Un minimum trop bas et le module génère un Problème par catégorie par semaine, devenant un bruit que personne ne traite ; trop haut et il ne se déclenche jamais, et vous revenez à la détection manuelle. Nous avons standardisé le fait de commencer prudemment et de passer par le bouton Tester avant d'activer : la simulation montre, sur vos propres tickets, chaque groupe que la règle formerait, le nombre de tickets et de demandeurs comptés face au minimum et l'aperçu du Problème. L'ajustement se fait là, sans rien créer, au lieu d'attendre des semaines de journal. Deux détails qu'on ne voit qu'en exploitation : d'abord, compter les tickets encore ouverts gonfle le nombre, car le même incident rouvert apparaît plusieurs fois - c'est pourquoi l'analyse sur les tickets résolus et clos est la bonne. Ensuite, l'erreur de terrain la plus fréquente consistait à pointer la règle sur une catégorie parente en espérant additionner les enfants, puis à voir les incidents dispersés dans des sous-catégories sœurs ne pas se regrouper. Dans les règles actuelles, l'opérateur règle la question : utilisez "sous" pour inclure les sous-catégories ; avec "est", seule la catégorie choisie compte. Il en va de même pour les lieux.
Pour qui (et quand ne pas l'utiliser)
Problem Flow s'adresse aux opérations qui adoptent formellement ITIL et veulent combler l'écart entre gestion des incidents et gestion des problèmes, en particulier :
- Les environnements à fort volume, où la détection manuelle des motifs est impraticable ;
- Les opérations à plusieurs entités, agences ou équipes réparties ;
- Les responsables qui ont besoin d'une trace vérifiable de maturité ITSM pour l'audit.
Il n'a aucun intérêt dans les opérations qui ne pratiquent pas encore la gestion des problèmes ou dont le volume est très faible : le minimum sera rarement atteint et le module reste inactif. Et mal calibré, il produit trop de Problèmes que l'équipe ne peut pas traiter - l'effet secondaire est une file de Problèmes abandonnés, pire que de ne pas avoir l'automatisation. Le calibrage d'abord (le bouton Tester sert à cela), la confiance ensuite.
Compatibilité
- GLPI : 11
- Plan : module sous licence
- Plugin : NexTool 6.24.1 ou supérieur (la version publique actuelle convient)
Problem Flow fait partie de NexTool, un plugin modulaire pour GLPI. Pour mettre en place une gestion des problèmes ITIL avec détection automatique et traçable, parlez à l'équipe.
Révisé par l'équipe NexTool Solutions.
