Annonce produit publiée sur le blog **Cloudflare** le **4 août 2026** par **Will Papper**, dans le cadre de l'**Agents Week** : **Cloudflare Wallets**, présenté comme *« the programmable wallet for the agentic Internet »*. **Le problème posé** est précis et bien choisi : un agent qui veut essayer une API doit traverser une page de connexion **conçue pour des humains**, faire ajouter un moyen de paiement par un humain, générer une clé d'API, puis comprendre comment appeler le service. Deux manques structurels l'expliquent — *« Agents do not have a stable identifier to sign up for an API, and they do not have a native way to pay for APIs »* — avec pour conséquence que *« AI agents often give up on these tasks entirely, kicking registration, payment methods, and API key generation back to humans »*. **L'architecture proposée tient en deux types de portefeuilles** : les **Account Wallets**, destinés aux humains propriétaires d'un compte Cloudflare (approvisionner, déléguer, retirer), et les **Virtual Wallets**, destinés aux agents, **opérant par clé d'API** et dont le plafond de dépense est **fixé par le détenteur du compte**. Les garde-fous annoncés sont explicites : **allocation, liste d'autorisation, montant maximal par transaction**. **Le rail de paiement est le protocole x402** (paiements attachés à des requêtes HTTP) et la monnaie est le **stablecoin** — ce qui place l'offre dans un camp distinct de celui des schémas adossés aux réseaux de cartes. **L'argument le plus intéressant est contre-intuitif et central** : *« These limits may seem like constraints, but counterintuitively they give agents more freedom. If an agent is responsible for $10, you can worry less about its spending than if it is responsible for $1,000. »* → **le plafond n'est pas ce qui bride l'autonomie, c'est ce qui la rend consentable.** **Second volet, plus stratégique que le premier** : l'identité, via un espace de noms **`cloudflare.pay`** — un agent de recherche pourrait vivre à `research.example.cloudflare.pay`, donnant au marchand la certitude qu'il parle à l'agent d'une organisation identifiée. Cloudflare revendique une ambition volontairement minimale (*« a human-readable identifier for a not-very-readable keypair, similar to the URL and IP-address pairings used in DNS »*), adossée à ses briques existantes (**Turnstile**, Bot Management, **Web Bot Auth** et ses paires de clés), et annonce vouloir adopter les schémas de la **x402 Foundation** à mesure qu'ils émergeront. **Réserve dirimante sur le statut du texte** : **presque tout est au futur**. Ce qui existe le jour de l'annonce, c'est la **réservation d'un handle** ; les paiements, les Virtual Wallets, les garde-fous et les rampes d'accès aux fonds sont annoncés (*« Soon, you will be able to… »*). C'est une **prise de position sur un espace de noms**, davantage qu'une mise en service.
#Cloudflare Wallets#commerce agentique#Agents Week
**Will Papper** — auteur de l'annonce sur le blog Cloudflare (lecture annoncée : 8 minutes). Publication rattachée à l'**Agents Week** de Cloudflare et étiquetée *Agents Week · AI · AI Bots · Developer Platform · Developers · Payments · Product News · x402*.
Annonce produit publiée sur le blog **Stripe** le **29 avril 2026** par **Dan Hill** (Product Manager, Link Consumer Product), dans le prolongement de la keynote **Stripe Sessions 2026** : le lancement du **portefeuille Link pour les agents**, bâti sur une brique nouvelle, **Issuing for agents**. **Le diagnostic tient en une phrase, et c'est la plus importante du texte** : *« While machine payments protocols are still gaining adoption, agents need to work with the payment options sellers and consumers use today. »* → **Stripe acte que les protocoles de paiement machine-natifs ne sont pas prêts, et livre un contournement des rails existants plutôt qu'un pari sur les nouveaux.** **Le mécanisme** : un consommateur donne à un agent l'accès à son portefeuille Link par un **flux OAuth standard** ; l'agent émet ensuite une *spend request* et reçoit soit une **carte à usage unique**, soit un **Shared Payment Token** — adossés aux cartes et comptes bancaires déjà présents dans le portefeuille. Point cardinal : *« The agent never gets access to your raw payment credentials. »* Le justificatif est **scopé** (montant, devise, marchand) et l'agent doit fournir le **contexte de la transaction** pour que l'humain comprenne ce qu'il approuve — l'exemple donné en CLI est explicite : `amount 3500`, `merchant-name "Powdur"`, `context "Purchasing the Powdur Glow Renewal Vitamin C Serum as a gift for $35."`. **La contrainte structurante est temporelle et assumée** : *« Today, each request requires the person's review before the credential is shared with your agent »* — approbation **humaine, transaction par transaction**, sur le web ou dans les **nouvelles applications iOS et Android** de Link. Les limites de dépense et les cas où l'agent agirait **sans approbation supplémentaire** sont annoncés, pas livrés. **Le second étage est le vrai produit d'infrastructure** : **Issuing for agents** ouvre l'ensemble des API Issuing à qui veut bâtir son propre portefeuille agentique — cartes virtuelles à usage unique, stockage de fonds, contrôles de dépense, permissions au niveau de la carte, contrôles antifraude **à l'autorisation**, visibilité temps réel. Quatre débouchés sont cités : automatisation de la dépense interne, cartes agentiques encastrées chez les **fintechs**, plateformes **SaaS verticales** émettant des cartes aux PME sous leur marque, **places de marché** dont les agents vendeurs paient fournisseurs et logistique. **Argument de distribution** : Link revendique **plus de 200 millions de consommateurs**, et l'article cite **OpenClaw** comme exemple d'agent personnel bénéficiaire. **Deux réserves à porter en tête** : l'approbation par transaction est présentée comme une commodité de conception alors qu'elle est **l'aveu que l'autorisation déléguée d'un agent n'est pas résolue** ; et le stablecoin, les *agentic tokens* et « d'autres moyens de paiement » sont tous au **futur** (*« coming soon »*).
#Stripe#Link#portefeuille pour agents
**Dan Hill** — Product Manager · **Link Consumer Product** chez Stripe. Auteur de l'annonce sur le blog Stripe · rubrique *Product*. Le rattachement au produit *Link Consumer* est significatif : l'annonce est écrite depuis le **portefeuille grand public** · pas depuis l'équipe protocole ni depuis Issuing — ce qui explique que le consentement de l'utilisateur final structure tout le texte.