Agentic Resource Discovery : ai-catalog.json, registres et confiance pour agents mobiles

Ce que résout Agentic Resource Discovery

Agentic Resource Discovery, ou ARD, répond à une question très concrète : comment un agent IA peut-il trouver une capacité fiable sans dépendre d’une liste privée, d’une intégration codée à la main ou d’une recherche web fragile ? La présentation Google Developers d’Agentic Resource Discovery, publiée le 17 juin 2026, décrit ARD comme une spécification ouverte pour publier, découvrir et vérifier des outils, des compétences et des agents sur le web.

Le fichier le plus souvent cité dans ce modèle est ai-catalog.json. Il sert de catalogue lisible par machine : une organisation peut y déclarer les ressources qu’elle expose, les interfaces disponibles, les métadonnées de l’éditeur, les liens vers d’autres catalogues et les informations nécessaires pour qu’un agent sache quoi examiner ensuite. L’enjeu n’est pas de donner le pouvoir d’agir immédiatement. L’enjeu est d’éviter qu’un agent devine où se trouve une capacité ou confonde une page marketing avec un vrai point d’intégration.

Pour les équipes qui construisent des agents, ARD apporte donc une couche de découverte. Le fournisseur publie. Le registre indexe ou le client récupère directement le catalogue. L’agent résout une ressource correspondant à une intention. Ensuite seulement vient la connexion au protocole natif. Cette séparation rend la découverte de ressources pour agents IA plus propre : elle clarifie ce qui a été trouvé, qui l’a publié et par quel canal la capacité doit être appelée.

Catalogues et registres : comment les capacités deviennent trouvables

Un catalogue et un registre ne jouent pas le même rôle. Le catalogue vit du côté de l’éditeur, souvent sous son propre domaine. Il indique les capacités disponibles, leurs descriptions, leurs interfaces et parfois des catalogues imbriqués. Le registre, lui, permet de rechercher parmi plusieurs catalogues : un client peut demander une capacité par intention, obtenir des résultats correspondants et examiner les métadonnées de vérification avant d’aller plus loin.

La spécification publique, disponible dans le dépôt ARD et ses schémas, présente ce travail comme une infrastructure de publication et de résolution. Les entrées peuvent annoncer des serveurs MCP, des agents A2A, des outils OpenAPI ou d’autres catalogues. Cette diversité compte, car le web agentique ne sera pas constitué d’un seul protocole. Une entreprise peut exposer une API métier, un autre éditeur peut publier un serveur MCP, et un fournisseur d’agent peut indiquer un point A2A.

Ce tableau montre pourquoi le catalogue d’outils ai-catalog.json est utile sans devenir un bouton d’exécution. Il donne à l’agent une carte plus structurée. Il ne décide pas encore si l’utilisateur a le droit de déclencher une action, si l’application mobile expose le bon contrat, ni si une étape sensible doit être approuvée.

Ce que prouve la vérification d’un éditeur

La vérification répond à une inquiétude légitime : un agent ne devrait pas se connecter à une ressource uniquement parce qu’elle a un nom crédible. ARD prévoit que la découverte en production puisse inclure des métadonnées d’éditeur vérifiables avant une connexion directe au protocole natif. Cela peut aider un client à confirmer que la ressource provient bien de l’organisation annoncée et que le catalogue n’est pas une simple copie anonyme.

Cette confiance d’origine a une vraie valeur. Elle limite les mauvaises directions, réduit le risque de se connecter au mauvais domaine et rend l’écosystème plus inspectable. Pour un catalogue fiable d’outils d’agents, l’identité de l’éditeur, l’intégrité du catalogue, la fraîcheur des métadonnées et la correspondance de l’endpoint sont des signaux décisifs avant même de parler d’action.

