Gérez Quicknode depuis votre terminal, votre code ou un agent IA.Désormais avec la CLI, l'API d'administration, MCP et le SDK.
Commencer à développerQu'est-ce que l'ERC-8257 ? Tout savoir sur le registre des outils d'agent
Qu'est-ce que l'ERC-8257 ? Un guide sur le registre des outils d'agents Ethereum, la découverte d'outils, les prédicats, les places de marché d'agents et l'infrastructure d'IA.

22 juin 2026 — 8 min de lecture

Les agents IA peuvent 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 aux agents augmente, cette approche devient difficile à adapter à l'échelle.
La norme ERC-8257 promet un moyen sans autorisation de découvrir et de vérifier des outils et des services « agentic ».
Cet article explique ce qu'est l'ERC-8257, comment fonctionne un registre d'outils d'agents, comment il s'intègre dans l'infrastructure globale des agents, et quelles possibilités ce registre permet de débloquer.
ERC-8257 (Agent Tool Registry) est un projet de norme Ethereum qui définit un registre sur la chaîne, accessible à tous, destiné aux agents et outils d'IA. Il normalise un enregistrement minimal et vérifiable indiquant 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 IA de découvrir, d'acheter un accès et d'utiliser des outils de manière autonome.
Chaque outil enregistré ou agent compatible ERC-8257 disposera d'un enregistrement sur la blockchain comprenant 3 éléments :
Adresse du créateur : l'éditeur, indiquée de manière définitive lors de l'enregistrement
URI des métadonnées : un pointeur vers le manifeste hors chaîne de l'outil
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 des outils d'agent, voyons comment ils fonctionnent ensemble et comment se déroule le processus.
Le saviez-vous ? La norme ERC-8257 est désormais opérationnelle sur le réseau principal d'Ethereum et sur Base, avec 76 outils référencés à la mi-2026.
La norme ERC-8257 prévoit deux processus, à savoir :
Flux du registre : interaction entre l'éditeur et le registre.
Processus de découverte et de vérification : interaction entre les agents, le registre et les outils.
Examinons-les un par un.
Le processus d'enregistrement définit 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 les agents pourront par la suite récupérer et vérifier.
Lorsqu'un agent identifie un outil ou un service, ce processus de découverte et de vérification permet d'établir la fiabilité des métadonnées qu'il analyse.
Le rôle du registre prend fin dès que l'agent 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 générique, mais c'est grâce à la section facultative consacrée aux prédicats qu'il devient bien plus qu'un simple registre.
Le registre des outils des agents permet de résoudre les problèmes de détection et de vérification. Cependant, tous les outils ne doivent pas nécessairement être accessibles par tous les agents 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.
Un prédicat d'accès est une adresse de contrat associée à l'enregistrement d'un outil.
Lorsqu'un agent tente d'utiliser un outil, il peut invoquer 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 un agent possède un NFT, détient un jeton d'abonnement, a payé pour obtenir l'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 :
Type d'outil | Logique des prédicats |
|---|---|
API publique | Renvoie toujours « true » |
Outil de recherche haut de gamme | Vérifier si l'abonnement est actif |
Services aux entreprises | Vérifier l'appartenance à la liste blanche |
Outil accessible uniquement via NFT | Vérifier la propriété d'un NFT |
Place de marché des agents | Vérifier les conditions de paiement ou de solvabilité |
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 à une multitude de cas d'utilisation.
Nous savons désormais ce qu'est le registre des 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 ?
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 aux agents. Découvrons ensemble les nombreuses fonctionnalités que cela permet de débloquer :
Chaque outil dispose d'une provenance vérifiable, d'un accès programmable et d'indications de prix enregistrées 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.
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.
Grâce à la norme ERC-8257, il est désormais possible de mettre en place des pipelines d'agents en plusieurs étapes, dans lesquels chaque outil est vérifié et soumis à des conditions de validation de manière indépendante.
Par exemple, un agent de trading peut être associé à un outil d'extraction d'actualités fonctionnant 24 heures sur 24, 7 jours sur 7, ou un agent de marché prédictif peut être relié à un agent Twitter (X).
La norme ERC-8257 offre un moyen standard de détecter et de vérifier ces dépendances, ce qui facilite la composition de flux de travail multi-agents entre des fournisseurs indépendants.
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. Les frameworks d'agents, les portefeuilles, les places de marché et les applications exploitent les mêmes enregistrements.
Aujourd'hui, la plupart des flux de travail des agents 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, un chercheur pourrait acheter un accès à des flux de données exclusifs mis à disposition via des outils enregistrés.
Le fonctionnement et les capacités de l'ERC-8257 sont désormais bien compris. Il s'agit désormais de cerner l'ensemble des composants nécessaires pour permettre aux agents de fonctionner efficacement.
La norme ERC-8257 résout un problème spécifique au sein de la pile d'agents au sens large : la découverte des capacités et l'interaction vérifiable.
Cependant, les agents 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.
Couche | Question | Protocole |
|---|---|---|
Identité d'Agent | Qui est l'agent ? | Identités ou portefeuilles ERC-8004 |
Découverte | Quelles sont les fonctionnalités disponibles ? | ERC-8257 |
Contrôle d'Accès | Qui peut les utiliser ? | Prédicats ERC-8257 |
Sous cet angle, 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'identification de l'agent peut être utilisée pour prouver l'identité de l'auteur de la demande.
Aucune de ces responsabilités n'incombe à l'ERC-8257 lui-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.
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 n'être qu'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 doivent-ils évaluer la réputation ? Comment les places de marché doivent-elles classer les outils ? Quelles normes doivent régir les paiements, les abonnements ou le partage des revenus entre systèmes autonomes ? Comment les organisations doivent-elles mettre en avant leurs capacités internes sans compromettre la sécurité ?
La norme ERC-8257 n'apporte pas de réponses à ces questions. Elle ouvre la voie au dialogue et à la recherche de solutions.
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. Les agents récupèrent le manifeste, le vérifient par rapport à l'enregistrement sur la blockchain, évaluent les éventuelles conditions d'accès, puis lancent l'outil.
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 les agents ont besoin pour comprendre le service et interagir avec lui.
Non. Tout service accessible par une machine peut être enregistré via la norme ERC-8257. Bien que cette norme ait été conçue à l'origine pour les agents d'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.
Le MCP normalise la manière dont les outils sont exposés et invoqué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.
Les développeurs peuvent créer des places de marché d'agents, des systèmes d'accès programmables, des flux de travail inter-organisations impliquant des agents, des couches de découverte de services et des écosystèmes multi-agents en s'appuyant sur une norme de registre partagé.
Oui. Le contrat ToolRegistry est déployé à l'adresse 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 sur le réseau principal d'Ethereum et sur 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.
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 aux agents de vérifier leur intégrité.
Fondée en 2017, Quicknode déploie une infrastructure blockchain de niveau institutionnel destinée aux développeurs et aux entreprises. Grâce à une disponibilité de 99,99 % et à la prise en charge de plus de 80 chaînes, les équipes peuvent développer et faire évoluer des applications sur la chaîne sans faire de compromis.
Les dernières actualités en matière d'ingénierie, les mises à jour sur les produits et les nouvelles du Web3, directement dans votre boîte mail.
Certifié SOC 2 Type II · ISO 27001
Paiements
Comment l'accès est-il financé ? |
x402, stablecoins |
Exécution | Comment les outils sont-ils lancés ? | MCP, API, frameworks d'agents |
Coordination | Comment les agents collaborent-ils entre eux ? | Systèmes multi-agents |