Découvrez les situations d'utilisation de GLPI pour le Centre

de services

De nos jours, le numérique est omniprésent. Les systèmes d’information (SI) des entreprises ont
évolué en fonction des nouveaux usages liés à la transformation digitale.
L’utilisation des moyens numériques est devenue ATAWADAC : at Any Time, Any Where, Any
Device, Any Content ; « tout, partout, tout le temps, quel que soit le support » (poste de travail,
smartphone, etc.).
Les SI sont désormais au cœur de l’activité des entreprises et le moindre dysfonctionnement
entraîne des risques cruciaux : mécontentement des clients, réputation négative, pertes de revenus,
voire mise en péril de l’entreprise.
Ces évolutions majeures obligent les entreprises à repenser leur support informatique, et à
l’organiser en suivant les bonnes pratiques d’ITIL via un logiciel de gestion de tickets comme
GLPI, pour traiter et se protéger contre les pannes, les pertes de données, etc.
Nous allons voir dans ce chapitre les principales situations d’utilisation de GLPI par les
techniciens du centre de services, comprendre les fondamentaux ITIL organisant ce centre de
services, et suivre le cycle de vie d'un ticket dans GLPI, depuis sa création jusqu’à sa clôture.

Qu'est ce que ITIL ?

ITIL signifie Information Technology Infrastructure Library. En français, on traduirait par
bibliothèque pour l'infrastructure des technologies de l'information 🤔. C'est un ensemble de bonnes
pratiques permettant d'assurer une bonne gestion du SI d'une entreprise.
→ Ce cours ne se focalise pas sur ITIL mais si vous souhaitez en savoir plus, n'hésitez pas à jeter un
œil au chapitre Comprenez le référentiel de bonnes pratiques ITIL du cours Mettez en place les
bonnes pratiques ITIL lors de vos déploiements.

Qu'est-ce que GLPI ?

GLPI est un outil ITSM pour IT Service Management. C'est un outil open source qui permet de
mener de nombreuses actions de gestion de l'IT, comme la gestion de parc ou le suivi des tickets
utilisateurs.
→ Ce cours ne présente pas comment installer GLPI, mais si vous avez besoin d'aide pour installer
votre serveur GLPI, ce qui sera mieux pour suivre ce cours, vous pouvez suivre le chapitre Installez
votre serveur GLPI du cours Gérez votre parc informatique avec GLPI.
À défaut, vous pouvez utiliser la version de démo en ligne de GLPI, mais il ne vous sera pas
possible de la personnaliser avec votre base de données.
Les outils ITSM et de helpdesk comme GLPI sont nombreux ! Et vous en utiliserez probablement
un autre que GLPI en entreprise. Ce sera même probablement un outil Sass (un outil en ligne)
puisque cette tendance se développe (Zendesk, Freshservice, Jira...). Pas d'inquiétude, les concepts
que nous couvrirons dans ce cours sont largement exportables à ces outils. Vous y retrouverez les
mêmes concepts généraux et les mêmes bonnes pratiques.

Identifiez un incident
Comme nous allons le voir avec des exemples ci-dessous, un incident correspond à un
comportement anormal d’un composant des SI : dysfonctionnement matériel, logiciel, réseau.
GLPI permet d’orchestrer la gestion des incidents informatiques, comme par exemple :
• les défaillances de messagerie :
• restaurer un email perdu (supprimé à tort, ou positionné en quarantaine),
• restaurer l’accès à ma messagerie (impossible d’accéder à mes mails) ;
• les pannes de matériel :
• clavier, souris, disque dur,
• poste de travail lent (« mon PC rame »),
• renouvellement de poste de travail obsolète,
• ordinateur qui redémarre lorsque je l’éteins,
• imprimante défectueuse,
• téléphone hors service,
• demande d’un casque téléphonique pour avoir les mains libres ;
• les ruptures de connexion au réseau de l’entreprise :
• impossibilité d’accéder à une ressource,
• pas de WiFi sur un PC portable,
• réinitialisation d’une session,
• création d’un compte utilisateur ;
• les soucis bureautiques :
• besoin de la dernière version d’Office pour pouvoir lire un document envoyé par un
client,
• restauration d’un fichier ou d’un dossier complet, suite à effacement accidentel ;
• les anomalies d'applications métier :
• erreur de calcul du prix de vente,
• erreur Internet : « La page que vous recherchez a été déplacée ou n'est pas disponible
(erreur 404) »,
• erreur d’affichage des soldes de RTT/congés payés.
Identifiez un problème
Les processus et méthodes de résolution sont différents selon qu’il s’agit d’un incident ou d’un
problème. ITIL nous permet de distinguer incident et problème, afin de traiter chacun de façon
appropriée.
Incident ou problème, comment savoir les distinguer ?

Incident
Un incident est isolé et ne nécessite pas la résolution d'un problème plus global. La gestion des
incidents permet de restaurer le fonctionnement normal du service, souvent par un
contournement, pas toujours par une résolution définitive.

Problème
Lorsqu'un incident se répète, ou lorsque plusieurs incidents résultent de la même cause
supposée, il s'agit d'un problème. La gestion des problèmes, elle, vise à traiter la cause de
l’incident pour que celui-ci ne se reproduise plus. GLPI permet d’orchestrer aussi bien la gestion
des incidents que la gestion des problèmes.

Exemple 1
Situation : échec de l’alimentation quotidienne du datalake.
Correction de l’incident dans l’urgence : contournement par modification d’un paramètre sur le
serveur du datalake. Cette modification est temporaire, car contraire aux règles de base de sécurité
informatique. Une fois le chargement du datalake effectué, le technicien remet le paramètre à sa
valeur initiale.
Le lendemain : répétition de l’incident car le datalake n’est pas alimenté encore une fois.
L’incident est donc identifié comme étant un problème, dont il est nécessaire d’investiguer la cause
“inconnue” afin de le résoudre définitivement.

