ITIL v3 (*) a 10 ans. Le paysage du numĂ©rique n’a plus grand-chose Ă  voir avec l’informatique des annĂ©es 80. Alors que l’heure est Ă  la transformation Digital, au Cloud, Ă  l’agilitĂ©, ITIL® est-il toujours au goĂ»t du jour ? 10 ans après, que faut-il en penser ?

(*)ITIL® : Information Technology Infrastructure Library

10 ans après, ITIL® est-il toujours d'actualitĂ© ?

Sommaire ITIL V3

1. Pourquoi ITIL® ?

2. Au cĹ“ur d'ITIL V3 : la notion de services

3. Manager le cycle de vie complet des services avec ITIL V3

4. Une approche par les processus

5. StratĂ©gie de services : quels services, pour qui, comment, et Ă  quel coĂ»t ?

6. Le design des services

7. La transition des services

8. L'exploitation des services

9. L'amélioration continue des services

Introduction

ITIL®, la « bible Â» de l’IT Service Management (ITSM) trouve ses origines, selon la lĂ©gende, dans la difficultĂ© rencontrĂ©e par la UK Navy pour coordonner l’ensemble de ses services informatiques lors de la prĂ©paration de la guerre des Malouines en 1983. La volontĂ© des Ă©quipes de rendre plus cohĂ©rent l’ensemble des services informatique serait Ă  l’origine des livres ITIL®, dĂ©veloppĂ©s par la suite en 1986 avec le concours d’IBM.

A l’aube des annĂ©es 2000, l’Office Public Britannique du Commerce publie « ITIL v2 Â», qui connaĂ®t un Ă©norme succès auprès des DSI (Directions des Systèmes d’Information), des prestataires de services informatiques et des infogĂ©rants. ITIL® s’impose alors comme le standard de facto pour la gestion de l’infrastructure et des services applicatifs informatiques.

En 2007, ITIL est refondu dans une version ITIL v3 plus cohĂ©rente, plus ambitieuse, autour de 5 ouvrages recensant les bonnes pratiques (« best practices Â») pour la gestion des services informatiques (IT Service Management ou ITSM), Ă©dictĂ©es par l'Office Public Britannique du Commerce (OGC). Une ultime version sera proposĂ©e en 2011.

1. Pourquoi ITIL ?

ITIL v3 aide les DSI et les fournisseurs de services IT Ă  se structurer pour :

  • Garantir aux utilisateurs la fourniture de services applicatifs et d’infrastructures informatiques de qualitĂ© au meilleur coĂ»t,
  • Fournir des services Ă  valeur ajoutĂ©e aux Directions MĂ©tiers,
  • Rendre un service de qualitĂ© dans le respect des contrats de service et des coĂ»ts,
  • Renforcer la flexibilitĂ© du système pour intĂ©grer les mises Ă  jour et la mise en place de nouveaux services.

L’une des grandes avancĂ©es d’ITIL a Ă©tĂ© de crĂ©er un langage commun Ă  tous, permettant de nommer de la mĂŞme manière partout dans le monde, les mĂŞmes concepts. Grâce Ă  ITIL, un incident est nommĂ© incident plutĂ´t qu’anomalie ou bug, et ce, oĂą que l’on se trouve sur la Terre !

Les bonnes pratiques d’ITIL v3 permettent de rĂ©pondre aux questions suivantes :

  • Comment crĂ©er et gĂ©rer un catalogue de services ?
  • Comment « designer Â» des services qui crĂ©ent de la valeur en s’alignant sur les enjeux mĂ©tiers et IT ?
  • Comment sĂ©curiser les mises en production de nouveaux projets sans remettre en cause l’existant ?
  • Comment traiter efficacement les incidents et les Ă©vĂ©nements dans le système d’information (SI) ?
  • Comment gĂ©rer les changements des configurations ?
  • Comment mettre en place des indicateurs pour mieux assurer la gouvernance de la DSI ?
  • Comment assurer la disponibilitĂ© et la continuitĂ© des services ?
  • Comment dĂ©finir les contrats de niveaux de service (SLA pour Service Level Agreements), de niveaux d’exploitation (OLA pour Operational Level Agreements) et de sous-traitance (UC pour Underpinning Contracts) ?
  • Comment mettre en place l’amĂ©lioration continue des services proposĂ©s ?

2. Au cĹ“ur d’ITIL® v3 : la notion de services

Faire de l’IT, c’est compliquĂ© ! Trop souvent, l’attention est focalisĂ©e sur la technique et le travail en silo finit par faire perdre de vue l’utilisateur et la valeur pour le client. La notion de service de bout en bout est l’essence mĂŞme d’ITIL®.

Selon ITIL® v3, un service se dĂ©finit comme un ensemble de moyens mis en Ĺ“uvre pour produire de la valeur pour un client en lui apportant un rĂ©sultat dĂ©sirable et sans qu’il n’en supporte les coĂ»ts (en termes d’effort ou de financement) ni les risques associĂ©s (en termes de complexitĂ© et de garantie).

Ce que nous pourrions rĂ©sumer par l’équation suivante :

SERVICE = VALEUR x GARANTIE

