Votre modèle de données pour la gestion des incidents

Jira Service Management
Votre modèle de données pour la gestion des incidents

Votre modèle de données pour la gestion des incidents

Ce modèle vous propose une méthode structurée pour réunir les données essentielles à l’analyse de votre processus de gestion des incidents. Il précise les attributs à recueillir et les activités à suivre, et vous guide concrètement dans l’extraction de ces informations depuis votre système source. Vous disposez ainsi des éléments nécessaires pour commencer à optimiser vos flux de travail de résolution des incidents.
  • Attributs recommandés à recueillir
  • Activités clés à suivre
  • Guide d’extraction pour Jira Service Management
Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Attributs de gestion des incidents

Voici les champs de données recommandés dans votre journal d’événements pour analyser en détail votre processus de gestion des incidents.
5 Obligatoire 6 Recommandé 12 Facultatif
Nom Description
Activité
ActivityName
Nom de l’événement ou du changement de statut survenu pour l’incident.
Description

L’activité correspond à une étape ou à un événement distinct du cycle de vie de la gestion des incidents, comme « Incident créé », « Incident attribué » ou « Résolution proposée ». Elle est généralement déduite des changements de statut ou des mises à jour consignées dans l’historique ou le journal des modifications du ticket Jira. L’analyse de l’ordre et de la durée de ces activités est au cœur du Process Mining : elle révèle le déroulement réel du processus, ses goulots d’étranglement et ses écarts.

Pourquoi est-ce important ?

Les activités constituent la base de la cartographie du processus et permettent de visualiser et d’analyser le cycle de vie des incidents.

Où trouver ces données

Dérivé de l’historique et du journal des modifications du ticket Jira, cet attribut recense les changements de statut et les mises à jour des principaux champs.

Exemples
Incident assignéDébut de l’enquêteIncident résolu
Heure de début
EventTimestamp
Date et heure exactes auxquelles l’activité a eu lieu.
Description

Cet attribut enregistre l’horodatage de chaque activité du cycle de vie de l’incident. Il permet de calculer les durées, les temps de cycle et les temps d’attente entre les différentes étapes du processus. Des horodatages précis rendent possibles une analyse détaillée des performances, le suivi des SLA et l’identification des goulots d’étranglement. Toutes les métriques de performance, comme le délai de résolution et la durée du diagnostic, sont calculées à partir de ces horodatages.

Pourquoi est-ce important ?

Les horodatages sont indispensables au calcul des métriques temporelles, à l’analyse de la durée du processus et à la détection des goulots d’étranglement.

Où trouver ces données

Il s’agit de la date de création associée à chaque entrée de l’historique ou du journal des modifications du ticket Jira.

Exemples
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
Identifiant de l’incident
IncidentId
Identifiant unique de chaque ticket d’incident dans Jira Service Management.
Description

L’identifiant de l’incident, souvent appelé clé de ticket dans Jira, est l’identifiant unique principal de chaque incident signalé. Il relie toutes les activités, tous les commentaires et tous les changements de statut associés, de la création à la clôture définitive. En Process Mining, cet identifiant est indispensable pour reconstituer le cycle de vie complet de chaque incident et analyser l’ensemble du processus.

Pourquoi est-ce important ?

Cet identifiant central permet de regrouper tous les événements associés dans un même dossier. Il constitue la base de toute analyse en Process Mining.

Où trouver ces données

Il s’agit du champ standard « Key » d’un ticket dans Jira Service Management (par exemple, « ITSM-123 »).

Exemples
INC-10234HELPDESK-5678OPS-9901
Dernière mise à jour des données
LastDataUpdate
Horodatage de la dernière actualisation des données depuis le système source.
Description

Cet attribut indique la date de la dernière mise à jour du jeu de données. Il permet aux personnes qui analysent le processus de savoir si les données sont récentes. C’est particulièrement important pour les Dashboards de suivi continu, qui nécessitent des informations à jour pour prendre des décisions en temps utile. En général, cette valeur est identique pour tous les événements d’un même lot d’extraction.

