Workflows ITIL incidents et demandes dans GLPI 11

Un ticket bien typé vaut dix tickets vaguement nommés. Sans un classement net entre incidents, demandes, problèmes et changements, le service desk dérive vers un fourre-tout où aucune métrique n’a de sens, où la priorité est subjective, et où la même demande peut être traitée en deux heures par un technicien et en deux semaines par un autre. ITIL 4 propose un cadre simple pour structurer ces flux, GLPI 11 l’implémente dans son cœur, et ce tutoriel montre comment paramétrer concrètement les workflows essentiels.

Vous allez configurer les types de tickets, les catégories, les statuts, les règles métier automatiques et les formulaires de demande. À la fin, n’importe quelle saisie utilisateur tombera dans le bon couloir, sera affectée au bon groupe de techniciens, avec la bonne priorité, sans intervention humaine. Le contexte ITSM global est posé dans GLPI 11 helpdesk ITIL : déployer un service desk professionnel.

Étape 1 — Distinguer incidents, demandes, problèmes et changements

ITIL 4 sépare quatre types de sollicitations qui n’obéissent pas aux mêmes règles de gestion :

La règle pratique : un ticket commence presque toujours comme Incident ou Demande. Si un même incident se répète, l’équipe ouvre un Problème pour traiter la cause racine pendant que les incidents continuent d’être résolus. Si la résolution du Problème exige une intervention coordonnée (changement de serveur, mise à jour du firmware d’un switch), un Changement est ouvert.

Étape 2 — Structurer les catégories de tickets

La taxonomie des catégories est le squelette du reporting futur. Une catégorie trop large (« Informatique ») ne dit rien ; une catégorie trop fine (« Outlook 2019 lent au démarrage sur Windows 11 ») n’est jamais retrouvée. La bonne profondeur tient en deux niveaux maximum au départ.

Allez dans « Configuration » → « Intitulés » → « Catégories ITIL ». Créez une dizaine de catégories de premier niveau :

• Compte et identité — mots de passe, déblocages, droits
• Poste de travail — matériel, OS, périphériques
• Applications métier — ERP, CRM, RH, comptabilité
• Bureautique et collaboration — Office, e-mail, agenda
• Réseau et connectivité — Wi-Fi, VPN, lenteurs
• Téléphonie — postes IP, mobiles, conférence
• Demande de matériel
• Demande de logiciel
• Sécurité — phishing suspecté, accès suspect, virus
• Autre — fourre-tout temporaire à réduire chaque mois

Pour chaque catégorie, cochez les usages : « Visible pour les demandes », « Visible pour les incidents », « Visible pour les changements », et associez un groupe de techniciens par défaut. La catégorie « Compte et identité » s’attribue par exemple automatiquement au groupe « Support N1 », tandis que « Sécurité » va au groupe « SOC ».

Étape 3 — Définir la matrice d’urgence × impact = priorité

GLPI calcule automatiquement la priorité d’un ticket à partir de deux dimensions : l’urgence (à quelle vitesse il faut agir) et l’impact (combien d’utilisateurs sont touchés). Allez dans « Configuration » → « Générale » → « Assistance » → « Matrice de calcul des priorités ». La matrice par défaut convient à 90 % des cas :

L’utilisateur final ne voit pas cette matrice. Il choisit simplement le niveau d’urgence ressenti dans le formulaire. L’impact est généralement déterminé par les règles métier en fonction de la catégorie ou du nombre d’utilisateurs concernés. Le calcul donne la priorité finale, et cette priorité conditionne les SLA appliqués au ticket — point détaillé dans SLA et matrice d’escalade dans GLPI.

Étape 4 — Configurer les statuts et le cycle de vie

GLPI livre par défaut six statuts pour les tickets : Nouveau, En cours (attribué), En cours (planifié), En attente, Résolu, Clos. Ajoutez ou renommez selon votre processus, mais évitez d’en multiplier sans raison. Un statut sert seulement s’il déclenche un comportement différent (notification, SLA pausé, escalade).

Le passage à « En attente » mérite une règle de gouvernance claire : il ne doit pas servir à masquer un ticket que personne ne veut traiter. Définissez les seuls cas légitimes :

• Attente d’information complémentaire de l’utilisateur
• Attente d’un fournisseur tiers
• Attente d’une fenêtre de maintenance planifiée

