Projets

GLPI : Optimisation de la Gestion des Tickets — mise en place d’un support structuré

GLPI
Ticketing
ITSM
ITIL
CMDB

J’ai organisé une gestion de tickets dans GLPI

Interface GLPI montrant la création, l’affectation et le suivi d’un ticket

GLPI : Optimisation de la Gestion des Tickets

  1. Configuration des Profils Utilisateurs

J’ai défini des profils distincts afin que chacun intervienne au bon niveau, sans mélange de responsabilités.

Self-Service (demandeurs) : accès limité à la création de tickets.

Technicien : droits étendus pour la gestion des tickets.

Superviseur : vue globale pour superviser et réassigner les tickets.

  1. Affectation des Équipements et des Profils : Organisation des Responsabilités

Par la suite, j’ai attribué des profils utilisateurs ainsi que du matériel adapté à chaque personne :

Paul Hochon : Profil Self-Service.

Guy Mauve et Marie Tim : Profils Technicien.

Sandy Kilot : Profil Superviseur.

  1. Mise en Place et Suivi des Tickets : Une Démarche Indispensable Contenu d’un ticket

Dans GLPI, un ticket doit comporter des informations structurées et détaillées afin d’assurer un traitement efficace :

Titre : résumé clair du problème (ex. : « L’imprimante ne fonctionne plus »). Description : explication détaillée de l’incident (ex. : « L’imprimante HP123 ne répond plus depuis hier matin »). Impact et urgence : éléments permettant d’évaluer la priorité. Assignation : technicien en charge du ticket. Statut : ouvert, en cours de traitement, résolu, etc.

Exemple concret Paul Hochon (Self-Service) a ouvert un ticket afin de signaler un dysfonctionnement. Guy Mauve (Technicien) a pris en charge le ticket, ajusté les niveaux d’impact et d’urgence, puis utilisé la matrice de priorité pour le classer comme « Important ».

  1. Gestion des Problèmes

Quand plusieurs incidents se ressemblent je crée un Problème.

Exemple :

Plusieurs tickets “panne disque” sur des serveurs DELL récents.

Sandy Kilot ouvre un Problème : “Pannes récurrentes de disques sur serveurs DELL”.

Il lie les incidents (celui de Paul, et d’autres) au Problème.

L’objectif devient alors : identifier la cause racine (lot matériel, firmware, conditions, configuration) et définir une action durable (mise à jour, remplacement préventif, standard).

  1. Rapport avec ITIL

J’ai aligné l’organisation sur une logique ITIL simple et compréhensible :

Incident : restaurer vite le service.

Problème : réduire la récurrence et traiter la cause racine.

Priorisation : impact + urgence → priorité.

Traçabilité : historique des actions.

GLPI fournit l’outil et le workflow ; ITIL fournit la méthode de classement et d’amélioration continue.

  1. Feedback Utilisateur

Un élément central du processus de ticketing concerne le retour des utilisateurs :

GLPI offre la possibilité de demander au demandeur de valider la résolution, afin de s’assurer que la solution apportée répond réellement à son besoin.

  1. Différence entre un incident et un problème

Incident : événement qui dégrade ou interrompt un service (objectif : remise en service rapide).

Problème : cause (ou cause potentielle) d’un ou plusieurs incidents (objectif : éviter la répétition).