Service desk ou bureau de support aux services
Le service desk est le contact de référence entre les utilisateurs du SI et de la DSI. Il gère aussi bien les incidents que les demandes d’assistance technique ou fonctionnelle. C’est également un point de remontée de la surveillance automatique du SI.
le Service desk est garant de la résolution des incidents et de leur information.
Ce bureau de support étend la fonction des traditionnels Call Center ou Help Desk. En plus de la gestion des incidents, problèmes ou questions, ce bureau doit s’intéresser aux besoins de changement des utilisateurs, à la capacité au changement de la DSI, aux questions financières et à la gestion de la continuité de service. Il a également la lourde tâche de tenir les utilisateurs informés.
Selon ITIL, les actions préventives de monitorage sont centralisées vers ce bureau, ainsi que les alarmes.
ITIL insiste aussi sur l’exigence de traçabilité des actions d’exploitation. Il est clair que c’est une exigence absolue et un des piliers de l’intégration de production.
Configuration management ou gestion de configuration
La gestion de configuration est nécessaire pour assurer le contrôle de tous les composants de l’infrastructure informatique, y compris la documentation. Sans cette gestion, les changements sont difficilement maîtrisables (comptabilité, régression, …) et le diagnostic/traitement des incidents imparfait (si la cause est due à une instabilité de la configuration par exemple).
A minima, il est conseillé de connaître les changements effectués ainsi que leur nature. L’utilisation d’outils (versionning, gestion de parc, aide au déploiement, …) est souhaitable. Le personnel chargé de la gestion des incidents devra avoir accès à certaines de ces informations.
Les informations de configuration sont également nécessaires pour gérer les contrats de service (quelle configuration offre quoi ?), pour la gestion des coûts et l’analyse de risque.
Change Management, Release Management ou gestion des changements et des versions
ITIL donne une définition assez restreinte de ces deux éléments (étude d’impact essentiellement). Je suis en désaccord sur ce point. Il me semble important de considérer la gestion des changements (incluant celle des versions) comme un troisième pilier dont l’importance est presque égale à la production ou au support des services. On doit certes y retrouver les études préalables (dont l’impact), mais aussi toute la phase de spécification, développement, intégration de production et recettes. Ceci est plus conforme à l’organisation actuelle des entreprises.
ITIL décrit la façon de conduire les changements de façon efficace est sécurisée afin de minimiser le risque d’incident de ces changements. Il introduit la notion de RFC (Request For Change). Ces RFC sont analysées par le CAB (Change Advisory Board) qui est chargé d’évaluer le risque et l’impact de ces changements et de conseiller le responsable des changements.
Ce sous-processus doit à la fois comprendre les impacts sur la technique, sur l’organisation, sur les risques et le business de l’entreprise. Ceci nécessite d’avoir de l’expérience et du recul.
Le sous-processus consacré aux versions vise à contrôler les activités liées au stockage, à la gestion, à la distribution et au déploiement des composants logiciels du système d’information. Il garantit que ce qui est en production est autorisée et recetté, il constitue un référentiel des logiciels validés et cherche à prendre en compte les aspects techniques (mutualisation, performance, compatibilité, …) et non-techniques (capacité interne de mise en oeuvre, schéma directeur, …). Ces versions sont stockées dans une DLS (Definitive Software Library) – bibliothèque de versions.
Incident management ou gestion des incidents
Sous-processus permettant de décrire le cycle de gestion des incidents (détection, palliatif, correctif, escalade, restauration, communication, …). L’objectif est de diminuer au maximum l’impact d’un dysfonctionnement.
Il est souhaitable de disposer d’outils permettant de tracer les incidents en cours, et d’une base de données permettant de retrouver la solution à des incidents qui sont déjà survenus.
Un incident est un évènement qui perturbe ou empêche la production normale du service informatique. La gestion des incidents est liée au contrat de service (Service Layer Agreement)
ITIL préconise d’utiliser différents statuts tout au long du cycle de vie d’un incident. Les entreprises utilisent des nomenclatures différentes pour ces statuts ; a minima, on distinguera la réception de la demande (« new »), l’acceptation (« accepted » – émission d’un ticket d’incident), l’assignation (ou la réassignation), la mise en place d’un palliatif (concept non ITIL), la résolution (« resolved ») et la clôture (« closed »). NB : un incident ne peut être clos que lorsqu’il est résolu.
Un incident peut donner lieu à une RFC (Request For Change), c’est à dire une demande de modification du SI.
La gestion correctes des incidents des incidents est indissociable d’outils de base tels que les logs normalisés et les procédures permettant de statuer sur chaque composant du SI ; si on ne sait pas statuer ni analyser ce qui s’est passé, on ne peut pas comprendre l’incident et en conséquence on ne pourra jamais progresser dans la fiabilisation du SI.
Problem management ou gestion des problèmes
La gestion des problèmes est déterminée par une vue globale des incidents (synthèse, corrélation, impact, tendance, …). On cherche ici la cause profonde des dysfonctionnements de manière à faire de la prévention. On peut également être amené à mettre en place des solutions à des problèmes qui n’ont que peu de chance de survenir (les Plans de Reprise d’Activité par exemple).
On constate en entreprise que les incidents aboutissent plus souvent à la mise en place d’un palliatif que d’un correctif. Ceci est essentiellement dû à une mauvaise estimation du coût d’une équation arrêt de production / mise en place d’un palliatif / mise en place d’un correctif. Ce problème est accentué par le fait que le palliatif est pris sur un budget de fonctionnement (urgence immédiate) alors que le correctif l’est souvent sur un budget d’investissement. Ce sous-processus a pour objet de mieux gérer cette équation.
