Auteur : Zack Pokorny, chercheur assistant chez Galaxy Digital ; Source : Galaxy Digital ; Compilation : Shaw Golden Finance

Introduction

Les cas d’usage et les capacités des agents d’intelligence artificielle (AI Agent) ont commencé à évoluer progressivement. Ils parviennent peu à peu à exécuter des tâches de manière autonome ; des travaux de R&D sont également en cours pour que les agents détiennent et configurent des fonds, explorent des stratégies de trading et de rendement, et déploient d’autres fonctions. Bien que cette transformation expérimentale soit encore à un stade très précoce, sa direction de développement diffère nettement de celle du passé : auparavant, la plupart des agents étaient surtout utilisés comme outils sociaux et d’analyse.

La blockchain offre un terrain d’essai naturel pour cette évolution. Elle présente des caractéristiques de non-autorisation, de composabilité (c’est-à-dire qu’un même cadre d’exécution peut accueillir divers composants financiers de base), un écosystème d’applications open source, des données ouvertes et accessibles à l’ensemble des participants de manière équitable, et tous les actifs on-chain sont, par défaut, pris en charge pour être programmables.

D’où une question structurelle : puisque la blockchain est programmable et sans permission, pourquoi des agents autonomes rencontreraient-ils encore des obstacles d’exécution ? La réponse ne tient pas à savoir si l’exécution est faisable, mais au coût de compréhension sémantique et d’orchestration de la coordination à assumer au-dessus du niveau d’exécution. La blockchain peut garantir l’exactitude des transitions d’état, mais elle ne fournit généralement pas les capacités abstraites telles que l’interprétation économique native du protocole, l’identité standard, ou l’orchestration hiérarchique des objectifs.

Une partie des obstacles provient des caractéristiques d’architecture des systèmes sans permission, une autre partie vient de l’état actuel du développement des outils, du filtrage de l’information et des infrastructures de marché. Dans les applications réelles, de nombreuses fonctionnalités de niveau supérieur doivent encore s’appuyer sur des logiciels et des processus de travail conçus avec l’humain comme principal opérateur.

Architecture de la blockchain et agents d’intelligence artificielle

Le cœur de la conception de la blockchain s’articule autour du mécanisme de consensus et de l’exécution déterministe, plutôt que de l’interprétation sémantique. Ce qu’elle offre en externe, ce sont des composants de base de bas niveau comme emplacements de stockage, journaux d’événements, traçage des appels, et non des objets économiques standardisés. Par conséquent, des concepts abstraits comme les positions détenues, le rendement, les coefficients de santé, la profondeur de liquidité, etc., doivent généralement être reconstruits hors chaîne par des indexeurs, des couches d’analyse, des interfaces front-end et des API, afin de transformer l’état exclusif de chaque protocole en une forme plus exploitable.

Bon nombre des processus opérationnels des principales plateformes de finance décentralisée, en particulier ceux orientés vers des utilisateurs ordinaires et des opérations à décision subjective, reposent encore sur le schéma central : l’utilisateur interagit via une interface front-end, et la confirmation de signature de chaque transaction individuelle constitue le mode clé. Ce modèle centré sur l’interface utilisateur, en accompagnant la diffusion des utilisateurs ordinaires, a permis une application à grande échelle, même si une part considérable des activités on-chain est déjà pilotée par des machines. La logique d’interaction standard avec les utilisateurs ordinaires reste aujourd’hui : intention d’action → interface utilisateur → envoi de transaction → confirmation que c’est terminé. Bien que l’opération programmatique suive un chemin différent, elle présente aussi ses propres limites : le développeur doit sélectionner à l’étape de construction le contrat et la plage d’actifs, puis faire fonctionner l’algorithme sur cette plage fixe. Ces deux modes ne peuvent pas s’adapter à des systèmes qui, pendant l’exécution, doivent découvrir, évaluer et combiner des comportements opérationnels de manière autonome selon des objectifs dynamiques.

Lorsque l’infrastructure conçue spécifiquement pour la validation des transactions est utilisée par des systèmes qui doivent aussi interpréter l’état économique, évaluer la crédibilité et optimiser le comportement autour d’objectifs clairement définis, les obstacles d’exécution commencent à apparaître. Une partie de cet écart provient des caractéristiques de conception des blockchains sans permission et hétérogènes ; une autre provient du fait que les outils existants emballent encore les interactions avec la blockchain autour d’un flux conçu pour l’audit humain et des intermédiaires front-end.

Flux d’opération des agents et stratégies algorithmiques traditionnelles

Avant d’analyser l’écart entre les infrastructures de blockchain et les systèmes d’agents, il faut d’abord clarifier un flux d’opération d’agents plus avancé, ainsi que les différences fondamentales avec les systèmes d’algorithmes on-chain traditionnels.

Les différences entre les deux ne résident pas dans le niveau d’automatisation, la complexité technique, la configuration paramétrique, voire la capacité d’adaptation dynamique. Les systèmes d’algorithmes traditionnels peuvent être hautement paramétrés : ils découvrent automatiquement de nouveaux contrats et tokens, allouent des fonds entre différents types de stratégies, puis se rééquilibrent en fonction des performances. La différence fondamentale réside dans la capacité du système à gérer des scénarios qui n’ont pas été présélectionnés au moment de la construction.

Qu’ils soient aussi complexes soient-ils, les systèmes d’algorithmes traditionnels ne peuvent exécuter que des logiques figées pour des schémas prévus lors de la phase de développement. Ces systèmes doivent être configurés avec des parseurs d’interfaces prévus pour chaque type de protocole, des logiques d’évaluation préétablies pour convertir l’état du contrat en sens économique, des règles de détermination explicites de la crédibilité et des standards, et toutes les branches de décision doivent être écrites en règles codées en dur (que l’algorithme lui-même soit dynamique et flexible ou non). Dès qu’une situation survient qui ne correspond pas au schéma prévu, le système soit ignore ce scénario, soit exécute directement en échec. Il ne peut pas raisonner sur un scénario inconnu : il ne peut qu’effectuer une vérification pour savoir si le scénario correspond à un modèle connu.

