Les creepy crawlies de Kernel.org transforment l’accès ouvert en taxe CPU

Konstantin Ryabitsev affirme que les creepy crawlies mobilisent désormais 14 à 16 cœurs CPU sur git.kernel.org, malgré des défenses conçues pour rendre le scraping automatisé coûteux. Les robots demandent des millions de pages individuelles de commits au lieu de cloner les dépôts Git sous-jacents. Ce choix transforme une archive publique efficace en un service permanent de rendu HTML pour des machines non identifiées.

Ryabitsev, administrateur systèmes de la Linux Foundation impliqué dans l’infrastructure de kernel.org, a publié ces chiffres le 29 août 2026. Simon Willison les a mis en lumière le 7 septembre, car Datasette présente un profil de risque similaire. Il peut exposer une base de données à travers une vaste collection de pages utiles et explorables par les robots.

L’histoire immédiate concerne l’infrastructure Linux, mais le conflit va bien au-delà. Les archives techniques ouvertes ont été conçues pour aider les utilisateurs à examiner, référencer et préserver l’information. Des clients opérant à l’échelle industrielle peuvent transformer cette ouverture en obligation informatique non tarifée.

Le retournement est particulièrement marqué sur git.kernel.org. Ses mainteneurs fournissent déjà l’historique complet des dépôts via Git, un protocole conçu pour transférer efficacement cet historique. Pourtant, les scrapers emprunteraient malgré tout la voie coûteuse en calcul, en demandant des pages rendues séparément pour les commits, correctifs et diffs.

Ce comportement pousse les mainteneurs à restreindre les interfaces utilisées par les développeurs légitimes. Le service reste réactif, selon Ryabitsev, mais il désactive déjà certaines fonctionnalités et place davantage d’actions derrière des contrôles d’accès. Le coût de la hausse des robots se mesure donc autant en perte d’ouverture qu’en temps CPU.

Les creepy crawlies génèrent six millions de requêtes quotidiennes

L’ampleur est suffisante pour mobiliser l’infrastructure en continu, même lorsque le site semble fonctionner normalement pour les visiteurs humains.

Les mesures des robots de Ryabitsev font état d’environ 6 millions de requêtes quotidiennes visant des commits apparemment aléatoires. Anubis, un défi de navigateur placé devant le site principal, rejette immédiatement environ 66 % de ces requêtes. 33 % supplémentaires résolvent le défi et poursuivent vers git.kernel.org.

Ces chiffres ne prouvent pas que chaque requête soumise au défi provient d’une entreprise d’IA. Ryabitsev précise explicitement que les opérateurs ne peuvent pas identifier chaque client avec certitude. Une personne peut ouvrir un ancien commit, tandis qu’un bot peut imiter un navigateur moderne.

Les schémas de requêtes fournissent les indices les plus solides. Un client qui parcourt des commits sans rapport dans d’anciens forks inactifs ne ressemble pas à un développeur suivant une série de correctifs. Ryabitsev estime que l’activité légitime représente environ 2 % du trafic total, même en utilisant des hypothèses favorables aux utilisateurs.

La charge de travail qui en résulte occupe 14 à 16 des 90 cœurs CPU répartis sur cinq nœuds géographiquement distribués. Cela représente en moyenne environ 20 % de la capacité totale de traitement du service. La demande réelle arrive par vagues, de sorte que la charge est moins régulière qu’une allocation fixe de 20 %.

Ces cœurs effectuent une tâche étroite. Ils transforment des objets Git en pages HTML pour des clients qui analysent ensuite le résultat rendu. Ryabitsev indique que cette activité consomme plus de temps CPU que toutes les formes d’accès légitime réunies, y compris les clones Git.

Cette distinction est importante, car un clone transfère un dépôt via le modèle d’objets natif de Git. Le client reçoit l’historique et peut parcourir les commits localement. Le serveur évite de reconstruire une page de présentation pour chaque objet que le client souhaite examiner.

