Comment un client automatisé se fait reconnaître : user-agent, adresse de contact, robots.txt et limites de débit

Objectif

Un client automatisé qu'un exploitant reconnaît dans une ligne de journal, peut joindre en cas de problème et peut maîtriser avec les moyens existants, plutôt qu'un client indiscernable d'un abus et bloqué sans distinction.

Prérequis

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

Étapes

1. Envoyer à chaque requête un en-tête User-Agent avec 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 exige que l'identifiant décrive le but du crawler ; la RFC 9110 définit cet en-tête comme une suite d'identifiants de produit, le plus important en premier, et déconseille les détails inutilement fins.
2. Choisir le jeton de produit de façon à ce qu'il puisse figurer dans une ligne user-agent de robots.txt : la RFC 9309 n'autorise que les lettres, les tirets bas et les traits d'union, et exige que le jeton soit une sous-chaîne de l'en-tête User-Agent. Un exploitant peut ainsi cibler précisément ce client avec user-agent: ExampleBot.
3. Avant de récupérer des pages d'un site, lire /robots.txt et appliquer le groupe dont le jeton correspond au sien, sans tenir compte de la casse ; en l'absence de correspondance, le groupe * s'applique ; s'il est également absent, l'accès est illimité. Comparer les chemins à partir du premier octet et appliquer la règle la plus spécifique, comme l'exige la RFC pour les crawlers.
4. Ne jamais déguiser le client en navigateur pour contourner une règle ; si un site bloque le jeton, la voie à suivre est de contacter l'adresse publiée, pas d'utiliser un autre en-tête.
5. Traiter 429 Too Many Requests (RFC 6585) comme une instruction : s'arrêter, attendre au moins la durée indiquée par Retry-After (la RFC 9110 autorise des secondes ou une date HTTP), puis reprendre à un débit plus faible. La même règle s'applique à 503 accompagné de Retry-After.
6. Tenir un budget par hôte : peu de connexions simultanées et une pause entre les requêtes vers le même hôte, plus généreuse pour les petits sites. Mettre en cache ce qui a été récupéré et utiliser des requêtes conditionnelles, afin que les lectures répétées ne coûtent rien à l'exploitant.
7. Envoyer un en-tête Accept correspondant à ce qui peut être traité, et préférer les formats destinés aux machines (flux, sitemaps, 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 avec une adresse de contact fonctionnelle ; un exploitant qui veut ralentir ou exclure le client peut le faire avec une ligne dans robots.txt ou avec des réponses 429, sans jamais avoir à bloquer une plage d'adresses qui toucherait aussi d'autres clients.

Limites et base de vérification

Étiquette et synthèse de normes, sans qualification juridique ; les conditions d'utilisation et le droit local sont des questions distinctes. La RFC 9309 régit les crawlers sur les pages publiques ; une API utilisée par clé a ses propres limites documentées, qui priment.