Ce qu'il faut retenir :
- Cloudflare a annoncé ses Wallets et les identifiants cloudflare.pay le 4 août 2026, mais l’essentiel des fonctions de paiement reste encore à venir.
- Les agents pourront utiliser des Virtual Wallets avec des limites de dépenses définies par un compte principal, notamment un budget, une liste de services autorisés et un montant maximal par transaction.
- L’identité de l’agent restera facultative, mais un site pourra décider d’exiger une identification pour accéder à certains services, promotions ou crédits.
- Cloudflare étend un modèle de paiement déjà expérimenté avec les crawlers à beaucoup plus de ressources, notamment les pages web, les jeux de données, les API et les outils MCP.
Cloudflare veut faire payer les agents ia directement
Les agents d’intelligence artificielle commencent à agir sur le web comme des utilisateurs capables de rechercher une information, d'appeler une API ou d'utiliser un outil pour accomplir une tâche. Mais jusqu’ici, leur capacité à payer automatiquement pour ces services restait limitée.
C’est précisément le problème auquel Cloudflare veut s’attaquer avec ses Wallets. L’entreprise a annoncé ce nouveau système le 4 août 2026, dans le cadre de son Agents Week. Le principe est simple : permettre à un agent de disposer d’un budget et de régler lui-même les ressources qu’il utilise.
Il ne s’agit toutefois pas encore d’un service pleinement disponible. Cloudflare indique que les fonctions permettant de configurer et d’utiliser un Wallet pour payer des API et du contenu arriveront prochainement. Le communiqué évoque une disponibilité complète dans les mois à venir.
Les identifiants cloudflare.pay ont, eux, déjà ouvert leur phase de réservation le 4 août.
Un portefeuille principal pour contrôler les dépenses des agents
Le système repose sur deux niveaux de portefeuille :
L’Account Wallet appartient à un humain et contient les fonds. Il peut ensuite déléguer une partie de cet argent à des Virtual Wallets, utilisés par les agents au moyen de clés API.
L’objectif est surtout de conserver un contrôle sur les dépenses. Cloudflare cite notamment trois mécanismes :
- Une allocation budgétaire,
- Une liste de services autorisés,
- Et un montant maximal par transaction.
Une entreprise pourrait ainsi attribuer à ses agents un budget hebdomadaire destiné à certains services d’intelligence artificielle. L’exemple donné par Cloudflare évoque une enveloppe de 100 dollars par semaine pour l’inférence IA.
Cette architecture permet donc d’éviter qu’un agent dispose d’un accès illimité aux fonds de son propriétaire. Le portefeuille de l’agent devient une sorte de compte de dépenses programmable.
Les fonds doivent être détenus sous forme de stablecoins. Cloudflare prévoit des possibilités d’alimentation et de conversion dans les zones géographiques prises en charge, ainsi que l’auto-financement par stablecoins pour certains utilisateurs éligibles.
À ce stade, l’entreprise n’a toutefois pas précisé quels stablecoins et quels réseaux seront utilisés. Elle n’a pas non plus annoncé de partenaire chargé de la conservation des fonds.
Cloudflare étend le paiement au-delà des crawlers
Le paiement pour accéder à une ressource n’est pas une nouveauté chez Cloudflare. En juillet 2025, l’entreprise avait lancé Pay Per Crawl en bêta privée. Le mécanisme permettait alors au propriétaire d’un site de choisir, crawler par crawler, entre trois possibilités : autoriser gratuitement l’accès, demander un paiement ou bloquer complètement le crawler.
La nouveauté des Wallets et du Monetization Gateway tient surtout à l’élargissement du périmètre :
Le Monetization Gateway, dont la liste d’attente a été ouverte le 1er juillet 2026, doit permettre de facturer pratiquement n’importe quelle ressource protégée par Cloudflare. Cela peut concerner une page web, un jeu de données, une API ou encore un outil MCP.
Le paiement intervient au niveau de l’infrastructure Cloudflare avant que la requête ne parvienne au serveur d’origine.
Autrement dit, Cloudflare ne cherche plus seulement à monétiser le passage des robots d’indexation. L’entreprise prépare une infrastructure dans laquelle n’importe quel appelant peut potentiellement devoir payer pour accéder à une ressource.
Le protocole x402 devient la pièce centrale des paiements
Les transactions doivent s’appuyer sur x402, un système qui utilise le code HTTP 402, « Payment Required », pour signaler qu’un paiement est nécessaire avant de fournir une ressource.
L’intérêt du mécanisme est de permettre à un agent de payer sans passer nécessairement par la création d’un compte classique. Cloudflare présente notamment les micropaiements en stablecoins comme un moyen de tester facilement une API ou un service.
Cette approche peut modifier la logique habituelle du web. Aujourd’hui, un utilisateur doit souvent créer un compte, renseigner ses informations et parfois accepter une période d’essai avant d'utiliser un service payant. Un agent pourrait, lui, effectuer directement une transaction pour obtenir la ressource dont il a besoin.
Le règlement est prévu en pair à pair vers le portefeuille du vendeur. Cloudflare précise qu’il n’est donc pas dans le circuit de règlement comme marchand de référence pour ce nouveau dispositif.
Le projet x402 bénéficie par ailleurs d’un soutien institutionnel croissant. Il est désormais porté par une structure de la Linux Foundation dont les membres comprennent notamment Visa, Mastercard, American Express, Google, Shopify et Stripe.
L’identité des agents reste facultative
Cloudflare ne veut pas seulement permettre aux agents de payer. L’entreprise cherche également à donner aux agents une identité lisible. Avec cloudflare.pay, un agent pourrait par exemple utiliser un nom permettant à un marchand de comprendre quelle organisation se trouve derrière lui. Un agent de recherche pourrait ainsi disposer d’un identifiant associé à l’entreprise qui l’exploite.
Cette couche s’appuie sur Web Bot Auth, qui permet déjà aux agents d’enregistrer leur identité à l’aide d’une paire de clés. Mais Cloudflare insiste sur un point important : la déclaration d’identité est facultative pour l’agent.
Cela ne signifie pas pour autant qu’un site doit accepter un agent anonyme. Le marchand reste libre de décider avec quels agents il souhaite travailler et peut imposer une identification pour accéder à certains services.
La différence est donc essentielle. Un agent peut choisir de ne pas révéler son identité, mais le propriétaire d’un service peut décider que l’accès à certaines fonctionnalités nécessite justement cette identification.
Le véritable enjeu concerne les essais gratuits et les crédits
Cette question devient particulièrement importante pour les entreprises qui proposent des essais gratuits, des crédits de bienvenue ou des remises.
Ces modèles commerciaux reposent généralement sur une hypothèse simple : une personne ou une organisation crée un compte et bénéficie d’un avantage limité dans le temps. Avec des agents autonomes, cette logique devient beaucoup plus difficile à contrôler. Un même humain peut potentiellement créer ou piloter plusieurs agents. Sans identité stable, un agent peut donc être difficile à distinguer d'un autre lorsqu’il réclame une promotion, un crédit ou une période d’essai.
Cloudflare reconnaît directement ce problème dans sa présentation du projet. L’entreprise souligne qu’il est facile d’accorder une période d’essai à un humain ou à une organisation, mais beaucoup plus difficile de faire la même chose à un agent sans identité stable.
La question ne concerne donc pas uniquement la facturation. Elle touche aussi les règles commerciales les plus courantes du web : offres de bienvenue, parrainage, remises sur une première commande ou paliers d’utilisation.
Pour les entreprises, les conditions générales d’utilisation devront probablement préciser ce qui est considéré comme un compte, un utilisateur ou un agent autorisé à bénéficier de ces avantages.
Un web déjà largement automatisé
Le contexte rend cette évolution particulièrement importante. Selon Cloudflare Radar, les bots représentaient 60,6 % des requêtes vers des contenus HTML sur les sept jours précédant le 10 août 2026, contre 39,4 % pour les humains. Ce chiffre ne mesure pas directement le trafic généré par les agents IA : il englobe notamment les crawlers et les scanners. Il constitue donc plutôt une indication de l’importance globale du trafic automatisé.
Mais la tendance est claire. Le web n’est déjà plus un environnement où chaque requête correspond à une personne derrière un navigateur. Les agents IA ajoutent une nouvelle catégorie à cette automatisation. Ils peuvent non seulement consulter une page, mais aussi prendre des décisions, enchaîner plusieurs requêtes et effectuer des transactions.
L’identité devient alors un moyen de distinguer différents comportements. Un agent qui s’identifie et agit à l’échelle d’un utilisateur peut être traité différemment d’un agent qui refuse toute identification tout en envoyant des requêtes à grande échelle.
Les entreprises devront adapter leurs règles
Pour les sites et les services en ligne, le sujet n’est donc pas simplement de décider s’il faut autoriser ou bloquer les agents IA.
Plusieurs situations peuvent être distinguées :
- Un agent qui déclare l’organisation qu’il représente et se comporte comme un utilisateur classique peut être servi dans les mêmes conditions, voire bénéficier d’un traitement privilégié si l’identification apporte une garantie supplémentaire.
- Un agent qui ne déclare pas son identité mais reste dans un comportement comparable à celui d’un utilisateur peut continuer à être traité selon les règles existantes.
- En revanche, un agent non identifié qui fonctionne à une échelle clairement automatisée peut être soumis aux mécanismes de limitation déjà utilisés contre les bots.
La situation devient encore plus sensible lorsqu’un agent réclame un essai gratuit, un crédit ou une remise. Dans ce cas, le service peut exiger le même niveau d’identification que celui demandé à une personne ou à une organisation.
Cette distinction permet aux entreprises de ne pas confondre absence d’identité et comportement abusif. Un agent anonyme n’est pas nécessairement malveillant. En revanche, son accès à certains avantages peut légitimement dépendre de sa capacité à établir son éligibilité.
Ce que les Wallets ne permettent pas encore
Malgré l’annonce, il faut se garder de présenter les Wallets comme une infrastructure déjà opérationnelle à grande échelle.
Cloudflare indique en effet que les principales fonctions de paiement arriveront ultérieurement. Le Monetization Gateway reste également associé à une liste d’attente. Il n’existe donc pas encore de disponibilité générale, de grille tarifaire publique détaillée ou de grande entreprise cliente présentée comme contrepartie payante du système.
Le rôle exact de Cloudflare dans la gestion des fonds mérite également d’être surveillé. Pour le nouveau modèle, le règlement doit se faire directement vers le portefeuille du vendeur et Cloudflare ne se présente pas comme intermédiaire dans le règlement.
Les prochaines étapes seront donc déterminantes pour comprendre les frais, les partenaires financiers, les stablecoins retenus, les réseaux utilisés et les conditions d’accès au service.