Exemple 2
Situation : lenteur d’une application de saisie d’une commande client.
Premier cas : diagnostic du technicien : l’application sur le poste de travail n’est pas dans sa
dernière version disponible. Il installe la dernière version et l’incident est résolu définitivement →
Ce cas est un incident.
Deuxième cas : le technicien diagnostique un problème de performance coté serveur. Il redémarre le
serveur. L’application fonctionne normalement jusqu’au lendemain où l’application est à nouveau
lente → ce cas est un problème, car l’incident est récurrent. Une investigation de la cause de la
lenteur sur le serveur est à mener pour trouver une solution de fond…

Identifiez un changement
La résolution d’un incident, d’un problème (ou encore un nouveau projet) peut entraîner un
changement de configuration des systèmes d’information. Un tel changement est rarement neutre.
Vous avez peut-être déjà entendu parler de ces cas qui ont fait parler d’eux :
 1. Durant plus de deux jours, des milliers de clients n'ont pas pu accéder à leur compte en ligne
car les SI de la banque sont tombés suite à l'échec du processus de déploiement de la
dernière version de l'une de ses applications.
2. Gros souci de performance d’une base de données Oracle suite à une mise à jour de ses
infrastructures (passage d’un serveur physique à une machine virtuelle) : l’absence de
déploiement en production de nouveaux paramètres sur les serveurs a provoqué ces lenteurs.
Les conséquences d’un changement de configuration peuvent donc être critiques. Il convient
donc de les gérer via GLPI, en suivant les bonnes pratiques d’ITIL : le processus de gestion des
changements précise les opérations et le dispositif à mettre en place pour veiller aux risques de
régression de l’existant, selon l’impact présumé du changement (majeur ou pas…), ou bien selon la
maîtrise de ce changement (changement standard…).
Ci-après, d’autres exemples de gestion de changements :
• changement d’infrastructure : remplacement d’un switch/routeur pour corriger un
bagotage réseau ;
• changement logiciel système : renouvellement d’un certificat (Java, SSL…) ;
• changement applicatif : nouvelle version d’une application de création d’une facture
fournisseur corrigeant un message d’erreur systématique (bug).

Restez serein pour traiter vos incidents

Une des difficultés du centre de services est l’accumulation d’incidents qui arrivent sur une même
période. Plusieurs incidents peuvent être signalés en même temps (plus ou moins importants, et
parfois en grand nombre) et générer un fort stress du technicien.
La résistance au stress est importante dans ce métier de relation client – fournisseur :
• le client : les utilisateurs internes à l’entreprise et les utilisateurs clients de l’entreprise ;
• le fournisseur : la DSI est le fournisseur de services numériques aux clients internes et
externes.
La pression est d’autant plus forte sur le technicien qu’il a conscience que le centre de services est
la vitrine de la DSI : une grande partie de la perception des utilisateurs de la DSI est issue de leur
relation avec le centre de services.
Lorsque la qualité de service du centre de services est perçue négativement, c’est toute l’image de
la DSI qui est perçue comme étant négative.
Pour aborder la relation avec les utilisateurs avec sérénité, le technicien a 2 points d’appui.

Un outil informatique éprouvé : GLPI

GLPI orchestre la gestion des incidents, aide à la priorisation, permet le suivi de l’avancement de la
résolution et fournit des indicateurs de qualité de service (qui sont une vraie réponse entre la qualité
perçue et la qualité mesurée).
Un relationnel adapté à la situation
Le technicien sait que l’utilisateur est dans une situation très indésirable, génératrice d’un réel
malaise. C’est en adoptant une posture d’aide, d’assistance et de bienveillance, ainsi qu’en se
mettant « à la place » de l’utilisateur, que la relation avec lui est apaisée et cordiale.
Pour cela, voici quelques attitudes clés à adopter :
• communication positive, constructive, et jamais conflictuelle. Ni de critique de l’utilisateur,
ni de critique de la DSI. Bannir par exemple de dire : « c’est encore un incident dû au chef
de projet, c’est toujours la même chose avec lui ! » : une véritable fonction de relation
publique ;
• toujours voir les faits du point de vue de l’utilisateur ;
• éviter le jargon technique ;
• pratiquer l’écoute active : poser des questions pertinentes et surtout reformuler ce
qu’exprime l’utilisateur pour valider la compréhension mutuelle de l’incident ;
• le plus : la connaissance du métier des utilisateurs. Un technicien qui parle la même
langue (métier) sera plus efficace.

En résumé
Dans ce chapitre :
• nous avons identifié des incidents : un incident correspond à un comportement anormal
d’un composant des SI ;
• nous avons appris à distinguer incident et problème : un incident ne nécessite pas la mise
en place d'une solution pérenne et sera souvent plus rapide à résoudre qu'un problème ;
• nous avons compris l’importance de la gestion des changements ;
• nous sommes sensibilisés à la posture de fournisseur de service que doit adopter le
technicien dans sa relation avec les utilisateurs ;
• nous avons découvert que les bonnes pratiques ITIL au travers de GLPI nous permettent
d’assurer notre métier avec sérénité.
Dans
le prochain chapitre, nous découvrirons comment s'organise le centre de services pour la gestion
des tickets d'utilisateurs.
Comprenez l'organisation du Centre de services

Découvrez la notion de service SI dans le référentiel ITIL

Dans ce chapitre, nous allons découvrir comment le référentiel ITIL via GLPI permet d'organiser le
centre de services, maîtriser la situation et permettre la satisfaction des utilisateurs.
Que devons-nous savoir d’ITIL pour assurer notre métier ?
ITIL est un cadre de référence des meilleures pratiques de gestion des services informatiques
(ITSM – IT Service Management) : c’est un ensemble d'ouvrages qui recensent les bonnes pratiques
("best practices") en vue d’offrir des services SI de haute qualité.
ITIL est un référentiel de bonnes pratiques qui permet à la DSI d’apporter le meilleur service
possible à ses clients internes ou externes.
Découvrons maintenant ce qu’est un service SI au sens ITIL : c'est un moyen de fournir de la
valeur à l’entreprise.
Selon ITIL, la valeur d’un service est fonction de :
• son utilité : le service est adapté aux besoins du client ;
• sa garantie selon 4 axes : assurer la disponibilité, la performance, la sécurité de l’information
et la continuité de service.
Les bénéfices d’une approche orientée services sont multiples :
• la fourniture de services informatiques est plus orientée vers le client, sur les objectifs de
l’entreprise, en soutien du business en augmentant la productivité ;
• l’amélioration de l’efficacité du SI et la réduction des coûts associés ;
• l’augmentation de la qualité de service et de la satisfaction des utilisateurs (employés et
clients/partenaires) ;
• l’amélioration des relations DSI – utilisateurs grâce aux accords relatifs à la qualité des
services ;
• la réduction de l’impact des incidents sur les activités métiers, augmentant ainsi leur
performance.
Niveaux de service, SLA, accord de service : quèsaco ?
L’objectif de la gestion des niveaux de service est de conclure des accords clairs avec l’utilisateur
sur le type et la qualité des services informatiques à livrer, et de mettre en œuvre ces accords. Elle
structure toute la relation entre les directions utilisatrices et l'Informatique, en contractualisant la
fourniture des services.
La gestion des niveaux de service (SLM : Service Level Management) propose la création de trois
types d’accord :
 • le SLA (Service Level Agreement) ou accord de niveaux de service : accord défini entre
