Comment créer une boutique en ligne avec panneau d’admin Next.js

À la fin de ce guide, vous saurez comment créer une boutique en ligne avec un panneau d’administration, grâce à Next.js, NestJS et le template e-commerce d’Aniq UI. Vous aurez une vitrine (storefront), un poste de commandes pour votre équipe et une API qui gère le catalogue, les clients et les commandes.

Nous suivons une boutique d’exemple, du premier plan au jour du lancement. Chaque étape nomme l’écran ou le réglage concerné et reprend les commandes et les chemins de fichiers exacts de la documentation. Le même parcours convient à un fondateur qui lance sa boutique comme à une agence qui en construit une pour un client.

Le cahier des charges

Cedar & Cloth est une petite boutique qui vend des chemises en lin et des sacs en toile. La propriétaire la gère avec deux personnes qui préparent les commandes. Voici ce dont la boutique a besoin :

• Un catalogue d’environ trente produits, chacun avec des tailles et des couleurs, rédigé en anglais et en arabe.
• Un paiement en tant qu’invité, pour qu’un nouveau visiteur puisse acheter sans créer de compte et suivre ensuite sa commande.
• Un paiement par carte, ou à la livraison pour les clients qui le préfèrent.
• La livraison gratuite au-dessus d’un certain montant de commande, et un tarif forfaitaire en dessous.
• Un poste de commandes où la propriétaire a le contrôle total et où les préparateurs peuvent seulement consulter les commandes.
• Une page d’accueil que la propriétaire peut réorganiser sans toucher au code.
• Des photos de produits propres sur fond uni, réalisées à partir de photos prises au téléphone.
• Un moyen de voir d’où viennent les visiteurs, avec Google Analytics.

Comment le template répond au cahier des charges

Besoin	Où ça se trouve	Ce que vous utilisez
Catalogue bilingue avec variantes	Panneau d’administration et API	Les écrans Products et Categories, avec des variantes de taille et de couleur
Paiement invité et suivi	Storefront	La page de paiement et Track Order, qui demande le numéro de commande et l’e-mail
Carte ou paiement à la livraison	Storefront et API	Stripe pour les cartes, le paiement à la livraison étant sélectionné par défaut
Règle de livraison	Storefront et API	Un fichier de configuration de la livraison et le service des commandes, à garder synchronisés
Poste de commandes et autorisations	Panneau d’administration	Orders, Admin Management et Admin Roles
Page d’accueil modifiable	Panneau d’administration	L’écran Home Page, section par section
Photos de produits	Panneau d’administration	Le studio IA du formulaire produit et la suppression d’arrière-plan
Analytics des visiteurs	Storefront	Les identifiants de balises, collés dans le fichier d’environnement du storefront

Avant de commencer : les décisions à prendre

Une boutique touche à l’argent, aux clients et aux obligations légales, donc mieux vaut prendre quelques décisions avant d’écrire la moindre ligne de configuration.

Que vendez-vous exactement ?

Comptez vos produits et, pour chacun, décidez quelles options l’acheteur choisit : taille, couleur, ou aucune. Les variantes ont leur propre SKU, leur propre ajustement de prix et leur propre stock, donc la forme de votre catalogue détermine la quantité de saisie à prévoir. Cedar & Cloth vend des chemises en plusieurs tailles et couleurs, et des sacs en une seule taille.

Dans quelles langues vendrez-vous ?

L’anglais et l’arabe sont fournis, avec une mise en page de droite à gauche. Les produits et les catégories portent un nom et une description dans les deux langues. Une troisième langue est possible pour l’interface, mais elle demande des modifications dans plusieurs fichiers.

Comment les clients paieront-ils ?

Les clients peuvent payer par carte (Stripe) ou choisir le paiement à la livraison, et PayPal ne fait pas partie du paiement. Stripe facture en dollars américains. Si vous vendez dans une autre devise, c’est une décision à régler avant le lancement, pas après.

Et la livraison et les taxes ?

Le template fournit une seule règle de livraison : gratuite à partir d’un certain montant de commande, tarif forfaitaire en dessous. Il n’applique aucune taxe. Si votre activité doit en facturer, prévoyez-le dans le code ou dans la façon dont vous fixez vos prix.

Invités, comptes, ou les deux ?

Les deux fonctionnent. Les invités paient avec une adresse e-mail et suivent leurs commandes avec le numéro et l’e-mail. Les clients avec un compte disposent aussi d’adresses enregistrées, d’un historique de commandes et d’une liste de souhaits.

