Système de tickets de service desk : ce que c'est et ce que ça coûte

Ce qu'est réellement un système de tickets de service desk

Je développe les intégrations chez eesel. Ce qui veut dire que mes journées se passent à lire les API de ces produits plutôt que leurs pages d'atterrissage, et c'est précisément là que l'écart entre les deux est le plus grand. La page d'accueil de chaque éditeur dit plus ou moins la même phrase sur la rationalisation du support IT. Ce que tu achètes réellement, c'est le modèle de données en dessous qui te le dit.

Commençons par la distinction qui compte. Un help desk répare ce qui est cassé. Un service desk livre aussi ce que les gens ont demandé. Cette seconde moitié est toute la raison pour laquelle cette catégorie existe, et le travail est structurellement différent : il te faut une liste publiée de choses commandables, puis un moyen de bloquer chacune derrière la bonne personne, plus un moyen de répartir le travail qui en résulte entre des équipes qui ne partagent pas de file d'attente.

Atlassian reconnaît avec une honnêteté rafraîchissante que la nomenclature est un désordre. L'entreprise cite une recherche de HDI qui trouve que 41 % des desks "portent un autre nom", et ajoute qu'il n'y a "aucune garantie que les service desks et help desks rapportés dans cette enquête HDI correspondent à nos descriptions". Donc n'achète pas sur le mot inscrit sur la boîte. Achète en fonction de si l'outil modélise une demande comme un objet de première classe, avec une entrée de catalogue, un approbateur et du travail dérivé, ou seulement comme un e-mail portant un champ de statut. La version longue de cet argument, je l'ai écrite séparément dans help desk vs service desk.

Une demande, trois numéros d'enregistrement

La façon la plus nette de voir la différence est d'observer ce qui arrive à une seule phrase.

« Mon ordinateur portable ne démarre pas » est un incident. Un enregistrement, un responsable, une résolution. « J'ai besoin d'un nouvel ordinateur portable » est une demande, et à l'intérieur de ServiceNow, cela devient trois enregistrements portant trois séries de numéros différentes. Il y a une Request (sc_request, préfixe REQ), le conteneur au niveau du panier pour un seul checkout. Il y a un Requested Item (sc_req_item, préfixe RITM), un par article de catalogue commandé. Puis les Catalog Tasks (sc_task, préfixe SCTASK), le travail d'exécution réel, que génère le flux de l'article. La propre référence de la Service Catalog API de ServiceNow montre une réponse de checkout qui porte "number": "REQ0010012" et "table": "sc_request", donc ce n'est pas du folklore.

Commande un ordinateur portable et un moniteur en un seul checkout, tu obtiens un REQ avec deux RITM. Chaque RITM peut engendrer plusieurs SCTASK, puisque l'approvisionnement, l'imagerie et l'expédition sont trois métiers différents. Une bizarrerie à signaler avant de construire des rapports : les réponses du catalogue ne vivent que sur le RITM. ServiceNow indique que « les variables ne sont associées qu'à la table Requested Item [sc_req_item] », ce qui explique pourquoi un technicien travaillant sur le SCTASK ne peut souvent pas voir ce que la personne a réellement demandé, sauf si quelqu'un l'a délibérément fait apparaître.

La raison de se soucier du nombre d'enregistrements n'est pas une question d'ordre. C'est que, selon les benchmarks MetricNet sur les tickets par technicien, la moitié demandes de ta file d'attente représente environ trois à cinq fois le travail de la moitié incidents, et le coût par ticket en découle : 113 $ par demande de service contre 48 $ par incident en support de bureau. Date ces montants de 2011, et traite le ratio, pas le montant, comme le chiffre durable.

Le catalogue, l'endroit où les éditeurs sont discrètement en désaccord

Chaque éditeur te vend « un catalogue de services ». Presque aucun n'entend la même chose par là, et les différences sont assez grandes pour changer quel outil tu achètes.