_Comme cet appareil mécanique du type « canard qui digère », il peut imiter des comportements vraiment convaincants, mais chaque geste est préprogrammé. (__《Scientific American》, janvier 1899 _)

Lors du balayage d’un nouveau marché de prêts et d’emprunts, l’algorithme traditionnel peut identifier les contrats déployés émettant des événements familiers, ou ceux correspondant à un motif d’usine connu. Mais si une nouvelle brique de base de prêt emprunt présente une interface inconnue, le système ne pourra pas l’évaluer. Il faut alors que des humains examinent le contrat, en comprennent le mécanisme d’exécution, déterminent s’il doit être inclus dans le pool d’opportunités, et rédigent la logique d’intégration. Ce n’est qu’après avoir accompli ces étapes que l’algorithme peut interagir avec lui. L’humain interprète, l’algorithme exécute. Et un système d’agents basé sur des modèles de base casse cette frontière. Ils peuvent accomplir ceci grâce à des capacités de raisonnement apprises :

• Interpréter des objectifs flous ou non spécifiés clairement. Des instructions comme « maximiser le rendement tout en évitant les risques excessifs » nécessitent une interprétation : à quel niveau considère-t-on qu’il y a risque excessif ? Comment équilibrer rendement et risque ? Les algorithmes traditionnels doivent définir ces conditions avec précision à l’avance, alors que les modèles de base peuvent interpréter l’intention, faire des jugements, puis optimiser leur compréhension en fonction du retour.

• Adapter de manière généralisée des interfaces nouvelles. Les agents peuvent lire le code de contrats inconnus, analyser la documentation ou examiner des interfaces binaires d’application (ABI) qu’ils n’ont jamais vues, puis déduire la fonction économique de ce système. Ils n’ont pas besoin de construire à l’avance des parseurs pour chaque catégorie de protocole. À l’heure actuelle, cette capacité n’est pas encore parfaite : un agent peut mal interpréter, mais il peut tenter d’interagir avec des systèmes qui n’avaient pas été prévus pendant la phase de développement.

• Raisonner la crédibilité et la conformité sous incertitude. Lorsque les signaux de confiance sont flous ou incomplets, le modèle de base peut pondérer probabilistement, plutôt que d’appliquer simplement des règles binaires. Ce contrat intelligent est-il une version officielle authentique ? Avec les preuves disponibles, ce token est-il très probablement légitime ? Les algorithmes traditionnels n’ont que deux états : « avec règles » ou « sans règles », tandis que les agents peuvent raisonner en se basant sur la confiance.

• Interpréter les erreurs et ajuster de manière adaptative. Lorsqu’une situation inattendue survient (par exemple, un revert de transaction, une sortie qui ne correspond pas à l’attendu, ou un changement d’état entre la simulation et l’exécution), l’agent peut inférer la cause du problème et décider de la réponse à adopter. En comparaison, les algorithmes traditionnels exécutent seulement des blocs de code de capture d’exceptions, en traitant l’exception par routage, mais ils ne « lisent » pas l’exception.

Ces capacités existent réellement, mais ne sont pas encore parfaites. Les modèles de base peuvent produire des hallucinations, mal interpréter des informations et porter des jugements erronés avec un air de confiance. Dans des environnements adverses impliquant des fonds (c’est-à-dire où le code peut être contrôlé ou des actifs peuvent être reçus), « tenter d’interagir avec des systèmes non prévus » peut signifier perdre directement de l’argent. L’argument central de cet article n’est pas que les agents puissent, à l’heure actuelle, accomplir ces fonctions de manière fiable ; c’est plutôt qu’ils peuvent tenter ces fonctions d’une manière que les systèmes traditionnels ne peuvent pas faire, et que les infrastructures futures ont des chances de rendre ces tentatives plus sûres et plus fiables. Considérer les deux comme un continuum plutôt que comme des classifications absolues permet de mieux comprendre : certains systèmes traditionnels ont déjà intégré un raisonnement de type apprentissage, et certains agents peuvent aussi dépendre de règles codées en dur sur des chemins critiques. La différence entre les deux est directionnelle, pas une opposition binaire. Les systèmes d’agents placent davantage d’interprétation, d’évaluation et de travail adaptatif dans le raisonnement en temps d’exécution, plutôt que dans des hypothèses préétablies au moment du développement. Cela est étroitement lié à l’argument précédent sur les obstacles, car ce que les agents tentent de faire est précisément ce que les algorithmes traditionnels évitent totalement. Les algorithmes traditionnels évitent le coût de découverte en sélectionnant manuellement les ensembles de contrats à l’étape de développement ; ils évitent le coût de couche de contrôle en se reposant sur des listes blanches entretenues par des opérateurs ; ils évitent le coût de données en préconfigurant des parseurs pour les protocoles connus ; ils évitent le coût d’exécution en opérant dans les limites de sécurité prédéfinies. Une fois que les humains ont préparé à l’avance le travail sémantique, de confiance et de la couche stratégie, l’algorithme n’exécute que dans un périmètre délimité. Les premières versions des flux d’opération d’agents on-chain peuvent continuer ce modèle, mais leur logique centrale consiste à transférer la découverte, la confiance et l’évaluation de la stratégie vers le raisonnement en temps d’exécution, plutôt que des hypothèses préétablies au moment du développement.