Par analogie, dans les transports en commun, l’usager, pour ĂŞtre transportĂ©, n’a pas besoin de savoir comment fonctionne le bus, ni de savoir qui le conduit. Ce qui l’intĂ©resse, c’est de savoir que le bus est fiable et moderne, qu’il a une vraie valeur d’usage (il est Ă  l’heure et passe près de chez lui). Bref, en rĂ©sumĂ©, que quelqu’un s’occupe pour lui de gĂ©rer les transports afin qu’il n’ait qu’à les utiliser.

ITIL® place le concept de service au cĹ“ur des bonnes pratiques afin de fournir de la valeur d’usage de bout en bout. Le fournisseur de services opère et optimise un catalogue de services (messagerie, visioconfĂ©rence, stockage, etc.) afin de dĂ©livrer de la valeur aux MĂ©tiers, dans une relation client/fournisseur. Les Directions MĂ©tiers sous-traitent au fournisseur de services la crĂ©ation et la maintenance des outils qui lui sont nĂ©cessaires pour assurer sa mission. Le fournisseur prend en charge les risques opĂ©rationnels et facturent ces services tandis que le client se concentre sur son cĹ“ur de mĂ©tier.

Que penser de la notion de services en 2017 ?

S’il n’y avait qu’une seule chose Ă  retenir d’ITIL, ce serait la notion de service et de centre de services, qui restent pleinement d’actualitĂ©. Les acteurs du Cloud y font eux-mĂŞmes rĂ©fĂ©rence dans le concept mĂŞme de leurs offres (Amazon Web Services).

VĂ©ritable dĂ©clinaison au XXIème siècle du majordome du XIXème, ce concept dominant perdure et s’est diffusĂ© Ă  l’ensemble des MĂ©tiers (centre de service Achats, centre de services Finance, etc.).

La notion de management des services (qui intègre les concepts de niveaux de services, de portefeuille de services, de stratĂ©gie de services entre autres) reste particulièrement pertinente.

Le concept de services a mis en lumière l’importance de la qualitĂ© et de la robustesse.

Par contre, les attentes en matière de services ont largement Ă©voluĂ©es. LĂ  oĂą on attendait de la stabilitĂ© et de la fiabilitĂ©, on attend aujourd’hui, en plus, plus d’agilitĂ©, de mobilitĂ© et d’évolutivitĂ©.

3. Manager le cycle de vie complet des services avec ITIL v3

Les bonnes pratiques d’ITIL v3 se sont structurĂ©es autour du cycle de vie des services en 5 Ă©tapes dĂ©crites chacune dans un livre :

  • La stratĂ©gie de services
  • Le design des services
  • La transition des services
  • L’exploitation des services
  • L’amĂ©lioration continue

Que penser du management du cycle des services en 2017 ?

La notion de cycle de vie des services reste vraie mais, dans un monde qui bouge plus et plus vite, l’idĂ©e d’une succession d’étapes cloisonnĂ©es se trouve dĂ©bordĂ©e par le besoin d’évolution et d’innovation continues. MĂŞme si la cause est toujours noble, stratĂ©gie et mise en Ĺ“uvre sont devenues plus dynamiques. Le dĂ©veloppement de l’agilitĂ© et du Lean Start-Up tend Ă  rĂ©duire les cycles de commercialisation des produits, Ă  mesurer rĂ©gulièrement les progrès rĂ©alisĂ©s et Ă  obtenir des retours de la part des utilisateurs.

Les stratĂ©gies mises en place ne sont plus figĂ©es et s’adaptent parfaitement Ă  un dĂ©marrage rapide d’un projet. Les tests sont effectuĂ©s de façon itĂ©rative et le projet enrichi au fil de l’eau. Dans cette approche, les « pizza teams Â» continuent de se poser les questions que posait ITIL® il y a 10 ans, mais elles y rĂ©pondent de façon dĂ©cloisonnĂ©e et plus agile.

4. Une approche par les processus

Dans ITIL® v3, les bonnes pratiques sont dĂ©crites sous forme de processus transverses Ă  l’organisation, intĂ©grĂ©s, clairement dĂ©finis et assez flexibles pour s’adapter Ă  tout type d’organisation.

La dĂ©marche par les processus vise Ă  Ă©tablir un cadre pour structurer les activitĂ©s IT et les interactions entre fournisseur et client, avec une approche descriptive, pas Ă  pas.

La qualitĂ© de services se fonde sur les processus, une approche qui existe Ă©galement dans plusieurs normes de qualitĂ© dont la plus cĂ©lèbre est ISO 9001.

L’approche par les processus vise Ă  maĂ®triser et amĂ©liorer le fonctionnement d’une organisation et favorise le travail en synergie entre les diffĂ©rentes parties prenantes du projet, qui, toutes, contribuent Ă  sa rĂ©ussite.

Cela nĂ©cessite de mettre en place une organisation collaborative et horizontale pour faire coopĂ©rer les diffĂ©rentes parties prenantes (clients, mĂ©tier, exploitation, conception, etc.) en s’appuyant sur 4 concepts clĂ©s suivants :

Pour autant, la structure d’ITIL V3 sĂ©pare involontairement les processus de stratĂ©gie de design et de mise en Ĺ“uvre.

Que penser de l'approche par processus d'ITIL V3 en 2017 ?

La stratĂ©gie d’approche par les processus reste un outil utile. Elle laisse un peu trop de cĂ´tĂ© la dynamique humaine, d’oĂą la critique assez frĂ©quente faite Ă  ITIL d’avoir introduit de la bureaucratie dans les activitĂ©s IT.