Jira Service Management n'a aucun produit de catalogue. Atlassian le dit directement : le modèle ITSM « est fourni avec un catalogue de services pour les demandes courantes. Celles-ci sont appelées types de demande », et tu consultes ton catalogue en allant dans les paramètres de l'espace, puis Gestion des demandes, puis Types de demande. Il n'existe aucun constructeur séparé. L'ancienne URL de documentation set-up-a-service-catalog renvoie une erreur 404, parce qu'une telle chose n'existe pas. Ce n'est pas automatiquement une mauvaise chose, et ça veut aussi dire qu'aucune barrière de plan ne pèse sur le catalogue, mais si tu arrives en espérant une expérience d'achat avec des catégories et des prix, tu seras surpris. Un administrateur a rapporté qu'on lui avait dit lors d'un appel de formation Atlassian que la liste devait rester petite :

"The answer that I got was like, 'You shouldn't have more than 8-10 requests in your help center so if they need unique workflows then it shouldn't be a problem.'"

u/Hefty-Possibility625, r/jira, Reddit

Huit à dix articles, c'est le volume d'un help desk. Ce n'est pas un catalogue d'entreprise. Que ça compte comme une recommandation ou comme un plafond structurel dépend de qui tu demandes, mais ça indique quand même où se situe le centre de gravité du produit.

Freshservice place le catalogue derrière son deuxième niveau. Un compte Starter à 19 $ par agent donne accès aux incidents, à la base de connaissances, aux tâches et à un portail, mais pas de catalogue ni d'articles de service, donc pas non plus de demandes de service générées depuis un formulaire de catalogue. Le catalogue démarre à Growth, 49 $, ce qui représente un bond de 158 % par rapport au prix d'entrée pour la seule fonctionnalité qui en fait un service desk. La gestion des SLA franchit la même ligne, et cela s'accumule, car les demandes enfants sont soumises aux « SLA correspondants ».

ManageEngine le facture à part. ServiceDesk Plus affiche 13 $ par technicien chez Standard, 27 $ chez Professional, puis vend le catalogue de services comme module complémentaire : 1 595 $ par an sur la grille des modules complémentaires cloud, ou 1 195 $ sur la grille annuelle. Ce n'est que chez Enterprise, à 67 $, qu'il est inclus. La CMDB coûte 1 595 $ de plus par an, réservée à Professional.

SolarWinds l'inclut dès le bas de gamme. Son Catalogue de Services et les Advanced Approval Workflows sont tous deux listés comme « Inclus » chez Essentials, chez Advanced et chez Premier, ce qui fait du plan Essentials à 39 $ la combinaison catalogue-et-approbations la moins chère et authentique de cette liste. Deux éléments liés à l'approbation restent verrouillés : Service Portal Tasks and Approvals, plus le Portal Designer. Les deux nécessitent Advanced.

ServiceNow l'inclut et te facture ailleurs. Service Catalog et Request Management se trouvent dans ITSM Foundation, le niveau de base, aux côtés d'Incident Management et d'Asset Management. La page de tarification ne comporte aucun chiffre en dollars et un seul bouton « Get Custom Quote », donc l'absence de barrière de plan sur le catalogue est une maigre consolation.

Halo regroupe littéralement tout. Un seul plan, 69 £ par agent et par mois facturé annuellement, et les workflows d'approbation, la CMDB, la gestion de projet et l'IA sont tous inclus dans le prix de base, avec la mention explicite « pas de niveaux, pas de modules complémentaires, pas de fonctionnalités verrouillées ». Le hic se trouve dans la note de bas de page. Les packs d'intégration sont obligatoires à l'achat, à un coût sur mesure, et le montant en dollars américains est injecté côté client, donc seul le prix en GBP s'affiche réellement.

Les approbations, l'étape qui décide à la fois de ton temps écoulé et de ta facture

Voici ma lecture honnête, après avoir développé contre la plupart de ces API : les approbations sont l'élément le moins étudié dans l'achat d'un service desk, et c'est là que se cachent à la fois le retard et la facture surprise.

Elles sont modélisées de façon complètement différente selon chaque éditeur. Dans Jira Service Management, une approbation existe comme une propriété de statut de workflow, pas comme un paramètre de formulaire. La documentation d'approbation de workflow d'Atlassian est franche : la case « Include approval step » n'est disponible que lorsque le statut porte déjà au moins deux transitions, une pour Approuver et une pour Refuser. L'approbation multi-étapes n'est donc pas vraiment une fonctionnalité du constructeur. C'est toi qui enchaînes plusieurs statuts porteurs d'approbation à la main. Le quorum est configurable, même si un refus reste absolu : si un approbateur refuse, l'élément de travail est refusé quel que soit le nombre que tu as défini.

