Détecter les agents IA : en quoi les navigateurs de Claude, ChatGPT et Perplexity diffèrent des humains

En 2024, les agents IA sont passés des démos expérimentales au trafic de production. L'API Computer Use de Claude peut piloter un navigateur. Les outils de navigation de ChatGPT parcourent des sites web pour répondre à des requêtes. Le moteur de réponse de Perplexity crawle en temps réel. Et une catégorie croissante d'assistants propulsés par l'IA — Browserbase, le Computer Use d'Anthropic, OpenAI Operator — accomplissent des tâches web de bout en bout pour le compte d'utilisateurs.

Pour un site web, cela crée une nouvelle catégorie de visiteur qui n'entre dans aucune des deux cases de la détection de bots traditionnelle. Les agents IA ne sont pas des scrapers extrayant des données à grande échelle. Ce ne sont pas des humains cliquant dans une UI. Ils sont quelque chose entre les deux — un visiteur par session, un objectif par visite, mais une exécution à la vitesse de la machine avec une précision mécanique.

Les détecter n'a pas le même enjeu que détecter des bots. Parfois vous voulez les servir (un agent utile faisant les achats d'un client). Parfois vous voulez les bloquer (du scraping non autorisé via un wrapper IA). Dans les deux cas, il faut d'abord savoir qu'ils sont là.

En quoi les agents IA diffèrent architecturalement

Trois architectures principales produisent du trafic d'agents IA sur le web :

Les agents pilotant un navigateur exécutent un navigateur headless ou headful contrôlé par un LLM. Le Computer Use d'Anthropic, OpenAI Operator, Browserbase et Skyvern entrent tous dans cette catégorie. Le navigateur est un vrai Chrome ou Chromium. L'agent le dirige par manipulation du DOM ou via l'analyse de captures d'écran et des clics par coordonnées.

Les agents API-only récupèrent les pages via des bibliothèques HTTP (Node.js, Python, Go) et passent le HTML à un LLM pour traitement. La plupart des agents Perplexity et des agents basés sur la recherche fonctionnent ainsi. Il n'y a pas de navigateur — juste une couche de récupération qui alimente un modèle en texte.

Les agents hybrides utilisent un navigateur pour les sites riches en JavaScript et la récupération par API pour le contenu statique. Beaucoup d'agents en production entrent dans cette catégorie, en choisissant dynamiquement selon la cible.

Chaque architecture laisse des empreintes différentes.

Signal 1. Durée de vie de la session navigateur

Les utilisateurs réels ont des sessions longues et peu focalisées. Ils ouvrent des onglets, se laissent distraire, reviennent. La durée médiane d'une session humaine sur une tâche de décision est de 8 à 20 minutes.

Les agents IA ont des sessions courtes et focalisées. Une tâche Computer Use typique — réserver un vol, commander des courses, extraire des données produit — prend de 30 secondes à 3 minutes de bout en bout. La session commence par le chargement de la page, exécute 5 à 30 actions en séquence, puis se termine.

Une durée de session inférieure à 5 minutes avec plus de 10 actions discrètes et aucun changement d'onglet est un comportement humain atypique et un comportement d'agent typique.

Signal 2. Précision des clics par coordonnées

Les agents pilotant un navigateur d'Anthropic et d'OpenAI utilisent l'analyse de captures d'écran pour identifier les éléments d'UI, puis cliquent sur des coordonnées. Le calcul des coordonnées est précis au pixel.

Les utilisateurs réels cliquent dans des zones. Un bouton de 200x40 pixels reçoit des clics distribués sur toute sa surface, pondérés vers le centre mais avec une variance humaine. Les agents IA cliquent dans une bande étroite — souvent à 2 ou 3 pixels du centre géométrique de l'élément. Cent clics avec une déviation moyenne inférieure à 3 pixels, ce n'est pas une distribution humaine.

La détection exige de collecter les coordonnées des clics et de les analyser par rapport aux limites des éléments. Cela fonctionne bien sur des données à l'échelle de la session.

