Comment lancer un site SaaS en anglais et en arabe avec Next.js

Ce guide montre comment lancer un site marketing SaaS en anglais et en arabe avec Next.js, grâce au template SaaS d’Aniq UI. Vous allez le lancer, le mettre à vos couleurs, réécrire les pages, configurer les tarifs et un blog, puis le mettre sur votre propre domaine.

Une chose à savoir avant de commencer : c’est un site web, pas une plateforme. Il n’a ni base de données ni back-end, donc les formulaires d’inscription, le formulaire de contact et les boutons des offres ne sont reliés à rien. Vous branchez vous-même votre connexion, le traitement des formulaires et le paiement. Les étapes ci-dessous signalent chaque endroit où cela se passe, et chaque étape se termine par ce qu’il faut vérifier et par ce qui se passe mal le plus souvent.

Avant de commencer : les décisions à prendre

Un site marketing se construit vite et se lance lentement quand les réponses à ces questions arrivent tard. Réglez-les d’abord.

• Quelle est l’unique action que doit faire un visiteur ? Créer un compte gratuit, réserver un appel ou acheter une offre. La page d’accueil, la page des tarifs et les boutons des offres doivent tous pousser vers cette action.
• Où vont les inscriptions ? Les pages d’inscription et de connexion sont des formulaires sans rien derrière. Décidez si elles mènent au système de comptes de votre produit, à un service de connexion hébergé ou à une liste d’attente.
• Comment quelqu’un paie-t-il ? Le template n’a pas de paiement. Choisissez entre un lien de paiement hébergé par votre prestataire de paiement et un écran de facturation dans votre produit, et faites en sorte que les noms des offres du site correspondent à ce que vend ce paiement.
• Qui reçoit les messages de contact et les inscriptions à la newsletter ? Chaque formulaire a besoin d’une destination : une boîte mail via un service de formulaires, une plateforme d’emailing ou votre propre API.
• Qui écrit le blog, et à quelle fréquence ? Les articles sont des fichiers dans le code, donc c’est un développeur qui les publie, sauf si vous branchez un CMS. Soyez honnête sur le fait que cela convienne ou non à votre équipe.
• Quelles langues, et qui traduit ? L’anglais et l’arabe sont fournis, y compris le texte d’exemple du template. Les textes de votre produit demandent un traducteur humain, idéalement un arabophone natif pour les pages en arabe.
• Quelle est l’adresse ? Le site construit ses liens canoniques, son sitemap et ses cartes de partage à partir d’un seul réglage, alors connaissez votre domaine définitif, y compris s’il utilise www.

Le brief

Plainview est un petit outil d’analyse pour les boutiques en ligne. Le produit lui-même est développé à part. Ce dont l’équipe a besoin maintenant, c’est de son site public :

• Une page d’accueil qui explique le produit et montre à quoi ressemble le dashboard.
• Une page de tarifs avec trois offres et un interrupteur mensuel ou annuel.
• Un blog dans lequel l’équipe peut écrire, avec recherche et catégories.
• Un formulaire de contact et des pages d’inscription et de connexion qui mèneront au produit.
• Des pages légales et de vraies pages d’erreur.
• Toutes les pages en anglais et en arabe, l’arabe étant mis en page de droite à gauche.
• Les bons liens canoniques, le sitemap et l’image de partage, pour que les moteurs de recherche et les applis de messagerie affichent correctement le site.

Comment le template répond au brief

Besoin	Où ça se trouve	Ce que vous utilisez
Présentation du produit et aperçu du dashboard	Site web	Sections de la page d’accueil et aperçu du dashboard codé dans le hero
Offres et prix	Site web	Page des tarifs et section tarifs de la page d’accueil
Blog	Site web	Pages du blog ; les articles sont des fichiers du template
Contact, inscription, connexion	Site web ; l’envoi demande votre service	Formulaire de contact, pages d’authentification, encarts newsletter
Pages légales et d’erreur	Site web	Pages conditions, confidentialité, cookies et RGPD avec un texte provisoire, plus des designs pour les erreurs 401, 404 et 500
Anglais et arabe	Site web	Adresses /en et /ar, fichiers dans messages/
Recherche et partage	Site web	NEXT_PUBLIC_SITE_URL, sitemap, robots.txt, public/meta_image.png
Comptes et paiements	Vos propres services (non inclus)	Votre fournisseur de connexion, votre service de formulaires et votre paiement

