Publier une extension Chrome en 2026 : ce qui a changé

Pourquoi en 2026 c'est encore intéressant

Le Chrome Web Store reste le canal le plus rentable pour distribuer un outil de productivité. Pas de App Store à passer, pas de backend obligatoire, et plusieurs centaines de millions d'utilisateurs accessibles. La friction d'installation est faible, et la mise à jour est automatique.

Les contre-parties : Manifest V3 a nettoyé l'API, donc plusieurs choses qui marchaient en V2 ne marchent plus. Et la revue manuelle de Google s'est durcie sur les permissions.

La structure que j'utilise maintenant

Pour une extension qui a besoin d'un service worker, d'un popup et d'un content script :

src/
  manifest.ts        // généré au build
  background/
    index.ts         // service worker
  popup/
    index.html
    main.tsx
  content/
    inject.ts

Je génère le manifest.json depuis du TypeScript pour avoir l'autocomplétion sur les permissions et un hash de version qui s'incrémente. Le bundler (Vite + crxjs) sort le ZIP final.

Le piège du service worker

En V3, le background n'est plus persistant. Le service worker peut être tué après quelques minutes d'inactivité. Concrètement :

• N'utilisez pas setInterval pour des tâches récurrentes : le worker peut être mort. Utilisez chrome.alarms.
• Stockez tout l'état dans chrome.storage ou IndexedDB. Les variables en mémoire disparaissent.
• Préférez les listeners (onMessage, onInstalled) au polling.

La soumission

1. Compte développeur : 5 USD une fois, par carte
2. ZIP du dist/, screenshots 1280×800 (au moins une), une icône 128×128
3. Description courte (132 caractères max), description longue (HTML autorisé)
4. Politique de confidentialité obligatoire dès qu'on touche aux données utilisateur
5. Justification claire de chaque permission

Délai de revue actuel : 2 à 5 jours pour une première soumission, 12 à 24h pour les mises à jour mineures.

Les refus que j'ai vus

• "Single purpose" violé : votre extension fait trop de choses. Découpez-la.
• Permissions trop larges : <all_urls> n'est plus accepté sans justification très explicite.
• Politique de confidentialité absente alors que l'extension envoie des données.
• Code obfusqué : interdit. Le minify est OK, l'obfuscation non.

Conclusion

L'écosystème est mature et stable. Si vous respectez le single purpose, justifiez vos permissions et fournissez une politique de confidentialité claire, la soumission passe sans douleur.