Comment créer un site de location saisonnière avec Next.js

Ce guide montre comment créer un site de location saisonnière avec réservation directe en Next.js : un site public où les voyageurs choisissent des nuits libres et paient, un tableau de bord où l’hôte gère le calendrier, et une API qui garde toutes les dates cohérentes. Nous partons du template Hollina et suivons un hôte fictif de l’installation jusqu’au lancement.

La réservation directe repose surtout sur la confiance dans le calendrier. Si le site affiche une nuit libre et que le tableau de bord la dit prise, vous perdez le voyageur et la soirée. Les étapes ci-dessous passent donc plus de temps sur la disponibilité, les paiements et la première semaine après le lancement, et moins sur la décoration.

Le cahier des charges

Larch Ridge Cabins est un petit hôte avec six cabanes et cottages, géré par une équipe de trois personnes. Aujourd’hui, il prend des réservations par téléphone et via un site d’annonces, et il veut aussi son propre site. Le projet doit :

• Permettre à un voyageur de chercher des hébergements par destination, dates, nombre de personnes et type de logement.
• Présenter chaque hébergement avec des photos, des équipements, le règlement intérieur, des avis et un calendrier des nuits libres.
• Calculer le prix avant le paiement : tarif par nuit, frais de ménage et total.
• Accepter les paiements par carte et PayPal, et permettre de payer à l’arrivée pour ceux qui le préfèrent.
• Empêcher les doubles réservations, tout en laissant un voyageur arriver le jour où un autre part.
• Laisser l’hôte bloquer des nuits pour des travaux, et voir les arrivées et les départs d’un coup d’œil.
• Fonctionner en anglais et en arabe, car certains voyageurs naviguent en arabe.

Une contrainte de plus, qui a sa place dans tout cahier des charges honnête : le template calcule le prix d’un séjour avec un seul tarif par nuit et un seul forfait ménage, et il fonctionne avec une seule devise (le dollar américain) et un seul fuseau horaire (America/New_York). Larch Ridge est une entreprise de la côte est des États-Unis, donc cela convient. Si votre activité exige des tarifs saisonniers ou une autre devise, prévoyez du développement sur mesure.

Comment le template répond au cahier des charges

Besoin	Où ça se trouve	Ce que vous utilisez
Chercher et filtrer les hébergements	Site des hébergements	La liste des hébergements sur /en/stays, avec les filtres conservés dans l’adresse
Nuits libres et devis immédiat	Site et API	Le calendrier sur deux mois et la carte de réservation de chaque page d’hébergement
Pas de double réservation	API	Un seul service de disponibilité utilisé par le calendrier, le paiement et le tableau de bord
Carte, PayPal ou paiement à l’arrivée	API et tableau de bord	Les clés Stripe et PayPal dans le .env de l’API, et l’interrupteur de paiement à l’arrivée sous Paramètres, Paiements
Dates bloquées et réservations	Tableau de bord des réservations	La page Calendrier avec la boîte de blocage des dates, et la page Réservations
Questions et avis des voyageurs	Site et tableau de bord	La boîte de questions et le formulaire de contact qui alimentent Demandes ; Avis pour publier ou masquer
Anglais et arabe	Les trois applications	Routes /en et /ar, fichiers de messages, éditeur d’hébergement bilingue

Avant de commencer : les décisions à prendre

Les sites de réservation dérapent quand les règles de l’activité sont floues. Réglez d’abord ceci.

• Quel pack. Full Stack pour une nouvelle activité. Un front end seul a besoin d’une API quelque part.
• Où il tourne. Un hébergement Node pour trois applications, une base de données (SQLite sur un disque persistant, ou MySQL) et un endroit pour les photos (un dossier persistant ou un bucket comme Cloudflare R2).
• Les langues. Chaque hébergement est rédigé en anglais et en arabe. La publication exige les deux, donc quelqu’un doit écrire le texte arabe.
• Les paiements. Stripe, PayPal, paiement à l’arrivée, ou un mélange, sur des comptes qui appartiennent à l’entreprise. L’argent va sur ces comptes, il ne passe pas par le template.
• Les règles de prix. Un tarif par nuit, un forfait ménage et un séjour minimum par cabane. Les tarifs saisonniers, les codes de réduction et la synchronisation des calendriers avec d’autres sites d’annonces ne sont pas inclus.
• Qui gère le tableau de bord. Décidez qui est Super Admin, qui est gestionnaire, et si la personne chargée du ménage a besoin d’un rôle à part.
• Comment les voyageurs reçoivent une réponse. L’API n’envoie aucun e-mail, donc décidez qui répond aux questions et depuis quelle boîte de réception.

