FLASH INFORMATIQUE FI



ITIL à l’échelle microscopique - Les pratiques adaptées à un service de quelques personnes




Jean-Damien HUMAIR


ITIL est né à la fin des années 80, sur une initiative du gouvernement britannique qui cherchait à réorganiser ses services informatiques. Les informaticiens de Sa Majesté ont observé les meilleures pratiques dans ce domaine et les ont recensées dans une série de livres, une sorte de catalogue cohérent. Ces pratiques évoluent : la version 3 d’ITIL vient de paraître, mais elle est encore peu répandue. La version 2, qui sert de référence pour cet article, est constituée de six volumes. Phénomène curieux, seuls deux d’entre eux sont abordés dans les formations et sont réellement utilisés par les services informatiques qui désirent s’itiliser ? : la fourniture des services (volume rouge) et le soutien aux services (volume bleu) [1].


JPEG - 7.2 ko
Exemple de répartition des processus ITIL dans une petite structure. Les flèches n’indiquent que les relations les plus importantes : en réalité, chaque processus est en interaction avec plusieurs autres.

Car ces meilleures pratiques ont rencontré un succès inattendu dans les entreprises, en particulier les grandes sociétés dont les services informatiques regroupent des centaines - voire des milliers - de collaborateurs. Elles commencent à se répandre dans les entreprises de plus petite taille, dont les services informatiques possèdent généralement moins de 100 postes. Les auteurs d’ITIL ont édité récemment un ouvrage à leur intention : ITIL Small-scale Implementation [2].
L’objectif de cet article est de proposer des idées et solutions pour une mise en place d’ITIL dans un service informatique de plus petite taille encore, constitué de moins de dix personnes. Concrètement, il se basera sur la structure du Centre Informatique de l’EESP [3] à Lausanne. Dans ce service, une personne prend en charge les serveurs et le réseau, une autre s’occupe des postes individuels (système, applications) et une troisième développe des outils de gestion de l’institution. Une équipe de quatre assistants-étudiants engagés à temps partiel assure le support aux utilisateurs. Enfin, un responsable organise et gère le service. Dans une si petite structure, les échanges de rôle sont fréquents et chaque personne est (plus ou moins) polyvalente.
Les deux volumes d’ITIL définissent ensemble dix processus auxquels s’ajoute une fonction, le service desk. En principe, il faudrait nommer un responsable par processus. Nous verrons comment regrouper ces tâches dans un service de petite taille. Il ne s’agira pas en revanche de décrire ici ces dix processus dans le détail. Si nécessaire, on se référera pour cela à Internet, en particulier à l’article ITIL de Wikipedia qui constitue une bonne base (l’article en anglais est meilleur).
Un avantage indéniable d’ITIL est d’instaurer un langage, une terminologie qui permet à différents prestataires de bien se comprendre. L’inconvénient est que ce vocabulaire est en anglais. Au risque d’écorcher la langue, j’utiliserai çà et là les termes originaux, en les traduisant lorsque leur sens pourrait prêter à confusion.

Un point de contact unique, virtuellement du moins

Le point de départ du soutien aux services, c’est la mise en place d’un service desk : un point de contact unique que les utilisateurs appellent pour toute question touchant à l’informatique. Les mauvaises expériences vécues par chacun avec les hotlines conduisent les utilisateurs à être réticents face à cette forme de centrale d’appels qui anonymise le service. Mais un point de contact unique ne doit pas signifier un interlocuteur unique. Ce qui doit être unique, c’est la base de données qui va recenser les demandes - les incidents dans le jargon ITIL. Si tous les membres du service informatique jouent le jeu d’alimenter la base des incidents - et dans un petit service, on peut motiver chacun-e à le faire - alors, on peut imaginer que les utilisateurs conservent le droit d’appeler directement le spécialiste qu’ils veulent. Si le spécialiste en question est en vacances ou s’il ne désire pas être dérangé, il déviera son téléphone et/ou son e-mail sur le service desk.


