Pratiques de changement, de mise en production et d’amélioration continue

Une liste de serveurs t’indique quels équipements existent. Pour juger ce qui se passe lorsqu’un serveur change, tu dois aussi savoir ce qui fonctionne sur ce serveur et qui en dépend. La gestion des configurations des services met des informations fiables sur les configurations des services à disposition là où et au moment où les équipes en ont besoin.

Déterminer ce qui nécessite un contrôle des configurations

Un élément de configuration (CI) est un composant qui doit être géré pour fournir un service informatique. Les CI peuvent être des équipements physiques, des machines virtuelles, des bases de données, des applications, des services cloud, des documents ou les services eux-mêmes. L’organisation choisit les composants qui nécessitent ce contrôle. Un accord de niveau de service peut être un CI parce que son contenu convenu compte pour la fourniture du service ; un clavier de rechange peu coûteux ne nécessite généralement pas d’enregistrement de configuration.

Un enregistrement de configuration décrit un CI. Les champs utiles comprennent son identifiant, son type, sa version, son responsable, son emplacement, son statut et ses relations. L’identifiant évite de confondre deux serveurs similaires. La version aide une équipe de déploiement à vérifier si une mise à jour prévue a déjà atteint une cible.

Suivre les dépendances pour évaluer l’impact

Des relations telles que « fonctionne sur », « utilise » et « dépend de » transforment les enregistrements en une cartographie du service. Lis attentivement leur direction : une application qui utilise une base de données dépend de la disponibilité de cette base.

Prenons l’application de commande WEB-ORD. Elle fonctionne sur les serveurs virtuels VS-01 et VS-02 et utilise DB-ORD. Cette base de données fonctionne sur le cluster CL-02. Le reporting mensuel des ventes utilise également DB-ORD.

Pour évaluer une mise à niveau de CL-02 :

1. Trouve la base de données hébergée sur le cluster : DB-ORD.
2. Repère les services qui utilisent cette base : la commande et le reporting des ventes.
3. Consulte les responsables des deux services sur l’impact et choisis un moment en dehors des heures de pointe des commandes.

Consulter uniquement le responsable de CL-02 ferait passer à côté des services métier qui en dépendent. La même cartographie aide le personnel de support à rechercher une défaillance et le personnel de sécurité à localiser les systèmes qui nécessitent un correctif. Les équipes de mise en production et de déploiement utilisent les versions de configuration pour vérifier ce qui est installé dans chaque environnement.

Relier les enregistrements au travail réel

Mets à jour les enregistrements concernés dans le cadre des changements autorisés et des déploiements. Sinon, une cartographie du service correcte devient trompeuse après la mise à niveau suivante. Les vérifications et les audits comparent les enregistrements à l’environnement réel ; la découverte automatique peut aider à trouver les écarts. Examine chaque différence pour déterminer si l’enregistrement est erroné ou si un changement a contourné l’autorisation.

Une configuration de référence est un état de CI approuvé et examiné, utilisé comme référence pour les changements ultérieurs. Elle aide les équipes à comparer un état connu à l’état actuel.

Recueille le niveau de détail nécessaire aux décisions réelles. Enregistrer chaque attribut de chaque appareil crée un travail qui risque de ne pas être maintenu. Un ensemble d’enregistrements utile facilite les vérifications d’impact, le diagnostic et la conformité, avec une responsabilité claire pour les mises à jour. Un inventaire seul ne peut pas montrer ces dépendances.

Les actifs informatiques ont une valeur financière et peuvent contribuer à la fourniture d’un produit ou service informatique. Ils comprennent le matériel, les licences logicielles et les abonnements cloud. La gestion des actifs informatiques gère l’ensemble de leur cycle de vie pour en tirer de la valeur, maîtriser les coûts et les risques, et respecter les exigences contractuelles et réglementaires.

Suivre l’actif tout au long de sa vie

Le cycle de vie commence avant l’achat et se poursuit après la fin de l’utilisation de l’actif :

1. Planifier : définir le besoin et examiner ce qui est déjà disponible.
2. Acquérir : acheter, louer ou souscrire un abonnement.
3. Recevoir et enregistrer : enregistrer l’élément ainsi que son appartenance ou ses conditions d’utilisation.
4. Déployer : l’affecter à un utilisateur ou à un site.
5. Exploiter et entretenir : le réparer, le déplacer, le réaffecter ou le renouveler.
6. Retirer : cesser de l’utiliser activement.
7. Mettre au rebut : effacer les données ou détruire le support de stockage, puis recycler ou restituer le matériel selon le cas.

Mets l’enregistrement à jour à chaque événement. Un inventaire annuel peut vérifier ces mises à jour, mais ne peut pas les remplacer. Si un ordinateur portable change deux fois d’utilisateur entre deux inventaires, l’organisation doit toujours savoir qui le détient actuellement.

Un registre des actifs consigne notamment le numéro d’inventaire, le modèle, le numéro de série, le responsable ou l’utilisateur, l’emplacement, la date et le coût d’achat, la fin de garantie ou de location, les conditions de licence et le statut. Le statut distingue un élément « en stock » d’un élément « en utilisation » ou « retiré ».

Faire correspondre les droits logiciels à l’utilisation