Pas à pas

Étape 1 : Choisir le pack

Hollina existe en pack Full Stack (site, tableau de bord et API) et en trois packs séparés. Le site et le tableau de bord ne gardent aucune donnée eux-mêmes, donc chacun a besoin de l’API derrière lui. Pour une nouvelle activité, prenez le pack Full Stack et gardez tout dans un seul dossier.

Les éléments séparés ont du sens pour les agences qui hébergent déjà une API, ou pour un hôte qui ne veut que le site des hébergements ou que le tableau de bord de réservation. Une chose à savoir avant de vous engager : le template est conçu pour une seule entreprise hôte. Ce n’est pas une place de marché où de nombreux propriétaires publient leurs biens.

À vérifier avant de continuer

Vous savez dire quel ZIP vous avez téléchargé et quelles applications il contient. Si c’est un front end seul, vous savez où son API va tourner.

Ce qui se passe mal en général

Un front end seul n’affiche rien sans son API, car aucune des deux applications ne garde de données.

Étape 2 : Le lancer en local avec Docker

Installez Docker Desktop, téléchargez votre ZIP depuis Mes templates, décompressez-le et ouvrez un terminal dans le dossier hollina-vacation-rental-full-stack. Lancez ensuite :

docker compose up --build

Le premier démarrage construit trois images et crée une entreprise de démonstration, ce qui prend quelques minutes. Vous avez alors le site des hébergements sur http://localhost:3030, le tableau de bord de réservation sur http://localhost:3031 et l’API sur http://localhost:8000. Si un port est pris, ajoutez SITE_PORT, ADMIN_PORT ou API_PORT dans un fichier .env à côté de docker-compose.yml et relancez la commande.

Dans cette capture de la vidéo d’installation, regardez la commande unique qui démarre les trois applications.

Le tableau de bord a deux comptes de démonstration : admin@hollina.example avec le mot de passe Admin@123, et manager@hollina.example avec Manager@123. Le site n’a aucun compte. Les voyageurs sont identifiés par une référence de réservation et l’e-mail avec lequel ils ont réservé.

Passez une heure avec les données de démonstration avant de supprimer quoi que ce soit. Le seed contient 14 hébergements, 60 réservations réparties sur l’année, des plages bloquées, des questions de voyageurs et des avis, et il garde ses dates relatives au jour où vous démarrez, donc une base neuve a toujours quelqu’un qui arrive. Réservez un hébergement en tant que voyageur, puis retrouvez cette réservation dans le tableau de bord et faites-la avancer.

Observez le chemin entre la page d’un hébergement et une réservation, c’est la boucle à répéter en tant que voyageur.

Attention à docker compose down -v : il supprime aussi le volume hollina-data, donc le démarrage suivant ramène une entreprise de démonstration neuve et tout ce que vous avez saisi disparaît.

À vérifier avant de continuer

Les trois adresses répondent, vous avez réservé un hébergement de démonstration en tant que voyageur et retrouvé cette réservation dans le tableau de bord.

Ce qui se passe mal en général

Docker n’est pas lancé : démarrez Docker Desktop et réessayez. Un port occupé termine le démarrage avec « address already in use » : déplacez l’application avec les variables de port ci-dessus. Au premier démarrage, un onglet de page d’hébergement qui affiche seulement « Hébergement » est sans gravité dans Docker, et le stack complet définit déjà l’adresse interne de l’API qui règle ce point. Sans Docker, rappelez-vous que les applications demandent Node.js 22 ou plus récent et que Yarn 1.22 répond tant que vous n’avez pas lancé corepack enable.

Étape 3 : Renseigner l’entreprise

Certaines informations sont du code et d’autres des données. Celles qui sont dans le code se trouvent dans le dossier du site :

• storefront/src/config/brand.config.ts contient le nom du site et ses métadonnées.
• storefront/src/config/booking.config.ts contient les valeurs de repli du fuseau horaire et de la devise.
• storefront/src/styles/theme-variables.css contient les couleurs sous forme de tokens, avec une valeur claire et une valeur sombre. Changez les deux, sinon un thème garde l’ancienne couleur de marque.
• storefront/public/brand/ contient le logo, et les photographies propres à l’hôte pour le site (bandeau d’accueil, étapes du fonctionnement, carte de contact) se trouvent dans le dossier de l’API, sous public/media/hollina/site/.