JPEG - 9.3 ko
Dans un petit service informatique, chaque personne est polyvalente et endosse plusieurs rôles.

Simultanément à la mise en place du service desk, voire auparavant, on élaborera le catalogue des services. Ce catalogue recense tout ce que le service informatique propose à ses utilisateurs : réseau, e-mail, assistance bureautique, etc. C’est à partir de ce catalogue que le service informatique négociera les SLA avec ses clients. Un SLA, pour Service Level Agreement , est un accord qui détermine le niveau de service que l’on s’engage à fournir. Par exemple, pour un client qui a besoin d’un accès à la base de données des finances, un SLA pourra spécifier qu’il ne peut pas s’écouler plus d’un jour ouvrable sans que cet accès fonctionne, et qu’en cas de perte des données, on doit pouvoir récupérer la base telle qu’elle était 48 heures avant la perte, au plus.
Selon la terminologie ITIL, un client est généralement composé d’un groupe de personnes. Typiquement, dans une université ou une haute école, il peut s’agir d’un institut, ou du décanat d’une faculté. Le service informatique ira négocier ces SLA avec chaque client. Il prendra donc sous son bras le catalogue des services et choisira avec le client ceux dont ce dernier a besoin parmi la liste. Parce qu’un catalogue peut n’être qu’une simple liste des services, avec éventuellement deux ou trois niveaux de prestations (intervention en cas de panne en 2 heures, 1 jour, 3 jours, par exemple).


JPEG - 12.1 ko
Dans un petit service informatique, chaque personne est polyvalente et endosse plusieurs rôles.

Les avantages des SLA sont nombreux et stratégiques : ils créent un climat de confiance avec le client qui sait ce qu’il peut attendre du service informatique ; ils protègent ledit service de l’utilisateur qui veut tout et tout de suite ; ils permettent de répartir les forces du service informatique en fonction des besoins des clients. Dans ce contexte, je pense que la tâche de service level management , dont dépendent les SLA, doit être confiée au responsable du service informatique. L’élaboration du catalogue, elle, sera une tâche partagée par tous les membres de l’équipe.
Le catalogue lui-même optimise le service informatique en mettant à jour d’éventuels doublons ou lacunes, ainsi que ses points forts et ses points faibles. La difficulté est d’en définir le niveau de détail : est-ce que support bureautique peut constituer un point du catalogue ou faut-il distinguer traitement de texte, tableur, etc. ? Dans une petite structure, une granulation assez grossière est souvent suffisante. On peut aussi limiter les SLA aux services centraux ou sensibles - bases de données de gestion de l’institution, e-mail, service de backup, notamment.

La CMDB : copie logique du parc informatique

Une fois les SLA signés, on pourra se consacrer à la gestion du parc informatique, recensé dans une CMDB (configuration management database). C’est une copie logique du parc informatique. Mettre en place une CMDB exhaustive dans une haute école n’est pas aussi aisé que dans une banque. Les caractéristiques des machines peuvent être extrêmement variées, la liberté académique peut conduire les clients à choisir eux-mêmes leur ordinateur et les applications qu’ils vont utiliser. Cela dit, on convainc assez facilement les utilisateurs de passer par le service informatique pour tout achat de matériel et de logiciel : rabais plus intéressants, délais de livraison plus courts, etc. Dès lors que les achats sont centralisés, la gestion d’une CMDB n’est plus un véritable obstacle. Mais il faut aussi en fixer les limites. ITIL propose d’y saisir les ordinateurs et logiciels, mais aussi les périphériques, et jusqu’à la documentation. Tout de même, recenser une souris et un manuel d’Excel dans une CMDB ne sera d’aucune utilité pour améliorer la performance du parc informatique. Il faut savoir raison garder.


JPEG - 9.9 ko
Puisque le service desk effectue les mises à jour du parc, c’est lui aussi qui alimentera la base de données des configurations, la CMDB

