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 réalisé que TAMSIV avait besoin d'un site vitrine — landing page, pricing, FAQ, pages légales — je me suis fixé un objectif ambitieux : 3 jours, pas un de plus.

72 heures plus tard, tamsiv.com était en ligne. Multilingue (6 langues), responsive, avec un hero animé, des pages SEO optimisées, et un score Lighthouse de 94/100/100. Voici le récit complet de ce sprint, les choix techniques, les pièges, et ce que je ferais différemment.

Points clés à retenir :
- Next.js 16 avec App Router est idéal pour un site vitrine multilingue performant
- L'internationalisation avec next-intl doit être configurée dès le départ, pas ajoutée après
- Toujours lancer npm run build localement avant de déployer sur Vercel
- Le responsive demande plus d'itérations que prévu — prévoir 30% du temps total
- Un score Lighthouse 90+ est atteignable en 3 jours avec les bons choix d'architecture

Pourquoi Next.js plutôt que Gatsby, Astro ou un simple HTML ?

Le choix du framework n'est pas anodin. J'ai considéré plusieurs options :

• HTML/CSS statique : Le plus simple, mais ingérable pour 6 langues et 20+ pages. Chaque modification doit être répliquée 6 fois.
• Gatsby : Bon pour les sites statiques, mais le build time et l'écosystème 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 même écosystème que le frontend mobile TAMSIV.

Le choix de Next.js s'est aussi imposé pour une raison pratique : je savais que le site allait évoluer au-delà d'un simple site vitrine. Le système d'authentification QR code, le dashboard app, le panel admin — tout ça nécessite un framework capable de gérer des pages dynamiques protégées.

Comment organiser un sprint de 3 jours efficacement ?

Trois jours, c'est court. Sans planification, tu passes le premier jour à configurer ton environnement et tu arrives au troisième sans contenu. Voici comment j'ai découpé le sprint :

Jour 1 : Fondations techniques (10 heures)

Le premier jour est entièrement consacré à l'infrastructure technique. Rien de visible pour l'utilisateur, mais tout le reste en dépend :