Freshservice a remplacé son ancien modèle séquentiel par des groupes et chaînes d'approbation : quatre règles de groupe et quatre règles de chaîne, où les groupes s'exécutent en parallèle à l'intérieur d'une chaîne, mais une seule chaîne active à la fois. Encore sur l'ancien modèle ? Note la date. Freshservice dit que la dernière prolongation avant l'abandon des approbations legacy est en août 2026, « après quoi aucune autre prolongation ne sera accordée ». Cette migration a aussi une queue d'API assez désagréable. L'ancien endpoint à approbateur unique accepte un approbateur à la fois, et après la migration, chaque appel crée son propre groupe, avec la règle de chaîne par défaut sur « Tous les groupes doivent approuver », ce qui bloque silencieusement les approbations qui se validaient auparavant avec « n'importe qui ».

Passons maintenant à la partie commerciale, celle que je mettrais devant quiconque signe le contrat.

Sur Jira Service Management, les approbateurs sont gratuits. Atlassian le dit clairement : « les approbateurs n'ont pas besoin d'une licence Jira Service Management », ils doivent seulement être clients de l'espace de service.

Sur ServiceNow, ce n'est pas le cas. Les utilisateurs uniquement approbateurs tombent dans une classe comptée séparément, appelée Business Stakeholder. Le propre guide de licences d'un employé de ServiceNow explique comment ça fonctionne :

"Business Stakeholder (BSH): This one catches people off guard because it is measured across two separate tables - one for role assignment and one for approval activity. A user qualifies as a BSH if they hold an Approver role but hold no Fulfiller role. The moment a BSH user gains a Fulfiller-mapped role, they move out of BSH measurement entirely."

About ServiceNow Licensing Guide, ServiceNow Community

Si tes chaînes d'approbation acheminent vers soixante managers qui, autrement, ne touchent jamais un ticket, cette phrase-là, c'est ton budget. Et l'économie liée aux demandeurs gratuits disparaît complètement dès que tu ajoutes le bon portail employé, car des produits comme Employee Center Pro et HRSD facturent selon le modèle Unrestricted User, où chaque utilisateur actif de l'instance compte.

Les praticiens tombent là-dessus au moment où ils créent leur premier article de catalogue. En décembre 2025, un administrateur a posé la question évidente :

"I know I need the itil role for approvers to approve the requests, but, is that it? Isn't there like a 'lower' role that I can assign them that is enough for them to view the answers of the item and approve/reject the catalog task instead of assigning them the itil role?"

u/edoo_stuff, r/servicenow, Reddit

L'ancienne solution de contournement était l'approbation par e-mail, qui contournait complètement le rôle. Une réponse dans ce fil rapporte que cette porte se ferme : "Email approvals require the business stakeholder license to be assigned. This has come up for a ton of my clients recently." Donc tu ne peux pas concevoir une chaîne d'approbation ServiceNow sans d'abord chiffrer chaque personne qu'elle contient.

L'exécution, et la case à cocher qui transforme une demande en dix

Une fois l'approbation obtenue, l'outil doit répartir ce travail. C'est la couche que les acheteurs évaluent le moins et avec laquelle ils vivent ensuite le plus.

Le mécanisme de Freshservice est une seule case à cocher sur l'article de catalogue : « Créer des demandes enfants pour chacun des articles ci-dessus ». Laisse-la décochée, et chaque ligne d'article reste dans un seul ticket assigné à un agent, qui bascule ensuite chaque article sur Livré ou Annulé à la main. Coche-la, et chaque article devient un ticket enfant individuel avec System comme demandeur, routé vers le service qui en est propriétaire, chacun avec sa propre horloge SLA. L'exemple concret de Freshservice est un parent New Employee Hire qui engendre New CRM Account, Apple MacBook et Adobe Photoshop CS6 comme enfants.

Cette case à cocher est, pour moi, l'illustration la plus nette de toute cette catégorie. Un interrupteur, et c'est ça, la différence entre une boîte de réception partagée et un service desk.