Signal 3. Absence de scroll exploratoire

Les humains scrollent pour voir ce qu'il y a sur une page. Ils descendent, puis remontent, puis redescendent à moitié. Ils s'arrêtent sur le contenu qui attire leur attention. Leurs traces de scroll sont irrégulières.

Les agents IA ne scrollent que lorsque c'est nécessaire. Si l'objectif est de cliquer sur « Ajouter au panier » et que le bouton est au-dessus de la ligne de flottaison, l'agent peut ne jamais scroller. Si l'élément cible est en dessous, l'agent scrolle une fois, directement jusqu'à la cible, puis exécute.

Les sessions avec moins de 2 changements de direction de scroll, ou avec une vélocité de scroll constante sur tous les événements, indiquent une navigation pilotée par la tâche plutôt qu'une exploration.

Signal 4. Timing de la saisie de texte

Les utilisateurs réels tapent à un rythme de 30 à 60 mots par minute, avec des pauses variables, des suppressions occasionnelles et des micro-corrections. Le timing des frappes suit une distribution à forte variance et avec un taux de suppression non nul.

Les agents IA remplissent les formulaires en collant des valeurs ou en simulant des frappes à une cadence fixe — souvent 50 à 100 caractères par seconde, uniformément, sans aucune suppression. Un champ rempli en 200 ms avec une chaîne de 30 caractères et zéro retour arrière n'est pas une saisie humaine.

Signal 5. Absence de fautes de frappe

Lié mais distinct : les humains font des fautes de frappe. Sur 1 000 caractères saisis, les utilisateurs réels produisent 15 à 40 corrections. Les agents IA en produisent zéro. Une soumission de formulaire avec 3 champs totalisant plus de 100 caractères et zéro correction est inhabituelle pour un humain.

Signal 6. Incohérences de user agent

Certains agents IA utilisent des user agents personnalisés qui les identifient explicitement : perplexity-user, ChatGPT-User, ClaudeBot. Ce sont des agents polis qui suivent la convention d'auto-identification et respectent souvent robots.txt.

La détection est ici triviale — lire le user agent et le comparer aux listes connues. La valeur est de savoir quand les servir différemment (ou les bloquer si vous ne voulez pas de scraping).

D'autres agents exécutent des frameworks de pilotage de navigateur et héritent du user agent du navigateur — typiquement Chrome. Ceux-là sont plus difficiles à identifier par le seul user agent et exigent des signaux comportementaux.

Signal 7. Rendu WebGL en headless

Les agents pilotant un navigateur qui utilisent Chromium en mode headless exposent le renderer SwiftShader dont nous avons parlé dans l'article sur Puppeteer. Toute session où le renderer WebGL contient SwiftShader et où le visiteur exécute plus de 10 actions délibérées est presque certainement un agent IA pilotant un navigateur.

Les frameworks d'agents plus récents (Browserbase, certaines configurations Skyvern) exécutent un Chrome headful pour éviter ce signal. Ils présentent de vraies chaînes GPU. Cela signifie que WebGL seul est insuffisant pour détecter les agents modernes — nécessaire comme filtre de départ, pas comme solution complète.

Signal 8. Adhérence parfaite à la structure de la page

Les utilisateurs réels cliquent sur des liens même quand une redirection de page est en cours. Ils s'interrompent. Ils double-cliquent quand un simple clic suffirait. Ils cliquent sur des choses qui ne sont pas des liens.

Les agents IA suivent le DOM. Quand ils veulent naviguer, ils émettent une action contre un élément spécifique. Ils ne cliquent pas sur le mauvais élément et ne rafraîchissent pas en plein chargement. Leurs sessions se déroulent avec une linéarité mécanique qu'aucun humain distrait ne produit.

Les traces de session avec une adhérence parfaite — chaque clic sur un élément valide, chaque champ de formulaire rempli dans l'ordre du DOM, chaque transition de page précédée d'une action intentionnelle — se lisent comme pilotées par un agent.

Signal 9. Un time-to-interactive nul

