Comment créer un système de commande pour restaurant avec Next.js

À la fin de ce guide, vous saurez comment créer un système de commande en ligne pour un restaurant avec Next.js : un site public pour commander, un back-office pour la cuisine et le propriétaire, et une API qui garde les règles. Nous partons du template Food Studio et suivons un restaurant d’exemple, de la première installation jusqu’au lancement.

L’objectif est un plan que vous pouvez suivre, pas une visite des fonctionnalités. Vous verrez quoi faire dès le premier jour, quels réglages comptent avant d’encaisser un vrai paiement, et quelles erreurs font perdre le plus de temps. Les mêmes étapes valent pour un seul restaurant, pour une marque de vente à emporter avec plusieurs cuisines, ou pour un site que vous réalisez pour un client.

Le cahier des charges

Olive Street Kitchen est un petit restaurant méditerranéen de vente à emporter avec deux cuisines, l’une dans la vieille ville et l’autre près de la gare. Le propriétaire veut que les clients commandent depuis un téléphone, paient en ligne et suivent la commande jusqu’à son arrivée. Voici ce que le projet doit faire :

• Afficher un menu que les clients peuvent chercher et filtrer par catégorie et par régime, avec les allergènes sur chaque plat.
• Vendre un combo (un plat, un accompagnement et une boisson) à un prix unique.
• Proposer la livraison et le retrait, et n’accepter une livraison que si l’adresse se trouve dans la zone d’une cuisine et que cette cuisine est ouverte.
• Accepter la carte bancaire ou PayPal sans que le restaurant ne manipule jamais de numéros de carte.
• Donner aux cuisines une file de commandes payées, et cacher les prix au personnel de cuisine.
• Fonctionner en anglais et en arabe, avec les pages arabes inversées de droite à gauche.
• Permettre au propriétaire de modifier le menu et la page d’accueil sans demander à un développeur.

Comment le template répond au cahier des charges

Besoin	Où ça se trouve	Ce que vous utilisez
Menu avec recherche et allergènes	Site de commande	La page du menu sur /en/shop, et l’éditeur de plats dans le tableau de bord
Combo à prix unique	Site et tableau de bord	La page du combo, et les sections offre de combo et composition de menu de la page d’accueil
Règles de livraison par cuisine	API et tableau de bord	Paramètres, Restaurant : cuisines, horaires, codes postaux de livraison, frais et commande minimum
Paiement en ligne	API	Clés et webhooks Stripe ou PayPal dans le fichier .env de l’API
File de cuisine sans prix	Tableau de bord	Page Équipe, le rôle cuisine rattaché à une seule cuisine
Anglais et arabe avec RTL	Les trois applications	Routes /en et /ar, les dossiers de messages, un éditeur de plats bilingue
Le propriétaire modifie la page d’accueil	Tableau de bord	Page d’accueil, neuf sections que vous activez, réordonnez et modifiez

Avant de commencer : les décisions à prendre

La plupart des retards, dans un projet comme celui-ci, viennent de décisions que personne n’a prises assez tôt. Réglez celles-ci avant d’ouvrir un terminal.

• Quel pack. Un pack à une seule application a besoin d’une API qui tourne quelque part, ne le choisissez donc que si vous en avez déjà une.
• Où ça tourne. Il vous faut un hébergeur Node pour trois applications, une base de données (SQLite sur un disque persistant, ou MySQL) et un endroit pour les fichiers envoyés (un dossier persistant ou un bucket comme Cloudflare R2).
• Quelles langues. Chaque plat est enregistré en anglais et en arabe : quelqu’un doit donc écrire ou vérifier chaque nom et chaque description en arabe avant le lancement.
• Quels prestataires de paiement. Stripe, PayPal ou les deux, avec des comptes qui appartiennent au restaurant. Les pourboires, les lignes de taxes et le paiement à la livraison ne sont pas inclus.
• Cuisines et zones de livraison. Chaque cuisine a besoin d’une adresse, d’horaires, d’un fuseau horaire, d’un temps de préparation et de ses codes postaux de livraison. Rassemblez tout sur une seule feuille.
• Qui utilise le tableau de bord. Décidez qui est le propriétaire, qui sont les managers, et prévoyez un compte de cuisine par cuisine.
• Comment les clients sont informés d’une commande. Il n’y a pas d’e-mails de confirmation de commande : les clients s’appuient donc sur la page de suivi. Décidez si cela suffit pour le premier mois.

