Zendesk Open Service Directory : ce que c'est, comment ça marche et ce qui est déjà en ligne

Qu'est-ce que le Zendesk Open Service Directory ?

L'Open Service Directory est la réponse de Zendesk à un nouveau type de demande de support : celle qui arrive de l'assistant IA personnel d'un client plutôt que du client lui-même. Dans l'article de lancement de Zendesk, rédigé par Jad Chamoun (Senior Director of Applied AI) et Will Poon (Director of Product Management pour Messaging et AI), il est décrit comme « a specification and public directory of verified support destinations ».

Je construis des intégrations pour vivre, donc j'ai lu ce lancement comme n'importe quelle annonce d'API : quel est le contrat, qui héberge quoi, et ce qui est livré par rapport à ce qui est promis. Voici la version courte.

Si les noms d'assistants de cette liste vous sont inconnus, j'ai écrit séparément sur OpenAI Dots, Instinct AI et Grok Bot. L'OSD est la première fois qu'un éditeur de helpdesk tente de leur donner à tous une porte d'entrée commune.

Pourquoi un assistant IA aurait-il besoin d'un annuaire pour trouver du support ?

Parce qu'aujourd'hui, il devine. L'exemple de Zendesk lui-même est un client qui demande à un assistant : « Can you move my air conditioner repair appointment to Monday? » L'assistant peut trouver les articles d'aide de l'entreprise, mais déplacer le rendez-vous suppose d'atteindre le vrai support de l'entreprise, et il n'existe aucun moyen commun et fiable de vérifier que le « support » trouvé est bien celui de la marque et non une imitation.

Ce n'est pas un problème d'un futur lointain. J'ai déjà vu des assistants orienter de vrais acheteurs : un prospect a raconté à l'équipe eesel lors d'un appel commercial qu'il avait trouvé eesel parce qu'un assistant IA le lui avait recommandé directement, en plus du conseil d'un ami la veille au dîner. Si les assistants choisissent déjà des fournisseurs pour le compte d'un acheteur, ils choisiront aussi des services de support pour le compte d'un client, et un mauvais choix signifie qu'un client confie les détails de sa commande à un faux service d'assistance.

Les sceptiques ont un point valable sur ce qui arrive dès qu'il y a quelque chose à gagner. Lorsque la spécification ARD de Google, la couche de base sur laquelle repose l'OSD, est arrivée sur Hacker News, le commentaire le plus voté l'a dit sans détour :

"This seems useful as a standard interface, but, again, doesn't solve the harder discovery problem. Once there is value in appearing in the top results, the system inherits the same adversarial dynamics as SEO/app stores, spam, scams, etc."

wslh, Hacker News

La réponse de l'OSD à cela est la règle d'approbation de la section suivante, et je pense que c'est le choix de conception le plus important de toute la spécification.

Comment fonctionne l'Open Service Directory

Zendesk le décrit en trois étapes : lister le support approuvé, trouver la bonne entreprise, se connecter au support officiel. La documentation développeur de l'OSD détaille la mécanique, et elle est étonnamment petite.

Étape 1 : la marque publie une fiche sur son propre domaine

Une marque décrit chaque agent de support qu'elle veut rendre trouvable par les assistants dans un manifeste JSON à l'adresse https://{brand-domain}/.well-known/ard.json. Chaque entrée est une entrée ARD classique (un identifiant, un nom d'affichage, une description, des exemples de requêtes et un lien vers la MCP Server Card ou l'A2A Agent Card de l'agent) plus deux champs OSD : osd:brandName et osd:brandDomain. Voici l'exemple abrégé de la page OSD et ARD, avec leur compagnie aérienne fictive :

{
  "identifier": "urn:air:airline.example:support:assistant",
  "displayName": "Example Air Support",
  "description": "Support for cancelled flights and rebooking.",
  "type": "application/mcp-server-card+json",
  "url": "https://support.airline.example/server-card.json",
  "osd:brandName": "Example Air",
  "osd:brandDomain": "airline.example"
}

L'agent lui-même peut se trouver n'importe où, y compris sur les serveurs de Zendesk ou d'une autre plateforme. Ce qui compte, c'est que l'approbation soit servie depuis le propre domaine de la marque. La marque peut maintenir le fichier elle-même ou autoriser sa plateforme de support à le gérer.

Étape 2 : l'assistant trouve un candidat

Si l'assistant connaît déjà le domaine de la marque (par exemple grâce à un itinéraire de vol), il lit directement le manifeste. S'il ne connaît que le nom de la marque ou le problème, il interroge un registre OSD via le POST /search d'ARD, qui renvoie des entrées complètes avec un score de pertinence. La documentation précise bien que ce score « measures query match, not trust ».

Étape 3 : l'assistant vérifie l'approbation et se connecte

C'est l'étape qui répond à la crainte du spam. Un résultat de registre n'est qu'un candidat. Il n'est approuvé que si son entrée complète correspond à une entrée publiée dans le manifeste de la marque elle-même.

