Ticketing ou ITSM : la question revient dès qu'un contrat de service se met en place, centre de services, tierce maintenance applicative ou support. Le ticketing est une fonction : enregistrer une demande et la suivre jusqu'à sa clôture. L'ITSM est une façon d'organiser un service informatique, ses incidents, ses changements et ses niveaux de service. Aucun des deux n'a pour objet principal le contrat lui-même : son volume, ses comités, ses décisions et les projets qui l'entourent. Ce guide dit où passe chaque ligne.
Trois objets différents, que l'on confond parce qu'ils vivent souvent dans la même équipe et sous le même contrat.
La demande unitaire : un ticket, son état, sa priorité, son responsable, son historique, jusqu'à sa résolution. C'est un outil de file et de traçabilité. Un ticketing projet comme Jira, Redmine ou GitHub Issues trace les demandes et les problèmes remontés sur un projet.
Le service informatique de bout en bout : incidents, demandes de service, problèmes, changements, catalogue de services, base de connaissances, niveaux de service, souvent les actifs informatiques. Le ticketing y est une fonction parmi d'autres, au service de processus décrits par un référentiel comme ITIL.
L'engagement qui entoure le service : le contrat de maintenance, son volume et son comité, les projets d'évolution et leurs jalons, les risques, les décisions et les actions, la charge de l'équipe, et ce que le client suit et valide. Il ne trace pas de tickets.
Un ticket est un enregistrement : quelqu'un demande quelque chose, ou signale que quelque chose ne marche pas, et la demande devient traçable. Un logiciel de ticketing sait recevoir ces demandes, les classer, les affecter, les relancer et les clore. Atlassian, qui édite Jira et Jira Service Management, le dit en une phrase : les systèmes de ticketing informatique ne sont qu'un aspect de l'ITSM.
L'ITSM, la gestion des services informatiques, est d'un autre ordre. IBM la définit comme la pratique qui consiste à planifier, mettre en œuvre, gérer et optimiser la prestation de bout en bout de services informatiques, pour répondre aux besoins des utilisateurs et aux objectifs de l'organisation, et rappelle qu'ITIL en est le cadre de référence le plus répandu. Un ITSM organise donc des processus : rétablir un service après un incident, traiter la cause d'incidents répétés, faire passer un changement sans casser la production, tenir un catalogue et mesurer des niveaux de service.
Il existe ainsi deux ticketings, qui servent des besoins différents. Le ticketing projet trace les demandes et les problèmes d'un projet ou d'un produit : une anomalie trouvée en recette, une évolution demandée, une tâche technique. Le ticketing d'incidents, au sein d'un ITSM, sert le maintien en condition opérationnelle, le support et l'exploitation. Sur ce site, « ticketing » désigne le premier, et l'on écrit « ITSM » pour le second.
« Famille » désigne l'outil dont c'est le centre ; la dernière colonne dit où les périmètres se touchent, et ce qui dépend de l'éditeur.
| Besoin | Famille | pylotik | Chevauchement ou limite |
|---|---|---|---|
| Recevoir, affecter et suivre une demande | Ticketing projet, ITSM | Non La demande reste dans son outil | Un ticketing projet porte souvent aussi des tâches ; pylotik ne trace pas de tickets |
| Incidents, problèmes, changements | ITSM | Non | Les projets de remédiation ou de migration qui en découlent sont des projets, que pylotik porte |
| Catalogue de services, base de connaissances | ITSM | Non | Le « catalogue » d'un contrat dans pylotik est autre chose : les types d'intervention autorisés sur ce contrat |
| Niveaux de service, délais, pénalités | ITSM, ou l'outil du contrat | Non Ni niveaux de service ni pénalités calculés | Le rapport de niveaux de service vient de l'ITSM ; le comité tenu dans pylotik en arrête les décisions |
| Portail où le client dépose ses demandes | ITSM | Non | Le client suit et valide dans pylotik ses projets et ses contrats, pas ses tickets |
| Volume du contrat : consommé, engagé, restant | Selon l'ITSM ou l'ERP | Oui En jours, décompté à chaque intervention validée | Les unités d'œuvre propres à un contrat se mesurent dans l'outil qui les compte |
| Comité du contrat, compte rendu validé par le client | Rarement le centre d'un ITSM | Oui Indicateurs figés à chaque séance, compte rendu validé ou refusé | Certains ITSM proposent des rapports de service ; la validation du compte rendu par le client est à vérifier |
| Évolutions livrées avec jalons et recette | Gestion de projet, ticketing projet | Oui Un projet, ses jalons, ses risques, son contrat | Le détail technique des anomalies de recette peut rester dans le ticketing projet |
| Charge d'une équipe partagée entre support et projets | PSA ; l'ITSM voit la file, pas le reste | Oui Plan de charge, temps à la semaine, alertes de surcharge | L'ITSM voit le temps passé sur les tickets ; pylotik voit la charge de l'équipe sur les projets et les interventions |
| Marge du contrat | PSA, ERP | Oui Forfait ou temps passé, commandé, facturé, payé | La facture reste émise par l'ERP |
Un intégrateur maintient l'application de gestion d'un client : un volume de jours par an, un support aux utilisateurs, des évolutions livrées en versions, un comité mensuel avec le client.
Les incidents des utilisateurs, qualifiés et priorisés ; les demandes de service ; les délais de prise en charge et de résolution mesurés contre les niveaux de service ; les changements à déployer. C'est la bonne place pour tout cela, et rien ne justifie de le déplacer.
Le volume du contrat déjà consommé, et ce qu'il en reste pour le trimestre. Trois évolutions demandées en comité qui attendent un arbitrage. Une version en retard parce que les données de recette du client ne sont pas livrées. Un consultant clé, à cheval sur ce contrat et sur un projet au forfait, qui ne tiendra pas les deux.
Côté familles, les périmètres varient beaucoup d'un éditeur à l'autre. Selon le produit et ses modules, un ITSM couvre aussi la gestion de projets, un portail client complet, des rapports de niveaux de service ou des contrats ; un ticketing projet peut porter des tableaux, des feuilles de temps ou des approbations. Ce guide décrit des familles, pas des produits : chaque fonction se vérifie sur la documentation de l'outil considéré. Pour Jira en particulier, voir le comparatif pylotik vs Jira, et pour le contrat lui-même, la gestion des contrats de maintenance.
Le ticket est l'enregistrement d'une demande. Le ticketing est l'outil, ou la fonction, qui reçoit les tickets et les suit jusqu'à leur clôture. L'ITSM est la discipline qui organise un service informatique de bout en bout, incidents, problèmes, changements, catalogue et niveaux de service, et qui s'appuie sur un ticketing parmi d'autres fonctions.
Jira est un outil de suivi de tickets et de gestion de projet agile, centré sur le travail des équipes logicielles et techniques. L'offre ITSM d'Atlassian est un produit distinct, Jira Service Management, avec son portail client et ses niveaux de service.
Non. Il ne calcule ni niveaux de service ni pénalités. Il tient le contrat de maintenance, son volume, son catalogue et son comité, où le rapport de niveaux de service produit par l'ITSM se discute et où les décisions se consignent.
Aucun échange de données n'est en place par défaut. Les connecteurs de pylotik sont optionnels et se réalisent selon les besoins des clients, à partir du palier Business : un échange avec un ITSM se définit donc pour un cas d'usage précis, d'après les données utiles et les interfaces disponibles.
Oui, c'est l'un des modes où il sert le plus : des dates perçues comme dues, des comités, des évolutions à livrer, une équipe partagée. La file des tickets et la mesure des niveaux de service restent dans l'ITSM ; pylotik porte le contrat, le comité, les décisions, les projets et la charge de l'équipe.
Ses tickets, non : ils restent dans le portail de l'outil ITSM ou du ticketing. Dans pylotik, avec un accès gratuit, il suit ses projets et ses contrats, lit les indicateurs figés au dernier comité, et valide ou refuse les comptes rendus, les interventions et les avenants.
Page mise à jour le . Sources consultées à cette date ; ce que fait pylotik est décrit d'après le produit en service à la même date.
Une démonstration sur un jeu de données déjà rempli : un contrat de maintenance, son comité et son compte rendu validé, un projet d'évolution, et la charge d'une équipe partagée.