Publier une extension pour la première fois

Cette procédure couvre la mise en ligne initiale d'une extension et son déploiement par stratégie de groupe. Pour les versions suivantes, voir Chrome, Edge, Brave ou Firefox.

Trois décisions difficiles à revenir en arrière

Avant de créer quoi que ce soit :

Décision	Pourquoi elle est figée
L'identifiant d'URL (slug)	Il apparaît dans les URL poussées aux postes par la GPO. Le changer après déploiement rend les mises à jour injoignables.
La clé de signature (Chromium)	Elle détermine l'identifiant de l'extension. En changer revient à publier une extension différente.
L'identifiant gecko.id (Firefox)	Même conséquence : Firefox y voit une autre extension.

Choisir un slug court, en minuscules, sans accent ni espace : alerteia, vpn-interne, filtrage-web.

Étape 1 — Créer la fiche

Extensions → Nouvelle extension.

• Nom affiché : libre, modifiable à tout moment.
• Identifiant d'URL : voir ci-dessus.
• Navigateur cible : Chromium ou Firefox. Une extension disponible sur les deux familles demande deux fiches distinctes, avec des paquets et des identifiants différents.
• Version minimale du navigateur : facultatif, laisser vide en cas de doute.

Étape 2 (Chromium) — La clé de signature

Sur la fiche, section Clé de signature, deux cas :

L'extension n'a jamais été déployée → Générer une clé. Une clé RSA 2048 est créée et l'identifiant d'extension est fixé à cet instant.

L'extension est déjà déployée sur le parc, packagée jusqu'ici à la main → Importer une clé existante, en fournissant le .pem utilisé auparavant (celui produit par chrome --pack-extension). L'identifiant est ainsi préservé et les postes existants recevront les mises à jour normalement.

Télécharger la clé immédiatement et la déposer dans le coffre-fort de l'équipe. Sans elle, plus aucune mise à jour ne pourra être signée sous cet identifiant : il faudrait redéployer une nouvelle extension sur tous les postes.

Si vous packagez déjà vos .crx par ailleurs, cette étape est inutile : déposez directement le .crx signé, le dépôt en lit l'identifiant.

Étape 2 (Firefox) — La signature Mozilla

Firefox Release et ESR refusent tout .xpi non signé par Mozilla, y compris en interne.

Avant la première soumission, le manifest.json doit déjà contenir :

"browser_specific_settings": {
  "gecko": {
    "id": "extension@exemple.fr",
    "update_url": "https://extensions.kernelpanics.fr/e/<slug>/updates.json"
  }
}

L'update_url doit y figurer dès la première version déployée : c'est le manifeste de l'extension installée qui déclenche les recherches de mise à jour. L'oublier condamne à redéployer l'extension une seconde fois pour amorcer le mécanisme.

Soumettre ensuite sur addons.mozilla.org en canal unlisted — l'extension reste privée et n'apparaît pas au catalogue public — puis télécharger le .xpi signé.

Étape 3 — Déposer le premier paquet

Sur la fiche, Publier une version :

• Chromium : un .zip du contenu du dossier de l'extension, manifest.json à la racine de l'archive — pas le dossier lui-même. Le dépôt le signe et produit le .crx. Un .crx déjà signé est accepté tel quel.
• Firefox : le .xpi signé récupéré depuis AMO. Un avertissement apparaît si le fichier déposé n'est pas signé.

Laisser Épingler décoché : le numéro de version le plus élevé est servi automatiquement.

Étape 4 — Vérifier avant de toucher aux GPO

curl -s https://extensions.kernelpanics.fr/e/<slug>/updates.xml     # Chromium
curl -s https://extensions.kernelpanics.fr/e/<slug>/updates.json    # Firefox
curl -sI https://extensions.kernelpanics.fr/dl/<slug>/latest.crx

Le manifeste doit annoncer la bonne version et le bon identifiant, et le téléchargement répondre 200. Tant que ce n'est pas le cas, inutile de déployer la stratégie.

Étape 5 — Déployer la stratégie

La fiche publique de l'extension (/e/<slug>) affiche les blocs prêts à coller, déjà remplis avec le bon identifiant et la bonne URL.

Chrome, Edge, Brave — par modèles ADMX (recommandé) : Configuration ordinateur → Modèles d'administration → Google Chrome (ou Microsoft Edge, ou Brave) → Extensions → Configurer la liste des applications et extensions installées de force, puis ajouter une ligne :

<identifiant>;https://extensions.kernelpanics.fr/e/<slug>/updates.xml

Chrome, Edge, Brave — par le registre : Configuration ordinateur → Préférences → Paramètres Windows → Registre, en reprenant le .reg proposé. Veiller à ce que les index numériques soient uniques si d'autres extensions sont déjà forcées.

Firefox : modèles ADMX Mozilla (github.com/mozilla/policy-templates), paramètre Extensions → Extension Management, en collant le JSON ExtensionSettings proposé sur la fiche. Sans GPO, déposer le policies.json dans <dossier Firefox>\distribution\.

Étape 6 — Valider sur un poste pilote

1. gpupdate /force sur le poste.
2. chrome://policy (ou edge://, brave://, about:policies pour Firefox) : la stratégie doit apparaître avec la bonne URL. Le bouton Recharger les stratégies évite d'attendre.
3. chrome://extensions : l'extension est présente, activée, et ne peut pas être désinstallée par l'utilisateur — c'est la signature d'une installation forcée réussie.

Si l'extension n'apparaît pas, le tableau de diagnostic des documents de mise à jour couvre les causes habituelles.

Check-list

• slug définitif, court et sans accent
• Clé de signature téléchargée et mise au coffre (Chromium)
• gecko.id et update_url présents dans le manifeste (Firefox)
• Manifeste de mise à jour vérifié en HTTPS
• Téléchargement du paquet vérifié
• Stratégie déployée avec un index libre
• Installation confirmée sur un poste pilote