Un escroc peut donc glisser une fiche factice dans un registre, mais pas dans airline.example/.well-known/ard.json sans contrôler le domaine de la compagnie aérienne. C'est le même point d'ancrage de confiance que le web utilise déjà pour les certificats TLS, et c'est un choix judicieux. La documentation ajoute une autre réserve honnête : osd:brandDomain est une déclaration, et c'est toujours à l'assistant de décider si ce domaine appartient à l'entreprise que le client visait.

Une fois la correspondance confirmée, l'assistant lit la carte de l'agent et se connecte via son protocole natif, généralement MCP ou A2A. Si vous suivez le MCP pour le support client ou ce qui fait un bon serveur MCP d'agent IA, c'est ici que ces serveurs se branchent.

Où l'OSD s'arrête et où votre agent de support commence

C'est la partie que je soulignerais pour tout responsable du support qui lit l'article de lancement. Zendesk le dit directement : « The directory does not access private customer data or carry out support actions. » La documentation va plus loin : l'OSD « defines discovery and endorsement only ».

Tout ce qui suit la poignée de main relève d'autres couches. Zendesk cite trois protocoles qu'il prévoit d'adopter pour cette partie :

• Personal Agent Protocol (PAP), de Sierra, couvre la façon dont une entreprise décide ce qu'un agent peut faire, de « search rooms » sans connexion à « book a room » avec l'accord de l'utilisateur. Je l'ai traité dans mon article sur le Personal Agent Protocol.
• PACT (Personal Agent Consent and Trust), de Decagon, s'appuie sur A2A et OAuth pour qu'une entreprise puisse vérifier quel agent appelle et ce que le client a autorisé. Il va de pair avec la passerelle d'agents personnels de Decagon.
• UCP (Universal Commerce Protocol), un langage commun pour le commerce agentique, de la découverte au paiement, de la même famille que les travaux sur l'agentic commerce protocol.

Tout le monde n'adhère pas à l'idée de protocoles ici. Dans le fil de lancement de PAP, un commentateur a objecté :

"As a human directing my personal agent, why does it need a protocol? It has that with the websites and APIs businesses expose."

dividedcomet, Hacker News

Mon avis, en tant que personne qui a branché beaucoup d'API de helpdesk : la voie site web et API fonctionne jusqu'à ce que l'action touche un compte, de l'argent ou une identité, et là, les deux parties ont besoin d'un moyen de prouver qui agit pour qui. C'est exactement la tranche visée par ces protocoles, et l'OSD n'est que la recherche qui vient avant.

Mises bout à bout, les couches donnent ceci, et une seule vous revient à vous de rendre bonne :

Qu'est-ce qui est réellement en ligne aujourd'hui ?

Moins que ce que les titres laissent entendre, ce qui est normal pour un lancement de spécification. Voici ce que j'ai pu vérifier le 14 octobre 2026 :

Rien de tout cela n'est un reproche. Les marques sont décrites comme rejoignant le projet « to help shape the Directory », et le modèle d'approbation est la partie difficile à réussir en premier. Mais si vous êtes responsable du support et que vous vous demandez si vous devez faire quelque chose cette semaine, la réponse honnête est non. Vous avez quelques mois.

La documentation mentionne aussi une CLI OSD pour la découverte, la vérification et des commandes MCP directes, mais elle précise qu'elle est « intended for internal developer workflows only », donc je ne planifierais pas autour d'elle pour l'instant.

Que signifie l'Open Service Directory pour vous ?

La réponse change beaucoup selon le côté de la connexion où vous vous trouvez. Choisissez le vôtre :

Ce que cela signifie pour une équipe support sur Zendesk

Si vous gérez votre support sur Zendesk, l'annuaire lui-même est la partie facile. La question qu'il pose est autre : quand l'assistant d'un client se connecte à votre support, qu'atteint-il réellement ?

Le coût porte sur votre agent, pas sur l'annuaire

L'annuaire est gratuit. L'agent au bout ne l'est pas. Si les demandes des assistants sont traitées par l'agent IA de Zendesk lui-même, elles sont facturées comme n'importe quelle autre conversation. Selon la page de tarifs de Zendesk, Suite Team coûte 55 $ par agent et par mois et Suite Professional 115 $ (facturés annuellement), chacun inclut un petit lot de résolutions automatisées (5 par agent et par mois pour Suite Team, 10 pour Suite Professional), et chaque résolution automatisée supplémentaire coûte 1,50 $ avec engagement ou 2,00 $ en paiement à l'usage. Mes détails sur les tarifs de Zendesk AI et les résolutions automatisées vont plus loin.

Ainsi, une marque qui reçoit 1 000 demandes par mois issues d'assistants, toutes résolues par l'agent IA de Zendesk au-delà du quota inclus, ajoute 1 500 à 2 000 $ en plus des licences. Ce n'est pas une raison d'ignorer l'OSD. C'est une raison de connaître votre coût par demande avant de vous rendre plus facile à joindre, et de surveiller où la tarification au résultat mène cette facture.

