DataDome

Menaces liées aux agents et tendances du secteur qui ont marqué l’année 2026 (jusqu’à présent)

Table des matières
Dernière mise à jour : 1 Jul, 2026
|
min

Le premier semestre de 2026 n’a pas donné lieu à un seul événement marquant dans le paysage des menaces liées aux bots et aux agents. Il en a produit plusieurs, et la plupart d’entre eux allaient dans la même direction.

L’IA a profondément transformé la nature des attaques, leur origine et la manière dont elles tentent de rester dissimulées. Dans le même temps, les outils sur lesquels s’appuient les défenseurs ont discrètement évolué sous leurs pieds.

Ce récapitulatif présente les conclusions les plus significatives de l’équipe de recherche sur les menaces Galileo de DataDome pour le premier semestre 2026, regroupées en fonction des tendances qui les ont traversées.

Le problème d’identité de l’IA est devenu impossible à ignorer

Le fil conducteur le plus constant de nos recherches du premier semestre n’était pas un nouveau type d’attaque ni une nouvelle technique d’évasion ingénieuse. Il s’agissait d’un problème d’identité qui se manifestait dans les deux sens.

En février, nous avons publié des données montrant que 80% des agents IA ne s’identifient pas correctement lorsqu’ils visitent des sites web, s’appuyant sur des chaînes user-agent facilement falsifiables au lieu de méthodes d’identification appropriées comme les plages d’IP publiées, les recherches DNS inversées ou les protocoles d’authentification comme Web Bot Auth

Et à l’inverse, lorsque nous avons testé environ 700 000 sites accessibles en utilisant un user-agent de type ChatGPT falsifié, 79,7% l’ont laissé passer sans le bloquer ni le défier. Non seulement la plupart des agents IA ne parviennent pas à s’identifier correctement, mais la plupart des sites web ne peuvent pas distinguer un agent IA légitime d’un attaquant qui prétend en être un.

Ces questions autour de l’identité des agents IA ne sont pas théoriques. Le rapport de mars de DataDome AI Traffic Report a montré que près de 8 milliards de requêtes d’agents IA ont frappé le réseau de DataDome au cours des deux premiers mois de 2026. Non seulement cela représentait une augmentation de 5% du trafic IA d’un trimestre à l’autre, mais les données ont également montré que des noms d’agents connus et de confiance sont activement utilisés par les attaquants comme couverture. 

Meta-ExternalAgent était l’agent le plus usurpé, avec 16,4 millions de requêtes falsifiées. ChatGPT-User a suivi avec 7,9 millions. Perplexity avait le taux d’usurpation le plus élevé, avec près de 2,4% des requêtes prétendant être PerplexityBot trouvées frauduleuses.

 

Spoofed traffic per AI agent in February 2026

 

La raison de cette usurpation est simple : les identités d’agents IA bien connues inspirent une confiance implicite. Les systèmes de sécurité qui soumettent le trafic provenant de ChatGPT ou de Perplexity à un contrôle moins rigoureux leur accordent, en effet, un passe-droit. Et dans un monde où le trafic d’IA légitime est lui aussi en pleine croissance, cette couverture s’améliore de mois en mois.

Les attaques derrière les chiffres 

Cette confiance a été exploitée bien au-delà du scraping. Notre recherche sur l’abus des agents IA a documenté quatre cas d’attaquants utilisant une infrastructure IA légitime comme mécanisme de livraison :

  • Perplexity a été utilisé pour exécuter une attaque de cross-site scripting (XSS) réfléchie contre un site de commerce électronique d’électronique. L’attaquant a probablement incité Perplexity à “résumer” une URL contenant une charge utile JavaScript malveillante ;
  • le crawler de Meta a été déclenché pour sonder un site de tourisme à la recherche de vulnérabilités. La requête provenait d’une IP Meta vérifiée, correctement identifiée comme Meta-ExternalAgent, transportant une charge utile XSS classique ;
  • l’infrastructure d’OpenAI a envoyé une injection SQL aveugle basée sur le temps contre un portail d’actualités financières. La requête provenait d’une IP OpenAI documentée et s’identifiait comme GPTBot ;
  • Comet Browser, un navigateur IA, a été utilisé pour automatiser l’enregistrement de faux comptes à un rythme constant et semblable à celui d’un humain, d’une requête toutes les 6-8 secondes pour éviter les limites de taux.

 

