Skip to content

🎙️ Podcast : Écouter (7 min)

Lightpanda — Le browser sans Chrome, intégré à Hermes

Je commence par regarder la RAM. Toujours. Quand tu fais tourner un agent vingt-quatre heures sur vingt-quatre, que le browser est le gros bout de la teub sur le serveur, la mémoire, c'est la première chose que tu regardes le matin en ouvrant htop. Actuellement, sur ma machine, Chrome OpenClaw prend la place d'un gros chien dans le canapé : deux gigas de RAM, juste pour être là, prêt à ouvrir une page. Ça marche, on vit avec, mais le 7 mai dernier, quand NousResearch a intégré Lightpanda comme backend alternatif dans Hermes, j'ai quand même levé un sourcil.

Lightpanda, c'est pas un fork de Chromium. C'est pas un patch par-dessus WebKit. C'est un browser headless écrit de zéro en Zig, ce langage qu'on commence à voir partout dans l'écosystème systèmes bas niveau. Trente-trois mille étoiles sur GitHub au moment où je parle, mille trois cents forks, licence AGPL-3.0, et une release 0.3.0 qui vient de tomber ce 13 mai. Le projet est jeune, il est clairement en beta, mais les chiffres qu'ils avancent sont suffisamment salés pour qu'on s'arrête dessus.

Deux gigas pour Chrome, cent vingt-trois mégas pour Lightpanda. Seize fois moins de mémoire. Seize. Je répète : seize. Quand tu fais tourner un homelab où chaque processus est un colocataire qui doit payer sa part du loyer mémoire, un browser qui consomme cent vingt-trois mégas au lieu de deux gigas, c'est comme passer d'un SUV à un vélo. Tu libères de la place pour autre chose, tu soulages le swap, et surtout, tu peux imaginer lancer plusieurs instances sans tuer la machine.

Et la vitesse. Les benchmarks officiels parlent de cinq secondes pour charger cent pages contre quarante-six secondes avec Chrome. Neuf fois plus rapide. Là, le cynique en moi note que les benchmarks officiels sont toujours rédigés par les gens qui veulent te vendre leur truc, et que cent pages en conditions réelles, c'est rarement cent pages Wikipedia propres. Mais même en divisant les gains par deux ou par trois, le rapport reste sidérant. Pour un agent qui scrap, qui extrait, qui navigue en boucle, chaque seconde gagnée à chaque appel de page se cumule vite. Une session de scraping qui prendrait quarante minutes avec Chrome pourrait en prendre cinq. C'est pas anodin.

Là où Lightpanda devient vraiment intéressant pour un usage agent, c'est ses quatre commandes natives. getMarkdown, getSemanticTree, getInteractiveElements, getStructuredData. Pour comprendre pourquoi c'est un game changer, il faut regarder comment on fait les choses aujourd'hui avec notre setup. On a Chrome OpenClaw, qui tourne sur le port CDP 18800, avec browser-harness devant pour l'automatisation. Quand je veux extraire du contenu d'une page, il faut injecter du JavaScript dans le DOM, attendre que le script s'exécute, parser le résultat, gérer les erreurs quand le DOM est pas encore prêt, et prier pour que la page soit pas un SPA qui met trois secondes à rendre. C'est du bricolage. Ça marche, on l'a fait cent fois, mais c'est du bricolage.

Avec getMarkdown, tu demandes la page en markdown et tu la reçois. Un appel, propre, sans injection, sans attendre que le DOM se stabilise. getSemanticTree te donne la structure sémantique de la page directement. getInteractiveElements t'extrait les boutons, les liens, les formulaires. getStructuredData te sort le JSON-LD. Pour un agent LLM, c'est du pain béni : le format markdown, c'est littéralement ce que le modèle mange le mieux. Plus besoin de pont entre le HTML du browser et le prompt. C'est natif.

Le MCP server est intégré directement dans le binaire de Lightpanda. Pas besoin de process externe, pas de configuration supplémentaire, pas de reverse proxy maison. Tu lances le binaire, il expose son protocole, Hermes se connecte, et c'est parti. Et pour ceux qui veulent la compatibilité historique, le CDP est là : WebSocket sur le port 9222, et Puppeteer comme Playwright fonctionnent avec. C'est pas un écosystème fermé, c'est pas un vendor lock-in. Tu peux Docker-iser ça en une ligne, docker run -d -p 127.0.0.1:9222:9222 lightpanda/browser:nightly, et t'as un browser headless fonctionnel.

Bon, maintenant qu'on a couvert ce qui brille, parlons de ce qui gratte.

Premièrement, CORS n'est pas encore supporté. C'est pas un détail quand ton agent doit naviguer entre des domaines différents, suivre des redirections, charger des ressources cross-origin. Chrome gère ça depuis toujours, parce que c'est son métier. Lightpanda est en version 0.3.0, les devs savent que c'est sur la roadmap, mais aujourd'hui, si tu as besoin de CORS, c'est point mort. Pour notre usage quotidien avec les bookmarks X, où on traverse régulièrement des domaines tiers via les liens partagés, ça serait un problème concret.

Deuxièmement, et c'est peut-être le plus gros pour nous : pas de UI, pas de session graphique, pas de profil persistant connecté à un compte. Notre Chrome OpenClaw a une session X/Twitter connectée dans le profil OpenClaw, avec les cookies, le login, tout le bazar. Quand je demande à l'agent de checker mes bookmarks X, de les lire, de les catégoriser, il se connecte en tant que moi, il a accès à tout. Lightpanda est headless pur. Pas d'interface, pas de session utilisateur persistante dans ce sens. Si tu veux te connecter à un site qui demande un login, t'es parti pour gérer ça manuellement à chaque session. C'est un fossé fonctionnel, pas juste technique.

Troisièmement, la maturité. Version 0.3.0, ça veut dire que les bugs sont là, que les edge cases sont nombreuses, que certains sites vont pas render correctement, que les CSS complexes vont poser problème. Chrome, même en version headless, c'est le moteur de rendu le plus testé au monde. Presque tout le web est optimisé pour Chromium. Quand tu scrapes avec Chrome, tu sais que la page va ressembler à ce qu'un humain voit. Avec Lightpanda, tu prends un risque sur chaque page. Pour du scraping de données structurées, probablement nikel. Pour du rendu fidèle de pages complexes, je serais prudents.

Alors, est-ce qu'on migre ? Franchement, pas tout de suite. Notre setup Chrome OpenClaw, c'est ce qu'on connaît, c'est ce qui marche tous les jours, et la session X connectée est un atout qu'on ne peut pas sacrifier pour le moment. Mais Lightpanda est un truc à suivre de très près. Dès que CORS sera là, dès que les sessions persistantes seront possibles, et que le projet aura gravi quelques versions de plus, la question de la migration deviendra sérieuse. Parce que seize fois moins de RAM et neuf fois plus vite, c'est pas des chiffres qu'on ignore quand on optimise un homelab.

En attendant, la beauté de l'intégration dans Hermes, c'est qu'on peut tester les deux. Chrome sur le port 18800 pour le travail quotidien, Lightpanda sur le port 9222 pour les tâches batch de scraping pur. Avoir le choix, c'est exactement ce qu'on voulait. Le reste, c'est une question de patience.