Ne bloquez pas les bots d'IA : éduquez-les

Dans un article (évidemment controversé) datant de l’année dernière, j’expliquais pourquoi le blocage des bots d’Intelligence Artificielle était une réponse maladroite au problème posé. Mon argumentaire reposait sur trois constats :

Le blocage tel que généralement proposé est techniquement fragile ;
Il est éthiquement douteux dans la mesure où il pénalise tous les robots, y compris ceux qui sont « vertueux » (par exemple, ceux qui respectent le robots.txt ou les bots d’archivage) ;
Il est intellectuellement appauvrissant, puisqu’il prive l’IA – et donc, les utilisateurs – de contenu de qualité potentiellement meilleure que ce à quoi elle est la plus exposée.

Un problème mal posé

Que l’on soit clairs d’emblée : oui, les entreprises qui maintiennent leurs bots en service veulent faire de l’argent. Comme tout le monde. Et, oui : les créateurs de contenu ont raison d’être méfiants. Mais fermer complètement la porte à l’IA mélange trois domaines différents : le droit d’accès (technique), le type d’usage (juridique) et la répartition de la valeur (financier). Ces trois domaines ne se traitent pas avec les mêmes outils.

Or, le bon débat n’est pas « faut-il laisser entrer les bots », mais « sous quelles conditions un bot peut-il entrer ». Si l’on pose la question en termes d’entrée, on ramène tout à une logique de frontière : soit le bot entre ; soit le bot n’entre pas. Mais cette formulation écrase toutes les différences importantes :

un bot de recherche n’est pas un bot d’entraînement ;
un bot identifié n’est pas un bot opaque ;
un bot qui respecte une cadence n’est pas un bot prédateur ;
un bot qui cite et renvoie du trafic n’est pas un bot qui absorbe sans contrepartie.

La question de l’accès est trop grossière : elle ne permet pas de gouverner finement.

À l’inverse, « sous quelles conditions un bot peut-il entrer ? » est la bonne question parce qu’elle remet le créateur en position de normer plutôt que de simplement subir ou interdire. Elle permet de spécifier les usages, le rythme, la politique d’identification. Autrement dit, cette question déplace le débat de la présence vers la conduite, de la peur vers la règle, du bunker vers la gouvernance.

Elle est aussi meilleure moralement, parce qu’elle refuse l’idée que la seule manière de se protéger soit de casser l’ouverture du web. Bloquer tout le monde, c’est souvent une réponse de désespoir. Poser des conditions, c’est affirmer une autorité.

Au final, le problème n’est pas qu’une machine lise (parce qu’avant que les humains ne lisent leur contenu sur Internet, il est d’abord lu par une machine : la leur), c’est qu’elle lise sans se nommer, sans rythme, sans finalité déclarée, sans contrepartie et sans responsabilité. Ainsi, si le problème est l’extraction unilatérale de valeur, la bonne réponse n’est pas de rendre la lecture impossible ; c’est de rendre son cadre explicite. On ne civilise pas le web en transformant chaque site en bunker, mais en imposant aux lecteurs automatiques des obligations lisibles, vérifiables et différenciées selon l’usage.

Contrôler l’usage plutôt que la lecture

Le standard robots.txt, tel que formalisé par le RFC 9309, n’est pas un mécanisme d’autorisation ; il exprime des souhaits que les crawlers sont censés honorer. Google rappelle d’ailleurs que son interprétation du robots.txt ne prend pas en charge crawl-delay, tandis qu’Anthropic indique au contraire supporter cette extension non standard pour ralentir ClaudeBot.

OpenAI distingue déjà plusieurs agents documentés publiquement, avec des usages et des réglages spécifiques à chacun ; Anthropic aussi, dans une moindre mesure. Cloudflare pousse encore plus loin avec les catégories search, ai-input et ai-train, qui permettent d’exprimer non pas seulement « oui/non au crawl », mais « oui/non selon l’usage du contenu ». Autrement dit : le besoin existe, mais il est encore traité de manière fragmentaire selon les acteurs. OpenAI dit d’ailleurs, dans sa réponse à la consultation britannique sur le copyright, qu’il existe « de la place pour améliorer » les standards actuels de réservation de droits.

