La liste d'autorisation de user agent est l'un des schémas les plus anciens du web. Vous conservez une liste de noms de robots et de clients auxquels vous faites confiance. Lorsqu'une requête arrive avec un en-tête User-Agent correspondant, vous la laissez passer, vous ignorez un défi, ou vous lui servez une page plus légère. La configuration prend quelques minutes et tout le monde dans l'équipe la comprend.
Ce schéma avait davantage de sens lorsque les principaux visiteurs automatisés étaient quelques robots d'indexation et quelques outils de supervision. Aujourd'hui, les agents IA, les assistants et les clients automatisés accèdent aux applications en nombre croissant, et beaucoup d'entre eux annoncent un nom. Certains de ces noms sont réels. D'autres sont copiés. L'en-tête ne peut pas vous dire lesquels.
Proof of Actor adopte une approche différente. Il traite une chaîne User-Agent pour ce qu'elle est, une déclaration, et la présente avec des preuves plus fortes lorsque ces preuves existent. Cette page explique les limites de l'autorisation par nom, les cas où les contrôles au niveau réseau aident, et comment les signatures vérifiées et une classe Unknown explicite changent la donne.
Version courte
| Liste d'autorisation de user agent | Proof of Actor | |
|---|---|---|
| Preuve principale | Un nom dans l'en-tête User-Agent | Signatures, déclarations et signaux, chacun avec sa base |
| Un client peut-il l'usurper ? | Oui, en envoyant la même chaîne | Une base déclarée peut être revendiquée; une base vérifiée exige la clé de signature |
| Résultat | Dans la liste ou non | Human, Human + AI, Agent ou Unknown, plus une base |
| Trafic ambigu | Traité comme non autorisé, ou autorisé par défaut | Unknown, avec un repli que vous choisissez par route |
| Personnes assistées par IA | Invisibles; elles utilisent des navigateurs ordinaires | Une classe distincte, Human + AI, quand c'est déclaré ou observé |
| Maintenance | Mises à jour manuelles de la liste quand les noms changent | Clés publiées par les opérateurs d'agents; politiques dans votre code |
| Par défaut à l'installation | Ce que la liste autorise | Observation; rien ne change tant que vous n'ajoutez pas de politique |
| Plus adapté à | Routage peu coûteux de clients connus et bien comportés | Contexte d'agent fondé sur des preuves pour les décisions produit et politique |
Le reste de la page explique chaque ligne.
Pourquoi l'autorisation par User-Agent est usurpable
L'en-tête User-Agent est défini par le client. Un navigateur le définit, un script le définit, et un framework d'agent le définit. Rien dans HTTP ne vérifie que la valeur est exacte. Si votre liste d'autorisation fait confiance à une chaîne, quiconque copie cette chaîne obtient le même traitement.
On appelle cela l'usurpation de user agent, et c'est courant pour une raison simple: cela ne coûte rien. Un scraper qui veut éviter un défi n'a qu'à emprunter le nom d'un robot d'indexation auquel vous faites confiance. Un client qui se comporte mal peut prétendre être un assistant populaire. Un outil légitime peut même envoyer une chaîne de navigateur générique parce qu'un défaut de bibliothèque l'a fait.
Le résultat est qu'une liste d'autorisation de user agent a deux modes de défaillance:
- Confiance erronée: un client non fiable revendique un nom de confiance et passe.
- Doute erroné: un client légitime envoie une chaîne inattendue ou générique et échoue.
Aucun de ces échecs n'est visible à partir du seul en-tête. C'est la limite fondamentale, et aucune quantité de maintenance de liste ne l'élimine.
À quoi l'en-tête sert encore
Cela ne signifie pas que vous devez ignorer les chaînes User-Agent. Les robots et les agents bien élevés s'identifient honnêtement, et le nom est un indice utile pour le routage, l'analytique et le débogage. Il vous indique ce qu'un client dit être.
L'endroit approprié pour cette information est une déclaration, évaluée avec d'autres preuves, pas une clé qui déverrouille l'accès à elle seule. Proof of Actor l'enregistre exactement de cette manière.
Reverse DNS et listes d'IP: des mesures partielles
De nombreuses équipes renforcent une liste d'autorisation avec des contrôles réseau. Ils aident, et il est utile de les comprendre précisément.
Vérification par reverse DNS
Certains opérateurs de robots documentent un processus de vérification: rechercher le nom d'hôte correspondant à l'adresse IP de la requête, vérifier qu'il appartient au domaine de l'opérateur, puis rechercher ce nom d'hôte et confirmer qu'il renvoie vers la même adresse IP. Lorsque cette boucle réussit, vous disposez d'une preuve réelle que la requête provient de l'infrastructure de l'opérateur.
Les limites sont pratiques. Cela ne fonctionne que pour les opérateurs qui documentent et prennent en charge cette méthode. Cela ajoute des recherches DNS que vous devez mettre en cache. Et cela vous renseigne sur le réseau, pas sur le produit ou l'agent qui a émis la requête sur ce réseau.
Plages d'IP publiées
D'autres opérateurs publient les plages d'IP utilisées par leurs clients automatisés. Faire correspondre une requête à ces plages est rapide et fournit des preuves similaires à celles du reverse DNS. Un travail de l'IETF se poursuit sur un format standard pour publier ces plages, mais en novembre 2026 il n'existe pas encore de norme arrêtée, et la couverture dépend du choix de publication de chaque opérateur.
La preuve par IP s'affaiblit aussi à mesure que davantage d'agents s'exécutent sur une infrastructure cloud partagée, derrière des proxys, ou depuis le propre appareil d'un utilisateur. Une adresse cloud peut héberger de nombreux clients sans rapport entre eux, et un agent qui agit depuis le navigateur d'une personne ressemble au trafic réseau de cette personne.
Ce qu'apportent au total les contrôles réseau
Le reverse DNS et les listes d'IP transforment certaines déclarations en quelque chose de plus solide pour un sous-ensemble d'opérateurs bien connus. Ils ne couvrent pas la longue traîne des agents et des outils, et ils n'aident pas du tout pour les personnes qui travaillent aux côtés de l'IA. Ce sont des mesures partielles: utiles, mais insuffisantes à elles seules.
Signatures contre déclarations
La forme de preuve la plus solide est une signature cryptographique. Avec HTTP Message Signatures, définies dans RFC 9421, un client signe certaines parties de chaque requête à l'aide d'une clé privée. Le vérificateur récupère la clé publique publiée par l'opérateur et contrôle la signature. Si elle est vérifiée, la requête a été signée par le détenteur de cette clé, et les parties signées n'ont pas été modifiées en chemin.
Le groupe de travail IETF Web Bot Auth standardise la manière dont les clients automatisés utilisent ces signatures et la manière dont ils publient leurs clés. Notre explication sur Web Bot Auth pour les équipes produit couvre l'état actuel.
Proof of Actor utilise une signature valide comme preuve Verified. Une chaîne User-Agent, un indice client ou une auto-description dans un corps de requête comptent comme Declared. Les signaux comportementaux et contextuels comptent comme Inferred, et sont étiquetés ainsi. Chaque résultat indique sur quelle base il repose, afin que votre équipe ne confonde jamais une affirmation avec une vérification. Consultez l'entrée base de preuve pour les définitions complètes.
Une limite s'applique même aux preuves vérifiées. Une signature valide prouve quelle clé a signé la requête. Elle ne prouve pas que l'agent est autorisé à faire ce qu'il demande. C'est une question d'autorisation d'agent, et elle reste dans votre application.
Gérer Unknown au lieu de deviner
Une liste d'autorisation force chaque requête dans l'une de deux cases: dans la liste ou non. En pratique, cela signifie que le trafic ambigu reçoit la valeur de votre défaut, et ce défaut est généralement choisi une seule fois pour tout le site.
Proof of Actor traite Unknown comme un résultat à part entière. Lorsque les preuves ne permettent pas une détermination fiable, il le dit au lieu de deviner. Vos politiques décident ensuite de ce que signifie Unknown pour chaque route:
- Sur les pages de documentation publique ou de marketing, autorisez-le.
- Sur les points de terminaison de recherche ou de listing, autorisez-le avec vos limites de débit habituelles.
- Sur les changements de compte, conservez vos contrôles existants.
- Pour les actions à fort impact, envoyez-le en revue ou demandez un signal plus fort.
Le guide sur la gestion du trafic Unknown et l'entrée classification Unknown détaillent ces schémas. Suivre votre taux de Unknown dans le temps vous indique aussi quelle part de votre trafic repose encore sur des preuves faibles.
Et pour les personnes assistées par IA ?
Une liste d'autorisation de user agent n'a rien à dire sur une personne qui utilise un assistant IA dans un navigateur ordinaire. Son User-Agent est une chaîne de navigateur normale. Pourtant, de nombreux produits veulent reconnaître cette interaction, par exemple pour étiqueter des soumissions rédigées avec l'aide de l'IA ou comprendre comment des utilisateurs assistés par l'IA avancent dans l'onboarding.
Proof of Actor signale ces interactions comme Human + AI lorsque l'assistance est déclarée ou observée via une intégration prise en charge. Il ne devine pas à partir du seul style d'écriture. En savoir plus dans interaction assistée par IA.
Passer d'une liste d'autorisation à des politiques fondées sur des preuves
Vous n'avez pas besoin de supprimer votre liste d'autorisation dès le premier jour. Une trajectoire sûre ressemble à ceci:
- Installer en mode observation. Proof of Actor ne change rien. Votre liste d'autorisation continue de fonctionner.
- Comparer. Pour chaque route, voyez quelles requêtes autorisées disposent de preuves vérifiées, lesquelles n'ont qu'une déclaration, et lesquelles finissent en Unknown.
- Prévisualiser les politiques. Rédigez une politique qui traite différemment les agents vérifiés, les agents déclarés et Unknown, puis prévisualisez son effet sur le trafic réel.
- Appliquer route par route. Commencez par les routes où un nom usurpé aurait le plus d'impact.
- Conserver la liste d'autorisation comme indice. Les noms restent utiles pour le routage et l'analytique, avec leur base visible.
Le guide sur le déploiement sûr de politiques sensibles aux acteurs couvre chaque étape, et requêtes automatisées vérifiées explique comment les clients signés s'intègrent.
Quand une liste d'autorisation suffit
Pour un routage à faible enjeu, comme servir une page plus légère à un robot connu sur du contenu public, une liste d'autorisation de user agent est souvent suffisante. Le coût d'un nom usurpé est faible.
Lorsque la décision a des conséquences, comme ignorer un défi, exposer des données plus riches ou autoriser une écriture, vous voulez une preuve que vous pouvez vérifier. C'est là que Proof of Actor trouve sa place, aux côtés des contrôles réseau et des protections en bordure que vous utilisez déjà.
Commencer
Proof of Actor est en beta privée. Les équipes fondatrices sélectionnées peuvent recevoir jusqu'à 12 months de free access dans les limites d'usage convenues, sans facturation automatique. Demandez l'accès anticipé et indiquez-nous quels clients vous autorisez aujourd'hui et quelles routes vous souhaitez protéger avec de meilleures preuves.