L’annonce de Cloudflare en juillet 2026 ne se résume pas à un nouveau conflit entre éditeurs et scrapers. Elle marque une tentative de transformer l’accès automatisé au web en couche de règles: une politique pour la recherche, une autre pour les agents agissant pour l’utilisateur, une autre pour l’entraînement des modèles.

Passerelle réseau en périphérie classant le trafic de recherche, agent et entraînement par règles d’accès

La distinction compte parce que l’ancien compromis du web se fissure. Pendant des années, un crawler lisait une page parce que le moteur de recherche renvoyait des visiteurs. Le site gagnait visibilité, clics, publicité, abonnements ou notoriété. Les moteurs de réponse IA et les agents de navigateur changent l’échange: ils peuvent lire, extraire la réponse, accomplir une tâche et ne jamais envoyer l’humain à la source.

Cloudflare ne répond pas simplement par “bloquer l’IA”. Dans son billet du 1er juillet, l’entreprise distingue Search, Agent et Training. Search collecte ou indexe le contenu. Agent agit, souvent en temps réel, au nom d’une personne. Training prend le contenu pour entraîner ou ajuster un modèle. À partir du 15 septembre 2026, Cloudflare dit que les nouveaux clients et nouveaux sites autoriseront Search par défaut, mais bloqueront Training et Agent sur les pages affichant de la publicité. Le communiqué ajoute les clients gratuits existants qui n’auront pas modifié leurs réglages. Les options restent modifiables.

La conséquence est simple: il ne suffit plus de savoir quel bot arrive. Il faut savoir pourquoi.

L’ancien contrat

Le web public reposait sur un compromis lisible. Les sites publiaient, les crawlers indexaient, les moteurs classaient, les utilisateurs cliquaient. Ce n’était pas parfait, mais les incitations étaient claires.

AI search et agentic browsing brouillent ce contrat. Un résultat de recherche est une porte. Une réponse IA peut devenir la destination. Un agent peut lire plusieurs pages, comparer des offres, résumer une documentation ou remplir un formulaire sans visite humaine. C’est pratique pour l’utilisateur, mais cela peut supprimer l’attention qui finançait la page.

Pew Research Center a montré le signal qui inquiète les éditeurs: dans son panel Google 2025 aux États-Unis, les utilisateurs cliquaient sur un résultat classique dans 8% des visites avec résumé IA, contre 15% sans résumé. Les liens à l’intérieur du résumé recevaient seulement 1% de clics. Ce n’est pas une loi universelle, mais cela explique la tension.

Cloudflare se trouve près du levier. L’entreprise affirme que plus de 20% du web est derrière son réseau. Cela ne signifie pas qu’elle contrôle Internet, mais beaucoup de requêtes passent par une couche edge où une règle peut s’appliquer avant le serveur d’origine.

Trois usages, trois politiques

Search est la catégorie la plus défendable. Le crawler indexe et, idéalement, renvoie de la découvrabilité. Cloudflare écrit que Search devrait apporter du trafic de référence ou une compensation équitable.

Agent est plus délicat. Il s’agit d’automatisation agissant pour une personne: bot de chat qui récupère une page, agent qui pilote Chrome, outil qui accomplit une tâche. L’intention peut être humaine, mais le site voit parfois un bot qui consomme du contenu sans impression publicitaire ni session normale.

Training est la catégorie que les éditeurs veulent contrôler le plus clairement. Ce n’est pas une réponse ponctuelle; c’est du contenu collecté pour améliorer un modèle. Beaucoup de sites acceptent l’indexation sans accepter de nourrir gratuitement l’entraînement.

Cette taxonomie pousse les entreprises IA à séparer leurs crawlers. Cloudflare prévient que les crawlers mixtes pourront recevoir la règle la plus restrictive. Un crawler utilisé à la fois pour Search et Training peut donc être bloqué par un site qui refuse Training. Pour les équipes infrastructure, un user-agent vague ne suffit plus.

Le changement de septembre

Il ne faut pas exagérer: Cloudflare ne bloque pas tous les bots IA partout. Le défaut concerne les pages affichant des publicités. Search reste autorisé. Les clients peuvent changer les réglages. Le périmètre vérifié inclut nouveaux clients, nouveaux sites et clients gratuits existants n’ayant pas modifié leurs options.

La publicité sert de signal économique. Si une page monétise l’attention humaine et qu’un agent lit puis répond ailleurs, cette attention disparaît. Le blocage par défaut de Agent et Training sur ces pages tente de protéger cette intention sans couper Search.

Reste une question technique: comment Cloudflare détecte-t-il qu’une page affiche des publicités? Les documents publics ne donnent pas de spécification complète. Or la monétisation peut être bannière, affiliation, sponsoring, paywall, page produit ou documentation commerciale.

Pour les clients Cloudflare, l’action est pratique: auditer les réglages avant septembre et choisir une politique par type de site.

De Pay Per Crawl à Pay Per Use

