Next.js pour le B2B : pourquoi on a arrêté de chercher autre chose

#Le choix de Next.js : une position assumée

Depuis mi-2025, Nehos a standardisé sur Next.js 16 pour tous les nouveaux projets B2B. Cette décision n'est pas venue d'une présentation Vercel ni d'un engouement pour la nouveauté — elle est le résultat d'une comparaison directe sur des projets réels, avec des équipes réelles, sur plusieurs années.

Les frameworks qu'on a sérieusement utilisés en production avant d'arriver à cette conclusion : Nuxt.js 3 (sur des projets Vue existants), Remix (sur deux projets SaaS en 2023-2024), SvelteKit (un projet pilote en 2024), Astro (plusieurs sites contenus). WordPress headless, aussi — une expérience édifiante.

#Ce que le B2B exige d'un framework web

Un site B2B n'est pas un blog. Il combine en général :

• Des pages SEO statiques ou semi-statiques (home, services, blog, ressources) qui doivent se charger vite
• Des zones authentifiées (portail client, espace commercial, configurateur) qui nécessitent données fraîches et sécurité
• Des intégrations multiples (CRM, ERP, signature électronique, analytics cookieless)
• Des exigences enterprise : SSO SAML, audit trail, conformité RGPD

Ce mix précis — contenu statique + zones dynamiques + intégrations enterprise — est là où Next.js domine.

#Performance et SEO : le duo décisif pour le B2B

Les décideurs B2B cherchent sur Google avant d'appeler. Le CMO d'une ETI qui veut refondre son ERP cherche "refonte portail client B2B". Le DAF qui évalue un outil de pilotage financier cherche "logiciel tableau de bord financier PME". Ces requêtes ont une valeur commerciale élevée — et Google les classe en partie sur les Core Web Vitals.

#Ce que nos mesures montrent

Sur 12 migrations WordPress → Next.js réalisées en 2024-2025 (sites B2B entre 80 et 800 pages), les scores Lighthouse en production avant/après :

Ces chiffres incluent des sites avec des plugins de cache WordPress (WP Rocket, W3 Total Cache). WordPress même optimisé ne passe pas la barre des 90 sur des sites avec des contenus dynamiques, des formulaires et des intégrations tiers.

#Pourquoi Next.js App Router + PPR change la donne

Le Partial Prerendering permet de servir le shell d'une page depuis le CDN (en ~20ms) tout en streamant les données dynamiques séparément. Sur un site B2B avec pages produit comportant à la fois du contenu statique et des données de stock ou de pricing client-spécifique, c'est le seul modèle qui satisfait simultanément le SEO et l'expérience utilisateur connecté.

Exemple concret : site de services B2B, 800 pages, LCP mesuré à 1,4s, INP à 120ms en production CrUX. Le même site sur son architecture WordPress précédente : LCP 3,1s, INP 310ms.

#App Router et Server Components : le changement de paradigme

Les React Server Components (RSC) permettent de garder la logique métier et les appels de données côté serveur — zero bundle JavaScript envoyé au client pour ces composants. Pour le B2B, les implications sont concrètes :

Pages produit avec données ERP en temps réel — un composant serveur peut appeler directement l'API interne sans exposer les credentials au navigateur. La clé API reste sur le serveur. Le client reçoit le HTML rendu, pas le code qui a servi à le produire.

Formulaires avec validation serveur — avec les Server Actions, la validation Zod côté serveur est native. Plus besoin d'une API route dédiée pour chaque formulaire. La logique de validation vit une seule fois, côté serveur, avec retour d'erreurs structuré vers le client via useActionState.

Dashboard avec streaming de données — <Suspense> combiné aux Server Components permet d'afficher les données qui arrivent au fur et à mesure. Un dashboard avec 5 blocs de données différents peut afficher chaque bloc dès qu'il est prêt, sans attendre le bloc le plus lent.

#La différence chiffrée vs Pages Router

Sur les migrations App Router vs Pages Router que nous avons menées, la réduction du JavaScript client est systématiquement entre -40% et -55%. Moins de JS = meilleur INP = meilleur ranking = plus de leads organiques.

#L'écosystème qui compte pour le B2B

Next.js seul n'est pas suffisant — c'est la stack TypeScript complète qui fait la différence pour les projets B2B enterprise.

Payload CMS v3 — TypeScript-first, schemas définis en code, API auto-générée, access control granulaire. Parfait pour du contenu structuré piloté par des équipes marketing B2B. Pas de SaaS pricing surprenant : auto-hébergeable.

tRPC — API type-safe entre Next.js et le backend. Les types des endpoints sont inférés automatiquement. Quand le backend change un paramètre, le frontend TypeScript plante à la compilation — pas en production devant un client.

