Variables d'environnement

Où se trouvent les paramètres

Créez le fichier de chaque application à partir du .env.example situé à côté, qui documente chaque variable : cp .env.example .env. Les exemples fonctionnent tels quels pour un lancement local, et le démarrage avec Docker Compose n'a besoin d'aucun fichier.

Où se trouvent les paramètres

Un seul fichier, .env dans le dossier du site. Les valeurs NEXT_PUBLIC_* qu'il contient sont lues au build du site et sont publiques : elles ne contiennent donc jamais de secret. REVALIDATE_SECRET et API_INTERNAL_URL sont lus par le serveur du site lui-même à l'exécution et n'atteignent jamais le navigateur. Créez-le à partir de .env.example, qui pointe vers une API sur http://localhost:8000 : cp .env.example .env. Avec Docker, passez les valeurs NEXT_PUBLIC_* en --build-arg et les deux autres avec -e.

Où se trouvent les paramètres

Un seul fichier, .env dans le dossier du tableau de bord, lu lors du build du tableau de bord. Toutes ses valeurs sont publiques : il ne contient donc jamais de secret, les clés des fournisseurs se trouvent dans le .env de l'API. Créez-le à partir de .env.example, qui pointe vers une API sur http://localhost:8000 : cp .env.example .env. Avec Docker, passez les mêmes valeurs en --build-arg.

Où se trouvent les paramètres

Un seul fichier, .env dans le dossier de l'API, lu par l'API avec yarn dev, et par un conteneur quand vous ajoutez --env-file .env -e NODE_ENV=production à son docker run. Il contient des secrets : ne le versionnez jamais. Créez-le à partir de .env.example, qui documente chaque variable et fonctionne tel quel pour un lancement local : cp .env.example .env.

L'image Docker définit ses propres valeurs par défaut, si bien que docker run fonctionne sans fichier : SQLite sur /data/database.sqlite, fichiers envoyés dans /data/uploads, exports CSV dans /data/exports, CORS_ORIGIN pour les deux frontends locaux, FRONTEND_URL=http://localhost:3031, STOREFRONT_URL=http://localhost:3030, PUBLIC_API_URL=http://localhost:8000, PUBLIC_MEDIA_URL=http://localhost:8000/media et SEED_DEMO_DATA=false. Remplacez-en n'importe laquelle avec -e.

Paramètres essentiels de l'API

L'API vérifie JWT_SECRET et, en production, CORS_ORIGIN avant de démarrer. Si l'une manque ou est inutilisable, elle s'arrête avec une ligne qui indique quoi corriger.

Générez votre propre JWT_SECRET avec :

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

Chaque fonctionnalité optionnelle ci-dessous reste désactivée tant que ses lignes dans .env.example restent en commentaire.

Votre propre espace de travail et son propriétaire

Lues uniquement sur une base sans compte d'équipe ni espace de travail (les tables de yarn db:sync, ou un volume Docker démarré avec SEED_DEMO_DATA=false). Le premier démarrage de l'API crée alors, à partir d'elles, les rôles, les paramètres du site, les catégories d'événements, un espace de travail et son propriétaire, une seule fois. Dès qu'un compte d'équipe existe, elles sont ignorées.

OWNER_EMAIL=you@your-domain.com
OWNER_PASSWORD=a-long-password-of-your-own
OWNER_NAME=Your Name
WORKSPACE_NAME=Your organisation

Dans le Docker Compose du Full Stack, elles peuvent aller dans le .env à côté de docker-compose.yml, avec SEED_DEMO_DATA=false : Compose transmet ce fichier à l'API en premier puis back-end/.env, dont la valeur l'emporte quand les deux en définissent une. Sans ces variables, l'API démarre et indique lesquelles définir.

• Mise en ligne avec votre propre espace de travail

Paiements

Le paiement envoie l'acheteur vers la page propre de Stripe ou de PayPal : les données de carte ne sont donc jamais saisies sur votre site. Chaque fournisseur est proposé dès que ses clés sont définies. Utilisez d'abord des clés de test : elles ne déplacent aucun argent.

STRIPE_SECRET_KEY=sk_test_your_key
STRIPE_WEBHOOK_SECRET=whsec_your_secret
PAYPAL_CLIENT_ID=your-client-id
PAYPAL_CLIENT_SECRET=your-client-secret
PAYPAL_WEBHOOK_ID=your-webhook-id
PAYPAL_ENV=sandbox

Les billets gratuits n'ont besoin de rien de tout cela : une commande sans rien à payer est confirmée au paiement, avec ou sans clés. Ticketory ne prélève aucune taxe lui-même : configurez la fiscalité de votre pays avant d'encaisser de vrais paiements.

• Commandes, paiements et remboursements

E-mail

Les billets, codes d'inscription, réinitialisations de mot de passe, nouvelles de remboursement et rappels d'événement sont envoyés via Resend dès que les deux variables sont définies. D'ici là, chaque e-mail est écrit dans le journal de l'API, c'est là qu'on lit un code d'inscription sur une installation neuve (avec Docker : docker compose logs api).