Cherchez Hollina dans messages/ et réécrivez ces lignes en anglais et en arabe. Les données se modifient dans le tableau de bord, sous Paramètres, onglet Entreprise : le nom de l’entreprise, le slogan et la description dans les deux langues, les coordonnées, et les heures d’arrivée et de départ par défaut. Ouvrez ensuite la page de confidentialité. Son texte est un texte provisoire, signalé comme tel sur la page, alors réécrivez-le pour votre entreprise et votre pays et retirez ce signalement.

À vérifier avant de continuer

Les titres des onglets, le pied de page et les titres affichent Larch Ridge dans les deux langues, et les deux thèmes restent lisibles avec les nouvelles couleurs.

Ce qui se passe mal en général

Une couleur changée dans un seul thème, ou une phrase réécrite en anglais sans la ligne correspondante dans le fichier de messages arabe. La page de confidentialité est l’oubli classique.

Étape 4 : Ajouter les destinations et les hébergements

Créez d’abord les destinations (Paramètres, Destinations), car chaque hébergement appartient à l’une d’elles. Larch Ridge en utilise deux : le bord du lac et la crête. Ajoutez ensuite chaque hébergement depuis la page Hébergements. L’éditeur range le titre et les descriptions sous des onglets anglais et arabe, avec le type de logement (cabane, cottage, chalet, etc.), la capacité, le tarif par nuit, les frais de ménage, le nombre de nuits minimum, les équipements, le règlement intérieur et les photos.

Quelques règles de l’éditeur comptent pour la planification :

• Chaque nouvel hébergement est un brouillon. Un brouillon répond comme introuvable sur le site public tant que vous ne le publiez pas.
• La publication exige trois photographies et les deux langues.
• Les photos sont envoyées et ordonnées par vous. La première sert de photo de carte et de couverture.
• Le tarif est un nombre entier de dollars américains. Un devis multiplie le tarif par les nuits et ajoute les frais de ménage une seule fois.

Une fois les hébergements en place, choisissez celui de la bannière de la page d’accueil et les quatre hébergements à la une sous Paramètres, Page d’accueil. Commencez par les quelques hébergements que vous savez bien photographier plutôt que par les six d’un coup.

À vérifier avant de continuer

Publiez un hébergement et ouvrez-le en tant que voyageur dans une fenêtre privée. Essayez ensuite de publier un deuxième hébergement avec une seule langue renseignée, pour voir la vérification qui vous arrête.

Ce qui se passe mal en général

Les photos de l’hébergement ne se chargent pas. Leurs adresses sont construites à partir de PUBLIC_MEDIA_URL, qui doit atteindre l’API depuis le navigateur du voyageur. Rappelez-vous aussi que le tableau de bord n’a pas de bouton pour supprimer un hébergement : dépubliez-le plutôt.

Étape 5 : Comprendre le fonctionnement des nuits

La logique du calendrier est le cœur d’un site de réservation, et celle-ci est simple à raisonner. Une réservation couvre les nuits depuis l’arrivée jusqu’au départ, celui-ci non compris. Si un voyageur part le 10, le suivant peut arriver ce jour-là, et trois nuits veulent dire trois nuits, pas quatre.

Le devis et le paiement appliquent les mêmes quatre vérifications : la date d’arrivée n’est pas passée, le séjour respecte le nombre de nuits minimum, le groupe tient dans la capacité, et aucune des nuits n’est prise. Le paiement les refait au moment d’écrire la réservation, de sorte que deux voyageurs ne peuvent pas payer la même nuit. Une réservation en attente de paiement garde ses dates pendant 30 minutes, puis expire.

Le calendrier du tableau de bord affiche chaque réservation sous forme de barre sur ses nuits. Pour fermer une cabane pour travaux, ouvrez la boîte de blocage des dates, choisissez maintenance, usage de l’entreprise ou autre, et ajoutez une note. Si la plage empiète sur une réservation ou sur un blocage antérieur, la boîte refuse et indique lequel.

Regardez les choix de motif et le champ de note dans la boîte qui ferme une cabane pour travaux.

