---
title: Pourquoi WebKit
description: >-
  Pourquoi Lilo repose sur le WebKit de macOS plutôt que sur Chromium, ce que
  cela coûte en compatibilité, et comment son fork optionnel de WebKit reste
  sûr.
sidebar:
  order: 1
---
Lilo est un navigateur pour Mac construit sur WebKit, le moteur qu'utilise Safari, plutôt que sur Chromium. Cette page explique pourquoi, ce à quoi vous renoncez en échange, et comment fonctionne la version de WebKit propre à Lilo lorsqu'elle s'exécute. Lisez-la pour décider si ce compromis convient aux sites et aux extensions dont vous dépendez.

## Le moteur déjà présent dans votre Mac [#the-engine-already-in-your-mac]

macOS fournit WebKit sous forme de framework système. Lilo utilise cette copie : le même moteur que celui de Safari, mis à jour par les mêmes mises à jour de macOS. Lilo lui-même est une app native en Swift et AppKit, dont la barre latérale et les réglages sont écrits en Svelte, autour de ce moteur. Deux choses en découlent.

- **Les correctifs de sécurité arrivent avec macOS.** Lorsqu'Apple corrige une vulnérabilité de WebKit, la mise à jour de macOS ou de Safari qui apporte le correctif corrige aussi Lilo. Lilo n'a pas à publier sa propre version du moteur pour rattraper son retard.
- **Une consommation d'énergie proche de celle de Safari.** Lors d'une mesure réalisée en octobre 2026, avec les mêmes onglets sur le même Mac, Lilo a consommé à peu près autant d'énergie que Safari. Avec une page animée et quatre onglets d'arrière-plan actifs, Chrome a consommé environ trois fois plus que Lilo et Firefox environ dix fois plus. Les chiffres, la machine et la méthode figurent sur la page [Consommation d'énergie](/fr/about/energy).

## Ce que coûte WebKit [#what-webkit-costs]

Choisir WebKit est un compromis. Certaines choses fonctionnent différemment de Chrome, et quelques-unes ne peuvent pas fonctionner du tout.

- **Les extensions Chrome s'exécutent sur le runtime d'extensions de WebKit.** Lilo installe les extensions Manifest V3 depuis le Chrome Web Store et comble lui-même une bonne partie des lacunes, mais certaines API de Chrome sont absentes ou se comportent différemment. Le `webRequest` bloquant et les extensions Manifest V2 ne sont pas disponibles. La page [Compatibilité des extensions](/fr/reference/extension-compatibility) répertorie chaque différence.
- **Certaines fonctionnalités web sont absentes ou limitées.** En dehors de Safari, WebKit n'a ni Web Push, ni Apple Pay sur le web, ni DRM Widevine ou PlayReady (FairPlay fonctionne, donc les services de streaming compatibles avec Safari sont lisibles). Les clés d'accès et les clés de sécurité (WebAuthn) propres à WebKit ne fonctionnent pas encore dans les versions publiées : WebKit ne les autorise que dans un navigateur disposant d'une habilitation qu'Apple accorde app par app, et qu'Apple n'a pas encore accordée à Lilo ; la demande de clé d'accès ou de clé de sécurité d'un site échoue donc immédiatement, à moins qu'une extension de gestionnaire de mots de passe n'y réponde elle-même (ce qui n'a pas été testé). La page [Compatibilité web](/fr/reference/web-compatibility) répertorie chaque limite et indique si Lilo peut y faire quelque chose.
- **Les sites voient Safari.** Les pages web reçoivent l'agent utilisateur Safari de WebKit, si bien qu'un site sert sa version pour Safari. Une identité Chrome n'est présentée qu'au Chrome Web Store ainsi qu'aux téléchargements d'extensions et aux vérifications de mises à jour que Lilo y effectue, afin que son bouton d'installation fonctionne ; au code des extensions que vous installez, qui s'attend à Chrome, et aux serveurs que contactent leurs workers, leurs popups et leurs panneaux ; et brièvement à Google Meet, le temps qu'il vérifie la présence de Document Picture-in-Picture. Google ne cautionne pas cette pratique et pourrait modifier le store de sorte que les installations depuis Lilo cessent de fonctionner.
- **Certaines fonctionnalités d'Apple restent réservées à Safari.** L'extension Mots de passe iCloud ne peut pas joindre son app auxiliaire depuis Lilo, et Apple Pay nécessite des habilitations qu'Apple n'accorde qu'à Safari.

Si un site dont vous avez besoin ne fonctionne que dans Chrome, Lilo ne peut pas y remédier en modifiant un réglage. Essayez vos sites quotidiens avant de changer de navigateur.

## Corriger WebKit plutôt que le contourner [#fixing-webkit-instead-of-working-around-it]

Lorsqu'une page est lente ou défaillante à cause du moteur, l'approche de Lilo consiste à corriger WebKit lui-même. Chaque correctif a un bug WebKit et une pull request en amont, de sorte que Safari et toutes les apps Mac qui affichent le web en bénéficient une fois le correctif intégré. Les correctifs actuels, avec leurs bugs et leurs pull requests, sont répertoriés dans [`docs/WEBKIT_FORK.md`](https://github.com/Alexays/Lilo/blob/main/docs/WEBKIT_FORK.md#patches).

## Le fork optionnel de WebKit [#the-optional-webkit-fork]

Un correctif envoyé en amont met des mois à atteindre macOS. Pour apporter ces correctifs plus tôt, une version de Lilo peut embarquer sa propre version de WebKit : la branche `main` de WebKit, plus la courte liste de correctifs de Lilo. Elle ne fonctionne que sur les Mac avec puce Apple.

Le fork est une livraison anticipée de correctifs, jamais une exigence. Chaque fonctionnalité de Lilo fonctionne sur le WebKit de macOS, et aucune fonctionnalité ne peut dépendre de quelque chose que seul le fork possède, car le fork peut se désactiver à n'importe quel lancement.

### Pourquoi le fork ne réduit jamais votre sécurité [#why-the-fork-never-makes-you-less-safe]

Apple livre les correctifs de sécurité de WebKit dans les mises à jour de macOS avant que leur code source ne soit public, si bien qu'un WebKit compilé à partir du code source public peut être en retard sur le système. L'exécuter annulerait alors un correctif que vous avez déjà. Lilo l'empêche :

1. Lorsque le fork est empaqueté, un script parcourt les bulletins de sécurité d'Apple pour la version de macOS à laquelle il est destiné et vérifie que chaque bug WebKit qu'ils mentionnent a un commit dans le fork. La version de Safari la plus récente entièrement couverte est inscrite dans l'app.
2. À chaque lancement, avant toute autre chose, Lilo compare le Safari installé, qui suit le WebKit du système, à cette version.
3. Le fork ne s'exécute que sur la même version majeure de macOS et avec un Safari identique ou plus ancien. Un Safari plus récent, une amélioration de sécurité en arrière-plan (une version telle que « 27.0.1 (a) »), un Safari absent ou un Mac Intel utilisent tous le WebKit de macOS.

Tout doute se résout en faveur du WebKit de macOS : un bulletin que le script ne peut pas lire interrompt l'empaquetage, et un bug qu'il ne trouve pas arrête la couverture à ce point. Ainsi, après l'installation d'une mise à jour de macOS contenant des correctifs WebKit, Lilo utilise le WebKit du système, correctifs compris, jusqu'à la sortie d'une version comportant un fork recompilé.

### Voir quel moteur s'exécute [#seeing-which-engine-runs]

Les Réglages affichent le moteur à côté de la version de Lilo. Lorsque le fork s'exécute, on y lit « WebKit *version*, Lilo fork » ; sinon, c'est le WebKit de macOS qui est indiqué. Le panneau À propos et le formulaire de signalement de bug qu'ouvre Aide > Signaler un problème… affichent la même information.

Le fork a lui aussi des coûts : environ 300 Mo de plus dans l'app (75 Mo une fois compressée), et à peu près 130 ms ajoutées à la première page d'un lancement à froid, car ses frameworks ne se trouvent pas dans le cache partagé du système. Une version compilée sans fork épinglé fonctionne uniquement sur le WebKit de macOS.

## En savoir plus [#learn-more]

- [`docs/WEBKIT_FORK.md`](https://github.com/Alexays/Lilo/blob/main/docs/WEBKIT_FORK.md) : comment le fork est compilé, vérifié et embarqué.
- [Compatibilité des extensions](/fr/reference/extension-compatibility) et [Compatibilité web](/fr/reference/web-compatibility) : ce qui diffère de Chrome aujourd'hui.
- [Consommation d'énergie](/fr/about/energy) : ce que le choix du moteur implique pour la consommation.