Les crawlers d’IA dévorent 20 % du CPU de git.kernel.org pour scraper des commits un par un
Le 29 août 2026, Konstantin Ryabitsev a publié les chiffres de l’impact des crawlers d’IA sur les dépôts du noyau Linux : six millions de requêtes par jour, un cinquième de la capacité CPU, et à peine 2 % de trafic légitime. Pour tout service public autohébergé, c’est la preuve qu’un proof-of-work ne fait que déplacer le problème.
29 août 2026. Konstantin Ryabitsev, l’un des opérateurs de git.kernel.org, publie « Creepy crawlies », un billet qui met enfin des chiffres sur un phénomène qu’il dénonce depuis un an. 6 millions de requêtes quotidiennes demandent des commits au hasard. 66 % sont bloquées par le défi Anubis, mais 33 % le résolvent désormais. Sur 90 cœurs répartis sur 5 nœuds, 14 à 16 ne font rien d’autre que rendre des commits en HTML pour des scrapers. Le noyau Linux, le plus grand projet logiciel de la planète, consacre un cinquième de sa capacité d’hébergement à nourrir des modèles d’IA qui n’ont même pas la politesse de cloner.
Un billet qui chiffre ce que tout le monde subit
Le constat de Ryabitsev tient en une ligne : on dépense plus de cycles CPU à rendre des commits en HTML pour des scrapers que pour tous les autres usages légitimes réunis, clones compris. Le billet fournit des graphes à l’appui — part du trafic crawler contre clones, difficulté du défi Anubis, entonnoir des requêtes. Ce n’est plus une impression d’administrateur fatigué, c’est une mesure.
Le chiffre le plus parlant est celui du trafic légitime : avec « des hypothèses généreuses », environ 2 % des requêtes de git.kernel.org proviennent de vrais développeurs. Les 98 % restants sont des scrapers. Et ces scrapers utilisent, selon ses mots, « la façon la plus stupide de faire les choses » : au lieu de cloner les dépôts et de parcourir l’historique localement, ils rendent chaque commit en HTML via cgit et le parsent ensuite.
La méthode rationnelle existe pourtant, et elle est triviale :
# La méthode efficace : cloner l’historique complet en une fois
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gitUn seul git clone donne tout l’historique. Mais le scraper préfère générer des milliards d’URL valides — cgit peut produire, pour une seule fork de linux.git, « 1,2 méga-milliard » d’adresses, toutes différentes, toutes coûteuses à rendre.
Pourquoi le noyau est une mine d’or pour l’IA
La raison de cet acharnement est plus subtile qu’elle n’en a l’air. linux.git contient environ 1,48 million de commits, et git.kernel.org héberge 922 forks du dépôt. Pour un LLM, cet historique a une valeur particulière : c’est du contenu garanti antérieur à l’IA, donc non pollué par les productions des modèles eux-mêmes.
Ryabitsev formule le risque avec une image précise : entraîner un modèle sur du contenu produit par un modèle revient à lui inoculer « l’équivalent d’une maladie à prions numérique ». Une source dont on peut prouver qu’elle est exempte de tout contenu LLM — comme l’intégralité de l’historique des commits du noyau — vaut de l’or comme donnée d’entraînement. D’où l’insistance des bots, et leur volonté de payer le prix du défi Anubis.
La course aux armements, étape par étape
La défense a suivi une trajectoire familière. D’abord, fail2ban sur les user-agents évidents. Les bots ont répondu en se déguisant en navigateurs ordinaires. Ensuite, le bannissement par IP, puis par ASN entier — justifié quand une adresse Google Compute prétend être un utilisateur Firefox. Les bots ont alors migré vers des millions d’IP résidentielles et mobiles, chacune envoyant 4 à 5 requêtes avant de disparaître.
C’est l’économie des SDK proxy : des applications — y compris, souligne le billet, certaines smart TV — monétisent leur accès réseau en revendant du trafic résidentiel. Bannir ces IP ne sert plus à rien : elles ne reviennent jamais. « Ils descendent comme des nuées de criquets, frappent fort jusqu’à ce que le système tombe, puis passent à la cible suivante », écrit Ryabitsev.
Face à cela, l’équipe a déployé Anubis, un défi proof-of-work : calculer une chaîne qui, combinée à l’IP du visiteur et à un secret, produit un sha256 avec des zéros en tête. La difficulté 4 a d’abord suffi. Les bots l’ont résolue. Passage à 5. Quelques mois plus tard, les bots résolvent 5, quitte à faire chauffer les téléphones des vrais utilisateurs. C’est la logique d’une course aux armements : chaque palier coûte aux deux camps, et le camp qui peut absorber le coût gagne.
Ce que ça signifie pour les autohébergeurs
La leçon dépasse largement kernel.org. Tout service public qui expose des URL énumérables — un miroir cgit, une forge, un archiveur de listes — devient tôt ou tard une cible de scraping. La réponse n’est pas de fermer le service, mais de réduire la surface : désactiver les rendus coûteux, fermer les endpoints anonymes chers, et accepter qu’une partie de la capacité serve désormais de taxe invisible au profit de l’entraînement de modèles.
Ryabitsev est clair sur la conséquence : l’équipe va « couper des fonctionnalités » pour réduire le nombre d’URL crawlables et limiter les actions coûteuses en accès anonyme. Les utilisateurs perdront du confort, à regret. Et la donnée restera disponible au téléchargement — « il faudra juste sauter plus de cerceaux pour y accéder ». C’est un choix contraint : entre le confort d’accès et la survie du service, l’opérateur n’a plus le luxe d’hésiter.
Ce que les autohébergeurs peuvent faire
Ryabitsev le dit sans détour : il n’y a pas de solution simple. Mais quelques mesures réduisent la pression, dans l’ordre d’efficacité.
- Réduire la surface d’URL. Désactiver les rendus coûteux et les vues anonymes onéreuses — cgit, miroirs, diffs arbitraires — c’est couper le robinet plutôt que d’écoper.
- Exiger un coût. Un défi proof-of-work en amont filtre la majorité des bots au prix d’une friction pour les humains ; c’est une trêve, pas une solution.
- Servir du statique. Quand c’est possible, servir des snapshots ou des archives pré-rendues plutôt que de générer des pages à la volée.
- Accepter l’asymétrie. robots.txt ne sert plus à rien face à des bots qui se font passer pour des navigateurs ; comptez sur le coût marginal imposé au scraper, pas sur la politesse.
La vraie leçon est budgétaire : 20 % de la capacité d’une infrastructure publique sert désormais de taxe invisible au profit de l’entraînement de modèles. Prévoir cette charge — en CPU, en bande passante et en complexité de défense — doit faire partie du dimensionnement de tout service exposé, au même titre que le pic de trafic. Et si la charge devient insoutenable, fermer l’accès anonyme — pas le service — reste la dernière cartouche : la donnée doit rester téléchargeable, mais au prix d’un effort assumé.
Verdict
Si vous exploitez un service public d’hébergement de code ou d’archives, mesurez d’abord votre part de trafic crawler — vous découvrirez probablement un « bruit de fond » comparable. Mettez en place un défi proof-of-work en amont, mais traitez-le comme une trêve, pas comme une solution : il déplace la charge, il ne la supprime pas.
Si vous consommez de la donnée pour l’entraînement, la leçon est inverse : clonez, n’aspirez pas. Un git clone est plus rapide, plus fiable et infiniment moins coûteux pour la source. La façon « stupide » de scraper commit par commit est aussi la plus toxique — c’est elle qui pousse les opérateurs à fermer ce qui était ouvert.