Les agents peuvent tenter de découvrir et d’évaluer des opportunités inconnues, de déterminer la conformité du contrat sans règles codées en dur, de parser des états hétérogènes sans parseurs préconfigurés, et d’exécuter des stratégies en fonction d’objectifs potentiellement flous. Et c’est précisément à ces étapes que les faiblesses de l’infrastructure commencent à se révéler. Les obstacles existent non pas parce que les agents font la même chose que les algorithmes mais que c’est simplement plus difficile, mais parce qu’ils tentent d’accomplir des choses totalement différentes : ils opèrent dans un espace de comportements ouvert et interprétable dynamiquement, plutôt que dans un espace fermé et préintégré à l’avance.

Où se situe la friction

Structurellement, cette contradiction ne vient pas d’une faille du consensus de la blockchain, mais de la manière dont l’ensemble de la pile d’interaction construite autour d’elle évolue.

La blockchain garantit des transitions d’état déterministes, un consensus sur l’état final et la finalité. Mais elle ne code pas, au niveau du protocole, l’interprétation économique, la validation de l’intention ou le suivi d’objectifs. Ces responsabilités ont toujours été assumées par le front-end, les portefeuilles, les indexeurs et d’autres couches de coordination hors chaîne, et le processus implique toujours une intervention humaine.

Les modes d’interaction dominants reflètent aussi ce design : même pour des participants professionnels, c’est le cas. Les utilisateurs ordinaires interprètent l’état via des panneaux, sélectionnent des actions via l’interface, puis signent des transactions avec un wallet — ils ne « vérifient » pas officiellement les résultats. Les institutions de trading algorithmique automatisent l’exécution, mais dépendent toujours de la sélection humaine des ensembles de protocoles, du contrôle des exceptions, et mettent à jour la logique d’intégration quand les interfaces changent. Dans les deux scénarios, le protocole ne garantit que l’exactitude de l’exécution ; l’interprétation d’intention, la gestion des exceptions et l’adaptation à de nouvelles opportunités restent une tâche humaine.

Les systèmes d’agents compressent voire éliminent cette répartition. Ils doivent reconstruire de manière procédurale des états ayant une signification économique, évaluer si les objectifs sont atteints, et vérifier les résultats en dehors du simple fait d’inscrire une transaction. Ces charges ressortent d’autant plus sur la blockchain, car les agents opèrent dans des environnements ouverts, adverses et changeant rapidement : de nouveaux contrats, actifs et chemins d’exécution peuvent apparaître sans qu’un audit décentralisé ait lieu. Le protocole garantit seulement que la transaction s’exécute correctement ; il ne garantit pas que l’état économique soit facile à interpréter, que le contrat soit une version officielle authentique, que le chemin d’exécution corresponde à l’intention de l’utilisateur, ou que les opportunités associées puissent être découvertes de manière procédurale.

Les chapitres suivants analyseront ces obstacles à chaque étape de la boucle d’exécution des agents : découverte des contrats et opportunités existants, vérification de leur légitimité, obtention d’états ayant une signification économique, puis exécution selon les objectifs.

Coût de découverte

Le coût de découverte existe parce que l’espace de comportements de la finance décentralisée (DeFi) s’étend continuellement dans un environnement ouvert sans permission, tandis que la pertinence et la légitimité doivent être filtrées par des humains via les couches de social on-chain, de marché et d’outils. Les nouveaux protocoles sont filtrés par des couches de signal : annonces et publications de recherche, intégration sur le front-end, listes de tokens, plateformes d’analyse et formation de liquidité, etc. Au fil du temps, ces signaux finissent par produire une série de critères opérationnels pour identifier la partie du comportement qui a de la valeur économique et assez de confiance, même si ce processus est souvent informel, déséquilibré, et dépend partiellement de tiers et de sélection humaine.

Même si les agents peuvent obtenir les données filtrées et les signaux de confiance, ils ne disposent pas des raccourcis naturels qu’ont les humains pour interpréter ces signaux. Du point de vue on-chain, la détectabilité de tous les contrats déjà déployés est égale. Les protocoles légitimes, les forks malveillants, les déploiements de test et les projets abandonnés existent tous sous forme de bytecode appelable. La blockchain ne signale pas lesquels sont importants ou lesquels sont sûrs.

Du point de vue on-chain, tous les contrats déployés ont la même détectabilité. Les contrats de protocoles légitimes, de forks malveillants, les contrats de déploiement de test et les projets abandonnés apparaissent tous sous forme de bytecode appelable.

Ainsi, les agents doivent construire eux-mêmes un mécanisme de découverte : scanner les événements de déploiement, identifier les motifs d’interfaces, suivre les contrats factory (des contrats qui déploient d’autres contrats de manière procédurale) et surveiller la formation de la liquidité afin de déterminer quels contrats doivent entrer dans le périmètre de décision. Ce processus ne consiste pas seulement à trouver des contrats, mais aussi à déterminer s’ils valent la peine d’entrer dans l’espace de comportements des agents.

Identifier des contrats candidats n’est que la première étape. Après un filtrage par découverte initiale, les contrats doivent encore passer par la validation de conformité et d’authenticité décrite dans la section suivante. L’agent doit confirmer que le contrat découvert correspond à ce qu’il prétend, avant de pouvoir l’intégrer dans l’espace de décision.

La découverte limitée par la stratégie diffère de la découverte ouverte

Le coût de découverte ne désigne pas simplement la détection de nouveaux déploiements. Les systèmes algorithmiques matures savent déjà le faire dans le cadre de leur stratégie. Par exemple, les searchers qui surveillent les événements d’usine Uniswap et intègrent automatiquement les nouvelles pools de liquidité réalisent une découverte dynamique. Les obstacles apparaissent à deux niveaux plus élevés : déterminer si le contrat trouvé est légitime (problèmes de conformité abordés dans la section suivante) ; et déterminer s’il sert des objectifs en découverte ouverte, plutôt que de se limiter à s’adapter à un type de stratégie prédéfini.