Vos politiques deviennent le produit

Zendesk est explicite : une fois qu'un assistant se connecte, « the brand decides what customer information can be accessed, which actions are permitted and when a human needs to step in ». Concrètement, trois choses doivent être écrites quelque part où une machine peut les suivre :

1. Réponses. Votre agent répond-il à partir de vos vraies politiques et de vos anciens tickets, ou d'un centre d'aide maigre ? Un assistant posera les questions de vos clients, formulées plus précisément.
2. Actions. Quelles écritures s'exécutent seules, lesquelles attendent un humain et lesquelles sont désactivées ? Reprogrammer est une chose ; les remboursements et les annulations en sont une autre. Mon guide des workflows d'approbation et la matrice d'approbation des remboursements expliquent comment tracer ces limites.
3. Passation. Quand l'agent n'est pas sûr, l'humain reçoit-il tout l'historique ? L'exemple de Zendesk promet que la demande « can move to the support team with the conversation history and actions already taken ». Voyez le contexte de passation et les escalades d'agents IA dans Zendesk pour des configurations qui le font vraiment.

Le deuxième point est celui que j'entends le plus de la part des responsables du support. Un responsable CX d'une marque DTC de compléments alimentaires qui traite environ 7 000 tickets par mois l'a formulé ainsi à l'équipe eesel :

"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

Un assistant qui arrive par un annuaire vérifié relève ce niveau d'exigence, il ne l'abaisse pas. Le client fait davantage confiance à la connexion, donc une mauvaise réponse coûte plus cher. Mon guide des seuils de confiance et les propres paramètres de confiance d'intention de Zendesk sont par où je commencerais.

Où eesel s'intègre

eesel est un coéquipier IA que vous embauchez pour une mission précise, et sur Zendesk cette mission, c'est le helpdesk. Il rejoint votre compte comme agent, apprend de vos anciens tickets Zendesk, de vos articles de centre d'aide et de vos macros, et vous décidez, action par action, s'il s'exécute seul, attend une approbation ou est désactivé.

Pour être clair sur ce qu'il n'est pas : eesel n'est pas listé dans l'Open Service Directory, et personne n'a encore de fiche publique. Ce qu'il fait, c'est la couche vers laquelle l'OSD passe la main, l'agent qui décroche et les règles sur ce qu'il peut faire, et il fonctionne de la même façon que la demande vienne d'une personne, d'une bulle de chat ou, plus tard, de l'assistant de quelqu'un.

Comme l'OSD est un lancement pensé d'abord pour les développeurs, il vaut la peine de savoir qu'eesel a aussi une surface pour développeurs. La CLI eesel (npm install -g @eesel/cli) exécute depuis un terminal le même agent que celui du tableau de bord, et chaque commande affiche du JSON, de sorte qu'un script ou un agent de code comme Claude Code, Codex ou Cursor peut la piloter. Pour une équipe Zendesk qui se prépare au trafic des assistants, les commandes utiles sont celles qui reflètent les trois points ci-dessus :

eesel integrations connect zendesk     # a Zendesk admin approves the connection
eesel integrations zendesk actions     # every Zendesk action and its approval setting
eesel instructions                     # read or edit the agent's standing rules
eesel approvals list                   # held actions waiting on a person
eesel activity                         # what the agent did, newest first

Les écritures depuis la CLI suivent les mêmes règles d'approbation que le tableau de bord, et --dry-run affiche l'appel serveur exact qu'une écriture ferait sans l'envoyer, ce qui est la façon dont je relirais un changement de politique avant sa mise en ligne. Chaque espace de travail est aussi un serveur MCP auquel vous pouvez vous connecter depuis Claude Code avec une seule commande eesel mcp token. Ce serveur sert à vous permettre de piloter votre agent, pas aux assistants de vos clients, donc ne le confondez pas avec une fiche OSD. Mon article sur la CLI d'agent IA explique pourquoi cet accès au terminal compte pour les équipes de support.

Essayer eesel sur votre file Zendesk

Si l'Open Service Directory vous fait réfléchir à qui répond quand un assistant frappe à la porte, commencez par l'agent plutôt que par la fiche. eesel se branche sur Zendesk en une trentaine de minutes, apprend des tickets que votre équipe a déjà traités et vous permet de le rejouer sur des conversations passées avant qu'il réponde à qui que ce soit. Vous définissez quelles actions nécessitent un humain, et chaque exécution apparaît dans un journal d'activité que vous pouvez auditer.

Le plan gratuit comprend 100 crédits et toutes les fonctionnalités, et les plans payants démarrent à 299 $ par mois pour 500 crédits, un ticket valant un crédit quelle que soit sa durée (tarifs eesel). Si vous voulez d'abord la comparaison, voici eesel vs Zendesk AI. Sinon, essayez eesel sur vos propres tickets Zendesk.