Sommaire
Comprendre la différence entre incident, problème et changement selon ITIL, et appliquer une démarche structurée pour gérer les changements en production.
🎯 Objectifs de la fiche
- Incident, problème, changement : ne pas confondre — Trois processus ITIL distincts mais liés
- Le processus de gestion des problèmes — Identifier la cause racine derrière des incidents répétés
- Le processus de gestion des changements — RFC, évaluation d'impact, comité (CAB)
- Catégoriser un changement — Standard, normal, urgent
- Documenter un changement pour le portfolio — Lien avec le rapport d'incident et le PCA/PRA
Prérequis
Avoir vu l'introduction à ITIL et le ticketing GLPI (fiches précédentes). Notions de base sur la méthodologie de diagnostic d'incident.
1. Incident, problème, changement : ne pas confondre
ITIL distingue trois notions souvent confondues en pratique. Un incident est une interruption ou une dégradation ponctuelle d'un service (ex: un poste ne démarre plus). Un problème est la cause sous-jacente d'un ou plusieurs incidents (ex: un disque dur défectueux sur un modèle de poste, provoquant plusieurs incidents similaires). Un changement est toute modification planifiée d'un système ou d'un service, qu'il soit correctif (résoudre un problème) ou évolutif (ajouter une fonctionnalité).
| Notion | Définition | Exemple |
|---|---|---|
| Incident | Interruption ou dégradation ponctuelle d'un service | Un utilisateur ne peut plus accéder au serveur de fichiers |
| Problème | Cause sous-jacente d'un ou plusieurs incidents | Une carte réseau défectueuse sur le serveur de fichiers |
| Changement | Modification planifiée d'un système ou service | Remplacer la carte réseau défectueuse |
2. Le processus de gestion des problèmes
La gestion des problèmes vise à identifier la cause racine derrière des incidents récurrents, afin d'éviter qu'ils ne se reproduisent. Elle s'appuie souvent sur l'analyse des tendances dans l'outil de ticketing (GLPI) : plusieurs incidents similaires signalés sur une courte période doivent déclencher une analyse de problème.
| Étape | Objectif |
|---|---|
| Détection | Repérer une récurrence d'incidents similaires |
| Analyse de cause racine | Identifier pourquoi le dysfonctionnement se produit |
| Solution de contournement (workaround) | Limiter l'impact en attendant une résolution définitive |
| Demande de changement | Proposer la correction définitive via le processus de changement |
3. Le processus de gestion des changements
Tout changement significatif (mise à jour majeure, remplacement de matériel, modification d'une configuration réseau critique) doit être formalisé par une RFC (Request For Change) avant exécution. Cette demande décrit le changement, son objectif, les risques identifiés et un plan de retour en arrière en cas d'échec.
| Élément d'une RFC | Contenu attendu |
|---|---|
| Description | Quoi changer, et pourquoi |
| Impact estimé | Services concernés, durée d'interruption prévue |
| Plan de test | Comment valider que le changement fonctionne |
| Plan de retour en arrière (rollback) | Comment annuler le changement en cas de problème |
| Fenêtre de changement | Date et heure prévues, idéalement hors période d'activité critique |
4. Catégoriser un changement
| Catégorie | Caractéristique | Validation requise |
|---|---|---|
| Standard | Changement répétitif, à faible risque, déjà documenté et approuvé une fois pour toutes | Pré-approuvé, pas de revalidation systématique |
| Normal | Changement non répétitif nécessitant une évaluation au cas par cas | Validation par le CAB (Change Advisory Board) |
| Urgent | Changement nécessaire immédiatement pour résoudre un incident critique | Validation accélérée, souvent a posteriori |
5. Documenter un changement pour le portfolio
Un changement bien documenté (RFC, résultat, éventuel incident lié) constitue une excellente situation professionnelle à valoriser : elle illustre une démarche structurée, rarement improvisée, qui se distingue nettement d'une simple intervention ponctuelle.
Quelle est la différence principale entre un incident et un problème selon ITIL ?
✅ Réponse : L'incident est l'interruption ponctuelle, le problème en est la cause sous-jacente
Que désigne une RFC dans le processus de gestion des changements ?
✅ Réponse : Une demande formalisée de changement (Request For Change)
Quel élément d'une RFC permet de revenir à l'état stable en cas d'échec ?
✅ Réponse : Le plan de retour en arrière (rollback)
Quelle catégorie de changement est pré-approuvée car répétitive et à faible risque ?
✅ Réponse : Changement standard
Que vise principalement le processus de gestion des problèmes ?
✅ Réponse : Identifier la cause racine pour éviter la récurrence d'incidents similaires
- AXELOS — ITIL 4 Foundation — https://www.axelos.com/certifications/itil-service-management
- ITIL — Gestion des changements (présentation) — https://www.itlibrary.org/
- GLPI — documentation officielle — https://glpi-project.org/documentation/