Pas à pas

Étape 1 : Choisir le pack

Food Studio est vendu comme un template full stack et aussi en plusieurs éléments : le site de commande, le tableau de bord du personnel et l’API back-end. Le site et le tableau de bord n’ont aucune donnée propre. Ils lisent tout depuis l’API : un pack de site ou de tableau de bord seul a donc besoin d’une API qui tourne quelque part.

Pour un nouveau restaurant, prenez le pack Full Stack. Il contient les trois applications, la configuration de la base de données et le restaurant de démonstration dans un seul dossier. Si un client a déjà une API de confiance, ou si vous ne remplacez qu’un front end, un pack seul suffit. Les éléments sont présentés sur les pages du site de commande et du tableau de bord du personnel.

À vérifier avant de continuer

Vous savez nommer le ZIP que vous avez téléchargé et les applications qu’il contient. S’il s’agit d’un front end seul, vous savez où tournera son API.

Ce qui se passe le plus souvent de travers

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

Étape 2 : Le lancer en local avec Docker

Installez Docker Desktop (ou Docker Engine avec Compose), téléchargez le ZIP depuis Mes templates, décompressez-le et ouvrez un terminal dans le dossier food-studio-full-stack. Puis démarrez tout avec une seule commande :

docker compose up --build

Rien n’est à configurer au préalable. Le premier lancement construit trois images et charge un restaurant de démonstration : comptez quelques minutes. Quand tout est prêt, vous avez trois applications :

• Le site de commande sur http://localhost:3030 (l’arabe sur /ar).
• Le tableau de bord du personnel sur http://localhost:3031.
• L’API sur http://localhost:8000, avec toutes les routes sous /api.

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

Si un autre programme occupe déjà l’un de ces ports, placez un fichier .env à côté de docker-compose.yml avec SITE_PORT, ADMIN_PORT ou API_PORT réglé sur un numéro libre, puis relancez la commande. Les autres adresses suivent d’elles-mêmes.

Connectez-vous au tableau de bord en tant que propriétaire avec owner@foodstudio.example et le mot de passe FoodDemo2026!. Le même mot de passe fonctionne pour manager@foodstudio.example et kitchen@foodstudio.example. Sur le site, le client de démonstration est sam@foodstudio.example. Ce sont des comptes de démonstration locaux : prévoyez de les changer avant que le site soit public.

Passez vingt minutes ici dans la peau de trois personnes différentes : commandez en invité, faites avancer la commande en tant que propriétaire, puis ouvrez le compte de cuisine et regardez le peu qu’il affiche.

Regardez comment un plat s’ouvre avec sa quantité et ses instructions avant d’entrer dans le panier.

Pour arrêter les applications, appuyez sur Ctrl+C ou lancez docker compose down. Vos données sont conservées dans le volume food-studio-data. Faites attention à docker compose down -v : cette commande supprime aussi ce volume, et le démarrage suivant charge un nouveau restaurant de démonstration par-dessus tout ce que vous aviez saisi.

À vérifier avant de continuer

Les trois adresses répondent, une commande d’invité arrive dans le tableau de bord et le compte de cuisine n’affiche aucun prix.

Ce qui se passe le plus souvent de travers

Docker n’est pas lancé : démarrez Docker Desktop et réessayez. Un port occupé interrompt le démarrage avec "address already in use" : déplacez l’application avec les variables de port ci-dessus. Un démarrage qui semble bloqué est généralement en train de charger les données. Sans Docker, la cause habituelle est un Node.js trop ancien (les applications attendent la version 24 ou plus récente) ou Yarn 1.22 (lancez corepack enable).

Étape 3 : Renseigner les informations de l’entreprise

Faites le nom et l’apparence avant le menu, pour que toutes les captures suivantes montrent la vraie marque. Trois endroits comptent :

• storefront/src/config/brand.config.ts contient les noms (une valeur en anglais et une en arabe pour chacun), le domaine, les coordonnées et les liens vers les réseaux sociaux.
• storefront/src/styles/theme-variables.css contient les couleurs, avec une valeur claire et une valeur sombre pour chacune. Changez --primaryColor et --heading-red et toutes les pages suivent. Vérifiez que le texte sur la nouvelle couleur reste lisible dans les deux thèmes.
• storefront/public/brand/ contient les fichiers du logo, un par langue et par thème.