Prisma / Drizzle — ORM typé pour PostgreSQL, MySQL, SQLite. Les queries sont vérifiées au build. Refactoring de schema sans surprise en production.

Auth.js — authentification SSO SAML/OIDC pour les clients enterprise, OAuth pour les connexions sociales, gestion de sessions JWT ou base de données. Configurations testées avec Okta, Azure AD, Google Workspace — les trois IdP les plus courants en B2B français.

Vercel ou OVHcloud — deux options de déploiement selon les contraintes RGPD du client. Vercel pour la simplicité maximale. OVHcloud (hébergement souverain français) pour les clients qui ont des contraintes de localisation des données.

Zod — validation de schéma TypeScript à runtime. Un seul schéma partagé entre frontend et backend pour valider les données entrantes, les payloads d'API et les formulaires.

Tout dans un seul langage : TypeScript end-to-end. Une équipe backend peut intervenir sur du code Next.js. Un développeur frontend peut lire les schémas Prisma. La barrière des contextes techniques s'efface.

#Cas d'usage B2B spécifiques où Next.js excelle

Portail client self-service (My Account B2B) — Server Components + Auth.js + Server Actions. Chaque utilisateur voit ses données, ses commandes, ses contrats. Zero exposition de données inter-clients. Le rendu serveur garantit que les données confidentielles ne transitent pas dans le bundle client.

Catalogue produit 10 000+ références — ISR (Incremental Static Regeneration) pour générer les pages produit statiquement, avec revalidation par tag quand un produit change en ERP. Les pages produit les plus visitées sont servies depuis le CDN en quelques millisecondes.

Espace commercial avec pricing client-spécifique — RSC + Auth. Le pricing contractuel de chaque client est chargé côté serveur, jamais exposé dans le bundle JavaScript. Un concurrent qui inspecte les sources ne voit que du HTML rendu.

Blog et ressources SEO — SSG + ISR pour le headless commerce B2B et les sites contenus. Build time génération de toutes les pages, CDN global, performances maximales sur les pages qui génèrent l'essentiel du trafic organique.

Landing pages A/B test — Edge Middleware pour router les visiteurs vers des variantes selon des critères géographiques, comportementaux ou de source de trafic. Zéro latence supplémentaire : le middleware tourne sur le CDN.

Dashboard analytics — Server Components avec streaming. Chaque widget charge ses données indépendamment. L'utilisateur voit le dashboard se peupler progressivement — meilleure expérience perçue que d'attendre un loading spinner global.

Application de devis complexe — Server Actions pour calculer les devis côté serveur (logique métier protégée), Zod pour valider les inputs, tRPC pour les appels intermédiaires. Formulaires multi-étapes avec validation progressive.

#Intégration IA native avec Next.js

En 2026, un projet B2B ambitieux intègre souvent des fonctionnalités IA — chatbot de qualification de leads, recherche sémantique dans la documentation, génération de contenus personnalisés, assistant de devis.

Next.js dispose d'un avantage structurel ici : le Vercel AI SDK est une bibliothèque React/Next.js first qui gère nativement le streaming des réponses LLM (Claude, GPT-4o, Mistral). Les implémentations IA en Next.js sont idiomatiques — pas de glue code à écrire.

Server Actions pour les appels LLM — les clés API Anthropic ou OpenAI restent côté serveur. Un utilisateur qui inspecte le réseau voit uniquement le stream de la réponse, jamais la clé API ni le prompt système.

Composants de chat UI — le Vercel AI SDK fournit des hooks React (useChat, useCompletion) qui gèrent le streaming, l'historique et les états de chargement. Un chatbot B2B fonctionnel en quelques heures de développement.

RAG dans les Server Components — le pattern Retrieval Augmented Generation (embeddings + vector search + LLM) s'intègre naturellement dans les Server Components. La recherche vectorielle côté serveur retourne du contexte au LLM sans exposer la base de connaissances au client.

C'est ce qui rend Next.js particulièrement pertinent pour les projets B2B avec IA intégrée : l'architecture serveur-first protège naturellement les actifs sensibles (clés API, données propriétaires, prompts système).

#Pourquoi pas les alternatives ?

Cette question revient dans chaque avant-projet. La réponse honnête :

Nuxt.js (Vue.js) — excellent framework, équipe Vercel/UnJS sérieuse, performances comparables à Next.js sur les benchmarks. Le problème pour le B2B français en 2026 : l'écosystème de profils Vue est plus restreint que React. Trouver un développeur Vue senior disponible en France prend deux fois plus de temps. Si votre équipe interne est déjà en Vue : Nuxt.js est le bon choix. Si vous partez de zéro : Next.js donne accès à un pool de talents plus large.

