Gestion des incidents avec Jira Service Management

Du chaos des tickets à la résolution structurée des perturbations

La gestion moderne des incidents repose sur trois piliers : l'enregistrement intelligent des tickets via des portails dynamiques, un workflow dédié pour les Major Incidents et une alerte automatisée via Opsgenie. Qui relie proprement ces trois éléments dans Jira Service Management réduit le temps de rétablissement et décharge le support de premier niveau des travaux préparatoires manuels.

Concrètement, cela signifie :

• Les formulaires dynamiques du portail client ne demandent que les champs pertinents, en fonction de la catégorie de l'incident.
• Un workflow séparé pour les Major Incidents informe automatiquement les parties prenantes et crée des responsabilités claires pendant la phase aiguë.
• Opsgenie achemine les alertes provenant du monitoring vers la personne de garde responsable, y compris avec des niveaux d'escalade.

En tant qu'Atlassian Platinum Solution Partner en Suisse, Swarmit accompagne les organisations informatiques précisément dans cette mise en œuvre, de la première structure du portail jusqu'au service de garde rodé.

Où la gestion des incidents échoue en pratique

La cause la plus fréquente d'une mauvaise gestion des incidents n'est pas l'absence d'outil, mais l'absence de structure. Les tickets arrivent dans une file générique, contiennent trop peu de contexte, et le support de premier niveau passe les dix premières minutes à essayer de comprendre de quoi il s'agit. Ensuite on demande des précisions, le ticket est transféré manuellement au groupe responsable, et quelque part dans ce processus commence le vrai travail.

Un incident est par définition une interruption imprévue d'un service. L'objectif est toujours le même : rétablir le service le plus rapidement possible. Tout ce qui raccourcit ce chemin en vaut la peine. Tout ce qui l'allonge doit être remis en question.

Dans les mandats que nous accompagnons chez des clients suisses, nous observons trois schémas récurrents : un enregistrement des tickets peu clair, pas de procédure définie pour les Major Incidents et des alertes qui arrivent dans la mauvaise boîte. Ces trois points peuvent tous être traités dans Jira Service Management (JSM).

Enregistrement intelligent des tickets avec des portails dynamiques

Un portail n'est utilisé que s'il aide l'employé plus rapidement qu'un appel à l'informatique. Pour y parvenir, deux choses sont nécessaires : une structure de catégories concise et des formulaires qui s'adaptent en fonction du choix.

Concrètement : si quelqu'un choisit « Applikation funktioniert nicht », le formulaire demande quelle application est concernée et affiche automatiquement des articles de connaissance associés. Si quelqu'un choisit « Zugriff verloren », il s'agit du nom d'utilisateur et du système, pas de captures d'écran. Ce n'est pas de la cosmétique. C'est la différence entre un ticket qui peut être traité directement et un ticket pour lequel l'agent doit poser trois fois la même question.

Dans JSM, nous mettons cela en œuvre avec les Request Types et les champs conditionnels. La structure des catégories reste volontairement légère : nous constatons en pratique que davantage de catégories de premier niveau réduisent plutôt l'utilisation qu'elles ne l'augmentent. Qui veut tout proposer devient un moteur de recherche que personne n'utilise.

Dans ce blog, Anja donne encore d'autres insights sur le portail de service : Qui construit le portail de service et pourquoi c’est la question décisive

Le workflow Major Incident : quand ça brûle vraiment

Un Major Incident n'est pas la même chose qu'un incident ordinaire. Sont généralement concernés plusieurs services métiers, le temps est critique et plusieurs personnes travaillent en parallèle. Utiliser dans cette situation le même workflow que pour un mot de passe oublié fait perdre du temps.

Nous recommandons un workflow Major Incident dédié comportant quatre éléments :

• Notification automatique des groupes de parties prenantes définis (Business, Communication, Direction) lors du passage au statut Major.
• Un schéma de communication fixe, consigné dans le ticket lui-même et non réparti sur Teams ou Slack.
• Création automatique d'un Post-Incident-Review après la clôture.

