Aller au contenu
supastack
Parcourir la documentation
BureauTauri

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/signing.md (or send Accept: text/markdown).

Signature de code

Signez les installeurs pour que macOS et Windows cessent d'avertir vos utilisateurs.

Poser une question sur ce guide
Ouvrir dans

Parcours pas à pas pour débuter

Conditions préalables : Terminez la configuration locale du bureau, y compris Rust et les outils de construction du système d'exploitation. Arrêtez le processus de développement Tauri avant de créer un programme d'installation ; laissez le backend Web fonctionner. Exécutez chaque vérification ci-dessous à partir de la racine du référentiel et attendez qu'elle se termine avant d'exécuter la suivante. Les commandes du package filtré fonctionnent dans les extractions de bureau uniquement et toutes les plateformes.

Termes rapides : un espace de travail est constitué des utilisateurs, des données et des paramètres distincts d'une équipe. Le serveur est le backend de confiance ; gardez les clés du fournisseur hors du code du navigateur et du téléphone. Une migration est une modification de base de données versionnée qui crée ou met à jour des tables. Un modèle d'IA est le moteur qui répond ; le catalogue de modèles est la liste du serveur des identifiants de modèles et des prix disponibles. Un fournisseur est un service externe tel qu'un service d'IA, de messagerie ou de facturation. Un droit est une subvention qui permet à un espace de travail d'utiliser une fonctionnalité. Un webhook est un message qu'un service envoie au URL d'un autre service.

1. Dans une succursale locale, demandez à votre agent de codage d'inspecter apps/desktop/src-tauri/tauri.conf.json et de définir l'identifiant du produit, le nom de l'application, les icônes et le backend URL sur les valeurs que vous possédez. Utilisez un backend public HTTPS URL pour les versions release.

2. À partir de la racine du référentiel, exécutez les vérifications du package Desktop ci-dessous. Avant de vérifier : release-config, définissez SUPASTACK_APP_URL dans ce terminal à l'aide de la commande du système d'exploitation dans la configuration locale du bureau ; le backend public HTTPS doit être en cours d'exécution et l'identifiant de l'application doit être le vôtre.

3. Une build réussie ne signe, ne légalise ni ne publie un programme d'installation ; si Rust ou une bibliothèque système est manquant, terminez la configuration locale du bureau.

Pour le code personnalisé, commencez par le prompts/README.md fourni et copiez l'invite la plus proche : prompts/new-app-screen.md pour un écran d'application ou prompts/new-landing-page.md pour une page publique. Pour le travail sur un serveur, une base de données ou un fournisseur, confiez à votre agent de codage la tâche de ce guide et demandez-lui de lire les miroirs AGENTS.md, .ai/PROJECT_CONTEXT.md et .ai/ correspondants ; inspectez les fichiers sources exacts nommés ici ; lister les fichiers et les vérifications avant de les modifier ; préserver la propriété de l'espace de travail et les secrets du serveur ; et je vous montre la différence. Indiquez-lui le comportement souhaité, les champs d'entrée et de sortie, les rôles autorisés, les succès et erreurs attendus, ainsi que le compte, le fournisseur ou l'appareil de test. Utilisez des exemples de valeurs ; ne collez jamais un vrai secret.

corepack pnpm --filter @supastack/desktop typecheck
corepack pnpm --filter @supastack/desktop test
corepack pnpm --filter @supastack/desktop check:release-config
corepack pnpm --filter @supastack/desktop build

Configurer le shell produit

Examinez src-tauri/tauri.conf.json, les métadonnées Cargo, les capacités et les identifiants de plateforme. Remplacez les icônes via le processus de ressources partagé et définissez l’URL backend visée à la compilation ou à l’exécution. L’application web hébergée doit déjà être déployée et accessible.

Exécuter la vérification de compilation native

Ces commandes de package exécutent la vérification et les tests de type Rust, valident les paramètres de version et créent le programme d'installation de Tauri. La configuration de la signature et de la distribution dépend de la plateforme cible et de votre compte/certificats ; ne stockez pas de matériel de signature dans la source.

corepack pnpm --filter @supastack/desktop typecheck
corepack pnpm --filter @supastack/desktop test
corepack pnpm --filter @supastack/desktop check:release-config
corepack pnpm --filter @supastack/desktop build

Vérifier l’installateur sur le système cible

Vérifiez l’installation propre, le lancement, l’accès au serveur, l’authentification, les menus/la zone de notification, l’enregistrement du raccourci, la seconde instance, les liens profonds, la reprise hors ligne et la désinstallation. Vérifiez séparément chaque système d’exploitation pris en charge. Une build locale ne prouve pas une distribution commerciale signée ou notarisée ; la configuration de signature, un flux de mise à jour et l’automatisation des versions ne sont pas inclus.

Configuration et paramètres

1. Les installeurs non signés s'installent très bien sur votre machine mais déclenchent les avertissements Gatekeeper et SmartScreen chez tous les autres — signez avant de livrer.

2. Sur macOS, rejoignez l'Apple Developer Program pour un certificat Developer ID, puis ajoutez la configuration de signature et de notarisation sous la section bundle de src-tauri/tauri.conf.json et fournissez à Tauri son env de signature documenté (APPLE_CERTIFICATE, APPLE_CERTIFICATE_PASSWORD, APPLE_SIGNING_IDENTITY, plus les identifiants de notarisation APPLE_API_KEY / APPLE_API_ISSUER) depuis le coffre de secrets de votre CI.