En 2017, l’heure est Ă  l’agilitĂ© et Ă  l’autonomie des Ă©quipes qui sont priĂ©es de traiter un service de sa conception en amont Ă  sa production quotidienne. Si cette approche apporte des bĂ©nĂ©fices Ă©vidents, nous constatons frĂ©quemment un risque gĂ©nĂ©rationnel : celui d’oublier les acquis du passĂ© (tracer les incidents, prĂ©parer l’exploitabilitĂ©, superviser correctement, garantir la stabilitĂ©, etc.).

Finalement, les concepts restent valides mais pas forcĂ©ment leur mise en Ĺ“uvre dans un contexte qui a fortement Ă©voluĂ©. Dans une approche agile, une relecture d’ITIL au travers de ses livrables ou de ses activitĂ©s (et non de ses processus) garde toute sa valeur…

5. StratĂ©gie de services : quels services, pour qui, comment et Ă  quel coĂ»t ?

L’objectif est de dĂ©finir, de façon claire, une stratĂ©gie de services du fournisseur (infogĂ©rant ou DSI) en intĂ©grant les notions suivantes :

  • La stratĂ©gie d’entreprise avec le principe des 4P : Perspective(vision), Position concurrentielle, Plan StratĂ©gique et Pattern(forces spĂ©cifiques),
  • Le marchĂ© potentiel (market space) afin d’identifier le client et de mieux comprendre les forces, les faiblesses et les opportunitĂ©s spĂ©cifiques Ă  une DSI ou un fournisseur externe,
  • La concurrence,
  • L’équation Service = Valeur x Garantie,
  • Les modes de fournitures du service (make by, progiciel, cloud, centre de services, etc.),
  • Les types de fournisseurs (internes, outsourcing total, partenaires, etc.),
  • Le rapport capacitĂ©s/ressources,
  • Les Ă©tapes de maturitĂ© de l’organisation,
  • La gestion des risques,
  • L’accès au service par l’utilisateur et les modalitĂ©s de commande du service (portail, App Store, etc.),
  • Le modèle de tarification et de coĂ»t du service.

Zoom sur 4 processus clĂ©s de la stratĂ©gie de services

Le portefeuille de services

L’objectif est de maximiser le rĂ©sultat du portefeuille de services en cours de dĂ©veloppement ou en production.

Ce livrable rassemble les engagements et investissements effectuĂ©s et prĂ©vus par le fournisseur de services, y compris les services des sous-traitants.

Il intègre le pipeline de services (services Ă  l’étude), le catalogue de services (en cours de dĂ©veloppement ou opĂ©rationnels) et les services retirĂ©s.

Les 4 Ă©tapes sont les suivantes :

La gestion du portefeuille de services est appuyĂ©e par un « Service Knowledge Management System Â» qui synthĂ©tise une vue en temps rĂ©el du portefeuille de services, des projets en cours et du (ou des) catalogue(s) de services.

La gestion des demandes

L’objectif est de comprendre et influencer l’évolution des volumes et de la nature des demandes des MĂ©tiers vis-Ă -vis de l’IT et l’approvisionnement en ressources.

Pour cela, il faut Ă©tablir des profils prĂ©visionnels de consommation de chacun des services dans le temps (PBA pour Patterns of Business Activities) pour rĂ©pondre de façon efficace aux diffĂ©rents types de demandes.

La gestion des demandes permet Ă©galement de capturer les besoins d’évolution, de dĂ©ploiement ou de nouveaux services, tout en garantissant que ces besoins reçoivent une rĂ©ponse et un traitement adĂ©quats dans les meilleurs dĂ©lais.

La gestion financière

L’objectif est de piloter tous les aspects financiers des services informatiques et des actifs de services pour une meilleure prise de dĂ©cision. Plus spĂ©cifiquement, cela signifie dĂ©finir, mesurer, contrĂ´ler, rĂ©partir, optimiser les coĂ»ts de production des services et leur tarification en s’appuyant sur 3 sous-processus :

  • La budgĂ©tisation,
  • Le contrĂ´le et la mesure,
  • La facturation.

Ce processus accĂ©lère le changement et facilite la gestion du portefeuille de services et la crĂ©ation de valeur.

La gestion de la relation mĂ©tier

Cette gestion des relations avec les mĂ©tiers n’est devenue un processus Ă  part entière qu’avec ITIL® 2011 au moment oĂą cette gestion des clients, des utilisateurs, des donneurs d’ordre devenait critique pour les DSI.

Elle commence par une identification, sur chaque Ă©tape, de la stratĂ©gie Ă  l’opĂ©rationnel, des points de contacts clients. Elle structure les interactions et la gouvernance de la DSI : demande, projet, finance, exploitation et support.

Que penser de la stratĂ©gie de services dans ITIL® V3 en 2017 ?

En 2017, l’approche par la stratĂ©gie de services est devenue mature. Elle rĂ©pond toujours aux besoins et reste d’actualitĂ© sur de nombreux concepts.

ITIL® Ă©tait mĂŞme en avance sur le sujet de la concurrence (en 2007 la menace du Cloud ou du SaaS Ă©tait inconnue des DSI). En avance sur son temps, ITIL® proposait de dĂ©finir des stratĂ©gies de services diffĂ©renciĂ©es et de rĂ©flĂ©chir sur le positionnement et l’offre de valeur de la DSI, anticipant donc sur le Shadow IT.

