Next.js vs. WordPress pour les sites d'entreprise : ce que les DSI des ETI doivent vraiment savoir

La décision se prend souvent en réunion : « Tout le monde connaît WordPress, on va aller vite. » Trois ans plus tard, l'équipe lutte contre des temps de chargement, des conflits de plugins et un design indiscernable de n'importe quelle autre ETI de l'espace DACH. Next.js, à l'inverse, évoque la complexité développeur. Pourtant, c'est la plateforme choisie par Stripe, Vercel et Linear. Pas par hasard.

Cet article n'est pas une question de conviction, mais une aide à la décision fondée sur des métriques, des pratiques de design et ce qui reste maintenable sur le long terme.

WordPress : puissance de marché et ses limites

WordPress fait tourner aujourd'hui plus de 43 % des sites web.^[1] Ce chiffre impressionne, mais il explique aussi le problème : la même infrastructure qui héberge des blogs personnels supporte simultanément le site corporate d'un industriel de 200 salariés.

Les atouts de WordPress sont réels. Le système de gestion de contenu est mature, les workflows éditoriaux sont familiers, et la marketplace de plugins offre une solution pour presque chaque cas d'usage. Pour les équipes marketing qui alimentent du contenu quotidiennement, c'est un avantage concret.

Les limites n'apparaissent qu'en charge :

• Performance : le rendu côté serveur en PHP signifie que chaque requête touche le serveur. Sans cache agressif, le LCP des sites WordPress non configurés dépasse régulièrement 3 secondes. Google marque comme à améliorer tout ce qui excède 2,5 secondes.^[2]
• Sécurité : WordPress est le CMS le plus attaqué du web. Plus de 97 % des vulnérabilités WordPress connues proviennent des plugins, pas du cœur lui-même.^[5]
• Qualité design : le plus grand angle mort. Des thèmes comme Avada ou Divi produisent des mises en page que je reconnais immédiatement en tant qu'UX Strategist : bandeau hero avec photo de stock, CTA générique en couleur principale, section fonctionnalités en trois colonnes. Ce n'est pas du design, c'est un template.

Next.js : ce que le framework est vraiment

Next.js n'est pas un CMS. C'est un framework React pour applications et sites web, développé et maintenu par Vercel. La différence est fondamentale : plutôt que de rendre le contenu depuis une base de données à chaque requête, Next.js peut générer les pages de manière statique au moment du build (Static Site Generation), les rendre côté serveur (Server-Side Rendering) ou combiner les deux approches (Incremental Static Regeneration).^[4]

Le résultat : les pages sont servies depuis un CDN mondial. Aucune exécution PHP, aucun appel base de données lors de la requête utilisateur. Le Time to First Byte descend sous 50 millisecondes, contre 200 à 800 millisecondes typiques pour des instances WordPress non configurées.

Stripe utilise Next.js pour l'intégralité de son site marketing. Linear construit sa page produit avec ce framework. Vercel fait tourner son propre site de plateforme sur Next.js et optimise le framework en continu à partir de cette expérience. Le point commun : contrôle maximal sur la performance et le design, sans compromis imposés par un système de thèmes.

L'inconvénient est tout aussi réel. Next.js nécessite des développeurs maîtrisant React. Les contenus éditoriaux ont besoin d'un CMS headless en backend, Contentful, Sanity ou Storyblok par exemple. Cela augmente la complexité initiale du projet et donc l'investissement de départ.

Performance : des chiffres, pas des promesses

L'HTTP Archive Web Almanac analyse chaque année des millions de sites sur les Core Web Vitals.^[3] Les sites bâtis sur des stacks statiques ou à base de frameworks JavaScript obtiennent en médiane des LCP nettement meilleurs que les pages CMS rendues dynamiquement.

Valeurs indicatives représentatives pour un site d'entreprise de 15 pages, avec formulaire de contact et blog :

Ces valeurs ne sont pas académiques. LCP et CLS entrent dans le Google Page Experience Score et influencent directement le référencement organique.^[2] Pour une ETI dont le site génère 60 % du trafic de leads, c'est un facteur de chiffre d'affaires direct.

Un exemple de calibrage concret : apple.com charge sa zone hero principale en moins d'une seconde, malgré des images produit haute résolution. Ce n'est pas un hasard, c'est le résultat de décisions de rendu prises très tôt dans le projet.

Qualité design : la différence entre « ça fait l'affaire » et le niveau Stripe

Voici la vérité la plus difficile de cet article : la plupart des sites WordPress d'entreprise ont l'air générique parce qu'ils le sont.