Activez la relance automatique : un ticket en attente plus de 5 jours déclenche une notification au demandeur, puis se ferme automatiquement après 10 jours d’attente sans retour. C’est dans « Configuration » → « Actions automatiques » → « Closeticket ».

Étape 5 — Créer les règles métier d’affectation automatique

La force de GLPI tient dans son moteur de règles métier. Allez dans « Administration » → « Règles » → « Règles métier pour les tickets ». Chaque règle a des conditions (sur le contenu du ticket) et des actions (sur les champs du ticket). Quelques règles utiles à publier dès le démarrage :

Règle 1 — Phishing par e-mail. Condition : « Titre contient phishing OU hameçonnage » OU « Catégorie = Sécurité ». Actions : forcer Type = Incident, Urgence = Élevée, Impact = Élevé (donc Priorité haute), affecter au groupe SOC.

Règle 2 — Réinitialisation de mot de passe. Condition : « Catégorie = Compte et identité » ET « Titre contient mot de passe ». Actions : forcer Type = Demande, affecter au groupe N1, ajouter un suivi automatique « Vérifier l’identité du demandeur avant toute action ».

Règle 3 — Incident applicatif critique. Condition : « Catégorie = Applications métier » ET « Source = Supervision » (tickets ouverts par webhook depuis votre Zabbix). Actions : Type = Incident, Urgence = Très élevée, Impact = Très élevé, alerte chat ChatOps via webhook sortant.

Les règles s’exécutent dans l’ordre, et l’option « Arrêter le moteur en cas de correspondance » permet de bloquer la suite si la règle est déjà conclusive. Pensez à tester chaque règle après création avec un ticket fictif avant de l’activer en production.

Étape 6 — Publier les formulaires self-service

Les Integrated Forms de GLPI 11 sont la fonctionnalité la plus impactante côté utilisateur final. Allez dans « Configuration » → « Formulaires ». Créez un formulaire « Demande de logiciel » avec :

1. Champ « Quel logiciel souhaitez-vous ? » (liste déroulante alimentée par votre catalogue de logiciels approuvés)
2. Champ « Justification métier » (texte long obligatoire)
3. Champ « Date souhaitée » (date)
4. Champ « Responsable hiérarchique pour validation » (rempli automatiquement depuis l’AD via l’attribut manager)

Côté « Destinations », configurez la création automatique d’un ticket de type Demande, avec catégorie « Demande de logiciel », et un workflow d’approbation envoyant la demande au manager avant de partir au technicien. Le formulaire est ensuite publié sur le portail self-service avec une icône et une description claire.

Répliquez ce pattern pour les six à douze demandes les plus courantes : déblocage de compte, ouverture de VPN, demande de matériel, signalement de panne réseau, demande de transfert de fichiers volumineux, demande d’accès à un partage. Les utilisateurs trouvent leur réponse sans appeler.

Étape 7 — Activer le workflow d’approbation

Certaines demandes exigent une validation hiérarchique. GLPI gère cela nativement via les « Approbations ». Sur le ticket généré par un formulaire à validation, GLPI envoie un e-mail au valideur avec deux boutons : « Approuver » et « Rejeter ». Le valideur n’a même pas besoin d’ouvrir GLPI : un clic depuis sa boîte mail suffit.

Configurez les délais d’approbation : sans réponse sous 48 heures, une relance part automatiquement ; sans réponse sous 5 jours, le ticket s’escalade au N+2. Cette mécanique évite que les tickets s’enlisent dans la boîte mail d’un manager en déplacement.

Étape 8 — Tester chaque chaîne de bout en bout

Avant d’ouvrir le service desk aux utilisateurs, jouez les scénarios :

1. Ouvrir un ticket de chaque catégorie depuis le portail self-service avec un compte utilisateur réel
2. Vérifier que la catégorie pré-affecte au bon groupe de techniciens
3. Vérifier que les notifications partent correctement (au demandeur, au technicien attribué)
4. Pour les demandes à validation, vérifier que l’approbateur reçoit son mail
5. Pour les incidents priorité haute, vérifier que l’alerte ChatOps déclenche bien le webhook
6. Clôturer le ticket et vérifier que l’utilisateur reçoit son enquête de satisfaction