Deux choses à ce sujet vont te mordre en production, et les deux figurent dans la propre documentation de Freshservice. Fermer un ticket parent ferme automatiquement chaque enfant lié, avec l'avertissement de « s'assurer que toutes les demandes de service enfants ont été satisfaites avant de fermer le ticket parent ». Ensuite il y a un plafond strict de 100 tâches sous une entité parente, ce qui semble généreux jusqu'à ce qu'une vague d'intégrations massives arrive.

L'équivalent chez ServiceNow est l'action Create Catalog Task à l'intérieur du flux de l'article, qui frappe un enregistrement sc_task par étape de travail. Jira Service Management, il faut le noter, ne comporte aucune répartition native de ce type. Tu obtiens un élément de travail par type de demande, et l'exécution multi-équipes est quelque chose que tu construis toi-même, avec de l'automatisation ou des sous-tâches.

Les actifs sont le second compteur que personne ne budgétise

Si un système de tickets de service desk suit ce qu'il distribue, alors il a besoin d'une CMDB, et cette CMDB vient avec sa propre grille tarifaire.

• Freshservice ne compte pas les appareils. Il facture plutôt des Asset Units, sa propre métrique de licence, que tu achètes par paquets de 500. Ni le prix du paquet ni l'allocation incluse par plan ne sont publiés nulle part sur cette page de tarification.
• SolarWinds parvient à être à la fois le plus explicite et le plus verrouillé derrière une demande de devis. La gestion des actifs IT est "disponible en achat additionnel", avec « prix des actifs disponible sur demande » écrit sur chaque carte de plan, et la règle de comptage est large : tout appareil capable d'accéder à un réseau compte dans ta limite d'actifs, « même si l'adresse IP n'est pas activement suivie ».
• Jira Service Management publie des allocations d'objets au lieu d'un prix : 5 000 chez Standard, 50 000 chez Premium et 500 000 chez Enterprise, avec un plafond global de 10 millions par-dessus. Dépasse la limite et les imports échouent. Assets est aussi réservé aux espaces gérés par l'entreprise, donc dans un espace géré par équipe, il n'y a pas de CMDB.
• ManageEngine facture les actifs IT gérés comme une seconde dimension simple à côté des techniciens, et sa page de tarification dit exactement ça : « Si tu utilises la gestion des actifs IT, tu paies selon le nombre d'actifs IT gérés. »
• Halo et ServiceNow incluent tous deux la CMDB dans l'offre de base, à un siège de 69 £ et à un devis non publié, respectivement.

Ce que coûte un système de tickets de service desk en 2026

Voici la comparaison que j'aurais voulu avoir sous la main quand j'ai commencé à lire ces pages de tarification. Chaque chiffre est un prix catalogue relevé sur la propre page de l'éditeur, vérifié le 31 juillet 2026.

Deux lectures de ce tableau valent la peine d'être formulées.

D'abord, le siège le moins cher et le catalogue le moins cher sont rarement le même produit. ManageEngine gagne sur le prix du siège, puis facture 1 595 $ par an pour ce qui en fait un service desk. Le vrai point d'entrée de Freshservice pour un catalogue est 49 $, pas 19 $. Zendesk joue le même coup avec 29 $ et 59 $. SolarWinds paraît cher à 39 $, jusqu'à ce qu'on remarque que le catalogue et le moteur d'approbation y sont déjà tous les deux inclus.

Ensuite, le prix du siège cesse de prédire ta facture au moment où tu actives l'IA ou les actifs. Quatre compteurs, pas un seul, et seul le premier figure en gros caractères sur la page de tarification.

La couche IA a son propre compteur, et l'unité compte plus que le tarif

Chacun de ces éditeurs vend désormais de l'IA sur le service desk, et chacun la comptabilise différemment. L'unité compte plus que le chiffre.

ServiceNow a publié sa grille tarifaire d'assists sous forme de PDF juridique public le 23 juillet 2026, ce qui en fait la plus transparente des grandes plateformes en ce moment. Les lignes pertinentes pour l'ITSM : un résumé d'incident vaut 1 assist, une recommandation d'approbation vaut 1, le préremplissage d'un formulaire de catalogue vaut 1, un sujet de Virtual Agent exécuté de bout en bout vaut 10, une commande de catalogue multi-tours vaut 10, et un workflow agentique vaut 25, 50 ou 150, selon le nombre d'outils qu'il touche. Les assists sont mutualisés au niveau du compte, entre production et sous-production. Un workflow se termine à l'achèvement, à 20 actions, ou après une heure d'inactivité, ce qui signifie que l'action 21 démarre un second workflow facturable.

