Traiter un incident et assurer la gestion du parc informatique

J'utilise GLPI et la bibliothèque ITIL

Du bon sens à la méthode

Au service support du CHU de Groloin, un chirurgien signale qu'un poste ne démarre plus, à quelques minutes d'une consultation. L'urgence est réelle, mais elle ne dispense pas de méthode : ouvrir un ticket, consulter l'historique de la machine, appliquer une démarche structurée, tracer chaque action. C'est ce cadre méthodique que vous apportent deux outils complémentaires : la bibliothèque ITIL, qui décrit comment traiter un incident, et GLPI, qui vous donne l'outil pour le faire.

ITIL : un vocabulaire commun pour le support

ITIL (Information Technology Infrastructure Library) est un ensemble de bonnes pratiques reconnues pour organiser la gestion des services informatiques. Vous n'avez pas besoin de la connaître dans son intégralité pour démarrer : l'essentiel, à ce stade, est de savoir distinguer deux notions que l'on confond souvent.

Un incident est une interruption ou une dégradation non planifiée d'un service : le poste du chirurgien qui ne démarre plus, une imprimante qui ne répond plus, une boîte mail inaccessible. Le but face à un incident est de rétablir le service le plus vite possible, quitte à contourner la cause réelle dans l'urgence.

Un problème, au sens ITIL, est différent : c'est la cause sous-jacente d'un ou plusieurs incidents, souvent récurrents. Si trois postes du même service tombent en panne le même mois pour la même raison, chaque panne est un incident traité individuellement, mais leur cause commune relève d'une analyse de problème, généralement portée par un niveau d'expertise supérieur au vôtre en tant que support N1.

Traiter un incident : les cinq étapes

Un incident se traite selon un enchaînement structuré :

Pour le poste du chirurgien, cela donne concrètement : ticket ouvert immédiatement, priorité maximale compte tenu de l'impact (consultation imminente), diagnostic rapide (alimentation ? carte mère ? disque ?), éventuellement prêt d'un poste de secours en solution de contournement le temps de la réparation définitive, puis clôture une fois le chirurgien confirmé opérationnel.

Une démarche méthodique pour ne pas s'éparpiller

Face à un incident qui ne se résout pas au premier coup d'œil, la tentation est de tester des solutions au hasard. Une démarche structurée reste plus efficace :

1. Isoler le problème : est-il local (le poste), réseau (la connexion), ou serveur (le service central) ?
2. Identifier les changements récents : qu'est-ce qui a changé depuis que ça fonctionnait ? Une mise à jour, un nouveau matériel, une intervention récente sont les premiers suspects.
3. Émettre des hypothèses et les tester par ordre de probabilité, en commençant par la moins coûteuse en temps.
4. Valider la solution une fois la correction appliquée, avant de considérer l'incident comme résolu.

Cette logique s'appuie souvent, en réseau, sur une lecture par couches (le modèle OSI) : la carte réseau physique fonctionne-t-elle ? L'adresse IP est-elle correcte ? Le service applicatif répond-il ? Chaque couche écartée resserre le champ des causes possibles.

GLPI : l'outil qui porte cette méthode

GLPI (Gestion Libre de Parc Informatique) est le logiciel open source de référence pour le ticketing et l'inventaire, utilisé au CHU de Groloin comme point d'entrée unique de tous les incidents. L'exploiter correctement suppose trois réflexes :

• Lier chaque ticket à un objet de l'inventaire — la machine concernée, l'utilisateur demandeur — plutôt que de le laisser isolé. Cela permet de retrouver l'historique complet d'un poste en un coup d'œil : pannes précédentes, interventions, garantie.
• Faire vivre le statut du ticket avec rigueur : Nouveau à l'ouverture, En cours (attribué) dès que vous le prenez en charge, En attente si vous patientez sur une réponse de l'utilisateur ou d'un fournisseur, Clos seulement après vérification.
• Documenter le suivi à chaque action, pour qu'un collègue puisse reprendre le dossier sans vous solliciter si vous êtes absent.

