Claude pour ServiceNow : comment le connecter et ce que ça coûte

Ce que ServiceNow a réellement annoncé

Deux annonces, à cinq mois d'écart, que l'on confond en permanence.

Le 28 janvier 2026, Anthropic et ServiceNow ont annoncé que Claude est le modèle par défaut qui alimente ServiceNow Build Agent et un modèle privilégié sur l'ensemble de la ServiceNow AI Platform. ServiceNow a également déployé Claude et Claude Code en interne auprès de plus de 29 000 employés, rapportant une réduction pouvant atteindre 95 % du temps de préparation des réunions commerciales. Bill McDermott a présenté cela comme une réinvention de la façon dont le travail se fait. La formule de Dario Amodei portait sur une IA tissée dans le travail quotidien plutôt qu'ajoutée après coup.

Puis le 5 mai 2026, à Knowledge 2026, ServiceNow a annoncé Action Fabric, ouvrant la plateforme à tout agent externe via un serveur MCP en disponibilité générale. Anthropic est cité comme premier partenaire de conception, connectant Claude Cowork à ce que ServiceNow appelle son système d'action. Boris Cherny, responsable de Claude Code chez Anthropic, est cité à propos de combler l'écart entre savoir ce qui doit se passer et le faire réellement se passer.

Mises bout à bout, ces deux annonces forment une histoire solide. Le discours propre de ServiceNow est que les autres plateformes laissent les agents lire et écrire des données, tandis que ServiceNow leur permet d'exécuter du travail gouverné : flows, playbooks, approbations, catalogues.

Voici maintenant la partie que les communiqués de presse omettent. Le serveur MCP est inclus dans les SKU Now Assist et AI Native, et les actions headless consomment la même monnaie d'assists que Now Assist et AI Agents. Cette phrase figure dans l'article Action Fabric lui-même, en italique, tout en bas. C'est toute la forme commerciale de cette intégration, et tout ce qui suit en découle.

Encore une chose à noter si tu lis la documentation : ServiceNow est en plein rebranding. Une bannière dans la documentation indique désormais que ServiceNow Otto est la nouvelle marque d'expérience IA, et les URL d'articles communautaires sont déjà passées de now-assist-articles à servicenow-otto-articles. Même produit, nouveau nom, documentation à moitié migrée.

Quatre façons dont Claude atteint une instance ServiceNow

Il y en a quatre, et elles ne sont pas équivalentes.

Les deux premières sont celles sur lesquelles tu peux agir dès aujourd'hui. La troisième pointe dans l'autre sens, Claude travaillant sur ServiceNow plutôt que dans ta file d'attente. La quatrième est celle dont le communiqué de presse parle le plus fort, et celle que tu peux acheter de la façon la moins fiable en ce moment.

La voie officielle : MCP Server Console

MCP Server Console est la réponse prise en charge, et la documentation ServiceNow cite explicitement Claude comme client, aux côtés de Microsoft Copilot.

Les quatre outils Quickstart

Tu n'as rien à construire pour démarrer. Il existe un Quickstart Server préconfiguré, et voici toute la surface qu'il expose :

Deux recherches et deux outils de résumé. L'expérience Claude prête à l'emploi sur ServiceNow consiste à lire et résumer, pas à agir. Demande « récupère tous les incidents ouverts » ou « résume tous les cas clôturés cette semaine » et ça fonctionne bien. Demande-lui de réassigner un P1, d'approuver un changement ou de déclencher un élément de catalogue, et il n'existe aucun outil pour ça tant que personne n'en construit un.

C'est un point de départ plus restreint que les quatre outils d'astreinte que j'ai trouvés dans le serveur MCP Rovo d'Atlassian, et bien plus restreint que les douze outils Confluence de mon article Claude pour Confluence. La différence est délibérée : Atlassian livre une liste d'outils fixe, ServiceNow livre un constructeur.

Ce que tu peux construire au-delà

Les outils dans MCP Server Console proviennent de cinq catégories, et c'est là que la profondeur de la plateforme se manifeste réellement :