Template, développement sur mesure ou outil de création de site hébergé

Il existe trois façons courantes d’obtenir un site marketing SaaS, et la réponse honnête dépend de qui est dans votre équipe.

Sur mesure, de zéro. Vous décidez de chaque détail, et rien dans la page n’est là par hasard. Vous concevez et construisez aussi le hero, les cartes de fonctionnalités animées, la grille tarifaire, le blog, les formulaires, les pages légales et d’erreur, les versions anglaise et arabe, et les réglages de recherche. Si un designer et un développeur ont le temps, c’est ce qui donne le résultat le plus singulier. Si l’objectif est de mettre un produit devant des clients, c’est la route la plus lente.

Un outil de création de site hébergé. Un tel outil vous met en ligne sans écrire de code, gère l’hébergement, et inclut souvent un outil de formulaires et un éditeur de blog. La contrepartie : vous travaillez dans ses mises en page et ses tarifs, déplacer le site ailleurs plus tard peut obliger à le refaire, et la prise en charge des mises en page arabes de droite à gauche varie. Lisez ses conditions sur l’export de votre contenu avant de vous engager.

Un template avec son code source. Vous partez de pages et d’animations terminées, vous possédez le code, vous l’hébergez où vous voulez et vous modifiez tout. Le prix à payer : un développeur doit faire les modifications, et les connexions (formulaires, connexion, paiement) sont à construire par vous. La licence couvre un nombre illimité de projets, sites clients compris, avec un paiement unique et des mises à jour gratuites, mais vous ne pouvez ni publier le code source ni le revendre comme template.

Plainview a un développeur et un designer qui écrira les textes, donc elle prend le template. Un fondateur sans développeur devrait sérieusement étudier un outil hébergé, et une société de services trouvera peut-être un autre template plus proche de son besoin, car celui-ci est construit autour d’un seul produit logiciel avec un design sombre.

Un exemple de plan de lancement semaine par semaine

Ce calendrier est un exemple pour Plainview, pas une promesse sur votre délai.

• Semaine 1, lancer et décider. Lancez le site en local, lisez chaque page dans les deux langues et réglez les décisions ci-dessus.
• Semaine 2, marque et textes. Changez le nom, le logo, le thème et l’image de partage. Réécrivez les sections de la page d’accueil et l’aperçu du dashboard pour le produit.
• Semaine 3, offres et contenu. Définissez les offres et les prix, écrivez les premiers articles de blog, remplacez le texte légal et traduisez tout en arabe.
• Semaine 4, connecter et tester. Branchez les formulaires et l’inscription, testez sur de vrais téléphones, vérifiez le build de production.
• Semaine 5, lancement. Fixez l’adresse définitive, déployez, vérifiez le sitemap et annoncez.

Pas à pas

1. Décidez ce que vous branchez vous-même

Dressez la liste des trois connexions avant de modifier une seule page. Pour Plainview, ce sont : où va une inscription (le système de comptes du produit), où vont les messages de contact (une boîte partagée via un service de formulaires) et où arrive un client qui paie après avoir choisi une offre.

Les boutons des offres sur la page des tarifs mènent à la page d’inscription, et rien dans le template ne débite une carte. Le choix vous revient donc : un lien de paiement hébergé par votre prestataire de paiement, ou un écran de facturation dans votre produit. Réglez-le maintenant pour que les noms des offres du site correspondent à ce que vend votre paiement.

À vérifier : vous pouvez dire, pour chaque formulaire et chaque bouton du site, où il enverra le visiteur ou les données. Ce qui se passe mal le plus souvent : découvrir au lancement que le message de réussite d’un formulaire n’était qu’un message.

2. Lancez le site sur votre ordinateur

Installez Docker Desktop, puis suivez ces sous-étapes.

2a. Télécharger. Dans votre compte Aniq UI, ouvrez My templates et téléchargez le ZIP.

Regardez la page My templates, où chaque template acheté a son propre téléchargement.

2b. Décompresser et ouvrir le dossier. Décompressez l’archive et ouvrez un terminal dans le dossier Nextjs-landing-page-template-2.

