Apport d’informations et de connaissances

Traiter un ticket d’incident dans un service d’assistance

TABLE DES MATIERES

1 ORGANISATION ............................................................................................................................. 3
PRESENTATION ITIL .................................................................................................................... 3
Qu’est-ce qu’ITIL ? .................................................................................................................... 3
Les séries ITIL ........................................................................................................................... 3
ITIL V3 ....................................................................................................................................... 4
La gestion des services............................................................................................................. 5
La fourniture des services ......................................................................................................... 6
Le soutien des services............................................................................................................. 6
Le centre de services ................................................................................................................ 6
La gestion des incidents ........................................................................................................... 6
La gestion des problèmes ......................................................................................................... 7
La gestion des configurations ................................................................................................... 7
Gestion des changements ........................................................................................................ 7
Gestion des mises en production .............................................................................................. 7
La certification ITIL .................................................................................................................... 8
MODELES D’ORGANISATION................................................................................................................................. 8
ORGANISATION GENERALE D’UN SERVICE DESK.......................................................................................... 10
PRINCIPE DE FONCTIONNEMENT ...................................................................................................................... 10
LES ACTIVITES DU PROCESSUS ........................................................................................................................ 11
Détection et enregistrement .................................................................................................... 11
Classification et support initial ................................................................................................. 12
Investigation ............................................................................................................................ 12
Résolution et restauration du service...................................................................................... 13
Clôture ..................................................................................................................................... 13
2 PRISE EN CHARGE DE L’UTILISATEUR ET DE SON APPEL .................................................. 14
LE CONTACT ........................................................................................................................................................ 14
IDENTIFIER L’UTILISATEUR ET SON ENVIRONNEMENT MATERIEL ................................................................ 14
IDENTIFIER SON PROBLEME .............................................................................................................................. 14
CE QU'IL NE FAUT PAS DIRE .............................................................................................................................. 14
QUALIFICATION DE L’APPEL ............................................................................................................................... 15
Principe ................................................................................................................................... 15
Aide à la décision .................................................................................................................... 15
L’impact ................................................................................................................................... 15
L’urgence ................................................................................................................................ 16
La priorité ................................................................................................................................ 16
Exemple de grilles d’analyse .................................................................................................. 16
3 QUE DEVIENNENT LES APPELS QUALIFIES? ......................................................................... 17

ITIL-
Auteurs : J einhorny
GestionIncidents.doc Page 1 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

4 TRAITEMENT D'UN APPEL ......................................................................................................... 18

TRAITEMENT EN DIRECT ................................................................................................................................................... 18
TRAITEMENT DIFFERE ....................................................................................................................................................... 18
MECANISME DU TRAITEMENT D'UN APPEL AU NIVEAU 1 ............................................................................. 18
Documenter l'intervention .................................................................................................................... 18
Respecter les contraintes de temps .................................................................................................... 18
Affecter l'appel à un niveau 2 .............................................................................................................. 19
Déclencher une intervention................................................................................................................ 20
LES PROBLEMES ................................................................................................................................................................ 20
Signalement des problèmes ................................................................................................................ 20
Gestion des problèmes ....................................................................................................................... 20
5 CLOTURE D'UN APPEL ............................................................................................................... 22
QUAND CLOTURER UN APPEL .......................................................................................................................................... 22
QUI CLOTURE UN APPEL.................................................................................................................................................... 22

6 RENDRE COMPTE DE L'INTERVENTION ................................................................................... 23

LE SUIVI D'UN APPEL ......................................................................................................................................................... 23
QUI FAIT LE COMPTE RENDU D'INTERVENTION ............................................................................................................. 23
QUEL EST LE SUPPORT D'UN COMPTE RENDU .............................................................................................................. 23
QUAND FAIRE UN COMPTE RENDU D'INTERVENTION ? ............................................................................... 23
LES RUBRIQUES D'UN COMPTE RENDU D'INTERVENTION ........................................................................................... 23
Les rubriques renseignées à la création du compte rendu ................................................................. 23
Les rubriques renseignées lors de l'intervention ................................................................................. 24

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

1 ORGANISATION
Présentation ITIL
Qu’est-ce qu’ITIL ?
Comment organiser un système d'information ?
Comment améliorer l'efficacité du système d'information ?
Comment réduire les risques ?
Comment augmenter la qualité des services informatiques ?
ITIL (Information Technology Infrastructure Library, bibliothèque d’infrastructure des
technologies de l’information) est un ensemble de bonnes pratiques réunies dans une série
de livres. Le principe fondamental est que le service informatique dans une entreprise doit
être vu comme un fournisseur de services ayant des relations contractuelles avec ses
utilisateurs, définies dans le SLA (accord de niveau de service).
ITIL s’articule autour de quelques « séries » regroupant les différents aspects des services
informatiques. Chaque série interagissant avec les autres. Les plus fondamentales sont le
soutien des services et la fourniture des services.