l’utilisateur (client du service) et la DSI sur le niveau de qualité de service offert ;
• le OLA (Operational Level Agreement) ou accord sur les niveaux opérationnels : accord
passé entre les différents pôles de la DSI ;
• l'UC (Underpinning Contract) ou contrat de sous-traitance : contrat entre la DSI et un
fournisseur externe.
L’ensemble présuppose l’existence d’un catalogue des services proposés par la DSI, qui a par
ailleurs l’intérêt de clarifier l'offre de l'informatique.
Les niveaux de service sont formalisés dans un contrat « convention de service » ou « contrat de
service », document écrit et signé des deux parties, qui comporte :
• la description du service, la durée du contrat ;
• les engagements : heures de fourniture/disponibilité du service, les délais de prise en charge
des appels au Centre de service, les délais de résolution (cibles de rétablissement de
services)…
Exemples de SLA : ouverture 24j/24–7h/7, ouverture aux heures ouvrées de bureau, rétablissement
du service en moins de 4 heures…
Les principaux bénéfices d’une gestion de niveaux de service ayant des SLA clairs et réalistes
sont :
• une meilleure compréhension mutuelle des besoins en termes de services SI ;
• un équilibre optimal entre les exigences de qualité/niveau de service et le coût d’exploitation
;
• une définition des critères objectifs de mesure de la qualité de service.

Apprenez le rôle du centre de services

Le centre de services (Service Desk) porte toute la relation entre le SI et les utilisateurs du SI. Il
coordonne toute l'activité support du SI. Il est le point de contact unique (SPOC : Single Point of
Contact) entre les utilisateurs et l’organisation informatique, pour l’ensemble des services proposés
par la direction des systèmes d’information.
Pourquoi un guichet unique de sollicitation de la DSI ? Le principe de base est que les utilisateurs
arrêtent de contacter toutes les personnes de l’informatique, entraînant des perturbations dans
les activités informatiques quotidiennes (études, projets, développements…).
4 grandes missions sont assurées par le centre de services :

1. Prendre en compte toutes les sollicitations des utilisateurs :

• accueillir, recevoir et enregistrer l’ensemble des appels, requêtes, réclamations, demandes,
incidents liés aux services fournis par la DSI ;
• suivre de bout en bout les demandes et incidents ;
• tracer et suivre toutes les interventions dans l'outil GLPI.
2. Assurer le bon traitement des sollicitations :
• résoudre les incidents conformément aux SLA, en facilitant le retour à un service
opérationnel normal en accord avec les conventions de niveau de service ;
• dépanner les utilisateurs soit en direct ou en différé, soit en escaladant vers d’autres équipes
plus qualifiées, c’est-à-dire en leur confiant la résolution de l’incident ;
• traiter les demandes ou les faire suivre aux équipes qui gèrent les demandes.

3. Prendre en charge la communication avec les utilisateurs :

• informer les utilisateurs sur l’état de leur sollicitation : donner de la visibilité sur le suivi de
l’avancement du traitement de leur demande, de leur incident ;
• assurer l’interface entre les opérationnels et la DSI via une communication apaisée, sereine
et efficace ;
• produire et diffuser des métriques de qualité de service : niveau d’activité (nombre de
tickets sur une période…), satisfaction perçue, délais réels de résolution… ;
• permettre d’améliorer l’image de la DSI auprès des utilisateurs.
Adapter votre communication est un facteur clé de réussite. L’attitude et le relationnel doivent être
exemplaires, dans un état d’esprit collaboratif au service des utilisateurs.
Le technicien adopte une posture de proximité avec les utilisateurs : être accessible, être
bienveillant, avoir la capacité à rassurer, comprendre le métier de l’utilisateur, permettre l’apport de
valeur par rapport au métier de l’utilisateur sont les qualités requises d’un technicien.

4. Coordonner les équipes support :

• permettre l’affectation, la planification et le suivi du traitement des demandes d’assistance,
d’intervention et de services ;
• définir le plan de déplacement ou d'installation de matériel (ressources, planning…) ;
• relancer les équipes si celles-ci sont proches du délai de fin d’intervention défini, ou sont
hors délais.
Tout ce qu’il ne faut pas faire : travailler continuellement en mode pompier. C’est le cas lorsque :
• il n'y a pas de support utilisateurs structuré ;
• les mêmes incidents sont résolus inlassablement sans éradication définitive ;
• les équipes DSI travaillent continuellement en mode interruption ;
• les changements apportés à l'infrastructure et aux applications ne sont pas coordonnés, tracés
et provoquent des régressions sur l’existant.
Le centre de services est une évolution majeure dans la gestion du support informatique. Fini le
centre d’appels qui ne fait qu’enregistrer les demandes. Fini le centre de support qui résout les
incidents sans prise de hauteur… Bienvenue dans l’ère du véritable apport de valeur ajoutée aux
métiers : le centre de services 🚀 .
Le centre d’appels (call center) : compétences techniques limitées et compétences métiers
inexistantes. S’en tient à la prise d’appels, à l’enregistrement et à l’affectation des demandes aux
personnes compétentes (délai de traitement long !).
Le centre de support (help desk) : ne traite (gestion, coordination et résolution) que les incidents,
avec un niveau technique peu approfondi, généralement peu communicant, peu proche des métiers.
Traite inlassablement le même dysfonctionnement qui se reproduit sans cesse.
Le centre de services (service desk) englobe plus de missions que le help desk ou le call center :
• approche client : extension à toutes les demandes. Restreindre les missions du centre de
services uniquement à la restauration du service normal aux utilisateurs dès que possible est
trop limité ;
• point de vue de l’utilisateur et connaissance du métier ;
• communicant ;
• prend la hauteur de vue nécessaire pour lancer la résolution définitive des incidents
récurrents.

