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.
Avoir vu l'introduction à ITIL et le ticketing GLPI (fiches précédentes). Notions de base sur la méthodologie de diagnostic d'incident.
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 |
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 |
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 |
| 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 |
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.
✅ Réponse : L'incident est l'interruption ponctuelle, le problème en est la cause sous-jacente
✅ Réponse : Une demande formalisée de changement (Request For Change)
✅ Réponse : Le plan de retour en arrière (rollback)
✅ Réponse : Changement standard
✅ Réponse : Identifier la cause racine pour éviter la récurrence d'incidents similaires