De l'agent IA aux limites d'autorisation sur la blockchain : que change l'ERC-8004 ?

null

Auteur : CoinW Research Institute

Résumé

Avec le développement d’applications telles que DeFi, l’abstraction des comptes et les AI Agents, l’autorisation sur la chaîne évolue progressivement d’une simple signature unique à une autorisation d’exécution pouvant durer dans le temps et être réutilisée. Parallèlement, de nouvelles évolutions se produisent : les AI Agents ont commencé à posséder la capacité de demander automatiquement des services et d’effectuer des paiements de façon autonome. Par exemple, le protocole x402 utilise le code d’état HTTP 402 pour permettre à l’Agent de payer instantanément des ressources et des services en stablecoin sans intervention humaine. Cela transforme le comportement sur la chaîne d’une transaction isolée en un processus d’automatisation continue et collaboratif.

Dans ce contexte, la question de l’autorisation est encore plus cruciale. Les méthodes d’autorisation dans le système Web3 actuel restent floues, peu expressives, se limitant souvent à déterminer si l’on peut utiliser un actif, sans répondre précisément à ce que l’on est autorisé à faire ou à quel degré. ERC-8004 a été proposé précisément pour répondre à ce besoin. Il ne définit pas de nouveaux actifs ni ne modifie la façon dont les transactions ou paiements sont effectués, mais tente d’établir un modèle de permissions compréhensible et vérifiable par le système, faisant de l’autorisation un objet pouvant être décrit, contraint et géré.

D’un point de vue systémique plus large, ERC-8004 n’est pas en concurrence avec l’abstraction des comptes ou les protocoles de paiement automatisés comme x402, mais occupe des rôles complémentaires à différents niveaux : x402 traite de l’échange de valeur après l’action, tandis qu’ERC-8004 se concentre sur qui est autorisé à agir avant l’action, et si cette autorisation dépasse ses limites. Dans des scénarios tels que DeFi, AI Agents, entreprises ou RWA, cette structure où l’autorisation précède le paiement pourrait faire évoluer l’autorisation du niveau des actifs vers celui des comportements, fournissant une base contrôlable pour des automatisations plus complexes et à long terme. Bien que des défis subsistent en termes de coût d’apprentissage, de compatibilité portefeuille et d’expérience utilisateur, ERC-8004 n’est pas un simple outil de narration à court terme, mais une norme fondamentale pour permettre à Web3 de supporter des systèmes complexes.

1. Motivation de la proposition ERC-8004

Avec l’évolution continue de l’infrastructure sur la chaîne, la capacité à inscrire des actifs et à exécuter des transactions s’est constamment abstraite et renforcée. Depuis ERC-20, NFT, jusqu’aux portefeuilles multisignatures et à l’abstraction des comptes (ERC-4337), le seuil de participation des utilisateurs sur la chaîne diminue, et les comptes deviennent de plus en plus intelligents.

Mais un problème fondamental n’a pas été résolument abordé : le mécanisme d’autorisation lui-même n’a pas connu d’évolution substantielle. Dans les premières phases de Web3, l’autorisation signifiait une signature unique de la clé privée. L’utilisateur exprimait son accord par une signature, que ce soit pour un transfert, un appel de contrat ou une opération approve, et cette autorisation était considérée comme une confirmation ponctuelle, avec un risque entièrement assumé par l’utilisateur.

Aujourd’hui, l’environnement sur la chaîne a changé. Dans le cas de DeFi, l’approve est souvent valable sur le long terme ; dans les stratégies automatisées et les systèmes de Session Keys, l’autorisation est réutilisée à plusieurs reprises ; dans le mode d’exécution par AI Agent ou Bot, l’utilisateur ne participe même plus directement à chaque opération. L’autorisation évolue d’une confirmation ponctuelle vers une capacité d’exécution continue, semblable à déléguer un pouvoir pour effectuer une tâche pendant une certaine période.

Le problème est que l’infrastructure Web3 actuelle offre presque aucune contrainte claire et unifiée pour ce type d’état d’autorisation à long terme. La portée des permissions est floue, leur révocation difficile, et les risques imprévisibles, ce qui engendre de nombreux incidents de sécurité. Par ailleurs, l’abstraction des comptes amplifie cette contradiction : lorsqu’un compte peut exécuter automatiquement des transactions ou faire payer le Gas par un tiers, ce qu’il peut ou ne peut pas faire devient encore plus flou.