Les bénéfices attendus du centre de services :

• ✅ optimisation de la gestion des demandes des utilisateurs qui bénéficient d’un point de
contact unique, quelle que soit la nature de leur demande, et d’une qualification immédiate
de celle-ci ;
 • ✅ accélération de la prise en charge et du traitement des tickets, diminution de
l’impact négatif sur l’activité de l’entreprise, et augmentation de la satisfaction de
l’utilisateur.

En résumé
Dans ce chapitre, nous avons :
• découvert ce qu’est un service au sens ITIL : un moyen d’apport de valeur ajoutée aux
métiers ;
• compris que les SLA (accords de niveaux de service) pertinents doivent être clairs et
réalistes. Ils seront le contrat entre la DSI et les utilisateurs quant aux services apportés ;
• cerné ce qu’est un centre de services à guichet unique : un rôle élargi à la prise en charge
de toutes les sollicitations (et pas seulement des incidents, comme le traite un help desk) ;
• déterminé les 4 missions principales du centre de services : prendre en compte toutes les
sollicitations, les traiter jusqu’à clôture, communiquer avec les utilisateurs, et coordonner les
équipes de support.
Dans le chapitre suivant, nous allons commencer à suivre le cycle de vie d'un ticket utilisateur
dans GLPI avec ITIL.

Suivez le cycle de vie d'un ticket dans GLPI

Créez un ticket et naviguez dans le logiciel GLPI

Pour prendre en main GLPI, nous allons dans cette section dérouler le processus de création d’un
ticket.
Prenez pour exemple une situation qui arrive souvent à chaque retour de congés : le
fameux oubli de mot de passe… Madame Zadot vous appelle et, avec une petite voix
toute penaude, vous dit : “je ne peux pas me connecter”.

Aller, hop, créez votre premier ticket, d’abord en vous connectant à GLPI (mais ça, ça a déjà été
fait dès votre arrivée ce matin au boulot).
Saisissez les informations pour permettre le traitement du ticket :
• date d’ouverture : laissez la date proposée par défaut ;
• type : demande ;
• catégorie : choisissez dans la liste déroulante : Connexion – Habilitation ;
• demandeur : choisissez dans la liste déroulante : Zadot Mirella ;
• attribué à : votre nom est affiché par défaut ;
• statut : Nouveau ;
• source de la demande : Appel au Service Desk ;
• urgence : Haute (il n’y a pas de débat : la personne ne peut pas travailler) ;
• impact : Moyen ;
• priorité : Haute ;
• lieu : Site Le Ponan - 3° étage ;
• titre : Réinitialisation du mot de passe de connexion MZADOT ;
• description : L'utilisatrice revient de congés et a oublié son mot de passe. Elle a fait
plusieurs tentatives de connexion avec des mots de passe erronés : elle a bloqué son compte.
Pour finir, cliquez sur le bouton Ajouter.
Un message pop-up vous confirme la création du nouveau ticket, avec son numéro (ici numéro 3).

Astuce pour effectuer 2 opérations en une seule fois. Si vous laissez vide le champ « attribué à », le
ticket est créé avec le statut « Nouveau ». Le fait de renseigner « attribué à » permet à GLPI de
créer le ticket directement avec le statut « en cours (attribué) » et évite ainsi de recharger le
ticket pour effectuer l’opération d’attribution à un technicien.
Pour retrouver dans GLPI le ticket nouvellement créé, 2 possibilités :
1) Allez à la page d’accueil de GLPI en cliquant sur le logo GLPI en haut à gauche :
2) Ou bien, choisissez dans le Menu Assistance > Tickets et effectuez une recherche sur le critère «
Caractéristiques – statut » = « non résolu » :

Suivez l'état d'avancement d'un ticket jusqu'à sa résolution

Dans la section précédente, nous avons démarré le processus de gestion d’un ticket, en le créant,
puis en l’attribuant à un technicien (dans notre cas, attribution à soi-même). Vous pouvez
maintenant dérouler le cycle de vie complet du ticket. Voyons comment se déroulera l'évolution
du ticket.

Découvrez les étapes du cycle de vie d'un ticket

À chaque étape, le ticket se voit attribuer un statut. Voyons chacune des étapes, son objectif et le
statut associé.
Étape du
Objectif Statut
processus

Enregistrement Création du ticket « Nouveau »

• Détermination de la catégorie de
ticket : incident, demande…
« Nouveau »
• Détermination de la catégorie :
Classification service impacté, composant Ou « En attente » si le technicien
d’architecture touché n’a pas les informations permettant
d’instruire le ticket
• Détermination de la gravité
(urgence, impact, priorité)

« En cours (attribué) »
Attribution du ticket à la personne
Traitement Ou « En cours (planifié) » si le
compétente
traitement du ticket n’est pas
effectué immédiatement

Le technicien estime avoir répondu à

Solution Résolu
l’attente de demandeur

Le demandeur confirme que la solution

Validation apportée par le technicien répond à son Clos
attente

En absence de validation formelle du

Clôture demandeur, le technicien qui a résolu le Clos
ticket peut le clore

Le temps de résolution indiqué dans GLPI correspond au temps passé du statut Nouveau au statut
Résolu, en neutralisant le temps pendant lequel le ticket est au statut En attente.
Exemple : ticket en statut Nouveau à 14 h, mis en attente d’informations du demandeur
nécessaires au traitement à 14 h 30, passé à En cours à 15 h 00, puis Résolu à 15 h 30
==> Le temps de résolution est de 1 h (et pas d’1 h 30).

