Résumé

  • Dans Pay Per Crawl, l'événement facturable est une requête authentifiée, assortie d'une intention de payer, qui reçoit une réponse réussie marquée crawler-charged. C'est une preuve de livraison payante, pas une preuve de citation, d'entraînement ou de valeur créée.
  • Cloudflare reconnaît désormais que le nombre de collectes mesure mal l'utilité. Ses essais Pay Per Use déplacent le déclencheur : Ceramic.ai rémunère l'apparition d'un contenu dans un résultat, tandis que You.com permet à un agent d'acheter un élément premium au moment du besoin.
  • Bot Preference Sync, annoncé le 21 août, aligne les choix Search, Agent et Training du tableau de bord avec robots.txt. L'écart entre politique déclarée et règle exécutée se resserre, sans faire disparaître le besoin d'une preuve d'usage en aval.
  • Monetization Gateway reste un projet en accès anticipé. Cloudflare ne publie ni date de disponibilité générale, ni volume, ni revenus éditeurs, ni tarif propre au produit ; la croissance du groupe ne vaut donc pas validation commerciale de ce marché.

Un prix à la porte ne mesure pas la valeur dans la pièce

Le dispositif Pay Per Crawl donne à l'éditeur trois décisions par robot : autoriser, facturer ou bloquer. Un robot identifié peut découvrir le prix au moyen d'une réponse 402 Payment Required, puis revenir en acceptant ce montant. Il peut aussi annoncer dès sa première requête le maximum qu'il est prêt à payer.

Le fait comptable est précis. Après vérification de l'identité, de la règle et du prix, le contenu est livré avec une réponse réussie comportant crawler-charged. Cloudflare dit enregistrer ces événements, débiter le robot et redistribuer le produit à l'éditeur en qualité de Merchant of Record. Si le robot n'a pas de relation de facturation avec Cloudflare, l'option « facturer » agit en pratique comme un blocage ; aucune créance magique n'apparaît.

Cette mécanique transforme une intention vague en reçu exploitable : qui a demandé quoi, à quel prix, et si la ressource a été servie. Elle ne suit pas la ressource après la porte. L'acheteur a-t-il cité le texte ? L'a-t-il utilisé pour répondre à mille questions, l'a-t-il conservé pour la recherche, ajouté à un entraînement ou simplement jeté ? Le même reçu d'accès est compatible avec chacune de ces suites.

Cloudflare le dit sans détour dans son passage de Pay Per Crawl à Pay Per Use : la collecte est une mesure grossière. Une page peut être collectée une fois et alimenter des milliers de réponses ; une autre peut être collectée sans jamais servir. Le prix de l'entrée et la valeur de l'usage appartiennent donc à des chronologies différentes.

Dire, faire respecter, identifier

Avant même le paiement, trois preuves doivent s'enchaîner. Le propriétaire publie une préférence. Le réseau applique une règle. Le demandeur prouve son identité et son objet.

Bot Preference Sync, annoncé le 21 août, traite le premier décalage. Les choix de la zone Cloudflare concernant Search, Agent et Training sont répercutés dans robots.txt, sans effacer les interdictions déjà présentes. L'entreprise constate qu'un fichier et une règle de blocage peuvent se contredire ; certains robots utilisent alors cette incohérence pour ignorer la préférence ou contourner le contrôle.

La synchronisation améliore la cohérence du dossier, pas son périmètre. La liste est alimentée par les robots suivis dans BotBase et porte sur des catégories. Elle ne lit pas automatiquement les exceptions contractuelles ou les règles sur mesure appliquées robot par robot. Un éditeur qui autorise un partenaire sous licence tout en refusant sa catégorie générale doit encore gouverner cette exception.

L'identité ajoute une seconde discipline. Pay Per Crawl prévoit des requêtes signées par Web Bot Auth. Pour qu'un opérateur mêlant Search et Training bénéficie d'un traitement distinct malgré un refus d'entraînement, Cloudflare exige davantage : respecter la préférence, offrir une sortie des résumés IA, donner une visibilité URL par URL et montrer que le refus d'entraînement ne dégrade pas la recherche traditionnelle. Ces engagements rendent la déclaration d'objet plus vérifiable. Ils ne permettent toujours pas au réseau d'observer seul toutes les utilisations ultérieures d'un modèle.

Le 15 septembre changera un rapport de force

Le communiqué de juillet sur les nouvelles classifications fixe au 15 septembre 2026 l'échéance de la nouvelle politique. Dans cette version, les nouveaux sites devaient rester ouverts à Search, mais bloquer Training et Agent sur les pages financées par la publicité. Les robots mixtes incapables de séparer leurs usages devaient être bloqués sur ces pages, avec une modification également prévue pour les clients gratuits existants n'ayant rien choisi.

