A qui la faute ? De l’importance de réaliser un REX suite à la résolution d’un incident critique

Et voilà, j’étais cool, à la machine à café, en train d’échanger avec quelques collègues sur le précédent week-end et les prochaines vacances. Nous parlions de nos destinations, futures et favorites, pour les petites et grandes vacances, histoire de se mettre en jambe pour attaquer la journée de boulot. Puis le retour à la réalité fut douloureux. Un incident est tombé pendant que nous devisions, mettant tout notre système de production en rade. Bref, la bonne journée qui commence…

Incident résolu. Et après ?

Je ne vais pas vous décrire par le menu le pourquoi du comment de cet incident, ni les étapes de sa résolution. Déjà, nous sommes tous un petit peu tenus par un minimum de secret professionnel, voyez-vous. Non, le sujet d’intérêt, ici, est de partager sur la dernière étape du traitement de ce type d’incident, à savoir, le retour d’expérience, REX, ou encore analyse Post-mortem, terme beaucoup moins glorieux que je m’abstiens toujours d’utiliser.

Nan mais c’est bon ! elle fonctionne la prod ! on s’en fout du REX !

Alors… non ! mais clairement, pas du tout !
En effet, la survenance d’un incident critique n’a rien d’anodin (sinon il ne serait pas qualifié de critique) et est souvent révélateur d’un manque de contrôle sur les outils que le SI met à disposition des collaborateurs.
Avant d’aller plus loin, nous devons être bien d’accord sur ce qu’est un incident, et à quel moment celui-ci devient critique. Pour cela, nous allons nous inspirer du référentiel ITIL, référentiel reconnu et accepté de la plupart des DSI des grandes sociétés à travers le monde.

C’est quoi un incident ?

Un incident, selon le référentiel ITIL, désigne une “Interruption non planifiée d’un service informatique ou une réduction de la qualité d’un service informatique. La défaillance d’un élément de configuration qui n’a pas encore eu d’impact sur le service est aussi un incident.” Par exemple, la défaillance d’un des disques de votre système de stockage ne vous empêchera pas d’utiliser ce système de stockage, mais c’est un incident, à traiter rapidement, car il entraine une dégradation de la qualité de service dans le sens où la pérennité du stockage et la préservation des données ne sont plus garanties à 100%.

Pour mesurer la criticité d’un incident, nous allons essentiellement parler d’impact, même si la criticité dépend directement de la priorité de l’incident qui est elle-même calculée en fonction de son impact et de son urgence. Pour les plus courageux, je vous laisse consulter le lien vers la description de la priorité, de l’impact et de l’urgence selon ITIL, au pied de l’article.

Un impact, c’est après avoir tiré avec un fusil, non ?

L’impact, donc, sert à définir la manière dont les services seront affectés par l’incident. Par exemple, nous pouvons définir 3 niveaux d’impact, bas, moyen et élevé, et, pour chacun d’eux, la mesure qui y sera associée. En général, cette définition fait référence au nombre d’utilisateurs concernés par l’incident. Dit autrement, le nombre de collaborateurs impactés par l’incident et pour lesquels cet incident induit une réduction de leur capacité de travail.

Par exemple, un impact bas traduira un incident sans impact sur la capacité de production des collaborateurs ou ne concernant que quelques collaborateurs isolés. Un impact fort, quant à lui, désignera tout incident impactant une grande partie des collaborateurs ayant une fonction clé dans la société. Si vous travaillez dans une société qui gère des plateformes téléphoniques et que vous avez une anomalie sur la distribution des appels téléphoniques, il s’agit assurément d’un incident critique.

Voilà, nous avons notre incident critique. Heureusement, grâce à votre équipe technique qui est ultra performante, celui-ci est résolu rapidement. Le service est donc rétabli et vos collaborateurs peuvent continuer à travailler. Malheureusement, pendant la durée de l’incident, personne n’a pu travailler et cela se traduit par une perte sèche que votre contrôleur de gestion ne manquera pas d’estimer, avec la demande impérative de sa part que celui-ci ne se reproduise jamais.

Un REX !? Mais pour faire quoi ?!

