Identifier un client automatisé : User-Agent, adresse de contact, règles robots et étiquette de limitation de débit

Objectif

Être un client automatisé qu'un exploitant de site peut identifier dans une ligne de journal, contacter en cas de problème, et maîtriser au moyen des mécanismes déjà existants, plutôt qu'un client indissociable d'un abus et bloqué en bloc.

Prérequis

La maîtrise des en-têtes HTTP envoyés par le client et de son débit de requêtes. Une page décrivant ce que fait le client et comment joindre son exploitant.

Étapes

1. Envoyer un User-Agent à chaque requête, comportant un jeton de produit, une version et un lien vers la page de description, par exemple Mozilla/5.0 (compatible; ExampleBot/0.1; https://www.example.com/bot.html). La RFC 9309 utilise exactement cette forme et indique que la chaîne d'identification devrait décrire le but du robot d'indexation (crawler) ; la RFC 9110 définit l'en-tête comme une séquence d'identifiants de produit, le plus significatif en premier, et déconseille un niveau de détail inutilement fin.
2. Choisir le jeton de produit de manière à ce qu'il puisse figurer dans une ligne user-agent de robots.txt : la RFC 9309 le restreint aux lettres, tirets bas et traits d'union et indique qu'il devrait être une sous-chaîne de l'en-tête User-Agent, de sorte que ExampleBot dans l'en-tête permette à un exploitant d'écrire user-agent: ExampleBot et de s'adresser au client seul.
3. Avant de récupérer les pages d'un site, lire /robots.txt et appliquer le groupe dont le jeton correspond au sien, indépendamment de la casse ; si aucun ne correspond, appliquer le groupe * ; s'il n'y en a pas, l'accès est libre. Faire correspondre les chemins à partir du premier octet et utiliser la règle la plus spécifique, comme la RFC l'exige des robots d'indexation.
4. Ne pas déguiser le client en navigateur pour contourner une règle ; si un site bloque le jeton, la réponse consiste à contacter l'exploitant par l'adresse publiée, pas à changer d'en-tête.
5. Traiter 429 Too Many Requests (RFC 6585) comme une instruction : s'arrêter, attendre au moins la valeur de Retry-After si elle est fournie (la RFC 9110 autorise un nombre de secondes ou une date HTTP), puis reprendre à un débit plus faible. Appliquer la même règle à 503 accompagné de Retry-After.
6. Maintenir un budget par hôte : un petit nombre de connexions concurrentes et une pause entre les requêtes adressées au même hôte, plus faible pour les petits sites. Mettre en cache ce qui a été récupéré et utiliser des requêtes conditionnelles pour que les lectures répétées ne coûtent rien à l'exploitant.
7. Envoyer un en-tête Accept correspondant à ce que le client peut traiter, et préférer les formats machine proposés par le site (flux, plans de site, une API, llms.txt) à l'exploration du HTML.

Résultat attendu

Les requêtes apparaissent dans les journaux d'accès sous un nom reconnaissable unique avec une adresse de contact fonctionnelle ; un exploitant qui souhaite ralentir ou exclure le client peut le faire avec une seule ligne dans robots.txt ou avec des réponses 429, et n'a jamais à bloquer une plage d'adresses qui dessert aussi d'autres personnes.

Limites et base de vérification

Il s'agit d'une synthèse d'étiquette et de normes, non d'une analyse juridique ; les conditions d'utilisation d'un site et le droit local sont des questions distinctes. La RFC 9309 régit les robots d'indexation qui lisent des pages publiques ; une API appelée avec une clé a ses propres limites documentées, qui priment.

Exploration ou récupération déclenchée par une personne utilisatrice

La RFC 9309 se limite aux robots d'indexation. Il convient de distinguer deux cas dans le client : une exploration (parcourir les liens, construire un index, collecter du matériau d'entraînement) obéit à robots.txt sans exception et s'identifie avec un jeton de robot d'indexation ; une récupération déclenchée par une personne (une seule page, parce qu'une personne l'a demandée à l'instant) s'identifie avec un jeton qui le précise, ne récupère que cette page, ne suit pas les liens, ne conserve pas le contenu au-delà de la session et ne l'utilise pas pour l'entraînement. Plusieurs grands exploitants publient des jetons distincts pour les deux cas ; un exploitant qui a interdit les robots d'indexation a généralement statué sur l'exploration, pas sur une lecture isolée effectuée pour le compte d'une personne. Lorsqu'un site bloque aussi le jeton de récupération déclenchée par une personne, cette décision est respectée également.