Cette extension Chrome installée depuis des années devient impossible à réinstaller le 31 août : vérifiez son Manifest maintenant

Une extension Chrome peut encore apparaître dans votre liste alors qu’elle est déjà condamnée : si elle utilise Manifest V2, Chrome ne sait plus l’exécuter dans ses versions récentes et le Chrome Web Store supprimera les dernières fiches restantes le 31 août 2026. Après cette date, vous ne pourrez plus compter sur le Store pour la retrouver, la mettre à jour ou la réinstaller.

Le piège est particulièrement dangereux pour une extension interne créée il y a des années, installée sur quelques ordinateurs puis oubliée. Si son projet source n’existe que sur le PC de la personne qui l’a développée, le départ de ce salarié ou une panne de disque peut faire disparaître la seule base à partir de laquelle construire une version Manifest V3.

Le 31 août ne marque pas le début de la panne

La chronologie officielle de Google pour la fin de Manifest V2 distingue deux événements que plusieurs articles mélangent.

« Rester installée » ne signifie donc pas « continuer à fonctionner ». Sur Chrome 139 et les versions suivantes, conserver le dossier ou l’entrée grisée dans chrome://extensions ne restaure pas le moteur Manifest V2. La date du 31 août ferme surtout le dernier canal officiel de distribution et de récupération.

Ce calendrier transforme notre ancienne sélection des 11 meilleures extensions Chrome d’août 2022 en liste d’audit plutôt qu’en liste d’installation. Une recommandation vieille de quatre ans doit désormais être vérifiée dans le Store, dans son manifeste et sur le site de son éditeur avant toute réinstallation.

Comment savoir si une extension utilise Manifest V2

Le numéro se trouve dans un fichier JSON placé à la racine de chaque extension. La ligne recherchée est sans ambiguïté :

{
  "name": "Mon extension",
  "version": "1.4.2",
  "manifest_version": 2
}

Si la valeur est 3, l’extension utilise Manifest V3. Si vous ne voyez qu’une fiche commerciale promettant une compatibilité avec « le nouveau Chrome », ce n’est pas encore une preuve : contrôlez le paquet réellement installé.

Méthode manuelle, sans installer un autre outil

1. Saisissez chrome://extensions dans la barre d’adresse.
2. Activez Mode développeur en haut de la page.
3. Notez le nom, l’identifiant composé de 32 lettres et la version de l’extension.
4. Ouvrez chrome://version et copiez la valeur Chemin d’accès au profil. Cette méthode évite de deviner si vous utilisez Default, Profile 1 ou un autre profil.
5. Dans l’explorateur de fichiers, ouvrez ce chemin, puis le dossier Extensions, l’identifiant noté et le sous-dossier correspondant à la version.
6. Ouvrez manifest.json dans un éditeur de texte et cherchez manifest_version.

Sur Windows, le profil se trouve généralement sous %LOCALAPPDATA%\Google\Chrome\User Data\. Sur macOS, il est habituellement sous ~/Library/Application Support/Google/Chrome/, et sous Linux sous ~/.config/google-chrome/. Utilisez néanmoins le chemin affiché par chrome://version, car les éditions de Chrome et les profils multiples changent l’emplacement réel.

Évitez d’installer une extension inconnue uniquement pour examiner les autres. Vous lui accorderiez potentiellement l’accès à votre liste d’extensions ou à votre navigation alors que le fichier recherché existe déjà sur le disque.

Scanner les profils Chrome avec PowerShell

Sur Windows, ce script en lecture seule parcourt les manifestes stockés dans les profils Chrome et affiche uniquement ceux qui déclarent la version 2. Il ne modifie ni ne désinstalle rien.

$racineChrome = Join-Path $env:LOCALAPPDATA "Google\Chrome\User Data"