La logique de découverte d’un searcher est étroitement liée à sa stratégie : il sait quel motif d’interface rechercher, puisque la stratégie est définie à l’avance. En revanche, un agent chargé de tâches plus larges comme « configurer l’opportunité avec le meilleur ajustement risque-rendement » ne peut pas se reposer uniquement sur des filtres dérivés de la stratégie. Il doit évaluer les opportunités rencontrées par rapport à l’objectif lui-même : cela nécessite d’analyser des interfaces inconnues, de déduire les fonctions économiques et de déterminer si cette opportunité doit être intégrée dans l’espace de décision. Cette partie relève du problème d’autonomie générale, mais la blockchain rend cette difficulté encore plus grande : du code inconnu peut s’exécuter directement, porter des fonds, et il est difficile de catégoriser uniquement avec les signaux natifs du protocole.

Friction de la couche de contrôle

Le coût de la couche de contrôle provient du fait que l’identité et la légitimité sont généralement déterminées en dehors du protocole par un filtrage, une gouvernance, des documents, des interfaces et des jugements d’opérateurs. Dans la plupart des flux de travail actuels, l’humain reste une étape importante de ce processus de détermination. La blockchain garantit une exécution déterministe et une finalité, mais elle ne garantit pas que l’appelant interagit avec le contrat cible. La détermination de l’intention est externalisée vers le contexte social, des sites web et un filtrage humain.

Dans le flux actuel, l’humain utilise la couche de confiance du web comme outil de vérification informel : via des agrégateurs comme DeFiLlama ou des comptes sociaux certifiés du projet, on trouve le domaine officiel, puis on considère ce site comme la correspondance « officielle » entre un concept humain et l’adresse de contrat. Le front-end encode ensuite une série de sources de vérité valides : il indique quelles adresses sont officielles, quel token sert à les représenter, quelles entrées sont sûres.

1789, le Turc mécanique (Mechanical Turk) : une machine à jouer aux échecs ; en surface elle semble fonctionner de manière autonome, mais en réalité elle dépend d’un opérateur humain caché. (Bibliothèque de l’université de Humboldt)

Par défaut, un agent ne va pas interpréter les identifiants de marque, les signaux sociaux certifiés ou la notion de « caractère officiel » via le contexte social. Nous pouvons fournir à l’agent des entrées filtrées provenant de ces signaux, mais pour les convertir en hypothèses de confiance stables et exploitables par une machine, il faut définir un registre, des règles de politique ou une logique de vérification. Les opérateurs peuvent configurer pour l’agent des listes blanches, des adresses certifiées et des stratégies de confiance. Le problème n’est pas que le contexte social soit totalement inaccessible, mais que maintenir en permanence ces protections dans un espace de comportements qui s’étend dynamiquement impose une charge d’exploitation énorme, et qu’en l’absence ou en cas d’imperfection de ces protections, l’agent n’a pas les mécanismes de vérification de secours que les humains utilisent intuitivement.

Les conséquences réelles d’un manque de capacité de jugement de confiance se manifestent déjà dans des systèmes on-chain pilotés par des agents. Le youtubeur crypto et influenceur Orangie a déjà eu un cas où un agent a déposé des fonds dans un contrat de « piège » (honeypot). Dans un autre incident, un agent nommé Lobstar Wilde, à cause d’un défaut d’état ou de contexte, a mal interprété l’état de l’adresse et a transféré des soldes importants de tokens à une adresse en ligne « d’aumône » (donation scam). Ces cas ne constituent pas le cœur de l’argumentation de cet article, mais ils montrent de manière intuitive que les erreurs dans le jugement de confiance, l’interprétation de l’état et la stratégie d’exécution peuvent conduire directement à des pertes de fonds.

L’identification des contrats officiels n’est pas une fonctionnalité native du protocole

Le problème n’est pas que les contrats soient difficiles à découvrir ; c’est plutôt qu’en général, on ne trouve pas on-chain le concept natif « c’est le contrat officiel de telle application X ». Cette absence découle dans une certaine mesure des caractéristiques des systèmes sans permission, plutôt que d’un oubli de conception, mais elle crée tout de même un défi de coordination pour les systèmes autonomes. Le problème provient en partie de l’architecture de systèmes ouverts avec identité faiblement standardisée, et en partie du fait que les registres, les standards et les mécanismes de distribution de confiance ne sont pas encore matures. Si un agent veut interagir avec Aave v3, il doit déterminer quelles adresses sont des versions officielles authentiques (pool de fonds, configurateur, fournisseur de données, etc.), si ces adresses sont des contrats immuables, des contrats proxy (upgradeables) ou si elles sont dans un état de proposition de gouvernance qui doit être exécutée après modification.

Les humains résolvent ce problème via la documentation, les interfaces front-end et les médias sociaux ; quant aux agents, ils doivent vérifier les informations suivantes pour déterminer :

• Le mode proxy et le contrat de mise en œuvre vers lequel il pointe

• Les permissions de gestion et les contrats à time-lock

• Les modules de mise à jour des paramètres soumis à la gouvernance

• Le degré d’adéquation entre les bytecodes / interfaces binaires d’application (ABI) entre des contrats déployés connus

En l’absence de registre officiel, « le caractère officiel » devient un problème de raisonnement. Cela signifie que l’agent ne peut pas traiter l’adresse du contrat comme une configuration statique. Il doit soit maintenir en permanence une liste blanche présélectionnée et vérifiée, soit re-déduire la conformité du contrat en runtime via la vérification du proxy et la surveillance de la gouvernance, soit assumer le risque d’interagir avec des contrats abandonnés, attaqués ou contrefaits. Dans les logiciels et infrastructures de marché traditionnels, l’identité du service est généralement ancrée par un espace de noms, des identifiants et des contrôles d’accès maintenus par des organisations. En revanche, on-chain, un contrat peut être appelable et fonctionner correctement, mais du point de vue de l’appelant, il peut ne pas être une version officielle authentique au niveau économique ou métier.