OpenAI used for SQL injections

 

Les attaquants ne s’introduisent pas par effraction. Ils sont laissés entrer par des systèmes conçus pour faire confiance à l’infrastructure derrière laquelle ils se cachent.

Ce qui se cache dans vos données de référencement IA

La même dynamique est apparue dans notre recherche sur le faux trafic de référencement IA. Vers le 14 janvier, nous avons observé un pic de près de 600 000 requêtes attribuées à chatgpt.com sur le réseau de DataDome. 

Lorsqu’un tableau de bord d’analyse web montre un pic vertical soudain de trafic attribué à chatgpt.com, c’est généralement une raison de se réjouir. En réalité, il s’agissait de bots de scraping. 

Le chiffre le plus révélateur : une session a consulté 109 pages de produits en cinq secondes, soit environ 22 requêtes par seconde. Les bots transitaient par des FAI résidentiels tels que Comcast et Verizon pour paraître authentiques. La moitié d’entre eux fonctionnaient sous GNU/Linux, ce qui est rare chez les particuliers effectuant des achats sur ces réseaux.

Pour les organisations qui utilisent le trafic référent de ChatGPT pour orienter leur stratégie de référencement naturel (SEO) ou d’optimisation de l’IA, la conséquence est directe : si vous ne pouvez pas vérifier l’identité de l’agent d’IA, vous risquez d’optimiser en fonction de bruit.

Les outils d’IA eux-mêmes sont devenus une infrastructure d’attaque

Le problème d’identité lié à l’IA ne concerne pas seulement l’usurpation. Certaines des recherches les plus marquantes de ce semestre ont porté sur des outils d’IA légitimes détournés pour servir d’infrastructure d’attaque — non pas usurpés, mais bel et bien piratés.

OpenClaw a été lancé fin janvier 2026, un agent IA open-source qui promettait de permettre aux utilisateurs de commander un serveur IA personnel depuis n’importe quelle application de messagerie. Il a gagné 60 000 étoiles GitHub en trois jours. Il a également été lancé avec des configurations par défaut qui laissaient des milliers d’instances largement ouvertes sur Internet, un audit de sécurité qui a révélé plus de 500 vulnérabilités, et un marché de plugins inondé d’extensions malveillantes.

L’analyse de l’équipe Galileo de DataDome a révélé que les acteurs malveillants ont commencé à détourner les instances OpenClaw exposées en l’espace de quelques semaines, les intégrant dans un botnet concentré en Asie du Sud et du Sud-Est, avec des grappes importantes aux États-Unis et en Europe.

 

Global distribution of OpenClaw-based botnet activity

 

Les cibles principales étaient les plateformes de voyage et de vente au détail, des industries avec des données de prix et d’inventaire de grande valeur. Environ 50 % de tout le trafic provenant de ces instances compromises était dédié à la recherche de vulnérabilités. Le reste était consacré au scraping, aux tentatives d’account takeover et à la fraude aux paiements.

OpenClaw est un incident spécifique. Le schéma qu’il illustre — des frameworks d’agents d’IA accessibles, dotés de paramètres par défaut faibles, devenant des nœuds de botnet — n’est pas près de disparaître. La barrière à la mise en place d’un agent d’IA est faible, ce qui rend également faible la barrière à sa compromission.

Les attaques à grande échelle sont devenues plus difficiles à bloquer par les moyens conventionnels

L’une des attaques les plus significatives de la première moitié de 2026 ne reposait pas du tout sur l’usurpation d’identité IA. Elle reposait sur l’échelle et le timing.

