Système de valeur des services et chaîne de valeur

Un système de valeur des services (SVS) décrit comment les composants et les activités d’une organisation fonctionnent ensemble pour permettre la création de valeur. ITIL 4 utilise ce nom ; ITIL Version 5 l’appelle système de valeur ITIL. La Version 5 a été introduite en janvier 2026 et son programme Foundation est daté de février 2026.

Entrées et sortie

La demande est le besoin ou le désir de produits et de services des consommateurs. Des employés qui demandent un accès à distance sécurisé expriment une demande. Une opportunité est une possibilité d’apporter de la valeur ou d’améliorer l’organisation, comme une fonctionnalité cloud inutilisée qui pourrait réduire les coûts. L’organisation décide des opportunités à saisir.

La sortie du système est la valeur : les bénéfices, l’utilité et l’importance perçus par les parties prenantes. Une application de notes de frais achevée est un produit du travail. Le fait que les responsables approuvent les demandes en deux minutes au lieu de deux jours est un résultat qui rend l’application utile. Terminer le logiciel ne suffit pas à établir que les personnes en retirent un bénéfice.

La valeur est cocréée. Le fournisseur apporte la technologie et le support ; les consommateurs apportent leurs connaissances, leurs décisions et leur utilisation. Un signalement clair d’une panne, accompagné d’une capture d’écran, peut aider un agent à rétablir le service plus rapidement.

Cinq composants qui fonctionnent ensemble

La Version 5 utilise les termes chaîne de valeur et pratiques de gestion pour les composants correspondants. Ces composants fonctionnent ensemble pendant le déroulement d’une activité. Ce ne sont pas cinq étapes à suivre dans l’ordre.

Les sept principes directeurs restent les mêmes : privilégier la valeur ; commencer là où tu es ; progresser par itération avec des retours d’information ; collaborer et promouvoir la visibilité ; penser et travailler de façon holistique ; rester simple et pratique ; optimiser et automatiser. Ils orientent les choix dans tout le système. Par exemple, « commencer là où tu es » signifie examiner un processus de réinitialisation existant avant de le remplacer.

Suivre une amélioration de la réinitialisation des mots de passe

Une banque qui compte 40 agences reçoit des signalements d’attentes téléphoniques de 20 minutes pour réinitialiser des mots de passe. C’est une demande. Sa plateforme de gestion des identités possède une fonction inutilisée de réinitialisation en libre-service : c’est une opportunité.

La gouvernance vérifie que l’idée respecte la politique de sécurité. Les activités de la chaîne de valeur recueillent les besoins des employés, conçoivent et construisent le parcours de réinitialisation, puis le mettent en service. Les pratiques du centre de services, de gestion de la sécurité de l’information et d’habilitation des changements fournissent les personnes, les connaissances et les outils. L’amélioration continue vérifie ensuite si l’attente a diminué. La valeur perçue par les employés est de pouvoir reprendre le travail en quelques minutes.

Voir le système dans son ensemble

Un silo se forme lorsque des équipes travaillent isolément et partagent peu d’informations. Des objectifs propres à chaque équipe peuvent masquer des travaux en double ou des pertes d’informations lors des transferts de prise en charge. Une vision partagée du parcours jusqu’à la création de valeur aide les équipes à se coordonner, et le système permet d’emprunter différents parcours lorsque la demande change.

Les quatre dimensions sont des perspectives pour examiner l’ensemble du système : organisations et personnes, information et technologie, partenaires et fournisseurs, et flux de valeur et processus. Elles sont différentes des cinq composants du système. Le SVS peut décrire une organisation entière ou une partie de celle-ci, quels que soient son secteur et sa taille.

La gouvernance dirige et contrôle une organisation. Elle veille à ce que le travail reste aligné sur la raison d’être, la stratégie et les politiques de l’organisation. Un organe de gouvernance est la personne ou le groupe qui répond au plus haut niveau des performances et de la conformité : un conseil d’administration, des administrateurs ou le patron d’une petite entreprise. Un comité peut préparer une décision, mais l’organe de gouvernance reste responsable.

Évaluer, diriger et surveiller

Pour classer une action, demande-toi ce que la décision permet d’accomplir. Examiner une orientation possible relève d’évaluer ; définir une orientation et des responsabilités relève de diriger ; examiner les performances au regard de cette orientation relève de surveiller. Le nom du document ne suffit pas : un rapport peut éclairer une décision d’évaluation ou de surveillance.

Traduire l’orientation en décisions quotidiennes

Une politique consigne formellement les attentes et les intentions qui orientent les décisions et les activités. Par exemple : « Les données personnelles des clients doivent être stockées dans des centres de données approuvés situés dans la région du client. » La direction choisit et configure ensuite les centres qui respectent cette politique. Celle-ci fournit une règle commune sans préciser chaque action technique.

La gouvernance et la gestion ont des rôles différents. La gouvernance fixe l’orientation, approuve les politiques et supervise les résultats. La gestion planifie, organise et dirige le travail dans ce cadre, puis rend compte des résultats.

Supposons qu’un conseil d’administration impose une disponibilité de 99,9 % pour une boutique en ligne. La direction informatique décide comment concevoir, maintenir et soutenir la boutique. Elle mesure la disponibilité et communique les résultats au conseil. Celui-ci surveille les résultats au regard de l’orientation qu’il a fixée ; il n’a pas besoin de choisir chaque paramètre des serveurs.

Les contrôles peuvent accélérer le travail