• REST API encapsule n'importe quel endpoint de l'instance, y compris la Table API.
• Action et Subflow sont les plus intéressants, car ils représentent du travail gouverné plutôt qu'un simple accès aux données. La documentation ServiceNow elle-même décrit les subflows et les actions comme permettant aux agents de soumettre des demandes, de les acheminer pour approbation et de confirmer les résultats sans quitter le client.
• Knowledge Graph offre des requêtes tenant compte des relations sur les données en direct de l'instance, plutôt que de simples lectures d'enregistrements.
• Now Assist skill expose une skill existante, y compris les skills personnalisées issues de l'AI Skill Kit.

Par outil, tu peux désactiver certains inputs individuels pour qu'ils n'atteignent jamais le client, même si certains inputs obligatoires ne peuvent pas être désactivés. Ce contrôle au niveau du champ est la meilleure fonctionnalité de gouvernance de toute la configuration, et c'est la raison pour laquelle je construirais des outils plutôt que d'exposer la Table API en entier.

Deux détails de friction relevés dans la documentation qui te mordront pendant la construction. Ajouter des inputs à une skill Now Assist après en avoir déjà fait un outil signifie créer un outil de remplacement, pas modifier celui qui existe. Et la création d'outils nécessite au minimum le patch Zurich 9 ou Australia 2, plus récent que le niveau de patch qui t'a donné le serveur MCP lui-même.

Comment connecter Claude à ServiceNow

La connexion est une poignée de main OAuth, pas une entrée d'annuaire sur laquelle on clique. Il n'existe aucune entrée ServiceNow en un clic dans l'annuaire des connecteurs de Claude, ce qui est la principale différence pratique avec quelque chose comme le serveur MCP officiel de Front.

1. Obtiens une SKU éligible. Now Assist (Pro Plus, Enterprise Plus) ou une SKU IA, selon la propre liste de prérequis de ServiceNow. Également sur cette liste : Zurich Patch 4 ou supérieur, l'application AI Agents en 6.x ou supérieur, et l'application MCP Client en 1.1 ou supérieur.
2. Choisis ou crée un serveur. Dans All > MCP Server Console > Configuration > Servers. Utilise le Quickstart Server pour commencer ; crée le tien si tu veux un ensemble d'outils restreint, par exemple un serveur pour l'IT et un pour les RH.
3. Crée des outils si nécessaire. Configuration > Tools > Create tool, puis choisis une catégorie. Le rôle requis est sn_mcp_server.tools_admin, sn_mcp_server.admin ou admin. Chaque serveur a besoin d'au moins un outil.
4. Crée une intégration OAuth entrante pour Claude. Une par client. C'est de là que viennent l'ID client et le secret.
5. Pointe Claude vers le serveur. Le modèle d'URL est https://<instance>.service-now.com/sncapps/mcp-server/mcp/<server-name>, et pour le Quickstart Server, le nom est sn_mcp_server_default. Le type d'authentification est OAuth 2.0 avec un fournisseur d'identité OAuth 2 générique, autorisation sur /oauth_auth.do, jeton sur /oauth_token.do, révocation sur /oauth_revoke.do, callback sur /oauth/callback, scope mcp_server.
6. Envoie-lui un prompt. Claude envoie Authorization: Bearer <token>, le serveur valide et renvoie sa liste d'outils, et les résultats reviennent en JSON que le client affiche sous forme de texte.

Prévois une heure si ton instance est déjà patchée et qu'une personne disposant de sn_mcp_server.admin est présente. Prévois un cycle d'achat si la SKU Now Assist n'est pas encore signée.

Ce que coûte réellement un appel de Claude

Voici la phrase qui détermine si c'est bon marché ou coûteux, directement issue de la FAQ MCP de ServiceNow : les skills Now Assist exposées comme outils via le serveur MCP consomment leur nombre habituel d'assists lors de l'invocation, plus 1 assist.

Ce supplément est fixe, ce qui signifie qu'il tombe très différemment selon la skill. Le résumé d'incident est une skill à 1 assist, donc l'appeler depuis Claude coûte 2, soit un surcoût de 100 % sur la chose la moins chère que tu voudrais faire. Une analyse de notes de travail à 250 assists paie le même assist supplémentaire et ne le remarque presque pas. La grille tarifaire publiée place aussi les sujets Virtual Agent et les actions sur ticket à 10 assists chacun, et les workflows agentiques à 25, 50 ou 150 selon le nombre d'outils touchés.

