Configurer l'assistance : tickets, catégories et règles métier

Configurer l'assistance dans GLPI, c'est préparer l'outil pour que chaque demande arrive au bon endroit avec les bonnes informations : catégories, gabarits de tickets, collecteur de courriels, notifications, règles métier qui attribuent et priorisent automatiquement. Ce chapitre règle l'outil côté administrateur. La méthode du technicien (qualifier avec le QQOQCP, prioriser, diagnostiquer, rédiger la solution) est dans le cours ITIL et gestion des incidents : les deux se complètent.

Ce que l'administrateur règle, ce que le technicien applique

Les portes d'entrée d'un ticket

Un ticket peut naître de plusieurs façons, et chacune se règle à un endroit différent :

• Le portail (interface simplifiée) : l'utilisateur choisit une tuile de l'accueil, un formulaire du catalogue de services ou le formulaire de ticket simple. L'accueil se compose dans la fiche de l'entité, onglet Accueil Helpdesk ; les formulaires font l'objet du chapitre 10.
• Le courriel : un message envoyé à l'adresse du support devient un ticket grâce à un collecteur.
• Le technicien : au téléphone ou au comptoir, il crée le ticket au nom de l'utilisateur dans Assistance > Tickets, bouton Ajouter, et indique la source de la demande (téléphone, direct, courriel…), utile aux statistiques.
• Une tâche planifiée : un ticket récurrent pour la maintenance préventive.
• Un autre outil : la supervision, un formulaire web externe ou un script peuvent créer des tickets par l'API de GLPI (chapitre 13).

Les catégories ITIL

Les catégories ITIL (Configuration > Intitulés, rubrique Assistance) classent les tickets, les problèmes et les changements. Elles servent à beaucoup plus qu'au classement : statistiques par catégorie, attribution automatique, choix du gabarit, articles de la base de connaissances proposés à l'utilisateur. Leur arborescence doit être pensée du point de vue de l'utilisateur, qui la voit dans le portail.

L'arborescence de Cèdre Habitat :

Pour chaque catégorie, la fiche permet de choisir :

• le groupe (ou le technicien) responsable, utilisé par l'attribution automatique ;
• la visibilité dans l'interface simplifiée, et pour quels types d'objets (incident, demande, problème, changement) ;
• un gabarit de ticket différent pour les incidents et pour les demandes ;
• un article de la base de connaissances à proposer (dans GLPI 12, une catégorie pointe vers un article, puisque les catégories de la base sont devenues des articles) ;
• un code, que les règles métier et les collecteurs peuvent utiliser.

Les gabarits de tickets

Un gabarit de ticket (Assistance > Tickets, bouton Gabarits) adapte le formulaire de création selon le type et la catégorie. Il définit trois listes :

• les champs obligatoires : sans eux, le ticket ne peut pas être créé (l'élément associé pour une panne matérielle, le lieu pour un problème réseau) ;
• les champs prédéfinis : remplis d'avance (l'urgence « Moyenne », une description modèle à compléter) ;
• les champs masqués : retirés de l'écran pour simplifier.

Quand un ticket est créé, GLPI choisit le gabarit dans cet ordre : celui de la catégorie pour le type choisi, sinon celui du profil de l'utilisateur, sinon celui de l'entité. Depuis GLPI 11, un gabarit peut aussi restreindre les statuts disponibles.

Chez Cèdre Habitat, le gabarit « Incident matériel », lié aux catégories Poste de travail > Matériel et Impression, rend obligatoire l'élément associé : impossible d'ouvrir un ticket de panne sans dire quelle machine est en panne. C'est ce qui nourrit l'historique des fiches et les statistiques par matériel.

La matrice de priorité

La priorité se calcule à partir de l'urgence (choisie par le demandeur) et de l'impact (évalué par le technicien), selon la matrice de calcul de la priorité de Configuration > Générale, onglet Assistance. Les échelles vont de « Très basse » à « Très haute » ; la priorité « Majeure » ne sort pas de la matrice, elle se fixe à la main. Les droits de modifier l'urgence, l'impact et la priorité se règlent dans l'onglet Assistance des profils. Comment évaluer l'impact et l'urgence, et lire la matrice, est expliqué dans le cours ITIL.

