Les Agents IA ont été trop médiatisés ces deux dernières années.
Beaucoup de projets commencent en disant qu'à l'avenir, l'IA peut analyser le marché, élaborer des stratégies, gérer des actifs et exécuter des opérations sur la chaîne. Ça a l'air super pratique, voire un peu séduisant.
Mais maintenant que j'entends ce genre de discours, ma première réaction est plutôt d'être plus prudent.
Parce qu'une fois que l'Agent commence à toucher aux actifs sur la chaîne, le problème change immédiatement.
Ce n'est plus juste une boîte de dialogue, et ce n'est plus seulement un outil de conseils. Une fois qu'il entre dans le portefeuille, les échanges inter-chaînes, les appels de contrats, les chemins de trading et l'exécution de stratégies, ce qui est vraiment important n'est pas à quel point il répond intelligemment, mais ce qu'il est réellement autorisé à faire.
La question des limites d’autorisation est, bien souvent, plus cruciale que l’intelligence elle-même.
Quand je faisais des produits financiers Web2, j’étais très marqué par les systèmes d’autorisations. Un back-office interne, qui ressemble à quelques boutons, derrière lesquels il y a en réalité des tables d’autorisations. Qui peut voir les données, qui peut modifier les plafonds, qui peut approuver, qui peut transférer l’argent, et qui peut seulement consulter sans agir : tout cela doit être décomposé très finement.
Si le design des autorisations est approximatif, même une interface front-end très jolie ne sert à rien.
En cas de vrai problème, la question ne s’arrêtera pas à « l’expérience n’est pas bonne ». Elle deviendra : qui a accordé l’autorisation, qui a opéré, quelle étape a fait un dépassement de droits, et pourquoi aucun garde-fou n’a empêché cela.
Le monde on-chain est encore plus exagéré.
Une autorisation, une signature, un pont inter-chaînes, une interaction avec un contrat : tout cela peut entraîner de vrais changements d’actifs. Une fois beaucoup d’actions effectuées, il est difficile de tout retirer aussi simplement que dans l’arrière-guichet de Web2.
Donc, aujourd’hui, en regardant les @OpenLedger d’OctoClaw et de Trading Agent, ce qui m’importe le plus n’est pas s’ils peuvent aider les utilisateurs à gagner du temps, mais s’ils peuvent traiter clairement ces trois éléments : autorisations, exécution et enregistrements.
Dans les sujets recommandés par l’officialité, il est mentionné OctoClaw, Trading Agent, cloud config, EVM Bridge et l’intégration ERC-4626. Mis ensemble, ils pointent tous vers la même direction : un AI Agent n’est pas seulement là pour discuter, il doit entrer dans des workflows on-chain plus concrets.
Dès que cette condition est remplie, le système d’autorisations devient la fondation.
Quand l’utilisateur dit : « aide-moi à optimiser ma stratégie », cette phrase, en elle-même, est trop vague.
Un agent peut-il vraiment mobiliser des fonds ?
Peut-il faire du cross-chain ?
Peut-il appeler un contrat ?
Peut-il accéder à un certain vault ?
Peut-on mettre l’agent en pause en cas de marché extrêmement volatil ?
Chaque étape doit être décomposée en autorisations précises, au lieu d’accorder un énorme paquet d’autorisations.
C’est aussi, selon moi, pour cela que la capacité d’OpenLedger à enregistrer on-chain mérite d’être observée.
Dans la documentation officielle d’OpenLedger, il est souligné que son système conservera des traces centrées sur les données, le modèle, l’appel d’inférence, l’attribution de la contribution et la gouvernance. La whitepaper mentionne aussi que les modèles peuvent être connectés via des APIs et des Agent Frameworks, devenant des moteurs de décision dans des applications décentralisées.
Cela montre qu’il veut traiter non pas un outil isolé, mais tout un ensemble de relations d’enregistrement une fois que l’IA entre dans une application.
Si un agent participe vraiment à l’exécution on-chain à l’avenir, il faut au moins répondre à quelques questions.
D’abord, quel modèle appelle-t-il ?
Deuxième : quelles données ou signaux a-t-il utilisés ?
Troisième : selon quelles règles génère-t-il des actions ?
Quatrième : à quel moment, à quelle étape l’utilisateur accorde-t-il l’autorisation ?
Cinquième : le résultat d’exécution peut-il être reconsulté ?
Si ces problèmes ne sont pas résolus, plus l’agent est « intelligent », plus le risque est élevé.
Parce que le plus effrayant d’un agent en « boîte noire », ce n’est pas qu’il ne fasse pas de choses : c’est que, une fois qu’il a fait quelque chose, tu ne sais pas pourquoi il l’a fait.
Dans un cadre de discussion ordinaire, si l’IA se trompe, tout au plus on lui redemande une fois.
Dans un scénario d’actifs on-chain, si l’IA se sert d’autorisations par erreur, les conséquences peuvent se refléter directement sur le solde.
Donc, j’ai une évaluation de base sur des produits comme Trading Agent : il ne doit pas être emballé comme un outil qui automatise le gain d’argent.
Sa position la plus logique, c’est de rendre plus clairs les processus d’opération complexes, à haute fréquence et sujets aux erreurs, afin que l’utilisateur puisse gérer séparément les règles, l’autorisation, l’exécution et la relecture.
Autrement dit, un bon agent ne devrait pas faire que l’on te confie les clés les yeux fermés.
Un bon agent devrait permettre de savoir quelle clé ouvre quelle porte.
On peut aussi voir ici la place de $OPEN.
D’après la documentation officielle, $OPEN sera utilisé pour le gas, les opérations réseau, l’enregistrement des modèles, les appels d’inférence, l’accès aux services IA, ainsi que le staking et la gouvernance. Dans un contexte d’agent, il pourrait prendre en charge non seulement des frais de transaction, mais aussi des appels de modèles, des historiques d’exécution, l’accès aux services et la participation à la gouvernance.
Cela rend l’usage du $OPEN plus concret que de simples récits habituels.
Mais cela impose aussi une exigence : l’appel réel doit avoir lieu.
Si l’agent ne fait que rester sur une page de promotion, alors ces usages ne sont que des designs sur papier. Ce n’est que lorsque les utilisateurs configurent réellement des tâches via OctoClaw ou des outils similaires, appellent des modèles, déclenchent des opérations on-chain et produisent des historiques d’exécution consultables que le rôle du $OPEN sera visible par le marché.
Donc, aujourd’hui, en regardant @OpenLedger, je vais m’intéresser à plusieurs variables.
OctoClaw prévoit-il de véritables tâches configurées par des utilisateurs dans le futur ?
Les historiques d’exécution de Trading Agent peuvent-ils être clairement affichés ?
Les limites d’autorisation de l’agent sont-elles suffisamment précises pour des actions spécifiques ?
Une fois les modules EVM Bridge et ERC-4626 intégrés, les parcours d’actifs complexes peuvent-ils être gérés en toute sécurité ?
Y a-t-il un usage réel pour l’appel de modèles et les paiements d’inférence ?
Ces indicateurs sont plus importants que de simplement réclamer « AI Agent ».
Au final, pour cette histoire d’AI Agent, ce n’est peut-être pas « qui parle le plus comme un humain » qui compte, mais plutôt qui peut gérer correctement les autorisations, les enregistrements et les responsabilités dans un contexte réel d’actifs.
Si OpenLedger veut vraiment faire entrer l’agent dans un workflow on-chain, il doit d’abord réparer cette porte.
Si la « porte » n’est pas solide, plus on court vite ensuite, plus le risque augmente.