Des limites de risque claires permettent aux équipes de prendre les décisions courantes en confiance. Une politique peut autoriser la préapprobation des changements standards peu risqués, tandis que les changements plus risqués font l’objet d’une évaluation distincte. Les équipes savent alors quand elles peuvent agir et quand elles doivent faire intervenir une autorité de changement.

Une autorité de changement prend des décisions sur les changements individuels dans le cadre de la gestion. Elle n’est pas l’organe de gouvernance simplement parce qu’elle approuve des travaux. Ajouter une approbation par un comité à chaque changement peut ralentir la fourniture de valeur sans améliorer le contrôle. Examine si chaque contrôle a une finalité utile, en appliquant le principe « rester simple et pratique ».

Appliquer la même logique à l’IA

La gouvernance de l’IA définit la supervision, les politiques et les responsabilités nécessaires à une utilisation sûre, légale et transparente de l’IA qui soutient les objectifs de l’organisation. Un organe de gouvernance évalue un service d’IA proposé et ses risques, définit les responsabilités et les politiques applicables, puis surveille les performances et la conformité. La direction met le service en œuvre et l’exploite dans ces limites.

La gouvernance a elle aussi besoin d’une amélioration continue. L’organe de gouvernance examine si ses contrôles restent utiles à mesure que l’organisation, la technologie et les risques évoluent. Une politique qui favorisait autrefois de bonnes décisions peut devoir être révisée lorsqu’elle commence à retarder le travail sans répondre à un risque actuel.

La chaîne de valeur des services est un modèle opérationnel pour créer, fournir et améliorer continuellement les services. Un modèle opérationnel décrit comment une organisation cocrée de la valeur et comment elle fonctionne. ITIL 4 nomme six activités liées entre elles. Chacune transforme des entrées en sorties, qui peuvent devenir les entrées d’autres activités.

La contribution de chaque activité

Identifier le travail par sa finalité

Décider de financer la messagerie cloud l’année prochaine relève de planifier. Recevoir la réclamation d’un utilisateur ou discuter des besoins métier de l’année suivante relève d’impliquer, le principal point de contact avec les consommateurs et les autres parties externes. Analyser une baisse de satisfaction et convenir d’une amélioration relève d’améliorer.

Pour un service de réservation en ligne, concevoir et assurer la transition définit les exigences de qualité et les besoins des utilisateurs, puis organise la mise en service. Obtenir/construire crée et teste les logiciels ou obtient des composants auprès d’un fournisseur. Exploiter le service chaque jour et le rétablir après une panne relève de fournir et soutenir.

Pour classer utilement le travail, il faut regarder ce qu’il permet d’accomplir. Acheter 200 ordinateurs portables rend des composants disponibles : cela relève donc d’obtenir/construire. Recueillir les retours d’information des employés sur ces ordinateurs relève d’impliquer. Les mêmes personnes peuvent contribuer aux deux activités.

Les sorties relient les activités

Une demande recueillie par impliquer peut devenir une entrée de concevoir et assurer la transition. Un composant fourni par obtenir/construire peut être mis en service par concevoir et assurer la transition. Les informations sur les performances issues de fournir et soutenir peuvent montrer à améliorer où les résultats sont insuffisants et aider planifier à fixer les priorités.

Ces liens n’imposent pas d’ordre unique. Une petite demande peut n’utiliser que les activités dont elle a besoin. Un nouveau service peut revenir à concevoir et assurer la transition après qu’un retour d’information a révélé une exigence manquante. Améliorer peut travailler sur un service existant pendant qu’obtenir/construire développe un nouveau composant.

Les activités sont plus larges que les pratiques ou les équipes

Chaque activité fait appel à plusieurs pratiques, et une pratique peut soutenir plusieurs activités. La gestion des niveaux de service aide impliquer à convenir des objectifs avec les clients, fournir et soutenir à évaluer les résultats et améliorer à repérer les objectifs non atteints. Fournir et soutenir ne peut donc pas être assimilé au centre de services.

Considérer les six activités comme une séquence de projet fixe masque cette flexibilité. Le modèle fournit des types de travail reliés entre eux ; un flux de valeur choisit un parcours parmi eux pour la demande traitée.

Un flux de valeur est une série d’étapes visant à créer et à fournir des produits et des services aux consommateurs. C’est un parcours concret à travers les activités de la chaîne de valeur. Chaque étape repose aussi sur des pratiques qui fournissent des compétences, des informations, des outils et des processus.

Distinguer trois niveaux

Un processus fonctionne souvent au sein d’une pratique et contribue à une partie d’un flux. Une liste de services indique qui participe, mais n’explique pas ce qui se passe entre le déclencheur et le résultat utile.

Établir une cartographie de flux de valeur

1. Nomme le déclencheur : la demande ou l’opportunité qui lance le travail.
2. Énumère les étapes réelles jusqu’à ce que le consommateur reçoive de la valeur.
3. Associe chaque étape à l’activité de la chaîne de valeur qu’elle réalise.
4. Ajoute les principales pratiques dont elle a besoin.
5. Vérifie l’aboutissement avec le consommateur et utilise les résultats pour alimenter l’amélioration.

Retracer un rétablissement

Un utilisateur signale une erreur dans l’application de vente. Le centre de services l’enregistre et l’évalue : impliquer, avec l’appui du centre de services et de la gestion des incidents. Le support applique une solution de contournement connue pour que les ventes puissent reprendre : fournir et soutenir, à l’aide de la gestion des incidents et des connaissances sur la solution de contournement.

