Pourquoi la mise en œuvre des agents intelligents AI sur la blockchain rencontre-t-elle de nombreux obstacles ?

Écrit par : Zack Pokorny

Traduit par : Chopper, Foresight News

La mise en œuvre d’agents intelligents sur la blockchain n’a pas été fluide ; bien que la blockchain possède des caractéristiques programmables et sans permission, elle manque d’une couche sémantique abstraite et de coordination adaptée aux agents. Selon un rapport de l’institut de recherche en cryptographie Galaxy, les agents rencontrent quatre frictions structurelles sur la chaîne : la découverte d’opportunités, la vérification de confiance, la lecture de données et l’exécution de processus. Les infrastructures existantes sont encore principalement conçues autour de l’interaction humaine, ce qui limite leur capacité à supporter la gestion autonome d’actifs et l’exécution de stratégies par l’IA. Ces limitations constituent les principaux goulots d’étranglement pour la généralisation des agents sur la blockchain. Voici la traduction intégrale du rapport :

Les scénarios d’application et les capacités des agents intelligents ont commencé à évoluer. Ils exécutent désormais des tâches de manière autonome, et sont développés pour détenir et configurer du capital, découvrir des stratégies de trading et de rendement. Bien que cette transition expérimentale en soit encore à ses débuts, elle diffère radicalement du modèle précédent où les agents étaient principalement des outils sociaux ou analytiques.

La blockchain devient naturellement un terrain d’expérimentation pour cette évolution. Elle est sans permission, composable, possède un écosystème d’applications open source, ouvre ses données à tous les participants de manière équitable, et tous les actifs sur la chaîne sont par défaut programmables.

Cela soulève une problématique structurelle : si la blockchain est programmable et sans permission, pourquoi les agents autonomes rencontrent-ils encore des frictions ? La réponse ne réside pas dans la faisabilité de l’exécution, mais dans la charge sémantique et de coordination qui repose au-dessus de cette exécution. La blockchain garantit la correction des transitions d’état, mais ne fournit généralement pas d’abstractions natives pour l’interprétation économique, la vérification d’identité ou la coordination des objectifs.

Certaines frictions proviennent des défauts architecturaux des systèmes sans permission, d’autres reflètent l’état actuel des outils, de la gestion de contenu et des infrastructures de marché. En réalité, de nombreuses fonctionnalités de haut niveau dépendent encore de logiciels et de workflows, qui nécessitent une intervention humaine pour leur construction.

Architecture de la blockchain et agents IA

La conception de la blockchain tourne autour du consensus et de l’exécution déterministe, plutôt que de l’interprétation sémantique. Elle expose des primitives de bas niveau telles que les slots de stockage, les journaux d’événements, les traces d’appels, plutôt que des objets économiques standardisés. Par conséquent, des concepts abstraits comme la position, le rendement, le coefficient de santé ou la profondeur de liquidité doivent souvent être reconstruits hors chaîne par des indexeurs, des couches d’analyse de données, des interfaces frontales et des API, pour transformer les états spécifiques à chaque protocole en formats plus utilisables.

De nombreux processus de finance décentralisée (DeFi), notamment ceux destinés aux particuliers ou aux décisions subjectives, s’appuient encore sur une interaction utilisateur via une interface frontale, où chaque transaction est signée. Ce modèle centré sur l’interface utilisateur s’est étendu avec la popularité des particuliers, même si une partie importante de l’activité est désormais machine-driven. Le mode d’interaction dominant reste : intention → interface → transaction → confirmation. Les opérations programmatiques suivent une autre voie, mais présentent aussi leurs limites : lors de la construction, le développeur choisit un ensemble de contrats et d’actifs, puis exécute des algorithmes dans ce cadre fixe. Ces deux modèles ne conviennent pas aux systèmes qui doivent découvrir, évaluer et combiner dynamiquement des opérations en fonction d’objectifs changeants en temps réel.

Lorsque une infrastructure optimisée pour la validation des transactions est utilisée pour interpréter simultanément l’état économique, évaluer la crédibilité ou optimiser des comportements autour d’objectifs précis, la friction apparaît. Une partie de ces écarts provient des caractéristiques des systèmes sans permission et hétérogènes, une autre partie de l’état actuel des outils, de la gestion de contenu et des infrastructures de marché. En réalité, de nombreuses fonctionnalités de haut niveau dépendent encore de logiciels et de workflows, qui nécessitent une intervention humaine pour leur construction.

Comparaison des processus comportementaux des agents et des stratégies algorithmiques traditionnelles

