Configuration des modules
Tickets
Le cœur de la gestion des services, tickets, incidents, demandes. Les modèles pilotent les questions affichées, les types relient workflow et SLA, le routage trouve le bon groupe de travail.
Mis à jour le 18 mai 2026
Configuration · Modules · 4.9
Le module Tickets est le moteur derrière chaque signalement, incidents, demandes de service, questions de base de connaissances, demandes de changement. Trois objets travaillent ensemble ici : le type de ticket pilote workflow et SLA, le modèle de ticket décide des questions que voit le demandeur, et le routage le délivre au bon groupe de travail.
Pourquoi cela compte pour l’entreprise
"Les tickets restent bloqués"
SLA par type de ticket + règles d'escalade, personne ne peut les "oublier".
"Le demandeur oublie la moitié"
Le modèle de ticket impose les champs obligatoires avant la création.
"Mauvaise équipe le reçoit"
Règle de routage sur catégorie/lieu/asset, affectation automatique du groupe de travail.
"Les statuts ne disent rien"
Workflow par type de ticket : "En cours · En attente client · Prêt pour revue · Clôturé", plus de "ouvert" flou.
Les trois objets de configuration
Type de ticket
Catégorie du ticket : Incident · Demande de service · Changement · Question de connaissance · Réclamation. Pilote workflow (voir Briques → Workflows) et SLA.
Modèle de ticket
Quelles questions vont au demandeur, exemples : "Portable cassé" demande le numéro d'inventaire, "Problème de salle" demande la salle. Réduit le texte libre.
Règles de routage
Condition vers groupe de travail. "Catégorie = matériel IT → groupe IT-L1". Empilables avec un fallback.
Champs standard sur un ticket
| Champ | À quoi ça sert |
|---|---|
| Titre et description | La question ou le problème. L'IA s'en sert pour faire des suggestions. |
| Demandeur | Qui a créé le ticket. Peut différer de l'utilisateur final (par exemple la réception le saisit pour autrui). |
| Type de ticket | Pilote workflow et SLA. |
| Classification | Catégorisation hiérarchique (voir Briques → Classifications). |
| Priorité | Impact × urgence (matrice) ou libre, convenu en 4.6. |
| Groupe de travail / traitant | Qui le prend en charge. Dérivé via routage ou défini explicitement. |
| CI / lieu associé | Quel asset ou salle est concerné. |
| Statut et horloge SLA | Statut issu du workflow ; le SLA affiche le temps restant, se met en pause sur "En attente client". |
| Pièces jointes et communication | Captures, photos, fils d'e-mails, tout sur la même timeline. |
Quelles décisions allez-vous prendre ?
Quels types de tickets distinguez-vous ?
Gardez peu, 3 à 6 types. Trop = personne ne choisit correctement.
Modèles libres ou guidés ?
Modèle d'abord pour les flux spécifiques (portable cassé, demande de badge). Saisie libre pour "autre" avec routage sur classification.
Qui définit la priorité ?
Le demandeur (rapide, sujet au "tout est P1") ou automatique via matrice (structuré, nécessite de la formation).
L'utilisateur final peut-il clôturer son propre ticket ?
OK pour les demandes de service ; pour les incidents généralement le traitant, ce qui garde le contrôle sur les métriques de temps de résolution.