Connecter GLPI à l'annuaire de l'établissement

Sur une installation GLPI en production comme celle du CHU de Groloin, les comptes utilisateurs ne sont pas ressaisis manuellement : ils sont synchronisés depuis l'annuaire Active Directory de l'établissement, via le protocole LDAP. Voici, à titre d'exemple, la configuration d'un environnement type (serveur AD SRVAD1 sur le domaine contorse.lan, GLPI hébergé sur un serveur Linux Debian 12 SRVLX1 avec Apache2) :

1. Dans GLPI, aller à Configuration → Authentification → Annuaire LDAP.
2. Cliquer sur + Ajouter, puis choisir la préconfiguration Active Directory.
3. Renseigner le formulaire :

• Nom : de préférence le nom du serveur, pour rester lisible dans la configuration ;
• Serveur par défaut : Actif = Oui ;
• Serveur : le FQDN (SRVAD1.contorse.lan) ou l'adresse IP du contrôleur de domaine ;
• BaseDN : le point de départ de la recherche dans l'annuaire, par exemple OU=Utilisateurs,OU=NAS,DC=contorse,DC=lan ;
• DN du compte (pour une connexion non anonyme) : un compte de service dédié, par exemple glpiuser@contorse.lan, avec son mot de passe.

1. Valider avec Ajouter.

Une fois l'annuaire connecté, l'import des comptes se fait depuis Administration → Utilisateurs → Annuaires LDAP → Importation de nouveaux utilisateurs : passage en Mode Expert, Rechercher, sélection de tous les résultats via le champ de synchronisation, puis Action → Importer → Envoyer.

Ce type de configuration relève généralement d'un administrateur GLPI plutôt que d'un technicien support de premier niveau, mais comprendre ce mécanisme vous aide à expliquer, face à un utilisateur qui ne parvient pas à se connecter à GLPI avec son compte du CHU, pourquoi la source du problème peut se trouver du côté de l'annuaire et non de l'application elle-même.

Incident ou problème : bien qualifier dès l'ouverture du ticket

La distinction entre incident et problème, vue plus haut, doit se refléter dès la création du ticket dans GLPI, car elle conditionne le traitement qui en découlera :

Un technicien de niveau 1 n'a pas vocation à résoudre lui-même une analyse de problème complexe, mais savoir la repérer et la signaler évite que les mêmes incidents ne reviennent indéfiniment sans jamais être traités à la racine.

Priorité et impact : ne pas confondre les deux

La priorisation d'un ticket dans GLPI combine deux critères souvent confondus par un technicien débutant :

• l'urgence, qui mesure la rapidité attendue de résolution du point de vue de l'utilisateur ;
• l'impact, qui mesure le nombre de personnes ou de services affectés par l'incident.

Un poste isolé en panne pour un agent administratif est urgent pour lui, mais d'impact limité. Une coupure réseau touchant un service entier de consultation a un impact large, même si chaque utilisateur individuel patiente sans appeler immédiatement. La priorité réelle d'un ticket combine ces deux dimensions, ce qui explique qu'un incident signalé calmement puisse malgré tout être traité avant un appel plus véhément mais d'impact limité.

Ce que vous savez faire maintenant

Vous savez désormais distinguer un incident d'un problème au sens ITIL, dérouler les cinq étapes de traitement d'un incident, appliquer une démarche méthodique pour isoler une cause, et exploiter GLPI avec la rigueur attendue : liaison aux objets, statuts à jour, suivi documenté. Vous comprenez également d'où viennent les comptes utilisateurs de GLPI, synchronisés depuis l'annuaire Active Directory du CHU. Cette maîtrise du ticketing est le socle sur lequel s'appuient les chapitres suivants, consacrés aux missions concrètes que vous traiterez au quotidien.