Qu'est-ce que l'ERC-8257 ? Explications sur le registre des outils « Agent »

Quicknode

22 juin 2026 — 8 min de lecture

Partager

Ajouter comme source préférée

L'agents e d'IA peut générer du code, exécuter des flux de travail et interagir avec des services externes.

Trouver de nouveaux outils reste bien plus difficile.

La plupart des « agents » s'appuient sur des intégrations configurées au préalable, que ce soit via des invites, des frameworks, des API ou des places de marché. À mesure que le nombre de services accessibles via l'agent augmente, cette approche devient difficile à faire évoluer.

La norme ERC-8257 promet un moyen sans autorisation de découvrir et de vérifier des outils et des services « agentiques ».

Cet article explique ce qu'est l'ERC-8257, comment fonctionne un registre d'outils « agent », comment il s'intègre dans l'infrastructure globale « agentic », et quelles possibilités ce registre permet de débloquer.

Qu'est-ce que l'ERC-8257 ?

ERC-8257 (Agent Tool Registry) est un projet de norme de l'Ethereum qui définit un registre sur la chaîne de blocs, accessible à tous, dédié aux agents s et outils d'IA. Il normalise un enregistrement minimal et vérifiable contenant des informations sur la nature d'un outil, son éditeur et les personnes autorisées à l'utiliser.

En avril 2026, Cody Sears et Ryan Ghods, d'OpenSea, ont proposé cette norme afin de permettre aux « agents s IA » de découvrir, d'acheter un accès à des outils et de les invoquer de manière autonome.

Fonctionnement de la norme ERC-8257

Chaque outil enregistré ou chaque « agent » compatible avec la norme ERC-8257 disposera d'un enregistrement sur la blockchain comprenant 3 éléments :

1. Adresse du créateur : l'éditeur, indiquée de manière définitive lors de l'enregistrement

2. URI des métadonnées : un pointeur vers le manifeste hors chaîne de l'outil

3. Hachage du manifeste : vérifie que la description n'a pas changé

Et un quatrième élément facultatif dans le prédicat d'accès : il s'agit d'une adresse de contrat qui détermine qui peut appeler l'outil.

Ensemble, ces éléments constituent une source de référence commune pour les métadonnées des outils, avec une garantie : le manifeste que vous avez récupéré est bien celui que le créateur a validé, depuis la source qu’il contrôle, sous l’adresse avec laquelle il l’a signé.

Maintenant que nous avons compris l'objectif et les composants du registre d'outils d'agent , voyons comment ils fonctionnent ensemble et à quoi ressemble l'flow .

La norme ERC-8257 prévoit deux processus, à savoir :

1. Flow s relatives au registre : interaction entre l'éditeur et le registre.

2. Flow s de découverte et de vérification : interaction entre l'agents, le registre et les outils.

Examinons-les un par un.

ERC-8257 : Fonctionnement de l'Flow du registre

Le registre flow régit la manière dont un outil est publié et rendu accessible. Un éditeur enregistre l'adresse du créateur de l'outil, l'URI des métadonnées et le hachage du manifeste (ainsi qu'un prédicat d'accès facultatif), créant ainsi l'enregistrement sur la chaîne de blocs que agents pourra ensuite résoudre et vérifier.

ERC-8257 : Comment fonctionnent la découverte et la vérification

Lorsqu'une « agent » identifie un outil ou un service, ce processus de découverte et de vérification permet d'établir la confiance dans les métadonnées que l'agent lit.

Le rôle du registre prend fin dès lors que l'agent e a vérifié que le manifeste, l'éditeur et les conditions d'accès correspondent à l'enregistrement enregistré.

Jusqu'à présent, l'ERC-8257 ressemble à un registre classique, mais c'est grâce à la section facultative consacrée aux prédicats qu'il devient bien plus qu'un simple registre.

Contrôle d'accès ERC-8257 : explication du modèle de prédicat

Le registre d'outils « agent » permet de résoudre les problèmes de découverte et de vérification. Cependant, tous les outils ne doivent pas nécessairement être accessibles depuis n'importe quelle instance d'agent , ni être entièrement publics.

Certains services peuvent nécessiter un abonnement. D'autres peuvent être réservés aux détenteurs de NFT, aux clients professionnels ou aux « agents » répondant à des critères de réputation spécifiques.

ERC-8257 résout la question de l'accès grâce à un composant facultatif appelé « prédicat d'accès » : un contrat externe qui détermine si un appelant est autorisé à utiliser un outil.

