Gestion des incidents

Page 1 of 9
Historique du document

Version Date Modifications

v 1.0 23/01/2024 Version initiale

Page 2 of 9
Table des matières

1 Objectif du document......................................................................................................................................... 4
2 Notre définition-Gestion des incidents : ............................................................................................................ 4
3 Gestion des incidents : ....................................................................................................................................... 4
a) L'importance de la gestion des incidents ............................................................................................ 5
b) Processus de gestion des incidents informatiques ............................................................................. 5
c) Notre Classification des incidents ....................................................................................................... 6
d) Qui est responsable de quoi ? ............................................................................................................. 7
e) Quels sont les objectifs de la gestion des incidents ? ......................................................................... 8
f) Comment fonctionne le processus de gestion des incidents ? ........................................................... 9
4 Manuel de gestion des incidents : .................................................................................................................... 12
a) À qui est destiné ce guide ? .............................................................................................................. 12
b) Qu'est-ce qu'un incident ? ................................................................................................................ 12
c) Nos valeurs en matière d'incidents................................................................................................... 12
d) Exigences relatives aux outils ............................................................................................................ 14
e) Suivi des incidents ............................................................................................................................. 14
f) Responsable des incidents ................................................................................................................ 15

Page 3 of 9
1 Objectif du document
Afin de Restaurer aussi vite que possible le fonctionnement normal des services
et minimiser l'impact négatif sur les activités métiers et s'assurer ainsi que les
meilleurs niveaux de qualité de service et de disponibilité sont maintenus,
technologies adopte un référentiel qui aide à améliorer la gestion des systèmes
d’information qui s’appelle ITIL « Information Technology Infrastructure
Library » ou « Bibliothèque pour l'infrastructure des technologies de
l'information ».
Selon le référentiel ITIL, ce denier défini un incident comme tout événement ne
faisant pas partie du fonctionnement normal d’un service (ou d’un équipement),
et qui cause ou peut causer une son interruption ou une altération de sa qualité.
En conséquence, la gestion des incidents permet de rétablir rapidement le
fonctionnement normal du service et de minimiser l’impact de ceux-ci sur
l’entreprise.
L’action doit être menée tout en assurant le niveau de disponibilité et de service
défini dans le contrat de services (SLA), à savoir le meilleur niveau possible.
Il faut porte une grande importance sur le Service Levels Agreement qu’il est une
partie de contrat de service entre notre service informatique et nos clients qui
définissent le niveau de service attendu et les garanties associées.

2 Notre définition-Gestion des incidents :

La gestion des incidents désigne le processus utilisé par les équipes de
développement et des opérations informatiques pour répondre à un
événement imprévu ou une interruption de service et rétablir le
fonctionnement du service.

Nous définissons un incident comme un événement ayant provoqué une

perturbation ou une réduction de la qualité d'un service nécessitant une
réponse d'urgence. À la place, les équipes qui adoptent les pratiques ITIL V 4.

3 Gestion des incidents :

Les incidents sont des événements de toute nature qui perturbent ou
affectent la qualité du service (ou menacent de le faire).

La panne d'une app métier constitue un incident, au même titre que la lenteur
d'un serveur web en fin de vie. Ce dernier fonctionne lentement et nuit à la
productivité. Pire encore, il risque d'entraîner une panne complète.

Ces incidents peuvent être d'une gravité très variable, allant du crash de tout
un service web mondial à un petit nombre d'utilisateurs subissant des erreurs
intermittentes.

Page 4 of 9
Un incident est résolu lorsque le service affecté fonctionne de nouveau de
manière habituelle. Cela inclut uniquement les tâches requises pour atténuer
l'impact et restaurer les fonctionnalités.

a) L'importance de la gestion des incidents

La gestion des incidents est l'un des processus les plus essentiels qu'une
organisation doit mettre en place. Les interruptions de service peuvent être
coûteuses pour l'entreprise, et les équipes ont besoin d'un moyen efficace
pour répondre à ces tickets et les résoudre rapidement.