La gestion des actifs logiciels compare les droits détenus aux installations ou utilisations réelles. Acheter trop peu de licences crée un risque de non-conformité ; conserver des licences inutilisées entraîne des dépenses inutiles. Vérifie les conditions de licence avant de réattribuer ou de réduire les abonnements.

Une entreprise paie 500 abonnements à une suite bureautique à 120 € par utilisateur et par an. Elle en a attribué 430, ce qui en laisse 70 inutilisés. Leur coût annuel en euros est de :

Quarante nouveaux employés ont besoin de la suite. Réattribuer 40 abonnements inutilisés évite d’en acheter 40 autres, soit 4 800 € de dépenses annuelles supplémentaires évitées. Trente restent inutilisés ; les supprimer au renouvellement permet d’économiser 3 600 € par an. Ce sont deux bénéfices différents : éviter de nouvelles dépenses et réduire les dépenses existantes.

Les comptes cloud font partie de la même vue financière. Un abonnement non déclaré d’un service peut échapper aussi bien au contrôle des renouvellements qu’à la revue de sécurité. Cette informatique fantôme doit être visible, même en l’absence d’appareil physique à compter.

Distinguer les questions financières et de configuration

Un même outil peut contenir les deux enregistrements, mais leurs finalités diffèrent. La valeur de revente n’est pas le critère qui définit un actif informatique : un abonnement cloud peut avoir une valeur financière sans être revendu.

Le retrait ne suffit pas à achever la mise au rebut. Avant que le matériel ne quitte l’organisation, efface ses données de manière sécurisée ou détruis le support de stockage et enregistre l’action. Confie les déchets électroniques à des recycleurs agréés et rends les appareils loués au bailleur. L’enregistrement de l’actif doit indiquer ce qui est arrivé à l’élément et quand.

Modifier une procédure de support peut affecter un service tout autant que modifier un serveur. Un changement est l’ajout, la modification ou la suppression de tout élément susceptible d’affecter directement ou indirectement les services. Cela comprend les équipements, les applications, les documents, les processus et les accords avec les fournisseurs qui entrent dans le périmètre choisi par l’organisation.

Rendre possibles les changements utiles

L’habilitation des changements vise à maximiser le nombre de changements réussis des services et des produits. Elle s’acquitte pour cela de trois responsabilités liées :

• Évaluer correctement les risques.
• Autoriser la mise en œuvre des changements.
• Gérer le calendrier des changements.

L’objectif est de réussir les changements en assurant une protection adaptée au risque. Les utilisateurs ont besoin d’améliorations et de corrections rapidement. Ils ont aussi besoin que les services existants continuent de fonctionner. Une procédure d’approbation lente pour chaque tâche mineure fait perdre du temps et peut pousser les équipes à la contourner. Laisser chaque équipe modifier les systèmes partagés sans coordination expose les utilisateurs à des défaillances évitables.

Par exemple, remplacer une application peut apporter de nouvelles fonctionnalités, mais aussi interrompre le travail en cours. Supprimer une ancienne base de données est aussi un changement : un autre service peut encore utiliser ses données. Même la modification d’un document entre dans le périmètre lorsqu’elle change la manière dont le personnel fournit le support. La question pertinente est l’effet possible sur les services, et non le fait que quelqu’un écrive ou non du nouveau code.

Juger la réussite au résultat

Un changement réussi est mis en œuvre comme prévu, produit le résultat attendu et ne cause aucun dommage imprévu, tel qu’un incident. « L’installation est terminée » ne répond qu’à une partie de ces critères. Les utilisateurs peuvent toujours être incapables d’accomplir la tâche que le changement devait améliorer.

Supposons que 240 changements aient été mis en œuvre au cours d’un trimestre et que 12 aient échoué ou aient été annulés. Le nombre de changements réussis est de 228. Calcule le taux en utilisant tous les changements mis en œuvre comme dénominateur :

Le taux d’échec de 5 % est le complément du taux de réussite de 95 %. Conserver à la fois le nombre et le taux aide l’équipe à voir l’ampleur du travail. Un taux de réussite élevé doit être examiné en regard de la rapidité avec laquelle les changements créateurs de valeur parviennent aux utilisateurs ; bloquer le travail utile pourrait produire peu d’échecs tout en répondant à peu de besoins.

Reconnaître les noms et les sources des changements

ITIL 4 utilise le nom habilitation des changements, tout comme ITIL (Version 5). Des documents plus anciens peuvent employer « change control » ou « change management ». La conduite du changement organisationnel est une pratique distincte qui concerne l’adoption de nouvelles façons de travailler par les personnes, notamment la communication et la formation.

Les demandes de changement peuvent provenir de corrections de problèmes, d’incidents urgents, de mises à jour de sécurité, de mises à jour des fournisseurs, de nouvelles fonctionnalités ou d’idées d’amélioration. Leur origine ne supprime pas la nécessité de les évaluer, de les autoriser et de les coordonner. Un correctif fournisseur nécessite toujours un parcours de changement adapté ; une petite amélioration de processus nécessite toujours une attention à son effet sur les utilisateurs.

Les organisations définissent le périmètre et les circuits de décision adaptés à leurs services. Un parcours utile rend visible la décision prise par le responsable, donne suffisamment d’informations pour juger le risque et permet à l’équipe d’effectuer le travail à un moment approprié.