3. Sur Windows, configurez la signature Windows du bundle — une empreinte de certificat ou une commande signtool personnalisée — avec le certificat là aussi livré via le coffre de secrets de votre runner.

# tauri.conf.json ships unsigned today:
#   "bundle": { "active": true, "targets": "all", "icon": [...] }
# Add signing under bundle > macOS / bundle > windows
# and keep every certificate and password in your secret store,
# never in the repo.
# Auto-updater & release channels (stable / beta via {{channel}}):
# SUPASTACK_UPDATER_ENDPOINT=https://releases.example.com/{{channel}}/{{target}}/{{arch}}/{{current_version}}
# SUPASTACK_UPDATER_PUBKEY=…
# SUPASTACK_UPDATE_CHANNEL=stable

Processus d’implémentation

Provisionnez les certificats via votre propre coffre de secrets et injectez-les en variables d'environnement au build — un certificat commité au dépôt est un certificat à révoquer.

Intégrez la SUPASTACK_APP_URL de production dans le même build de release pour que les shells installés pointent vers l'app déployée.

Vérification et dépannage

Vérifiez en installant l'artefact produit sur une machine qui n'est pas la vôtre : aucun avertissement Gatekeeper ou SmartScreen, l'app se lance et la session persiste. Un tauri build vert sans le test d'installation signée n'est pas une preuve de release.

Ensuite : la checklist Déploiement de l'onglet Web couvre les portes de lancement côté serveur.

Questions fréquentes

14 questions

Qu'est-ce que supastack ?

supastack est une fondation modulaire pour construire des produits SaaS avec IA. Elle réunit l'infrastructure commune pour que vous puissiez vous concentrer sur les fonctionnalités propres à votre produit.

Prend-il en charge le web et le mobile ?

Oui. supastack inclut des applications Next.js et Expo comme points de départ pour des expériences web et mobile.

Quelle authentification est incluse ?

Better Auth couvre e-mail/mot de passe, OTP et connexion sociale. Les espaces de travail personnels sont provisionnés avec le compte pour que les enregistrements restent délimités dès le premier jour.

Comment l'IA est-elle prise en charge ?

supastack inclut une IA multi-fournisseurs configurable, le suivi d'usage, des budgets, et la prise en charge chiffrée de vos propres clés (BYOK).

Comment les abonnements sont-ils gérés ?

Pour les produits construits sur le kit, la facturation Stripe, les abonnements et les droits d'accès forment la base de l'accès payant. Les secrets fournisseur restent côté serveur.

Où vit le code propre à mon produit ?

Les fonctionnalités propres au produit restent dans un codebase séparé, tandis que le produit configure et intègre les modules de la fondation supastack.

Comment fonctionne la tarification de supastack ?

Le kit est un achat unique avec mises à jour à vie : Un framework à 249 $ (prix de lancement temporaire — 100 $ de réduction par rapport au prix habituel de 349 $) ou Tous les frameworks (Next.js, iOS, Android) à 499 $ (prix de lancement temporaire — 100 $ de réduction par rapport au prix habituel de 599 $), plus 75 $ par siège développeur supplémentaire. Pas d'abonnement au kit. Le paiement sur ce site livre votre clé de licence par e-mail, avec accès au dépôt via invitation GitHub.

Comment les espaces de travail délimitent mes données ?

Les enregistrements appartenant aux utilisateurs sont délimités par workspaceId. Identité, droits d'accès, usage IA, événements de facturation et entrées d'audit restent dans le périmètre de l'espace personnel.

Comment fonctionnent les jobs en arrière-plan ?

Trigger.dev est le runtime de jobs explicite. Le contrat JobRunner ne promet que enqueue, status et cancel — la sémantique de workflow reste propre à Trigger.dev et explicite.

En quoi l'e-mail diffère-t-il de la prospection ?

L'e-mail transactionnel couvre les flux produit comme les avis de fin de tâche. La prospection à froid et les campagnes relèvent du produit, hors du module e-mail de ce kit.

Comment fonctionnent les achats sur mobile ?

Le mobile inclut les achats natifs et leur restauration via RevenueCat, avec un accès vérifié par votre serveur. Configurez les comptes des boutiques et terminez les tests sur appareil avant publication. La facturation web reste séparée.

Où vivent les clés des fournisseurs IA ?

Les identifiants BYOK sont chiffrés et restent côté serveur. Les clés sont masquées dans les journaux ; l'usage et les budgets restent visibles au niveau de l'espace de travail.

Quels moyens de paiement le checkout accepte-t-il ?

Le checkout hébergé par Stripe accepte les cartes et peut aussi proposer Alipay et WeChat Pay une fois ces portefeuilles activés sur le compte Stripe — pratique pour les acheteurs en Chine. Les autorisations de portefeuille se confirment de manière asynchrone : la page de licence se met à jour dès que le paiement est validé.

Puis-je obtenir un remboursement ?

Une fois que vous avez accès au dépôt, supastack vous appartient pour toujours et ne peut donc pas être remboursé. Mais rassurez-vous : vous obtenez le code source complet avec des mises à jour à vie pour créer et déployer un nombre illimité de produits pour vous ou vos clients. Vous ne pouvez simplement pas revendre le code ni redistribuer le dépôt sous forme de kit de démarrage ou de modèle.

FR
Thème