Regardez l’emplacement du terminal : le dossier doit contenir Dockerfile, package.json, messages, public et src.

2c. Construire l’image et la démarrer.

docker build -t analytics-landing .
docker run -p 3030:3030 analytics-landing

Comptez quelques minutes pour le premier build, avec un accès à internet indispensable, car les dépendances s’installent et le site est construit à l’intérieur de l’image.

Regardez le journal de build se terminer avant de lancer la seconde commande.

2d. L’ouvrir. Allez sur localhost:3030/en. Si le port est pris, changez le premier nombre après -p, comme dans docker run -p 3041:3030 analytics-landing, et ouvrez localhost:3041/en. Les modifications n’atteignent pas un conteneur déjà lancé : reconstruisez l’image après avoir changé un fichier, car elle contient une copie figée de votre code.

Regardez la barre d’adresse : le site s’ouvre sur /en, donc la langue fait partie de chaque URL.

Pour modifier le site, Node.js est plus confortable. Installez la version 20.9 ou plus récente, lancez corepack enable une fois, puis yarn install et yarn dev. Le serveur de développement répond aussi sur le port 3030 et se recharge à chaque enregistrement.

Regardez les deux commandes dont a besoin la voie sans Docker une fois Corepack activé.

Ce qui se passe mal le plus souvent : Docker n’est pas lancé (démarrez Docker Desktop et attendez), un port est utilisé, Yarn répond avec la version 1.22 parce que Corepack est désactivé, ou Node.js est antérieur à 20.9. Utilisez Yarn plutôt que npm, car le fichier de verrouillage garde votre installation sur les versions testées.

Regardez le hero : un titre, deux boutons, des cartes flottantes et, en dessous, un dashboard produit construit en code.

3. Faites le tour du site entier avant de le modifier

Passez une demi-heure à lire le site comme un visiteur. Ouvrez chaque page dans les deux langues : Accueil, Tarifs, Blog, un article de blog, Contact, Connexion, Inscription, Mot de passe oublié, les quatre pages légales et les pages d’erreur à /error/401, /error/404 et /error/500. Taper une adresse qui n’existe pas est un moyen rapide de voir la page 404.

Regardez l’ordre des sections pendant que vous faites défiler la page, car vous les réécrirez une par une à l’étape 5.

Pendant votre lecture, tenez une liste intitulée « à remplacer ». Elle doit contenir les logos d’entreprises d’exemple, les témoignages d’exemple, le texte légal d’exemple, les articles de blog d’exemple, les offres d’exemple et tout lien qui va vers #. Cette liste est votre plan de modification.

Ce qui se passe mal le plus souvent : les gens sautent la passe en arabe à ce stade et ne découvrent les surprises de mise en page qu’après avoir tout réécrit.

4. Donnez-lui le nom et le style de Plainview

L’identité de marque est répartie dans quelques fichiers, tous listés dans la documentation :

• Nom, titre et description du site : le bloc Metadata de messages/layout/en.json et ar.json. Chaque autre page a son propre bloc meta, comme PricingPage.meta dans messages/pricing/.
• Le logo : src/components/Logo.tsx. C’est du texte par défaut (le mot LOGO et une marque déposée), et l’en-tête, le pied de page et les pages de connexion utilisent tous ce même composant. Changez le mot, ou remplacez les deux spans par une image de public/.
• Thème de couleurs : defaultTheme dans src/app/[locale]/layout.tsx. Quatre sont fournis : monochrome, bleu (par défaut), violet et cyan. Pour utiliser votre propre couleur, modifiez un thème dans src/Demo/ThemeColorSwitcher/themes.ts.
• Favicon : src/app/favicon.ico. Image de partage : public/meta_image.png, de 1200 par 630 pixels.

Avec yarn dev, un panneau flottant présente un aperçu des quatre thèmes. C’est un outil de développement uniquement ; les builds de production ne l’incluent jamais. Comme le navigateur mémorise un choix fait dans le panneau, ce choix l’emporte sur defaultTheme pendant le développement. Si votre nouveau thème n’apparaît pas, choisissez-le dans le panneau, ou effacez les données stockées pour localhost:3030 dans votre navigateur.

