Gérer les incidents IT avec JSM : du ticket à la résolution en 5 étapes

Vendredi, 17h30. Le serveur de production tombe. Les emails d’alerte s’accumulent. Le téléphone sonne. Et la seule chose qui empêche ta soirée de devenir un cauchemar, c’est la qualité de ton processus de gestion d’incidents.

Un bon processus de gestion d’incidents, c’est pas compliqué. Mais il faut qu’il soit clair, outillé, et surtout suivi. Voici comment je le configure avec Jira Service Management.

Étape 1 : Détection et création du ticket

Un incident peut arriver de plusieurs façons : un utilisateur signale un problème via le portail, un outil de monitoring déclenche une alerte, ou un membre de l’équipe remarque une anomalie.

Dans JSM, configure des canaux d’entrée multiples : le portail client (bien sûr), l’email (chaque email à une adresse dédiée crée automatiquement un ticket), et les intégrations avec tes outils de monitoring (Opsgenie, PagerDuty, Datadog).

Étape 2 : Classification et priorisation

Chaque incident doit être classé selon son impact et son urgence. En suivant le référentiel ITIL, tu définis une matrice de priorité qui détermine automatiquement le niveau de service applicable.

• P1 (Critique) : service complètement indisponible, business impact majeur
• P2 (Haute) : dégradation significative du service, workaround possible
• P3 (Moyenne) : impact limité, fonctionnalité secondaire touchée
• P4 (Basse) : demande d’information ou problème cosmétique

Les SLA se déclenchent dès la création du ticket. Un P1 doit avoir une première réponse en 15 minutes et une résolution en 4 heures. Un P4 peut attendre 48 heures. Configure tout ça dans les paramètres SLA de ton projet JSM.

Étape 3 : Investigation et diagnostic

C’est là que la puissance de JSM brille. L’agent assigné peut consulter Assets pour voir quels serveurs et services sont concernés, vérifier les incidents récents similaires, et accéder à la base de connaissances pour trouver des procédures de résolution connues.

Étape 4 : Résolution et communication

Une fois la solution identifiée, applique le fix et documente chaque action dans le ticket. La transparence est clé : l’utilisateur qui a signalé l’incident doit être informé à chaque étape.

Configure des automatisations pour envoyer des notifications automatiques : quand le ticket passe en «En cours d’investigation», quand une solution est identifiée, et quand le ticket est résolu.

Étape 5 : Post-mortem et amélioration continue

C’est l’étape que 90% des équipes oublient. Après chaque incident P1 ou P2, fais un post-mortem. Pas pour blamer, mais pour améliorer.

• Qu’est-ce qui s’est passé ? (chronologie factuelle)
• Pourquoi c’est arrivé ? (cause racine)
• Comment on a résolu ? (actions prises)
• Comment on empêche que ça se reproduise ? (actions préventives)

La gestion d’incidents, c’est un des modules les plus denses de ma formation JSM. On passe de la théorie ITIL à la pratique sur un vrai environnement Atlassian Cloud 2026, avec des scénarios d’incidents concrets.