Découvrabilité des serveurs MCP : comment un agent personnel trouve, choisit et utilise votre service

Un voyageur demande à son agent personnel : « Trouve-moi un cours de ski collectif pour mon fils de 8 ans à Val Thorens, la dernière semaine de février, et réserve-le. » L’agent lance une recherche web, tombe sur l’école de ski locale, repère qu’elle expose un serveur MCP (Model Context Protocol, le protocole ouvert par lequel un agent appelle des outils externes), s’y connecte tout seul, vérifie les créneaux, et prépare la réservation.

Cette scène est celle qu’on se raconte. Cet article vérifie, maillon par maillon, ce qui existe aujourd’hui (1er octobre 2026), ce qui est en cours de standardisation, et ce qui n’existe pas du tout. La réponse courte : la chaîne est incomplète, le maillon central (« passer d’une marque à son endpoint, avec confiance ») est en train d’être construit par trois chantiers concurrents, et personne n’a encore démontré de bout en bout la connexion automatique sans humain. Pour un petit ou moyen acteur, cela change la question : ce n’est pas « quel standard attendre ? » mais « quelles surfaces publier dès maintenant, pour être trouvé par les chemins qui fonctionnent déjà ? ».

Cet article prolonge Visa Trusted Agent Protocol : exploration du repo de référence. Celui-ci traitait de l’identité de l’agent vis-à-vis du site marchand (Web Bot Auth). Celui-là traite du sens inverse : comment l’agent découvre le marchand.

Périmètre : découverte et connexion. L’authentification fine, la conception des outils et les protocoles de paiement ne sont abordés que là où ils conditionnent la découverte.

1. Le scénario et ses cinq maillons

Pour que la scène d’introduction fonctionne, cinq choses doivent se produire, dans l’ordre :

 ① TROUVER       ② LOCALISER        ③ FAIRE            ④ SE CONNECTER     ⑤ RÉSERVER
 la marque       son endpoint       CONFIANCE          (consentement,     (créneau, panier,
 de confiance    agent              à cet endpoint     authentification)  paiement)

 recherche web   ??? (le maillon    identité du        OAuth, clé,        outils MCP,
 citations       manquant)          domaine, avis,     validation         protocole de
 fiches Google                      registre, review   humaine            commerce (UCP…)

Maillon	État au 1er octobre 2026	Détail
① Trouver la marque	Fonctionne	Recherche web et citations des IA (voir section 6)
② Localiser l’endpoint	Partiel	Quatre chemins coexistent, aucun n’est universel (sections 2 à 5)
③ Faire confiance	En construction	Racine de confiance = le domaine ; pas de label commun
④ Se connecter	Fonctionne, avec un humain	Consentement et OAuth ; pas de connexion « zéro clic » documentée
⑤ Réserver	Fonctionne pour le panier et le lien de paiement	La délégation du paiement reste minoritaire

Sur ce dernier point : selon Accenture, seuls 10 % des voyageurs accepteraient de confier entièrement un paiement à un agent, 84 % acceptent une simple assistance et 91 % veulent valider les moments clés (Source : Accenture, relayé par TOM.travel). Le maillon ④ restera donc, de toute façon, un point de validation humaine : l’enjeu de la découverte est de le rendre à un clic, pas de le supprimer.

2. Chemin n° 1 : l’ajout manuel

C’est le chemin le plus simple et, aujourd’hui, le seul que tous les agents personnels supportent : l’utilisateur (ou l’administrateur de son organisation) colle l’URL du serveur MCP distant.

2.1 Claude : le connecteur personnalisé et le lien d’installation

Dans Claude, un connecteur personnalisé est un serveur ajouté par URL ; il utilise exactement la même infrastructure qu’un connecteur de l’annuaire. La différence est ailleurs : revue Anthropic, découverte dans le produit, distribution. Anthropic documente aussi un lien d’installation qu’on peut mettre dans sa documentation, derrière un bouton « Connect to Claude » ou dans un e-mail d’accueil (Source : Claude Docs — Directory vs custom connectors) :

https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=Ecole%20de%20ski&connectorUrl=https%3A%2F%2Fmcp.exemple-esf.fr%2F

Le lien ne fait que préremplir le formulaire : l’utilisateur voit une alerte précisant que les valeurs viennent d’un lien externe, relit et confirme. Il ne contourne aucune permission.

En pratique, le bouton d’installation est le levier le moins cher pour un acteur qui a déjà un serveur MCP : une page « Utiliser avec votre assistant IA » sur le site, avec un lien par assistant, suffit à transformer un visiteur en utilisateur connecté.

2.2 Muse : « You bring the API »

Meta a ouvert Muse aux connecteurs tiers le 18 septembre 2026, avec la formule de Mark Zuckerberg « You bring the API » (Source : Runtime Wire). Un guide tiers décrit l’ajout d’un serveur MCP personnalisé : l’URL du serveur, une phrase pour nommer le service, des questions de transport et d’authentification, puis les identifiants via une invite sécurisée plutôt que dans le chat. Il précise que les serveurs MCP distants en HTTP fonctionnent le mieux (la machine virtuelle de Muse est dans le cloud de Meta, un serveur sur un portable n’est pas joignable), que les services uniquement OAuth peuvent fonctionner via le navigateur de Muse « avec plus d’allers-retours », et que Muse « peut aller chercher ces informations lui-même » si on lui colle le lien (Source : Parallel — custom integrations with Meta Muse, guide tiers daté de mi-septembre, avec la mention que Meta « change le produit rapidement »).