Documentez les écarts. C’est lors de ces tests que vous identifierez les règles métier oubliées ou les groupes de notification manquants. Mieux vaut corriger sur dix tickets de test que sur cent tickets réels mal routés.

Étape 9 — Capitaliser dans la base de connaissances

Chaque incident résolu pour la première fois est candidat à devenir un article de base de connaissances. GLPI propose un mécanisme « Créer un article KB depuis ce ticket » qui pré-remplit l’article avec le titre, le contenu et la solution. Le technicien complète, publie, et le prochain utilisateur trouvera la réponse sur le portail self-service avant même d’ouvrir un ticket.

Posez un rituel hebdomadaire de 30 minutes pour passer en revue les tickets clos de la semaine et décider lesquels méritent un article KB. Une équipe disciplinée arrive en six mois à un taux de déviation self-service supérieur à 30 % — c’est autant de tickets en moins à traiter manuellement, et autant de capacité libérée pour le travail à valeur ajoutée.

Erreurs fréquentes

Articles associés

• GLPI 11 helpdesk ITIL : déployer un service desk professionnel
• SLA et matrice d’escalade dans GLPI
• Inventorier le parc IT avec GLPI Agent
• API REST GLPI : intégrer un script Python

Références

• Cadre ITIL 4 — Axelos / PeopleCert
• Documentation utilisateur GLPI

Gouvernance hebdomadaire des tickets

Sans rituel d’équipe, même la meilleure configuration GLPI s’effondre en six mois. Posez un rendez-vous hebdomadaire de 45 minutes avec les techniciens et le Service Desk Manager. L’ordre du jour tient en cinq points :

• Revue des tickets de la semaine — volume, top catégories, anomalies
• Revue des tickets en retard sur SLA — comprendre pourquoi, ajuster les règles
• Tickets candidats à un article de connaissance — décision et affectation
• Tickets candidats à un Problème — quand un même incident revient trois fois
• Améliorations à apporter aux formulaires self-service en fonction des retours

Le compte-rendu est court (cinq lignes) mais publié dans le canal d’équipe. Cette discipline transforme le service desk en organisation apprenante plutôt qu’en pompier permanent.

Modéliser une chaîne incident → problème → changement

Quand un incident révèle une cause systémique, ITIL prévoit une montée en charge contrôlée. Concrètement dans GLPI :

Sur le ticket d’incident le plus récent, cliquez « Ouvrir un Problème lié ». GLPI crée un objet Problème pré-rempli avec le contexte, et lie automatiquement tous les incidents passés portant la même signature (même catégorie, même mot-clé). Le Problème est attribué au technicien senior qui mènera l’investigation root cause.

Quand l’investigation aboutit à une action corrective qui nécessite une fenêtre de maintenance ou une coordination avec une équipe infrastructure, cliquez « Ouvrir un Changement lié » depuis le Problème. Le Changement embarque une fiche de plan d’action, une procédure de retour arrière, et une planification avec validation CAB simplifiée (Change Advisory Board : un mail à deux validateurs suffit pour la majorité des changements standard).

Cette chaîne tracée bout en bout — incidents répétés → Problème ouvert → Changement validé → résolution durable — est exactement ce qu’un audit ITIL attend de voir. Aucun outil concurrent ne le fait nativement avec autant de fluidité.

Mesurer la qualité du service rendu

Une enquête de satisfaction post-clôture est le seul moyen d’objectiver le ressenti utilisateur. Activez « Configuration » → « Générale » → « Assistance » → « Enquête de satisfaction » avec une note sur 5 étoiles et un champ commentaire libre. Le déclenchement est automatique 48 heures après la clôture pour laisser à l’utilisateur le temps de valider que le problème ne revient pas.

Suivez deux chiffres mensuels :

• CSAT = nombre de notes ≥ 4 / nombre total de réponses. Cible : ≥ 85 %
• Taux de réponse = nombre de réponses / nombre d’enquêtes envoyées. Cible : ≥ 30 %

Un CSAT bas signale un problème opérationnel à corriger. Un taux de réponse bas signale soit une enquête mal formulée, soit un public déconnecté du portail — dans les deux cas, le simple fait de mesurer attire l’attention de la direction sur la qualité du service desk.