Mais une identité correcte ne transforme pas chaque capacité en action sûre. Un éditeur légitime peut exposer un outil puissant, mal adapté à une tâche donnée, trop large pour une session mobile, ou incompatible avec les règles locales de l’utilisateur. La vérification dit “voici qui publie cette ressource”. Elle ne dit pas “cette action doit être exécutée maintenant sur ce téléphone”. Pour un agent mobile, il faut ensuite examiner le périmètre, la cible, les permissions, l’état de l’application, le niveau de risque et la possibilité de revenir en arrière.

La bonne lecture est donc positive et opérationnelle : vérifier avant de connecter, puis contrôler avant d’agir. ARD améliore le premier mouvement. L’autorisation et l’exécution gouvernée relèvent d’une autre couche.

Le passage vers MCP, A2A, OpenAPI et les contrats d’applications

Une fois la ressource trouvée, ARD ne remplace pas son protocole natif. Il indique où et comment poursuivre. Si le catalogue annonce un serveur MCP, le client doit parler MCP. S’il annonce un agent A2A, la conversation suit A2A. S’il annonce un outil OpenAPI, le contrat, les schémas et les règles d’authentification de cette API restent centraux. ARD joue le rôle d’annuaire vérifiable, pas celui de protocole unique pour tout exécuter.

Cette distinction devient très importante côté mobile. Découvrir qu’une application, un service ou un fournisseur expose une capacité ne signifie pas que l’application Android installée sur le téléphone possède une action appelable, ni que cette action peut être déclenchée dans l’état actuel de l’écran. Les contrats mobiles ont leurs propres réalités : intentions Android, partage, liens profonds, permissions, comptes connectés, limites de version et contexte visible.

Pour approfondir ce passage entre capacité déclarée et action réellement appelable, notre guide App Intents et applications appelables par machine : ce que les agents IA peuvent vraiment faire détaille le niveau suivant : une application doit exposer un contrat utilisable avant qu’un agent puisse l’invoquer proprement. ARD peut aider à trouver et qualifier une ressource ; le contrat d’application détermine ensuite comment elle peut être appelée.

En pratique, un agent sérieux garde ces niveaux séparés dans ses journaux et dans son interface. Il peut afficher “ressource trouvée”, “éditeur vérifié”, “protocole compatible”, puis “action disponible sur cet appareil”. Ce sont quatre états différents, et les confondre rend les erreurs plus difficiles à diagnostiquer.

Pourquoi la découverte n’autorise pas une action sur téléphone

Sur un téléphone, l’autorisation commence là où la découverte s’arrête. Un catalogue peut dire qu’un outil existe. Un registre peut le classer comme pertinent. Une signature peut confirmer l’éditeur. Android, l’application cible et l’utilisateur doivent encore décider si l’action peut se produire dans ce contexte précis.

La documentation Android sur les permissions demandées au moment utile rappelle que l’application doit demander les autorisations dans le contexte de la fonctionnalité qui en a besoin et gérer les refus. Cela ne vérifie pas un éditeur distant ; cela encadre l’accès local à des capacités du téléphone. Autrement dit, la permission Android et la vérification ARD répondent à deux questions différentes.

Les équipes qui travaillent sur les compétences mobiles doivent donc relier découverte et sécurité d’exécution sans les fusionner. Pour les contrôles au moment de l’action, Sécurité des compétences d’agents IA : pourquoi les permissions sur mobile doivent être vérifiées au moment de l’action approfondit la gestion des compétences et des permissions. Et lorsque la question touche à l’identité de l’agent, aux droits et aux traces d’activité, Identité, permissions et audit des agents IA : la sécurité nécessaire sur téléphone apporte le cadre complet.

Checklist avant connexion et avant exécution

Une ressource découverte devient utile quand elle passe une série de contrôles observables. La checklist suivante sépare ce qu’un agent peut vérifier avant de se connecter et ce qu’un runtime mobile doit vérifier avant d’exécuter une action.

