Distingue incident, demande, problème et changement

01Commence par l’intention

Incident
- interruption ou dégradation non prévue
- objectif : restaurer le service

Demande
- accès, information, équipement ou prestation standard
- objectif : fournir un service convenu

Problème
- cause d'un ou plusieurs incidents potentiels
- objectif : comprendre et éliminer la cause

Changement
- modification planifiée du système d'information
- objectif : modifier avec analyse, validation et retour arrière

02Relie ces objets aux pratiques de gestion de services

Dans le vocabulaire ITIL 4, cette leçon recoupe quatre pratiques distinctes :

Incident Management
→ restaurer le fonctionnement normal aussi vite que raisonnablement possible

Service Request Management
→ traiter une demande utilisateur prédéfinie ou convenue

Problem Management
→ réduire la probabilité et l'impact des incidents en travaillant sur leurs causes

Change Enablement
→ augmenter la réussite des changements en évaluant les risques, les autorisations et le calendrier

Le but n’est pas de transformer ce cours en préparation à une certification ITIL. Le vocabulaire sert ici à comprendre pourquoi quatre objets différents existent et comment ils coopèrent dans un service informatique réel.

03Observe le scénario PME

TCK-004 — Latence récurrente à Tours
Type : incident
But immédiat : rétablir un service acceptable

PRB-001 — Latence WAN Tours
Symptômes : pertes et débit instable
Cause : file QoS incorrecte
Contournement : prioriser le trafic métier

CHG-001 — Correction QoS WAN Tours
Plan : appliquer la politique versionnée
Sauvegarde : exporter la configuration
Checklist : test, rollback, supervision

Le ticket protège l’utilisateur, le problème explique la répétition et le changement gouverne la correction durable.

04Évite les faux changements

Réinitialiser un mot de passe selon une procédure standard
→ demande

Redémarrer un service pour restaurer rapidement
→ tâche d'un incident

Modifier la politique QoS d'un routeur
→ changement

Analyser pourquoi la QoS se dérègle régulièrement
→ problème

Une tâche technique n’est pas automatiquement un changement. Le critère est la gouvernance nécessaire autour de la modification.

05Relie les objets

actif affecté
   ↑
ticket incident ──→ problème ──→ changement
   │                    │             │
   └─ solution          └─ cause      └─ déploiement
      et preuve            et contournement  sauvegarde et checklist

Les liens permettent de retrouver l’impact, l’historique et la justification de la décision.

06Documente le problème

Symptômes observables
Impact métier
Incidents liés
Cause confirmée ou hypothèses
Contournement disponible
Éléments concernés
Décision suivante

Un problème sans analyse devient seulement un second ticket avec un autre nom.

07Documente le changement

impact attendu
contrôles préalables
plan de déploiement
plan de sauvegarde
plan de retour arrière
fenêtre et responsables
validation requise
critères de succès

GLPI permet de lier tickets, problèmes, actifs et projets au changement. Le lab exige déjà les plans essentiels.

08Valide hors ligne

lab=/tmp/soria-glpi-service-desk-$USER
bash module3-glpi-service-desk-sla.sh setup "$lab"
bash module3-glpi-service-desk-sla.sh run "$lab"
cat "$lab/input/problems.csv"
cat "$lab/input/changes.csv"

Le script vérifie les liens et les plans. Il ne crée aucun objet dans une instance GLPI.