Qui s’occupe des e-mails ?

Le template n’en envoie aucun : ni confirmation, ni avis d’expédition, ni réinitialisation de mot de passe. Choisissez tôt un fournisseur d’e-mail, car les clients attendent au moins une confirmation de commande.

Quels outils d’IA, le cas échéant ?

Chacun a besoin de sa propre clé, et certains ont besoin du bucket de médias. Décidez lesquels valent la peine d’être activés pour le lancement. Une boutique qui veut seulement des photos de produits propres peut activer la suppression d’arrière-plan et rien d’autre.

Pas à pas

Étape 1 : Choisir le package

Le template propose quatre packages : Full Stack (storefront, administration et API), Storefront seul, Admin Dashboard seul, et Backend API seul. Chacun des deux frontends peut fonctionner seul, sur une boutique d’exemple intégrée au navigateur. C’est utile pour une revue du design, mais les vraies commandes, les paiements et les fonctions d’IA ont besoin de l’API NestJS.

Cedar & Cloth prend le package Full Stack. La licence commerciale couvre un nombre illimité de projets, y compris les boutiques que vous construisez et remettez à un client.

La page My templates liste un ZIP pour chaque package, choisissez donc celui que vous avez acheté.

Ce qu’il faut vérifier : le ZIP Full Stack s’extrait dans e-commerce-1, qui contient admin-dashboard, back-end, storefront et docker-compose.yml. Les packages à une seule application s’extraient dans leur propre dossier, avec un Dockerfile, un package.json et un .env.example.

Étape 2 : Le lancer en local avec Docker

Téléchargez le ZIP depuis My templates, décompressez-le et ouvrez un terminal dans le dossier e-commerce-1. Démarrez Docker, puis lancez :

docker compose up --build

Docker construit trois images au premier lancement et charge une boutique de démonstration dans la base de données, prévoyez donc quelques minutes. Le storefront s’ouvre sur localhost:3030, l’administration sur localhost:3031 et l’API sur localhost:8000. Un port occupé peut être changé avec SITE_PORT, ADMIN_PORT ou API_PORT dans un fichier .env placé à côté de docker-compose.yml.

Connectez-vous à l’administration en Super Admin (admin@example.com, mot de passe Admin@123) et au storefront en client de démonstration (john.doe@example.com, mot de passe password123). Un compte d’équipe en lecture seule, john.smith@admin.com avec admin123, montre ce que voit le rôle Viewer. Passez une commande de test en tant que client, puis retrouvez-la dans l’administration.

Une remarque honnête : sur la vue d’ensemble de l’administration, plusieurs cartes (revenus, ventes, objectif, visiteurs, conversion et la carte) affichent des chiffres factices tant que vous n’avez pas branché vos propres données. Vérifiez quelles cartes sont reliées à des données réelles avant de vous y fier.

Cette capture montre un terminal ouvert dans le dossier extrait, c’est-à-dire là où chaque commande doit être lancée.

Repérez le moment où l’API réussit son contrôle d’état, car les deux frontends ne démarrent qu’après elle.

La voie Node.js commence par l’API, une fois que le seed a créé la base de données et la boutique de démonstration.

Le panneau d’administration tourne dans son propre terminal sur le port 3031, à côté du storefront sur le 3030.

La capture ci-dessus est la vue d’ensemble de l’administration que vous devriez voir après vous être connecté en Super Admin.

Ce qu’il faut vérifier : ouvrez localhost:8000/api/health, qui doit répondre avec un statut ok. Ajoutez ensuite un produit au panier en client de démonstration, payez en invité et retrouvez la commande dans l’administration.

Ce qui se passe mal le plus souvent :

• Docker n’est pas lancé, ou le port 3030, 3031 ou 8000 est pris. Libérez-le, ou réglez SITE_PORT, ADMIN_PORT ou API_PORT sur un numéro libre.
• Le premier démarrage semble bloqué. Il charge la boutique de démonstration, et les frontends ne démarrent que lorsque l’API est en bonne santé.
• Un avis « Sample data » s’affiche. Le frontend a été construit sans adresse d’API et fonctionne sur sa propre boutique d’exemple.
• Yarn indique la version 1.22. Lancez corepack enable et réinstallez.

Étape 3 : En faire Cedar & Cloth

