Le manifeste V3 des extensions Chrome expliqué

Si vous avez cherché récemment des tutoriels sur les extensions Chrome, vous avez probablement remarqué quelque chose de frustrant : la moitié des guides que vous trouvez font référence à une architecture de page d’arrière-plan qui ne fonctionne plus. Le manifeste V2 est obsolète et désactivé par défaut dans Chrome. Le manifeste V3 est la plateforme actuelle, et comprendre son architecture est le seul point de départ pratique pour le développement d’extensions en 2026.

Cet article explique ce qui a changé, pourquoi cela a changé, et comment les principales API s’articulent entre elles.

Pourquoi Chrome a abandonné le manifeste V2

Les extensions du manifeste V2 pouvaient exécuter une page d’arrière-plan persistante — un document HTML complet qui restait chargé en mémoire indéfiniment, même lorsque l’extension ne faisait rien. C’était pratique pour les développeurs, mais coûteux pour les utilisateurs. Chaque extension installée avec une page d’arrière-plan consommait continuellement de la mémoire et du processeur.

Au-delà de la performance, MV2 permettait aux extensions de charger et d’exécuter du JavaScript provenant d’URL distantes. Cela signifiait qu’une extension pouvait passer la révision du Chrome Web Store avec un code anodin, puis remplacer silencieusement une logique malveillante depuis un serveur externe plus tard. Il n’y avait pas de moyen pratique d’auditer ce qu’une extension exécutait réellement.

Ces deux problèmes — gaspillage de ressources et code distant non auditable — sont les véritables moteurs du manifeste V3.

Les changements architecturaux fondamentaux du manifeste V3 des extensions Chrome

Les service workers d’extension remplacent les pages d’arrière-plan

Dans MV3, la page d’arrière-plan persistante a disparu. Son remplaçant est un service worker d’extension — un script événementiel que Chrome lance lorsqu’il est nécessaire et termine lorsqu’il est inactif.

C’est le changement qui déstabilise le plus les développeurs venant de MV2. Un service worker n’a pas d’accès au DOM et ne reste pas actif entre les événements. Vous ne pouvez pas stocker un état dans une variable globale et vous attendre à ce qu’il persiste. Utilisez plutôt chrome.storage pour tout ce qui doit survivre entre les événements, et utilisez l’API chrome.alarms pour planifier des tâches récurrentes qui auraient auparavant été contenues dans un appel setInterval à l’intérieur d’une page d’arrière-plan.

{
  "background": {
    "service_worker": "background.js",
    "type": "module"
  }
}

declarativeNetRequest remplace webRequest bloquant

L’API webRequest de MV2 permettait aux extensions d’intercepter chaque requête réseau et de décider de manière synchrone de la bloquer ou de la modifier. Cela donnait aux extensions une visibilité étendue sur tout le trafic du navigateur — une exposition significative à la vie privée — et introduisait une latence, car chaque requête devait attendre la réponse de l’extension.

L’API declarativeNetRequest (DNR) fonctionne différemment. Vous définissez un ensemble de règles en JSON, Chrome les évalue nativement, et les extensions n’ont plus besoin d’intercepter de manière synchrone les requêtes en JavaScript pour les bloquer ou les modifier. C’est plus rapide et plus respectueux de la vie privée par conception.

Depuis Chrome 120, les limites de règles se sont considérablement étendues par rapport aux premiers jours de MV3. Des bloqueurs de contenu comme uBlock Origin Lite ont livré des versions compatibles MV3, donc l’affirmation selon laquelle MV3 « a tué les bloqueurs de publicités » n’est pas tout à fait exacte — bien que le modèle de filtrage soit véritablement plus restrictif que les approches de l’ère MV2, et l’uBlock Origin original reste exclusivement MV2 par choix de son auteur.

Plus de code hébergé à distance

Tout JavaScript exécuté par une extension MV3 doit être empaqueté à l’intérieur du package de l’extension lui-même. Le chargement de code exécutable depuis un CDN ou une API externe n’est pas autorisé. Cela rend chaque extension entièrement auditable au moment de la révision.

L’API chrome.action et l’API Offscreen

Les API browserAction et pageAction de MV2 sont unifiées dans une seule API chrome.action dans MV3. Elle gère l’icône de la barre d’outils, le texte du badge et le popup dans une interface cohérente.

Pour les cas où vous avez besoin d’accéder au DOM ou de lire de l’audio depuis un contexte d’arrière-plan — des choses qu’un service worker ne peut pas faire — MV3 fournit l’API Offscreen. Elle vous permet de créer un document minimal et caché spécifiquement pour ces tâches, sans la surcharge d’une page d’arrière-plan persistante complète. Selon Can I Use, les API offscreen associées sont désormais largement prises en charge dans les navigateurs modernes basés sur Chromium.

À quoi ressemble un manifeste MV3 minimal

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0",
  "background": { "service_worker": "background.js" },
  "action": { "default_popup": "popup.html" },
  "permissions": ["storage", "activeTab"],
  "host_permissions": ["https://example.com/*"]
}

Notez que les permissions d’hôte sont désormais déclarées séparément des permissions d’API — un changement délibéré qui donne aux utilisateurs une visibilité plus claire sur les sites auxquels une extension peut accéder.

Conclusion

Le manifeste V3 est une plateforme plus contrainte que MV2, et certaines de ces contraintes nécessitent de véritables changements architecturaux. Mais ces contraintes existent pour des raisons concrètes : moins de consommation de mémoire, pas de code distant non auditable, et moins d’exposition du trafic réseau brut aux processus d’extension. Si vous démarrez une nouvelle extension aujourd’hui, MV3 est la seule voie pratique prise en charge. Comprendre le cycle de vie du service worker et le modèle declarativeNetRequest, c’est par là que ce travail commence.

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.