Fiche RFC — Demande de changement (ITIL) : Modèle Word

Le document qui crédibilise la transformation et sécurise l’exploitation

Dans une DSI mature, la « Request for Change » (RFC) ne sert ni de cache-misère, ni de sésame bureaucratique. C’est une pièce maîtresse de la gouvernance opérationnelle : elle cadre l’intention, objective l’impact, discipline l’exécution et fournit, après coup, la preuve que l’on maîtrise son patrimoine numérique. Une fiche RFC soignée devient alors un contrat de service clair entre métiers, exploitation et sécurité, capable d’absorber l’urgence sans sacrifier la fiabilité.

1) Pourquoi formaliser une RFC ?

Trois raisons dominent :

Traçabilité. Relier chaque modification à un besoin métier, un incident ou une exigence de conformité, avec un fil d’audit complet.
Maîtrise du risque. Forcer l’analyse d’impact (availability, performance, sécurité, continuité) et préparer le filet de sécurité (tests, retour arrière).
Synchronisation. Aligner calendrier de changement, fenêtres de maintenance, astreintes, parties prenantes et dépendances CMDB.

2) Périmètre et typologie ITIL

Changement standard. Pré-autorisé, faiblement risqué, déjà industrialisé (ex. : patch mensuel routinier avec script éprouvé).
Changement normal. Passage par revue (CAB), évaluation de risque et planification.
Changement urgent. Circuit ECAB, critères d’éligibilité serrés, validation a posteriori (PIR rapide obligatoire).

3) Anatomie d’une Fiche RFC v1.0

Ce socle vise l’efficacité : suffisamment structuré pour protéger l’exploitation, assez léger pour ne pas décourager les équipes.

Identifiants & gouvernance

RFC-ID, Service/Produit concerné, Demandeur, Propriétaire du changement, Sponsor métier
CI impactés (références CMDB), Environnements (DEV/TEST/UAT/PROD), Périmètre géographique
Références : incident problème, exigence sécurité, audit, user story, ticket parent

Objet & justification

Intitulé du changement (verbe d’action + composant)
Contexte déclencheur et valeur attendue (KPI visés : disponibilité, temps de réponse, coûts, conformité)
Hypothèses et limites connues

Analyse d’impact (condensée, factuelle)

Disponibilité/SLA : risque de downtime, durée estimée, fenêtre proposée
Performance/Capacité : variations attendues, seuils d’alerte
Sécurité : posture modifiée (droits, surface d’attaque, vulnérabilités traitées)
Continuité/DRP : implications sur PRA/PCS, sauvegardes vérifiées
Réglementaire : données personnelles, traçabilité, exigences sectorielles

Évaluation du risque

Probabilité (1–5) × Impact (1–5) → Exposition (P×I)
Principales causes plausibles & garde-fous associés
Décision de traitement : éviter / réduire / transférer / accepter (avec justification)

Plan d’implémentation

Étapes numérotées, prérequis, scripts, référentiel d’artefacts
RACI opérationnel (qui exécute, qui valide, qui informe)
Fenêtre de changement proposée, dépendances (gel de code, freeze change, autres RFC)

Plan de test & critères de succès

Tests fonctionnels et techniques, jeux de données, critères d’acceptation mesurables
Monitoring ad hoc (dashboards, sondes, logs ciblés)

Plan de retour arrière (backout)

Conditions de déclenchement, séquence détaillée, durée max de rollback
Preuve que le retour arrière a été testé en pré-prod (ou justification solide si non testable)

Communication & parties prenantes

Public ciblé (support N1/N2, on-call, métiers), messages prêts à publier
Notice aux utilisateurs, page de statut, canaux et timing

Approbations

Revue technique, Revue sécurité, CAB/ECAB, validation métier
Clauses spécifiques (ex. : changement de schéma DB → approbation DBA obligatoire)

Clôture & retour d’expérience (PIR)

Résultat (succès/échec partiel), écarts vs plan, incidents dérivés, actions correctives
Mise à jour CMDB, documentation, runbook et procédure standard si industrialisation

4) Le circuit de décision sans friction

Triage par le Change Manager : complétude minimale, bonne classification, niveau de risque cohérent.
Évaluation (technique + sécurité) : challenge de la valeur, réalisme du plan, couverture des tests.
Arbitrage CAB : priorisation avec le calendrier de changements, compatibilité avec périodes sensibles (paie, clôture comptable, pics e-commerce).
Go/No-Go opérationnel le jour J : check de dernière minute (pré-requis, sauvegardes, astreinte).
PIR : boucle apprenante et alimentation des changements standards.

5) Indicateurs qui comptent vraiment

