Claude pour Jira Service Management : quatre outils JSM, aucun pour les tickets

Atlassian a fait ce que tout le monde promet encore

Je construis des agents IA chez eesel, ce qui signifie en pratique que je lis les spécifications d'outils des autres pour gagner ma vie. La question « puis-je pointer Claude vers notre helpdesk » a été de loin la plus fréquente dans ma boîte de réception cette année. La réponse est généralement une variante de non.

Quand j'ai vérifié Claude pour Zendesk, ce que Zendesk avait livré était un client MCP, pas un serveur. Freshdesk se cache derrière un programme d'accès anticipé. Gorgias n'a même pas de fiche marketplace pour ça. Help Scout a bien livré un vrai serveur, puis l'a rendu en lecture seule, délibérément.

Atlassian, lui, l'a tout simplement construit. Sur la page Rovo MCP, il y a une grille de clients IA, et Claude en fait partie, aux côtés de Cursor, VS Code et ChatGPT. Le texte le dit directement : restez dans le flux, « que vous ayez besoin de contexte Atlassian dans Claude ». Un éditeur qui oriente ses propres clients vers le modèle de quelqu'un d'autre, volontairement, sur sa propre page marketing.

Le modèle d'accès est aussi inhabituellement généreux. Le FAQ d'Atlassian dit lui-même « Tous les clients Atlassian Cloud ont accès ». Votre plan ne change que le débit : les sites Free obtiennent 500 appels par heure, Standard 1 000, et Premium ou Enterprise obtiennent 1 000 plus 20 par utilisateur, jusqu'à un plafond de 10 000. Aucun abonnement Rovo n'est requis non plus, car comme le dit Atlassian, le serveur « n'est pas un modèle IA, c'est une couche d'intégration ».

Cet article n'est donc pas un règlement de comptes. C'est ce que j'aurais aimé qu'on me dise avant de passer un après-midi à m'attendre à un service desk et à me retrouver avec un simple traceur de tâches.

Les quatre façons de connecter Claude à Jira Service Management

Il existe quatre voies. Elles se classent selon un axe qui compte plus que tous les autres réunis : la capacité, ou non, à mettre des mots devant la personne qui a soulevé le ticket.

La forme de ce graphique résume tout l'argument. La voie instantanée, officielle et gratuite est justement celle qui ne peut pas répondre à un demandeur. Le même compromis que j'ai trouvé chez Help Scout, même si Atlassian y arrive par un chemin différent. Help Scout a délibérément livré du lecture seule. Atlassian a livré de l'écriture, puis ne l'a jamais dirigée vers le service desk.

Voie 1 : le serveur officiel, de bout en bout

Le endpoint est une seule chaîne :

https://mcp.atlassian.com/v1/mcp/authv2

Un avertissement, avant de copier une ancienne configuration trouvée quelque part. Atlassian a supprimé l'ancien transport SSE : après le 30 juin 2026, https://mcp.atlassian.com/v1/sse n'est plus pris en charge. Cette date est déjà passée. Donc si vous avez hérité d'une configuration du billet de blog d'un collègue publié au printemps, elle est morte, et le symptôme ressemblera plutôt à un échec d'authentification qu'à une dépréciation.

Pour Claude Code, c'est une seule commande :

claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2

Puis /mcp pour exécuter le flux OAuth. Dans Claude Desktop, le chemin est Settings, Extensions, Browse extensions, Plugins, recherche Atlassian. Et sur claude.ai, la fiche Atlassian figure dans l'annuaire des connecteurs, décrite comme lecture et écriture, construite par Atlassian.

Un détail d'implémentation piège les gens dès le tout premier appel. Chaque outil veut un cloudId, et le moyen d'en obtenir un est getAccessibleAtlassianResources, qu'Atlassian décrit comme un premier appel obligatoire pour n'importe quel outil. Sautez-le, laissez Claude tirer directement sur searchJiraIssuesUsingJql, et l'erreur qui revient ressemble à un problème de permissions. Ce n'en est pas un.

L'autre chose à savoir dès le premier jour : Claude atteint votre serveur MCP depuis l'infrastructure d'Anthropic, jamais depuis votre ordinateur portable. Vrai même dans Claude Desktop. Donc si votre site Atlassian est derrière une liste blanche d'IP, les appels d'outils échoueront tandis que l'écran de consentement OAuth continuera d'apparaître sans problème, ce qui est probablement le mode d'échec le plus déroutant qui soit.

Voie 2 : les quatre outils JSM, et la barrière du jeton devant eux

Passons maintenant à la partie qui m'a fait m'arrêter et relire la page deux fois.

