Je suis en train de lire sur ITIL et ma première réaction n’est pas très glorieuse : ça sent le gros cartable de procédures. Une fois le vocabulaire passé, j’y vois surtout une façon de ne pas mélanger trois boucles différentes : remettre le service, éliminer une cause et modifier la production.

Un incident commence lorsqu’un service est dégradé. Le ticket doit capturer l’heure, le service, le symptôme, l’impact, la personne qui coordonne et les actions prises. La priorité combine l’impact et l’urgence : une erreur qui bloque toute la facturation aujourd’hui passe avant un défaut visuel vu par une seule personne, même si les deux sont « urgents » dans le courriel.

Le serveur de suivi enregistre ces événements dans une base et transmet un message aux responsables selon la priorité. Son journal devient la chronologie commune; une boîte de réception personnelle ne devrait pas être la seule mémoire de la panne.

Nouveau → Assigné → Diagnostic → Service restauré → Fermé
                         ↘ escalade / communication

Le but immédiat est la restauration. Redémarrer un service ou basculer vers un nœud sain peut être un bon workaround. Ça ne prouve pas que la cause est comprise. Le ticket conserve une chronologie et un identifiant commun pour que les logs, appels et décisions parlent du même événement.

Un problème cherche ensuite la cause et le risque de répétition. Prenons un SQL Server arrêté parce que le volume du journal est plein :

1. incident : ajouter temporairement de l’espace ou corriger la chaîne de sauvegarde pour restaurer le service;
2. problème : découvrir qu’aucun backup du journal ne roulait depuis trois semaines;
3. erreur connue : documenter le symptôme et le workaround;
4. correction permanente : automatiser backups, seuils et tests de restauration;
5. validation : surveiller un cycle complet et retirer le workaround.

Le redémarrage ferme l’incident, pas le problème. À l’inverse, attendre l’analyse parfaite avant de remettre la facturation serait une mauvaise priorité. Séparer les objets rend les deux travaux visibles.

Un changement applique une modification contrôlée. Sa fiche utile n’a pas besoin de quinze pages, mais elle répond à :

quoi et pourquoi
composantes et utilisateurs touchés
risque et dépendances
étapes avant / pendant / après
test de succès mesurable
point de décision pour arrêter
plan de retour avec durée
responsable et fenêtre

Le rollback doit être possible, pas seulement écrit. Une migration qui supprime une colonne ne se renverse pas en remettant l’ancien .dll; il faut une sauvegarde, un script inverse ou un déploiement en deux temps où l’ancienne et la nouvelle version coexistent. Je teste le retour dans un environnement représentatif et je fixe l’heure après laquelle il ne reste plus assez de fenêtre pour l’exécuter.

Toutes les modifications ne méritent pas la même gouvernance. Un changement standard, répété et déjà prouvé peut être préautorisé avec une checklist. Un correctif urgent a un chemin rapide avec approbateur disponible et revue après coup. Une migration risquée passe une revue plus large. Si une correction de texte et un changement de schéma exigent le même rituel, les équipes vont contourner le système.

Les relations aident : l’incident pointe vers le problème, le problème vers le changement, et le changement vers les serveurs ou services concernés. Une CMDB parfaite est ambitieuse; commencer par une liste fiable des services critiques, de leurs propriétaires et dépendances apporte déjà beaucoup.

Je mesurerais peu de choses : délai de restauration, taux d’incidents récurrents, changements ayant causé un incident, rollbacks réussis et tickets rouverts. Compter le nombre de formulaires remplis ne mesure pas la fiabilité. Les notes doivent aider la prochaine personne, pas seulement satisfaire une case.

Ma pratique sera de traiter le prochain incident avec trois enregistrements seulement si nécessaire, reliés et courts. Si le processus permet de retrouver la chronologie, de répéter un workaround sûr et de revenir d’un changement, il gagne sa place. S’il retarde la restauration sans réduire un risque, je vais l’alléger plutôt que blâmer les gens qui l’évitent.