Le parcours d’un changement dépend de la manière dont il est évalué et autorisé. Sa seule ampleur technique ne détermine pas s’il est standard, normal ou urgent. Une modification d’une ligne sur un routeur peut présenter un risque plus élevé qu’une installation logicielle importante et éprouvée.

Choisir le parcours approprié

Le risque d’une procédure standard est évalué lors de sa création et de sa modification. Sa préautorisation s’applique à cette procédure convenue. Une équipe ne peut pas qualifier de standard une tâche qu’elle ne connaît pas simplement parce qu’elle pense qu’elle sera facile.

Normal ne signifie pas risque moyen. Un changement normal à faible risque peut ne nécessiter qu’une approbation rapide par un pair ou des vérifications automatisées. Un changement normal majeur peut nécessiter l’intervention de la direction. Les modèles de changement définissent ces parcours afin que les équipes sachent quelles informations et quelle autorité chaque type de changement nécessite.

Rédiger une demande de changement exploitable

Un changement normal commence généralement par une demande de changement, également appelée RFC. Donne au décideur les informations nécessaires pour l’évaluer :

• Ce qui changera, pourquoi et le bénéfice attendu.
• Les services et CI concernés, avec le risque et l’impact.
• Les plans de mise en œuvre et de test.
• Un plan de remédiation pour rétablir le service en cas d’échec.
• La date et l’heure proposées.

Pour le déplacement d’une base de données, dire « le nouveau stockage est plus rapide » explique un bénéfice espéré, mais ne permet pas à l’autorité de juger qui pourrait être affecté ni comment l’équipe rétablirait la situation.

Traiter une véritable urgence sans perdre le contrôle

L’évaluation et l’autorisation des changements urgents sont accélérées, souvent par une autorité plus restreinte. Effectue des tests aussi complets que le temps le permet. Une partie de la documentation peut être terminée après coup, mais l’urgence ne transforme pas le travail en changement non autorisé. Une correction non testée peut créer un nouvel incident.

Le fait qu’un responsable souhaite une fonctionnalité aujourd’hui ne rend pas la demande urgente. Des menaces immédiates pour un service ou pour la sécurité justifient la procédure accélérée. Pour un trimestre comptant 18 changements urgents sur 240 changements, la proportion est de :

Suis cette proportion dans le temps. Des interventions urgentes fréquentes peuvent révéler des problèmes de planification qui méritent d’être corrigés.

Un changement normal répété peut devenir standard après que l’équipe a documenté la procédure éprouvée, évalué son risque et obtenu son approbation. L’application mensuelle de correctifs à des serveurs de test non critiques pourrait remplir ces conditions. La répétition seule apporte de l’expérience, mais pas de préautorisation. Une modification du pare-feu pour un nouveau partenaire reste normale, sauf si une procédure standard approuvée couvre ce type précis de modification.

Une approbation est utile lorsque la personne qui la donne comprend le risque et peut prendre une décision en temps voulu. Une autorité de changement est la personne ou le groupe qui autorise un changement. Désigne l’autorité selon le type et le risque du travail, en confiant les décisions courantes aux personnes les plus proches de sa réalisation.

Évaluer séparément la probabilité et l’impact

La probabilité concerne le risque d’échec : la complexité, les tests et l’expérience de l’équipe comptent. L’impact concerne les conséquences : les services et les utilisateurs affectés, la perte de données, la gravité et le délai de rétablissement. Utilise les relations de configuration pour trouver les services qui partagent le composant modifié.

Une organisation peut multiplier l’impact et la probabilité, chacun étant noté de 1 à 5. Dans cet exemple, elle attribue les scores de 1 à 5 à l’approbation par un pair, de 6 à 12 à un gestionnaire des changements et de 13 à 25 à une autorité de niveau élevé ou à un CAB. Ces seuils sont propres à l’organisation.

Un comité consultatif des changements (CAB) conseille sur les changements importants. Il n’a pas à approuver chaque changement. La revue par les pairs et les vérifications automatisées peuvent fournir des parcours autorisés pour les travaux adaptés à faible risque.

Prévoir le rétablissement avant la mise en œuvre

Chaque changement normal doit disposer d’un plan de remédiation qui indique comment rétablir le service et quand commencer le rétablissement. Le retour arrière, ou annulation, permet de revenir à l’état précédent. Une correction par un nouveau changement corrige la situation ; une autre option consiste à basculer vers un autre service.

Une procédure de rétablissement testée peut réduire les conséquences d’un échec. Un changement sans moyen de rétablissement testé présente un risque plus élevé et justifie une décision à un niveau supérieur. Écrire simplement « revenir en arrière si nécessaire » ne donne à l’équipe ni déclencheur, ni responsable, ni suite d’actions concrètes.

Coordonner le calendrier des changements

Le calendrier facilite la planification, la communication, la vérification des conflits et l’affectation des ressources. Il aide aussi les équipes chargées des incidents et des problèmes à voir les changements récents qui peuvent expliquer une défaillance. Les organisations peuvent définir des périodes de gel, par exemple pendant un traitement de facturation, avec des exceptions pour les changements urgents.

