NexTool Solutions

La plupart des Service Desks fonctionnent en mode réactif : ils attendent que le ticket arrive et se précipitent pour le résoudre. L'entonnoir de support inverse cette logique - chaque couche filtre la demande avant qu'elle n'atteigne le technicien. Dans GLPI, l'entonnoir n'est pas un bouton que l'on active : c'est un agencement de catégories, de règles métier, de base de connaissances et de cron qu'il faut mesurer et ajuster. Ce guide montre comment construire chaque couche avec ce que GLPI fournit déjà, et les pièges que nous avons vus faire tomber des entonnoirs entiers lors de la maintenance d'environnements clients.

Avant de construire l'entonnoir, mesurez d'où vient le volume

L'erreur la plus courante est de construire l'entonnoir à l'envers : écrire des dizaines d'articles et de formulaires génériques en espérant qu'ils réduisent les tickets. En maintenance, nous faisons l'inverse - d'abord découvrir quelles catégories concentrent le volume, car c'est là que chaque couche est rentable. La requête ci-dessous, exécutée avec un utilisateur en lecture seule, liste les catégories qui génèrent le plus de demande sur les 90 derniers jours et sépare incident et demande, la distinction qui décide si la demande va au self-service ou au N1 :

-- Top catégories par volume (90 derniers jours) : où les couches de
-- prévention et de self-service rapportent le plus. Utiliser un utilisateur en lecture seule.
-- type : 1 = incident, 2 = demande
SELECT
    COALESCE(c.completename, '(sans catégorie)') AS categoria,
    COUNT(*)        AS chamados,
    SUM(t.type = 1) AS incidentes,
    SUM(t.type = 2) AS requisicoes
FROM glpi_tickets t
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.is_deleted = 0
  AND t.date >= DATE_SUB(CURDATE(), INTERVAL 90 DAY)
GROUP BY t.itilcategories_id
ORDER BY chamados DESC
LIMIT 15;

Deux lectures en ressortent. Les catégories de demande répétitive (réinitialisation de mot de passe, octroi d'accès, installation standard) sont candidates au self-service et à l'automatisation : l'utilisateur ne devrait pas avoir besoin d'un technicien. Les catégories d'incident à fort volume pointent des pannes récurrentes que la couche de prévention devrait capter avant que l'utilisateur ne s'en aperçoive. Et si "(sans catégorie)" apparaît en tête, le problème est en amont de l'entonnoir : le tri est relâché et aucune règle ne peut router ce qui n'a pas été classé.

La matrice de décision : chaque demande dans sa couche

Un entonnoir n'est pas une hiérarchie de personnes, c'est du routage de demande. Chaque type de demande a une couche adéquate et un mécanisme natif de GLPI qui la soutient. La matrice ci-dessous est le point de départ que nous utilisons pour concevoir l'entonnoir d'un client :

Couche 1 - Prévention : le ticket né de la supervision

L'objectif de cette couche est le ticket que l'équipe (ou le système lui-même) ouvre avant que l'utilisateur ne remarque le problème. En pratique :

• La supervision crée le ticket : Zabbix, GLPI Agent ou un autre collecteur déclenche un ticket par e-mail (collector) ou API lorsqu'un seuil est franchi - disque à 90 %, service arrêté, certificat qui expire. Le ticket arrive déjà catégorisé et dans le groupe infra.
• Maintenance planifiée communiquée : avant une fenêtre, une annonce sur le portail et une notification évitent le déluge de « c'est en panne ? ».
• Correction de la cause racine : les incidents qui se répètent deviennent un Problème (Problem) dans GLPI, traité une fois au lieu de N tickets identiques.

Le gain est mesurable : le taux de prévention est la part des incidents dont le premier enregistrement vient de la supervision, pas de l'utilisateur. L'intégration de Zabbix avec GLPI est le chemin le plus direct vers cette couche.

Couche 2 - Self-service : publier n'est pas la même chose qu'apparaître

C'est là que se cache le piège qui, le plus souvent, tue la couche self-service : l'équipe écrit des dizaines d'articles et pourtant le portail self-service ne montre rien à l'utilisateur. Dans GLPI, un article n'apparaît dans la FAQ publique que lorsque trois conditions coïncident :

1. l'article est publié (avec une date de début de validité, pas un brouillon) ;
2. il est marqué visible dans la FAQ (le champ is_faq) ;
3. il a une cible qui inclut le profil self-service (ou « tous ») - sans cible, l'article n'est visible que pour son créateur.

Qu'il en manque une des trois et l'article existe en base mais reste invisible pour qui en a besoin. Ajoutez à cela la visibilité de la catégorie : une catégorie non marquée visible dans le helpdesk n'apparaît pas dans le formulaire d'ouverture, donc l'utilisateur n'y parvient même pas à se servir lui-même. Au-delà des articles, cette couche inclut des formulaires guidés (réinitialisation de mot de passe, demandes standardisées) qui résolvent ou routent sans intervention. Commencez la base de connaissances par les catégories que le SQL ci-dessus a placées en tête, pas par le manuel produit de A à Z.

Couche 3 - Résolution : router par règle, pas par e-mail

Ce qui n'a été ni prévenu ni self-servi doit atteindre vite celui qui le résout - et arriver au bon endroit. Le moteur ici, ce sont les règles métier de ticket (RuleTicket) : elles affectent le groupe, la catégorie, la priorité et le SLA selon des critères (catégorie, origine, mot dans le titre, demandeur). Le routage par règle est auditable et reproductible ; le routage par « transfère l'e-mail à untel » ne passe pas à l'échelle et disparaît quand untel part en congé. La requête ci-dessous liste les règles de ticket actives dans l'ordre où GLPI les exécute :

-- Règles métier de ticket (RuleTicket) actives, dans l'ordre d'exécution.
-- GLPI traite par `ranking` ; une action « arrêter le traitement » sur une
-- règle antérieure empêche les suivantes de s'exécuter. Utiliser un utilisateur en lecture seule.
SELECT ranking, name, `match` AS operador_criterios, is_active
FROM glpi_rules
WHERE sub_type = 'RuleTicket'
  AND is_active = 1
ORDER BY ranking;

L'ordre (colonne ranking) compte parce qu'une action « arrêter le traitement » interrompt les règles suivantes. L'erreur courante est de créer une nouvelle règle en fin de file en espérant qu'elle ajuste la priorité, sans voir qu'une règle antérieure, avec « arrêter le traitement » activé, a déjà clos le routage - la nouvelle ne s'exécute jamais. Les niveaux N1/N2/N3 sont des groupes ; l'escalade entre eux est une règle plus un SLA par priorité, pas une décision manuelle au cas par cas.

L'erreur qui fait tomber n'importe quel entonnoir : l'automatisation qui ne se déclenche jamais

Vous pouvez construire les trois couches avec soin et pourtant que rien ne se passe tout seul. Escalade de SLA, envoi de notifications, clôture automatique des tickets résolus, alertes - tout cela dans GLPI dépend des Actions automatiques (CronTask), et elles ne s'exécutent de façon fiable que lorsqu'un cron externe du système d'exploitation appelle GLPI. Dans le mode par défaut « GLPI » (déclenché par la navigation web), les actions s'exécutent de façon irrégulière, dépendent de quelqu'un qui ouvre l'interface et se bloquent sous charge. Le symptôme classique qu'on nous signale : « le SLA n'escalade pas », « la notification n'arrive pas », « le ticket ne se ferme pas tout seul » - et la cause est presque toujours la même. La ligne ci-dessous corrige cela (ajustez le chemin vers la racine de votre GLPI et l'utilisateur PHP) :

