Tickets

Les tickets constituent la couche humaine de gestion du travail au-dessus de vos installations — l'endroit où l'investigation, l'attribution, la discussion et la résolution se déroulent réellement. Là où un événement est un signal détecté par la machine, un ticket est l'espace de travail dont votre équipe est propriétaire : qui s'en occupe, ce qui a été tenté, et comment cela se termine.

Concept de ticket

Vos installations génèrent automatiquement des événements — un arrêt réseau, un plafonnement de surproduction, un logger qui perd sa source. Ces événements sont délibérément légers : ils enregistrent quoi a été détecté, où, quand et quelle gravité. Ils ne sont pas le bon endroit pour suivre le travail qui s'ensuit.

Un ticket, c'est ce suivi. Vous ouvrez un ticket pour investiguer un problème, le confier à un collègue, rassembler notes et constatations dans un seul fil de discussion, lier les composants et les événements qu'il concerne, et le clôturer une fois la situation résolue. Chaque changement est consigné, de sorte que des mois plus tard vous puissiez reconstituer exactement ce qui s'est passé et qui a fait quoi.

Événements vs. tickets

Un événement est un signal détecté, généralement automatique et en lecture seule en tant qu'enregistrement. Un ticket est l'histoire humaine qui l'entoure : tri, attribution, commentaires et résolution. Les deux sont liés afin que le signal et le travail nécessaire à sa résolution restent connectés. Le titre et la description en texte libre que portaient les anciens événements sont en cours de retrait au profit des tickets — considérez l'événement comme le déclencheur et le ticket comme l'espace de travail.

Les tickets sont une sous-ressource d'installation : chaque ticket appartient à une installation, et votre accès à celui-ci découle de votre rôle sur cette installation plutôt que d'un paramètre distinct.

Ce que contient un ticket

Un ticket rassemble tout ce qui concerne un travail dans une vue unique :

Titre et description — un intitulé court accompagné du récit complet de ce qui est traité.
Catégorie — quel type de travail il s'agit (voir ci-dessous), afin que les tickets puissent être filtrés et triés par type.
Statut — où en est le travail dans son cycle de vie.
Assigné — la personne unique responsable du ticket. Toute réattribution est consignée.
Chronologie — une heure de début et de fin facultatives pour le travail, aux côtés des horodatages automatiques de création, de mise à jour et de clôture.
Commentaires — un fil de discussion où l'équipe résout le problème.
Mentions — impliquez un collègue dans un ticket avec une @mention ; il est notifié et suivi.
Liens — connexions vers les événements, les autres tickets et les composants que ce travail touche.
Flux d'activité — un historique complet et automatique de chaque modification apportée au ticket.

Tickets système

Certains tickets sont ouverts automatiquement par la plateforme plutôt que par une personne. Ils se comportent comme n'importe quel autre ticket — vous pouvez les commenter, les attribuer et les clôturer — mais ils sont signalés comme générés par le système, ce qui vous permet de repérer d'un coup d'œil quel travail la plateforme a mis en file d'attente pour vous.

Catégories de tickets

Chaque ticket porte une catégorie afin que votre équipe puisse classer et trier le travail selon le type de problème qu'il représente :

Catégorie	À utiliser pour
Maintenance	Entretien et maintenance planifiés ou de routine
Défaut	Un composant défaillant ou une panne d'équipement
Communication	Problèmes de connectivité ou d'acquisition de données avec une source
Arrêt	Travail lié à un arrêt de production réseau ou externe
Environnemental	Conditions liées à la météo, à l'encrassement, à l'ombrage ou à l'environnement
Informatif	Un enregistrement conservé à titre d'information, sans action requise
Général	Tout ce qui ne correspond pas aux catégories ci-dessus

Cycle de vie d'un ticket

Un ticket évolue à travers une séquence de statuts claire afin que chacun puisse voir où en est le travail :

Ouvert — créé et en attente d'un premier tri.
Détecté — le problème sous-jacent a été identifié et confirmé.
En cours — quelqu'un y travaille activement.
Clôturé — le travail est terminé et la situation est résolue.

Un ticket clôturé peut être rouvert si le problème réapparaît, de sorte qu'un problème récurrent conserve l'intégralité de son historique au même endroit plutôt que de générer un ticket neuf et déconnecté à chaque fois. La clôture et la réouverture sont toutes deux consignées dans le flux d'activité, avec l'auteur et la date.

Commentaires et mentions

Le fil de discussion est l'endroit où se déroule la résolution effective du problème. Toute personne qui traite un ticket peut :