Le nom du restaurant, son slogan et son contact de support sont enregistrés comme des paramètres : le propriétaire peut donc les modifier plus tard depuis la liste All settings by key du tableau de bord (Paramètres, puis Restaurant). Ouvrez aussi messages/legal : la politique de confidentialité et les conditions du téléchargement sont écrites pour un restaurant fictif. Remplacez-les, avant le lancement, par des textes adaptés à Olive Street Kitchen et à son pays.

À vérifier avant de continuer

Le nouveau nom apparaît dans les titres des onglets, dans le pied de page et dans les titres, dans les deux langues, et le texte sur la couleur de votre marque reste lisible dans les deux thèmes (la documentation demande un rapport de contraste de 4,5 pour 1).

Ce qui se passe le plus souvent de travers

Une couleur modifiée dans un seul thème, ou un texte anglais réécrit sans la ligne correspondante dans ar.json.

Étape 4 : Ajouter les cuisines, les horaires et les frais

Les règles de livraison sont des données, pas du code. Dans le tableau de bord, ouvrez Paramètres puis l’onglet Restaurant. Pour chaque cuisine, vous renseignez l’adresse, les horaires d’ouverture et le fuseau horaire, le temps de préparation, les codes postaux desservis et un point sur la carte. La démonstration compte quatre cuisines. Olive Street Kitchen en garde deux, les modifie pour en faire les cuisines de la vieille ville et de la gare, puis désactive les autres.

Le même onglet contient les frais de livraison et de retrait, ainsi que la commande minimum. La démonstration démarre avec des frais de livraison de $2.99, un retrait gratuit et un minimum de $10.00 pour la livraison : considérez ces valeurs comme des exemples à remplacer par vos propres chiffres. Regardez aussi l’horloge de service. Le jeu de données initial démarre sur l’horloge Demo, qui garde toutes les cuisines ouvertes à 20:55 pour que vous puissiez tester à toute heure. Passez-la sur Real avant le lancement, sinon on dira aux clients que vous êtes ouvert à 3 heures du matin.

À vérifier avant de continuer

Utilisez deux fois la recherche par code postal de la page des adresses, une fois avec un code postal figurant dans la liste d’une cuisine et une fois avec un code absent de toutes les listes, et lisez les deux réponses.

Ce qui se passe le plus souvent de travers

Le paiement refuse un client en prétendant que la cuisine est fermée ou que l’adresse de livraison est hors zone. La cause est presque toujours dans les données : un code postal manquant, des horaires dans le mauvais fuseau horaire, ou un panier sous le minimum. Corrigez-le dans les paramètres de la cuisine.

Étape 5 : Construire le menu en deux langues

Ouvrez Menu dans le tableau de bord. Chaque plat porte son nom, son texte et sa liste d’ingrédients dans les deux langues, saisis côte à côte. Ajoutez une catégorie, un temps de préparation, des allergènes, des étiquettes de régime et des photos. Les suppléments et les tailles sont des groupes d’options : chaque groupe a ses propres choix, chaque choix peut modifier le prix, et vous définissez combien le client doit et peut en choisir. Le stock facultatif fait refuser par le serveur une commande qu’il ne peut pas honorer.

Pour notre exemple, nous créons d’abord quelques plats clairement fictifs : une assiette d’agneau, un wrap de falafels, une entrée de houmous, une salade d’accompagnement et une limonade. Puis nous configurons un combo avec un choix de plat, d’accompagnement et de boisson. Un client qui choisit une option plus chère ne paie que la différence. Terminez en ouvrant la page Accueil et en choisissant lesquelles des neuf sections afficher, dans quel ordre et avec quels plats populaires.

Regardez le choix proposé pour chaque partie du repas et le prix affiché pour le combo dans son ensemble.

À vérifier avant de continuer

Ouvrez un plat en anglais et en arabe, marquez un plat comme indisponible (il reste visible et l’indique), et commandez le combo avec un accompagnement plus cher pour confirmer que seule la différence s’ajoute.

Ce qui se passe le plus souvent de travers