RESEND_API_KEY=re_your_key
MAIL_FROM=Ticketory <tickets@your-domain.com>
EVENT_REMINDER_HOURS=24

EVENT_REMINDER_HOURS est le délai avant un événement auquel part son rappel : 24 si non défini, au plus 168 (une semaine), et 0 désactive les rappels. Chaque e-mail concernant une commande (billets, remboursements, avis d'annulation et rappel) est rédigé dans la langue de la commande.

• Billets, passes et e-mails

Utiliser MySQL au lieu de SQLite

Créez une base de données vide, puis définissez le pilote et la connexion dans le .env de l'API :

DB_TYPE=mysql
DB_HOST=localhost
DB_PORT=3306
DB_USERNAME=root
DB_PASSWORD=
DB_DATABASE=ticketory

Lancez ensuite yarn seed pour les données d'exemple, ou yarn db:sync pour les tables sans données. L'API en marche ne crée et ne met à jour les tables d'elle-même que si NODE_ENV=development : avec NODE_ENV=production, l'une de ces commandes se lance donc avant le premier démarrage (yarn seed:prod ou yarn db:sync:prod après yarn build). L'image Docker le fait d'elle-même sur SQLite uniquement : sur MySQL, lancez-le une fois vous-même.

Images et fichiers envoyés

L'API sert elle-même les images d'exemple, depuis public/media/ticketory (les symboles de catégories, les logos de marque, l'emblème de l'assistant et les photos d'exemple du studio), sur /media/ticketory/…. Les fichiers envoyés depuis le tableau de bord (les photos de lieux vides pour le studio, les photos jointes à une question de l'assistant) et les concepts terminés du studio sont stockés sur le disque de l'API sous MEDIA_UPLOAD_DIR et servis sur /media/uploads/…, sauf si un bucket est défini.

PUBLIC_MEDIA_URL=http://localhost:8000/media
MEDIA_UPLOAD_DIR=./public/media/uploads

PUBLIC_MEDIA_URL est l'adresse à laquelle /media est joint depuis un navigateur. Chaque adresse d'image en est construite, et l'API y ramène celles déjà enregistrées au démarrage : déplacer l'API conserve donc toutes les images. Sur un serveur, pointez MEDIA_UPLOAD_DIR vers un stockage persistant ; avec Docker, il est dans le volume de données.

Pour envoyer les fichiers vers Cloudflare R2, ou tout bucket compatible S3, définissez les cinq variables. Donnez aux deux frontends l'hôte public du bucket via NEXT_PUBLIC_MEDIA_HOSTNAME (avec Docker Compose, MEDIA_HOSTNAME) pour que Next.js redimensionne ces images.

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

Les images sont réencodées en JPEG à l'envoi, sur 1 920 pixels de large au plus. Les vidéos sont acceptées en MP4, WebM, MOV ou M4V, jusqu'à 150 Mo.

Site et tableau de bord organisateur

Chaque valeur NEXT_PUBLIC_* est compilée dans le JavaScript que charge le navigateur, et toute personne qui ouvre la page peut la lire. N'y mettez jamais de secret, et reconstruisez (ou redémarrez yarn dev) après en avoir changé une.

Les balises marketing du site sont aussi des valeurs NEXT_PUBLIC_* : Google Tag Manager (NEXT_PUBLIC_GTM_ID), GA4 (NEXT_PUBLIC_GA4_MEASUREMENT_ID), Meta, TikTok, Snapchat et Pinterest, chacune activée par un seul identifiant ; un identifiant vide ne charge aucun script. NEXT_PUBLIC_ANALYTICS_CURRENCY (USD par défaut) est la devise envoyée avec les prix des billets, et NEXT_PUBLIC_ANALYTICS_DEBUG=true consigne chaque événement suivi dans la console du navigateur.

• Le site

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.

Changez un port quand un autre programme l'utilise déjà, par exemple ADMIN_PORT=3041. Le CORS_ORIGIN, le FRONTEND_URL, le STOREFRONT_URL, le PUBLIC_API_URL et le PUBLIC_MEDIA_URL de l'API, ainsi que les adresses d'API, de site et de tableau de bord des frontends, sont tous construits à partir des ports et des trois adresses : ils suivent donc d'eux-mêmes.

• Un port est déjà utilisé

Le conteneur de l'API lit d'abord ce .env puis back-end/.env s'il existe, dont la valeur l'emporte quand les deux en définissent une : les clés optionnelles se définissent donc à un seul endroit pour yarn dev et pour Docker. Le fichier compose l'emporte pour les valeurs qui diffèrent dans un conteneur : le chemin de la base, les dossiers des fichiers envoyés et des exports, le port, NODE_ENV=production et les adresses ci-dessus. La base, les fichiers envoyés et les exports CSV vivent dans le volume ticketory-data.

Fonctionnalités IA

Le serveur MCP

Mode démo