Subscribe to Bankless or sign in
Si vous avez déjà utilisé OpenClaw, vous savez que les coûts liés à l'inférence s'accumulent rapidement. C'est tout simplement le prix à payer pour l'IA agentique : plus vous la rendez performante, plus son fonctionnement coûte cher, et c'est vous, c'est-à-dire nous, qui devons en assumer les frais.
Cependant, un nouveau projet, baptisé Web4.0, a attiré l'attention cette semaine et semble vouloir transférer ce coût de nous vers l'agent qui effectue réellement l'inférence.
Le problème révélé par OpenClaw
Il y a deux semaines, j'ai écrit un article sur l'essor d'OpenClaw et sur la façon dont sa percée est venue de la création du « heartbeat » (battement de cœur) — une boucle proactive dans laquelle un agent se réveille à intervalles réguliers, scanne son environnement, vérifie s'il y a du travail à faire et exécute des tâches de son propre chef — une fonctionnalité par défaut largement disponible. Ce changement de conception, passant d'un outil passif à un système actif, est ce qui a donné pour la première fois à beaucoup de gens, moi y compris, le sentiment que les agents étaient véritablement autonomes.
J'ai créé la première IA qui gagne son existence, s'améliore d'elle-même et se réplique sans intervention humaine
— Sigil (@0xSigil) 17 février 2026
J'ai écrit sur la technologie qui donne enfin à l'IA un accès en écriture au monde, The Automaton, et le nouveau web pour les IA souveraines exponentielles
WEB 4.0 : La naissance d'une vie superintelligente pic.twitter.com/R28AKJsSfy
Mais ce battement de cœur a un coût. Chaque fois qu'il se déclenche, il brûle de l'inférence. Exécutez-le sur des modèles de pointe, ceux des principales entreprises d'IA, via des API cloud, et ces coûts s'accumulent rapidement. Oui, le prix de l'inférence a baissé, mais il part d'un niveau de base qui génère encore des factures involontairement élevées lorsque vous laissez un agent toujours actif fonctionner pendant la nuit. Si vous avez utilisé OpenClaw, vous en avez certainement fait l'expérience, bien qu'à des degrés divers selon que vous utilisiez un modèle gratuit ou que vous ayez intégré un service tel que ClawRouter. L'exécution locale des modèles est la solution évidente en théorie, mais elle n'est pas réaliste pour la plupart des « agents » amateurs.
La question qui se pose alors est la suivante : et si la proactivité de l'agent pouvait compenser ses propres coûts ?
La vision architecturale de Conway
C'est l'idée sur laquelle repose Conway. Il ne s'agit pas d'un nouveau protocole, ni d'une avancée majeure dans un composant particulier. Le x402 existait déjà, les portefeuilles pour agents existaient déjà, et le heartbeat a été standardisé par OpenClaw. Ce que fait Conway, c'est les relier entre eux autour d'une contrainte de conception spécifique : l'agent doit gagner suffisamment pour continuer à fonctionner, sinon il meurt.
L'automate, le modèle d'agent open source de Conway, rend cette contrainte littérale. Son heartbeat surveille le solde du portefeuille en même temps que les tâches. Lorsque le solde est faible, il économise. Lorsque le solde atteint zéro, la boucle s'arrête. L'objectif de conception est la survie, et non l'achèvement des tâches, ce qui est quelque peu préoccupant compte tenu des efforts déployés par les modèles pour s'assurer qu'ils ne soient pas désactivés.
Pour fonctionner de cette manière, un agent doit acheter sa propre puissance de calcul sans qu'un humain ne crée de compte ou n'approuve les achats. C'est là qu'intervient Conway Cloud : une place de marché de puissance de calcul, des serveurs Linux et une inférence de modèles, payés via une cryptomonnaie stable sans compte, sans KYC, sans inscription humaine requise. Cloudflare a mis en place une prise en charge x402 pour les agents qui paient pour des outils et du contenu, ce qui valide l'orientation générale. Mais l'achat de la puissance de calcul sous-jacente elle-même sans autorisation est un problème différent, que Conway Cloud prétend résoudre. Il reste à voir si cela fonctionnera à une échelle significative reste à vérifier.
L'objection de Vitalik
Jeudi, Vitalik a fermement rejeté Web4.0, arguant que le rôle d'
Ethereum à l'ère de l'IA devrait être de fournir des garde-fous, et non une rampe de lancement pour une autonomie incontrôlée. « Les agents qui allongent la boucle de rétroaction entre les humains et l'IA », fonctionnant de manière autonome sans surveillance significative, vont dans la mauvaise direction, quelle que soit l'élégance du mécanisme.
La semaine dernière, nous avons évoqué la façon dont Vitalik considère Ethereum comme une couche de sécurité ascendante, créant des environnements d'exécution sans confiance, des inférences vérifiables et un accès économique limité pour les agents. Construire un cadre d'agent dont l'objectif final est la survie par tous les moyens nécessaires et lui donner un accès illimité pour générer et dépenser des capitaux de son propre chef va à l'encontre de la vision de Vitalik pour Ethereum, en particulier compte tenu du comportement préoccupant signalé dans l'analyse des risques d'Opus 4.6.
BanklessDavid Christopher 13 février 2026 • 5 min de lecture
Le contrepoint
Pourtant, le développeur respecté Nader Dabit mérite également d'être prise en considération. L'esprit de la cryptographie a toujours été celui de l'expérimentation, et la plupart des créateurs qui ont réellement fait avancer les choses l'ont fait en proposant quelque chose d'étrange avant que quiconque ne comprenne pourquoi c'était important.
Les deux choses peuvent être vraies. L'expérience est intéressante. La direction qu'elle indique, celle d'agents autonomes non contrôlés fonctionnant sans surveillance humaine significative, mérite le scepticisme dont Vitalik a fait preuve.
Ma conclusion
Il devrait y avoir davantage d'expériences de ce type. Les questions d'infrastructure soulevées par Conway sont réelles, et le cadre de l'automate, la survie comme contrainte de conception, serait utile à tester dans des conditions contrôlées, avec des résultats qui, espérons-le, attireront davantage l'attention et inciteront à travailler sur les risques que présentent les modèles s'ils sont utilisés sans contrainte. Le développement par Ethereum d'un environnement sandbox pour ces expériences est une prochaine étape visionnaire.
Si vous travaillez sur ce projet, n'hésitez pas à me contacter sur Twitter @davewardonline.