Pourquoi est-ce important ?

Indique si les données sont à jour, un élément important pour garantir la pertinence et la précision de l’analyse.

Où trouver ces données

Il s’agit de l’horodatage de l’extraction des données, ajouté lors de leur transformation.

Exemples
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
Système source
SourceSystem
Système d’où proviennent les données extraites.
Description

Cet attribut indique l’origine des données, ici Jira Service Management. Il est particulièrement utile lorsque l’analyse combine des données issues de plusieurs systèmes. La précision du système source garantit la traçabilité des données et facilite le diagnostic des problèmes de qualité ou d’extraction. Dans ce modèle, la valeur est fixe.

Pourquoi est-ce important ?

Cet attribut précise l’origine des données et en garantit la traçabilité, notamment lors d’analyses portant sur plusieurs systèmes.

Où trouver ces données

Cette valeur fixe doit être ajoutée lors de l’extraction des données.

Exemples
Jira Service ManagementJira Cloud
Date de création
CreatedDate
Date et heure de création initiale de l’incident dans le système.
Description

Cet attribut marque le début officiel du cycle de vie de l’incident. Il fournit l’horodatage de référence pour calculer les métriques globales, comme le délai total de résolution. La date de création reste fixe pour chaque incident et sert de point de départ à l’analyse de l’ensemble du dossier en Process Mining.

Pourquoi est-ce important ?

Sert de point de départ au calcul des temps de cycle de bout en bout et au suivi des SLA.

Où trouver ces données

Champ standard « Created » d’un ticket Jira.

Exemples
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
Date de résolution
ResolutionDate
Date et heure auxquelles l’incident a été marqué comme résolu.
Description

Cet attribut enregistre l’horodatage du premier passage de l’incident à un statut de résolution. Il marque la fin de la phase de traitement actif et sert de point final au calcul du délai de résolution. La comparaison entre la date de résolution et la date de création fournit la principale mesure de l’efficacité du processus. Elle contribue également à déterminer le respect des SLA.

Pourquoi est-ce important ?

Marque la fin du processus de résolution et permet de calculer le temps de cycle total ainsi que les performances des SLA.

Où trouver ces données

Champ standard « Resolved » d’un ticket Jira.

Exemples
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
Groupe d’affectation
AssignmentGroup
Équipe ou groupe chargé du traitement de l’incident.
Description

Le groupe d’affectation désigne l’équipe chargée de l’incident. Il peut s’agir d’un niveau d’assistance, comme « Assistance niveau 1 », d’une équipe spécialisée, comme « Exploitation réseau », ou d’une équipe de développement. L’analyse des changements de groupe d’affectation permet de comprendre les escalades et les transferts dans le processus. Elle sert à mesurer les performances des équipes, à repérer les goulots d’étranglement à leur niveau et à analyser les dépendances entre équipes.

Pourquoi est-ce important ?

Indispensable pour analyser les performances des équipes, le volume de traitement et la circulation du travail entre les différents niveaux d’assistance ou groupes spécialisés.

Où trouver ces données

Ce champ personnalisé dans Jira est souvent nommé « Team » ou « Assignment Group ». Il peut parfois être déduit des composants Jira ou des rôles du projet.

Exemples
Assistance niveau 1Équipe infrastructureAdministrateurs de bases de données
Priorité
Priority
Niveau de priorité attribué à l’incident, qui indique le degré d’urgence de sa résolution.
Description

La priorité détermine la rapidité avec laquelle un incident doit être traité. Elle combine souvent l’impact et l’urgence et influe directement sur les objectifs de SLA. L’analyse des incidents par priorité permet de vérifier si les incidents prioritaires sont traités plus rapidement que les autres et si les règles de priorisation sont appliquées de façon cohérente. C’est un critère essentiel pour filtrer et comparer les performances du processus.

Pourquoi est-ce important ?

Indispensable à l’analyse des performances des SLA et à la vérification de l’affectation des ressources aux incidents les plus importants.

Où trouver ces données

Champ standard « Priority » d’un ticket Jira.

