Invyra

Plateforme de création et d'envoi d'invitations d'événement. L'organisateur choisit un modèle de la galerie, le personnalise sans code (textes, photos, couleurs, écran d'ouverture, musique), l'envoie par email ou WhatsApp avec un lien nominatif par invité, et suit les ouvertures et les réponses. L'invité qui confirme reçoit un billet à QR code, scanné à l'entrée le jour J ; il retrouve l'itinéraire sur une carte et laisse ses photos, ses vidéos et un mot dans le livre d'or. Les modèles eux-mêmes sont écrits en HTML, CSS et JavaScript par les administrateurs.

---

Fonctionnalités

Organisateur (/dashboard)

• Événement avec date, heure, code vestimentaire, numéro de contact et un itinéraire en plusieurs étapes placées sur une carte.
• Galerie de modèles classés par catégorie, personnalisation sans code.
• Invités ajoutés un par un ou importés en CSV (nom,email,téléphone,places), avec un nombre de places par invité.
• Envoi par email, individuel ou groupé, ou par lien WhatsApp ; suivi des ouvertures et des réponses ; export PDF de la liste des invités.
• Collaborateurs en édition ou en lecture seule, statistiques.
• Modération des souvenirs et préparation de l'accueil du jour J.

Invité (/invite/[token], sans compte)

• Invitation animée, avec écran d'ouverture et musique.
• Réponse (présent, absent, peut-être), nombre de personnes, régime alimentaire, mot pour les hôtes.
• Billet d'entrée : page avec QR code, PDF au format A6, et e-mail envoyé à la confirmation.
• Itinéraire : carte des étapes et liens vers Google Maps, Waze ou Plans.
• Souvenirs : livre d'or, photos et vidéos partagées avec les autres invités.

Jour J (/check-in/[token])

• Lien secret confié à l'équipe d'accueil, qui n'a pas besoin de compte.
• Lecture du QR code à la caméra, saisie du code à la main ou recherche par nom.
• Compteurs d'arrivées, correction du nombre de personnes, annulation d'une arrivée.

Administration (/admin)

• Utilisateurs (rôle, formule, suspension) et ensemble des événements.
• Les admins créent et modifient aussi les modèles en code, depuis Modèles dans l'espace connecté.

Site public

• Accueil, collection des modèles (/templates) et page de chaque modèle publié (/templates/[id]), toutes ouvertes sans compte.

---

Démarrer

pnpm install              # génère aussi le client Prisma (postinstall)
cp .env.example .env      # puis remplissez les valeurs
npx prisma db push        # crée le schéma sur une base vide
pnpm dev                  # http://localhost:3000

Sur une base existante, n'utilisez pas db push : appliquez les migrations de prisma/migrations-sql/ (voir Base de données).

Variables d'environnement

Variable	Rôle
DATABASE_URL	Chaîne de connexion PostgreSQL (NeonDB)
BETTER_AUTH_SECRET	Clé de signature des sessions, 32 caractères ou plus (openssl rand -base64 32)
NEXT_PUBLIC_APP_URL	URL publique, utilisée pour les liens d'invitation, le sitemap et l'Open Graph
SMTP_HOST SMTP_PORT SMTP_USER SMTP_PASS	Envoi des emails (Nodemailer) ; port 465 en SSL, 587 en STARTTLS
BLOB_READ_WRITE_TOKEN	Store Vercel Blob public pour les photos, la musique et les souvenirs. Sans lui, seul le collage d'un lien d'image fonctionne
CRON_SECRET	Facultatif. Protège la tâche planifiée /api/cron/keepalive

Sur Vercel, si NEXT_PUBLIC_APP_URL est absente, l'URL publique retombe sur VERCEL_PROJECT_PRODUCTION_URL côté serveur (lib/site.js).

---

Architecture

Rendu

Les pages sont des Server Components : elles appellent directement la couche app/actions/* et arrivent peuplées. Les composants clients sont réduits à ce qui a besoin d'état (formulaires, dialogues, onglets) et reçoivent leurs données en propriétés.

Concrètement, une page ne va pas chercher ses données dans un useEffect. Si vous ajoutez un écran, chargez ses données dans le composant serveur et passez le résultat à un enfant client.

Authentification

Gérée par better-auth (lib/auth/server.js).

• Sessions en base, table sessions ; cookie en cache 5 minutes pour éviter un aller-retour SQL à chaque server action.
• Les mots de passe sont hachés en bcrypt et non en scrypt : le hasher par défaut de better-auth est surchargé pour que les comptes créés avant la bascule restent valides.
• app/actions/auth.js expose getSession() sous la forme historique { userId, email, name, role, plan }, ce qui permet au reste des actions de ne rien savoir de better-auth.
• proxy.js (le middleware de Next 16) ne vérifie que la présence du cookie. L'autorisation réelle (rôle, suspension, propriété d'un événement) est faite côté serveur par requireAuth / requireAdmin / canAccessEvent.
• Chaque nouveau compte reçoit un e-mail de bienvenue, envoyé par un databaseHooks.user.create.after dans after() : l'inscription n'attend pas le serveur SMTP et un envoi raté ne la bloque jamais.

Migration depuis l'authentification JWT

Les comptes existants ont leur hash bcrypt dans users.password, exposé en legacyPassword. better-auth l'attend dans accounts.password.

La bascule se fait automatiquement à la première connexion de chaque utilisateur. Pour tout migrer d'un coup :

여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