Variables d'environnement

Où se trouvent les paramètres

Créez chaque fichier à partir du .env.example placé à côté, qui documente chaque variable : cp .env.example .env. Les exemples fonctionnent tels quels pour une exécution locale.

Où se trouvent les paramètres

Un seul fichier, storefront/.env, lu au moment du build de la boutique. Toutes ses valeurs sont publiques : il ne contient donc jamais de secret. Omettez-le pour fonctionner sur la boutique d'exemple ; créez-le à partir de .env.example quand vous connectez une API : cp .env.example .env.

Où se trouvent les paramètres

Un seul fichier, admin-dashboard/.env, lu au moment du build du tableau de bord. Toutes ses valeurs sont publiques : il ne contient donc jamais de secret. Omettez-le pour fonctionner sur la boutique d'exemple ; créez-le à partir de .env.example quand vous connectez une API : cp .env.example .env.

Où se trouvent les paramètres

Un seul fichier, back-end/.env, lu par l'API avec yarn dev, et par un conteneur quand vous le lui passez avec --env-file .env. Il contient des secrets : ne le committez jamais. Créez-le à partir de .env.example, qui documente chaque variable et fonctionne tel quel pour une exécution en local : cp .env.example .env.

Paramètres essentiels de l'API

L'API vérifie JWT_SECRET et CORS_ORIGIN avant de démarrer. Si l'une manque ou est inutilisable, elle s'arrête avec une ligne indiquant ce qu'il faut corriger.

Générez votre propre JWT_SECRET avec :

node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"

Tout identifiant ci-dessous qui garde exactement sa valeur de .env.example compte comme non défini : la fonctionnalité correspondante s'affiche alors comme désactivée au lieu d'échouer à son premier appel.

Utiliser MySQL au lieu de SQLite

Créez une base de données vide, puis définissez le pilote et la connexion dans back-end/.env :

DB_TYPE=mysql
DB_HOST=your-mysql-host
DB_PORT=3306
DB_USERNAME=your-mysql-username
DB_PASSWORD=your-mysql-password
DB_DATABASE=your-database-name

Puis exécutez yarn seed pour la boutique de démonstration, ou yarn db:sync pour les tables sans données. L'API en fonctionnement ne crée et ne met à jour elle-même les tables qu'avec NODE_ENV=development : avec NODE_ENV=production, l'une de ces commandes doit donc tourner avant le premier démarrage (yarn db:sync:prod ou yarn seed:prod après yarn build).

Boutique et tableau de bord admin

Chaque valeur NEXT_PUBLIC_* est compilée dans le JavaScript chargé par le navigateur, et toute personne qui ouvre la page peut la lire. Ne mettez jamais de secret dans ces fichiers, et reconstruisez après en avoir modifié un.

Les balises marketing de la boutique sont aussi des valeurs NEXT_PUBLIC_*.

• Analytics et pixels de suivi

Options de Docker Compose

Rien n'est à définir pour une exécution en local. Pour changer quelque chose, placez-le dans un fichier .env à côté de docker-compose.yml et relancez docker compose up --build : les frontends intègrent ces valeurs à la compilation.

Le conteneur de l'API lit aussi back-end/.env lorsqu'il existe : les clés de paiement, de médias et d'IA se définissent donc à un seul endroit, pour yarn dev comme pour Docker. Le fichier compose l'emporte pour les quelques valeurs qui diffèrent dans un conteneur : le chemin de la base de données, le port, NODE_ENV=production, CORS_ORIGIN et FRONTEND_URL. Les données vivent dans le volume ecommerce-data.

Stockage des médias

Les photos de produits, les images de catégories, les avatars, les pièces jointes de conversation, les résultats du studio IA et les photos de la cabine d'essayage sont envoyés dans un bucket Cloudflare R2, ou n'importe quel bucket compatible S3. Définissez les cinq variables dans back-end/.env et donnez aux deux frontends l'hôte public du bucket via NEXT_PUBLIC_MEDIA_HOSTNAME (avec Docker Compose, MEDIA_HOSTNAME).

