Fondamentaux du change management¶

Comprendre pourquoi les changements non contrôles provoquent des incidents — et comment une taxonomie claire réduit le risque.

Pourquoi le change management¶

Les changements sont la première cause d'incidents en production. Les études ITIL et les postmortems de grands opérateurs convergent : 70 a 80 % des incidents sont causes par un changement — déploiement, reconfiguration, mise à jour de dépendance, modification réseau.

Sans process de changement :

• un déploiement effectue un vendredi soir sans backup provoquer une panne le week-end
• une mise à jour de librairie casse silencieusement une API consommee par dix équipes
• un changement de configuration effectue "juste pour tester" reste en production indéfiniment

Le change management ne ralentit pas les équipes — il réduit le temps perdû à gérer les incidents causes par des changements non contrôles.

Le coût réel d'un incident non maîtrise¶

Taxonomie des changements¶

ITIL v4 distingue trois types de changements. Chaque type a un workflow adapté a son niveau de risque.

Critères de classification¶

La bonne question a se poser pour classer un changement :

• Fréquence : ce changement a-t-il déjà été exécuté avec succès plusieurs fois ?
• Impact : combien de services, d'utilisateurs ou de données sont affectes ?
• Réversibilité : peut-on revenir en arriere facilement en moins de 15 minutes ?
• Procédure : existe-t-il une runbook validee et testée pour ce changement ?

Un changement standard répond OUI aux quatre critères. Un changement normal répond NON a au moins un. Un changement urgent s'impose par les circonstances.

ITIL v4 simplifie — Change Enablement¶

ITIL v4 remplacé l'ancien "Change Management" par la pratique Change Enablement, centree sur la valeur et la vitesse plutôt que sur la conformité formelle.

graph TD
    A["Demande de changement<br/>(RFC)"] --> B["Evaluation du risque<br/>et de l'impact"]
    B --> C{Type}
    C -->|Standard| D["Execution directe<br/>+ enregistrement"]
    C -->|Normal| E["CAB / Peer review<br/>+ planification"]
    C -->|Urgent| F["Approbation acceleree<br/>(ECAB ou manager)"]
    E --> G["Execution planifiee"]
    F --> G
    G --> H["Verification<br/>post-changement"]
    H --> I["Cloture<br/>+ PIR si necessaire"]

Ce que ITIL v4 change par rapport à ITIL v3¶

ITIL v3 privilegiait le contrôle strict via le CAB. ITIL v4 reconnait que des changements standard bien définis n'ont pas besoin de passer par un comite — cela crée de la friction sans valeur ajoutee. Le CAB reste pertinent pour les changements a fort impact, mais doit être un accelerateur et non un point de blocage.

Change vs Release vs Deploy¶

Ces trois termes sont souvent confondus. Leur distinction est fondamentale pour structurer un process clair.

Un deploy peut contenir plusieurs releases, chacune regroupant plusieurs changes. Comprendre cette hiérarchie permet de savoir à quel niveau appliquer la gouvernance.

Shadow changes¶

Outils¶