Donc, quand vous posez une question au demandeur, vous devez mettre le ticket au statut En
attente afin de neutraliser le temps.

Revenez sur le ticket précédemment créé pour le traiter

Ici, le cas est simple, vous déroulez la procédure de réinitialisation du mot de passe et vous
l’indiquez dans GLPI en cliquant sur le menu Traitement du ticket et sur le bouton Solution :
• choisissez dans la liste déroulante le type de solution : réinitialisation Password dans AD ;
• saisissez la description précise de la solution : Déroulement de la procédure de
réinitialisation de mot de passe : Après confirmation par mail de la DRH que l'utilisatrice
 fait partie des effectifs, réinitialisation dans l'AD du mot de passe avec indication "changer
de mot de passe à la première connexion". Mot de passe initial généré par
[Link] et communiqué par téléphone à l'utilisatrice ;
• puis cliquez sur le bouton Sauvegarder.

Ne raccrochez pas ! Ayant identifié que la résolution est immédiate, bien sûr vous gardez en ligne
le demandeur jusqu’à la clôture du ticket...
Le ticket passe au statut Résolu et apparaît dans l’écran d’accueil de GLPI dans le cadre « Vos
tickets à clore » :

Dernière étape : obtenez la confirmation du demandeur que vous pouvez fermer le ticket
Cliquez sur le ticket dans l’écran ci-dessus.
Faites vérifier au demandeur que la solution apportée répond bien à son attente.
Ici, demandez-lui maintenant de se connecter avec le nouveau mot de passe.
C’est tout bon, alors inscrivez dans GLPI l’approbation par le demandeur de la solution
proposée.
Saisissez le commentaire : En direct au téléphone, l'utilisatrice s'est connectée avec le mot de
passe initial et heureuse de pouvoir travailler à son retour de vacances m'a remercié
chaleureusement ! OK donc pour clôture.

En discutant avec votre client, assurez-vous qu'il est d'accord pour clôturer le ticket

Et cliquez sur le bouton Approuver la solution.

Mon conseil : ne jamais clore un ticket sans avoir eu l’approbation du demandeur. Oui, oui, la
communication étant une des missions clés du centre de services, celui-ci ne peut pas prendre la
décision unilatérale de clore un ticket, sans s’assurer que le demandeur est bien dépanné. Rappelez-
vous tous les jours que vous êtes dans une véritable relation client – fournisseur.
Cette dernière action fait disparaître le ticket de la liste des tickets à traiter de l’écran d’accueil
GLPI.
Mais vous pouvez retrouver le ticket clos via le menu Assistance > Ticket et effectuer une recherche
sur le critère « Caractéristiques – statut » = « Clos ». Cela permet de voir si nécessaire tout
l’historique des actions effectuées (quoi, par qui et comment) sur ce ticket.
En résumé
Dans ce chapitre, nous avons :
• créé un ticket dans GLPI ;
• complété le formulaire de création du ticket de manière précise pour pouvoir le traiter le
plus rapidement possible ;
• déroulé le cycle de vie (processus complet de gestion) d’un ticket, au travers de ses étapes :
enregistrement, classification, traitement, solution, validation et clôture ;
• navigué dans GLPI pour suivre l’état d’avancement du ticket et recherché un ticket selon
son statut : nouveau, en attente, en cours (attribué), en cours (planifié), résolu et clos.
Vous pouvez maintenant passer au quiz pour vérifier vos compétences à la suite de cette première
partie.
Dans les 3 prochaines parties, nous découvrirons plus en détail comment gérer les 3 types de
tickets : les incidents, les problèmes et les changements. Commençons par les incidents dans la
prochaine partie !

Créez et qualifiez un ticket d’incident

Identifiez un incident
Nous allons voir dans ce chapitre comment créer un ticket d’incident dans GLPI, et étudier sa
gravité pour définir l’ordre de priorité de traitement parmi toute la file d’incidents.

Mais tout d’abord, qu’est-ce qu’un incident au sens ITIL ?

Le référentiel ITIL définit un incident par : tout événement qui ne fait pas partie du fonctionnement
standard d’un service et qui entraîne, ou peut causer, une interruption ou une diminution de la
qualité de ce service.
Le fonctionnement standard (ou normal) d’un service est défini dans les SLA* décrits dans les
contrats ou conventions de service.
Prenons comme exemple le service d’accès à Internet dont le débit normal serait défini
comme supérieur à 50ko/s dans les SLA. Si un utilisateur se rend compte qu’il
télécharge sur un débit de 70ko/s, même si c’est trop faible pour lui, ce n’est pas un
incident car ça reste conforme aux SLA.

* La notion de niveau de service SLA est décrite dans la partie 1 de ce cours.

Un incident correspond donc à une interruption non planifiée ou une dégradation de la qualité
d’un service informatique, qui sera donc souvent déclarée par un utilisateur.
Mais ITIL va plus loin : un incident est aussi une défaillance d’un élément de configuration n’ayant
pas encore impacté le service, qui sera donc détecté par un outil de supervision de l’exploitation
informatique.
Par souci de simplification et de façon générale, un incident s’identifie par :
• un dysfonctionnement : interruption imprévue d’un service SI ;
• ou chaque fois qu’un événement détériore, perturbe ou menace le niveau d’un service.
Une fois que le technicien est informé de l’existence d’un incident, il va le prendre en charge dans
l’objectif de le résoudre.
Que doit faire le technicien de support informatique lorsqu’il est avisé d’un incident ?
Le technicien va dérouler le processus ITIL de gestion des incidents (Incident Management, en
anglais), dans l’objectif :
• de restaurer dans les délais les plus courts le fonctionnement normal des services et de
réduire au minimum l’impact sur les activités métiers/business (utilisateurs et clients) ;
• et de s’assurer ainsi que les meilleurs niveaux de qualité de service et de disponibilité
convenus sont maintenus, conformément au contrat de service (SLA).
ITIL structure l’organisation de la gestion des incidents, pour éviter l’écueil classique de mobiliser
tous les informaticiens pour un incident qui peut être résolu directement par le technicien de
support informatique.
En effet, le rétablissement du service normal dès que possible ne doit pas dégrader les autres
activités (projets, études) menées par la DSI, qui doit respecter ses engagements en termes de délai,
coût et qualité.
En synthèse, l’objectif de la gestion des incidents est de :
• rétablir le fonctionnement normal (au sens SLA) du service à l’utilisateur (interne à
l’entreprise, ou client) ;
• par tous les moyens possibles ;
• aussi vite que possible ;
• avec le minimum d’impact sur les activités de la DSI.
Identifions maintenant plusieurs cas typiques d’incidents.