À retenir : le chemin OAuth de Muse est, à ce stade, moins fluide que celui des clés ou jetons. Un petit acteur qui veut être utilisable partout aura intérêt à proposer les deux (voir section 8.3).

2.3 Hermes : configuration locale et skills

Hermes Agent, agent personnel open source de Nous Research, supporte MCP par configuration et ligne de commande, et propose des skills partagées via un hub communautaire (agentskills.io). La documentation décrit une découverte « guidée par la communauté » plutôt que pleinement autonome ; elle insiste sur l’approbation des commandes, l’autorisation et l’isolation en conteneur (Source : Hermes Agent — documentation).

2.4 Limite du chemin manuel

L’ajout manuel suppose que l’utilisateur connaît déjà votre service. Il fonctionne pour la fidélisation (« rajoute le connecteur de mon école de ski habituelle ») et pas pour l’acquisition. Les chemins suivants servent l’acquisition.

3. Chemin n° 2 : annuaires et marketplaces

Les trois grandes plateformes ont tranché dans le même sens : un annuaire relu par la plateforme, avec suggestion dans la conversation.

3.1 Annuaire de connecteurs Claude et « Suggested Connectors »

Un connecteur listé dans l’annuaire Anthropic passe une revue. Deux avantages : il est parcourable et cherchable dans les produits Claude, et il est automatiquement éligible aux Suggested Connectors — Claude peut le recommander en conversation quand il est pertinent. Les connecteurs personnalisés ne sont jamais suggérés (Source : Claude Docs — Directory vs custom connectors).

Anthropic a lancé cette suggestion dynamique le 23 avril 2026, avec des exemples de réservation (Resy, Booking.com, Tripadvisor, Viator, Uber) et une garantie de consentement : avant de réserver ou d’acheter, Claude vérifie avec l’utilisateur (Source : Anthropic — New connectors in Claude for everyday life).

Point crucial, écrit noir sur blanc dans la documentation : l’annuaire Anthropic est indépendant du registre MCP ouvert. Publier dans le registre officiel ne fait pas apparaître votre serveur dans Claude (Source : Claude Docs).

3.2 Annuaire d’applications ChatGPT

Côté OpenAI, les applications de ChatGPT sont construites avec l’Apps SDK, qui repose sur MCP. La soumission est la plus exigeante des trois et sa documentation est précise (Source : OpenAI — App submission) :

vérification individuelle ou d’entreprise de l’organisation ;
vérification du domaine : un jeton en texte brut servi sur https://<hôte>/.well-known/openai-apps-challenge ;
cinq cas de test positifs, trois négatifs (refus appropriés), des identifiants de revue, une vidéo de démonstration, des notes de version ;
quatre URL de fiche : site, support, confidentialité, conditions ;
un seul serveur MCP par application ; OpenAI rescanne les serveurs hébergés chaque jour.

La découverte, elle, est décrite comme « recherche par nom et suggestions ». Les applications qui montrent une forte utilité réelle peuvent bénéficier d’une distribution renforcée (placement dans l’annuaire, suggestions proactives). À la DevDay du 29 septembre 2026, OpenAI a annoncé que « quand un plugin est pertinent pour une question, ChatGPT peut le faire apparaître et laisser l’utilisateur le connecter sur place », d’après un compte rendu de développeurs (Source : Alpic — OpenAI Dev Day 2026).

3.3 Muse Connectors

Pour Muse, la même couverture presse note un angle mort : Meta « n’a pas décrit comment Muse choisira entre des connecteurs qui se recoupent, si les utilisateurs pourront fixer un fournisseur préféré, ni comment les développeurs mesureront les renvois et les actions accomplies » (Source : Runtime Wire). Autrement dit : le classement des connecteurs, c’est-à-dire la visibilité, est encore une boîte noire sur la plateforme qui compte le plus de nouveaux agents.

3.4 Dots, Instinct : ce qu’on sait

Dots (OpenAI) est présenté comme un agent « toujours actif », avec son propre ordinateur cloud et son navigateur. Selon The Neuron il se connecte à plus de 4 000 applications ; le détail de l’intégration tierce n’est, à ce stade, documenté que par la presse et non par une page produit que j’ai pu lire (Source : The Neuron — DevDay 2026). Instinct, agent par SMS et WhatsApp réservé sur invitation, serait en discussion pour lever 1 milliard de dollars à 10 milliards de valorisation et revendiquerait plus de 100 000 utilisateurs (Source : AI Weekly, d’après Business Insider). Je n’ai trouvé aucune documentation publique sur la façon dont Instinct sélectionne ou intègre un fournisseur tiers. À ce stade, ce sont des acteurs dont on ne peut pas dire comment ils découvrent un serveur MCP.

