TRAFIC HUMAIN VS AGENT

Distinguer le trafic humain, assisté par IA et agentique

Attribuez à chaque interaction une classe claire et une base claire, afin que votre application puisse servir les personnes, les personnes travaillant avec l'IA et les agents autonomes de la manière qui convient à chacun.

Obtenir un accès anticipé Découvrir le fonctionnement

Par Toshendra SharmaFondateur et CEO, AgentCredia · Updated November 13, 2026

Deux catégories ne suffisent plus

Pendant des années, le trafic a été réparti en deux catégories: les humains et les bots. Les humains recevaient le produit. Les bots étaient bloqués, soumis à une limitation de débit ou ignorés.

Cette distinction ne tient plus. Certains visiteurs automatisés sont des agents agissant pour le compte de vrais clients: un assistant qui compare des offres, un agent qui récupère des données via votre API, un outil qui appelle votre MCP server pour terminer une tâche. Les fournisseurs d'IA documentent désormais eux-mêmes ce type d'accès initié par l'utilisateur: OpenAI indique que son agent ChatGPT-User visite des pages lorsqu'un utilisateur pose une question à ChatGPT (OpenAI crawler documentation), et Anthropic répertorie Claude-User pour le même usage (Anthropic crawler documentation). Dans le même temps, certaines personnes travaillent main dans la main avec l'IA, rédigent des messages, remplissent des formulaires et naviguent dans des produits avec un assistant à leurs côtés. Forcer tout cela à entrer dans les catégories humain ou bot conduit à de mauvaises décisions dans les deux sens. Des agents légitimes sont bloqués, et de vraies personnes sont challengées parce que leur comportement paraît inhabituel.

Pour distinguer le trafic humain et le trafic d'agents IA d'une manière qui mène à de bonnes décisions, vous avez besoin de davantage de catégories et vous devez savoir à quel point chaque résultat est fiable. L'article de blog sur comment savoir si le trafic d'un site web provient d'agents IA passe en revue les signaux qui rendent cela possible, et le cas d'usage des apps SaaS montre en quoi cette distinction modifie les décisions produit.

Quatre classes, chacune avec une signification précise

Proof of Actor classe les interactions en quatre classes. Chacune a une définition et une limite explicite, afin que personne dans votre équipe ne lise plus dans un résultat que ce que les preuves permettent. Pour le raisonnement derrière cette taxonomie, lisez Human, AI-assisted or agent: a taxonomy for app traffic.

Human

Les signaux observables pris en charge indiquent une interaction dirigée par un humain. Cette classe concerne l'auteur de la direction de l'interaction, pas l'identité. Un résultat Human ne vérifie pas qui est la personne, et n'affirme pas qu'aucune IA n'a été utilisée nulle part.

Human + AI

Une assistance IA a été déclarée, ou observée via une intégration prise en charge qui peut réellement la voir. Cela inclut par exemple un utilisateur qui indique qu'un contenu a été rédigé avec l'IA via votre propre contrôle de divulgation, ou votre application qui signale que son assistant intégré a exécuté une action pour un utilisateur connecté. Pour en savoir plus, consultez l'entrée de glossaire AI-assisted interaction.

Agent

Interaction automatisée ou d'origine agentique, étayée par une identité vérifiable, comme une signature de requête valide provenant d'une clé publiée, ou par une inférence soigneusement qualifiée. Un résultat Agent décrit qui agit. Il ne signifie pas que l'agent est autorisé, sûr ou qu'il agit avec une délégation valide de la part d'une personne. Pour en savoir plus, consultez autonomous agents.

Unknown

Les preuves disponibles ne permettent pas une détermination fiable. Unknown est un résultat honnête et utile: il montre où s'arrête votre couverture, et il permet à vos politiques de traiter délibérément les cas incertains au lieu de le faire par accident.

Chaque classe est accompagnée d'une base

Séparer le trafic humain et le trafic agentique ne représente que la moitié du travail. L'autre moitié consiste à savoir à quel point chaque conclusion est solide. C'est pourquoi chaque résultat Proof of Actor porte une base:

Verified: une assertion vérifiable a été validée, par exemple une signature de requête vérifiée à l'aide d'une clé publiée.
Declared: le client ou votre application l'a déclaré, par exemple un agent qui se nomme lui-même ou un utilisateur qui divulgue une assistance IA.
Inferred: une conclusion tirée de signaux comportementaux ou contextuels, toujours étiquetée comme une inférence.
Unknown: pas assez de preuves pour une détermination.

La combinaison de la classe et de la base est ce qui vous permet de construire des règles précises. Un agent Verified et un agent Inferred sont tous les deux des agents, mais vous voudrez peut-être donner au premier une API structurée et traiter le second avec une limitation de débit standard. Une soumission Human + AI déclarée et une session Human peuvent toutes deux se poursuivre normalement, avec une étiquette qui aide votre équipe support. Vous trouverez la taxonomie complète sur Detection & Limitations.

Comment se fait la classification

Proof of Actor suit le même parcours fondé sur les preuves pour chaque interaction. L'explication complète se trouve sur How It Works.

Les signaux que votre intégration peut voir

Signatures de requête provenant de clients automatisés qui publient leurs clés, en utilisant HTTP Message Signatures tel que défini dans RFC 9421. Le groupe de travail IETF Web Bot Auth working group a pour mandat de standardiser la façon dont les clients automatisés s'authentifient de cette manière.
Déclarations des clients qui s'identifient eux-mêmes, comme les user agents documentés des crawlers et fetchers IA, et de votre propre application lorsqu'elle sait qu'une assistance IA est impliquée.
Contexte de requête disponible pour une intégration côté serveur, comme les en-têtes et les détails du protocole.
Signaux d'interaction provenant d'une intégration navigateur approuvée sur les pages où elle s'exécute.

Des signaux au résultat

Les signaux sont vérifiés, étiquetés par base et combinés. Des preuves vérifiées solides produisent un résultat fiable. Des preuves faibles ou contradictoires produisent une inférence qualifiée ou Unknown. Un délai d'attente ou un signal manquant ne devient jamais un résultat Human. Le résultat comprend une classe, une base et un résumé des preuves que toute votre équipe peut lire.

Ce que vous pouvez faire une fois le trafic séparé

Proof of Actor s'organise autour de trois capacités: Detect, Understand et Route.

Detect the actor behind each interaction

Collectez les signaux disponibles dans chaque contexte et séparez les assertions vérifiées des inférences. Gardez Unknown visible.

Understand how each actor uses your product

Voyez la répartition entre activité humaine, assistée par IA, agentique et inconnue par route et dans le temps. Ouvrez n'importe quel résultat pour voir ce qui est connu et ce qui ne l'est pas. Repérez les routes où les agents se concentrent et les workflows où l'assistance IA est fréquente.

Route each actor to the right experience

Appliquez vos propres politiques une fois que les preuves les justifient. Sur un site public, le cas d'usage des websites montre comment ces choix se traduisent sur de vraies routes:

Servez aux agents vérifiés une réponse structurée ou une API plutôt que des pages au format humain.
Conservez l'expérience standard pour les sessions dirigées par un humain.
Étiquetez les soumissions Human + AI pour que la bonne équipe les traite.
Demandez des identifiants plus solides pour les actions sensibles lorsque vos propres conditions l'exigent.
Choisissez un repli explicite pour Unknown sur chaque route, par exemple en autorisant les pages publiques et en conservant les vérifications existantes sur les modifications de compte.

Le guide sur le déploiement sécurisé de politiques sensibles aux acteurs explique comment passer de l'observation à l'application, une route à la fois.

Pourquoi cela compte pour vos utilisateurs

Bien faire les choses est utile à toutes les personnes qui utilisent votre application.

Les personnes profitent d'une expérience plus fluide parce qu'elles ne sont pas challengées sur la base d'un score vague. Les personnes qui travaillent avec l'IA bénéficient d'une prise en charge de l'assistance déclarée dans les workflows où cela convient. Les agents légitimes disposent d'un moyen fiable et structuré d'accomplir leur tâche, ce qui réduit le scraping et la charge sur votre interface. Votre équipe obtient des décisions explicables, afin que les échanges avec le support, les revues d'incident et les changements de politique reposent sur des preuves plutôt que sur des suppositions.

Une connexion n'est pas l'acteur

