« Don't crawl this page. » La phrase est polie, compréhensible et parfaitement inopérante. Dans un épisode de la série « Non-Canonical Cabinet » relayé le 22 octobre, Gary Illyes, chez Google, rappelle que le parseur de robots.txt ne reconnaît que quatre directives — user-agent, allow, disallow et sitemap — et écarte tout le reste sans message d'erreur. Le fichier n'est pas un contrat moral. C'est un format.
L'exemple cité dans la vidéo est instructif : un webmaster écrit « don't crawl secret page ». Google ne reconnaît pas la règle, ignore la ligne et peut donc explorer la page. Pas de sanction, pas d'avertissement, pas de trace. Le robot passe, et l'intention reste dans le fichier.
Quatre directives, et un silence de format
La mécanique est volontairement pauvre. Le parseur lit le fichier ligne par ligne, identifie le groupe de user-agent, puis applique allow et disallow aux chemins concernés. Sitemap sert à déclarer un plan de site. Une faute d'espacement, une syntaxe créative ou une règle maison suffisent à faire disparaître la ligne. Les commentaires précédés d'un dièse sont tolérés : Cherry Prommawin cite un site dont le robots.txt était composé à 97 % de dessin textuel et à 3 % de directives. Le fichier n'a pas cassé, il a surtout gaspillé de la bande passante.
La limite pratique compte aussi. Googlebot ne lit que les 500 premiers Kio (kibioctets) du fichier et ignore la suite. Un robots.txt bavard peut donc, à l'extrême, repousser une directive utile hors de portée. Ce n'est pas un détail de puriste : c'est la différence entre une intention et une règle réellement appliquée.
Bloquer l'accès n'est pas encadrer l'usage
La question arrive vite : peut-on laisser un robot d'IA explorer un site tout en lui interdisant d'utiliser les textes pour entraîner ses modèles ? La réponse tient dans la définition du protocole. La RFC 9309 (Request for Comments), le standard de l'IETF (Internet Engineering Task Force) que Google déclare suivre, décrit robots.txt comme un protocole de préférence d'accès. Il indique si un robot peut entrer, pas ce qu'il fait des données une fois ressorti.
Un disallow dit « n'entrez pas dans la pièce ». Il ne dit rien de ce qui se passe une fois la porte franchie.
D'où la distinction à garder en tête : le contrôle de l'exploration et la licence d'usage sont deux chantiers différents. Google propose depuis 2023 le jeton Google-Extended pour refuser l'usage des contenus par Gemini sans bloquer l'indexation dans la recherche. Cloudflare a de son côté poussé une ligne Content-Signal pour exprimer des préférences d'usage. Mais un parseur conforme à la RFC ignore une directive qu'il ne connaît pas : l'effet dépend de la volonté de l'acteur en face. Ce n'est pas rien. Ce n'est pas un droit opposable.
Ce qu'il faut vérifier dans un robots.txt
Avant de considérer le fichier comme une protection, un audit minimal s'impose. Il porte sur la syntaxe, les jetons et les adresses, pas sur le ton du message.
- Les jetons exacts. Chaque robot d'IA doit être visé par le nom publié par son éditeur. Un émoji ou un caractère non latin dans le user-agent ne fonctionne pas : le jeton n'accepte que des lettres et des tirets.
- Les adresses internationales. Les caractères accentués ou non latins doivent être écrits en encodage pourcentage, par exemple /poulet-%C3%A9pic%C3%A9 pour /poulet-épicé. Un robot qui décode mal peut ignorer toute la ligne disallow.
- La syntaxe réelle, pas l'intention. Une règle lisible par un humain peut être invalide pour un parseur. Il faut tester les motifs d'adresses et les groupes de user-agent, pas relire le fichier en diagonale.
- La sécurité. robots.txt n'empêche pas un client non coopératif d'accéder au site. Ce n'est ni une authentification, ni un pare-feu, ni une protection de données.
Le fichier reste utile, mais il ne suffit plus
Faut-il pour autant jeter le robots.txt ? Non. La plupart des robots sérieux le lisent, et un refus explicite reste un signal utile, ne serait-ce que pour documenter une position. Le problème commence quand on lui demande un travail qu'il ne peut pas faire : empêcher une collecte déjà réalisée, ou transformer une préférence en interdiction juridique.
Car un disallow posé aujourd'hui ne remet pas en cause les pages aspirées hier. Si le contenu a déjà été collecté, la réponse se situe ailleurs : conditions d'utilisation, licence, analyse juridique, surveillance des journaux d'accès. C'est moins élégant qu'une ligne dans un fichier texte. C'est aussi plus solide.
Reste une incertitude honnête : la portée réelle de signaux comme Content-Signal ou Google-Extended dépendra de ce que les éditeurs accepteront de reconnaître, et des arbitrages juridiques à venir. En attendant, la bonne méthode tient en deux vérifications : ce que le fichier dit vraiment, et ce qu'il ne peut pas dire.