Nos équipes ont besoin d'une méthode fiable pour prioriser les incidents,
parvenir à une résolution plus rapide et offrir un meilleur service aux
utilisateurs.

Lorsque nos équipes sont confrontées à un incident, elles ont besoin d'un plan
qui leur permet de :

• Répondre efficacement pour une reprise rapide ;

• Communiquer clairement avec les clients, les parties prenantes, les
Service Owners et les autres membres de l'organisation ;
• Collaborer efficacement pour résoudre le problème plus rapidement
en équipe et éliminer les obstacles à la résolution ;
• S’améliorer continuellement pour apprendre de ces pannes et
appliquer les leçons pour optimiser un service et peaufiner leur
processus pour l'avenir.

b) Processus de gestion des incidents informatiques

Un processus de gestion des incidents aide notre équipe informatique à

enquêter, à consigner et à résoudre les interruptions ou les pannes de service.
Le workflow de gestion des incidents ITIL vise à réduire les temps d'arrêt et à
minimiser l'impact sur la productivité des employés en cas d'incident.

En utilisant des modèles conçus pour gérer les incidents, vous pouvez créer un
workflow de gestion des incidents reproductible, qui garantit que les équipes
consignent, diagnostiquent et résolvent les incidents et disposent d'un
enregistrement de leurs activités.

Le framework (ou référentiel) ITIL est principalement utilisé par les équipes
informatiques qui fournissent des services au sein des entreprises. En général,
les équipes prennent ce dont elles ont besoin dans ITIL, qui couvre presque
tous les types d'incidents et de problèmes et processus auxquels les équipes
informatiques peuvent être confrontées, et laissent le reste.

Page 5 of 9
ITIL V4 est idéal lorsque nos équipes doivent se concentrer sur l'instauration
d'une culture de résolution active des problèmes. Les processus prescrits
aident les équipes à suivre les incidents et les actions de manière cohérente,
ce qui améliore les rapports et analyses, et peut conduire à un service plus
sain et à une équipe plus performante.

c) Notre Classification des incidents

Les incidents sont classés en fonction :

• De leur priorité (faible, moyenne et élevée)

⌑ Les incidents de faible priorité n’interrompent pas les utilisateurs

finaux, ils peuvent généralement terminer le travail malgré l'incident.

⌑ Les incidents de priorité moyenne sont des problèmes qui touchent

les utilisateurs finaux, mais la perturbation est légère ou brève.

⌑ Les incidents de priorité élevée affectent un grand nombre

d’utilisateurs finaux et empêchent le bon fonctionnement d’un
système.

⇨ On constate le volume et l’ampleur d'un incident sur une entreprise

en mesurant le nombre d’utilisateurs ou le nombre de systèmes
touchés par un dysfonctionnement. Lorsqu’un incident présente un
impact majeur pour un grand nombre d’utilisateurs, on considère qu’il
s’agit d’un incident hautement prioritaire.

• De leur type

⌑ Matériel (Problème de réseaux et autres pannes du système).

⌑ Logiciel (Bug d’application ou problème de disponibilités de service).

⌑ Sécurité (Accès non autorisé d’un domaine ou tout autre menace qui
compromet et viole les données).

⇨ Notez tout de même qu’un problème de performances résulte

souvent de n’importe quelle combinaison de ces domaines.

Page 6 of 9
 d) Qui est responsable de quoi ?

Le premier niveau de résolution des incidents est le centre de services. Si

celui-ci ne parvient pas à résoudre rapidement un incident, une procédure
d’escalade est engagée.

Cette procédure correspond au transfert de l’incident à un niveau de support

supérieur (deuxième, troisième niveau, etc.) composé de spécialistes qui
disposent de plus de compétences et de temps pour trouver une solution au
dysfonctionnement.

La structuration du support informatique autour des niveaux permet de