Atlassian publie environ 46 outils, répartis en 13 groupes de permissions. Jira en obtient 14. Confluence en obtient 12, Bitbucket aussi 12, Compass 10. Jira Service Management en obtient quatre :

Chacun de ces outils vit du côté opérations, la partie de JSM qui descend de l'alerte d'astreinte. Aucun ne touche au service desk. Il n'existe aucun outil publié pour les demandes, les types de demande, les files d'attente, les SLA, les approbations, les clients du portail ou la configuration du portail.

Et une seconde barrière se dresse même devant ces quatre-là. La page des outils pris en charge d'Atlassian indique que les outils JSM « ne prennent en charge que l'authentification par jeton API » et ne sont « disponibles que si l'authentification par jeton API a été activée par l'administrateur de votre organisation ». Or OAuth est le flux par défaut, et le flux recommandé. Le résultat pratique pour la plupart des gens, donc : une connexion Claude normale n'affiche aucun des outils JSM, et rien dans l'interface n'explique pourquoi.

Compass, pour sa part, fonctionne selon la règle inverse : OAuth uniquement, pas de jeton API. Bitbucket veut un jeton API et un espace de travail lié. Trois produits, trois règles d'authentification différentes, tout ça dans un seul serveur.

Ce que vous pouvez réellement atteindre dans un service desk

Rien de tout cela ne signifie que Claude est aveugle à vos tickets. Un projet JSM est un projet Jira en dessous, donc les outils Jira génériques fonctionnent dessus. getVisibleJiraProjects, getJiraIssue, searchJiraIssuesUsingJql, getTransitionsForJiraIssue, transitionJiraIssue, editJiraIssue et addCommentToJiraIssue opèrent tous sans problème sur les éléments de travail JSM.

Cette distinction compte plus qu'elle n'en a l'air. La documentation d'Atlassian elle-même est directe sur ce qu'apporte un type de demande : « Si vous créez un élément de travail sans type de demande, vos demandes n'auront pas accès à toutes les fonctionnalités de Jira Service Management. » Claude regarde la couche Jira sous le service desk, pas le service desk lui-même. Là où vos agents voient une demande avec une horloge SLA, une file d'attente, un portail et un client rattaché, Claude voit un élément de travail.

La version la plus tranchante de cet écart concerne les commentaires. Dans l'API du service desk, la visibilité côté client se résume à exactement un booléen sur le corps du commentaire :

POST /rest/servicedeskapi/request/{issueIdOrKey}/comment
{ "body": "Hello there", "public": true }

public: true est une réponse que le demandeur voit sur le portail. public: false est une note interne, réservée aux agents. Pas de endpoint séparé, pas d'objet de visibilité, juste l'indicateur. Et l'outil MCP addCommentToJiraIssue ne comporte aucun paramètre équivalent dans sa description publiée, ce qui signifie que Claude n'a aucun moyen d'indiquer si les mots qu'il écrit sont destinés au demandeur. Sur un service desk IT, ce n'est pas un détail cosmétique manquant. C'est la différence entre une note à un collègue et un e-mail à un directeur.

Bon à savoir si vous empruntez la voie de l'API plus tard : la ressource de commentaires du service desk n'expose que GET et POST. Pas de PUT, pas de DELETE. Retirer un commentaire signifie descendre à l'API de plateforme Jira sur /rest/api/3/issue/{id}/comment/{id}, en détenant la permission Modifier ses propres commentaires ou Supprimer ses propres commentaires. Planifiez l'annulation avant d'en avoir besoin.

Voie 3 : l'API REST du service desk, si vous la construisez vous-même

Si vous voulez le comportement conscient des files d'attente, des SLA et visible côté client, vous l'écrivez vous-même contre /rest/servicedeskapi/. C'est un vrai projet, pas un week-end, et trois choses façonneront la conception plus que prévu.

Les limites de débit sont trois systèmes à la fois, et Atlassian dit que votre intégration « doit gérer les trois ». Un quota horaire basé sur des points, des limites de rafale par seconde, puis des limites d'écriture par ticket par-dessus. Le Global Pool par défaut est de 65 000 points par heure partagés entre les tenants ; un pool par tenant va de 65 000 sur Free jusqu'à 150 000 plus 30 par utilisateur sur Enterprise, plafonné à 500 000. Les valeurs par défaut de rafale sont de 100 requêtes par seconde en GET et POST, et 50 en PUT et DELETE. Les écritures par ticket sont plafonnées à 20 en deux secondes et 100 en trente. Et un endpoint est nettement plus restreint que tous les autres : GET /servicedeskapi/servicedesk/{id}/customer est limité à 5 requêtes par seconde, et ce sera le premier mur que vous heurterez sur tout remplissage massif de clients.