Les développeurs recherchent la cause, puis écrivent et testent un correctif définitif : obtenir/construire, en s’appuyant sur la gestion des problèmes et le développement logiciel. Évaluer, autoriser et mettre en service le correctif contribue à concevoir et assurer la transition, à l’aide de l’habilitation des changements et de la gestion des déploiements.

L’équipe informe l’utilisateur et vérifie que l’application fonctionne : impliquer, puis confirmation de fournir et soutenir. Examiner l’évolution des incidents similaires relève d’améliorer. La valeur pour le consommateur est de pouvoir reprendre les ventes. Le rétablissement peut fournir cette valeur avant que le correctif définitif soit terminé.

Les parcours peuvent répéter des activités

Une fonctionnalité d’approbation des notes de frais sur mobile suit un autre parcours : impliquer recueille le besoin ; planifier fixe la priorité et le budget ; concevoir et assurer la transition définit les exigences ; obtenir/construire crée la fonctionnalité ; concevoir et assurer la transition la met en service ; fournir et soutenir la fournit ; impliquer recueille les retours d’information ; améliorer planifie les changements. Répéter impliquer ou concevoir et assurer la transition est normal. Le parcours suit les besoins du travail.

Flux principaux et flux de soutien

Dans la Version 5, un flux de valeur principal fournit de la valeur aux consommateurs externes conformément au modèle opérationnel, par exemple en exécutant les commandes des clients. Un flux de valeur de soutien sert les consommateurs internes et soutient les flux principaux, par exemple en intégrant des employés ou des fournisseurs. Les deux utilisent les mêmes activités. « De soutien » décrit les personnes servies par le flux et ce qu’il soutient ; cela ne signifie pas que le travail est dépourvu de valeur.

La cartographie rend visible la dimension flux de valeur et processus. Elle applique le principe « penser et travailler de façon holistique » en montrant l’ensemble du parcours, y compris les transferts de prise en charge entre des équipes qui n’en voient parfois chacune qu’une partie.

La cartographie des flux de valeur examine et montre la circulation du travail afin que les équipes puissent voir comment la valeur est créée et où apporter des améliorations. La gestion des flux de valeur est le travail continu de gestion et d’amélioration de cette circulation.

Rendre les attentes visibles

Une cartographie de l’état actuel consigne la manière dont le travail se déroule réellement. Inclus les étapes, les personnes, les informations et les éléments transmis entre les étapes, le travail de traitement et l’attente. Une cartographie de l’état futur montre le flux amélioré que l’équipe vise. Consigner uniquement la procédure officielle peut laisser de côté les files d’attente et les saisies répétées qui expliquent l’attente d’un consommateur.

Le délai de traversée est le temps écoulé entre le déclencheur et la fourniture de valeur. Le temps de traitement est le temps consacré au travail sur l’élément. Pour un flux séquentiel dont les périodes de traitement et d’attente ne se chevauchent pas :

Utilise la même unité de temps au numérateur et au dénominateur.

Étudier une demande d’ordinateur portable

Le temps de traitement est de 4 h. L’attente est de 48 h, ce qui donne un délai de traversée de 52 h. L’efficience du flux est d’environ 7,7 %, car seules 4 des 52 heures écoulées sont consacrées au traitement de l’élément.

L’approbation préalable de l’ordinateur portable standard réduit l’attente d’approbation de 16 h à 1 h. Le temps de traitement reste de 4 h ; l’attente passe à 33 h. Le délai de traversée est désormais de 37 h et l’efficience du flux d’environ 10,8 %. La file d’attente restante de 24 h pour l’équipe de préparation est la prochaine piste à étudier.

Réduire de moitié la tâche de configuration de 2 h ne fait gagner que 1 h sur les 52 h initiales, soit environ 1,9 %. Réduire l’attente d’approbation a fait gagner 15 h. Vérifie l’ensemble du flux après un changement : envoyer le travail plus vite vers une autre file d’attente peut laisser le délai de traversée total inchangé.

Adapter l’amélioration au type de travail

La pensée complexe aide à choisir une manière de travailler.

• Le travail ordonné est prévisible. Les demandes d’ordinateurs portables standards peuvent suivre des étapes convenues et être automatisées.
• Dans le travail complexe, les liens de cause à effet deviennent clairs après coup. Développer un produit numérique que l’on connaît mal demande de petites expérimentations et des retours d’information rapides.
• Les situations chaotiques nécessitent d’abord une stabilisation. Lors d’une panne majeure de cause inconnue, rétablis suffisamment de contrôle pour permettre ensuite une analyse utile.

Traiter un travail incertain comme une procédure entièrement connue peut figer une mauvaise solution. Traiter chaque demande courante comme une expérimentation gaspille des efforts. Choisis une approche adaptée à la situation, puis utilise les résultats observés pour l’ajuster.

La gestion des flux de valeur utilise la cartographie et les mesures pour améliorer les pratiques sur lesquelles repose le flux, supprimer les approbations inutiles et les saisies répétées, et réexaminer le parcours lorsque la demande change. Chaque changement proposé peut s’appuyer sur le modèle d’amélioration continue pour établir une base de référence, agir et vérifier les résultats.

La gestion des produits et services numériques consiste à gérer les produits et services qui dépendent de la technologie numérique, de l’idée jusqu’à leur retrait. Un produit numérique est constitué principalement de logiciels, de données et d’une infrastructure numérique, comme une application bancaire mobile. Un service numérique donne aux consommateurs accès aux fonctionnalités des produits, comme les paiements en ligne.

Le cycle de vie de la Version 5