Avant d’aborder les écarts entre l’infrastructure blockchain et les systèmes d’agents, il est essentiel de clarifier : en quoi un processus comportemental plus intelligent et autonome diffère-t-il d’un système algorithmique traditionnel sur la chaîne ?

La différence ne réside pas dans le degré d’automatisation, la complexité, la paramétrisation ou même la capacité d’adaptation dynamique. Les systèmes algorithmiques traditionnels peuvent être hautement paramétrés, découvrir automatiquement de nouveaux contrats ou tokens, répartir des fonds entre différentes stratégies, et rééquilibrer selon la performance. La véritable distinction réside dans leur capacité à gérer des scénarios imprévus lors de la phase de construction.

Les systèmes algorithmiques classiques, aussi complexes soient-ils, n’exécutent que des logiques prédéfinies selon des modèles préétablis. Ils nécessitent des interfaces, des évaluations, des règles de confiance et de conformité codées en dur pour chaque type de protocole. Lorsqu’un scénario inconnu apparaît, ils le ignorent ou échouent. Ils ne peuvent pas raisonner sur des situations nouvelles, mais seulement vérifier si elles correspondent à des modèles connus.

À l’image de cette machine « canard digestif », capable d’imiter le comportement biologique, mais dont tous les mouvements sont préprogrammés.

Une machine classique qui scanne le marché de prêt DeFi peut reconnaître des événements familiers ou de nouveaux contrats correspondant à des modèles connus. Mais si une nouvelle composante de prêt, avec une interface inconnue, apparaît, le système ne pourra pas l’évaluer. Il faudra qu’un humain examine le contrat, comprenne son mécanisme, juge s’il s’agit d’une opportunité exploitable, puis écrive une logique d’intégration. Ensuite, seul l’algorithme pourra interagir avec lui. L’humain interprète, l’algorithme exécute. Avec des agents basés sur un modèle fondamental, cette frontière change : ils peuvent, grâce à leur capacité de raisonnement appris, :

Interpréter des objectifs ambigus ou incomplets. Par exemple, une instruction du type « maximiser le rendement tout en évitant un risque excessif » nécessite une interprétation sémantique. Qu’est-ce qu’un risque excessif ? Comment équilibrer rendement et risque ? Les algorithmes traditionnels doivent définir précisément ces conditions à l’avance, alors que l’agent peut comprendre l’intention, faire des jugements, et optimiser sa compréhension en fonction du retour.

Généraliser pour s’adapter à des interfaces inconnues. L’agent peut lire du code de contrat inconnu, analyser la documentation, ou examiner des interfaces binaires d’applications jamais rencontrées, pour déduire la fonction économique du système. Il n’a pas besoin de construire à l’avance un parseur pour chaque protocole. Bien que cette capacité soit encore imparfaite, et qu’il puisse faire des erreurs d’interprétation, il peut tenter d’interagir avec des systèmes imprévus lors de la phase de construction.

Raisonner dans un contexte d’incertitude sur la confiance et la conformité. Lorsqu’un signal de confiance est flou ou incomplet, le modèle de base peut pondérer probabilistiquement ces signaux, plutôt que d’appliquer des règles binaires. La conformité d’un contrat standard ? La légalité d’un token ? Les algorithmes traditionnels ont des règles fixes ou ne peuvent pas répondre ; l’agent peut faire du raisonnement sur la confiance.

Interpréter des erreurs et ajuster ses actions. Lorsqu’un problème survient, l’agent peut raisonner sur la cause, et décider comment réagir. À l’inverse, un algorithme classique ne fait que transmettre une erreur ou une exception, sans interprétation.

Ces capacités existent aujourd’hui, mais ne sont pas parfaites. Les modèles de base peuvent halluciner, mal interpréter, ou prendre des décisions erronées apparemment convaincantes. Dans un environnement compétitif et capitalistique (où le code contrôle ou reçoit des actifs), « tenter d’interagir avec un système imprévu » peut signifier une perte financière. L’idée n’est pas que ces agents soient aujourd’hui parfaitement fiables, mais qu’ils peuvent, de manière inédite, tenter des actions que les systèmes traditionnels évitent, et que des infrastructures futures pourraient rendre plus sûres et plus fiables.