À la mi-avril, une campagne de DDoS ciblant une plateforme de contenu généré par les utilisateurs à grande échelle a généré 2,45 milliards de requêtes malveillantes en cinq heures, sans jamais déclencher une seule limite de débit traditionnelle. 

 

Attack traffic observed by DataDome’s bot protection across the 5-hour attack window

Trafic d’attaque observé par la protection contre les bots de DataDome pendant la fenêtre d’attaque de 5 heures

 

La raison : le botnet a réparti le trafic sur 1,2 million d’adresses IP uniques couvrant 16 402 systèmes autonomes. Chaque source a envoyé en moyenne environ une requête toutes les neuf secondes, restant ainsi largement en dessous des seuils par adresse IP. L’opérateur a modulé l’intensité par vagues, laissant les compteurs de limitation de débit se réinitialiser pendant les pauses avant de remonter en puissance.

DataDome a bloqué l’attaque en temps réel, mais l’architecture de cette attaque illustre pourquoi les défenses basées sur des seuils statiques ont du mal à contrer ce type de campagne. La menace réside dans le schéma qui se dessine au fil du temps et entre les différentes sources, et non dans une adresse IP en particulier.

Les pics trafic ont favorisé des attaques à fort volume 

Un autre type d’attaque est apparu en juin, synchronisé avec la Coupe du Monde de la FIFA 2026. 

Pour une grande plateforme européenne de paris sportifs, le trafic malveillant atteignait en moyenne 200 000 requêtes par jour début juin. Puis, à la veille du match d’ouverture, un DDoS éclair a tiré 786 000 requêtes en 87 secondes, culminant à près de 18 000 requêtes par seconde. Sur la période de trois semaines autour du tournoi, DataDome a bloqué près de 19 millions de requêtes malveillantes pour ce client seul.

 

Graph depicting the nearly 19 million blocked malicious requests

 

L’infrastructure à l’origine de cette attaque DDoS éclair a été retracée jusqu’à Biterika Group LLC, un hébergeur basé en Russie. Selon les données télémétriques de DataDome, 91 % du trafic provenant de ce fournisseur est malveillant.

L’attaque s’est déclenchée immédiatement à pleine intensité, puis s’est dispersée sur des dizaines de zones géographiques en quelques secondes, rendant inefficace le blocage basé sur la localisation. Et comme l’attaque s’est terminée en 87 secondes, il n’y a pas eu le temps d’intervenir manuellement. Un blocage automatisé en temps réel, avec une latence de l’ordre de la milliseconde, est la seule solution viable.

Les règles ont changé des deux côtés

L’une des évolutions les plus discrètes mais significatives en matière de détection de l’automatisation au cours du premier semestre 2026 n’est pas venue des attaquants, mais des éditeurs de navigateurs.

Depuis 2018, la spécification WebDriver du W3C exige que les navigateurs contrôlés par des outils d’automatisation s’identifient comme automatisés — via une propriété JavaScript appelée navigator.webdriver, qui est définie sur « true ». Ce n’a jamais été le seul signal de détection, mais c’était une base de référence fiable. Les navigateurs constituaient une infrastructure neutre.

Cela a changé discrètement. En juin 2025, Microsoft a lancé Playwright 1.53.0 — l’un des frameworks d’automatisation de navigateur les plus utilisés au monde — avec une modification non documentée : lorsqu’un agent d’IA pilote Playwright, navigator.webdriver est désormais défini sur « false », la même valeur que renvoie un navigateur utilisé par un humain.

When an AI agent drives Playwright, navigator.webdriver is now set to false

Google a pris une mesure similaire dans V8, le moteur JavaScript de Chrome, en supprimant une méthode bien documentée permettant de détecter si le protocole Chrome DevTools (CDP) est actif dans un navigateur. Un signal qui s’était révélé fiable pour identifier la plupart des frameworks d’automatisation modernes.