Le cycle de vie ITIL des produits et services nomme huit activités : découvrir, concevoir, acquérir, construire, assurer la transition, exploiter, fournir et soutenir. Les quatre premières servent principalement à créer et à modifier les produits ; les quatre dernières servent principalement à faire fonctionner les produits et à fournir les services qui en découlent. Assurer la transition permet de mettre en service des produits nouveaux ou modifiés.

Du point de vue de l’organisation, ces activités forment la chaîne de valeur de la Version 5. Un flux de valeur les combine aux pratiques de gestion pour répondre à un type particulier de demande. Le cycle de vie décrit le travail nécessaire tout au long de la vie d’un produit ; un flux décrit un parcours particulier à travers ce travail.

Le système de valeur reste le système plus large, avec ses cinq composants. Le cycle de vie ne remplace ni la gouvernance, ni les principes directeurs, ni les pratiques, ni l’amélioration continue.

Utiliser les activités ensemble

Le cycle de vie n’est pas une séquence linéaire unique. La découverte peut se poursuivre pendant que les développeurs construisent une version. Les retours d’information du support peuvent conduire directement à la conception. Un produit dont une version est mise en production toutes les deux semaines peut repasser par la conception, la construction et la transition pendant que le service existant continue de fonctionner et de servir les utilisateurs.

Un conseil municipal lance une application pour signaler les lampadaires en panne. Le support remarque que des signalements arrivent sans indication de lieu. Découvrir en recherche la raison, concevoir ajoute un repère automatique sur une carte, puis construire et assurer la transition le réalisent et le mettent en service. Exploiter et fournir maintiennent l’application existante disponible pendant ce travail. Le produit est concerné par plusieurs activités en même temps.

Relier la Version 5 à ITIL 4

Voici une comparaison générale du travail, et non une équivalence exacte entre les activités.

Les versions regroupent le travail différemment : pour un flux réel, il faut donc examiner la finalité propre de chaque activité. Exploiter maintient la technologie en bon état ; fournir met le service à disposition et répond aux besoins courants des utilisateurs. Ces activités contribuent au même résultat par des travaux différents.

Mesurer les résultats des activités

Parmi les mesures utiles, on trouve les besoins des consommateurs testés qui justifient les éléments de la feuille de route pour découvrir, les taux de réussite des tests automatisés pour construire et les changements déployés sans incident pour assurer la transition. Exploiter peut suivre la disponibilité, fournir peut suivre le délai d’exécution des demandes et la satisfaction des utilisateurs, et soutenir peut suivre le délai de rétablissement.

Ces mesures aident à repérer les points faibles d’un flux. Un taux élevé de réussite des tests pendant la construction peut coexister avec une exécution lente des demandes : la réussite d’une activité ne montre pas si le consommateur reçoit un service utile à temps.

Créer un produit numérique utile signifie comprendre un besoin, élaborer une solution, obtenir des ressources et faire fonctionner la solution. La Version 5 nomme ces travaux découvrir, concevoir, acquérir et construire. Les retours d’information peuvent faire passer le travail d’une activité à l’autre avant qu’un produit complet existe.

Découvrir un besoin auquel il vaut la peine de répondre

Découvrir explore les besoins des consommateurs, les opportunités technologiques et commerciales, ainsi que la stratégie de l’organisation. Cette activité aide à décider quels produits et services proposer ou modifier et maintient la feuille de route alignée sur ces besoins et opportunités. Une feuille de route donne une orientation au développement prévu du produit ; elle doit être révisée lorsque les éléments disponibles changent.

Pour une clinique, une étude montre que les patients souhaitent prendre rendez-vous en ligne. La clinique ajoute cette possibilité à sa feuille de route. La découverte utile est le besoin du patient et le service qui pourrait y répondre, et non simplement la possibilité de construire une nouvelle application.

Concevoir toute la solution

Concevoir transforme les besoins en spécifications et en prototypes. Une spécification du produit décrit les fonctionnalités, les niveaux de qualité et les contraintes requis. Un prototype est une première version simplifiée utilisée pour tester une idée auprès des utilisateurs avant la construction complète.

La spécification de la clinique exige que les patients puissent prendre, déplacer ou annuler un rendez-vous en trois écrans au maximum, utiliser le système en dehors des heures de bureau et recevoir des rappels 24 heures avant une visite. Chaque exigence décrit un comportement ou une qualité par rapport auxquels la solution finale pourra être vérifiée.

Dix patients essaient un prototype cliquable. Quatre ne trouvent pas le bouton d’annulation. L’équipe modifie la conception avant d’écrire le logiciel complet. Un prototype sert à apprendre ; il peut être abandonné après avoir répondu à la question posée. Le considérer comme un logiciel presque terminé peut conduire une équipe à conserver une conception médiocre simplement parce que quelque chose existe déjà.

La conception couvre aussi la manière dont le produit sera exploité et soutenu. La surveillance, les sauvegardes et l’aide aux utilisateurs doivent avoir leur place dans la solution. Découvrir ces besoins après le lancement peut imposer des changements plus coûteux. Cela applique le principe « penser et travailler de façon holistique » à toute la vie du produit.

Acquérir des ressources

Acquérir consiste à obtenir ou à affecter les ressources nécessaires à la solution. Cela comprend la capacité cloud, les licences, les appareils, les données et les personnes possédant les compétences adaptées. Les ressources peuvent provenir de fournisseurs ou de l’organisation elle-même. Réutiliser un composant existant ou affecter un spécialiste interne relève aussi de l’acquisition.