Cette différence doit plutôt être vue comme un continuum, et non comme une frontière binaire. Certains systèmes traditionnels intégreront des formes de raisonnement appris, et certains agents s’appuieront sur des règles codées en dur à des points critiques. La distinction est directionnelle, pas absolue. Les systèmes d’agents transféreront davantage de tâches d’interprétation, d’évaluation et d’adaptation à la phase d’exécution, plutôt qu’à la phase de construction. Cela est crucial pour la discussion sur la friction, car ce que tentent de réaliser ces agents, c’est précisément ce que les algorithmes traditionnels évitent : en construisant une sélection de contrats à l’avance, ils évitent la friction ; en utilisant des listes blanches maintenues par des opérateurs, ils évitent la friction de contrôle ; en utilisant des parseurs prévus pour des protocoles connus, ils évitent la friction de données ; en opérant dans des limites de sécurité prédéfinies, ils évitent la friction d’exécution. La phase de construction est déléguée à l’humain, qui effectue le travail sémantique, de confiance et de stratégie, tandis que l’algorithme exécute dans un cadre défini. Peut-être que dans les premiers agents on retrouvera ce modèle, mais la valeur centrale des agents réside dans leur capacité à transférer la découverte, la confiance et l’évaluation stratégique à la phase d’inférence en temps réel, plutôt qu’à la phase de construction.

Ils tenteront de découvrir et d’évaluer des opportunités inconnues, d’inférer la conformité sans règles codées, d’interpréter des états hétérogènes sans parseurs prédéfinis, et d’appliquer des contraintes stratégiques face à des objectifs flous. La friction n’est pas due à une difficulté accrue à faire ce que font les algorithmes, mais parce qu’ils tentent de faire des choses radicalement différentes : fonctionner dans un espace d’action ouvert, dynamique, en interprétant en continu, plutôt que dans un système fermé, préintégré.

Friction

Sur le plan structurel, cette contradiction ne provient pas d’un défaut du consensus blockchain, mais de la façon dont l’ensemble de la pile d’interaction, construite autour, fonctionne.

La blockchain garantit la détermination de l’état, le consensus sur l’état final, et la certitude ultime. Elle ne tente pas d’intégrer dans le protocole une interprétation sémantique, la vérification d’intentions ou le suivi d’objectifs. Ces responsabilités ont toujours été déléguées à l’interface frontale, au portefeuille, aux indexeurs et à d’autres couches hors chaîne, où une intervention humaine est nécessaire.

Même pour les acteurs expérimentés, le mode d’interaction dominant reflète cette conception. Les particuliers interprètent l’état via un tableau de bord, choisissent des opérations via une interface, signent des transactions avec leur portefeuille, sans validation formelle du résultat. Les institutions de trading algorithmique automatisent l’exécution, mais dépendent encore d’opérateurs humains pour filtrer les protocoles, vérifier les anomalies, et mettre à jour les intégrations en cas de changement d’interface. Dans ces deux cas, le protocole ne garantit que la correction de l’exécution, tandis que l’interprétation de l’intention, la gestion des anomalies et l’adaptation aux nouvelles opportunités sont assurées par l’humain.

Les systèmes d’agents condensent ou éliminent même cette division. Ils doivent, de manière programmatique, reconstruire un état à signification économique, évaluer la progression vers l’objectif, et vérifier la réussite de l’exécution, plutôt que de simplement confirmer la transaction sur la chaîne. Sur la blockchain, cette charge est encore plus critique : les agents évoluent dans un environnement ouvert, adversarial, en rapide changement, où de nouveaux contrats, actifs et chemins d’exécution peuvent apparaître sans validation centralisée. Les protocoles garantissent uniquement la correcte exécution des transactions, pas la facilité d’interprétation de l’état économique, la conformité des contrats, ou la programmabilité des opportunités.

Nous examinerons ci-après chaque étape du cycle de fonctionnement des agents pour identifier ces frictions : découverte de contrats et opportunités, vérification de leur légitimité, lecture d’états à signification économique, et exécution autour d’objectifs.

Friction de découverte

Elle naît du fait que l’espace de la finance décentralisée s’ouvre et s’étend dans un environnement sans permission, où la pertinence et la légitimité sont filtrées par l’humain via la socialisation, le marché et les outils hors chaîne. De nouveaux protocoles émergent par annonces, mais aussi par intégration frontale, listes de tokens, plateformes d’analyse de données et de liquidité. Au fil du temps, ces signaux forment souvent une norme informelle permettant de distinguer les parties de l’espace qui ont une valeur économique et une crédibilité suffisante, même si ce consensus est non officiel, asymétrique, et dépend en partie de tiers et de filtrages manuels.

Les agents peuvent recevoir des données et des signaux de confiance filtrés, mais ils ne disposent pas de l’intuition humaine pour leur interprétation. Sur la chaîne, tous les contrats déployés sont également découvrables. Les contrats légitimes, les forks malveillants, les déploiements de test ou abandonnés existent sous forme de bytecode accessible. La blockchain ne code pas quels contrats sont importants ou sécurisés.