Exemples
La plus élevéeÉlevéeMoyenneFaible
Responsable
Assignee
Utilisateur actuellement chargé du traitement de l’incident.
Description

Le responsable est l’agent ou l’utilisateur chargé de l’incident à un moment donné. Le suivi des changements de responsable permet d’analyser les transferts, de comprendre la répartition de la charge de travail et de déterminer qui intervient à chaque étape du processus. Cet attribut aide à répondre aux questions sur les performances individuelles et l’affectation des ressources au sein des équipes d’assistance.

Pourquoi est-ce important ?

Permet de suivre la charge de travail de chacun, de repérer les goulots d’étranglement liés à certains agents et d’analyser l’effet des transferts sur le délai de résolution.

Où trouver ces données

Champ standard « Assignee » d’un ticket Jira.

Exemples
John SmithEmily JonesAgentAssistance1
Statut
Status
Étape actuelle du cycle de vie de l’incident.
Description

Le champ de statut indique l’état actuel de l’incident dans le flux de travail défini, par exemple « Open », « In Progress », « Pending Customer » ou « Resolved ». Les changements de statut constituent la principale source utilisée pour générer le journal d’activités en Process Mining. L’analyse du temps passé dans chaque statut est essentielle pour repérer les goulots d’étranglement et comprendre à quelles étapes les incidents prennent le plus de temps.

Pourquoi est-ce important ?

Reflète directement l’avancement de l’incident et constitue la principale source pour repérer les étapes du processus et les temps d’attente.

Où trouver ces données

Champ standard « Status » d’un ticket Jira.

Exemples
En coursEn attente du clientRésoluFermé
Catégorie de cause profonde
RootCauseCategory
Classification de la cause profonde de l’incident.
Description

Cet attribut indique la raison fondamentale de l’incident, par exemple « Défaut logiciel », « Panne matérielle » ou « Erreur utilisateur ». Il est généralement renseigné après l’investigation et joue un rôle essentiel dans la gestion des problèmes et la prévention de futurs incidents. L’analyse des catégories de causes profondes permet de repérer les faiblesses systémiques et de définir les priorités d’amélioration. Une forte proportion de causes profondes « Inconnues » peut signaler la nécessité d’améliorer les procédures d’investigation.

Pourquoi est-ce important ?

Permet d’analyser les causes profondes et de passer d’une approche réactive à une approche préventive, en repérant et en traitant les sources des incidents.

Où trouver ces données

Il s’agit presque toujours d’un champ personnalisé dans Jira. Son nom et ses options dépendent fortement de la configuration propre à l’organisation.

Exemples
Erreur de configurationPanne réseauAnomalie logicielle
Comporte des reprises
IsRework
Indique si l’incident a fait l’objet de reprises, par exemple s’il a été rouvert.
Description

Cet attribut booléen calculé identifie les incidents renvoyés à une étape antérieure du processus, le plus souvent parce qu’ils ont été rouverts après leur résolution. Les boucles de reprise sont une source importante d’inefficacité et d’insatisfaction des clients. Cet indicateur permet de calculer facilement le taux de reprises et d’orienter l’analyse vers les raisons pour lesquelles les incidents ne sont pas résolus correctement dès la première fois.

Pourquoi est-ce important ?

Met en évidence les problèmes de qualité et les inefficacités du processus en signalant les incidents qui nécessitent des reprises, ce qui facilite directement leur analyse.

Où trouver ces données

Calculé en détectant des séquences précises de changements de statut dans le journal d’événements, par exemple « Resolved » -> « Reopened ».

Exemples
truefalse
Composant
Component
Système, application ou partie de l’infrastructure touché par l’incident.
Description

Les composants sont des sous-parties d’un projet Jira qui servent à regrouper les tickets, par exemple « Interface utilisateur », « Base de données » ou « API ». L’analyse des incidents par composant permet de repérer les parties d’un système les plus sujettes aux problèmes. Ces informations sont utiles à l’analyse des causes profondes et peuvent orienter les efforts d’amélioration du service ou de réduction de la dette technique.

Pourquoi est-ce important ?

