Bots, scrapers et Git : et si on inversait la logique ?

Soyons honnêtes : internet croule sous les bots. Scrapers, crawlers, scripts automatisés — ils tapent sur les sites 24h/24, et les hébergeurs de dépôts Git n'y échappent pas. La réponse classique des admins cramés ? Des outils comme Anubis, qui repose sur du proof-of-work pour filtrer les intrus. Ça fonctionne, techniquement. Mais avouons-le : c'est une solution laborieuse qui pénalise tout le monde.

Le proof-of-work, ce n'est pas l'idéal

Ces systèmes forcent les navigateurs à résoudre des puzzles mathématiques avant d'accéder au contenu. Exactement le même principe énergivore qu'on reproche au Bitcoin et à l'Ethereum — du travail de calcul jeté aussitôt terminé. Pour un développeur qui veut juste consulter un dépôt ou récupérer du code, attendre que son navigateur triture des nombres, c'est punitif.

On a passé des décennies à optimiser les perfs web. Chaque milliseconde compte. Les temps de connexion sont compressés jusqu'à leurs limites théoriques. Et là, on introduit délibérément des délais artificiels parce que les bots sont pénibles ? Ça ressemble à balayer tout ce travail.

Et si on retournait le problème ?

C'est là qu'intervient le concept « do-the-work » — une approche qui inverse la relation client-serveur classique de façon étonnamment élégante. Au lieu que le serveur fasse tout le travail pendant que les clients se reposent, c'est le client qui absorbe le coût computationnel d'accès à l'information.

Ça paraît bizarre dit comme ça, mais quand on parle de dépôts Git, c'est moins farfelu. Git stocke tout sous forme d'objets — commits, trees, blobs, tags. Chaque donnée affichée dans un visualiseur Git n'est qu'un calcul loin de ces primitives. Si vous avez les objets, vous avez tout.

Le visualiseur Git côté client, ça change tout

Le truc malin là-dedans, c'est que les navigateurs modernes sont parfaitement capables de faire ce travail. Un développeur (legoktm) a créé un visualiseur de dépôts Git 100% côté client qui tourne entièrement dans le navigateur. Le serveur ? Il ne fait que servir des fichiers statiques — des dépôts nus en HTTP. Pas de CGI, pas de base de données, pas de backend complexe. Juste Apache avec quelques règles de rewrite.

Le navigateur télécharge les objets à la demande, les stocke dans IndexedDB, et calcule les diffs, contenus de fichiers et logs de commits en local. En gros, il effectue un git clone partiel à la volée, récupérant les objets manquants au fur et à mesure de la navigation. Le job du serveur devient presque ridiculement simple — servir des fichiers.

Pourquoi ça compte pour les devs et les startups

Si vous gérez une startup ou une petite équipe de développement, cette approche a des avantages concrets :

La bande passante devient votre seule vraie préoccupation. Puisqu'on sert du contenu statique, on peut plaquer un CDN devant sans prise de tête. Le visualiseur devient infiniment scalable avec une complexité backend quasi nulle.

La vie privée s'améliore presque gratuitement. Une fois que le navigateur a mis en cache les objets, les visites suivantes ne récupèrent rien si rien n'a changé. Théoriquement, on peut naviguer sur un dépôt en mode offline après le premier chargement. Pas de tracking serveur à travers les requêtes de pagination.

Le déploiement devient d'une simplicité déconcertante. L'hébergement statique fonctionne partout. GitHub Pages, Netlify, Cloudflare Pages, voire un simple bucket de stockage d'objets — le visualiseur Git devient une infra qui se gère presque toute seule.

Le lien avec l'IA qui code

Voici où ça devient intéressant pour les adeptes du vibe coding. Avec la montée des outils de développement assistés par IA, on va voir de plus en plus de code généré, de dépôts créés, et de demande pour des solutions d'hébergement légères. Des systèmes comme celui-ci pointent vers un futur où l'infrastructure de développement n'a pas besoin d'être un service managé compliqué — elle peut être simple, statique, et surprenamment efficace.

La puissance de calcul dans le navigateur d'un utilisateur, c'est autant de computing gratuit qu'on peut exploiter. Au lieu de payer pour du server-side rendering, on récupère de la puissance côté client. Pour les dépôts publics à fort trafic, ça peut représenter des économies massives.

C'est ça l'avenir ?

C'est encore tôt — considérez ça comme une preuve de concept qui montre ce qui est possible, pas une solution prête pour la production. Mais l'idée de base tient la route : faire bosser le client, et le serveur peut rester léger.

Pour l'hébergement Git spécifiquement, si vous n'avez pas besoin du experience forge complète — issues, pull requests, CI/CD — et que vous voulez juste parcourir du code, cette approche pourrait remplacer les installations cgit par quelque chose de bien plus scalable et respectueux de la vie privée.

La prochaine fois que vous réfléchissez à comment protéger vos services des scrapers sans pourrir la vie des utilisateurs légitimes, pensez au concept do-the-work. Les navigateurs de vos utilisateurs ont des cycles à revendre. Vos serveurs ont des ressources limitées. Laissez les navigateurs calculer.

Parfois, la meilleure façon de résoudre un problème de scale, c'est pas de balancer plus de puissance serveur — c'est de distribuer le travail là où le calcul existe déjà.