Pourquoi le nouveau paradigme d'interaction ERC-8211 mérite-t-il notre attention ?

Auteur : imToken

À partir de 2025, beaucoup de personnes commenceront peut-être à s’habituer à une nouvelle façon d’interagir : dire à GPT ou Gemini « Aide-moi à planifier mon voyage à Hong Kong la semaine prochaine et recommande-moi des billets d’avion et hôtels appropriés », et il effectuera silencieusement en arrière-plan une série d’étapes telles que la recherche d’informations, le filtrage des conditions, le choix d’itinéraire, la comparaison des prix, etc., pour finalement vous présenter le résultat à confirmer.

Cependant, apporter la même attente sur la blockchain, l’histoire devient complètement différente.

Par exemple, si vous donnez une instruction à un Agent DeFi : « Échanger l’ETH dans le portefeuille contre des USDC, transférer sur la chaîne Base, puis déposer en totalité dans Aave », objectivement, du point de vue de « compréhension du besoin » et « planification du chemin », l’Agent d’aujourd’hui ne peut pas forcément le faire, la véritable rupture apparaît dans la phase d’exécution :

Vous devrez encore probablement effectuer étape par étape la signature, l’autorisation, l’échange, le transfert inter-chaînes et le dépôt, et chaque étape est exposée aux risques de slippage, de fluctuations du Gas, de délais de pont, et de changements d’état sur la chaîne, ce qui signifie que si une étape dévie de la prévision, il se peut que les actions précédentes ne puissent pas être annulées, et que les actions suivantes ne puissent pas être reliées, laissant souvent sur la chaîne un processus inachevé ou partiel.

Le problème ne réside pas dans le fait que l’IA n’est pas assez intelligente, mais dans le fait que la couche d’exécution sur la chaîne manque encore d’une véritable façon d’exprimer une opération adaptée à l’Agent.

C’est aussi pour cette raison qu’au début avril 2026, Biconomy et la Fondation Ethereum ont publié conjointement l’ERC-8211, visant à résoudre le problème des « limites statiques » dans l’exécution des contrats intelligents actuels, en fournissant une couche d’exécution plus expressive pour les agents IA et les flux de travail DeFi complexes, tentant de combler cette pièce manquante du puzzle.

1. La « dernière rupture » dans l’intégration des AI Agents sur la chaîne

Au cours de l’année ou deux dernières, l’attention de l’industrie de la cryptographie s’est clairement déplacée de l’expansion des L2, de la liquidité RWA, vers la question perturbatrice de savoir comment les AI Agents peuvent réellement prendre en charge les opérations sur la chaîne.

Objectivement, du « déploiement de stratégies DeFi multi-étapes via langage naturel » à « la gestion d’un portefeuille d’investissement inter-chaînes par un Agent autonome », nous avons récemment vu de nombreuses pratiques, et la plupart des concepts sont déjà matures au niveau de la démo, que ce soit la génération de stratégies DeFi multi-étapes par langage naturel, l’exécution autonome de rééquilibrages, le transfert automatique de revenus, l’ajustement de positions inter-chaînes, voire la gestion de portefeuilles plus complexes.

Du point de vue du raisonnement et de l’orchestration, la capacité de l’IA a déjà progressé rapidement, mais lorsque l’on met réellement cela en environnement de production, les limites de l’exécution deviennent de plus en plus évidentes.

En réalité, cette limite peut être résumée en une phrase : le DeFi est dynamique, mais la majorité des batchs (traitements par lots) aujourd’hui restent statiques.

Le site officiel et les discussions autour de l’ERC-8211 expliquent très bien ce problème : bien que l’ERC-4337 et l’EIP-5792 aient déjà permis de faire évoluer le modèle ancien « une signature = un appel », vers un nouveau modèle « une signature peut regrouper plusieurs appels », en réalité, les paramètres de ces appels restent en grande partie figés au moment de la signature.

Autrement dit, les montants, valeurs cibles, résultats attendus que l’utilisateur remplit lors de la signature ne s’ajustent pas automatiquement en fonction des changements d’état sur la chaîne lors de l’exécution.

Or, le DeFi lui-même est plein d’incertitudes. Le résultat réel d’un Swap dépend du slippage et de la liquidité dans le bloc d’exécution ; le délai et le montant final d’un transfert inter-chaînes dépendent du mécanisme et des frais du pont ; le ratio de partage-asset dans un protocole de prêt ou un Vault évolue constamment.

En fin de compte, les valeurs que l’utilisateur ou l’Agent voit lors de la signature ne sont souvent qu’une estimation instantanée, et non le résultat réel lors de l’exécution.

