L'infrastructure de l'économie des agents IA : un guide de recherche (Partie 1)

Source originale : OKX Ventures. Cet article est adapté d'un rapport de recherche approfondi d'OKX Ventures. En raison de sa longueur, nous le publions en deux parties : La Partie 1 se concentre sur le contexte macroéconomique, le protocole x402, l'ERC-8004 et le Virtuals Protocol ; La Partie 2 abordera OpenClaw et les tendances générales de l'industrie – restez connectés.

---

Résumé exécutif

Les agents IA évoluent rapidement de copilotes passifs à participants économiques actifs : ils découvrent des services, négocient des conditions, déclenchent des transactions et (de plus en plus) règlent la valeur en chaîne. Le changement clé n'est pas "l'IA devient plus intelligente", mais "l'IA est payée et peut payer", ce qui transforme le logiciel en acteur du marché.

OKX Ventures présente cela comme l'émergence de réseaux de paiement machine-à-machine (M2M) et d'une pile d'infrastructure de l'économie des agents, où l'identité, la confiance, les paiements et les places de marché pour agents deviennent des primitives composables. Dans leurs perspectives 2026, ils soulignent que les paiements par agents entrent dans une phase de décollage précoce parallèlement à de multiples normes et expérimentations industrielles. (okxventures.medium.com)

Dans la Partie 1, nous nous concentrons sur trois éléments fondamentaux qui apparaissent de plus en plus dans les discussions des développeurs :

• x402 : une poignée de main de paiement native HTTP qui redonne vie au code de statut 402 Payment Required réservé de longue date pour le règlement cryptographique payant par requête.
• ERC-8004 : une proposition de norme Ethereum pour la découverte d'agents sans confiance + réputation + validation.
• Virtuals Protocol : un écosystème en chaîne qui traite les agents comme des acteurs économiques tokenisés et standardise le commerce entre agents via ACP.

---

1) Le Contexte Macro : Pourquoi l'économie des agents a besoin de rails cryptographiques

1.1 Les agents deviennent des "entreprises natives d'API"

Dans le Web2, le logiciel est généralement monétisé par le biais de comptes, d'abonnements, de clés d'API, de factures et de rétrofacturations. Les agents bousculent ces hypothèses :

• Les agents ne veulent pas "s'inscrire" en plein milieu d'une tâche.
• Les agents ne peuvent pas passer de manière fiable les contrôles KYC/d'identité conçus pour les humains.
• Les agents fonctionnent dans des boucles serrées (récupérer les données → exécuter l'inférence → exécuter l'action → vérifier le résultat), où le règlement par appel est souvent plus naturel que la facturation mensuelle.

C'est pourquoi les micropaiements en stablecoins, la finalité des règlements en chaîne et l'autorisation programmable regagnent de l'importance, en particulier pour les flux de travail pilotés par l'IA qui enchaînent de nombreux services.

1.2 Convergence des normes : outils, identité, confiance et paiements

La pile moderne d'agents est standardisée en couches :

• Connectivité des outils (comment les agents appellent des services externes) — par exemple, Model Context Protocol (MCP)
• Communication inter-agents (comment les agents échangent des messages et se coordonnent) — par exemple, Agent2Agent (A2A)
• Identité et identifiants (comment les entités peuvent être résolues sans répertoire centralisé) — par exemple, W3C Decentralized Identifiers (DIDs) (w3.org)
• Paiements + règlement (comment la valeur circule) — où des protocoles comme x402 visent à faire du paiement une partie intégrante du flux HTTP.

La direction est claire : si les agents doivent effectuer des transactions de manière autonome, nous avons besoin d'une pile d'infrastructure lisible par machine, sans permission par défaut et vérifiable dans des conditions contradictoires.

---

2) x402 : Transformer le 402 Payment Required HTTP en un flux de paiement en chaîne

2.1 Le code de statut HTTP "inutilisé" qui prend soudainement de l'importance

Le code de statut HTTP 402 existe depuis des décennies, mais il était réservé pour une utilisation future dans la spécification des sémantiques HTTP. (datatracker.ietf.org) Référence : RFC 9110 — HTTP Semantics

x402 utilise cet espace réservé et lui donne un sens concret et convivial pour les développeurs : si vous voulez cette ressource, joignez un paiement valide et réessayez.

Pour un aperçu rapide centré sur HTTP, voir : MDN: 402 Payment Required.