répondre stratégiquement aux besoins de la clientèle, de créer une
expérience client positive, de résoudre rapidement les problèmes mineurs,
d’améliorer la formation des employés en favorisant la mobilité ascendante.

• Niveau 1 : Il fournit généralement un support ou une assistance

rudimentaire grâce à la base de connaissances et de solutions
identifiées (CMDB : Configuration management database). Ce niveau
comprend l’identification, l’enregistrement, la hiérarchisation et la
catégorisation des incidents, ainsi que la décision de passer au niveau
deux du soutien si besoin. Il tente donc de résoudre l'incident s’il en
est capable, cela permet d’augmenter la satisfaction de l’utilisateur
final. Par exemple : un ordinateur ne fonctionne pas, l'utilisateur
demande assistance et on l'invite à vérifier si la barre de prise est bien
branchée. Ce niveau gère aussi les réinitialisations de mots de passe et
les dépannages informatiques.

⇢ L’acteur principal est le « Service Desk ».

• Niveau 2 : Il passe par un processus similaire mais répond à des

demandes plus complexes qui nécessitent de plus de formation, de
compétences ou d’accès à la sécurité pour être satisfaites. Le support
de niveau 2 peut rendre visite à l’utilisateur final si besoin, ce que le
personnel du Service Desk ne peut pas faire.

⇢ Les acteurs principaux sont les « techniciens IT ».

• Niveau 3 : Ce niveau concerne les incidents majeurs, ceux qui

perturbent réellement le fonctionnement d’une entreprise, comme un
problème de réseau. Les techniciens tentent de définir les causes
profondes à l’aide de codes et de spécifications. Une fois la cause
profonde identifiée, des correctifs aux incidents sont apportés,
documentés puis communiqués aux techniciens de niveau 1 et de
niveau 2 comme références futures.

⇢ Les acteurs principaux sont « des experts IT, comme les

ingénieurs réseaux ».

Page 7 of 9
• Niveau 4 : Les incidents concernés par le niveau 4 relèvent de la
responsabilité de services externalisés, soit les fournisseurs. Par
exemple, si le logiciel Skype dysfonctionne, seule l'entreprise
Microsoft pourra résoudre l’incident.

e) Quels sont les objectifs de la gestion des incidents ?

• Maintien du niveau de service. Un accord ou contrat SLA offre une

définition claire du niveau de service qu’une entreprise doit fournir à
sa clientèle. Si une entreprise ne respecte pas un SLA, les
conséquences peuvent être importantes pour elle mais aussi pour ses
clients. Grâce à la gestion des incidents ITIL, notre entreprise
comprendra exactement comment traiter n’importe quel incident, et
ceci à tout moment. Vous pourrez aussi utiliser ITIL pour résoudre les
incidents avant qu’ils ne deviennent hors de contrôle. Nous
minimiserons ainsi l’impact sur le métier client et vous serez assuré
que le niveau de service convenu avec l’utilisateur ou le client est bien
respecté.

• Augmentation de la satisfaction des utilisateurs finaux. Grâce à la mise

en place d'ITIL, notre entreprise dégagera des solutions en amont afin
d'éviter des incidents futurs dans la mesure du possible. Si l'incident se
produit tout de même, notre entreprise comprendra comment
minimiser les interruptions de service et rétablir les services le plus
rapidement possible.

• Renforcement de l’efficacité et de la productivité du personnel. ITIL

aide les professionnels de la gestion des incidents à découvrir les
meilleures façons de traiter ces incidents.

• Optimisation de l’utilisation des ressources matérielles et humaines.

Ces ressources, impliquées dans le processus de support seront
optimisées et un suivi efficace des incidents sera garanti. Ainsi votre
entreprise capitalisera l’expérience des différents techniciens en
conservant l’historique des incidents et de leurs solutions.
Ce suivi pourra être utilisé conjointement avec des solutions
informatiques pour accroître la productivité.

Page 8 of 9
 f) Comment fonctionne le processus de gestion des incidents ?

Étape 1 : Identification de l’incident