# GLPI - action automatique EXTERNE, toutes les 1 minute, en tant qu'utilisateur PHP.
# Sans cela, SLA/escalade, notifications et clôture automatique ne s'exécutent PAS.
# Ajustez le chemin vers la racine de votre GLPI (GLPI 10 et 11 utilisent front/cron.php).
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

Ensuite, dans Configuration > Actions automatiques, passez le mode des tâches de « GLPI » à « CLI ». Sans cette étape, une bonne partie de l'entonnoir est décorative.

Du terrain : l'entonnoir qui n'existait que sur le papier

En reprenant la maintenance d'un environnement déjà en production, nous avons trouvé le scénario le plus courant de tous : l'entonnoir était dessiné sur la diapositive mais pas dans le système. La base de connaissances comptait plus de cent articles - tous enregistrés en brouillon, aucun marqué FAQ ni avec de cible, si bien que le portail self-service apparaissait vide pour l'utilisateur. Les règles d'affectation existaient, mais la troisième avait « arrêter le traitement » activé et avalait la moitié des tickets dans le mauvais groupe. Et le cron externe n'avait jamais été configuré, donc le SLA n'escaladait pas et la clôture automatique était à l'arrêt - le backlog gonflait de tickets résolus que personne ne confirmait. Nous avons exécuté le SQL de volume par catégorie avant de toucher à quoi que ce soit : réinitialisation de mot de passe et VPN représentaient une bonne part du total. Nous avons publié et marqué en FAQ une demi-douzaine d'articles de ces deux catégories, corrigé l'ordre des règles et activé le cron externe. En quelques semaines, le volume de ces catégories a baissé de façon visible dans le même rapport - non parce que le problème a disparu, mais parce qu'il a cessé de devenir un ticket. L'entonnoir n'était pas nouveau ; il n'était simplement jamais sorti du papier.

Construire l'entonnoir dans GLPI relève moins des plugins que de l'ordre : mesurer le volume, router par règle, publier vraiment le self-service et s'assurer que l'automatisation se déclenche. La maintenance GLPI de NexTool inclut exactement cette conception - de la matrice de catégories aux règles et au cron - et le suivi mensuel qui montre chaque couche réduisant la demande qui atteint le technicien.

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