L’identité de marque se trouve dans des fichiers, et le storefront comme l’administration gardent chacun leur propre copie. Dans le storefront, src/config/brand.config.ts contient le nom de la boutique (fourni sous forme de logotype textuel), le nom de l’onglet du navigateur, les coordonnées et les liens sociaux, chacun avec des valeurs en anglais et en arabe. Réglez NEXT_PUBLIC_SITE_URL sur votre vrai domaine, car les liens canoniques, le sitemap et les cartes de partage l’utilisent.

Les textes fournis décrivent une boutique de mode masculine. Trois endroits portent ces textes : les blocs de texte de brand.config.ts, le dossier messages/home/ pour la page d’accueil et messages/seo/ pour les titres de pages. Cedar & Cloth vend aussi de la mode masculine, elle a donc moins à modifier que la plupart des boutiques.

Chaque application garde ses couleurs dans src/styles/theme-variables.css, sous forme de variables CSS, avec un bloc pour le thème clair et un pour le thème sombre. La couleur d’accent est --primaryColor. Le storefront charge Plus Jakarta Sans pour le texte latin et deux polices arabes. L’administration a son propre fichier de marque et utilise la pile de polices du système.

Ce qu’il faut vérifier : reconstruisez, puis cherchez l’ancien nom dans l’onglet du navigateur, le pied de page, l’aperçu de partage et les pages en arabe. Remplacez les coordonnées factices, car elles sont fournies comme exemples.

Ce qui se passe mal le plus souvent : le pied de page n’affiche aucune icône sociale, car les liens sont fournis vides et seuls ceux qui sont remplis apparaissent. Autre cas : une image de partage qui montre encore la photo principale du template. Faites pointer meta.ogImage vers votre propre image.

Étape 4 : Ajouter des catégories et des produits

Commencez par les catégories : un nom et une description dans les deux langues, plus une image, un slug, une position de tri et un interrupteur activé ou désactivé. Elles forment un seul niveau. Ajoutez ensuite les produits. Un produit comprend :

• Un nom et des descriptions dans les deux langues (seul le nom anglais est obligatoire), un slug, un SKU et une catégorie.
• Un prix, un prix barré facultatif, un prix de revient et une quantité en stock.
• Jusqu’à 12 images et vidéos dans l’ordre voulu, dont une marquée comme principale, chacune avec un texte alternatif.
• Des variantes comme Size avec M, ou Colour avec son code hexadécimal. Chaque variante a son propre SKU, son ajustement de prix et son stock.
• Des indicateurs actif, mis en avant et meilleure vente, et des étiquettes libres.

Les envois vont vers un bucket Cloudflare R2, ou un autre stockage compatible S3, et échouent avec une erreur 503 tant que vous n’avez pas renseigné les cinq variables R2_* de back-end/.env. Le catalogue de démonstration s’affiche à partir de fichiers fournis, vous pouvez donc construire tout le parcours avant de configurer un bucket.

Travaillez dans cet ordre, pour que rien ne pointe vers quelque chose qui n’existe pas encore :

1. Créez d’abord les catégories, car chaque produit en a besoin d’une.
2. Ajoutez un produit complet, avec photos, variantes et les deux langues, avant d’ajouter les autres.
3. Ouvrez-le sur le storefront en anglais et en arabe et vérifiez la galerie, le sélecteur de variantes et le prix.
4. Seulement ensuite, répétez l’opération pour les produits restants.

Regardez la liste à plat des catégories avec leur ordre et leur interrupteur d’activation : l’ordre défini ici détermine la rangée de catégories de la page d’accueil.

La vue compacte affiche plus de lignes à l’écran, ce qui aide quand vous contrôlez le stock et les prix de nombreux produits.

Ce qu’il faut vérifier : les produits supprimés ont leur propre liste, vérifiez donc où atterrit un produit après sa suppression. Les SKU des variantes doivent être uniques, adoptez donc dès le départ une convention de nommage claire.

Ce qui se passe mal le plus souvent : les envois échouent avec une erreur 503, parce que les variables du bucket ne sont pas définies. Ou les images se chargent en taille réelle, parce que les frontends ne connaissent pas l’hôte public de votre bucket. Réglez NEXT_PUBLIC_MEDIA_HOSTNAME sur cet hôte, sans https://, et reconstruisez.

Étape 5 : Organiser la page d’accueil