À vérifier avant de continuer

Réservez deux fois la même cabane pour des nuits qui se chevauchent et vérifiez que la deuxième tentative est refusée avec un message indiquant que ces nuits sont prises. Bloquez une plage, puis essayez de réserver à cheval dessus.

Ce qui se passe mal en général

On s’attend à ce qu’un voyageur qui part le 10 bloque le 10. Ce n’est pas le cas : ce jour reste ouvert pour celui qui arrive ensuite. Autre surprise, le séjour minimum limite aussi les jours de départ que le calendrier propose.

Étape 6 : Configurer les paiements, puis éteindre le simulateur

Une installation neuve n’a aucun prestataire de paiement, donc un simulateur intégré valide chaque réservation par carte ou PayPal sans prélever d’argent. Le paiement affiche « Mode test : aucune carte n’est débitée », et un numéro de carte qui se termine par 0 échoue exprès, pour que vous voyiez le parcours d’échec. C’est utile pendant la construction, et dangereux si on l’oublie. Dès que Stripe ou PayPal est configuré, le simulateur s’éteint de lui-même.

Pour Stripe, définissez une clé secrète de test (sk_test_) dans STRIPE_SECRET_KEY, dans le .env de l’API. Quand l’API est sur un serveur, ajoutez dans Stripe un point de terminaison de webhook dont l’adresse est l’adresse publique de votre API suivie de :

/api/webhooks/payments/stripe

Abonnez-le à checkout.session.completed, payment_intent.payment_failed, charge.refunded et charge.dispute.created, puis mettez son secret de signature dans STRIPE_WEBHOOK_SECRET. Sans ce secret, l’API rejette tous les webhooks Stripe et aucune réservation par carte n’est jamais validée. Réservez ensuite un hébergement dans le navigateur avec la carte de test 4242 4242 4242 4242.

Regardez les choix de paiement et la politique d’annulation affichés à côté du récapitulatif des nuits.

Pour PayPal, définissez PAYPAL_CLIENT_ID, PAYPAL_CLIENT_SECRET et PAYPAL_WEBHOOK_ID ; PAYPAL_ENV reste sur sandbox jusqu’à la mise en ligne. Le paiement à l’arrivée n’a besoin d’aucune clé. C’est un interrupteur sous Paramètres, Paiements, et le même onglet contient la politique d’annulation que lisent les voyageurs, dans les deux langues.

À vérifier avant de continuer

Réservez avec la carte de test Stripe, puis vérifiez que la réservation passe à payée dans le tableau de bord et que la page de réservation du voyageur n’indique plus que le paiement est en cours de confirmation.

Ce qui se passe mal en général

Une réservation payée reste en attente. La page de réservation attend le webhook, donc vérifiez l’adresse du point de terminaison, le secret de signature et redémarrez l’API. Au bout de 30 minutes, la réservation non payée prend fin et un balayage l’annule comme expirée.

Étape 7 : Ajouter l’équipe et limiter ce que voit chacun

Il n’y a pas de page d’inscription. Les deux comptes du tableau de bord viennent du seed : un Super Admin avec les 32 permissions, et un Manager avec tout sauf les administrateurs, les rôles et les paramètres de l’entreprise. Créez de vrais comptes sous Gestion des administrateurs, puis remplacez les mots de passe de démonstration, ou supprimez les comptes du seed, avant que quelqu’un hors de votre équipe puisse atteindre le tableau de bord.

Pour Larch Ridge, ajoutez un rôle pour la personne chargée du ménage, qui n’a besoin que du calendrier. Sous Rôles des administrateurs, créez un rôle avec seulement les permissions du calendrier et attribuez-le à cette personne. L’assistant respecte les mêmes permissions, donc quelqu’un qui n’a pas le droit de modifier les réservations ne peut pas non plus en annuler une depuis le chat.

À vérifier avant de continuer

Connectez-vous en tant que gestionnaire et vérifiez que les pages des administrateurs et des rôles sont absentes. Connectez-vous avec le rôle de ménage et vérifiez que seul le calendrier apparaît.

Ce qui se passe mal en général

Personne n’a supprimé les mots de passe du seed. Le rôle Manager ne peut pas non plus modifier les paramètres de l’entreprise, donc le propriétaire doit faire les changements de l’onglet Paiements.

Étape 8 : Prévoir le côté voyageur après la réservation

