Note de veille de **Didier Girard** datée du **2 août 2026**, partie d'une question de collègue (« c'est quoi ACP ? ») pour traiter un problème qui n'est pas terminologique mais **documentaire**. **Trois protocoles se disputent le sigle**, sans aucune intersection technique : **Agent Client Protocol** (client ↔ agent — Zed, août 2025, JSON-RPC 2.0 sur stdio, Apache-2.0, « ce que LSP a fait pour les langages »), **Agentic Commerce Protocol** (agent ↔ commerçant — OpenAI + Stripe, 29 sept. 2025, face à l'**UCP** de Google du 11 janv. 2026 adossé à **AP2**), et **Agent Communication Protocol** (agent ↔ agent — IBM Research / BeeAI, marginal mais polluant les recherches). **Le cœur de la note n'est pas le démêlage mais son échec constaté** : l'auteur cherche « ACP » dans sa base de connaissances de veille et obtient **douze résultats, tous sur le protocole de commerce, zéro sur celui de Zed** — *« nos agents de veille avaient indexé le sigle sans le désambiguïser »*. D'où une règle d'ingénierie de la connaissance : ***« on n'indexe jamais un sigle seul »*** — l'entité est « Agent Client Protocol », « ACP » n'est **qu'un alias**, porté par trois entités distinctes. Suit une clarification structurante (**MCP relie un agent à ses outils, ACP relie un client à un agent ; les deux s'empilent**) puis le cas d'école : **Buzz**, publié par **Block** le 21 juillet 2026 sous Apache-2.0 — espace de travail auto-hébergeable bâti sur **Nostr**, où chaque participant humain ou agent est une **paire de clés** et chaque message, étape de workflow ou push git un **événement signé** dans un journal append-only. Architecture entièrement protocolaire (`buzz-acp` harnais ACP sur stdio, `buzz-agent` agent ACP appelant un LLM, `buzz-dev-mcp` serveur MCP shell + édition), d'où l'agnosticisme d'agents : **Goose, Claude Code et Codex** se branchent par le même harnais, et **Hermes** (Nous Research) s'y est raccordé sans que Block écrive une ligne — *« N+M au lieu de N×M, tenue en production »*. La note se clôt sur la question de l'**abonnement Claude** face aux agents tiers, avec une chronologie 2026 en cinq temps et une **règle de conception** qui vaut au-delà du cas : la ligne n'est pas juridique mais **architecturale** — ***« qui consomme, et pour le compte de qui »*** (un agent `owner-only` consomme votre abonnement pour vous ; un agent `anyone` dans un canal partagé fait passer les requêtes de vos collègues par votre compte). **Vérification menée sur ce corpus** : la thèse tient, et plus durement que ce que la note affirme — non seulement « Agent Client Protocol » y est **totalement absent**, mais le sigle nu `ACP` **est déjà typé comme entité** dans deux fiches, et la page KB `Agentic-Commerce-Protocol` **attribue déjà le protocole à Google** alors qu'il est d'OpenAI + Stripe. La collision décrite n'est pas un risque à venir : elle a **déjà produit une erreur d'attribution** dans le graphe.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
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.