Back

Explorer Ladybird, le projet de navigateur non-Chromium

Explorer Ladybird, le projet de navigateur non-Chromium

Ladybird est un moteur de navigateur web construit de zéro — sans Chromium, sans WebKit, sans lignée Gecko — développé par la Ladybird Browser Initiative, une organisation à but non lucratif de type 501(c)(3) fondée par Andreas Kling et Chris Wanstrath. Il s’agit du premier moteur de navigateur véritablement indépendant et nouveau depuis plus d’une décennie à atteindre un niveau de conformité aux standards suffisant pour mériter l’attention des développeurs frontend. Cet article répond aux trois questions qu’un développeur se pose concrètement après avoir vu « Ladybird » faire le buzz sur Hacker News ou X : est-ce sérieux, l’alpha 2026 a-t-elle une réelle portée, et cela change-t-il quelque chose au web que vous livrez ? La réponse courte est : oui, vraisemblablement, et pas encore — mais c’est la trajectoire qui est intéressante.

Points clés à retenir

  • Ladybird est construit de zéro sous l’égide d’une organisation à but non lucratif de type 501(c)(3), la Ladybird Browser Initiative, avec Andreas Kling comme Président — ce n’est pas un fork d’un moteur existant.
  • Le web repose actuellement sur trois moteurs (Blink, WebKit, Gecko) ; le dernier nouveau moteur indépendant à avoir atteint une adoption significative remonte à avant le passage d’Opera à Blink en 2013.
  • D’après la newsletter d’avril 2026, Ladybird a déclaré 2 067 263 sous-tests Web Platform Test réussis et un taux de réussite de 97,8 % sur les sous-tests de conformité JavaScript test262 importés.
  • En février 2026, l’équipe a intégré une réimplémentation en Rust du pipeline frontend de LibJS — lexer, parser, AST, collecteur de portée et générateur de bytecode — activée par défaut.
  • Une alpha publique cible Linux et macOS en 2026 ; Ladybird est un logiciel en pré-alpha et ne convient pas à une utilisation quotidienne.

Ce qu’est Ladybird et qui le développe

Ladybird est un moteur de navigateur indépendant ne partageant aucun code avec Blink, WebKit ou Gecko, gouverné par la Ladybird Browser Initiative — une organisation à but non lucratif enregistrée sous le statut 501(c)(3). D’après la page de l’organisation du projet, la direction actuelle comprend Andreas Kling en tant que Président, Tim Flynn comme Secrétaire et Mike Shaver comme Trésorier. Le projet a débuté comme visionneuse HTML intégrée à SerenityOS, le système d’exploitation personnel de Kling, avant de se détacher en un navigateur multiplateforme autonome.

La structure de gouvernance est un indicateur de sérieux plus fiable que n’importe quelle liste de fonctionnalités. Ladybird est financé par des parrainages et des dons plutôt que par la publicité ou la vente d’appareils. Chris Wanstrath — cofondateur de GitHub — a cofondé l’Initiative, et sa famille a promis 1 million de dollars, comme annoncé sur awesomekling.github.io. La liste des sponsors du projet, publiée sur ladybird.org (consultée en avril 2026), comprend des sponsors de niveau Platine tels que FUTO, Shopify et Cloudflare, ainsi que des sponsors de niveau Or incluant la Human Rights Foundation, Proton, Guillermo Rauch et Ohne Makler. Vérifiez les niveaux actuels directement sur le site, car ils évoluent au fil de la croissance du projet.

Voilà l’élément essentiel pour les sceptiques : une entité juridique nommée, des dirigeants identifiés, des sponsors d’entreprise nommés et un engagement de financement vérifiable. Ladybird n’est pas un prototype de week-end.

Pourquoi un nouveau moteur de navigateur est si rare

Le web repose sur trois moteurs — Blink de Google, WebKit d’Apple et Gecko de Mozilla — et un véritable nouveau moteur est rare, car le coût d’entrée est considérable. La dernière fois qu’un nouveau moteur indépendant a atteint une adoption significative, Opera utilisait encore Presto ; cela a pris fin en 2013 lorsqu’Opera est passé à un navigateur basé sur Chromium, et la transition de Microsoft depuis EdgeHTML s’est conclue avec la version stable de Edge basé sur Chromium en 2020. Aujourd’hui, le web dépend largement de ces trois moteurs de rendu, Blink détenant la part dominante d’utilisation des navigateurs selon StatCounter.