C’est là que la réservation directe diffère d’un site d’annonces, et cela mérite une décision avant le lancement. L’API n’envoie aucun e-mail. Après le paiement, le voyageur voit la page de réservation avec un numéro de référence, et la retrouve sur la page Retrouver ma réservation avec la référence et l’e-mail utilisé. Les questions du formulaire de contact et de la page d’hébergement arrivent comme des demandes dans le tableau de bord, avec une notification sur la cloche, et l’équipe répond depuis sa propre messagerie.

Regardez la référence de réservation, dont le voyageur a besoin plus tard pour retrouver sa réservation.

Les voyageurs peuvent annuler depuis leur page de réservation tant que l’arrivée est dans au moins sept jours. Une réservation payée passe alors à remboursement en attente, et l’hôte effectue le remboursement dans le tableau de bord de Stripe ou de PayPal. Les avis ne fonctionnent que pour les séjours terminés, un par réservation, et l’équipe peut masquer ou publier chacun d’eux.

L’assistant est facultatif. Avec une clé Google Gemini dans GOOGLE_API_KEY, le chat du tableau de bord répond à des questions comme quelles cabanes sont libres le week-end prochain et, si vous le demandez, il peut bloquer des dates ou faire avancer une réservation. Sans clé, il dit qu’il n’est pas connecté, rien n’est facturé, et tout le reste fonctionne. Google facture Gemini selon sa propre grille, indiquée sur la page des tarifs de Gemini.

Regardez le graphique que l’assistant dessine quand la question porte sur une tendance.

À vérifier avant de continuer

Retrouvez votre propre réservation de test avec sa référence et son e-mail, annulez-en une à plus de sept jours, et envoyez-vous une question depuis la page d’un hébergement pour la voir arriver comme demande.

Ce qui se passe mal en général

Un formulaire rejette un envoi. Les formulaires acceptent cinq envois de chaque par adresse en dix minutes et portent un champ caché contre les robots, donc une série de tests depuis un seul ordinateur peut vous bloquer brièvement.

Étape 9 : Tester sur téléphone, dans les deux langues

Parcourez tout le chemin en tant que voyageur sur un vrai téléphone : recherche, ouverture d’un hébergement, choix des nuits, vérification du devis, réservation, paiement avec la carte de test Stripe, puis ouverture de la page de réservation. Sur téléphone, une barre de réservation reste fixée en bas de la page d’hébergement, alors faites défiler une page longue et une page courte pour la vérifier. Faites ensuite la même chose en arabe sur /ar.

Regardez la barre de réservation en bas, qui garde le prix et l’étape suivante à portée de main.

Essayez exprès les cas délicats : des nuits déjà prises, moins de nuits que le minimum, un groupe plus nombreux que ce que la cabane peut loger, et un paiement qui échoue. Dans le tableau de bord, vérifiez que la réservation apparaît dans le calendrier, puis confirmez-la, enregistrez l’arrivée et terminez-la. Une réservation avec paiement à l’arrivée est marquée payée à l’enregistrement de l’arrivée.

À vérifier avant de continuer

Gardez une courte liste de tests et exécutez-la sur un téléphone et sur un ordinateur : recherche, devis, réservation, paiement, retrouver la réservation, l’annuler, et noter un séjour terminé.

Ce qui se passe mal en général

La page d’hébergement affiche une erreur de carte au lieu de la carte. La carte utilise OpenFreeMap par défaut, qui demande un accès à internet et ne promet aucune disponibilité. Définissez NEXT_PUBLIC_MAP_STYLE_LIGHT avec un autre style MapLibre si vous avez besoin d’un niveau de service.

Étape 10 : Mettre en ligne

La documentation présente trois façons de déployer : un serveur avec Docker Compose, chaque application depuis son propre Dockerfile sur un hébergeur comme Railway ou Render, ou Node.js seul. Pour un petit hôte, un serveur avec Docker Compose est le plus simple. Mettez les trois adresses publiques dans un .env à côté de docker-compose.yml (SITE_URL, ADMIN_URL et API_URL), et les origines autorisées, les adresses des photos et les réglages du front end en sont déduits. Utilisez un reverse proxy pour le HTTPS.

La liste de contrôle avant le premier vrai voyageur :

• Construisez le site et le tableau de bord avec des adresses publiques. NEXT_PUBLIC_API_BASE_URL est compilé dans le JavaScript, donc un changement exige une reconstruction.
• Définissez NODE_ENV=production, votre propre JWT_SECRET et CORS_ORIGIN. L’API les vérifie avant de démarrer.
• Définissez SITE_URL avec l’adresse que parcourent les voyageurs, car le prestataire de paiement y renvoie les voyageurs.
• Placez le fichier SQLite et les envois sur un disque qui survit aux déploiements, ou passez à MySQL avec un bucket.
• Sur un serveur avec NODE_ENV=production, créez d’abord les tables avec yarn seed:prod ou yarn db:sync:prod, après yarn build. Utilisez l’option des tables vides pour une vraie entreprise.
• Remplacez les clés de test Stripe et PayPal par des clés live, et enregistrez le webhook live. Derrière un proxy, transmettez le corps du webhook intact, sinon la signature ne correspondra pas.

Ne lancez jamais yarn setup:fresh ni yarn db:reset sur une entreprise en production. Les deux suppriment toutes les tables. Enfin, faites une petite vraie réservation à une date calme et annulez-la, pour avoir vu de l’argent réel circuler dans les deux sens.

À vérifier avant de continuer

Dans une fenêtre privée, réservez un petit séjour réel à une date calme, vérifiez que le webhook le marque payé, puis annulez-le et remboursez-le depuis le tableau de bord du prestataire.

Ce qui se passe mal en général

Les pages affichent « Something went wrong » et la console mentionne CORS : ajoutez les deux adresses live à CORS_ORIGIN. Tous les visiteurs reçoivent des erreurs « Too many » derrière un proxy : définissez TRUST_PROXY. Les photos échouent quand NEXT_PUBLIC_MEDIA_HOSTNAME ne nomme pas leur hôte.

Au quotidien

Voici une semaine normale pour l’équipe de Larch Ridge, avec uniquement des écrans que le tableau de bord possède déjà.

Une matinée dans le tableau de bord

La vue d’ensemble affiche le taux d’occupation et les revenus du mois en cours, qui arrive et qui part aujourd’hui, les réservations qui demandent une décision, un an de revenus et les réservations les plus récentes. Commencez par ce qui attend.

Regardez les arrivées et les départs du jour, qui disent à la personne chargée du ménage et à l’hôte ce que la journée réserve.

Ouvrez ensuite Réservations. Des onglets de statut avec leur nombre, un champ de recherche par référence ou nom du voyageur et une plage de dates d’arrivée gardent la liste maniable. Ouvrez une réservation pour voir la chronologie et les actions que son état permet : confirmer, enregistrer l’arrivée, terminer ou annuler, avec un motif affiché quand une étape n’est pas disponible.

Regardez les boutons proposés pour cette réservation et le motif affiché pour ceux qui ne sont pas disponibles.

Le calendrier et les demandes

Le calendrier dessine chaque réservation sous forme de barre sur ses nuits, colorée selon le statut, et les dates bloquées apparaissent à côté. Ouvrez-le avant de promettre une date par téléphone.

Regardez comment une réservation ne couvre que ses nuits, si bien que le jour de départ est visiblement libre pour une arrivée.

Les demandes ont leur propre page. Chacune s’ouvre à côté de la liste et montre l’hébergement et les dates sur lesquels le voyageur a posé sa question, le nombre de personnes et une note privée. Marquez-la comme répondue ou close au fil de l’eau.

Regardez le statut de chaque demande, qui évite à l’équipe de répondre deux fois à la même question.

Tâches hebdomadaires

• Publiez ou masquez les nouveaux avis, et regardez la note de chaque hébergement suivre.
• Passez en revue le registre des dates bloquées et retirez celles qui sont terminées.
• Renouvelez les hébergements à la une et les questions de la page d’accueil sous Paramètres, Page d’accueil.
• Demandez à l’assistant quelles cabanes sont libres le week-end prochain ou comment les revenus se comparent d’un mois à l’autre.
• Sauvegardez la base de données et les envois, et gardez une copie ailleurs.

Un exemple de plan de lancement, semaine par semaine

Voici un calendrier d’exemple pour Larch Ridge, pas une promesse sur la durée de votre projet.