Supposons que le remplacement d’un commutateur et la mise à niveau d’une application soient tous deux prévus le samedi de 22 h à 2 h. Les serveurs de l’application dépendent du commutateur. L’interruption empêcherait de tester l’application et rendrait les défaillances difficiles à localiser. Reporte la mise à niveau de l’application au dimanche à 22 h et informe le centre de services des deux créneaux.

Examiner ce qui s’est réellement passé

Après la mise en œuvre, vérifie l’objectif, les incidents et les effets imprévus avant de clore l’enregistrement. Examine les échecs pour en tirer des enseignements. Les mesures utiles comprennent le taux de réussite, les changements qui provoquent des incidents, la proportion de changements urgents et le délai entre la demande et la mise en œuvre.

Une fonctionnalité peut être installée en production alors que les utilisateurs ne peuvent pas encore y accéder. La gestion des mises en production met à disposition les services et les fonctionnalités nouveaux ou modifiés. Elle planifie la préparation et la communication ainsi que le moment où les utilisateurs obtiennent l’accès.

Définir le contenu de la mise en production

Une mise en production est une version d’un service ou d’un autre CI, ou un ensemble de CI, mis à disposition pour utilisation. Elle peut contenir du code applicatif, de l’infrastructure, de la documentation, des procédures mises à jour, de la formation et des articles de la base de connaissances. Si le personnel de support ne peut pas aider les utilisateurs avec la fonctionnalité, la seule préparation technique laisse une lacune.

La planification de la mise en production définit le périmètre, le calendrier et les critères de préparation. Par exemple, exige que les tests réussissent, que le personnel de support soit informé, que le guide utilisateur soit mis à jour et que le retour arrière soit testé. Ces critères permettent à l’équipe de décider si tout est prêt sur la base de preuves avant d’élargir l’accès.

Les identifiants de version distinguent ce qui est disponible. Selon une convention courante majeure.mineure.correctif, le passage de 4.2.0 à 4.3.0 indique une mise en production mineure de fonctionnalités ; 5.0.0 indique une mise en production majeure. Les équipes conviennent de leur convention de numérotation afin que les notes de version, les enregistrements de support et les versions installées désignent la même chose.

Séparer le déploiement de l’accès

Le déploiement transfère les composants dans un environnement. La mise en production les rend disponibles pour utilisation. Un drapeau de fonctionnalité, ou commutateur, peut laisser le code déployé inactif, puis l’activer pour certains utilisateurs.

Prenons une application bancaire qui ajoute des relevés PDF :

1. Le mardi, déploie la version 3.4 sur les serveurs de production avec la fonctionnalité désactivée. Le code est présent, mais les clients ne peuvent pas utiliser la nouvelle fonctionnalité.
2. Le jeudi, mets-la à disposition de 10 % des utilisateurs. Surveille le taux de plantage par rapport à la limite fixée par l’équipe, soit 0,5 % des sessions.
3. Le taux reste inférieur à cette limite ; le lundi, mets donc la fonctionnalité à disposition de tous les utilisateurs.

La limite de déploiement appartient au plan de mise en production de cette équipe. Ce n’est pas un seuil universel de mise en production. Un accès contrôlé permet d’obtenir des retours d’information avant que la fonctionnalité n’atteigne l’ensemble des utilisateurs.

Adapter la planification au rythme de livraison

La livraison fréquente change l’organisation du travail. Des règles et des vérifications automatisées peuvent faciliter des décisions rapides, tandis qu’une équipe décide toujours qui reçoit quelle fonctionnalité et quand.

Les notes de version expliquent clairement ce qui a changé, ce qui a été corrigé et les problèmes connus. Pour l’application bancaire : « Tu peux télécharger les relevés mensuels au format PDF. Les relevés datant de plus de 24 mois ne sont pas encore disponibles. » Donne ces informations au centre de services avant que les utilisateurs ne commencent à poser des questions.

Après la mise en production, recueille les retours d’information des utilisateurs, les incidents et les données de performance. Transmets les enseignements à l’amélioration continue. Appuyer sur un bouton de déploiement ne réalise pas ce travail de préparation, d’accès, de communication et de revue.

La gestion des déploiements transfère les composants nouveaux ou modifiés dans les environnements de production et peut les transférer dans d’autres environnements pour les tester. Les composants comprennent le matériel, les logiciels, les documents et les processus. La pratique contrôle ce qui atteint chaque cible et vérifie que les composants y fonctionnent.

Savoir où va le composant

Un test réussi en préproduction fournit une preuve en faveur du transfert en production. Après le transfert, des tests fonctionnels rapides et la surveillance permettent de vérifier le résultat réel en production. Mets à jour les enregistrements de configuration pour indiquer la version installée et les relations modifiées.

Choisir une approche adaptée au service

Le déploiement par phases transfère les composants dans une partie de la production à la fois. Il limite l’exposition initiale et permet d’obtenir des retours d’information avant la vague suivante. Une équipe qui met à jour 2 000 ordinateurs portables choisit quatre vagues de 500, en commençant par le personnel informatique capable de décrire clairement les problèmes.

L’équipe fait une pause si des incidents liés au déploiement touchent plus de 2 % des ordinateurs portables d’une vague. Lors de la première vague, les incidents touchent 25 ordinateurs distincts :