La clinique passe un contrat avec un fournisseur de SMS pour les rappels. Elle affecte aussi du personnel interne au support du système de réservation. L’achat est une façon d’acquérir des ressources ; il ne résume pas toute l’activité.

Construire et vérifier la solution fonctionnelle

Construire consiste à développer, intégrer et tester les composants pour transformer la conception en une solution fonctionnelle. Un test vérifie si un composant ou un produit répond aux exigences et fonctionne comme prévu. Tester la fonctionnalité de rappel comprend la vérification du moment d’envoi spécifié, et pas seulement la confirmation qu’un message peut être envoyé.

Avec l’intégration continue, les développeurs fusionnent fréquemment leurs modifications dans une base de code partagée, et des constructions et des tests automatisés vérifient ces modifications. Cela fournit rapidement des retours d’information sur les échecs d’intégration et les défauts que les tests peuvent détecter. La réussite de ces tests ne prouve pas que tous les défauts ont été trouvés ; le résultat dépend de ce qui a été testé.

La clinique peut réviser sa conception après le test d’un prototype, acquérir une autre ressource après un test pendant la construction ou découvrir un nouveau besoin pendant la construction du produit.

Un produit numérique fonctionnel doit être mis en service, rester en bon état et fournir un service utile. Les utilisateurs ont aussi besoin d’aide lorsque le service tombe en panne. La Version 5 répartit ce travail entre assurer la transition, exploiter, fournir et soutenir.

Assurer la transition vers la mise en service

Assurer la transition met en service des produits et services nouveaux ou modifiés, notamment par la mise en production, le déploiement et l’intégration ou la sortie des fournisseurs. Le déploiement transfère des composants dans un environnement. La mise en production rend une version ou un ensemble de composants disponible pour utilisation. Un logiciel peut être installé en production avec une fonctionnalité désactivée : le déploiement et la mise en production n’ont donc pas nécessairement lieu en même temps.

La livraison continue maintient les changements testés prêts à être déployés, une personne décidant du moment. Le déploiement continu transfère chaque changement qui réussit les tests automatisés dans l’environnement de production sans décision manuelle. Aucun de ces deux termes ne signifie que les utilisateurs reçoivent nécessairement une nouvelle fonctionnalité à chaque transfert de composants.

Exploiter une technologie fiable

Exploiter consiste à faire fonctionner, maintenir et surveiller les produits conformément aux performances et à la fiabilité convenues. La fiabilité est la capacité à assurer les fonctions requises comme prévu dans le temps. L’observabilité est la capacité à comprendre l’état interne d’un système à partir de sorties comme les journaux, les indicateurs et les traces. L’ingénierie de la fiabilité des sites (SRE) applique le génie logiciel aux opérations, notamment par l’automatisation et des objectifs de fiabilité mesurables.

Un événement est un changement d’état important pour la gestion d’un service ou d’un élément de configuration. La fin d’une sauvegarde est un événement ; l’utilisation d’un disque qui atteint 90 % en est un autre. Beaucoup d’événements nécessitent uniquement un enregistrement. D’autres avertissent qu’une intervention pourrait empêcher un incident.

Pour un service de réservation disponible 99,9 % d’un mois complet de 30 jours, la durée totale est de 43 200 minutes. L’indisponibilité autorisée est de 0,1 % de cette durée, soit 43,2 minutes. Avec 43 minutes d’indisponibilité, la disponibilité est d’environ 99,90 %, ce qui permet tout juste d’atteindre l’objectif. Compare les valeurs non arrondies avant de décider si un résultat proche respecte une cible.

Fournir les actions de service courantes

Fournir consiste à fournir les services au quotidien, à intégrer les utilisateurs et à gérer leur sortie, à exécuter les demandes et à recueillir les retours d’information. Une demande de service sollicite une action de service normale et convenue, comme l’accès à un dossier partagé ou un nouvel ordinateur portable. L’utilisateur autorisé ou son représentant formule la demande.

Soutenir lorsque le service rencontre une défaillance

Soutenir consiste à rétablir le fonctionnement normal et à réduire les défaillances futures par la résolution des incidents, le rétablissement après sinistre et la gestion des problèmes. Un incident est une interruption non planifiée ou une réduction de la qualité. Un sinistre cause une perte ou des dommages graves, comme un incendie qui détruit un centre de données.

Un problème est une cause réelle ou potentielle d’incidents. Une erreur est un défaut ou une vulnérabilité susceptible de les provoquer. Une erreur connue est un problème analysé qui reste non résolu.

Supposons que 30 personnes ne puissent plus imprimer après une mise à jour défectueuse du pilote. Les défaillances de leur service sont des incidents. La mise à jour défectueuse est le problème ; une fois analysé mais toujours non résolu, le problème est une erreur connue. Revenir à la version précédente du pilote peut rétablir l’impression en attendant le correctif définitif. Le rétablissement ne signifie donc pas que la cause a été éliminée.

« J’ai besoin d’accéder au dossier des ventes » est une demande. « Le dossier des ventes ne s’ouvre pas » signale un incident. Détermine si l’utilisateur demande une action normale ou le rétablissement de quelque chose qui ne fonctionne plus.

Une pratique est un ensemble de ressources organisationnelles conçu pour effectuer un travail ou atteindre un objectif. La Version 5 l’appelle une pratique de gestion. Une pratique couvre les quatre dimensions, notamment les personnes et les compétences, l’information et la technologie, les partenaires et les fournisseurs, ainsi que les flux de valeur et les processus.