Permet de filtrer et d’analyser les incidents selon le produit ou la partie du système touché, afin de repérer les points sensibles de l’environnement technologique.

Où trouver ces données

Champ standard « Components » d’un ticket Jira.

Exemples
Service d’authentificationDashboard de reportingApplication mobile
Déclarant
Reporter
Utilisateur ayant créé ou signalé l’incident initialement.
Description

Le déclarant est la personne, souvent un utilisateur final, ou un autre système qui a signalé l’incident en premier. L’analyse des incidents par déclarant peut aider à repérer les utilisateurs ou les services qui rencontrent fréquemment des problèmes. Elle permet aussi d’étudier les échanges, notamment lors d’activités comme « En attente du client » et « Réponse du client reçue ».

Pourquoi est-ce important ?

Permet d’analyser l’origine des incidents, de repérer les tendances liées à certains utilisateurs ou services et de comprendre les délais de réponse des clients.

Où trouver ces données

Champ standard « Reporter » d’un ticket Jira.

Exemples
Alice JohnsonBob Williamsmonitoring-tool@example.com
Délai cible de résolution
TimeToResolutionTarget
Durée cible du SLA pour résoudre l’incident.
Description

Cet attribut définit le délai maximal prévu pour résoudre un incident d’une priorité ou d’un type donné. Il sert de référence pour comparer le délai de résolution réel et déterminer si le SLA est respecté. Cette valeur est généralement définie de façon dynamique selon des règles qui tiennent compte de facteurs comme la priorité, la gravité ou le type de ticket. Elle est indispensable au suivi des performances des SLA dans un Dashboard.

Pourquoi est-ce important ?

Fournit la référence nécessaire pour mesurer le respect des SLA et calculer l’indicateur de taux de dépassement des SLA pour les incidents.

Où trouver ces données

Cette valeur est définie dans la configuration des SLA de Jira Service Management. Il faut identifier l’objectif concerné, par exemple « Délai de résolution ».

Exemples
4 h8 h3 j
Dépassement du SLA
SlaBreach
Indique si le délai de résolution de l’incident a dépassé l’objectif du SLA.
Description

Cet attribut booléen calculé indique si le délai de résolution de l’incident a dépassé le SLA « Délai de résolution ». Il vaut vrai si « IncidentResolutionCycleTime » est supérieur à « TimeToResolutionTarget ». Ce marqueur simplifie l’analyse et la visualisation : il permet de filtrer et d’agréger facilement les données pour calculer le taux global de dépassement des SLA. C’est la mesure de résultat principale du Dashboard de suivi des performances des SLA.

Pourquoi est-ce important ?

Fournit un résultat binaire clair pour évaluer les performances des SLA, calculer facilement les taux de dépassement et repérer les problèmes.

Où trouver ces données

Calculé comme suit : (« IncidentResolutionCycleTime » > « TimeToResolutionTarget »).

Exemples
truefalse
Gravité
Severity
Mesure de l’impact de l’incident sur l’activité.
Description

La gravité indique l’ampleur de l’impact d’un incident sur l’activité, depuis le problème touchant un seul utilisateur jusqu’à l’interruption d’un système critique. La priorité détermine l’ordre de traitement, tandis que la gravité renseigne sur l’impact global pour l’organisation. L’analyse par niveau de gravité permet d’évaluer le traitement des incidents les plus importants pour l’activité. Elle est souvent combinée à la priorité pour affiner l’analyse.

Pourquoi est-ce important ?

Donne une vision de l’impact sur l’activité et permet de centrer l’analyse sur les incidents qui perturbent le plus les opérations.

Où trouver ces données

Il s’agit généralement d’un champ personnalisé dans Jira, car il ne fait pas partie des champs standard du système. Consultez la configuration du projet Jira Service Management.

Exemples
CritiqueMajeureMineureNégligeable
Identifiant du problème associé
LinkedProblemId
Identifiant du ticket de problème associé à cet incident.
Description