La gestion financière des services est plus que jamais au cĹ“ur des dĂ©bats. Sur ce sujet d’actualitĂ©, les pratiques ont fortement Ă©voluĂ© pour aller vers plus de fluiditĂ© dans la budgĂ©tisation et l’allocation des fonds. Un projet pourra ainsi ĂŞtre dĂ©coupĂ© et son budget allouĂ© au fur et Ă  mesure de l’avancĂ©e du projet. Le cycle budgĂ©taire est, lui aussi, devenu plus court et plus agile.

6. Le design de services

L’objectif du design de services dans ITIL® v3 est de garantir que tous les aspects des besoins mĂ©tiers et des contraintes (techniques, exploitation, sĂ©curitĂ©) sont correctement pris en compte dans la conception ET l’évolution de toute application ou service d’infrastructure.

Ce faisant, cette discipline vise Ă  Ă©viter de concevoir et/ou de livrer trop vite des applications mal conçues du point de vue de l’exploitation ou qui viendraient perturber le fonctionnement des systèmes existants.

Le design de services est une approche holistique : tous les Ă©lĂ©ments (architecture, processus, documentation, organisation et compĂ©tences de run) sont Ă  prendre en compte.

Le « service design Â» d’ITIL® v3 prend en compte :

  • L’alignement sur les besoins mĂ©tiers afin de concevoir des services qui amènent plus d’efficacitĂ© tout respectant les exigences de qualitĂ©, de conformitĂ©, de gestion des risques et de sĂ©curitĂ©,
  • L’optimisation des dĂ©lais et des coĂ»ts,
  • La gestion des risques afin de les supprimer ou les rĂ©duire avant que les services ne passent en production,
  • La gestion des changements dans les services existants,
  • La robustesse des infrastructures informatiques,
  • La mesure des objectifs (mĂ©thodes et mĂ©triques),
  • La mise en place de rĂ©fĂ©rentiels de conception,
  • L’amĂ©lioration continue.

La mise en Ĺ“uvre consiste Ă  s’appuyer sur les 4P :

  • Produits et technologies : solutions fonctionnelles et infrastructures techniques,
  • Partenaires et fournisseurs : intĂ©gration de fournisseurs et de prestataires extĂ©rieurs,
  • Personnel : impact d’un nouveau service (dĂ©veloppement et mise en production) en termes de ressources humaines,
  • Processus : impact d’un nouveau service (dĂ©veloppement et mise en production) en termes d’organisation.

Zoom sur 2 processus clĂ©s du design des services

La gestion du (ou des) catalogue(s) de services

Ce processus vise Ă  dĂ©finir, publier les catalogues « publics Â» (pour les utilisateurs) et « privĂ©s Â» (pour la DSI) des services. Il rĂ©pond aux questions suivantes :

  • Quels services sont disponibles ?
  • Comment (et en combien de temps) les obtenir ?
  • Qui y a droit ?
  • Qui les rĂ©alise ?
  • Qui les supporte ?
  • Combien ça coĂ»te ?

Le catalogue de services ITIL® v3 est Ă  la fois l’outil marketing principal de la DSI et le fondement de la gestion financière. Il peut ĂŞtre structurĂ© en services mĂ©tiers et en sous-service techniques. La gestion du catalogue de services intègre l’architecture des services, leur nommage, leur description, leur promotion, et les moyens (portails) de les commander.

La gestion des SLA (niveaux de services)

Ce processus permet de dĂ©finir et de nĂ©gocier les engagements de services de l’IT avec ses clients, de mesurer et Ă©tablir des reportings sur l’atteinte de ces engagements, et de lancer, si nĂ©cessaire, des actions d’amĂ©lioration, en contrĂ´lant les coĂ»ts et bĂ©nĂ©fices pour le business.

Un SLA (pour Service Level Agreement) est un contrat entre un client interne et un fournisseur (DSI) qui dĂ©finit les services et les engagements de qualitĂ©. Cela implique l’existence d’un catalogue de services et la mesure de la qualitĂ© des services.

Les principaux bĂ©nĂ©fices sont les suivants :

  • Objectiver la relation client/fournisseur entre direction informatique et utilisateurs
  • Garantir une meilleure dĂ©finition des besoins en termes de services
  • Favoriser l’équilibre optimal entre QualitĂ© du Service et CoĂ»ts
  • Etablir des critères objectifs de mesure de qualitĂ©
  • AmĂ©liorer la qualitĂ© et la satisfaction

Les outils Ă  utiliser reposent sur une structure documentaire, des outils de mesure de la qualitĂ© de service et un Service Level Manager.

Voici les 5 Ă©tapes du processus de gestion des SLA :

Que penser du design des services dans ITIL® V3 en 2017 ?

ITIL® n’a pas pris une ride sur le sujet du catalogue de services, ce dernier restant un incontournable ! ITIL® est arrivĂ© au bon moment pour l’IT qui avait besoin de s’organiser sur ce sujet. Sur la gestion des niveaux de services, deux philosophies s’affrontent depuis quelques annĂ©es. Pour les services matures et classiques, le design des services reste le saint Graal et rĂ©pond parfaitement aux besoins.

Concernant les services qui ont vocation Ă  Ă©voluer vers plus d’agilitĂ© et d’innovation, ITIL®, avec son approche contractuelle, est clairement anti-agile et devient un frein Ă  la coopĂ©ration. Mais l’esprit demeure : mesurer la qualitĂ© de service, dialoguer avec les clients et chercher Ă  garantir et amĂ©liorer constamment la qualitĂ© de service.