Les polices sont DM Sans pour le texte anglais avec Clash Display pour les titres, et Noto Sans Arabic avec Almarai pour l’arabe. Pour changer une police Google, importez-la depuis next/font/google dans le layout en gardant le même nom de variable.

Le pied de page affiche une ligne de copyright et un lien de crédit. Les mots sont Footer.copyright et Footer.madeWith dans les fichiers de messages du layout, et le lien se trouve dans src/components/shared/layout/footer/components/BottomSection.tsx. Modifiez-les ou supprimez-les comme vous voulez.

À vérifier : ouvrez le code source de la page ou l’onglet du navigateur et confirmez que le titre et l’image de partage sont les vôtres. Collez l’adresse d’une page dans une appli de messagerie pour voir la carte de partage. Ce qui se passe mal le plus souvent : changer le nom en anglais et oublier le bloc Metadata en arabe.

5. Réécrivez la page d’accueil pour votre produit

La page d’accueil est un empilement de sections : Hero, une rangée défilante de logos d’entreprises, cinq cartes de fonctionnalités animées, trois statistiques qui comptent jusqu’à leur valeur, les tarifs, des témoignages, une FAQ avec recherche, et un bloc « Where we work » avec une carte du monde et un champ email. Tout ce qu’elles contiennent est du contenu d’exemple pour un produit d’analyse, et la documentation vous demande de le remplacer avant le lancement.

Traitez-les section par section :

1. Hero. Réécrivez le titre et les libellés des deux boutons pour votre appel à l’action unique.
2. Rangée d’entreprises. Supprimez-la, ou remplissez-la avec des clients qui ont accepté d’être cités.
3. Cartes de fonctionnalités. Gardez-en cinq, ou moins. Chacune décrit un bénéfice en une ou deux phrases.
4. Statistiques. Trois chiffres s’incrémentent à leur apparition. Ne gardez que des chiffres que vous pouvez prouver, et utilisez de vrais chiffres.
5. Témoignages. Ne gardez que des citations réelles et autorisées. Sinon, supprimez la section.
6. FAQ. Remplacez les dix questions par celles que vos prospects posent vraiment, et utilisez les catégories.
7. Where we work. Gardez la carte si vous avez des lieux à montrer, ou réduisez le bloc au champ email.

Plainview est aussi un produit d’analyse, donc son aperçu de dashboard demande le moins de travail. L’aperçu est construit en code plutôt qu’affiché comme une image : une barre latérale, cinq chiffres clés que l’on peut faire glisser, un graphique de nouveaux utilisateurs, un donut des sources de trafic, une liste de tâches et un tableau de clients. Remplacez ses noms, ses nombres et ses libellés par ceux qui correspondent à votre produit. En arabe, il reste de gauche à droite, comme le ferait une vraie capture de produit, et ses libellés sont traduits.

Regardez les cinq chiffres clés et les deux graphiques, les parties que vous renommerez avec les mesures de votre propre produit.

Deux sections demandent de l’honnêteté plus que de la modification. La rangée de logos et les témoignages contiennent des entreprises et des citations d’exemple. Ne lancez pas avec elles. Utilisez de vrais clients, avec leur accord, ou supprimez ces sections jusqu’à ce que vous en ayez. Un produit nouveau sans client est mieux servi par une FAQ simple et des tarifs clairs que par des éloges inventés.

Ce qui se passe mal le plus souvent : laisser une statistique d’exemple, comme un nombre d’utilisateurs que votre produit ne peut pas justifier. Les visiteurs la lisent comme une affirmation.

6. Définissez les offres et les prix

Les offres apparaissent à deux endroits : la section de la page d’accueil et la page /pricing. Les offres d’exemple, toutes en dollars américains par mois, sont Starter ($29), Growth ($79, signalée Most Popular) et Enterprise ($199). Ce sont des valeurs d’exemple à remplacer. La page des tarifs ajoute un interrupteur Mensuel et Annuel, puis une grille de comparaison qui couvre 32 fonctionnalités en cinq groupes, une courte liste de questions et un bloc de fin qui renvoie vers la page de contact.

