Résumé

  • Le consensus de juin 1994 a choisi /robots.txt parce que les serveurs Web existants pouvaient le servir et qu’un robot pouvait récupérer la politique en une seule requête HTTP.
  • Le compromis associait une convention commune et prévisible à une administration par site et à une conformité volontaire ; en 1995, une discussion montra que permission, identité du robot et cadence des visites étaient des questions distinctes.

Un robot pouvait transformer un petit site en charge étonnamment lourde. Dans son introduction, le document de 1994 « A Standard for Robot Exclusion » rappelle des plaintes formulées en 1993 et 1994 : certains robots demandaient des pages trop rapidement ou les récupéraient plusieurs fois ; d’autres exploraient des arborescences virtuelles profondes, des contenus dupliqués ou temporaires, ainsi que des scripts CGI dont l’appel pouvait avoir des effets secondaires. Le problème n’était pas le manque de pages sur le Web.

Un robot qui suivait les liens pouvait franchir les limites opérationnelles d’un serveur sans mécanisme commun permettant à son exploitant de lui indiquer où s’arrêter.

La réponse proposée était un fichier texte ordinaire à une adresse fixe. Avant d’explorer un site, le robot devait récupérer l’URL locale /robots.txt. Les auteurs avançaient des raisons pratiques : la méthode pouvait être mise en œuvre sur les serveurs existants et le robot découvrait la politique avec une seule récupération de document. Une adresse à la racine évitait aussi d’apprendre à chaque robot une nouvelle adresse propre à chaque site. Le fichier pouvait nommer un robot ou utiliser un joker, puis indiquer les chemins qu’il ne devait pas récupérer. Des règles générales et des exceptions pouvaient coexister dans des groupes distincts.

Cette simplicité plaçait le contrôle au niveau du site. L’administrateur du serveur pouvait publier une politique unique pour l’ensemble de l’hôte. Le document reconnaissait la limite : dans ce fichier unique, les responsables de chaque document ne pouvaient pas entretenir directement leurs propres règles. Un processus local aurait pu regrouper plusieurs listes pour fabriquer le fichier commun, mais la proposition ne le définissait pas. La commodité d’une seule requête soulevait donc une question de gouvernance interne : qui, dans l’organisation, avait le pouvoir de fixer la politique destinée aux robots ?

Le statut de la convention était tout aussi explicite. Le document rapporte un consensus daté du 30 juin 1994 entre la majorité des auteurs de robots et d’autres personnes intéressées ; la liste www-talk avait aussi pu le commenter. Il s’appuyait sur un brouillon antérieur. Pourtant, il précisait ne pas être une norme officielle portée par un organisme de normalisation, ne pas être appliqué par une autorité et ne pas garantir que tous les robots, présents ou futurs, l’utiliseraient. Ses auteurs le présentaient comme un service commun offert par la majorité des auteurs de robots.

C’était une proposition de coordination, pas une barrière technique devant les fichiers.

Un message de mai 1995 dans les archives W3C de www-talk rendit visible une autre limite. Kee Hinckley répondit qu’un fichier de permissions pouvait indiquer à un robot les endroits à éviter, mais pas au serveur l’identité du robot. Il ajoutait que le fichier n’était pas récupéré à chaque visite, afin d’espacer les requêtes et de réduire la charge, et qu’une personne pouvait elle aussi le demander. Son message témoigne de l’explication d’un participant, pas d’une enquête sur tous les robots.

Il sépare néanmoins trois fonctions faciles à confondre : exprimer la préférence d’un site, identifier un client et décider à quelle fréquence il revient.

Le protocole acquit ensuite un autre statut institutionnel. Publié comme RFC IETF Standards Track en septembre 2022, le RFC 9309 précise et étend la méthode de Martijn Koster datant de 1994 ; il clarifie notamment les définitions, les erreurs et la mise en cache. Il énonce aussi la limite : les robots sont invités à respecter les règles, qui ne constituent pas une autorisation d’accès. Le passage d’une convention communautaire à une norme ne transforma donc pas le fichier en mécanisme d’authentification ou d’application.

Cette histoire montre où peut vivre une règle commune. Un fichier unique et prévisible abaissait le coût de participation pour les exploitants de sites comme pour les auteurs de robots. En contrepartie, l’administrateur devenait l’éditeur par défaut de la politique et le respect dépendait du client. Les sources décrivent un choix de conception et une voie de normalisation ultérieure ; elles ne disent ni combien de sites ont adopté le fichier, ni combien de requêtes il a évitées, ni quelle charge il a économisée.

Sources

  • Martijn Koster, « A Standard for Robot Exclusion », document de consensus daté du 30 juin 1994, copie du projet robots de WebCrawler : document.
  • Kee Hinckley, « Re: Byte ranges (actually robots) », archives W3C www-talk, 25 mai 1995 : message.
  • IETF, RFC 9309, « Robots Exclusion Protocol », septembre 2022 : RFC.