Planifier la mise en place de la Gestion des Services

L
a
L Gestion des
es S
Services
T
e
e
Soutien des Gestion des c
M Perspective Services
IInfrastructures h
é Métier TIC n
t
o
i Fourniture
l
e des Services
o
r
Gestion de g
la Sécurité i
e
Gestion des Applications

Les séries ITIL

• Le soutien des services aux TI (Service support), décrivant comment l’utilisateur a

accès aux services informatiques appropriés, et comprenant
1. Le centre de services (Service Desk)
2. La gestion des incidents (Incident Management)
3. La gestion des problèmes (Problem Management)
4. La gestion des changements (Change Management)

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

5. La gestion des mises en production (Release Management)

6. La gestion des configurations (Configuration Management)

• La fourniture des services des TI (Service Delivery), décrivant les services devant
être fournis pour répondre aux besoins de l'entreprise.
1. La gestion financière des services des TI (IT Financial Management)
2. La gestion de la capacité (Capacity Management)
3. La gestion de la disponibilité (Availability Management)
4. La gestion de la continuité des services des TI (IT Continuity Management)
5. La gestion des niveaux de service (Service Level Management)

• Planification pour la mise en œuvre des services (Planning to Implement Service

Management)
• Gestion de la sécurité (Security Management)
• Gestion des infrastructures des TIC (ICT Infrastructure Management)
• Point de vue de l'entreprise (The Business Perspective)
• Gestion des applications (Application Management)
• Gestion du parc logiciel (Software Asset Management)

ITIL V3
Dans sa version 3, ITIL distingue également d’autres séries afin d’apporter une vue
transverse en prenant mieux en compte les services métiers :

• Stratégie des services (Service Strategy)

1. Gestion financière des services
2. Gestion du portefeuille des services
3. Gestion de la demande

• Conception des services (Service Design)

1. Gestion des niveaux de service
2. Gestion de la capacité
3. Gestion de la disponibilité
4. Gestion de la continïté
5. Gestion de la sécurité
6. Gestion des fournisseurs
7. Gestion du catalogue de services

• Transition des services (Service Transition)

1. Gestion des actifs et des configurations
2. Gestion des changements
3. Gestion des mises en production et déploiements
4. Gestion des connaissances

• Exploitation des services (Service Operation)

1. Gestion des évènements
2. Gestion des incidents
Auteurs : Einhorny ITIL-
j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

3. Exécution des requêtes

4. Gestion des problèmes
5. Gestion des accès
6. Centre de service, c’est le « guichet unique » entre les utilisateurs et le
service
7. Gestion technique de l’infrasctructure
8. Gestion des opérations informatiques
9. Gestion des applications

• Amélioration continue des services (Continual Service Improvement)

Les deux vues, V2 et V3 ne sont pas incompatibles d’autant plus qu’ITL ne constitue pas un
cadre rigide mais un ensemble de bonnes pratiques que l’entreprise va choisir en fonction de
ses objectifs.

La gestion des services

C’est l’élément clé d’ITIL qui regroupe deux ensembles : la fourniture des services
(conception des services) et le soutien des services (exploitation des services). Dans
beaucoup d’entreprise, ITIL se résume presque exclusivement à ces deux séries.

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

La fourniture des services

C’est la série qui détermine les produits mis à disposition par la direction informatique.

Le soutien des services

C’est la série qui assure le bon fonctionnement des services, elle concerne particulièrement
la maintenance.

Demande
Incident Ticket Erreur de
d’incident connue (KE) changement
(RfC)
Centre de Gestion des Gestion des Gestion des
sevices incidents problèmes changements

Gestion des
mises en
production

Gestion des
configurations

Le centre de services

Fournit un point de contact à tous (clients, fournisseurs, utilisateurs) pour toutes les
demandes (incidents, questions, demandes de services, réclamations, demandes de
changement),

Facilite la restauration du service,

Génère des rapports,

Facilite l'identification des coûts associés à la gestion de l'infrastructure informatique (mesure

les coûts de traitement),

Assiste la gestion des changements,

Assiste la gestion des services (support) et l'optimisation des investissements,

Contribue à la satisfaction durable.

La gestion des incidents

Associé au centre de services, traite les incidents sur une base individuelle.
Auteurs : Einhorny ITIL-
j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

Restaure le service normal dès que possible.

Minimise l'impact sur le business.

S'assure que les SLA (Service Level Agreements) sont tenus.

