Détection automatique des problèmes ITIL dans GLPI

Le module Problem Flow lit les incidents résolus dans GLPI, détecte une concentration par catégorie et entité dans une fenêtre de temps et crée le Problème ITIL automatiquement dès que le motif atteint le seuil - avec un déclencheur en temps réel, un cron et un journal traçable.

Les incidents qui reviennent sont le symptôme d'un problème que personne n'a encore ouvert. Dans GLPI, remarquer que dix tickets de la même catégorie sont tombés sur la même entité en deux semaines 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, sur la même entité, 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 automatiquement les tickets déjà résolus et clôturés, en cherchant une concentration par catégorie et entité dans une fenêtre de temps configurable. Quand le nombre d'occurrences atteint le seuil de la règle, un Problème ITIL est créé dans GLPI, déjà contextualisé.

  • Déclencheurs doubles - l'évaluation s'exécute en temps réel, à la clôture ou à la résolution d'un ticket, et aussi via un cron périodique, assurant la couverture même lors des pics de volume.
  • Règles configurables - chaque règle définit le nombre minimum de tickets, la période d'analyse, la catégorie et l'entité surveillée. Plusieurs règles coexistent pour couvrir des scénarios différents.
  • Périmètre ciblé - le module analyse uniquement les tickets de type Incident, en cohérence avec la pratique ITIL d'associer les Problèmes aux incidents répétitifs.
  • Traçabilité complète - chaque détection est enregistrée dans le journal du module, avec la référence aux tickets qui ont déclenché la règle et au Problème généré.

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;

C'est ce travail, répété pour chaque fenêtre et chaque règle, que le module prend en charge, sans dépendre de quelqu'un qui pense à lancer le rapport.

Fonction du module face au comportement natif

Étape de la gestion des problèmesGLPI natifAvec Problem Flow
Détecter la récurrence par catégorie et entitéManuel : quelqu'un doit consulter rapports et tableaux de bordAutomatique par règle, en temps réel et via cron
Ouvrir le Problème ITILManuel : le technicien le crée et lie les incidentsCréé automatiquement quand le seuil est atteint
Périmètre de l'analyseTout type de ticket, sans critèreRestreint aux Incidents, en cohérence avec ITIL
Traçabilité de la décisionDépend d'une note manuelleJournal avec les tickets sources et le Problème généré
Preuve de maturité ITSMDifficile à prouverTrace enregistrée que le processus est actif

Comment l'activer

  1. Installez le plugin NexTool dans GLPI.
  2. Allez dans Configuration > NexTool > Modules.
  3. Activez le module Problem Flow.
  4. Enregistrez les règles de détection : catégorie, entité, seuil de tickets et fenêtre de temps.
  5. Surveillez le journal du module les premières semaines pour calibrer le seuil avant de faire pleinement confiance à l'automatisation.

Ce que nous avons appris en maintenance

En maintenance d'opérations ITIL, Problem Flow réussit ou échoue sur le calibrage du seuil, pas sur la technologie. Un seuil 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, d'observer le journal pendant deux ou trois semaines et de ne resserrer qu'ensuite. 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 clôturés est la bonne. Ensuite, l'erreur de terrain la plus fréquente est de pointer la règle sur une catégorie parente en espérant additionner les enfants : comme le comptage se fait par la catégorie choisie, des incidents dispersés dans des sous-catégories sœurs ne se regroupent pas, et la règle semble "ne pas marcher" alors qu'elle regarde en réalité le mauvais niveau de l'arbre.

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 ou équipes réparties ;
  • Les responsables qui ont besoin d'une trace traçable 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 seuil 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, la confiance ensuite.

Compatibilité

  • GLPI : 10.0+ et 11.0+
  • Plan : Enterprise
  • Plugin : NexTool 3.x ou supérieur

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.


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

Questions fréquentes

Pas nativement. GLPI dispose de l'itemtype Problème et permet de lier des incidents, mais détecter la récurrence est manuel : quelqu'un doit remarquer le motif. Le module Problem Flow analyse les incidents résolus par catégorie et entité et crée le Problème ITIL automatiquement dès que le seuil configuré est atteint.

Chaque règle définit quatre critères : catégorie, entité, nombre minimum de tickets et fenêtre de temps. Le module compte les incidents résolus et clôturés qui correspondent à la règle dans la fenêtre ; quand le compte atteint le seuil, le Problème est ouvert et lié.

Les deux. L'évaluation s'exécute en temps réel à la clôture ou à la résolution d'un ticket et aussi via un cron périodique. Le déclencheur double assure la couverture même lors des pics de volume, quand beaucoup de tickets sont clôturés en même temps.

Seulement les incidents (tickets de type Incident). Cela correspond à la pratique ITIL d'associer les Problèmes aux incidents répétitifs ; les demandes de service ne sont pas comptées.

Commencez prudemment, avec un seuil plus élevé, surveillez le journal du module pendant deux ou trois semaines et ajustez. Un seuil trop bas devient du bruit ; trop haut ne se déclenche jamais. Et pointez la règle sur la bonne catégorie : comme le comptage se fait par la catégorie choisie, une catégorie parente n'additionne pas automatiquement les incidents de ses sous-catégories.

Besoin d'aide ?