L’un de ces standard existe déjà : RSL se présente précisément comme une manière de passer du blocage à l’énoncé de termes de licence lisibles par machine, avec attribution, paiement au crawl ou au résultat. Il est déjà formalisé et utilisable par tous.

Éduquer, au lieu de bloquer

Le blocage traite tout bot comme un intrus indistinct ; l’éducation oblige chaque bot à se présenter moralement et techniquement. Elle remet le créateur au centre, non pas comme guetteur paranoïaque, mais comme auteur de conditions. Et elle évite de punir indistinctement les usages qui peuvent être bénéfiques aux lecteurs : la recherche assistée, l’accès orienté par l’utilisateur, ou la citation.

Anubis, un « Web AI Firewall Utility » parmi les plus cités dans mes recherches sur la question du « blocage des bots d’IA », est pensé comme réponse aux scrapers. Mais sa propre documentation reconnaît que c’est une réponse « nucléaire » qui peut bloquer de plus petits scrapers et gêner des bots « vertueux » (comme ceux d’Internet Archive). C’est une logique purement défensive qui finit par casser l’écosystème ouvert d’Internet au lieu d’y introduire des règles.

Un bot vertueux est un bot responsable. Il doit respecter l’identification, la cadence, les opt-out, les anti-contournements et, idéalement, fournir de la traçabilité. Anthropic dit respecter robots.txt, les CAPTCHA et, « lorsque c’est approprié », Crawl-delay (qui, encore une fois, n’est pas une directive standard de robots.txt). OpenAI documente publiquement ses bots et leurs usages séparés. Cela ne règle pas tout, mais cela montre qu’un terrain normatif existe déjà, et que les gros acteurs du marché montre une certaine volonté de s’y soumettre officiellement.

Comment éduquer les bots

Un bot est comme un enfant : il a besoin qu’on lui impose des limites. Libre à vous, évidemment, de définir ces limites comme étant l’interdiction pure et simple, mais il est possible de faire preuve de plus de finesse.

D’une part, comme déjà mentionné plus haut, il est possible d’indiquer dans le robots.txt des directives concernant le rythme des visites. Pour autant, la plupart des entreprises contrôlant des bots demandent plutôt à ce que vous configuriez cette fréquence dans les outils pour webmasters qu’ils proposent (c’est notamment le cas chez Microsoft, mais plus chez Google qui préconise justement l’usage des erreurs 429 dont on va parler ci-dessous).

D’autre part, vous pouvez avoir recours à un code HTTP standard : le 429. Si vous estimez qu’un bot vous ratisse de façon un peu trop large, bloquez-le pendant quelques minutes, et pensez à mentionner un en-tête Retry-After. Rien que ça devrait éliminer 90% du trafic que vous jugez indésirable. Notez qu’il n’y a pas de règle universelle : c’est à vous de déterminer quelle part de votre infrastructure vous accordez à ces bots, en fonction de ses capacités matérielles et logicielles.

Enfin, si même les erreurs 429 ne les calment pas, c’est que ce ne sont pas des bots vertueux, et là, le blocage se révèle pertinent.

On punit un enfant quand il enfreint les règles, pas avant.

Sur nginx, on peut faire quelque chose comme ça :

http {
    map $http_user_agent $is_meta_bot {
        default 0;
        ~*(meta-externalagent|facebookexternalhit) 1;
    }

    server {
        listen 443 ssl;
        server_name exemple.org;

        location / {
            if ($is_meta_bot) {
                add_header Retry-After 600 always;
                return 429 "Too Many Requests\n";
            }

            proxy_pass http://127.0.0.1:3000;
        }
    }
}

Ici, le bot reçoit un 429 et l’indication d’attendre 600 secondes, soit 10 minutes.