Qu'est-ce que le contrôle d'accès basé sur des prédicats ?

Un prédicat d'accès est une adresse de contrat associée à l'enregistrement d'un outil.

Lorsqu'une entité « agent » tente d'utiliser un outil, elle peut appeler le contrat de prédicat et poser une question simple : cet appelant est-il autorisé à accéder à cet outil ?

Désormais, le contrat prédicatif peut vérifier si une « agent » possède un NFT, détient un jeton d’abonnement, a payé pour obtenir un accès, figure sur une liste blanche ou répond à un critère de réputation.

Différents outils permettent de mettre en œuvre différentes politiques sans qu'il soit nécessaire de modifier le registre lui-même. En voici quelques exemples :

Surtout, la norme ERC-8257 n'impose aucune de ces règles de manière rigide ; elle permet au contrat de prédicat d'être un module complémentaire facultatif, ce qui garantit la légèreté de la norme tout en la rendant extensible pour une multitude de cas d'utilisation.

Nous savons désormais ce qu'est le registre d'outils d'agent , comment il est enregistré, comment les agents le détectent et comment l'accès y est contrôlé. À présent, que pouvez-vous créer grâce à cela ?

Ce que permet l'ERC-8257

Un registre en soi n'a rien de particulièrement intéressant.

Le DNS a pris de l'importance car il permettait de trouver des sites web. Les registres de paquets ont pris de l'importance car les logiciels pouvaient s'appuyer sur eux. Les boutiques d'applications ont pris de l'importance car elles mettaient les utilisateurs en relation avec les applications.

La norme ERC-8257 met en place une couche de découverte pour les outils accessibles via agent. Découvrons ensemble quelques-unes des fonctionnalités rendues possibles grâce à cela :

1. Les places de marché agentiques

Chaque outil dispose d'une provenance vérifiable, d'un accès programmable et d'indications de prix sur la blockchain. Cela suffit pour créer une place de marché où les outils peuvent être découverts, consultés et échangés sans l'intervention d'un opérateur de plateforme.

2. Marchés d'accès programmables

Un fournisseur d'outils peut définir les tarifs, les abonnements, les conditions de détention de jetons, les seuils de réputation ou les autorisations d'entreprise via le contrat de prédicat. Cette flexibilité permet à différents modèles d'accès de se faire concurrence tout en restant interopérables au niveau de la couche de découverte.

3. Flux de travail modulaires d'Agent

Grâce à la norme ERC-8257, il est désormais possible de mettre en place des pipelines d'agent s en plusieurs étapes, dans lesquels chaque outil est vérifié et soumis à des conditions de validation de manière indépendante.

Par exemple, une agent dédiée au trading peut être associée à un outil de collecte d'actualités fonctionnant 24 h/24 et 7 j/7, ou un agent de marché prédictif peut être relié à un compte Twitter (X) agent.

La norme ERC-8257 offre un moyen standard de recenser et de vérifier ces dépendances, ce qui facilite la mise en place de workflows multiagent s entre différents fournisseurs indépendants.

4. Écosystèmes « Agent » ouverts

Toute plateforme est tôt ou tard confrontée au même défi : gérer son propre répertoire de services.

La norme ERC-8257 transfère cette responsabilité vers une infrastructure partagée. Les fournisseurs d'outils effectuent une seule publication. Agent Les frameworks, portefeuilles, places de marché et applications utilisent les mêmes enregistrements.

5. Flux de travail inter Agent s au sein de l'organisation

Aujourd'hui, la plupart des flux de travail « agent » s'inscrivent dans le cadre d'une seule organisation ou d'une seule plateforme.

La norme ERC-8257 ouvre la voie à des flux de travail inter-organisations, tels que fournisseur-client, client-place de marché, etc.

Par exemple, une agent de recherche pourrait acheter un accès à des flux de données propriétaires mis à disposition via des outils enregistrés.

Le fonctionnement et les capacités de la norme ERC-8257 sont désormais bien compris. Il s'agit désormais de comprendre l'ensemble de l'agent , plus large, nécessaire au bon fonctionnement de agents .

Place occupée par la norme ERC-8257 dans la pile d'infrastructure d'Agentic

La norme ERC-8257 résout un problème spécifique au sein de la pile plus large de l'agent : la découverte des capacités et l'interaction vérifiable.

Cependant, les « agents s » ont toujours besoin d’une identité, d’environnements d’exécution, de canaux de paiement et d’une coordination pour interagir.

Assemblons maintenant la pile.

