Blog / Article #84

Next.js, c'est facile ? Ça dépend si tu aimes qu'on te tienne la main

Next.js, c’est un peu comme ce pote qui insiste pour t’aider à monter ton meuble Ikea. Au début, tu te dis : « Super, je vais gagner du temps ». Sauf qu’à la fin, tu réalises qu’il a vissé toutes les planches à l’envers, et que tu passes trois heures à tout démonter pour comprendre comment ça marche. Alors, Next.js, c’est facile ? Oui, si tu aimes les frameworks qui prennent les décisions à ta place. Non, si tu veux garder le contrôle sur ton code sans te battre contre des abstractions.

Le syndrome du « tout-en-un » qui fait tout… sauf ce que tu veux

Next.js, c’est le couteau suisse du développement frontend : routage automatique, rendu côté serveur (SSR), génération de sites statiques (SSG), régénération incrémentielle (ISR), optimisation des images, et même un système de middleware pour faire joujou avec les requêtes HTTP. Tout est là, prêt à l’emploi, avec une documentation qui te murmure à l’oreille : « Allez, laisse-toi porter, on s’occupe de tout. »

Sauf que. Sauf que quand tu veux sortir des sentiers battus, c’est une autre paire de manches. Tu veux gérer ton propre système de routage ? Bonne chance pour désactiver next/router sans te prendre un mur d’erreurs. Tu veux utiliser un autre bundler que Webpack ? bah tu ne peux pas (ou alors, bon courage pour éjecter tout le bordel). Next.js est conçu pour que tu restes dans son écosystème, et si tu essaies de t’en échapper, tu vas vite te sentir comme un hamster dans une roue en acier.

Prenons un exemple concret : tu veux ajouter un simple script tiers qui a besoin de s’exécuter côté client, après le chargement de la page. Avec Next.js, tu as le choix entre :

• Utiliser next/script, qui va optimiser le chargement… mais qui peut aussi casser ton script si tu ne maîtrises pas ses subtilités.
• Te battre avec useEffect et dangerouslySetInnerHTML en priant pour que le SSR ne fasse pas planter ton app.
• Ou simplement désactiver le SSR pour cette page, parce que parfois, la solution la plus simple, c’est de dire à Next.js de lâcher l’affaire.

Et c’est là que le bât blesse : Next.js te donne l’illusion du contrôle, mais dès que tu veux faire quelque chose d’un peu spécifique, tu te retrouves à contourner ses mécanismes plutôt qu’à les utiliser. C’est comme si on te donnait une voiture automatique avec un mode manuel… sauf que le mode manuel est verrouillé à 80% du temps.

La magie noire du SSR : quand le framework décide à ta place

Le Server-Side Rendering (SSR), c’est la feature star de Next.js. L’idée ? Générer le HTML côté serveur pour améliorer le SEO et les performances. En théorie, c’est génial. En pratique, c’est un peu comme confier ton portefeuille à un inconnu dans un bar : tu ne sais pas ce qu’il va en faire, mais tu espères que ce sera pour ton bien.

Le problème, c’est que le SSR ajoute une couche de complexité invisible. Ton code React, qui tournait tranquillement côté client, doit maintenant s’exécuter côté serveur. Résultat :

• Tu dois t’assurer que ton code est « universel » (compatible serveur ET client), sinon tu te prends des erreurs du type window is not defined en pleine gueule.
• Tu dois gérer les différences entre les environnements (navigateur vs Node.js), ce qui peut vite devenir un casse-tête si tu utilises des librairies qui ne sont pas conçues pour ça.
• Tu perds en flexibilité : certaines librairies client-side (comme les animations complexes ou les WebGL) vont te faire suer sang et larmes pour fonctionner avec le SSR.

Et le pire, c’est que Next.js active le SSR par défaut. Tu veux une page statique ? Trop tard, ton composant est déjà en train de s’exécuter côté serveur, et tu vas devoir ajouter getStaticProps ou désactiver explicitement le SSR avec export const dynamic = 'force-static'. Parce que oui, en 2026, il faut encore dire à Next.js de ne PAS faire de SSR. Logique, non ?

Un exemple qui résume bien l’approche « paternaliste » de Next.js :

// Tu veux une page statique ? Trop tard, Next.js a déjà décidé pour toi.
export async function getServerSideProps() {
  return { props: {} };
}

// Pour une page statique, il faut explicitement le demander.
export async function getStaticProps() {
  return { props: {} };
}

// Ou alors, tu peux forcer le mode statique (parce que oui, c'est nécessaire).
export const dynamic = 'force-static';

Bref, Next.js te donne l’impression d’avoir le choix, mais en réalité, il a déjà pris les décisions importantes à ta place. Et si tu veux changer les règles, prépare-toi à lire 15 pages de documentation pour comprendre comment contourner ses mécanismes.

La hype et les promesses : quand le marketing prend le pas sur la technique

Next.js, c’est aussi un phénomène de hype. Entre les conférences sponsorisées, les tutos YouTube qui te promettent de « créer un site en 10 minutes », et les articles qui te vendent Next.js comme la solution miracle à tous tes problèmes de performance, on finit par oublier que c’est juste… un framework. Un outil, pas une religion.

Le problème, c’est que la hype autour de Next.js a tendance à occulter ses limites. Par exemple :

• La complexité cachée : Next.js est simple à prendre en main pour un projet basique, mais dès que tu veux faire quelque chose d’un peu avancé (comme un système d’authentification personnalisé ou une intégration fine avec une API), tu te retrouves à devoir comprendre des mécanismes internes qui ne sont pas toujours bien documentés.
• La dépendance à Vercel : Next.js est développé par Vercel, et certaines features (comme les Edge Functions ou le middleware) sont optimisées pour leur plateforme. Si tu veux déployer ailleurs, tu risques de te heurter à des incompatibilités ou à des performances dégradées.
• La courbe d’apprentissage inversée : Next.js est facile au début, mais plus tu avances, plus tu réalises que tu dois désapprendre certaines choses pour comprendre comment il fonctionne vraiment. C’est comme apprendre à conduire avec une voiture automatique, puis réaliser que tu dois réapprendre à passer les vitesses pour conduire une manuelle.

Et puis, il y a cette tendance à présenter Next.js comme LA solution ultime, alors qu’en réalité, il existe des alternatives tout aussi valables (comme Astro, Remix, ou même un bon vieux create-react-app avec un backend séparé) qui peuvent être plus adaptées selon ton cas d’usage. Mais bon, quand tu es le framework chouchou de Vercel, tu as le droit de faire comme si la concurrence n’existait pas.

Alors, Next.js, c’est pour qui ?

Next.js n’est pas un mauvais framework. Il est même très bien conçu pour certains cas d’usage :

• Les sites vitrines ou les blogs, où le SSR et le SSG apportent un vrai gain en SEO et en performance.
• Les applications qui ont besoin d’un rendu côté serveur pour des raisons de sécurité ou de performance (comme les dashboards avec des données sensibles).
• Les projets où tu veux une solution « clé en main » sans te prendre la tête avec la configuration.

En revanche, si tu veux :

• Un contrôle total sur ton code et ton architecture.
• Une stack légère et minimaliste, sans dépendances superflues.
• Une flexibilité maximale pour intégrer des outils tiers ou des librairies spécifiques.

Alors Next.js risque de te frustrer plus qu’autre chose. C’est un peu comme acheter une voiture avec toutes les options alors que tu voulais juste un volant et quatre roues : au début, c’est pratique, mais à la longue, tu réalises que tu paies pour des trucs dont tu n’as pas besoin.

En résumé : Next.js, c’est facile si tu acceptes de jouer selon ses règles. Si tu veux sortir du cadre, prépare-toi à ramer. Et surtout, ne crois pas les tutos qui te promettent un développement « sans effort » : derrière la magie des abstractions, il y a toujours un moment où tu vas devoir mettre les mains dans le cambouis. Et à ce moment-là, mieux vaut avoir compris comment Next.js fonctionne vraiment… sinon, tu risques de passer plus de temps à contourner ses mécanismes qu’à coder ton app.

Alors, Next.js, c’est pour toi ? Ça dépend. Si tu aimes les frameworks qui te mâchent le travail, fonce. Si tu préfères garder le contrôle, cherche peut-être ailleurs. Et dans tous les cas, n’oublie pas : la magie, ça n’existe pas. Même en JavaScript.