Change Success Rate (CSR). Part des RFC clôturées sans incident imputable.
Lead Time for Change. Délai entre soumission et mise en production (goulots visibles).
Change Failure Rate (CFR). Proportion de changements générant rollback ou incident majeur.
MTTR post-changement. Capacité à restaurer le service quand ça déraille.
Taux de standardisation. Part des « normaux » convertis en « standards » après 2–3 itérations stables.

6) Anti-patterns à éliminer

RFC-courriel. Contenu épars, hors outil ITSM, introuvable six mois plus tard.
Électricité statique dans la CMDB. Dépendances erronées → impacts sous-estimés.
Plan de test décoratif. Assertions vagues, pas de critères d’acceptation vérifiables.
Backout théorique. Jamais exécuté en amont, donc impraticable en stress réel.
Urgence inflationniste. ECAB sollicité pour des sujets routiniers, jusqu’à l’usure.

7) Modèle minimal « v1.0 » (prêt à industrialiser)

Objectif : tenir en une page, sans sacrifier le risque ni le retour arrière.

En-tête

RFC-ID · Service/Produit · Demandeur · Propriétaire · Environnements · CI (CMDB)

Objet & valeur

Titre du changement
Contexte déclencheur / KPI attendus (1–2 lignes)

Impact & risque (score 1–5)

Disponibilité · Performance · Sécurité · Continuité · Réglementaire
Exposition = P×I, décision (réduire/…/accepter) + garde-fous majeurs

Implémentation

Étapes clés (numérotées) · Prérequis · Fenêtre · Dépendances

Tests & succès

3–5 checks mesurables + outil de monitoring associé

Retour arrière

Conditions · Étapes · Durée max · Preuve de test pré-prod

Com & approbations

Parties prenantes · Messages prêts · Visa technique · Visa sécu · CAB/ECAB

Clôture (PIR)

Résultat · Incidents dérivés · Actions · Mise à jour CMDB/doc

8) Décider vite et juste : l’arbre d’orientation

Risque ≤ 2 et procédure éprouvée ? → Standard (pré-autorisé).
Risque 3–4 ou nouveauté partielle ? → Normal (CAB).
Vulnérabilité critique exploitée / service dégradé / impact financier immédiat ? → Urgent (ECAB), PIR renforcé.

9) Sécurité : intégrer sans alourdir

Lier la RFC au registre des vulnérabilités (CVSS), imposer une revue de droits si périmètre IAM bouge, consigner les hypothèses de menace (abuse cases).
Pour les patchs récurrents, bâtir des RFC standards sécurité avec jeux de tests et backout mécaniques.

10) Conseils de mise en œuvre

Un seul outil ITSM, une seule vérité. Champs obligatoires paramétrés, gabarits par type de changement.
Checklists brèves et incisives. Trois questions bloquantes suffisent souvent : sauvegarde vérifiée ? backout testable ? critères de succès mesurables ?
Réunions CAB utiles. Ordre du jour court, données préparées (risque, fenêtre, conflits de calendrier), décisions consignées.
Capitalisation. Chaque normal réussi deux fois de suite → candidat à la standardisation.
Discipline de calendrier. Blackout sur pics business, fenêtres de maintenance annoncées tôt, astreinte confirmée.

Lexique express

CAB (Change Advisory Board) : instance de revue et d’arbitrage.
ECAB : format restreint pour l’urgence.
CMDB : base de données de configuration, carte des dépendances techniques.
Backout plan : scénario de retour à l’état antérieur.
PIR : Post-Implementation Review, bilan à froid.

La fiche RFC rend visibles les choix, supporte la décision, protège l’exploitation et fabrique de l’apprentissage. Avec un modèle ramassé, des critères de succès tranchants et un backout crédible, le changement cesse d’être un pari : il devient un acte de production maîtrisé.

⬇️

Fiche_RFC_ITIL_Demande_Changement_v1.0 Download

Cas particuliers — Fiche RFC (ITIL) v1.0

Situations sensibles, traitements ciblés et champs à durcir

Ces cas exigent des preuves et des garde-fous. En les traitant avec des champs durcis, des tests orientés risques et un backout praticable, votre RFC reste courte, lisible, et pourtant taillée pour le réel.

Vous avez la structure v1.0. Voici les cas où elle mérite un réglage chirurgical. Pour chaque situation : l’enjeu, ce qu’il faut durcir dans la fiche, les contrôles, le backout, et la gouvernance.

1) Patch de sécurité critique (exploit actif)

Enjeu. Fenêtre serrée, pression métier, risque de régression.
Fiche — à durcir.