Une pratique est plus large qu’un processus ou qu’un service. La gestion des incidents peut comprendre des processus d’enregistrement et de diagnostic, une base de connaissances, des outils de surveillance et des personnes issues d’un centre de services, d’une équipe réseau et d’un fournisseur. Ensemble, ces ressources créent la capacité de rétablir le service.

Deux façons de regrouper les 34 pratiques

La Version 5 conserve les noms des 34 pratiques. La gestion des déploiements, la gestion de l’infrastructure et des plateformes, et le développement et la gestion des logiciels passent du groupe technique à la gestion des produits et services. La gestion de la sécurité de l’information et la gestion financière des services rejoignent aussi ce groupe, en quittant la gestion générale.

Pratiques de gestion générale de la Version 5

Les 12 pratiques sont la gestion de l’architecture ; l’amélioration continue ; la gestion des connaissances ; la mesure et le reporting ; la conduite du changement organisationnel ; la gestion des portefeuilles ; la gestion de projet ; la gestion des relations ; la gestion des risques ; la gestion de la stratégie ; la gestion des fournisseurs ; et la gestion des effectifs et des talents.

Ces capacités soutiennent la gestion de l’organisation. Par exemple, la mesure et le reporting fournissent des informations fiables pour les décisions d’amélioration. L’amélioration continue aide à maintenir les pratiques et les services alignés sur l’évolution des besoins.

Pratiques de gestion des produits et services de la Version 5

Les 22 pratiques sont la gestion de la disponibilité ; l’analyse métier ; la gestion de la capacité et des performances ; l’habilitation des changements ; la gestion des déploiements ; la gestion des incidents ; la gestion de la sécurité de l’information ; la gestion de l’infrastructure et des plateformes ; la gestion des actifs informatiques ; la surveillance et la gestion des événements ; la gestion des problèmes ; la gestion des mises en production ; la gestion du catalogue de services ; la gestion des configurations des services ; la gestion de la continuité des services ; la conception des services ; le centre de services ; la gestion financière des services ; la gestion des niveaux de service ; la gestion des demandes de service ; la validation et les tests des services ; et le développement et la gestion des logiciels.

Relier les capacités à un flux

Une demande d’ordinateur portable fait appel à la gestion des demandes de service pour traiter l’action convenue, à la gestion des actifs informatiques pour suivre l’appareil, à la gestion des déploiements pour installer les logiciels et au centre de services pour contacter l’utilisateur. Une seule activité de la chaîne de valeur peut avoir besoin de toutes ces pratiques. Le centre de services peut aussi contribuer à plusieurs activités en recevant la demande, en tenant les utilisateurs informés et en recueillant leurs retours d’information.

Ne transforme pas systématiquement chaque pratique en équipe distincte. Les organisations adoptent et adaptent ce dont elles ont besoin, combinent les ressources lorsque c’est utile et développent progressivement les capacités. Une petite organisation peut s’appuyer sur les mêmes personnes pour plusieurs pratiques tout en gardant claire la finalité de chacune.

Utiliser les guides de pratique comme point de départ

Les guides de pratique officiels décrivent les pratiques. Les guides ITIL 4 couvrent la finalité, les termes clés, le périmètre, les facteurs de succès et les quatre dimensions, y compris les processus et les flux de valeur auxquels les pratiques contribuent. Ils fournissent un langage commun et un point de départ à adapter. Suivre les principes « commencer là où tu es » et « rester simple et pratique » signifie adapter ces recommandations au travail réel de l’organisation.

Lorsque les utilisateurs contactent un fournisseur, plusieurs pratiques peuvent contribuer. Leurs finalités aident à distinguer le contact, les demandes courantes, le rétablissement, la recherche des causes et les accords sur la qualité de service.

Contact, rétablissement et causes

Le centre de services peut utiliser le téléphone, la messagerie instantanée, un portail, le courrier électronique ou l’accueil sur place. Il est le point de contact, tandis que la gestion des incidents fournit la capacité de rétablissement. D’autres équipes techniques et fournisseurs peuvent effectuer une grande partie de ce rétablissement.

La gestion des incidents peut rétablir le service au moyen d’une solution de contournement avant que la cause soit connue. La gestion des problèmes peut se poursuivre après le rétablissement ou rechercher une faiblesse avant qu’un incident ne se produise. Les incidents répétés fournissent des éléments utiles, mais leur répétition n’est pas nécessaire pour qu’un problème existe.

Une réinitialisation prédéfinie de mot de passe par un portail est une demande de service. L’impossibilité inattendue pour un utilisateur d’accéder à un service en fonctionnement peut être un incident. Examine le besoin et l’action de service convenue, pas seulement le mot « mot de passe ».

Convenir de la qualité et entretenir les relations

La gestion des niveaux de service établit des objectifs de service clairs fondés sur les besoins métier, puis évalue, surveille et gère la fourniture au regard de ces objectifs. Un accord de niveau de service (SLA) documente les services requis et le niveau de service attendu convenus entre le fournisseur et le client. Un objectif de délai de réponse est utile lorsqu’il reflète les besoins du travail du client.

La gestion des relations développe les relations avec les parties prenantes aux niveaux stratégique et tactique. Elle aide à comprendre les besoins et l’impact métier au-delà d’un contact au sujet d’une panne particulière. Discuter de l’effet d’un service de mauvaise qualité avec un directeur de service peut éclairer les priorités futures.

La surveillance et la gestion des événements observent les services et leurs composants, puis enregistrent et signalent certains changements d’état importants. Une alerte liée à un seuil fournit une information qui peut déclencher une recherche ou une action ; cette pratique ne remplace pas le travail de rétablissement d’un service en panne.

