De la théorie à la pratique : rappels de la théorie ITIL®

2. De la théorie à la pratique

2.1. Rappels de la théorieITIL®

Dans la partie documentaire de la stratégie des services, le fournisseur de services délivre de la valeur aux clients par le biais de services [d’affaires] incluant utilité et garantie et ce, au moyen des aptitudes de service dont il dispose (ressources et aptitudes) :



Ce schéma synthétique permet de bien relier les différents concepts théoriques mais il nécessite une description supplémentaire pour passer de la théorie à la pratique.

Une difficulté apparaît immédiatement à la mise en pratique : elle porte sur l’inventaire des services fournis. Dans la partie conception des services, la personne qui veut réaliser en pratique le catalogue de services se heurte rapidement à une faune très diversifiée de types de services :

  • services business : que je traduis complétement en français par services d’affaires

  • services techniques : que je traduis en service d’opérations, terme plus cohérent avec le reste du modèle

  • services de base

  • services nécessaires

  • services d’amélioration

  • services externes

  • services internes

  • services de support,

  • etc.

Je ne reviendrais pas sur la plupart de ces différents termes (à mon avis liés à des notions marketing et une tentative maladroite de classifier les services fournis).

2.2. Ce qui est réellement utile à la pratique

Je vais me concentrer sur les deux premiers types : les services d’affaires et les services d’opérations.

Ces deux types de service vont permettre de relier en pratique d’un côté les clients et utilisateurs et de l’autre les technologies et composants techniques gérés par le fournisseur de services.

Une vision claire du pont qui existe entre ces deux mondes va faciliter par la suite :

  • la formalisation des processus informatiques

  • le paramétrage des outils ITSM pour tous les processus informatiques gérés

  • une simplification de la recherche d’impact : diagnostic d’un incident, recherche de l’erreur pour un problème, analyse d’impact d’un changement, etc. sans se noyer dans des considérations métaphysiques du modèle de la CMDB et dans les arcanes parfois sombres des outils ITSM sur le sujet