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, lu quand le site est construit. Chaque valeur NEXT_PUBLIC_* qu'il contient est publique, il ne contient donc jamais de secret. Créez-le depuis .env.example, qui pointe vers une API sur http://localhost:8000 : cp .env.example .env. Avec Docker, passez les mêmes valeurs avec --build-arg.

Où se trouvent les paramètres

Un seul fichier, .env dans le dossier du tableau de bord, lu quand le tableau de bord est construit. Chaque valeur qu'il contient est publique, il ne contient donc jamais de secret : les clés de paiement et d'IA vivent dans le .env de l'API. Créez-le depuis .env.example, qui pointe vers une API sur http://localhost:8000 : cp .env.example .env. Avec Docker, passez les mêmes valeurs avec --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, donc docker run fonctionne sans fichier : SQLite à /data/database.sqlite, envois dans /data/uploads, CORS_ORIGIN pour les deux frontends locaux, FRONTEND_URL=http://localhost:3031, SITE_URL=http://localhost:3030, PUBLIC_MEDIA_URL=http://localhost:8000/media et SEED_DEMO_DATA=false. Remplacez 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.

Paiements

Sans aucune de ces valeurs, le simulateur fourni accepte toute réservation par carte et PayPal, donc tout le paiement fonctionne sans compte marchand, et le journal de démarrage de l'API affiche Payment simulator active tant que c'est le cas. Il confirme ces réservations sans prendre d'argent, définissez donc Stripe, PayPal ou les deux avant de prendre de vraies réservations : le simulateur se désactive alors, le paiement ne propose que les moyens configurés plus le paiement à l'arrivée, et un moyen sans processeur est refusé. L'onglet Paiements des paramètres du tableau de bord montre quels processeurs sont configurés, si leurs clés sont de test ou réelles, et si le simulateur est utilisé, jamais les clés elles-mêmes.

STRIPE_SECRET_KEY=your-stripe-secret-key
STRIPE_WEBHOOK_SECRET=your-stripe-webhook-signing-secret
PAYPAL_CLIENT_ID=your-paypal-client-id
PAYPAL_CLIENT_SECRET=your-paypal-client-secret
PAYPAL_WEBHOOK_ID=your-paypal-webhook-id
PAYPAL_ENV=sandbox

Le paiement à l'arrivée n'a besoin d'aucune clé : c'est l'interrupteur allow_pay_on_arrival dans l'onglet Paiements du tableau de bord, activé dans le seed.

• Réservations et paiements

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=hollina

Lancez ensuite yarn seed pour la société de démonstration, ou yarn db:sync pour les tables sans données. L'API en cours d'exécution ne crée et ne met à jour les tables d'elle-même que si NODE_ENV=development, donc avec NODE_ENV=production l'une de ces commandes est lancée avant le premier démarrage (yarn seed:prod ou yarn db:sync:prod après yarn build).

Photographies et envois

L'API sert elle-même les photographies du seed, depuis public/media/hollina, sur /media/hollina/…. Les envois depuis le tableau de bord (photographies de séjours, couvertures de destinations, photos de profil) 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 de photographie en est construite, et l'API y déplace celles qui sont enregistrées à son démarrage, donc déplacer l'API conserve chaque photographie. Sur un serveur, faites pointer 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 photographies.

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 photographies sont réencodées à l'envoi en JPEG, de 1920 pixels de large au plus, avec une copie plus petite pour les cartes de séjour. Les vidéos sont acceptées en MP4, WebM, MOV ou M4V, jusqu'à 150 Mo.

Site des séjours et tableau de bord des réservations

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 du site sont aussi des valeurs NEXT_PUBLIC_* : Google Tag Manager, GA4, Meta, TikTok, Snapchat et Pinterest, chacune activée par un seul identifiant.

• Balises d'analyse et 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.

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

Le conteneur de l'API lit aussi back-end/.env quand il existe, donc les clés de paiement, d'IA, R2 et MCP se définissent à un seul endroit pour yarn dev comme pour Docker. Le fichier compose l'emporte pour les valeurs qui diffèrent dans un conteneur : le chemin de la base de données, le dossier des envois, le port, NODE_ENV=production et les adresses ci-dessus. La base de données et les envois vivent dans le volume hollina-data.

L'assistant IA

Le serveur MCP

Mode démo