Modèles et enregistrements · ISO 20000 · Chapitre 8.5.1
Modèle de demande de changement (RFC) selon l’ISO 20000-1
Chaque modification d’un service ou d’un élément sous contrôle : ce qui change, pourquoi, quel risque cela comporte, qui l’approuve, comment revenir en arrière si cela tourne mal et si cela a fonctionné.
En une phrase
Une demande de changement consigne la description et le motif du changement, son classement, l’évaluation des risques, des bénéfices, de la faisabilité et de l’impact financier, l’approbation par la personne habilitée, la date planifiée communiquée, le plan de retour arrière, le résultat des tests et la revue de son efficacité, car le chapitre 8.5.1 de l’ISO/IEC 20000-1 exige d’enregistrer et de classer chaque demande et de prendre les décisions avec les parties concernées selon la politique de gestion des changements.
- Où la norme l’exige
- ISO 20000 · Chapitre 8.5.1 Les chapitres sont cités selon la numérotation de l’ISO/IEC 20000-1:2018, l’édition en vigueur et celle qu’utilise l’Académie.
- Type d’information
- Enregistrement obligatoire Enregistrement et classement des demandes de changement (8.5.1.2), avec la politique documentée (8.5.1.1)
- Qui le renseigne
- Gestionnaire des changements L’approbation revient à qui la politique désigne ; les changements importants passent par un comité réunissant les parties concernées
- Quand
- Avant tout changement maîtrisé Les changements d’urgence peuvent être approuvés par voie rapide, mais ils sont enregistrés de la même façon
- Durée de conservation
- Fixée par l’organisme La norme demande de maîtriser la conservation et l’élimination des informations documentées (7.5.3) sans fixer de durée. L’usage est de couvrir au moins le cycle de certification de trois ans, ou la durée du contrat avec le client si elle est plus longue.
Ce que demande la norme
Ce qu’exige ISO 20000 et ce qui est laissé à votre appréciation
La norme demande une politique de gestion des changements qui définisse les éléments de configuration placés sous son contrôle, les critères d’identification des changements susceptibles d’avoir un impact majeur — gérés via la conception et la transition des services du 8.5.2 — et le traitement des changements d’urgence.
Chaque demande est enregistrée et classée. La décision est prise avec les parties concernées, en appréciant les risques, les bénéfices, la faisabilité et l’impact financier. Les dates planifiées sont communiquées, les activités de retour arrière sont préparées et, si possible, testées, et elles sont appliquées si le changement échoue.
Après la mise en œuvre, l’efficacité du changement est revue, et les enregistrements des demandes sont analysés périodiquement pour détecter les tendances.
Structure
Les champs que doit comporter le modèle
- Numéro, date et demandeur
- Description et motif
- Services et éléments de configuration concernés
- Classement : standard, normal, urgence ou à impact majeur
- Évaluation des risques, des bénéfices, de la faisabilité et de l’impact financier
- Approbation et décideur
- Fenêtre planifiée et communication
- Plan de retour arrière et indication de son test
- Résultat des tests et de la mise en œuvre
- Revue de l’efficacité et clôture
Exemple
Exemple : inventaire des certificats avec alerte
Entreprise, personnes et chiffres fictifs : l’exemple montre seulement à quoi ressemble un enregistrement correctement renseigné.
| Champ | Contenu |
|---|---|
| Changement | CHG-26-077 · 22 avril 2026 · origine : problème PRB-26-021 |
| Description | Création des 46 certificats de serveur comme éléments de configuration et alerte automatique à 30 jours |
| Concerne | Base de données de configuration et outil de supervision |
| Classement | Normal · risque faible |
| Évaluation | Aucune interruption de service · coût interne de 3 jours-homme · évite des pannes comme celle d’avril |
| Approbation | Comité des changements du 24 avril |
| Fenêtre | 28 avril, 19 h-21 h · communiquée au client le 24 |
| Retour arrière | Désactiver la règle d’alerte · testé en préproduction |
| Efficacité | Première alerte reçue le 12 juin, 30 jours avant l’expiration · efficace |
À l’audit
Les erreurs que relèvent souvent les auditeurs
- Des changements appliqués en production sans demande enregistrée.
- Des changements d’urgence jamais enregistrés après coup.
- Des plans de retour arrière inexistants ou jamais testés.
- Aucune revue a posteriori pour vérifier que le changement a fonctionné.
- La politique ne définit pas les éléments placés sous le contrôle des changements.
Dans Kimobox
Comment tenir cet enregistrement dans Kimobox
- 1Les demandes de changement sont gérées comme circuit d’approbation.
- 2Chaque changement conserve son approbation, ses tests et son résultat documentés dans le même circuit.
- 3Les éléments de configuration sont enregistrés comme actifs versionnés.
Questions fréquentes
Ce que l’on nous demande avant de commencer
Qu’est-ce qu’un changement standard ?
Un changement à faible risque, fréquent et à la procédure connue, préapprouvé et qui ne passe pas en comité à chaque fois. L’ISO/IEC 20000-1 n’emploie pas ce terme, mais permet de définir dans la politique les changements traités ainsi.
Que fait-on d’un changement d’urgence ?
La politique de gestion des changements doit définir comment les gérer. L’usage est une approbation rapide par une personne habilitée, suivie d’un enregistrement complet et de sa revue.
Tenez les enregistrements ISO 20000 sans modèles éparpillés
Nous vous montrons le module en fonctionnement avec des données proches des vôtres.
Poursuivez la visite
Pages associées
Conception et transition des services
Tout changement apporté à un service informatique doit être planifié et testé avant sa mise en production…
Modèle de catalogue de services IT selon l’ISO 20000-1
Ce que doit comporter le catalogue de services exigé par l’ISO/IEC 20000-1 : description, résultats…
Modèle d’accord de niveau de service (SLA) ISO 20000-1
Ce que doit contenir un SLA selon l’ISO/IEC 20000-1 (8.3.3) : services, objectifs de niveau, limites de…
Modèle de rapport de niveau de service ISO 20000-1
Ce que doit contenir le rapport de service exigé par l’ISO/IEC 20000-1 : respect des SLA, charge, incidents…