Le 19 février 2026, Stack Overflow et Cloudflare ont dévoilé publiquement une annonce que la plupart des acteurs de l'industrie des données web n'avaient pas vue venir. Ils ont lancé conjointement le pay-per-crawl : un système dans lequel les robots d'indexation d'IA reçoivent une réponse 402 Payment Required en temps réel et peuvent soit payer le tarif fixé par l'éditeur, soit passer leur chemin. L'identité du bot est vérifiée à l'edge, le tarif est défini par le site et la transaction est mesurée.
Cloudflare protège environ un site web sur cinq dans le monde. En activant le blocage par défaut des bots d'IA identifiés et en mettant en place une place de marché où les éditeurs facturent à la requête, ils ont transformé en un week-end le modèle d'accès d'une part massive du web ouvert.
Si vous développez actuellement des infrastructures de données web, cette annonce de Cloudflare n'est pas à classer sans suite. Elle redéfinit l'équation même de ce que signifie le web « ouvert ».
Le mécanisme sous-jacent
Sur le plan technique, le changement est minime. Cloudflare a ressuscité le code de statut HTTP 402, « Payment Required », resté longtemps inexploité, pour le relier à un registre de crawlers d'IA vérifiés. L'éditeur fixe un prix par requête. Le crawler dispose d'un solde de crédits et paie, ou se retrouve bloqué.
Sur le plan stratégique, l'impact est bien plus large. Auparavant, les seules approches pour empêcher l'extraction de contenu pour l'entraînement d'IA étaient le fichier robots.txt (consultatif, non contraignant) et le blocage agressif des bots (binaire, générateur de pertes et de faux positifs). Cloudflare a introduit une troisième option : une tarification d'accès.
La dynamique économique de cette troisième option diffère nettement des deux premières. Le robots.txt ne coûte rien et se fait ignorer. Le blocage des bots vous coûte du trafic d'utilisateurs légitimes classés par erreur comme bots. Une tarification directe filtre, par conception, les crawlers prêts à payer de ceux qui ne le sont pas.
Qui facture réellement ?
Stack Overflow a été le partenaire de lancement car ses données d'entraînement possèdent une valeur concrète et que l'entreprise négociait déjà des accords bilatéraux avec OpenAI et d'autres acteurs. La place de marché de Cloudflare a généralisé ces accords bilatéraux sous la forme d'un registre accessible à l'ensemble des éditeurs.
La liste des entreprises qui ont emboîté le pas s'est rapidement allongée. AWS a déployé sa propre couche de monétisation des bots. Akamai en a développé une équivalente. L'argument présenté aux éditeurs est direct : plutôt qu'un procès coûteux contre un laboratoire d'IA, mettez en place une source de revenus récurrente facturée à la requête.
Pour le moment, cela concerne principalement les contenus à haute valeur ajoutée : documentation technique, actualités, plateformes de questions-réponses pour développeurs et données de référence structurées. La longue traîne du web (petits sites e-commerce, annonces régionales, forums de niche) ne dispose d'aucun mécanisme de ce type et n'en disposera probablement jamais. L'exécution de la gestion des bots de Cloudflare a un coût opérationnel, et le pay-per-crawl fonctionne sur la base du volontariat. Ce modèle n'est rentable que pour les sites dont l'affichage d'une seule page justifie une facturation.
Ce que cela implique pour les pipelines de données web
Si vous construisez un pipeline qui extrait des données de Stack Overflow, de grands sites d'actualités ou de n'importe quel éditeur en cours d'intégration, vos options se réduisent à trois. Payer via la marketplace dès que votre trafic est identifiable comme un crawler IA. Passer à un jeu de données sous licence lorsqu'il en existe un. Ou trouver les données là où elles sont encore ouvertes.
La plupart des équipes finiront par combiner ces trois approches à différents moments. C'est la réalité pratique. Le web se divise entre contenu sous licence et contenu ouvert, et la frontière ne suit pas proprement les noms de domaine. Un même éditeur peut placer une section derrière un code 402 et laisser une autre section ouverte. Le même site peut facturer un crawler spécifique et ignorer complètement un bot de recherche.
Selon nous, la réaction pratique pour les équipes d'ingénierie se résume ainsi. D'abord, auditez vos sources. Si une part significative de votre pipeline extrait des données de Stack Overflow, de Reddit, de grands sites d'actualités ou de l'un des nombreux éditeurs cherchant visiblement ces accords, partez du principe que le modèle d'accès changera d'ici douze mois. Ensuite, séparez très tôt les sources sous licence des sources ouvertes au sein de votre architecture. Un pipeline qui traite chaque source de manière identique devient fragile quand la moitié d'entre elles commence à demander un paiement et que l'autre moitié ne le fait pas. Enfin, cessez de considérer le fichier robots.txt comme le seul signal. La réponse 402 aura un impact opérationnel même si votre crawler n'est pas un agent IA. Les faux positifs sont inévitables dans un système aussi récent.
Cela s'ajoute à la pression de conformité sur les données d'entraînement imposée par l'EU AI Act, qui poussait déjà les équipes vers des sources à la traçabilité garantie. Le pay-per-crawl applique la même pression, avec une couche de facturation en plus.
Notre analyse
Plusieurs aspects vont poser problème. La vérification d'identité de Cloudflare repose sur l'enregistrement des bots. Les bots qui ne s'enregistrent pas, ou qui ressemblent à du trafic résidentiel, ne déclenchent pas du tout de code 402. Ils se heurtent plutôt à la détection de bots standard. C'est déjà la voie que suivront la plupart des crawlers IA agressifs. Le pay-per-crawl fonctionne donc pour les bots qui souhaitent se conformer. Ceux qui s'y refusent n'allaient de toute façon jamais respecter robots.txt.
Le changement majeur n'est peut-être pas la marketplace elle-même. C'est le fait que déterminer si ce contenu est disponible pour l'entraînement d'IA est devenu une question avec une réponse contractuelle, et non plus une supposition basée sur robots.txt. Les éditeurs peuvent enfin faire appliquer leurs règles. Les crawlers peuvent enfin savoir. La zone grise rétrécit là où la marketplace s'étend.
Ce qui reste flou, c'est tout ce qui se trouve en dehors. Le petit site sans Cloudflare, l'agrégateur régional sans stratégie IA, la longue traîne du web que personne ne négocie: ceux-là n'affichent pas de 402 et n'obtiennent pas non plus d'accord de licence. Ils conservent leur politique d'accès précédente, simplement avec des protestations plus fortes maintenant qu'un précédent de rémunération existe.
Les perspectives d'évolution
Deux prédictions, et elles ne sont pas sans risque.
Premièrement : les douze prochains mois verront apparaître un second niveau de paywall, cette fois pour les bots non liés à l'IA. Le mécanisme de marketplace repose simplement sur un code de statut HTTP et une couche de facturation. Il n'est pas techniquement difficile de l'étendre à la tarification des crawlers de recherche, des bots d'archivage ou du monitoring concurrentiel. La décision des éditeurs de se limiter à la facturation des crawlers d'IA dépendra du comportement de la prochaine vague. La plupart du temps, cette limite finit par céder.
Deuxièmement : les laboratoires d'IA contourneront cette contrainte. Non pas en ignorant le code 402 (ce qui est traçable et source de litiges), mais en achetant des jeux de données sous licence en masse, puis en faisant passer tout le reste par un trafic ressemblant à de vrais utilisateurs. Cloudflare déploie déjà davantage de détection comportementale précisément parce qu'ils le savent. Nous avons observé cette course aux armements se déplacer vers des signaux au niveau de la session depuis deux ans maintenant. Cela ne s'arrête pas à une marketplace.
La question intéressante pour les développeurs n'est pas de savoir s'il faut payer. Elle est de savoir où le web ouvert reste ouvert, et pour combien de temps.