• Setup Next.js 16 avec TypeScript, App Router, Tailwind CSS 4
• Internationalisation avec next-intl — 6 langues (FR, EN, DE, ES, IT, PT) configurées dès le départ
• Routing localisé : /fr/fonctionnalites, /en/features, /de/funktionen... chaque page a une URL traduite
• Layout de base : Header, footer, navigation responsive, thème sombre (#101922)
• Configuration Vercel : Repo Git connecté, preview deployments automatiques

Le routing localisé m'a coûté 2 heures de configuration à lui seul. Avec next-intl, chaque route doit être déclarée avec ses traductions de slugs. C'est verbeux mais ça donne des URLs propres et SEO-friendly dans chaque langue.

Jour 2 : Contenu et design (12 heures)

Le jour le plus intense. C'est là où le site prend forme :

• Hero animé : Arrière-plan de particules sur fond sombre #101922, avec un CTA principal. J'ai utilisé une scène 3D Spline pour le visuel principal.
• Pages de contenu : Use cases (4 scénarios), features (grille responsive), pricing (3 plans avec feature comparison), FAQ (accordéon)
• Copywriting : Chaque page en français d'abord, puis traduite. Le ton : direct, tutoiement, axé bénéfices utilisateur
• Responsive : Là où j'ai passé le plus de temps. Les grilles de features (3 colonnes → 2 → 1) ont nécessité 3 itérations. Le hero animé sur mobile a demandé un fallback statique pour la performance.

Jour 3 : SEO, performances et déploiement (8 heures)

Le dernier jour est consacré à 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 légales : Mentions légales, politique de confidentialité, CGU, cookies
• Performance : Optimisation des images, lazy loading, preloading des fonts critiques
• Déploiement Vercel : Et là... la bataille.

Pourquoi le premier déploiement Vercel a-t-il échoué ?

Le moment de vérité. git push, le build Vercel démarre... et échoue. Erreur TypeScript. Puis une autre. Puis une troisième.

Ce qui s'est passé : en développement local, Next.js est tolérant avec certaines erreurs de types. Le build de production (next build) est strict. Des types implicites any, des imports manquants, des props optionnelles non gérées — tout ça passe en dev et casse en prod.

La leçon, apprise à la dure : toujours lancer npm run build localement avant de push. Ça prend 30 secondes et ça évite 3 heures de debug sur les logs Vercel (qui sont moins lisibles que la sortie locale).

Les erreurs les plus courantes que j'ai corrigées :

• Types implicites : function Component({ data }) → function Component({ data }: { data: DataType })
• Imports non utilisés : Le build les traite comme des erreurs, pas des warnings
• Variables d'environnement : Préfixe NEXT_PUBLIC_ obligatoire pour les variables accessibles côté client
• Alternates metadata : Les URL de chaque langue doivent être absolues, pas relatives

Comment configurer l'internationalisation avec next-intl dès le départ ?

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, clés identiques, valeurs traduites.
2. Middleware : Détection automatique de la langue du navigateur, redirection vers le bon préfixe (/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 accéder aux traductions dans chaque composant.

Le piège classique : commencer sans i18n et l'ajouter après. J'ai vu des projets où ça a coûté des semaines de refactoring. En le mettant dès le jour 1, chaque composant est déjà prêt pour 6 langues. La traduction automatique via LLM s'en charge ensuite.

Un point important : le contenu HTML du blog est stocké dans des fichiers séparés (content/blog/{locale}/{slug}.html), pas dans les fichiers JSON. Pourquoi ? Parce que next-intl interprète les balises HTML comme des variables ICU et génère des erreurs. Cette séparation m'a évité des heures de debug.

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

Le score Lighthouse final : 94 Performance, 100 Accessibilité, 100 SEO. Voici les optimisations clés :

• Images optimisées : 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. Zéro layout shift.
• Lazy loading : Tous les composants below-the-fold chargés à la demande. Le hero animé est le seul à être chargé immédiatement.
• CSS atomique : Tailwind CSS 4 génère un CSS minimal — seules les classes utilisées sont incluses.
• Static Generation : Toutes les pages de contenu sont pré-rendues au build. Zéro serveur au runtime pour le contenu statique.

Le point de performance le plus critique était le hero animé. L'animation de particules sur fond sombre était belle mais lourde. J'ai dû implémenter un seuil : sur mobile, l'animation est remplacée par un gradient statique. Sur desktop, elle ne démarre qu'après 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 créé en 3 jours :

1. Landing page : Hero + use cases + features + pricing + FAQ + CTA. C'est 80% du trafic.
2. About : Qui est derrière le projet. Pour un dev solo, c'est un atout de crédibilité.
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 dès le jour 3. Le blog est devenu un canal d'acquisition SEO majeur.

Chaque page existe dans 6 langues grâce à l'i18n. Ça fait 30+ pages générées à partir de 6 templates. Le rapport effort/impact de l'i18n est énorme — j'en parle en détail dans mon article sur l'i18n comme canal d'acquisition.

Comment le site a-t-il évolué après le sprint initial ?

Les 3 jours ont posé les fondations. Depuis, le site a considérablement évolué :

• Dashboard app (/app/tasks, /app/memos, /app/agenda) : Interface web complète pour gérer ses tâches et mémos depuis un navigateur. Authentification par QR code ou email.
• Panel admin (/admin/dashboard) : Métriques utilisateurs, graphiques Recharts, alertes. Détaillé dans l'article sur le dashboard admin.
• Blog SEO : 40+ articles techniques optimisés pour le référencement, avec images générées par IA.
• Roadmap publique : Page de roadmap avec fonctionnalités livrées et à venir.
• Guide utilisateur : Documentation interactive pour les nouveaux utilisateurs.

Tout ça n'aurait pas été possible sans les fondations solides des 3 premiers jours. L'App Router de Next.js, l'i18n native, le déploiement Vercel automatique — chaque brique posée au départ a facilité 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 maîtrises.
2. Configure l'i18n au jour 1 : Même 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. Systématiquement. Sans exception.
4. Mobile first pour le CSS : Commence par le mobile, ajoute les breakpoints desktop. L'inverse coûte 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 coûte l'hébergement 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, même avec 40+ pages et du trafic régulier.

Faut-il Tailwind CSS ou un autre framework CSS ?

Tailwind CSS est idéal pour un sprint rapide. Tu codes le design directement dans le JSX, pas besoin de fichiers CSS séparés. L'inconvénient : le code HTML est verbeux. Mais pour un dev solo qui veut aller vite, l'overhead de lisibilité est largement compensé par la vitesse de développement.

Comment gérer les traductions sans traducteur professionnel ?

J'utilise un script de traduction automatique via OpenRouter (LLM). Le script détecte les clés modifiées (delta-only), traduit uniquement ce qui a changé, et coûte environ 0.05 EUR par passe. La qualité est très bonne pour des textes techniques. Les détails sont dans l'article sur l'i18n en 6 langues.

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

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

Peut-on faire le même sprint avec Astro au lieu de Next.js ?

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