R2_ACCESS_KEY_ID=
R2_SECRET_ACCESS_KEY=
R2_ENDPOINT=https://your-account-id.r2.cloudflarestorage.com
R2_BUCKET_NAME=
R2_PUBLIC_URL=https://your-public-url.r2.dev

Sans bucket, yarn seed enregistre chaque image de produit et de catégorie sous forme de chemin /mock-media/…, et les deux frontends livrent ces 35 fichiers dans public/mock-media/ : le catalogue s'affiche donc sans aucun envoi. Seul l'envoi de nouvelles images cesse de fonctionner : il répond 503 tant que le bucket n'est pas configuré.

Avec un bucket, le seed y envoie les images de son catalogue. Gardez public/mock-media/ dans les deux frontends tant qu'un produit pointe encore dessus.

Paiements par carte

Les paiements par carte passent par Stripe : STRIPE_SECRET_KEY et STRIPE_WEBHOOK_SECRET dans back-end/.env, et NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY pour la boutique. Sans elles, aucun paiement par carte n'est encaissé, et le paiement à la livraison fonctionne normalement.

STRIPE_SECRET_KEY=sk_test_your-stripe-secret-key
STRIPE_WEBHOOK_SECRET=whsec_your-webhook-secret

• Configurer Stripe

E-mail

Le template ne fournit aucun transport d'e-mails : aucun message n'est donc jamais envoyé par e-mail. Hors production, le jeton de réinitialisation du mot de passe d'un client est écrit dans le journal de l'API à la place ; avec NODE_ENV=production, il n'est envoyé nulle part. Connectez votre propre service d'e-mails avant la mise en ligne : le point d'accroche est forgotPassword dans back-end/src/modules/customer-auth/customer-auth.controller.ts.

• Comptes clients

Fonctionnalités IA

La boutique d'exemple des frontends

Les deux frontends fonctionnent sans API. Démarré ou construit sans NEXT_PUBLIC_API_BASE_URL, chacun répond à chaque requête à partir d'une boutique d'exemple dans le navigateur et affiche une mention « Sample data ». C'est en définissant l'adresse que vous la désactivez.

• N'importe quel e-mail et mot de passe vous connectent en tant que client d'exemple sur la boutique. Dans le tableau de bord, n'importe quel e-mail valide avec un mot de passe d'au moins 6 caractères vous connecte en tant que Super Admin.
• Les écritures sont réelles et conservées dans le stockage du navigateur : elles survivent donc à un rechargement. Pour repartir de zéro, exécutez localStorage.removeItem("mock_db_v1"); location.reload(); dans la console du navigateur.
• Le paiement sur la boutique aboutit sans appeler Stripe.
• Dans le tableau de bord, l'assistant IA et le studio IA restent indisponibles, car tous deux ont besoin des clés de l'API.
• Une fois votre API en ligne, yarn remove:mock dans l'une ou l'autre application supprime la boutique d'exemple et sa mention. La commande laisse public/mock-media/ en place, car un backend rempli sans bucket y fait pointer ses images.

Comment fonctionne la boutique d'exemple

Mode démo

Mise en ligne

Avant de déployer quelque part en public :

1. Définissez NODE_ENV=production et un JWT_SECRET long et aléatoire qui vous est propre dans back-end/.env.
2. Réglez CORS_ORIGIN sur les adresses de votre boutique et de votre tableau de bord admin, séparées par une virgule, et FRONTEND_URL sur l'adresse du tableau de bord admin.
3. Sur une base de données vide, exécutez yarn build, puis yarn db:sync:prod une fois (ou yarn seed:prod pour la boutique de démonstration), puis yarn start:prod.
4. Faites pointer le health check de votre hébergeur vers /api/health.
5. Construisez chaque frontend avec NEXT_PUBLIC_API_BASE_URL pointant vers votre API déployée et le NEXT_PUBLIC_SITE_URL de la boutique sur sa propre adresse.
6. Changez le mot de passe du Super Admin, ou partez de tables vides.