For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/desktop/external-accounts.md (or send Accept: text/markdown).
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.
Apple : certificat + clé de notarisation
1. Inscrivez-vous au programme Apple Developer — 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 → 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.
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.
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.
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 :
Pour poursuivre la configuration, consultez Assembler et publier.