Les assists sont mutualisés au niveau du compte, à travers les instances de production et de sous-production, et se réinitialisent à la date anniversaire de l'achat, donc une équipe qui expérimente sur une instance de développement puise dans le même pool que celui utilisé par la file d'attente de production.

La forme qui en résulte est contre-intuitive. Le supplément MCP pénalise précisément les lectures bon marché et fréquentes que tu voudrais le plus voir Claude effectuer, et se dilue dans le bruit sur les workflows coûteux. Si ton plan est « tout le monde à l'IT résume des incidents avec Claude toute la journée », c'est exactement le cas où l'assist supplémentaire double ta consommation.

Je vois constamment des acheteurs se heurter à ce mur. L'un d'eux, avec qui j'ai travaillé, une entreprise de sécurité des e-mails utilisant Freshdesk et montant vers 20 000 tickets par an, a consommé 200 interactions mesurées en une seule journée de test et s'est immédiatement inquiété du chiffre à volume réel. Un autre, un opérateur à très fort volume, a trouvé la distinction entre par interaction et par ticket suffisamment déroutante en plein appel pour projeter environ 30 000 $ par mois pour son entreprise avant que quiconque ne puisse corriger le calcul. Les tarifs IA mesurés ne sont pas une erreur en soi. Ils sont simplement très difficiles à prévoir avant de les avoir réellement testés, et c'est pourquoi j'insiste désormais pour simuler chaque déploiement eesel sur les tickets historiques propres du client avant que qui que ce soit ne l'active.

Où s'arrête la voie officielle

Six limites à connaître avant de t'engager. Aucune n'est secrète ; elles figurent toutes dans la documentation et la FAQ de ServiceNow, ce qui est déjà plus que ce que publient la plupart des fournisseurs.

Transport distant uniquement. Le HTTP en streaming et SSE sont pris en charge. Stdio ne l'est pas, et les serveurs MCP locaux ne sont pas pris en charge du tout. Si ta représentation mentale de la configuration MCP de Claude est une commande locale dans un fichier JSON, ce schéma ne s'applique pas ici.

Protocole MCP 2025-06-18. C'est la version de spec prise en charge. Les ressources et prompts MCP ne sont pas encore pris en charge, même si ServiceNow indique qu'ils figurent sur la roadmap sous safe harbour.

Pas de GCC pour le serveur. Le client MCP et A2A fonctionnent sur GCC. Le serveur MCP non, d'après la FAQ du patch Zurich 4. Pour une instance fédérale américaine, cela ferme complètement la voie officielle.

Les données quittent ton instance. La documentation de MCP Server Console indique clairement que l'application nécessite le transfert de données des instances clients vers un environnement ServiceNow centralisé, potentiellement dans une région de datacenter différente, et potentiellement vers un fournisseur cloud tiers comme Microsoft Azure. Lis cela en gardant à l'esprit tes engagements en matière de résidence des données.

Les inputs et outputs alimentent le développement du modèle par défaut. Cette même page de documentation indique que ServiceNow collecte et utilise les inputs, les outputs et les modifications apportées aux outputs pour développer et améliorer ses technologies, avec une option de retrait disponible via la page de retrait Now Assist. Se retirer signifie que quelqu'un doit effectivement s'en charger.

Une intégration OAuth par client. C'est le design, et il est raisonnable, mais cela signifie qu'intégrer une deuxième application IA est une nouvelle tâche administrative plutôt qu'une case à cocher. L'AI Gateway dans l'AI Control Tower est l'endroit où voir qui a appelé quoi.

Pourquoi les équipes se tournent encore vers l'open source

Les serveurs MCP communautaires ne sont pas un phénomène marginal. Le plus connu, echelon-ai-labs/servicenow-mcp, affiche 286 étoiles et 225 forks, est sous licence MIT, et fournit des outils couvrant les incidents, les demandes de changement, le catalogue de services, les bases de connaissances, les utilisateurs et groupes, les workflows, les script includes, les changesets et les user stories agiles. Il prend en charge l'authentification basique, OAuth et les clés API, s'exécute sur stdio ou SSE, et dispose d'un système d'empaquetage d'outils avec des bundles basés sur les rôles comme service_desk, change_coordinator et knowledge_author pour garder un nombre d'outils exposés raisonnable.