La gestion des problèmes

Prend en compte et résout les erreurs connues sous forme de demandes de changement
pour une résolution définitive et, éventuellement, par une solution de contournement pour
apporter une solution provisoire.

Minimise l'impact sur le business des incidents et problèmes causés par des erreurs
d'infrastructure, empêche la récurrence des incidents liés aux erreurs

La gestion des configurations

Fournit des informations fiables sur l'infrastructure et ses composants à tous les processus et
à la direction informatique (Gestion des incidents, Gestion des problèmes, Gestion des
changements (qui alimente la CMDB et surveille les changements), Gestion des mises en
production)

Permet le contrôle de l'infrastructure en surveillant et en gardant à jour les informations liées

aux :
• Ressources nécessaires pour délivrer des services
• Statuts et historiques des CI
• Relations des CI

Gestion des changements

Gérer et coordonner les changements en s'assurant que les impacts négatifs sur les services
soient minimisés à un risque acceptable et que les opérations quotidiennes soient
améliorées

Gestion des mises en production

Planifie et surveille les déploiements matériels et logiciels,

Met en œuvre des procédures efficaces pour la distribution et l'installation des changements,

S'assure que les changements (matériels/logiciels) sont traçables, sécurisés, corrects,

autorisés et testés,

Gère les attentes client pendant le déploiement,

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

S'accorde sur le contenu et le plan de déploiement des mises en production avec la gestion
des changements,

Implémente les nouvelles versions dans l'environnement de production en s'appuyant sur la

gestion des changements et des configurations,

Sécurise les sources logicielles et matérielles dans la DHS (Definitive Hardware Store) et
DSL (Defnitive Software Library),

Met à jour la CMDB.

La certification ITIL
Il existe trois niveaux de certification ITIL délivrées à des personnes ayant subi une formation
préalable :

• Foundation, pour une connaissance générale des fondamentaux

• Practitionner, pour une connaissance approfondie d’une discipline particulière
• Manager, pour une connaissance approfondie de l’ensemble des aspects d’ITIL.

Modèles d’organisation
Les modèles d'organisation pour traiter les appels clients sont très variés. Ils dépendent de la
nature des prestations proposées, du contexte dans lequel ils se situent et de la culture
d’entreprise.
L’organisation d’une « hotline » destinée à des particuliers ou des SOHO (Small Office /
Home Office) sera différente de l’organisation d’un service desk à destination de grands
parcs informatiques.
ITIL (Information Technology Infrastructure Library) fournit pour la gestion des services
informatiques un recueil des meilleures pratiques issues d’un grand nombre d’entreprises
anglo-saxonnes. Mais chaque structure de service desk sera unique et cela pour deux
raisons :
o ITIL n’est pas une norme, juste un ensemble de recommandations qui doivent être
adaptées sur le terrain
o En France, à la fin 2006, 13% des entreprises appliquaient la démarche ITIL et 60%
déclaraient s’y intéresser. ITIL devient un standard de fait, de façon complémentaire
aux normes d’assurance qualité telles que ISO 9001 ou ISO 20000.
Dans ce support nous allons examiner le traitement d'un appel dans ses grands principes en
conformité avec ITIL.
Dans une organisation Service Desk, le traitement d’un appel utilisateur va consister à :
o Ouverture d’un dossier lors de l’appel de l’utilisateur,
o Qualifier le type d’appel, cela va consister à identifier le type de prestation attendue par
l’utilisateur et à affecter une priorité à l’appel.

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

o Traiter l’appel, on va soit résoudre le problème soit le transférer ou l’escalader.

o Clôturer l’appel
ITIL recommande qu’il y ait un point de contact unique entre les utilisateurs et le
département informatique.

UtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateurUtilisateur

Centre de services

Support partie tierce Support poste de travail

Support réseau Support applicatif

Dans ITIL ce point de contact s’appelle Centre de Services (Service Desk), il est
responsable du traitement de tous les appels des utilisateurs qu’ils soient occasionnés par
des dysfonctionnements ou que ce soient de simples demandes.
Il doit également enregistrer tous les incidents, afin de fournir une source centrale
d’information pour le management du SI (Système d’Information).
Ainsi les incidents récurrents seront requalifiés en problèmes et génèreront des
changements de configuration qui permettront d’améliorer le service rendu par le SI.
L’enregistrement des incidents va également permettre de renseigner des indicateurs sur la
qualité du service rendu : nombre d’appels, taux de résolution des incidents au 1er niveau,
temps moyen de résolution…
Ces indicateurs permettront de chiffrer le service que vous rendez aux utilisateurs en
quantité et en qualité, ce qui, au passage, justifie votre poste et votre rémunération.
Dans ce support nous emploierons le terme de Service Desk pour désigner ce point de
contact, nous le préférons à Help Desk très employé jusqu’à présent mais plus restrictif.

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