Des échecs de permissions silencieux. Atlassian documente que sur GET /request/{id}/comment, « aucune erreur de permission n'est fournie si, par exemple, l'utilisateur n'a pas accès au service desk ou à la demande ; la méthode renvoie simplement une réponse vide ». Un agent qui ne lit aucun commentaire, puis en conclut qu'il n'y en avait aucun, finit par répondre en toute confiance à la mauvaise question.

L'accès à la base de connaissances est en recherche seule. GET /rest/servicedeskapi/knowledgebase/article renvoie les articles correspondant à une requête, par service desk ou sur l'ensemble, et query est obligatoire. Rien dans cet espace de noms ne récupère le corps complet d'un article, si bien qu'ancrer les réponses dans votre base de connaissances implique un second aller-retour vers l'API Confluence. Le bon côté : les deux endpoints de base de connaissances sont exemptés des règles d'accès des applications, contrairement à tout endpoint de demandes et de commentaires.

Ce que coûte réellement une réponse JSM

C'est là que la limite de lecture seule devient intéressante financièrement. Les tokens sont bon marché, et ce qu'ils achètent est limité.

Une réponse fondée revient à environ 12 000 tokens d'entrée une fois que vous avez récupéré le ticket, les transitions et deux pages Confluence, plus environ 700 tokens de sortie au retour. Sur Claude Sonnet 5 à 2 $ et 10 $ par million, cela fait environ 3,1 centimes. Plus proche de 1,3 centime une fois que la mise en cache des prompts fait son travail, à 0,20 $ par million en lecture mise en cache. Sur Claude Opus 5 à 5 $ et 25 $, la même réponse se rapproche de 7,8 centimes.

Passons aux comparaisons. L'agent virtuel propre à Atlassian inclut 1 000 conversations assistées par mois, puis facture à partir de 0,30 $ chacune au-delà, et une conversation qui est associée à une intention puis escaladée vers un humain est quand même facturée. Les crédits Rovo constituent un compteur totalement séparé : Standard en obtient 25 par utilisateur et par mois, Premium 70, Enterprise 150. Les outils bêta Teamwork Graph du serveur MCP sont gratuits aujourd'hui, mais Atlassian a annoncé qu'ils « seront facturés à un minimum de 1 crédit Rovo par appel » à la disponibilité générale, avec un préavis de 90 jours.

Une mise en garde avant de prendre n'importe quel chiffre par conversation au pied de la lettre, de la part d'un responsable IT qui a directement porté le sujet à l'équipe produit :

"One example: virtual agent will count a ticket as "successfully deflected" if the user gives up responding and it auto closes. That's not a successful deflection, that's an awful user experience."

u/Goose-tb, r/ITManagers

Cela vaut la peine de vérifier ce point pour n'importe quel outil que vous choisissez, le nôtre inclus. Un taux de déviation qui compte l'abandon comme un succès mesure la mauvaise chose, et c'est le chiffre qu'on vous ressortira le plus probablement lors d'une réunion de renouvellement.

Entrez vos propres chiffres :

La lecture honnête de ces trois chiffres : la colonne des tokens est la moins chère parce qu'elle achète le moins de choses. Pas de pipeline de réponse, pas d'indicateur de visibilité, pas de routage de file d'attente, pas de conscience des SLA, et aucun moyen de se tester avant de rencontrer un vrai demandeur. Comparer ça à un prix par demande revient à comparer un assistant de recherche à un agent. Utile. Pas le même métier.

Le côté administrateur, et pourquoi il dira accès refusé

Quatre éléments distincts doivent tous être vrais avant qu'un seul appel d'outil n'aboutisse. Chacun échoue différemment.

1. Le domaine IA doit être autorisé. Atlassian fournit une liste par défaut de domaines partenaires IA, Claude et ChatGPT inclus. Les administrateurs peuvent l'autoriser ou la bloquer, mais Atlassian est explicite : « Vous ne pouvez pas bloquer des domaines individuels. Vous ne pouvez qu'autoriser ou bloquer la liste entière de domaines. » Ce qui ne laisse aucun moyen d'autoriser Claude et de refuser tout le reste.
2. L'IP doit passer la liste blanche, et celle-ci est vicieuse, car « l'écran de consentement OAuth 2.1 peut quand même apparaître pour les utilisateurs se connectant depuis des IP bloquées, mais les appels d'outils échoueront ». La connexion a l'air réussie jusqu'au moment précis où elle ne fait rien.
3. La méthode d'authentification doit être autorisée. L'authentification par jeton API est un interrupteur à l'échelle de l'organisation, et c'est cet interrupteur qui décide si les outils JSM existent pour vous, tout simplement. Le blocage de domaines, notamment, ne s'applique pas aux connexions par jeton API.
4. La sortie réseau doit atteindre *.atlassian.net, puisque le serveur restitue des widgets Jira et Confluence interactifs à l'intérieur du client IA via des iframes.

