> ## 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

# Créer les comptes de publication desktop

Identifiants de signature et de notarisation Apple, options de signature de code Windows et le backend hébergé dont un shell publié a besoin.

## Quand vous en avez besoin

Le travail desktop local n'a besoin de rien sur cette page — `corepack pnpm --filter @supastack/desktop dev` lance le shell, et `tauri build` produit des installateurs non signés qui fonctionnent très bien sur votre propre machine.

Ces comptes ne comptent qu'avant une sortie publique : la signature de code et la notarisation Apple sont ce qui supprime les avertissements de sécurité que les ordinateurs des autres affichent pour une app inconnue. Créez-les quand une sortie approche, pas le premier jour.

[Configurer Amazon SES avec le SDK AWS ou IAM SMTP](https://supastack.dev/fr/docs/web/aws-ses.md)


## Apple : certificat + clé de notarisation

1. Inscrivez-vous au [programme Apple Developer](https://developer.apple.com) — 99 $ par an. La même adhésion qui soumet les apps iOS couvre la signature macOS ; vous ne payez pas deux fois.

2. Créez un certificat Developer ID Application sur un Mac : Xcode → Settings → Accounts → votre compte → Manage Certificates → + → Developer ID Application (le flux certificate-assistant de Keychain Access est l'alternative).

3. La notarisation — le contrôle côté serveur d'Apple auquel Gatekeeper fait confiance — utilise une clé API App Store Connect : ouvrez [appstoreconnect.apple.com](https://appstoreconnect.apple.com) → Users and Access → Integrations → App Store Connect API → générez une clé, téléchargez immédiatement le fichier `.p8` (il n'est proposé qu'une fois) et notez le Key ID et l'Issuer ID.

Ces identifiants alimentent les noms d'environnement `APPLE_*` documentés dans Code signing — le certificat, son mot de passe, l'identité de signature et la paire clé API/émetteur. Gardez chacun dans un magasin de secrets, jamais dans le dépôt.

[Brancher les identifiants dans le build](https://supastack.dev/fr/docs/desktop/signing.md)


## Signature de code Windows

Deux options existent : acheter un certificat de signature de code OV ou EV auprès d'une autorité de certification — EV lève les avertissements SmartScreen le plus vite tandis que OV construit une réputation avec le temps — ou utiliser le service Azure Trusted Signing de Microsoft avec un compte Azure, la voie par abonnement plus récente.

Les installateurs non signés s'installent et tournent quand même ; ils déclenchent des avertissements SmartScreen pour quiconque les télécharge. Acceptable pour des tests privés, inacceptable pour une sortie publique.

L'empreinte du certificat ou une commande `signtool` personnalisée va dans la configuration du bundle Windows — les détails vivent dans Code signing ; cette page ne couvre que le compte.

[Configurer la signature Windows](https://supastack.dev/fr/docs/desktop/signing.md)


## Une URL de backend publique

Le shell desktop est une webview, pas une app autonome : un build de sortie doit charger un backend HTTPS public, que vous fournissez en intégrant `SUPASTACK_APP_URL` au build. Un shell qui pointe vers `localhost` est un outil local, pas un produit.

Déployez l'app web d'abord — le parcours Google Cloud produit l'URL HTTPS, et la liste de contrôle de déploiement est la référence plus courte. Réglez `SUPASTACK_APP_URL` dessus quand vous construisez la sortie.

[Déployer le backend sur Google Cloud](https://supastack.dev/fr/docs/web/deploy-google-cloud.md)

[Liste de contrôle de déploiement](https://supastack.dev/fr/docs/web/deployment.md)


## Un endpoint de mise à jour

L'updater de Tauri consulte un manifeste HTTPS `latest.json` pour connaître les nouvelles versions. N'importe quel hébergement statique convient — une release GitHub Releases ou un fichier dans un bucket S3/R2 — donc un compte GitHub existant suffit pour commencer ; aucun service séparé n'est requis.

Ce n'est que de la préparation au niveau compte : le câblage de l'updater lui-même relève du travail Bundle et release au moment de la sortie, pas d'une configuration à faire maintenant.


## Ce que « terminé » signifie

Vérifiez chaque élément avant le travail de sortie : Apple affiche une adhésion Developer Program active, un certificat Developer ID Application siège dans le Trousseau, et la `.p8` App Store Connect est sauvegardée avec son Key ID et son Issuer ID notés. Sous Windows, un chemin de certificat est choisi — achat auprès d'une CA ou Trusted Signing — ou vous avez explicitement décidé de livrer non signé pour l'instant.

La vérification backend : un déploiement HTTPS public existe et `SUPASTACK_APP_URL` pour les builds de sortie pointe dessus. La vérification des mises à jour : un hébergement pour `latest.json` est choisi — GitHub Releases ou un bucket.

Puis continuez dans l'ordre :

[Assembler et publier](https://supastack.dev/fr/docs/desktop/release.md)

[Signature de code](https://supastack.dev/fr/docs/desktop/signing.md)

[Déployer le backend partagé](https://supastack.dev/fr/docs/web/deployment.md)


Pour poursuivre la configuration, consultez [Assembler et publier](https://supastack.dev/fr/docs/desktop/release.md).


## Suivant

[Assembler et publier](https://supastack.dev/fr/docs/desktop/release.md)