Le problème de l’authenticité des tokens et des métadonnées est fondamentalement le même

Les tokens semblent se décrire eux-mêmes, mais leurs métadonnées ne sont pas faisant autorité : ce ne sont que des données de type byte renvoyées par le code du contrat. Un exemple typique est Wrapped Ether (WETH). Dans les contrats WETH largement utilisés, les définitions sont clairement établies :

Ces informations semblent représenter une identité, mais ce n’est pas le cas. N’importe quel contrat peut renvoyer ce qui suit :

• symbol() = “WETH”

• decimals() = 18

• name() = “Wrapped Ether”

Et implémenter exactement la même interface standard ERC-20. name(), symbol() et decimals() ne sont que des fonctions publiques en lecture seule, dont le contenu est entièrement défini par le déployeur. En fait, il existe déjà près de 200 tokens sur Ethereum dont le nom est « Wrapped Ether », dont le symbole est « WETH » et dont la précision est également 18 décimales. Si vous ne consultez pas CoinGecko ou Etherscan, pouvez-vous distinguer lequel de ces « WETH » est bien celui qui est officiel authentique ? (La réponse est le 78e élément de la liste)

Il existe près de 200 tokens sur Ethereum dont le nom est « Wrapped Ether » et le symbole est « WETH ». Sans l’aide de plateformes tierces, comment savoir lequel est le WETH authentique ?

Voilà la situation à laquelle les agents sont confrontés. La blockchain ne valide pas l’unicité, ne compare avec aucun registre et n’y prête aucune attention. Aujourd’hui même, vous pouvez déployer 500 contrats, tous renvoyant exactement les mêmes métadonnées. On trouve aussi certaines méthodes empiriques de jugement on-chain (par exemple comparer le solde ETH avec l’offre totale, vérifier la profondeur de liquidité des principaux DEX, contrôler s’il est listé comme collatéral par des protocoles de prêt, etc.), mais aucune méthode ne fournit une preuve absolument irréfutable. Chaque méthode repose soit sur des hypothèses de seuil (personne ne peut contrefaire une liquidité de pool de plusieurs milliards), soit de manière récursive nécessite d’abord de vérifier la conformité d’autres contrats.

Comme dans un labyrinthe, pour identifier le « vrai » chemin on-chain, il faut un guidage externe ; aucun signal standard n’est fourni. (Musée de Birmingham et galeries)

C’est la raison pour laquelle les listes de tokens et les registres existent en tant que couche de filtrage hors chaîne : ils fournissent un mécanisme qui associe la notion de « WETH » à une adresse spécifique, ce qui explique aussi pourquoi les wallets et les front-ends maintiennent des listes blanches ou s’appuient sur des agrégateurs de confiance. Pour un agent, le problème ne tient pas seulement au fait que les métadonnées ne sont pas fiables ; il tient aussi au fait que l’identité de conformité est généralement établie au niveau social ou institutionnel, et non comme une fonctionnalité native du protocole. L’identifiant unique fiable on-chain, c’est l’adresse du contrat ; cependant, pour mapper des intentions compréhensibles par l’humain (par exemple « échanger contre USDC ») vers la bonne adresse, il faut encore fortement dépendre d’un filtrage non natif du protocole, de registres, de listes blanches ou d’autres couches de confiance.

Friction des données

Un agent qui optimise entre plusieurs protocoles DeFi doit abstraire chaque opportunité en un objet économique unique : rendement, profondeur de liquidité, paramètres de risque, structure des frais, sources des oracles, etc. D’un certain point de vue, il s’agit d’un problème d’intégration système courant. Mais sur blockchain, en raison de l’hétérogénéité des protocoles, du risque de fonds directs, du collage de plusieurs états d’appels, et du fait que la couche de base ne fournit pas de schéma économique unifié, cette charge est amplifiée considérablement. Et ce sont précisément les informations nécessaires pour comparer les opportunités, simuler la configuration et surveiller les risques.

Au niveau du protocole, la blockchain ne expose généralement pas d’objets économiques standardisés ; elle expose seulement des emplacements de stockage, des journaux d’événements et des valeurs renvoyées par les fonctions. Les objets économiques doivent donc être déduits ou reconstruits à partir de ceux-ci. Le protocole garantit que l’appel de contrat renvoie la bonne valeur d’état, mais ne garantit ni que cette valeur corresponde clairement à des concepts économiques compréhensibles, ni que le même concept puisse être obtenu via des interfaces cohérentes entre différents protocoles.

Ainsi, des concepts abstraits comme le marché, les positions, les coefficients de santé, etc., ne sont pas des composants natifs du protocole : ils sont reconstruits hors chaîne par des indexeurs, des plateformes d’analyse, des front-ends et des API, afin de normaliser l’état hétérogène des protocoles en une couche d’abstraction exploitable. Les utilisateurs humains ne voient généralement que cette couche de données normalisées, et les agents peuvent aussi l’utiliser, mais ils héritent alors aussi des schémas tiers, de la latence et des hypothèses de confiance ; sinon, ils doivent reconstruire eux-mêmes toute cette logique d’abstraction.

Ce problème s’aggrave encore dans différents types de protocoles. Le prix des parts du coffre, le taux de collatéral du marché de prêt, la profondeur de liquidité des pools DEX, le taux de récompense des contrats de staking, etc. sont tous des indicateurs fondamentaux ayant une signification économique, mais aucun n’est exposé via une interface standardisée. Chaque pile de protocoles a sa propre méthode de lecture, sa propre structure de données et ses conventions d’unités ; même pour la même catégorie, la manière de faire peut différer.