7. La transition des services

La transition des services a pour objectif de garantir, Ă  la fin de la conception :

  • Que les services sont correctement testĂ©s, intĂ©grĂ©s, mobilisĂ©s, dĂ©ployĂ©s et mis en production,
  • Qu’un inventaire Ă  jour de toutes les itĂ©rations intervenues dans la production (utilisateurs, licences, points de contacts, etc.) soit disponible,
  • Que la gestion des Ă©volutions soit maitrisĂ©e pour Ă©viter une rĂ©gression sur l’existant.

La transition des services permet de valider que les services nouveaux, modifiĂ©s ou retirĂ©s rĂ©pondent bien aux attentes des et respectent les spĂ©cifications ET la planification.

N’oublions pas que 80% des incidents en exploitation sont causĂ©s par des changements mal gĂ©rĂ©s.

La transition des services consiste donc Ă  mettre en place une organisation et des processus permettant de valider et prioriser la conception et le GO pour la production et le dĂ©ploiement de chaque changement. Dans ITIL®, une modification technique, un patch, l’ajout de capacitĂ© de traitement ou de stockage, sont Ă©videmment des changements Ă  valider ainsi que tout changement de mĂ©thode de travail ou de SLA. Dans ITIL® tout est changement !

Il s’agit donc, pour chaque changement de :

  • Le tester complètement,
  • Le prĂ©parer pour la production,
  • GĂ©rer les risques associĂ©s,
  • Organiser la mise en production (communication, transfert de compĂ©tences, mise Ă  jour des rĂ©fĂ©rentiels, etc.),
  • Le mettre en production,
  • D’organiser la mise en production en termes de transfert de compĂ©tence et de mise Ă  jour des rĂ©fĂ©rentiels entre autres.

Zoom sur 4 processus clĂ©s de la transition des services

La gestion des changements

Ce processus garantit que tous les changements sont autorisĂ©s et tracĂ©s. Il a pour objectif de rĂ©pondre aux besoins des MĂ©tiers tout en rĂ©duisant les incidents et les corrections itĂ©ratives.

Concrètement, ce processus garantit que tous les changements soient connus, Ă©valuĂ©s, approuvĂ©s et implĂ©mentĂ©s, rapidement et efficacement, via des mĂ©thodes et procĂ©dures standardisĂ©es, afin de minimiser les incidents liĂ©s aux modifications sur la production et les risques affĂ©rents.

Il est structurĂ© de la façon suivante :

  • En cas de besoin de changement une demande est dĂ©posĂ©e.
  • Suivant la « taille Â» (le risque), la demande est Ă©valuĂ©e - par un coordinateur, le change manager, ou le « ComitĂ© d’Approbation des Changements Â».
  • Elle fait l’objet d’une double validation tout d’abord pour Ă©tudier/dĂ©velopper, puis pour implĂ©menter.

Le pĂ©rimètre inclut tout changement sur un service Ă  savoir l’ajout, la modification ou le retrait d’un service ou d’un composant de service autorisĂ©, planifiĂ© ou supportĂ©, avec la documentation associĂ©e.

Les points importants Ă  retenir sur les activitĂ©s sont les suivants :

  • Estimer et Ă©valuer (impact, d prioritĂ© et autoritĂ© du changement),
  • Planifier avec le calendrier des changements et le calendrier des interruptions planifiĂ©es de service (y compris les retours en arrière),
  • Coordonner (construction du changement et des tests).

Les tests et validations des services

Ce processus dĂ©finit les mĂ©thodes et les techniques pour garantir que le nouveau service ou le service modifiĂ© correspond bien aux besoins et est conforme aux spĂ©cifications (assurance-qualitĂ©).

Il gère l’ensemble des processus de test : les tests unitaires, les recettes fonctionnelles et d’intĂ©gration, les tests de charge et de performance, les tests de sĂ©curitĂ©, les tests d’« usabilitĂ© Â» et d’exploitabilitĂ©, l’interopĂ©rabilitĂ© et en particulier les tests de non rĂ©gression et de compatibilitĂ©.

La gestion des mises en production et des dĂ©ploiements

L’objectif de ce processus est d’assurer la traçabilitĂ© des packages de mise en production et des dĂ©ploiements ainsi que de planifier les dĂ©ploiements.

Il garantit et optimise les installations, les dĂ©ploiements, les activations de nouveaux composants en production ainsi que produire et gĂ©rer un rĂ©fĂ©rentiel des images de logiciels en production appelĂ©e la « Definitive Software Library Â».

Le principe est le suivant :

  • Grouper les changements en Â« versions Â»,
  • CrĂ©er des standards et procĂ©dures de construction, test, livraison, test d’exploitabilitĂ©, installation, formation, communication, dĂ©marrage des versions,
  • ContrĂ´ler et garantir leur respect,
  • Maintenir la DSL et le planning de mise en production

ITIL® v3 permet de mieux intĂ©grer la rĂ©alisation effective des dĂ©ploiements et insiste sur l’automatisation.

ITIL® intègre les concepts clĂ©s suivants :

  • La notion de DML, lieu oĂą l’on stocke toutes les versions de tous les logiciels (OS, applis) utilisĂ©s en production,
  • La check list et le cycle de mise en production,
  • Le regroupement des changements dans une seule mise en production,
  • Le planning prĂ©dĂ©fini de mise en production.

