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

02Observe 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.

03É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.

04Relie 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.

05Documente 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.

06Documente 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.

07Valide 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.