À noter sur cet écran : le L1 Service Desk AI Specialist, celui qui résout réellement le volume de niveau 1, est réservé à Prime. Foundation et Advanced obtiennent l'IA assistive.

Freshservice compte des sessions, définies comme toute interaction qu'un utilisateur unique a avec l'agent IA dans une fenêtre de 24 heures, donc il facture la tentative, pas le résultat. Chaque licence Enterprise inclut 1 200 sessions par an, cent par mois, et le tarif de dépassement n'est publié nulle part. Freddy AI Copilot coûte 29 $ à part par agent et par mois chez Pro et chez Enterprise, ce qui fait grimper un siège Pro jusqu'à 128 $.

Jira Service Management fait tourner trois compteurs à la fois. Il y a des crédits Rovo inclus avec le siège, plus l'agent de service virtuel à partir de 0,30 $ par conversation assistée au-delà de 1 000 par mois, plus Rovo Customer Service à 1 $ par résolution. Le piège se trouve dans la définition d'« assistée » : Atlassian compte toute conversation associée à une intention, que l'agent la résolve ou l'escalade, donc un ticket escaladé est quand même facturé.

C'est la question d'achat résumée en une ligne. Un compteur de résolution te facture quand ça a fonctionné. Un compteur de sessions ou de conversations te facture quand ça a essayé.

Ce que disent honnêtement les benchmarks sur la déviation

Avant d'acheter quoi que ce soit sur la foi d'un chiffre de déviation, va d'abord te calibrer sur la recherche plutôt que sur le pitch commercial.

La base de benchmarking de MetricNet situe le taux moyen d'achèvement en libre-service des service desks à l'échelle mondiale à 10,4 %, avec une fourchette allant de zéro, pour les desks sans libre-service, jusqu'à un maximum de 55 %. Sa précédente passe avait trouvé 8,9 %, et notait que « la grande majorité de ces incidents auto-résolus sont des réinitialisations de mot de passe ». La résolution nette au premier niveau atteint en moyenne 74,3 %, tandis que seuls 1,4 % des service desks dépassent 95 %.

Dans cette même recherche, il y a un effet de second ordre que presque personne ne mentionne et que tout le monde ressent : à mesure que les tickets faciles sont déviés, « la complexité moyenne et le temps de traitement moyen des incidents qui continuent d'être traités par des agents en direct vont augmenter ». La déviation ne fait pas que réduire la file d'attente. Elle la concentre. Alors planifie tes effectifs en fonction du mélange plus difficile qui reste.

L'échelle d'escalade est la raison pour laquelle tout cela compte financièrement. MetricNet tarife le support de niveau 1 à 22 $ par ticket, le support de bureau à 62 $, le niveau 3 à 85 $, le support terrain à 196 $ et le support fournisseur à 471 $, et cette échelle est cumulative : un ticket enregistré au niveau 1 puis escaladé au niveau 2 coûte 62 $ plus 22 $, pas seulement 62 $. Date ces montants de 2011, et lis la conclusion comme durable : « maximiser le FLR équivaut à minimiser le TCO ».

Ce que disent vraiment ceux qui gèrent ces desks

Les pages des éditeurs ne te diront rien de tout ça, alors voici une lecture de praticiens sur les douze derniers mois.

Sur la question de savoir si un catalogue fonctionne, le test le plus tranchant que j'aie trouvé n'est pas du tout une fonctionnalité. C'est un chiffre que personne ne rapporte :

"Every incident/request should narrow down to an obvious CSI that an idiot in a hurry could categorise, consistently and repeatedly. If everyone is just hitting other, other, other then it's failed. Capital F."

u/gumbrilla, r/ITManagers, Reddit

Va vérifier quel pourcentage de tes demandes atterrit dans une case générique. Si c'est élevé, plus d'articles de catalogue ne t'aideront pas, et le routage par IA au-dessus d'une taxonomie que personne ne sait parcourir non plus.