En pratique, les annuaires sont le chemin le plus probable à 6-12 mois pour l’acquisition, parce que c’est là que le consentement, la revue de sécurité et le classement se rejoignent. Le coût d’entrée est réel (revue, cas de test, vérification de domaine) mais il se fait une fois.

4. Chemin n° 3 : le registre officiel MCP

Le registre MCP officiel est le grand malentendu de l’écosystème. Ce n’est pas l’annuaire que consultent les assistants.

4.1 Ce que c’est

Le registre est un dépôt centralisé de métadonnées de serveurs MCP publics, soutenu par Anthropic, GitHub, PulseMCP et Microsoft. Il est en préversion : des changements cassants ou des remises à zéro des données sont possibles. Il stocke un fichier server.json par serveur (Source : MCP Registry — About).

La documentation est explicite sur son rôle :

« The MCP Registry is not intended to be directly consumed by host applications. Instead, host applications should consume other MCP registries, such as downstream marketplaces. »

Il est destiné aux agrégateurs en aval (places de marché de serveurs MCP) qui en tirent les métadonnées « à intervalle régulier mais peu fréquent, par exemple une fois par heure ». Il ne supporte pas les serveurs privés. Il délègue l’analyse de sécurité du code aux registres de paquets et aux agrégateurs.

4.2 Un `server.json` minimal pour un serveur distant

Voici la forme observée dans le registre pour un serveur distant en streamable HTTP (champs réduits ; le schéma complet est publié par le projet) :

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "fr.exemple-esf/reservation-cours",
  "title": "École de ski exemple — cours collectifs",
  "description": "Recherche de cours collectifs par station, niveau, âge et date ; ajout au panier.",
  "version": "1.0.0",
  "websiteUrl": "https://www.exemple-esf.fr",
  "remotes": [
    { "type": "streamable-http", "url": "https://mcp.exemple-esf.fr/mcp" }
  ]
}

Le nom suit le DNS inversé : fr.exemple-esf/… ne peut être publié que par le détenteur du domaine exemple-esf.fr.

4.3 Prouver qu’on possède le domaine

Le registre propose trois méthodes d’authentification. GitHub donne un espace de noms io.github.<compte>/…. Les deux méthodes de domaine (com.exemple.*/…) reposent sur une paire de clés (Source : MCP Registry — Authentication) :

# Génération de la clé et de la preuve (Ed25519)
openssl genpkey -algorithm Ed25519 -out key.pem
PUBLIC_KEY="$(openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64)"

# Option A — enregistrement DNS TXT sur le domaine
echo "exemple-esf.fr. IN TXT \"v=MCPv1; k=ed25519; p=${PUBLIC_KEY}\""

# Option B — fichier servi sur https://exemple-esf.fr/.well-known/mcp-registry-auth
echo "v=MCPv1; k=ed25519; p=${PUBLIC_KEY}" > mcp-registry-auth

L’option B convient à un acteur qui ne gère pas facilement sa zone DNS : un fichier statique suffit. Dans les deux cas, la publication passe ensuite par l’outil mcp-publisher.

4.4 Un constat de terrain sur la recherche

L’API publique du registre accepte un paramètre search. Test du 1er octobre 2026 :

curl -s 'https://registry.modelcontextprotocol.io/v0/servers?search=ski&limit=40'

Sur la première page de 40 résultats, aucun serveur lié au ski : la recherche est une recherche de sous-chaîne, qui renvoie des serveurs de « skills » (compétences d’agents) et un serveur de soins de la peau. De même search=esf renvoie des serveurs Salesforce. Les doublons de versions encombrent aussi la liste. Observation limitée (première page, un jour), mais elle illustre pourquoi le registre n’est pas fait pour être interrogé par un agent en langage naturel.

En pratique, publiez dans le registre officiel pour l’ancrage de l’identité et pour être repris par les agrégateurs, pas pour la visibilité directe.

5. Chemin n° 4 : la découverte par le web

C’est ici que se joue votre scénario d’introduction : l’agent a trouvé la marque, et cherche son endpoint sans que personne ne lui ait donné l’URL. Quatre familles de propositions se disputent le terrain. Les trois premières sont des fichiers à publier sur son propre domaine, sous /.well-known/ (la convention de la RFC 8615 pour les ressources de métadonnées d’un site).

5.1 Server Cards et `server/discover`

L’idée : publier une fiche d’identité du serveur MCP à un endroit prévisible, pour que navigateurs, robots d’indexation et registres puissent le découvrir sans ouvrir de session. La proposition s’appelle SEP-2127 (successeur de SEP-1649). Au 30 septembre 2026, elle est toujours « en revue » : le chemin exact a déjà changé plusieurs fois, et la proposition a été déplacée de la voie « Standards » vers la voie « Extensions », avec une implémentation de référence expérimentale (Source : SEP-2127 sur GitHub ; Source : charte du groupe de travail Server Card).

Le groupe de travail précise son périmètre : définir le format de la fiche, la façon dont un client la découvre, et recommander comment l’initiative externe « AI Card » doit s’articuler avec elle. Il exclut explicitement un registre généraliste (propriété du groupe Registry) et demande que la fiche reste « aussi proche que possible d’un sous-ensemble de server.json ».