Pay Per Crawl, lancé en bêta privée en 2025, permettait à un site d’autoriser, bloquer ou faire payer un crawler. Le crawler pouvait recevoir HTTP 402 Payment Required avec un prix, puis réessayer avec une volonté de payer. Cloudflare agissait comme Merchant of Record et utilisait Web Bot Auth pour vérifier l’identité.

HTTP 402 est un symbole intéressant: MDN rappelle que les navigateurs n’ont pas de flux standard pour ce code et l’affichent comme erreur 4xx. Cloudflare ne crée pas un paywall navigateur; il teste une négociation machine-à-machine.

Le prix par crawl reste grossier. Une page jamais utilisée dans une réponse ne vaut pas autant qu’un passage qui devient source centrale d’une requête chère. D’où l’évolution vers Pay Per Use. Les exemples publics sont Ceramic.ai et You.com. Ceramic est présenté comme pay-per-query: l’éditeur est payé quand son contenu apparaît dans des résultats IA, avec reporting sur requêtes, snippets et position. You.com illustre l’accès payant à la demande pour du contenu premium.

Ce n’est pas encore un marché mature. C’est le sens du mouvement.

L’identité du bot devient une infrastructure

Robots.txt reste utile mais volontaire. RFC 9309 standardise le Robots Exclusion Protocol, sans en faire un mécanisme d’authentification ou de sécurité. Un acteur peut l’ignorer ou usurper un user-agent.

Cloudflare Content Signals Policy ajoute des préférences lisibles par machine: search, ai-input, ai-train, et désormais un champ use. Ces signaux expriment une intention; ils ne bloquent pas seuls. Ils prennent du poids avec edge controls, WAF, bot management et contrats.

Web Bot Auth apporte la partie vérifiable. Les crawlers signent les requêtes avec HTTP Message Signatures et des identités Ed25519. Cloudflare peut alors reconnaître, classer, autoriser, bloquer ou facturer. L’identité des bots devient cryptographique, pas simplement polie.

Pour les développeurs, cela impose de séparer les usages, signer les requêtes, publier des métadonnées d’identité, respecter les signaux et prévoir des flux de paiement ou de refus.

Ce que gagnent les éditeurs, et le prix possible

Les éditeurs gagnent du levier. Un petit site ne négocie pas avec chaque société IA. Des contrôles Search, Agent et Training donnent un tableau de bord: rester visible, refuser l’entraînement, tester l’accès payant ou bloquer l’automatisation non signée.

Le risque est une fragmentation du web. Si chaque plateforme edge, groupe d’éditeurs et vendeur IA définit ses propres catégories, en-têtes, licences et exceptions, les grands négocieront et les petits développeurs subiront. Outils de recherche, accessibilité, moteurs indépendants ou agents personnels peuvent être pris dans des règles conçues contre l’extraction industrielle.

Il y a aussi un risque de gatekeeper. Cloudflare répond à un problème réel, mais classe l’intention. Une erreur de catégorie peut bloquer l’accès à une part importante du web. Les faux positifs, la transparence et les recours compteront.

SEO, agents et équipes infrastructure

Pour le SEO, index/noindex devient une matrice. Faut-il autoriser les moteurs de réponse IA? Exiger citation ou paiement? Traiter un agent temps réel différemment d’un crawler d’index? Les rapports évoqués avec Ceramic ressemblent autant à de l’analyse de licence qu’à du rank tracking.

Pour les agents IA, le message est de rendre le but visible. Indexation, retrieval temps réel, navigation au nom d’un utilisateur et entraînement ne devraient pas partager une identité opaque. Les logs, headers et signatures doivent distinguer ces fonctions. Les équipes produit doivent budgéter l’accès payant quand le contenu est critique.

Pour l’infrastructure, commencez par l’inventaire: zones Cloudflare, pages avec publicité, documentation, marketing, support, pricing, données produit. Puis vérifiez AI traffic settings, Bot Management, WAF, verified bots, robots.txt, Content Signals, sitemaps et logs. Enfin, auditez vos propres dépendances: scraping, enrichissement de données, agents qui lisent le web en temps réel.

Un web plus programmable et plus contractuel

Le vrai changement n’est pas un bouton Cloudflare. C’est l’arrivée de règles lisibles par machines: Search peut indexer, AI input peut utiliser, Training non, Agents doivent peut-être payer, crawlers signés reçoivent un traitement différent.

Cela peut protéger créateurs et éditeurs. Cela peut aussi transformer le web en mosaïque de règles privées. Tout dépendra de la transparence, des standards ouverts, de prix raisonnables, de recours et de la place laissée aux petits acteurs.

L’annonce de Cloudflare prévient les développeurs d’agents: ils ne vivront pas seulement par la puissance des modèles. Ils vivront par les règles d’accès au bord du web. L’avantage concurrentiel sera peut-être de savoir quelles portes l’agent peut ouvrir, ce qu’il doit signer et quand il doit payer.