Courriels Solutions

Appels Escalades

I*Net Centre de service Information

Demandes de
Fax
changement

Entrée, le Service Desk reçoit des demandes par tous les moyens habituels dans l’entreprise, il peut
aussi disposer d’outils de supervision du matériel, des applications et du réseau.

En sortie, plusieurs cas de figure peuvent exister :

• La solution : le problème est directement résolu

• L’escalade : le problème est transmis à un échelon supérieur pour être traité par des
spécialistes
• L’information : des consignes peuvent être diffusées pour éviter de renouveler l’incident
• La demande de changement : s’il convient d’apporter une modification.

Organisation générale d’un Service Desk

L’organisation générale d’un service desk est le plus souvent structurée en 3 niveaux.
Le niveau 1, composé de techniciens ayant une bonne connaissance des produits, dispose
d'un temps limité pour répondre aux besoins des utilisateurs. C’est ce premier niveau, avec
un n° d’appel unique, qui est le passage obligé de tout utilisateur ayant une demande
d’assistance ou de dépannage.
Le service desk n’est pas une cellule d’accueil « boîte aux lettres », il doit résoudre la plupart
des incidents dés le 1er niveau.
On considère qu’un service desk est performant quand le niveau 1 résout à peu près 80%
des incidents.
Le niveau 2 est constitué de spécialistes qui disposent d'un temps plus long pour résoudre
les incidents et qui ont rarement les utilisateurs en ligne.
Très souvent, le niveau 3 ne fait pas partie de la cellule Service Desk, il se trouve chez
l'éditeur du logiciel ou le constructeur du matériel.

Principe de fonctionnement
Le service desk est le niveau 1. Il reçoit les appels, pour traiter les appels, il dispose d'un
temps limité. S'il parvient à traiter l'appel, celui-ci est clôturé. S'il n'y parvient pas, il a deux
possibilités :
o déclencher une intervention sur place ou faire intervenir un fournisseur tiers (dans le cas
d'une garantie, par exemple)
o Soumettre l’incident au niveau 2 si ce dernier dépasse ses compétences.

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

Dans tous les cas de figure, il devra ouvrir le dossier d’appel, suivre le déroulement de
l'intervention, tenir informé l’utilisateur et déterminer si l'appel peut être clôturé.
Le niveau 2 va intervenir sur les cas qui nécessitent une connaissance plus pointue d'un
domaine. Il dispose d'un délai plus long pour résoudre les incidents, le délai dépend des
contrats de services passés avec l'utilisateur.
Dans le cas où il ne pourrait traiter l’incident, il remonte ce dernier au niveau 3.
Le niveau 3 est le niveau « expert », très souvent il s’agit des éditeurs et constructeurs.

Les activités du processus

Détection et enregistrement

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

Détection et
enregistrement

Enregistrer l’incident Mise à jour des

Incident venant du Alerter les supports si incidents
centre de service nécessaire Identification des erreur
Démarrer la procédure de dans la CMDB*
Remontée d’alarme traitement des demandes Notification des statuts
de service des incidents au client

*CMDB = base de données de gestion des composants

Classification et support initial

Classification et support
initial
Classifier les incidents
Lier les incidents, problèmes
Description de l’incident et erreurs connues Demande de changement
Prévenir la gestion des
problèmes des nouveaux
problèmes (incidents répétés)
Détail des configuration
Définir impact * urgence = Mise à jour de l’incident
CMDB
priorité
Base de Liaison entre incidents et
connaissance*base des composants affectés Solution de contournement
problèmes*erreurs Support initial ou escalade
connues Fermeture ou escalade de
l’incident

Investigation

Investigation

Mise à jour de l’incident Nouvelle mise à jour de l’incident

Analyse du détail de l’incident
Fourniture d’une solution
(même de contournement) ou
escalade
Détails de la configuration Identification de la solution de
dans la CMDB contournement

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

Résolution et restauration du service

Résolution et
restauration du service
Demande de changement
Mise à jour de l’incident
Résout l’incident en pour résoudre l’incident
utilisant une solution
Réponse de la gestion des définitive ou de
changements au sujet d’une contournement ou en
Incident résolu
demande de changement émettant une demande
(solution de l’incident) changement
Mets en place des actions
Solution définitive ou de de restauration Mis
e à jour de l’incident
contournement

Clôture

Clôture

Confirme la résolution
Mise à jour de l’incident avec le client ou Mise à jour de l’ l’incident
demandeur
Incident résolu Affecte la catégorie Clôture du ticket
« fermé » à l’incident

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

2 PRISE EN CHARGE DE L’UTILISATEUR ET DE SON

APPEL
Lorsqu'un utilisateur vous appelle, ce qu'il attend de vous, ce n'est pas forcément une
réponse immédiate, mais que vous preniez en charge son incident et que vous ne le laissiez
pas tomber.
Si quelques prestataires font correctement leur travail, avec les autres, deux cas de figures
peuvent se produire :
o on dit que l'on va vous rappeler et on vous oublie
o on ne répond pas à votre question, mais à une autre
Le premier cas de figures peut être résolu en suivant la demande d'intervention depuis
l'appel de l’utilisateur jusque sa résolution (il s'agit donc d'un problème d'organisation et de
méthode résolue si l’on suit les recommandations d’ITIL) et pour le deuxième cas de figure,
c'est avant tout un problème de communication.