Découvrez des exemples d’incidents plus ou moins graves

L’objectif de cette section est :
1. De citer des exemples d’incidents fréquemment rencontrés.
2. De commencer à catégoriser un incident et d’en évaluer la gravité.
Les pannes de matériel
La catégorie la plus fréquente d’incident concerne les pannes de matériel informatique :
• panne d’un poste de travail (ordinateur fixe, PC portable, tablette, client léger…) d’un
utilisateur ;
• serveur hors service. Tous les utilisateurs voulant accéder aux applications/données sur ce
serveur sont bloqués ;
• dysfonctionnement global d’un smartphone/téléphone mobile/téléphone fixe du
directeur commercial ;
• remontée d’alerte automatique : avertissement sur seuil atteint de la capacité d’espace
disque d’un serveur ;
• imprimante bloquée pour tout un département ou service.

Les incidents réseau

Des incidents liés aux réseaux sont aussi très souvent rencontrés :
• réseau défaillant : plus de communication vers Internet depuis un navigateur pour tous les
salariés de l’entreprise ;
• plus de connexion possible au système d’information pour tout un bâtiment/site ;
• lenteur constatée sur un site de production situé en Espagne ;
• remontée d’alerte automatique : avertissement sur seuil atteint de la bande passante ;
• dysfonctionnement du WiFi sur le smartphone du PDG ;
• compte bloqué après saisie de mot de passe invalide d’un comptable qui n’a plus que
quelques heures pour finaliser la clôture comptable mensuelle.

Les défaillances de logiciels

Bon nombre d’incidents se rapportent aussi aux défaillances de logiciels ou d’applications métiers
ou bureautiques :
• application indisponible : impossible de respecter les engagements de ventes, impact direct
sur le chiffre d’affaires ;
• fonction applicative non disponible : calcul de paie de tous les salariés ;
• erreur de programme (bug) lors de la passation d’une commande : risque d’impact sur le
chiffre d’affaires ;
• absence de synchronisation des emails entre la messagerie sur le PC et celle sur le
smartphone de la directrice des opérations ;
• page d’un site web inaccessible (erreur HTTP 404) pour une recherche d’information par
un employé ;
• diminution de la performance d’une application de contrôle de la qualité des produits
fabriqués ;
 • impossibilité de sauvegarder un fichier MS-Word dans Office365.

Les demandes diverses

Au-delà de ces incidents classiques, certaines sollicitations du service Desk peuvent se référer à des
demandes diverses, qui sont aussi suivies dans le cadre de la gestion des incidents :
• demande d’information, de documentation utilisateur (mode opératoire), d’assistance ou
de conseil suite à un défaut de maîtrise de certaines fonctionnalités applicatives ;
• demande de conseil d’utilisation ;
• perte de droits d’accès, oubli d’un mot de passe au retour de congés.
La provenance, les canaux de signalement des incidents au support informatique sont variés :
• utilisateur par appel téléphonique, par mail, voire se déplaçant directement dans l’espace de
travail du support ;
• sources automatiques : mails d’alerte des outils de supervision, souvent considérés dans
l’exploitation courante. Ces événements sont traités dans le cadre de la gestion des incidents,
même si le service délivré aux utilisateurs n’est pas « encore » affecté.
Comme vous pouvez le voir au travers de ces exemples, un incident est plus ou moins important
et peut impacter une ou plusieurs personnes. Nous allons découvrir dans la prochaine section
comment établir la priorisation de la prise en charge des incidents.

Définissez la priorité de traitement de l'incident

Évaluer la gravité, l’étendue d'un incident pour déterminer son ordre de traitement dans la file
des incidents, est un des rôles clés du technicien. Ainsi, à la fin de cette section, vous saurez
comment prioriser la résolution de chaque incident.
La priorité d’un incident permet d’identifier dans quel ordre les incidents doivent être traités par
les équipes du service Desk.
Les sollicitations du service Desk sont nombreuses et plusieurs incidents peuvent être déclarés
simultanément. Afin de renforcer la satisfaction des utilisateurs, le traitement efficient des incidents
s’organise selon un ordre de priorité précis et établi à l’avance : évitons en permanence le
mécontentement des utilisateurs vis-à-vis de la direction SI !
ITIL nous guide pour déterminer la priorité d’un incident : ce sont les critères métiers qui doivent
être pris en compte, et non les critères informatiques.
La priorité est la combinaison de l’impact et de l’urgence de l’incident :
• impact (ou sévérité) : effet d'un incident sur l’activité, sur le business (risque sur le chiffre
d’affaires ou sur les potentielles pertes financières).
Les incidents qui affectent beaucoup d’utilisateurs ont un effet plus sensible sur l’activité
de l’entreprise et doivent être résolus plus rapidement qu’un incident qui concerne peu
d’utilisateurs ;
• urgence (ou criticité) : temps que peut mettre un incident à avoir des répercussions
négatives sur les affaires. C’est donc la rapidité à laquelle l’entreprise a besoin d’une
solution.
La priorisation dépend aussi du rôle de (des) personne(s) perturbées par l’incident :
• VIP – Very Important Person : en général, les membres du comité exécutif, du comité de
direction. La liste des VIP est établie par la Direction générale ;
• VOP – Very Operational Person : souvent des personnes différentes en fonction du temps
(par exemple, le responsable de la paie en fin de mois), les VOP se définissent par le fait
qu’elles jouent un rôle clé sur l’activité. En général, il s’agit des personnes dont le métier
est la vente (risque d’impact sur le chiffre d’affaires), d’un domaine sensible (médical,
clôture comptable à J+6 du mois+1…) ou liées à la saisonnalité (pic d’activité).
Attention, lorsque vous évaluez la priorité de l’incident, fiez-vous à votre connaissance des
différents et critères et à vos collègues, mais pas à l’utilisateur concerné. Celui-ci sera presque
toujours persuadé que son incident est le plus prioritaire !
Soyons pragmatique et simple : afin d’éviter une complexité avec un grand nombre de
combinaisons possibles, nous pouvons restreindre à 3 niveaux d’impact et 3 niveaux d’urgence :
• niveaux d’impact :
• haut (ou élevé ou bloquant) : un grand nombre d’utilisateurs est impacté, ou c’est
une application majeure qui est concernée, ou encore il s’agit d’un VIP/VOP,
• moyen : un nombre limité d’utilisateurs est impacté, ou c’est une application
standard qui est concernée,
• bas (ou faible ou mineur) : un seul ou très peu d’utilisateurs (hors VIP/VOP) sont
impactés, ou c’est une application bureautique qui est concernée ;
• Niveaux d’urgence :
• haut (ou critique) : application ou équipement critique,
• moyen : application ou équipement non critique,
• bas (ou faible) : utilisation acceptable en mode dégradé.
Tout est question d’appréciation. En effet, les applications bureautiques peuvent être considérées
avec un impact haut et une urgence haute dans les situations suivantes :
• un document MS-Word, Google Docs… est fondamental pour la réponse à un appel
d’offres ;
• Un document MS-Excel, Google Sheets… est fondamental pour effectuer une prévision
budgétaire, un business plan…
Pour fixer correctement et rapidement la priorité sans avoir à repenser, recalculer à chaque fois les
combinaisons possibles, nous constituons en amont la matrice de priorités, conformément aux
contrats de niveaux de service. À l’intersection ligne (urgence)/colonne (impact), se situe la
priorité :
 Matrice d'évaluation de la priorité d'un incident