Ne pas confondre avec server/discover, introduit par la version 2026-07-28 de la spécification : une requête que le serveur DOIT implémenter pour annoncer ses versions de protocole, ses capacités et son identité — mais qu’on appelle une fois qu’on connaît déjà l’URL. Cette version rend aussi MCP sans état (suppression du handshake initialize) et déprécie l’enregistrement dynamique de clients OAuth au profit des Client ID Metadata Documents (Source : MCP — Key changes 2026-07-28). server/discover répond à « que sais-tu faire ? », pas à « où es-tu ? ».

5.2 ARD et `ai-catalog.json`

L’Agentic Resource Discovery (ARD) est une spécification ouverte (licence Apache 2.0) annoncée par Google le 17 juin 2026, qui s’appuie sur le modèle de données « AI Catalog » du groupe de travail de la Linux Foundation. Elle repose sur deux primitives (Source : Google Developers Blog — Announcing the Agentic Resource Discovery specification) :

un catalogue : un fichier ai-catalog.json que le fournisseur publie à un chemin /.well-known/ de son domaine ;
un registre : un moteur de recherche tiers qui explore les catalogues publiés, les indexe, et répond à des requêtes en langage naturel.

Trois propriétés intéressent un petit acteur :

La racine de confiance est le domaine. Les éditeurs peuvent joindre des métadonnées vérifiables permettant au client de « confirmer l’identité cryptographique réelle de l’éditeur avant de se connecter à l’endpoint ».
Un agent peut court-circuiter la recherche en récupérant directement le catalogue d’un domaine partenaire connu.
L’hébergement seul ne garantit pas l’inclusion dans un registre : un registre choisit ce qu’il indexe (Source : Zuplo — Agentic Resource Discovery).

Un cas réel, observé le 1er octobre 2026 : le catalogue de SnowSure (service d’informations d’enneigement) à https://www.snowsure.ai/.well-known/ai-catalog.json. Il contient un bloc host (identité did:web:www.snowsure.ai, manifeste de confiance signé) et sept entrées : un serveur MCP (dont l’entrée pointe vers sa fiche server-card.json, de type application/mcp-server-card+json), deux API, un agent A2A, deux sous-catalogues dont un « réseau de stations », et un registre. Chaque entrée porte un identifiant en URN, la liste des capacités, et des requêtes représentatives en langage naturel — précisément ce dont un registre a besoin pour répondre à « cours de ski pour un enfant de 8 ans » :

{
  "specVersion": "1.0",
  "host": {
    "displayName": "SnowSure",
    "identifier": "did:web:www.snowsure.ai",
    "trustManifest": {
      "identity": "did:web:www.snowsure.ai",
      "identityType": "did",
      "signature": "…"
    }
  },
  "entries": [
    {
      "identifier": "urn:air:snowsure.ai:server:mcp",
      "displayName": "SnowSure MCP Server",
      "type": "application/mcp-server-card+json",
      "url": "https://www.snowsure.ai/.well-known/mcp/server-card.json",
      "description": "Hosted Streamable HTTP MCP server for ski snow conditions…",
      "capabilities": ["get_snow_report", "find_best_powder", "plan_ski_trip"],
      "representativeQueries": [
        "is Aspen Mountain open right now — base depth and lifts open of total"
      ]
    }
  ]
}

(Extrait raccourci du catalogue réel.) Statut : brouillon de standard, à adoption inégale. L’annonce évoque des partenaires de lancement ; aucune source ne me permet d’affirmer qu’un assistant grand public interroge aujourd’hui un registre ARD pour choisir un connecteur.

5.3 UCP : le profil du marchand

L’Universal Commerce Protocol (UCP), publié par Google le 11 janvier 2026 avec plus de 20 partenaires dont Shopify, Etsy, Walmart, Target, Stripe, Visa et Mastercard, prend le problème par le commerce : une entreprise publie à /.well-known/ucp un manifeste JSON de ses services, capacités (paiement, remises, livraison), gestionnaires de paiement et endpoints, que l’agent découvre « sans intégration codée en dur ». Les transports possibles sont REST, MCP et A2A (Source : Google Developers Blog — Under the hood: UCP).

Deux faits de septembre à noter :