Les incidents qui sont les symptômes d’un problème sous-jacent plus vaste sont souvent associés à un ticket de problème. Ce champ contient l’identifiant du problème correspondant. L’analyse de ces liens aide à comprendre les relations entre incidents et problèmes, à mesurer l’efficacité du processus de gestion des problèmes et à repérer les incidents récurrents qui nécessitent un correctif définitif.

Pourquoi est-ce important ?

Relie les incidents aux problèmes sous-jacents et permet d’analyser l’efficacité avec laquelle l’organisation traite les causes profondes pour prévenir de futurs incidents.

Où trouver ces données

Ces informations figurent dans la section « Issue Links » d’un ticket Jira.

Exemples
PROB-123PROB-456Aucun
Nombre de transferts
HandoffCount
Nombre de réattributions de l’incident à un autre groupe ou utilisateur.
Description

Cette métrique calculée compte le nombre de changements des champs « Assignee » ou « AssignmentGroup » au cours du cycle de vie de l’incident. Un nombre élevé de transferts peut révéler un processus inefficace, un faible taux de résolution dès le premier contact ou des lacunes dans les connaissances, et entraîner des délais de résolution plus longs. L’analyse de cet indicateur aide à améliorer le processus d’attribution et la collaboration entre les équipes.

Pourquoi est-ce important ?

Mesure les frictions et les inefficacités liées aux réattributions et aide à repérer les possibilités d’amélioration du processus.

Où trouver ces données

Calculé en comptant le nombre de modifications apportées au champ « Assignee » ou « AssignmentGroup » dans l’historique des modifications du ticket.

Exemples
015
Résolution
Resolution
Résultat final ou motif de résolution de l’incident.
Description

Le champ de résolution précise pourquoi un incident a été marqué comme résolu. Les valeurs courantes sont « Fixed », « Duplicate », « Won’t Do » ou « Cannot Reproduce ». L’analyse de la répartition des types de résolution renseigne sur la qualité des signalements et l’efficacité du processus de résolution. Par exemple, un grand nombre de résolutions « Duplicate » peut révéler un problème lors de la création ou du triage des incidents.

Pourquoi est-ce important ?

Précise l’issue de l’incident, aide à catégoriser les résolutions et fait ressortir les tendances dans la clôture des incidents.

Où trouver ces données

Champ standard « Resolution » d’un ticket Jira. Il est généralement renseigné lorsque le ticket passe dans une catégorie de statut « Done ».

Exemples
TerminéCorrigéDoublonNe sera pas corrigé
Type de demande du client
CustomerRequestType
Type précis de demande envoyée par le client via le portail de services.
Description

Ce champ classe les demandes du point de vue du client, telles qu’elles sont présentées sur le portail Jira Service Management (par exemple, « Signaler un problème système »). Il propose une catégorisation compréhensible par les utilisateurs, qui peut différer du type de ticket interne. Son analyse permet de mieux comprendre la façon dont les clients perçoivent et signalent les problèmes, et d’améliorer la conception du portail et les services proposés.

Pourquoi est-ce important ?

Présente les catégories d’incidents du point de vue du client, ce qui aide à analyser la demande et à améliorer son expérience.

Où trouver ces données

Champ « Customer Request Type », propre aux projets Jira Service Management.

Exemples
Obtenir de l’aide informatique > Signaler un problème systèmeE-mail > Demande d’accès
Type de ticket
IssueType
Type de ticket, par exemple incident, demande de service ou problème.
Description

Jira utilise les types de ticket pour distinguer les différentes catégories de tâches. Dans le cadre de la gestion des incidents, le type principal est « Incident », mais d’autres types, comme « Sous-tâche », peuvent aussi être pertinents. Cet attribut permet de filtrer le jeu de données pour ne conserver que les incidents et de centrer l’analyse en Process Mining sur le bon processus.

Pourquoi est-ce important ?

Permet de limiter l’analyse aux incidents et de les distinguer des autres types de travail, comme les demandes de service ou les changements.

Où trouver ces données

Champ standard « Issue Type » d’un ticket Jira.

Exemples
IncidentAssistance informatiqueAnomalie
Obligatoire Recommandé Facultatif