Les principaux bĂ©nĂ©fices sont :

  • L’amĂ©lioration de la QualitĂ© de Service et ce, Ă  faible coĂ»t,
  • La diminution du nombre d’erreurs lors du dĂ©marrage d’un applicatif,
  • Une meilleure satisfaction des utilisateurs car tous les acteurs de la DSI sont formĂ©s,
  • Une plus grande stabilitĂ© de l’application dès la mise en production car elle est sauvegardĂ©e, supervisĂ©e, automatisĂ©e, etc.

La gestion des actifs de services et des configurations

Chaque jour, de nouveaux services sont livrĂ©s, de nouveaux utilisateurs se connectent, des PC sont remplacĂ©s, de nouvelles licences sont attribuĂ©es. L’objectif de la gestion des configurations est de pouvoir maintenir Ă  jour en temps rĂ©el un inventaire de l’ensemble des « actifs de services Â» (logiciels, serveurs, codes, documentations, compĂ©tences clĂ©s) pour :

  • Faciliter l’asset management,
  • Garantir la maĂ®trise des Ă©quipements et composants en production,
  • Faciliter l’analyse des changements,
  • Faciliter le diagnostic des incidents.

ITIL® v3 recommande la mise en Ĺ“uvre d’un Configuration Management System. La traditionnelle CMDB est remplacĂ©e par une approche plus flexible de CMDB fĂ©dĂ©rĂ©e (« integrated CMDB Â»), regroupant sous un processus unique l’ensemble des outils d’inventaires et de rĂ©fĂ©rentiels de gestion des configurations ainsi que des outils de requĂŞte ou de BI (Business Intelligence) permettant d’interroger cette masse d’informations.

La gestion des connaissances

L’objectif est de garantir que les compĂ©tences acquises en phase projet sont bien capitalisĂ©es et transmises en exploitation. Ce processus amĂ©liore la qualitĂ© de prise de dĂ©cision en s’assurant que des informations et des donnĂ©es fiables et sĂ©curisĂ©es sot disponible tout au long du cycle de vie d’un service.

Le principe est le suivant :

  • Processus d’identification des connaissances clĂ©s,
  • Standardisation des documents et activitĂ©s de transfert de compĂ©tences,
  • Mise en place d’un « Service Knowledge Management System Â» (Gestion documentaire + moteur de recherche).

Que penser de la transition des services dans ITIL® V3 en 2017 ?

Difficile de nier que le besoin de gĂ©rer la transition des services reste d’actualité… Soulignons tout de mĂŞme que les bonnes pratiques et les processus proposĂ©s par ITIL® revĂŞtent un aspect très bureaucratique qui impose une gestion des mises Ă  jour avec des paliers très lourds. La transition des services permet de sĂ©curiser cette Ă©tape cruciale dans un contexte oĂą les mises Ă  jour sont peu frĂ©quentes. Ce principe est battu en brèche par les mouvements Agile et DevOps qui favorisent des mises Ă  jour frĂ©quentes et de petite taille ainsi que par le Cloud dans lequel les ressources, gĂ©rĂ©es dynamiquement, deviennent plus complexes Ă  inventorier.

L’approche ITIL® de la transition des services nĂ©cessite d’être revue en mettant Ă  profit les actuels outils d’automatisation très poussĂ©s de mise en production, de test, de dĂ©ploiement et de retour arrière.

8. L’exploitation des services

L’exploitation des services, au sens ITIL® du terme, couvre toutes les tâches quotidiennes d’exploitation, d’administration et de support aux utilisateurs, y compris la supervision IT. Elle regroupe les autres activitĂ©s de l’ancien « Service Support Â» et remet la production quotidienne au centre du dĂ©bat. Elle rĂ©habilite notamment les activitĂ©s de supervision.

L’objectif est de fournir et gĂ©rer les services au niveau de service dĂ©fini avec les clients et de gĂ©rer la technologie utilisĂ©e ainsi que les activitĂ©s des Ă©quipes qui supportent les services.

Elle regroupe toutes les fonctions d’exploitation quotidienne, et notamment, sans exhaustivitĂ© :

  • Supervision,
  • Gestion des batches et interfaces,
  • Sauvegardes,
  • Impressions,
  • Reporting sur la qualitĂ© de la production,
  • Maintenance et administration quotidienne des Ă©quipements physiques,
  • Maintenance, purge, tuning des composants middleware et des bases de donnĂ©es.

Cette version insiste également sur le fait d’automatiser tout ce qui peut l’être au sein de 5 processus clés :

  • Le centre de services,
  • La gestion des incidents,
  • L’exĂ©cution des demandes,
  • La gestion des problèmes,
  • La gestion des accès.

Zoom sur 5 processus clĂ©s de l’exploitation des services dans ITIL® v3

Le centre de services

Le centre de services se dĂ©finit comme le point de contact UNIQUE pour toutes les interactions quotidiennes avec les utilisateurs (demandes de traitement ou d’action, questions, incidents).

  • Une Ă©quipe est dĂ©diĂ©e, outillĂ©e et staffĂ©e pour accueillir (tĂ©l, mail, web) tous types de demandes (standard/non standard) et incidents.
  • La rĂ©ponse et la rĂ©solution se font sur la base de du savoir propre et de la base de connaissances.
  • Le service desk gère les appels de bout en bout, avec escalade au niveau 1/2/3 et externe.