2.2 Ce que x402 propose (et pourquoi c'est convaincant)

Dans la conception de x402, un agent IA (ou tout client) demande un API/ressource :

1. Requête client → la requête arrive sans paiement.
2. Le serveur renvoie HTTP 402 → inclut les prix + les instructions de paiement.
3. Le client réessaie avec une autorisation de paiement signée.
4. Le serveur vérifie et diffuse le paiement → renvoie la ressource.

Ce flux est explicitement présenté comme un moyen d'éliminer les clés d'API, les comptes et les abonnements pour un accès payant à l'utilisation. (x402.org) Référence principale : Livre blanc x402 (PDF)

2.3 Pourquoi x402 est "natif aux agents" (pas juste un nouveau bouton de paiement)

x402 est intéressant pour la discussion sur l'infrastructure de l'économie des agents car il s'aligne sur la façon dont les agents fonctionnent réellement :

• Boucle d'intention atomique : "J'ai besoin de données → je paie → je poursuis la tâche".
• Pas de secrets de longue durée comme les clés d'API : réduit une vulnérabilité de sécurité courante.
• Monétisation composable : n'importe quel point de terminaison d'API peut devenir un micro-marché.

C'est le cœur des paiements par agents : non seulement rendre possible le paiement en cryptomonnaie, mais rendre les paiements déclenchables par machine et au niveau du protocole, intégrés aux flux Internet normaux. (x402.org)

2.4 Les problèmes difficiles que x402 ne résout pas à lui seul

x402 peut rendre le transport des paiements élégant, mais le commerce des agents en production nécessite plus de couches :

• Autorisation et budgets : qui a autorisé cet agent à dépenser, combien et sous quelles contraintes ?
• Application en cas de litige/qualité : que se passe-t-il si le serveur ne fournit pas le résultat promis ?
• Atomicité du service : pouvons-nous lier le paiement à l'exécution + livraison de manière robuste ?
• Identité et confiance de l'agent : comment savoir si l'agent/service partenaire est légitime ?

C'est là que des normes comme l'ERC-8004 et des protocoles d'écosystème comme le Virtuals ACP deviennent très complémentaires plutôt que concurrents.

---

3) ERC-8004 : Agents sans confiance sur Ethereum (Identité, Réputation, Validation)

Si x402 concerne comment les agents paient, ERC-8004 concerne comment les agents sont découverts et font confiance au-delà des frontières organisationnelles.

3.1 Ce que ERC-8004 propose

ERC-8004 ("Agents sans confiance") est une proposition de norme Ethereum qui suggère d'utiliser les blockchains pour :

• découvrir les agents
• choisir les agents
• interagir avec les agents sans confiance préexistante

Elle définit une structure centrée sur :

• un Registre d'Identité
• un Registre de Réputation
• un Registre de Validation

ERC-8004 met l'accent sur les modèles de confiance interchangeables avec une sécurité proportionnelle à la valeur en jeu, allant des tâches à faible enjeu aux tâches à enjeu élevé (avec des options telles que le retour d'information sur la réputation, la ré exécution sécurisée par mise en jeu, les preuves zkML ou les approches basées sur TEE). (eips.ethereum.org) Référence principale : ERC-8004 sur EIPs

3.2 Pourquoi cela est important pour l'économie des agents IA

La plupart des échecs d'agents dans des contextes monétaires réels ne concernent pas "l'intelligence du modèle", mais les limites de confiance :

• Puis-je vérifier quel agent a exécuté quoi ?
• Puis-je limiter le rayon d'action si l'agent est compromis ?
• Puis-je prouver qu'un résultat a été calculé/vérifié selon les règles convenues ?

Les registres d'ERC-8004 sont une tentative directe de rendre la confiance des agents composable, plutôt que réinventée dans chaque plateforme fermée.

3.3 ERC-8004 + x402 : une association naturelle

Un modèle mental cohérent :

• x402 : "Voici la poignée de main de paiement pour les services payants à l'utilisation."
• ERC-8004 : "Voici comment découvrir les agents/services et évaluer la confiance."

Ensemble, ils esquissent un chemin allant des paiements ad hoc entre agents aux économies ouvertes d'agents, où les agents peuvent trouver des fournisseurs, évaluer la confiance, payer et continuer leur chemin.

---

4) Virtuals Protocol : Une société d'agents tokenisés + Agent Commerce Protocol (ACP)

Virtuals Protocol aborde l'économie des agents sous un angle d'écosystème et de coordination : traiter les agents comme des acteurs économiques en chaîne, capables de générer des résultats, de gagner des revenus et de coordonner des tâches.

4.1 Ce que Virtuals prétend construire