Marché de prêts : un exemple typique de lecture fragmentée

Le marché de prêts illustre clairement ce problème. Les concepts économiques sont généralement similaires et universels : par exemple liquidités de dépôt et de prêt, taux d’intérêt, coefficients de collatéral, limites de capacité, seuils de liquidation, etc. ; mais les chemins de lecture des données sont totalement différents.

Prenons Aave v3 comme exemple : l’énumération du marché et la lecture de l’état des actifs de réserve sont des étapes séparées. Le processus typique est le suivant :

Lister les actifs de réserve via ce qui suit

Cette fonction renvoie un tableau d’adresses de tokens.

Pour chaque actif, obtenir les données de base de liquidité et de taux d’intérêt via ce qui suit :

L’appel renvoie une structure contenant les données, une seule fois suffit pour obtenir des informations incluant le volume total de liquidité, l’indice des taux et l’identifiant de configuration, par exemple :

À l’inverse, dans Compound v3 (Comet), chaque déploiement correspond à un seul marché (comme USDC, USDT, ETH, etc.), et il n’existe pas de structure unifiée de réserves. Par conséquent, il faut effectuer plusieurs appels de fonctions pour assembler un snapshot complet du marché :

Utilisation de base

Total

Taux d’intérêt

Configuration des actifs collatéraux

Paramètres de configuration globaux

Chaque appel ne renvoie que des fragments différents de l’état économique. « Le marché » n’est pas un objet de premier rang ; c’est une structure inférée que l’appelant assemble à sa manière.

Du point de vue de l’agent, ces deux protocoles appartiennent au même type : le marché de prêts. Mais du point de vue de l’intégration, le système de récupération de données est totalement différent. Il n’existe pas de structure de données universelle comme :

À la place, l’agent doit, pour des protocoles différents, utiliser des méthodes différentes d’énumération d’actifs, effectuer plusieurs appels pour assembler des données d’état, uniformiser les unités et les règles de conversion, et coordonner la différence entre les valeurs déduites et les données de base exposées directement.

La fragmentation engendre de la latence et un risque d’incohérence

En plus du manque d’unification au niveau de la structure, cette fragmentation engendre aussi des risques de latence et d’incohérence. Comme l’état économique n’est pas exposé comme un objet de marché unifié et atomique, l’agent doit envoyer plusieurs appels de procédure à distance (RPC) vers plusieurs contrats afin de reconstruire un snapshot d’état. Chaque appel supplémentaire ajoute de la latence, augmente la probabilité de déclencher une limitation de débit d’interface, et accroît le risque d’incohérence des blocs en raison de la chaîne. Dans un environnement de volatilité du marché, une fois le calcul des taux d’intérêt sur la base de l’offre terminé, l’utilisation des fonds peut déjà avoir changé. Si la hauteur de bloc n’est pas clairement verrouillée, les paramètres de configuration et le volume total de liquidité peuvent ne pas provenir du même bloc. Les utilisateurs humains résolvent implicitement ce problème grâce à une couche de cache front-end et à un backend d’agrégation. En revanche, un agent qui appelle directement les interfaces RPC primitives doit gérer explicitement les problèmes de synchronisation des données, de requêtes par lots et de cohérence temporelle. Ainsi, la non-standardisation de la collecte de données n’est pas seulement une gêne d’intégration : c’est aussi une contrainte pour les performances, les mécanismes de synchronisation et la correction d’exécution.

Le manque de normes unifiées pour l’accès aux données économiques signifie que, même si différents protocoles mettent en œuvre presque les mêmes fonctions financières de base, leur façon d’exposer l’état reste spécifique aux contrats et dépend d’une logique d’assemblage. Cette différence de structure est la cause essentielle des frictions liées aux données.

Inadéquation potentielle des flux de données

L’accès à l’état économique on-chain est essentiellement un modèle de « pull » ; même si les signaux d’exécution peuvent être poussés en flux. Les systèmes externes doivent activement interroger les nœuds pour obtenir l’état nécessaire, plutôt que de recevoir en continu des mises à jour structurées. Ce mode reflète la fonction centrale de la blockchain : valider à la demande, plutôt que maintenir une vue persistante et continue de l’état au niveau des applications.

Il existe aussi des composants de base pour le modèle « push » on-chain. Les abonnements WebSocket permettent de pousser en temps réel de nouveaux blocs et des journaux d’événements, mais ils ne contiennent pas l’état de stockage qui porte la majeure partie du sens économique, sauf si le protocole choisit activement d’y consigner les redondances comme journaux. Un agent ne peut pas, directement via des abonnements on-chain, lire l’utilisation du marché de prêts, le montant de réserve d’un pool ou les coefficients de santé des positions. Ces valeurs sont stockées dans l’espace de stockage des contrats, et la plupart des protocoles ne fournissent pas de mécanisme natif pour pousser les changements de stockage aux utilisateurs en aval. La méthode la plus viable consiste à s’abonner aux têtes de nouveaux blocs et à réinterroger l’état de stockage à chaque bloc — même si les états sont déclenchés par des événements en flux, l’accès à l’état reste fondamentalement un modèle de pull. Les journaux ne peuvent que suggérer qu’une donnée pourrait changer, mais ils ne codent pas l’état économique final ; reconstruire cet état nécessite toujours une lecture explicite et un accès à l’historique.

En revanche, les systèmes d’agents seraient mieux adaptés à des flux de données en sens inverse (push). L’agent n’a pas besoin de scruter les changements d’état de centaines de contrats ; il peut recevoir des mises à jour structurées et pré-calculées, puis les pousser directement dans son environnement d’exécution (par exemple, mettre à jour l’utilisation, les coefficients de santé ou les variations de positions). Une architecture push peut réduire les requêtes redondantes, diminuer la latence entre le changement d’état et la perception de l’agent, et permettre une couche intermédiaire d’encapsuler l’état en mises à jour sémantiques bien définies, plutôt que de forcer l’agent à interpréter seul le sens à partir du stockage brut.

Ce basculement de mode n’est pas facile. Il faut des infrastructures d’abonnement, une logique de filtrage de la pertinence, et des normes d’événements économiques convertissant les modifications de stockage en actions exécutables par l’agent. Mais à mesure que les agents deviennent des participants en continu en ligne, plutôt que des demandeurs occasionnels, le problème d’inefficacité du modèle pull — limitation de débit d’interfaces, surcharge de synchronisation, requêtes répétées entre différents agents — deviendra de plus en plus grave. Traiter l’agent comme un consommateur continu plutôt que comme un client occasionnel rend l’infrastructure push peut-être plus adaptée au fonctionnement des systèmes autonomes.

Le fait qu’une infrastructure push soit réellement supérieure n’est pas encore tranché. Un flux de changements d’état complet crée des problèmes de filtrage, et l’agent devra toujours déterminer quelles informations sont pertinentes, ce qui réintroduit de la logique de pull à un autre niveau. Le problème n’est pas que le modèle pull soit « mauvais » en soi ; c’est que l’architecture actuelle n’avait pas été conçue en tenant compte d’utilisateurs machines persistants, et qu’à mesure que l’échelle d’utilisation des agents augmente, il devient pertinent d’explorer des alternatives.

Friction d’exécution

La friction d’exécution apparaît parce que, dans de nombreuses couches d’interaction actuelles, la conversion de l’intention, l’audit des transactions et la validation des résultats sont encapsulés dans des workflows centrés sur le front-end, les wallets et la supervision humaine. Dans les scénarios d’utilisateurs ordinaires et de décisions subjectives, cette supervision est généralement effectuée par des humains. Pour les systèmes autonomes, ces fonctions doivent être formalisées et implémentées directement dans le code. La blockchain peut garantir une exécution déterministe selon la logique des contrats, mais elle ne garantit pas que la transaction respecte l’intention de l’utilisateur, respecte des contraintes de risque ou réalise le résultat économique attendu. Dans les flux existants, le front-end et les humains comblent cette lacune.

Le front-end orchestre une séquence d’actions (échange, autorisation, dépôt, prêt), le wallet fournit le point de contrôle final « d’audit et d’envoi », et l’utilisateur ou l’opérateur effectue généralement un jugement de stratégie de manière informelle à la dernière étape. Ils évaluent souvent si la transaction est sûre et si le résultat d’une cotation est acceptable, même avec des informations incomplètes. Si la transaction échoue ou si des résultats inattendus surviennent, l’utilisateur réessaie, ajuste le slippage, modifie le chemin ou abandonne l’action. Les systèmes d’agents éliminent les humains de cette boucle d’exécution, ce qui signifie que le système doit remplacer trois fonctions humaines par une logique native machine :

1. Compilation de l’intention. L’objectif humain, par exemple « allouer mes stablecoins vers le meilleur canal de rendement ajusté au risque », doit être compilé en un plan d’action concret : choisir quel protocole, quel marché, quel chemin de tokens, l’échelle de l’opération, le mode d’autorisation et l’ordre d’exécution. Pour les humains, ce processus est réalisé implicitement via le front-end ; pour les agents, il doit être formalisé.

2. Exécution de stratégie. Cliquer sur « envoyer la transaction » n’est pas seulement un acte de signature : c’est aussi une validation implicite que la transaction respecte les contraintes — tolérance au slippage, limite de levier, coefficient de santé minimal, contrats sur liste blanche ou « interdire les contrats upgradeables », etc. L’agent doit encoder des contraintes de stratégie explicites en règles vérifiables par la machine :

Le système d’exécution doit, avant de diffuser la transaction, vérifier que le graphe des appels envisagés correspond à ces règles.

1. Validation des résultats. Le fait que la transaction soit incluse on-chain ne signifie pas que la tâche est terminée. Une transaction peut s’exécuter avec succès, mais ne pas atteindre l’objectif : le slippage pourrait dépasser la tolérance, des limites de montant peuvent empêcher d’atteindre la taille de la position cible, ou le taux d’intérêt pourrait changer entre la simulation et l’exécution on-chain. Les humains effectuent une vérification informelle via le front-end après la transaction, tandis que les agents doivent évaluer de manière procédurale les conditions d’état après exécution :

Cela impose des exigences plus élevées pour la validation du niveau d’achèvement : il ne suffit pas de confirmer que la transaction est incluse on-chain. Une architecture centrée sur l’intention pourrait fournir une partie de la solution, en déplaçant davantage la charge liée à « comment exécuter » vers des solveurs spécialisés. Les agents ne diffusent plus des données d’appels brutes : ils diffusent une intention d’exécution déjà signée, et spécifient des conditions basées sur le résultat ; le solveur ou des mécanismes de couche protocole doivent satisfaire ces contraintes, et l’exécution est considérée comme valide.

Workflows multi-étapes et modes de défaillance

Une grande partie de l’exécution en finance décentralisée (DeFi) est naturellement composée de plusieurs étapes. Une opération de configuration de rendement peut nécessiter d’accomplir successivement : autoriser → échanger → déposer → emprunter → déposer en garantie (staker). Certaines étapes peuvent être des transactions indépendantes, tandis que d’autres peuvent être regroupées via des appels batch ou des contrats de routage. Les humains peuvent tolérer que le flux ne soit pas totalement terminé, retourner sur l’interface et continuer l’opération ; tandis qu’un agent doit disposer d’une orchestration déterministe : si une étape échoue, il doit décider s’il faut réessayer, changer de chemin, annuler les opérations précédentes (rollback), ou suspendre l’exécution.

Cela engendre de nouveaux modes de défaillance généralement masqués dans les flux d’opération humains :

• Dérive de l’état entre la décision et l’inscription on-chain : entre l’exécution simulée et l’intervalle réel on-chain, le taux d’intérêt, l’utilisation ou la liquidité peuvent changer. Les humains peuvent accepter ces variations ; l’agent doit fixer des plages acceptables et les appliquer strictement.

• Exécution non atomique et exécution partielle : certaines opérations peuvent s’étendre sur plusieurs transactions, ou ne produire qu’une partie du résultat attendu. L’agent doit suivre l’état intermédiaire et confirmer que l’état final correspond à l’objectif.

• Risques d’autorisation de plafond et d’approbation : les humains complètent souvent l’autorisation par habitude via l’interface, tandis que l’agent doit raisonner la portée d’autorisation (montant, payeur/destinataire, durée de validité) dans une stratégie de sécurité, plutôt que de traiter l’autorisation seulement comme une étape d’interface.

• Choix du chemin et coûts d’exécution implicites : les humains s’appuient sur les outils de routage et les configurations par défaut de l’interface ; l’agent doit modéliser le slippage, les risques MEV (valeur extraite par les mineurs), les frais Gas et l’impact sur les prix dans la fonction objectif.

Exécution : un problème de contrôle natif pour la machine

Le point central de la friction d’exécution est le suivant : la couche d’interaction DeFi traite la signature du wallet humain comme le dernier maillon de contrôle. Aujourd’hui, la validation de l’intention, l’évaluation de la tolérance au risque et le contrôle informel du type « est-ce raisonnable » se concentrent dans cette étape. En retirant l’humain, l’exécution devient un problème de contrôle : l’agent doit transformer l’objectif en actions on-chain, exécuter automatiquement des contraintes de stratégie, et vérifier le résultat dans l’incertitude. Ce défi existe dans de nombreux systèmes autonomes, mais il est particulièrement sévère dans un environnement blockchain, car l’exécution implique directement des fonds, des appels composables à des contrats inconnus, et des changements d’état adverses. Les humains prennent des décisions en s’appuyant sur l’expérience et corrigent les erreurs par essais-erreurs ; l’agent doit accomplir des tâches similaires à la vitesse machine, de manière procédurale, et fait souvent face à des espaces d’opération dynamiques. Par conséquent, l’idée que « l’agent n’a qu’à soumettre des transactions » sous-estime fortement la difficulté. Soumettre des transactions est la partie simple ; le véritable manque concerne l’ensemble du travail assumé par l’interface et les humains : compilation de l’intention, garde-fou de sécurité et validation de l’atteinte de l’objectif.

Conclusion

À l’origine, la blockchain ne fournit pas nativement une couche sémantique et une couche de coordination nécessaires aux agents autonomes. Son objectif de conception est d’assurer une exécution déterministe et un consensus sur les transitions d’état dans un environnement adversarial. Les couches d’interaction développées sur cette base restent toujours centrées sur les utilisateurs humains : interpréter l’état via l’interface, choisir des actions via le front-end, vérifier et valider les résultats via l’audit humain.

Les systèmes d’agents renversent cette architecture. Ils retirent de la boucle les interprètes humains, les validateurs et les vérificateurs, et exigent que ces fonctions soient rendues natives par une machine. Cette transformation révèle une friction structurelle dans quatre dimensions : découverte, jugement de confiance, acquisition des données et orchestration de l’exécution. Ces frictions ne proviennent pas du fait que l’exécution est impossible, mais parce que, dans la plupart des scénarios, les infrastructures autour de la blockchain supposent encore que des humains participent à l’interprétation des états et à la soumission des transactions.

Combler ces lacunes pourrait nécessiter la construction d’une nouvelle infrastructure à plusieurs niveaux : un middleware qui normalise l’état économique entre protocoles en une spécification lisible par les machines ; des services d’indexation ou des extensions RPC qui exposent des composants sémantiques comme les positions, les coefficients de santé et des ensembles d’opportunités, plutôt que de simples données de stockage brutes ; des registres fournissant une cartographie des contrats officiels et la vérification de l’authenticité des tokens ; et enfin un cadre d’exécution permettant d’encoder des contraintes de stratégie, de gérer des workflows multi-étapes et de valider de manière procédurale l’atteinte de l’objectif. Certaines lacunes proviennent des caractéristiques structurelles des systèmes sans permission : déploiement ouvert, identité faiblement standardisée et interfaces hétérogènes ; d’autres sont limitées par les outils existants, les standards et la conception des incitations. À mesure que l’utilisation des agents augmente, et que les protocoles optimisent la compétition pour améliorer la facilité d’intégration des systèmes autonomes, ces problèmes ont de bonnes chances d’être atténués.

À mesure que les systèmes autonomes commencent à gérer des fonds, à exécuter des stratégies et à interagir directement avec des applications on-chain, les hypothèses d’architecture intégrées dans les couches d’interaction actuelles deviennent de plus en plus visibles. La majorité des frictions décrites dans cet article proviennent du fait que les outils blockchain et les modes d’interaction se sont développés autour de workflows impliquant des intermédiaires humains ; une partie vient naturellement de l’ouverture, de l’hétérogénéité et de l’environnement adversarial des systèmes sans permission ; et certaines relèvent de problèmes communs auxquels les systèmes autonomes font face dans des environnements complexes.

Le défi central n’est pas de faire signer les transactions aux agents, mais de leur fournir des chemins fiables ; de permettre, entre l’état on-chain brut et l’action réelle, d’accomplir des fonctions liées à la sémantique, à la confiance et à la stratégie — fonctions actuellement réalisées conjointement par les logiciels et le jugement humain.