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

# Configuration

Gardez la configuration de l’application explicite et les identifiants fournisseurs côté serveur.

## Effectuez une modification de configuration et vérifiez-la

Commencez avec une application Web en cours d’exécution. Dans l'éditeur, ouvrez apps/web/.env.local ; s'il n'existe pas, copiez-y .env.example à l'aide du didacticiel Web. Pour une première vérification inoffensive, recherchez EMAIL_PROVIDER=local et laissez-le local. Ce paramètre envoie l'e-mail du produit vers l'aperçu local au lieu d'une véritable boîte de réception. Ne collez pas les lignes KEY=value dans le terminal.

Pour chaque service que vous activez, suivez le guide de configuration de ce fournisseur, remplacez uniquement les valeurs nommées, enregistrez le fichier, arrêtez le serveur Web avec Ctrl + C et redémarrez avec la commande ci-dessous. Si la validation nomme une clé manquante, rouvrez ce fichier et comparez cette clé avec le guide du fournisseur. Gardez root .env synchronisé uniquement pour les valeurs utilisées par les migrations de bases de données ; le copier seul ne configure pas Next.js.

[Rechercher une clé de configuration](https://supastack.dev/fr/docs/web/project-structure.md)

[Apprenez à exécuter une commande et à modifier un fichier](https://supastack.dev/fr/docs/web/terminal-basics.md)

```
corepack pnpm --filter @supastack/web dev
```


## Les réglages que vous modifierez vraiment en premier

`.env.example` à la racine du dépôt est l'inventaire complet des réglages que le kit comprend ; un nom absent de ce fichier n'existe pas. Vous n'en modifiez qu'une poignée au début — les autres gardent leurs valeurs par défaut jusqu'à ce qu'un guide de fournisseur les demande.

Quel fichier chaque app lit : le `.env` racine alimente les commandes de migration, `apps/web/.env.local` alimente le serveur Next.js, et `apps/mobile/.env.local` alimente Expo. Modifier un fichier ne configure pas les autres, donc `DATABASE_URL` vit à la fois dans le `.env` racine et dans `apps/web/.env.local`.

- `APP_URL` — l'adresse où vit l'app ; `http://localhost:3000` en local, votre domaine en production.
- `DATABASE_URL` — la chaîne de connexion Postgres que les migrations et le serveur partagent.
- `AUTH_SECRET` et `CREDENTIAL_ENCRYPTION_KEY` — des secrets générés ; `node scripts/setup-env.mjs` les remplit pour vous (cet utilitaire est livré dans le dépôt Web et le monorepo All Platforms).
- Les sélecteurs de fournisseur — `EMAIL_PROVIDER`, `AI_PROVIDER`, `BILLING_PROVIDER`, `JOB_PROVIDER`, `CAPTCHA_PROVIDER` — chacun choisit quel adaptateur s'exécute ; les valeurs par défaut `local`/`fake`/`off` n'exigent aucun compte.
- Les secrets de fournisseur tels que `RESEND_API_KEY` ou `STRIPE_SECRET_KEY` — à n'ajouter que quand le guide du fournisseur correspondant vous le dit.


## Commencer par l’exemple d’environnement

Le `.env.example` racine est l’inventaire de configuration. La validation partagée se trouve dans `packages/config`. Examinez ensemble l’environnement choisi et les modes des fournisseurs ; une interface locale ne constitue pas une stratégie d’identifiants de production.

Le mode de référence sans identifiants exige une configuration d’application locale/de test et des fournisseurs fake/local. Le choix d’un fournisseur de production modifie les exigences du runtime.


## Garder les secrets derrière l’API

Les secrets d’authentification, identifiants de base, clés de fournisseurs, secrets Stripe et identifiants Trigger sont réservés au serveur. Ne leur ajoutez jamais le préfixe NEXT_PUBLIC_ ou EXPO_PUBLIC_. Ne les affichez pas pendant la configuration et ne les incluez pas dans les réponses d’erreur.

Le navigateur reçoit la configuration publique et les alias de modèles autorisés. La propriété de l’espace de travail, les décisions de droits, les budgets et le choix des fournisseurs restent imposés par le serveur.


## Vérifier un changement avant de l’utiliser

Validez la configuration avec le package config existant et exécutez les tests déterministes pertinents. Lorsque vous souhaitez valider de vraies intégrations, utilisez le parcours d’essai fournisseur auquel vous avez choisi de participer séparément.

```
corepack pnpm test
corepack pnpm check
corepack pnpm build
```


Pour poursuivre la configuration, consultez [Configurer la base de données](https://supastack.dev/fr/docs/web/setup-database.md).


## Suivant

[Construire votre première fonctionnalité](https://supastack.dev/fr/docs/web/first-feature.md)