Typologie : Urgent (ECAB) avec motif « CVSS ≥ 9 / IOC détectés ».
Impact : Sécurité = 5/5, Disponibilité estimée (minutes), périmètre exact des CI.
Implémentation : canary sur 5 % du parc, puis élargissement par paliers.
Contrôles. Sonde avant/après (vuln scan ciblé), logs d’échec d’exploitation.
Backout. Paquet N–1 disponible, durée max rollback : 15 min.
Gouvernance. ECAB restreint (Ops + SecOps + Propriétaire de service), PIR sous 24 h.
Indicateur. Change Failure Rate (CFR) spécifique « sec-patch ».

2) Rotation de certificats à large périmètre (wildcard, mTLS)

Enjeu. Rupture silencieuse de flux inter-services.
Fiche — à durcir.

Dépendances CMDB : lister consommateurs, caches, terminators, jobs batch, agents.
Fenêtre : propagation DNS/OCSP/CRL prise en compte.
Contrôles. Tests mTLS sur maillage interne, vérification chaîne de confiance.
Backout. Remise en service du certificat précédent si non révoqué (sinon bascule vers CA secondaire).
Gouvernance. Visa DBA/app-owner si SGBD TLS activé, message proactif « possible reset de sessions ».
Indicateur. Taux d’erreurs 5xx/SSL par minute, seuils d’arrêt.

3) Migration de schéma de base de données « sans arrêt »

Enjeu. Incompatibilités applicatives latentes.
Fiche — à durcir.

Plan : stratégie expand–contract (ajout colonne → double écriture → bascule lecture → suppression).
Critères de succès : latence d’écriture, consistance réplication.
Contrôles. Shadow reads, requêtes de santé (checksum sur échantillons).
Backout. Script inverse prêt, sauvegarde logique et snapshot volume.
Gouvernance. CAB avec DBA obligatoire, freeze de déploiements concurrents.
Indicateur. Taux d’erreurs SQL par endpoint + lag de réplication.

4) Bascule blue/green multi-locataires

Enjeu. Effet domino sur plusieurs clients, données chauffées.
Fiche — à durcir.

Segmentations : ordre de bascule par cohortes (bronze/silver/gold).
Plan : warming cache + pré-provisionnement licences/quotas.
Contrôles. SLO par locataire, canary business (tunnel de commande, paiement fictif).
Backout. DNS/ingress flip, redirect 302 temporaire, TTL courts déjà en place.
Gouvernance. Fenêtre validée client premium, comms différenciées.
Indicateur. CSR par cohorte, temps moyen d’upgrade par tenant.

5) Changement piloté par un tiers (SaaS/Vendeur)

Enjeu. Faible maîtrise du calendrier, risque d’incompatibilité API.
Fiche — à durcir.

Références : avis fournisseur, numéros de tickets, version cible, breaking changes.
Plan : sandbox miroir, contrat de tests de non-régression.
Contrôles. Contrats d’API (schema validation), tests e2e sur cas d’usage cœur.
Backout. Feature-flag « compat layer », bascule vers version précédente si fournisseur le permet.
Gouvernance. CAB : présence Achats/Juridique si SLA impacté.
Indicateur. Erreurs 4xx/5xx par méthode API, error budget consommé.

6) Décommissionnement avec purge réglementaire

Enjeu. Risque de non-conformité (conservation, droit à l’effacement).
Fiche — à durcir.

Réglementaire : durée de rétention, registre de traitements, base légale.
Plan : purge scriptée, horodatage, export probatoire.
Contrôles. Échantillon signé, hash de preuves conservé.
Backout. Impossible après purge : prévoir quarantaine chiffrée (X jours) avant suppression définitive.
Gouvernance. Visa DPO/Conformité.
Indicateur. % de données purgées vs attendu, écarts justifiés.

7) Changement sur chaîne de paiement (PCI-DSS)

Enjeu. Haut niveau de contrôle, forte aversion au risque.
Fiche — à durcir.

Sécurité : zones CDE explicitement listées, segmentation vérifiée.
Plan : tests avec tokens, aucun PAN réel.
Contrôles. Journaux d’accès, attestation d’intégrité des binaires.
Backout. Basculer vers PSP secondaire en cas d’échec.
Gouvernance. ECAB + RSSI, fenêtre low-traffic.
Indicateur. Abandon de panier, taux d’autorisation, délai moyen d’auth 3-DS.

8) Surcharge saisonnière (pic e-commerce, clôture comptable)

Enjeu. Calendrier contraint, blackout partiel.
Fiche — à durcir.

Fenêtre : en dehors du pic, capacité de rollback < 10 min.
Plan : traffic shaping, autoscaling provisoire, read-only mode si nécessaire.
Contrôles. Test de performance ciblé (p95), alertes ajustées.
Backout. Désactivation du nouveau chemin via feature-flag.
Gouvernance. CAB élargi aux métiers concernés.
Indicateur. Taux de conversion/traitements clôture, SLO respectés.