Pour comprendre ce que l’ERC-8211 résout, prenons un exemple typique : supposons qu’un Agent veuille faire une opération simple — échanger l’ETH du compte contre des USDC, puis déposer en totalité dans Spark pour gagner des intérêts.

Dans le modèle actuel de traitement batch statique, l’Agent doit estimer à l’avance combien d’USDC il recevra après le Swap, ce qui l’oblige souvent à coder en dur le montant d’entrée pour la deuxième étape lors de la signature, et si l’estimation est trop haute, le montant réel reçu sera insuffisant, ce qui entraîne un rollback complet du batch ; si elle est trop basse, une partie des fonds restera inutilisée dans le portefeuille sans pouvoir être utilisée.

En d’autres termes, il se retrouve dans une situation de dilemme : prendre le risque d’échouer ou sacrifier une opportunité. C’est pourquoi, lorsque les étapes d’un processus sur la chaîne s’allongent à 5, 8, voire traversent deux chaînes, cela devient rapidement fragile. Ce n’est pas parce que la stratégie est trop complexe pour être décrite, mais parce que le paradigme d’exécution actuel dépend trop de paramètres codés en dur.

En résumé, la capacité maximale du batch statique détermine en réalité la limite de sécurité que l’Agent peut atteindre lors de l’exécution de stratégies.

De ce point de vue, l’ERC-8211 ne cherche pas à faire faire des décisions à l’IA, mais à fournir une méthode plus naturelle, plus stable et plus sûre pour exécuter une fois que l’Agent a pris sa décision. Cela permet à l’exécution sur la chaîne d’avoir une expression native conçue pour l’Agent IA.

2. Qu’est-ce que l’ERC-8211 change concrètement ?

La percée centrale de l’ERC-8211 ne réside pas dans le fait d’empiler plus d’étapes dans une seule signature, mais dans la transformation du traitement batch, passant d’une séquence de transactions avec paramètres codés en dur, à une « procédure d’évaluation dynamique des paramètres lors de l’exécution ».

Cela peut sembler abstrait, mais ce n’est pas difficile à comprendre : l’équipe officielle la décrit en une phrase : « From transactions to programs. »

Cela signifie que l’ERC-8211 ne considère plus le batch comme une liste d’actions à exécuter dans l’ordre, mais comme un programme d’exécution qui s’évalue en temps réel, avec des conditions de sécurité. Concrètement, il se décompose en trois primitives composables :

• Fetchers (récupérateurs) : définissent d’où provient la valeur du paramètre, par exemple une requête en temps réel sur le solde d’une adresse, ce qui fait que le paramètre n’est plus une image instantanée lors de la signature, mais une lecture en temps réel de l’état de la chaîne lors de l’exécution ;

• Constraints (contraintes) : une fois le paramètre extrait, il doit être vérifié via des contraintes inline — par exemple « USDC reçu doit être ≥ 2500 », ou « le slippage ne doit pas dépasser 0,5 % » —, ces contraintes étant vérifiées avant de passer à l’appel suivant, et si l’une échoue, tout le batch est annulé ;

• Predicates (prédicats) : peuvent être compris comme des gardiens entre les étapes, responsables de décider si la suite doit continuer, par exemple dans un scénario inter-chaînes, le batch sur Ethereum peut attendre que « le WETH transféré via le pont soit arrivé » avant de continuer, en bloquant jusqu’à cette condition.

Dans cette conception, chaque paramètre doit répondre à deux questions : d’où provient cette valeur lors de l’exécution, et quelles conditions doivent être remplies avant de l’utiliser. La combinaison de ces trois éléments transforme un batch en un programme d’exécution avec vérification de sécurité intégrée.

En fin de compte, le modèle mental du traitement batch statique est une liste — exécuter A, puis B, puis C —, tandis que celui d’ERC-8211 est un programme conditionnel — après A, prendre sa sortie réelle pour B ; B doit satisfaire la contrainte pour passer à C ; toute étape non conforme entraîne un rollback.

On peut le voir comme un « mécanisme de batch intelligent » spécialement conçu pour les AI Agents et opérations DeFi complexes, car dans l’opération traditionnelle, réaliser une stratégie DeFi complexe nécessite plusieurs transactions indépendantes : retirer des fonds d’un protocole de prêt, échanger des tokens, puis déposer dans un autre protocole (voir aussi « Panorama des protocoles d’IA cryptographiques : comment construire un nouveau système d’exploitation pour AI Agents à partir du champ de bataille d’Ethereum »).