La facturation annuelle est calculée sur dix mois, et l’interrupteur l’annonce par « Économisez 17 % ». Changez le texte si votre remise est différente. Un détail piège les gens : la section d’accueil, la page des tarifs et l’en-tête de la grille de comparaison contiennent chacune leur propre copie d’un prix, donc après un changement de prix, cherchez l’ancien nombre dans le code et mettez à jour chaque occurrence. Les chiffres sont de simples valeurs dans le code, tandis que les noms d’offres et les lignes de fonctionnalités se trouvent dans les fichiers de messages des deux langues.

Les boutons des offres sur la page des tarifs mènent à la page d’inscription. Faites-les pointer vers votre lien de paiement, ou vers votre parcours d’inscription avec l’offre choisie dans l’adresse, selon la décision prise à l’étape 1. Sur la page d’accueil, le bouton d’une offre ouvre une courte fenêtre qui propose l’inscription par email ou de continuer à naviguer ; décidez si cela convient à votre parcours ou si le bouton doit mener directement à l’inscription.

La section d’accueil a aussi un filtre qui réduit la liste des fonctionnalités à une catégorie, avec quatre noms de catégories d’exemple. Renommez-les avec des noms qui décrivent votre produit, ou supprimez le filtre si vos offres sont simples.

À vérifier : basculez entre Mensuel et Annuel et relisez chaque nombre de la page en le comparant à votre grille de prix, dans les deux langues. Ce qui se passe mal le plus souvent : un prix mensuel modifié dans les cartes mais pas dans l’en-tête de la comparaison.

7. Ajoutez le blog et écrivez les premiers articles

L’index du blog affiche les articles sous forme de cartes, cinq par page, et les visiteurs peuvent chercher dans les titres et les résumés ou filtrer par catégorie. Une barre latérale ajoute les articles populaires et les tags. Chaque page d’article affiche l’image de couverture, la date, le temps de lecture, l’auteur, des boutons de partage et jusqu’à trois articles liés. Chaque article porte son propre titre, sa description et son image de partage, et le sitemap le liste dans les deux langues.

Les articles sont des fichiers du template, pas des enregistrements d’un CMS. Un fichier de données typé et des fichiers de messages en anglais et en arabe les contiennent, et cinq articles d’exemple sont fournis avec leurs couvertures dans public/images/blog/. Pour Plainview, cela signifie qu’un développeur ajoute chaque article. Cela convient à une équipe qui publie quelques articles par mois. Si vous voulez que des rédacteurs publient seuls, remplacez le fichier de données par un CMS de votre choix.

Planifiez les premiers articles avant de les écrire. De bons sujets de départ pour Plainview suivent les questions de ses acheteurs : comment lire un rapport de trafic, que mesurer dans une petite boutique, et à quoi ressemble une première semaine avec l’outil. Écrivez chacun d’abord en anglais, traduisez-le et ajoutez les deux versions dans le même changement.

À vérifier : ouvrez le nouvel article dans les deux langues, vérifiez sa couverture, puis cherchez-le depuis l’index du blog. Ce qui se passe mal le plus souvent : supprimer les articles d’exemple un par un et laisser des boutons de catégorie qui n’affichent plus rien.

8. Vérifiez l’arabe page par page

Chaque adresse existe sous /en et /ar. Sur /ar, le layout définit dir="rtl", donc les menus, les cartes, les flèches et les tableaux sont inversés. Ouvrir / envoie le visiteur vers l’arabe quand son navigateur le préfère, et vers l’anglais sinon.

Les textes se trouvent dans sept dossiers sous messages/ : home, layout, pricing, blog, contact, auth et legal, chacun avec un en.json et un ar.json. Modifiez les deux ensemble. Si vous ajoutez du balisage, utilisez des classes logiques comme ms-2 et text-start au lieu de ml-2 et text-left. Faites relire les pages traduites par un arabophone natif ; le template traduit son propre texte d’exemple, et le texte de votre produit mérite le même soin.

Les titres arabes utilisent Almarai et le texte courant utilise Noto Sans Arabic, choisis selon la direction dans src/styles/base.css. Vérifiez les longs mots anglais et les nombres au milieu de phrases arabes, car le texte mixte est l’endroit où les mises en page de droite à gauche montrent leurs coutures.

À vérifier : chaque page que vous avez modifiée, sur /ar, à la largeur d’un téléphone. Ce qui se passe mal le plus souvent : une nouvelle chaîne dans en.json sans sa jumelle dans ar.json.

