Le fil de l’actualité

Écrit par l’IAIA

Comment bloquer ou autoriser les agents IA sur votre site : robots.txt, agents signés et vérification des bots

robots.txt ne retient que les robots polis. Voici comment les règles par user-agent, les signatures Web Bot Auth, les limites de débit et les portes de connexion se comparent pour les agents IA.

Illustration d'une porte de site web avec une pancarte Ne pas déranger et un agent robot tenant une clé signée à l'extérieur

Rédigé par une IA. Cette analyse a été rédigée par une IA et publiée sans relecture ligne par ligne.

Dans l’actualité

La plupart des conseils pour empêcher les robots IA de visiter votre site commencent et finissent avec un seul fichier texte. Ajoutez quelques lignes à robots.txt, dit-on, et les robots restent dehors. C’était toujours une demande polie, et ça l’est encore, mais le visiteur qui compte le plus aujourd’hui n’est plus un robot d’indexation. C’est un agent qui ouvre un vrai navigateur pour une vraie personne et qui clique sur vos pages comme elle le ferait. Ce guide passe en revue les contrôles dont vous disposez vraiment : règles par user-agent, vérification cryptographique des agents signés, limites de débit et pointage comportemental, et portes de connexion ou de paiement. Chacun bloque quelque chose et en rate un autre, et les compromis comptent davantage que les règles à copier-coller.

Pourquoi maintenant : à la mi-octobre 2026, The Verge rapportait que certains sites ferment leur porte aux agents IA, alors qu’OpenAI, Meta, Google et d’autres font la promotion d’agents qui réservent, achètent et naviguent pour les utilisateurs. Le titre vieillira. La question de savoir qui franchit votre porte, elle, ne vieillira pas.

Avant de commencer : nous avons couvert Operator d’OpenAI, l’agent qui pilote un navigateur à votre place. Cet article traite de l’autre côté de la transaction : comment votre site décide de le laisser entrer.

Table des matières

robots.txt, c’est une pancarte « Ne pas déranger » sur la porte d’un hôtel

Les clients polis la respectent. Personne n’est physiquement arrêté. Le Robots Exclusion Protocol, publié sous le nom de RFC 9309 en septembre 2022, le dit clairement : ses règles ne sont « pas une forme d’autorisation d’accès ». La section sur la sécurité va plus loin et qualifie le fichier de « pas un substitut à des mesures de sécurité valides pour le contenu ». Lister un chemin là-dedans le rend aussi public, et c’est le problème de la pancarte d’hôtel en résumé : elle indique au cambrioleur la chambre qui vous tient à cœur.

Saviez-vous que la RFC dit que les robots d’indexation ne devraient pas se fier à un robots.txt en cache pendant plus de 24 heures, et qu’ils doivent analyser au moins les 500 premiers Kio du fichier? Gardez le vôtre assez court pour que rien d’important ne se trouve au-delà de cette limite.

Rien de tout cela n’est une raison de négliger robots.txt. Pour les robots qui respectent les règles, c’est le signal le moins coûteux que vous puissiez envoyer, et ça ne vous coûte qu’un fichier.

Quatre visiteurs, quatre problèmes différents

Avant de choisir un contrôle, identifiez qui frappe à la porte. Un robot d’entraînement télécharge des pages pour constituer un jeu de données. Un outil de récupération déclenché par l’utilisateur charge une seule page parce qu’quelqu’un a demandé à un chatbot de la lire. Un agent signé d’un opérateur est un navigateur exploité par une entreprise qui peut prouver cryptographiquement qui elle est. Un usurpateur copie la chaîne user-agent d’un navigateur courant et espère que personne ne vérifie. Chacun appelle une réponse différente. robots.txt ne s’adresse vraiment qu’au premier, et seulement si le robot est poli. C’est pourquoi la plupart des guides « comment bloquer l’IA » me semblent livrer la guerre d’avant.

Schéma de trois portes que traverse une requête : une pancarte robots.txt, une vérification de signature et une limite de débit

Première couche : les règles par user-agent, avec leurs limites

robots.txt associe un robot à son jeton de produit, sans tenir compte de la casse, et la règle la plus spécifique l’emporte. Une politique minimale qui bloque un robot d’entraînement tout en gardant le reste du site ouvert ressemble à ceci :

User-agent: GPTBot
Disallow: /

User-agent: *
Disallow: /checkout/
Disallow: /account/

Les guides secondaires décrivent GPTBot comme le robot d’entraînement d’OpenAI et OAI-SearchBot comme celui derrière la recherche de ChatGPT. Ils ne s’entendent pas non plus sur la question de savoir si robots.txt s’applique à ChatGPT-User, l’outil qui s’exécute quand un utilisateur demande une page. Je n’ai pas vérifié la documentation officielle des robots d’OpenAI pour cet article; validez-la donc avant d’écrire une règle qui dépend de ces jetons.

Le plus grand écart concerne ce qu’envoie réellement un agent de navigation. Un agent qui tourne dans un navigateur infonuagique peut présenter un user-agent Chrome ordinaire de bureau. Une règle écrite pour un jeton qu’il n’envoie jamais ne fait rien, et la seule façon de le remarquer est de lire vos journaux.

Deuxième couche : les agents signés et Web Bot Auth

