Chapitre 611 minDébutant
Gestion des changements, configurations et retour arrière
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- classer un changement : standard, normal ou urgent ;
- rédiger une demande de changement avec son analyse de risque ;
- écrire un plan de retour arrière testable ;
- expliquer à quoi servent la CMDB et les éléments de configuration.
3 exercices corrigés
La gestion des changements est la pratique ITIL qui fait aboutir les modifications du système d'information (mise à jour, nouvelle règle de pare-feu, migration de serveur) tout en maîtrisant les risques : on évalue chaque changement, on le fait autoriser, on le planifie et on prépare un plan de retour arrière en cas d'échec. Elle s'appuie sur la gestion des configurations, qui dit de quoi chaque service est fait. Ce chapitre présente les types de changements, la demande de changement, le retour arrière et la CMDB.
Pourquoi encadrer les changements
Une grande partie des incidents suit un changement : une mise à jour qui casse un pilote, une règle de pare-feu trop stricte, un serveur redémarré au mauvais moment. Encadrer les changements ne sert pas à les ralentir, mais à répondre à quatre questions avant d'agir :
- Qu'est-ce qui peut casser ? (les éléments et les services touchés)
- Quand le faire ? (le moment où la gêne sera la plus faible)
- Comment vérifier que ça a marché ? (les tests après le changement)
- Comment revenir en arrière si ça échoue ? (le plan de retour arrière)
Dans ITIL 4, la pratique s'appelle change enablement : faciliter les changements utiles, pas les bloquer. Plus un changement est courant et maîtrisé, plus son circuit est léger.
Trois types de changements
| Type | Définition | Autorisation | Exemples chez Cèdre Habitat |
|---|---|---|---|
| Standard | Changement courant, à faible risque, décrit par une procédure éprouvée | Pré-autorisé une fois pour toutes : on l'exécute sans nouvelle validation, mais on le trace | Installer un logiciel du catalogue, ajouter un utilisateur à un groupe, remplacer un poste par un poste du même modèle |
| Normal | Changement qui doit être évalué et autorisé au cas par cas | Par l'autorité de changement prévue : le responsable, un comité, un pair selon le risque | Migrer le serveur de fichiers, mettre à jour le logiciel de gestion locative, modifier l'architecture du réseau |
| Urgent | Changement à faire au plus vite, pour résoudre un incident majeur ou corriger une faille critique | Circuit accéléré, par une autorité réduite et joignable vite ; documentation complétée après coup si nécessaire | Appliquer un correctif de sécurité exploité activement, remplacer un commutateur en panne par un autre configuré différemment |
L'autorité de changement est la personne ou le groupe qui autorise un changement. Pour les changements à fort risque, c'est souvent un comité consultatif des changements (change advisory board, CAB), qui réunit la DSI, les référents des services touchés et parfois les fournisseurs. ITIL 4 recommande de ne pas tout faire remonter au comité : plus la décision est proche de l'équipe qui connaît le sujet, plus elle est rapide.
La demande de changement
Un changement normal commence par une demande de changement (request for change, RFC). Dans GLPI, elle se crée par Assistance > Changements, et peut être liée aux tickets et aux problèmes qui l'ont motivée. Ses rubriques :
| Rubrique | Contenu |
|---|---|
| Description et justification | Ce qu'on change, et pourquoi (problème à corriger, évolution demandée, fin de support d'une version) |
| Éléments touchés | Serveurs, applications, services, utilisateurs concernés |
| Analyse d'impact et de risque | Ce qui peut mal tourner, la probabilité, la gravité, la durée d'interruption prévue |
| Plan de mise en œuvre | Les étapes, dans l'ordre, avec qui fait quoi |
| Plan de tests | Comment vérifier que le changement a réussi, du point de vue technique et utilisateur |
| Plan de retour arrière | Comment revenir à l'état précédent, et à partir de quand on le déclenche |
| Planification | La date, la fenêtre de maintenance, la communication aux utilisateurs |
Le cycle d'un changement normal : demande → évaluation → autorisation → planification → mise en œuvre → tests → revue après mise en œuvre (a-t-il atteint son objectif, sans effet de bord ?) → clôture.
Le plan de retour arrière
Le plan de retour arrière (rollback ou backout plan) décrit comment revenir à l'état d'avant si le changement échoue. Sans lui, un échec à 23 h devient une panne le lendemain matin.
Un bon plan de retour arrière a quatre qualités.
- Il est préparé avant : les sauvegardes et les instantanés sont faits et vérifiés avant de commencer.
- Il a un critère de déclenchement : « si les tests ne sont pas tous verts à 22 h 30, on revient en arrière ». Sans heure limite, on s'acharne jusqu'au matin.
- Il est concret : des commandes, des fichiers, des écrans, pas « on restaure si besoin ».
- Il a été testé quand c'est possible, au moins sur une maquette.
Exemple : la mise à jour du logiciel de gestion locative chez Cèdre Habitat, prévue un vendredi soir.
Préparation (avant 20 h). Instantané de la machine virtuelle du serveur d'application ; sauvegarde complète de la base de données, vérifiée par une restauration sur le serveur de test ; copie du dossier de configuration.
Mise en œuvre (20 h - 21 h 30). Arrêt du service, mise à jour par l'installeur de l'éditeur, migration de la base.
Tests (21 h 30 - 22 h 15). Connexion avec trois comptes de profils différents, calcul d'une quittance, export PDF, recherche d'un locataire.
Critère de retour arrière. Un test en échec non corrigé à 22 h 30, ou toute erreur dans la migration de la base.
Retour arrière (45 min). Restauration de l'instantané de la machine virtuelle et de la sauvegarde de la base, redémarrage du service, mêmes tests qu'avant la mise à jour, message aux utilisateurs.
La fenêtre de maintenance et la communication
Une fenêtre de maintenance est un créneau convenu à l'avance où les interruptions sont acceptées : le soir, le week-end, ou un créneau fixé dans le contrat de service. Chez Cèdre Habitat, c'est le jeudi de 19 h à 23 h, sauf la dernière semaine du mois (paiement des loyers).
Les utilisateurs sont prévenus avant (« le logiciel de gestion locative sera indisponible vendredi de 20 h à 23 h »), et informés après (« la mise à jour est terminée ; voici les nouveautés »). Un changement réussi mais mal annoncé génère des dizaines d'appels le lundi.
Pour planifier, l'équipe tient un calendrier des changements : il évite que deux changements risqués tombent le même soir, et qu'un changement soit planifié pendant une période sensible (clôture comptable, paie, campagne de location).
Les configurations et la CMDB
Pour évaluer l'impact d'un changement ou diagnostiquer un incident, il faut savoir de quoi un service est fait. C'est l'objet de la gestion des configurations.
Un élément de configuration (configuration item, CI) est tout composant qu'il faut gérer pour fournir un service : un serveur, une machine virtuelle, un logiciel et sa version, une licence, un contrat, un document de procédure. La base de données de gestion des configurations (configuration management database, CMDB) enregistre ces éléments et leurs relations : le logiciel de gestion locative tourne sur telle machine virtuelle, hébergée sur tel hyperviseur, utilise telle base de données, dépend du lien VPN pour le site de Vénissieux.
| Inventaire du parc | CMDB |
|---|---|
| La liste des équipements et des logiciels, avec leurs caractéristiques | Les éléments et leurs dépendances, vus sous l'angle des services |
| Répond à « qu'avons-nous ? » | Répond à « si cet élément tombe, quel service s'arrête ? » |
| Alimenté par un agent d'inventaire | Alimenté par l'inventaire, complété à la main pour les relations |
GLPI joue les deux rôles pour une organisation comme Cèdre Habitat : l'inventaire automatique remplit le parc, et les liens entre éléments (une application installée sur un serveur, un serveur relié à un contrat) donnent une vue des dépendances. Associer un ticket ou un changement aux éléments concernés, c'est ce qui rend ces liens utiles. La mise en place de l'inventaire est traitée dans le cours GLPI et gestion de parc.
Exercices
Exercice 1 sur 3 Standard, normal ou urgent ? Réussi À revoir
Classe chaque changement et justifie.
- Ajouter une utilisatrice au groupe « Lecture Contentieux », selon la procédure d'habilitation validée par le responsable du service.
- Remplacer le pare-feu du siège par un modèle d'une autre marque.
- Appliquer ce soir le correctif d'une faille du serveur VPN que l'éditeur dit activement exploitée.
- Passer les 180 postes à une nouvelle version majeure du navigateur.
- Remplacer un écran défectueux par un écran identique du stock.
Voir la réponseMasquer la réponse de l'exercice 1
- Standard : courant, à faible risque, décrit par une procédure, l'autorisation est donnée par la validation du responsable prévue dans la procédure.
- Normal : risque élevé (tout le trafic du siège), il faut une évaluation, une autorisation, une fenêtre de maintenance et un retour arrière (remettre l'ancien pare-feu).
- Urgent : une faille activement exploitée justifie le circuit accéléré, avec quand même une sauvegarde de la configuration et un retour arrière.
- Normal : impact potentiel sur toutes les applications Web ; on teste d'abord sur un groupe pilote, puis on déploie par vagues.
- Standard : remplacement à l'identique, procédure connue. Pense à mettre à jour l'inventaire (numéro de série).
Tu avais trouvé ?
Exercice 2 sur 3 Un plan de retour arrière à compléter Réussi À revoir
Thomas prépare ce changement : « Mise à jour du serveur DHCP du siège (machine virtuelle Windows Server) vers la dernière version cumulative, jeudi à 19 h. » Son plan de retour arrière tient en une ligne : « Si problème, restaurer. »
- Quelles questions ce plan laisse-t-il sans réponse ?
- Rédige un plan de retour arrière complet en cinq lignes au plus.
- Quels tests valident la réussite du changement ?
Voir la réponseMasquer la réponse de l'exercice 2
- Restaurer quoi (instantané, sauvegarde, configuration DHCP exportée) ? Quand décider (quel critère, quelle heure limite) ? Qui le fait ? En combien de temps ? Comment vérifier que la restauration a fonctionné ?
- Par exemple : « Avant 19 h : export de la configuration DHCP et des baux, instantané de la machine virtuelle. Critère : un test en échec à 20 h 30. Retour arrière par Thomas : restauration de l'instantané (15 min), vérification que le service DHCP démarre et que l'étendue du siège est active, test de bail sur un poste. Message aux utilisateurs si le retour arrière déborde après 21 h. »
- Le service DHCP démarre ; l'étendue est active ; un poste de test obtient un bail (
ipconfig /releasepuisipconfig /renew) avec la bonne passerelle et les bons serveurs DNS ; les réservations (imprimantes) sont toujours présentes ; aucun avertissement dans le journal du service.
Tu avais trouvé ?
Exercice 3 sur 3 Lire les dépendances Réussi À revoir
La CMDB de Cèdre Habitat indique : le portail locataires tourne sur la machine virtuelle WEB-01 ; WEB-01 et la machine virtuelle BDD-01 (base du portail et du logiciel de gestion locative) sont hébergées sur l'hyperviseur HV-02 ; le logiciel de gestion locative tourne sur APP-01, hébergée sur HV-01.
- On doit redémarrer HV-02 pour une mise à jour. Quels services seront interrompus ?
- Quel type de changement est-ce, et quel moment choisis-tu ?
Voir la réponseMasquer la réponse de l'exercice 3
- Le portail locataires (WEB-01 est sur HV-02) et le logiciel de gestion locative, parce que sa base de données BDD-01 est aussi sur HV-02, même si l'application elle-même tourne sur HV-01. C'est exactement ce que la CMDB permet de voir : l'arrêt de HV-02 touche aussi un service qui n'y est pas hébergé.
- Un changement normal (deux services interrompus), planifié dans la fenêtre de maintenance (jeudi 19 h - 23 h, hors dernière semaine du mois), annoncé aux salariés et aux locataires (bandeau sur le portail), avec un retour arrière (instantanés, procédure de redémarrage dans l'ancienne version).
Tu avais trouvé ?