Le contact
Le technicien de service desk doit dans un premier temps s'identifier formellement, rassurer
son utilisateur et parfois même le calmer.
Il n'est pas à exclure que ce dernier vous passe un savon, prenez-le avec bonne humeur et
laissez passer l'orage ou alors changez de métier…

Identifier l’utilisateur et son environnement matériel

L'identification est très importante, car elle permet de connaître la nature de la prestation que
vous êtes tenu de lui offrir.
Vous devez également identifier le matériel sur lequel il travaille : marque et modèle du PC
ou du périphérique, type de réseau, système d'exploitation et logiciels.

Identifier son problème

Pour identifier le problème de l’utilisateur, vous disposez de 3 à 5 minutes environ. Avant de
chercher à le résoudre, il faut d'abord l'écouter et surtout s'assurer que l'on a compris. Pour
cela vous utiliserez toutes les techniques de l'entretien de recueil d'informations à savoir :
écoute, reformulation, relance, synthèse partielle et synthèse finale.

Ce qu'il ne faut pas dire

Beaucoup d’utilisateurs risquent de vous demander quand le technicien va intervenir et
combien de temps cela va durer. Pour la première question, vous n'apporterez de réponse
que si vous êtes en mesure de planifier dans l'immédiat l'intervention. Si ce n'est pas vous
qui planifiez, vous ne devez pas apporter de réponse, vous risqueriez de mettre votre
technicien dans l'embarras et de nuire à l'image de marque de votre service. Il sera
préférable de rassurer l’utilisateur en lui assurant le meilleur service dans les délais prévus
contractuellement.

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

De même pour la durée d'une intervention, si cela sort du cadre de votre compétence, vous
ne devez avancer aucun chiffre. Si vous annoncez une heure et que trois heures sont
facturées, l’utilisateur n'aura pas oublié ce que vous avez avancé.

qualification de l’appel
Principe
Face à une demande d'intervention, le technicien de service desk de 1er niveau se trouve
confronté à l'alternative suivante : traiter la demande dans l'immédiat, faire appel à un
spécialiste et différer l'intervention. Il doit affecter une priorité à l’appel, c’est ce qu’on
appelle la qualification de l’appel. S’il prend la décision de faire appel à un spécialiste il
effectue ce que l’on appelle un transfert.

Le transfert ne doit pas être confondu avec l’escalade. On appelle .escalade

l’action qui consiste à transmettre au spécialiste un incident que le technicien de
service desk aurait dû résoudre lui-même.

Beaucoup de techniciens de service desk de 1er niveau en herbe, ont la mauvaise habitude
de vouloir traiter tous les incidents eux-mêmes en direct. Ce choix peut être mauvais et ce
pour plusieurs raisons :
o La durée de l'intervention au téléphone ou avec un autre moyen de communication
monopolise le technicien de service desk de 1er niveau qui ne peut prendre d'autres
appels.
o Un spécialiste interviendra plus rapidement et plus efficacement.
o Agir dans la précipitation n'est pas forcément le meilleur service à rendre.

La durée d'une intervention faite par un technicien de service desk de 1er niveau ne
doit pas excéder, en général plus de 10 minutes, au-delà il faut passer la main à un
spécialiste.

Aide à la décision
Trois paramètres vont vous permettre de qualifier un appel, ce sont :
o L’impact (ou sévérité)
o L’urgence
o La priorité

L’impact

Permet de mesurer le volume et l’ampleur d’un incident : toute l’entreprise, un service, un

VIP, un utilisateur.
Ainsi un incident sur un serveur aura un impact plus important qu’un incident sur un poste de
travail.

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

L’urgence

Ce paramètre permet de mesurer la criticité d’un incident par rapport à l’activité de

