Comment j'ai créé un site Next.js multilingue en 3 jours

Une app mobile sans site web, c'est comme un restaurant sans enseigne. Tu peux avoir la meilleure cuisine du monde, personne ne te trouvera. Quand j'ai realise que TAMSIV avait besoin d'un site vitrine — landing page, pricing, FAQ, pages legales — je me suis fixe un objectif ambitieux : 3 jours, pas un de plus.

72 heures plus tard, tamsiv.com etait en ligne. Multilingue (6 langues), responsive, avec un hero anime, des pages SEO optimisees, et un score Lighthouse de 94/100/100. Voici le recit complet de ce sprint, les choix techniques, les pieges, et ce que je ferais differemment.

Points cles a retenir :
- Next.js 16 avec App Router est ideal pour un site vitrine multilingue performant
- L'internationalisation avec next-intl doit etre configuree des le depart, pas ajoutee apres
- Toujours lancer npm run build localement avant de deployer sur Vercel
- Le responsive demande plus d'iterations que prevu — prevoir 30% du temps total
- Un score Lighthouse 90+ est atteignable en 3 jours avec les bons choix d'architecture

Pourquoi Next.js plutot que Gatsby, Astro ou un simple HTML ?

Le choix du framework n'est pas anodin. J'ai considere plusieurs options :

• HTML/CSS statique : Le plus simple, mais ingerable pour 6 langues et 20+ pages. Chaque modification doit etre repliquee 6 fois.
• Gatsby : Bon pour les sites statiques, mais le build time et l'ecosysteme de plugins vieillissant m'ont refroidi.
• Astro : Excellent pour le contenu statique, mais je savais que j'aurais besoin de composants interactifs (auth, dashboard) plus tard.
• Next.js 16 : App Router, React Server Components, rendu hybride (statique + dynamique), i18n natif. Et surtout, je connais React — c'est le meme ecosysteme que le frontend mobile TAMSIV.

Le choix de Next.js s'est aussi impose pour une raison pratique : je savais que le site allait evoluer au-dela d'un simple site vitrine. Le systeme d'authentification QR code, le dashboard app, le panel admin — tout ca necessite un framework capable de gerer des pages dynamiques protegees.

Comment organiser un sprint de 3 jours efficacement ?

Trois jours, c'est court. Sans planification, tu passes le premier jour a configurer ton environnement et tu arrives au troisieme sans contenu. Voici comment j'ai decoupe le sprint :

Jour 1 : Fondations techniques (10 heures)

Le premier jour est entierement consacre a l'infrastructure technique. Rien de visible pour l'utilisateur, mais tout le reste en depend :

