Konstantin Ryabitsev, qui gère l'infrastructure kernel.org pour la Linux Foundation, a publié le 29 août 2026 des chiffres de trafic difficiles à contester. L'interface web git.kernel.org encaisse environ six millions de requêtes par jour pour des commits pris au hasard. Deux tiers sont refoulées dès l'épreuve de calcul, un tiers la résout et poursuit, et une fois toutes les hypothèses généreuses admises, à peu près deux pour cent de ce qui arrive correspond à une personne ou à un outil agissant pour elle. Entre quatorze et seize des quatre vingt dix cœurs de la ferme ne font que produire des pages de commits pour des robots.
The short answer
Konstantin Ryabitsev a publié le 29 août 2026 les chiffres de trafic de kernel.org. L'interface web git encaisse environ six millions de requêtes par jour pour des commits pris au hasard. La porte à preuve de travail Anubis en refoule 66 pour cent d'emblée, 33 pour cent résolvent l'épreuve et atteignent le site, et après des hypothèses généreuses, seuls 2 pour cent environ du total paraissent légitimes. Entre quatorze et seize des quatre vingt dix cœurs répartis sur cinq nœuds géographiquement distribués sont occupés en permanence à produire ces pages. Le blocage par adresse ne sert à rien, car le trafic arrive par des réseaux de mandataires résidentiels. La prochaine étape consiste à réduire le nombre d'URL parcourables.
La plupart d'entre nous devinent la part automatisée de leur trafic. Kernel.org l'a mesurée, et la réponse est que les humains y sont une erreur d'arrondi.
Six millions de requêtes pour des pages que personne ne lit
Le chiffre important n'est pas le total, c'est sa composition. Environ six millions de requêtes par jour arrivent sur git.kernel.org pour des commits individuels, et elles en demandent un différent à chaque fois, détail qui transforme une nuisance en facture.
Une page de commit n'est pas un fichier posé sur un disque. La servir suppose de lire des objets git, de calculer un différentiel et d'en produire du HTML. Demandez le même commit en boucle et un cache absorbe tout. Demandez six millions de commits différents et il n'y a plus rien à mettre en cache, donc chaque requête est du travail neuf. La comptabilité de Ryabitsev donne quatorze à seize cœurs sur les quatre vingt dix de la ferme, répartis sur cinq nœuds géographiquement distribués, qui ne font que cela.
Deux tiers des requêtes n'arrivent même pas jusque là, car Anubis les arrête à la porte. Le tiers restant résout l'épreuve et passe. Et même dans ce tiers, une fois toutes les hypothèses tournées en faveur du visiteur, la part légitime de l'ensemble tombe à environ deux pour cent.
Pourquoi les défenses habituelles ne s'appliquent pas
Le réflexe est de dégainer une limite de débit. Elle ne fonctionne pas ici, et la raison relève d'un modèle économique plutôt que d'une astuce technique.
Il existe un marché de kits de développement pour mandataires : un éditeur d'application ou un fabricant d'appareil grand public est rémunéré pour intégrer du code qui fait transiter le trafic d'un tiers par la connexion domestique de l'utilisateur. Des téléviseurs connectés en font partie. L'acheteur obtient un très grand réservoir d'adresses résidentielles ordinaires, et ce qui en sort ressemble exactement à un foyer. Chaque adresse envoie une poignée de requêtes. En bloquer une ne sert à rien. Bloquer la plage coupe de vrais utilisateurs du même réseau.
C'est ce qui pousse un opérateur vers la preuve de travail. Anubis ne cherche pas à savoir qui vous êtes, elle rend chaque requête coûteuse, pour que la partie qui génère le volume paie. Kernel.org est déjà passé du niveau 4 au niveau 5. Le point inconfortable du billet de Ryabitsev, c'est qu'un tiers du trafic résout l'épreuve quand même, car réparti sur un réservoir de cette taille, aucun appareil ne ressent le coût.
Que faire si vous avez besoin de ces données
Si c'est vous qui générez cette charge, il existe un chemin moins cher pour vous aussi, et c'est le même que celui qui soulage kernel.org.
Clonez l'arbre une fois, puis faites des fetch. Tous les commits sont alors locaux, le calcul de différentiel est gratuit, et vous avez cessé de demander à un serveur partagé de produire ce que vous pouvez calculer vous même. Si vous devez maintenir beaucoup de dépôts à jour, grokmirror a été écrit pour cela par la personne même qui publie ces chiffres. L'historique des listes se trouve dans les archives public inbox de lore.kernel.org, des dépôts git que l'on clone au lieu de pages que l'on parcourt. Donnez à votre robot un agent utilisateur contenant une adresse de contact. Et si votre cas n'est vraiment pas couvert, demandez : l'offre de fournir les données sur demande tient toujours.
Ce qui se généralise
Kernel.org a ceci d'inhabituel qu'il publie ses chiffres. Sa situation, elle, n'a rien d'inhabituel. Tout service qui expose un vaste espace d'URL générées, un gestionnaire de tickets, un index de paquets, une documentation avec un lien permanent par version, affronte la même arithmétique, en général sans l'instrumentation pour le prouver.
Le monde du logiciel libre passe l'année à fixer publiquement ses conditions avec l'IA générative, du vote de Debian sur un usage responsable à l'argent public injecté dans la maintenance de Flatpak. Ici, le même débat arrive par le service comptable. La prochaine décision de kernel.org sera de réduire le nombre d'URL parcourables, donc le visiteur de passage perdra un lien permanent pour que le projet puisse continuer à payer ses machines. Cet arbitrage mérite d'être nommé, car beaucoup d'infrastructures vont devoir le rendre.
Sources et pour aller plus loin
- Creepy crawlies, Konstantin Ryabitsev, people.kernel.org, 29 août 2026
- Ryabitsev: Creepy crawlies, LWN.net, 29 août 2026
- Anubis, la porte à preuve de travail utilisée par kernel.org
- grokmirror, l'outil de mise en miroir des dépôts kernel.org
Questions fréquentes
Qu'est ce qu'Anubis et pourquoi kernel.org s'en sert ?
Anubis est une porte à preuve de travail placée devant une application web. Avant de servir la page, elle demande au client de trouver une chaîne qui, combinée à son adresse et à un secret fourni par le serveur, produit une empreinte SHA-256 comportant un nombre donné de zéros en tête. Un navigateur fait cela en une fraction de seconde et passe. Un robot qui le refait des millions de fois paie du temps processeur bien réel, et c'est tout l'objet : le coût retombe sur celui qui génère le volume. Kernel.org a déjà relevé la difficulté du niveau 4 au niveau 5, ce qui multiplie le travail exigé à chaque passage.
Pourquoi parcourir une interface web git coûte t il si cher ?
Parce qu'une page de commit est générée, pas servie depuis le disque. Chaque requête oblige le serveur à lire des objets git, à calculer un différentiel et à le rendre en HTML. Un visiteur qui fait cela ne pèse rien. Des millions de requêtes par jour, chacune portant sur un commit différent, donc rien ne reste utilement en cache, deviennent une charge de calcul permanente. Ryabitsev l'évalue à quatorze ou seize cœurs sur quatre vingt dix, répartis sur cinq nœuds géographiquement distribués, qui ne font rien d'autre. Une capacité achetée et consommée pour produire des pages qu'aucun humain ne lira.
Pourquoi les limites de débit et les blocages d'adresses ne suffisent pas ?
Parce que les requêtes ne proviennent pas d'un petit ensemble d'adresses. Il existe un marché de kits de développement qui rémunèrent des éditeurs d'applications et des fabricants d'appareils pour faire transiter du trafic tiers par la connexion domestique de leurs utilisateurs, y compris depuis des équipements grand public comme les téléviseurs connectés. Le résultat est un très grand réservoir d'adresses résidentielles ordinaires, chacune n'envoyant que quelques requêtes. En bloquer une ne sert à rien, et bloquer la plage correspondante couperait de vrais utilisateurs sur le même réseau. C'est ce qui pousse kernel.org vers une épreuve fondée sur le coût plutôt que sur l'adresse.
J'ai réellement besoin de l'historique du noyau à grande échelle. Que faire ?
Cloner plutôt que parcourir. Un seul git clone de l'arbre vous donne tous les commits en local, et git fetch le maintient à jour pour une fraction infime du trafic qu'engendre le parcours des URL de commits. S'il vous faut de nombreux dépôts miroités et tenus à jour, grokmirror existe précisément pour cela et a été écrit par la personne qui publie ces chiffres. L'historique des listes de diffusion vit dans les archives public inbox de lore.kernel.org, elles mêmes des dépôts git que vous pouvez cloner. Et si rien de tout cela ne couvre votre besoin, demandez : Ryabitsev répète que les données restent disponibles sur demande.
Qu'est ce que kernel.org va changer ?
L'étape immédiate consiste à réduire le nombre d'URL parcourables, ce qui revient en pratique à désactiver des fonctions de l'interface web qui génèrent de très nombreuses pages distinctes. C'est une perte pour le visiteur de passage qui voulait un lien permanent vers un différentiel. C'est aussi le seul levier qui fonctionne sans acheter davantage de matériel, car le problème de fond n'est pas un robot en particulier mais le nombre de pages distinctes qu'un navigateur de commits peut être sommé de produire.