Par conséquent, les agents doivent construire leur propre mécanisme de découverte : scanner les événements de déploiement, reconnaître des modèles d’interface, suivre les contrats-factory (qui peuvent déployer d’autres contrats programmables), et surveiller la formation de liquidité pour déterminer quels contrats doivent entrer dans leur espace décisionnel. Ce processus ne consiste pas seulement à rechercher des contrats, mais aussi à juger s’ils doivent faire partie de l’espace d’action de l’agent.

Identifier une cible n’est que la première étape. Après une détection initiale, le contrat doit encore passer par une étape de validation de conformité et de véracité, décrite ci-après. L’agent doit d’abord confirmer que le contrat découvert est authentique, avant de l’intégrer dans son espace décisionnel.

La friction de découverte ne concerne pas la détection d’un comportement de déploiement nouveau. Des systèmes algorithmiques avancés peuvent déjà faire cela dans leur propre cadre stratégique. Surveiller les événements d’un factory Uniswap et intégrer automatiquement de nouveaux pools est une découverte dynamique. La friction apparaît à deux niveaux supérieurs : juger si le contrat découvert est légitime, et déterminer s’il est pertinent par rapport à l’objectif ouvert, plutôt que de simplement faire correspondre un modèle prédéfini.

La logique de découverte du chercheur est étroitement liée à sa stratégie. Il sait quels modèles d’interface rechercher, car sa stratégie est définie. Mais pour une IA qui doit « configurer la meilleure opportunité après ajustement du risque », elle ne peut pas simplement se baser sur un filtre stratégique. Elle doit évaluer l’opportunité rencontrée en fonction de l’objectif lui-même, ce qui implique de parser des interfaces inconnues, d’inférer la fonction économique, et de juger si cette opportunité doit entrer dans l’espace décisionnel. C’est en partie une problématique d’autonomie générale, mais la blockchain l’amplifie.

Friction au niveau du contrôle

Elle naît du fait que la vérification de l’identité et de la légitimité se fait souvent hors protocole, en s’appuyant sur la filtration, la gouvernance, la documentation, les interfaces et le jugement de l’opérateur. Dans de nombreux workflows actuels, l’humain reste une étape clé. La blockchain garantit la détermination de l’exécution et la certitude finale, mais ne garantit pas que l’appelant interagit avec le bon contrat. Cette vérification d’intention est externalisée dans le contexte social, sur le site web ou via une sélection manuelle.

Dans le processus actuel, l’humain utilise la couche de confiance du site web comme une vérification informelle. Il consulte un domaine officiel (souvent via des plateformes comme DeFiLlama ou des comptes sociaux certifiés), et considère ce site comme une cartographie standard entre concept humain et adresse de contrat. Ensuite, l’interface frontale forme une référence de confiance, précisant quelles adresses sont officielles, quels tokens utiliser, et quels points d’entrée sont sûrs.

Le Turc mécanique de 1789 était une machine à jouer aux échecs, qui semblait autonome mais reposait en réalité sur un opérateur caché.

Les agents ne peuvent pas interpréter directement la marque, la certification ou la « légitimité officielle » via le contexte social. On peut leur fournir des données filtrées issues de ces signaux, mais pour en faire une hypothèse de confiance machine durable, il faut des registres, des stratégies ou des logiques de vérification explicites. On peut leur fournir une liste blanche d’opérateurs, d’adresses certifiées, ou de stratégies de confiance. Le problème n’est pas qu’il soit impossible d’accéder à ces signaux sociaux, mais que leur maintien dans un espace d’action en expansion rapide est coûteux, et que leur absence ou leur imperfection prive l’agent d’un mécanisme de vérification de secours, que l’humain utilise par défaut.

Des systèmes d’agents sur la chaîne ont déjà montré des conséquences concrètes d’un affaiblissement de la confiance. Par exemple, le cas du crypto-influenceur Orangie, qui aurait déposé des fonds dans un contrat honeypot, ou celui de Lobstar Wilde, qui, en raison d’un bug ou d’un contexte défaillant, a transféré un gros solde de tokens à un « mendiant » en ligne. Ces exemples ne sont pas centraux, mais illustrent comment une erreur dans la vérification de confiance, la lecture d’état ou la stratégie d’exécution peut entraîner des pertes financières.