Par-dessus tout ça, un onglet Permissions permet désormais aux administrateurs d'organisation d'autoriser ou de bloquer Lecture, Écriture et Recherche indépendamment par application, et Atlassian dit que cela « prendra le pas sur les paramètres de Connected Apps ». Il existe aussi un interrupteur « Appliquer aux ajouts futurs ». Ce qui signifie, en silence, que les permissions ajoutées récemment peuvent hériter d'une autorisation sans que personne ne les révise. Si vous êtes la personne qui valide les revues d'accès, cet interrupteur mérite un coup d'œil.

Deux faits de conformité à transmettre à votre équipe sécurité avant qu'elle ne pense à demander. Le serveur ne stocke ni ne met en cache aucun contenu Jira ou Confluence, et il fonctionne strictement dans les limites des permissions de l'utilisateur connecté, ce qui est une meilleure valeur par défaut que la plupart des connecteurs. Mais Atlassian indique qu'il « ne prend actuellement pas en charge les exigences FedRAMP ou HIPAA », et il est uniquement Cloud, sans aucune voie Data Center ou Server publiée. Pour de nombreux service desks IT réglementés, ces deux phrases mettent fin à l'évaluation sur-le-champ.

Ce à quoi les gens se heurtent vraiment

La plainte la plus bruyante ne concerne ni les outils ni les crédits. C'est que le jeton n'arrête pas d'expirer. Un fil de la communauté Atlassian intitulé « The MCP Auth expires too fast » court d'octobre 2025 à mars 2026, avec environ 16 500 vues et aucune résolution, et il est plein d'utilisateurs de Claude Code :

"Bump! I need to reauthenticate sometimes once an hour, sometimes once every 10-20 minutes. This morning I authenticated the MCP connection then sent my prompt, 12 minutes later claude code was getting a 401 response and I only had a single terminal session open. This is basically unusable, I guess I'll just need to build some custom tools to utilize the API."

Aaron Kirn, Atlassian Community

Un Community Champion sur le même fil a pointé la cause clairement : le serveur émet des jetons OAuth à courte durée de vie, les clients externes ne peuvent pas les renouveler automatiquement, et les jetons longue durée n'ont pas encore été livrés. Deux choses en découlent si vous faites tourner des agents plutôt que de simplement discuter.

Les sessions parallèles se battent entre elles. Plusieurs personnes rapportent que s'authentifier dans une fenêtre désauthentifie silencieusement les autres, ce qui rend pénible n'importe quel flux de travail multi-agents. Et le nouveau endpoint /mcp échoue plus silencieusement que l'ancien : un utilisateur a noté que /sse renvoyait au moins un 401 qu'on pouvait intercepter, alors que le remplaçant « échoue simplement en silence ». Si vous configurez des tentatives de reconnexion, interceptez le résultat vide, pas seulement le code d'erreur.

La qualité des outils a son propre fil, et c'est la partie que je n'attendais pas. Un product manager Atlassian travaillant sur le serveur MCP a répondu sur Reddit, officiellement :

"Tool quality - the problem you mention where the Jira create tool doesn't respect required fields is something we just need to fix. We've been moving quickly to release a broad range of tools, and now we need to go back and fix some of those pain points. Tool descriptions included. You'll see some improvements here soon Context bloat - we acknowledge this is a problem as well. There are many more tools we want to provide but the current design is already at it's limit."

u/atlassiadam, Atlassian PM, r/mcp

L'anxiété liée aux crédits est l'autre grand thème, et il s'agit surtout de Rovo plutôt que de MCP. Un utilisateur de Bitbucket a rapporté qu'une seule revue de pull request avait englouti presque la moitié de son allocation mensuelle :

"Rovo had a look at the PR and made a few suggestions and in doing so appeared to use 965 of my 2000 credits with 760 being marked as 'Code review in Bitbucket', I'm not sure where the other 205 went?? Either I'm doing something amazingly wrong or that's not value for money at all."

Chris Mingay, Atlassian Community

Un product manager Atlassian a répondu dans ce fil et a reconnu que le calcul était lourd, ce qui est honnête, et inhabituellement franc. La même inquiétude ressurgit sur Reddit, où un utilisateur du plan Standard a fait la comparaison à voix haute :