Construire un nouveau moteur est exceptionnellement difficile, car il doit passer des dizaines de milliers de tests de compatibilité et gérer correctement le HTML, le CSS, le JavaScript, les graphiques, la sécurité, l’accessibilité et les performances à l’échelle du web. La référence pour cette surface est la suite Web Platform Tests (WPT), un projet de conformité inter-éditeurs. Le WPT contient des millions de sous-tests individuels ; reproduire le comportement dont dépendent les sites réels — y compris les particularités non documentées que les moteurs établis ont intégrées depuis des décennies — est précisément ce qui a historiquement condamné les moteurs indépendants. Une implémentation stricte des standards qui casse des sites reposant sur ces particularités échoue au seul test qui compte commercialement : le rendu du web existant.

C’est dans ce contexte que Ladybird se distingue. Il ne cherche pas à se démarquer par ses fonctionnalités. Il tente de franchir le seuil de conformité que la consolidation de la dernière décennie a rendu presque insurmontable.

L’architecture de Ladybird de l’intérieur

L’architecture multiprocessus de Ladybird sépare le rendu, le décodage d’images et les requêtes réseau en processus distincts et isolés, coordonnés par communication inter-processus. D’après la documentation du projet et la structure des sources, le moteur se divise en un processus UI principal et un ensemble de processus auxiliaires : WebContent gère le rendu et l’exécution des scripts, ImageDecoder décode les images, et RequestServer gère les requêtes réseau. Chaque processus de contenu web s’exécute dans un bac à sable.

L’objectif de cette séparation est le cloisonnement au niveau des frontières de processus. Le décodage de données d’image non fiables — une source historiquement fréquente de bugs de corruption mémoire — s’effectue dans ImageDecoder, isolé du processus de rendu. La gestion réseau réside dans RequestServer, isolé du contenu des pages. La séparation des processus constitue en elle-même la conception vérifiable revendiquée ; ces frontières définissent le modèle de sécurité de Ladybird, inspiré des architectures multiprocessus adoptées par les navigateurs grand public au cours des quinze dernières années.

Le travail de rendu et d’exécution de scripts est réparti entre un ensemble de bibliothèques, chacune couvrant une couche de la plateforme :

BibliothèqueResponsabilité
LibWebAnalyse HTML/CSS, mise en page et rendu
LibJSJavaScript : lexer, parser, AST, génération de bytecode et interpréteur
LibWasmAnalyse et exécution WebAssembly
LibGfxPrimitives graphiques 2D et formats d’image

LibJS mérite d’être mis en avant, car ce n’est pas un simple wrapper autour d’un moteur JavaScript existant comme V8 ou JavaScriptCore — c’est une implémentation complète avec son propre lexer, parser, AST, générateur de bytecode et interpréteur de bytecode. Ce détail est important pour la section suivante, car le frontend de ce pipeline est là où les travaux d’ingénierie les plus significatifs du projet ont récemment abouti.

Stratégie de langage : C++ au cœur, Rust en cours

Le cœur de Ladybird est écrit en C++ moderne, mais l’équipe a commencé à migrer les composants sensibles aux performances et à la sécurité vers Rust. En février 2026, le projet a intégré une réimplémentation en Rust du pipeline frontend de LibJS — couvrant le lexer, le parser, l’AST, le collecteur de portée et le générateur de bytecode — avec le pipeline Rust activé par défaut, comme rapporté dans la newsletter de février 2026. Il s’agit du développement le plus récent et le plus significatif sur le plan technique dans le projet, absent des couvertures médiatiques antérieures.

La motivation est celle qui justifie classiquement l’adoption de Rust dans un moteur de navigateur : la sécurité mémoire dans les chemins de code qui analysent des entrées non fiables. Un parser JavaScript ingère du texte arbitraire potentiellement malveillant à chaque chargement de page, ce qui en fait exactement le type de composant pour lequel une garantie de sécurité mémoire au niveau du langage élimine toute une classe de vulnérabilités. Des frontières d’interopérabilité bien définies rendent également la migration incrémentale réalisable — le frontend Rust peut transmettre du bytecode à l’interpréteur C++ existant sans réécriture complète.

Ce n’était pas la première expérimentation du projet au-delà du C++. Ladybird avait précédemment exploré Swift pour certaines parties du code, avant de supprimer tout le code Swift et de s’engager vers Rust. Le passage de « nous essayons Swift » à « le pipeline frontend Rust est activé par défaut » est un marqueur de maturité technique : le projet prend désormais des décisions de langage de manière délibérée, et les révise si nécessaire, plutôt que de traiter le C++ comme une donnée immuable.