Un plat qui n’apparaît jamais n’est pas publié ou est archivé. Des photos qui ne se chargent pas renvoient à PUBLIC_MEDIA_URL, que le jeu de données initial écrit dans l’adresse de chaque image : sur un serveur, définissez-la avant le tout premier chargement des données.

Étape 6 : Configurer les paiements en mode test

Sans prestataire de paiement configuré, le paiement propose un paiement de démonstration intégré qui n’utilise pas d’argent réel et marque la commande comme payée. C’est utile pour apprendre le déroulement, et il disparaît dès qu’un vrai prestataire est configuré. Les clients paient sur la page propre à Stripe ou à PayPal : votre site ne voit donc jamais un numéro de carte.

Pour Stripe, mettez une clé secrète de test (elle commence par sk_test_) dans le back-end/.env de l’API, puis ajoutez dans Stripe un endpoint de webhook qui pointe vers votre API suivie de :

/api/payments/webhooks/stripe

Abonnez-le à checkout.session.completed, checkout.session.expired, charge.refunded et charge.dispute.created, copiez son secret de signature dans STRIPE_WEBHOOK_SECRET, puis redémarrez l’API. Pour PayPal, renseignez PAYPAL_CLIENT_ID, PAYPAL_CLIENT_SECRET et PAYPAL_WEBHOOK_ID ; PAYPAL_ENV vaut sandbox par défaut, ce qui ne déplace aucun argent.

Passez ensuite une commande de test et observez-la. Une commande est enregistrée comme non payée, et elle ne compte comme payée qu’une fois que l’API a demandé au prestataire ce qui s’est passé. Si un client abandonne la page de paiement, l’API annule la commande plus tard et restitue le stock et les points de fidélité. Le serveur calcule le prix de chaque commande à partir de son propre menu : un navigateur ne peut donc pas modifier un total.

Regardez le choix de paiement dans le checkout : le client est envoyé vers la page du prestataire, aucun champ de carte n’apparaît donc ici.

À vérifier avant de continuer

Une commande est enregistrée comme non payée, passe à payée après la confirmation du prestataire, puis apparaît dans la file de cuisine comme confirmée.

Ce qui se passe le plus souvent de travers

Une commande payée reste non payée. Vérifiez l’adresse du webhook, le secret de signature dans le .env de l’API, le redémarrage de l’API, et que API_PUBLIC_URL et STOREFRONT_URL sont accessibles depuis le navigateur du client. Le retour du client sur votre site ne paie jamais une commande à lui seul.

Étape 7 : Ajouter le personnel et les rôles

Ouvrez Équipe. Le template propose trois types de comptes. Le propriétaire voit tout, y compris l’équipe et les rôles. Un manager voit tout sauf ces deux éléments. Un compte de cuisine est limité aux commandes d’une seule cuisine, masque les prix et l’e-mail du client, et fait passer les commandes de confirmée à en préparation, puis à prête.

Pour Olive Street Kitchen, créez un compte de cuisine pour chacune des deux cuisines, plus un manager. Les rôles se modifient permission par permission : vous pouvez donc aussi créer un rôle à vous. Supprimez ou modifiez ensuite les comptes de démonstration. Personne ne devrait pouvoir se connecter avec un mot de passe imprimé dans un document.

À vérifier avant de continuer

Le compte de cuisine ne voit que sa propre cuisine, sans prix, et peut faire passer les commandes à prête. Le manager ne voit pas la page Équipe.

Ce qui se passe le plus souvent de travers

Seul le propriétaire détient les permissions d’équipe et de rôles : un manager ne peut donc pas corriger un rôle. Modifiez les rôles permission par permission quand les valeurs par défaut ne conviennent pas.

Étape 8 : Décider si vous voulez les outils d’IA

Les fonctions d’IA sont facultatives, et le restaurant fonctionne sans elles. Avec une clé Google Gemini dans le .env de l’API, trois choses s’activent : un assistant à qui vous pouvez poser des questions sur les commandes, les ventes et le menu, et qui répond à partir de vos propres données, un rédacteur qui prépare la fiche d’un plat à partir d’une consigne ou de photos, et un outil de restylage de photos. Google facture l’usage de Gemini selon ses propres tarifs : consultez donc la page des tarifs de Gemini avant de confier une clé à un propriétaire de restaurant.