1. Confirmer l’origine. Le domaine, les métadonnées de l’éditeur et le catalogue doivent correspondre à la ressource recherchée.
2. Vérifier la fraîcheur. Un catalogue ancien peut pointer vers des endpoints déplacés, des capacités retirées ou des règles de sécurité dépassées.
3. Valider le protocole. MCP, A2A, OpenAPI ou contrat d’application doivent être traités selon leurs propres règles, avec erreurs lisibles.
4. Limiter le périmètre. L’agent doit connaître les actions nécessaires, les champs sensibles, les effets externes et les chemins de repli.
5. Tester avec une tâche à faible risque. Une lecture ou une simulation contrôlée donne plus d’informations qu’un premier essai avec un effet irréversible.
6. Contrôler l’activation locale. Une capacité trouvée dans un registre doit être activée dans le runtime avant d’être utilisée.
7. Valider la cible. Le compte, l’application, le destinataire, le fichier, le lieu ou le service visé doivent être visibles et corrects.
8. Appliquer l’approbation adaptée au risque. Certaines actions peuvent être fluides, d’autres demandent une confirmation claire avant effet.
9. Afficher le résultat. L’utilisateur doit voir ce qui a été fait, ce qui a échoué et ce qui reste à décider.
10. Prévoir arrêt et révocation. Désactivation d’outil, retrait d’accès, mise à jour du catalogue et journal consultable doivent faire partie du cycle.

Cette séquence évite deux erreurs fréquentes : faire confiance à une ressource parce qu’elle est bien cataloguée, ou bloquer toute innovation parce qu’une découverte peut échouer. La découverte ouvre une porte documentée. Le runtime décide ensuite comment passer cette porte, avec quels droits et sous quel contrôle.

Comment FoneClaw sépare visibilité du catalogue et autorité sur le téléphone

Chez FoneClaw, nous abordons ce sujet par la pratique du téléphone Android. Un modèle configuré comprend la demande, raisonne et prépare un plan. FoneClaw invoque ensuite des outils Android gouvernés et pris en charge, avec des permissions guidées au moment utile, des résultats visibles et des contrôles adaptés au risque de l’action.

Notre catalogue public d’outils intégrés donne une visibilité structurée sur ce que le runtime sait exposer. La copie datée du 1er août 2026 contient 118 outils dans 11 catégories, avec des libellés de risque et d’approbation ; dans le texte durable, nous parlons plus naturellement de 100+ outils intégrés. Le catalogue public des outils FoneClaw sert à rendre ce périmètre inspectable, pas à installer silencieusement des ressources tierces.

La version actuelle ajoute aussi des contrôles utiles pour ce modèle de confiance. Les notes de version publiques FoneClaw indiquent que FoneClaw 0.1.0 a renforcé la gestion par outil, les contrats plus sûrs, la récupération de permissions et la continuation de plugins fiables. Cela illustre une règle produit simple : voir une capacité dans un catalogue ne lui donne pas automatiquement l’autorité d’agir. L’outil doit être pris en charge, activé, compatible avec la demande et exécuté dans un cadre gouverné.

Pour les lecteurs qui veulent le modèle complet intention-action côté Android, notre page Contrôle du téléphone par agent IA : ce qu’un agent Android doit vraiment faire explique comment FoneClaw transforme une intention en action visible, avec permissions, approbations et résultats vérifiables. Ici, le point clé est plus étroit : la visibilité d’un catalogue aide à choisir et comprendre les outils ; l’autorité sur le téléphone se gagne étape par étape.

Ce qu’une équipe doit tester avant d’adopter un registre de ressources

Avant d’intégrer un registre de ressources agentiques dans un produit mobile, une équipe doit mesurer autre chose que le nombre de capacités trouvées. La qualité de découverte se juge par les faux résultats, les catalogues obsolètes, les échecs de vérification, les incompatibilités de protocole, les refus de politique et la clarté du repli.

La décision d’adoption devient alors progressive. Commencez par des ressources lues ou simulées, ajoutez la vérification éditeur, validez le protocole, puis testez une action mobile à faible risque avec journal et révocation. Quand la découverte et l’autorité restent observables séparément, les équipes peuvent intégrer de nouveaux catalogues sans transformer chaque trouvaille en pouvoir immédiat sur le téléphone.