Les requêtes HTML inversent cette efficacité. Chaque requête demande au serveur de localiser les données du dépôt, d’exécuter cgit et de construire une réponse lisible par un humain. Le client écarte une grande partie de l’interface environnante après avoir extrait le texte recherché.

Répétée sur des millions d’URL, une page raisonnable prise individuellement devient un point d’accès machine coûteux. La planification traditionnelle des capacités considère souvent les pages vues comme des unités de travail comparables. Le cas de git.kernel.org montre pourquoi ce modèle échoue lorsqu’une URL peut déclencher bien plus de calcul qu’une autre.

Le service ne s’est pas effondré sous la charge de fond actuelle. Ryabitsev affirme que des systèmes d’intégration continue mal conçus peuvent encore provoquer des pannes plus aiguës, en particulier lorsque de nombreux nœuds effectuent simultanément des clones superficiels. Le trafic des robots crée un problème différent, car il réduit durablement la marge opérationnelle.

Cette marge perdue réduit la tolérance aux pics de trafic, aux opérations de maintenance et à l’automatisation légitime. Elle oblige également les opérateurs à consacrer du temps à l’étude de comportements adverses plutôt qu’à l’amélioration des services destinés aux développeurs du noyau. Un site web apparemment stable peut donc supporter un coût caché important.

Le changement crucial n’est pas que le code source public puisse être téléchargé. Kernel.org soutient volontairement cet usage. Le changement est que des clients non identifiés choisissent une représentation coûteuse et l’exigent à l’échelle industrielle.

Git rend les données peu coûteuses, mais HTML les rend coûteuses

Le conflit central n’oppose pas l’accès au secret. Il oppose l’accès massif efficace à l’extraction gaspilleuse page par page.

Le développement Linux a toujours bénéficié de la réplication. Les dépôts Git peuvent être clonés, les archives de listes de diffusion peuvent être copiées et les miroirs peuvent préserver des documents au-delà de la durée de vie d’un serveur unique. Kernel.org encourage cette redondance plutôt que de considérer chaque téléchargement comme une menace.

Git rend ce modèle économique en transférant les objets selon leurs relations. Un dépôt stocke les commits, arbres et contenus de fichiers sous forme d’objets adressables. Le client et le serveur négocient quels objets manquent au client, puis déplacent les données nécessaires sans recréer une page web autour de chaque commit.

L’interface web répond à un autre objectif. Elle aide un développeur à examiner une modification, partager un lien stable, comparer des révisions ou télécharger un correctif sans cloner un grand dépôt. cgit, l’interface utilisée par git.kernel.org, propose plusieurs vues car chacune répond à un flux de travail humain légitime.

Ces options multiplient aussi la surface explorable par les robots. Le dépôt principal Linux contient environ 1,48 million de commits, selon le récit de Ryabitsev. Git.kernel.org héberge environ 922 forks qui partagent largement les mêmes objets sous-jacents.

Un robot peut donc découvrir de nombreuses URL menant à un contenu de commit dupliqué. Il peut aussi demander des vues de correctifs, des rendus en texte brut, des arbres de dépôt et des comparaisons arbitraires. Le contenu est fini, mais l’espace d’URL possible devient bien plus vaste.

Il s’agit d’un mode de défaillance familier pour les sites web adossés à des bases de données. Une base peut contenir un nombre gérable d’enregistrements tandis que son interface autorise d’innombrables combinaisons de filtres, tris, paginations et comparaisons. Chaque route générée ressemble à un document supplémentaire pour un robot indiscriminé.

Willison a relié ce schéma à Datasette, son outil open source de publication de bases de données consultables sur le web. Une instance Datasette peut transformer des informations structurées en pages parcourables et résultats de requêtes. Cette accessibilité est précieuse pour les personnes, les moteurs de recherche, les chercheurs et les outils d’assistance.

Elle peut aussi exposer des combinaisons coûteuses de paramètres. Un bot n’a pas besoin de code malveillant pour créer une charge nuisible. Il lui suffit d’énumérer des liens ou de construire des URL valides plus vite que l’application ne peut les servir à faible coût.