Shopify a déprécié son serveur MCP Storefront historique (https://{shop}/api/mcp) au profit d’un point d’entrée UCP à https://{shop}/api/ucp/mcp, avec des outils de catalogue, de panier et de checkout (Source : Shopify — Storefront MCP). L’exposition MCP d’une boutique a donc été absorbée par le protocole de commerce.
UCP a créé un Lodging Technical Council (11 août) avec Amadeus, Booking.com, Expedia, Google, Hilton, Marriott et Trip.com pour spécifier la réservation hôtelière (Source : Abondance). Aucune trace d’un travail équivalent sur les activités à créneau (cours, excursions) dans les sources que j’ai lues.

5.4 A2A : l’Agent Card

Le protocole Agent2Agent (A2A) a sa propre fiche, l’Agent Card, récupérable à /.well-known/agent-card.json. Elle décrit l’agent, ses compétences, ses capacités et ses endpoints. Des brouillons IETF explorent déjà sa découverte par WebFinger (Source : IETF — draft-zhao-a2a-webfinger). À la différence de MCP, A2A modélise un agent qui dialogue avec un autre agent : pertinent pour un acteur qui exposerait un agent de conseil plutôt que des outils.

5.5 WebMCP et NLWeb : quand le site est l’API

Deux propositions partent du site web lui-même.

WebMCP permet à une page d’exposer des outils directement au navigateur. Le brouillon du Web Machine Learning Community Group (statut « Draft Community Group Report » au 30 septembre 2026, pas une Recommandation du W3C) définit trois méthodes : registerTool() pour exposer une fonction JavaScript avec description en langage naturel, getTools() pour les découvrir, executeTool() pour les appeler. Il existe une API déclarative pour les formulaires et une API impérative pour la logique complexe ; Microsoft est co-auteur aux côtés de Google. La spécification prévoit explicitement trois menaces d’injection de prompt : attaques par les métadonnées, injection par les sorties d’outil, ciblage de l’implémentation (Source : spécification WebMCP ; Source : heise).

Forme indicative (les signatures exactes évoluent avec le brouillon) :

// Indicatif : exposer la recherche de cours à un agent qui navigue sur la page
document.modelContext.registerTool({
  name: "rechercher_cours",
  description:
    "Cherche des cours collectifs par station, niveau, âge de l'élève et date.",
  inputSchema: {
    /* JSON Schema : station, niveau, dateDebut, dateNaissanceEleve */
  },
  execute: async (args) =>
    fetch(`/api/cours?${new URLSearchParams(args)}`).then((r) => r.json()),
});

L’intérêt pour un petit acteur : le parcours de réservation web existant devient pilotable sans serveur MCP séparé. L’enjeu est réel, car certains agents réservent déjà en navigant. Skift documente que Muse réserve les hôtels « par un navigateur qui parcourt les sites grand public comme le ferait un humain », et seulement les vols par une connexion directe à Duffel (Source : Skift). Pour une activité sans API connue de l’agent, c’est donc le site qui est l’interface.

NLWeb, de Microsoft (licence MIT), est le pendant côté serveur : un cadre qui s’appuie sur les données schema.org et les flux RSS déjà publiés par le site, et expose deux points d’entrée, /ask (langage naturel) et /mcp. Un service « AgentFinder » est censé aider les systèmes d’IA à localiser les endpoints NLWeb (Source : GitHub — microsoft/NLWeb). Je n’ai trouvé aucune mesure d’adoption.

5.6 llms.txt : la solution populaire qui ne marche (presque) pas

llms.txt est un fichier Markdown à la racine du site, qui liste les pages importantes à destination des modèles. C’est la proposition la plus déployée et la moins efficace pour la découverte :

Common Crawl a analysé 584 107 fichiers llms.txt dans son archive de juillet 2026 : taux de présence de 11,72 % des domaines échantillonnés, 68,27 % générés par modèle (Wix seul en produit 41,34 %), 22,56 % sans aucun lien, 6,59 % avec un langage de politique non autorisé et dix fichiers contenant des tentatives d’injection de prompt (dont quatre réelles) (Source : Common Crawl).
Côté usage, l’étude Ahrefs sur 137 000 domaines (mai 2026) trouve que 97 % des fichiers llms.txt n’ont reçu aucune requête ; les robots de récupération d’IA ne pèsent que 1,1 % des requêtes, les outils d’audit SEO 21,7 %. Google déclare que le fichier « n’aura d’impact ni positif ni négatif » sur la visibilité ; OpenAI et Anthropic renvoient à robots.txt pour le contrôle des robots (Source : PPC Land, d’après Originality.ai et Ahrefs).

Nuance utile : llms.txt reste pertinent comme documentation pour des agents de développement — la documentation de MCP elle-même invite en en-tête les agents à récupérer son index à https://modelcontextprotocol.io/llms.txt. Il aide un agent de code à lire votre doc API ; il ne fait pas qu’un agent de consommation vous découvre.

En pratique, publiez un llms.txt si cela coûte dix minutes, mais ne comptez pas dessus pour le maillon ②. Le même constat vaut pour ai.txt : aucune source n’établit qu’un assistant grand public l’exploite pour choisir un fournisseur.

5.7 Web Bot Auth : l’identité de l’agent, dans l’autre sens

Pour être complet : tout ce qui précède décrit le site qui se présente à l’agent. Le sens inverse — l’agent qui prouve son identité au site — est couvert par Web Bot Auth, un ensemble de brouillons IETF fondés sur les signatures de messages HTTP (RFC 9421), avec un en-tête Signature-Agent et un répertoire de clés au format JWKS servi à une URL bien connue (Source : IETF — HTTP Message Signatures for Bots). Il est déjà mis en production par Cloudflare, Anthropic et OpenAI selon une synthèse tierce (Source : Stellagent). Le détail technique est dans l’article précédent. Pour la découverte, la conséquence est simple : un acteur qui sait reconnaître les agents qui le visitent peut leur réserver un traitement privilégié (limites, tarification, accès).

5.8 Récapitulatif

Mécanisme	Chemin / forme	Initiative	Statut au 1er oct. 2026	Qui le lit aujourd’hui
`server/discover`	RPC MCP	MCP, spec 2026-07-28	Publié	Un client qui connaît déjà l’URL
Server Card	`/.well-known/mcp/server-card.json` (chemin instable)	MCP, SEP-2127	En revue, extension expérimentale	Peu de clients documentés
ARD	`/.well-known/ai-catalog.json`	Google + Linux Foundation	Brouillon ouvert (juin 2026)	Registres ARD ; usage grand public non établi
UCP	`/.well-known/ucp`	Google, Shopify, Stripe…	Publié (janv. 2026), v4 en août	Agents de commerce, plateformes marchandes
A2A Agent Card	`/.well-known/agent-card.json`	A2A	Publié	Clients A2A
WebMCP	`registerTool()` dans la page	W3C CG (Google, Microsoft)	Brouillon de groupe communautaire	Navigateurs avec agent intégré
NLWeb	`/ask`, `/mcp`	Microsoft	Open source (MIT)	Non documenté
`llms.txt`	`/llms.txt`	Communauté	Non normalisé	97 % des fichiers jamais requis

Constat transversal : quatre propositions écrites dans /.well-known/ et aucune convention gagnante. On le voit sur les sites eux-mêmes. Un site de location de ski français publie une « capability card » à un chemin propre (/.well-known/capability-card.json) décrivant un serveur MCP sans authentification de recherche d’environ 9 000 appartements, avec un schéma qui ne correspond à aucun des standards ci-dessus (Source : ski-france.com — capability card) ; SnowSure, lui, publie plusieurs variantes en parallèle (son catalogue ARD renvoie vers une fiche MCP à un chemin différent des autres).

6. Le maillon manquant : de la marque à l’endpoint

Reprenons la scène d’introduction, étape par étape, avec ce qui existe réellement.

① L’agent trouve la marque. Ce maillon fonctionne, et c’est lui qui est le mieux documenté en France. Un test de Nicolas François sur Google et ChatGPT (45 requêtes, 5 destinations dont Chamonix) montre que, dès qu’une question approche la réservation, les sources citées sont majoritairement des fiches Google d’établissements (44 sources sur 79 ; 21 sur 27 pour les guides de Chamonix) et non les sites des acteurs, et que le Mode IA recommande des guides par leur nom en affichant des prix pris là où ils sont lisibles (Source : IA, Tech & Travel Café). Une enquête GetYourGuide ajoute que plus des deux tiers des utilisateurs partent de ChatGPT pour l’inspiration avant de revenir sur Google, et que 70 % des opérateurs d’activités sont de très petites structures, dépendantes des plateformes pour exister dans les moteurs IA (Source : TOM.travel). Test limité (un jour, une personne), mais cohérent avec le reste.

② L’agent localise l’endpoint. Trois scénarios possibles aujourd’hui :

Scénario	Mécanisme	Humain requis ?	Réalité
A	L’assistant suggère un connecteur de l’annuaire quand l’intention correspond	Oui : clic de connexion	Existe (Claude depuis avril, ChatGPT : suggestions)
B	L’agent lit le site de la marque, y trouve un lien d’installation ou une URL de serveur, et se configure	Oui : consentement	Possible pour Muse (« peut aller chercher lui-même »), non documenté par Meta
C	L’agent interroge un registre (ARD) ou lit `/.well-known/…` du domaine de la marque	Idéalement non, hors consentement	Non démontré sur un assistant grand public

Pour le scénario B, un détail pratique : l’agent suit un lien, il n’invente pas un chemin. Si la page d’accueil ou la page « réserver » d’une école contient un lien explicite (Connect to Claude, URL du serveur MCP, mention dans une page de documentation lisible), un agent navigateur peut le trouver. Si l’information n’existe que dans un fichier /.well-known/ qu’aucun agent n’a de raison de requêter, elle ne sera pas lue.

③ La confiance. Aucun assistant grand public n’expose, à ma connaissance, de critère documenté pour accepter un serveur découvert sur le web. Les mécanismes disponibles : revue de l’annuaire (Claude, ChatGPT), vérification du domaine (ChatGPT, registre MCP), identité cryptographique du domaine (ARD). La conclusion est que la confiance suit le domaine : c’est sur le domaine de la marque (ou sur la marque reconnue par l’utilisateur dans l’annuaire) que tout converge.

④ La connexion. Pour un serveur qui exige un compte, OAuth. La spécification MCP de juillet 2026 déprécie l’enregistrement dynamique de clients (qui permettait à n’importe quel client de s’inscrire seul) au profit des Client ID Metadata Documents (CIMD), où l’URL du client sert d’identifiant et héberge ses métadonnées ; l’enregistrement dynamique reste un repli (Source : MCP — Key changes 2026-07-28). Conséquence pratique : un serveur de recherche sans authentification (comme celui du site de location ci-dessus) est découvrable et utilisable sans friction ; seule la réservation exige un compte.

⑤ La réservation. Elle fonctionne par outils MCP jusqu’au panier ; le paiement reste à l’utilisateur dans les implémentations que je connais. Le modèle « l’agent prépare, l’humain paie » est celui que les chiffres de confiance justifient (section 1).

En pratique, la connexion « automatique » n’est pas encore un manque technique, c’est un choix de conception : les plateformes veulent un consentement visible. Le gain de découvrabilité à viser est « un clic au bon moment », pas « zéro clic ».

7. Confiance et sécurité : pourquoi la connexion automatique est lente à arriver

Un agent qui se connecte à un serveur découvert sur le web accorde à ce serveur une influence sur son raisonnement. Les risques sont documentés :

Empoisonnement d’outil (tool poisoning) : des instructions cachées dans la description d’un outil, invisibles pour l’utilisateur mais lues par le modèle, peuvent détourner le comportement de l’agent vis-à-vis d’autres serveurs. L’OWASP le classe MCP03:2025 dans son MCP Top 10, avec les « rug pulls » (un serveur de confiance qui change ses outils après coup) et l’usurpation de nom (Source : Cloud Security Alliance — MCP tool poisoning).
Pollution des listes : Common Crawl a trouvé des fichiers llms.txt contenant des tentatives d’injection ; le registre MCP prévoit des mesures anti-spam (vérification de l’espace de noms, limites de champs, retrait manuel) et envisage une détection par IA.
Reconnaissance du site par l’agent : la spécification WebMCP elle-même énumère les attaques par métadonnées et par sorties d’outil.

Ces risques expliquent pourquoi les plateformes ont d’abord opté pour des annuaires revus. Ils expliquent aussi l’accent mis sur le domaine comme racine de confiance : c’est la seule identité qu’une petite structure possède déjà et qu’un attaquant ne peut pas fabriquer.

En pratique, pour un petit acteur, la protection est de servir peu et de servir en lecture seule. Un serveur dont les outils sont des recherches (sans effet de bord) et dont l’ajout au panier se limite à créer un panier dont l’utilisateur valide le paiement est le profil de risque le plus faible, donc le plus facile à faire accepter par une revue.

8. L’autonomisation : ce qui permet à un petit acteur d’y arriver sans équipe

L’enjeu du « 1) être visible, 2) enchaîner sur la réservation » est que la majorité des acteurs n’ont pas de développeurs. Plusieurs voies existent pour exposer un service sans écrire un serveur MCP.