Avant (situation WordPress typique) : L'équipe marketing achète un thème premium à 89 euros. Le développeur active trois plugins page builder. Six semaines plus tard, le site ne reflète en rien le positionnement de l'entreprise. L'association typographique est Inter et Roboto Slab. La zone hero arbore un dégradé bleu. La section fonctionnalités présente trois pictogrammes avec du texte de remplissage. Le résultat est une interface sans identité, interchangeable avec le site concurrent à trois clics de distance.

Après (Next.js avec système de design propriétaire) : Un système typographique fondé sur l'identité de marque de l'entreprise. Des espaces blancs généreux. Des animations qui communiquent la hiérarchie de l'information sans se contenter de décorer. La même rigueur que Linear a investie dans sa page produit : chaque interaction se ressent précise, chaque section a un propos.

Next.js contraint l'équipe à prendre des décisions de design de manière consciente. Il n'y a pas de thème derrière lequel se cacher. C'est un inconvénient pour les équipes sans compétence design, et un avantage pour toutes celles qui prennent leur présence de marque au sérieux.

L'accessibilité (WCAG 2.1 AA) est bien plus contrôlable dans les projets Next.js. Les composants React peuvent imposer un HTML sémantique avec une implémentation ARIA propre. Dans Divi ou Elementor, un balisage accessible est l'exception, pas la règle.

Sécurité et maintenance

Les installations WordPress sans maintenance active constituent un risque de sécurité prévisible. Les mises à jour de plugins, de thèmes et du cœur génèrent régulièrement des conflits et ouvrent des brèches. Les vecteurs d'attaque les plus courants sont bien connus : plugins obsolètes, mots de passe administrateur faibles et interface de connexion exposée sous /wp-admin.

Les déploiements Next.js sur Vercel, ou sous forme d'artefacts générés statiquement sur un CDN, présentent une surface d'attaque fondamentalement plus réduite. Pas de base de données, pas de login administrateur, pas d'API de plugin accessible publiquement. L'attaque pertinente, si elle existe, se situe au niveau API, là où les standards d'authentification modernes comme OAuth 2.0 et JWT s'appliquent.

La maintenance avec Next.js consiste à maintenir React et les dépendances npm à jour. C'est gérable, mais requiert une attention développeur soutenue. Les deux plateformes exigent une maintenance active ; la nature de cette maintenance diffère fondamentalement.

Matrice de décision : quelle plateforme et dans quel cas ?

Le choix de plateforme n'est pas une décision technique, c'est une décision stratégique.

WordPress est le bon choix si :

• l'équipe interne alimente du contenu quotidiennement et aucun support développeur n'est disponible pour les modifications courantes
• le budget de développement est inférieur à 15 000 euros
• le site est avant tout un média d'information sans intégrations complexes
• une infrastructure WordPress existante et les compétences internes correspondantes sont déjà en place

Next.js est le bon choix si :

• la performance et le référencement organique sont stratégiquement importants
• le design doit refléter avec précision le positionnement de la marque
• des besoins d'intégration avec un CRM, un ERP ou des API propriétaires existent
• l'entreprise prévoit de scaler dans les trois prochaines années
• une équipe de développement interne ou externe maîtrisant React est disponible

La combinaison front-end Next.js et CMS headless est l'approche la plus propre pour les ETI à ambition de croissance : flexibilité éditoriale pour l'équipe marketing, contrôle technique pour l'équipe développement.

Conclusion

WordPress et Next.js résolvent des problèmes différents. WordPress résout le problème de la gestion de contenu. Next.js résout les problèmes de performance, de qualité design et de scalabilité technique.

La question « Qu'est-ce qui est mieux ? » est la mauvaise question. La bonne question est : « Que fera notre site dans trois ans, et combien nous coûte chaque jour une présence générique et lente en termes de confiance et de visibilité organique ? »

Stripe, Linear et Vercel ont donné leur réponse. Pour les ETI qui veulent être perçues comme des acteurs sérieux dans leur catégorie, cette réponse devient de plus en plus pertinente. Le prochain site d'entreprise mérite une décision fondée sur des métriques et des standards de design, pas sur ce que tout le monde connaît.

Sources

[1] W3Techs Web Technology Surveys : « Usage statistics of content management systems for websites », https://w3techs.com/technologies/overview/content_management, consulté juillet 2026.

[2] Google Developers : « Core Web Vitals », https://web.dev/articles/vitals, consulté juillet 2026.

[3] HTTP Archive : « Web Almanac 2023, chapitre : Performance », https://almanac.httparchive.org/en/2023/performance, consulté juillet 2026.

[4] Vercel : « Documentation Next.js : stratégies de rendu », https://nextjs.org/docs/app/building-your-application/rendering, consulté juillet 2026.

[5] WPScan : « WordPress Vulnerability Statistics », https://wpscan.com/statistics/, consulté juillet 2026.