Le même risque concerne les systèmes de documentation, les gestionnaires de tickets, les navigateurs de code, les portails de registres publics et les archives personnelles. Les sites qui transforment des données structurées à la demande sont plus vulnérables que les pages statiques, car chaque consultation peut déclencher un travail de base de données ou un rendu côté serveur.

La mise en cache aide lorsque de nombreux clients demandent la même ressource. Elle aide moins lorsque des robots répartissent délibérément ou accidentellement leurs requêtes entre des URL uniques. Les paramètres de requête, les diffs arbitraires et les anciens forks peuvent empêcher la réutilisation qui rend un cache précieux.

Les opérateurs peuvent pré-rendre les pages populaires, mais pré-rendre chaque comparaison possible est impossible. Ils peuvent aussi fournir des exports groupés, mais un robot conçu autour des liens web risque de ne jamais découvrir ou choisir la voie efficace. La disponibilité technique ne garantit pas un comportement client judicieux.

Pour les développeurs qui construisent des archives consultables, c’est un avertissement architectural. L’accès machine doit passer autant que possible par des API limitées, des flux, des exports ou des protocoles de dépôt. Les interfaces humaines ont besoin de limites qui reflètent le coût de génération de chaque réponse.

Les équipes documentant ces choix devraient aussi préserver les décisions opérationnelles avec le code. Une base de connaissances d’ingénierie consultable peut relier les politiques concernant les robots, les routes coûteuses et les éléments de preuve issus des incidents avant l’arrivée d’une nouvelle vague de trafic.

L’incident kernel.org démontre que la bande passante n’est qu’une partie de la facture. Le temps CPU, l’agitation du cache, les coûts d’observabilité et l’attention des opérateurs peuvent dominer lorsque des clients automatisés demandent à répétition des représentations dynamiques.

Anubis a augmenté le prix jusqu’à ce que les robots le paient

La preuve de travail a temporairement réduit le trafic abusif, mais les robots persistants se sont adaptés parce que les données sous-jacentes restaient précieuses.

Kernel.org a d’abord utilisé des défenses familières. Les opérateurs ont identifié des chaînes user-agent suspectes, examiné les journaux et bloqué les adresses associées à une collecte automatisée évidente. Cette approche fonctionnait tant que les robots s’identifiaient ou provenaient d’un ensemble gérable de réseaux.

Le trafic est ensuite devenu plus difficile à classifier. Ryabitsev décrit des clients se présentant comme des navigateurs ordinaires et distribuant leurs requêtes sur des sous-réseaux cloud. Bloquer un réseau entier pouvait stopper les abus, mais aussi refuser des vérifications automatisées légitimes hébergées chez le même fournisseur.

L’étape suivante a encore affaibli les contrôles fondés sur les adresses. Les requêtes ont commencé à arriver depuis un grand nombre d’adresses résidentielles et mobiles. Chaque adresse ne générait que quatre ou cinq requêtes avant de disparaître des journaux, selon Ryabitsev.

Ce schéma ressemble aux réseaux de proxys qui font transiter le trafic par des appareils grand public. Un site voit ce qui semble être une vaste population d’utilisateurs sans lien entre eux plutôt qu’une opération de scraping concentrée. Lorsqu’une adresse paraît suspecte, cette source particulière peut ne jamais revenir.

Kernel.org a répondu avec Anubis, un pare-feu web open source qui soumet les clients à un défi avant de les laisser atteindre un service en amont. Son mécanisme central est la preuve de travail, une petite tâche mathématique relativement coûteuse pour le client mais peu coûteuse à vérifier pour le serveur.

Le projet Anubis décrit le logiciel comme une défense destinée aux petits services internet confrontés à un trafic soutenu de robots d’IA. Ses mainteneurs le qualifient aussi de réponse sévère, car les défis peuvent bloquer de petits scrapers et des robots d’archivage légitimes.

Sur git.kernel.org, le défi a initialement modifié l’équation économique. Les clients automatisés ont cessé de tenter l’accès, tandis que les visiteurs humains acceptaient un délai modeste. Cette période a duré plusieurs mois.

