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.
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.
Identifiez un incident
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
Problème
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 :
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.
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.
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.