• Setup Next.js 16 avec TypeScript, App Router, Tailwind CSS 4
• Internationalisation avec next-intl — 6 langues (FR, EN, DE, ES, IT, PT) configurees des le depart
• Routing localise : /fr/fonctionnalites, /en/features, /de/funktionen... chaque page a une URL traduite
• Layout de base : Header, footer, navigation responsive, theme sombre (#101922)
• Configuration Vercel : Repo Git connecte, preview deployments automatiques

Le routing localise m'a coute 2 heures de configuration a lui seul. Avec next-intl, chaque route doit etre declaree avec ses traductions de slugs. C'est verbeux mais ca donne des URLs propres et SEO-friendly dans chaque langue.

Jour 2 : Contenu et design (12 heures)

Le jour le plus intense. C'est la ou le site prend forme :

• Hero anime : Arriere-plan de particules sur fond sombre #101922, avec un CTA principal. J'ai utilise une scene 3D Spline pour le visuel principal.
• Pages de contenu : Use cases (4 scenarios), features (grille responsive), pricing (3 plans avec feature comparison), FAQ (accordeon)
• Copywriting : Chaque page en francais d'abord, puis traduite. Le ton : direct, tutoiement, axe benefices utilisateur
• Responsive : La ou j'ai passe le plus de temps. Les grilles de features (3 colonnes → 2 → 1) ont necessite 3 iterations. Le hero anime sur mobile a demande un fallback statique pour la performance.

Jour 3 : SEO, performances et deploiement (8 heures)

Le dernier jour est consacre a tout ce qui rend le site "professionnel" :

• SEO technique : generateMetadata() par page avec Open Graph, alternates langues, sitemap XML dynamique
• Analytics : GA4 avec Consent Mode RGPD (pas de tracking sans consentement)
• Pages legales : Mentions legales, politique de confidentialite, CGU, cookies
• Performance : Optimisation des images, lazy loading, preloading des fonts critiques
• Deploiement Vercel : Et la... la bataille.

Pourquoi le premier deploiement Vercel a-t-il echoue ?

Le moment de verite. git push, le build Vercel demarre... et echoue. Erreur TypeScript. Puis une autre. Puis une troisieme.

Ce qui s'est passe : en developpement local, Next.js est tolerant avec certaines erreurs de types. Le build de production (next build) est strict. Des types implicites any, des imports manquants, des props optionnelles non gerees — tout ca passe en dev et casse en prod.

La lecon, apprise a la dure : toujours lancer npm run build localement avant de push. Ca prend 30 secondes et ca evite 3 heures de debug sur les logs Vercel (qui sont moins lisibles que la sortie locale).

Les erreurs les plus courantes que j'ai corrigees :

• Types implicites : function Component({ data }) → function Component({ data }: { data: DataType })
• Imports non utilises : Le build les traite comme des erreurs, pas des warnings
• Variables d'environnement : Prefixe NEXT_PUBLIC_ obligatoire pour les variables accessibles cote client
• Alternates metadata : Les URL de chaque langue doivent etre absolues, pas relatives

Comment configurer l'internationalisation avec next-intl des le depart ?

L'i18n est le sujet qui m'a pris le plus de temps sur le jour 1. Avec next-intl, le setup initial demande de la rigueur :

1. Fichiers de messages : Un fichier JSON par langue (messages/fr.json, messages/en.json...). Structure identique, cles identiques, valeurs traduites.
2. Middleware : Detection automatique de la langue du navigateur, redirection vers le bon prefixe (/fr/, /en/).
3. Routing : Chaque page est dans un dossier [locale]. Les slugs sont traduits via un fichier de mapping.
4. Composants : useTranslations('section') pour acceder aux traductions dans chaque composant.

Le piege classique : commencer sans i18n et l'ajouter apres. J'ai vu des projets ou ca a coute des semaines de refactoring. En le mettant des le jour 1, chaque composant est deja pret pour 6 langues. La traduction automatique via LLM s'en charge ensuite.

Un point important : le contenu HTML du blog est stocke dans des fichiers separes (content/blog/{locale}/{slug}.html), pas dans les fichiers JSON. Pourquoi ? Parce que next-intl interprete les balises HTML comme des variables ICU et genere des erreurs. Cette separation m'a evite des heures de debug.

Comment obtenir un score Lighthouse 90+ avec Next.js ?

Le score Lighthouse final : 94 Performance, 100 Accessibilite, 100 SEO. Voici les optimisations cles :

• Images optimisees : Composant <Image> de Next.js avec sizes et priority pour le LCP. Format WebP automatique.
• Fonts critiques : next/font pour les Google Fonts avec display: swap. Zero layout shift.
• Lazy loading : Tous les composants below-the-fold charges a la demande. Le hero anime est le seul a etre charge immediatement.
• CSS atomique : Tailwind CSS 4 genere un CSS minimal — seules les classes utilisees sont incluses.
• Static Generation : Toutes les pages de contenu sont pre-rendues au build. Zero serveur au runtime pour le contenu statique.

Le point de performance le plus critique etait le hero anime. L'animation de particules sur fond sombre etait belle mais lourde. J'ai du implementer un seuil : sur mobile, l'animation est remplacee par un gradient statique. Sur desktop, elle ne demarre qu'apres le LCP (Largest Contentful Paint).

Quelles pages sont indispensables pour un site vitrine d'app mobile ?

Pour un lancement, tu n'as pas besoin de 50 pages. Voici le minimum viable que j'ai cree en 3 jours :

1. Landing page : Hero + use cases + features + pricing + FAQ + CTA. C'est 80% du trafic.
2. About : Qui est derriere le projet. Pour un dev solo, c'est un atout de credibilite.
3. Privacy Policy : Obligatoire pour le Play Store et le RGPD.
4. Terms of Service : Obligatoire pour les abonnements in-app.
5. Cookie Policy : Obligatoire avec le cookie consent RGPD.
6. Blog : Optionnel au lancement, mais j'ai mis la structure en place des le jour 3. Le blog est devenu un canal d'acquisition SEO majeur.

Chaque page existe dans 6 langues grace a l'i18n. Ca fait 30+ pages generees a partir de 6 templates. Le rapport effort/impact de l'i18n est enorme — j'en parle en detail dans mon article sur l'i18n comme canal d'acquisition.

Comment le site a-t-il evolue apres le sprint initial ?

Les 3 jours ont pose les fondations. Depuis, le site a considerablement evolue :

• Dashboard app (/app/tasks, /app/memos, /app/agenda) : Interface web complete pour gerer ses taches et memos depuis un navigateur. Authentification par QR code ou email.
• Panel admin (/admin/dashboard) : Metriques utilisateurs, graphiques Recharts, alertes. Detaille dans l'article sur le dashboard admin.
• Blog SEO : 40+ articles techniques optimises pour le referencement, avec images generees par IA.
• Roadmap publique : Page de roadmap avec fonctionnalites livrees et a venir.
• Guide utilisateur : Documentation interactive pour les nouveaux utilisateurs.

Tout ca n'aurait pas ete possible sans les fondations solides des 3 premiers jours. L'App Router de Next.js, l'i18n native, le deploiement Vercel automatique — chaque brique posee au depart a facilite les ajouts suivants.

Quels conseils pour un dev solo qui lance son site en sprint ?

Si tu es dev solo et que tu veux lancer un site vitrine rapidement, voici mes 5 recommandations :

1. Choisis un framework que tu connais : Ce n'est pas le moment d'apprendre. Utilise ce que tu maitrises.
2. Configure l'i18n au jour 1 : Meme si tu ne traduis qu'en une seule langue, la structure est en place. Ajouter les traductions plus tard sera trivial.
3. Build local avant chaque push : npm run build. Systematiquement. Sans exception.
4. Mobile first pour le CSS : Commence par le mobile, ajoute les breakpoints desktop. L'inverse coute toujours plus cher en temps.
5. Ship early, iterate later : Un site imparfait en ligne vaut mieux qu'un site parfait qui n'existe que sur localhost. Les corrections viendront.

FAQ

Combien coute l'hebergement d'un site Next.js sur Vercel ?

Le plan gratuit de Vercel est suffisant pour la plupart des sites vitrines. Il inclut le SSL, le CDN global, et les preview deployments. J'utilise encore le plan gratuit pour tamsiv.com, meme avec 40+ pages et du trafic regulier.

Faut-il Tailwind CSS ou un autre framework CSS ?

Tailwind CSS est ideal pour un sprint rapide. Tu codes le design directement dans le JSX, pas besoin de fichiers CSS separes. L'inconvenient : le code HTML est verbeux. Mais pour un dev solo qui veut aller vite, l'overhead de lisibilite est largement compense par la vitesse de developpement.

Comment gerer les traductions sans traducteur professionnel ?

J'utilise un script de traduction automatique via OpenRouter (LLM). Le script detecte les cles modifiees (delta-only), traduit uniquement ce qui a change, et coute environ 0.05 EUR par passe. La qualite est tres bonne pour des textes techniques. Les details sont dans l'article sur l'i18n en 6 langues.

Le SEO est-il suffisant avec generateMetadata de Next.js ?

generateMetadata() gere le titre, la description, les Open Graph, et les alternates (hreflang). C'est suffisant pour 90% des besoins SEO on-page. J'ai ajoute un sitemap dynamique et un robots.txt pour le crawling. Le reste (backlinks, contenu, autorité) depend du blog et du marketing.

Peut-on faire le meme sprint avec Astro au lieu de Next.js ?

Oui, Astro serait meme plus rapide pour un site purement statique. Mais si tu prevois d'ajouter des pages dynamiques (auth, dashboard) plus tard, Next.js reste le meilleur choix. Le passage de statique a dynamique est transparent avec l'App Router.