Le problème ne réside pas dans la difficulté à découvrir les contrats, mais dans l’absence d’un concept natif de « contrat officiel » d’une application sur la blockchain. Cette absence est en partie inhérente à la nature sans permission, plutôt qu’à une erreur de conception, mais elle complique la collaboration autonome. Elle provient en partie d’un faible standard d’identification, d’un système d’enregistrement, de stratégies de crédit encore immature. Un agent interagissant avec Aave v3 doit juger quels adresses sont standards, si elles sont immuables, si elles peuvent être mises à jour via un proxy, ou si elles sont en cours de gouvernance.

Les humains résolvent cette problématique via la documentation, l’interface frontale et les médias sociaux. Les agents doivent, eux, vérifier :

Les modes de gestion et les verrouillages temporels

Les paramètres de gouvernance et de mise à jour

Les correspondances avec des déploiements connus (bytecode, API)

En l’absence d’un registre standard, la « légitimité » devient une problématique de raisonnement. Les agents ne peuvent pas considérer une adresse comme une configuration statique. Ils doivent soit maintenir une liste blanche vérifiable en continu, soit la déduire dynamiquement via des contrôles proxy et une surveillance de gouvernance, ou risquer d’interagir avec des contrats abandonnés, compromis ou contrefaits. Dans les logiciels et infrastructures classiques, l’identité d’un service est souvent maintenue par un espace de noms, des certificats ou des contrôles d’accès gérés par une institution. Sur la chaîne, un contrat peut être appelé et fonctionner, mais ne pas avoir de légitimité économique ou commerciale intrinsèque.

La véracité des tokens et leurs métadonnées pose un problème similaire. Un token peut sembler s’auto-décrire, mais ses métadonnées ne sont pas officielles, seulement des données renvoyées par le code. Par exemple, le contrat WETH définit explicitement le nom, le symbole et la précision, mais n’est pas une preuve d’identité unique. En réalité, il existe près de 200 tokens sur Ethereum portant le nom « Wrapped Ether », avec le symbole « WETH » et une précision de 18 décimales. Sans consulter CoinGecko ou Etherscan, comment distinguer le WETH standard d’une copie ?

Les agents font face à cette situation. La blockchain ne vérifie pas l’unicité, ne se réfère à aucun registre, et n’impose aucune restriction. Vous pouvez déployer 500 contrats identiques en métadonnées. Il existe des méthodes de détection approximative (par exemple, vérifier si le solde ETH correspond à la supply, ou si la liquidité sur des DEX majeurs est cohérente), mais aucune ne garantit l’authenticité. Chaque méthode dépend d’hypothèses de seuil ou de vérifications récursives d’autres contrats.

Comme dans un labyrinthe, pour trouver le « vrai » chemin, il faut une guidance extérieure. La blockchain n’a pas de signal natif de standardisation.

C’est la raison pour laquelle existent des listes de tokens et des registres hors chaîne. Ils offrent une façon de faire correspondre « WETH » à une adresse spécifique, ce qui explique aussi pourquoi les portefeuilles et interfaces maintiennent des listes blanches ou dépendent de plateformes d’agrégation de confiance. Pour les agents, le problème central n’est pas seulement la crédibilité faible des métadonnées, mais aussi que l’identité standard est souvent établie par des signaux sociaux ou institutionnels, et non par le protocole lui-même. Un identifiant fiable sur la chaîne est une adresse de contrat, mais faire correspondre une intention humaine comme « échanger contre USDC » à la bonne adresse dépend encore fortement de filtres, registres, listes blanches ou autres couches de confiance hors chaîne.

Friction des données

Pour un agent, la standardisation de chaque opportunité en objets économiques — rendement, profondeur de liquidité, paramètres de risque, structure de frais, sources d’oracles — est une étape essentielle. D’un point de vue systémique, c’est une problématique d’intégration classique. Mais sur la blockchain, l’hétérogénéité des protocoles, l’exposition directe au capital, la multiplication des appels d’état, et l’absence d’un modèle économique unifié, compliquent cette tâche. Ces éléments sont pourtant fondamentaux pour comparer des opportunités, simuler des répartitions, ou surveiller des risques.

La blockchain ne fournit généralement pas d’objets économiques standardisés au niveau du protocole. Elle expose des slots de stockage, des logs d’événements, et des résultats de fonctions, mais c’est à partir de ces données qu’il faut déduire ou reconstruire les objets économiques. Le protocole garantit uniquement que l’appel de contrat retourne des valeurs correctes, pas que ces valeurs soient facilement interprétables comme des concepts économiques, ni qu’on puisse retrouver ces concepts de manière cohérente à travers différents protocoles.