Conformité aux standards : où en est Ladybird

En avril 2026, Ladybird a déclaré 2 067 263 sous-tests Web Platform Test réussis — en hausse par rapport à 2 003 537 lors de la période précédente — d’après la newsletter d’avril 2026, ainsi qu’un taux de réussite de 97,8 % sur 52 045 des 53 207 sous-tests de conformité JavaScript test262 importés. Ces chiffres constituent la preuve la plus claire que Ladybird est un moteur sérieux et non une démonstration.

Quelques mises en garde s’imposent pour interpréter ces chiffres honnêtement. Le nombre de sous-tests WPT est un chiffre absolu, non un pourcentage de la suite complète ; pour un classement global du taux de réussite WPT par rapport aux autres moteurs, vérifiez directement sur wpt.fyi en notant la date de consultation, car la taille de la suite et les résultats par navigateur évoluent en permanence. Le chiffre test262 est limité aux sous-tests importés, et non à la suite entière — Ladybird importe un sous-ensemble et rend compte sur cette base. Ces précisions étant apportées, le tableau est celui d’une implémentation JavaScript réussissant la grande majorité des tests de conformité qu’elle exécute, et d’une implémentation de plateforme web franchissant des millions de sous-tests WPT. C’est bien au-delà du seuil à partir duquel un moteur est capable de restituer le web réel.

Feuille de route et mises en garde honnêtes

Le site officiel cible une alpha publique en 2026 pour Linux et macOS, d’après la page d’accueil de Ladybird. Des dates de sortie bêta et stable ont circulé dans des sources secondaires, évoquant respectivement 2027 et 2028, mais ces informations ne peuvent pas être vérifiées actuellement sur ladybird.org et doivent être considérées comme indicatives plutôt que comme des engagements fermes. Les calendriers en pré-alpha glissent, et le travail de conformité d’un moteur de navigateur est par nature ouvert, de sorte que toute date au-delà de l’alpha 2026 est un objectif plutôt qu’une promesse.

La prise en charge des plateformes est plus restreinte que celle d’un navigateur finalisé, mais plus large que « Linux uniquement ». L’alpha cible Linux et macOS ; le support Windows est en développement actif, et des workflows de compilation basés sur WSL2 existent déjà pour les développeurs sous Windows souhaitant exécuter le moteur dès aujourd’hui. L’état pratique, au moment de la rédaction de cet article, est celui d’un logiciel qui se compile et s’exécute, mais qui n’est pas prêt pour une utilisation quotidienne — attendez-vous à des fonctionnalités manquantes et à des comportements approximatifs.

Pourquoi Ladybird est important pour les développeurs frontend

Un quatrième moteur de navigateur indépendant importe aux développeurs frontend comme point de pression en matière de conformité, et non comme un nouveau navigateur à cibler. Un projet qui respecte strictement les WPT et ouvre des tickets de spécification lorsque des sites réels se cassent crée une responsabilisation qu’un oligopole à deux ou trois moteurs ne génère pas. La valeur est structurelle, et non liée aux parts de marché.

Parce que la structure à but non lucratif de Ladybird ne dispose d’aucun revenu publicitaire à protéger ni d’aucun écosystème d’appareils à défendre, c’est le seul moteur visant un navigateur grand public complet sans incitation structurelle à dévier des spécifications W3C vers un agenda commercial. Servo, issu à l’origine de Mozilla et désormais sous l’égide de la Linux Foundation, partage cette posture non commerciale, mais est actuellement développé comme un moteur intégrable plutôt que comme un produit navigateur complet. La distinction devient concrète lorsqu’on se souvient que FLoC était une proposition Google Privacy Sandbox ultérieurement remplacée par Topics, et que l’Intelligent Tracking Prevention est une fonctionnalité WebKit reflétant les priorités de plateforme d’Apple. Ces deux exemples reflètent le contexte commercial de leurs organisations parentes ; un moteur dépourvu d’un tel contexte supprime entièrement cette pression.

Les particularités de rendu et d’exécution de scripts propres à chaque moteur — cas limites de mise en page CSS, différences de comportement JavaScript aux marges de la spécification — constituent la catégorie de bugs qui se manifestent en trafic de production sur une population hétérogène de navigateurs, et non lors des tests locaux sur un seul moteur. Les replays de session sur des problèmes inter-navigateurs révèlent fréquemment des échecs qui ne se reproduisaient jamais sur la machine du développeur. Plus il y a d’implémentations indépendantes réussissant la même suite de conformité, plus l’espace où ces particularités peuvent se dissimuler se réduit.