Côté licences, le malentendu le plus coûteux de cette catégorie, c'est qui compte comme agent. Un acheteur Atlassian a publié ses propres chiffres à côté de ceux de son ingénieur cloud :

"What I think I need (for starters): $ 8500 / year

What the cloud engineer thinks I need (for starters): $ 40,750 / year

JSM Standard - 10 agents - annual cost $2000

Confluence Standard - 10 users - annual cost $ 500

Atlassian access - 200 users - $6.000 (this one hurts)

JSM Standard - 200 agents - annual cost $25,750

Confluence Standard - 200 users - annual cost $ 9000

Atlassian access - 200 users - $6.000" -- u/LooselySubtle, r/atlassian, Reddit

C'est un écart de 4,8x provoqué entièrement par le fait de savoir si 200 employés sont des agents ou des demandeurs. Règle cette question par écrit avant de comparer deux outils quels qu'ils soient.

Et sur l'IA : le fil le plus utile que j'ai lu cette année était celui d'un product designer de ServiceNow demandant à sa propre communauté des réussites Now Assist à utiliser comme références. Les réponses n'étaient pas ce qu'il espérait :

"These features all seem like things that make for a cool demo but don't actually save a company much time or money. Most of our closed incidents never get looked at again, and when they need to be looked at it's not particularly hard to read the history."

u/pnbloem, r/servicenow, Reddit

Une autre réponse dans ce même fil s'attaquait directement à l'affirmation de précision :

"There is a persistent belief in the big tech bubble that it can, but it simply isn't good enough. It's auto prediction on steroids. Traditional automation is far more effective than chained ai agents that are only 50% accurate."

u/paablo, r/servicenow, Reddit

Je vends de l'IA pour les files de support, et je trouve que cette réponse est fondamentalement juste. Le résumé et la rédaction sont les fonctionnalités qui font les meilleures démos et changent le moins de choses. Ce qui bouge réellement les chiffres d'un service desk, c'est l'ennuyeux : répondre correctement à la question répétée avant qu'un humain ne l'ouvre. Tout le reste est de la décoration sur une file d'attente qui reste de la même taille.

Ce que je vérifierais vraiment avant de signer

Après plus de trois ans à déployer des agents IA sur des files de support et IT en production, les questions que je poserais à un éditeur ne ressemblent en rien à une matrice de fonctionnalités.

1. Crée une demande d'intégration pendant l'essai. Pas une réinitialisation de mot de passe. Commande un ordinateur portable, un compte et un téléphone en une seule soumission, approuve-le en tant que deux personnes différentes, puis regarde combien d'enregistrements existent, et si tu peux voir en un coup d'œil quelle tâche d'exécution est encore ouverte.
2. Compte tes approbateurs, puis demande comment ils sont licenciés. Sur la plupart des outils, c'est gratuit. Sur ServiceNow, c'est une classe comptée, et sur ServiceNow, le bon portail employé te fait aussi basculer sur une facturation par utilisateur actif.
3. Demande ce que compte le compteur IA, par écrit. Session, conversation, assist ou résolution. Demande ensuite quel est le tarif de dépassement, car Freshservice et Zendesk publient tous les deux l'allocation mais pas le tarif.
4. Demande le prix des actifs. SolarWinds et Freshservice verrouillent tous les deux cette information derrière un devis. Ce n'est pas une petite ligne.
5. Vérifie le chemin d'export avant d'être enfermé. Freshservice n'a aucun export d'interface pour le catalogue ; la solution documentée est un appel API. Bien si tu as des ingénieurs sous la main. Terrible sinon.

Et une mise en garde honnête sur ma propre catégorie. L'IA dans un service desk n'est pas magique, et j'en ai les cicatrices pour le prouver. J'ai eu des clients payants, dont un fournisseur danois d'énergie solaire, dont le bot a inventé des réponses et les a envoyées à de vrais clients au moment où la base de connaissances n'avait pas de correspondance. C'est exactement pour ça que chaque déploiement eesel est d'abord simulé sur des tickets historiques, et pourquoi je ne ferais confiance à aucune affirmation de déviation, y compris la mienne, qui n'a pas été testée sur ton propre historique de tickets.