C’est dans ce contexte que ERC-8004 a été proposé. Il vise à combler une lacune fondamentale de Web3 : établir un modèle d’autorisation clair, contraignant et compréhensible par le système.

2. Contenu central d’ERC-8004

L’approche d’ERC-8004 ne concerne pas la forme des actifs ou la méthode d’exécution des transactions, mais la capacité à décrire, vérifier indépendamment et gérer en continu une permission.

2.1 Qu’est-ce que ERC-8004 définit ?

Selon la définition officielle du site des Ethereum Improvement Proposals (EIP) : ERC-8004 est un protocole standard permettant de découvrir, sélectionner et interagir avec des agents autonomes (autonomous agents) fiables sur Ethereum. Il construit une infrastructure décentralisée d’agents via l’enregistrement sur la chaîne, la réputation et des mécanismes de vérification, permettant des interactions sans confiance préalable.

Les “autonomous agents” ici ne se limitent pas aux AI Agents, mais désignent toute entité pouvant être autorisée et exécutant des comportements de façon indépendante, comme des contrats, scripts automatisés, multi-signatures ou processus de service. ERC-8004 se concentre sur la capacité de l’entité à disposer d’un cadre clair d’autorisation et de limites de permissions, AI Agent étant un exemple typique.

D’un point de vue plus général, ERC-8004 n’est pas une nouvelle norme d’actifs ou un nouveau type de compte, mais un cadre d’expression et de vérification des permissions sur la chaîne, décrivant dans quelles conditions un sujet est autorisé à effectuer quels comportements, avec vérification préalable. Il ne s’agit pas de “qu’est-ce que l’argent” ou “comment la transaction est exécutée”, mais de “quels comportements sont permis”. Il ne crée pas de nouveaux actifs ni ne modifie les propriétés des actifs existants, mais ajoute une couche claire et vérifiable de règles de permission au-dessus des actifs et comptes.

De plus, ERC-8004 n’est pas une alternative à l’abstraction des comptes (ERC-4337). L’abstraction des comptes concerne la façon dont les transactions sont exécutées, tandis qu’ERC-8004 traite de la vérification des permissions avant l’exécution. Si l’abstraction des comptes rend les comptes plus flexibles, ERC-8004 en définit les limites précises.

L’essence d’ERC-8004 est de transformer l’autorisation, qui était implicite dans la signature, en un objet de permission pouvant être décrit, vérifié et géré de façon continue.

2.2 Cadre du mécanisme central d’ERC-8004

Pour comprendre le mécanisme central d’ERC-8004, on peut d’abord l’abstraire comme une “fiche d’autorisation sur la chaîne”. Dans la logique d’autorisation traditionnelle, l’utilisateur se contente souvent d’un simple “je suis d’accord”. Laquelle, en pratique, ne distingue pas ce que l’on peut faire, combien, ou pendant combien de temps. Le système ne fait qu’enregistrer cette approbation globale.

Dans le cadre d’ERC-8004, une autorisation n’est plus une simple acceptation vague, mais décomposée en un ensemble de règles précises, décrites de façon claire et imposées par le système. Cette “fiche d’autorisation” contient généralement cinq types d’informations clés :

• Autorité (Who) : Qui est autorisé à agir ?

Il faut d’abord préciser qui reçoit l’autorisation. Dans ERC-8004, l’objet autorisé n’est pas limité à une adresse de portefeuille fixe, mais peut aussi être un contrat, un agent automatisé, voire une Session Key à usage temporaire. Cela permet d’adapter l’autorisation à des scénarios complexes, comme faire exécuter un contrat dans un périmètre défini, ou faire agir un Agent sans signatures répétées. L’essentiel est que l’autorisation soit toujours donnée à un “sujet précis”, et non pas simplement déléguée de façon vague.

• Actions autorisées (What) : Que peut-on faire ?

Ensuite, il s’agit de préciser quelles actions sont permises. La permission n’est pas une ouverture totale, mais peut être limitée à certains types d’opérations, comme uniquement effectuer un swap, un transfert, ou appeler certaines fonctions spécifiques. ERC-8004 répond à la question “jusqu’où puis-je utiliser cette permission ?”, plutôt que “est-ce que je peux l’utiliser ou pas”.