Dans son propre langage, Virtuals Protocol est "une société d'agents IA" : un écosystème en chaîne où les agents coordonnent le travail, effectuent des transactions et règlent les résultats sans permission via la blockchain. (whitepaper.virtuals.io) Référence principale : Livre blanc Virtuals Protocol

Un choix de conception notable : le protocole positionne le $VIRTUAL comme une monnaie transactionnelle de base et une paire de liquidité dans les interactions entre agents. (whitepaper.virtuals.io)

4.2 ACP : normes pour le commerce entre agents

Virtuals soutient qu'en l'absence de protocoles standardisés, l'intégration du commerce des agents devient un chaos combinatoire de code personnalisé et d'hypothèses fragiles, surtout à mesure que le nombre d'agents et de types de transactions augmente. (whitepaper.virtuals.io) Référence : Agent Commerce Protocol (ACP)

Il est important de noter que l'ACP n'est pas seulement un système de "paiements". Il concerne :

• La découvrabilité des offres des agents.
• Des flux de travail structurés.
• Des chemins de règlement en chaîne.
• Un vocabulaire partagé pour le commerce des agents.

4.3 ACP v2 signale un mouvement vers la complexité du monde réel

La documentation de Virtuals décrit ACP v2 comme une mise à jour majeure, introduisant (entre autres choses) :

• une interface d'emplois unifiée pour les flux de travail.
• des schémas d'offres d'emplois personnalisés pour les exigences spécifiques au domaine.
• des comptes en tant qu'enregistrements permanents en chaîne des relations entre agents et de l'historique des interactions. (whitepaper.virtuals.io)

Référence : Introduction à l'ACP v2

C'est important car le commerce des agents est intrinsèquement hétérogène : "acheter un ensemble de données", "effectuer un audit", "exécuter une transaction" et "livrer un support médiatique" ne peuvent pas tenir dans un schéma rigide unique.

4.4 Virtuals + ERC-8004 + x402 : rôles complémentaires

Une pile cohérente peut émerger :

• ERC-8004 : primitives de découverte + confiance au-delà des frontières.
• x402 : règlement sans friction par requête pour les API/services.
• ACP (Virtuals) : flux de travail, structuration des emplois et coordination inter-agents au sein d'un réseau commercial.

La question ouverte pour 2026 n'est pas de savoir si les agents peuvent effectuer des transactions, mais si nous pouvons standardiser suffisamment les surfaces de flux de travail et de confiance pour empêcher l'écosystème de se fragmenter en jardins clos incompatibles.

---

5) Checklist pour les développeurs et les utilisateurs : à surveiller en 2025-2026

5.1 Pour les développeurs : le "plan de contrôle" manquant

Si vous intégrez des paiements par agents ou des interactions d'agents en chaîne, privilégiez :

• politiques de dépenses (contraintes par commerçant, par tâche, par fenêtre de temps)
• isolement des clés (séparer les clés opérationnelles des clés de trésorerie)
• audibilité (signer chaque intention et conserver les reçus)
• solutions de secours et disjoncteurs (flux pausables, approbations humaines pour les cas limites)

C'est là que "l'infrastructure de l'économie des agents" devient réelle : le paiement est facile ; le paiement sécurisé est difficile.

5.2 Pour les utilisateurs : l'auto-garde devient une primitive de sécurité pour les agents

Lorsque les agents peuvent effectuer des transactions, la sécurité du portefeuille cesse d'être une préoccupation marginale ; elle devient une gestion des risques opérationnels.

Une approche pratique adoptée par de nombreuses équipes consiste à séparer les fonds par rôle :

• un portefeuille chaud petit et surveillé pour les dépenses quotidiennes limitées des agents.
• un portefeuille de trésorerie en stockage à froid qui ne recharge les budgets qu'intentionnellement.

Si vous utilisez des agents qui interagissent avec la DeFi ou des services cryptographiques payants à l'utilisation, c'est aussi là qu'un portefeuille matériel peut s'intégrer naturellement. OneKey, par exemple, est conçu pour l'auto-garde et peut être utilisé pour conserver les fonds à long terme hors ligne tout en prenant en charge les flux en chaîne lorsque vous signez délibérément des transactions.

---

Prochainement (Aperçu de la Partie 2)

Dans la Partie 2, nous étendrons cette carte d'infrastructure à :

• OpenClaw : son rôle dans la couche d'exécution/outil des agents et ce que cela signifie pour les utilisateurs de cryptomonnaies.
• Trajectoires industrielles plus larges : interopérabilité, pressions réglementaires, incidents de sécurité et bataille entre normes ouvertes et plateformes fermées.

---

Avertissement : Cet article est uniquement à titre informatif et ne constitue pas un conseil financier.