9. Branchez les formulaires

Le template valide ses formulaires puis affiche un message de réussite, mais rien ne quitte le navigateur. Cela concerne le formulaire de contact, les formulaires de connexion, d’inscription et de mot de passe oublié, ainsi que les encarts newsletter et email du pied de page, de la barre latérale du blog et de la section « Where we work ». Les boutons Google, GitHub et X des pages d’authentification ne font encore rien.

Pour chaque formulaire que vous gardez, branchez une destination : une API à vous, un outil de formulaires hébergé, une plateforme d’emailing ou un fournisseur de connexion. Supprimez les formulaires dont vous n’avez pas besoin. Un visiteur qui lit « Message envoyé » alors que rien n’arrive est pire qu’un formulaire absent. Les clés secrètes appartiennent à un serveur. Tout ce qui part vers le navigateur, valeur NEXT_PUBLIC_ comprise, est lisible par chaque visiteur.

Les contrôles déjà en place vous aident. Chaque champ est testé quand le visiteur le quitte, et les messages arrivent dans la langue de la page. Les emails doivent être valides, les noms demandent 2 caractères ou plus, un sujet de contact en demande 5 et un message en demande 20, et un nouveau mot de passe demande 8 caractères mêlant majuscules, minuscules, un chiffre et un symbole. Assurez-vous que votre service accepte les mêmes règles, ou adaptez le code pour qu’elles concordent.

Cherchez aussi les liens qui pointent vers # : certains liens du pied de page et les icônes de réseaux sociaux sont des emplacements pour vos propres pages et profils.

À vérifier : soumettez chaque formulaire que vous avez gardé avec une vraie adresse, et confirmez qu’il arrive là où vous l’attendez. Ce qui se passe mal le plus souvent : une clé placée dans une variable NEXT_PUBLIC_ pour que « ça marche tout seul », ce qui l’expose à tout le monde.

10. Fixez votre adresse et mettez en ligne

Le seul réglage qui compte est NEXT_PUBLIC_SITE_URL : votre adresse publique, qui commence par https:// et se termine sans barre oblique. Les liens canoniques, les liens du sélecteur de langue, le sitemap, robots.txt et les cartes de partage en sont issus. Elle est intégrée lors de la construction du site, donc définissez-la là où le build s’exécute. Avec Docker, passez-la en argument de build :

docker build --build-arg NEXT_PUBLIC_SITE_URL=https://www.your-domain.com -t analytics-landing .

Vos options d’hébergement :

• Vercel. Poussez le dossier vers un dépôt privé (la licence interdit de partager le code source publiquement), importez-le et ajoutez NEXT_PUBLIC_SITE_URL ainsi que ENABLE_EXPERIMENTAL_COREPACK avec la valeur 1. Déployez, puis ajoutez votre domaine.
• Un serveur Node.js. Installez, construisez avec votre adresse et démarrez. Il écoute sur le 3030, donc placez Nginx ou Caddy devant pour le HTTPS. Sur un hébergeur qui choisit le port, utilisez yarn start -p $PORT.
• Docker. Le Dockerfile inclus construit une petite image qui s’exécute sous un utilisateur sans droits d’administrateur.

Une fois en ligne, ouvrez /sitemap.xml sur votre domaine et confirmez que chaque adresse qui s’y trouve commence par votre domaine. Laissez NEXT_PUBLIC_BUY_URL vide ; quand il est renseigné, le pied de page affiche un bandeau « Buy This Template ». Enfin, remplacez le texte d’exemple des quatre pages légales (conditions, confidentialité, cookies et RGPD) par un texte adapté à votre activité, idéalement relu par un juriste. Le template ne les fournit que comme texte d’exemple.

Le site combine Framer Motion, GSAP et WebGL, ce qui fait beaucoup de mouvement. Ouvrez-le sur un téléphone de milieu de gamme avant le lancement, et retirez des effets s’il paraît lourd.

À vérifier : le sitemap en ligne, un lien partagé dans une appli de messagerie et le changement de langue sur chaque page. Ce qui se passe mal le plus souvent : un build fait avant que l’adresse ne soit définie, si bien que tous les liens canoniques pointent vers localhost. Définissez la valeur, puis reconstruisez.