L’écran Home Page de l’administration décide, section par section, de ce que les clients voient sur la page d’accueil du storefront. Les catégories n’ont besoin que d’un ordre. Les autres sections acceptent un nombre limité de produits ou de textes : jusqu’à 3 piliers de style, 2 panneaux éditoriaux, 6 nouveautés, 8 meilleures ventes, 6 produits en vedette et 5 diapositives dans le slider de fin. Si New drops est vide, la section affiche les produits les plus récents. Modifier une section demande l’autorisation products.edit.

Ce qu’il faut vérifier : ajoutez un produit qui utilise toutes les sections, puis ouvrez la page d’accueil du storefront et confirmez que chaque section affiche ce que vous avez choisi. Videz la section New drops et confirmez qu’elle se rabat sur les produits les plus récents.

Ce qui se passe mal le plus souvent : un changement n’apparaît pas parce qu’il vous manque l’autorisation products.edit, ou parce que le storefront est sur sa boutique d’exemple et ne lit pas l’API.

Étape 6 : Régler la livraison, les paiements et le circuit des commandes

Le paiement propose la carte via Stripe et le paiement à la livraison. Le paiement à la livraison est sélectionné par défaut, et l’API calcule toujours le prix d’une commande à partir de son propre catalogue, jamais à partir des chiffres envoyés par le navigateur. Il n’y a pas d’option PayPal.

La règle de livraison est fournie ainsi : gratuite à partir de $75, et $9.99 en dessous, sans taxe. Elle est écrite à deux endroits, storefront/src/config/shipping.ts et back-end/src/modules/orders/orders.service.ts. Modifiez les deux dans un même changement, sinon le panier et le montant débité ne concorderont pas.

Pour accepter les cartes, utilisez d’abord les clés de test Stripe :

1. Ajoutez STRIPE_SECRET_KEY et STRIPE_WEBHOOK_SECRET à back-end/.env.
2. Mettez NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY dans le .env du storefront et reconstruisez.
3. Dans le tableau de bord Stripe, créez un endpoint de webhook qui pointe vers l’adresse de votre API suivie de /api/payments/webhook, et faites-lui écouter deux événements : payment_intent.succeeded et payment_intent.payment_failed.

Une commande réglée par carte reste en attente jusqu’à ce que Stripe appelle ce webhook, puis elle passe à payée et confirmée. Pour les tests en local, la CLI Stripe peut relayer les événements vers http://localhost:8000/api/payments/webhook. Dans l’administration, une commande avance d’une étape à la fois : pending, confirmed, processing, shipped, delivered, ou cancelled avant sa clôture. Ajoutez le numéro de suivi à l’expédition et téléchargez n’importe quelle commande au format CSV.

Ce qu’il faut vérifier : passez une commande avec paiement à la livraison et une commande par carte avec les clés de test Stripe. La première doit être confirmée et non payée. La seconde doit rester en attente jusqu’à l’arrivée du webhook, puis devenir payée et confirmée. Faites échouer une carte volontairement et confirmez que la commande est marquée comme échouée.

Ce qui se passe mal le plus souvent :

• L’option carte est absente du paiement. La clé publique est vide ou n’est pas une vraie clé de test ou de production, ce qui ne laisse que le paiement à la livraison.
• Les commandes par carte restent en attente. L’endpoint du webhook ou son secret de signature est incorrect.
• Le storefront affiche toujours l’ancienne clé publique. Elle est compilée dans le code, reconstruisez donc après l’avoir changée.

Étape 7 : Ajouter l’équipe et définir ses autorisations

Les comptes de l’équipe se trouvent dans Admin Management, et leurs autorisations dans Admin Roles. Le seed vous donne un Super Admin avec toutes les autorisations et un rôle Viewer avec toutes les autorisations de lecture, hormis l’assistant IA. Les rôles Admin, Manager et Editor existent mais démarrent sans rien, cochez donc leurs autorisations avant de les attribuer à quelqu’un.

Cedar & Cloth garde la propriétaire en Super Admin. Pour les deux préparateurs, elle accorde l’accès en lecture aux commandes, plus l’autorisation de modification nécessaire pour faire avancer une commande. Tout le reste leur est masqué, car la barre latérale et l’API vérifient les mêmes noms d’autorisations.

Ce qu’il faut vérifier : connectez-vous avec le compte Viewer et confirmez qu’il peut voir les listes mais pas les modifier. Connectez-vous ensuite avec le rôle de préparateur que vous avez créé et confirmez que faire avancer une commande fonctionne.