Les bots ont ensuite commencé à résoudre le niveau de difficulté quatre. Les opérateurs ont relevé le défi au niveau cinq, nécessitant davantage de calcul côté client. Ryabitsev indique que ce réglage peut prendre plusieurs secondes sur un appareil mobile et chauffer sensiblement le téléphone.

Une difficulté plus élevée a de nouveau offert plusieurs mois de répit. Elle a également imposé un coût plus important à chaque visiteur légitime recevant le défi. L’accessibilité se dégrade lorsque du matériel ancien, des navigateurs axés sur la confidentialité, JavaScript désactivé ou des connexions instables ne peuvent pas achever le processus attendu.

Les crawlers ont fini par résoudre le niveau cinq eux aussi. Au moment du rapport de Ryabitsev, environ un tiers des 6 millions de requêtes quotidiennes de commits franchissaient l’épreuve. La preuve de travail n’était pas devenue inutile, puisqu’elle bloquait encore les deux autres tiers, mais elle ne rétablissait plus l’équilibre initial.

Ce résultat met en lumière la faiblesse centrale de la dissuasion économique. Une épreuve ne fonctionne que tant que son coût dépasse la valeur attendue pour le scraper. Un historique technique propre et précieux donne aux collecteurs une raison de dépenser davantage de ressources.

Ryabitsev soutient que l’historique des commits Linux est particulièrement attractif, car une grande partie précède la prolifération des textes générés. Des chercheurs craignent qu’un entraînement répété sur des contenus synthétiques dégrade la qualité des modèles ou amplifie des artefacts. Les archives techniques bien structurées et produites par des humains deviennent ainsi un matériau d’entraînement recherché.

Les identités et objectifs exacts des clients restent non vérifiés. Certains pourraient contribuer à l’entraînement de modèles, tandis que d’autres constitueraient des index de recherche, des jeux de données de code, des produits de sécurité ou des archives commerciales. Leur comportement commun importe davantage sur le plan opérationnel que leur étiquette.

Xe Iaso, développeur d’Anubis, a également reconnu que la preuve de travail n’est pas une réponse complète. Dans une discussion technique, Iaso a expliqué que le mécanisme vise l’économie du scraping de masse, tout en exprimant son scepticisme quant à ses effets face à des clients distribués et compétents.

Un client doté d’une automatisation de navigateur peut exécuter JavaScript, stocker des cookies et résoudre la même épreuve publique qu’une personne. Les clients distribués peuvent répartir le travail sur de nombreux appareils. Augmenter la difficulté risque alors de pénaliser les visiteurs légitimes plus rapidement que cela ne dissuade les collecteurs bien financés.

L’expérience de Kernel.org confirme ce compromis à partir de données de production. La défense a réussi, les clients adverses se sont adaptés, et les opérateurs ont augmenté le coût. Le concours ne s’est pas achevé, car l’attaquant comme le défenseur disposaient chacun d’un autre paramètre à modifier.

Les archives ouvertes sont contraintes de supprimer des fonctionnalités utiles

Le résultat le plus dommageable n’est pas une facture serveur plus élevée. C’est le recul progressif d’un accès anonyme et convivial pour les humains.

Kernel.org prévoit de réduire le nombre d’URL explorables et de restreindre les opérations coûteuses à exécuter. Ryabitsev avertit que les utilisateurs anonymes doivent s’attendre à voir certaines fonctionnalités disparaître. Les données sous-jacentes resteront téléchargeables, mais leur obtention pourra exiger des étapes supplémentaires.

Cette réponse est rationnelle pour un opérateur d’infrastructure. Si une interface génère une charge disproportionnée, la restreindre protège le reste du service. Les clones Git et les flux de travail des développeurs sont plus importants que le rendu anonyme et illimité de comparaisons arbitraires.

Pourtant, chaque restriction modifie les personnes capables d’utiliser l’archive. Un développeur ayant Git installé peut cloner un dépôt et l’examiner localement. Un étudiant suivant un lien, un journaliste vérifiant un commit ou une personne utilisant un appareil limité peut dépendre de l’interface navigateur.

