Le réseau de fermeture : blocage des robots d'indexation IA et accès des agents
All Posts

Le réseau de fermeture : blocage des robots d'indexation IA et accès des agents

Ryan Turner
Ryan Turner · Head of Growth

Le Web, autrefois ouvert aux robots d'indexation anonymes, se referme. Les blocages par défaut et les plateformes d'accès payant remplacent l'ancien modèle libre d'accès. En conséquence, l'accès des agents se divise désormais en deux voies : l'indexation sous licence ou payante lorsqu'elle est disponible, ou l'accès en tant qu'utilisateur réel le reste du temps. Si votre agent continue de supposer qu’il peut récupérer n’importe quelle URL publique à partir d’une adresse IP de centre de données, il s’appuie sur des fondations qui sont en train de s’effondrer sous ses pieds.

Points à retenir
  • Le 1er juillet 2025, Cloudflare a commencé à bloquer par défaut les robots d'indexation basés sur l'IA sur environ 20 % du Web et a lancé une place de marché fonctionnant selon un modèle de paiement à l'indexation (Cloudflare, Cloudflare vient de révolutionner la manière dont les robots d'indexation basés sur l'IA explorent l'Internet dans son ensemble).
  • Les principaux sites d'information ont adopté une politique de refus par défaut : environ 79 % bloquent les robots d'entraînement de l'IA, et environ 49 % interdisent expressément l'accès à GPTBot.
  • La cause est d'ordre économique : le rapport entre le nombre de pages explorées et le nombre de références a atteint environ 38 000 pour 1 pour l'un des principaux robots d'exploration. Les sites sont exploités, et non pas bénéficiaires de trafic.
  • L'entraînement des robots d'indexation et la détection des agents en temps réel sont pris dans les mêmes filets. Les agents qui continuent à fonctionner ressemblent à de vrais utilisateurs situés dans la bonne zone géographique, ou paient pour un accès sous licence.

Ce qui a changé : le Web est passé à un mode « refus par défaut »

