Gestion des incidents : le cycle de vie d'un ticket

La gestion des incidents est la pratique ITIL qui vise à rétablir un service le plus vite possible après une panne ou une dégradation, en limitant la gêne pour les utilisateurs. Elle suit un cycle : détecter, enregistrer, qualifier, prioriser, diagnostiquer, résoudre, clôturer. Ce chapitre déroule ce cycle sur un vrai ticket, explique les statuts d'un ticket GLPI de « Nouveau » à « Clos » et montre comment traiter les demandes de service, les incidents majeurs et les incidents de sécurité.

Les étapes de la gestion d'un incident

Deux règles traversent toutes les étapes. Rétablir d'abord, comprendre ensuite : si un redémarrage remet la messagerie en marche en cinq minutes, on redémarre, puis on cherche la cause à froid. Tenir l'utilisateur informé à chaque changement d'état : un utilisateur sans nouvelles rappelle, et son mécontentement grandit plus vite que la panne.

Qualifier l'appel avec le QQOQCP

L'utilisateur dit : « Ça marche pas. » C'est inexploitable. Qualifier, c'est transformer cette plainte en faits vérifiables. La méthode QQOQCP te donne six questions à poser, dans l'ordre qui convient à la conversation.

La question « qu'est-ce qui a changé ? » est la plus rentable du support : une mise à jour, un déménagement de bureau, un mot de passe modifié la veille expliquent une grande partie des pannes.

Voici une qualification réussie, au téléphone, chez Cèdre Habitat.

Description rédigée dans le ticket : « Poste PC-SIE-047 (Mme Roussel, service attributions, siège 2e étage) : impression impossible vers le copieur du 2e étage, message "Imprimante hors ligne", depuis le redémarrage après la mise à jour Windows de cette nuit. Les postes voisins impriment normalement. Bloquant pour une commission à 14 h. »

Cette description dit déjà beaucoup : le copieur fonctionne (les autres impriment), le réseau du bureau aussi, la cause probable est sur ce poste, et la mise à jour de la nuit est suspecte. Le diagnostic commence avant même d'avoir touché le PC.

Le ticket : les champs qui comptent

Dans GLPI, un ticket se crée par Assistance > Tickets, bouton Ajouter. Les champs essentiels :

Associer l'élément du parc est ce qui fait la force d'un outil comme GLPI : depuis la fiche du copieur, tu vois tous ses tickets passés. Si le même copieur revient dix fois en un mois, il ne s'agit plus d'incidents isolés.

Les statuts d'un ticket, de Nouveau à Clos

Pourquoi deux statuts, Résolu puis Clos ? « Résolu » veut dire « je pense que c'est réglé » ; « Clos » veut dire « le demandeur confirme ». Ce double palier évite de fermer un ticket sur une fausse réparation : tant que le ticket est résolu, l'utilisateur peut refuser la solution et le ticket est rouvert. Dans GLPI, un délai de clôture automatique se règle par entité : sans réponse du demandeur, le ticket se ferme seul au bout de ce délai.

Suivis, tâches et solution

Pendant le traitement, trois types d'écrits enrichissent le ticket dans GLPI.

• Le suivi est un message horodaté : une question à l'utilisateur, un point d'avancement, un compte rendu de vérification. Il est public (le demandeur le voit et reçoit une notification) ou privé (note interne entre techniciens).
• La tâche est une action concrète, avec une durée et un responsable : « Réinstaller le pilote du copieur, 15 min, Sarah ». Les tâches mesurent le temps passé et peuvent être planifiées.
• La solution dit ce qui a résolu le ticket. Elle se rédige pour un collègue qui ne connaît pas le dossier (chapitre 10).

Le fil du ticket de Mme Roussel, tel qu'on le lit dans GLPI :

Incident ou demande de service : deux circuits

Une demande de service n'est pas une panne. Elle suit un circuit prévu à l'avance, souvent avec une validation.

Dans GLPI, le type du ticket (Incident ou Demande) les sépare. Les formulaires intégrés à GLPI depuis la version 11 permettent de proposer aux utilisateurs des demandes toutes prêtes (« Arrivée d'un salarié », « Accès à un dossier »), avec les bons champs et la validation automatique du responsable. Les demandes d'évolution d'une application (« ajouter un filtre par date dans l'export ») passent par le même circuit, puis deviennent des changements ou des tâches de développement : la section suivante montre comment.

Traiter un bug applicatif ou une demande d'évolution

Un bug applicatif est un incident dont la cause est dans le code d'une application : il se traite comme tout incident (ticket, priorité, communication), mais sa correction passe par le cycle du développement. C'est la sous-compétence « traiter des demandes concernant les applications » du bloc 1, celle que l'on attend surtout d'un étudiant SLAM. Quand l'application est un progiciel, le support reproduit le bug et le transmet à l'éditeur (N3) ; quand elle est développée en interne, c'est l'équipe qui la corrige.

Chez Cèdre Habitat, le portail locataires est développé par l'équipe projets (une API Node.js et une base de données, déployées en conteneurs Docker). Mardi, la version 2.3.0 a ajouté le complément d'adresse sur les avis d'échéance en PDF. Mercredi, le ticket 4356 arrive par l'accueil : « Plusieurs locataires ne peuvent plus télécharger leur avis d'échéance : le portail affiche "Une erreur est survenue". » Nadia le prend en charge.