• Semaine 1, les fondations. Lancez le stack avec Docker, réservez un hébergement de démonstration, prenez les décisions ci-dessus et commencez l’image de marque et la page de confidentialité.
• Semaine 2, les hébergements. Ajoutez les destinations et les premières cabanes dans les deux langues avec des photos, fixez les tarifs et les nuits minimum, et testez le blocage de dates.
• Semaine 3, l’argent et les personnes. Connectez Stripe et PayPal en mode test, rédigez la politique d’annulation, créez l’équipe et testez sur téléphone et en arabe.
• Semaine 4, la mise en ligne. Déployez, passez aux clés live, réservez et remboursez un vrai séjour, et ouvrez le site d’abord aux anciens voyageurs.

Liste de contrôle du lancement

• Le nom de l’entreprise, les coordonnées, le texte de confidentialité et la politique d’annulation sont les vôtres, dans les deux langues.
• Chaque hébergement publié a trois photos ou plus, les deux langues, un tarif, des frais de ménage et un séjour minimum.
• Les mots de passe de démonstration sont remplacés ou les comptes du seed sont supprimés.
• Les clés Stripe ou PayPal sont live, le webhook livre, et l’onglet Paiements n’indique plus que le simulateur est utilisé.
• NODE_ENV vaut production, JWT_SECRET est le vôtre, et CORS_ORIGIN liste les adresses live.
• SITE_URL est l’adresse que parcourent les voyageurs.
• Les deux front ends ont été reconstruits avec l’adresse live de l’API.
• La base de données et les envois sont sur un stockage persistant, avec une sauvegarde.
• Quelqu’un est responsable de la boîte de réception où l’on répond aux questions des voyageurs.
• Une vraie réservation a été faite, annulée et remboursée.

Template, développement sur mesure ou plateforme hébergée

Vous avez trois voies réalistes vers un site de réservation directe.

Un template comme celui-ci

Vous obtenez le code source du site, du tableau de bord et de l’API, avec la disponibilité, les devis, les paiements et les webhooks qui fonctionnent déjà ensemble. Il est à vous et vous pouvez le modifier. Vous l’hébergez aussi, et ce qui manque au template, comme les e-mails, les tarifs saisonniers ou la synchronisation des calendriers avec d’autres sites, relève du développement.

Tout construire soi-même

Vous obtenez un produit taillé exactement pour votre activité, et vous construisez vous-même les parties difficiles : la logique des nuits qui se chevauchent, les blocages sur les réservations non payées, une gestion des webhooks qui confirme un paiement une seule fois, les remboursements. C’est un long chemin, sauf si vos règles sont inhabituelles.

Une plateforme de réservation hébergée

Elle est rapide à démarrer et inclut souvent des outils de diffusion multicanale. En contrepartie, il y a des frais récurrents, moins de contrôle sur l’expérience du voyageur, et les données de vos voyageurs qui vivent sur leur système. Vérifiez d’abord les conditions, les frais et la prise en charge de l’arabe.

Beaucoup d’hôtes gardent les sites d’annonces pour la visibilité et ajoutent un site direct pour fidéliser les voyageurs. Si vous faites les deux, rappelez-vous que ce template ne synchronise pas les calendriers avec d’autres sites, donc les blocages doivent être reproduits à la main.

Ce que coûte son fonctionnement

Le template est un achat unique, à partir de $79 pour le site des hébergements seul. Le pack Full Stack que nous avons utilisé ici coûte $179, avec une licence commerciale et un support à vie.

En plus, vous payez :

• Un serveur ou des hébergeurs pour l’API, le site et le tableau de bord, plus un disque persistant ou une base MySQL.
• Le stockage des photos si vous utilisez un bucket comme Cloudflare R2 au lieu du disque de l’API.
• Les frais de Stripe et PayPal, facturés selon leurs propres pages de tarifs (voir les tarifs de Stripe). L’argent va sur vos propres comptes et le template ne le détient jamais.
• Une clé Google Gemini, seulement si vous activez l’assistant.
• Un nom de domaine.

Gratuit : l’exécution en local avec SQLite, le simulateur de paiement, le paiement à l’arrivée, et la carte de la page d’hébergement, qui utilise des styles OpenFreeMap sans clé.

Que personnaliser ensuite