Activités de gestion des incidents

Voici les principales étapes et les jalons du processus à consigner dans votre journal d’événements pour découvrir et analyser avec précision vos flux de travail de résolution des incidents.
7 Recommandé 8 Facultatif
Activité Description
Début de l’enquête
Indique qu’un agent assigné a commencé à diagnostiquer activement l’incident. Cette étape est généralement déduite du passage du ticket d’incident de l’état « Open » ou « New » à « In Progress ».
Pourquoi est-ce important ?

Cette étape importante marque le début des efforts actifs de résolution. Mesurer le délai qui la précède aide à repérer les retards initiaux dans les files d’attente et les problèmes de disponibilité des ressources.

Où trouver ces données

Cette étape est déduite de l’historique des changements d’état du ticket. L’horodatage de l’événement correspond au passage à un état indiquant que le travail a commencé, par exemple « In Progress ».

Données à recueillir

Repérez l’horodatage du passage à l’état « In Progress ».

Type d’événement inferred
En attente du client
Indique que l’équipe d’assistance attend une information ou une action du client. Cet événement est déduit du passage à un état d’attente dédié, tel que « Waiting for customer ».
Pourquoi est-ce important ?

Il est essentiel d’isoler cette période de suspension pour mesurer précisément les SLA, car elle est souvent exclue du calcul du délai de résolution. Cela permet d’analyser les retards de réponse des clients.

Où trouver ces données

Cet événement est déduit de l’historique des changements d’état du ticket. Son horodatage correspond au passage à l’état « Waiting for customer » ou à un état similaire.

Données à recueillir

Repérez l’horodatage du passage à l’état « Waiting for customer ».

Type d’événement inferred
Incident clôturé
Correspond à la clôture administrative définitive du ticket d’incident, après résolution et vérification. Cet événement est déduit du passage à l’état « Closed ».
Pourquoi est-ce important ?

Il s’agit de l’événement final du processus. L’analyse du délai entre « Resolved » et « Closed » peut révéler des retards dans les tâches administratives de clôture ou dans la confirmation par l’utilisateur.

Où trouver ces données

Déduit de l’historique des changements de statut du ticket. L’événement correspond à l’horodatage du passage au statut final « Closed ».

Données à recueillir

Repérez l’horodatage du passage au statut « Closed ».

Type d’événement inferred
Incident créé
Marque le début officiel du cycle de vie de l’incident, lorsqu’un signalement est soumis et qu’un nouveau ticket est créé dans Jira. Cet événement est enregistré explicitement à la création d’un nouveau ticket de type « Incident » dans le système.
Pourquoi est-ce important ?

Il s’agit de l’événement de début principal du processus. Analyser le délai entre cette activité et la résolution est essentiel pour mesurer le temps de cycle global et le respect des SLA.

Où trouver ces données

Cet événement explicite est extrait de l’horodatage de création du ticket d’incident dans Jira. La création du ticket est consignée dans son historique.

Données à recueillir

Utilisez l’horodatage de création du ticket.

Type d’événement explicit
Incident réassigné
Cet événement survient lorsqu’un incident est transféré à un autre agent ou groupe après son assignation initiale. Il est déduit de toute modification du champ « Assignee » ou « Assigned Group ».
Pourquoi est-ce important ?

Le suivi des réassignations est essentiel pour analyser les transferts. Un nombre élevé de réassignations révèle souvent des inefficacités dans le processus, des lacunes dans les connaissances ou une mauvaise orientation initiale, qui retardent la résolution.

Où trouver ces données

Cet événement est déduit de l’historique du ticket en repérant toute mise à jour du champ « Assignee » après son premier renseignement. Chaque modification constitue un événement de réassignation.

Données à recueillir

Repérez les modifications ultérieures du champ « Assignee » après l’assignation initiale.

Type d’événement inferred
Incident résolu
Cette activité confirme que l’incident a été résolu et que le service est rétabli. Elle coïncide souvent avec le passage à l’état « Resolved ».
Pourquoi est-ce important ?