Avec cette lens, l'ERC-8257 ressemble moins à une norme d'IA qu'à une infrastructure.

• Un outil enregistré peut exposer un serveur MCP.

• Une condition peut exiger un paiement avant que l'accès ne soit accordé.

• Une norme d'agent peut être utilisée pour vérifier l'identité de la personne à l'origine de la demande.

Aucune de ces responsabilités n'incombe à l'ERC-8257 elle-même.

Le rôle de cette norme est de répondre à une question plus simple : « Quelles sont les fonctionnalités disponibles et où peut-on les trouver ? »

À présent, l'architecture est solide, tout comme le choix de conception. Les questions qui restent en suspens concernent l'adoption.

Quelle est la prochaine étape pour l'ERC-8257 ?

De nos jours, la plupart des logiciels s'appuient sur des intégrations directes.

Un développeur choisit un service, consulte sa documentation, écrit du code en s'appuyant sur son API et entretient cette relation au fil du temps.

La norme ERC-8257 ne va pas dans ce sens, mais oriente l'infrastructure agentique dans une autre direction.

• Les capacités deviennent détectables lors de l'exécution.

• Les politiques d'accès deviennent programmables.

• Les services peuvent être utilisés sans autorisation humaine.

ERC-8257 est une couche de découverte courante. Cela peut sembler être un élément mineur de l'infrastructure.

Le DNS n'était qu'un petit élément de l'infrastructure. Les registres de paquets n'étaient qu'un petit élément de l'infrastructure. Les boutiques d'applications ont d'abord pris la forme de répertoires.

Le plus gros défi reste à venir.

Comment les « agents » devraient-ils évaluer la réputation ? Comment les places de marché devraient-elles classer les outils ? Quelles normes devraient régir les paiements, les abonnements ou le partage des revenus entre systèmes autonomes ? Comment les organisations devraient-elles mettre en avant leurs capacités internes sans compromettre la sécurité ?

La norme ERC-8257 n'apporte pas de réponses. Elle ouvre le dialogue et trace la voie vers une solution.

FAQ (Foire aux questions)

1. Comment fonctionne la norme ERC-8257 ?

Un fournisseur enregistre un outil en publiant une adresse de créateur, une URI de métadonnées, un hachage du manifeste et, éventuellement, un prédicat d'accès. Agents récupère le manifeste, le vérifie par rapport à l'enregistrement sur la blockchain, évalue les éventuelles conditions d'accès, puis lance l'outil.

2. Qu'est-ce qu'un manifeste ERC-8257 ?

Un manifeste est une description d'un outil lisible par machine. Il contient des métadonnées telles que les capacités, les points de terminaison, les conditions d'utilisation et d'autres informations dont agents a besoin pour comprendre le service et interagir avec lui.

3. La norme ERC-8257 s'applique-t-elle uniquement aux « agents s » basées sur l'IA ?

Non. Tout service accessible par une machine peut être enregistré via la norme ERC-8257. Bien que cette norme ait été conçue dans la perspective de l'agents de l'IA, les API, les services logiciels, les systèmes d'automatisation et d'autres applications programmables peuvent utiliser ce même modèle de découverte.

4. En quoi la norme ERC-8257 diffère-t-elle de la norme MCP ?

Le MCP normalise la manière dont les outils sont exposés et appelés. La norme ERC-8257 normalise la manière dont les outils sont détectés et vérifiés. Ces deux normes sont complémentaires et peuvent être utilisées conjointement au sein d'une même architecture d'agent .

5. Que peuvent créer les développeurs grâce à la norme ERC-8257 ?

Les développeurs peuvent créer des places de marché « agent », des systèmes d’accès programmables, des flux de travail inter- agent s, des couches de découverte de services et des écosystèmes multi-agent s en s’appuyant sur une norme de registre partagé.

6. La norme ERC-8257 est-elle disponible sur mainnet?

Oui. Le contrat ToolRegistry est déployé à l'adresse 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 sur Ethereum ,mainnet et Base. À la mi-2026, 76 outils étaient répertoriés. L'EIP reste au stade de projet, ce qui signifie que l'interface peut encore évoluer avant sa finalisation.

7. La norme ERC-8257 stocke-t-elle les métadonnées des outils sur la blockchain ?

Non. Le registre stocke des références aux métadonnées plutôt que les métadonnées elles-mêmes. Les descriptions des outils restent hors chaîne, tandis que les hachages stockés sur la chaîne permettent à agents de vérifier leur intégrité.