Pourquoi passer à Next.js en 2026 (et quand ne pas le faire)

Je me souviens encore du jour où j'ai compris que Next.js allait gagner. C'était en 2022, je codais un site client en Next 12, j'ai vu la vitesse de rendu SEO et la simplicité de l'API Routes. À ce moment-là, je me suis dit "le débat Angular vs React vs Vue, c'est fini, la prochaine décennie va se jouer sur le framework fullstack". 4 ans plus tard, j'avais raison. Voici pourquoi — et pourquoi ce n'est quand même pas la bonne réponse partout.

La vraie rupture : la mort du front-only

Avant Next.js 13, on séparait nettement front (SPA React) et back (API Node ou autre). Next.js brouille la ligne : les Server Components peuvent interroger directement la base de données, faire des calculs lourds côté serveur, et rendre du HTML final sans jamais toucher le JavaScript client. Le front devient intelligent.

Résultat concret : mon bundle JavaScript client est passé de 600 KB (React SPA) à 90 KB (Next.js avec Server Components) sur le même type de projet. Le LCP est passé de 3,2 s à 1,1 s. Je n'ai pas écrit de code d'optimisation, j'ai juste utilisé la plateforme. C'est ça qui a changé.

Les 5 atouts qui pèsent vraiment

Le SEO natif (l'évidence)

Google reçoit une page complète, pas un squelette. Je sais, on le répète depuis 2020, mais j'ai encore des prospects qui arrivent avec une SPA React classique en me demandant pourquoi ils ne rankent pas. Fin 2025, Googlebot rend toujours le JavaScript, mais avec un délai et des limites. Avec Next.js SSR, le problème n'existe plus.

La performance par défaut

Tout le monde peut faire du WordPress qui rame. Presque personne ne le fait exprès. Mais entre les plugins obligatoires, les scripts tiers, les shortcodes lourds, les thèmes bloat, un WordPress moyen fait 3 à 6 secondes de LCP sur mobile 4G. Next.js bien configuré fait 1-2 secondes sans effort. C'est pas du marketing, c'est mon quotidien.

Les Server Components, la vraie nouveauté de la décennie

C'est le truc qui justifie à lui seul Next.js en 2026. Vous écrivez un composant qui fait async/await sur une requête SQL, et il se rend côté serveur avec le résultat. Zéro API Routes à écrire, zéro fetch client, zéro gestion d'état de loading. La complexité drop de 40 %. C'est comme passer de jQuery à React, mais pour le data fetching.

L'écosystème qui s'aligne

Vercel pousse Next.js et a un quasi-monopole sur les innovations : Image Optimization, ISR, Edge Functions, Middleware, Server Actions. shadcn/ui est pensé pour Next d'abord. Tailwind officialise ses intégrations Next. TanStack, motion, Sanity, Payload — tout ce qui compte en 2026 supporte Next en priorité.

Le déploiement qui "juste marche"

Vercel, Netlify, Cloudflare Pages, Docker sur votre infra : le code est le même, le déploiement est trivial. J'ai des clients qui sont en Docker sur OVH, d'autres sur Cloudflare Pages gratuit, d'autres sur Vercel payé. Même codebase, même CI/CD, une variable d'environnement qui change. Portabilité remarquable.

Les cas où je ne recommande PAS Next.js

Contrairement à ce que la hype veut vous faire croire, Next.js n'est pas universellement supérieur. Je déconseille dans ces cas :

• App purement interne, sans SEO à soigner : une SPA React ou Blazor Server est plus simple
• Site avec moins de 10 pages statiques : Astro ou Eleventy sont plus légers et plus simples
• Équipe 100 % C# qui n'a jamais touché JavaScript : le coût d'apprentissage dépasse les gains
• App mobile native : React Native, Flutter, ou natif selon le cas
• Projet avec un SSR ultra-complexe et des besoins de streaming particuliers : Remix a parfois un meilleur modèle

Le vrai critère de décision

Posez-vous cette question : est-ce que mon projet combine SEO + interactivité riche + performance ? Si les trois cases sont cochées, Next.js est quasi imbattable. Si une des trois ne compte pas (par exemple : app interne où le SEO n'existe pas), d'autres options deviennent pertinentes.