L'accessibilité de GitHub perturbée par les LLM

Si l'interface web ne marche pas, c'est la faute aux LLM.

En réponse à des signalements d'erreurs 429 ("trop de requêtes"), GitHub ne présente pas tout à fait les choses ainsi, mais il établit clairement un lien. Ces problèmes seraient, en l'occurrence, la "conséquence inopinée" de limites de débit mises en place la semaine dernière. Elles s'appliquent aux requêtes non authentifiées. Entre autres sur l'API REST, objet d'une recrudescence de scraping, notamment par des robots destinés à alimenter des LLM.

GitHub évoque des limites absolument nécessaires

À en croire GitHub, ces limites ont déteint sur l'expérience de navigation web. Les utilisateurs non connectés à un compte pouvaient tomber, après avoir consulté une poignée de fichiers, sur une erreur 429. Sans explication particulière. De là ont pu naître des craintes de mise en place d'une forme de datawall sur le code open source.

GitHub affirme avoir, en réaction, ajusté la logique de limitation de débit. Il assure que sa mise en oeuvre était nécessaire : la croissance subite du volume de trafic de bots menaçait de dégrader la performance de l'UI web.

Chez GitHub, les limites de débit pour l'API REST sont établies sur deux plans : "primaire" et "secondaire". Seuls les changements dans la première catégorie doivent être formellement notifiés aux utilisateurs. En l'état, sont autorisées 60 requêtes par heure pour les utilisateurs non connectés (contre 5000 pour ceux authentifiés et 15 000 pour les applications GitHub et OAuth liées à des organisations GitHub Enteprise Cloud). Ces seuils ne valent pas pour certains endpoints, plus restrictifs (recherche, par exemple). L'API GraphQL a des limites spécifiques.

Parmi les limites dites secondaires :

• 100 requêtes concurrentes (partagées entre API REST et GraphQL)
• 900 requêtes par minute sur chaque endpoint REST / 2000 sur GraphQL
• 90 secondes d'usage CPU (60 pour GraphQL) pour 1 minute de "temps réel"
• 80 requêtes de génération de contenu par minute et 500 par heure (plus bas sur certains endpoints)

La concurrence a aussi pris des mesures

Il y a quelques semaines, SourceHut - une alternative à GitHub - avait lui aussi expliqué faire face à une recrudescence du trafic de crawlers LLM. Il avait d'abord déployé, sur certains chemins, le logiciel Nepenthes. Celui-ci crée une forme de cul-de-sac en générant aléatoirement des séquences infinies de pages. Les chemins en question n'étaient alors plus accessibles sans connexion.

Dans un deuxième temps, SourceHut a déployé, sur son front-end web, le logiciel Anubis. Une solution moins "agressive" : elle soumet au navigateur un défi de type preuve de travail à résoudre avec JavaScript. Il est automatiquement contourné chez les utilisateurs connectés.

Parallèlement à la mise en place de Nepenthes, SourceHut avait bloqué le trafic en provenance des réseaux de certains CSP (dont Azure et GCP), dont provient traditionnellement un gros volume de trafic automatisé. Les utilisateurs concernés ont été invités à solliciter des exceptions pour leurs IP et/ou subnets.

Les admins d'intégrations SourceHut ont par ailleurs été sommés d'avoir un "usage responsable" de la plate-forme. Par exemple en préférant les webhooks au polling. Ou en préférant, pour la mise à jour de repos persistants, un git fetch à un fresh clone. Il leur a en outre été demandé de paramétrer un user-agent incluant une adresse e-mail de contact.

Illustration © MichaelVi - Adobe Stock