Sous Apache, on peut marquer un User-Agent avec BrowserMatchNoCase, ajouter Retry-After avec Header always set, puis renvoyer le statut 429 avec RewriteRule. Apache documente explicitement que BrowserMatchNoCase sert à poser des variables d’environnement selon le User-Agent, que Header always set permet d’ajouter un en-tête même hors succès, et que RewriteRule [R=code] accepte aussi des codes hors 3xx ; dans ce cas, la substitution est abandonnée et le code est renvoyé tel quel.

# modules nécessaires : setenvif, headers, rewrite

BrowserMatchNoCase "(meta-externalagent|facebookexternalhit)" is_meta_bot

Header always set Retry-After "600" env=is_meta_bot

RewriteEngine On
RewriteCond %{ENV:is_meta_bot} =1
RewriteRule ^ - [R=429,L]

Caddy permet de faire la même chose proprement : header_regexp pour repérer le bot, header pour poser Retry-After, respond pour renvoyer 429, et route pour garantir que l’ordre des directives est respecté.

exemple.org {
    @metaBots header_regexp User-Agent (?i)(meta-externalagent|facebookexternalhit)

    route @metaBots {
        header Retry-After "600"
        respond "Too Many Requests" 429
    }

    reverse_proxy 127.0.0.1:3000
}

Quelques lignes à ajouter pour discipliner les bots, vous faire économiser de la bande passante et de l’énergie, sans priver le monde de ce que vous faites. C’est du donnant-donnant.

Mon expérience

J’ai ouvert récemment de façon un peu plus large ma forge Gitea (qui n’a pourtant rien de remarquable), et j’ai constaté un nombre de visites que je n’imaginais pas devoir gérer un jour. À ma grande surprise, ce n’est pas parce qu’un de mes serveurs était tombé, ni parce que je trouvais ma connexion lente que je l’ai découvert : c’est simplement en consultant les statistiques de mon serveur web. En cinq jours, j’ai accumulé près d’un million de visites sur ma forge. Du jamais vu. 99% de bots, évidemment.

Parmi eux, les moins vertueux sont ceux de Meta. Ils déboulent par cent ou deux cents machines d’un coup, et génèrent un trafic monstrueux, scrapent tout, y compris les pages de connexion, plusieurs fois par heure (voire, par minute), en continu, même si les pages n’ont pas été modifiées entre-temps. Ils ne respectent pas du tout le robots.txt qui indique aux robots de ne pas suivre les page de blame. J’ai appliqué une réponse 429 systématique à tout bot qui s’identifie comme appartenant à Meta (grâce aux adresses IP que l’entreprise publie¹). Pourtant, ils essayaient encore trop rapidement de retrouver un accès. Je les ai bloqués au niveau du firewall pendant une heure. Ça les a calmés : maintenant, ils viennent en nombre très réduit (j’en ai compté une dizaine sur une heure de journaux), ils choppent une page, et reviennent quelques minutes plus tard.

En termes de volume « incontrôlé », juste derrière Meta, on trouve ceux d’Anthropic (Claude). Je trouve ça assez ironique d’ailleurs, mais passons. Eux aussi, ils brassent en quantité. Le même traitement leur a été opposé, mais ils n’ignorent pas les 429 et se montrent un peu plus dociles ensuite. Il ne m’a pas été utile de les bloquer au niveau du firewall.

Parmi les bots les plus vertueux, il y a ceux d’OpenAI (ChatGPT). Un seul bot me visite, presque toujours le même, un document à la fois, et jamais deux fois le même document. Une connexion par seconde, c’est largement acceptable, selon mes critères. Et ceux d’Apple, une fois de temps en temps, quand ils ont vu de la lumière chez moi.

Conclusion

J’ai appris à ces bots comment ils devaient se comporter chez moi. Je ne leur ai pas fermé la porte. Je les juge à leur comportement, pas à leur existence. Est-ce que ça ne fait pas de moi un bon humain ? Ne ferais-je pas la même chose en présence d’un étranger ? Ne feriez-vous pas la même chose avec votre enfant ?

En tout cas, cela ferait sûrement de vous un meilleur administrateur système.