Gestion des changements

Un changement est toute modification de l'infrastructure IT : installation, mise à jour, configuration, retrait. La gestion des changements vise à minimiser les risques liés à ces modifications.

Pourquoi gérer les changements ?

• Prévenir les incidents : De nombreux incidents sont causés par des changements mal planifiés
• Traçabilité : Savoir qui a modifié quoi et quand
• Coordination : Éviter les conflits entre changements simultanés
• Communication : Informer les utilisateurs des maintenances

Exemples de changements

• Mise à jour d'un serveur
• Déploiement d'une nouvelle application
• Modification de règles firewall
• Remplacement d'un équipement réseau
• Migration de base de données

KaliaOps distingue 3 types de changements selon le niveau de risque et le processus d'approbation :

Changement Standard

Changement pré-approuvé, à faible risque, suivant une procédure établie.

• Approbation : Automatique (pré-approuvé)
• Exemples : Reset mot de passe, ajout utilisateur, installation logiciel standard
• Processus : Exécution directe sans CAB

Changement Normal

Changement nécessitant une évaluation et approbation par le CAB.

• Approbation : CAB (Change Advisory Board)
• Exemples : Mise à jour serveur, modification réseau, nouveau déploiement
• Processus : Analyse d'impact, soumission CAB, planification

Changement Emergency

Changement urgent nécessitant une procédure accélérée.

• Approbation : ECAB (Emergency CAB) ou approbation manager
• Exemples : Patch de sécurité critique, correction incident majeur
• Processus : Fast-track avec documentation a posteriori

Le workflow de gestion des changements comporte 11 statuts :

Diagramme

BROUILLON → SOUMIS → EN ATTENTE APPROBATION → APPROUVÉ → PLANIFIÉ → EN COURS → TERMINÉ → CLÔTURÉ
                            ↓                                         ↓
                         REJETÉ                                     ÉCHOUÉ
                            ↓
                        ANNULÉ

Description des statuts

Le CAB (Change Advisory Board) est l'instance d'approbation des changements normaux.

Composition du CAB

Typiquement :

• Responsable des changements (Change Manager)
• Représentants techniques (Infrastructure, Applications)
• Représentants métier (si impact utilisateur)
• Responsable sécurité (si applicable)

Soumettre au CAB

1. Depuis un changement en brouillon, cliquez sur « Soumettre »
2. Le changement passe en statut « Soumis »
3. Cliquez sur « Demander approbation CAB »
4. Indiquez la date de réunion CAB souhaitée

Décisions CAB

Le CAB peut décider :

• Approved : Changement approuvé, peut être planifié
• Rejected : Changement rejeté (avec motif)
• Deferred : Report, informations complémentaires requises

Traçabilité CAB

Chaque décision CAB est enregistrée avec :

• Date de la décision
• Décision prise
• Notes et commentaires
• Utilisateur ayant enregistré la décision

Fenêtre de maintenance

Après approbation, définissez la fenêtre d'implémentation :

1. Cliquez sur « Planifier »
2. Définissez :
   • Date/heure de début planifiée
   • Date/heure de fin planifiée
3. Le changement passe en statut « Planifié »

Bonnes pratiques de planification

• Évitez les heures de pointe : Préférez les créneaux à faible utilisation
• Coordonnez les changements : Évitez les conflits avec d'autres maintenances
• Prévoyez une marge : Le temps réel dépasse souvent le temps prévu
• Communiquez : Informez les utilisateurs impactés

Calendrier des changements

Le calendrier affiche tous les changements planifiés, permettant de :

• Visualiser les fenêtres de maintenance
• Identifier les conflits potentiels
• Planifier les ressources

Le plan de rollback décrit la procédure de retour arrière en cas d'échec.

Contenu du plan de rollback

• Conditions de déclenchement : Quand déclencher le rollback ?
• Procédure détaillée : Étapes pour revenir à l'état initial
• Points de contrôle : Vérifications à chaque étape
• Durée estimée : Temps nécessaire pour le rollback
• Responsable : Qui déclenche et exécute le rollback ?

Exemples de déclencheurs

• Tests post-changement échoués
• Incident majeur détecté
• Temps d'indisponibilité dépassé
• Performances dégradées au-delà du seuil acceptable

Importance du rollback

Un changement sans plan de rollback est un risque non maîtrisé. Les changements à risque élevé ou critique ne doivent jamais être approuvés sans plan de retour arrière documenté et testé.

Démarrer l'implémentation

1. À la date planifiée, cliquez sur « Démarrer »
2. Le changement passe en statut « En cours »
3. La date de début réelle est enregistrée

Pendant l'implémentation

• Suivez le plan d'implémentation étape par étape
• Documentez les écarts éventuels
• Exécutez les tests de validation

Terminer le changement

1. Cliquez sur « Terminer »
2. Rédigez les notes de complétion : résumé de l'implémentation
3. Confirmez

Le changement passe en statut « Terminé ». La date de fin réelle est enregistrée.

Clôturer

Après une période d'observation (vérification qu'aucun incident n'est survenu) :

1. Cliquez sur « Clôturer »
2. Sélectionnez le code de clôture
3. Le changement est archivé

Déclarer un échec

Si l'implémentation échoue :

1. Exécutez le plan de rollback
2. Cliquez sur « Marquer comme échoué »
3. Documentez la raison de l'échec
4. Le changement passe en statut « Échoué »

Analyse post-mortem

Après un échec, analysez :

• Cause de l'échec : Technique, planification, communication ?
• Efficacité du rollback : A-t-il fonctionné comme prévu ?
• Leçons apprises : Comment éviter cet échec à l'avenir ?

Change Success Rate

Le taux de succès des changements est un indicateur clé :

CSR = (Changements réussis / Total changements) × 100

Objectif : > 95%

Un CSR faible indique des problèmes de processus ou de préparation.

KaliaOps détecte automatiquement les corrélations entre changements et incidents.

Corrélation automatique

Le système identifie les incidents survenus peu après un changement :

• Incidents dans les X minutes suivant un changement
• Incidents sur les mêmes assets/applications que le changement

Table de corrélation

Chaque corrélation enregistre :

• Changement et Incident liés
• Délai entre le changement et l'incident
• Force de corrélation : Faible, Moyenne, Forte
• Assets/Applications communs
• Confirmation : Corrélation confirmée ou non

Utilisation

• Investigation incident : « Y a-t-il eu un changement récent ? »
• Analyse des changements : « Ce changement a-t-il causé des incidents ? »
• Amélioration continue : Identifier les types de changements à risque

Confirmer une corrélation

Lors de l'investigation d'un incident :

1. Consultez les corrélations suggérées
2. Si le changement est la cause, confirmez la corrélation
3. Documentez pour l'analyse post-mortem