Cinq pour cent dépassent la limite fixée par l’équipe : elle fait donc une pause, mène une enquête, corrige la cause et effectue un nouveau test avant la vague 2. Le dénominateur est la vague déployée, et non l’ensemble des 2 000 ordinateurs portables. Compte les appareils touchés, car plusieurs tickets d’incident peuvent concerner le même appareil.

Le déploiement big bang transfère les composants vers toutes les cibles à la fois. Il convient à un basculement net lorsque l’ancienne et la nouvelle version ne peuvent pas coexister. Par exemple, les 120 magasins reçoivent un nouveau logiciel de caisse la même nuit parce que les deux versions ne peuvent pas partager le système central. Un échec pourrait toucher tous les magasins : effectue donc des tests approfondis et répète la procédure de remédiation.

Le déploiement à la demande place les logiciels approuvés dans un dépôt contrôlé afin que les utilisateurs les installent quand ils le souhaitent. Une organisation peut publier une mise à jour d’un logiciel de visioconférence sur son portail de logiciels et fixer une date limite avant que l’ancienne version ne cesse de fonctionner.

La livraison continue intègre, teste et déploie les composants chaque fois que nécessaire, ce qui favorise des retours d’information fréquents. Un transfert automatisé nécessite toujours des sources contrôlées, une autorisation, une validation et des enregistrements à jour.

Contrôler la source et le rétablissement

Conserve les composants prêts à être déployés dans des emplacements sécurisés et contrôlés, tels qu’une bibliothèque définitive ou un dépôt d’artefacts. Les équipes doivent toujours obtenir la version autorisée et testée plutôt que de se fier à une copie locale non vérifiée.

Effectue le déploiement dans le cadre d’un changement autorisé. Prépare un plan de remédiation avant de transférer les composants. Vérifie immédiatement le résultat et réagis si les vérifications échouent. Une version installée peut rester inactive jusqu’à ce que la gestion des mises en production mette sa fonctionnalité à disposition des utilisateurs ; la fin du déploiement ne prouve pas que la mise en production a eu lieu.

Une livraison fait appel à plusieurs pratiques, car chacune résout un problème différent. Leur coordination évite une rupture entre une tâche technique autorisée et une fonctionnalité que les personnes peuvent utiliser efficacement.

Poser la question à laquelle répond chaque pratique

Une même équipe peut assumer ces responsabilités. Elles nécessitent néanmoins des décisions et des enregistrements distincts. Une équipe agile peut combiner revue par les pairs, vérifications automatisées et décisions enregistrées sans soumettre chaque livraison à une réunion.

Suivre la livraison d’une fonctionnalité du portail

Un portail RH permettra aux employés de téléverser leurs justificatifs de frais. La demande de changement décrit le bénéfice, les CI concernés, la mise en œuvre, les tests et le rétablissement. Selon le modèle de risque de l’organisation, un impact de 3 et une probabilité de 2 donnent un score de 6. Le gestionnaire des changements autorise un changement normal pour le mercredi de 20 h à 22 h après avoir vérifié l’absence de conflits concernant le portail.

L’équipe teste la version 2.8 en préproduction, puis la déploie sur les serveurs de production pendant ce créneau. Elle laisse la fonctionnalité de téléversement désactivée. Les enregistrements de configuration indiquent désormais la version 2.8. Tout abonnement ou équipement ajouté nécessite aussi un enregistrement d’actif et un responsable de son cycle de vie.

Le vendredi, la gestion des mises en production met la fonctionnalité à disposition de 150 employés du service financier. Le centre de services dispose au préalable des notes de version et d’un court guide. Une semaine plus tard, l’accès est élargi aux 2 400 employés. L’installation et la disponibilité pour les utilisateurs ont lieu à des dates différentes : si l’on demande si la fonctionnalité est « en production », il faut donc préciser de quel événement on parle.

Examiner les résultats et transmettre les enseignements

Pendant la première semaine, trois personnes demandent comment utiliser la fonctionnalité de téléversement. Le service fonctionne normalement : ce sont des demandes de conseil, et non des incidents. La revue vérifie que les justificatifs peuvent être téléversés comme prévu et ne constate aucune interruption ni dégradation. Le changement peut être clos comme réussi, avec une idée d’amélioration consistant à ajouter une indication dans l’application.

Une mise en production peut nécessiter plusieurs déploiements, par exemple des vagues vers différentes cibles. Un déploiement peut contenir plusieurs fonctionnalités mises à disposition à des moments différents à l’aide de drapeaux. Il n’existe pas de correspondance obligatoire terme à terme entre un changement, un déploiement et une mise en production.

Relier le travail à la fourniture de valeur

Dans ITIL 4, ces pratiques contribuent particulièrement aux activités « concevoir et assurer la transition », « obtenir/construire » et « fournir et soutenir ». ITIL (Version 5) décrit huit activités du cycle de vie des produits et services : découvrir, concevoir, acquérir, construire, assurer la transition, exploiter, fournir et soutenir. La construction et la transition jouent un rôle central dans la préparation et l’introduction des composants modifiés. La livraison nécessite toujours des preuves que le résultat attendu du service est parvenu aux utilisateurs.

