MĂȘme architecture que la roue : rien de nouveau Ă apprendre, rien de nouveau Ă payer. La page est directement opĂ©rationnelle â pas de mode privĂ©, puisquâaucune promesse automatique nâest faite au visiteur.
Supabase â SQL Editor â coller supabase/supabase-cartes-cadeaux.sql â Run.
Une seule table créée, cartes_cadeaux. Rien dâexistant nâest touchĂ©.
La table prévoit déjà les colonnes stripe_session, montant_paye et
paye_le : elles restent vides tant que tu encaisses Ă la main, et servent
si tu branches le paiement en ligne plus tard. Câest ce qui fera de cette
évolution une greffe et non une refonte.
Copier aurea-vercel/api/carte-cadeau.js dans le dossier api/ du projet
Auréa, à cÎté de roue.js, puis vercel --prod.
Aucune nouvelle variable dâenvironnement : la fonction rĂ©utilise
SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY et BREVO_API_KEY déjà en place.
Déposer dans le repo GitHub, en respectant les dossiers :
NOUVEAUX
carte-cadeau.html la page
assets/css/carte-cadeau.css
assets/js/carte-cadeau.js
MODIFIĂS
index.html + lien menu et pied de page
evenements.html + lien menu et pied de page
_includes/header.html + lien menu
_includes/footer.html + lien pied de page
cgv.html + article 5 bis « Cartes cadeaux »
confidentialite.html + section 4 octies
â ïž Comme la derniĂšre fois : le contenu du dossier, pas le dossier.
Tout se pilote depuis Supabase â SQL Editor. Les requĂȘtes sont en bas du fichier SQL, prĂȘtes Ă copier. La seule vraiment quotidienne :
select cree_le, reference, offrant, email, telephone,
destinataire, formule_nom, mode, montant, occasion, mot, statut,
round(extract(epoch from now() - cree_le) / 3600) as heures_ecoulees
from public.cartes_cadeaux
where statut in ('nouvelle', 'devis_envoye', 'payee')
order by cree_le;
La colonne heures_ecoulees te dit lesquelles approchent des 48 h promises.
nouvelle â devis_envoye â payee â carte_envoyee â utilisee
Une contrainte en base refuse tout autre statut : impossible dâĂ©crire « payĂ©e » avec un accent ou « envoyĂ© » au singulier et de ne plus retrouver la commande. Chaque Ă©tape a sa requĂȘte toute prĂȘte dans le fichier SQL.
LâĂ©tape carte_envoyee pose automatiquement la date de validitĂ© Ă un an.
Une requĂȘte te donne un verdict en clair â valable, dĂ©jĂ utilisĂ©e, expirĂ©e, ou pas encore rĂ©glĂ©e. Elle est dans le fichier SQL sous « est-elle valable ».
Une requĂȘte calcule ton taux de transformation : combien de demandes deviennent des cartes payĂ©es.
En dessous de 50 %, ce nâest pas ta page qui est en cause, câest le dĂ©lai. Un cadeau sâachĂšte sur un Ă©lan, et ton systĂšme impose une attente de 48 h puis un virement. Câest ce chiffre, et lui seul, qui dira sâil vaut le coup de brancher le paiement en ligne â pas une intuition.
Autre requĂȘte utile : les cartes vendues mais jamais utilisĂ©es qui arrivent Ă Ă©chĂ©ance. Un rappel amical trois semaines avant, et tu rĂ©cupĂšres une consultation qui allait se perdre.
La carte elle-mĂȘme. Tu la prĂ©pares Ă la main, comme convenu. Lâaperçu de la page indique honnĂȘtement au visiteur que la vraie carte sera illustrĂ©e et plus belle â ne le dĂ©mens pas, câest une promesse.
Le jour oĂč tu veux lâautomatiser, la mĂ©thode est prĂȘte : tu gĂ©nĂšres deux ou trois fonds sur OpenArt comme pour tes affiches de lot, et je compose le prĂ©nom, le message et la rĂ©fĂ©rence par-dessus. Les donnĂ©es sont dĂ©jĂ toutes en base.