Mesure et amélioration¶
Évaluer la performance du change management avec les métriques DORA, conduire les post-implémentation reviews et construire une boucle d'amélioration continue.
Métriques DORA¶
Les DORA metrics (DevOps Research and Assessment) sont les quatre indicateurs les plus valides scientifiquement pour mesurer la performance des livraisons. Deux d'entre eux concernent directement le change management.
Change Failure Rate (CFR)¶
Le taux d'échec des changements mesure la proportion de deployments qui necessitent un rollback, un hotfix ou causent un incident.
| Performance | CFR | Interpretation |
|---|---|---|
| Elite | < 5 % | Processus mature, changements bien prepares |
| Haute | 5-10 % | Processus solide avec quelques lacunes |
| Moyenne | 10-15 % | Des améliorations processus sont nécessaires |
| Faible | > 15 % | Process insuffisant ou contourne fréquemment |
Lead Time for Changes¶
Le lead time mesure le temps ecoule entre le premier commit d'un changement et son déploiement en production.
| Performance | Lead Time | Interpretation |
|---|---|---|
| Elite | < 1 heure | Déploiement continu, pipeline très automatise |
| Haute | 1 jour - 1 semaine | CI/CD mature, process lean |
| Moyenne | 1 semaine - 1 mois | Processus manuel significant |
| Faible | > 1 mois | Cycles de release longs, friction importante |
Métriques vanity vs métriques actionnables
Le nombre de tickets de change créés, le taux d'approbation du CAB, la durée moyenne des fenêtres de maintenance — ces métriques sont faciles a produire et impressionnantes dans un reporting, mais elles mesurent l'activité du process, pas sa valeur. Les métriques DORA mesurent l'impact sur la production : est-ce que les changements causent des incidents ? Est-ce qu'ils arrivent en production rapidement ? Ce sont ces questions qui importent.
Post-Implémentation Review (PIR)¶
La Post-Implémentation Review est une analyse structurée effectuee après un changement significatif — réussi ou ayant nécessité un rollback. Elle n'est pas un debriefing de blame mais une opportunité d'apprentissage.
Quand faire une PIR¶
| Situation | PIR obligatoire |
|---|---|
| Changement ayant cause un incident | Oui |
| Rollback exécuté | Oui |
| Dépassement significatif de la fenêtre prévue | Recommande |
| Changement majeur réussi (migration datacenter, etc.) | Recommande |
| Changement standard nominal | Non |
Template de PIR¶
| Section | Contenu |
|---|---|
| Contexte | Description du changement, date, équipe, périmètre |
| Déroulement | Ce qui s'est passe, ecarts par rapport au plan |
| Impact | Utilisateurs, services, données affectes (si incident) |
| Causes | Ce qui a permis (ou cause) ce résultat |
| Actions | Actions correctives identifiées, responsable, deadline |
| Métriques | Durée réelle vs estimée, services impactes, incidents générés |
La PIR doit être terminee dans les 72 heures qui suivent le changement. Au-delà, les détails sont perdus et les actions ne sont pas prises.
Tableau de bord change management¶
Un tableau de bord centralise donne une vision continue de la sante du processus. Il doit être consulte au moins hebdomadairement par le Change Manager.
| Métrique | Fréquence | Alarme si |
|---|---|---|
| Change Failure Rate | Hebdomadaire | > 10 % sur 4 semaines glissantes |
| Changements sans RFC | Hebdomadaire | > 0 (shadow changes) |
| Fenêtres depassees | Par changement | Dépassement > 25 % de la durée prévue |
| Rollbacks exécutés | Par changement | Tout rollback = PIR obligatoire |
| Lead time moyen | Mensuel | Tendance à la hausse |
| PIR en retard | Hebdomadaire | Toute PIR > 72h après le changement |
Boucle d'amélioration PDCA¶
Le change management n'est pas un processus statique — il s'amélioré en continu via le cycle PDCA (Plan-Do-Check-Act).
graph LR
A["PLAN<br/>Definir le process,<br/>les criteres et les KPIs"] --> B["DO<br/>Executer les changements<br/>selon le process"]
B --> C["CHECK<br/>Mesurer CFR, lead time,<br/>PIR, incidents causes"]
C --> D["ACT<br/>Identifier les ecarts,<br/>ajuster le process"]
D --> AApplications concrètes¶
| Observation | Action PDCA |
|---|---|
| CFR > 15 % plusieurs semaines | Analyser les PIR : cause commune ? Manque de tests ? Rollback mal préparé ? |
| Lead time en hausse | Le CAB est-il un goulot ? Les approbations peuvent-elles être simplifiées ? |
| Shadow changes fréquents | Le process est trop lent ou trop complexe — le simplifier pour les changements standards |
| Rollbacks systematiques sur un type de changement | Ce type doit-il passer en changement normal avec procédure renforcee ? |
Intégration aux métriques SRE¶
Le change management s'intégré aux pratiques SRE via les error budgets. Un change failure rate élevé consomme du budget d'erreur — ce qui peut déclencher un gel automatique des changements non critiques jusqu'à ce que le budget soit reconstitue.
Cette intégration permet de lier la gouvernance du change à la réalité opérationnelle : ce n'est plus "le process dit non" mais "notre budget d'erreur ne permet pas ce risque supplémentaire".
Outils¶
| Outil | Description | Lien |
|---|---|---|
| DORA DevOps Quick Check | Auto-évaluation des métriques DORA | dora.dev |
| Grafana | Tableaux de bord avec datasources multiples | grafana.com |
| Four Keys (Google) | Implémentation open source des métriques DORA | github.com/dora-team/fourkeys |
| Sleuth | DORA metrics automatiques depuis le pipeline | sleuth.io |