Le passage au statut Major se fait par un bouton depuis le ticket d'incident normal. À condition que les critères aient été définis au préalable : à partir de quand un incident est-il un Major Incident ? Cette question est clarifiée avec le client au départ et enregistrée comme règle.

On-Call et Alerting : du monitoring directement à l'incident

Une alarme issue du monitoring ne sert à rien si elle arrive dans la mauvaise boîte. Jira Service Management connecte les systèmes de monitoring à la gestion des incidents. Les alertes entrantes sont acheminées vers la personne responsable selon les plannings d'astreinte ou de garde enregistrés et sont automatiquement escaladées si aucune réaction n'est constatée.

Deux points sont décisifs lors de la mise en place :

Le planning de garde doit refléter la réalité. Vacances, maladie, remplacements ou responsabilité partagée entre sites doivent être maintenus en permanence. Un plan d'astreinte obsolète fait que des alarmes critiques atteignent les mauvaises personnes ou restent sans réponse.

Les seuils d'alerte doivent être définis de manière réfléchie. Un système qui sonne en permanence crée de la fatigue d'alerte. Il est pertinent de démarrer avec des seuils clairement définis et de les optimiser progressivement en fonction de l'expérience opérationnelle.

Les alertes critiques peuvent automatiquement créer un incident dans Jira Service Management. Ainsi, un événement de monitoring devient immédiatement un incident avec des responsabilités claires, des workflows standardisés et une traçabilité complète.

Démarcation : ce que la gestion des incidents n'est pas

La gestion des incidents remet le service en service. Elle ne clarifie pas la cause. Cette séparation est importante car sinon cela mène à des tickets mélangés : un incident reste ouvert pour rechercher la root cause alors que le service fonctionne déjà à nouveau.

La règle est simple. Si le service fonctionne de nouveau, l'incident est fermé. Si une cause reste ouverte, un ticket problem est créé et lié à l'incident. À ce sujet, nous consacrerons un des prochains articles de cette série.

Questions fréquemment posées

Quelle est la différence entre Incident et Problem dans Jira Service Management ? Un Incident décrit l'impact : un service ne fonctionne pas comme prévu. Un Problem décrit la cause sous-jacente. Un Incident est fermé dès que le service est rétabli. Un Problem reste ouvert jusqu'à ce que la cause soit éliminée. Les deux sont représentés dans JSM comme des Issue Types distincts et liés entre eux.

Jira Service Management Standard est-il suffisant ?
Pour de nombreuses petites et moyennes équipes de service, JSM Standard est suffisant. Il offre la gestion des tickets, des workflows, des automatisations et des rapports de base. Cependant, si des fonctionnalités telles que la gestion d'incidents intégrée, l'alerte, les rotations d'astreinte/On-Call, les escalades ou des fonctions avancées de gestion des services sont nécessaires, JSM Premium ou Enterprise est généralement le choix approprié.

Comment mesure-t-on si la gestion des incidents fonctionne ? Les indicateurs centraux sont le Mean Time to Resolution (MTTR), la part des tickets résolus au premier contact (First Contact Resolution) et la part des Major Incidents escaladés. JSM fournit ces indicateurs out of the box dans le reporting.

Quelle est la situation en Suisse concernant la résidence des données ? Atlassian Cloud prend en charge l'option de localisation des données en Suisse. Pour les organisations soumises aux exigences du révisé Datenschutzgesetz (revDSG) ou du milieu régulé (FINMA, obligations cantonales), c'est la base d'une utilisation conforme. Swarmit accompagne la configuration et documente de manière vérifiable les réglages de data residency.

‍

Prochaines étapes

Pour situer objectivement l'état actuel de son Incident Management, un bon point de départ est un assessment : nous analysons la structure actuelle des tickets, examinons la conception du portail et identifions les leviers ayant le plus grand impact.