La CMDB, et avec elle la gestion des configurations, est en principe confiée au configuration management . Dans une petite structure, c’est le service desk lui-même qui tiendra à jour cette base de données : c’est lui qui installe les nouvelles machines et les logiciels, qui effectue les mises à jour. Il me semble logique qu’on lui demande de relever ce qu’il fait dans la CMDB. Les auteurs de ITIL small-scale implementation recommandent de regrouper la gestion des configurations, la gestion des changements et la gestion des mises en production (release management). Mis à part l’alimentation de la CMDB, je pense que l’idée est bonne et qu’une même personne, le responsable des postes clients typiquement, peut jouer ce triple rôle. Il supervisera alors le travail du service desk en ce qui concerne la CMDB.
ITIL établit une distinction entre la gestion des incidents et la gestion des problèmes, où un problème est la cause sous-jacente d’un incident : typiquement, le fait qu’un utilisateur ne puisse pas se connecter à Internet est un incident ; une panne de routeur pourra être le problème causant cet incident-là. Dans une petite structure, le service desk et la gestion des incidents formeront une seule entité, ce qui semble aller de soi. ITIL small-scale implementation propose de regrouper la gestion des problèmes avec la gestion des disponibilités (availability management), ce qui a priori peut sembler curieux, les deux processus faisant partie du soutien pour l’un, de la fourniture pour l’autre. L’idée n’est pourtant pas mauvaise : un problème implique forcément une baisse de disponibilité. Par ailleurs, il est judicieux de séparer la gestion des incidents et celle des problèmes, de manière à apporter un regard différent, un autre point de vue que celui du service desk, pour la mise en oeuvre de solutions. Le service desk doit trouver des réponses d’urgence, des bricolages si nécessaire, permettant à l’utilisateur de reprendre son travail. La réflexion menant à la mise en place de mesures générales, à long terme, voire proactives, n’est pas de son ressort. Le responsable des serveurs pourra endosser la tâche du problem management.


JPEG - 4.2 ko
Puisque le service desk effectue les mises à jour du parc, c’est lui aussi qui alimentera la base de données des configurations, la CMDB

Il devra travailler en étroite collaboration avec son collègue responsable des changements. Un changement - mise à jour de logiciels, remplacement d’un serveur, etc. - mal préparé est toujours source de problèmes, impliquant d’importantes pertes de temps, et pour les utilisateurs, et pour le service informatique. Une CMDB exhaustive est un outil indispensable à une bonne gestion des changements.
La gestion de la capacité - qui consiste à doter l’institution de machines suffisamment performantes pour répondre aux besoins, mais pas surdimensionnées afin de limiter les coûts - peut très bien être regroupée avec la gestion financière. La tâche de capacity management reviendra donc au responsable du service, qui est aussi chargé du financial management.
La gestion de la continuité met en place des procédures à suivre en cas de catastrophe : incendie, inondation de la salle des machines, etc. Dans une petite structure, les démarches informatiques seront traitées en même temps, et par les mêmes personnes, que le plan d’action général de l’institution en cas de catastrophe. On peut imaginer que la fonction de continuity management soit confiée à une personne externe au service informatique. Dans notre exemple de l’EESP, cette fonction peut être confiée au poste de développeur, moins concerné par les autres processus.

ITIL, est-ce bien utile ?

La mise en place de ces dix processus est un travail de longue haleine. Quels bénéfices peut-elle apporter à un petit service informatique ? D’abord, elle permettra de fournir une qualité de service plus constante, moins dépendante des personnes. Elle renforcera la sécurité des données : redondances, backups, etc. - ITIL est très précis dans ce domaine où les petites entités manquent souvent de méthode. Elle procurera au service informatique une image de professionnalisme certainement bienvenue. Enfin, un service conforme à ITIL sera bien armé pour une démarche de qualité. Sachant que les HES doivent obtenir une certification ISO 9000, cet argument prend toute son importance.

[1] ITIL, Service Support. London, TSO, 2000. ITIL, Service Delivery. London, TSO, 2000

[2] S. Taylor, I. Macfarlane : ITIL Small-scale Implementation. London, TSO, 2005

[3] Haute école dans le domaine du travail social et de la santé



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.