Chrome a purgé Manifest V2 le 31 août — j’ai perdu 3 extensions open source en une nuit
Panos Petropoulos
Expert développement web · 2 septembre 2026 · 11 min de lecture
TL;DR — L’essentiel en 30 secondes
- • Le 31 août 2026, Google a supprimé définitivement du Chrome Web Store toutes les extensions Manifest V2 restantes.
- • Conséquence immédiate : plus aucune mise à jour possible par les auteurs, et plus aucune réinstallation possible par les utilisateurs.
- • Une extension MV2 installée avant Chrome 138 continue de fonctionner sur sa machine, mais sans correctif de sécurité. Si elle est désinstallée, elle est perdue.
- • Google signalait cette échéance depuis plus de quatre ans. Ce n’est pas une surprise, c’est une date butoir enfin appliquée.
- • Pour les mainteneurs open source, la vraie question n’est pas migrer ou non, mais quelle partie du code ne peut pas migrer : webRequest bloquant, code distant, état persistant en background.
- • Notre plan de sortie en 5 points est en fin d’article, avec l’audit à lancer aujourd’hui sur votre dépôt.
Il y a des dépréciations qu’on regarde venir pendant des années sans jamais y croire tout à fait. La fin de Manifest V2 en faisait partie. Annoncée en 2021, repoussée plusieurs fois, contestée par une partie de l’écosystème, elle avait fini par devenir une sorte de bruit de fond dans les issues GitHub des projets d’extensions. Le 31 août 2026, le bruit de fond s’est arrêté : Google a purgé le Chrome Web Store des dernières extensions Manifest V2 encore listées.
Je l’ai découvert de la manière la plus banale qui soit. Un lundi matin, un utilisateur ouvre une issue sur un de nos dépôts : « impossible de réinstaller l’extension après avoir changé de poste ». Trois heures plus tard, deux autres projets que nous maintenons remontaient le même symptôme. Aucune erreur, aucun mail d’avertissement le jour J : simplement des pages Web Store qui ne répondent plus, et des utilisateurs qui ne comprennent pas pourquoi l’outil qu’ils utilisaient vendredi a disparu lundi.
Cet article n’est pas un plaidoyer contre Manifest V3. Le débat technique a eu lieu, longuement, et il est largement épuisé. C’est un état des lieux opérationnel destiné aux mainteneurs : ce qui a réellement changé le 31 août, ce qui continue de fonctionner, ce qui est définitivement perdu, et comment décider en une heure si votre projet migre, bascule ou s’arrête.
Ce qui a réellement changé le 31 août 2026
La confusion la plus répandue depuis lundi consiste à croire que Chrome a désactivé les extensions MV2 sur les machines des utilisateurs. Ce n’est pas ce qui s’est produit ce jour-là, et la nuance a des conséquences pratiques importantes.
La désactivation dans les canaux stables du navigateur avait déjà eu lieu lors des étapes précédentes de la feuille de route. Ce qui s’est passé le 31 août est de nature différente : c’est la fermeture du canal de distribution. Le Chrome Web Store ne référence plus ces extensions. Un auteur ne peut plus publier de nouvelle version. Un utilisateur ne peut plus les installer ni les réinstaller.
Le point réellement irréversible tient en une phrase : une extension MV2 désinstallée est définitivement perdue. Pour un utilisateur ayant conservé une installation antérieure à Chrome 138, l’extension peut encore fonctionner. Mais elle ne recevra plus jamais de correctif, y compris de sécurité. Et le premier changement de machine, la première réinstallation du navigateur, le premier nouveau profil suffisent à la faire disparaître.
Pour un mainteneur open source, cela signifie que la base installée ne peut désormais plus que décroître, sans aucun levier d’action. C’est une situation nouvelle : on a l’habitude des dépréciations qui imposent un travail, beaucoup moins de celles qui suppriment purement et simplement la capacité d’agir.
Ce qui survit, ce qui meurt — état au 31 août 2026
Notre avis d’expert n°1 — le vrai coût n’est pas technique
Sur les trois projets que nous maintenons, le travail de migration représentait entre quatre heures et trois semaines selon l’extension. Ce n’est pas ce qui a coûté le plus cher. Le coût réel a été la rupture du lien avec les utilisateurs : plus de page Store, donc plus de canal d’annonce, plus d’avis, plus de statistiques d’installation. Un mainteneur qui n’avait pas de dépôt public visible ni de liste de diffusion s’est retrouvé sans aucun moyen de prévenir sa base installée. C’est la leçon que nous retenons : pour un projet open source, le Store n’était pas qu’un canal de distribution, c’était le canal de communication. Et il n’a jamais été à nous.
Pourquoi certaines extensions n’ont jamais pu migrer
Une idée fausse circule depuis lundi : les extensions supprimées seraient celles de mainteneurs négligents qui auraient ignoré quatre ans d’avertissements. C’est vrai pour une partie d’entre elles, notamment les projets abandonnés. Ce n’est pas vrai pour l’autre partie, et la distinction mérite d’être faite honnêtement.
Le point de blocage principal reste le remplacement de l’API webRequest bloquante par declarativeNetRequest. La différence n’est pas cosmétique. Avec webRequest bloquant, votre code s’exécutait à chaque requête et pouvait décider dynamiquement, avec un contexte arbitraire, de laisser passer ou non. Avec declarativeNetRequest, vous déclarez à l’avance un jeu de règles que le navigateur applique lui-même, sans jamais exécuter votre code. C’est meilleur pour la performance et pour la vie privée — l’extension ne voit plus passer le trafic. C’est aussi structurellement moins expressif.
Le deuxième blocage est l’interdiction du code distant. Beaucoup d’extensions mettaient à jour leurs règles ou leur logique en récupérant un fichier depuis un serveur, sans repasser par une publication. Cette pratique est désormais interdite. Pour un outil dont la valeur dépend de la fraîcheur de ses règles, cela signifie qu’une mise à jour de règles devient une publication complète, avec le délai de revue associé.
Le troisième blocage est plus insidieux : le passage des background pages persistantes aux service workers. Un service worker peut être arrêté par le navigateur à tout moment. Tout état conservé en mémoire disparaît alors silencieusement. Le symptôme classique est une extension qui fonctionne parfaitement en développement, puis se comporte de façon erratique chez les utilisateurs après quelques minutes d’inactivité. Ce n’est pas une migration d’API, c’est un changement de modèle mental sur la durée de vie du code.
Notre avis d’expert n°2 — l’audit qui prédit la charge de travail
Avant d’estimer une migration, nous lançons systématiquement trois recherches dans le dépôt : les occurrences de webRequest avec l’option blocking, les appels à eval ou à des scripts chargés depuis une URL distante, et les variables globales déclarées dans le script de background. Le résultat donne une estimation étonnamment fiable. Zéro occurrence dans les trois catégories : comptez une demi-journée. Des globales de background uniquement : deux à quatre jours pour passer sur un stockage explicite. Du webRequest bloquant au cœur de la logique métier : ce n’est plus une migration, c’est une réécriture, et la question honnête devient celle de l’opportunité de la mener.
Une extension ou un outil interne bloqué par la fin de Manifest V2 ?
Nous auditons le code, chiffrons la migration MV3 et vous disons franchement quand elle n’en vaut pas la peine. Discutons-en.
Parler de votre migrationL’impact sur l’écosystème open source : trois effets déjà visibles
Premier effet : la fragmentation des cibles. Firefox continue de supporter l’API webRequest bloquante. Depuis lundi, plusieurs projets qui traitaient Firefox comme une cible secondaire en ont fait leur cible principale, voire unique. Pour un mainteneur bénévole, maintenir deux implémentations divergentes n’est pas soutenable : le choix se fait, et il se fait souvent au détriment de Chrome.
Deuxième effet : le risque de reprise malveillante. C’est le point qui nous inquiète le plus. Quand une extension populaire disparaît, la demande, elle, ne disparaît pas. Les utilisateurs cherchent un remplaçant portant le même nom, et des clones apparaissent. Nous avons déjà documenté ce schéma sur d’autres écosystèmes d’extensions dans notre analyse des 77 extensions malveillantes de type evil twin repérées sur Open VSX : un nom crédible, une description recopiée, et une charge utile en plus. La purge MV2 vient de créer plusieurs centaines de niches de ce type d’un seul coup.
Troisième effet : la perte de l’archive. Une extension retirée du Store emporte avec elle sa page publique. Pour les projets dont le dépôt était privé ou dont l’auteur a disparu, le dernier artefact publié n’existe plus nulle part de façon vérifiable. C’est une perte patrimoniale discrète mais réelle pour l’écosystème.
Arbre de décision — que faire de votre extension cette semaine
Notre avis d’expert n°3 — ce que cette purge dit des dépendances de plateforme
La leçon dépasse largement les extensions de navigateur. Un projet open source dont la distribution dépend entièrement d’une place de marché contrôlée par un tiers n’est pas maître de sa propre survie, quelle que soit la licence de son code. Nous appliquons désormais une règle simple à toutes nos dépendances de plateforme : si le canal de distribution disparaissait demain, combien de temps faudrait-il pour joindre nos utilisateurs ? Si la réponse dépasse quelques jours, le canal est un point de défaillance unique et doit être doublé — dépôt public, release taguée, et un moyen de contact qui ne passe pas par la plateforme. C’est exactement le raisonnement que nous appliquons aussi aux dépendances logicielles, détaillé dans notre méthode pour sécuriser les dépendances open source d’un projet Python.
Le plan de sortie en 5 points, à appliquer cette semaine
1. Constatez l’état réel. Ouvrez la page Web Store de chacune de vos extensions. Si elle ne répond plus, le canal est fermé et aucune action de votre part ne le rouvrira. Notez les chiffres d’installation dont vous vous souvenez : ils ne sont plus récupérables.
2. Archivez immédiatement. Créez une release GitHub taguée contenant le dernier artefact MV2 publié, avec son empreinte SHA-256 dans les notes de version. C’est désormais la seule copie de référence, et c’est aussi ce qui permettra à vos utilisateurs de distinguer votre code d’un clone malveillant.
3. Parlez à vos utilisateurs. Un encart en haut du README, une issue épinglée, et si votre extension est encore active sur des postes, un message dans son interface. Dites explicitement trois choses : l’extension ne sera plus mise à jour sur Chrome, elle reste fonctionnelle jusqu’à désinstallation, et voici la suite prévue. Le silence est ce qui pousse les utilisateurs vers les clones.
4. Lancez l’audit des trois signaux. Recherchez dans le dépôt les usages de webRequest bloquant, de code distant ou d’eval, et les globales du script de background. Le résultat vous donne la charge de migration en une heure de travail, sans avoir à ouvrir un chantier.
5. Décidez, et écrivez la décision. Migration MV3, bascule Firefox, distribution interne par politique d’entreprise, ou arrêt assumé du projet. Les quatre réponses sont légitimes. Ce qui ne l’est pas, pour un projet dont d’autres dépendent, c’est de laisser la question ouverte pendant six mois. Si votre extension servait un usage interne en entreprise, le déploiement par politique reste la voie la plus simple — et souvent la moins connue. Nous détaillons ce type d’arbitrage dans notre guide pour auditer le code livré par un prestataire, dont la grille s’applique très bien à la reprise d’une extension orpheline.
Enfin, si la disparition d’une extension vous prive d’une brique de sécurité côté navigateur, la bonne réponse n’est pas de la remplacer par le premier clone disponible. Nos confrères de WebGuard Agency traitent régulièrement des compromissions dont l’origine est une extension de remplacement installée dans l’urgence. Et si le sujet est plutôt celui de l’outillage interne à reconstruire, l’équipe de Plug-Tech publie des retours utiles sur l’automatisation des chaînes de build.
FAQ
Que s’est-il passé exactement le 31 août 2026 avec Manifest V2 ?
Google a exécuté la phase finale de sa feuille de route : la suppression définitive des extensions Manifest V2 encore présentes dans le Chrome Web Store. Elles ne peuvent plus être mises à jour par leurs auteurs ni réinstallées par les utilisateurs. Une extension installée avant Chrome 138 continue de fonctionner sur sa machine, mais sans aucun correctif. Il n’y a pas de retour arrière : désinstallation, changement de poste ou nouveau profil suffisent à la perdre définitivement.
Mon extension open source Manifest V2 est-elle définitivement morte ?
Sur le Chrome Web Store, le canal est fermé. Le code, lui, reste exploitable par trois voies : la migration vers Manifest V3, réaliste pour la majorité des extensions ; la distribution hors Store, en mode développeur ou par politique d’entreprise, viable en interne ; et Firefox, qui continue de supporter l’API webRequest bloquante et devient la cible naturelle des extensions qui ne peuvent pas migrer.
Quelle est la vraie difficulté technique de la migration vers Manifest V3 ?
Presque jamais le fichier manifest.json. Les trois points durs sont le passage aux service workers, qui peuvent être arrêtés à tout moment et perdent leur état en mémoire ; le remplacement de webRequest bloquant par declarativeNetRequest, déclaratif et soumis à des quotas de règles ; et l’interdiction du code distant et d’eval, qui casse les mises à jour de règles à chaud. Une extension de contenu simple migre en quelques heures ; un bloqueur avancé demande une réécriture de son moteur.
Que doit faire un mainteneur open source dans les prochains jours ?
Cinq actions : vérifier l’état de la page Store et récupérer ce qui peut l’être ; archiver le dernier artefact MV2 dans une release taguée avec son hash ; publier un avis explicite pour les utilisateurs afin qu’ils ne se rabattent pas sur un clone ; auditer le code à la recherche de webRequest bloquant, de code distant et de globales de background ; puis décider entre migration, bascule Firefox, distribution interne ou arrêt — et écrire cette décision publiquement.
Votre outillage dépend d’une plateforme que vous ne contrôlez pas ?
Nous cartographions vos dépendances de plateforme et vos points de défaillance uniques, puis nous chiffrons les alternatives. Discutons-en.
Demander un audit de dépendances