l’utilisateur : bloqué, ralenti, peut vivre avec.

La priorité

C’est la vitesse à laquelle l’incident doit être résolu en fonction de l’impact et de l’urgence.
Ce paramètre est en général associé à un délai de résolution contractuel.

Exemple de grilles d’analyse :

Détermination des priorités

IMPACT
URGENCE Toute l’entreprise Un service, un VIP Un utilisateur
Bloqué 1 2 3
Ralenti 2 3 4
Peut vivre avec 4 4 4

Indicateurs de traitement des priorités

1 2 3 4
Temps de détection 1 mn 5 mn 10 mn 30 mn
Taux de réussite 99% 98% 97% 95%
Temps de résolution 10 mn 30 mn 1h 24 h
Taux de réussite 98% 97% 95% 90%
Délais maximum 1h 2h 4h 5 jours

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

3 QUE DEVIENNENT LES APPELS QUALIFIES?

La qualification des appels revient à classer les appels de vos utilisateurs par priorité.
L'activité de qualification d'appel n'est pas plus simple que celle qui consiste à faire des
interventions de premier niveau.
Une erreur à ce niveau peut être lourde de conséquences. Si vous qualifiez mal une panne
bloquante d'un serveur, votre entreprise ou votre client peuvent avoir une perte de chiffre
d’affaire …ou plus grave encore…

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 2 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

4 TRAITEMENT D'UN APPEL

Traitement en direct
Un appel est traité en direct lorsque c'est le technicien qui a qualifié l'appel qui le prend en
charge. Il n'y a donc pas de rupture entre le moment où le client appelle et le moment où l'on
traite son appel.

Le temps alloué pour traiter un appel au premier niveau est généralement limité. Si
l'intervention est trop lourde ou trop compliquée, il ne faudra pas la traiter à ce
niveau. Par contre, il faudra que la majorité des incidents soient résolus à ce niveau,
c’est la toute la difficulté du système !

Traitement différé
Lorsque le technicien qui qualifie l'appel l'affecte à un autre intervenant, cet appel sera traité
en différé. Dans ce cas c'est l’utilisateur qui sera rappelé.
En fonction de la qualification de l'appel, le traitement différé sera de niveau 1 ou 2. Si l'appel
est transféré à un spécialiste il s’agira de niveau 2 (on parlera alors de transfert). Si une
intervention sur site est déclenchée, cela pourra être des niveaux 1 ou 2 selon la nature de
l’intervention.

Mécanisme du traitement d'un appel au niveau 1

Documenter l'intervention
Quel que soit le cas de figure, il y aura toujours un suivi de l'intervention. Le technicien devra
toujours laisser une trace de son diagnostic et de ce qu'il a fait. Il y a deux raisons à cela :
o Avoir un historique des interventions chez le client
o Informer de ce qui se passe et de ce qui a été fait pour le cas où vous affecteriez l'appel
à un spécialiste.

Respecter les contraintes de temps

Selon les organisations, le temps alloué pour résoudre l'appel peut varier. Dans les hotlines
grand public, cette durée est de l'ordre de 10mn. Toutefois en fonction de la file des appels
en attente, cette durée peut être allongée ou, au contraire, aux heures de forte affluence elle
peut être réduite.
Les contraintes de temps se justifient par le fait que si vous passez trop de temps avec un
utilisateur, la file d'attente s'allonge et vos utilisateurs en file d'attente vont raccrocher. Cela
va générer du mécontentement et ces utilisateurs vont rappeler ultérieurement ce qui va à
nouveau encombrer la file d'attente. De plus lorsque l’utilisateur arrivera à avoir un
technicien, il sera quelque peu énervé…

Dans le jargon officiel les utilisateurs qui raccrochent sont appelés des …
"Raccrochés". Il fallait y penser.

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 18 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

Affecter l'appel à un niveau 2

Plusieurs cas de figures peuvent amener le technicien de niveau 1 à affecter un appel au
niveau 2.
o Il n'a pas assez de temps
o Il n'a pas les compétences suffisantes pour traiter le problème
o Il a pris en charge l'appel et il n'arrive pas à le résoudre…
Le technicien manque de temps
Lorsque le technicien, bien qu'il soit compétent pour le faire, s'aperçoit que le problème à
résoudre ne pourra pas l'être dans le temps imparti, il va affecter l'appel au niveau 2.
De même, lorsque le technicien a commencé à traiter l'appel et qu'il s'aperçoit qu'il approche
du temps limite et qu'il est loin de la solution, il va affecter l'appel au niveau 2.
Dans ces deux cas de figure, il aurait pu traiter l'appel, c'est le manque de temps qui l'en a
empêché. L'action qui consiste à affecter l'appel au niveau 2 s'appelle une escalade.

