Qu’est-ce qu’un examen post-incident ?

Effectué

Nous l’avons mentionné dans un module précédent dans ce parcours d’apprentissage, mais en tant que révision rapide, les incidents ont un cycle de vie qui ressemble à ceci :

Diagramme illustrant le cycle des phases ci-dessus inscrites chacune dans des cercles reliés entre eux par des flèches

Un incident passe par les phases suivantes :

  • Détection : Lorsque nous constatons d’abord qu’il existe un problème (idéalement à partir de notre système de surveillance avant qu’un client ne remarque ou se plaint) ;
  • Réponse : Nous prenons l’action, engageons notre processus de réponse aux incidents, essayons de trier la situation et de répondre en toute urgence.
  • Correction : Nous travaillons à déterminer le problème et à ramener le système ou le service dans l’ordre de travail.
  • Analyse : Après l’incident, nous essayons d’apprendre de l’expérience, peut-être en déterminant les choses que nous pourrions changer dans le système ou notre processus.
  • Préparation : Nous faisons des modifications en fonction de ce que nous avons appris qui peut améliorer notre fiabilité et le contexte (processus, et ainsi de suite) autour de celui-ci.

La rubrique de ce module se déroule en grande partie pendant la phase d’analyse. Nous apprenons des incidents en effectuant un examen post-incident.

Vous devez effectuer un examen post-incident après chaque incident significatif.

Bien que l’examen formel ait lieu après les phases de réponse et de correction, vous commencez à jeter les bases de votre analyse dès que vous recevez une alerte actionnable indiquant qu’un incident s’est produit, informez les membres de l’équipe et commencez une conversation autour de l’incident.

Définition de l’examen post-incident

Tout le monde n’utilise pas exactement le même langage pour faire référence à ce processus. Certaines personnes l’appellent :

  • Examen post-incident
  • Examen d’apprentissage post-incident
  • Analyse post-mortem
  • Rétrospective

Dans ce module, nous utiliserons le terme « examen post-incident. »

En outre, tout le monde ne l’effectue pas exactement de la même façon. Par exemple, de nombreuses personnes commencent par réunir tous les individus qui ont un lien avec l’incident, tandis que d’autres choisissent de mettre en place l’examen à travers des entretiens individuels avant de s’adresser à l’ensemble du groupe.

La seconde méthode fonctionne souvent mieux quand les situations de groupe au sein de votre organisation rendent difficile la tenue d’une réunion élargie. Par exemple, si la dynamique de groupe, les personnalités, la nature distribuée d’une équipe répartie sur les fuseaux horaires interfèrent avec ce type de collecte, il peut être plus facile de travailler sur l’examen d’une manière différente. Vous devez faire ce qui convient le mieux à votre équipe et suivant les circonstances.

Quels que soient le nom que vous lui donnez et la façon dont vous l’organisez, il y a trois points clés :

  • Vous devriez essayer d’inclure toutes les personnes impliquées dans la réponse à l’incident dans l’examen post-incident. L’inclusion de toutes ces voix est importante, car différentes personnes ont des points de vue et des souvenirs différents du même événement.
  • Vous devez effectuer l'examen post-incident dans les vingt-quatre à trente-six heures après l'événement, si possible. La neuroscience a confirmé que la mémoire humaine est notoirement non fiable ; les gens oublient des choses. Plus le temps passe après un événement, moins les souvenirs sont détaillés et précis.
  • L’examen d’un incident doit être exempt de reproche. Nous en parlerons plus en détail dans l’unité suivante.

Objectif de l’examen post-incident

L’objectif de l’examen post-incident est que votre équipe tire des enseignements et apporte des améliorations. Vous souhaitez en savoir plus sur les systèmes et sur les éléments que vous avez mis en place et qui ont fonctionné ou non, afin de pouvoir apporter des améliorations.

En même temps, vous devez vous rappeler que les éléments d’action que vous générez des—rapports, des tâches, des rapports de bogues, des tickets, des commentaires—sont utiles, mais sont périphériques au point du processus, qui consiste à apprendre et à améliorer. La génération d’une liste de mesures est au mieux un objectif secondaire.