La gestion de la sécurité de l’information protège les informations dont une organisation a besoin pour travailler en comprenant et en gérant les risques. Elle s’applique aux personnes, aux procédures, aux fournisseurs et aux technologies qui traitent ces informations. L’équipe de sécurité coordonne le travail spécialisé, mais chacun a un rôle à jouer.

Identifier ce qui doit être protégé

Les trois premières forment souvent la triade CID : confidentialité, intégrité et disponibilité. Un service peut protéger la confidentialité tout en manquant de disponibilité si les utilisateurs ne peuvent pas y accéder. L’authentification vérifie l’identité d’une personne ; elle ne détermine pas à elle seule ce à quoi cette personne peut accéder. La non-répudiation concerne la preuve d’une action, au-delà de la connexion.

Équilibrer prévention, détection et correction

La prévention réduit la probabilité d’incidents. Elle comprend notamment l’application de correctifs, les contrôles d’accès, les pare-feu et les formations de sensibilisation. La détection repère les incidents qui surviennent malgré tout, à l’aide de la surveillance, des alertes et de l’examen des journaux. La correction limite les dommages et rétablit le fonctionnement normal, à l’aide de l’isolement, du rétablissement et des corrections.

Pour un rançongiciel, une approche équilibrée intervient à ces différentes étapes :

1. Applique rapidement les correctifs, filtre les courriels malveillants, impose une authentification multifacteur et donne aux comptes les seuls accès nécessaires.
2. Déclenche une alerte lorsqu’un logiciel commence à chiffrer de nombreux fichiers de façon inattendue.
3. Isole les ordinateurs infectés, restaure les données à partir de sauvegardes hors ligne, puis trouve et corrige le point d’entrée.

Les sauvegardes facilitent le rétablissement ; elles ne remplacent pas les mesures qui empêchent les attaques ou les détectent tôt. Choisis les mesures en proportion de la valeur des informations, des menaces et des vulnérabilités. Des mesures qui compliquent inutilement le travail courant peuvent encourager des solutions de contournement non officielles.

Intégrer la sécurité aux pratiques courantes

Une politique de sécurité, des rôles définis et des formations régulières orientent les comportements quotidiens. Supprime les accès d’une personne qui quitte l’organisation le dernier jour où elle travaille. ISO/IEC 27001 fixe les exigences applicables à un système de management de la sécurité de l’information ; les organisations peuvent demander une certification selon cette norme.

Les informations de configuration aident à localiser les systèmes concernés : une bibliothèque vulnérable présente sur 37 serveurs sur 400 permet d’identifier les cibles du correctif. Les correctifs courants suivent les parcours de changement standard ou normal. Une menace active nécessitant une action immédiate suit une évaluation et une autorisation urgentes. La gestion des actifs sécurise les données avant la mise au rebut, tandis que la gestion des fournisseurs définit les exigences de sécurité et contrôle les accès des fournisseurs.

Le travail d’un fournisseur fait partie du service dont bénéficient les clients. La gestion des fournisseurs gère les fournisseurs, les relations, les accords et les performances afin que les produits et services de qualité s’articulent sans difficulté. Les fournisseurs peuvent être des entreprises externes ou des services internes.

Choisir comment se procurer le travail

Ces stratégies décrivent différents aspects du sourcing : une organisation peut externaliser auprès d’un seul partenaire ou de plusieurs fournisseurs. Choisis en fonction de la culture, de la rareté des compétences, de l’expertise, du coût total, des contraintes externes et de la prévisibilité de la demande. Le prix proposé le plus bas peut masquer un effort de coordination ou une qualité de service insuffisante.

Rendre les attentes mesurables

Maintiens une visibilité sur les fournisseurs, la stratégie, les politiques et les informations contractuelles. Conviens des objectifs de service, des délais de réponse, des exigences de sécurité et relatives aux données, des comptes rendus, des prix et des compensations telles que les crédits de service. Prévois le traitement des litiges et les dispositions de sortie, en particulier la restitution des données.

Les contrats marquent le début d’une gestion continue. Suis les performances, examine les relations et planifie les renouvellements et les sorties. Un fournisseur cloud stratégique nécessite une planification conjointe et des revues régulières ; un fournisseur de câbles peut généralement être géré au moyen de conditions d’achat standard.

Vérifier les performances par rapport à l’accord

Supposons qu’un contrat d’hébergement promette une disponibilité de 99,9 % sur un mois entier de 30 jours. La période de mesure comprend :

La durée d’indisponibilité autorisée est de 0,1 % de cette période, soit 43,2 minutes. La durée réelle d’indisponibilité est de 95 minutes. La disponibilité est de :

L’objectif n’a pas été atteint. Applique le crédit de service prévu au contrat et conviens d’un plan d’amélioration lors de la revue fournisseur. Un écart apparemment faible entre des pourcentages peut tout de même représenter une durée d’indisponibilité supplémentaire importante. Utilise la période de mesure et les règles contractuelles convenues pour évaluer les performances.

Conserver la responsabilité et gérer la dépendance

L’organisation reste comptable du service auprès de ses propres clients même lorsqu’un fournisseur en assure une partie. Un crédit accordé par le fournisseur répond à un accord ; il ne rétablit pas le travail interrompu d’un client. Les équipes ont aussi besoin d’une réponse coordonnée et d’actions d’amélioration.

