NexTool Solutions

La visibilité ne consiste pas à avoir plus de rapports - il s'agit de voir l'état de la file tant qu'il est encore possible d'agir. GLPI stocke déjà tout ce dont vous avez besoin ; le problème, c'est que la donnée est dispersée et que le tableau de bord natif ne montre que le passé. Ce guide montre où vit la vraie visibilité dans GLPI, quelles requêtes de diagnostic nous lançons quand nous reprenons l'exploitation d'un environnement, comment anticiper un dépassement de SLA avant qu'il ne survienne et comment transformer tout cela en alerte automatique.

La visibilité que GLPI vous donne déjà - et où elle s'arrête

GLPI est livré avec des tableaux de bord sur la Centrale et une recherche filtrée puissante. Au quotidien, cela règle beaucoup de choses : comptages par statut, par technicien, par catégorie. La limite apparaît en trois points :

• C'est à la demande, pas proactif. Le tableau de bord ne se rafraîchit que lorsqu'on ouvre l'écran. Personne n'est prévenu quand un goulet d'étranglement se forme - il faut aller regarder.
• Il compte ce que votre profil peut voir. Le chiffre du tableau de bord dépend de l'entité et du profil de la personne connectée. Le coordinateur d'une entité et l'administrateur global voient des totaux différents de la même file.
• Il montre l'agrégat, pas le ticket oublié. "42 tickets ouverts" ne dit pas lequel est bloqué depuis 20 jours.

La vraie visibilité commence quand on arrête de regarder le total et qu'on regarde la forme de la file et ce qui est sur le point de mal tourner.

Étape 1 : où le backlog s'accumule

Avant tout beau tableau de bord, la première radiographie est la répartition du backlog par groupe et par statut. Tout vit dans glpi_tickets ; l'affectation à un groupe, dans glpi_groups_tickets (type 2 = attribué). Les statuts qui comptent : 1 Nouveau, 2/3 En cours, 4 En attente, 5 Résolu, 6 Clos.

-- Backlog ouvert par groupe attribué (type 2 = attribué)
SELECT
  g.completename                    AS groupe,
  COUNT(*)                          AS ouverts,
  SUM(t.status = 1)                 AS nouveaux_non_tries,
  SUM(t.status = 4)                 AS en_attente
FROM glpi_tickets t
JOIN glpi_groups_tickets gt
     ON gt.tickets_id = t.id AND gt.type = 2
JOIN glpi_groups g ON g.id = gt.groups_id
WHERE t.status NOT IN (5, 6)
  AND t.is_deleted = 0
GROUP BY g.id
ORDER BY ouverts DESC;

En quelques secondes, vous voyez quel groupe est surchargé et quelle part du backlog correspond à des tickets neufs que personne n'a triés - le chiffre que le tableau de bord natif masque derrière le total.

Étape 2 : le SLA qui va être dépassé avant de l'être

C'est là que se sépare l'exploitation qui réagit de celle qui anticipe. Quand un SLA correspond au ticket, GLPI écrit l'échéance dans des colonnes dédiées de glpi_tickets : time_to_resolve (échéance de résolution) et time_to_own (échéance de prise en charge). C'est une horloge - on peut regarder ce qui expire dans les prochaines heures, pas seulement ce qui a déjà expiré :

-- Tickets ouverts dont le SLA de résolution expire dans les 4 prochaines heures
SELECT
  t.id,
  t.name,
  t.time_to_resolve,
  TIMESTAMPDIFF(MINUTE, NOW(), t.time_to_resolve) AS minutes_restantes
FROM glpi_tickets t
WHERE t.status NOT IN (4, 5, 6)        -- hors En attente, Résolu, Clos
  AND t.is_deleted = 0
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve > NOW()
  AND t.time_to_resolve <= NOW() + INTERVAL 4 HOUR
ORDER BY t.time_to_resolve ASC;

Le piège de terrain est dans ce IS NOT NULL. La colonne time_to_resolve n'est renseignée que lorsqu'une règle de SLA a correspondu au ticket à sa création. Un ticket qui n'a correspondu à aucune règle garde une échéance NULL - et disparaît silencieusement du tableau de bord de risque. Autrement dit : les tickets sans SLA, précisément ceux que personne ne mesure, sont invisibles pour toute alerte basée sur une échéance. Quand nous reprenons un environnement, le premier comptage que nous lançons est le nombre de tickets ouverts avec time_to_resolve IS NULL. Nous avons déjà vu un client avec 60% du backlog sans aucun SLA associé : le tableau de bord disait "tout dans les temps" parce que la moitié de la file n'avait tout simplement pas d'échéance.

Étape 3 : le responsable qui n'existe pas

