NexTool Solutions

La gestion des incidents est la pratique ITSM que le plus de gens croient maîtriser et celle qui casse le plus en exploitation réelle. En infogérance d'environnements GLPI clients, le problème n'est presque jamais un technicien incapable de clôturer un ticket : c'est le SLA dépassé sans que personne ne soit alerté, la priorité que quelqu'un a modifiée à la main et le cron qui tourne dans le mauvais mode. Ce guide montre où vit l'incident dans GLPI, comment le classer sans inventer de champ, et les pièges de terrain qui n'apparaissent qu'après des mois d'exploitation.

Où vit l'incident dans GLPI

Incident et demande ne sont pas des modules distincts : c'est le même objet Ticket, dans la table glpi_tickets, distingués par la colonne type - 1 pour incident, 2 pour demande. Ce qui change, c'est le flux, le SLA et la lecture managériale. Selon ITIL 4, un incident est une interruption non planifiée ou une réduction de la qualité d'un service, et l'objectif est de rétablir le service le plus vite possible, pas d'en trouver la cause - cela relève de la gestion des problèmes.

Tout incident parcourt une machine à états fixe. Connaître le code de chaque statut compte car les rapports, les règles métier et le SQL de diagnostic travaillent avec le numéro, pas avec le libellé :

Le détail qui fausse un rapport : le statut En attente (4) suspend le décompte du SLA quand vous le configurez ainsi. Le technicien qui met tout En attente pour "ne pas dépasser le délai" masque l'indicateur, il n'améliore pas le service.

Classification : la matrice Urgence × Impact