Remix — très bon framework sur le modèle web-standards (forms, loaders, actions). Shopify l'a racheté en 2023 et a depuis ralenti le développement public. L'incertitude sur la roadmap est un risque réel pour des projets B2B avec une durée de vie de 5-7 ans. Nous ne recommandons plus Remix pour des projets nouveaux.

SvelteKit — performances excellentes, bundle JavaScript très petit, syntaxe agréable. L'adoption enterprise reste faible. Peu de bibliothèques UI enterprise testées en production. Trouver des profils Svelte seniors en France : quasi impossible. Pour un pilote ou une équipe déjà en Svelte : acceptable. Pour un projet B2B critique : le risque de ressources est trop élevé.

Astro — parfait pour les sites statiques ou contenus (documentation, blogs, marketing sites). Dès qu'on ajoute de l'authentification, des données dynamiques et des mutations, Astro montre ses limites. Ce n'est pas un framework applicatif. Pour un blog ou un site vitrine sans auth : Astro est plus léger que Next.js. Pour 80% des projets B2B qu'on rencontre : il manque des briques essentielles.

WordPress headless — nous avons arrêté de proposer cette architecture après 6 projets en 2022-2023. La complexité opérationnelle (WordPress + API WP + Next.js front = 3 couches à maintenir) ne se justifie que si le client a un investissement éditorial majeur dans WordPress et des équipes habituées. Les migrations WordPress vers Next.js sont aujourd'hui plus rapides que maintenir un headless WordPress en bonne santé.

#Ce qui est dur avec Next.js pour le B2B

Ce serait malhonnête de ne pas le dire clairement.

La courbe d'apprentissage App Router est réelle. Un développeur JavaScript senior qui connaît React arrive sur l'App Router et est déstabilisé les premières semaines : où mettre 'use client' ? Pourquoi ce composant ne peut pas appeler useRouter ? Pourquoi mes données sont-elles stale ? Notre mesure empirique : 4 à 6 semaines pour qu'un dev senior JavaScript soit autonome et confiant sur l'App Router. Budget en conséquence.

La gestion du cache est complexe. L'App Router a 4 types de cache qui interagissent : Request Memoization, Data Cache, Full Route Cache, Router Cache. Chacun a ses règles d'invalidation, ses durées de vie et ses comportements par défaut. Des surprises sont possibles — contenu stale après une mutation, pages qui ne se revalident pas comme prévu. La documentation Vercel est complète mais dense. Prévoir du temps de debugging cache en début de projet.

Le déploiement sans Vercel est plus complexe. Vercel est la plateforme cible native de Next.js — zéro configuration, edge CDN inclus, ISR out-of-the-box. Sur OVHcloud, AWS ou un VPS dédié, il faut configurer Nginx, Node.js, la gestion du cache ISR manuellement (ou via standalone output). C'est faisable et nous le faisons régulièrement, mais c'est du travail supplémentaire à budgéter.

Les erreurs d'hydratation en dev local peuvent être mystérieuses. Un mismatch entre le rendu serveur et le rendu client se manifeste par une erreur Hydration failed pas toujours facile à tracer. En général c'est résolu en 10-30 minutes, mais le message d'erreur initial n'est pas toujours parlant.

Ces points durs sont connus, documentés et surmontables. Ils expliquent pourquoi un projet Next.js bien fait demande de l'expérience — pas pourquoi il faudrait choisir un autre framework.

#Verdict et recommandation Nehos

Après 50+ projets B2B et 4 frameworks testés sérieusement, notre grille de décision en 2026 :

Choisissez Next.js 16 App Router si :

• Projet B2B (site vitrine, portail client, e-commerce B2B, SaaS, application interne)
• Performance et SEO sont des critères de succès
• Budget pour une équipe tech qui monte en compétence sur l'App Router
• Horizon projet de 3-7 ans

Choisissez Nuxt.js si :

• Votre équipe interne est déjà en Vue et vous ne voulez pas la requalifier
• Vous avez des bibliothèques Vue propriétaires à réutiliser

Choisissez Astro si :

• Site purement éditorial (blog, documentation, site vitrine sans auth ni données dynamiques)
• Performance maximale avec JavaScript minimal est la priorité absolue

Évitez WordPress headless sauf si vous avez une contrainte éditoriale majeure et documentée.

Pour 80% des projets B2B que nous rencontrons : c'est Next.js. Le ROI d'une refonte de site B2B se justifie plus rapidement quand la stack de base est performante dès le départ — moins de dette technique, moins de maintenance de performance, plus de temps pour livrer des fonctionnalités à valeur ajoutée.

Si vous avez un projet en cours d'évaluation et que vous hésitez sur le choix de framework, notre équipe peut faire une revue technique de votre contexte en moins d'une heure. Les bonnes décisions d'architecture se prennent avant de commencer à coder, pas après 6 mois de développement.