"advertised ($0.01 per credit after the initial 2000), copilot is a mere $10 for 300 claude 4.5 requests why is it so expensive? the free tier..."

Rovo Dev credits, r/RovoDev

Ce même utilisateur a décrit avoir brûlé les trois quarts de 2 000 crédits en l'espace de quelques heures, sur pas plus de 30 requêtes.

Ce contexte explique précisément pourquoi le modèle de tarification du serveur MCP se lit aujourd'hui comme un soulagement plutôt qu'une inquiétude. C'est aussi pourquoi la note de facturation Teamwork Graph mérite un rappel dans l'agenda. Gratuit-avec-votre-plan est un produit très différent de facturé-en-crédits, et Atlassian vous a déjà dit dans quelle direction vont deux de ces outils.

Comment je déciderais concrètement

Si votre objectif est l'analyse, l'assurance qualité, les comptes rendus d'incidents, ou poser des questions à travers Jira et Confluence en un seul endroit, installez le connecteur dès aujourd'hui. C'est le meilleur plugin IA pour Jira gratuit que j'aie testé cette année. Gratuit, officiel, le modèle de permissions est solide, et lecture-seule-en-pratique est une qualité la première fois que vous pointez une IA vers un service desk en production. La chose gratuite la plus solide de la catégorie, et je ne dissuaderais personne de l'utiliser.

Si votre objectif est l'astreinte, les quatre outils JSM méritent leur place, et cela vaut le coup d'avoir la conversation avec votre administrateur sur l'activation de l'authentification par jeton API. Accuser réception et escalader des alertes directement depuis une fenêtre de chat est un vrai flux de travail.

Si votre objectif est de traiter les demandes de niveau 1 pour que votre équipe arrête de répondre à la même question VPN, le connecteur n'est pas cet outil, et aucune quantité de prompting n'en fera un. Ce qu'il vous faut, c'est quelque chose qui parle /rest/servicedeskapi/, qui connaît la différence entre une réponse publique et une note interne, qui respecte la file d'attente et la politique de SLA que vous avez déjà configurées, qui gère l'escalade proprement, et qui peut être testé contre des demandes déjà survenues avant de rencontrer une demande qui ne l'a pas encore fait. Mon comparatif de la meilleure IA pour l'ITSM couvre le terrain si vous voulez comparer sérieusement.

eesel AI pour Jira Service Management

Ce dernier métier est celui pour lequel nous construisons. eesel rejoint votre service desk comme un véritable agent IA, pas comme un widget vissé sur le côté. Il lit les demandes, rédige et envoie des réponses, ajoute des notes internes, met à jour les champs de la demande, fixe la priorité et route vers les équipes, le tout dans les règles d'attribution et les politiques de SLA que vous avez déjà.

Ce à quoi je tiendrais le plus, en évaluant cela sur un service desk réel, c'est la simulation. Vous rejouez vos demandes passées avant que quoi que ce soit n'approche d'une vraie, vous obtenez des pourcentages de couverture répartis par thème, vous comblez les lacunes que le passage révèle, puis vous lancez une fois que le chiffre est assez bon. Nous avons construit cela parce que nous avons vu des bots au ton confiant donner de mauvaises réponses sur les files d'attente d'autres personnes, et un essai à blanc sur votre propre historique est la seule façon honnête de le découvrir avant.

Pour une idée de ce à quoi cela ressemble sur un service de support interne : InDebted fait tourner JSM pour une équipe IT de 5 à 10 personnes soutenant des centaines d'employés répartis sur cinq marchés. Leur savoir provient de Confluence et d'un bot Slack :

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

Jason Loyola, IT Team, InDebted, eesel case study

Aujourd'hui, ils sont à 15 % des tickets Jira entrants déviés, avec 55 % comme objectif une fois la base de connaissances complétée. Un chiffre réel venant d'un vrai service desk, pas un chiffre de démo. Et la partie honnête, c'est que ça a commencé à 15 %, pas à 55 %.

La tarification est de 0,40 $ par demande traitée. Facturée par demande plutôt que par réponse, si bien qu'un échange de quinze messages compte quand même comme un seul montant facturé. Pour démarrer, il y a 50 $ d'usage gratuit sans carte, ce qui équivaut à 125 demandes, avec toutes les fonctionnalités débloquées.

Si votre service desk vit ailleurs que dans JSM, le même agent fonctionne sur Zendesk et six autres helpdesks.

Utilisez le connecteur Atlassian pour réfléchir. Pour répondre, utilisez quelque chose qui parle l'API du service desk. Des métiers différents, et la bonne nouvelle, c'est qu'en 2026 vous n'avez plus à en choisir un seul.