La matrice de priorité se configure dans GLPI via le menu Configuration > Générale > Assistance.

Si deux incidents ont la même priorité, ils doivent être traités dans l’ordre d’apparition sur le
principe FIFO : « First In – First Out » ou « premier entré – premier sorti ».
À chaque priorité est défini un délai maximum de remise en service. Chaque organisation définit
ses propres délais.
Voici un exemple complet de délais maximum de résolution dans la matrice des priorités :

Impact Impact Impact

Priorité & Délai de résolution
haut moyen bas

Urgence haute Priorité haute Priorité haute Priorité moyenne

Résolution en Résolution en Résolution en

 4 heures 4 heures 8 heures

Priorité haute Priorité moyenne Priorité basse

Urgence moyenne Résolution en Résolution en Résolution en

4 heures 8 heures 24 heures

Priorité moyenne Priorité basse Priorité basse

Urgence basse Résolution en Résolution en Résolution en

8 heures 24 heures 24 heures

Au-delà des priorités haute, moyenne et basse, GLPI permet de saisir une priorité majeure que
nous réservons aux cas d’incidents les plus graves.
Un incident majeur s’identifie par un degré d’impact extrême sur l’ensemble des utilisateurs
(internes ou clients).
Dans ces circonstances, il est nécessaire de déclencher une procédure particulière permettant de
mobiliser des ressources adaptées à la situation critique de l’entreprise :
• mise en place d’une cellule de crise ;
• information du haut management ;
• communication périodique toutes les x heures pour informer de l’état de situation, de
l’avancement de la résolution…
Ça y est, vous savez maintenant comment estimer la priorité de vos incidents et donc leur délai de
traitement.
Dans la prochaine section : c’est parti, vous allez savoir créer un ticket d’incident dans GLPI.

Créez le ticket incident dans GLPI

Dans cette section, nous allons créer notre premier ticket d’incident (fiche incident) dans GLPI.
Prenons un cas concret qui est assez fréquent au sein des entreprises : un vendeur appelle le centre
de services car son poste de travail est hors service.
GLPI offre 3 possibilités pour ouvrir un ticket :
• par email : l’utilisateur envoie un mail préformaté à une adresse mail générique de type «
centre-de-services-DSI@[Link] », en décrivant l’incident dans le corps du mail ;
• dans l'interface simplifiée de GLPI : saisie directement dans GLPI par l’utilisateur avec le
formulaire self-service de saisie allégé ;
• dans l'interface standard de GLPI : saisie par le technicien avec le formulaire de saisie
complet.
En tant que technicien, nous utilisons l’interface standard de GLPI, accessible depuis l’écran
d’accueil de GLPI par le menu Assistance > Créer un ticket.
Renseignez les champs de base
• Date d’ouverture : laissez la date et l’heure renseignées par défaut.
• Type : “incident” (un Incident concerne un dépannage, alors que la Demande appelle un
traitement suivant un circuit différent).
• Demandeur : le vendeur s’appelle Martial LODEZ.
• Attribué à : laisser ce champ renseigné par défaut avec votre nom.
• Statut : nouveau (pour nouvel incident).
• Source de la demande : appel au centre de services.
• Lieu : important pour localiser le demandeur (site, étage, n° de bureau…) : Agence Paris XII
- RdC - Bureau 047C.

Décrivez l’incident : soyez précis

C’est le moment le plus important du processus de gestion des incidents, car il permet de
comprendre l’incident et d’envisager les premières pistes de résolution.
• Titre : résumez le dysfonctionnement en quelques mots (soyez clair et succinct) : Poste de
travail ne démarre pas.
• Description : décrivez le fonctionnement anormal du service, de façon précise et
détaillée. Si un autre technicien que vous doit intervenir plus tard sur ce ticket, toutes les
précisions (contexte, cas d’utilisation…) lui serviront pour résoudre l’incident : M. Lodez
appuie sur le bouton Power de son poste de travail, et celui-ci ne démarre pas, même après
plusieurs tentatives.
• Catégorie : permet d’évaluer sur quel composant de l’infrastructure se situe l’incident. Si
le technicien n’a pas la compétence ou la capacité à résoudre l’incident, cette catégorisation
permet d’identifier le groupe de support vers lequel l’incident sera à diriger : Matériel.
Vous pouvez configurer les catégories sous forme arborescente (comme beaucoup de champs de
GLPI), par exemple la catégorie Matériel :
• poste de travail fixe ;
• PC portable ;
 • téléphone fixe ;
