Pendant la majeure partie de l’histoire du web, le trafic automatisé n’avait qu’une mission dans la stack de sécurité: être identifié puis stoppé. La gestion des bots s’est développée autour de cette mission. Elle se place à la périphérie de votre infrastructure, évalue les requêtes et bloque ou défie celles qui semblent abusives. Elle le fait très bien, et vous devez la conserver.
Les agents IA ont changé ce que les applications doivent savoir. Une part croissante des requêtes automatisées provient désormais d’agents agissant pour de vrais clients: un assistant qui compare des offres, un agent qui dépose un ticket de support, un client qui appelle votre MCP server pour terminer une tâche. En même temps, beaucoup de personnes utilisent votre produit avec un assistant IA à leurs côtés. Ce ne sont pas des attaques. Ce sont des utilisateurs, et ils méritent la bonne expérience plutôt qu’une page de blocage.
C’est cette lacune que Proof of Actor comble. Cette page compare les deux catégories de manière claire pour que vous voyiez où chacune a sa place.
La version courte
| Gestion des bots | Proof of Actor | |
|---|---|---|
| Question principale | Cette requête doit-elle être arrêtée ? | Qui agit, ou qu’est-ce qui agit, et quelle est la preuve ? |
| Où cela s’exécute | À la périphérie, devant votre application | Dans votre application, API ou MCP server |
| Sortie typique | Autoriser, bloquer ou défier; souvent un score | Human, Human + AI, Agent ou Unknown, plus une base |
| Traite les personnes assistées par l’IA comme | Généralement indifférenciables des autres personnes | Une classe distincte, Human + AI |
| Traite le trafic incertain comme | Souvent défié ou bloqué | Unknown, avec un repli que vous choisissez par route |
| Qui décide de la réponse | L’ensemble de règles de la périphérie | Le code de votre application |
| Comportement par défaut à l’installation | Application des règles | Observation; rien ne change tant que vous n’ajoutez pas de politique |
| Meilleur pour | Arrêter le credential stuffing, les abus de scraping et les attaques volumétriques | Décisions produit, analytique et politique pour chaque acteur |
Le reste de cette page explique chaque ligne.
Deux questions différentes
La gestion des bots répond à une question de protection. Son objectif est de tenir l’automatisation abusive à l’écart de votre infrastructure, de vos comptes et de votre inventaire. Chaque signal qu’elle collecte sert cet objectif, et sa sortie est une décision: laisser passer la requête, la bloquer ou lui opposer un défi.
Proof of Actor répond à une question de compréhension. Son objectif est d’indiquer à votre application qui, ou quoi, pilote chaque interaction, afin que vous puissiez décider comment la servir. Sa sortie n’est pas un verdict sur la requête. C’est une classification accompagnée de sa preuve:
- Human: les signaux observables indiquent une interaction pilotée par une personne.
- Human + AI: une personne a dirigé l’interaction avec une assistance IA qui a été déclarée ou observée.
- Agent: interaction automatisée ou issue d’un agent, étayée par une identité vérifiable ou une inférence qualifiée.
- Unknown: les preuves ne permettent pas une détermination fiable.
Chaque résultat indique aussi sa base de preuve: verified, declared, inferred ou unknown. C’est l’information dont une décision produit a besoin, et ce n’est pas le type d’information qu’un score de protection est conçu pour porter.
Où chacun s’exécute
La gestion des bots s’exécute généralement à la périphérie du réseau ou dans un reverse proxy, devant tout le reste. Cette position est exactement la bonne pour la protection. Elle voit le trafic tôt, absorbe les attaques avant qu’elles ne vous coûtent quoi que ce soit et garde vos serveurs d’origine propres.
Proof of Actor s’exécute là où vit la logique de votre application: middleware serveur, Next.js, la couche edge que vous contrôlez, une intégration navigateur approuvée, une API HTTP générique ou votre MCP server. Cette position lui donne accès à ce que votre application sait: quelle route est appelée, à quel workflow elle appartient, si votre propre assistant a effectué une action et si un client s’est déclaré. Consultez les chemins d’intégration pour la liste complète.
Parce que les deux s’exécutent à des endroits différents, ils ne se disputent pas le même rôle. Une requête peut passer votre gestion des bots, atteindre votre application, puis recevoir un contexte d’acteur qui façonne la réponse.
Scores contre preuves
De nombreux produits de protection expriment leur jugement sous forme de score. Un score est efficace pour une décision de blocage: choisissez un seuil, agissez au-dessus. Il est bien moins utile lorsque la question est "quelle expérience cet acteur doit-il recevoir ?"
Un score ne vous dit pas si une requête à faible risque provient d’une personne, d’une personne travaillant avec un assistant ou d’un agent bien comportement. Il ne vous dit pas quelles parties de la conclusion ont été vérifiées et lesquelles ont été déduites. Et il ne peut pas exprimer "nous ne savons pas" sans le forcer à entrer dans un chiffre.
Proof of Actor conserve ces distinctions. Un résultat d’agent verified signifie qu’une signature de requête a été vérifiée par rapport à une clé publiée, par exemple via HTTP Message Signatures. Un résultat declared signifie qu’un client ou votre propre application l’a déclaré. Un résultat inferred est étiqueté comme une inférence. Et Unknown est une réponse à part entière plutôt qu’un défaut caché. Votre équipe peut lire chaque résultat et voir exactement sur quoi il repose.
Les personnes assistées par l’IA ne sont pas des bots
Le groupe qui croît le plus vite dans la plupart des applications est celui des personnes qui travaillent avec l’IA. Elles rédigent des messages avec un assistant, remplissent des formulaires avec de l’aide et avancent dans votre produit avec un outil d’IA à leurs côtés. Les outils de protection n’ont pas été conçus pour les distinguer des autres personnes, et ils n’ont pas à le faire.
Votre produit, lui, en a souvent besoin. Vous pouvez vouloir étiqueter les tickets de support rédigés avec l’aide de l’IA pour que la bonne équipe les traite, mesurer comment les utilisateurs assistés par l’IA progressent dans l’onboarding, ou leur proposer un parcours plus fluide. Proof of Actor donne à ce groupe sa propre classe, Human + AI, et ne la renvoie que lorsque l’assistance est déclarée ou observable via une intégration prise en charge. En savoir plus dans l’entrée de glossaire interaction assistée par l’IA.
Unknown est une réponse, pas une menace
Tout classificateur rencontre un trafic qu’il ne peut pas expliquer. Les systèmes de protection sont conçus pour rester prudents, donc le trafic incertain rencontre souvent un défi. C’est un choix sensé à la périphérie.
À l’intérieur de votre application, un seul défaut prudent est souvent le mauvais choix. Une requête inconnue vers une page de documentation publique et une requête inconnue pour modifier le mot de passe d’un compte méritent un traitement très différent. Proof of Actor renvoie Unknown comme résultat à part entière et vous permet de définir le repli par route: l’autoriser sur les pages publiques, conserver vos contrôles existants sur les changements de compte, l’orienter vers une revue pour les actions à fort impact. Le guide sur la gestion du trafic Unknown présente les schémas.
Qui décide de la réponse
Avec la gestion des bots, c’est l’ensemble de règles à la périphérie qui décide. C’est efficace et cela maintient la cohérence des décisions sur vos propriétés.
Avec Proof of Actor, votre application décide. Le produit fournit le contexte d’acteur; votre code applique la politique. Vous pouvez servir aux agents vérifiés une API structurée au lieu de pages conçues pour des personnes, conserver l’expérience standard pour les sessions humaines, étiqueter les soumissions assistées par l’IA et demander des identifiants plus forts pour les actions sensibles lorsque vos propres conditions l’exigent. Les politiques s’écrivent par route, par classe d’acteur et par base, et elles vivent à côté du reste de votre logique métier.
L’observation d’abord
La gestion des bots est généralement installée pour appliquer des règles, parce que toute sa valeur consiste à arrêter les abus.
Proof of Actor commence en mode observation. L’installer ne change rien au comportement de votre application. Vous voyez votre véritable mix d’acteurs par route, vous examinez les preuves, vous prévisualisez l’effet d’une politique sur le trafic réel, puis vous appliquez seulement quand vous êtes prêt, une route à la fois. Le guide sur le déploiement sûr de politiques sensibles aux acteurs détaille le processus.
Comment les deux fonctionnent ensemble
La configuration la plus solide utilise les deux, chacun dans sa propre couche:
- À la périphérie, la gestion des bots arrête le credential stuffing, les abus de scraping et les attaques volumétriques.
- Dans votre application, Proof of Actor classe le trafic qui passe en Human, Human + AI, Agent ou Unknown, avec sa base.
- Dans votre code, les politiques utilisent ce contexte pour choisir l’expérience: l’API structurée pour un agent vérifié, le parcours normal pour une personne, une étiquette pour une soumission assistée par l’IA, un repli explicite pour Unknown.
- Dans vos analyses, votre équipe voit quelles routes et quels workflows chaque classe d’acteur utilise, afin que le produit et la sécurité travaillent à partir de la même image.
Enregistrer la décision de périphérie à côté du résultat d’acteur rend l’image complète: ce que la protection a fait, et qui agissait réellement.
Quand choisir l’un ou l’autre
Choisissez la gestion des bots lorsque votre principal problème est l’abus: tentatives de prise de contrôle de compte, accaparement de stock, scraping agressif ou rafales de trafic.
Choisissez Proof of Actor lorsque votre question principale concerne vos utilisateurs: quelle part de votre produit les agents utilisent déjà, quels agents appellent votre API ou votre MCP server, où les personnes assistées par l’IA rencontrent des difficultés, et quelles routes ont besoin d’une politique sensible aux acteurs.
La plupart des équipes qui exploitent une application, une API ou un MCP server en production ont besoin de réponses aux deux, ce qui explique pourquoi les deux ont leur place dans la même stack.
Démarrer
Proof of Actor est en beta privée. Les équipes fondatrices sélectionnées peuvent bénéficier jusqu’à 12 mois d’accès gratuit dans les limites d’utilisation convenues, avec un support direct de l’équipe qui le construit. Demandez un accès anticipé et dites-nous quelle application et quelle interaction vous souhaitez comprendre.