GLPI ne laisse pas le technicien choisir la priorité dans le vide. Elle est calculée par le croisement de deux champs renseignés par le demandeur et le trieur : urgence (à quelle vitesse le métier en a besoin) et impact (combien de personnes touchées et à quel point c'est critique). La matrice se trouve dans Configuration > Général > Assistance et est entièrement modifiable. Un extrait simplifié de la logique :

GLPI gère jusqu'à cinq niveaux d'urgence et d'impact, plus la priorité Majeure (critique). La matrice par défaut est symétrique : urgence et impact pèsent autant. Ajustez les poids à la réalité du client : dans le commerce, une caisse hors service en heure de pointe est une urgence maximale, quel que soit le nombre de magasins touchés.

Le flux de traitement, étape par étape

1. Enregistrement : portail self-service, e-mail (collecteur), téléphone ou intégration. Les règles métier (RuleTicket) classent catégorie, groupe et priorité automatiquement au item_add.
2. Prise en compte (première réponse) : GLPI enregistre dans takeintoaccount_delay_stat le temps jusqu'à la première action du technicien. C'est votre SLA de prise en charge (TTO - time to own), distinct du SLA de résolution (TTR - time to resolve).
3. Investigation : base de connaissances, historique de tickets similaires et CMDB. Le module AI Assist résume les longs fils et suggère des solutions depuis la base.
4. Résolution : définitive (cause corrigée) ou contournement (workaround). Si c'est un contournement récurrent, liez-le à un Problème - un incident ne "devient" pas un problème, ce sont des objets distincts.
5. Clôture : après confirmation, le ticket passe à Clos et déclenche l'enquête de satisfaction.

Le piège nº 1 de l'infogérance : le cron dans le mauvais mode

C'est la panne que nous traitons le plus souvent chez un nouveau client. Le SLA est configuré, les niveaux d'escalade sont créés, et pourtant personne n'est alerté quand le délai est dépassé et les tickets résolus ne se clôturent jamais seuls. La cause est presque toujours la même : les actions automatiques de GLPI sont en mode GLPI (web), qui ne s'exécute que quand quelqu'un charge une page. Chez un client à faible trafic hors heures ouvrées, l'escalade de SLA ne tourne tout simplement pas.

La correction consiste à mettre le planificateur en mode CLI, déclenché par un cron du système d'exploitation. Sur chaque action automatique (Configuration > Actions automatiques), réglez Mode d'exécution = CLI et ajoutez l'entrée dans le crontab :

# /etc/cron.d/glpi - execute le planificateur GLPI chaque minute
# GLPI 10 et 11 : front/cron.php est le chemin portable entre versions
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Dépendent de ce cron pour fonctionner : closeticket (clôture automatiquement ce qui est resté Résolu au-delà du délai), createinquest (génère l'enquête de satisfaction) et l'escalade par niveau de SLA. Un détail de portabilité qui piège beaucoup de monde : GLPI 11 n'a pas la commande console glpi:cron que citent certains tutoriels GLPI 10 - le chemin qui fonctionne dans les deux versions est le front/cron.php ci-dessus.

Diagnostic : trouver les incidents qui dépassent le SLA

Quand le client dit "le SLA ne tient pas", la première étape est de regarder la donnée brute, pas le tableau de bord. Ce SQL liste les incidents ouverts dont le délai de résolution est déjà dépassé et signale ceux qui n'ont même jamais été pris en compte (takeintoaccount_delay_stat = 0) :

SELECT t.id,
       t.name AS titre,
       c.completename AS categorie,
       t.priority,
       t.time_to_resolve,
       IF(t.takeintoaccount_delay_stat = 0,
          'SANS PREMIERE REPONSE', 'ok') AS traitement
FROM glpi_tickets t
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.is_deleted = 0
  AND t.type = 1                       -- 1 = incident
  AND t.status NOT IN (5, 6)           -- exclut Resolu et Clos
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()        -- delai de resolution deja depasse
  AND t.solvedate IS NULL
ORDER BY t.time_to_resolve ASC;

En exécutant cela en infogérance, le motif qui ressort le plus n'est pas un fort volume de tickets : c'est une poignée d'incidents à haute priorité bloqués En attente depuis des jours, l'horloge "en pause", tandis que le demandeur croit qu'ils sont traités.

Une notification d'escalade que le manager lit vraiment

Le modèle d'escalade par défaut envoie un bloc générique. Un modèle épuré, avec les bonnes balises, fait agir le superviseur sans ouvrir GLPI. Les balises ##ticket.*## sont résolues par GLPI à l'envoi :

Objet : [SLA depasse] Ticket ##ticket.id## - ##ticket.title##

Le ticket ci-dessous a depasse son delai de resolution.

Titre :       ##ticket.title##
Categorie :   ##ticket.category##
Priorite :    ##ticket.priority##
Statut :      ##ticket.status##
Attribue a :  ##ticket.assigntousers##
Delai (TTR) : ##ticket.time_to_resolve##

Ouvrir le ticket : ##ticket.url##

Erreurs de terrain courantes

• « Tout est urgent » : quand chaque ticket arrive en priorité haute, vous n'avez pas de priorisation, vous avez une file chronologique coûteuse. Verrouillez l'urgence dans le formulaire guidé et formez avec la matrice.
• Priorité modifiée à la main : le technicien qui écrase la priorité calculée casse la lecture du SLA et la matrice. S'ils doivent toujours reclasser, le défaut est dans la matrice, pas chez le technicien.
• Confondre TTO et TTR : « j'ai ouvert le ticket pour le lire » compte déjà comme prise en compte et respecte le SLA de première réponse sans que personne n'ait rien résolu. Suivez le TTR (résolution), pas seulement le TTO.
• Un contournement qui devient permanent : workaround appliqué et ticket clos, sans Problème ouvert - l'incident revient la semaine suivante. Liez les contournements récurrents à un Problème.

Étape suivante

Une fois la gestion des incidents solide, passez à la gestion des problèmes (éliminer la cause racine) et à la gestion des changements. Pour accélérer le tri, le module Smart Assign répartit les incidents entre techniciens selon des règles de charge et de compétence, et le guide SLA et OLA couvre la configuration des délais.

Besoin d'un GLPI qui tient vraiment le SLA ? NexTool infogère les environnements GLPI de bout en bout, de la matrice de priorité au cron d'escalade. Découvrez notre service de support et de maintien en condition.

Révisé par l'équipe NexTool Solutions.