La vraie raison pour laquelle les gens utilisent ces serveurs, c'est la licence, et r/servicenow le dit tout haut :

"These open source ones that keep popping up are more-so alternatives if your company doesn't want to purchase now assist licensing."

u/averageuser612, Reddit

Le même fil contient la version la plus tranchante, dans un commentaire prédisant que ServiceNow ne livrera jamais de version gratuite :

"ServiceNow most definitely won't give customers something for free when the alternative is to charge you in assists. If they could charge you assist to log in to your instance, they would."

u/tokenontokens, Reddit

Je nuancerais légèrement cette lecture, et il vaut la peine de le faire équitablement. ServiceNow a bel et bien livré un serveur MCP, il est en disponibilité générale, et la documentation est étonnamment précise sur ce qu'il couvre et ce qu'il ne couvre pas. Il n'est simplement pas gratuit, et il ne prétend pas l'être.

Ce que l'on sacrifie en optant pour l'open source est réel, cependant. Le mainteneur d'un serveur communautaire plus récent, interrogé directement sur les garde-fous, a répondu que le côté MCP est un ensemble brut d'outils sans garde-fous intégrés par défaut, et que c'est le client qui décide de la façon de les utiliser. Voilà le compromis : le serveur officiel te donne un contrôle des inputs au niveau du champ, OAuth, des pistes d'audit via l'AI Control Tower et une mesure par outil. Un simple wrapper de la Table API te donne immédiatement tout ce que ton compte de service peut atteindre.

Il existe aussi une troisième position dans ces fils, à prendre au sérieux, de la part de quelqu'un qui ne voulait rien de tout ça :

"Claude has built perfectly fine servicenow fluent code for me without any external tooling whatsoever."

u/Correct-Mood5309, Reddit

Pour le scripting et le travail Fluent, c'est souvent vrai. MCP se justifie quand Claude a besoin de l'état en direct de l'instance, pas quand il doit écrire du code qu'il sait déjà écrire.

Une note de terrain d'une équipe ayant construit son propre serveur, sur la version du patch Australia 4 : leur seul piège fut l'authentification, car CMDB Search ne fonctionne pas actuellement avec le compte admin, alors que n'importe quel autre compte disposant de droits de lecture fonctionne parfaitement. C'est le genre de détail qui coûte une après-midi si personne ne prévient à l'avance.

Build Agent : Claude dans l'autre sens

Cela vaut la peine de le distinguer, car l'intention de recherche derrière « Claude pour ServiceNow » signifie souvent ceci.

Build Agent est le produit de vibe-coding de ServiceNow pour construire des apps et des automatisations, et Claude en est désormais le modèle par défaut. ServiceNow s'attend à ce que l'usage de Build Agent quadruple au cours des 12 prochains mois, et vise une réduction de 50 % du temps de mise en œuvre pour les clients avec Claude dans la boucle. C'est Claude qui construit sur la plateforme, générant des applications scopées, des flows et des configurations.

La distinction que fait la communauté entre Build Agent et la voie MCP est utile. Build Agent est construit autour du SDK ServiceNow et de Fluent, déploie chaque changement approuvé dans son propre update set indépendant, et tend à créer des artefacts à partir de zéro car il est conçu pour de nouvelles applications scopées. Un serveur MCP basé sur la Table API travaille sur ce qui existe déjà et applique les changements dans ton update set actuel comme n'importe quel changement manuel.

Si tu es développeur ServiceNow, Build Agent est probablement le plus intéressant des deux. Si tu gères un service desk, ce n'est pas l'outil que tu cherchais.

Personne ne surveille ta file d'attente

C'est la partie que j'aimerais connaître avant de consacrer un trimestre au déploiement.

Chaque voie ci-dessus est initiée par un humain. Une personne ouvre Claude, tape un prompt, et un appel d'outil se produit. Il n'existe aucun mode où le serveur MCP remarque qu'un nouveau P2 atterrit dans ta file d'attente ITSM, décide qu'il correspond à un schéma connu, rédige une réponse et la publie. L'exemple même d'Action Fabric est un chef de produit demandant à Claude pourquoi il n'a pas accès, puis examinant une liste et confirmant. Gouverné, auditable, utile, et pourtant déclenché par un humain.