1. Qualifier avec le QQOQCP, en ajoutant ce qu'un développeur demande toujours : la version de l'application, le compte concerné, les données en jeu, les étapes exactes pour reproduire, le résultat attendu et le résultat obtenu. Ici : version 2.3.0, trois comptes de locataires cités, clic sur « Télécharger » dans « Mes avis d'échéance ».
2. Reproduire en environnement de test, jamais sur la production : avec une copie anonymisée des données, Nadia obtient l'erreur pour un des trois locataires, et pas pour son compte de test.
3. Lire les journaux. Le code HTTP oriente tout de suite : un code 4xx dit que le serveur a refusé la requête (400 donnée invalide, 401 non authentifié, 403 accès interdit, 404 introuvable) ; un code 5xx dit que le serveur a échoué en la traitant, donc souvent un défaut du code ou de son environnement. La console du navigateur (touche F12, onglets Console et Réseau) montre la requête en erreur ; le journal de l'API dit pourquoi :

docker compose logs --since 2h api

api-1  | GET /api/avis/2026-11/pdf 500
api-1  | TypeError: Cannot read properties of null (reading 'trim')
api-1  |     at formaterAdresse (/app/src/pdf/avis.js:42:38)

4. Isoler un cas minimal. Les trois locataires touchés n'ont pas de complément d'adresse : le champ vaut null, et la ligne 42 appelle .trim() dessus. Les locataires qui en ont un ne sont pas touchés. Le contournement est noté dans le ticket : l'accueil envoie l'avis par courriel depuis le logiciel de gestion locative.
5. Écrire le test qui reproduit le bug, avant de corriger. Il échoue (rouge) tant que le bug est là :

test("avis d'échéance : locataire sans complément d'adresse", () => {
  const lignes = formaterAdresse({
    rue: '12 rue des Lilas', complementAdresse: null,
    codePostal: '69200', ville: 'Vénissieux',
  });
  expect(lignes).toEqual(['12 rue des Lilas', '69200 Vénissieux']);
});

6. Corriger la cause, pas le symptôme : (locataire.complementAdresse ?? '').trim() traite l'absence de complément. Masquer l'erreur par un try/catch qui renvoie un PDF vide aurait caché le défaut.
7. Lancer toute la suite de tests : le nouveau test passe (vert) et les anciens aussi. C'est la non-régression : la correction n'a rien cassé ailleurs, et le test restera dans la suite pour que ce bug ne revienne jamais.
8. Livrer comme un changement : une branche, un commit fix: avis PDF sans complément d'adresse, une revue par un collègue, une version 2.3.1, un déploiement annoncé, et un plan de retour arrière (redéployer l'image de la version précédente). Si le déploiement par la chaîne d'intégration continue est une procédure pré-autorisée, c'est un changement standard ; sinon, un changement normal (chapitre 6).
9. Relier les traces : le ticket GLPI cite l'issue du dépôt et le commit de correction, l'issue cite le numéro du ticket. N'importe qui peut ainsi remonter du symptôme au code, et inversement.
10. Clore et capitaliser : solution rédigée sans jargon pour l'accueil, validation par un locataire touché, note de version, et une erreur connue enregistrée si la livraison tarde.

Une demande d'évolution (« pouvoir filtrer ses avis d'échéance par année ») suit un autre chemin, plus proche de la demande de service. Le support enregistre un ticket de type Demande et qualifie le besoin : qui le demande, pour quoi faire, ce qui se passe aujourd'hui sans. Le responsable métier (ici, la responsable de la relation locataires) valide ; l'équipe estime la charge ; la responsable de la DSI arbitre et planifie avec les autres demandes. L'évolution est développée sur une branche avec ses tests, livrée dans une version mineure (2.4.0) par un changement normal, puis annoncée aux utilisateurs. Le ticket est résolu à la livraison, pas à la validation.

L'incident majeur

Un incident majeur a un impact très fort sur l'activité : tout un site sans réseau, la messagerie en panne pour tous, le logiciel métier inaccessible un jour de paiement des loyers. Il ne se traite pas comme un ticket ordinaire.

• Une seule personne coordonne (souvent la responsable de la DSI ou un responsable d'astreinte) : elle répartit le travail, décide, informe.
• Un seul ticket principal (le « ticket chapeau ») ; les dizaines d'appels qui arrivent y sont rattachés (dans GLPI, on les lie comme tickets fils du ticket parent) au lieu d'être traités un par un.
• Une communication régulière à tous les utilisateurs, même sans nouveauté : « Incident en cours sur la messagerie, prochain point à 11 h. »
• Un retour d'expérience après coup : un post-mortem et l'ouverture d'un problème (chapitre 5).

L'incident de sécurité : des réflexes à part

Un poste qui affiche une demande de rançon, un utilisateur qui a saisi son mot de passe sur une fausse page, un compte qui se connecte la nuit depuis l'étranger : ce sont des incidents de sécurité. On les enregistre comme tout incident, mais les réflexes changent.

1. Isoler sans éteindre : débrancher le câble réseau ou couper le Wi-Fi du poste suspect, mais le laisser allumé pour conserver les traces en mémoire.
2. Prévenir immédiatement la personne chargée de la sécurité (responsable de la DSI, RSSI), sans attendre d'avoir compris.
3. Ne rien effacer : ni fichier, ni journal, ni courriel suspect.
4. Restreindre la visibilité du ticket : une catégorie dédiée, accessible à peu de personnes.
5. Si des données personnelles sont touchées, l'organisation doit notifier la violation à la CNIL dans les 72 heures après en avoir pris connaissance (article 33 du RGPD) : la décision revient au responsable, pas à toi, mais il doit être prévenu tout de suite.

Ces réflexes sont détaillés dans le cours Journalisation et réponse à incident, et l'obligation de notifier dans le chapitre Notifier un incident ; voir aussi les cours cybersécurité de l'infrastructure et droit et RGPD.

Exercices