Les outils de recherche automatisée peuvent également avoir des usages légitimes. L’indexation de recherche aide les utilisateurs à retrouver d’anciens correctifs. Les systèmes d’archivage préservent des éléments de preuve. Les services de sécurité établissent des corrélations entre commits et vulnérabilités. Les outils d’accessibilité peuvent récupérer des pages d’une manière qui ne ressemble pas à une navigation conventionnelle.

Les restrictions générales ne peuvent pas séparer proprement ces clients des collecteurs abusifs. L’authentification crée de la responsabilité, mais ajoute du travail administratif. Les limitations de débit réduisent les pics, mais peuvent échouer lorsque les requêtes proviennent d’adresses distribuées.

Bloquer les réseaux résidentiels exclurait de vrais foyers. Bloquer les fournisseurs cloud perturberait l’automatisation des développeurs. Exiger une preuve de travail oblige chaque visiteur à dépenser de l’électricité et du temps avant que le serveur ne sache si la requête est utile.

Robots.txt fournit un signal de politique, mais ce n’est pas un mécanisme de contrôle d’accès. La norme robots officielle indique que ses règles ne constituent pas une autorisation. Les crawlers coopératifs suivent les préférences déclarées, tandis qu’un client non identifié peut les ignorer ou se faire passer pour un navigateur.

Il en résulte une asymétrie. Les organisations responsables identifient leurs crawlers, publient de la documentation, respectent les exclusions et deviennent faciles à bloquer. Les collecteurs moins responsables cachent leur identité et répartissent leur trafic, ce qui les rend plus difficiles à arrêter.

Cette situation peut produire un résultat pervers : les crawlers conformes perdent l’accès tandis que les autres continuent. Elle rend également l’attribution du trafic peu fiable. Les opérateurs peuvent raisonnablement qualifier une catégorie comportementale de scraping par IA sans pouvoir relier les requêtes à un développeur de modèles nommé.

Cette incertitude constitue le principal point de scepticisme dans cette histoire. Les mesures de trafic de Ryabitsev sont des preuves opérationnelles directes, mais la finalité de chaque requête n’a pas été établie indépendamment. L’estimation de 98 % concerne un comportement de scraping apparent, et non une liste vérifiée d’entreprises d’IA.

Cette distinction doit orienter à la fois les politiques et le traitement journalistique. Il serait inexact d’attribuer toute la charge à un fournisseur précis sans preuves réseau. Il serait tout aussi inexact d’écarter le problème au motif que chaque client n’a pas d’identité publique.

Le préjudice mesurable existe au niveau de la couche applicative. Des millions de requêtes sélectionnent d’anciens commits, des forks dupliqués et des rendus coûteux. Une épreuve défensive bloque de nombreuses requêtes, mais des volumes substantiels paient le coût computationnel et continuent.

Cloudflare a abordé le problème plus large en offrant aux propriétaires de sites des contrôles plus granulaires pour les crawlers de recherche, d’agents et d’entraînement. Ses contrôles du trafic IA reflètent une distinction importante, car un crawler destiné à l’entraînement de modèles et un assistant sollicité par un utilisateur ne servent pas le même objectif.

Les grands réseaux de périphérie peuvent combiner l’intelligence d’adresses, les signaux des navigateurs, l’historique du trafic et des observations à l’échelle de leur clientèle. Les petits services open source disposent rarement de cette visibilité. Ils doivent prendre des décisions à partir de journaux locaux et d’identifiants imparfaits.

Cet écart concentre les dommages sur les organisations les moins capables de les absorber. Une grande plateforme commerciale peut acheter davantage de capacité et déployer une gestion spécialisée des bots. Un projet bénévole, une archive universitaire ou un éditeur indépendant peut simplement fermer des routes coûteuses.