Il s’agit de la principale étape de réussite du processus. Le délai jusqu’à cette étape est l’indicateur clé le plus courant : le délai de résolution (TTR).

Où trouver ces données

Cet événement est déduit du passage à l’état « Resolved ». Dans de nombreux flux de travail, il correspond à l’événement « Résolution proposée » et marque le point principal de résolution.

Données à recueillir

Repérez l’horodatage du passage à l’état « Resolved ».

Type d’événement inferred
Résolution proposée
Cette activité indique qu’une solution a été trouvée et mise en œuvre, et que l’incident attend une confirmation ou une validation finale. Elle est déduite du passage à l’état « Resolved ».
Pourquoi est-ce important ?

Cette étape importante marque la fin du travail actif de l’équipe d’assistance. C’est souvent à ce moment que le décompte du SLA s’arrête.

Où trouver ces données

Cet événement est déduit de l’historique des changements d’état du ticket. Son horodatage correspond au passage à l’état « Resolved » ou à un état équivalent.

Données à recueillir

Repérez l’horodatage du passage à l’état « Resolved ».

Type d’événement inferred
Commentaire ajouté
Correspond à toute communication ou prise de notes lorsqu’un utilisateur ajoute un commentaire au ticket d’incident. Cet événement explicite est enregistré à chaque publication d’un commentaire.
Pourquoi est-ce important ?

L’analyse de la fréquence des commentaires peut éclairer les pratiques de communication, l’efficacité de la collaboration et la complexité des incidents. Elle peut aussi mettre en évidence les incidents qui nécessitent trop d’échanges.

Où trouver ces données

Il s’agit d’un événement explicite. Jira conserve chaque commentaire avec son horodatage et son auteur, dans l’historique des commentaires du ticket ou via l’API.

Données à recueillir

Utilisez l’horodatage de chaque commentaire ajouté au ticket.

Type d’événement explicit
Incident assigné
Cette activité correspond à l’assignation initiale de l’incident à un agent ou à un groupe d’assistance. Elle est enregistrée en repérant la première fois où le champ « Assignee » ou « Assigned Group » est renseigné.
Pourquoi est-ce important ?

Cette mesure porte sur le délai de première réponse et d’assignation, qui constitue un élément important des indicateurs SLA. Elle aide à repérer les retards avant le début de l’enquête.

Où trouver ces données

Cette étape est déduite de l’historique du ticket en repérant la première modification du champ « Assignee » dont la valeur précédente était « Unassigned ».

Données à recueillir

Repérez la première mise à jour du champ « Assignee » dans l’historique du ticket.

Type d’événement inferred
Incident priorisé
Correspond à la définition de la priorité ou de la gravité de l’incident, qui détermine son urgence et son impact sur l’activité. Cette étape est généralement déduite du premier renseignement ou de la première mise à jour des champs « Priority » ou « Severity » après la création du ticket.
Pourquoi est-ce important ?

Le suivi de la priorisation permet de vérifier si les incidents sont évalués rapidement et de manière cohérente. Un retard à cette étape peut avoir des conséquences directes sur le calcul des SLA et la répartition des ressources.

Où trouver ces données

Cette étape est déduite de l’historique du ticket, qui consigne les modifications de tous les champs. Recherchez la première mise à jour du champ « Priority » ou d’un champ personnalisé « Severity » après la création du ticket.

Données à recueillir

Repérez la première modification du champ « Priority » dans l’historique du ticket.

Type d’événement inferred
Incident rouvert
Correspond à la réactivation d’un incident précédemment résolu, parce que le problème s’est reproduit ou que la correction était inefficace. Cet événement est déduit du passage de l’état « Resolved » ou « Closed » à un état ouvert.
Pourquoi est-ce important ?

Les incidents rouverts mesurent directement la qualité de la résolution et constituent un indicateur majeur des reprises. Leur analyse aide à repérer les clôtures prématurées et les solutions inefficaces.

Où trouver ces données