La gestion des incidents

L’objectif est de restaurer le service Ă  l’utilisateur le plus vite possible, le plus efficacement possible, et de minimiser l’impact sur l’activitĂ© de l’entreprise, en s’appuyant sur 5 concepts clĂ©s :

  • Restaurer le service ne signifie pas rĂ©soudre un problème.
  • La dĂ©tection de l’incident se fait via l’utilisateur et la surveillance des infrastructures.
  • Les escalades techniques et hiĂ©rarchiques doivent ĂŞtre clairement dĂ©finies.
  • Le niveau de prioritĂ© impose le dĂ©lai de traitement.
  • Le Service Desk gère l’incident de bout en bout.

Le processus exploite les outils de HelpDesk, la base de connaissances, les accords de service avec les experts, un portail de « self-service Â», les accords de qualitĂ© de service avec les clients, les procĂ©dures dĂ©gradĂ©es et les incidents managĂ©s par le Duty manager.

Le processus est le suivant :

  • Sur dĂ©tection, l’incident est loggĂ©.
  • Sa prioritĂ© est dĂ©terminĂ©e.
  • Si l’erreur est connue, le contournement ou la solution est appliquĂ©.
  • Dans le cas de procĂ©dures de contournement ou dĂ©gradĂ©es, la mise en Ĺ“uvre a lieu.
  • Dans le cas d’un diagnostic, cela dĂ©clenche le suivi sur un principe d’escalade suivant un circuit prĂ©dĂ©fini.
  • De bout en bout, un contrĂ´le est effectuĂ© par le gestionnaire des incidents.
  • L’incident est clĂ´turĂ©.

L’apport de ce processus se traduit par une meilleure satisfaction des utilisateurs, plus de rĂ©activitĂ© face aux incidents, une meilleure mesure des incidents et de la disponibilitĂ©, plus d’information au management et un dĂ©veloppement de la fidĂ©litĂ© des clients internes et externes.

L’exĂ©cution des demandes utilisateurs

Ce processus garantit que les demandes quotidienne des utilisateurs sont traitĂ©es rapidement et efficacement :

  • Demandes de PC, dĂ©mĂ©nagement d’un poste, demandes de tĂ©lĂ©phone, d’application micro, etc.,
  • Demandes de formation, d’information,
  • Demandes « quotidiennes Â» de production (dĂ©clencher un batch manuel, des impressions, etc.).

Ce processus est très orientĂ© « Outillage Â» et Workflow et pour sa mise ne place, il est prĂ©conisĂ© de :

  • Partir du catalogue de services,
  • Outiller via un portail et des formulaires toutes les demandes quotidiennes,
  • Mettre en place des rĂ´les pour suivre les flux et les dĂ©lais de rĂ©alisation.

La gestion des problèmes

Ce processus Ă©tend (enfin) la notion d’incidents Ă  la prĂ©vention et permet de rĂ©pondre Ă  la question : Comment faire pour Ă©viter qu’un incident ne se reproduise et/ou comment mieux rĂ©agir si cet incident se reproduit ?

Il a pour objectif de minimiser l’impact des incidents et problèmes sur l’activitĂ© de l’entreprise et d’en rĂ©duire la rĂ©currence.

Pour ce faire, le processus de gestion des problèmes cherche Ă  trouver la « root cause Â» d’une erreur et Ă  implĂ©menter des actions permanentes de correction ou d’amĂ©lioration.

4 concepts clĂ©s de la gestion des problèmes dans ITIL® V3 :

  • Un problème est crĂ©Ă© après la rĂ©solution d’incident critique ou lorsque l’on constate la rĂ©pĂ©tition d’un mĂŞme incident ou que l’on identifie un risque rĂ©current ou critique. Une erreur connue dĂ©clenche un incident (identification), qui devient un problème, puis une erreur connue et doit permettre de trouver une solution permanente (solution) et donc un changement (mise en Ĺ“uvre et test).
  • Dans la mĂŞme logique, une analyse a posteriori des incidents permet de suggĂ©rer des focus sur certains problèmes.
  • Le cycle est le suivant : proposition, validation, planification, revue des problèmes
  • Ce processus nĂ©cessite que des ressources y soient affectĂ©es.

Les Ă©quipes peuvent s’appuyer sur l’outil de Help Desk, la base de connaissances et la disponibilitĂ© des experts techniques. Ce processus permet :

  • Une amĂ©lioration de la QualitĂ© de Service, Ă  faible coĂ»t,
  • Une diminution du nombre d’erreurs et donc du nombre d’incidents,
  • De façon gĂ©nĂ©rale, l’amĂ©lioration continue,
  • Une amĂ©lioration du taux de rĂ©solution 1er niveau,
  • Une plus grande satisfaction des utilisateurs.

Il est important de prĂ©voir un budget pour Ă§a.

La gestion des accès

Ce processus spĂ©cifique de gestion des demandes de droits sur les applications et infrastructures, de surveillance de la conformitĂ© des droits et de retrait des habilitations a Ă©tĂ© apportĂ© par ITIL® v3.

Les concepts clĂ©s reposent sur les accès, les droits, les identitĂ©s, les groupes et les Directory Services.