Idéalement les incidents sont identifiés à un stade très précoce par la

surveillance automatisée des évènements, donc avant même qu’ils n’aient
des répercussions sur un utilisateur. Cependant, ce n’est pas toujours le cas.
Parfois, les incidents sont identifiés par l’utilisateur touché qui le signale au
Service Desk.

Étape 2 : Enregistrement de l’incident

Afin de tenir un registre historique complet, tous les incidents, quelle que soit
la méthode utilisée pour les identifier et les signaler au Service Desk, doivent
être enregistrés avec tous les détails pertinents, par exemple :

• Numéro incident : Numéro unique renseigné automatiquement par

l'outil lors de l'enregistrement de la déclaration.

• Statut de l’incident : État de traitement de l’incident.

• Date de détection de l’incident : Date à laquelle l’incident a été

détecté par le déclarant (Date du jour par défaut).

• Déclarant interne : La personne remontant l’incident au sein de

l'entreprise.

• Déclarant externe : La personne remontant l’incident n’est pas

salariée de l’entreprise.

• Département : Vous définirez le périmètre concerné par l’incident.

• Description de l’incident : Vous indiquerez succinctement en quoi

consiste l'incident.

• Pièce jointe : Possibilité d'ajouter des pièces jointes si besoin.

Étape 3 : Classification et priorisation de l’incident

L’attribution de la priorité est essentielle pour déterminer comment, quand et

par qui l’incident sera traité.

Page 9 of 9
Une fois enregistré, vous effectuerez une catégorisation de l’incident pour
déterminer sa prise en charge, et pour donner la priorité aux ressources
d’intervention. Par exemple, si un incident est classé comme une panne de
système, l’incident sera considéré comme à priorité élevée, et sera
directement confié à un niveau supérieur afin de ne pas perdre de temps.

Notre département renseigne les éléments suivants :

1. Catégorie de l’incident

2. Périmètre de l'incident

3. Source de détection

4. Impact

5. Priorité (critique, haute, moyenne, faible)

Étape 4 : Recherche et diagnostic de l’incident

Au cours de cette étape, l’équipe mènera son enquête sur l’incident, elle
devra décrire le problème le plus précisément possible. L’incident devra être
diagnostiqué par toutes les parties concernées et ceci jusqu’à ce que le
problème soit résolu. L’enquête et le diagnostic comprendront les mesures
suivantes :

1. Établir la cause exacte de l’incident.

2. Comprendre l’ordre chronologique des évènements.

3. Confirmer l’impact complet de l’incident.

4. Identifier tout évènement qui aurait pu le déclencher (un changement

récent ou une action de l’utilisateur par exemple).

5. Rechercher les erreurs connues dans la base de connaissances CMDB

afin de trouver rapidement une solution de contournement ou de
résolution.

6. Rechercher s'il existe des évènements antérieurs similaires (des

incidents déjà enregistrés, des erreurs fréquentes, chercher dans la
CMDB, dans les journaux d’erreurs, dans les bases de connaissances
des fabricants et fournisseurs associés, etc.)

Page 10 of 9
Étape 5 : Affectation ou escalade d’incident

Au cours de cette étape, votre entreprise devra mettre en pratique ce que je

vous expliquais précédemment. Initialement, le technicien du service desk
tentera de résoudre l’incident. S'il n’est pas en mesure de fournir une
solution, l’incident sera élevé au niveau approprié de soutien (niveau deux ou
trois).

Si d’aventure un incident s’intensifiait, l’escalade devrait se poursuivre dans la

chaîne de gestion. Les cadres supérieurs devraient être avisés de la situation
afin qu’ils puissent se préparer à prendre toutes les mesures nécessaires,
comme l’allocation de ressources supplémentaires ou la participation de
fournisseurs par exemple.

Étape 6 : Résolution de l’incident et restauration du service

Une fois l'incident résolu, la solution pourra être implémentée (assurez-vous