Ce qui se passe mal le plus souvent : un nouveau membre de l’équipe ne voit presque rien, parce qu’aucune autorisation n’est cochée pour son rôle. Les changements d’autorisations parviennent aux membres connectés par une connexion en direct, ils n’ont donc pas besoin de se déconnecter.

Étape 8 : Ajouter les outils d’IA voulus

Chaque fonction d’IA ne s’active que lorsque sa clé est dans back-end/.env, et une clé qui porte encore sa valeur d’exemple compte comme non définie.

• Assistant d’administration : demande une clé Google Gemini. Il répond aux questions sur la boutique, retrouve des commandes, modifie les produits et le stock, et dessine des graphiques de ventes, toujours dans les limites des autorisations de l’administrateur connecté.
• Studio produit IA : dans le formulaire produit. Son mode assistant demande une clé Gemini et le bucket de médias. Son mode Animate demande une clé et un secret Higgsfield.
• Cabine d’essayage : permet aux clients de voir un produit porté par un mannequin ou sur leur propre photo. Elle demande une clé Gemini et le bucket.
• Suppression d’arrière-plan : demande un fichier de modèle sur votre propre serveur et le bucket, mais aucune clé, et ne coûte rien par image.

Cedar & Cloth n’active que la suppression d’arrière-plan, pour que les photos prises au téléphone deviennent de propres photos de catalogue. L’image Docker laisse le modèle de côté, sauf si vous le demandez à la construction. Les frais des fournisseurs pour les fonctions à clé sont à votre charge.

Ce qu’il faut vérifier : ouvrez la page AI Assistant et demandez un résumé des ventes. Confirmez que la réponse arrive avec un graphique tiré de vos propres données. Pour la suppression d’arrière-plan, ouvrez une photo de produit et confirmez que le bouton Remove background apparaît.

Ce qui se passe mal le plus souvent : une fonction se déclare désactivée. Soit sa clé est absente ou porte encore la valeur d’exemple, soit elle a aussi besoin du bucket de médias. Le studio, la cabine d’essayage et la suppression d’arrière-plan ont tous besoin du bucket. Rappelez-vous aussi que l’assistant et le studio ne sont pas disponibles sur la boutique d’exemple.

Étape 9 : Brancher les analytics

Six réseaux publicitaires et d’analytics sont intégrés au storefront. Collez un identifiant dans storefront/.env et reconstruisez. Un identifiant vide ne charge aucun script. Les variables sont NEXT_PUBLIC_GTM_ID, NEXT_PUBLIC_GA4_MEASUREMENT_ID, NEXT_PUBLIC_META_PIXEL_ID, NEXT_PUBLIC_TIKTOK_PIXEL_ID, NEXT_PUBLIC_SNAPCHAT_PIXEL_ID et NEXT_PUBLIC_PINTEREST_TAG_ID.

Si vous n’en renseignez qu’un, choisissez Google Tag Manager, qui peut charger les autres lui-même. Si GA4 tourne déjà dans votre conteneur Tag Manager, laissez la variable GA4 vide, sinon chaque session est comptée deux fois. Le storefront remonte les pages vues, les vues de produit, les ajouts au panier, le début de paiement, l’achat, la recherche et l’inscription. Réglez NEXT_PUBLIC_ANALYTICS_DEBUG=true pour afficher chaque événement dans la console du navigateur pendant les tests.

Les balises se chargent dès qu’une page se charge. Si vous vendez dans l’UE ou au Royaume-Uni, affichez une bannière de consentement avant qu’elles ne s’exécutent.

Ce qu’il faut vérifier : activez la journalisation de débogage, parcourez un achat et regardez les événements apparaître dans la console du navigateur, dans l’ordre : vue de produit, ajout au panier, début de paiement, achat. Confirmez ensuite les mêmes événements dans l’aperçu de Tag Manager ou dans votre outil d’analytics.

Ce qui se passe mal le plus souvent : la modification d’un identifiant n’a aucun effet, car les identifiants sont compilés et demandent une reconstruction. Ou l’événement d’achat part sans la bonne devise. Réglez NEXT_PUBLIC_ANALYTICS_CURRENCY si vous ne vendez pas en dollars américains.

Étape 10 : Passer en production

Comblez les manques que laisse le template, puis déployez :