Au quotidien

Après le lancement, le travail est petit et régulier. Voici les routines que suivrait Plainview.

Publier un article de blog

Écrivez l’article en anglais, puis traduisez-le. Ajoutez son entrée au fichier de données typé du blog, ajoutez le texte anglais au fichier de messages du blog dans messages/blog/ et le texte arabe à son jumeau, et placez l’image de couverture dans public/images/blog/. Vérifiez la page de l’article et l’index dans les deux langues, et cherchez-le dans le sitemap après le déploiement. Si vous passez à un CMS plus tard, le fichier de données est la pièce que vous remplacez.

Mettre à jour les tarifs

Changez le nombre à chaque endroit qui le contient : la section d’accueil, la page des tarifs et l’en-tête de la grille de comparaison. Mettez ensuite à jour les noms d’offres ou les lignes de fonctionnalités dans les fichiers de messages des deux langues, et relisez les vues Mensuel et Annuel. Prévenez la personne qui gère votre paiement, pour que le site et le paiement soient toujours d’accord.

Ajouter ou modifier une chaîne de langue

Trouvez le bon dossier sous messages/ (home, layout, pricing, blog, contact, auth ou legal), modifiez la valeur dans en.json et ar.json, et gardez les clés telles quelles, avec tout mot entre accolades laissé intact. Redémarrez yarn dev ou reconstruisez, puis vérifiez les deux langues. Pour ajouter une langue entière, ajoutez son code à src/i18n/routing.ts et src/config/i18n.ts, copiez chaque fichier de messages des sept dossiers et ajoutez-la au menu des langues. Les liens canoniques et le sitemap incluent la nouvelle langue sans travail supplémentaire.

Petites routines

• Changer le thème. Modifiez defaultTheme et reconstruisez.
• Vérifier les formulaires. Envoyez un test par chacun de temps en temps, car une intégration cassée ressemble exactement à un formulaire qui fonctionne.
• Mettre à jour le template. Les dépendances portent des versions exactes avec un fichier de verrouillage. Changez les versions volontairement, construisez et testez les deux langues.

Ce que coûte son exploitation

Le template est un achat unique à partir de $79. La licence couvre un nombre illimité de projets, y compris les sites réalisés pour des clients, et les mises à jour sont comprises.

Ce que vous payez en plus, chaque poste au tarif de son propre fournisseur :

• L’hébergement. Vercel, un serveur Node.js ou n’importe quel hébergeur Docker conviennent.
• Un nom de domaine.
• Les services que vous branchez : un fournisseur de connexion, un service de formulaires ou d’emailing, et un prestataire de paiement pour le paiement (qui prélève des frais selon sa propre page de tarifs).
• Un CMS, seulement si vous remplacez le blog basé sur des fichiers.
• Un traducteur pour le texte arabe, si personne dans l’équipe ne l’écrit.

Ce qui est gratuit : il n’y a ni base de données ni secret pour faire tourner le site, donc un premier déploiement n’a besoin que du réglage de l’adresse.

Que personnaliser ensuite

• Les données de l’aperçu. Reconstruisez le dashboard du hero avec des chiffres que votre produit affiche vraiment.
• Une couleur sur mesure. Modifiez brandPrimary et bgDark dans un thème pour correspondre exactement à votre marque.
• Le logo. Remplacez la marque texte par un SVG dans Logo.tsx, et l’en-tête, le pied de page et les pages d’authentification suivent.
• Une troisième langue. Ajoutez le code, copiez chaque fichier de messages des sept dossiers et ajoutez-la au menu des langues.
• Les pages d’erreur. Les designs 401, 404 et 500 sont là pour être montrés et aussi réutilisés dans votre produit.
• Le blog. Remplacez le fichier de données par un CMS si des non-développeurs doivent publier.

Checklist de lancement

• NEXT_PUBLIC_SITE_URL définie avec la vraie adresse avant le build de production.
• Nom du site, logo, favicon, couleur du thème et image de partage changés.
• Logos d’entreprises, témoignages et statistiques d’exemple remplacés par du matériel réel ou supprimés.
• Offres et prix cohérents avec le paiement, à chaque endroit où ils apparaissent.
• Chaque formulaire est soit relié à un service, soit supprimé.
• Les liens qui pointaient vers # mènent maintenant quelque part de réel.
• Pages légales réécrites pour votre activité.
• Chaque page vérifiée dans les deux langues, sur un téléphone et sur un ordinateur.
• Sitemap ouvert sur le domaine en ligne.
• NEXT_PUBLIC_BUY_URL laissée vide.