Cet écart compte différemment selon qui tu es :

• Un développeur ou administrateur ServiceNow ne perd presque rien. C'était de toute façon toi qui allais taper.
• Un responsable des opérations IT obtient une bien meilleure lecture de l'instance et des résumés d'incidents plus rapides, ce qui est une réelle valeur.
• Un responsable de service desk évalué sur la déflexion n'obtient rien directement. La déflexion a besoin de quelque chose qui répond avant qu'un humain n'intervienne, ce à quoi sert Virtual Agent, et les propres limites du palier d'entrée de Virtual Agent forment une conversation à part.

Si tu évalues cela pour augmenter la résolution au premier contact ou réduire le volume de tickets sur un helpdesk interne, le serveur MCP est le mauvais instrument. C'est un très bon instrument pour autre chose.

Claude ou Now Assist : lequel devrait toucher ton instance ?

Ce n'est pas vraiment une compétition, mais voici la répartition que j'utiliserais.

La seule ligne que je soulignerais : appeler une skill Now Assist via MCP coûte plus cher que d'appeler la même skill nativement. Si une skill va de toute façon s'exécuter dans un workflow ServiceNow, ne la fais pas passer par Claude juste pour la forme.

eesel AI pour les équipes ServiceNow

La réponse directe d'abord : eesel n'a pas d'intégration ITSM native avec ServiceNow. Je préfère le dire clairement plutôt que de te laisser le découvrir trois paragraphes plus loin.

Ce que fait eesel, c'est la moitié non supervisée que MCP Server Console ne couvre structurellement pas. Il se connecte à ton helpdesk et à ta base de connaissances, s'entraîne sur tes propres tickets et documents passés, puis gère des conversations de façon autonome plutôt que d'attendre que quelqu'un ouvre une fenêtre de chat pour poser une question. C'est la pièce que recherche généralement un responsable de service desk lorsqu'il atterrit sur une recherche « Claude pour ServiceNow ».

Trois différences qui comptent si tu viens de lire le calcul d'assists ci-dessus :

• Tu simules avant de passer en production. eesel exécute l'agent sur tes véritables tickets historiques et te montre ce qu'il aurait dit et ce qu'il aurait résolu, avant de toucher une file d'attente en direct. Cela existe parce que j'ai vu des bots à l'air sûr d'eux donner de mauvaises réponses en production, et un essai à blanc sur l'historique réel est la seule façon honnête de le découvrir au préalable.
• Un seul chiffre, par ticket. 0,40 $ par ticket ou chat traité, pas un pool d'assists avec des tarifs différents par skill et un taux de dépassement non publié. Tu peux le prévoir au dos d'une enveloppe.
• Cela fonctionne aussi sur les desks internes. eesel gère le volet interne via Slack, Microsoft Teams et l'e-mail. Il lit depuis Confluence et d'autres sources internes, là où vit réellement une grande partie du travail d'automatisation ITSM proche de ServiceNow.

Tu utilises ServiceNow et tu veux voir ce que fait un agent non supervisé sur ton propre historique de tickets avant de t'engager sur quoi que ce soit ? C'est à ça que sert la démo, et l'essai est gratuit.

Où je me positionnerais

Si tu as déjà une SKU Now Assist, connecte Claude via MCP Server Console cette semaine. C'est une heure de travail administratif, le Quickstart Server te donne immédiatement une surface utile de lecture et de résumé, et les contrôles d'input au niveau du champ constituent une meilleure gouvernance que ce qu'offre n'importe quel serveur communautaire.

Si tu n'as pas Now Assist, et que l'acheter pour ça est toute la question, sois lucide : tu licencierais un niveau d'IA de plateforme pour obtenir quatre outils plus un constructeur, en plus d'une licence ServiceNow qui n'est déjà pas bon marché. Un serveur MCP communautaire est gratuit et couvre la plupart des cas d'usage en lecture, au prix de l'absence de garde-fous et de mesure.

Et si ce que tu voulais réellement, c'était moins de tickets plutôt que de meilleures réponses sur les tickets, aucune des quatre voies ne t'y mène. C'est un outil différent, et il vaut la peine de nommer cette différence avant le début du trimestre plutôt qu'après.