// analyse
Cloudflare : qui compte les usages que les IA doivent payer ?
Sujets et garanties de lectureProfondeur 2 · 3 niveaux détectés
Garanties de lecture
Niveaux de preuve
Profondeur 2 : référence · 3 niveaux détectés
Sommaire et notions13 étapes · 2 notions
Analyse complète
Un article peut nourrir une réponse d’IA sans que son lecteur visite le site qui l’a publié. Cloudflare, fournisseur d’infrastructure web, veut organiser un paiement à cette étape, lorsque le contenu sert dans un autre produit. Sa bêta Pay Per Use, annoncée le 30 septembre 2026, propose une relation commerciale : une entreprise d’IA définit un usage rémunéré et son prix, l’éditeur accepte l’offre, puis les utilisations déclarées alimentent la facturation. 1
Le mécanisme donne une possibilité supplémentaire aux producteurs d’information. Il déplace aussi une question essentielle : qui peut vérifier combien de fois leur travail a réellement été utilisé ? Dans le dispositif décrit par Cloudflare, les événements viennent de l’acheteur. La plateforme vérifie leur rattachement à un éditeur inscrit. Cette validation et le contrôle de l’exhaustivité des usages sont deux opérations différentes. L’annonce publique documente la première, sans présenter un audit indépendant systématique de la seconde. 1
Au 2 novembre 2026, le corpus consulté permet de reconstruire les circuits techniques et les conditions affichées. Il ne fournit pas de montant agrégé vérifié des reversements Pay Per Use, de revenu médian par éditeur ou de barème universel de frais. C’est à cet endroit que se situe l’enquête : comprendre les conditions d’un marché viable avant de lui attribuer un rendement. 1, 2
Le clic perd sa place dans l’échange
L’ancien échange entre un moteur de recherche et un éditeur reposait sur une circulation : le moteur explorait le site, puis lui envoyait des lecteurs. Une réponse rédigée directement dans l’interface du moteur peut modifier cette circulation. L’enjeu économique dépend alors du nombre de visites conservées, de leur valeur et des recettes que l’éditeur pourrait percevoir ailleurs.
Une étude de Pew Research Center offre un point de repère, avec un périmètre précis. Elle porte sur la navigation de 900 adultes américains en mars 2025. Lorsqu’un résumé d’IA apparaissait, un clic vers un résultat classique suivait 8 % des visites de recherche, contre 15 % en son absence. Les liens inclus dans le résumé recevaient un clic dans 1 % des visites comportant ce résumé. Ce dernier chiffre concerne une autre famille de liens. 10
Méthode et périmètre
Pew Research Center, publication du 22 juillet 2025. Navigation de 900 adultes américains en mars 2025 ; résultats de recherche collectés du 7 au 17 avril. Clic vers un résultat classique : 15 % des visites sans résumé et 8 % avec résumé. Le taux de 1 % porte sur les liens du résumé, parmi les visites avec résumé. Les requêtes diffèrent entre groupes ; ces associations observationnelles ne quantifient aucune perte causale de recettes.
L’étude décrit une association, avec des requêtes qui peuvent différer entre les groupes. Les résultats ont été collectés du 7 au 17 avril, après la période de navigation. Pour évaluer une perte de revenus chez un média français, il faudrait mesurer son propre trafic, la valeur de ses visites et les autres facteurs qui les font évoluer. 10
Le déplacement du paiement vers l’usage répond à cette difficulté : un contenu peut avoir de la valeur pour l’outil qui le mobilise, même lorsque son auteur perd la visite. Reste à définir la partie de cette valeur que l’acheteur accepte de partager, et l’événement qui déclenche le règlement.
Trois produits, trois événements facturés
Cloudflare emploie plusieurs dispositifs qu’il faut distinguer pour suivre l’argent. Pay Per Crawl facture l’accès réussi à un contenu. Lancé en bêta privée le 1er juillet 2025, il reste présenté comme une bêta fermée dans la documentation consultée. Un robot identifié peut rencontrer une réponse HTTP 402 indiquant qu’un paiement est nécessaire ; une récupération payante réussie donne lieu à facturation. 3, 4, 18, 20
L’éditeur dispose d’un prix par défaut et peut utiliser une tarification dynamique selon l’URL ou le contenu. Le minimum documenté est de 0,001 dollar par crawl. Ce plancher appartient à Pay Per Crawl : il ne renseigne ni le prix moyen accepté par les acheteurs ni les tarifs de Pay Per Use. Les règles de sécurité de Cloudflare restent prioritaires sur la consigne de facturer. 4, 5, 6
Le code 402 joue le rôle d’un signal. Dans la spécification HTTP, il demeure réservé pour un usage futur ; les conditions d’accès et le règlement viennent des protocoles et des accords construits autour de lui. Pour Pay Per Crawl, Cloudflare agit comme intermédiaire de vente, ou merchant of record, et décrit des reversements mensuels au moyen d’un compte Stripe Connect dédié, soumis aux conditions de règlement applicables. 4, 7, 8
Pay Per Use choisit un événement ultérieur : l’usage facturable couvert par le programme d’un acheteur. Monetization Gateway, également annoncé en bêta le 30 septembre 2026, vise les interfaces permettant à des logiciels d’échanger des requêtes et des réponses (API), les données et les outils dont chaque requête constitue déjà une consommation. Son lancement décrit x402 et un règlement en USDC sur Base, avec Coinbase comme facilitateur. La bêta initiale concerne les acteurs américains éligibles. Cette architecture ne doit être transposée ni à Pay Per Use ni à un éditeur français sans vérifier ses conditions d’accès. 1, 16
Méthode et périmètre
Schéma fonctionnel, sans volumes observés. Pay Per Crawl, lancé en bêta privée le 1er juillet 2025, concerne les récupérations réussies. Pay Per Use, annoncé en bêta le 30 septembre 2026, repose sur un usage défini par le programme et déclaré par l’acheteur. Monetization Gateway vise les API, outils et données ; sa bêta du 30 septembre décrit x402 et USDC sur Base pour des acteurs américains éligibles. Prix, licences, disponibilité et circuits de règlement sont propres à chaque produit.
Le choix dépend de l’objet vendu. Une requête vers une API peut produire immédiatement le service demandé. Une page web peut être explorée, conservée dans un index, ignorée pendant des mois ou réutilisée de nombreuses fois. Les deux compteurs peuvent donc évoluer dans des directions opposées.
Une copie peut servir cent fois
Prenons un exemple volontairement normalisé. Un premier service récupère cent fois un contenu, mais ne l’utilise qu’une fois dans une expérience couverte. Un second le récupère une fois, puis l’utilise cent fois. Avec un tarif fictif d’une unité monétaire par événement, l’accès et l’usage donnent des factures inverses. [Calcul l0g]
Méthode et périmètre
Construction pédagogique l0g : le service A récupère le contenu 100 fois et l’utilise une fois ; le service B le récupère une fois et l’utilise 100 fois. Un point représente un événement fictif. Avec un tarif normalisé d’une unité monétaire par événement, les factures valent respectivement 100 et 1 unités pour l’accès, puis 1 et 100 pour l’usage. Volumes et prix hypothétiques, hors frais ; les sources décrivent uniquement les mécanismes.
Cet exemple ne reproduit aucun trafic observé. Il montre pourquoi le nombre de requêtes au serveur fournit une base économique différente de celle des utilisations dans une réponse. La fréquence d’actualisation, la politique de cache (les copies conservées pour être réutilisées) et la nature du service déterminent une partie de l’écart.
Facturer chaque exploration fait supporter à l’acheteur le coût des contenus qu’il examine puis écarte. Rémunérer l’usage lui permet d’attendre que la valeur apparaisse. C’est l’argument commercial de Cloudflare pour attirer davantage d’acheteurs. L’éditeur prend, en contrepartie, une exposition à la définition contractuelle de l’usage et à sa mesure. 1
Une mention dans une liste de résultats, un extrait restitué et une information intégrée à une recommandation correspondent à des événements différents. Un prix élevé portant sur un événement rare peut rapporter moins qu’un petit prix sur un périmètre large. Pour comparer deux offres, l’éditeur doit connaître le dénominateur autant que le tarif.
Le compteur se trouve chez l’acheteur
Dans la bêta Pay Per Use, l’entreprise d’IA transmet un événement comportant la date d’utilisation, l’URL source et un identifiant. Cloudflare agrège les déclarations, facture l’acheteur et prévoit un paiement mensuel aux éditeurs. Selon Cloudflare, les conditions du programme imposent une déclaration complète. 1
L’identité vérifiée du robot aide à savoir à qui ouvrir la porte. L’URL permet de rattacher une déclaration à un participant. Aucune de ces informations, prise isolément, ne décrit toutes les opérations effectuées ensuite dans les systèmes de l’acheteur. Le contenu peut circuler entre un index, un cache et un générateur de réponses. La complétude réelle des déclarations demande une vérification supplémentaire ; les documents publics examinés gardent cette question ouverte. 1, 18
Le 16 octobre 2026, Cloudflare a décrit un suivi interne du comportement des robots vérifiés, notamment leur respect de robots.txt et leur réaction aux réponses HTTP 429 de limitation du débit. Les scores publics et les seuils choisis par les clients sont présentés comme des étapes à venir. Ce suivi de l’accès observé par Cloudflare laisse entière la question de l’exhaustivité des usages Pay Per Use dans les systèmes de l’acheteur. 21
Méthode et périmètre
Schéma du circuit décrit dans l’annonce Pay Per Use du 30 septembre 2026, avec l’identification du robot comme étape d’accès. Le contenu circule dans les systèmes de l’acheteur, qui déclare l’URL, la date et un identifiant. Le rattachement du relevé à un participant et la vérification de l’exhaustivité des usages sont des contrôles distincts. Les contrôles comportementaux annoncés le 16 octobre concernent notamment l’accès, robots.txt et les réponses 429 ; leur périmètre reste distinct de l’observation exhaustive des usages en aval. La figure n’attribue aucun taux de sous-déclaration et ne représente aucun audit indépendant systématique comme acquis.
Une comparaison sérieuse entre programmes devrait donc examiner leur définition du fait générateur, le traitement des répétitions, la conservation des journaux et les procédures de contestation. L’éditeur pourrait chercher à obtenir des vérifications sur échantillon ou une attestation indépendante. Ce sont ici des critères d’évaluation proposés, et non des fonctionnalités universelles confirmées de la bêta.
Les contrôles soulèvent également une question de confidentialité. Vérifier la contribution d’une source à une réponse ne nécessite pas automatiquement de transmettre à l’éditeur la conversation complète de l’utilisateur. Cloudflare annonce travailler sur davantage de contexte, comme les sujets ou les mots-clés, sans échange de données personnelles. La portée opérationnelle de ces protections doit être appréciée dans les conditions du programme effectivement proposé. 1
La différence entre revenus estimés, montants facturés et argent encaissé mérite enfin de rester visible. Le nombre d’événements validés constitue une étape ; les annulations, contestations éventuelles, frais et délais de paiement influencent la trésorerie finale. Un tableau de bord utile doit permettre ce rapprochement plutôt que laisser un montant d’usage tenir lieu de relevé bancaire.
Le robot peut aussi repartir
Un retour d’expérience de Stack Overflow fournit un contrepoint particulièrement concret. Dans un entretien publié le 19 février 2026, l’ingénieur Josh Zhang explique que certains robots ont cessé leurs requêtes après l’affichage d’une réponse 402, là où ils recevaient auparavant un refus 403. 9
Ce témoignage vient d’un partenaire commercial, dans une discussion avec Cloudflare. Il ne constitue ni une mesure représentative du marché ni un bilan financier du programme. Il rappelle toutefois une option élémentaire de l’acheteur : renoncer à l’accès. Un contrôle qui réduit une consommation indésirable peut avoir atteint son objectif technique sans créer une vente. 9
Cloudflare mentionnait en juillet 2026 des expérimentations avec Ceramic.ai et You.com, autour de la présence d’un contenu dans des résultats ou de l’accès à des sources premium. Ces exemples documentent des pistes commerciales. Ils ne donnent pas le nombre d’acheteurs payants de la bêta de septembre, leurs volumes réglés ou les recettes de chaque éditeur. 2, 11
La valeur de négociation paraît plus forte lorsqu’une information est récente, précise et difficile à remplacer. Il s’agit d’un mécanisme économique plausible : l’acheteur compare le coût d’accès au coût de chercher une autre source, au risque d’une réponse moins fiable ou à la possibilité de renoncer. Une exclusivité locale et une reprise générique d’un communiqué ne posent pas le même problème de substitution. Le corpus public ne permet pas encore de chiffrer ce différentiel.
Du tarif affiché au revenu d’une rédaction
Un modèle simple permet de repérer les paramètres décisifs sans fabriquer une prévision. Imaginons, sur un mois fictif, un million d’utilisations potentielles. Seules 20 % entrent finalement dans le périmètre participant, facturable, déclaré et validé. À 0,002 dollar par événement, la recette brute atteint 400 dollars.
En appliquant une hypothèse de 10 % de déductions agrégées et 100 dollars de coûts additionnels, il reste 260 dollars. Les 10 % sont une hypothèse de calcul, à distinguer des frais applicables à une offre Cloudflare. Le prix est lui aussi une hypothèse Pay Per Use, distincte du minimum Pay Per Crawl. [Calcul l0g]
Méthode et périmètre
Hypothèses l0g en dollars US nominaux sur un mois fictif : U = 1 000 000 usages potentiels, a = 20 % couverts, q = 0,002 dollar par événement, f = 10 % de déductions agrégées et K = 100 dollars de coûts additionnels. Événements facturables = U × a = 200 000 ; brut = 400 dollars ; après déductions = 360 ; contribution nette avant fiscalité = 260. La couverture regroupe plusieurs filtres, et le taux de déduction est une hypothèse pédagogique distincte des frais réels de Cloudflare.
Comparons cette contribution à un autre scénario explicite : 50 000 visites humaines de moins, chacune contribuant en moyenne à hauteur de 10 dollars nets pour mille visites. L’enjeu serait de 500 dollars. Cette hypothèse n’est dérivée ni de Pew ni du trafic de l0g. Elle sert à comparer deux flux définis sur le même mois et dans la même devise.
Pour atteindre ces 500 dollars après les déductions et les coûts additionnels du modèle, le prix doit s’élever à environ 0,00333 dollar par événement facturable, à couverture inchangée. Au prix initial de 0,002 dollar, la part couverte devrait atteindre un tiers des usages potentiels. Les équations, les données et un atelier de calcul accompagnent l’article. [Calcul l0g]
Méthode et périmètre
Calcul l0g : contribution nette = U × a × q × (1 − f) − K. U = 1 000 000 par mois fictif, f = 10 % et K = 100 dollars ; cible B = 50 000 visites hypothétiquement perdues × 10 dollars par mille visites = 500 dollars. Le prix par mille événements facturables satisfaisant la cible vaut 1 000 × (B + K) / [U × a × (1 − f)]. À 20 % de couverture : 3,333… dollars pour mille ; à un tiers : 2 dollars. Axe des couvertures de 5 % à 100 %. Les volumes sont tenus constants, avec des paramètres entièrement fictifs ; aucune élasticité de demande, prévision de revenus ou perte causale issue de Pew n’est estimée.
l0g / CLOUDFLARE / ATELIER DE REVENUS
Comparer le revenu des usages à une perte de visites
Explorez deux contributions sur un même mois fictif, en dollars américains. Chaque réglage est une hypothèse pédagogique indépendante des tarifs et revenus réels de Cloudflare.
Modifier les sept hypothèses
SCÉNARIO PÉDAGOGIQUE : un million d’usages possibles, 20 % couverts, 0,002 $US par usage, 10 % de déductions et 100 $US de coûts. La référence suppose 50 000 visites perdues à 10 $US pour mille visites.
- Contribution des usages avant fiscalité
- Référence des visites humaines
- Écart à la référence
La contribution des usages reste inférieure à la référence des visites dans ce scénario.
Détail des recettes et des seuils
- Usages facturables attendus
- Recette brute
- Recette après déductions
- Prix nécessaire à couverture inchangée
- Couverture nécessaire à prix inchangé
Le seuil de couverture est compris entre 0 et 100 % des usages possibles.
Calcul et périmètre
U désigne les usages possibles, a la part couverte, p le prix, f les déductions et K les coûts additionnels. L et r définissent la référence de visites H. Les pourcentages sont convertis en fractions pour le calcul. Un objectif et des coûts nuls donnent un seuil de zéro ; une cible positive avec une base nulle laisse le seuil indéfini.
N = U × a × p × (1 − f) − K
H = L × r / 1 000
p* = (H + K) / [U × a × (1 − f)]
a* = (H + K) / [U × p × (1 − f)]
Le taux de couverture agrège plusieurs filtres commerciaux et techniques ; il ne mesure pas la fraude. Les volumes restent constants quand le prix change. La réaction des acheteurs, la fiscalité et les délais d’encaissement restent hors du modèle. Les résultats sont des contributions mensuelles hypothétiques, avant fiscalité. Le signe ≈ indique un arrondi ; les très petits montants restent visibles en notation scientifique.
Le calcul s’effectue sur votre appareil, dans cette page. Les réglages restent en mémoire pendant son ouverture.
La part de 20 % regroupe plusieurs filtres. Les utilisations restantes peuvent provenir d’acheteurs hors programme ou d’événements exclus par la licence. Cette part décrit des filtres commerciaux ; mesurer la fiabilité du déclaratif exigerait une autre collecte. Quant à la hausse du prix, elle peut faire reculer la demande : le simulateur garde les volumes constants pour isoler une sensibilité, sans estimer la réaction des acheteurs.
L’échelle individuelle compte. Une solution commune peut rendre rentables de petits paiements qu’un contrat négocié séparément absorberait en frais. Mais un tarif attractif sur quelques milliers d’événements ne suffit pas à financer une production éditoriale coûteuse. La question devient celle du volume couvert, des coûts de suivi et de la durée de la relation commerciale.
Séparer les réponses d’IA de la recherche classique
Le pouvoir de négociation dépend aussi des choix accessibles en dehors du programme. Sur ce point, l’histoire a changé en 2026. Google indique avoir généralisé mondialement, le 31 août, un contrôle Search Console permettant d’exclure son contenu et ses liens d’AI Overviews, d’AI Mode et des fonctions génératives concernées de Discover. Selon sa documentation, ce choix ne sert pas de signal de classement ou d’inclusion dans les autres parties de Search. 13, 19
L’éditeur renonce alors aux impressions et aux visites provenant de ces fonctions IA. L’entraînement reste géré séparément. Ce contrôle élargit le choix disponible ; il ne garantit ni trafic stable ni revenu compensatoire. Une présentation qui réduirait encore l’alternative à l’acceptation de toute utilisation IA ou à la disparition de la recherche classique serait dépassée. 13
Cloudflare a annoncé le 15 septembre des contrôles distincts pour la recherche, l’entraînement et les agents, ainsi qu’une désignation Accountable reposant sur des critères remplis ou des engagements assortis d’un calendrier. Le détail des fonctions effectivement déployées compte donc autant que le label. Le 30 octobre, Google a aussi annoncé viser 2027 pour un signal partagé d’entraînement issu des travaux de standardisation AIPREF. Ce dernier calendrier demeure prospectif. 12, 14
Ces préférences, la sécurité de l’accès et la facturation interviennent à des étages différents. Le standard de robots.txt rappelle qu’il ne remplace pas un contrôle de sécurité. Un signal de refus doit être lu par son destinataire ; un contrôle d’accès agit sur les requêtes reçues ; une licence précise les utilisations autorisées et payantes. Cette distinction aide à concevoir une protection cohérente sans prêter à un réglage technique le pouvoir de résoudre toutes les questions de droit d’auteur. 15
Cloudflare se place entre la source et le produit d’IA
Le meilleur argument en faveur du dispositif tient à sa coordination. Une petite publication peut difficilement négocier et maintenir une intégration avec chaque acheteur. Une infrastructure commune rapproche l’identification, l’inscription, le relevé des usages et le règlement. Si les coûts unitaires de cette coordination diminuent, des transactions auparavant trop modestes peuvent devenir possibles. C’est la promesse de marché qu’il faut tester. 1
Cloudflare est ainsi susceptible d’acquérir une place supplémentaire dans la relation entre producteurs et distributeurs de contenus. La sélection des acheteurs, la présentation des offres, les définitions retenues et les informations restituées aux éditeurs influencent la négociation. Cette position peut rendre le service utile tout en créant une dépendance. Ce constat analytique ne constitue pas une conclusion juridique sur un abus ou une position dominante.
D’autres acteurs poursuivent une logique voisine. Microsoft a présenté le 3 février 2026 son Publisher Content Marketplace, alors en pilote : licences de contenu, conditions d’usage définies par les éditeurs et reporting, avec des expérimentations dans Copilot. La comparaison publique permet d’identifier des architectures concurrentes. Elle ne permet pas de classer leur rentabilité pour un média sans connaître les offres concrètes, leurs frais et leurs volumes. 17
Dans la bêta Pay Per Use décrite en septembre, les acheteurs proposent la définition et le prix. Cloudflare évoque pour la suite des contre-offres et une différenciation plus fine selon le contenu et l’usage. Il faut conserver cette distinction entre choix disponibles et feuille de route : le droit de refuser une offre et le pouvoir d’en modifier les conditions ont des effets économiques différents. 1
Les preuves qui feraient de la promesse un revenu
Le bilan pertinent d’un tel marché devrait suivre des cohortes d’éditeurs sur plusieurs mois : acheteurs réellement actifs, définitions d’usage, recettes brutes, retenues, sommes encaissées et maintien des participants. La concentration des versements importe également. Un total élevé peut coexister avec des revenus très faibles pour la majorité des publications.
Il faudrait ensuite rapprocher la mesure des usages des garanties de contrôle : identifiants, règles de déduplication, délais de déclaration, corrections et droit de contestation. Ces éléments permettraient d’évaluer la solidité du compteur. Aucun des documents examinés ici ne suffit à établir un rendement représentatif du marché Pay Per Use. Cette absence publique laisse une question ouverte ; elle ne démontre pas une absence de paiements. 1, 2, 11
Cloudflare a documenté une infrastructure et une manière d’organiser l’échange. La création de valeur dépend maintenant de la volonté de payer des acheteurs, du périmètre rémunéré et de la confiance dans les relevés. Pour l’éditeur, le critère final demeure très concret : quelle contribution nette et vérifiable cette relation apporte-t-elle à la prochaine information qu’il pourra produire ?
Méthode et limites
Enquête documentaire arrêtée au 2 novembre 2026. Les descriptions des produits et de leurs contrôles proviennent de leurs fournisseurs et sont attribuées comme telles. Le témoignage Stack Overflow est celui d’un partenaire. L’étude Pew est observationnelle et porte sur 2025. Aucun entretien, accès à un compte commercial ou test en production n’a été réalisé.
Les scénarios utilisent des dollars américains nominaux sur un mois fictif. Tous leurs paramètres sont hypothétiques ; aucune statistique de trafic n’a été transformée en estimation des revenus de l0g ou d’un autre éditeur. Le modèle ignore la réaction de la demande aux prix, la fiscalité et les délais d’encaissement. Les sources évolutives sont datées dans le dossier documentaire ; les originaux sont accessibles par leurs URL complètes.
Repères. Un crawl est une récupération automatisée. Un usage rémunéré est l’événement défini par le programme commercial. Une API permet à des logiciels d’échanger des requêtes et des réponses. La contribution nette utilisée ici est une recette diminuée des déductions et coûts additionnels du modèle, avant fiscalité ; elle ne constitue pas le résultat comptable d’une entreprise.
Prolonger l’enquête
Les paiements des agents IA éclairent les rails de règlement et les mandats. Notre analyse de l’économie des intentions situe ces modèles dans la transformation de la publicité. Le prix d’accès aux données de recherche de Google permet de comparer un autre marché de données, ses conditions et ses coûts.
Sources
- Pay Per Use: when AI uses your work, you should get paid
Acheteur : définition, prix, déclaration. Éditeur : acceptation. Cloudflare : rattachement au domaine inscrit, facturation et paiements mensuels.
Passages et périmètre
Événement ou période : Bêta annoncée le 30 septembre 2026. Aucun audit indépendant de complétude ni montant global de reversement fourni dans cette annonce.
- Your Content, Your Rules
Pay Per Use ; partenaires Ceramic.ai et You.com.
Passages et périmètre
Événement ou période : Annonce et expérimentations de juillet 2026. Projets et partenariats annoncés, pas preuve de revenus encaissés par chaque éditeur.
- Introducing Pay Per Crawl (private beta)
Accès payant à chaque récupération et règlement via Stripe.
Passages et périmètre
Événement ou période : Lancement de la bêta privée. Statut historique de lancement.
- What is Pay Per Crawl?
Bêta fermée ; HTTP 200 ou 402 ; Cloudflare merchant of record ; priorité des règles de blocage WAF/Bot Management.
Passages et périmètre
Événement ou période : Date de mise à jour affichée. Documentation consultée, aucune activation en compte réel.
- Set a pay per crawl price
Plancher indiqué : 0,001 dollar US par crawl ; prix par défaut et option dynamique.
Passages et périmètre
Événement ou période : Date de mise à jour affichée. Plancher Pay Per Crawl seulement. Ni moyenne de marché ni tarif Pay Per Use.
- Advanced configuration
Exclusions par URI et prix dynamique via crawler-price/origine/Worker.
Passages et périmètre
Événement ou période : Date de mise à jour affichée. Un tarif unique immuable pour tout le domaine serait une description dépassée.
- Manage payouts
Stripe Connect dédié pour Pay Per Crawl ; charges agrégées ; paiements mensuels avec conditions.
Passages et périmètre
Événement ou période : Date de mise à jour affichée. Seuils et délais de règlement mentionnés sans chiffrage universel ; ne pas transposer automatiquement à Pay Per Use.
- RFC 9110, HTTP Semantics, §15.5.3
Le code HTTP 402 est réservé pour un usage futur dans cette spécification.
Passages et périmètre
Événement ou période : Spécification HTTP. Le code seul ne définit pas une infrastructure universelle de règlement.
- Why Stack Overflow and Cloudflare launched a pay-per-crawl model
Josh Zhang rapporte que certains bots ont arrêté leurs requêtes après passage du 403 au 402.
Passages et périmètre
Événement ou période : Entretien et retour d’expérience publiés. Source intéressée, pas étude représentative ni relevé de chiffre d’affaires.
- Google users are less likely to click on links when an AI summary appears
900 adultes américains, 68 879 recherches uniques ; 8 % vs 15 % de clics vers résultats classiques ; 1 % vers liens du résumé.
Passages et périmètre
Événement ou période : Navigation du 1 au 31 mars 2025 ; résultats collectés du 7 au 17 avril 2025. Association, requêtes différentes, résultats rejoués ultérieurement. Aucune perte de revenus causale calculable à partir de ces seuls taux.
- Making AI search smarter
Ceramic : paiement lié à présence en résultats ; You.com : contenu premium à la demande ; expérimentation explicitement reconnue.
Passages et périmètre
Événement ou période : Expériences annoncées en juillet. Aucun volume de paiements démontré par ces exemples.
- Cloudflare Helps End the Search-or-AI-Training Tradeoff
Contrôles séparés ; désignation Accountable et critères remplis ou engagements datés.
Passages et périmètre
Événement ou période : Évolution des contrôles annoncée. Ne pas transformer des engagements de déploiement en contrôles intégralement opérationnels partout.
- Search generative AI control
Exclusion des fonctions génératives Search, sans signal de classement dans les autres parties de Search ; entraînement séparé.
Passages et périmètre
Événement ou période : Note de disponibilité mondiale au 31 août 2026. Perte des liens et visites issus des fonctions IA en cas de retrait. Déclarations de Google, sans test indépendant réalisé ici.
- Supporting a shared AI training control for websites
Projet de signal commun dans robots.txt issu du travail AIPREF ; objectif de support en 2027.
Passages et périmètre
Événement ou période : Prise en charge visée en 2027. Préférence d’entraînement, pas paiement ; calendrier annoncé et standardisation encore en cours.
- RFC 9309, Robots Exclusion Protocol, §3
robots.txt ne remplace pas un contrôle de sécurité valide.
Passages et périmètre
Événement ou période : Spécification du protocole robots.txt. Ne tranche pas les droits de propriété intellectuelle ou obligations juridiques des IA.
- Monetization Gateway beta: charge AI agents for consumption with HTTP 402
Facturation de requêtes via x402 ; règlement présenté en USDC sur Base via Coinbase ; produit distinct de Pay Per Use.
Passages et périmètre
Événement ou période : Bêta fermée annoncée pour acteurs US éligibles. Conditions de la bêta au lancement, pas disponibilité générale en France.
- Building Toward a Sustainable Content Economy for the Agentic Web
Licence, usages définis par éditeurs et reporting ; pilote avec éditeurs et produits Copilot.
Passages et périmètre
Événement ou période : Pilote Publisher Content Marketplace. Source intéressée ; aucun rendement financier comparé démontré ici.
- Verify your AI crawler
Identification du robot participant et indication du prix dans la réponse HTTP.
Passages et périmètre
Événement ou période : Date de mise à jour affichée. Une identité authentifiée ne prouve pas chaque utilisation ultérieure du contenu.
- New opportunities, control and insights for website owners
Début du test du contrôle indépendant des fonctions IA Search.
Passages et périmètre
Événement ou période : Début du test annoncé en juin ; source 13 pour disponibilité ultérieure. L’annonce initiale ne suffit pas à établir le statut au 2 novembre.
- Pay Per Crawl FAQ
Chaque nouvelle récupération facturable peut être payante ; pas de facturation des réponses d’erreur.
Passages et périmètre
Événement ou période : Date de mise à jour affichée. Lire les évolutions de tarification dans la documentation plus récente de juillet.
- Continuous accountability for Verified bots
Cloudflare décrit un suivi interne de comportements répétés des robots vérifiés : respect des préférences robots.txt et réponse aux signaux directs, notamment HTTP 429. La publication décrit les scores publics et le choix de seuil par les clients comme des étapes futures.
Passages et périmètre
Événement ou période : Annonce de suivi comportemental interne ; scores publics et contrôles clients encore prévus. Observations des requêtes d’accès et du respect des préférences, selon le fournisseur ; aucune vérification exhaustive des événements Pay Per Use à l’intérieur des systèmes des acheteurs n’est établie par ce texte. Aucun audit indépendant ou test du produit réalisé ici.
// l’hebdo l0g
N° 14 · 1 nov.Les dossiers à retenir, leurs limites et les prochaines vérifications.
Lire la revue ↗Cet article ne constitue en aucun cas un conseil en investissement.
// historique des révisions
- publication
- révision
Les corrections substantielles suivent la politique de correction et sont consignées dans le changelog éditorial.
$ cd ..