Les utilisateurs réels ont besoin de temps pour assimiler une page. Ils lisent. Ils balayent. Ils comprennent avant d'agir.

Les agents IA parsent le DOM instantanément. Le délai entre la fin du chargement de la page et la première action utilisateur est, pour un utilisateur réel, typiquement de 1,5 à 4 secondes même sur des pages simples. Pour les agents IA, il peut être inférieur à 200 ms — le temps qu'il faut au LLM pour identifier l'élément cible dans le DOM.

Une première action très rapide sur une page exigeant la compréhension du contenu est un signal d'agent fort.

Signal 10. Patterns de récupération HTTP des agents API-only

Perplexity, certains flux de tool-use de Claude et la plupart des agents basés sur la recherche n'exécutent pas de navigateur. Ils récupèrent les pages directement via des bibliothèques HTTP.

Ces agents laissent les signaux TLS et HTTP évoqués plus haut — empreinte undici de Node.js, empreinte de Python requests, empreinte de Go net/http. Ils n'exécutent typiquement pas JavaScript, donc ils ne déclenchent aucune détection côté client.

La détection des agents API-only se fait à la couche réseau : hachages TLS JA4, ordre des en-têtes HTTP, comportements propres aux navigateurs absents (pas de requête favicon, pas de balise analytics, pas de requêtes de polices). Pour identifier ces agents, il faut regarder ce qui ne se passe pas autant que ce qui se passe.

Signal 11. Des objectifs de session en forme de tâche

Le signal le plus fort n'est pas technique — il est comportemental. Les sessions d'agents IA sont orientées objectif d'une manière que les sessions humaines ne sont que rarement.

Un utilisateur réel qui cherche un produit peut regarder 8 articles, comparer les specs dans 3 onglets, lire les avis, abandonner puis revenir une heure plus tard, et enfin acheter. Un agent IA va au produit, extrait les specs, ajoute au panier, passe au paiement. Moins de 90 secondes. Aucune déviation.

Les systèmes de détection qui suivent les taux de complétion d'objectif au niveau de la session peuvent identifier le trafic d'agents par la densité de tâches accomplies avec succès dans des sessions courtes. C'est un signal plus lent mais très fiable lorsqu'il est combiné avec des signaux par action.

Servir les agents différemment

Une fois identifié, le trafic d'agents IA peut être traité de plusieurs façons :

• Bloquer — si le site ne veut pas d'accès automatisé, refuser à la périphérie. Bon marché et simple.

• Servir un contenu alternatif — répondre avec une version optimisée pour les API (JSON, données structurées) moins chère à générer que la page HTML complète.

• Limiter le débit — autoriser les agents mais contraindre leur taux de requêtes pour préserver les performances du site.

• Facturer — certains sites commencent à facturer aux entreprises d'IA l'accès programmatique à leurs données. La détection est un prérequis à la facturation.

• Servir normalement — si l'agent agit pour le compte d'un vrai client, le servir, c'est du business.

Chaque site fera un choix différent. Ce qui compte techniquement, c'est d'avoir la détection en place pour que le choix soit possible.

Une cible mouvante

Les frameworks d'agents IA s'améliorent chaque mois. Anthropic publie des mises à jour de Computer Use qui ajoutent de la variance de scroll. Browserbase ajoute du jitter de souris. OpenAI Operator introduit la simulation de fautes de frappe. Chaque génération de framework referme une partie de la surface de détection décrite ci-dessus.

Les techniques qui fonctionnent en 2026 devront être mises à jour d'ici 2027. Mais la réalité sous-jacente ne changera pas : les agents IA exécutent des tâches. Les humains font l'expérience des sites web. Cette asymétrie produit du signal, quelles que soient les techniques spécifiques que les agents emploient pour tenter de se fondre dans la masse.

Les stacks de détection qui traitent les agents IA comme une catégorie persistante et évolutive — plutôt que comme un problème résolu une fois pour toutes — conserveront leur visibilité. Celles qui livrent un détecteur unique et passent à autre chose verront leur couverture se dégrader silencieusement.