Ainsi, des notions comme marché, position, coefficient de santé ne sont pas des primitives du protocole. Elles sont reconstruites hors chaîne par des indexeurs, des plateformes d’analyse, des interfaces frontales et des API, qui transforment des états hétérogènes en abstractions utilisables. Les utilisateurs humains ne voient généralement que cette couche standardisée. Les agents peuvent aussi l’utiliser, mais ils hériteront alors de modèles tiers, de latences et de suppositions de confiance ; sinon, ils doivent reconstruire eux-mêmes ces abstractions.

Ce problème devient de plus en plus aigu dans divers protocoles. La valeur des parts dans un vault, le taux de collatéral dans un marché de prêt, la profondeur de liquidité d’un pool DEX, ou le taux de récompense d’un contrat de staking, sont tous des composants fondamentaux à valeur économique, mais sans interface standardisée. Chaque protocole a ses propres méthodes d’accès, sa structure, ses conventions d’unité. Même dans une même catégorie, il existe des différences.

Exemple : le marché de prêt — fragmentation dans la recherche

Le marché de prêt illustre bien cette problématique. Ses concepts économiques sont généralement unifiés : liquidité de dépôt et d’emprunt, taux d’intérêt, ratio de collatéral, limite de crédit, seuil de liquidation, etc. Mais leur accès diffère considérablement.

Dans Aave v3, l’énumération des réserves et la récupération de l’état de réserve sont deux étapes distinctes. Le processus typique est :

Lister les réserves via une requête qui retourne un tableau d’adresses de tokens.

Pour chaque réserve, récupérer via une autre requête des données de base sur la liquidité et le taux d’intérêt,

Cette méthode retourne une structure contenant la liquidité totale, un indice de taux, et des flags de configuration, par exemple :

En revanche, dans Compound v3, chaque déploiement correspond à un seul marché (USDC, USDT, ETH, etc.), sans structure de réserve unifiée. Il faut plutôt faire plusieurs appels pour assembler une vue d’ensemble :

Utilisation de base

Total

Taux d’intérêt

Configuration de l’actif en garantie

Paramètres globaux

Chaque appel ne retourne qu’un sous-ensemble de l’état économique. Le « marché » n’est pas un objet de premier niveau, mais une structure déduite par concaténation.

Du point de vue de l’agent, ces deux protocoles sont tous deux des marchés de prêt ; mais d’un point de vue d’intégration, ils sont totalement différents. Il n’existe pas de modèle commun. L’agent doit donc utiliser des méthodes d’énumération d’actifs différentes, en multipliant les appels pour reconstituer l’état.

Fragmentation : risques de latence et d’incohérence

Au-delà de la différence de structure, cette fragmentation introduit aussi des risques de latence et d’incohérence. Comme l’état économique n’est pas exposé sous une forme atomique unique, l’agent doit faire plusieurs appels distants pour reconstituer une image cohérente. Chaque appel supplémentaire augmente la latence, le risque de limitation, et la probabilité d’incohérence entre le bloc et l’état perçu. En environnement volatile, le taux d’intérêt peut avoir changé entre la lecture et l’utilisation. Si l’on ne verrouille pas explicitement le bloc, la configuration peut ne pas correspondre à la même hauteur de bloc que la liquidité. Les interfaces utilisateur et les backends agrégateurs tentent d’atténuer ces problèmes par cache et par agrégation. Les agents utilisant directement des RPC doivent gérer explicitement la synchronisation, le batching et la cohérence temporelle. La recherche de données économiques non standardisées, même si elle est partiellement automatisée, limite la performance, la synchronisation et la fiabilité.

Faible correspondance des flux de données

L’accès à l’état économique sur la blockchain est essentiellement un mode pull, même si les signaux d’exécution peuvent être streamés. Les systèmes externes interrogent les nœuds pour obtenir l’état, plutôt que de recevoir des mises à jour continues et structurées. Ce mode reflète la fonction fondamentale de la blockchain : vérification à la demande, plutôt que maintien d’une vue d’état persistante au niveau applicatif.

Il existe des primitives push. Les abonnements WebSocket peuvent transmettre en temps réel les nouveaux blocs et logs, mais ces derniers ne contiennent pas la majorité des états économiques, sauf si le protocole choisit explicitement de publier en redondance. Les agents ne peuvent pas directement s’abonner pour suivre l’utilisation, la réserve ou la santé d’un marché de prêt. Ces valeurs sont stockées dans la mémoire du contrat, et la plupart des protocoles ne proposent pas de mécanisme natif pour pousser ces informations en aval. La meilleure pratique consiste à s’abonner aux nouveaux blocs, puis à relancer la lecture à chaque bloc. Les logs ne font que signaler que l’état a changé, mais ne codent pas l’état économique final ; il faut encore le reconstruire en lisant explicitement l’historique.