9) OT/ICS — correctif en environnement industriel

Enjeu. Sécurité opérationnelle (HSE), obsolescence matérielle, fenêtres rares.
Fiche — à durcir.

Pré-requis : permis de travail, consignations, version firmware/PLC, plan de reprise manuel.
Plan : banc d’essai, jumeau numérique si dispo.
Contrôles. Mesures de stabilité (jitter, cycle time), tests fail-safe.
Backout. Rechargement image contrôleur, retour à séquence précédente.
Gouvernance. ECAB incluant Maintenance/Qualité/HSE.
Indicateur. MTBF post-changement, non-qualités produites.

10) Changement d’horaires (DST, fuseaux) et tâches planifiées

Enjeu. Jobs doublés ou sautés, dérive comptable/BI.
Fiche — à durcir.

Impact : liste des CRON, timezone effective des nœuds, dépendances aval BI/ETL.
Plan : gel temporaire ou migration vers UTC, jobs idempotents.
Contrôles. Vérification des volumes traités, absence de doublons.
Backout. Rétablir planning initial, reprise manuelle des lots manquants.
Gouvernance. CAB + Finance/Contrôle de gestion si calculs impactés.
Indicateur. Écarts de volumétrie vs N–1.

11) Feature à fort impact UX avec dark-launch

Enjeu. Effet réputation si défaut.
Fiche — à durcir.

Plan : exposition 0 % → 1 % → 10 % avec kill-switch documenté.
Succès : métriques UX (taux de clic, temps tâche, NPS in-app).
Contrôles. A/B test, traçage analytique.
Backout. Off instantané du flag + purge progressive du cache.
Gouvernance. Approbation Produit, information Support N1.
Indicateur. Variation de funnel, tickets « how-to ».

12) Hotfix en chaîne d’incident majeur (P1)

Enjeu. Courir sans casser plus.
Fiche — à durcir.

Typologie : Urgent lié à incident #INC-…, objectif de mitigation.
Plan : correctif minimal, isolement de cause, tests ciblés.
Contrôles. SLO rétabli, pas d’alarmes périphériques nouvelles.
Backout. Revenir à l’état degradé stable initial si régression.
Gouvernance. ECAB « de crise », PIR fusionné avec RCA.
Indicateur. MTTR, time to mitigate.

13) Changement de politique IAM (droits, SSO, MFA)

Enjeu. Blocage d’accès en masse, risque sécurité.
Fiche — à durcir.

Sécurité : inventaire des rôles impactés, break-glass account noté.
Plan : double-run (ancien + nouveau) le temps de la bascule, communication anticipée.
Contrôles. Taux de succès d’auth, tickets d’accès.
Backout. Réactivation de la politique précédente, purge des tokens invalides.
Gouvernance. Visa RSSI + RH si impacts salariés.
Indicateur. Erreurs 401/403, demandes d’assistance.

14) Observabilité : changement d’agent ou de pipeline

Enjeu. Cécité partielle pendant la bascule.
Fiche — à durcir.

Plan : double émission (ancien et nouveau collecteur), compatibilité schémas.
Succès : couverture métriques/logs/traces ≥ 98 % vs référence.
Contrôles. Table de correspondance champs, alertes test.
Backout. Restauration agent précédent, conservation des buffers.
Gouvernance. CAB technique, gel d’autres changements pendant migration.
Indicateur. Taux de drop, data-lag.

Deux micro-gabarits prêts à coller dans la RFC

A) Clause “Go/No-Go minute” (à insérer dans Implémentation)

Sauvegarde vérifiée (horodatage, taille) : ✅ / ❌
Health-checks verts sur canary : ✅ / ❌
Astreinte confirmée (Ops/Sec/DBA) : ✅ / ❌
Kill-switch fonctionnel (preuve) : ✅ / ❌

B) Clause “Retour arrière” (à insérer dans Backout)

Condition de déclenchement : CFR > X % ou SLO < Y min
Étapes ordonnées : flag off → rollback artefact N–1 → clear cache → redémarrage contrôlé
Durée maximale : T ≤ 15 min
Responsables : exécutant / validateur
Preuve de test pré-prod : lien artefact + log

Check rapide de complétude (à cocher en revue)

Les dépendances CMDB sont-elles vérifiées (pas copié-collé d’une RFC ancienne) ?
Les critères de succès sont-ils mesurables et reliés à des sondes existantes ?
Le backout a-t-il été exercé (ou justifié s’il est impossible) ?
La fenêtre respecte-t-elle les blackouts métier (paie, clôture, campagnes) ?
La communication est-elle prête avant le Go (statut, N1, clients sensibles) ?