Un outil ne coûte rien par photo : la suppression de l’arrière-plan d’une photo de plat s’exécute sur votre propre serveur avec un modèle local et n’a pas besoin de clé. Vous n’avez qu’à ajouter le fichier du modèle. C’est ce qui permet à chaque plat d’apparaître détouré sur sa propre vignette. Si vous ne mettez aucune clé d’IA, ces boutons indiquent qu’ils ne sont pas connectés, et rien d’autre ne casse.

Regardez la photo du plat avant et après le restylage, avec l’original conservé pour comparer.

À vérifier avant de continuer

Posez à l’assistant une question que vous pouvez vérifier dans la vue d’ensemble, par exemple combien de commandes sont arrivées aujourd’hui, et lisez l’avant et l’après de toute modification qu’il propose.

Ce qui se passe le plus souvent de travers

Les fonctions d’IA indiquent qu’elles ne sont pas connectées. Mettez la clé dans le .env de l’API, jamais dans un fichier de front end, et redémarrez l’API.

Étape 9 : Tester toute la commande, sur téléphone et en arabe

Avant de toucher à un domaine, faites la commande de bout en bout. Sur votre téléphone, ouvrez le site, trouvez un plat, ajoutez un combo, choisissez la livraison, saisissez un code postal situé dans la zone d’une cuisine et payez avec la clé de test. Regardez la commande apparaître dans le tableau de bord, faites-la passer par chaque statut et vérifiez que la page de suivi du client se met à jour. Les commandes à retirer sautent l’étape de livraison.

Regardez le sélecteur livraison ou retrait en haut du panier, qui décide si la vérification du code postal s’applique.

Refaites ensuite le parcours en arabe sur /ar. Vérifiez le menu, le panier, le paiement et le tableau de bord dans la mise en page de droite à gauche. Vérifiez aussi une adresse hors de la zone de toutes les cuisines et une commande passée pendant qu’une cuisine est fermée, car ce sont les cas qu’un vrai client rencontrera dès le premier jour.

Regardez la ligne d’état qui indique au client où en est sa commande : c’est la page à actualiser pendant que vous faites avancer la commande dans le tableau de bord.

Regardez la mise en page inversée : les filtres, les vignettes et la navigation changent de côté tandis que les prix gardent les chiffres latins.

Regardez comment la page du plat s’adapte à un écran étroit, avec la quantité et le bouton d’ajout à portée de pouce.

À vérifier avant de continuer

Déroulez votre liste de tests sur un téléphone et sur un ordinateur portable : trouver un plat, passer de la livraison au retrait, appliquer un code promo, payer, et regarder la chronologie se mettre à jour.

Ce qui se passe le plus souvent de travers

Les nouvelles commandes n’apparaissent qu’après un rechargement. Le tableau de bord se connecte à NEXT_PUBLIC_WEBSOCKET_BASE_URL, et l’API n’accepte cette connexion que depuis l’adresse de FRONTEND_URL.

Étape 10 : Mettre en ligne

Mettre en ligne, c’est trois applications sur un hébergeur Node, une base de données, un endroit pour les fichiers envoyés et vos vrais domaines. Le template garde ses décisions dans des fichiers .env : l’essentiel du travail consiste donc à les renseigner correctement :

• Définissez NODE_ENV=production et votre propre JWT_SECRET. Générez un nouveau secret plutôt que de réutiliser celui de l’exemple. En production, l’API ne démarre pas sans CORS_ORIGIN, qui liste les adresses du site et du tableau de bord, séparées par des virgules.
• Définissez FRONTEND_URL (le tableau de bord, pour les notifications de commandes en direct), STOREFRONT_URL (où les paiements et les réinitialisations de mot de passe renvoient le client) et API_PUBLIC_URL (où Stripe et PayPal reviennent en premier).
• Choisissez la base de données : SQLite sur un disque persistant, ou une base MySQL vide dont la connexion est définie dans .env, avec le chargement des données ou la création des tables exécuté avant le premier démarrage.
• Dirigez les fichiers envoyés vers un stockage persistant : un dossier local sur un disque qui persiste, ou un bucket (renseignez les cinq variables du bucket).
• Dans les deux front ends, définissez NEXT_PUBLIC_API_BASE_URL avec l’adresse de l’API en ligne, /api compris, puis reconstruisez. Ces valeurs sont compilées dans le code que charge le navigateur : un changement ne fait rien tant que la construction suivante n’a pas eu lieu.
• Passez Stripe et PayPal des clés de test aux clés réelles, et ajoutez les webhooks réels.