Commenter pour consigner constatations, décisions et prochaines étapes.
Modifier ou supprimer ses propres commentaires — les commentaires modifiés et supprimés sont marqués plutôt que silencieusement modifiés, afin que la piste reste honnête.
Mentionner un collègue avec @ pour l'impliquer dans le ticket. La plateforme suit qui a été mentionné, par qui et quand, et notifie l'utilisateur mentionné.

Le ticket consigne également quels utilisateurs ont été notifiés à son sujet et lesquels l'ont vu, afin que vous sachiez si les bonnes personnes sont au courant d'un problème ouvert.

Relier la vue d'ensemble

Un ticket est rarement isolé. Vous pouvez le connecter au reste de la plateforme afin que le contexte suive le travail :

Liens d'événements — référencez les événements qui ont déclenché le travail ou s'y rapportent. Un événement d'arrêt réseau et le ticket de maintenance destiné à le corriger restent liés.
Liens de tickets — référencez d'autres tickets, afin de naviguer facilement entre des travaux liés ou dépendants.
Liens de composants — attachez les parties spécifiques de l'installation que le ticket concerne (un logger, un onduleur, un GAK, un string, un compteur d'injection ou un capteur d'irradiation), et recherchez dans les composants de l'installation pour trouver le bon. C'est le même modèle de liaison que celui utilisé par les événements, de sorte que la vue d'évaluation des composants et le ticket restent cohérents.

Partir d'un événement

Lorsqu'un événement nécessite une investigation ou une correction, ouvrez un ticket et liez-y l'événement. L'événement reste l'enregistrement objectif de ce que la plateforme a détecté ; le ticket porte l'assigné, la discussion, les mentions, les liens de composants et l'historique complet du travail.

Historique d'activité

Chaque ticket conserve un flux d'activité automatique — un audit chronologique de tout ce qui lui est arrivé. Vous n'avez jamais à le tenir à jour à la main ; la plateforme enregistre chaque action au fur et à mesure :

Création, clôture, réouverture et suppression.
Modifications de titre, de description, de catégorie et de statut — capturées avec l'ancienne et la nouvelle valeur.
Attribution, réattribution et désattribution.
Commentaires ajoutés, modifiés ou supprimés, et utilisateurs mentionnés.
Composants liés ou déliés, et événements ou autres tickets référencés ou déréférencés.

Ce flux est la source de vérité du ticket en matière de responsabilité : litiges de garantie, audits et revues post-incident s'appuient tous dessus, et il ne peut pas être discrètement réécrit après coup.

Trouver et consulter les tickets

Les tickets sont conservés comme enregistrement à long terme afin que vous puissiez gérer le travail quotidien et consulter l'historique ultérieurement :

Lister et filtrer — parcourez les tickets sur les installations auxquelles vous avez accès, filtrés par installation, catégorie, statut ou assigné, et triés pour faire remonter les plus récents ou les plus urgents en premier.
Vue détaillée — ouvrez n'importe quel ticket pour voir sa description, ses commentaires, ses événements et composants liés, le suivi des notifications et des consultations, et le flux d'activité complet.
Enregistrement historique — les tickets clôturés restent disponibles, conservant intacte l'histoire complète des travaux passés et des problèmes récurrents.

Accès et autorisations

Les tickets sont une sous-ressource d'installation, de sorte que l'accès découle de votre rôle de fonction sur l'installation parente — et non d'un paramètre distinct par ticket. Toute personne pouvant consulter une installation peut lire ses tickets. Au-delà, la plateforme distingue la responsabilité technique de la responsabilité commerciale :

Rôles techniques — les Exploitants et les Technical Manager (ainsi que les rôles d'organisation équivalents) obtiennent l'administration complète des tickets : créer, modifier, attribuer, commenter, clôturer, rouvrir et supprimer.
Asset Manager (Commercial) peut lire et créer des tickets, mais ne peut pas les clôturer, les rouvrir ni les supprimer — une supervision commerciale sans modifier l'état de résolution technique.
Spectateurs peuvent lire les tickets mais pas les modifier.

Les coopérateurs qui détiennent le rôle de fonction requis sur une installation partagée sont inclus aux mêmes conditions. Consultez le système d'autorisations pour le modèle de rôles complet.

Fonctionnalités connexes

Événements — les signaux détectés par la machine pour lesquels des tickets sont ouverts afin d'investiguer et de résoudre
Évaluation des composants — la vue de santé par composant vers laquelle les tickets renvoient
Système d'autorisations — les rôles de fonction qui régissent qui peut lire, créer et administrer les tickets
Rapports — la documentation périodique qui s'appuie sur les problèmes résolus et les pertes de production