Ben justement, j’en parle juste au-dessus : pour éviter que cela ne se reproduise. Ou, à minima réduire l’impact si celui-ci était amené à se reproduire. Pour atteindre cet objectif, il faut faire attention à la façon dont sont menées les investigations et le but que l’on veut atteindre.

Ce qu’un REX n’est pas

Un exemple de ce que le REX ne doit pas être. Tout d’abord, il ne faut pas que le REX se transforme en chasse aux sorcières. Prenons un expert technique de votre SI et appelons le Jean-Kevin. Ce n’est pas parce que Jean-Kevin a fait une erreur de manipulation qui a causé cette interruption de service, qu’il faut le virer et le mettre au pilori en place publique. Jean-Kevin serait même plutôt bien vu de tout le monde dans l’entreprise et se rapproche pas mal de l’employé modèle : Il cire les pompes de son manager, paie souvent le café aux collègues de son équipe à la cafétéria, est très prévenant concernant la qualité du service rendu, ne s’offusque pas en fin d’année s’il n’est pas augmenté… Et puis, on ne va pas non plus se débarrasser des gens à la première erreur. Alors que devons-nous faire ?

Ce qu’est un REX

Une des bonnes pratiques concernant la réalisation d’un REX est de mener un REX sans reproche. Il faut partir du principe que tout le monde a agi avec la meilleure intention du monde et, sans doute le plus important pour la suite, sur la base des informations disponibles à l’époque.
Dit autrement, la question à se poser à ce niveau, n’est pas “Qui c’est le c** qui a tout fait planter !?”, mais plutôt “quel enchainement d’évènements a poussé Jean-Kevin à faire cette erreur ?”

En effet, si vous avez identifié Jean-Kevin comme étant le maillon faible, c’est qu’il n’a peut-être pas été suffisamment accompagné pour être autonome sur les tâches qui lui sont confiées. Ou alors qu’il n’a pas les compétences techniques pour celles-ci. Ou encore que les instructions qui lui ont été données n’étaient pas suffisamment précises.

Et comment qu’on s’y prend alors, pour faire un REX ?

Réunir toutes les équipes ayant participé à la résolution de l’incident autour d’une table pour discuter de ce qui a été fait pour résoudre cet incident est un bon début. En effet, sans l’appui des équipes techniques qui ont aidé ou permis la résolution, le REX est inutile. Bien entendu, réaliser un REX nécessite de prendre en compte l’ensemble des dimensions de l’entreprise, à savoir :
- La dimension technique, comme nous l’avons vu précédemment et qui comprend le matériel, les équipements…
- La dimension humaine, qui inclut le management, l’implication des équipes, le comportement, le savoir-être, la formation…
- La dimension organisationnelle, qui va concerner la communication, les procédures d’administration ou de mise à jour, et toute la documentation associée à l’exploitation des outils du SI
Demander une analyse de la cause primaire (root cause) de cet incident. C’est à partir de cette analyse que vous pourrez identifier les actions correctives.
Lister les solutions potentielles en mode brainstorming. Cela implique que tout le monde participe, sans fard ni autocensure.
Pour chacune des solutions évoquées, estimer le coût et l’amélioration attendue pour prévenir l’apparition de l’incident en question. Ce n’est qu’après cette étape qu’il sera envisageable d’écarter certaines solutions.
Et enfin, si plusieurs solutions sont en concurrence, elles doivent être soumises à un arbitrage managérial qui décidera de celle qui sera retenue en fonction d’autres critères tels que les paramètres sociaux ou financiers.

En conclusion

Réaliser un REX n’est pas toujours aisé. En effet, de par les composantes techniques et organisationnelles concernées, il peut être difficile de réunir tout le monde autour d’une table. L’autre difficulté est dans la remise en cause de l’existant. Comme nous l’avons vu, le but n’est pas de pointer du doigt une personne ou un élément de son organisation. Mais il appartient à tout un chacun d’accepter l’échec et de reconnaitre les erreurs passées si l’on veut que le REX ait une utilité.

Gérez vos incidents avec le référentiel ITIL sur GLPI