Cet événement est déduit de l’historique des changements d’état du ticket. Il est consigné lorsque le ticket passe d’un état final, tel que « Resolved » ou « Closed », à « Open » ou « In Progress ».

Données à recueillir

Repérez le passage de l’état « Resolved » ou « Closed » à un état ouvert.

Type d’événement inferred
Lié à un ticket de problème
Cet événement survient lorsqu’un incident est lié à un ticket de type « Problem » pour analyser sa cause première. Il est enregistré explicitement à la création d’un lien « relates to » ou « caused by » vers un ticket de type « Problem ».
Pourquoi est-ce important ?

Le suivi de ce lien est essentiel pour comprendre dans quelle mesure l’organisation passe efficacement de l’atténuation de l’incident à l’analyse des causes premières et à la prévention.

Où trouver ces données

Il s’agit d’un événement explicite consigné dans l’historique des liens du ticket. Chaque création de lien est horodatée et peut être filtrée pour les liens vers des tickets de type « Problem ».

Données à recueillir

Utilisez l’horodatage de création d’un lien vers un ticket de type « Problem ».

Type d’événement explicit
Réponse du client reçue
Indique que le client a fourni les informations demandées et que l’incident peut être traité à nouveau. Cet événement est déduit du passage de l’état « Waiting for customer » à un état actif.
Pourquoi est-ce important ?

Cette activité marque la fin d’un délai imputable au client. L’analyse du temps écoulé entre « En attente du client » et cet événement révèle le délai moyen de réponse des clients.

Où trouver ces données

Cet événement est déduit de l’historique des changements d’état du ticket. Il survient lorsque le ticket passe de « Waiting for customer » à un état tel que « In Progress », souvent après l’ajout d’un commentaire par le client.

Données à recueillir

Repérez le passage de l’état « Waiting for customer » à « In Progress ».

Type d’événement inferred
Solution de contournement fournie
Correspond à la mise en place d’une solution temporaire pour rétablir le service pendant l’élaboration d’une solution définitive. Cet événement peut être déduit d’un changement d’état ou d’un commentaire précis.
Pourquoi est-ce important ?

Le délai de mise en place d’une solution de contournement est un indicateur clé de la rapidité de rétablissement du service. Il permet de distinguer une mesure temporaire d’atténuation d’une résolution définitive.

Où trouver ces données

Cet événement est souvent déduit. Il peut correspondre au passage à l’état « Workaround Provided » ou à l’ajout d’un commentaire public contenant des mots-clés précis, comme « workaround ».

Données à recueillir

Repérez un changement d’état précis ou un mot-clé dans un commentaire.

Type d’événement inferred
Transféré à une équipe spécialisée
Indique que l’incident a été transmis à une équipe spécialisée, par exemple l’assistance de niveau 2 ou l’équipe de développement, pour une prise en charge avancée. Cet événement est déduit d’une modification du champ personnalisé « Support Team » ou d’une réassignation précise.
Pourquoi est-ce important ?

Cet indicateur met en évidence les incidents qui nécessitent des compétences spécialisées et suit les transferts entre les différents niveaux d’assistance. Il aide à repérer les goulots d’étranglement au sein des équipes spécialisées et à analyser les pratiques d’escalade.

Où trouver ces données

Cet événement est déduit de l’historique du ticket en suivant les modifications d’un champ personnalisé qui indique l’équipe assignée, ou en repérant une modification du champ « Assignee » vers un membre d’une équipe spécialisée connue.

Données à recueillir

Repérez une modification du champ personnalisé « Assigned Team » ou une modification précise du champ « Assignee ».

Type d’événement inferred
Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Jira Service Management

Prêt à commencer ?

Utilisez ce modèle de données pour améliorer la gestion de vos incidents, repérer les inefficacités et réduire les délais de résolution. Commencez dès aujourd’hui à optimiser votre processus.

Optimisez la gestion des incidents et résolvez-les plus rapidement

Réduisez le MTTR de 35 % et améliorez la satisfaction des utilisateurs grâce à des processus optimisés.

Démarrez l’essai gratuit

Aucune carte bancaire requise • Configuration en 5 minutes