L'objection qui décide la plupart de ces achats, c'est le contrôle, pas le prix. Une responsable CX dans une marque de compléments alimentaires traitant environ 7 000 tickets par mois l'a mieux formulé que je ne pourrais le faire : l'IA ne répondra jamais à tout, mais si elle répond « désolé, je ne sais pas » à tout le reste, « je ne peux pas aller vérifier mes 7 000 tickets pour voir si l'IA a vraiment donné une bonne réponse, alors l'intérêt disparaît un peu ». Ce qu'ils voulaient, c'était une IA qui ne traite que ce dont elle est sûre, et qui laisse le reste tranquille. J'ai perdu ce contrat à cause du routage basé sur la confiance, et ça a rendu le produit meilleur.

Comment je choisirais en 2026

Si ta file d'attente est surtout du dépannage et que tu as moins de dix techniciens, commence avec le niveau Standard gratuit de ManageEngine ou Freshservice Starter, et saute complètement le catalogue jusqu'à ce que les demandes dépassent réellement les incidents en nombre. Acheter un catalogue qu'on ne remplit ensuite pas est le gaspillage le plus courant dans cette catégorie.

Si tu as besoin d'un vrai catalogue plus des approbations au prix honnête le moins cher, SolarWinds Essentials à 39 $ est le choix, parce que les deux sont dans le plan de base au lieu d'être revendus à part.

Si tu utilises déjà Atlassian, Jira Service Management est difficile à contester sur la structure de coût : demandeurs gratuits et illimités, approbateurs gratuits, 25 $ pour 1 à 15 agents. Sache simplement que la page de tarification règle sa calculatrice par défaut sur 75 agents, donc les 20 $ que tu vois sont un tarif mixte, pas un prix catalogue. Prévois de construire ton catalogue comme des types de demande, et ta répartition comme de l'automatisation.

Si tu es une grande entreprise avec de vraies obligations de gestion des changements et de CMDB, ServiceNow est le modèle le plus complet ici, et personne ne conteste sérieusement que le design d'incident, de changement et de CMDB est mauvais. La plainte porte sur le coût, les clics et les mois, pas sur le bien-fondé. Sa note G2 est de 4,5 sur 5 sur 1 915 avis, avec 70 % de cinq étoiles et zéro une étoile, ce qui n'est pas le profil d'un mauvais produit.

Et si ce que tu veux vraiment, c'est un seul prix sans rien de verrouillé, Halo est le seul éditeur ici à s'y engager, à condition de pouvoir vivre avec un coût d'intégration sur mesure et un chiffre publié seulement en GBP.

Mets eesel devant le service desk que tu utilises déjà

Rien de ce qui précède n'est une raison d'arracher ton système de tickets, et je ne le suggérerais pas. Ce qui change l'équation économique d'un service desk en 2026, ce n'est pas une file d'attente différente. C'est ce qui arrive à une demande avant même qu'un technicien ne l'ouvre.

C'est ce que je construis. eesel se branche sur le desk que tu as déjà, apprend de tes tickets passés et de tes documents existants dans Confluence, Slack, Google Docs ou une base de connaissances, puis répond aux demandes répétées en tant que premier répondant. Même type de travail, que la file d'attente soit orientée client ou IT interne.

Jason Loyola, Head of IT chez InDebted, l'exploite exactement sur ce type de desk :

"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."

Jason Loyola, Head of IT, InDebted

Son équipe se situe aujourd'hui à 15 % de déviation sur les tickets IT internes, avec un objectif de 55 %. J'aime citer le chiffre en cours plutôt qu'un chiffre terminé, parce qu'un déploiement de service desk est une montée en puissance, pas un interrupteur.

Deux choses font que ça correspond à ce problème précis. Le tarif n'a aucune dimension de sièges du tout : 0,40 $ par ticket traité, pas de frais par agent et pas de minimum, donc ajouter soixante approbateurs, ou mille demandeurs, ne te coûte rien. Et tu peux router une tranche plutôt que toute la file d'attente, c'est-à-dire le pointer vers les vingt questions répétées de catalogue qui dévorent ton temps de niveau 1 et laisser les approbations de changement tranquilles. Si tu utilises Jira Service Management, la connexion prend quelques minutes et c'est gratuit à essayer.