• Conditions (Under what conditions) : Dans quelles circonstances ?

C’est une différence clé par rapport à l’autorisation traditionnelle. La fiche d’autorisation peut inclure des restrictions précises, telles que des plafonds de montant pour une seule opération ou cumulées, des limites de fréquence ou de nombre d’exécutions, ou des restrictions à certains protocoles, pools ou adresses de contrats. Ces conditions doivent être remplies avant l’exécution, et non après. Si elles ne sont pas respectées, l’opération ne peut pas être effectuée.

• Validité et révocation (When) : Quand l’autorisation est-elle valable ou expirée ?

ERC-8004 introduit une gestion claire du cycle de vie. L’autorisation peut être limitée dans le temps (valide uniquement dans une période donnée), être valable une seule fois, ou être révoquée à tout moment. Cela évite que l’autorisation devienne une charge à long terme non récupérable, et permet une gestion fine des droits.

• Vérification (How enforced) : Comment la règle est-elle appliquée ?

Enfin, la façon dont ces règles sont réellement appliquées. L’idée centrale d’ERC-8004 est de faire une vérification préalable avant l’action. Si une opération ne respecte pas les règles définies, elle est rejetée immédiatement. Cela diffère fondamentalement des systèmes de contrôle traditionnels, qui vérifient après coup ou laissent faire, puis gèrent les risques a posteriori.

2.3 Quelles capacités nouvelles ERC-8004 apporte-t-il ? Pourquoi n’était-ce pas possible avant ?

Apparentement, ERC-8004 ne fait que rendre l’autorisation plus fine. Mais en réalité, le modèle d’autorisation d’Ethereum avant était incapable d’exprimer des logiques complexes. La vérification se limitait à “l’adresse est autorisée ou pas”, sans pouvoir préciser ce que cette autorisation permettait, ni ses limites.

ERC-8004 innove en passant d’une “identité” à une “comportementalisation”. Le système peut maintenant juger si une opération est conforme aux limites fixées par l’utilisateur, plutôt que de se limiter à vérifier qui l’a initiée. Cela permet d’intégrer des conditions de montant, de fréquence, de portée et de durée, sans dépendre d’une révocation manuelle ou d’un contrôle après coup.

Une fois la logique d’autorisation structurée, elle devient réutilisable et composable. Des opérations multi-étapes ou cross-protocol peuvent être explicitement limitées lors de la phase d’autorisation, plutôt que d’être laissées à la décision au moment de l’exécution. Cela ouvre la voie à des scénarios Agent plus sophistiqués. Les programmes automatisés ne sont plus “sans limite”, mais contraints à des comportements précis et vérifiables, et tout dépassement est rejeté.

Ce que ERC-8004 ajoute, ce n’est pas simplement une “autorisation plus sûre”, mais une capacité à faire comprendre et exécuter la logique d’autorisation par le système, ce qui constitue sa différence essentielle avec les mécanismes traditionnels.

3. Applications potentielles d’ERC-8004

ERC-8004 n’est pas une norme conçue pour un produit spécifique, mais plutôt un langage universel pour la capacité d’autorisation. Son intérêt ne réside pas dans un cas d’usage unique, mais dans la demande commune de capacités d’autorisation plus complexes dans plusieurs systèmes.

DeFi : de “l’autorisation d’actif” à “l’autorisation comportementale”

Dans le DeFi actuel, la méthode la plus courante reste “autorisation unique, limite illimitée”. Par exemple, pour faire un swap, un prêt ou un staking, l’utilisateur doit d’abord approuver le contrat, ce qui revient à transférer le contrôle total de l’actif. C’est efficace en termes d’expérience, mais risqué : si le contrat est mis à jour, attaqué ou utilisé dans une logique non prévue, l’autorisation devient un vecteur de risque. ERC-8004 ne concerne plus l’actif lui-même, mais le comportement spécifique. Par exemple, l’utilisateur peut dire : “Je n’autorise pas ce contrat à utiliser mon USDC à l’infini, mais seulement 24 heures, et pas plus de 1 000 USDC pour une seule opération”. Bien que certains projets aient déjà tenté de limiter la portée ou la durée des autorisations, ces approches restent fragmentées. ERC-8004 vise à standardiser cette autorisation comportementale, permettant une gestion réutilisable et composable, et renforçant la sécurité.