Inutile de dire qu'il est préférable de s'apercevoir rapidement qu'on ne pourra traiter
un problème…

Le problème dépasse ses compétences

Dans ce cas de figure, le technicien va affecter l'appel à un spécialiste, cette action se
nomme un transfert.

La distinction entre transfert et escalade n’est pas pratiquée partout et ne figure pas
dans ITIL

Le technicien ne parvient pas à résoudre le problème

Deus cas de figure peuvent générer cette situation. L'un va générer un transfert, l'autre une
escalade.
Imaginons que le technicien dispose d'une procédure de dépannage qu'il doit suivre pas à
pas. Si le problème n'est pas résolu à l’issue du déroulement de la procédure, cela signifie
que cela dépasse ses compétences. Il va donc effectuer un transfert.
Imaginons maintenant, que le technicien qui fait de l'assistance bureautique ne parvienne
pas à résoudre un problème d'utilisation courante (générer une table des matières sous
Word par exemple), il va faire appel au niveau 2 afin de résoudre le problème du client.
Nous sommes dans le cas de figure où, malgré que le problème soit de niveau 1, on a dû
faire appel au niveau 2. C'est donc une escalade.

Les pratiques varient considérablement d’une organisation de service desk à

l’autre.
Chez certains, la distinction entre transfert et escalade n’existe pas, chez d’autres
au contraire on va faire la chasse aux escalades et aux raccrochés, vous
rencontrerez aussi des Service Desk où le niveau 2 n’existe pas.

Auteurs : Einhorny ITIL-

j GestionIncidents.doc Page 19 / 24
x
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

Déclencher une intervention

Lorsque de toute évidence le problème est matériel, le technicien ne pourra faire
l'intervention à distance. Dans ce cas de figure il peut déclencher une intervention sur le site
de l’utilisateur.

N'oubliez pas qu'à ce stade, l'appel à été qualifié et que le technicien sait ce à quoi
peut prétendre l’utilisateur en termes d'intervention.

Pour déclencher l'intervention, le technicien devra pouvoir remplir une demande

d'intervention. Sur cette demande, on trouvera, bien entendu les coordonnées de l’utilisateur
ainsi que l'identification de l'équipement concerné.
Le cas échéant on indiquera le délai d'intervention. Mais il faudra surtout faire un diagnostic
précis du problème rencontré pour ne pas envoyer le technicien dans l'inconnu.
Si le technicien n'est pas en mesure de réaliser ce diagnostic, il n'a pas forcément les
compétences, il ne déclenchera pas l'intervention, il la transférera au niveau 2 et c'est ce
dernier qui déclenchera ou non l'intervention.

Les problèmes
Quand la cause d’un incident ne peut pas être identifiée, cet incident pour ITIL est requalifié
en « problème ».
Quand la cause est trouvée le problème est requalifié en « erreur connue ».
Ce processus de transformation des problèmes en erreurs connues pousse l’entreprise au
changement.

Signalement des problèmes

Il appartient au technicien de Service Desk, c'est-à-dire vous, d’enregistrer les problèmes.
La forme de cet enregistrement variera selon l’organisation du Service Desk auquel il
appartient, on peut dire schématiquement que le problème sera enregistré dans une base de
données (la même que celle où sont enregistrés tous les incidents).

Gestion des problèmes

Un problème est la cause sous-jacente inconnue d’un ou plusieurs incidents. Il devient une
erreur connue lorsque la cause à l’origine de ce problème est connue et une solution de
contournement provisoire ou permanente a été identifiée.

Qui va gérer les problèmes ?

C’est au technicien de Service Desk de signaler les problèmes.
Pour le travail de recherche des causes d’incidents, cela varie selon les organisations : cela
peut être le travail du niveau 2 ou bien le travail de groupes avec une spécialité technique au
niveau 1 (groupe bureautique, groupe réseau, groupe poste de travail…).
La tendance actuelle va vers le niveau 1 à qui l’on demande de plus en plus de compétences
techniques et d’autonomie.

Auteurs Einhorny j
Page 20 / 24
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

Quand la cause est identifiée le problème devient une erreur connue, qui doit être
enregistrée dans la base de données.
Dans ITIL cette base de données s’appelle la CMDB : Configuration Management Database.
Cette base de données sera à la disposition des techniciens Service Desk, mais pourra
aussi être à la disposition des utilisateurs de différentes manières (à travers des FAQ par
exemple).
Cela aura pour effet :
1. d’améliorer l’efficacité du support,
2. d’identifier des incidents récurrents,
3. de supprimer la cause du problème en améliorant l’existant (formation des
utilisateurs, modification de configuration matérielle, application de services packs ou
changement de version de logiciels, amélioration du réseau, amélioration des
procédures de sécurité…).