L'une des sources de confusion les plus fréquentes est le compte lui-même. Une session connectée vous indique quel compte est utilisé. Elle ne vous dit pas qui dirige l'interaction en cours. Le même compte peut être utilisé par son propriétaire qui navigue dans les paramètres le matin, par un assistant que le propriétaire a chargé d'exporter un rapport à midi, et par un agent travaillant via une clé API le soir.

Traiter les trois de la même manière crée des problèmes dans les deux sens. Si chaque requête sur le compte est supposée provenir du propriétaire, un agent peut accéder à des workflows conçus pour une personne. Si chaque requête inhabituelle est considérée comme une attaque, les propres outils du propriétaire sont bloqués. Séparer l'acteur du compte permet à votre application de conserver l'authentification et l'autorisation exactement comme elles sont, et d'ajouter le contexte manquant sur qui agit à cet instant. C'est ce contexte qui rend possible un accès structuré pour les agents sans leur ouvrir les workflows réservés aux humains.

Commencez en mode observation

Chaque déploiement commence en mode observation. Proof of Actor enregistre les résultats pendant que votre application répond exactement comme avant. Votre équipe construit une base de référence de l'activité Human, Human + AI, Agent et Unknown, la compare aux résultats que vous connaissez déjà, et examine les faux positifs avant qu'une seule règle ne change. Lorsqu'une politique est prête, vous l'activez pour un workflow, puis vous élargissez progressivement.

Rejoignez le programme fondateur développeur

Proof of Actor est en beta privée avec un petit groupe d'équipes applicatives. Les fondateurs développeurs sélectionnés peuvent bénéficier d'un accès gratuit pouvant aller jusqu'à 12 mois, dans les limites d'utilisation convenues, en échange de retours concrets. Vous bénéficiez d'un support d'intégration direct de nos ingénieurs, d'un accès anticipé aux fonctionnalités et d'une influence sur les priorités.

Si vous avez besoin de distinguer le trafic humain et le trafic d'agents IA dans votre application, demandez un accès anticipé et dites-nous quelle interaction vous souhaitez le plus comprendre.

Explorez Proof of Actor, lisez comment cela fonctionne, ou voyez précisément ce que les preuves peuvent établir.

Sources

RFC 9421: HTTP Message Signatures, IETF, février 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Overview of OpenAI crawlers, OpenAI.
Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.

POUR LES DÉVELOPPEURS

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent ou Unknown.
basis: Niveau de solidité des preuves : Verified, Declared, Inferred ou Unknown.
evidence: Les signaux derrière le résultat, pour que votre équipe puisse voir pourquoi.

Commencez en mode observation : enregistrez les résultats à côté de vos logs et ne changez rien tant que vous n'avez pas choisi une politique. Lire le guide d'intégration Node.js

Questions fréquentes

Comment distinguez-vous le trafic humain et le trafic d'agents IA ?

Proof of Actor combine les signaux que votre intégration peut observer, comme les signatures de requête, les déclarations du client, le contexte de la requête et les signaux d'interaction du navigateur, puis renvoie une classe avec une base explicite.

Pourquoi existe-t-il une classe Human + AI ?

Certaines personnes travaillent avec un assistant IA à leurs côtés. Les traiter comme entièrement humaines ou entièrement automatisées fait perdre un contexte important. Human + AI couvre une assistance déclarée ou observable via une intégration prise en charge.

Un résultat Agent est-il la même chose qu'un mauvais bot ?

Non. De nombreux agents sont des participants légitimes. Un résultat Agent décrit qui agit, pas si l'action est autorisée. Vos politiques déterminent comment chaque agent est servi.

Que se passe-t-il si le trafic ne peut pas être classé ?

Il est signalé comme Unknown, un résultat de premier rang. Unknown n'est jamais converti en Human et n'est jamais considéré comme malveillant par défaut.

Dois-je bloquer quoi que ce soit ?

Non. Vous commencez en mode observation, vous examinez les résultats et vous activez les politiques uniquement là où votre équipe est sûre qu'elles conviennent.

Savoir qui utilise votre app.

Private beta pour un petit groupe de développeurs fondateurs.

Obtenir un accès anticipé Voir les prix

Vous préférez en parler d'abord ? Parler aux fondateurs