AI Agent : fournir des limites d’autorisation vérifiables pour l’automatisation

Avec l’émergence des AI Agents dans la prise de décision et l’exécution sur la chaîne, la question de l’autorisation devient encore plus critique. L’Agent doit fonctionner en continu et exécuter automatiquement, ce qui nécessite des droits d’opération à long terme. Sans limites claires, un Agent n’est qu’un programme automatisé avec un contrôle total, ce qui n’atténue pas le risque. ERC-8004 offre une structure vérifiable d’autorisation, permettant de définir précisément ce que l’Agent peut faire, dans quelles limites, avec ou sans limite temporelle. La vérification préalable garantit la confiance dans l’automatisation.

Collaboration avec le protocole x402 : rendre les actions “autorables et réglables”

Dans le cas des Agents, un autre enjeu est la réalisation de la valeur une fois l’action autorisée. Certains protocoles, comme x402, tentent de résoudre ce problème en réactivant le code HTTP 402 (Payment Required), permettant à l’Agent de payer automatiquement en stablecoin lors de la demande de ressources ou services. ERC-8004 et x402 opèrent à des niveaux différents mais complémentaires : ERC-8004 définit “qui peut faire quoi, est-ce permis”, tandis que x402 gère “comment effectuer le paiement lors de l’action”. Ensemble, ils permettent un processus complet, sans intervention humaine, de vérification d’autorisation à la réalisation de la valeur, tout en évitant de mélanger identité, autorisation et paiement dans un seul système. Avec la croissance des scénarios d’utilisation (contenu, données, calcul), cette architecture modulaire pourrait devenir une infrastructure évolutive.

Entreprises et RWA : l’autorisation comme expression de conformité

Dans les applications d’entreprise et RWA, la valeur d’ERC-8004 réside dans la conformité et la traçabilité. La gestion d’actifs dans le monde réel nécessite de répondre à la question : “qui, sous quelles conditions, a effectué quelles actions ?”. La définition et l’enregistrement des permissions deviennent une étape clé pour intégrer Web3 dans le système financier traditionnel. ERC-8004 ne résout pas directement la conformité, mais fournit une base pour une expression structurée des permissions, permettant audit, traçabilité et vérification. Cela peut réduire considérablement le coût d’intégration entre Web3 et les organisations classiques.

Ces applications montrent que ERC-8004 n’est pas un standard “orienté scénario”, mais une capacité fondamentale qui émerge naturellement avec la complexification des autorisations. Lorsqu’un comportement sur la chaîne devient un système continu, une expression claire et vérifiable des permissions devient presque incontournable.

4. Défis et valeur à long terme d’ERC-8004

Défis pratiques

Premièrement, le coût d’apprentissage. Comparé à une simple autorisation ponctuelle, ERC-8004 introduit une logique de permission plus fine, nécessitant une nouvelle compréhension pour développeurs et utilisateurs. Ce coût doit être absorbé par le marché. Deuxièmement, la compatibilité avec les portefeuilles et l’infrastructure. La pleine puissance d’ERC-8004 ne peut s’exprimer que si wallets, SDK et environnements d’exécution le supportent. Au début, cela reste une capacité utilisable mais pas encore universelle. Troisièmement, l’expérience utilisateur. La complexité des autorisations structurées ne doit pas alourdir l’interaction. La traduction de règles machine en interfaces intuitives est un défi crucial pour une adoption massive.

ERC-8004, pas une solution immédiate

En raison de ces barrières, ERC-8004 n’est pas une solution à court terme. Il ne provoquera pas une explosion immédiate d’utilisateurs ni de revenus. Son rôle est plutôt de rendre le système contrôlable, explicable et vérifiable dans un contexte de complexification. Sa valeur ne réside pas dans le nombre de fonctionnalités, mais dans sa capacité à poser une base d’autorisation évolutive pour l’automatisation, les Agents et la participation institutionnelle. En ce sens, ERC-8004 n’est pas une norme pour une seule période, mais une capacité fondamentale pour que Web3 supporte des relations de collaboration complexes.