Mastercard a ouvert l'accès anticipé à son système de paiement par agents le 20 octobre 2026. Selon le communiqué publié ce jour-là, Agent Pay for Machines met désormais à disposition des développeurs des API côté acheteur et côté vendeur, une boîte à outils et un bac à sable de test, après des pilotes de bout en bout menés avec des partenaires comme Cloudflare, Ant International, BVNK et Coinbase. Le service avait été annoncé dès juin ; la nouveauté de cette semaine n'est pas le concept, mais l'arrivée des outils entre les mains des développeurs.
Ce que l'agent de démonstration a réellement acheté
Lors d'une démonstration à Cloudflare Connect, un agent travaillant pour l'agence marketing Hype a reçu une mission de campagne pour une barre protéinée : mener une étude sur les réseaux sociaux, puis générer huit visuels. Au fil de la tâche, il a effectué neuf paiements vers deux commerçants, AIsa et Cloudflare AI Gateway, tous prélevés sur un budget unique approuvé à l'avance. Pas de comptes séparés, pas de clés API ni de factures par service : l'agent a trouvé les prestataires, convenu des conditions et payé uniquement ce qu'il a utilisé.
La première question : pourquoi une machine aurait-elle le droit de dépenser ?
Le dispositif de Mastercard relie x402, le protocole de paiement ouvert lancé par Coinbase, aux systèmes de confiance et de gestion des risques de son propre réseau. Les agents agissent avec des justificatifs signés qui établissent identité et autorisation, les entreprises fixent à l'avance des plafonds de dépense et des catégories permises, et les règlements peuvent se faire par carte, compte bancaire ou stablecoin. L'autorisation est ainsi écrite, avant que l'argent ne bouge, sous forme de règles qu'une machine peut exécuter et qu'un auditeur peut retracer ensuite, au lieu d'être reconstituée une fois la dépense faite.
Encore un pilote, pas un lancement commercial
Un peu de prudence s'impose. L'accès anticipé ne s'accompagne ni de tarifs ni de date de lancement commercial, et Mastercard indique vouloir d'abord recueillir les retours des développeurs. Les problèmes les plus durs sont aussi absents de la démonstration : que se passe-t-il quand un plafond s'épuise en pleine tâche, comment révoque-t-on une autorisation en cours, et qui est responsable quand un agent paie le mauvais destinataire ? Les documents publics n'y répondent pas encore complètement.
La direction, elle, est limpide. Une fois que les agents savent écrire du code et réserver des services, le paiement devient le goulot suivant : qui l'a autorisé, combien peut être dépensé, qui est payé et qui répond en cas d'erreur. Quand un réseau de paiement construit des API dédiées et un bac à sable pour des transactions machine fréquentes et de faible montant, ces questions cessent d'être des sujets de conférence pour devenir une compétition d'infrastructure. Pour les développeurs, le geste utile dès maintenant est de tester dans le bac à sable les flux d'autorisation et de rapprochement de leurs propres cas d'usage, plutôt que d'attendre une sortie commerciale pour s'y mettre.