Le collecteur de courriels

Un collecteur (Configuration > Collecteurs) lit une boîte aux lettres et transforme chaque nouveau message en ticket, ou en suivi d'un ticket existant. Sa configuration :

L'action automatique mailgate relève la boîte à intervalles réguliers. Quand GLPI envoie une notification, il met le numéro du ticket dans l'objet du message, sous la forme [GLPI #0001234] : si l'utilisateur répond, le collecteur reconnaît le numéro et ajoute sa réponse en suivi du ticket existant au lieu d'en créer un nouveau.

Des règles pour assigner un ticket créé via un collecteur de mails placent le ticket dans la bonne entité (selon le domaine de l'expéditeur, par exemple) ou le refusent. Une liste de contenus de courriel refusés écarte les réponses automatiques (« absent du bureau ») qui créeraient des tickets parasites.

Les notifications

Les notifications sont les courriels que GLPI envoie quand quelque chose se passe : un ticket créé, un suivi ajouté, une solution proposée, un ticket en retard, une enquête de satisfaction. Leur mise en place suit trois étapes, dans Configuration > Notifications :

1. Activer les suivis par courriel et configurer l'envoi : serveur SMTP, port, chiffrement, compte d'envoi, adresse d'expéditeur. Le bouton d'envoi d'un courriel de test vérifie la configuration.
2. Vérifier les notifications : chacune associe un événement (« Nouveau ticket »), un modèle (le texte du courriel, avec des balises comme le numéro, le titre, le lien) et des destinataires (demandeur, groupe chargé, observateurs, administrateur de l'entité). Depuis GLPI 11, on peut aussi exclure des destinataires.
3. Contrôler l'envoi : les courriels passent par une file d'attente (Administration > File d'attente des notifications) vidée par une action automatique. Un courriel qui n'arrive pas est d'abord à chercher là.

Chaque entité règle aussi son adresse d'expéditeur, sa signature et un délai d'envoi qui regroupe les modifications rapprochées d'un même ticket en un seul message.

Les règles métier pour les tickets

Les règles métier pour les tickets (Administration > Règles) modifient automatiquement un ticket à sa création ou à sa mise à jour. Chaque règle a :

• des critères : catégorie, titre ou description qui contient un mot, demandeur, groupe du demandeur, lieu, élément associé, source, entité, urgence ;
• une logique : tous les critères (ET) ou au moins un (OU) ;
• une utilisation : à l'ajout, à la mise à jour, ou les deux ;
• des actions : affecter un groupe ou un technicien, fixer l'impact ou la catégorie, ajouter un observateur, appliquer un SLA ou un OLA, demander une validation, changer l'entité.

Toutes les règles dont les critères correspondent s'appliquent, dans l'ordre de la liste : si deux règles modifient le même champ, la dernière l'emporte. L'ordre se change par glisser-déposer, et le bouton Tester simule une règle sur des valeurs que tu saisis, sans toucher aux tickets réels.

Les règles de Cèdre Habitat :

L'attribution automatique

Sans règle, GLPI peut déjà attribuer un ticket tout seul, selon un réglage de l'entité (onglet Assistance, Attribution automatique) :

• en fonction de l'élément, puis de la catégorie : si le ticket a un élément associé avec un technicien ou un groupe responsable, le ticket lui est attribué ; sinon, on prend le responsable de la catégorie ;
• en fonction de la catégorie, puis de l'élément : l'inverse.

Chez Cèdre Habitat, c'est la catégorie d'abord : les compétences sont réparties par domaine, pas par machine. Les règles métier viennent ensuite affiner.

Les validations

Certaines demandes demandent un accord avant d'être traitées : un achat, un accès à un dossier sensible, l'installation d'un logiciel payant. Le technicien (ou une règle, ou le formulaire) envoie une demande de validation (le mot « approbation » remplace « validation » dans l'interface récente) à un utilisateur ou à un groupe ; depuis GLPI 11, n'importe quel membre du groupe peut répondre, et les validations peuvent être organisées en étapes successives. Le valideur reçoit une notification, accepte ou refuse avec un commentaire, et le ticket garde la trace de la décision. Une action automatique peut relancer les validations en attente.

Les tickets récurrents

Assistance > Tickets récurrents crée automatiquement un ticket à intervalle régulier, à partir d'un gabarit. C'est l'outil de la maintenance préventive : chez Cèdre Habitat, un ticket « Vérifier les sauvegardes de la nuit » chaque lundi pour le groupe Systèmes et réseau, et un ticket « Test de restauration trimestriel » le premier jour de chaque trimestre. Chaque exécution laisse une trace datée, ce qui est précieux pour prouver à la commission de l'E5 que les sauvegardes sont réellement contrôlées.

Lier les tickets, les problèmes et les changements

Un ticket peut être lié à un autre (lié à, doublon de, parent de, enfant de), à un problème ou à un changement. Depuis GLPI 11, n'importe quel objet de l'assistance peut être lié à n'importe quel autre. Ces liens servent :

• à regrouper les appels d'un incident majeur sous un ticket principal ;
• à rattacher des incidents répétés au problème qui recherche leur cause ;
• à relier une demande d'évolution au changement qui la réalise.

Clôture automatique et enquête de satisfaction

Dans l'onglet Assistance de l'entité :

• la clôture automatique des tickets résolus ferme un ticket résolu sans réponse du demandeur au bout du délai choisi (7 jours chez Cèdre Habitat). La valeur « immédiatement » ferme le ticket dès sa résolution et empêche le demandeur de refuser la solution : à éviter ;
• la purge automatique des tickets clos supprime les vieux tickets après un délai : prudence, car ils nourrissent les statistiques et l'historique des équipements ;
• l'enquête de satisfaction, interne à GLPI ou externe, est envoyée après la résolution, avec un taux de déclenchement (par exemple un ticket sur deux) et une échelle de notation réglable.

Exercices

Exercice 1 sur 5 Construire les catégories Réussi À revoir

Cèdre Solidarité (15 salariés, un local, une imprimante multifonction, une application de gestion des adhérents en ligne, des portables) veut ses propres catégories. Propose une arborescence de 5 à 7 catégories, avec le groupe chargé et la visibilité pour les utilisateurs.

Voir la réponseMasquer la réponse de l'exercice 1

Exemple :

Catégorie	Groupe chargé	Visible
Ordinateur portable (panne, lenteur)	Support N1	Oui
Impression et numérisation	Support N1	Oui
Compte et mot de passe	Support N1	Oui
Application adhérents	Applications	Oui
Internet et Wi-Fi	Systèmes et réseau	Oui
Demande de matériel ou de logiciel	Support N1, avec validation de la présidente	Oui
Sécurité (message suspect, perte, vol)	Systèmes et réseau	Oui

Les catégories sont créées dans l'entité Cèdre Solidarité (ou dans la racine, visibles dans les sous-entités si elles sont communes). Les mots sont ceux des utilisateurs, et une catégorie dédiée aux incidents de sécurité les fait remonter vite.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 5 Écrire des règles métier Réussi À revoir

Écris les règles (critères, logique, actions) pour les besoins suivants, puis dis dans quel ordre tu les places.

1. Tout ticket dont l'élément associé est un serveur va au groupe Systèmes et réseau.
2. Tout ticket de Cèdre Solidarité a la présidente de l'association comme observatrice.
3. Les tickets dont le titre contient « virus », « rançon » ou « piratage » passent en catégorie Sécurité.
4. Les tickets de la catégorie Sécurité vont au groupe Systèmes et réseau avec une urgence très haute.

Voir la réponseMasquer la réponse de l'exercice 2

1. Critère : type de l'élément associé est « Ordinateur » ET type d'ordinateur est « Serveur » (ou nom de l'élément commence par SRV-). Action : groupe chargé Systèmes et réseau.
2. Critère : entité est Cèdre Solidarité. Action : ajouter l'observatrice. Utilisation : à l'ajout.
3. Logique OU : titre contient « virus », OU contient « rançon », OU contient « piratage ». Action : catégorie Sécurité.
4. Critère : catégorie est Sécurité. Actions : groupe chargé Systèmes et réseau, urgence Très haute.

Ordre : la règle 3 doit passer avant la règle 4, puisque la 4 s'appuie sur la catégorie que la 3 fixe. Les règles 1 et 2 sont indépendantes. On teste chaque règle avec le bouton Tester avant de l'activer.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 5 Le ticket qui se dédouble Réussi À revoir

Mme Lopez répond par courriel à la notification « Votre ticket a été résolu » pour dire que le problème est revenu. Au lieu d'ajouter un suivi, GLPI crée un nouveau ticket. Donne deux causes possibles et leur correction.

Voir la réponseMasquer la réponse de l'exercice 3

1. Le numéro du ticket a disparu de l'objet : Mme Lopez (ou son logiciel de messagerie) a modifié l'objet et supprimé [GLPI #…]. Le collecteur ne peut pas rattacher la réponse. Correction : fusionner ou lier les deux tickets, rouvrir le premier, et rappeler aux utilisateurs de ne pas modifier l'objet.
2. Le ticket était déjà clos : selon la configuration, une réponse à un ticket clos crée un nouveau ticket. Correction : vérifier le délai de clôture automatique (trop court ?) et lier le nouveau ticket à l'ancien pour garder l'historique.

D'autres causes sont possibles : la réponse est partie d'une autre adresse que celle du demandeur, ou le message de notification a été envoyé depuis une adresse différente de celle du collecteur.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 5 Les notifications muettes Réussi À revoir

Depuis la migration du serveur, plus aucun courriel ne part de GLPI. Les tickets se créent normalement. Liste les vérifications, dans l'ordre.

Voir la réponseMasquer la réponse de l'exercice 4

1. La file d'attente des notifications (Administration > File d'attente des notifications) : si les courriels s'y accumulent, ils sont créés mais pas envoyés.
2. Le cron du nouveau serveur : la ligne de la crontab de www-data a-t-elle été recréée ? Dans Configuration > Actions automatiques, la date de dernière exécution de l'envoi des notifications avance-t-elle ?
3. La configuration SMTP (Configuration > Notifications, suivis par courriel) : le nouveau serveur a-t-il le droit d'envoyer vers le serveur de messagerie (pare-feu, relais autorisé, identifiants) ? Le bouton d'envoi d'un courriel de test répond.
4. Les journaux de GLPI (/var/log/glpi) pour le message d'erreur exact.

Le plus probable, après une migration, est l'oubli du cron.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 5 sur 5 Un ticket récurrent pour l'E5 Réussi À revoir

Propose un ticket récurrent qui prouve le contrôle des sauvegardes de Cèdre Habitat : titre, fréquence, groupe, contenu du gabarit, et ce que le technicien écrit à chaque exécution.

Voir la réponseMasquer la réponse de l'exercice 5

• Titre : « Contrôle hebdomadaire des sauvegardes » ; fréquence : chaque lundi, création à 8 h ; type : Demande ; catégorie : Serveurs et sauvegardes ; groupe chargé : Systèmes et réseau.
• Gabarit : description modèle avec la liste des contrôles (rapport de la nuit sans erreur pour chaque serveur, espace libre sur la cible, copie hors site présente, date de la dernière restauration testée).
• À chaque exécution, le technicien coche les contrôles dans une tâche avec la durée passée, joint la capture du rapport de sauvegarde et résout le ticket ; en cas d'anomalie, il ouvre un incident lié.

Sur un trimestre, ces 13 tickets datés et documentés sont une preuve solide pour la sous-compétence « gérer des sauvegardes » de l'E5 ; le test de restauration trimestriel, sous forme d'un second ticket récurrent, complète la preuve.

Tu avais trouvé ?

Oui, j'avais bonPas encore