Dans le chapitre précédent, vous avez acquis le vocabulaire de gestion des changements. Ce vocabulaire normalisé est utilisé dans toutes les entreprises. Si l’un des termes abordés vous paraît flou, n’hésitez surtout pas à relire le chapitre précédent.
Dans ce chapitre, nous allons voir ensemble comment préparer et organiser un changement. Grâce à la règle des 7R, vous apprendrez à définir le périmètre de votre changement et ainsi faire apparaître les risques potentiels. Ensuite, vous apprendrez à catégoriser une RFC pour déterminer la priorité d’un changement. Pour finir, j’aborderai les plans de retour arrière qui constitueront votre assurance de retrouver la situation initiale en cas de pépin.
C'est parti !
Les demandes de changements sont diverses
Le point de départ de tout changement est la RFC. Pour des raisons diverses, tout le monde peut demander un changement. Il peut s’agir d’une demande concernant :
L’installation d’un serveur d’impression pour gérer plus rapidement les impressions ;
Une mise à jour de sécurité pour pallier une faille dans l’OS ;
Une migration vers une infrastructure cloud qui pourrait permettre de faire des économies à long terme ;
L'ajout de CPU/mémoire pour résoudre un incident de production dans lequel le site web de l’entreprise est inaccessible ;
Un widget connecté qui affiche la météo et les dernières informations de la bourse sur le bureau des ordinateurs.
Lesquelles doit-on traiter en premier ? Les retours attendus par l’exécution de ces changements nécessitent-ils un changement ?
Déjà, à bien y regarder, on s’aperçoit que toutes les demandes ne se valent pas. Certaines sont urgentes, d’autres un peu moins, mais présentent un risque réel si elles ne sont pas effectuées dans un certain délai.
La règle des 7R va vous aider à y voir un peu plus clair.
Découvrez la règle des 7R
Comme vous l’avez appris, la RFC est le point de départ de tout changement. L’impact potentiel des changements, les éléments de configuration (et leurs relations) doivent être abordés. Cette évaluation est réalisée dans l’étape d’analyse de la RFC.
La règle des 7R vous aidera à vous poser les questions essentielles lors de l’analyse d’une RFC. Vous pourrez ainsi établir le périmètre de ce changement :
Requis : qui a requis ce changement ?
Raison : quelle est la raison de ce changement ?
Retour : quel est le retour attendu de ce changement ? Quels sont les bénéfices attendus ?
Risque : quels sont les risques encourus à la réalisation ou la non-réalisation de ce changement ?
Ressources : quelles sont les ressources nécessaires pour réaliser ce changement ? De quoi aurons-nous besoin ?
Responsable : qui est responsable de la réalisation de ce changement ?
Relation : quelle relation avec d’autres changements ? Existe-t-il des dépendances ?
Une fois le périmètre du changement établi, il est temps de catégoriser la demande de changement et ainsi faire apparaître les demandes devant être traitées en priorité.
Catégorisez vos changements
Catégoriser un changement consiste à lui affecter une priorité. Dit autrement, il s’agit de lui affecter une importance relative. Pour cela, vous pouvez vous appuyer sur l’évaluation du risque que présente ce changement (souvenez-vous, R comme Risque…), ainsi que la probabilité que ce risque se réalise.
Une autre méthode consiste à déterminer la priorité d’un changement grâce à une matrice prenant en compte l’impact et l’urgence de ce changement :
L’impact représente l’ampleur du périmètre et/ou le nombre d’utilisateurs concernés par ce changement. Il doit être inscrit dans la RFC ;
L’urgence va mesurer le niveau de criticité sur l’activité, l’urgence à mettre en place le changement.
En évaluant l’impact et l’urgence sur 3 niveaux (fort, moyen, faible), vous pourrez ensuite déterminer la priorité du changement, c'est-à-dire un couple urgence–impact.
Vous obtenez 5 niveaux de priorité que vous pourrez affecter aux changements.
Pour rendre le tout plus pratique, je vous ai décrit dans le tableau ci-dessous les priorités en fonction du type de changement (corriger un incident ou déployer/améliorer un nouveau service) :
Priorité | Changement correctif | Changement d'amélioration |
|---|---|---|
P1 – Critique : À traiter comme un changement urgent. | Risque vital causant une perte significative de la qualité de service. Action immédiate requise. | Ne doit pas être utilisé pour ce type de changement. |
P2 – Majeur : La priorité la plus haute pour les actions de déploiement. | Service dégradé avec impact sur un grand nombre d’utilisateurs. | Déployer un patch de sécurité, répondre à une obligation légale, déploiement d’un nouveau service avec une forte valeur ajoutée pour le business, non-respect d’un délai contractuel. |
P3 – Moyen | Impact peu sévère de l’incident sur les utilisateurs. Cas où la correction doit attendre le déploiement d’une nouvelle version, ou d’une mise à jour. | Changement apportant une amélioration dans l’utilisation du service, planifiée avec un délai contractuel. |
P4 – Normal | Changement correctif justifié mais pas nécessaire, car il existe une solution de contournement. Peut attendre la prochaine mise à jour. | Changement apportant une amélioration dans l’utilisation du service, planifiée avec un délai de contractuel moins important que le P3, voire sans délai contractuel. |
P5 – Planifié | Ne doit pas être utilisé pour les changements correctifs. | Tout autre cas non abordé pour les changements d’amélioration. |
Voici quelques exemples de changements associés à leur niveau de priorité :
L’ajout de CPU ou de mémoire pour résoudre un incident de production dans lequel le site web de l’entreprise est inaccessible : urgence Forte (on perd de l’argent si en plus il s’agit d’une boutique en ligne) + impact Fort (tous les clients n’y ont plus accès) = P1–Critique. Changement à réaliser immédiatement.
Une migration vers une infrastructure cloud qui pourrait permettre de faire des économies : urgence Moyenne (l’infrastructure actuelle est fonctionnelle) + impact Fort (on réalise des économies substantielles) = P2–Majeur. Déploiement d’un service à forte valeur ajoutée pour le business.
Un widget connecté qui affiche la météo et les dernières informations de la bourse le bureau des ordinateurs : urgence Faible (franchement on peut encore utiliser le navigateur pour avoir la météo) + impact Faible = P5–Planifié. Ce changement est planifié pour être exécuté mais avec la plus faible priorité.
Planifiez vos changements
De manière générale, vous devrez éviter que vos changements s’interfacent avec d’autres processus de changement (prestataires et fournisseurs externes). Autant que possible, établissez votre planning de changement en fonction des besoins du business, plutôt qu’en fonction des besoins informatiques.
Établissez un calendrier des changements autorisés. Prévoyez toujours une durée approximative de la maintenance.
Établissez un plan de remédiation
Aucun changement ne devrait être mis en œuvre sans au préalable fournir un plan de remédiation. On parle aussi de Backout Plan.
Il s’agit de prévoir un plan de retour dans le cas où le déploiement se passe mal (oui, ça peut arriver !). Idéalement, établissez une solution qui vous permettra de redonner au service sa situation initiale. Restaurez vos sauvegardes du système pour le software, prévoyez du matériel de secours dans le cas du hardware.
Si pour une raison ou une autre vous ne pouvez pas effectuer un retour arrière, déclenchez le plan de continuité d’activité. Mais ça, c’est une tout autre histoire.
En résumé
Organiser les changements consiste à :
Définir les activités à mettre en œuvre dans votre processus de changement ;
Prévoir un processus pour chaque type de changement : Normal, Standard, Urgent ;
Commencer par le changement normal, et simplifier le processus pour obtenir un changement standard, ou changement urgent, sans pour autant supprimer les contrôles et l’analyse des risques liés à ce changement ;
Utiliser la règle des 7R afin d’établir le périmètre du changement : Requis, Raison, Retour, Risques, Ressources, Relation, Responsable ;
En fonction de l’impact et de l’urgence, catégoriser vos changements en leurs affectant des priorités ;
Planifier vos changements, ce qui vous permettra de limiter l’impact sur le service d’un arrêt pour maintenance ;
Enfin, toujours prévoir un plan de retour arrière dans l’éventualité d’un mauvais déroulement.
Dans le chapitre suivant, je vous propose de lister les activités, rôles et responsabilités de votre processus de gestion des changements.
