L'agent IA Gemini Spark a besoin d'un portefeuille, pas d'une carte
Google a annoncé Gemini Spark le 19 mai 2026 : un assistant agentique disponible 24h/24 et 7j/7 qui lit votre Gmail, rédige des réponses, effectue des réservations et continue de travailler après que vous ayez fermé votre ordinateur. La promesse est celle d'un assistant agentique toujours actif qui gère la partie ennuyeuse de votre boîte de réception pendant que vous dormez.
Derrière les démonstrations Gmail se cache un problème que personne sur scène ne voulait énoncer clairement. Dès qu'un agent agit sans que vous soyez présent, toutes les hypothèses sur lesquelles reposent les paiements par carte s'effondrent. Pas d'humain pour appuyer sur "approuver". Pas de téléphone pour recevoir le code 3-D Secure. Ni carte présente, ni titulaire présent, ni session.
Je pense que c'est le vrai sujet du lancement de Gemini 3.5, et il n'a presque rien à voir avec les e-mails.
Pourquoi un assistant agentique toujours actif ne peut pas utiliser votre carte
Les réseaux de paiement par carte supposent l'existence d'une personne. L'ensemble du dispositif anti-fraude, CVV, 3-D Secure, le petit code SMS, les vérifications de fréquence, existe pour confirmer qu'un humain est à l'origine de la transaction. Spark est tout le contraire. C'est un processus dans le cloud de Google qui se réveille à 3h du matin pour rebooker un vol annulé.
Faites tourner un agent autonome sur les réseaux Visa et vous vous heurterez rapidement à un mur :
- Les transactions sans carte présente depuis une adresse IP de centre de données sont signalées ou refusées.
- Les défis 3-D Secure sont envoyés à un humain qui dort.
- La responsabilité des rétrofacturations incombe au marchand pour un achat qu'aucun humain n'a autorisé.
- Il n'existe pas de moyen propre de donner à un agent un plafond de dépenses de 40 $ qui se réinitialise quotidiennement et ne peut pas être vidé.
Le positionnement AI Ultra de Google lui-même repose sur le regroupement d'abonnements précisément parce que les paiements par action ne sont pas résolus. Vous payez à Google un forfait mensuel fixe, Google absorbe les coûts de l'agent, et personne n'a à se demander comment l'agent paye un tiers. Cela fonctionne jusqu'à ce que l'agent ait besoin d'acheter quelque chose en dehors de l'écosystème fermé de Google.
La demande est enfin au rendez-vous
Pendant deux ans, les acteurs des paiements pour agents ont construit des infrastructures pour un client qui n'existait pas. J'ai écrit sur ce fossé dans AI Agent Payments: Anvita, x402, and Who Owns the Rail, la technologie était prête, les dépensiers autonomes ne l'étaient pas.
Spark change la donne. Google s'apprête à déployer des dizaines de millions d'agents toujours actifs qui auront, à terme, besoin d'effectuer des transactions. C'est la demande que les infrastructures attendaient.
La pile qui a émergé est ennuyeuse dans le bon sens du terme :
- x402 réactive le code de statut HTTP 402 "Payment Required" dormant pour qu'un serveur puisse indiquer un prix et qu'un agent puisse le payer en ligne, en stablecoins, au cours d'une seule requête.
- AWS AgentCore a ajouté un chemin de paiement pour que les agents tournant dans le cloud d'Amazon puissent régler sans qu'un humain approuve chaque paiement.
- Pay.sh et des outils similaires encapsulent USDC sur Base dans quelque chose qu'un agent peut appeler comme n'importe quelle autre API.
Le fil conducteur : USDC sur Base. Finalité bon marché, frais inférieurs au centime, et un stablecoin qu'une trésorerie d'entreprise peut réellement détenir sans que l'équipe de conformité ne dépose une injonction.
Pourquoi USDC sur Base, précisément
Les paiements d'agents sont des micropaiements. Un agent pourrait payer 0,003 $ pour interroger une API météo ou 2 $ pour acheter un jeu de données. Le gas du réseau principal Ethereum éclipserait le paiement lui-même. Base a réglé plus d'1 milliard de dollars de volume DEX quotidien ce cycle, et ses frais se situent en fractions de centime, ce qui est le seul régime de frais où les micropaiements à vitesse machine ont un sens.
Les stablecoins comptent plus que la chaîne. Un agent ne peut pas détenir un actif volatil ; une variation de prix de 4 % entre l'autorisation et le règlement d'un paiement est rédhibitoire. USDC est libellé en dollars, remboursable et émis par une entité réglementée. Après que le GENIUS Act AML rulemaking a soumis les émetteurs de stablecoins à un régime de surveillance de type bancaire, un directeur financier peut approuver la détention de USDC d'une façon qu'il n'aurait jamais pu faire avec un token non adossé.
Cette clarté réglementaire est le facteur décisif, pas le débit. J'ai vu des transactions institutionnelles échouer précisément à cause de cette question : « qui est responsable, et l'émetteur est-il supervisé ? »
La partie difficile n'est pas les paiements. C'est l'autorité
Donner un portefeuille à un agent, c'est les 20 % faciles. Les 80 % restants, c'est la gouvernance :
- Des plafonds de dépenses qui tiennent. Un portefeuille d'agent a besoin d'un plafond strict appliqué on-chain, pas d'une limite souple dans le code applicatif qu'une injection de prompt peut contourner.
- Délégation révocable. Vous autorisez l'agent pour les réapprovisionnements alimentaires, pas pour déplacer vos économies. Cette délimitation doit être cryptographique, pas une case à cocher.
- Auditabilité. Chaque paiement d'agent doit être attribuable à une politique définie par un humain. « L'IA a décidé de » n'est pas une réponse qu'un régulateur accepte.
C'est là que le risque d'injection de prompt devient réel. Nous avons déjà vu ce que fait une seule clé divulguée, voir l'exploit Polymarket. Imaginez maintenant que cette clé se trouve dans un agent qui lit des e-mails non fiables toute la journée et peut dépenser de l'argent. La surface d'attaque, c'est toute la boîte de réception.
Ce que je surveillerai ensuite
Google n'intégrera pas USDC dans Spark cette année. La première version acheminera tout via Google Pay et la facturation propre à Google, parce que c'est contrôlable et parce que Google préfère posséder l'infrastructure plutôt que de la louer.
Mais l'agent qui réserve votre vol à 3h du matin voudra éventuellement payer un fournisseur avec lequel Google n'a pas de relation de facturation. Lorsque cela arrivera, le chemin le moins cher sera un paiement en stablecoin via un protocole ouvert, pas une intégration de carte sur mesure par marchand. L'infrastructure qui gagnera sera celle qu'un agent peut appeler sans demander la permission à un géant des paiements.
Le portefeuille arrive pour l'agent. La seule question ouverte est de savoir s'il s'agit d'un registre fermé à l'intérieur de Google ou d'un registre ouvert sur lequel n'importe qui peut construire. Je parie sur l'ouvert, pour la même raison que le web a battu AOL.