De bonnes relations favorisent des comptes rendus honnêtes et des résultats communs. Gère le verrouillage propriétaire, c’est-à-dire la difficulté à quitter un fournisseur, grâce à des données portables et à un plan de sortie testé. Avec plusieurs fournisseurs, clarifie les responsabilités et les transferts de prise en charge afin qu’une défaillance soit résolue à l’échelle du service au lieu d’être renvoyée d’un contrat à l’autre.

Les besoins en matière de services évoluent avec les utilisateurs, les technologies et les organisations. L’amélioration continue maintient les services et les pratiques en adéquation avec ces besoins grâce à l’amélioration permanente des produits, des services, des pratiques et de leur gestion. Un formulaire plus clair peut compter autant pour une équipe qu’une nouvelle plateforme pour l’organisation.

Donner aux idées quotidiennes un chemin vers l’action

L’amélioration est l’affaire de tous. Une équipe dédiée peut coordonner le travail, accompagner les personnes et suivre les résultats. Les dirigeants fournissent du temps et un budget. Les personnes qui effectuent le travail repèrent les difficultés et testent de meilleures façons de les traiter.

Les activités d’amélioration consistent à trouver les opportunités, les enregistrer, les évaluer et définir leur priorité, établir des dossiers d’opportunité, planifier et réaliser les actions, puis évaluer les résultats. La coordination aide les équipes à éviter les efforts concurrents ou les changements qui déplacent un problème ailleurs.

Les idées peuvent provenir des tendances observées dans les incidents et les problèmes, des retours d’information des clients, des enquêtes de satisfaction, des suggestions du personnel, des audits, des nouvelles technologies, des revues fournisseurs et des revues de changements ou de mises en production. Une équipe de support qui remarque des incompréhensions répétées après les mises en production dispose d’éléments utiles pour l’amélioration, même sans interruption majeure.

Tenir un registre d’amélioration continue

Un registre d’amélioration continue (CIR) est un document structuré ou une base de données qui suit les idées de leur identification jusqu’à l’action finale. Enregistre l’idée, sa source, le bénéfice attendu, l’effort estimé, la priorité, le responsable et le statut. Désigner un responsable permet de confier à une personne la prochaine décision concernant une idée utile.

Une organisation peut tenir des registres au niveau des équipes et de l’organisation. L’essentiel est de gérer les idées pendant leur évaluation et leur mise en œuvre. Une longue liste sans responsables ni mise à jour des statuts aide peu à choisir la suite.

Comparer le bénéfice et l’effort

Une équipe note le bénéfice et l’effort de 1 à 10 et utilise le bénéfice par unité d’effort comme aide à la priorisation :

Selon cet indicateur, commence par C, puis A, puis B. Le bénéfice total le plus élevé n’est pas la même chose que le bénéfice par unité d’effort le plus élevé. Conserve B dans le registre afin de pouvoir réexaminer sa valeur et ses besoins en ressources. Un rapport aide à comparer les travaux ; la priorisation nécessite toujours de tenir compte des objectifs et des contraintes de l’organisation.

Relier l’amélioration au système de services

ITIL 4 place l’amélioration continue dans le système de valeur des services, dans l’activité « améliorer » de la chaîne de valeur et dans les pratiques de gestion. ITIL (Version 5) la conserve dans le système de valeur ITIL et comme pratique.

L’amélioration intègre au travail quotidien les principes « commencer là où tu es », « privilégier la valeur » et « progresser par itération avec des retours d’information ». Commence par des éléments attestant le problème actuel, choisis une action produisant un résultat utile et utilise les retours d’information pour décider de l’action suivante. De petites étapes fréquentes réalisées par les personnes qui effectuent le travail ont leur place aux côtés des initiatives plus importantes.

Acheter un outil ou réécrire une procédure est une action. Pour établir qu’il y a amélioration, relie cette action à un résultat nécessaire et mesure ce qui a changé. Le modèle d’amélioration continue fournit sept étapes pour ce travail, à toute échelle.

Fixer la direction et comprendre le point de départ

1. Quelle est la vision ? Relie le travail aux objectifs de l’organisation et explique le bénéfice dont les parties prenantes ont besoin.
2. Où en sommes-nous maintenant ? Évalue objectivement l’état actuel et établis une base de référence pour la comparaison.
3. Où voulons-nous aller ? Compare l’état actuel à l’état souhaité et fixe des cibles précises, mesurables et assorties d’un délai.

Une vision telle que « les utilisateurs peuvent reprendre rapidement leur travail » donne une direction. Une cible telle que « atteindre 70 % de résolution au premier contact dans les six mois » rend une partie de cette direction mesurable. « Un support plus rapide » ne définit à lui seul ni résultat ni échéance.

Une base de référence enregistre l’état de départ. Utilise une définition claire de la mesure pour que le résultat ultérieur puisse être comparé de façon pertinente. Compter des types de sollicitations différents pendant les deux périodes peut rendre un changement apparent difficile à interpréter.

Planifier, agir, vérifier et pérenniser