Ce processus consiste Ă  exĂ©cuter la politique de sĂ©curitĂ©, c’est-Ă -dire :

  • GĂ©rer les demandes d’accès (portail),
  • VĂ©rifier la validitĂ© de la demande,
  • Fournir les droits,
  • Surveiller l’évolution des besoins (mutations, dĂ©parts),
  • Tracer,
  • Supprimer les accès.

La partie « politique et outillage Â» est traitĂ©e dans le processus de sĂ©curitĂ©.

Que penser de l’exploitation des services dans ITIL® V3 en 2017 ?

ITIL® a permis de faire progresser les helpdesks et la satisfaction client Ă  une Ă©poque d’explosion du nombre d’applications et de technologies. Depuis ITIL® v3, la situation a bien Ă©voluĂ©e. Les parcs bureautiques sont mieux maĂ®trisĂ©s et les solutions de self-service se gĂ©nĂ©ralisent, induisant une baisse des flux de demandes concernant des incidents basiques. Aujourd’hui l’heure est Ă  l’« autonomisation Â» des utilisateurs avec des helpdesks Ă  forte valeur ajoutĂ©e. Les utilisateurs ont Ă  prĂ©sent accès Ă  plus d’informations, Ă  un support Ă  l’usage et plus d’autonomie, en particulier grâce aux portails de service desk modernes et demain, aux chatbots qui permettent de s’auto-dĂ©panner. Grâce Ă  ITIL® les helpdesks ont changĂ© de visage et sont entrĂ©s dans le XXIème siècle. Lire Ă  ce sujet notre tribune sur l’helpdesk de demain.

9. L’amĂ©lioration continue des services

L'amĂ©lioration continue des services a pour but d'aligner de façon permanente les services IT avec les besoins du business et de :

  • Faire la revue, analyser et de faire des recommandations sur les amĂ©liorations Ă  chaque phase du cycle de vie des services,
  • Analyser les rĂ©sultats au regard de l’atteinte des niveaux de services,
  • ImplĂ©menter des activitĂ©s pour amĂ©liorer la qualitĂ© et l’efficacitĂ© des services IT,
  • Optimiser les coĂ»ts sans baisser la satisfaction des clients,
  • ContrĂ´ler que des mĂ©thodes de gestion de la qualitĂ© sont utilisĂ©es.

3 principes essentiels sont Ă  retenir :

  • Ce qui n’est pas contrĂ´lĂ© ne peut ĂŞtre gĂ©rĂ©.
  • Ce qui n’est pas mesurĂ© ne peut ĂŞtre contrĂ´lĂ©.
  • Ce qui n’est pas dĂ©fini ne peut ĂŞtre mesurĂ©.

Ces concepts clĂ©s se mettent en Ĺ“uvre de la façon suivante :

Cette nouveautĂ© de ITIL® V3 couvre trois processus qui permettent de :

  • Mesurer la qualitĂ© de service,
  • Rassurer le reporting sur les services,
  • DĂ©finir et exĂ©cuter les plans d’amĂ©lioration.

Zoom sur les 7 Ă©tapes du processus d’amĂ©lioration continue :

  • DĂ©finir ce qu’il faudrait mesurer : qu’est-ce qui est important pour l’IT et pour les MĂ©tiers ? Que faut-il mesurer (processus ? services ? outils ? efficacitĂ© ? conformitĂ© ?) ?
  • DĂ©finir ce qu’il est possible de mesurer en listant tous les outils qui existent et toutes les mesures possibles avec ces outils puis en faisant une analyse d’écart entre ce qui Ă©tait envisagĂ© et ce qui est rĂ©alisable et choisir Ă©ventuellement d’ajouter de nouveaux outils,
  • Collecter les donnĂ©es de base sans tomber dans l’excès (attention Ă  la volumĂ©trie),
  • Ajuster les donnĂ©es de base pour les transformer dans le bon format, les grouper et calculer des donnĂ©es composĂ©es, de façon automatique ou manuelle,
  • Analyser les donnĂ©es pour comparer les rĂ©sultats avec les objectifs et identifier des tendances sous forme de graphiques et tableaux documentĂ©s (les rĂ©sultats sont-ils bons ? est-ce que l’on espĂ©rait ? etc.),
  • PrĂ©senter et utiliser l’information (tableaux de bord) et les rĂ©sultats d’analyse en les rendant accessibles aux cibles qui ne sont pas « techniques Â» pour qu’elles puissent prendre des dĂ©cisions stratĂ©giques (sans trop d’information),
  • Mettre en place les actions correctives en utilisant la connaissance acquise pour optimiser, amĂ©liorer et corriger les services fournis.

Que penser de l’amĂ©lioration continue des services dans ITIL® V3 en 2017 ?

Force est de constater qu’en 2017 comme en 2007, l’amĂ©lioration continue reste encore le parent pauvre… L’approche initiale d’ITIL® Ă©tait très orientĂ©e sur la qualitĂ© et les processus. Or, ce qui compte c’est aussi et surtout l’amĂ©lioration continue des services : ce point a Ă©tĂ© remis en lumière par ITIL® 2011. Aujourd’hui, les pratiques issues de l’agilitĂ© (rĂ©trospective rĂ©gulière, apprentissage continu, etc.) donnent clairement une nouvelle jeunesse Ă  l’amĂ©lioration continue. La culture IT Ă©volue pour se transformer et donner une vraie valeur Ă  l’amĂ©lioration continue.