Le web ouvert perd alors plus que quelques fonctionnalités d’interface. Il perd l’hypothèse selon laquelle publier des informations utiles et accessibles par lien est économiquement sûr. Les pages restent techniquement publiques, mais l’accès devient conditionnel, soumis à une épreuve ou disponible uniquement via des flux de données en masse.

Le véritable conflit oppose l’ouverture au calcul non tarifé

Les données ouvertes n’exigent pas que chaque représentation possible reste gratuite, anonyme et illimitée.

L’argument éthique autour du crawling porte souvent sur l’autorisation de copier du contenu. Kernel.org ajoute une deuxième question : qui doit payer pour transformer ce contenu dans le format préféré par un collecteur ?

Les dépôts Linux sont déjà accessibles par un mécanisme de transfert efficace. Les opérateurs ne retiennent pas l’historique et n’exigent pas d’en garder un contrôle exclusif. Ils s’opposent aux clients qui contraignent le service public à calculer de manière répétée une représentation plus coûteuse.

Cette différence distingue ce cas d’un simple débat sur la restriction du savoir. Un clone efficace permet à un collecteur d’assumer une grande part du coût de traitement après le transfert. Le scraping HTML commit par commit reporte le travail répété sur la source.

Un collecteur responsable devrait d’abord rechercher des exports en masse, un accès au dépôt, des flux, des sitemaps ou des API documentées. Il devrait mettre en cache les contenus récupérés, dédupliquer les forks et éviter les combinaisons arbitraires de paramètres. Il devrait également s’identifier et proposer un canal de contact fonctionnel.

La négociation du débit compte aussi. Un crawler nécessitant un volume inhabituel peut demander à un opérateur un miroir ou un export planifié. Kernel.org indique vouloir continuer à fournir des données aux personnes qui en font la demande, même si les interfaces anonymes deviennent plus restrictives.

Ces pratiques paraissent élémentaires parce que les moteurs de recherche matures les ont développées au fil des décennies. La demande liée à l’IA a élargi le nombre d’organisations qui collectent des jeux de données à l’échelle du web. Toutes les équipes ne semblent pas avoir hérité des mêmes normes opérationnelles.

Les incitations diffèrent également. Un collecteur qui s’empresse d’acquérir des contenus rares antérieurs à l’IA a intérêt à agir vite. Le coût d’une collecte inefficace retombe sur des milliers d’opérateurs de sites sans rapport entre eux. Sans contrats, application des règles ni identité fiable, le crawler ne paie pas automatiquement ce coût externe.

La preuve de travail tente de reporter une partie de la dépense sur le demandeur. Les résultats de git.kernel.org montrent à la fois l’attrait et les limites de ce modèle. Elle augmente le coût marginal, mais ne peut distinguer une requête humaine précieuse d’une requête automatisée précieuse.

Faire payer chaque crawl ouvre une autre voie possible, mais le paiement seul ne résout pas la conception du système. Un crawler peut toujours surcharger un endpoint dynamique si la tarification, les quotas et les contrôles de capacité sont mal alignés. Les petits sites ne disposent pas non plus des systèmes de facturation nécessaires pour négocier l’accès des machines.

Une meilleure découverte par protocole aiderait. Une page lisible par machine pourrait orienter les collecteurs vers un clone de dépôt, une archive compressée ou un export de données limité. Les crawlers auraient toujours besoin d’incitations ou d’obligations pour respecter cette orientation.

La conception applicative peut réduire l’exposition avant l’arrivée du trafic. Les développeurs peuvent plafonner la taille des résultats, rejeter les comparaisons déraisonnables, canoniser les URL équivalentes et attribuer des limites distinctes aux routes coûteuses. Ils peuvent précalculer les vues courantes et exiger une authentification pour les requêtes inhabituelles.

L’observabilité doit mesurer le travail plutôt que les seules requêtes. Un million de réponses statiques mises en cache peut coûter moins que quelques milliers de requêtes de base de données non mises en cache. Les opérateurs ont besoin du temps processeur par route, de l’efficacité du cache, des taux de réussite aux épreuves et du comportement des clients regroupé entre adresses.

