Pourquoi la mise en œuvre des agents intelligents (AI) sur la chaîne de blocs est-elle si difficile ?
TechFlow SélectionTechFlow Sélection
Pourquoi la mise en œuvre des agents intelligents (AI) sur la chaîne de blocs est-elle si difficile ?
La blockchain est conçue pour les machines, mais pas pour les agents intelligents.
Dédié à des analyses Web3 approfondiesAuteur : Zack Pokorny
Traduction : Chopper, Foresight News
L’intégration des agents intelligents sur la blockchain ne se déroule pas sans heurts. Bien que la blockchain soit programmable et sans autorisation préalable, elle manque d’abstraction sémantique et de couche de coordination adaptées aux agents intelligents. Une étude publiée par l’institut de recherche cryptographique Galaxy met en lumière quatre frictions structurelles auxquelles les agents font face sur la chaîne : découverte des opportunités, vérification fiable, lecture des données et exécution des processus. Les infrastructures existantes restent conçues autour de l’interaction humaine et sont donc mal adaptées à la gestion autonome d’actifs ou à l’exécution de stratégies par les IA — ce qui constitue le principal goulot d’étranglement à leur déploiement à grande échelle sur la blockchain. Voici la traduction intégrale du rapport :
Les cas d’usage et les capacités des agents intelligents commencent à évoluer. Ils exécutent désormais des tâches de façon autonome et sont développés pour détenir et allouer du capital, ainsi que pour identifier des stratégies de trading et de rendement. Bien que cette transition expérimentale en soit encore à un stade très précoce, elle marque une rupture radicale avec le modèle antérieur, dans lequel les agents étaient principalement utilisés comme outils sociaux ou analytiques.
La blockchain devient naturellement le terrain d’expérimentation idéal pour cette évolution. Elle est sans autorisation préalable, composable, dotée d’un écosystème d’applications open source, offre un accès égal aux données pour tous les participants, et tous les actifs qu’elle héberge sont, par défaut, programmables.
Cela soulève une question structurelle : si la blockchain est programmable et sans autorisation préalable, 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 le fardeau sémantique et coordonné qu’elle implique. La blockchain garantit la justesse des transitions d’état, mais ne fournit généralement pas d’abstractions natives au niveau protocole — telles que des interprétations économiques, des identités normalisées ou des mécanismes de coordination au niveau des objectifs.
Une partie de ces frictions provient des lacunes architecturales inhérentes aux systèmes sans autorisation préalable ; une autre reflète l’état actuel des outils, de la gestion des contenus et des infrastructures marchandes. En réalité, de nombreuses fonctionnalités de haut niveau continuent de dépendre de logiciels et de workflows dont la conception requiert une intervention humaine.
Architecture blockchain et agents intelligents
La blockchain est conçue autour du consensus et de l’exécution déterministe, non pas autour de l’interprétation sémantique. Elle expose des primitives fondamentales — emplacements de stockage, journaux d’événements, traces d’appel — plutôt que des objets économiques standardisés. Ainsi, des concepts abstraits tels que les positions, les rendements, les coefficients de santé ou la profondeur de liquidité doivent être reconstitués hors chaîne par des indexeurs, des couches d’analyse de données, des interfaces utilisateur et des API, afin de transformer les états spécifiques à chaque protocole en formats plus accessibles.
De nombreux processus financiers décentralisés courants — surtout ceux destinés aux particuliers ou aux décisions subjectives — reposent encore sur un modèle centré sur l’interface utilisateur : l’utilisateur interagit via celle-ci et signe individuellement chaque transaction. Ce modèle centré sur l’interface a permis une expansion à grande échelle grâce à la démocratisation de l’accès aux particuliers, même si une part importante de l’activité sur la chaîne est déjà pilotée par des machines. Le modèle dominant d’interaction pour les particuliers reste aujourd’hui : intention → interface utilisateur → transaction → confirmation. Les opérations automatisées suivent un autre chemin, mais présentent également leurs propres limites : les développeurs sélectionnent, lors de la phase de construction, l’ensemble des contrats et des actifs à utiliser, puis exécutent leurs algorithmes dans ce cadre fixe. Aucun de ces deux modèles ne permet d’adapter dynamiquement, à l’exécution, la découverte, l’évaluation et la composition d’opérations en fonction d’objectifs changeants.
Les frictions apparaissent lorsque des infrastructures optimisées pour la validation des transactions sont utilisées par des systèmes devant simultanément interpréter l’état économique, évaluer la solvabilité et optimiser leur comportement autour d’objectifs explicites. Une partie de cet écart provient des caractéristiques intrinsèques de la blockchain — son caractère sans autorisation préalable et hétérogène — tandis qu’une autre découle du fait que les outils d’interaction sont encore conçus autour de l’audit humain et des intermédiaires frontaux.
Comparaison entre les flux de comportement des agents et les stratégies algorithmiques traditionnelles
Avant d’explorer l’écart entre l’infrastructure blockchain et les systèmes d’agents, il convient de préciser en quoi un flux de comportement doté d’une autonomie intelligente accrue diffère véritablement des systèmes algorithmiques traditionnels sur la chaîne.
Cette différence ne réside ni dans le degré d’automatisation, ni dans la complexité, ni dans la paramétrisation, ni même dans la capacité d’adaptation dynamique. Les systèmes algorithmiques traditionnels peuvent être fortement paramétrés, détecter automatiquement de nouveaux contrats et de nouveaux jetons, allouer des fonds entre divers types de stratégies et rééquilibrer leurs portefeuilles selon les performances. La vraie distinction réside dans la capacité du système à traiter des scénarios imprévus lors de sa conception.
Quel que soit leur degré de complexité, les systèmes algorithmiques traditionnels n’appliquent que de la logique prédéfinie à des motifs prédéfinis. Ils nécessitent des analyseurs d’interfaces préconfigurés pour chaque protocole, une logique d’évaluation prédéfinie pour mapper l’état des contrats vers des significations économiques, des règles explicites pour juger de la solvabilité et de la conformité, ainsi que des règles codées en dur pour chaque branche décisionnelle. Lorsqu’un scénario ne correspond pas à un motif prédéfini, le système l’ignore ou échoue purement et simplement. Il ne peut pas raisonner sur des situations inconnues, mais seulement déterminer si un scénario donné correspond à un modèle connu.
Tout comme ce dispositif mécanique « canard digestif », capable d’imiter des comportements biologiques, mais dont tous les mouvements sont prédéfinis
Un algorithme traditionnel analysant les marchés de prêt DeFi peut identifier de nouveaux contrats déployés qui émettent des événements familiers ou correspondent à des modèles d’usine connus. Mais face à un nouveau composant fondamental de prêt doté d’une interface inconnue, le système est incapable de l’évaluer. Un humain doit alors examiner le contrat, en comprendre le fonctionnement, déterminer s’il représente une opportunité exploitable et rédiger la logique d’intégration. Seulement après cela, l’algorithme pourra interagir avec lui. L’humain interprète ; l’algorithme exécute. Les systèmes d’agents basés sur des modèles fondamentaux transforment cette frontière. Grâce à leurs capacités de raisonnement apprises, ils peuvent :
- Interpréter des objectifs vagues ou incomplètement formulés. Par exemple, une instruction telle que « maximiser le rendement tout en évitant les risques excessifs » exige une interprétation sémantique. Qu’est-ce qu’un « risque excessif » ? Comment équilibrer rendement et risque ? Les algorithmes traditionnels exigent que ces conditions soient définies avec précision à l’avance. Les agents, eux, peuvent interpréter l’intention, prendre des décisions et affiner progressivement leur compréhension à partir des retours.
- S’adapter de façon généralisée à des interfaces inconnues. Les agents peuvent lire le code d’un contrat inconnu, analyser sa documentation ou consulter une interface binaire d’application (ABI) jamais rencontrée auparavant, et en déduire la fonction économique du système. Ils n’ont pas besoin de construire à l’avance des analyseurs spécifiques à chaque protocole. Bien que cette capacité ne soit pas encore parfaite — les agents pouvant mal interpréter ce qu’ils voient — ils peuvent néanmoins tenter d’interagir avec des systèmes non anticipés lors de leur conception.
- Raisonner en présence d’incertitudes concernant la confiance et la conformité. Lorsque les signaux de solvabilité sont flous ou incomplets, les modèles fondamentaux peuvent pondérer probabilistiquement ces signaux, plutôt que d’appliquer aveuglément des règles binaires. Ce contrat intelligent est-il conforme aux normes ? À partir des preuves disponibles, ce jeton est-il légitime ? Les algorithmes traditionnels appliquent soit une règle existante, soit ne peuvent rien faire ; les agents, eux, peuvent raisonner sur leur propre degré de confiance.
- Expliquer les erreurs et s’ajuster. Lorsqu’un événement imprévu survient, les agents peuvent identifier la cause racine du problème et décider de la meilleure réponse. En comparaison, les algorithmes traditionnels se contentent d’exécuter un module de capture d’exceptions, qui transmet uniquement l’information d’erreur, sans interprétation.
Ces capacités existent bien aujourd’hui, mais ne sont pas parfaites. Les modèles fondamentaux peuvent générer des hallucinations, mal interpréter des contenus et prendre des décisions erronées avec une apparence de certitude. Dans un environnement concurrentiel et impliquant du capital — c’est-à-dire où le code peut contrôler ou recevoir des actifs — « tenter d’interagir avec un système non anticipé » peut entraîner des pertes financières. Le point central de cet article n’est pas que les agents soient aujourd’hui capables d’exécuter de façon fiable ces fonctions, mais qu’ils tentent des choses impossibles pour les systèmes traditionnels, et que les infrastructures futures pourront rendre ces tentatives plus sûres et plus fiables.
Cette différence doit plutôt être vue comme un état continu, et non comme une frontière catégorique absolue. Certains systèmes traditionnels intègrent déjà des formes de raisonnement appris ; certains agents peuvent aussi dépendre, sur des chemins critiques, de règles codées en dur. Cette distinction est orientée, non binaire. Les systèmes d’agents déplacent davantage d’interprétation, d’évaluation et d’adaptation vers le raisonnement à l’exécution, plutôt que vers des règles prédéfinies lors de la conception. Cela est crucial pour la discussion sur les frictions, car les systèmes d’agents cherchent précisément à accomplir ce que les algorithmes traditionnels évitent totalement. Ces derniers évitent la friction de découverte en faisant en sorte que les humains filtrent l’ensemble des contrats dès la phase de conception ; ils évitent la friction de contrôle en s’appuyant sur des listes blanches maintenues par des opérateurs ; ils évitent la friction de données en utilisant des analyseurs préconstruits pour des protocoles connus ; ils évitent la friction d’exécution en opérant dans des limites de sécurité prédéfinies. Les humains accomplissent à l’avance le travail sémantique, de solvabilité et stratégique ; les algorithmes exécutent ensuite dans le cadre défini. Les premiers flux de comportement d’agents sur la chaîne pourraient reprendre ce modèle, mais leur valeur fondamentale réside précisément dans le transfert de la découverte, de l’évaluation de la solvabilité et de la stratégie vers le raisonnement à l’exécution, plutôt que vers des règles prédéfinies lors de la conception.
Ils essaieront de découvrir et d’évaluer des opportunités inconnues, raisonneront sur la conformité sans règles codées en dur, interpréteront des états hétérogènes sans analyseurs prédéfinis, et appliqueront des contraintes stratégiques à des objectifs potentiellement flous. La présence de frictions ne signifie pas que les agents accomplissent la même tâche que les algorithmes, mais avec plus de difficulté : ils tentent des choses radicalement différentes — fonctionner dans un espace comportemental ouvert et interprété dynamiquement, plutôt que dans un système fermé et pré-intégré.
Frictions
D’un point de vue structurel, cette contradiction ne provient pas d’un défaut du consensus blockchain, mais du mode de fonctionnement de la pile d’interaction globale qui s’est développée autour de celle-ci.
La blockchain garantit des transitions d’état déterministes, un consensus sur l’état final et une finalité définitive. Elle ne cherche pas à coder au niveau protocole l’interprétation du sens économique, la vérification des intentions ou le suivi des objectifs. Ces responsabilités ont toujours été assumées par les interfaces utilisateur, les portefeuilles, les indexeurs et autres couches de coordination hors chaîne, impliquant invariablement une intervention humaine.
Même pour les participants expérimentés, le modèle d’interaction dominant aujourd’hui illustre clairement cette conception. Les particuliers interprètent l’état via des tableaux de bord, choisissent les opérations via l’interface utilisateur et signent les transactions via leur portefeuille, sans procéder à une vérification formelle des résultats. Les institutions de trading algorithmique automatisent l’exécution, mais dépendent encore d’opérateurs humains pour filtrer les ensembles de protocoles, vérifier les anomalies et mettre à jour la logique d’intégration en cas de changement d’interface. Dans les deux cas, le protocole ne garantit que la justesse de l’exécution, tandis que l’interprétation des intentions, le traitement des anomalies et l’adaptation aux nouvelles opportunités restent entièrement assurés par des humains.
Les systèmes d’agents compressent, voire éliminent, cette division des tâches. Ils doivent reconstituer de façon programmatique des états dotés de sens économique, évaluer la progression vers les objectifs et valider les résultats de l’exécution — et non simplement confirmer le minage des transactions. Sur la blockchain, ces charges sont particulièrement accentuées, car les agents évoluent dans un environnement ouvert, concurrentiel et en constante mutation, où de nouveaux contrats, actifs et chemins d’exécution peuvent apparaître sans aucune approbation centralisée. Le protocole garantit uniquement que les transactions sont correctement exécutées, mais ne garantit pas que l’état économique soit facile à interpréter, que les contrats soient conformes aux normes, que les chemins d’exécution correspondent aux intentions de l’utilisateur, ou que les opportunités puissent être découvertes de façon programmatique.
La suite examine, étape par étape du cycle d’exécution des agents, chacune de ces frictions : découverte des contrats et opportunités existants, vérification de leur légitimité, obtention d’un état doté de sens économique, et exécution d’opérations alignées sur les objectifs.
Friction de découverte
Cette friction naît du fait que l’espace comportemental de la finance décentralisée s’étend librement dans un environnement sans autorisation préalable, tandis que la pertinence et la légitimité sont filtrées par les humains via les couches sociales, marchandes et outillées de la chaîne. Les nouveaux protocoles émergent par annonces officielles, puis passent successivement par des filtres tels que l’intégration frontale, les listes de jetons, les plateformes d’analyse de données et la formation de liquidités. Avec le temps, ces signaux tendent à former un critère pratique permettant de distinguer les parties de l’espace comportemental qui possèdent une valeur économique suffisante et une crédibilité acceptable — bien que ce consensus soit souvent informel, déséquilibré et partiellement tributaire de tiers ou de filtres humains.
Il est possible de fournir aux agents des données filtrées et des signaux de crédibilité, mais ceux-ci ne disposent pas des raccourcis intuitifs utilisés par les humains pour interpréter ces signaux. Du point de vue de la chaîne, tous les contrats déployés sont également « découvrables ». Protocoles légitimes, fourches malveillantes, déploiements de test et projets abandonnés coexistent sous forme de bytecode appelable. La blockchain elle-même ne code aucune information sur l’importance ou la sécurité de tels contrats.
Les agents doivent donc construire leurs propres mécanismes de découverte : scanner les événements de déploiement, identifier les motifs d’interface, suivre les contrats-usines (c’est-à-dire les contrats capables de déployer d’autres contrats de façon programmatique) et surveiller la formation de liquidités afin de déterminer quels contrats doivent entrer dans leur espace décisionnel. Ce processus ne consiste pas seulement à trouver des contrats, mais à juger s’ils doivent ou non faire partie de l’espace comportemental de l’agent.
L’identification d’un candidat n’est que la première étape. Une fois passé le premier filtre de découverte, le contrat doit subir le processus de vérification de conformité et d’authenticité décrit dans la section suivante. L’agent doit d’abord confirmer que le contrat trouvé est effectivement ce qu’il prétend être avant de l’intégrer à son espace décisionnel.
La friction de découverte ne concerne pas la simple détection de nouveaux déploiements. Des systèmes algorithmiques matures savent déjà réaliser cela dans le cadre de leurs propres stratégies. Un « searcher » qui surveille les événements émis par l’usine Uniswap et intègre automatiquement les nouveaux pools de liquidité dans ses recherches effectue déjà 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 à des objectifs ouverts, et non simplement compatible avec un type de stratégie prédéfini.
La logique de découverte du « searcher » est étroitement liée à sa stratégie. Il sait quels motifs d’interface rechercher, car sa stratégie l’a déjà défini. En revanche, un agent exécutant une instruction plus large telle que « configurer l’opportunité optimale ajustée au risque » ne peut pas se fier uniquement à des filtres issus de la stratégie. Il doit évaluer chaque nouvelle opportunité rencontrée directement par rapport à l’objectif lui-même — ce qui exige d’analyser des interfaces inconnues, d’en déduire la fonction économique et de décider si cette opportunité doit ou non entrer dans son espace décisionnel. C’est, dans une certaine mesure, un problème d’autonomie universelle, mais la blockchain l’aggrave.
Friction de la couche de contrôle
Cette friction naît du fait que la détermination de l’identité et de la légitimité s’effectue généralement en dehors des protocoles, en combinant des filtres, la gouvernance, la documentation, les interfaces et le jugement des opérateurs. Dans de nombreux workflows actuels, l’humain demeure une pièce essentielle du processus de jugement. La blockchain garantit l’exécution déterministe et la finalité, mais ne garantit pas que l’appelant interagit effectivement avec le contrat cible. Cette détermination des intentions est externalisée vers le contexte social, les sites web et les filtres humains.
Dans les workflows actuels, les humains utilisent la couche de crédibilité des sites web comme moyen de vérification informelle. Ils visitent le domaine officiel (généralement trouvé via des plateformes agrégées comme DeFiLlama ou des comptes sociaux certifiés du projet) et considèrent ce site comme le vecteur standard reliant le concept humain à l’adresse du contrat. Ensuite, l’interface utilisateur établit une base de confiance viable, précisant quelles adresses sont officielles, quels identifiants de jeton utiliser et quels points d’entrée sont sûrs.
Le « Turc mécanique » de 1789 était une machine à jouer aux échecs, apparemment autonome, mais en réalité pilotée par un opérateur humain caché
Par défaut, les agents ne peuvent pas interpréter les marques, les signaux de certification sociale ou la notion d’« officialité » à partir du contexte social. On peut leur fournir des données filtrées issues de ces signaux, mais pour les transformer en hypothèses de crédibilité persistantes exploitables par la machine, il faut des registres explicites, des politiques ou une logique de vérification. On peut configurer les agents avec des listes blanches, des adresses certifiées et des politiques de crédibilité fournies par des opérateurs. Le problème n’est pas qu’il soit impossible d’accéder au contexte social, mais que maintenir ces protections dans un espace comportemental en expansion dynamique est extrêmement coûteux en termes d’opération, et que, lorsqu’elles font défaut ou sont imparfaites, les agents manquent des mécanismes de vérification de secours que les humains utilisent instinctivement.
Des conséquences concrètes liées à la faiblesse des jugements de crédibilité ont déjà été observées dans des systèmes pilotés par des agents sur la chaîne. Dans le cas du blogueur crypto populaire Orangie, des agents auraient apparemment déposé des fonds dans un contrat « piège à abeilles » (honeypot). Dans un autre cas, un agent nommé Lobstar Wilde aurait, en raison d’un dysfonctionnement de l’état ou du contexte, mal interprété l’état d’une adresse et transféré un important solde de jetons à un « mendiant » en ligne. Ces exemples ne constituent pas l’argument central, mais illustrent clairement comment des erreurs de jugement de crédibilité, d’interprétation de l’état ou d’exécution stratégique peuvent conduire directement à des pertes financières.
Le problème ne réside pas dans la difficulté à découvrir les contrats, mais dans le fait que la blockchain ne dispose généralement pas d’un concept natif du type « ceci est le contrat officiel d’une application ». Cette absence est, dans une certaine mesure, une caractéristique inhérente aux systèmes sans autorisation préalable, et non une faille de conception — elle pose toutefois des difficultés de coordination aux systèmes autonomes. Une partie de ce problème provient de l’architecture ouverte et de l’absence de mécanismes d’identification standardisés ; une autre partie vient de l’immaturité des registres, des normes et des mécanismes de distribution de la crédibilité. Un agent tentant d’interagir avec Aave v3 doit par exemple déterminer quelles adresses sont standardes, et si celles-ci sont immuables, mis à jour via un proxy ou actuellement soumises à une modification en cours de gouvernance.
Les humains résolvent ce problème grâce à la documentation, aux interfaces utilisateur et aux médias sociaux. Les agents doivent, quant à eux, évaluer les éléments suivants :
- Le mode proxy et les détails de l’implémentation
- Les droits de gestion et les verrous temporels
- Les modules de mise à jour des paramètres de gouvernance
- La correspondance du bytecode / de l’ABI entre les déploiements connus
En l’absence de registres standardisés, la notion d’« officialité » devient un problème de raisonnement. Cela signifie que les agents ne peuvent pas considérer une adresse de contrat comme une configuration statique. Ils doivent soit maintenir une liste blanche filtrée soumise à une vérification continue, soit redéduire la conformité à l’exécution via des vérifications de proxy et une surveillance de la gouvernance, soit assumer le risque d’interagir avec des contrats obsolètes, corrompus ou usurpés. Dans les logiciels traditionnels et les infrastructures marchandes, l’identité des services est généralement ancrée dans des espaces de noms, des certificats et des contrôles d’accès gérés par des institutions. En revanche, sur la chaîne, un contrat peut être appelable et fonctionner correctement, mais manquer de conformité économique ou métier du point de vue de l’appelant.
L’authenticité des jetons et leurs métadonnées relèvent du même problème. Les jetons semblent pouvoir s’auto-décrire. Pourtant, leurs métadonnées ne possèdent aucune autorité : elles ne sont que des données octets renvoyées par le code. Un exemple classique est l’Ether enveloppé (WETH). Le code du contrat WETH largement utilisé définit explicitement le nom, le symbole et la précision.
Cela semble être une identification, mais ne l’est pas. N’importe quel contrat peut définir :
- symbol() = WETH
- decimals() = 18
- name() = Wrapped Ether
et implémenter la même interface standard ERC-20. Les fonctions name(), symbol() et decimals() ne sont que des fonctions publiques en lecture seule, renvoyant des valeurs arbitraires définies par le déployeur. En effet, il existe près de 200 jetons sur Ethereum dont le nom est « Wrapped Ether », le symbole « WETH » et la précision « 18 ». Sans consulter CoinGecko ou Etherscan, pouvez-vous distinguer quelle version de « WETH » est la version standard ?
C’est précisément la situation dans laquelle se trouvent les agents. La blockchain ne vérifie pas l’unicité, ne compare pas les métadonnées à aucun registre et n’impose aucune restriction. Vous pouvez déployer aujourd’hui 500 contrats, tous renvoyant exactement les mêmes métadonnées. Certains critères heuristiques existent sur la chaîne (par exemple, vérifier la cohérence entre le solde d’Ethereum et l’offre totale, consulter la profondeur de liquidité sur les principales DEX ou vérifier si le jeton est accepté comme collatéral dans des protocoles de prêt), mais aucun ne fournit une preuve absolue. Chaque méthode repose soit sur des hypothèses seuil, soit sur une vérification récursive de la conformité d’autres contrats.
Tout comme trouver le « vrai » chemin dans un labyrinthe nécessite une indication extérieure, la chaîne ne dispose d’aucun signal standard natif
C’est pourquoi les listes de jetons et les registres existent comme couches de filtrage hors chaîne. Elles offrent un moyen d’associer le concept de « WETH » à une adresse spécifique — ce qui explique pourquoi les portefeuilles et les interfaces utilisateur maintiennent des listes blanches ou s’appuient sur des plateformes agrégées fiables. Pour les agents, le problème fondamental ne réside pas seulement dans la faible crédibilité des métadonnées, mais aussi dans le fait que l’identité standard est généralement établie au niveau social ou institutionnel, et non nativement au niveau protocole. L’identifiant fiable sur la chaîne est l’adresse du contrat, mais associer une intention humaine telle que « échanger contre USDC » à l’adresse correcte dépend encore fortement de filtres, de registres, de listes blanches ou d’autres couches de crédibilité non natives au protocole.
Friction des données
Un agent optimisant l’allocation de capitaux entre divers protocoles de finance décentralisée doit standardiser chaque opportunité en tant qu’objet économique : rendement, profondeur de liquidité, paramètres de risque, structure des frais, sources d’oracles, etc. Sous certains aspects, il s’agit d’un problème classique d’intégration système. Toutefois, sur la blockchain, l’hétérogénéité des protocoles, l’exposition directe au capital, la concaténation d’états multi-appel et l’absence fondamentale d’un modèle économique unifié aggravent considérablement cette charge — alors même que ces éléments constituent les fondations indispensables pour comparer les opportunités, simuler les allocations et surveiller les risques.
La blockchain n’expose généralement pas d’objets économiques standardisés au niveau protocole. Elle expose des emplacements de stockage, des journaux d’événements et des sorties de fonctions, à partir desquels les objets économiques doivent être déduits ou reconstitués. Le protocole garantit uniquement que les appels de contrat renvoient les bonnes valeurs d’état, sans garantir que ces valeurs soient clairement interprétables comme des concepts économiques lisibles, ni qu’elles puissent être récupérées via une interface cohérente et transversale.
Ainsi, des concepts abstraits tels que le marché, la position ou le coefficient de santé ne sont pas des primitives protocole. Ils sont reconstitués hors chaîne par des indexeurs, des plateformes d’analyse de données, des interfaces utilisateur et des API, transformant les états hétérogènes des protocoles en abstractions exploitables. Les utilisateurs humains ne voient généralement que cette couche standardisée. Les agents peuvent également utiliser cette couche, mais héritent alors des modèles tiers, des délais et des hypothèses de crédibilité qui y sont associés ; sinon, ils doivent reconstituer eux-mêmes ces abstractions.
Ce problème devient de plus en plus criant dans divers protocoles. Le prix par part des caisses de réserve, le taux de collatéralisation sur les marchés de prêt, la profondeur de liquidité des pools d’échange décentralisés ou le taux de récompense des contrats de staking sont des composants fondamentaux dotés de sens économique, mais aucun ne dispose d’une interface standardisée. Chaque protocole utilise sa propre méthode d’accès, sa propre structure et ses propres conventions d’unités. Même au sein d’une même catégorie, les implémentations divergent.
Marchés de prêt : un exemple emblématique de fragmentation
Les marchés de prêt illustrent clairement ce problème. Leurs concepts économiques sont universels et relativement uniformes — liquidité offerte et empruntée, taux d’intérêt, taux de collatéralisation, plafonds d’emprunt et seuils de liquidation — mais les chemins d’accès varient considérablement.
Sur Aave v3, l’énumération des réserves et la récupération de leur état sont deux étapes indépendantes. Le flux typique est le suivant :
Énumérer les actifs réserves via la méthode ci-dessous, qui renvoie un tableau d’adresses de jetons.
Pour chaque actif, récupérer les données fondamentales sur la liquidité et les taux d’intérêt via un autre extrait de code,
Cette méthode renvoie en un seul appel une structure contenant le volume total de liquidité, l’indice des taux d’intérêt et des indicateurs de configuration, par exemple :
En comparaison, Compound v3 associe chaque déploiement à un marché unique (USDC, USDT, ETH, etc.) et ne propose aucune structure de réserve unifiée. À la place, il faut assembler une « photo instantanée » du marché via plusieurs appels de fonctions :
- Taux d’utilisation de base
- Volume total
- Taux d’intérêt
- Configuration des actifs en collatéral
- Paramètres de configuration globale
Chaque appel ne renvoie qu’un sous-ensemble différent de l’état économique. Le « marché » n’est pas un objet de premier niveau, mais une structure inférée par l’appelant.
Du point de vue de l’agent, les deux protocoles sont des marchés de prêt ; mais du point de vue de l’intégration, ce sont des systèmes de récupération structurellement différents. Aucun modèle partagé et unifié n’existe. L’agent doit donc adopter des méthodes d’énumération d’actifs spécifiques à chaque protocole et assembler l’état via plusieurs appels.
Fragmentation : délais et risques de cohérence
Outre l’incohérence structurelle, cette fragmentation introduit également des délais et des risques de cohérence. Comme l’état économique n’est pas exposé sous la forme d’un objet de marché atomique unique, l’agent doit reconstituer une « photo instantanée » via plusieurs appels de procédure à distance (RPC) traversant plusieurs contrats. Chaque appel supplémentaire augmente le délai, le risque de limitation de débit et la probabilité d’incohérence entre blocs. Dans un environnement volatil, le taux d’intérêt calculé peut avoir changé d’ici la fin du calcul ; sans verrouillage explicite du bloc, les paramètres de configuration peuvent correspondre à une hauteur de bloc différente de celle du volume total de liquidité. Les utilisateurs comptent sur les couches de cache des interfaces utilisateur et les backends agrégés pour atténuer indirectement ces problèmes. Les agents opérant directement sur les RPC bruts doivent gérer explicitement la synchronisation, le regroupement (batching) et la cohérence temporelle. Ainsi, l’absence de standardisation dans la récupération des données nuit non seulement à l’intégration, mais limite aussi les performances, la synchronisation et la justesse.
En l’absence d’un schéma normalisé pour la récupération des données économiques, même des protocoles implémentant des primitives financières presque identiques exposent leur état différemment, selon les détails spécifiques de leur contrat et de leur composition. Cette différence structurelle constitue une composante centrale de la friction des données.
Décalage potentiel des flux de données
L’accès à l’état économique sur la blockchain repose essentiellement sur un modèle « pull » (requête à la demande), même si les signaux d’exécution peuvent être transmis en continu. Les systèmes externes interrogent les nœuds pour obtenir l’état requis, plutôt que de recevoir des mises à jour continues et structurées. Ce modèle reflète la fonction fondamentale de la blockchain : la vérification à la demande, et non le maintien d’une vue continue de l’état au niveau applicatif.
Des primitives « push » (envoi proactif) existent toutefois. Les abonnements WebSocket permettent de diffuser en temps réel les nouveaux blocs et les journaux d’événements, mais ceux-ci ne contiennent pas l’état de stockage — qui porte la majorité du sens économique — sauf si le protocole choisit explicitement de publier ces données de façon redondante. Les agents ne peuvent pas recevoir directement, via un abonnement sur la chaîne, les taux d’utilisation des marchés de prêt, les réserves des pools ou les coefficients de santé des positions. Ces valeurs sont stockées dans le stockage des contrats, et la plupart des protocoles ne fournissent pas de mécanisme natif pour les pousser vers les utilisateurs finaux. La meilleure méthode actuelle consiste à s’abonner aux en-têtes de blocs et à interroger à nouveau chaque bloc. Les journaux ne font que signaler qu’un changement d’état est possible, sans encoder l’état économique final ; sa reconstitution nécessite encore une lecture explicite et un accès à l’état historique.
Les systèmes d’agents pourraient bénéficier d’un flux inversé. Plutôt que d’interroger périodiquement l’état de centaines de contrats, les agents pourraient recevoir des mises à jour d’état structurées et pré-calculées, directement poussées vers leur environnement d’exécution. Une architecture « push » réduirait les requêtes redondantes, diminuerait le délai entre le changement d’état et sa perception par l’agent, et permettrait aux couches intermédiaires d’emballer l’état sous forme de mises à jour sémantiquement explicites, plutôt que de laisser l’agent interpréter le sens à partir du stockage brut.
Cette inversion n’est pas aisée à réaliser. Elle nécessite une infrastructure d’abonnement, une logique de filtrage de la pertinence et un modèle permettant de traduire les modifications de stockage en événements économiques exécutables par les agents. Toutefois, à mesure que les agents deviennent des participants permanents plutôt que des interrogateurs intermittents, le coût de l’inefficacité du modèle « pull » devient de plus en plus élevé. Une infrastructure considérant les agents comme des consommateurs persistants plutôt que comme des clients intermittents serait probablement mieux adaptée au fonctionnement des systèmes autonomes.
La supériorité d’une infrastructure « push » reste une question ouverte. Un volume massif de changements d’état poserait des défis de filtrage, et les agents devraient tout de même déterminer quels changements sont pertinents — ce qui réintroduirait, à un autre niveau, la sémantique du modèle « pull ». L’enjeu n’est pas que l’architecture « pull » soit intrinsèquement défectueuse, mais que sa conception actuelle ne prend pas en compte les consommateurs machines persistants. À mesure que l’adoption des agents s’étendra, il sera sans doute utile d’explorer d’autres modèles alternatifs.
Friction d’exécution
Cette friction naît du fait que de nombreuses couches d’interaction actuelles regroupent la conversion des intentions, l’audit des transactions et la vérification des résultats dans des workflows conçus autour des interfaces utilisateur, des portefeuilles et de la supervision des opérateurs. Dans les scénarios destinés aux particuliers ou aux décisions subjectives, cette supervision est généralement assurée par des humains. 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 produise le résultat économique attendu. Dans les workflows actuels, l’interface utilisateur et l’humain comblent ce vide.
L’interface utilisateur assemble des séquences d’opérations (échange, autorisation, dépôt, emprunt), le portefeuille fournit le nœud final « vérifier et envoyer », tandis que l’utilisateur ou l’opérateur effectue généralement, à la dernière étape, un jugement stratégique informel. Ils évaluent souvent, avec des informations incomplètes, si la transaction est sûre ou si le résultat de l’offre est acceptable. Si la transaction échoue ou produit un résultat inattendu, l’utilisateur réessaie, ajuste le glissement, modifie le chemin ou abandonne purement et simplement l’opération. Les systèmes d’agents retirent l’humain de ce cycle d’exécution. Cela signifie que le système doit remplacer trois fonctions humaines par des équivalents nativement machine :
- L’intégration des intentions. Une intention humaine telle que « transférer mes stablecoins vers le lieu de rendement optimal ajusté au risque » doit être traduite en un plan d’action concret : choix du protocole, du marché, du chemin de jetons, de l’échelle, des autorisations requises et de l’ordre d’exécution. Pour les humains, ce processus est réalisé implicitement via l’interface utilisateur ; pour les agents, il doit être formalisé.
- L’exécution stratégique. Cliquer sur « envoyer la transaction » n’est pas seulement une signature : c’est aussi une vérification implicite que la transaction respecte les contraintes — tolérance au glissement, limite de levier, coefficient de santé minimal, contrats sur liste blanche, ou interdiction des contrats mis à jour par proxy. Les agents doivent coder explicitement ces contraintes stratégiques sous forme de règles vérifiables par machine :
- Le système d’exécution doit vérifier que le graphe d’appels proposé satisfait ces règles avant de diffuser la transaction.
- La vérification des résultats. Le minage d’une transaction ne signifie pas que la tâche est accomplie. Même une exécution réussie peut ne pas atteindre l’objectif : le glissement peut dépasser la tolérance, la taille de la position cible peut ne pas être atteinte en raison d’un plafond, ou le taux d’intérêt peut avoir changé entre la simulation et le minage. Les humains vérifient informellement les résultats en consultant l’interface utilisateur après coup. Les agents doivent évaluer de façon programmatique les conditions postérieures.
Cela introduit une exigence de vérification de complétion, et non plus simplement d’inclusion transactionnelle. Une architecture centrée sur l’intention peut partiellement résoudre ce problème en transférant une plus grande part de la charge « comment exécuter » de l’agent vers des solveurs spécialisés. En diffusant une intention signée plutôt que les données brutes d’appel, l’agent peut spécifier des contraintes basées sur les résultats, que le solveur ou le mécanisme au niveau protocole doit impérativement satisfaire pour que l’exécution soit acceptable.
Workflows multi-étapes et modes de défaillance
La plupart des opérations d’exécution en finance décentralisée sont, par nature, multi-étapes. Une allocation de rendement peut nécessiter une séquence d’autorisation → échange → dépôt → emprunt → staking. Certaines étapes peuvent être des transactions indépendantes, d’autres peuvent être regroupées via des appels multiples ou des contrats de routage. Les humains tolèrent une exécution partielle et reviennent à l’interface utilisateur pour poursuivre le flux. Les agents, eux, exigent un orchestration déterministe : si une étape quelconque échoue, l’agent doit décider de réessayer, de rerouter, de revenir en arrière ou de suspendre l’opération.
Cela donne naissance à de nouveaux modes de défaillance, largement masqués dans les workflows humains :
- La dérive d’état entre la prise de décision et le minage. Entre la simulation et l’exécution, le taux d’intérêt, le taux d’utilisation ou la liquidité peuvent changer. Les humains acceptent cette variabilité ; les agents doivent définir une plage acceptable et l’appliquer de façon stricte.
- L’exécution non atomique et les résultats partiels. Certaines opérations peuvent être exécutées sur plusieurs transactions ou produire des résultats partiels. L’agent doit suivre les états intermédiaires et confirmer que l’état final correspond à l’objectif.
- Les risques liés aux plafonds d’autorisation et à l’approbation. Les humains signent inconsciemment les autorisations via l’interface utilisateur ; les agents doivent intégrer la portée de l’autorisation (montant, bénéficiaire, durée) comme une composante de leur stratégie de sécurité, et non comme une simple étape d’interface.
- Le choix du chemin et les coûts d’exécution implicites. Les humains comptent sur les contrats de routage et les paramètres par défaut de l’interface utilisateur. Les agents doivent intégrer le glissement, le risque de valeur maximale extractible (MEV), le coût en gaz et l’impact sur les prix dans leur fonction-objectif.
L’exécution : un problème de contrôle nativement machine
L’argument central de la friction d’exécution est que la couche d’interaction de la finance décentralisée utilise la signature du portefeuille humain comme plan de contrôle final. Ce point porte actuellement la vérification des intentions, la tolérance au risque et le jugement informel de « raisonnable ou non ». Supprimer l’humain transforme l’exécution en un problème de contrôle : l’agent doit traduire l’objectif en un modèle comportemental, exécuter automatiquement les contraintes stratégiques et vérifier les résultats dans un environnement incertain. Ce défi existe dans de nombreux systèmes autonomes, mais l’environnement blockchain est particulièrement exigeant : l’exécution implique directement du capital, la composition avec des contrats inconnus et l’exposition à des changements d’état adverses. Les humains prennent des décisions heuristiques et corrigent les erreurs par essais et erreurs. Les agents doivent accomplir le même travail à la vitesse de la machine, de façon programmatique, et généralement dans un espace comportemental en constante évolution. Ainsi, l’affirmation selon laquelle « les agents n’ont qu’à soumettre une transaction » sous-estime fortement la difficulté. Soumettre la transaction est la partie la plus simple.
Conclusion
La blockchain n’a pas été conçue initialement pour fournir nativement les couches sémantique et de coordination nécessaires aux agents intelligents. Son objectif était de garantir, dans un environnement concurrentiel, l’exécution déterministe et le consensus sur les transitions d’état. La couche d’interaction bâtie sur cette base a évolué autour du modèle humain : interprétation de l’état via une interface, sélection des opérations via une interface frontale, vérification des résultats via un audit humain.
Les systèmes d’agents bouleversent cette architecture. Ils retirent du cycle l’interprète, l’approbateur et le vérificateur humains, exigeant que ces fonctions soient désormais réalisées de façon native par la machine. Cette transformation révèle, sur quatre dimensions, des frictions structurelles : découverte, jugement de crédibilité, acquisition des données et processus d’exécution. Ces frictions ne proviennent pas de l’impossibilité d’exécuter, mais du fait que l’infrastructure construite autour de la blockchain suppose, dans la plupart des cas, la présence d’un intervenant humain entre l’interprétation de l’état et la soumission de la transaction.
Combler ces écarts exigera probablement la construction d’infrastructures nouvelles à plusieurs niveaux : un middleware normalisant l’état économique transversal aux protocoles pour qu’il soit lisible par la machine ; des services d’indexation ou des extensions d’appel à distance pour des primitives sémantiques telles que les positions, les coefficients de santé ou les ensembles d’opportunités ; des registres fournissant des cartographies standardisées de contrats et des mécanismes de vérification de l’authenticité des jetons ; et des cadres d’exécution codant les contraintes stratégiques, gérant les workflows multi-étapes et vérifiant de façon programmatique la réalisation des objectifs. Une partie de ces écarts provient des caractéristiques structurelles des systèmes sans autorisation préalable : déploiement ouvert, identité standard faible, interfaces hétérogènes. Une autre partie dépend des outils, des normes et des mécanismes d’incitation actuels, et devrait se réduire à mesure que l’adoption des agents s’étendra et que les protocoles rivaliseront pour améliorer leur compatibilité avec les systèmes autonomes.
À mesure que les systèmes autonomes commenceront à gérer du capital, à exécuter des stratégies et à interagir directement avec les applications sur la chaîne, les hypothèses architecturales sous-jacentes à la couche d’interaction actuelle deviendront de plus en plus visibles. La plupart des frictions décrites ici reflètent l’évolution des outils et des modes d’interaction blockchain autour des workflows médiés par les humains ; certaines proviennent de l’ouverture, de l’hétérogénéité et de l’environnement concurrentiel inhérents aux systèmes sans autorisation préalable ; d’autres sont des problèmes universels rencontrés par les systèmes autonomes dans des environnements complexes.
Le défi fondamental ne consiste pas à permettre aux agents de signer des transactions, mais à leur fournir des moyens fiables pour accomplir le travail d’interprétation sémantique, de jugement de crédibilité et d’exécution stratégique — actuellement partagé entre logiciels et jugement humain — entre l’état blockchain et les actions opératoires.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@galaxyhq
