Actualités
Atexo adopte les concepts ITIL "Incident" et "Problème" pour ses projets

Atexo adopte les concepts ITIL "Incident" et "Problème" pour ses projets

Par Direction des projets

ITIL (IT Infrastructure Library) est un référentiel de bonnes pratiques de management de système d'information (infrastructure, système applicatif, projet).

Ce référentiel permet d'utiliser un vocabulaire commun entre ATEXO et ses clients, et d'adopter des pratiques homogènes sur l'ensemble des projets. 

Deux notions ITIL sont fondamentales : "Incident" et "Problème"

En maîtrisant ces deux notions, et en les utilisant de façon précise en interne et dans nos communications ATEXO-Clients, nous augmentons l'efficacité de nos processus de support et de maintenance.

Incident ~ symptôme visible

Un Incident est défini par ITIL comme étant : « Tout événement qui ne fait pas partie du fonctionnement standard d’un service et qui cause, ou peut causer, une interruption ou une diminution de la qualité de ce service. »

De façon générale, le terme Incident correspond à un dysfonctionnement signalé par un utilisateur.

Les incidents peuvent être classés en plusieurs catégories :

  • Applicatif (Progiciel & données) - ex : une mauvaise donnée s'affiche, un message d'erreur apparaît
  • Sécurité - ex : accès à une information d'un autre utilisateur
  • Exploitation - ex : lenteurs (performance), indisponibilité
  • Installation et MàJ (mise à jour) - ex : échec de montée de version sur un environnement

Les items remontés par les utilisateurs sont toujours des incidents car il s’agit de symptômes, et non des causes.

Un incident est résolu par une action de retour au service (fonctionnement suffisant rétabli), que ce soit

  • un correctif (qui traite la cause profonde),
  • un redressement de données (en BDD),
  • un contournement / opération ponctuelle (ex : relancer une machine).

Problème ~ origine profonde

Un problème est :

  • la cause inconnue ou complexe d'un incident significatif (ce qui permet de traiter rapidement l'incident en différant le traitement du problème)
  • ou la raison sous-jacente d’une collection de plusieurs incidents présentant les mêmes symptômes (plus de 3 incidents similaires)
  • la cause d'un risque d'altération future du service (problème préventif, traité hors SLA)

Par conséquent, un problème non préventif est lié à un ou plusieurs incidents.

Attention, un incident (symptôme) ne devient jamais un problème (cause). En effet, la gestion d'un problème est indépendante de la gestion des incidents associés : l’analyse du problème peut continuer même si les incidents ont été résolus et fermés.

Il est donc nécessaire, en cas d'incident récurrent (même symptôme), de créer un problème, et lier chaque incident de même nature à ce problème.  

Pourquoi utiliser ces notions ?

L'objectif de la gestion des problèmes est notamment d'identifier les incidents récurrents, de capitaliser sur les méthodes de résolution des incidents, et de conserver la trace / l'exigence du traitement complet de l'incident via le problème associé (logique de maintenance préventive). Ce traitement peut être :

  • L'application d'une solution de contournement systématique et documentée ("Fiche Solution")
  • La correction partielle de la cause, permettant de minimiser l'impact (moindre occurrence, ou moindre symptôme). Dans ce cas, le problème initial est fermé, et un nouveau problème est éventuellement pour le cas résiduel.
  • La correction complète et définitive de la cause identifiée (qui clôt le problème, met fin à la récurrence des incidents et permet la clôture de tous les incidents associés non encore fermés.

Un problème fermé n'est pas réouvert. Un nouveau problème peut être créé sur le même sujet.