• Il n’envoie aucun e-mail : ni confirmation de commande, ni avis d’expédition, ni réinitialisation de mot de passe. Branchez un fournisseur d’e-mail dans le hook forgotPassword de back-end/src/modules/customer-auth/customer-auth.controller.ts et pour les commandes.
• Le formulaire de contact comme l’inscription à la newsletter accusent réception au visiteur mais ne livrent rien, et aucune page de conditions ni de confidentialité n’est fournie avec le template. Branchez les formulaires et rédigez les pages.

Configurez ensuite l’API dans back-end/.env : un nouveau JWT_SECRET (généré avec node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"), NODE_ENV=production, CORS_ORIGIN listant les adresses du storefront et de l’administration, et FRONTEND_URL réglé sur l’adresse de l’administration. Construisez l’API, lancez yarn db:sync:prod une fois pour créer les tables, puis démarrez-la. Dans chaque frontend, réglez NEXT_PUBLIC_API_BASE_URL avec /api à la fin et reconstruisez. Réglez NEXT_PUBLIC_STOREFRONT_URL dans l’administration pour que son lien Go to storefront fonctionne.

N’utilisez pas yarn railway:setup pour une boutique en production : il supprime toutes les tables à chaque exécution. Changez les mots de passe de démonstration publiés, ou partez de tables vides.

Ce qu’il faut vérifier après la mise en production : passez une vraie petite commande sur votre domaine, regardez-la apparaître dans l’administration avec une notification, faites-la passer par ses statuts, puis suivez-la en invité avec le numéro de commande et l’e-mail. Confirmez que la cloche de notifications fonctionne en direct, ce qui signifie que l’adresse de l’administration correspond à FRONTEND_URL.

Ce qui se passe mal le plus souvent :

• Les navigateurs sont bloqués par l’API. CORS_ORIGIN doit lister les deux frontends exactement comme le navigateur les affiche.
• Tout le monde reçoit « Too many attempts » derrière un proxy. Chacune de ces routes (connexion, inscription, réinitialisation du mot de passe, suivi invité) accepte dix requêtes par minute depuis une même adresse. Réglez TRUST_PROXY sur le nombre de proxys placés devant.
• La réinitialisation du mot de passe ne mène nulle part. En production, le jeton de réinitialisation n’est pas livré tant que vous n’avez pas branché un fournisseur d’e-mail.

Au quotidien

Une fois la boutique en ligne, la propriétaire et les préparateurs utilisent une courte liste d’écrans de l’administration.

Commencer la journée par la vue d’ensemble

La vue d’ensemble est en haut de la barre latérale et montre la boutique d’un coup d’œil. Rappelez-vous que plusieurs cartes affichent des chiffres factices tant que vous n’avez pas branché de vraies données, gardez donc une source distincte et fiable pour les revenus d’ici là.

Regardez les dernières commandes et la cloche de la barre supérieure, c’est là que la nouvelle activité apparaît en premier.

Faire avancer les commandes

Filtrez la liste par statut de commande ou par statut de paiement ; les commandes les plus récentes viennent en premier. Ouvrez une commande, vérifiez les articles, les totaux et les adresses, ajoutez le numéro de suivi à l’expédition et faites-la avancer d’une étape. N’annulez qu’avant la clôture de la commande. Le statut de paiement est fixé par le paiement, jamais à la main.

La progression de préparation de chaque ligne montre où en est une commande, ce qui permet aux préparateurs de repérer ce qui attend encore.

Aider un client

L’écran des clients liste les clients de la boutique, et les clients supprimés ont leur propre liste. Un client qui n’arrive pas à suivre une commande a besoin du numéro de commande exact et de l’e-mail utilisé au paiement, car le suivi demande les deux.

Utilisez cette liste pour retrouver un client par son compte et ouvrir sa fiche quand il vous écrit.

Garder le storefront à jour

Réorganisez les sections de la page d’accueil quand vous lancez un nouveau produit, ajoutez une offre ou voulez mettre une meilleure vente en avant. Ces modifications se font dans l’administration, elles ne demandent donc aucun changement de code.

Les réglages sont des valeurs enregistrées

L’onglet App settings contient des paires clé et valeur, notamment pour le paiement, l’e-mail et des réglages généraux. Le storefront et l’API fournis ne les lisent pas encore, donc en modifier un ne change rien tant que votre propre code ne le fait pas.

Un exemple de plan de lancement, semaine par semaine

Ce calendrier est un exemple pour Cedar & Cloth, pas une promesse sur la durée de votre lancement.

• Semaine 1, comprendre. Lancez la stack, passez une commande de test et arrêtez la liste des décisions.
• Semaine 2, marque et catalogue. Changez la marque des deux applications, réécrivez les textes fournis et ajoutez des catégories et un produit complet.
• Semaine 3, le reste de la boutique. Ajoutez les autres produits, organisez la page d’accueil et mettez en place le stockage en bucket et les photos.
• Semaine 4, argent et équipe. Réglez la règle de livraison, branchez Stripe en mode test, créez les rôles des préparateurs et faites passer des commandes par tous les statuts.
• Semaine 5, production. Mettez en place l’hébergement, les fichiers d’environnement et les tables. Branchez un fournisseur d’e-mail, ajoutez les balises de suivi et rédigez les pages de conditions et de confidentialité manquantes.
• Semaine 6, lancement en douceur. Commencez avec un petit public, puis passez aux clés Stripe de production quand vous êtes sûr de vous.

Liste de contrôle avant le lancement

• Nom de la boutique, logos, icônes, couleurs et polices remplacés dans les deux applications.
• Textes de mode masculine fournis réécrits dans le fichier de marque, les messages d’accueil et les messages SEO.
• Coordonnées, liens sociaux et images de partage remplacés.
• Catégories et produits complets dans les deux langues, avec variantes et photos.
• Règle de livraison modifiée dans les deux fichiers, si vous l’avez modifiée.
• Clés Stripe de production et webhook de production en place, après un essai complet en mode test.
• Rôles cochés pour chaque membre de l’équipe, et mots de passe de démonstration changés.
• JWT_SECRET, CORS_ORIGIN, FRONTEND_URL et les deux adresses d’API des frontends réglés pour la production.
• NEXT_PUBLIC_SITE_URL réglé sur le vrai domaine.
• Un fournisseur d’e-mail branché, et le formulaire de contact et celui de la newsletter reliés.
• Pages de conditions et de confidentialité rédigées.
• Identifiants de suivi collés, et bannière de consentement ajoutée si vous vendez dans l’UE ou au Royaume-Uni.
• Préremplissage du paiement de démonstration laissé désactivé.
• Sauvegardes programmées pour la base de données et le bucket de médias.

Template, développement from scratch ou constructeur de boutique hébergé

Un constructeur de boutique hébergé

Vous pouvez vendre rapidement, avec l’hébergement, le paiement et les mises à jour pris en charge pour vous. Vous payez des frais récurrents, vous travaillez dans le cadre du design et des règles de la plateforme, et vos données restent sur leur système. C’est adapté à une boutique qui veut vendre, pas gérer un logiciel.

Tout construire from scratch

Vous obtenez exactement ce que vous concevez. Mais vous devez aussi construire un catalogue avec variantes, des paniers, le paiement invité, le suivi des commandes, les paiements et les webhooks, des comptes pour les clients et l’équipe, des autorisations, une administration, deux langues et une API avant la première commande. Et vous maintenez tout cela.

Partir d’un template

Vous possédez le code, vous hébergez la stack et vous pouvez tout modifier. Le storefront, l’administration et l’API sont déjà reliés, vous consacrez donc votre temps aux produits et à la marque. En échange, vous acceptez le travail que liste ce guide : e-mail, règles fiscales, pages de conditions, hébergement et mises à jour. C’est adapté aux fondateurs qui veulent garder le contrôle et aux agences qui construisent des boutiques pour leurs clients.

Ce que coûte l’exploitation

Les packages du template démarrent à partir de $79, et le package Full Stack utilisé par Cedar & Cloth coûte $179. Il inclut une licence commerciale et un support à vie. Au-delà, vous payez ce que vous activez :

• L’hébergement du storefront, de l’administration et de l’API, et une base de données si vous dépassez SQLite.
• Les frais de traitement de Stripe, indiqués sur la page des tarifs de Stripe. Le paiement à la livraison n’a besoin d’aucun processeur de paiement.
• Un bucket comme Cloudflare R2 pour les images de produits.
• Une clé Google Gemini pour l’assistant, le studio ou la cabine d’essayage, facturée par Google, et un compte Higgsfield pour la vidéo.
• Un fournisseur d’e-mail et un nom de domaine.

Ce qui est gratuit : SQLite pour le travail en local, la boutique de démonstration, le paiement à la livraison et la suppression d’arrière-plan sur votre propre serveur.

Que personnaliser ensuite

• Textes et photos. Remplacez les messages de la page d’accueil et les titres de pages dans les deux langues.
• Règles de livraison. Changez le seuil de livraison gratuite ou le tarif dans les deux fichiers à la fois.
• Un autre réseau de suivi. Les balises marketing sont configurées dans src/config/analytics.config.ts, et le template décrit l’ajout d’une de plus comme une tâche d’un seul fichier.
• Cartes de la vue d’ensemble. Reliez les cartes factices de revenus et de conversion à vos propres chiffres.
• Rôles. Créez un rôle pour chaque personne de l’équipe.
• Une troisième langue. Ajoutez-la aux deux frontends et à l’API. Les produits contiennent deux langues, l’anglais et l’arabe.

Erreurs courantes

Des commandes par carte qui restent en attente

Une commande ne passe à payée qu’une fois que le webhook de Stripe atteint votre API ; le retour du client sur le site n’y change rien. Vérifiez l’adresse de l’endpoint, les deux événements souscrits et le secret de signature.

Modifier la règle de livraison à un seul endroit

Le panier, le récapitulatif de paiement et l’API doivent concorder. Modifiez la configuration du storefront et le service des commandes dans le même changement.

Laisser les frontends sur la boutique d’exemple

Sans NEXT_PUBLIC_API_BASE_URL, chaque frontend répond avec des données d’exemple dans le navigateur, affiche un avis et ne facture personne. Renseignez l’adresse et reconstruisez.

Compter chaque session GA4 deux fois

Si GA4 se charge depuis Tag Manager, laissez vide la variable GA4 du template.

Remettre un rôle vide

Admin, Manager et Editor démarrent sans autorisations. Un membre de l’équipe qui reçoit l’un d’eux ne voit presque rien tant que vous n’avez pas coché ce dont il a besoin.

FAQ

Comment créer une boutique en ligne avec un panneau d’administration sous Next.js ?

Utilisez un template qui réunit déjà le storefront, le tableau de bord et l’API dans un seul projet, puis changez la marque et le catalogue. Celui-ci vous donne les trois, avec un seeder qui remplit la base de données d’une boutique de démonstration en une seule commande.

Puis-je l’utiliser pour des clients ?

Oui. La licence couvre un nombre illimité de projets, y compris les boutiques construites pour un client et remises à celui-ci. Vous ne pouvez pas revendre le code ni le publier comme template.

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

Oui. Le storefront, l’administration et l’API sont fournis en anglais et en arabe, l’arabe étant mis en page de droite à gauche. Les produits et les catégories sont enregistrés dans les deux langues.

Ai-je besoin d’un backend ?

Pour de vraies commandes, oui. Les frontends fonctionnent seuls sur une boutique d’exemple, mais les vraies commandes, les paiements et les fonctions d’IA dépendent de l’API NestJS, fournie avec les packages Full Stack et Backend API.

Prend-il en charge le paiement invité ?

Oui. Les invités paient avec une adresse e-mail et suivent leur commande avec le numéro et l’e-mail, sans compte.

Quels moyens de paiement fonctionnent ?

Les paiements par carte passent par Stripe, et les clients peuvent aussi choisir le paiement à la livraison. PayPal n’est pas proposé au paiement.

Quelle base de données utilise-t-il ?

SQLite pour le travail en local et MySQL par configuration, sans modification du code.

Gère-t-il les taxes ?

Non. La règle de livraison et le total du paiement n’appliquent aucune taxe. Si votre activité doit en facturer, ajoutez-les à la logique de prix du storefront et de l’API pour que les totaux restent identiques.

Les clients peuvent-ils payer dans d’autres devises ?

Les paiements par carte sont facturés en dollars américains. Vendre dans une autre devise demande de modifier cela dans le code, et la devise du suivi est un réglage distinct.

Que se passe-t-il quand une carte est refusée ?

La commande est marquée comme échouée lorsque Stripe signale l’échec du paiement. Le paiement à la livraison reste disponible pour ce client.

Essayez-le vous-même

Ouvrez la démo du storefront et la démo de l’administration. Lisez ensuite la documentation ou visitez la page du template e-commerce. D’autres choix sont disponibles dans la catégorie des templates e-commerce et dans le guide des templates e-commerce Next.js.

Le template e-commerce fait aussi partie des dix templates du Next.js Templates Bundle.