L’équipe Galileo de DataDome a identifié les deux changements lors de tests de routine. Aucun des deux n’a fait l’objet d’une annonce accompagnée de commentaires publics significatifs.

À mesure que les agents d’IA prennent en charge davantage de tâches que les humains effectuaient auparavant manuellement — navigation, clics, réalisation de transactions —, la distinction binaire entre « humain » et « automatisé » devient plus difficile à appliquer au niveau du navigateur. Que cela ait motivé ces décisions ou non, l’effet est le même : les signaux d’automatisation au niveau du navigateur sont moins fiables qu’il y a un an.

C’est le genre d’évolution qui met à nu les faiblesses des systèmes de détection à couche unique ou dépendants des signaux du navigateur, rendant d’autant plus importante la détection multicouche.

Au-delà des signaux auto-déclarés 

La preuve de navigateur récemment publiée par DataDome est un contrôle d’intégrité du navigateur qui ne repose pas sur des signaux auto-déclarés. Au lieu de vérifier si une propriété spécifique est définie, « Proof of Browser » oblige le client à effectuer des opérations qui existent de manière native et exclusive au sein d’un véritable moteur de navigateur : des tâches complexes et interdépendantes telles que le rendu WebGL, étroitement lié aux calculs de mise en page CSS et aux mutations du DOM. Celles-ci ne peuvent pas être reproduites à moindre coût en dehors d’un véritable navigateur sans produire des divergences détectables.

La preuve de navigateur ne fonctionne pas de manière isolée. Elle fonctionne à l’intérieur de la couche d’obfuscation basée sur une machine virtuelle (VM) de DataDome, et les deux travaillent ensemble : la VM cache ce qui est mesuré, forçant les attaquants à analyser du bytecode virtualisé et fortement obfusqué juste pour comprendre quels mécanismes de navigateur sont testés. La preuve de navigateur rend ensuite la mesure elle-même infalsifiable, même si un attaquant déduit ce qui est vérifié, il ne peut toujours pas produire une réponse valide sans exécuter le code dans un véritable navigateur.

Depuis son déploiement, la preuve de navigateur a bloqué 14 millions de tentatives de contournement sophistiquées. Pour empêcher l’analyse statique, le défi est entièrement régénéré à chaque build : lorsqu’un nouveau build est déployé, le calcul central, les mécanismes de navigateur qu’il teste et la structure du code changent tous. Les connaissances issues du reverse-engineering d’un build ne se transfèrent pas au suivant.

Les six prochains mois

Les tendances observées au cours des six premiers mois de 2026 ne sont pas près de disparaître. Elles deviennent même plus marquées.

Le trafic généré par les agents d’IA continuera de croître, ce qui signifie que le problème de l’identité deviendra de plus en plus difficile à gérer. À mesure que la navigation autonome prendra une part plus importante du trafic web global, il deviendra plus difficile de distinguer les agents légitimes de ceux qui utilisent des identités de confiance comme couverture. La faille que les attaquants exploitent déjà va s’élargir avant de se réduire.

Les signaux d’automatisation au niveau du navigateur sont également moins fiables qu’il y a un an, et cette tendance ne s’inversera pas. La détection qui s’appuie sur des propriétés autodéclarées ou sur une seule couche de signaux est de plus en plus fragile. Les approches multicouches, basées sur le comportement, sont désormais plus importantes qu’à l’époque où ces signaux étaient stables.

L’équipe Galileo continuera de publier des recherches à mesure que de nouveaux modèles émergent. Si vous souhaitez rester à jour, le hub de recherche sur les menaces est mis à jour au fur et à mesure que nous découvrons de nouvelles découvertes dignes d’être partagées.

Effectuez notre analyse de vulnérabilité gratuite aujourd’hui pour évaluer votre exposition aux menaces des bots et agents IA, ou réservez une démonstration pour découvrir comment DataDome peut sécuriser vos points de terminaison.