Erreurs courantes

Lancer avec l’adresse encore sur localhost

Si NEXT_PUBLIC_SITE_URL n’est pas définie au moment du build, les liens canoniques, le sitemap et les cartes de partage pointent vers http://localhost:3030. Définissez-la avant de construire pour la production.

Des formulaires qui semblent finis mais n’envoient rien

Chaque formulaire affiche une réussite sans rien envoyer. Branchez ou supprimez chacun d’eux avant que quiconque voie le site.

Laisser en place des clients et des citations d’exemple

La rangée de logos et les témoignages sont du contenu d’exemple. Remplacez-les par du matériel réel et autorisé, ou supprimez les sections.

Changer un prix à un seul endroit

Les offres se répètent dans la section d’accueil, la page des tarifs et l’en-tête de la comparaison. Mettez-les toutes à jour, dans les deux langues là où il y a des mots.

Modifier un réglage de build sans reconstruire

Les valeurs qui commencent par NEXT_PUBLIC_ sont intégrées à la construction. Reconstruisez l’image, relancez yarn build ou redéployez sur Vercel.

Mettre en ligne les pages légales d’exemple

Les pages conditions, confidentialité, cookies et RGPD sont du texte d’exemple. Remplacez-les par un texte adapté à votre activité et aux pays de vos visiteurs.

FAQ

Comment lancer un site SaaS en anglais et en arabe avec Next.js ?

Utilisez un template qui intègre déjà les deux langues, puis remplacez le texte d’exemple dans les deux fichiers de messages. Ici, chaque page existe sous /en et /ar, et la version arabe est mise en page de droite à gauche.

Ai-je besoin d’un back-end ?

Pas pour faire tourner le site web. Il n’a ni base de données ni back-end. Vous n’avez besoin de services que pour ce que vous branchez : connexion, formulaires et paiement.

Inclut-il le paiement ou l’encaissement ?

Non. Les boutons des offres mènent à la page d’inscription. Vous ajoutez un lien de paiement ou un parcours de facturation de votre prestataire de paiement.

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

Oui, grâce à next-intl. Les menus, les cartes et les tableaux sont inversés sur les pages arabes, tandis que l’aperçu du dashboard du hero reste de gauche à droite comme une capture de produit.

Y a-t-il un CMS pour le blog ?

Non. Les articles sont stockés dans le code, dans un fichier de données typé plus des fichiers de messages, donc c’est un développeur qui les publie. Un CMS peut prendre le relais si vous remplacez ce fichier de données.

Puis-je l’utiliser pour des clients ?

Oui. La licence commerciale couvre un nombre illimité de projets, y compris le travail client que vous livrez. Vous ne pouvez ni publier le code source ni le revendre comme template.

Puis-je changer les couleurs ?

Oui. Quatre thèmes sont fournis (monochrome, bleu, violet et cyan), et vous pouvez en modifier un avec la couleur de votre marque. Le design lui-même est sombre.

Est-il bon pour le référencement ?

Il construit pour vous les liens canoniques, les liens de langue, un sitemap, robots.txt et les cartes de partage, et chaque article de blog a ses propres métadonnées. Tout dépend de NEXT_PUBLIC_SITE_URL, alors fixez-la sur votre vrai domaine avant de construire.

Le site est-il lourd sur téléphone ?

Il combine Framer Motion, GSAP et WebGL, donc il y a beaucoup de mouvement. Essayez-le sur un téléphone de milieu de gamme et réduisez les effets s’il est lent.

Essayez-le vous-même

Ouvrez la démo en ligne pour voir le site en anglais, puis passez à l’arabe depuis le menu des langues. La page produit du template SaaS donne les détails, et la documentation couvre chaque étape. Parcourez la catégorie des templates de landing page, ou lisez le guide des templates SaaS Next.js pour comparer les options.

Ce template fait aussi partie des dix du Next.js Templates Bundle, si vous pensez construire plusieurs types de produits.