N’utilisez pas yarn railway:setup comme commande de build d’un restaurant en production. Elle supprime toutes les tables et recharge les données à chaque exécution, ce qui convient à un nouvel environnement et ruine un environnement en service. Passez ensuite une petite commande réelle et remboursez-la depuis le tableau de bord du prestataire lui-même, pour savoir que toute la boucle fonctionne avec de l’argent réel.

À vérifier avant de continuer

Dans une fenêtre privée, passez une commande d’invité et vérifiez que la page de paiement, le retour sur votre site et la notification dans le tableau de bord fonctionnent.

Ce qui se passe le plus souvent de travers

Des pages vides avec un message CORS dans la console signifient que les vraies adresses manquent dans CORS_ORIGIN. Un "Too many attempts" pour tout le monde signifie que TRUST_PROXY n’est pas défini derrière un proxy. Les photos échouent quand NEXT_PUBLIC_MEDIA_HOSTNAME ne nomme pas leur hôte.

Au quotidien

Le lancement n’est que le début du travail. Voici une journée et une semaine ordinaires pour l’équipe d’Olive Street Kitchen, avec des écrans que le tableau de bord possède déjà.

Une matinée dans le tableau de bord

Le manager ouvre la vue d’ensemble. Elle commence par l’argent et le rythme de la journée (chiffre d’affaires, nombre de commandes, panier moyen, commandes en préparation) à côté de ceux d’hier, puis affiche des graphiques du chiffre d’affaires par heure et de la répartition par catégorie, et liste les meilleures ventes et la file de cuisine. Elle se met à jour dès qu’une commande arrive.

Regardez la file de cuisine à côté des chiffres de vente : c’est la partie de l’écran à laquelle l’équipe revient toute la journée.

Vient ensuite la page des commandes. Filtrez par statut, par livraison ou retrait, ou par date, puis ouvrez une commande pour voir ses articles, ses totaux et sa chronologie. Seul le statut suivant logique est proposé, et une annulation demande un motif. Regardez aussi la cloche : elle contient les messages du formulaire de contact.

Pendant le service

Le personnel de cuisine travaille depuis son propre compte, voit sans prix les commandes confirmées de sa cuisine et les fait avancer. Quand quelque chose est épuisé, le manager passe ce plat en indisponible sur sa ligne du menu, ce qui bloque les nouvelles commandes sans supprimer le plat.

Tâches de la semaine

• Rafraîchir la page d’accueil. Réordonnez les neuf sections, modifiez le bandeau d’en-tête dans les deux langues et choisissez les plats populaires. Aucun changement de code n’est nécessaire.

Regardez la liste des sections avec leurs interrupteurs et leurs flèches : c’est ainsi que se règle l’ordre de la page d’accueil publique.

• Revoir le menu. Archivez ce que vous ne cuisinez plus et ajoutez le plat de saison avec les deux langues renseignées.
• Interroger l’assistant. Quels plats se vendent le mieux cette semaine ? Il répond à partir de vos propres données et trace un graphique pour les tendances.
• Sauvegarder les données. La base de données et les fichiers envoyés sont l’entreprise. Activez les instantanés de votre hébergeur et gardez une copie ailleurs.

Un exemple de plan de lancement, semaine par semaine

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

• Semaine 1, les fondations. Lancez la stack avec Docker, faites la visite en tant que propriétaire, manager, cuisine et client, prenez les décisions ci-dessus et commencez la marque et les pages légales.
• Semaine 2, le contenu. Saisissez les deux cuisines, les catégories et les premiers plats dans les deux langues avec photos. Créez un combo et organisez la page d’accueil.
• Semaine 3, l’argent et les personnes. Connectez Stripe et PayPal en mode test, créez les comptes de l’équipe et déroulez tout le parcours de commande sur deux téléphones et en arabe.
• Semaine 4, la mise en ligne. Déployez sur vos domaines, passez aux clés réelles, passez une petite commande réelle et invitez d’abord quelques clients habituels.

Liste de contrôle avant le lancement

