Next.js est mon choix par défaut pour les produits web, et pas parce que c’est à la mode. Une seule base TypeScript couvre ce qui demandait autrefois trois projets : le site marketing qui doit être bien référencé, l’application derrière la connexion et la fine couche API qui les relie. Ce site en est un petit exemple : routes localisées, métadonnées générées, sitemap, images Open Graph et route llms.txt, le tout dans un même projet App Router.
Je commence par le serveur. Pages et layouts sont des Server Components par défaut : ils récupèrent les données près de la base, envoient du HTML plutôt qu’un bundle JavaScript et gardent les secrets côté serveur. Je réserve « use client » aux feuilles de l’arbre qui ont besoin d’état, d’effets ou d’API du navigateur — un formulaire, une liste déroulante, une carte. Quand l’arbre entier commence par « use client », un bundle lourd et toute une catégorie de bugs suivent souvent.
Le choix du mode de rendu relève du produit, pas d’une préférence technique. La génération statique convient aux pages qui changent au déploiement. L’ISR ou la revalidation par tags conviennent aux catalogues, annonces et blogs qui évoluent dans la journée : revalidateTag après une écriture, plutôt qu’un minuteur que personne ne comprend. Le rendu dynamique avec streaming Suspense est destiné aux tableaux de bord et aux données personnelles : la structure apparaît tout de suite, les données lentes arrivent ensuite. Pour chaque route, je note pourquoi elle est statique ou dynamique ; cette ligne m’épargne une semaine de « pourquoi le prix est-il périmé ? ».
Pour les mutations, j’utilise les Server Actions pour les formulaires associés à une page et les Route Handlers quand un service externe doit appeler l’application — webhook d’un prestataire de paiement ou de Telegram, client mobile, tâche cron. Dans les deux cas, Zod valide les entrées sur le serveur, l’authentification y est vérifiée, et le client ne décide jamais des questions d’argent ou d’autorisations. Pour les produits plus importants, Next.js reste le frontend et le BFF, tandis que le domaine métier vit dans un service NestJS ou Node.js doté de sa propre base.
La performance et le SEO font partie de la définition du travail terminé. J’utilise next/image avec les bonnes dimensions, next/font pour éviter les décalages de mise en page, generateMetadata et des données structurées sur chaque page publique, des imports dynamiques pour les widgets lourds, puis je vérifie les Core Web Vitals sur un téléphone de milieu de gamme, pas sur un MacBook. Le déploiement se fait sur Vercel si l’équipe veut éviter l’exploitation, ou avec un build standalone dans Docker sur AWS ou un VPS si le coût, la résidence des données ou les tâches longues comptent.
Ce que je refuse : « use client » dans le layout racine, récupérer les mêmes données dans cinq composants sans réfléchir au cache, cacher la logique métier dans le middleware et faire une mise à niveau majeure un vendredi sans lire les codemods. Si ton application Next.js te paraît lente ou fragile, envoie-moi le dépôt et les deux pages les plus lentes. Je te dirai ce que je déplacerais côté serveur, ce que je mettrais en cache et ce que je supprimerais.
Donnez à votre prochain produit quelqu’un qui reste.
Prêt à commencer ? Écrivez-moi — je peux démarrer immédiatement et rester dans la durée. Des collaborations à long terme, pas une passation après deux semaines. Discutons de votre projet, de vos exigences et de la meilleure façon d’avancer.