Auteurs Einhorny j
Page 21 / 24
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

5 CLOTURE D'UN APPEL

Une règle d'or en assistance informatique : tous les appels doivent être clôturés.
La clôture d'un appel, comme toutes actions en Service Desk, obéit à certaines règles. Il faut
savoir quand clôturer un appel et savoir qui peut le clôturer.

Quand clôturer un appel

Un appel ne peut être clôturé que lorsqu'une solution définitive qui permet de résoudre
l’incident a été apportée.
Une solution définitive est une solution qui résout complètement l’incident. Selon le contexte
une même solution peut être temporaire ou définitive.
Prenons le cas d'un appel consécutif à une panne d'imprimante. La solution qui consiste à
mettre en place une nouvelle imprimante peut être considérée comme une solution
temporaire, il s'agit alors d'un prêt. Elle peut être également considérée comme définitive, il
s'agit alors d'un remplacement.

C'est le contrat passé avec le client qui, généralement, détermine s’il s'agit d'un prêt
ou d'un remplacement.

Dans le cas de figure où il s'agit d'un prêt, l'appel ne peut être clôturé. S’il s'agit d'un
remplacement l'appel peut être clôturé.

qui clôture un appel

Dans la mesure où une seule personne doit suivre un appel, il ne peut s'agir que de la
personne qui a ouvert le dossier d'appel. Cette personne doit en assurer le suivi et ce,
jusqu’à la clôture du dossier d'appel.
C’est donc le technicien de niveau 1 du Service Desk qui a ouvert le dossier d’appel et qui
en a effectué le suivi, qui devra clôturer l’appel.

Auteurs Einhorny j
Page 22 / 24
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

6 RENDRE COMPTE DE L'INTERVENTION

Pour que la décision de clôturer un appel soit prise, il est nécessaire de connaître dans le
détail la ou les interventions qui ont été déclenchées suite à cet appel.

Le suivi d'un appel

De multiples événements peuvent se produire pendant la prise en charge d'un appel.
Le cas le plus simple est le suivant :
1. Un technicien du niveau 1 prend l'appel
2. Ce dernier réalise l'intervention et remplit un compte rendu d'intervention
3. Le technicien du niveau 1 clôture l'appel.
Si les étape 1et 3 sont toujours les mêmes, il en va tout autrement pour l'étape 2.
En effet, le technicien de niveau 1 n'est pas toujours en mesure de réaliser l'intervention.
Il peut soit l'escalader, soit la transférer... et dans ce cas un autre technicien va réaliser une
intervention qui donnera lieu à un autre compte rendu d'intervention… etc.
Afin de pouvoir, à tout instant, suivre un appel, il est impératif que chaque intervenant
informe l’initiateur de l'appel qu'il prend en charge cet appel et qu'il rédige systématiquement
un compte rendu d'intervention.
Vous voyez que tout cela peut devenir très compliqué et qu'il convient d'examiner plus en
détail la création et la rédaction des comptes rendus d'intervention.

Qui fait le compte rendu d'intervention

La règle dans ce domaine est simple, c'est la personne qui réalise l'intervention qui réalise le
compte rendu.

Quel est le support d'un compte rendu

Le support d'un compte rendu peut être sous deux formes: une forme électronique ou une
forme papier.

Quand faire un compte rendu d'intervention ?

Un compte rendu devra systématiquement être fait à chaque intervention.

Les rubriques d'un compte rendu d'intervention

Les rubriques renseignées à la création du compte rendu
A la création les rubriques renseignées seront :
o Un numéro d'intervention
o Les coordonnées de l’utilisateur
o Le numéro de contrat du client

Auteurs Einhorny j
Page 23 / 24
Traiter un ticket d’incident dans un service d’assistance
Apport d’informations et de connaissances

o Le montant de l'intervention dans le cadre d'une intervention non contractuelle

o L'identification du ou des matériels concernés
o Le descriptif de l’incident
o La nature de l'intervention à réaliser

Les rubriques renseignées lors de l'intervention

o L'identification des pièces fournies ou échangées
o Le temps passé
o L'heure de début et de fin
o Le descriptif de l'intervention
o Une information sur la fin de l'intervention ou sur la suite à donner
o La signature du technicien et de l’utilisateur (et son identification : nom et fonction).

Toutes les personnes ne sont pas habilitées à signer un document. Une

signature non habilitée n'engage pas la société de cette dernière.

Auteurs Einhorny j
Page 24 / 24