On parle d’incident dès lors qu’un système (applicatif, matériel) n’assure plus le service qu’il est censé assurer, totalement ou partiellement. Dans tous les cas, cette situation a un impact sur l’entreprise, son activité, voire parfois sa pérennité : il devient alors nécessaire de mobiliser plus ou moins de ressources pour rétablir la situation, et minimiser les conséquences.
Détecter un incident : ouvrir ses yeux et ses oreilles
La gestion de l’incident sera d’autant plus efficace si celui-ci a été détecté rapidement. Il est alors nécessaire de prévoir des dispositifs au sein de l’entreprise qui permettent de faciliter son identification.
Pour commencer, il s’agira d’écouter les utilisateurs : il est primordial de prévoir un dispositif permettant aux utilisateurs d’une application de remonter facilement les problèmes qu’ils rencontrent. Les entreprises prévoient donc des « équipes support », « help desk » ou « services d’assistance ». Ces équipes ont pour mission d’être à l’écoute des utilisateurs, de répondre à leurs questionnements, et de faire le lien avec les équipes techniques lorsque cela est nécessaire.
Mais il ne suffit pas de rediriger les demandes des utilisateurs vers les équipes informatiques : il faut également observer le flux de demandes utilisateurs dans le temps, pour alerter si l’on identifie une augmentation inhabituelle et rapide de sollicitations sur un sujet précis : il peut s’agir d’un incident, qui nécessitera alors une prise en charge spécifique.
Toutefois, certains incidents ne seront pas visibles immédiatement par les utilisateurs, comme ceux, par exemple, relatifs à des traitements nocturnes de données. Pour garantir une prise en charge rapide de ces incidents, il s’agira alors de prévoir un dispositif de surveillance régulier du bon fonctionnement de ces systèmes, généralement assuré par les équipes gestionnaires des dispositifs concernés.
Anomalie ou incident ? Bien qualifier pour mieux gérer
Même lorsque plusieurs utilisateurs rencontrent des difficultés dans l’utilisation d’une application, il ne s’agit pas forcément d’un incident. En tant qu’utilisateur, on a parfois le sentiment que « ça ne fonctionne pas » et qu’il y a un problème, alors qu’il peut s’agir :
- D’une mauvaise manipulation de l’application elle-même : on est alors en présence d’un sujet purement fonctionnel, et le help desk va guider l’utilisateur dans les manipulations à effectuer pour que l’application assure le service attendu.
- D’une mauvaise qualité des données entrantes : il arrive que certaines données soient incomplètes dans la « chaîne » en amont de l’application utilisée. Soit cela est à la main de l’utilisateur, et le help desk le guide pour compléter les données, soit ce n’est pas le cas et la demande est envoyée aux équipes techniques.
Dans les deux cas évoqués ci-dessus, l’application ne fait pas l’objet d’un incident, mais au mieux d’une anomalie lorsque l’équipe technique doit prendre le relais dans la résolution du problème. A ce stade, cela ne nécessite pas de mobiliser des ressources complémentaires au-delà de ce qui est déjà prévu par le dispositif d’assistance de l’entreprise.
Mais alors, comment détecter un incident ? Parfois, c’est simple et sans appel : l’application est indisponible. C’est la page blanche. Mais souvent, c’est plus subtil, l’incident ne concerne pas toutes les fonctionnalités, ou tous les utilisateurs. L’incident peut alors être détecté :
- Par le help desk : si ce dernier reçoit de nombreuses demandes utilisateurs sur le même sujet et dans un court laps de temps.
- Par les équipes techniques : soit dans le cadre de leur surveillance, soit lors de l’analyse d’une anomalie qui s’avère être un véritable dysfonctionnement, mais qui n’avait pas fait l’objet de beaucoup de demandes utilisateurs car l’application est peu utilisée.
Dans ce cas, il est nécessaire de catégoriser et regrouper les remontées utilisateurs, de bien qualifier le problème rencontré, etde mobiliser le dispositif de gestion d’incident.
Prioriser les incidents en fonction de leur impact et de leur urgence
Première étape de la gestion d’incident : la priorisation. Pourquoi ? Tout simplement parce que les ressources de l’entreprises sont limitées, et que si plusieurs incidents surviennent en parallèle (ce qui est très souvent le cas dans les grandes organisations), il va falloir déterminer l’ordre dans lequel ils seront pris en charge.
Il convient alors de mettre en place une matrice de priorisation des incidents. On retient généralement deux critères : l’impact et l’urgence. Le croisement de ces deux axes permet de déterminer le niveau de priorité de traitement de l’incident.
On comprend ici l’enjeu d’une bonne qualification de l’incident, qui va permettre de répondre efficacement à ces deux questions :
- L’impact : quelle est l’ampleur de l’incident ? Combien d’utilisateurs sont touchés ? En effet, si un CRM utilisé par 10 000 commerciaux fait l’objet d’un incident, il sera prioritaire par rapport à l’outil de commande des fournitures de bureau utilisé par 50 responsables logistiques.
- L’urgence : dans quelle mesure le problème est bloquant, touche à un processus critique, peut être générateur de risques, et nécessite d’être résolu rapidement ?
Autant la notion d’impact est relativement facile à déterminer, celle de l’urgence est plus délicate. Plusieurs questionnements permettent toutefois de guider la réflexion :
- Le processus impacté par l’incident est-il dégradé ou totalement interrompu ?
- Est-ce un processus critique pour l’entreprise ? Est-il lié à son cœur de métier, ou alors à une fonction sensible de l’entreprise (paie des salariés, paiement des fournisseurs, etc.) ?
- Y a-t-il une possibilité de « contourner » le problème en attendant la résolution ?
- Y a-t-il un risque de contagion de l’incident à d’autres processus ou applications ? C’est un cas de figure que l’on peut rencontrer lors d’incidents impactant des infrastructures (réseaux, serveurs, etc.), d’incidents impactant des référentiels partagés ou encore des briques transversales du système d’information, etc.
- L’incident est-il visible des clients ? Risque-t-il de générer des insatisfactions ?
- Au-delà de l’impact opérationnel, l’incident génère-t-il des risques complémentaires : fraude, réputation, juridique, conformité, financier, etc. ?
Ces quelques pistes, non exhaustives, permettent de guider la réflexion afin d’évaluer dans quelle mesure l’incident est urgent à prendre en charge.
Gestion d’incident ou gestion de crise ?
L’incident a été détecté, qualifié, priorisé. Place désormais aux équipes qui vont mener les travaux d’analyse et de résolution pour rétablir le service au plus vite. Dans la majorité des cas, la cause du problème est identifiée, les correctifs sont apportés et tout rendre dans l’ordre. L’incident est résolu. Mais parfois, les choses se compliquent.
En effet, il arrive que ce qui soit qualifié comme incident prioritaire un lundi à 14h, soit requalifié quelques heures plus tard le même jour, en crise. Qu’est-ce que cela signifie ? Que la situation est devenue hors de contrôle, que le dysfonctionnement risque de compromettre la pérennité de l’entreprise : en un mot, que la situation est devenue critique et nécessite de mobiliser des ressources complémentaires.
La gestion d’incident laisse alors sa place à la gestion de crise : l’idée est désormais d’adapter le dispositif afin de renforcer les moyens logistiques et de mettre en place un pilotage dédié à ces situations critiques.
La communication, enjeu majeur de la gestion d’incident
Colonne vertébrale d’une gestion d’incident efficace : la communication. Elle doit être la plus fluide possible :
- entre les parties prenantes mobilisées pour la résolution technique de l’incident ;
- mais également avec les utilisateurs impactés, afin de leur apporter de la visibilité, voire des solutions intermédiaires pour contourner les dysfonctionnements.
La communication avec les utilisateurs ne va pas seulement dans un sens. Ils sont également des personnes précieuses à mobiliser afin :
- de co-construire les solutions de contournement, afin de garantir leur pertinence et leur clarté ;
- d’évaluer le bon fonctionnement des corrections apportées et confirmer le retour à la normale.
L’incident est résolu : place au post-mortem et à la gestion des problèmes
L’incident est terminé et le service est de nouveau assuré : les ressources dédiées à la gestion de l’incident vont alors être mobilisées sur les autres dysfonctionnements en cours. Toutefois le sujet n’est pas clos pour autant : il est bon de réaliser un post-mortem. Cette « analyse à froid » permettra d’établir les causes ayant conduit à la survenance de l’incident, et les axes d’amélioration, dans une perspective d’amélioration continue.
Activité bien distincte de la gestion des incidents, la gestion des problèmes a pour finalité de réduire la fréquence des incidents, et les impacts des incidents ne pouvant être évités. Il s’agit d’une démarche « à froid », préventive, qui permettra d’identifier et de corriger les problèmes de fond dans l’écosystème du système d’information, et assurer à ce dernier un niveau de service optimal.
Florent Goossens