Les agents pourraient bénéficier d’un flux inverse. Au lieu de faire du polling sur des centaines de contrats, ils pourraient recevoir des mises à jour structurées, pré-calculées, directement poussées dans leur environnement d’exécution. La poussée permettrait de réduire la redondance des requêtes, de diminuer le délai entre changement d’état et perception, et de permettre à une couche intermédiaire d’emballer ces changements en une mise à jour sémantiquement claire, plutôt que de devoir les interpréter à partir de données brutes.

Ce changement n’est pas trivial. Il nécessite une infrastructure d’abonnement, une logique de filtrage, et un mode de transformation des changements de stockage en événements économiques exploitables par l’agent. Mais à mesure que les agents deviennent des participants permanents plutôt que des interrogateurs ponctuels, le coût de la méthode pull devient prohibitif. Considérer l’agent comme un consommateur continu, plutôt qu’un client sporadique, pourrait mieux correspondre à leur mode de fonctionnement.

L’infrastructure push est-elle vraiment meilleure ? La question reste ouverte. La masse de changements d’état pose un défi de filtrage, et l’agent doit encore juger de la pertinence de chaque changement, ce qui réintroduit une sémantique de type pull. Le problème n’est pas la nature du mode pull, mais la conception actuelle qui n’intègre pas la persistance pour les consommateurs machine. Avec l’expansion de l’usage des agents, il pourrait être pertinent d’explorer d’autres modèles alternatifs.

Friction d’exécution

Elle naît du fait que de nombreux niveaux d’interaction actuels intègrent la conversion d’intention, la vérification de transaction et la validation des résultats dans des workflows centrés sur l’interface frontale, le portefeuille et la supervision humaine. Dans les scénarios de particuliers ou de décisions subjectives, cette supervision est encore assurée par l’humain. Pour les systèmes autonomes, ces fonctions doivent être formalisées et codées directement. La blockchain garantit l’exécution déterministe selon la logique du contrat, mais ne garantit pas que la transaction corresponde à l’intention de l’utilisateur, respecte les contraintes de risque ou atteigne le résultat économique attendu. Dans le workflow actuel, l’interface utilisateur et l’humain comblent cette lacune.

Les séquences d’opérations via l’interface utilisateur (échange, autorisation, dépôt, prêt, staking), la signature finale par le portefeuille, et la décision stratégique informelle de l’opérateur, sont souvent effectuées dans la dernière étape. La plupart du temps, ils jugent la sécurité ou la qualité de l’offre en l’état, avec des informations incomplètes. En cas d’échec ou d’anomalie, ils réessaient, ajustent le slippage, changent de route, ou abandonnent. Les agents éliminent cette boucle humaine. Cela implique que le système doit, en mode machine, remplacer ces trois fonctions :

Intégration de l’intention. Par exemple, « transférer mes stablecoins vers la meilleure plateforme de rendement ajustée au risque » doit être traduit en un plan d’action précis : choisir le protocole, le marché, la route de tokens, la taille, les autorisations, et l’ordre d’exécution. Pour l’humain, cela se fait implicitement via l’interface ; pour l’agent, cela doit être formalisé.

Exécution stratégique. Cliquer sur « Envoyer » ne se limite pas à signer, mais inclut implicitement la vérification que la transaction respecte les contraintes : tolérance au slippage, limite de levier, seuil de santé, whitelist, ou interdiction d’interagir avec des contrats upgradables. L’agent doit encoder ces contraintes en règles vérifiables par la machine :

Le système doit vérifier que le graphe d’appels proposé respecte ces règles avant de le diffuser.

Vérification du résultat. La transaction sur la chaîne ne signifie pas que la tâche est accomplie. La réussite de l’exécution ne garantit pas l’atteinte de l’objectif : le slippage peut dépasser la tolérance, la position peut ne pas atteindre la taille souhaitée à cause d’une limite, ou le taux peut avoir changé entre la simulation et la mise en œuvre. L’humain vérifie cela a posteriori via l’interface. L’agent doit pouvoir évaluer ces conditions en mode programmatique.

Cela introduit une exigence de vérification de l’achèvement, pas seulement de la transaction. Une architecture centrée sur l’intention peut, en déléguant une partie du « comment » à un solveur dédié, réduire cette charge. En diffusant une intention signée plutôt que la donnée brute de la transaction, l’agent peut spécifier des contraintes basées sur le résultat, que le solveur ou le protocole doit satisfaire pour que l’exécution soit acceptable.

Flux de travail multi-étapes et modes de défaillance