• Le nom du restaurant, les coordonnées et les textes légaux sont les vôtres, en anglais et en arabe.
• Chaque plat du menu a les deux langues, ses allergènes et une photo.
• Chaque cuisine a les bons horaires, le bon fuseau horaire, les bons codes postaux, les bons frais et la bonne commande minimum.
• L’horloge de service est sur Real, pas sur l’horloge de démonstration.
• Les comptes de démonstration sont supprimés ou ont de nouveaux mots de passe.
• JWT_SECRET est le vôtre, et NODE_ENV vaut production.
• CORS_ORIGIN, FRONTEND_URL, STOREFRONT_URL et API_PUBLIC_URL utilisent les adresses réelles.
• Les deux front ends ont été reconstruits avec l’adresse réelle de l’API.
• Stripe et PayPal utilisent des clés réelles, et leurs webhooks réels sont bien délivrés.
• La base de données et les fichiers envoyés se trouvent sur un stockage qui survit à un redémarrage, et une sauvegarde existe.
• domain.url dans la configuration de la marque est la vraie adresse.
• Une vraie commande a été passée, suivie et remboursée depuis le tableau de bord du prestataire.

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

Il y a trois façons honnêtes de mettre un restaurant en ligne, et aucune n’est la meilleure pour tout le monde.

Un template comme celui-ci

Vous obtenez le code source du site, du tableau de bord et de l’API : le résultat vous appartient et vous pouvez tout modifier. Le calcul des prix côté serveur, les vérifications de livraison, les statuts de commande et les webhooks de paiement sont déjà résolus. En contrepartie, c’est vous qui hébergez et maintenez, et tout ce que le template n’a pas, comme les confirmations par e-mail, demande du développement.

Développer à partir de zéro

Vous obtenez exactement le produit que vous concevez. Vous construisez et testez aussi chaque règle vous-même : comment un combo est tarifé, comment un webhook confirme un paiement une seule fois, comment le stock est réservé puis libéré. Pour la plupart des restaurants, c’est un long chemin pour arriver là où un template commence.

Une plateforme de commande hébergée

C’est la façon la plus rapide de démarrer, et quelqu’un d’autre gère les serveurs. En contrepartie, il y a des frais récurrents, moins de contrôle sur l’expérience client, et vos données de commande qui vivent sur leur système. Comparez les conditions de chaque plateforme, les frais de paiement et la prise en charge de l’arabe avant de choisir.

Ce que coûte l’exploitation

Le template est un achat unique, à partir de $79 pour le site de commande seul. Le pack Full Stack que nous avons utilisé dans cet exemple coûte $179. Il comprend un support à vie et une licence commerciale.

Faire tourner le restaurant coûte plus cher que le template. Vous payez :

• L’hébergement de l’API, du site et du tableau de bord, et un disque persistant ou une base de données MySQL.
• Le stockage des photos envoyées si vous choisissez un bucket comme Cloudflare R2.
• Les frais du prestataire de paiement. Stripe et PayPal facturent selon leurs propres pages de tarifs, et le template n’y ajoute rien. Voir les tarifs de Stripe.
• Une clé Google Gemini, seulement si vous activez l’assistant d’IA ou les outils photo.
• Votre propre nom de domaine.

Ce qui ne coûte rien : le développement local avec SQLite, le paiement de démonstration, les tuiles de la carte (le template utilise par défaut les styles publics d’OpenFreeMap, qui n’ont pas besoin de clé) et la suppression d’arrière-plan sur votre propre serveur.

Que personnaliser ensuite

• Fidélité. La démonstration donne un point par dollar et retire $5 pour 100 points. Changez ces chiffres dans les Paramètres pour les adapter à vos marges.
• Codes promo. Créez un code avec un pourcentage, décidez s’il s’applique au menu ou à toute la commande, et s’il se cumule avec la fidélité.
• La page d’accueil. Réordonnez les neuf sections pour suivre une campagne, et réécrivez le bandeau d’en-tête dans les deux langues sans changer le code.

Erreurs courantes

Modifier le .env d’un front end en s’attendant à ce que cela s’applique

Chaque valeur NEXT_PUBLIC_* est compilée dans la page au moment de la construction. Si le site appelle encore l’ancienne API après la modification du fichier, reconstruisez-le. Avec Docker Compose, placez la valeur dans le .env à côté de docker-compose.yml et lancez docker compose up --build.

Laisser l’horloge de démonstration activée

