Agentic Resource Discovery (ARD) : la découverte, maillon manquant de l'IA agentique

Par THOMAS FOUTREIN · 2026-07-08

Annoncé en juin 2026 par Google, Microsoft et Hugging Face, Agentic Resource Discovery (ARD) standardise la découverte des ressources agentiques (agents, serveurs MCP, API). Le chaînon qui manquait entre MCP et A2A : décryptage technique d'un protocole émergent.

Tags : ARD, IA agentique, MCP, A2A, interopérabilité, protocoles ouverts, standards IA

En deux ans, l'IA agentique est passée du prototype à la production. Deux protocoles ouverts se sont imposés comme socle : le Model Context Protocol (MCP), qui relie un agent à ses outils et à ses données, et l'Agent2Agent (A2A), qui fait dialoguer les agents entre eux. Il restait une question qu'aucun des deux ne résout : comment un agent trouve-t-il la bonne ressource à appeler, parmi des centaines de serveurs MCP, d'agents et d'API ?

Annoncé le 17 juin 2026, Agentic Resource Discovery (ARD) vient combler ce vide. C'est un protocole de découverte, et non d'invocation. Une distinction qui change tout. Décryptage.

La découverte, angle mort de l'IA agentique

MCP et A2A répondent à la question du comment appeler une ressource déjà connue. Aucun ne répond au où la trouver. Or, à l'échelle d'une entreprise (sans même parler de l'Internet), un agent qui veut accomplir une tâche se heurte à trois questions, toutes situées avant l'appel :

  1. Où vit la bonne capacité ? Quel serveur MCP, quel agent A2A, quelle API ?
  2. Laquelle choisir parmi plusieurs candidates équivalentes ?
  3. Est-il sûr de s'y connecter ? Quelle identité, quelles attestations de conformité ?

Une analogie : MCP et A2A vous disent comment passer un appel téléphonique une fois le numéro en main. ARD, c'est l'annuaire et le service de renseignements. Sans lui, chaque orchestrateur d'agents recâble à la main sa propre liste de ressources, une approche qui ne tient pas à l'échelle.

Qu'est-ce qu'ARD, exactement ?

ARD est une spécification ouverte qui définit comment cataloguer, rechercher et découvrir des ressources agentiques : agents, serveurs MCP, agents A2A, Skills, API, workflows. Bref, tout ce qui peut être représenté comme une entrée de catalogue. Le principe tient en une phrase, tirée de la spécification :

ARD se situe entièrement avant l'invocation. Il aide le client à trouver la bonne ressource ; la ressource est ensuite appelée par son propre mécanisme natif.

Autrement dit, ARD est une enveloppe agnostique : il ne remplace ni MCP, ni A2A, ni les runtimes d'API. Il référence ces artefacts, aide à choisir le bon, puis s'efface.

Côté gouvernance, le pedigree est notable. Les auteurs sont Junjie Bu (Google), R.V. Guha (Microsoft) et Shaun Smith (Hugging Face). Le nom de Guha n'est pas anodin : c'est l'un des architectes de schema.org, de RSS et de RDF, exactement le profil pour standardiser une couche de découverte à l'échelle du web. La spécification est publiée sous licence Apache 2.0 et soutenue, dès le lancement, par Cisco, Databricks, GitHub, GoDaddy, Nvidia, Salesforce, ServiceNow et Snowflake. Elle s'appuie sur un modèle de données ouvert préexistant, AI Catalog, qu'elle étend avec des primitives de découverte.

Deux couches : un manifeste et un registre

ARD repose sur deux mécanismes complémentaires. Le schéma ci-dessous résume le parcours complet, de la publication d'un catalogue jusqu'à l'invocation de la ressource.

Schéma du fonctionnement d'ARD : publication d'un manifeste, indexation par un registre, recherche en langage naturel, puis invocation via le protocole natif

1. La découverte statique : le manifeste ai-catalog.json

Une organisation publie un manifeste à un emplacement conventionnel défini par la spécification, /.well-known/ai-catalog.json, qui liste ses ressources. Chaque entrée porte un identifiant URN ancré au domaine (urn:air:<éditeur>:<espace>:<nom>), un type exprimé sous forme de media type défini par la spécification (non encore enregistré à l'IANA — par exemple application/mcp-server-card+json ou application/a2a-agent-card+json), et soit une URL vers l'artefact, soit l'artefact intégré directement.

{
  "specVersion": "1.0",
  "host": { "displayName": "Pulse by Astek", "identifier": "did:web:pulse.astek.com" },
  "entries": [
    {
      "identifier": "urn:air:pulse.astek.com:server:portal",
      "displayName": "Serveur MCP du Portail Pulse",
      "type": "application/mcp-server-card+json",
      "url": "https://pulse.astek.com/.well-known/mcp/portal.json",
      "capabilities": ["SearchCatalog", "ShowTechRadar"],
      "representativeQueries": [
        "trouver une compétence Kubernetes",
        "afficher le tech radar"
      ]
    }
  ]
}

Le champ representativeQueries est une bonne idée de conception : il fournit, en langage naturel, les questions auxquelles la ressource sait répondre. C'est ce qui alimentera l'indexation sémantique côté registre.

2. La découverte dynamique : un registre interrogeable en langage naturel

Au-dessus des manifestes, des registres crawlent et indexent ces catalogues, puis exposent une API REST de recherche. La méthode obligatoire est POST /search : on envoie une requête en langage naturel, on reçoit des ressources classées par pertinence.

{
  "query": { "text": "un agent pour réserver un vol" },
  "federation": "referrals",
  "pageSize": 5
}

La réponse renvoie une liste de résultats, chacun assorti d'un score de pertinence (0 à 100) et de la source du registre. Point important, et lucide de la part des auteurs : ce score est purement informatif. La spécification interdit explicitement de l'interpréter comme une note de confiance, de conformité ou de sécurité. La fédération (auto, referrals, none) permet à un registre d'entreprise de renvoyer vers des registres publics, sans index central unique.

La confiance, intégrée au modèle

Chaque entrée peut porter un trustManifest : une identité vérifiable (SPIFFE, DID), des attestations (SOC 2, HIPAA, RGPD…) et une trace de provenance. On peut donc filtrer une ressource sur son niveau de conformité avant même de s'y connecter, une brique précieuse pour un usage en entreprise régulée.

ARD ne remplace ni MCP ni A2A : il les complète

C'est le point à retenir. Chaque protocole occupe une place distincte dans la pile agentique.

Protocole Rôle Question répondue
ARD Découverte (avant l'appel) Quelle ressource ? où ? est-elle sûre ?
MCP Invocation agent ↔ outils Comment appeler des outils et des données ?
A2A Invocation agent ↔ agent Comment déléguer une tâche à un autre agent ?
OpenAPI Invocation REST Comment appeler une API ?

Le flux complet est limpide : un orchestrateur interroge un registre (« trouve-moi un agent capable de déposer une note de frais »), reçoit des candidats classés et attestés, en choisit un, puis l'invoque via son protocole natif : MCP, A2A ou REST. ARD a fait son travail avant que le premier octet d'invocation ne soit échangé.

Les enjeux concrets pour l'entreprise

À mesure qu'une organisation multiplie serveurs MCP internes, agents et API, le problème n'est plus comment invoquer, mais comment retrouver et choisir la bonne ressource. ARD ouvre trois usages directs :

  • Un annuaire interne : publier un ai-catalog.json sur le domaine de l'entreprise, listant ses serveurs MCP, agents et API. Un orchestrateur les découvre dynamiquement, sans configuration figée.
  • La fédération inter-organisations : un agent peut interroger le registre d'un partenaire (federation: referrals) sans index partagé, pour une découverte gouvernée entre entités.
  • La gouvernance par la confiance : n'exposer aux agents que des ressources attestées, en s'appuyant sur le trustManifest.

Un standard jeune, à suivre de près

Soyons honnêtes sur la maturité : ARD en est à sa version v0.9 (draft), datée du 28 mai 2026. La spécification est ouverte et évolutive, et conserve quelques incohérences mineures entre son texte, ses schémas et ses exemples, le lot habituel d'un standard de quelques semaines. Ce n'est pas un protocole à mettre en production aveuglément aujourd'hui.

Mais le signal est fort. C'est la première tentative multi-éditeurs crédible (Google, Microsoft, Hugging Face et huit autres acteurs majeurs) d'adresser une couche jusqu'ici laissée à chaque framework. Et elle arrive précisément au moment où les écosystèmes MCP et A2A atteignent une masse critique qui rend la découverte indispensable.

Le regard de Pulse by Astek

Notre recommandation : surveiller et prototyper, pas encore industrialiser. ARD mérite une place en veille active et en R&D, pour deux raisons. D'une part, la spécification est encore mouvante. D'autre part, et c'est l'essentiel, un ai-catalog.json peut dès aujourd'hui référencer un serveur MCP existant sans rien changer à la façon dont on l'invoque. Le coût d'expérimentation est faible, le potentiel de différenciation est réel.

Un angle nous intéresse particulièrement chez Pulse by Astek : ARD pourrait devenir une brique fondatrice du contexte d'engineering de l'entreprise. Publier un catalogue interne de nos serveurs MCP, agents et API, c'est donner à chaque nouveau produit — et aux agents de développement qui l'assistent — le moyen de découvrir automatiquement le contexte pertinent : quelles ressources internes existent, ce qu'elles savent faire, si elles sont de confiance. Plutôt que de recâbler ce contexte à la main projet après projet, on le rend interrogeable. Le catalogue de ressources agentiques et le contexte d'engineering se confondent alors, et la découverte devient un levier de productivité pour l'ingénierie.

Pour les organisations qui déploient des architectures agentiques à l'échelle, ARD pourrait devenir ce que le DNS et les annuaires ont été pour le web : une infrastructure invisible mais structurante. Le genre de brique qu'il vaut mieux comprendre tôt.

Pour aller plus loin