La majorité des opérations en DeFi sont intrinsèquement multi-étapes. Une allocation de rendement peut nécessiter autorisation → échange → dépôt → prêt → staking. Certaines étapes peuvent être séparées en transactions distinctes, d’autres peuvent être regroupées via des contrats de routage. L’humain tolère une certaine complétude, puis revient à l’interface pour continuer. L’agent doit orchestrer de manière déterministe : si une étape échoue, il doit décider de réessayer, de rerouter, de revenir en arrière ou de suspendre.

Cela engendre de nouveaux modes de défaillance masqués dans le processus humain :

Décalage d’état entre décision et mise en chaîne. Entre simulation et exécution, le taux, l’utilisation ou la liquidité peuvent changer. L’humain accepte cette variabilité ; l’agent doit la limiter à une plage acceptable et l’appliquer.

Exécution non atomique et résultats partiels. Certaines opérations peuvent s’étaler sur plusieurs transactions, ou produire des résultats partiels. L’agent doit suivre l’état intermédiaire, et vérifier que l’état final correspond à l’objectif.

Risques liés aux limites d’autorisation et d’approbation. L’humain signe implicitement des autorisations via l’interface ; l’agent doit raisonner sur la portée (montant, utilisateur, durée) comme une stratégie de sécurité, et pas seulement comme une étape d’interface.

Choix de route et coûts implicites. L’humain dépend des contrats de routage et des réglages par défaut. L’agent doit intégrer le slippage, le risque de valeur maximale, le coût en gas, et l’impact sur le prix dans sa fonction objectif.

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

Le cœur de la friction d’exécution est que la couche d’interaction décentralisée repose encore largement sur la signature du portefeuille humain comme contrôle ultime. Cette étape porte la vérification d’intention, la tolérance au risque, et la validation informelle du « c’est raisonnable ». En supprimant l’humain, l’exécution devient un problème de contrôle : l’agent doit transformer l’objectif en un comportement, appliquer automatiquement des contraintes stratégiques, et vérifier le résultat dans un environnement incertain. Ce défi est commun à de nombreux systèmes autonomes, mais la blockchain est particulièrement exigeante : l’exécution implique du capital, des contrats inconnus, et est exposée à des états adversariaux. L’humain prend des décisions heuristiques, et corrige par essais et erreurs. L’agent doit faire la même chose à la vitesse machine, souvent dans un espace d’action dynamique. Dire que « l’agent ne fait que soumettre une transaction » sous-estime la difficulté. La soumission n’est que la partie la plus simple.

Conclusion

La blockchain n’a pas été conçue à l’origine pour fournir nativement une couche sémantique et de coordination pour les agents. Son objectif est de garantir la détermination de l’état et le consensus en environnement adversarial. La couche d’interaction qui en découle s’est construite autour d’un modèle où l’humain interprète l’état, choisit des opérations via une interface, et vérifie manuellement les résultats.

Les agents bouleversent cette architecture. Ils suppriment l’humain comme interprète, approbateur et vérificateur, en exigeant que ces fonctions soient directement codées en machine. Ce changement révèle quatre types de frictions structurelles : découverte, crédibilité, accès aux données, et processus d’exécution. Ces frictions ne proviennent pas d’une impossibilité d’exécution, mais du fait que la majorité des infrastructures autour de la blockchain supposent encore une intervention humaine entre l’état et l’action.

Combler ces écarts nécessitera probablement la mise en place d’infrastructures multi-couches : normaliser l’état économique inter-protocoles en une couche intermédiaire machine-lisible ; développer des indexeurs ou des API pour les primitives sémantiques comme position, coefficient de santé, opportunités ; créer des registres pour la correspondance d’adresses et la vérification de tokens ; et coder des cadres pour la gestion de stratégies, le traitement de workflows multi-étapes, et la validation programmatique de l’atteinte d’objectifs. Certains de ces écarts sont liés à la nature sans permission, à la faiblesse des identifiants standard, à l’hétérogénéité des interfaces. D’autres dépendent des outils, standards et incitations actuels, qui devraient s’améliorer à mesure que l’usage des agents s’étendra, et que les protocoles optimiseront leur intégration pour l’autonomie.

À mesure que les systèmes autonomes commenceront à gérer du capital, exécuter des stratégies, et interagir directement avec les applications chainées, la conception actuelle de la couche d’interaction deviendra de plus en plus problématique. La majorité des frictions décrites reflète la conception des outils et des modes d’interaction centrés sur le travail humain ; d’autres proviennent de la nature ouverte, hétérogène et adversariale de l’environnement sans permission ; et une dernière partie concerne des problématiques universelles des systèmes autonomes dans des environnements complexes.