Extension Chrome maison : le manifest.json qui fait tout tenir ensemble
Créer une extension Chrome ne demande ni framework spécialisé ni compte développeur payant pour commencer. Un dossier, trois ou quatre fichiers, et un navigateur en mode développeur suffisent à faire tourner un premier prototype en quelques minutes. Cet article détaille chaque brique du projet, du fichier manifeste aux différents contextes d'exécution du JavaScript, pour que vous puissiez construire une extension fonctionnelle et comprendre pourquoi elle fonctionne, pas seulement copier un exemple.
Ce qu'il faut savoir avant d'ouvrir son éditeur
Une extension Chrome est avant tout un petit site web empaqueté différemment. Elle repose sur les mêmes technologies qu'une page classique : HTML pour la structure, CSS pour l'apparence, JavaScript pour le comportement. La différence tient à un fichier supplémentaire, le manifeste, et à un ensemble d'API spécifiques (préfixées chrome.* dans le code) qui donnent accès à des fonctionnalités du navigateur normalement hors de portée d'une page web : onglets ouverts, notifications système, stockage persistant, etc.
Quiz : Fondamentaux des extensions Chrome
Aucun compilateur, aucun bundler n'est obligatoire pour démarrer. Vous pouvez écrire vos fichiers tels quels et les charger directement dans Chrome. Si vous savez déjà écrire une page HTML avec un peu de JavaScript, vous savez déjà 80 % de ce qu'il faut pour une première extension.
Le matériel minimal
Il faut un navigateur Chrome (ou tout navigateur basé sur Chromium, comme Edge ou Brave, qui partagent le même système d'extensions), un éditeur de texte, et un dossier vide qui accueillera les fichiers du projet. Aucun outil de build n'est requis pour une extension simple : Chrome sait lire directement du HTML, du CSS et du JavaScript bruts.
Activer le mode développeur
Avant de pouvoir tester quoi que ce soit, il faut basculer Chrome dans un mode qui autorise le chargement de code non vérifié par le Chrome Web Store. Rendez-vous sur chrome://extensions/ et activez l'interrupteur Mode développeur en haut à droite de la page. Trois nouveaux boutons apparaissent alors : Charger l'extension non empaquetée, Empaqueter l'extension, et Mettre à jour. C'est le premier de ces trois boutons qui va vous servir tout au long du développement.
Construire la structure du projet
Créez un dossier, appelons-le mon-extension, et placez-y les fichiers suivants : un manifest.json à la racine (c'est une obligation, Chrome le cherche systématiquement à cet endroit), un fichier HTML pour l'interface éventuelle, un ou plusieurs fichiers JavaScript, et éventuellement une feuille de style. Ajoutez aussi une icône, idéalement au format 128 × 128 pixels, qui identifiera votre extension dans le navigateur et dans le Chrome Web Store si vous allez jusqu'à la publication.
Cette arborescence simple suffit pour la grande majorité des projets débutants :
- manifest.json — la carte d'identité de l'extension
- popup.html et popup.js — l'interface qui s'affiche au clic sur l'icône
- background.js — la logique qui tourne en tâche de fond
- content.js — le script qui vient s'exécuter dans les pages visitées
- icon.png — l'icône de l'extension
Il n'est pas nécessaire d'avoir les cinq fichiers dès le départ. Une extension minimale peut se limiter au manifeste et à une pop-up.
Configurer le fichier manifest.json
Le manifeste est le fichier central : c'est lui que Chrome lit en premier pour comprendre ce que fait l'extension, quelles ressources elle embarque et à quoi elle a le droit d'accéder. Il déclare le nom, la description, la version, la version du format de manifeste lui-même, les icônes, la page d'action et les permissions demandées. Un exemple typique ressemble à ceci :
{ "manifest_version": 3, "name": "Mon Extension", "description": "Une extension de démonstration", "version": "1.0", "action": { "default_popup": "popup.html", "default_icon": "icon.png" }, "permissions": ["storage"] }Le champ manifest_version mérite une attention particulière. La version 3 est aujourd'hui la référence : elle remplace le script d'arrière-plan persistant par un service worker, qui ne reste pas actif en permanence mais se réveille à la demande. Ce changement impacte directement la façon d'écrire la logique de fond de votre extension, comme on le verra plus loin. Le champ action (qui a remplacé l'ancien browser_action) définit ce qui se passe quand l'utilisateur clique sur l'icône de l'extension dans la barre d'outils.
Choisir ses permissions avec discernement
Les permissions du manifeste se répartissent en deux grandes familles : les permissions d'API, qui donnent accès à des fonctionnalités du navigateur comme tabs ou notifications, et les motifs d'URL (match patterns), qui déterminent sur quelles pages web l'extension est autorisée à agir. Chaque permission ajoutée élargit la surface d'accès de votre extension, et donc la méfiance légitime de l'utilisateur au moment de l'installation. Le principe à retenir est simple : ne demandez que ce que la fonctionnalité utilise réellement. Une extension qui se contente de stocker une préférence locale n'a besoin que de storage, pas d'un accès large aux onglets ou à l'historique.
Créer une pop-up et lui donner vie en JavaScript
La pop-up est la fenêtre qui s'ouvre quand l'utilisateur clique sur l'icône de l'extension dans la barre d'outils. Techniquement, c'est une page HTML tout à fait ordinaire, avec ses propres balises, sa propre feuille de style et son propre script. Voici un popup.html minimal :
<!DOCTYPE html> <html> <head> <link rel="stylesheet" href="popup.css"> </head> <body> <button id="action">Cliquez ici</button> <script src="popup.js"></script> </body> </html>Le script popup.js se comporte comme n'importe quel script de page web : il peut écouter des clics, manipuler le DOM de la pop-up, ou appeler des API Chrome si les permissions nécessaires ont été déclarées. Sa particularité est sa durée de vie : dès que l'utilisateur ferme la pop-up, le script s'arrête et perd tout son état en mémoire. C'est une bonne interface pour des actions ponctuelles, mais un mauvais endroit pour héberger une logique qui doit persister.
Distinguer pop-up, service worker et content script
C'est probablement le point qui perd le plus de débutants, alors autant le poser clairement avec un tableau de référence :
| Contexte | Quand il s'exécute | Accès au DOM de la page | Accès aux API chrome.* |
|---|---|---|---|
| Pop-up (popup.js) | Tant que la pop-up est ouverte | Non, uniquement le DOM de la pop-up elle-même | Oui |
| Service worker (background.js) | À la demande, réveillé par des événements | Non | Oui |
| Content script (content.js) | À l'injection dans une page correspondant aux motifs déclarés | Oui, dans un contexte isolé | Très limité |
Le service worker déclaré dans le manifeste sous "background": {"service_worker": "background.js"} remplace l'ancien script d'arrière-plan persistant. Il permet de garder une logique active indépendamment de l'ouverture de la pop-up, par exemple pour réagir à un changement d'onglet ou déclencher une notification à intervalle régulier. Le content script, lui, s'exécute directement dans le contexte d'une page web visitée et peut donc lire ou modifier son DOM, mais dans un contexte isolé, sans accès direct aux variables JavaScript de la page ni à la plupart des API chrome.*. Pour combiner les deux mondes, un content script doit passer par un système de messages afin de communiquer avec le service worker.
Une image aide à retenir la distinction. La pop-up est un cadran qu'on ne consulte qu'en s'approchant : elle affiche une information ponctuelle, puis disparaît. Le service worker tourne en coulisses, silencieux la plupart du temps, mais réveillé à intervalles précis pour accomplir une tâche précise. Le content script, lui, agit directement sur la page visitée tout en restant séparé du reste de l'extension. Garder cette distinction en tête évite l'erreur classique qui consiste à vouloir tout faire depuis un seul fichier : chaque contexte a une fonction précise, et le forcer à en assumer une autre casse l'équilibre de l'ensemble.
Interagir avec les pages web via un content script
Pour qu'un content script s'exécute automatiquement sur certaines pages, il faut le déclarer dans le manifeste avec les motifs d'URL correspondants :
"content_scripts": [ { "matches": ["https://*.exemple.com/*"], "js": ["content.js"] } ]Une fois injecté, ce script peut lire le contenu de la page, modifier des éléments, ajouter des styles ou écouter des événements utilisateur, exactement comme le ferait un script embarqué directement dans la page. C'est le mécanisme à utiliser pour toute extension qui doit surligner du texte, extraire des données affichées, ou ajouter un bouton flottant sur un site tiers. Pour renvoyer une information vers le service worker, par exemple pour déclencher une notification ou sauvegarder une donnée extraite, le content script utilise l'API de messages, qui fait le pont entre le contexte isolé de la page et le reste de l'extension.
Ajouter des notifications
Une fois la permission notifications déclarée dans le manifeste, l'extension peut afficher des notifications système depuis son service worker, typiquement en réponse à un événement détecté par un content script ou à une tâche planifiée. C'est une fonctionnalité simple à mettre en œuvre qui donne à l'extension une présence perceptible pour l'utilisateur, au-delà de la seule pop-up.
Charger, tester et corriger son extension
Une fois les fichiers en place, retournez sur chrome://extensions/, cliquez sur Charger l'extension non empaquetée et sélectionnez le dossier du projet. Chrome analyse le manifeste, affiche une carte pour votre extension et l'ajoute à la barre d'outils. Toute modification apportée aux fichiers nécessite ensuite un clic sur le bouton de rechargement de la carte d'extension pour être prise en compte : Chrome ne surveille pas les fichiers en continu.
Si l'extension ne se charge pas ou se comporte mal, la carte d'extension affiche un lien "Erreurs" qui liste les problèmes de syntaxe JSON ou de référence de fichier. Pour déboguer le script de la pop-up, faites un clic droit dessus puis "Inspecter" pour ouvrir les outils de développement dédiés à ce contexte. Pour le service worker, un lien direct apparaît sur la carte de l'extension dans chrome://extensions/ et ouvre une console spécifique à ce contexte. Un validateur JSON en ligne permet par ailleurs de repérer rapidement une virgule ou une accolade mal placée dans le manifeste, une source d'erreur fréquente chez les débutants.
Publier et gérer l'extension
Une fois le fonctionnement validé en local, l'extension peut être compressée en fichier ZIP puis soumise via le Chrome Web Store Developer Dashboard. Quatre niveaux de visibilité sont proposés au moment de la publication : publique, pour une diffusion ouverte à tous ; non répertoriée, accessible uniquement via un lien direct sans apparaître dans les résultats de recherche du store ; privée, réservée à une liste d'utilisateurs ou de comptes définis ; et par groupe, pensée pour une diffusion contrôlée au sein d'une organisation.
Dans un contexte d'entreprise utilisant Chrome Enterprise, les administrateurs disposent en plus d'outils pour forcer l'installation de certaines extensions, en bloquer d'autres, ou appliquer des règles d'utilisation à l'ensemble d'un parc de postes. Cette dimension dépasse le cadre du développement individuel, mais elle explique pourquoi certaines organisations imposent des contraintes supplémentaires sur les permissions ou les sources autorisées.
Avant de soumettre une extension, il vaut la peine de relire les permissions déclarées dans le manifeste et de vérifier qu'aucune n'est restée présente par habitude alors qu'elle n'est plus utilisée par le code final. Une extension qui demande le strict nécessaire inspire davantage confiance, aussi bien à l'utilisateur final qu'au processus de validation du Chrome Web Store.