Autre angle mort classique : un ticket attribué à un seul groupe, sans technicien nommé. À l'écran il paraît attribué ; en pratique, personne ne se sent responsable. Ces tickets disparaissent des tableaux de bord personnels ("mes tickets") et vieillissent invisibles. L'attribution à une personne vit dans glpi_tickets_users avec type = 2 :

-- Ouverts attribués à un groupe mais SANS technicien responsable nommé
SELECT COUNT(*) AS sans_responsable
FROM glpi_tickets t
WHERE t.status NOT IN (5, 6)
  AND t.is_deleted = 0
  AND NOT EXISTS (
    SELECT 1 FROM glpi_tickets_users tu
    WHERE tu.tickets_id = t.id AND tu.type = 2
  );

Les couches de visibilité : quoi utiliser pour quoi

Il n'existe pas d'outil unique. Chaque couche résout un problème et a une limite. Voici comment nous décidons où placer chaque indicateur :

Étape 4 : transformer le diagnostic en alerte automatique

Lancer la requête à la main ne passe pas à l'échelle et, pire, repose sur le fait que quelqu'un pense à regarder. Deux façons de boucler la boucle dans GLPI :

1. Natif, sans infrastructure supplémentaire : enregistrez la recherche "SLA à échéance" ou "en attente depuis plus de 7 jours" et créez une alerte de recherche enregistrée. Le cron de GLPI exécute la recherche périodiquement et déclenche un e-mail quand le comptage franchit le seuil que vous définissez.
2. Hors de GLPI, pour un écran mural et l'historique : planifiez la requête de diagnostic dans le cron du système, en lisant l'identifiant depuis un fichier .cnf (chmod 600) pour ne jamais laisser de mot de passe sur la ligne de commande.

# /etc/cron.d/glpi-visibilite  ->  chaque heure ouvrée, en tant que www-data
# Liste les tickets dont le SLA expire dans les 4h pour la file d'astreinte
0 8-18 * * 1-5 www-data /usr/bin/mysql --defaults-file=/etc/glpi/kpi-ro.cnf glpi \
  < /opt/glpi-kpi/sla-a-echeance.sql \
  > /var/log/glpi-kpi/sla-risque-$(date +\%Y-\%m-\%d-\%H).csv 2>&1

Avant de planifier, assurez-vous que le cron de GLPI tourne bien en mode externe (le cron du système appelant front/cron.php) - sinon les échéances de SLA et les alertes natives ne sont même pas recalculées, et vous liriez une horloge arrêtée.

Le tournant, vu de la pratique du support

Quand nous reprenons le GLPI d'un client, la première radiographie n'est jamais le tableau de bord natif - c'est le comptage des tickets attribués à un seul groupe (sans responsable) et des tickets avec un time_to_resolve nul. Dans un cas, 40% du backlog était "attribué" à un groupe de huit personnes et personne ne se sentait responsable ; aucun de ces tickets n'apparaissait sur un tableau de bord personnel et le plus ancien avait 90 jours. Le correctif n'était pas un nouveau tableau de bord - c'était une règle métier imposant un technicien nommé à l'attribution, plus une alerte de SLA à 4 heures de l'échéance. La visibilité n'est pas venue de l'achat d'un outil ; elle est venue du fait de regarder les bons champs.

Erreurs de terrain fréquentes

• Se fier au total du tableau de bord : il agrège et masque le ticket bloqué ; regardez la répartition par groupe et par ancienneté.
• Croire que chaque ticket a un SLA : time_to_resolve NULL = hors de toute alerte d'échéance. Comptez d'abord ceux sans SLA.
• Traiter "attribué à un groupe" comme "a un responsable" : sans une ligne dans glpi_tickets_users avec type = 2, personne n'est responsable.
• Comparer des entités par le même chiffre : le tableau de bord natif filtre déjà par profil et entité ; le total change selon qui est connecté.
• Oublier is_deleted = 0 : la corbeille de GLPI ne quitte pas la table et pollue tout comptage.
• Mesurer avec le cron arrêté : sans le cron externe en marche, les SLA et les alertes natives ne se mettent pas à jour.

Étape suivante

Commencez par les trois comptages de ce guide (sans responsable, sans SLA, SLA à échéance), poussez ces coupes vers un tableau de bord dans Metabase ou Grafana et reliez vos KPI de Service Desk à des alertes. Ainsi la file cesse d'être un chiffre de fin de mois et devient un signal qui se déclenche tant qu'il est encore temps d'agir.

Chez NexTool, cette radiographie de visibilité est le premier livrable quand nous reprenons le support d'un GLPI : nous cartographions les angles morts, branchons les alertes et livrons le tableau de bord. Si vous voulez ce suivi sur votre environnement, découvrez notre service de support et de maintenance.

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