Ticketing GLPI
Dans le cadre de ma formation BTS SIO, j'ai intégré GLPI avec Active Directory via LDAP, importé les utilisateurs et groupes, puis géré des tickets d'incidents et de problèmes en suivant la méthodologie ITIL.
Lire la source originale (Référentiel BTS SIO)Compétences mobilisées
B1.1.3 — Mettre en place et vérifier les niveaux d’habilitation associés à un service
B1.2.1 — Collecter, suivre et orienter des demandes
B1.2.2 — Traiter des demandes concernant les services réseau et système, applicatifs
Intégration GLPI / Active Directory
Pour éviter de gérer deux bases d’utilisateurs distinctes, j’ai connecté GLPI à l’annuaire Active Directory via le protocole LDAP (Lightweight Directory Access Protocol). LDAP est le protocole standard permettant d’interroger un annuaire de type Active Directory.
La configuration dans GLPI comprenait :
- L’adresse IP du contrôleur de domaine
- La requête LDAP pour rechercher les utilisateurs
- Les identifiants d’un compte administrateur AD autorisé à lire l’annuaire
- Le mapping des champs LDAP (samaccountname pour le login, objectguid pour l’identifiant unique)
Après configuration, j’ai importé les groupes et utilisateurs depuis AD dans GLPI. Les utilisateurs peuvent désormais se connecter à GLPI avec leurs identifiants de domaine Windows.
Définition des habilitations dans GLPI
GLPI propose plusieurs profils avec des droits différents :
- Self-Service : l’utilisateur peut créer des tickets pour lui-même mais ne voit pas les tickets des autres.
- Technician : peut voir et traiter les tickets, mais ne peut pas les supprimer.
- Supervisor : droits étendus, peut supprimer des tickets, escalader, affecter à d’autres techniciens.
J’ai configuré les profils suivants : Paul Hochon en Self-Service, Guy Mauve et Marie Tim en Technician, Sandy Kilot en Supervisor.
Gestion d’un ticket d’incident
J’ai simulé le cycle de vie complet d’un ticket en suivant la méthodologie ITIL :
- Ouverture : Paul Hochon (Self-Service) ouvre un ticket d’incident pour son serveur DELL.
- Qualification : Guy Mauve (Technicien) s’attribue le ticket, évalue l’urgence, l’impact et la priorité selon la matrice GLPI.
- Mise à jour : Guy Mauve ajoute les résultats de son diagnostic (analyse RAID défaillant via mdadm).
- Escalade : Sandy Kilot (Supervisor) transfère le ticket à Marie Tim, plus compétente sur le sujet.
- Résolution : Marie Tim clôture le ticket avec le commentaire “Disque HS remplacé, RAID 5 en cours de reconstruction”.
- Approbation : Paul Hochon approuve la solution, le ticket passe en statut “Clos”.
Gestion d’un ticket de problème
La panne de disque s’étant produite plusieurs fois sur des serveurs DELL neufs, Sandy a ouvert un ticket de problème pour en rechercher la cause racine. Après investigation, la cause identifiée était un firmware buggé sur une série de disques DELL nécessitant une mise à jour (KB5465288865786).
Ce ticket de problème a été lié au ticket d’incident initial, illustrant parfaitement la distinction ITIL : l’incident = le disque HS (conséquence), le problème = le firmware défaillant (cause).
Ce que j’ai appris
Ce TP m’a permis de comprendre concrètement le fonctionnement d’un centre de services IT en entreprise. La traçabilité complète des actions dans GLPI (historique, escalades, solutions) est essentielle pour respecter les engagements du SLA. En tant que développeur, cette expérience m’aide à concevoir des applications avec des workflows de validation, des rôles utilisateurs bien définis et un historique des actions.