Get-ChildItem -LiteralPath $racineChrome -Filter manifest.json -Recurse `
  -ErrorAction SilentlyContinue |
  Where-Object { $_.FullName -match '\\Extensions\\[a-p]{32}\\[^\\]+\\manifest\.json$' } |
  ForEach-Object {
    try {
      $manifeste = Get-Content -LiteralPath $_.FullName -Raw | ConvertFrom-Json
      if ($manifeste.manifest_version -eq 2) {
        [PSCustomObject]@{
          Nom = $manifeste.name
          Version = $manifeste.version
          Identifiant = $_.Directory.Parent.Name
          Fichier = $_.FullName
        }
      }
    } catch {
      Write-Warning "Manifeste illisible : $($_.FullName)"
    }
  } | Sort-Object Identifiant, Version -Unique

Un nom comme __MSG_appName__ n’est pas une erreur : certaines extensions stockent leur libellé dans un dossier de traduction. L’identifiant permet de retrouver la fiche correspondante dans chrome://extensions. Le même identifiant peut apparaître plusieurs fois si Chrome conserve plusieurs versions du paquet.

Reconnaître une extension abandonnée avant de lui chercher un remplaçant

Manifest V2 est un signal technique, mais une extension Manifest V3 peut elle aussi être abandonnée. Pour chaque outil indispensable, consignez ces éléments dans un tableau partagé :

• nom, identifiant, version et valeur de manifest_version ;
• URL actuelle du Chrome Web Store et nom exact de l’éditeur ;
• date de dernière mise à jour et site d’assistance encore accessible ;
• fonction réellement utilisée dans l’entreprise ;
• permissions accordées : tous les sites, presse-papiers, téléchargements, historique ou données de connexion ;
• données locales à exporter et méthode de restauration ;
• propriétaire interne capable de répondre en cas de panne.

Une fiche supprimée du Store, un domaine d’assistance expiré, aucun dépôt ou contact, plusieurs années sans mise à jour et l’absence de version V3 constituent un faisceau d’alertes. Ne remplacez pas automatiquement l’extension par le premier clone portant un nom proche : vérifiez l’éditeur, la politique de confidentialité, les permissions et l’existence d’un support.

La désinstallation des extensions inutiles peut aussi alléger le navigateur. Notre guide pour réduire l’utilisation de la RAM par Chrome recommande déjà de supprimer les anciennes extensions. Faites toutefois l’inventaire et l’export avant le ménage : une suppression irréversible n’est pas un audit.

Choisir un équivalent Manifest V3 sans perdre ses données

1. Décrivez la fonction, pas le nom du produit. « Enregistrer une page dans notre base documentaire avec ses étiquettes » est un meilleur critère que « trouver un clone de l’ancienne extension ».
2. Exportez d’abord. Sauvegardez les listes, règles, modèles, raccourcis et préférences dans un format lisible. Vérifiez qu’un import ou une restauration est réellement possible.
3. Installez dans un profil de test. Ne remplacez pas l’outil de toute l’équipe en une fois. Utilisez des données factices et accordez seulement les permissions nécessaires.
4. Vérifiez le manifeste installé. Confirmez "manifest_version": 3 dans le paquet, même si la fiche du Store mentionne MV3.
5. Testez le travail complet. Redémarrez Chrome, déconnectez puis reconnectez le compte, essayez le mode hors ligne et contrôlez l’export.
6. Révoquez l’ancienne extension. Quand le remplacement est validé, retirez l’ancienne des règles d’entreprise, des procédures et des postes encore concernés.

Une extension qui lit toutes les pages visitées mérite une revue plus sévère qu’un outil limité à un domaine. Les extensions peuvent également devenir un vecteur d’espionnage : notre article sur une campagne ayant utilisé une extension de navigateur pour viser des messageries rappelle pourquoi le nom et l’icône ne suffisent jamais à établir la confiance.

Votre extension interne n’existe que sur le PC du développeur : que sauvegarder ?

Copier le dossier installé par Chrome vaut mieux que ne rien conserver, mais ce dossier n’est pas forcément le projet source. Il peut contenir du JavaScript minifié, des fichiers générés et aucune configuration de compilation. Il manque souvent les tests, les maquettes, les fichiers de verrouillage des dépendances et les instructions de publication.

Récupérez au minimum :

• le dépôt complet avec son historique Git, ou le dossier de travail le plus récent ;
• manifest.json, scripts, pages HTML, styles, icônes et fichiers de traduction ;
• package.json et le fichier de verrouillage correspondant ;
• les commandes de construction, de test et de création du paquet ;
• la liste des domaines, API, applications natives et règles Chrome nécessaires ;
• une procédure d’installation et de retour arrière ;
• un export des données de test sans information personnelle.

Placez le code dans un dépôt privé accessible à au moins deux responsables. Retirez les clés, jetons et mots de passe avant le premier commit. Une éventuelle clé privée servant à préserver l’identité d’une extension distribuée hors Store doit être conservée dans un gestionnaire de secrets, jamais dans Git ou dans un dossier partagé. Documentez son propriétaire et sa procédure de récupération sans recopier sa valeur.

Cette sauvegarde empêche de perdre le projet ; elle ne rend pas Manifest V2 compatible avec Chrome 139 et les versions suivantes. Charger le dossier en mode développeur n’est pas une stratégie durable lorsque le navigateur a supprimé le support de la plateforme elle-même.

Les six changements qui cassent le plus souvent une migration MV3

Passer la ligne manifest_version de 2 à 3 ne suffit pas. La présentation officielle de Manifest V3 met en avant trois transformations majeures : les pages d’arrière-plan deviennent des service workers, le code exécuté à distance est interdit et la modification bloquante des requêtes réseau change de modèle.

1. La page d’arrière-plan devient un service worker

Le champ background.scripts est remplacé par background.service_worker. Le service worker démarre lorsqu’un événement l’exige puis peut s’arrêter. Les variables globales ne constituent donc plus un stockage fiable.

2. Les temporisations et l’état disparaissent au redémarrage

Un setTimeout() ou setInterval() peut être interrompu lorsque le service worker s’arrête. Google recommande l’API chrome.alarms pour les tâches différées et chrome.storage pour l’état persistant.

3. Le DOM et window ne sont pas disponibles

Un service worker ne peut pas manipuler directement le DOM ni utiliser window.localStorage. Les traitements concernés doivent rejoindre une page visible, un script de contenu ou, pour certains usages, un document hors écran. La documentation de migration vers un service worker recommande aussi d’enregistrer les écouteurs d’événements de manière synchrone au niveau principal du fichier.

4. webRequestBlocking n’a pas de remplacement ligne pour ligne

Pour la plupart des extensions, les interceptions qui bloquent ou modifient les requêtes doivent être réécrites sous forme de règles declarativeNetRequest. Google précise que webRequestBlocking reste disponible en MV3 pour certaines extensions installées par politique, mais il faut documenter et tester ce cas d’entreprise au lieu de supposer une compatibilité générale.

5. Le code distant doit entrer dans le paquet

Manifest V3 interdit de télécharger du JavaScript ou du WebAssembly pour l’exécuter depuis un serveur externe. Les bibliothèques exécutables doivent être incluses dans l’extension et soumises à l’examen du Store. Une API distante peut toujours renvoyer des données ; elle ne doit pas devenir un chargeur de code non contrôlé.

6. Les permissions changent de place et de portée

Les domaines précédemment placés dans permissions migrent généralement vers host_permissions. browser_action et page_action deviennent action, tandis que plusieurs injections utilisent désormais chrome.scripting. Profitez de la migration pour retirer les accès inutiles au lieu de recopier l’ancien manifeste.

Plan de migration en dix jours pour une extension métier

1. Jour 1 : inventaire. Identifiez le propriétaire, les utilisateurs, les données, les permissions, les API et la méthode de distribution.
2. Jour 2 : sauvegarde. Clonez le dépôt, étiquetez la dernière version connue et vérifiez qu’un second ordinateur peut construire le paquet.
3. Jour 3 : tests de référence. Notez les parcours qui fonctionnaient sous l’ancien environnement sans utiliser de données de production.
4. Jours 4 et 5 : manifeste et service worker. Migrez les champs, l’état, les écouteurs et les tâches différées.
5. Jour 6 : réseau et sécurité. Remplacez les interceptions bloquantes, intégrez le code distant et réduisez les permissions.
6. Jour 7 : test de cycle de vie. Redémarrez Chrome, suspendez la machine, mettez l’extension à jour et simulez l’arrêt du service worker.
7. Jour 8 : pilote. Déployez auprès de quelques utilisateurs dans un groupe distinct et prévoyez un retour arrière.
8. Jour 9 : documentation. Écrivez l’installation, la supervision, le support, la rotation des secrets et la procédure de publication.
9. Jour 10 : diffusion. Soumettez la version MV3 ou mettez à jour la règle d’entreprise, puis surveillez erreurs et permissions refusées.

Ne planifiez pas la soumission au Store le 30 août. Une revue peut révéler du code distant, une permission trop large ou un comportement qui ne respecte plus les règles de publication. La date limite concerne les fiches V2 restantes ; elle ne garantit aucun délai d’approbation pour votre nouvelle version.

La décision à prendre pour chaque extension avant le 31 août

Le 31 août 2026 ne fera peut-être apparaître aucune fenêtre spectaculaire sur votre écran. C’est précisément le problème : la fiche disparaîtra du Store alors que l’extension pourra encore rester visible dans un profil ancien, donnant l’illusion que le projet est conservé. Le bon livrable n’est pas une copie figée d’un dossier MV2, mais un inventaire, un export des données, un dépôt source récupérable et une version V3 testée.

Article vérifié le 16 août 2026 à partir du calendrier et des guides de migration officiels de Chrome for Developers. Les versions, politiques d’entreprise et règles du Chrome Web Store évoluent : contrôlez la documentation applicable à votre canal Chrome et à votre mode de distribution avant le déploiement.