Processus de changement¶
Structurer le cycle de vie d'un changement — de la demande à la clôture — pour garantir traceabilite et reducation du risque.
Workflow type¶
Un processus de changement bien défini couvre sept étapes. Chaque étape a un livrable clair et un responsable identifié.
graph LR
A["Demande<br/>(RFC)"] --> B["Evaluation<br/>risque/impact"]
B --> C["Approbation<br/>(CAB / peer)"]
C --> D["Planification<br/>fenetre + rollback"]
D --> E["Execution<br/>change window"]
E --> F["Verification<br/>smoke tests"]
F --> G["Cloture<br/>+ enregistrement"]Contenu d'une RFC (Request For Change)¶
Une RFC n'est pas un formulaire bureaucratique — c'est la mémoire du changement. Elle doit contenir :
- description du changement et justification
- périmètre : services, systèmes et utilisateurs impactes
- évaluation du risque et plan de mitigation
- procédure d'exécution pas a pas
- procédure de rollback
- critères de succès et de go/no-go
- fenêtre de maintenance proposee
Évaluation du risque¶
L'évaluation du risque permet de classer le changement et de choisir le niveau d'approbation adequat. La matrice impact x probabilite est l'outil le plus utilisé.
| Probabilite faible | Probabilite moyenne | Probabilite élevée | |
|---|---|---|---|
| Impact fort | Risque modere | Risque élevé | Risque critique |
| Impact moyen | Risque faible | Risque modere | Risque élevé |
| Impact faible | Risque minimal | Risque faible | Risque modere |
Scoring pratique¶
Pour objectiver l'évaluation, certaines organisations utilisent un score numérique :
| Critère | Score 1 | Score 2 | Score 3 |
|---|---|---|---|
| Services impactes | 1 service isole | 2-5 services | > 5 services ou critique |
| Réversibilité | Rollback < 5 min | Rollback 5-30 min | Rollback > 30 min ou impossible |
| Procédure | Runbook valide et teste | Runbook non teste | Pas de runbook |
| Historique | Exécuté plusieurs fois | Exécuté 1 fois | Jamais exécuté |
Un score total de 4-5 = changement standard. 6-8 = changement normal. 9-12 = changement a risque élevé, escalade obligatoire.
Approbation¶
Le niveau d'approbation dépend du type et du score de risque.
| Type de changement | Approbateur | Délai typique |
|---|---|---|
| Standard (pre-approuve) | Aucun — exécution directe | Immédiat |
| Normal faible risque | Peer review (lead ou pair technique) | 24-48h |
| Normal moyen risque | Change Manager | 48-72h |
| Normal fort risque | CAB (Change Advisory Board) | 1 semaine |
| Urgent | ECAB ou manager de permanence | < 2h |
Le pre-approved change — automatiser l'approbation standard
Les changements standards repetitifs (rotation de clés, renouvellement de certificats, mise à jour de paquets de sécurité) peuvent être pre-approuves une fois pour toutes via une RFC générique. L'exécution ultérieure ne requiert qu'un enregistrement. Cela réduit la charge du CAB et accéléré les opérations courantes sans sacrifier la traceabilite.
Le CAB — Change Advisory Board¶
Le CAB n'est pas une instance de contrôle mais un forum de coordination. Son rôle est de :
- identifier les conflits de planification entre changements
- s'assurer que les changements a fort impact sont communiques aux parties prenantes
- valider que les procédures de rollback sont realistes
- capitaliser sur les retours d'expérience
Un CAB efficace se reunit régulièrement (hebdomadaire pour la plupart des organisations) et traite les demandes en moins de 30 minutes.
Rôles et responsabilités¶
| Rôle | Responsabilité |
|---|---|
| Change Owner | Porte la RFC, s'assure de l'exécution et de la clôture. Généralement le tech lead ou l'ingénieur auteur du changement |
| Change Manager | Orchestre le processus, valide la qualité des RFC, anime le CAB |
| CAB Member | Expert métier ou technique qui évalué l'impact sur son périmètre |
| ECAB | Sous-ensemble réduit du CAB disponible pour les urgences (Change Manager + responsable technique de permanence) |
| Approbateur technique | Peer reviewer qui valide la procédure et le rollback avant exécution |
Clôture et enregistrement¶
La clôture est souvent negligee mais elle est critique pour la traceabilite et l'amélioration continue.
La RFC doit être clôturée avec :
- statut final : succès, succès partiel, échec avec rollback, échec sans rollback
- ecarts par rapport à la procédure prévue
- durée réelle vs durée estimée
- incidents ou alertes declenches pendant la fenêtre
- link vers le PIR si applicable
Ne pas clore une RFC sans vérification post-changement
Clore une RFC immédiatement après l'exécution technique, sans smoke tests ni vérification des métriques, c'est prendre le risque de masquer un problème qui se manifestera quelques heures plus tard — souvent en dehors des heures ouvrables.
Outils¶
| Outil | Description | Lien |
|---|---|---|
| ServiceNow Change Management | Module dédié avec workflow CAB intégré | servicenow.com |
| Jira Service Management | Workflows configurables, approbations natives | atlassian.com |
| OpsLevel | Catalogage de services et change tracking pour équipes platform | opslevel.com |
| Backstage | Developer portal open source avec plugin de change management | backstage.io |