Le jeu de données initial garde toutes les cuisines ouvertes à la même heure fixe pour que vous puissiez tester à minuit. Si vous oubliez de passer à l’horloge réelle, les clients peuvent commander auprès d’une cuisine fermée.

Oublier CORS sur les domaines réels

Si les pages en ligne restent vides et que la console du navigateur mentionne CORS, l’API ne connaît pas encore votre domaine. Ajoutez les deux adresses de front end à CORS_ORIGIN et redémarrez l’API.

Supposer que des fonctions non incluses le sont

Le template n’envoie pas d’e-mails de confirmation de commande, ne prend pas de commandes pour plus tard, n’ajoute ni pourboires ni lignes de taxes et ne gère pas le paiement à la livraison. L’e-mail de réinitialisation de mot de passe passe par Resend si vous le configurez. Si Olive Street Kitchen a besoin de l’une des autres, prévoyez du temps de développement.

FAQ

Comment créer un système de commande en ligne pour un restaurant avec Next.js ?

Partez d’un template qui inclut déjà les parties difficiles, puis configurez-le. Il vous faut un site pour les clients, un tableau de bord pour le personnel et une API qui calcule le prix des commandes et dialogue avec un prestataire de paiement. Ce guide déroule les étapes avec Food Studio : le lancer, l’habiller à votre marque, saisir les cuisines et le menu, tester les paiements, ajouter le personnel et déployer.

Ai-je besoin d’un back-end ?

Oui. Les prix, le stock, les statuts de commande et la confirmation du paiement doivent être décidés sur un serveur, pas dans le navigateur. Le template fournit pour cela une API NestJS avec TypeORM, et le site et le tableau de bord lisent tout depuis elle.

Puis-je l’utiliser pour des projets clients ?

Oui. Il est livré avec une licence commerciale pour un nombre illimité de projets, ce qui couvre les agences qui réalisent des sites de restaurants. Lisez la licence dans la documentation pour connaître les conditions exactes.

Prend-il en charge l’arabe et le RTL ?

Oui. Le site, le tableau de bord et l’API fonctionnent en anglais et en arabe. Les pages arabes s’inversent de droite à gauche, et les plats sont enregistrés avec un nom et une description dans les deux langues.

Puis-je gérer plusieurs cuisines ?

Oui. Chaque cuisine a ses propres horaires, son fuseau horaire, ses codes postaux de livraison et ses comptes de personnel. Le site indique au client si une cuisine livre à son code postal, si elle est fermée, ou si une autre cuisine peut prendre la commande.

Quels prestataires de paiement fonctionnent ?

Stripe Checkout et PayPal. Les deux envoient le client sur leur propre page et confirment la commande par un webhook signé. Vous utilisez vos propres comptes, et leurs frais ne sont pas inclus dans le prix du template.

Ai-je besoin de Docker ?

Non, mais c’est le démarrage le plus rapide. Sans Docker, il vous faut Node.js 24 ou plus récent et Yarn via Corepack, et vous lancez chaque application avec yarn dev. L’API n’a pas besoin d’un serveur de base de données, car elle utilise SQLite par défaut.

Les clients peuvent-ils commander sans compte ?

Oui. Les clients peuvent payer avec un nom et un e-mail, et suivre la commande grâce à son numéro et à cet e-mail. Un compte ajoute des points de fidélité, des plats et des adresses enregistrés, et un bouton pour recommander.

Envoie-t-il des e-mails de confirmation de commande ?

Non. Le template n’envoie pas d’e-mails de confirmation de commande. Les clients voient la commande sur les pages de confirmation et de suivi, et le tableau de bord prévient l’équipe. L’e-mail de réinitialisation de mot de passe fonctionne via Resend une fois ses clés ajoutées.

Puis-je utiliser MySQL à la place de SQLite ?

Oui, par un simple changement de configuration. Créez une base de données vide, définissez le pilote et la connexion dans le .env de l’API, puis exécutez le chargement des données ou la création des tables avant le premier démarrage en production.

Essayez-le vous-même

Passez commande sur le site de commande de démonstration, puis ouvrez la démo du tableau de bord du personnel pour voir l’autre côté. Lisez la documentation de Food Studio pour chaque réglage de ce guide, ou consultez la page du produit pour les packs. D’autres options figurent dans la catégorie des templates pour restaurants. Food Studio fait aussi partie des dix templates du Next.js Templates Bundle.