Suivre un ralentissement du système de paie

Le jour de la paie, la surveillance déclenche une alerte indiquant que le délai de réponse du système de paie a dépassé son seuil. Le centre de services reçoit les appels des utilisateurs. La gestion des incidents ajoute de la capacité serveur pour rétablir une vitesse normale. La gestion des problèmes identifie ensuite un index de base de données défectueux comme cause.

La gestion des niveaux de service informe le client que l’objectif de délai de réponse n’a pas été respecté. La gestion des relations discute de son impact métier avec le directeur financier. Chaque contribution a une finalité différente, même si le même responsable participe à plusieurs discussions.

Si les utilisateurs peuvent reprendre le travail après l’ajout de capacité, l’incident peut prendre fin alors que le problème reste ouvert. Garder cette distinction visible évite qu’un rétablissement réussi masque des causes non résolues susceptibles d’avoir un effet sur la prochaine paie.

Une nouvelle fonctionnalité de service demande plus qu’une installation. Les risques doivent être évalués, les utilisateurs doivent y avoir accès au bon moment et l’organisation a besoin d’informations fiables sur les composants, les coûts et les fournisseurs. Ces contributions proviennent de différentes pratiques.

Introduire des changements réussis

L’habilitation des changements vise à maximiser le nombre de changements réussis des produits et services grâce à l’évaluation des risques, à l’autorisation et à la gestion du calendrier des changements. Un changement ajoute, modifie ou supprime tout élément susceptible d’avoir un effet direct ou indirect sur les services. L’ouvrage ITIL 4 Foundation d’origine appelait cette pratique contrôle des changements.

L’objectif est de réussir les changements, et non de tenir le plus grand nombre possible de réunions d’approbation. Les changements standards peu risqués peuvent être préautorisés. L’autorité et l’évaluation sont adaptées au risque et au contexte du changement.

Une fonctionnalité peut être déployée tout en restant désactivée. Sa mise en production ultérieure la rend disponible aux utilisateurs. Cette distinction explique pourquoi « installation réussie » ne signifie pas toujours « les utilisateurs peuvent l’utiliser ».

Connaître les composants et leur valeur

La gestion des configurations des services fournit des informations exactes et fiables sur les services et les éléments de configuration qui les soutiennent, quand et où elles sont nécessaires. Un élément de configuration (CI) est un composant qui doit être géré pour fournir un service informatique. Les informations de configuration comprennent les paramètres et les relations, par exemple l’application qui dépend de telle base de données.

La gestion des actifs informatiques planifie et gère l’intégralité du cycle de vie des composants informatiques ayant une valeur financière. Elle soutient la gestion de la valeur, des coûts et des risques, les achats, la réutilisation, le retrait et le respect des exigences réglementaires ou contractuelles. Un actif informatique peut être un ordinateur portable ou une licence logicielle.

Un même ordinateur portable peut être à la fois un actif et un élément de configuration. La perspective des actifs s’intéresse à sa valeur et à son cycle de vie ; celle de la configuration examine comment il est configuré et relié aux autres éléments pour fournir le service. Tenir un enregistrement exact ne supprime pas le besoin de l’autre perspective.

Protéger l’information et gérer les performances des fournisseurs

La gestion de la sécurité de l’information protège les informations nécessaires à l’activité. La confidentialité limite l’accès aux personnes autorisées ; l’intégrité garantit que les informations sont exactes et complètes ; la disponibilité permet de les utiliser en cas de besoin.

La gestion des fournisseurs gère les fournisseurs et leurs performances afin qu’ils soutiennent la fourniture fluide de produits et services de qualité. L’amélioration continue aligne les produits, les services, les pratiques et les autres éléments de gestion sur l’évolution des besoins métier grâce à une amélioration permanente.

Déployer un logiciel d’accès à distance

Pour 1 500 employés, l’habilitation des changements évalue le risque et planifie le déploiement. La gestion des déploiements installe le logiciel sur des appareils de test, puis sur les ordinateurs portables des employés. La gestion des mises en production permet son utilisation par vagues.

La gestion des configurations des services enregistre les versions présentes sur les appareils et leurs relations. La gestion des actifs informatiques suit les licences. La gestion de la sécurité de l’information vérifie les paramètres de chiffrement, et la gestion des fournisseurs veille à ce que l’éditeur respecte son contrat de support. L’amélioration continue peut utiliser les résultats du déploiement pour améliorer le prochain changement. Le flux réussit grâce à ces capacités combinées ; aucune pratique ne fournit à elle seule toutes les contributions.

L’amélioration continue est un travail récurrent mené à tous les niveaux pour que les performances continuent de répondre aux attentes des parties prenantes. Elle est un composant du système de valeur, une activité de la chaîne de valeur d’ITIL 4 appelée améliorer et une pratique. Tous partagent la responsabilité de repérer et de soutenir les améliorations.

Le modèle d’amélioration continue fournit sept étapes liées entre elles. Il peut guider un petit changement dans une équipe, un flux de valeur ou une transformation à l’échelle de l’organisation. Un changement important nécessite généralement plusieurs itérations plus courtes.

Que faire à chaque étape

La Version 5 conserve sept étapes, mais appelle l’étape 6 « Sommes-nous en train d’atteindre notre objectif ? » et l’étape 7 « Comment faire en sorte que les améliorations restent pertinentes ? » Ces formulations mettent l’accent sur les progrès en cours et l’utilité durable des améliorations.

Suivre une amélioration du centre de services