En 2025, les paramètres par défaut ont changé. L'événement le plus marquant a été celui de Cloudflare, qui, dès le 1er juillet, a commencé à bloquer par défaut les robots d'exploration basés sur l'IA sur environ 20 % du Web et a lancé une plateforme de services payants à l'exploration (Cloudflare, Cloudflare vient de révolutionner la manière dont les robots d'indexation basés sur l'IA explorent l'Internet dans son ensemble). Paiement à l'exploration Il s'agit d'une plateforme où un site fait payer aux robots l'accès qu'il offrait auparavant gratuitement. En réalité, un simple changement de configuration a fait passer un cinquième du Web d'un système « opt-out » à un système « opt-in ».

Il ne s'agissait pas d'un simple changement de cap ponctuel. Les robots ne représentent plus qu'une part minoritaire du trafic. En 2024, les robots automatisés ont dépassé les 51 % de l'ensemble du trafic web pour la première fois depuis dix ans, les robots malveillants représentant quant à eux 37 % (Imperva, Rapport 2025 sur les robots malveillants). Lorsque la plupart des requêtes adressées à votre serveur d'origine proviennent de machines, le fait de bloquer ces dernières par défaut ne semble plus être une mesure agressive. Au contraire, cela relève plutôt des mesures de sécurité élémentaires.

C'est le secteur de l'information qui a réagi le premier et le plus fermement. En 2025, environ 79 % des plus grands sites d'information au monde bloquaient les robots d'entraînement à l'IA, et environ 49 % interdisaient expressément l'utilisation de GPTBot (Press Gazette, Huit des dix plus grands sites d'information au monde bloquent désormais les robots d'apprentissage de l'IA). En conséquence, le fichier robots.txt est passé d'une simple recommandation à une politique de refus par défaut pour la catégorie IA. L'accès libre à l'exploration ne s'est pas arrêté du jour au lendemain. Néanmoins, la tendance est claire et va dans un seul sens.

Pourquoi cela s'est produit : l'effondrement du trafic provenant des moteurs de recherche

La raison est d'ordre économique, et non idéologique. L'ancien principe était simple. Les robots d'indexation indexaient votre contenu, et les moteurs de recherche vous envoyaient des visiteurs en retour. L'indexation par IA a brisé ce cercle vertueux. Au milieu de l'année 2025, le robot d'indexation d'Anthropic traitait environ 38 000 pages par visiteur référé, tandis que le GPTBot d'OpenAI affichait un ratio d'environ 3 700:1 (Cloudflare, Le ralentissement qui a précédé la chute du nombre de références). Par conséquent, les éditeurs font le calcul et constatent que leur contenu part sans qu'ils n'en retirent pratiquement rien en retour.

On y voit plus clair lorsqu'on examine l'objectif de l'exploration. L'exploration par l'IA se répartit approximativement comme suit : 80 % pour l'apprentissage, 18 % pour la recherche et seulement 2 % pour les actions des utilisateurs (Cloudflare, Un examen approfondi des robots d'indexation basés sur l'IA). Les quatre cinquièmes de ces données servent à l'entraînement du modèle, qui, de par sa conception, ne renvoie aucune recommandation. Du point de vue d'un propriétaire de site, il s'agit donc d'une pure exploitation, et le blocage constitue la réaction la plus rationnelle.

Le volume est également en hausse, ce qui rend la situation encore plus critique. Le trafic généré par l'IA et les robots d'indexation a augmenté de 18 % d'une année sur l'autre jusqu'en 2025, et la part de GPTBot dans les requêtes des robots d'indexation basés sur l'IA est passée de 5 % à 30 % en un an, soit une augmentation de 305 % du nombre brut de requêtes (Cloudflare, De Googlebot à GPTBot : qui explorera votre site en 2025 ?). Une charge plus importante, aucun trafic de retour et des outils simples pour bloquer l'accès. En conséquence, le mode « par défaut : refus » était inévitable.

Ce que cela signifie pour les agents : pris dans le même filet

Voici le piège dans lequel tombent souvent les équipes d'ingénieurs. L'entraînement des robots d'indexation et la récupération de données en temps réel par un agent sont deux choses différentes. Un robot d'indexation d'entraînement explore des millions de pages pour constituer un ensemble de données. Votre agent, en revanche, récupère trois pages pour répondre à la question d'un utilisateur ici et maintenant. Cependant, le site ne perçoit pas l'intention. Il détecte une requête automatisée provenant d'un agent utilisateur bot connu ou d'une plage d'adresses IP signalée, et il applique la même règle de refus par défaut aux deux. C'est pourquoi « le Web se ferme à l'IA » touche des agents qui ne touchent jamais aux données d'entraînement. L'infrastructure de blocage ne fait pas la distinction entre un agent de récupération et un scraper. Elle distingue plutôt les humains des bots, et de plus en plus, elle distingue les adresses IP réputées fiables des plages d'adresses des centres de données. En bref, un agent honnête utilisant une adresse IP cloud est perçu comme identique à un scraper malveillant.

Adresses IP des centres de données Il s'agit d'adresses appartenant à des fournisseurs de services cloud et d'hébergement ; ce sont les plages que les systèmes anti-bot signalent en premier, car aucun utilisateur lambda ne navigue à partir de ces adresses. Plus précisément, ce sont les premières cibles détectées par les systèmes anti-bot modernes en 2026, ce qui explique en grande partie pourquoi les agents échouent lorsqu'ils tentent d'atteindre des cibles protégées. Nous abordons les mécanismes de ce phénomène dans Pourquoi les agents sont-ils bloqués sur les adresses IP des centres de données ?, mais pour faire court, un agent honnête connecté à une adresse IP cloud est considéré comme hostile.

La question de l'accès se présente donc sous deux angles, et les deux ont leur raison d'être. Lorsqu'il existe une voie autorisée ou payante, comme un accord de paiement à l'indexation ou une API officielle, optez pour celle-ci. C'est l'option la plus sûre, et elle résiste par définition à la fermeture progressive du Web. Partout ailleurs, la solution durable consiste à se présenter comme un utilisateur réel : une requête provenant d'un appareil résidentiel ou mobile situé dans la zone géographique prévue par le contenu, qui affiche la page comme le ferait le navigateur d'une personne. Proxys résidentiels Il s'agit de connexions qui transitent par de véritables appareils grand public ; la requête porte donc une adresse attribuée par le FAI, que le site traite comme celle d'un visiteur ordinaire. Le choix entre ces types de réseau relève de sa propre décision, que nous détaillons dans Proxys résidentiels vs proxys de centre de données.

C'est l'aspect que la plupart des équipes sous-estiment jusqu'à ce qu'il provoque une panne en production. À mesure que le chemin d'exploration ouvert se referme, les agents qui continuent de fonctionner sont ceux qui ne ressemblent en rien à des robots d'exploration. D'après notre expérience en matière de charges de travail des agents, l'accès via des appareils d'utilisateurs réels, sous la forme d'un visiteur local organique avec un rendu propre, est ce qui reste fiable lorsque le refus par défaut est la norme. C'est le positionnement qui sous-tend le réseau d'accès aux appareils et la pile de rendu de Massive : de véritables appareils grand public dans plus de 195 pays, avec un ciblage géographique par pays, subdivision et ville, renvoyant du code HTML ou Markdown propre à partir de n'importe quelle source publique, où qu'elle se trouve. D'après notre collaboration avec les équipes, nous constatons qu'elles l'utilisent comme solution de secours pour les cibles qui ont échoué, puis le font passer en solution principale une fois que la file d'attente des tickets a disparu. Lorsque la pile proxy-plus-navigateur-headless DIY cesse d'être rentable, l'étape suivante consiste généralement en une infrastructure gérée, que nous abordons dans infrastructure de navigation gérée.

Pour découvrir l'architecture complète permettant de fournir à un agent un accès en direct permanent, commencez par consulter la section consacrée à la manière de donner aux agents IA un accès en temps réel au Web. Cette tendance est l'un des éléments pris en compte dans cette conception, mais elle ne fait pas tout.

Que faire maintenant : se préparer à la fin du web

Prévoyez comme si le principe « par défaut, refus » était la norme, car c'est ce qu'il est devenu en 2025. D'un seul coup, Cloudflare a placé environ 20 % du Web derrière un accès sur demande (Cloudflare, Cloudflare vient de révolutionner la manière dont les robots d'indexation basés sur l'IA explorent l'Internet dans son ensemble), et leur adoption ne cesse de croître. Par conséquent, concevez votre couche d'accès en partant du principe que les cibles faciles seront sécurisées, et non en supposant que les URL actuellement accessibles le resteront.

Trois mesures concrètes découlent de ces données. Premièrement, classez vos cibles en deux catégories : « parcours sous licence/payant disponible » et « doit arriver en tant qu'utilisateur réel », puis acheminez chacune d'elles en conséquence. Deuxièmement, cessez d’envoyer du trafic d’agent à partir d’adresses IP cloud brutes, car le système de détection les signale avant même que le corps de votre requête ne soit lu. Troisièmement, privilégiez une sortie au format Markdown ou HTML propre plutôt que des sauvegardes de pages brutes, car votre LLM paie pour chaque token de données superflues que vous lui fournissez. Par exemple, nous avons testé le trafic résidentiel par rapport au trafic sortant des centres de données sur des sites protégés et avons constaté que le taux de réussite du trafic résidentiel était nettement plus élevé (fourchettes approximatives : résidentiel ~85-99 % contre centre de données ~20-40 %). Considérez cela comme une référence fournie par le fournisseur, et non comme une étude indépendante. Cela dit, cette tendance correspond à ce que la tendance de détection prévoit.

Sources

Frequently Asked Questions

Le Web ouvert est-il réellement en train de se refermer, ou s'agit-il simplement d'un effet de mode ?

Ce sont les paramètres par défaut qui ont changé, et c'est cela qui importe. En 2025, Cloudflare a configuré environ 20 % du Web pour bloquer par défaut les robots d'exploration basés sur l'IA, et environ 79 % des principaux sites d'information bloquent désormais les robots d'entraînement de l'IA (Cloudflare; Press Gazette). Il existe encore des URL ouvertes. Cependant, le principe du « refus par défaut » est désormais la norme, et non plus l'exception.

Mon agent ne récupère que quelques pages, pas les données d'entraînement. Pourquoi est-ce bloqué ?

En effet, l'infrastructure de blocage ne peut pas discerner l'intention. Elle signale les agents utilisateurs de robots et les plages d'adresses IP de centres de données, et applique la même règle à un agent de récupération de trois pages qu'à un robot d'indexation d'entraînement traitant un million de pages. L'indexation par IA repose à environ 80 % sur l'entraînement (Cloudflare). Par conséquent, les sites bloquent par défaut l'ensemble de la catégorie.

Pourquoi les éditeurs bloquent-ils l'accès au lieu de simplement faire payer ?

Les deux, de plus en plus. Le facteur déclencheur est l'effondrement du rapport entre l'exploration et les visites référencées : un robot d'exploration majeur a atteint environ 38 000 pages explorées par visiteur référencé en 2025 (Cloudflare). Les plateformes de paiement à la consultation, quant à elles, permettent aux sites de facturer un accès qu'ils offraient auparavant gratuitement, ce qui constitue la partie payante de cette nouvelle répartition.

Quel est désormais le chemin d'accès permanent pour les agents ?

Deux approches. Lorsque vous disposez d'un accès sous licence ou payant, utilisez-le. Dans tous les autres cas, connectez-vous comme un utilisateur réel : une requête provenant d'un appareil résidentiel ou mobile situé dans la zone géographique prévue, avec un affichage standard. Vous éviterez ainsi le drapeau « IP de centre de données » qui détecte la plupart des agents sur les sites protégés.