8.1 Laisser la plateforme exposer à votre place

Voie	Principe	Ce qu’il faut savoir
Shopify (UCP)	Chaque boutique expose un endpoint MCP de catalogue, panier et checkout	Migration en cours de `/api/mcp` vers `/api/ucp/mcp` ; l’activation par défaut n’est pas précisée dans la documentation
WordPress (Abilities API + MCP Adapter)	Le site déclare des « abilities » typées, l’adaptateur officiel les expose en MCP	Exposition publique explicite via `meta.mcp.public` ; chaque ability a un `permission_callback` ; transport HTTP via application passwords ou OAuth
Google Cloud API Gateway	On annote une spécification OpenAPI 3.x existante (`x-google-api-management.mcp`) ; la passerelle devient un serveur MCP distant	En préversion publique ; jusqu’à 1 000 outils ; les descriptions d’outils restent à écrire
Agrégateur d’expériences (ex. Holibob)	Un SDK donne accès à plus de 500 000 expériences via 45 API partenaires	Vous existez dans les agents par le biais d’un tiers ; dépendance et commission

(Source : Shopify ; Source : WordPress Developer Blog ; Source : Google Developers Blog ; Source : TOM.travel — Holibob SDK).

Remarque d’opinion : la voie « plateforme » est la plus rapide, mais elle fait de la plateforme le propriétaire de la relation de découverte. Une école de ski ou un hébergeur qui n’est visible que via un agrégateur reproduit, dans le monde des agents, la dépendance qu’il a connue avec les OTA (agences de voyage en ligne).