Vision : les employés doivent pouvoir travailler sans longues interruptions. Situation actuelle : le centre résout 1 392 contacts mensuels sur 2 400 dès le premier contact. En divisant les résolutions par les contacts, on obtient une base de référence de 58 %.

Situation souhaitée : atteindre 70 % en six mois. Avec le volume de la base de référence, cela représenterait 1 680 contacts résolus au premier contact. La cible est la proportion : le nombre nécessaire changera donc si le volume change.

Plan : constituer une base de connaissances pour les 20 solutions les plus courantes, par itérations mensuelles. Action : publier les articles et former les agents à leur utilisation.

Vérification : après six mois, 1 620 contacts sur 2 500 sont résolus au premier contact. Le résultat est de 64,8 % : supérieur à 58 %, mais inférieur à 70 %. Le centre s’est amélioré, mais n’a pas atteint la cible. Au nouveau volume, 70 % nécessiteraient 1 750 résolutions au premier contact.

Poursuite : partager les résultats, tenir les articles à jour et examiner l’écart restant. Les retours d’information peuvent amener l’équipe à revenir à l’étape 4 pour modifier le plan, ou à l’étape 3 si la cible doit être révisée. Une cible non atteinte est une information utile pour la décision suivante.

Garder le point de départ visible

Sauter la base de référence supprime la comparaison nécessaire pour juger du changement. Un résultat de 64,8 % montre ici un progrès parce que l’équipe a mesuré 58 % avant d’agir. Commencer par « acheter un nouvel outil » revient aussi à brûler les étapes : cela consiste à choisir une solution avant de convenir du résultat et de la cible.

Les principes directeurs soutiennent les étapes. « Privilégier la valeur » guide la vision ; « commencer là où tu es » guide la base de référence ; « progresser par itération avec des retours d’information » guide la planification, l’action et la vérification. « Collaborer et promouvoir la visibilité » implique les personnes concernées et rend les progrès visibles tout au long du processus.

Un indicateur est une mesure ou un calcul suivi ou communiqué pour la gestion et l’amélioration. Un indicateur clé de performance (KPI) est un indicateur important utilisé pour juger des progrès vers un objectif. Un facteur clé de succès énonce une condition nécessaire à l’obtention des résultats visés.

Relier l’objectif aux éléments de preuve

Pars de l’objectif, identifie les facteurs clés de succès nécessaires pour l’atteindre, puis choisis pour chacun deux ou trois indicateurs clés de performance fiables. Enregistre une base de référence avant d’agir, fixe chaque cible et sa date, puis communique les résultats aux personnes qui décident des prochaines actions.

Pour le facteur clé de succès « les utilisateurs peuvent résoudre les problèmes courants sans attendre un agent », les indicateurs clés de performance utiles comprennent la part des problèmes courants résolus en libre-service et la part des réinitialisations de mots de passe effectuées en libre-service. Le taux de résolution au premier contact ne mesure pas la même chose : un agent peut résoudre un problème lors d’un contact ; cet indicateur ne montre donc pas si les utilisateurs l’ont résolu de manière autonome.

Un indicateur devient un indicateur clé de performance par son lien avec l’objectif. Tous les nombres disponibles ne méritent pas la même attention. La mesure et le reporting, une pratique de gestion générale, fournissent des données fiables pour appuyer ces décisions.

Choisir le bon dénominateur

Les résolutions au premier contact du centre de services sont passées de 1 392 à 1 620, soit une hausse de 228. Cependant, les contacts sont aussi passés de 2 400 à 2 500. Les proportions sont :

Le changement est de 6,8 points de pourcentage. Communiquer à la fois le nombre et le pourcentage permet de distinguer la charge de travail de la part traitée avec succès au premier contact. Pour atteindre 70 % au nouveau volume, il faut 1 750 résolutions.

Utilise un pourcentage lorsque l’objectif porte sur une proportion. Les nombres, les durées et les coûts sont aussi des formes valables d’indicateurs clés de performance lorsque l’objectif porte sur eux. Par exemple, un objectif de réduction d’une attente nécessite une mesure de temps.

Mesurer les résultats et les effets involontaires

Le « nombre d’articles de la base de connaissances publiés » mesure un livrable. La part des contacts résolus au premier contact et la satisfaction des utilisateurs sont plus proches du résultat auquel les personnes accordent de la valeur. Publier 200 articles que personne n’utilise permettrait d’atteindre un nombre de production sans aider les utilisateurs.

Combine les mesures de résultat ou de valeur avec des mesures de rapidité et de coût. Une cible unique peut encourager un comportement qui améliore le chiffre tout en nuisant au service. Si les agents sont jugés uniquement sur le taux de résolution au premier contact, ils peuvent clôturer les contacts trop tôt. Suivre la part des incidents rouverts dans les sept jours aide à révéler cet effet.

Garder les idées et les responsabilités visibles

Un registre d’amélioration continue (CIR) est un document structuré ou une base de données qui suit les idées d’amélioration jusqu’à leur réalisation ou leur rejet. Les entrées comprennent une description, un responsable, une priorité, le bénéfice attendu et l’état d’avancement. Un registre partagé évite les efforts en double et aide à comparer les bénéfices potentiels pour décider de l’ordre des actions.

La gouvernance surveille les performances au regard de la stratégie. Les responsables sont chargés d’améliorer les pratiques et les flux de valeur. Chaque membre d’une équipe peut proposer une idée dans le registre. Désigner un responsable clarifie les responsabilités tout en permettant aux idées de venir de toute l’organisation.