Titre : X402 expliquée : Micropaiements HTTP natifs pour les agents IA

La spécification X402 réutilise le statut standard HTTP 402 Payment Required pour transformer un appel API classique en un micropaiement on-chain. Les agents IA peuvent désormais régler les frais de requêtes LLM ou de flux de données sans intervention humaine, et les fournisseurs peuvent facturer à la requête sans avoir à construire un système de facturation personnalisé.

Pourquoi les agents IA ont besoin d'un protocole de paiement

Les agents autonomes assemblent des modèles de langage, des outils de recherche web et des sources de données propriétaires. Chaque assemblage a un coût : des frais par jeton (token) pour un modèle ou des frais par appel pour une API de données de marché. Les modèles économiques actuels reposent sur des clés API liées à des comptes d'abonnement, des recharges de crédit manuelles ou une facturation a posteriori. Ces méthodes rompent la promesse d'autonomie (« no-human ») des agents et ajoutent une charge opérationnelle pour les fournisseurs.

X402 offre un juste milieu : un flux requête-réponse qui ressemble à n'importe quel autre appel HTTP, mais avec une étape de paiement intégrée et enregistrée sur une blockchain publique. La seule exigence est que le client puisse signer et diffuser une transaction sur la chaîne spécifiée par le serveur.

Le handshake X402 en détail

  1. Requête initiale – L'agent envoie un GET ou POST normal vers un endpoint payant. Aucun en-tête spécial n'est nécessaire.
  2. Le serveur répond par une 402 – La réponse contient le statut 402 et un corps JSON listant :
    • amount – le montant attendu par le serveur, dans la plus petite unité du jeton ;
    • token – l'adresse du contrat ERC-20 (ou équivalent) ;
    • chain – l'identifiant de la blockchain sur laquelle le paiement doit être enregistré ;
    • nonce optionnel – une valeur unique qui empêche les attaques par rejeu.
  3. Le client prépare le paiement – L'agent vérifie l'adresse du jeton et la chaîne par rapport à sa politique (par exemple, uniquement les chaînes de confiance). Il crée ensuite une transaction qui transfère le montant requis vers l'adresse fournie par le serveur, la signe avec sa clé privée et la diffuse.
  4. Soumission du hash de paiement – Une fois le hash de la transaction disponible, le client répète la requête originale, en ajoutant cette fois un en-tête X-Payment contenant le hash. Le payload reste inchangé.
  5. Le serveur vérifie on-chain – Le serveur interroge la blockchain pour trouver un transfert confirmé correspondant au montant, au jeton, à la chaîne et au nonce. S'il trouve une correspondance, il renvoie les données demandées avec un statut 200 OK.

Toute bibliothèque cliente HTTP prenant en charge les en-têtes personnalisés et capable d'appeler un SDK blockchain peut effectuer ces étapes. Aucun nouveau protocole de transport ou couche socket personnalisée n'est requis.

Compromis à garder à l'esprit

  • Latence – La confirmation sur une blockchain publique ajoute un délai.
  • Frais de gaz – Même les chaînes peu coûteuses facturent du gaz ; les paiements inférieurs à 0,001 $ peuvent ne pas être rentables.
  • Complexité – Les agents doivent gérer les transactions échouées et les réorganisations de chaîne (chain reorganizations) ; une logique de réessai robuste est indispensable.
  • Sécurité – Le nonce empêche les attaques par rejeu, mais les agents doivent tout de même protéger leurs clés privées et éviter de les réutiliser pour des services non liés.