• Les destinations et la page d’accueil. Ajoutez des visuels de destination et réécrivez les questions de la page d’accueil dans les deux langues depuis les Paramètres.
• Les types d’hébergement. Les six types de logement (villa, appartement, cabane, chalet, loft et cottage) ont leurs propres icônes dans public/icons/stay-types/.
• Le suivi. Ajoutez un identifiant Google Tag Manager, GA4, Meta, TikTok, Snapchat ou Pinterest dans le .env du site.
• La politique d’annulation. Modifiez le texte dans les deux langues pour qu’il corresponde à ce que vous respecterez.

Erreurs fréquentes

Laisser le simulateur allumé

Le simulateur confirme des réservations qui n’ont jamais été payées. Configurez Stripe ou PayPal avant que le site soit public, puis vérifiez que l’onglet Paiements n’indique plus que le simulateur est utilisé.

Oublier le secret du webhook Stripe

Si un paiement par carte réussit dans Stripe mais que la réservation reste en attente, le webhook n’arrive pas ou son secret manque. La réservation garde ses nuits bloquées pendant 30 minutes, après quoi une tâche de fond l’annule comme expirée.

S’attendre à des tarifs saisonniers ou à des taxes

Chaque hébergement a un seul tarif par nuit. Les tarifs saisonniers, les tarifs de week-end, les taxes et les frais de service n’existent pas. Si vos prix sont plus compliqués, décidez tôt s’il faut étendre la logique du devis ou simplifier les prix.

S’attendre à des e-mails automatiques

L’API n’envoie aucun e-mail, donc les voyageurs ne voient que ce qui se passe sur la page. Prévoyez comment l’équipe écrira aux voyageurs, et dites-le sur le site.

FAQ

Comment créer un site de location saisonnière avec Next.js ?

Partez d’un template qui gère déjà la disponibilité, les prix et les paiements, puis configurez-le pour vos biens. Un site de réservation directe a besoin d’un site public, d’un tableau de bord pour l’hôte et d’une API qui soit l’unique source de vérité pour les dates. Les étapes ci-dessus le déroulent avec Hollina.

Ai-je besoin d’un back-end ?

Oui. Les dates libres, les prix et la confirmation du paiement doivent être décidés sur un serveur. Le template inclut une API NestJS avec TypeORM, qu’utilisent à la fois le site et le tableau de bord.

Comment évite-t-il les doubles réservations ?

Un seul service de disponibilité décide quelles nuits sont libres pour le calendrier, le devis, le paiement et le tableau de bord, et le paiement revérifie au moment d’écrire la réservation. Les réservations non payées bloquent leurs nuits pendant 30 minutes.

Puis-je l’utiliser pour des clients ?

Oui. Il est livré avec une licence commerciale pour un nombre illimité de projets. Consultez la page de licence de la documentation pour connaître les conditions exactes.

Gère-t-il l’arabe et le RTL ?

Oui. Le site et le tableau de bord existent en anglais et en arabe, et l’arabe inverse toute la mise en page. Les hébergements sont rédigés dans les deux langues, et les prix et les dates gardent les chiffres latins.

Plusieurs propriétaires peuvent-ils y publier leurs biens ?

Non. Il est conçu pour une seule entreprise hôte, avec un seul ensemble d’hébergements, une seule équipe et un seul compte de paiement. Une place de marché demanderait un travail supplémentaire.

Quels moyens de paiement les voyageurs peuvent-ils utiliser ?

La carte via le Checkout hébergé de Stripe, PayPal, et le paiement à l’arrivée tant que cet interrupteur est activé. Le paiement hébergé signifie qu’aucun numéro de carte n’atteint votre serveur.

Les voyageurs peuvent-ils réserver sans créer de compte ?

Oui. Le site n’a pas de comptes voyageurs. Un voyageur réserve avec un nom et un e-mail, puis retrouve la réservation avec sa référence et cet e-mail.

Se synchronise-t-il avec d’autres sites d’annonces ?

Non. La synchronisation des canaux n’est pas incluse, donc si vous publiez aussi ailleurs, vous devez reproduire vous-même les dates bloquées et les réservations, ou développer la synchronisation.

Essayez par vous-même

Réservez un hébergement sur le site des hébergements en ligne, puis ouvrez la démo du tableau de bord de réservation pour la voir arriver. La démo utilise le mode test de Stripe : payez avec la carte de test de Stripe et aucun argent ne bouge. La documentation de Hollina couvre chaque réglage de ce guide, et la page du produit liste les packs. Parcourez des projets similaires dans la catégorie des templates full stack. Hollina fait aussi partie des dix templates du Next.js Templates Bundle.