Comment suivre et essayer Ladybird

Ladybird est un logiciel en pré-alpha qui se compile et s’exécute sur Linux et macOS. La façon la plus fiable de le suivre est de consulter les canaux officiels du projet — les couvertures secondaires deviennent obsolètes en quelques semaines. Le flux ladybird.org/news publie des newsletters régulières avec les chiffres de conformité, les évolutions d’architecture et les mises à jour des jalons — c’est la source principale de toutes les affirmations de statut dans cet article. Les sources se trouvent dans le dépôt LadybirdBrowser/ladybird sur GitHub.

Pour le compiler et l’exécuter, suivez les instructions de compilation actuelles dans la documentation officielle plutôt que tout guide tiers — les listes de dépendances et les commandes de compilation changent fréquemment dans un projet évoluant aussi rapidement. Après avoir cloné le dépôt et installé les dépendances, le point d’entrée de compilation et d’exécution du projet est son script Meta :

git clone https://github.com/LadybirdBrowser/ladybird.git
cd ladybird
./Meta/ladybird.py run

La forme ./Meta/ladybird.py run remplace les anciennes commandes ladybird.sh que l’on trouve dans des tutoriels obsolètes. Traitez avec méfiance toute version de dépendance spécifique trouvée en dehors de la documentation officielle ; vérifiez les instructions de compilation pour connaître les exigences actuelles de la chaîne d’outils avant de commencer.

Ladybird est un véritable moteur de navigateur construit de zéro, bien gouverné, qui franchit des seuils de conformité sérieux — ce n’est pas une alternative viable à Chrome aujourd’hui, mais c’est la tentative la plus crédible de diversification des moteurs que le web ait connue depuis plus d’une décennie. La prochaine action concrète est de mettre ladybird.org/news en signet et de consulter les chiffres de conformité à chaque newsletter ; la trajectoire de ces chiffres vous en dira plus sur l’impact potentiel pour le web que vous livrez que n’importe quelle instantané isolé.

FAQ

Vous pouvez compiler et exécuter Ladybird sur Linux et macOS, mais il s'agit d'un logiciel en pré-alpha qui ne convient pas encore à des tests inter-navigateurs fiables. Des fonctionnalités sont manquantes et le comportement est encore approximatif, de sorte qu'un résultat positif ou négatif vous apprend peu sur la préparation à la production. Pour l'instant, suivre les comptages de sous-tests WPT dans chaque newsletter est plus instructif que de tester votre propre site, ce qui ne devient pertinent qu'une fois l'alpha publique 2026 disponible.

Non. Ladybird ne partage aucun code avec Chromium, WebKit ou Gecko et est écrit de zéro. Sa bibliothèque de rendu LibWeb, son moteur JavaScript LibJS, son moteur WebAssembly LibWasm et sa bibliothèque graphique LibGfx sont toutes des implémentations originales et non des wrappers autour de V8 ou d'un moteur existant. Le projet est né dans SerenityOS comme visionneuse HTML avant de devenir un navigateur multiplateforme autonome, et il s'inspire architecturalement des moteurs précédents sans en réutiliser le code source.

Le chiffre de 2 067 263 rapporté dans la newsletter d'avril 2026 est un décompte absolu de sous-tests Web Platform Test réussis, et non un pourcentage de la suite complète. La taille totale de la suite évolue en permanence au fur et à mesure que des tests sont ajoutés, de sorte qu'un décompte absolu ne peut pas être converti en classement sans dénominateur. Pour une comparaison globale du taux de réussite par rapport à Blink, WebKit ou Gecko, consultez wpt.fyi directement et notez la date de consultation, car les résultats varient de jour en jour.

La migration vers Rust cible les chemins de code qui analysent des entrées non fiables, où les garanties de sécurité mémoire préviennent toute une classe de vulnérabilités. La newsletter de février 2026 rapporte que le pipeline frontend de LibJS — lexer, parser, AST, collecteur de portée et générateur de bytecode — a été réimplémenté en Rust et activé par défaut, car un parser JavaScript ingère du texte potentiellement malveillant à chaque chargement de page. Des frontières d'interopérabilité bien définies permettent au frontend Rust de transmettre du bytecode à l'interpréteur C++ existant, rendant la migration incrémentale réalisable sans réécriture complète.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay