> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# Construire un SaaS avec une extension Chrome (MV3) partageant auth web & API

La plupart des équipes construisent un second backend pour leur extension navigateur. Voici comment câbler un compagnon Manifest V3 à votre SaaS existant via les clés API workspace — sans auth dupliquée ni seconde base.

_Publié 2026-11-07._
_Mis à jour le 2026-11-07._

> **Comment construire une extension Chrome qui partage le backend de votre SaaS ?**
> En ne construisant pas de second backend. Une extension MV3 ne peut pas compter sur les cookies HttpOnly : on s'authentifie donc avec des clés API workspace. L'extension appelle l'API REST versionnée de l'app (/api/v1) avec une clé scopée liée à exactement un workspace, réutilisant le même modèle d'auth, le même scoping de tenant et la même base Postgres que l'app web. Le scaffold MV3 de supastack — popup, page d'options, worker d'arrière-plan, manifeste à moindres privilèges — est câblé exactement ainsi.

## Le piège : construire un second backend sans s'en rendre compte

Le scénario classique : votre SaaS a besoin d'une extension compagnon pour capturer des pages, clipper du contenu ou annoter le web. Six mois plus tard, vous maintenez deux systèmes d'auth (cookies pour le web, quelque chose d'artisanal pour l'extension), une API parallèle que l'extension peut réellement appeler, et une couche de synchro qui aligne deux magasins de données censés n'en faire qu'un.

Rien de tout cela n'est nécessaire. L'extension est juste un client de plus de votre produit existant — elle a besoin d'une credential qu'elle peut conserver et d'une API conçue pour l'accès programmatique. L'erreur, c'est d'aller chercher un nouveau backend au lieu d'utiliser les clés API workspace et la surface REST versionnée qu'un SaaS sérieux possède déjà.


## Ce que Manifest V3 autorise réellement

MV3 a remplacé les background pages par des service workers à durée de vie courte et pousse les extensions vers le moindre privilège. En pratique : pas d'état en mémoire persistant, pas de grattage de cookies pour réutiliser des sessions (les cookies HttpOnly sont de toute façon inaccessibles), et chaque permission d'hôte est une question posée par la revue du web store.

La réponse propre est ce que la plateforme donne déjà : une credential scopée dans `chrome.storage.local` et des appels HTTPS vers l'origine de votre app — demandés en permissions d'hôte optionnelles au moment du setup, pas à l'installation.


## Le scaffold MV3 de supastack : ce qui est déjà câblé

`apps/extension` de supastack est un compagnon Manifest V3 volontairement petit et sans framework — « enregistrer la page dans le workspace » — qui montre tout le pattern de bout en bout. Il enregistre le titre, l'URL et le texte sélectionné de l'onglet actif comme entrée de contenu workspace via l'API REST versionnée `POST /api/v1/content-entries`.

L'auth utilise une clé API workspace (`sk_…`) créée sous Settings → Developers : la clé est liée à exactement un workspace, donc la liaison est elle-même la sélection du workspace — elle ne peut écrire nulle part ailleurs. La page d'options persiste l'URL de l'app et la clé dans `chrome.storage.local`, ne demande l'accès que pour cette origine et vérifie la connexion via `GET /api/v1/workspaces/current`.

```
apps/extension/
  manifest.json        MV3: service worker, least-privilege permissions
  src/
    background.js      context-menu save + badge feedback
    popup.html/.js     capture UI — title, URL, selection, note
    options.html/.js   app URL + workspace API key setup
    lib/
      api.mjs          versioned /api/v1 client (key auth)
      capture.mjs      active-tab + selection capture
      config.mjs       chrome.storage.local persistence
```


## Moindre privilège par défaut

Le scaffold n'embarque que le jeu minimal de permissions requis — important pour la revue du web store comme pour la confiance des utilisateurs :

- Pas de `tabs`, pas de `<all_urls>`, pas de cookies/webRequest/declarativeNetRequest — un scaffold qui déclare honnêtement ce dont il n'a pas besoin.

| Autorisation | Pourquoi |
|---|---|
| activeTab | Lire titre/URL de la page courante uniquement à l'invocation |
| scripting | Lire le texte sélectionné dans l'onglet invoqué |
| contextMenus | Enregistrer l'entrée de menu « enregistrer » au clic droit |
| storage | Persister URL de l'app, clé API et workspace en cache |
| optional_host_permissions | Origine de l'app demandée au setup — zéro accès site à l'installation |


## Du scaffold au compagnon de votre produit

Rebrander consiste à renommer le `manifest.json` ; l'extension est la partie intéressante — et reste dans le même pattern : de nouveaux types de capture appellent de nouveaux endpoints `/api/v1` avec la même clé, et le `@supastack/api-sdk` typé généré depuis le document OpenAPI de l'app garantit des formes de requêtes exactes.

Comme l'extension lit et écrit via la même API à scoping de tenant que tout autre client, les pages enregistrées tombent dans les mêmes lignes Postgres que le dashboard web liste — une base, un modèle d'auth, le scoping `workspaceId` appliqué à un seul endroit. Pas de second backend, pas de synchro, pas de dérive. Comparez les paliers sur la [page tarifaire](https://supastack.dev/#pricing).

|  | Approche second backend DIY | Scaffold MV3 supastack |
|---|---|---|
| Auth | Système de tokens artisanal à côté des cookies | Clés API workspace — même modèle d'auth que le web |
| API | Nouveaux endpoints inventés pour l'extension | /api/v1 versionnée + SDK typé OpenAPI |
| Données | Second store + logique de synchro | Mêmes lignes Postgres, scopées workspace |
| Autorisations | Accès large par commodité | Manifeste moindres privilèges, review-friendly |


## FAQ : SaaS + extension Chrome sur un seul backend

Les questions que posent les développeurs avant de livrer un compagnon extension :

- Pourquoi une clé API plutôt que le cookie de session de l'utilisateur ?, Les cookies HttpOnly sont invisibles au JS d'extension par conception et les service workers MV3 sont éphémères — une clé `sk_…` scopée dans `chrome.storage.local` est persistante, révocable et liée à un workspace, donc incapable d'écrire ailleurs.
- L'extension fonctionne-t-elle sur Firefox ?, MV3 supporte la même surface ; le code utilise un shim de namespace `browser ?? chrome` et se développe Chromium-first — Firefox est donc un portage, pas une réécriture.
- Est-elle prête pour le store dès l'installation ?, C'est un scaffold de pattern production, pas une soumission au store — vous renommerez le manifeste, ajouterez votre logique de capture et rédigerez le listing. La partie difficile (auth, API, scoping de tenant) est terminée.
- Quel palier inclut l'extension ?, Le Full Bundle à $299 livre les cinq surfaces — deux moteurs web, Expo, Tauri et le scaffold d'extension — dans un dépôt.