Jusqu’à récemment, le trafic sur le web ouvert prenait deux grandes formes. La navigation humaine, épisodique, limitée par l’attention, plafonnée par le nombre de pages qu’une personne peut lire en une session. Et le scraping programmatique, à fort volume, en éventail, majoritairement sans état, majoritairement invisible pour l’utilisateur.
Une troisième forme émerge rapidement. Les agents IA qui utilisent un navigateur — Computer Use d’Anthropic, Operator d’OpenAI, les divers agents autonomes open source — pilotent un vrai navigateur à travers une séquence de pages pour le compte d’un utilisateur. Le trafic qu’ils génèrent ne ressemble ni à l’un ni à l’autre des deux précédents. Les sites qui se sont défendus avec succès contre le scraping ne savent pas encore quoi en faire. Les fournisseurs d’infrastructure qui sous-tendent ces agents cherchent encore les bonnes primitives.
Cet article est un instantané de ce à quoi ressemble concrètement le trafic des agents IA en production aujourd’hui, et de la façon dont il a façonné la pile d’infrastructure qui le supporte.
Ce à quoi ressemble le trafic au niveau du réseau
Un flux d’agent IA typique aujourd’hui : l’utilisateur demande à l’agent de “trouver le vol direct le moins cher de New York à Tokyo fin août.” L’agent lance un Chromium headless, navigue vers Google Flights, remplit le formulaire, le soumet, analyse les résultats, suit le moins cher jusqu’au site de la compagnie aérienne, navigue vers la page de réservation, confirme la disponibilité, retourne la réponse.
Cela représente 8 à 15 requêtes HTTP sur 30 à 90 secondes, avec les propriétés suivantes :
Par rafales. Soit zéro requête, soit une séquence soutenue, sans état intermédiaire stable. L’agent est inactif jusqu’à ce que l’utilisateur pose une question, puis tourne à plein régime pendant une minute.
Avec état au sein de la rafale. Le flux de l’agent comporte des cookies, une session, un User-Agent. La requête N+1 doit ressembler à une continuation de la requête N du point de vue du site cible. Un changement d’IP en cours de flux brise la session.
Avec des points de terminaison hétérogènes. Chaque exécution d’agent visite plusieurs sites distincts : moteur de recherche, compagnie aérienne 1, compagnie aérienne 2, éventuellement un agrégateur comparatif. Chaque site a sa propre posture anti-bot.
Ancré géographiquement à l’utilisateur. L’utilisateur veut des vols depuis JFK, pas depuis un datacenter quelconque. Le trafic de l’agent doit se géolocaliser de façon plausible là où l’utilisateur pose sa question, ou du moins là où il souhaite paraître effectuer sa réservation.
Sensible à la latence. L’utilisateur attend. Une latence par requête de 800 ms au lieu de 200 ms, multipliée sur 12 requêtes, fait la différence entre “l’agent a répondu en 30 secondes” et “l’agent a répondu en 1,5 minute.”
Cette forme ne correspond ni au modèle de navigation humaine (trop rapide, trop stateful à vitesse machine) ni au modèle de scraping (trop peu de requêtes par session, trop lié à la session, trop ancré à l’utilisateur).
Pourquoi l’infrastructure naïve échoue
Quelques patterns utilisés avec succès par les équipes data expérimentées ne se transposent pas :
La rotation par requête sur un grand pool résidentiel. Le pattern de scraping par défaut. Inadapté aux agents car la session nécessite une cohérence d’IP, des cookies de connexion, un état de recherche, un binding d’empreinte. La rotation par requête brise la session dès la deuxième requête.
Les proxies datacenter pour la vitesse. Tentant en raison du profil de latence. Inadapté car les cibles en amont que visite l’agent (Google, compagnies aériennes, e-commerce, banques) se défendent agressivement contre le trafic datacenter. La moitié des exécutions de l’agent échouent avec des CAPTCHA.
Une seule IP résidentielle statique. Tentant car cohérent. Inadapté car l’IP brûle rapidement entre agents : une IP servant des milliers de flux d’agents ressemble à un scraper après les 100 premières exécutions.
La forme qui fonctionne se rapproche davantage de sessions persistantes sur du résidentiel, avec une session fraîche par exécution d’agent, un ciblage géographique correspondant à l’intention de l’utilisateur, et la session bornée à la durée de vie naturelle de l’exécution.
Le pattern qui fonctionne
L’architecture vers laquelle convergent la plupart des déploiements d’agents en production :
user_request → agent.spawn( proxy_session_id=hash(user_id, request_id), # unique per user-run pair proxy_country=user_geo_or_intent, proxy_ttl=longer_than_expected_run, # don't expire mid-flow ) → browser navigates target sites through that session → agent returns result → proxy session expires naturallyL’abstraction proxy est par exécution, pas par requête. Au sein d’une exécution, l’agent dispose d’une IP résidentielle cohérente. D’une exécution à l’autre, chaque flux d’agent obtient une IP fraîche, d’un FAI différent, généralement d’une ville différente. La diversité du pool protège contre le fait qu’une seule IP soit brûlée par un trafic d’agent répété ; la cohérence de session protège contre le fait que le site cible signale l’agent comme suspect en cours de flux.
C’est fonctionnellement le même pattern qu’utiliserait un bot de comparaison d’achats — session résidentielle persistante par session, attribution par client à un sid stable. La nuance pour les agents IA est que le volume est considérablement plus élevé (chaque requête utilisateur déclenchant une exécution d’agent est une session) et la durée est plus courte (la plupart des flux d’agents durent moins de 2 minutes).
L’infrastructure résidentielle facturée à la bande passante s’y adapte naturellement : les exécutions d’agents sont des transactions limitées par la bande passante, pas par la concurrence. On paie au Go que les agents transfèrent ; la concurrence est le problème du runtime de l’agent, pas celui du proxy.
Ce que font les sites cibles
Pas grand-chose, pour l’instant. La plupart des grands sites traitent encore le trafic des agents IA comme du trafic de scraping — mêmes règles anti-bot, même blocage. Cela va changer rapidement, dans deux directions :
Les sites qui bénéficient du trafic des agents vont s’y adapter. Flux de réservation, checkout e-commerce, comparaison d’achats. L’agent est un vrai utilisateur servi par une couche d’automatisation ; la conversion reste réelle. Des sites avisés commencent à publier des points de terminaison adaptés aux agents, des déclarations de type robots qui indiquent “traitez le trafic avec ce user-agent et cet en-tête comme un agent médié par un humain, ne bloquez pas, mais limitez le débit.”
Les sites qui pâtissent du trafic des agents vont se durcir. Tout ce qui est financé par la publicité a un vrai problème : les agents ne voient pas les publicités, ne cliquent pas dessus, ne convertissent pas les annonceurs. Les sites d’actualités, les sites de contenu gratuit, tout ce qui est monétisé par les impressions a intérêt à détecter et bloquer spécifiquement le trafic des agents. Ce sera le prochain épisode de la course aux armements anti-bot, et il sera plus disputé que le scraping ne l’a été, car la couche agent a des soutiens d’entreprise puissants qui perdent si leurs agents sont bloqués.
La couche d’infrastructure au milieu — c’est nous et nos pairs dans les réseaux de proxies résidentiels — se trouve dans une position intéressante. Nous sommes la couche d’accès qui permet aux agents d’atteindre des sites qui ne les accueillent pas encore. À mesure que la négociation entre les sites et les fournisseurs d’agents se déroule (probablement via un mélange de contrats, de relations commerciales et de protocoles révisés de type robots.txt), le rôle des fournisseurs d’infrastructure pure se réduira sur le chemin “autorisé” et s’élargira sur le chemin “nécessite une diversité au niveau IP.”
Ce qu’il faut surveiller en 2026
Quelques signaux à suivre si vous développez sur des agents :
La fraction des exécutions d’agents nécessitant une ré-authentification en cours de flux. Aujourd’hui, elle est quasi nulle avec des sessions persistantes correctement configurées. Si elle commence à augmenter, les sites cibles ont appris à détecter les empreintes d’agents et les challengent en cours de session. La mitigation nécessite soit une meilleure empreinte navigateur côté agent, soit des stratégies de proxy différentes.
La latence p99 sur les flux d’agents multi-étapes. Aujourd’hui, elle est principalement due au réseau et au temps de réponse du site cible. Si les passerelles proxy deviennent un goulot d’étranglement sous charge d’agents concurrents, la couche d’infrastructure doit monter en charge.
La distribution géographique du trafic des agents. Aujourd’hui, la plupart du trafic des agents se géolocalise là où le runtime de l’agent est hébergé (US-East principalement). À mesure que les agents commencent à médier de vraies transactions utilisateur (achats, réservations, opérations bancaires), le trafic doit se géolocaliser à l’emplacement de l’utilisateur pour que la logique du site fonctionne correctement. C’est le scénario haussier pour une infrastructure résidentielle précise au niveau ville/ASN devenant la norme.
Les déclarations de sites adaptés aux agents. Surveillez l’émergence d’un équivalent agents.txt ou d’une déclaration structurée “j’accepte le trafic des agents sous ces contraintes.” Si cela se produit, le rôle de la couche proxy se réduit ; si ce n’est pas le cas, la couche proxy reste le médiateur d’accès.
La conclusion
Les agents IA constituent une vraie nouvelle forme de trafic. Ce n’est pas du scraping, ni de la navigation, ni de la récupération RAG — ils partagent des caractéristiques avec chacun mais ne correspondent nettement à aucun. L’infrastructure sous-jacente doit s’adapter pour supporter des sessions persistantes par exécution à une concurrence de volume de scraping, avec une géographie ancrée à l’utilisateur et des objectifs de latence trois fois inférieurs à ce que tolère le scraping.
La bonne nouvelle pour les fournisseurs d’infrastructure : les réseaux de proxies résidentiels bien construits supportent déjà exactement cette forme. Sessions persistantes par exécution d’agent, IPs fraîches par session, précision géographique, tarification à la bande passante qui s’adapte à l’usage. Les primitives qui ont mûri en servant les scrapers et les bots de comparaison sont les mêmes primitives dont les agents ont besoin.
La question produit pour les deux prochaines années n’est pas de savoir si le trafic des agents sera une vraie catégorie — il l’est déjà. C’est de savoir avec quelle clarté la pile d’infrastructure et l’écosystème des sites cibles convergeront vers des termes acceptables pour les deux parties. Nous aurons une image plus nette d’ici l’article de lancement de l’année prochaine.