bien de disposer des autorisations nécessaires pour le faire) et testée pour
confirmer la récupération du service. Si tout fonctionne, le service confirmera
que le service de l’utilisateur a été restauré au niveau SLA requis.

Étape 7 : Clôture de l’incident

Pour finir notre service confirmera le correctif et fermera le ticket. Assurez-

vous de recueillir une confirmation de bon fonctionnement de la part de
l’utilisateur qui a déclaré l’incident avant de fermer le ticket.

L’analyste de l’incident devra rédiger le rapport d’incidence en s’assurant de

décrire les éléments ci-dessous :

1. Date de clôture effective : date de résolution effective de l’incident.

2. Délai de traitement : journées nécessaires au traitement de l’incident.

3. Source de l’incident : interne ou externe.

4. Catégorie de l’incident.

5. Type d’incident.

6. Cause de l’incident.

7. Conséquence de l’incident.

8. Le ou les responsables du plan d’action.

9. Plan d’action d’amélioration continue.

Page 11 of 9
4 Manuel de gestion des incidents :
Les équipes responsables de services techniques devraient être disponibles
24h/24 et 7j/7.

En cas de problème (panne ou bug de fonctionnalité), les membres de l'équipe

doivent réagir immédiatement et restaurer le service. Ce processus, appelé
gestion des incidents, est un défi permanent et complexe pour les entreprises de
toute taille.

Nous voulons aider les équipes partout dans le monde à améliorer leur gestion
des incidents. Inspirés par des équipes comme celle de Google, nous avons créé
ce manuel pour résumer le processus de gestion des incidents.

Ce sont les leçons que nous avons tirées en répondant aux incidents depuis plus
d'une décennie. Bien qu'il repose sur nos expériences uniques, nous espérons
qu'il pourra être adapté aux besoins de votre propre équipe.

a) À qui est destiné ce guide ?

Si vous faites partie d'une équipe de développement ou opérationnelle

responsable des services Internet pour des clients nécessitant une disponibilité
24h/24 et 7j/7.

b) Qu'est-ce qu'un incident ?

Nous définissons un incident comme un événement ayant provoqué une

perturbation ou une réduction de la qualité d'un service nécessitant une réponse
d'urgence. À la place, les équipes qui adoptent les pratiques ITIL

Un incident est résolu lorsque le service affecté fonctionne de nouveau de

manière habituelle. Cela inclut uniquement les tâches requises pour restaurer
toutes les fonctionnalités.

Le post-mortem de l'incident est réalisé après l'incident pour en déterminer la

cause profonde et mettre en œuvre des mesures pour la corriger avant qu'elle ne
provoque un nouvel incident.

c) Nos valeurs en matière d'incidents

Un processus de gestion des incidents ne saurait couvrir toutes les situations

possibles, c'est pourquoi nous fournissons à nos équipes des conseils généraux
sous forme de valeurs.

À l'instar des valeurs , nos valeurs en matière d'incident sont conçues pour :

Page 12 of 9
 • Guider une prise de décisions autonome par les personnes et les équipes
responsables des incidents et des post-mortems ;

• Développer une culture d'identification, de gestion et d'apprentissage des

incidents cohérente entre les équipes ;

• Aligner les équipes quant à l'attitude qu'elles doivent adopter aux étapes
d'identification, de résolution et d'analyse des incidents.

Étape Valeur Valeur liée à Justification