Chaque étape nécessite une signature et une confirmation séparées, ce qui est déjà fastidieux pour l’utilisateur humain, mais devient un goulot d’étranglement pour un AI Agent qui doit opérer fréquemment. La solution de l’ERC-8211 est de permettre l’exécution combinée de plusieurs opérations blockchain dans une seule transaction, avec une analyse dynamique des valeurs lors de l’exécution, et une progression conditionnelle.

Par exemple, un Agent peut réaliser en une seule signature : retirer des fonds d’Aave → échanger le montant reçu sur Uniswap → déposer le résultat dans Compound — tout cela de manière atomique, sans écrire de nouveau contrat intelligent.

3. Pourquoi cela concerne-t-il davantage les portefeuilles, en particulier les portefeuilles intelligents ?

L’ERC-8211 mérite l’attention de l’industrie des portefeuilles, non seulement parce qu’il est adapté aux Agents, mais aussi parce qu’il redéfinit la position du portefeuille dans la chaîne d’interaction.

Les portefeuilles passés étaient plus comme un signataire sécurisé : ils gèrent la clé privée, affichent la transaction, demandent la confirmation, puis envoient la signature. Ce rôle était déjà crucial à l’époque des EOA, et continue de l’être dans l’ère de l’abstraction de compte. Mais si à l’avenir, de plus en plus d’opérations sur la chaîne sont effectuées par des Agents, le rôle du portefeuille deviendra encore plus central.

La raison est simple : lorsque l’utilisateur ne contrôle plus chaque action sur la chaîne, mais autorise un Agent à exécuter une série d’objectifs, le portefeuille doit pouvoir supporter cette interaction de haut niveau. Il doit afficher non plus une adresse de contrat et un calldata, mais une « intention — logique de récupération — vérification de conditions — résultat final » sous forme d’un programme d’exécution.

Ainsi, le portefeuille de demain doit comprendre non plus seulement des transactions, mais des programmes. L’ERC-8211 fournit une base plus claire pour cela, en intégrant explicitement ces sémantiques d’exécution dans la structure du code, incluant d’où viennent les paramètres, quelles conditions doivent être remplies, quand continuer, quand revenir en arrière. Tout cela n’est plus une boîte noire dans la logique backend, mais un objet pouvant être interprété, simulé et présenté par le portefeuille.

Du point de vue du portefeuille, cette mécanique vise finalement une seule chose : l’utilisateur ne signe plus une longue série d’appels sous-jasents qu’il ne peut pas entièrement comprendre, mais une procédure d’exécution orientée résultat, avec des limites claires et des conditions vérifiables :

• L’Agent IA peut comprendre l’intention de l’utilisateur, générer le chemin ;

• Le portefeuille peut présenter ce chemin de façon plus claire pour validation ;

• Le relayer ne se charge que de soumettre lorsque les conditions sont remplies, sans pouvoir altérer le résultat.

C’est précisément cette capacité d’exécution non déléguée qui fait de l’Agentic DeFi une prémisse, car l’intelligence peut participer, mais la souveraineté, les contraintes et le règlement final restent sur la chaîne. C’est aussi là que l’ERC-8211 s’intègre parfaitement avec le portefeuille intelligent : il inscrit dans le protocole la capacité d’exprimer des intentions complexes de manière sécurisée.

Il est important de noter que l’ERC-8211 est compatible avec d’autres cadres d’abstraction de compte comme ERC-4337, EIP-7702, ERC-7579. Il ne remplace pas l’abstraction de compte, mais ajoute une couche sémantique de programmation pour les Agents.

Si l’ERC-4337 a résolu « qui peut initier une transaction en mon nom », et l’EIP-7702 « comment un EOA peut temporairement posséder une capacité de contrat intelligent », alors l’ERC-8211 résout la question : une fois que l’Agent commence à agir pour moi, peut-il réaliser toute une chaîne de décisions en une seule signature ?

En regardant l’évolution du paradigme d’interaction sur Ethereum au cours des 10 dernières années :

• Première étape : une signature = un appel de fonction (ère EOA)

• Deuxième étape : une signature = un lot d’appels statiques packagés (ERC-4337, EIP-5792)

• Troisième étape : une signature = un programme d’intention à évaluation dynamique (ERC-8211)

Chaque transition permet à l’utilisateur (ou à l’Agent représentant l’utilisateur) d’exprimer des objectifs plus complexes avec moins de friction.

Bien que l’ERC-8211 soit encore en phase de brouillon, avec des discussions techniques en cours, et que son intégration à grande échelle prenne du temps, la direction est déjà très claire : lorsque les Agents IA commenceront réellement à prendre des décisions sur la chaîne, il faudra une syntaxe d’exécution native adaptée.