Les robots d’indexation d’IA parcouraient autrefois le web ouvert comme s’il s’agissait d’un bien commun sans surveillance. Pendant des années, les éditeurs ne disposaient que d’outils rudimentaires pour les ralentir : blocages ad hoc des user-agents, filtres IP fragiles, et une convention robots.txt dont la force juridique restait incertaine. Pendant ce temps, le trafic se déplaçait des sites d’origine vers les réponses fournies par l’IA, érodant les revenus publicitaires et les abonnements, tandis que les modèles absorbaient silencieusement des décennies de travail provenant des rédactions, des communautés open source et des créateurs indépendants.
En 2024 et 2025, cet équilibre des pouvoirs a commencé à basculer. Une vague de normes techniques, de paramètres par défaut au niveau de l’infrastructure et de cadres de licences transforme le « scraping par défaut » passif en quelque chose de plus proche du « consentement requis ». Des outils de blocage à l’échelle du réseau et de paiement à la requête de Cloudflare, à la norme Really Simple Licensing et aux « tarpits » anti-IA, les éditeurs ne se contentent plus de résister au scraping non autorisé, ils commencent à définir les conditions économiques et juridiques dans lesquelles l’IA peut accéder à leur travail.
La fin du crawling IA par défaut
Pendant la majeure partie de la dernière décennie, les entreprises d’IA considéraient les URL publiques comme un terrain de chasse libre. Si votre contenu était accessible par un bot et non explicitement bloqué, il était probablement intégré dans des jeux de données d’entraînement. La friction était si faible qu’en 2025, Cloudflare estimait que les robots d’IA généraient plus de 50 milliards de requêtes par jour, soit près de 1 % de tout le trafic observé sur son réseau. Pour les petits sites et projets open source, les requêtes automatisées dépassaient souvent largement les visites humaines, consommant de la bande passante et des ressources sans bénéfice correspondant.
Des services de surveillance comme CheckAIBots ont commencé à documenter ce changement. Ils rapportent qu’environ 48 % des sites d’actualités bloquent désormais les principaux robots d’IA tels que GPTBot, ClaudeBot, Google-Extended et CCBot, en utilisant à la fois robots.txt et des mesures côté serveur. Ils prévoient que ce chiffre atteindra 60 à 70 % parmi les éditeurs premium d’ici fin 2025, sous l’effet de la baisse du trafic de référencement, de la montée des boîtes de réponse IA qui remplacent les clics, et du scepticisme juridique croissant envers l’entraînement non licencié.
Parallèlement, les journaux de serveur et les travaux académiques ont commencé à quantifier une réalité inconfortable : sur certains sites de petites organisations, on estime que 80 à 95 % du trafic provenait de robots d’IA et de bots, et non d’humains. Pour les administrateurs et les associations à but non lucratif, cela devenait intenable. Beaucoup ont été contraints de bloquer des plages IP entières, voire des pays, simplement pour maîtriser les coûts d’infrastructure. Dans ce contexte, l’idée que l’accès à l’IA devrait être basé sur l’opt-in, négocié et rémunéré, a commencé à gagner du terrain politique et commercial.
Blocage par défaut de Cloudflare : l’infrastructure prend parti
Le tournant le plus visible est survenu le 1er juillet 2025, lorsque Cloudflare est devenu le premier grand fournisseur d’infrastructure à bloquer par défaut les robots d’IA connus s’ils accédaient à du contenu « sans autorisation ni compensation ». Au lieu que chaque site doive maintenir sa propre liste de bots agressifs, Cloudflare a inversé le modèle : les entreprises d’IA doivent désormais déclarer ce que font leurs robots et demander à être autorisées, tandis que les éditeurs disposent d’un tableau de bord explicite de choix.
Le système de Cloudflare exige que les clients IA identifient leurs robots comme étant utilisés pour l’entraînement, l’inférence ou la recherche. Cette distinction est importante. L’entraînement implique la construction ou la mise à jour d’un modèle avec le contenu de l’éditeur ; l’inférence signifie généralement une récupération en direct pour alimenter des réponses IA ; la recherche fait référence à l’indexation classique et aux extraits. Les propriétaires de sites peuvent autoriser ou refuser sélectivement chaque usage, choisissant par exemple de permettre l’indexation pour la recherche tout en bloquant le scraping pour l’entraînement et les systèmes de réponse en temps réel susceptibles de cannibaliser leur audience.
De grands groupes médias comme Condé Nast, Dotdash Meredith et Gannett ont publiquement soutenu l’initiative de Cloudflare, la présentant comme un « game-changer » permettant un « échange de valeur équitable » et limitant le « scraping non autorisé ». En intégrant un régime basé sur le consentement directement dans un grand CDN, Cloudflare a fait de l’accès à l’IA une décision d’infrastructure, et non plus un problème propre à chaque site. C’est l’une des premières fois qu’un grand fournisseur neutre prend explicitement parti pour les éditeurs sur la politique de crawling IA, et cela signale que le scraping sans friction ne sera plus la norme sur une grande partie du web.
D’un robots.txt rudimentaire à des politiques IA granulaires
Robots.txt a longtemps été la norme de facto pour indiquer aux bots ce qu’ils peuvent explorer. Cependant, sa conception initiale était grossière : on pouvait autoriser ou interdire des user-agents ou des répertoires, mais il était impossible d’exprimer des règles nuancées sur la façon dont ce contenu pourrait être utilisé par la suite. Pour l’IA, ce modèle binaire était trop simple. Les éditeurs pouvaient être à l’aise avec l’indexation pour la recherche qui génère du trafic, mais très réticents à ce que le même robot alimente des modèles de langage qui répondent aux questions sans renvoyer les lecteurs.
La Content Signals Policy de Cloudflare, lancée en septembre 2025, étend robots.txt avec trois permissions lisibles par machine, correspondant plus directement aux comportements de l’IA : search, ai-input et ai-train. Ainsi, un éditeur peut, par exemple, autoriser search pour les bénéfices SEO traditionnels, tout en bloquant ai-input pour que son contenu ne soit pas utilisé dans des réponses d’IA ou des chats, et refuser ai-train pour l’empêcher d’entrer dans des jeux d’entraînement. Ce niveau de granularité était impossible avec les règles de base autoriser/interdire.
La politique est explicitement présentée comme un moyen de « limiter l’utilisation de votre contenu par l’IA via robots.txt ». Elle reflète aussi une tendance plus large : robots.txt évolue d’un simple indice de crawling vers une surface de politique et de licence plus complexe, qui doit différencier plusieurs classes d’agents automatisés et d’usages. Reste à savoir si les acteurs dominants comme Google respecteront pleinement ces directives nuancées, mais les bases techniques pour des permissions IA différenciées sont désormais posées, et les premiers utilisateurs les exploitent déjà pour formaliser leurs préférences.
Robots.txt comme couche de licence IA : Really Simple Licensing
En s’appuyant sur cette même surface de contrôle, la norme Really Simple Licensing (RSL), lancée en septembre 2025, réinvente explicitement robots.txt comme une couche de licence pour l’IA. Plutôt que de simplement signaler « crawl » ou « ne pas crawler », RSL permet aux éditeurs d’attacher des conditions de licence lisibles par machine, précisant si un site est ouvert à l’entraînement IA, sous licence commerciale particulière, payant, ou strictement interdit à l’IA.
Soutenue dès le lancement par Reddit, Yahoo, Medium et d’autres, RSL est conçue pour que les robots d’IA puissent automatiquement détecter le statut d’un site et agir en conséquence. Une entreprise d’IA peut, par exemple, traiter différemment un contenu marqué comme « licencié » d’un contenu « payant » nécessitant un accord séparé, ou ignorer totalement les sites « no-AI ». En principe, cela permet une conformité et une facturation automatisées, faisant passer le scraping d’une pratique implicite et unilatérale à une pratique explicite et négociée.
L’association à but non lucratif RSL Collective, fondée par des figures comme Eckart Walther (co-créateur du RSS) et Doug Leeds (ancien PDG d’Ask.com), présente la norme comme une couche interopérable pour le consentement et la compensation. Combinée à l’application de type Cloudflare, RSL laisse entrevoir un futur où les robots d’IA lisent non seulement robots.txt pour les permissions techniques, mais aussi pour des conditions commercialement contraignantes. Reste à savoir si les tribunaux traiteront finalement ces signaux comme des obligations contractuelles, mais l’architecture d’un tel écosystème prend rapidement forme.
Du blocage au business : paiement à la requête et échange de valeur
Pour de nombreuses rédactions et éditeurs premium, le problème central n’est pas le crawling IA en soi, mais la réutilisation non rémunérée qui remplace les visites, les impressions publicitaires et les abonnements. À mesure que les systèmes de réponse IA s’amélioraient, les utilisateurs obtenaient de plus en plus ce dont ils avaient besoin sans cliquer, même lorsque ces réponses étaient directement construites sur les reportages ou analyses des éditeurs. Les premiers accords de licence, comme ceux négociés par certains éditeurs via des intermédiaires comme TollBit, ont démontré que des arrangements payants étaient possibles, mais ils restaient l’exception plutôt que la règle.
Le modèle « Pay Per Crawl » de Cloudflare, lancé à la mi-2025, vise à normaliser la compensation. Grâce à lui, les sites web peuvent monétiser l’accès des robots d’IA sur une base par requête. Les entreprises d’IA souhaitant lire du contenu protégé doivent soit payer des frais mesurés, soit être bloquées à la périphérie. Cela transforme effectivement les robots d’IA en consommateurs d’API facturables, alignant leur utilisation sur l’économie de la création et de l’hébergement de contenu. Si ce système est largement adopté, il pourrait faire passer l’entraînement et la récupération IA d’une externalité non valorisée à un centre de coûts prévisible pour les fournisseurs d’IA.
De grands éditeurs et plateformes, dont Condé Nast, l’Associated Press, Reddit et Pinterest, se sont alignés sur cette approche. Beaucoup y voient un moyen de récupérer une partie de la valeur perdue lorsque les systèmes d’IA résument ou reconditionnent leur contenu sans trafic équivalent. Combinés aux signaux de licence basés sur robots.txt et au langage juridique dans les conditions d’utilisation interdisant l’entraînement IA non licencié, les outils de paiement à la requête aident les éditeurs à passer du blocage défensif à des accords proactifs et au partage des revenus.
L’application devient concrète : pièges, tarpits et l’affaire Perplexity
Les normes techniques ne fonctionnent que si les robots les respectent. Un nombre croissant de robots d’IA et de scraping le font, mais d’autres ont été pris à ignorer ou à contourner activement les contrôles. Pour détecter ces mauvais acteurs, les éditeurs et fournisseurs d’infrastructure recourent à des honeypots et à des défenses plus agressives. L’article de 2025 sur le système Logrip, par exemple, propose des techniques de hachage IP hiérarchiques pour identifier l’activité coordonnée des bots et la limiter avant qu’elle ne submerge les petites organisations.
L’un des épisodes d’application les plus médiatisés a eu lieu en août 2025, lorsque Cloudflare a révélé que la startup IA Perplexity avait accédé à des sites « pièges » : des pages non publiques, à la fois bloquées dans robots.txt et conçues spécifiquement pour piéger les robots indélicats. Selon Cloudflare, les robots de Perplexity se seraient fait passer pour Chrome et auraient utilisé des IP tournantes pour contourner ces contrôles. En réponse, Cloudflare a révoqué sa vérification et a commencé à bloquer activement les robots de l’entreprise, invoquant une rupture de confiance et le non-respect des règles d’accès publiées.
Au-delà de la détection, certains développeurs sont passés à l’offensive avec des « tarpits » anti-IA comme Nepenthes. Ces systèmes visent à attirer les robots non autorisés dans de vastes labyrinthes de pages générées automatiquement et à leur servir du contenu absurde de type « Markov babble », gaspillant du calcul et polluant les données d’entraînement. Inspirés des techniques utilisées autrefois contre les spammeurs d’e-mails, les tarpits marquent un passage de la résistance passive, reposant uniquement sur robots.txt, à l’interférence active contre les bots qui refusent d’honorer le consentement. Cette escalade de la course technologique explique pourquoi de nombreux acteurs politiques réclament des solutions juridiques plus claires en complément des défenses techniques.
Robots.txt, droit et la revendication de la souveraineté des auteurs
À mesure que robots.txt prend plus de poids normatif à l’ère de l’IA, juristes et universitaires s’interrogent sur les responsabilités et droits juridiques qui y sont attachés. L’analyse de 2025 « The Liabilities of Robots.txt » met en lumière comment ce fichier chevauche plusieurs domaines du droit : contrat (est-ce une offre acceptée par les bots ?), droit d’auteur (l’ignorer constitue-t-il une infraction ou relève-t-il de l’usage loyal ?), et responsabilité délictuelle (un préjudice causé par un crawling abusif peut-il donner lieu à des réclamations ?). Elle conclut que, bien que robots.txt soit une norme technique puissante, son statut juridique reste flou dans de nombreuses juridictions.
Parallèlement, un débat culturel se développe sous la bannière de la « souveraineté des auteurs ». Un manifeste de 2025 portant ce nom plaide pour un passage du scraping présumé sous fair use à un consentement volontaire, négocié et une compensation contractuelle. Dans cette perspective, l’entraînement IA sans consentement n’est pas une pratique technique inoffensive, mais une exploitation structurelle des auteurs, dont le travail et l’expression sont monétisés à grande échelle par des tiers.
Certaines entreprises d’IA ont commencé à mettre en avant leur conformité comme moyen de gérer cette tension. Anthropic, par exemple, a consolidé ses robots sous un unique user-agent ClaudeBot et s’est engagée explicitement à respecter toute règle robots.txt historique visant ses anciens identifiants comme Claude-Web ou Anthropic-AI. Cette rétrocompatibilité signifie que les éditeurs ayant déjà bloqué ces anciens bots n’ont pas besoin de mettre à jour leurs fichiers pour empêcher Claude d’accéder, renforçant robots.txt comme un mécanisme de contrôle durable, même s’il reste en partie extralégal.
Robots de récupération, pression sur l’open source et nouvelle réalité du trafic
Un développement clé qui intensifie les préoccupations des éditeurs est le passage des scrapes d’entraînement ponctuels aux robots de récupération persistants et à fort volume, utilisés pour les réponses IA en direct. Les données de TollBit, citées par le Washington Post, montrent que le trafic des robots de récupération liés à des systèmes comme OpenAI et Anthropic a augmenté de 49 % entre fin 2024 et début 2025, dépassant la croissance des robots d’entraînement purs. Ces robots récupèrent de manière répétée du contenu à jour pour alimenter des réponses conversationnelles qui peuvent totalement remplacer les visites de pages.
Pour les rédactions, cela signifie que le coût de servir le trafic IA est continu, tandis que les bénéfices sont souvent minimes ou inexistants sans licence formelle. Certains éditeurs, comme Time, ont utilisé les analyses de TollBit pour négocier des accords de récupération rémunérés. Mais la majorité constate encore un schéma de scraping non rémunéré couplé à une baisse des visites humaines. Ce déséquilibre explique pourquoi les associations professionnelles publient désormais des recommandations encourageant leurs membres à bloquer ou mesurer les robots d’IA à moins qu’un partage de revenus n’existe.
Les développeurs open source et les petits créateurs, quant à eux, font face à un problème différent mais lié : la capacité. Des rapports de 2025 décrivent des mainteneurs ayant trouvé les robots d’IA si agressifs qu’ils ont dû bloquer des pays entiers ou de larges plages IP pour préserver leur infrastructure. Des initiatives communautaires comme ai.robots.txt compilent désormais des listes d’agents utilisateurs liés à l’IA et fournissent des modèles prêts à l’emploi de robots.txt et .htaccess pour les bloquer. Pour ces créateurs, reprendre le contrôle relève autant de la survie technique que de l’équité économique.
Ensemble, ces évolutions marquent un tournant dans la relation entre les systèmes d’IA et le web ouvert. Là où les robots d’IA opéraient autrefois sans contrôle, les éditeurs disposent désormais d’un arsenal croissant d’outils : blocage au niveau de l’infrastructure, signaux de contenu granulaires, licences lisibles par machine via RSL, modèles d’accès monétisés, et, si nécessaire, défenses actives contre les bots non conformes. Aucun de ces outils ne résout à lui seul les ambiguïtés juridiques sous-jacentes ni ne garantit une compensation équitable, mais pris ensemble, ils font passer le défaut de l’extraction à la négociation.
Dans les années à venir, les contours de ce nouveau compromis seront définis dans les contrats, les organismes de normalisation et les tribunaux. Les grandes plateformes d’IA respecteront-elles pleinement les directives nuancées de robots.txt ? Les modèles de paiement à la requête et les couches de licence deviendront-ils des sources de revenus stables ou se fragmenteront-ils en silos incompatibles ? Et la loi évoluera-t-elle pour reconnaître robots.txt et les signaux associés comme des expressions exécutoires de la volonté des auteurs ? Quelle que soit la réponse à ces questions, une chose est claire : les éditeurs ne sont plus de simples sources de données passives pour l’IA. Par une combinaison d’innovation technique et de pression collective, ils commencent à reprendre le contrôle de la manière, du moment et des conditions dans lesquelles leur travail alimente la prochaine génération de systèmes intelligents.