relative aux Société
incidents
1. Détection La société sait Construire Un service équilibré inclut suffisamment de
avant ses avec cœur et surveillance et d'alertes pour détecter les incidents
clients équilibre avant nos clients.
Une surveillance de pointe nous prévient des
problèmes avant même qu'ils ne deviennent des
incidents.
2. Réaction Faites Miser sur Personne n'aime être réveillé en pleine nuit, et
remonter, l'esprit nous ne prenons pas cette responsabilité à la
faites d'équipe légère. Mais les gens comprennent que, de temps
remonter, en temps, ils seront réveillés pour un incident où il
faites s'avère qu'ils ne sont même pas nécessaires. Mais
remonter le plus dur, c'est de devoir se réveiller pour un
incident majeur et être contraint de rattraper le
temps perdu alors que vous auriez dû être alerté
plus tôt.
Nous n'avons pas toujours toutes les réponses,
donc « n'hésitez pas à faire remonter ».
3. Reprise Quand c'est la Le client c’est Nos clients ne veulent pas savoir pourquoi leur
cata, la un Roi service ne fonctionne pas, tout ce qu'ils souhaitent
solution doit c'est que nous le restaurions aussi vite que
être rapide possible.
N'hésitez jamais à résoudre un incident au plus vite
pour réduire son impact sur nos clients.
4. Toujours sans Entreprise Les incidents font partie de l'exécution de services.
Apprentissage reproche ouverte Nous améliorons nos services en responsabilisant
nos équipes, pas en rejetant la faute.
5. Évitez la Incarner le Identifiez la cause profonde et les changements
Amélioration répétition du changement qui empêcheront cette classe entière d'incidents
même visé de se reproduire.
incident Engagez-vous à apporter des changements
spécifiques à des dates précises.

Page 13 of 9
 d) Exigences relatives aux outils

Le processus de gestion des incidents décrit ici utilise plusieurs outils spécifiques à
La société et pouvant être remplacés selon les besoins :

• Suivi des incidents : chaque incident est suivi comme un ticket Jira, et un
ticket de suivi est créé pour suivre l'achèvement des post-mortems

• Groupe de discussion : un canal de communication écrite en temps réel

est fondamental pour diagnostiquer et résoudre l'incident en équipe.

• Tchat vidéo : pour de nombreux incidents, un tchat vidéo d'équipe nous

aider à discuter et à vous mettre d'accord sur les approches.

• Système d'alertes : un outil interne de La société gère les rotations

d'astreinte et les remontées.

• Outil de documentation : nous sauvegardant nos documents d'état

d'incident et pour le partage de post-mortems via des blogs.

• Statuspage : communiquer l'état aux parties prenantes internes et aux

clients via un canal spécifié de communication permet de tenir en
permanence tout le monde au courant.

e) Suivi des incidents

Le processus de gestion des incidents décrit ici utilise plusieurs outils spécifiques à
La société et pouvant être remplacés selon les besoins :

Chaque incident est suivi comme un ticket, et un ticket de suivi est créé pour
suivre l'achèvement des post-mortems. Le processus de ce manuel fait référence
à notre version fortement personnalisée de Jira Software.

Les tickets d'incidents sont généralement créés par un ingénieur de support en

réponse à un ticket client ou par un développeur reconnaissant une alerte de
surveillance comme un incident. Nous exhortons toute personne à créer un ticket
si quelque chose la préoccupe au lieu d'attendre que le problème potentiel ne
s'aggrave.

Dans La société, nous disposons d'un système de workflow simple pour suivre les
incidents au cours de la phase de résolution et pour enregistrer toutes les actions
importantes prises pendant la réponse à l'incident.

Page 14 of 9
 f) Responsable des incidents

Chaque incident est géré par un gestionnaire d'incident qui est globalement
garant et dispose de toute autorité pour l'incident.

Cette personne est indiquée par le responsable sur le ticket de l'incident. Le

gestionnaire d'incident est habilité à prendre toutes les mesures nécessaires pour
résoudre l'incident, ce qui implique notamment de contacter toute personne de
l'organisation et de veiller à ce que les personnes impliquées dans un incident
restent concentrées sur une restauration aussi rapide que possible du service.

Le responsable de l'incident est un rôle, plutôt qu'une personne spécifique.

Définir des rôles lors d'un incident s'avère bénéfique, car cela rend les personnes
interchangeables. Tant qu'une personne donnée sait jouer un certain rôle, elle
peut jouer ce rôle pour tout incident.

Page 15 of 9
Page 16 of 9