La question politique plus profonde concerne l’identité vérifiable. Un crawler qui déclare son opérateur et son objectif peut recevoir un accès adapté. Un client distribué qui se fait passer pour des millions de navigateurs empêche toute négociation et transforme chaque requête en décision de confiance.

Tant que l’identité ne s’améliore pas, les systèmes de défense s’appuieront sur des inférences comportementales. Cela signifie que les faux positifs resteront inévitables. Le coût humain doit être suivi aussi sérieusement que le trafic bloqué, car une protection qui exclut de vrais utilisateurs peut compromettre le service qu’elle préserve.

Les créatures rampantes représentent donc autant un échec de gouvernance qu’un problème de trafic. Le web dispose de normes pour le comportement volontaire des crawlers, mais manque d’un cadre fiable pour les clients à l’échelle des machines qui ignorent ces normes.

Trois signaux montreront si la pression diminue

La prochaine phase se mesurera à travers le comportement du trafic, les fonctionnalités perdues et une meilleure responsabilité des crawlers.

Le premier signal est le taux de réussite aux épreuves sur git.kernel.org. Environ 33 % des requêtes aléatoires de commits franchissaient Anubis lorsque Ryabitsev a publié ses chiffres. Une baisse durable suggérerait que les nouveaux contrôles ont rétabli une pression économique ou amélioré la classification des clients.

Un taux de réussite stable ou en hausse indiquerait l’inverse. Il montrerait que les collecteurs continuent de valoriser suffisamment les données pour absorber chaque renforcement défensif. Une nouvelle hausse de la difficulté de l’épreuve révélerait également que le concours reste centré sur le coût plutôt que sur l’identité.

Le deuxième signal est l’ampleur des fonctionnalités anonymes que kernel.org supprime. Des restrictions limitées à des comparaisons exceptionnellement coûteuses conforteraient l’idée d’une réponse ciblée. Des pertes plus larges concernant les vues ordinaires de commits, de patches ou de navigation montreraient que la pression des crawlers transforme l’expérience publique.

Les opérateurs devraient documenter ce qui disparaît et pourquoi. Ces données aideraient d’autres projets à identifier les schémas d’URL dangereux avant d’atteindre le même point. Elles révéleraient également si les défenses préservent les processus de travail humains courants qu’elles étaient censées protéger.

Le troisième signal consiste à voir si les principaux opérateurs de crawlers adoptent des identités vérifiables et des voies d’acquisition efficaces. Des plages d’adresses publiées, des agents utilisateurs dédiés, des coordonnées de contact et des politiques de limitation de débit contraignantes permettraient aux sites de distinguer l’automatisation coopérative du scraping furtif.

Sans cette responsabilisation, le marché des défenses continuera de se tourner vers l’empreinte des navigateurs, les contrôles edge gérés, l’authentification et les accès payants. Ces outils peuvent protéger les capacités, mais ils rendent aussi la publication indépendante plus complexe.

Pour les développeurs, l’action immédiate consiste à examiner quelles routes publiques consomment le plus de CPU et combien d’URL distinctes exposent le même enregistrement sous-jacent. Vérifiez si un client en masse peut récupérer les mêmes informations via une interface moins coûteuse.

Publiez clairement cette voie, puis imposez des budgets stricts à la génération de HTML dynamique. Surveillez séparément les taux d’achèvement de la preuve de travail et les échecs rencontrés par les utilisateurs légitimes. Une défense doit réduire les calculs abusifs sans transformer chaque lecteur en victime collatérale.

Pour les créateurs d’IA, le choix responsable est plus simple. Utilisez la représentation autorisée la moins coûteuse, identifiez le crawler, respectez la politique du site et contactez les opérateurs avant de passer à l’échelle. L’accès ouvert est une invitation à utiliser des connaissances partagées, non un droit illimité sur les processeurs d’autrui.

Les bestioles rampantes de git.kernel.org ont rendu cette limite visible. Le web ouvert peut prendre en charge les lecteurs automatisés, mais seulement si ces machines cessent de considérer chaque URL publique comme une capacité de calcul gratuite.