4. Comment y parvenir ? Choisis un plan en utilisant des itérations lorsque le meilleur parcours est incertain.
5. Passer à l’action. Mets le plan en œuvre tout en surveillant les risques et les effets secondaires.
6. Y sommes-nous parvenus ? Mesure à nouveau et compare le résultat à la base de référence et à la cible. Ajuste les étapes précédentes si nécessaire.
7. Comment maintenir la dynamique ? Partage les résultats, ancre la meilleure façon de travailler et poursuis l’amélioration.

Ces questions forment une boucle. Elles n’obligent pas à attendre la fin d’un grand projet pour tirer des enseignements des retours d’information. Une itération infructueuse peut montrer ce qu’il faut changer ensuite.

Suivre une amélioration du centre de services

Un centre de services résout 696 de ses 1 200 sollicitations mensuelles au premier contact. Sa base de référence est de :

L’équipe fixe une cible de 70 % dans les six mois. Elle prévoit de meilleurs articles de la base de connaissances et des outils d’accès à distance, puis les met en place. Après trois mois, 736 sollicitations sur 1 150 sont résolues au premier contact :

Compare les taux, car le nombre total de sollicitations a changé. Soixante-quatre pour cent est supérieur à la base de référence, mais inférieur à la cible. Reviens à la planification, examine les types de sollicitations encore transmis à d’autres et ajoute une formation ciblée. Il y a des progrès, mais l’équipe ne peut pas déclarer que la cible est atteinte.

Après avoir obtenu un résultat utile, maintiens la responsabilité des articles, forme les nouveaux employés et partage les preuves du résultat. Cela aide le service à éviter un retour en arrière lorsque l’équipe chargée de l’amélioration initiale passe à autre chose.

Reconnaître la formulation de la version 5

ITIL (Version 5) conserve sept étapes. L’étape 6 demande « Sommes-nous en bonne voie ? » et l’étape 7 « Comment préserver la pertinence des améliorations ? ». Cette formulation met l’accent sur la vérification continue des progrès et de la pertinence des améliorations. La base de référence, la cible, l’action et les retours d’information restent essentiels à l’utilisation du modèle.

Une mesure utile montre si le service accomplit ce dont les personnes ont besoin. Compter uniquement l’activité peut donner l’impression qu’une équipe très occupée réussit alors que ses utilisateurs restent insatisfaits. Choisis des mesures qui relient le travail aux résultats attendus.

Relier les conditions de réussite aux indicateurs

Un facteur clé de succès est une condition qui doit être remplie pour atteindre le résultat attendu. Un indicateur clé de performance (KPI) mesure si un facteur clé de succès est satisfait. Pour le facteur clé de succès « les problèmes des utilisateurs sont résolus rapidement », les indicateurs clés de performance possibles comprennent le taux de résolution au premier contact et le délai moyen de résolution d’un incident.

Équilibre les indicateurs afin qu’une cible ne récompense pas un comportement nuisible. Si les agents sont jugés uniquement sur le délai de résolution, clôturer les tickets trop tôt améliore les chiffres en apparence. Associe cette mesure au taux de réouverture et aux retours d’information des utilisateurs pour vérifier si les problèmes ont réellement été résolus.

Lorsque les rapports techniques sont au vert mais que l’expérience des utilisateurs est mauvaise, ce décalage est parfois appelé effet pastèque. Les mesures de satisfaction et de réclamations aident à révéler ce que les indicateurs techniques ne montrent pas.

Comparer correctement les pourcentages

Une hausse de 58 % à 64 % représente 6 points de pourcentage. La hausse relative compare cet écart au taux de départ :

Précise la comparaison dont tu parles. Présenter ce changement comme une « amélioration de 6 % » confond l’écart en points avec le changement relatif. Utilise des populations, des définitions de mesure et des périodes cohérentes pour comparer les résultats.

Pour regrouper des groupes, additionne leurs nombres de réussites et leurs effectifs totaux avant de calculer le taux global. Un canal web résout 90 sollicitations sur 150 et un canal téléphonique en résout 20 sur 50. Ensemble, ils en résolvent 110 sur 200, soit 55 %. Calculer la moyenne à poids égal de leurs taux de 60 % et 40 % donnerait 50 %, mais le groupe web compte trois fois plus de sollicitations.

Choisir une technique adaptée à la question

Une échelle de maturité peut aller de 1, initial, à 5, optimisé ; utilise l’échelle définie par l’évaluation. Une meilleure note pour une pratique et un meilleur résultat pour les clients sont des mesures différentes qui nécessitent chacune leurs propres preuves.

Un changement normal prend 6 jours entre la demande et la mise en œuvre. Cinq jours sont consacrés à l’attente d’une réunion d’approbation hebdomadaire. L’attente représente :

Le lean attire l’attention sur cette attente. Une procédure adaptée d’approbation par les pairs pour les travaux à faible risque peut réduire le délai tout en maintenant l’autorisation. Accélérer une courte tâche de mise en œuvre laisserait intacte la plus grande partie du délai de traversée.

L’agilité favorise les petits incréments et les retours d’information fréquents. DevOps relie le développement et l’exploitation grâce à l’automatisation pour assurer une livraison rapide et sûre. Les deux conviennent à l’amélioration itérative. Lorsqu’une amélioration modifie un service, un outil ou un processus, fais-la passer par l’habilitation des changements et, si nécessaire, par le déploiement et la mise en production. Mesure son effet par rapport à la base de référence.