• téléphone mobile ;
• imprimante ;
• etc.

Saisissez les champs de classification de l’incident

C’est le moment d’évaluer la gravité de l’incident : vous saisissez Urgence et Impact, et GLPI en
déduit la priorité :
• urgence : l'urgence indique l'importance donnée par le demandeur au ticket. Cette valeur est
donc définie par le demandeur(ici, Monsieur Lodez). Le technicien apporte son conseil au
demandeur sur l’évaluation de l’urgence, en fonction des accords de niveaux de service :
• rappel de la définition de l’urgence : temps que peut mettre un incident à avoir des
répercussions négatives sur les affaires,
• ici, choisir dans la liste déroulante : Haute ;
• impact : cette valeur est définie par le technicien. C’est lui qui évalue l’impact en fonction
de sa connaissance globale de l’entreprise et de sa compréhension du métier.
• rappel de la définition de l’impact : plus l’incident a des répercussions négatives sur
le business, plus l’impact est haut,
• ici, choisir dans la liste déroulante : Moyen ;
• priorité : Laissez GLPI calculer la priorité, selon la combinaison de l’urgence et de
l’impact. Dans notre exemple :
• l’urgence est haute : plus on attend, plus l’impact sur les ventes et le chiffre
d’affaires sera élevé,
• l’impact est moyen : il ne s’agit que d’un seul vendeur qui est affecté par l’incident,
• ainsi, la priorité qui découle d’urgence et impact est : haute (selon la matrice des
priorités définie dans la section 3) ;
L’urgence et l’impact sont évalués : il s’agit d’une appréciation de la portée de l’incident sur
l’entreprise. Ce point de vue peut être subjectif, et peut être révisé à tout moment. Il arrive qu’un
incident initialement priorisé à un niveau Haut, puisse être repriorisé à un niveau Moyen, car mal
qualifié en termes d’impact au moment de la création du ticket dans GLPI.
Qualification d'un ticket dans GLPI avec toutes les informations nécessaires

• demande de validation : nécessaire lorsque les actions demandées au centre de services

sont soumises à autorisation. Par exemple, il faut saisir ici le nom du responsable du parc
informatique si le ticket concerne une demande d’un tout nouveau matériel ;
• les temps de prise en charge et de résolution sont gérés automatiquement en fonction des
SLA configurés dans GLPI :
• temps de prise en charge = la garantie de temps d'intervention (GTI) : délai dans
lequel un service accidentellement interrompu doit avoir occasionné un début
d'intervention,
• temps de résolution = la garantie de temps de rétablissement (GTR) : délai dans
lequel un service accidentellement interrompu doit être rétabli ;
 • idem pour les temps internes de prise en compte et de résolution interne : ils sont gérés
automatiquement en fonction des OLA configurés dans GLPI (un OLA est un engagement
interne aux différents pôles de la DSI) ;
• le champ Fichier permet d’ajouter au ticket un document utile à la compréhension et la
résolution de l’incident par les techniciens de la DSI. Il s’agit le plus souvent d’une capture
d’écran, et/ou de la description des circonstances de l’incident (se produit dans tel cas,
mais ne se produit pas dans tel autre).
Après avoir cliqué sur le bouton Ajouter, le ticket apparaît en tête de la file d’incidents, et une
notification par mail est envoyée au demandeur indiquant la référence (le numéro) du ticket créé :

Gérez les tickets récurrents

Qu’est-ce qu’un ticket récurrent dans GLPI ?
Un ticket récurrent est ouvert pour que GLPI crée automatiquement un ticket d’incident « juste
avant » que l’incident prévu ne soit effectif.
Ceci permet d’alerter le centre de services sur des cas comme :
• se préparer à intervenir suite à un bourrage papier lors de l’édition périodique d’un sujet
sensible ;
• ouvrir un ticket tous les mois pour se rappeler de vérifier le résultat de la sauvegarde
mensuelle ;
• valider que le traitement de clôture comptable à J+6 de M+1 s’est bien effectué ;
• etc.
Dans GLPI, ce type de ticket se crée via le menu Assistance > Tickets récurrents :
• saisissez le nom du ticket récurrent : Imprimante KDA2830 – Bourrage papier hebdo ;
• rendez ce ticket actif (choisissez Oui dans la liste déroulante) : cela permet de générer le
ticket incident, selon les critères/éléments suivants :
• gabarit de ticket : Bourrage Papier. C’est ce modèle de ticket qui sera utilisé pour
créer le ticket incident,
• date de début et date de fin de la création du ticket d’incident,
• périodicité de création du ticket (ici la fréquence est : tous les 7 jours),
• création anticipée : 2 heures avant l’incident hebdomadaire,
• calendrier : 2019 (permet de ne créer le ticket que sur les jours ouvrés de l’année
2019, et report à J+1 ouvré si le jour n’est pas ouvré) ;
• décrivez l’incident dans la zone commentaires : Lors de l'édition hebdomadaire des
factures, l'imprimante KDA2830 est en bourrage papier à la moitié de l'impression des
factures.
Puis cliquez sur le bouton Ajouter.
Dès lors que le flag « Actif » est positionné à « Oui » et que l’action automatique « ticket recurrent
» est activée dans GLPI, alors le ticket sera créé automatiquement.

En résumé
Dans ce chapitre, nous avons :
• découvert ce qu’est un incident au sens ITIL ;
• évalué le niveau de gravité de cet incident en veillant à recueillir de manière précise et
exhaustive toutes les informations relatives au dysfonctionnement rencontré, de manière à
être en mesure de prioriser, catégoriser et effectuer le diagnostic ;
• priorisé la résolution de l’incident, sachant que la priorité est la combinaison de l’impact et
de l’urgence, servant à identifier le délai acceptable de résolution d’un incident ;
• créé notre premier ticket d’incident ;
• et enfin appris à générer automatiquement un ticket récurrent.
Dans le prochain chapitre, nous allons suivre le traitement du ticket d'incident.