8.2 Publier une fédération plutôt que N serveurs

Quand une fédération regroupe des dizaines de structures locales (écoles de ski d’un réseau, offices de tourisme d’une vallée), le catalogue ARD prévoit des sous-catalogues imbriqués : le catalogue de SnowSure en publie un pour son « réseau de stations ». Un serveur MCP unique, filtré par station, plus un catalogue de la fédération qui référence les entrées par station, évite de demander à chaque petite structure de déployer quoi que ce soit.

8.3 Choisir son authentification pour être utilisable partout

D’après les guides de Muse et les exigences des annuaires :

recherche publique sans authentification : compatible partout, y compris les agents navigateur et les revues ;
ajout au panier ou action : OAuth (CIMD en priorité, selon la spécification de juillet 2026), avec repli par jeton pour les agents dont le flux OAuth est moins fluide.

8.4 Faire de son site une API : WebMCP et données structurées

Le site est la dernière ligne de défense. Si aucune des voies précédentes n’est possible, un parcours de réservation propre (étapes balisées, pas de CAPTCHA bloquant, informations de prix et de niveau dans le HTML et non dans des PDF) est ce qui permettra à un agent navigateur comme Muse de conclure. WebMCP, quand il sera généralisé, en sera le prolongement naturel.

9. Plan d’action ordonné