La publication d'août précise un parcours un peu différent : un éditeur ou site publicitaire peut choisir à l'inscription un défaut Disallow pour Training ; un autre type de site démarre sans blocage ; les utilisateurs de l'ancien robots.txt géré seront invités à valider leur migration. Le bon usage de ces textes n'est pas de prétendre que l'état final est déjà connu. Il faudra vérifier la matrice réellement active après le 15 septembre, les dérogations des clients et la réponse des robots mixtes.

Ce changement compte parce que Cloudflare occupe une position de distribution. Dans son bilan d'un an, le groupe affirme que 52 % des requêtes de robots observées sur son réseau en juin 2026 relevaient de l'entraînement, contre 22 % au printemps 2025, et que les robots mixtes dépassaient 36 % de l'activité. Il affirme aussi se trouver devant plus de 20 % du web. Ce sont des mesures Cloudflare, pas un recensement mondial. Elles indiquent néanmoins qu'un défaut appliqué à cette frontière peut créer une rareté et modifier la négociation.

Un blocage ou une obligation de séparer les usages produit du levier. Il ne produit pas encore le règlement, et encore moins la licence.

Le registre d'usage demande un autre témoin

Les essais avec Ceramic.ai et You.com déplacent le moment de facturation. Ceramic.ai propose de rémunérer l'éditeur lorsque son contenu apparaît dans les résultats, avec des informations sur la requête, la page, l'extrait et la position. Dans l'exemple You.com, l'agent achète à la demande une ressource premium précise.

Le signal est plus proche de l'utilité que le simple téléchargement. Il est aussi plus discutable. Une réponse qui assemble cinq sources doit-elle partager le prix à parts égales ? Une citation visible démontre-t-elle une contribution causale ? Comment traiter deux pages presque identiques, une attribution manquante ou un résultat généré à partir d'un cache ? Faut-il facturer la requête, le résultat, le succès de la tâche, le nombre de jetons ou une période de licence ?

Cloudflare ne tranche pas encore. L'entreprise parle d'expériences Pay per Query, Pay per Result et d'autres modèles. Cette pluralité est un signe de recherche du bon dénominateur, pas un défaut de présentation. Un accès se compte facilement mais corrèle mal avec la valeur ; un résultat se rapproche de la valeur mais dépend des journaux internes de l'acheteur.

Le tableau Attribution Business Insights fournit aux clients Bot Management les accès réussis, les ratios collecte-référence, la bande passante, l'opérateur et la catégorie comportementale. Il réduit l'asymétrie lors d'une négociation. Une observation au niveau du réseau ne reconstitue cependant pas un corpus d'entraînement ni le chemin complet d'une réponse.

x402 étend le catalogue avant d'établir le chiffre d'affaires

Le Monetization Gateway annoncé par Cloudflare viserait les pages, les jeux de données, les API et les appels d'outils MCP. Un client recevrait une instruction x402, paierait en stablecoins, renverrait une preuve et ne franchirait la périphérie qu'après vérification. Les règles pourraient varier selon la route, la méthode ou la complexité, puis être gérées dans le tableau de bord, par API ou Terraform.

Pour une petite ressource numérique, cela peut éliminer le coût disproportionné d'un compte, d'une clé et d'un abonnement. Le vendeur garde la demande non payée loin de son origine ; l'agent acquiert une seule unité au moment voulu. Cloudflare réunit identité, règle, vérification du paiement et livraison sur un même plan de contrôle.

Mais il s'agit encore d'un futur. La source renvoie vers une liste d'attente. Elle ne donne pas de date de disponibilité générale, de volume de production, de délai réel par percentile, de recette nette pour les vendeurs, de commission Cloudflare, de régime de remboursement ou de détail opérationnel sur les actifs et juridictions. L'objectif d'un règlement en moins d'une seconde n'est pas une statistique de service.

Les comptes du groupe ne permettent pas davantage d'anticiper la conversion. Cloudflare a publié un chiffre d'affaires trimestriel de 696,1 millions de dollars, en hausse de 36 %, avec 56,4 millions de dollars de flux de trésorerie disponible. Son 10-Q précise que l'abonnement et le support représentent presque tout le chiffre d'affaires et que la contrepartie variable mentionnée vient surtout de la bande passante excédentaire. Aucun client, revenu ou engagement restant n'est isolé pour les trois initiatives. La solidité de l'activité existante n'est pas le reçu d'une nouvelle place de marché.

Réconcilier sans confondre

Le premier registre devra rapprocher les demandes payantes, les livraisons réussies, le produit net des éditeurs, les délais, les échecs et les litiges. Le second devra relier une requête ou une tâche à la ressource qui a contribué, au droit concédé, à l'attribution et au paiement correspondant.

Le protocole HTTP peut transporter un prix et une preuve de paiement. Il ne rédige pas silencieusement un contrat de licence. Une réponse 200 après un 402 ne constitue à elle seule ni un consentement à l'entraînement, ni un droit de redistribution, ni la preuve qu'une valeur a été créée. Cloudflare rend le registre d'accès crédible. Son évolution vers Pay Per Use reconnaît que le registre d'usage exige une autre preuve.

Sources