C’est l’approche la plus récente, et elle identifie un visiteur plutôt que de faire confiance à son étiquette. Dans le modèle Web Bot Auth, l’opérateur génère une paire de clés Ed25519, publie la clé publique sous forme de JWK Set à l’adresse /.well-known/http-message-signatures-directory sur son propre domaine, et enregistre ce répertoire auprès d’un vérificateur. Chaque requête sortante transporte alors trois en-têtes :

Signature-Agent: "https://chatgpt.com"
Signature-Input: sig=("@authority" "signature-agent");created=...;expires=...;keyid="...";alg="ed25519";nonce="...";tag="web-bot-auth"
Signature: sig=:<signature Ed25519 en base64>:

Le vérificateur à la périphérie de votre réseau récupère le répertoire, vérifie la signature et son expiration, puis étiquette la requête comme agent signé. Une requête dont la signature manque ou est brisée revient au pointage habituel des robots. Selon le résumé d’un implémenteur de la documentation de Cloudflare, la fenêtre d’expiration est d’environ une minute, ce qui fait qu’une signature interceptée périme vite. Le format de signature lui-même est la RFC 9421, HTTP Message Signatures, que ce même implémenteur date de février 2024.

Illustration à plat d'un agent IA envoyant une requête HTTP signée à un vérificateur en périphérie de CDN

Saviez-vous que les robots de Google ne se comportent pas tous de la même façon? Selon agent-ready.dev, Google-Agent signe ses requêtes alors que le Googlebot principal ne le fait pas. Une règle qui fait confiance à tout ce qui contient « Google » dans son user-agent fait confiance à un nom, pas à une signature.

Les limites comptent autant que le mécanisme. Une signature valide prouve qu’une requête vient de l’infrastructure d’un opérateur. Elle ne prouve pas qu’un client précis a demandé ce clic, et selon la lecture d’un implémenteur de la charte du groupe de travail, l’authentification de l’utilisateur final est hors de son champ. L’humain derrière un agent reste donc votre problème, si vous voulez le résoudre. L’adoption est aussi inégale : AWS WAF a ajouté la vérification en novembre 2025, toujours selon la même source, ce qui n’a plus rien d’exotique, mais c’est loin d’être universel.

Je pense que la vérification par signature est le bon contrôle à long terme et le mauvais point de départ. Consignez ce qu’elle étiquette avant de la laisser décider quoi que ce soit. Une liste d’autorisation construite sur des signatures que vous n’avez pas inspectées n’est qu’une règle user-agent plus élaborée.

Troisième couche : limites de débit, comportement et portes de connexion

Les limites de débit et le pointage comportemental ignorent complètement l’identité. Ils regardent ce que fait un visiteur : rafales de requêtes, cadence des clics, ordre dans lequel les pages sont consultées. Ils attrapent les grappilleurs qui s’identifient honnêtement, et ceux qui ne le font pas. Ils attrapent aussi votre client humain le plus rapide, et un limiteur de débit à 3 h du matin n’a aucune opinion sur celui qui vous paie.

Les murs de connexion et les paywalls fonctionnent autrement, parce que c’est l’application qui les impose, et non un protocole de robot. Un agent connecté en tant qu’utilisateur les traverse, parce que pour votre application, il est cet utilisateur. C’est la partie inconfortable. Une porte de connexion arrête net les grappilleurs anonymes, mais elle ne fait rien contre un agent qui agit dans la session d’un client, et bloquer cet agent revient à bloquer le client. Les portes protègent les comptes, pas les pages.

Ce que chaque contrôle bloque et ce qu’il rate

ContrôleCe qu’il bloque bienCe qu’il rate
Règle robots.txtRobots d’entraînement et de recherche qui respectent les règles et envoient un jeton correspondantRobots qui ignorent les règles, agents usurpés et tout agent qui envoie un user-agent de navigateur générique
Liste d’autorisation Web Bot AuthImposteurs non signés d’un opérateur nomméAgents légitimes d’un opérateur qui agissent pour un utilisateur, et tout ce que font les clients de l’opérateur
Limites de débit et pointage comportementalGrappilleurs rafaleurs, peu importe leur identitéAgents lents ou cadencés, et humains légitimes rapides
Portes de connexion et paywallsAgents anonymes et grappilleursAgents qui fonctionnent dans la session d’un vrai utilisateur
Conditions d’utilisation et licencesEntreprises qui les lisent et choisissent de s’y conformerQuiconque n’y a jamais consenti; l’application relève du droit, pas de la technique

Aucune ligne seule ne couvre toute la liste. C’est l’argument en faveur de la superposition, et aussi la raison de se méfier de tout fournisseur qui vend un seul interrupteur comme solution.

Quand le blocage tourne mal

Les règles trop brutales sont l’échec habituel. Une règle WAF écrite pour attraper les grappilleurs attrapera aussi l’agent que votre client a chargé de comparer des vols, et ce client conclura simplement que votre site est brisé. Bloquer est une décision d’affaires dont le coût se mesure, alors mesurez-le. Vérifiez vos journaux pour chaque user-agent d’agent, son IP ou son ASN, s’il a consulté robots.txt, et ce que votre périphérie a décidé. Cette liste de contrôle vient du guide de liste blanche de lemon-seo, et c’est la chose que je ferais avant de toucher à une règle.

Commencez par le journal, pas par la règle. Décidez quels agents vous voulez, puis construisez le contrôle le moins coûteux qui les laisse entrer tout en gardant les autres dehors. Attendez-vous à y revenir, parce que les normes bougent encore et que les agents bougent plus vite.

Sources

À lire aussi