Classé par rapport efficacité/coût aujourd’hui, pas par intérêt théorique :

#	Action	Coût	Pourquoi maintenant
1	Fiche Google complète + données structurées schema.org (offres, prix, langues, créneaux)	Faible	C’est ce que les IA citent dans 44 réponses sur 79 (maillon ①)
2	Serveur MCP distant en lecture seule, recherche publique sans authentification	Moyen	Fait de vous une source lisible ; profil de risque minimal
3	Page « Utiliser avec votre assistant » avec liens d’installation (Claude, etc.)	Très faible	Convertit la visite en connexion, sans attendre un standard
4	Action d’ajout au panier derrière OAuth, paiement par l’utilisateur	Moyen	Aligné avec la défiance mesurée (10 % de délégation totale)
5	Publication au registre MCP officiel avec preuve DNS ou HTTP	Faible	Ancre l’identité et alimente les agrégateurs en aval
6	Soumission aux annuaires Claude et ChatGPT	Moyen (revue)	Seul chemin documenté vers les suggestions en conversation
7	Publier `ai-catalog.json` (et une fiche serveur) sous `/.well-known/`	Très faible	Pari à bas prix sur le scénario C ; sans effet démontré aujourd’hui
8	Parcours web agent-compatible, puis WebMCP	Variable	Couvre les agents qui réservent par navigateur
9	`llms.txt`	Très faible	Utile aux agents de développement, pas à la découverte

Les actions 1 à 4 donnent un résultat mesurable cette saison. Les actions 5 à 7 sont des investissements de positionnement. L’action 9 ne devrait pas retarder les autres.

10. Pièges et limites de cet article

Sources de presse pour Dots et Instinct. Je n’ai pas pu lire les pages produit officielles ni les articles d’Axios et de CNBC (accès refusé). Ce que j’écris sur ces deux agents repose sur des comptes rendus tiers. Les chiffres (4 000 applications, 100 000 utilisateurs, 1 milliard de dollars en discussion) sont à vérifier.
Muse. L’essentiel sur l’ajout de serveurs vient d’un guide tiers et d’un article de presse spécialisé ; Meta a indiqué que le produit change vite. Je n’ai pas trouvé de documentation développeur de Meta sur la procédure d’enregistrement.
Chemins /.well-known/ instables. Le chemin de la fiche serveur MCP a changé plusieurs fois selon les sources secondaires ; avant de publier, vérifier l’état de SEP-2127.
Nom du fichier ARD. Le blog Google parle d’un fichier ai-catalog.json ; une source tierce évoque ard.json. J’ai retenu le blog Google et le catalogue réel de SnowSure, qui utilise ai-catalog.json.
A2A et WebFinger. Les brouillons IETF cités sont des documents de travail, pas des standards.
Aucune mesure de trafic. Je n’ai trouvé aucune étude chiffrant la part des connexions à des serveurs MCP issues de chacun de ces chemins. Les recommandations de la section 9 sont un jugement sur des coûts et des risques, pas sur des résultats mesurés.
Observation du registre. Le test sur search=ski porte sur la première page de 40 résultats le 1er octobre 2026 ; la pagination n’a pas été parcourue.

11. Conclusion

Sur le trajet « recherche web → marque de confiance → serveur MCP → réservation », trois maillons sur cinq fonctionnent déjà (trouver la marque, se connecter avec consentement, réserver jusqu’au panier). Le maillon central — retrouver, depuis la marque, un endpoint de confiance sans que l’utilisateur ait à coller une URL — repose aujourd’hui sur les annuaires revus par les plateformes, et demain, peut-être, sur des catalogues publiés sous le domaine et indexés par des registres (ARD, Server Cards). Rien ne garantit que ce « demain » arrive vite ni sous cette forme : les propositions sont jeunes, concurrentes, et sans lecteur grand public démontré.

Trois idées à retenir :

Le domaine est la racine de confiance de tout le monde : registre MCP, ARD, vérification OpenAI. Un acteur qui maîtrise son domaine, sa fiche Google et son parcours de réservation a déjà fait l’essentiel du travail de fond.
Le consentement humain n’est pas un défaut à supprimer. C’est le point où les plateformes placent leur responsabilité. Optimiser pour « un clic au bon moment » est réaliste ; viser « zéro clic » ne l’est pas, et les chiffres de confiance donnent raison aux plateformes.
L’autonomisation passera par les plateformes et les agrégateurs pour la majorité des petites structures. Le risque est de ne pas posséder sa propre découvrabilité : publier son identité (domaine, catalogue, registre) en plus de passer par un intermédiaire est ce qui préserve la relation.

À surveiller dans les trois prochains mois : l’issue de SEP-2127, l’apparition d’un lecteur grand public de catalogues ARD, la documentation développeur de Muse Connectors (critères de classement), et un éventuel travail UCP sur les activités à créneau.