Next.js vs WordPress

WordPress et Next.js répondent à des questions différentes. WordPress est un CMS complet qu’on installe, qu’on habille d’un thème et qu’on étend avec des extensions. Next.js est un framework React : il donne aux développeurs les briques d’un site ou d’une application, et vous y ajoutez le CMS de votre choix.

Si vous tenez un blog, un magazine ou un site d’entreprise classique, que votre équipe connaît déjà le back-office WordPress et que le budget est modeste, choisissez WordPress. Il est mûr, tout le monde sait recruter dessus, et une installation bien entretenue fait le travail.

Si le site est un vrai canal d’acquisition, où la vitesse, la sécurité et la qualité SEO pèsent directement sur le chiffre d’affaires, ou s’il va devenir un espace client, un configurateur ou un produit, choisissez Next.js avec un CMS headless. Vous obtenez un site plus rapide et plus sûr, sans empilement d’extensions, et la liberté de tout construire.

La question décisive est de savoir qui maintiendra le site. WordPress peut être tenu par un profil généraliste ; Next.js demande un développeur ou une agence.

Next.js est un framework React open source maintenu par Vercel et publié sous licence MIT. React construit l’interface ; Next.js ajoute ce dont un vrai site ou une vraie application a besoin autour : routage par fichiers, rendu serveur, génération statique, cache, optimisation des images et des polices, et logique back-end dans le même projet. La dernière version stable en novembre 2026 est la 16.4.

Next.js n’est pas un CMS. Le contenu vient de la source de votre choix : un CMS headless comme Payload, Contentful ou Sanity, une base de données, ou même WordPress utilisé en headless. Nous l’associons à Payload, qui s’installe dans l’application Next.js : le site, l’interface d’administration et le modèle de contenu vivent dans un seul dépôt. Le framework est gratuit ; vous payez l’hébergement (Vercel, un serveur Node.js ou un conteneur) et le travail de développement.

WordPress est un CMS open source écrit en PHP, publié sous licence GPL, qui fait tourner plus de 40 % des sites web. On l’installe chez un hébergeur, on choisit un thème, puis on ajoute des extensions pour tout le reste : SEO, formulaires, e-commerce avec WooCommerce, multilingue, cache, sécurité. Le répertoire officiel compte près de 60 000 extensions gratuites, et l’éditeur de blocs (Gutenberg) permet aux rédacteurs de construire des pages sans code.

Ses forces : il est familier, le vivier de prestataires est immense, et il existe une solution à presque tous les besoins. Ses faiblesses viennent du même endroit : chaque extension est du code écrit par quelqu’un d’autre, qui ajoute du poids, des mises à jour et des risques de sécurité. WordPress.org est le logiciel libre que vous hébergez vous-même ; WordPress.com est le service hébergé d’Automattic, avec ses propres offres.

Les dix critères que nous regardons sur chaque projet de site. La dernière colonne indique l’option qui l’emporte, d’après notre expérience sur les projets clients, avec Next.js associé à un CMS headless.

C’est là que WordPress a son meilleur argument. Des millions de personnes connaissent déjà son back-office : écrire un article, ajouter une image, publier. L’éditeur de blocs permet d’assembler des pages, et les types de contenus personnalisés, avec une extension comme ACF, structurent le reste. Pour une équipe qui publie tous les jours et ne veut rien réapprendre, cette familiarité vaut beaucoup.

Avec Next.js, l’édition dépend du CMS que vous y associez. Avec Payload, l’interface d’administration est générée à partir d’un modèle de contenu écrit en code : chaque collection a exactement les champs dont votre équipe a besoin, avec brouillons, versions, aperçu en direct, rôles et langues. Les rédacteurs ne voient pas un back-office générique, ils voient le leur. La contrepartie : le modèle est conçu par un développeur, et ajouter un champ demande une petite modification du code.

La règle que nous appliquons : si les rédacteurs ont besoin d’inventer librement des mises en page chaque semaine, un constructeur de pages sur WordPress ou un outil visuel comme Webflow convient mieux. Si le contenu est structuré (articles, études de cas, produits, landing pages faites de blocs validés), Next.js avec Payload offre une édition plus propre et plus sûre.

Un site Next.js peut être généré en statique ou rendu côté serveur, puis mis en cache au plus près des visiteurs. Les pages n’embarquent que le JavaScript dont elles ont besoin, les images sont redimensionnées et servies dans des formats modernes automatiquement, et les polices se chargent sans décalage de mise en page. De bons Core Web Vitals sont la norme, pas un chantier.

WordPress peut lui aussi être rapide, avec un thème léger, peu d’extensions, un cache de pages et un CDN. En pratique, les sites que nous auditons ressemblent rarement à cela : un constructeur de pages, un carrousel, trois extensions de suivi et un widget de chat s’additionnent, et chaque page en paie le prix. Chaque extension peut ajouter ses propres scripts et styles à toutes les pages, qu’elles s’en servent ou non.

Quand nous avons quitté un outil visuel pour Next.js sur notre propre site, le poids des pages sur mobile est passé de 3,7 Mo à 1,0 Mo. La vitesse ne fait pas de miracle sur le classement, mais sur un site d’acquisition elle se voit dans le taux de rebond et la conversion.

Le cœur de WordPress est bien maintenu et corrigé vite. Le risque est autour : la grande majorité des failles signalées sur WordPress se trouvent dans les extensions et les thèmes. Comme WordPress est partout, des robots scannent chaque installation à la recherche de failles connues dans les extensions populaires, et une mise à jour oubliée quelques semaines suffit. Faire tourner WordPress en sécurité, c’est appliquer les mises à jour chaque semaine, limiter les extensions, protéger la connexion et garder des sauvegardes réellement testées.

Un site Next.js a une surface d’attaque bien plus réduite. Les pages sont pré-générées ou servies par une application Node.js, il n’y a pas d’administration PHP publique à attaquer par force brute, et l’interface d’administration (Payload, par exemple) peut avoir ses propres règles d’accès. Ce n’est pas sans entretien : les dépendances doivent être mises à jour, et les frameworks publient eux aussi des correctifs de sécurité. Mais les mises à jour passent par une relecture du code et un déploiement de test avant la production, au lieu d’un bouton dans un back-office.

Dans les deux cas, un site a besoin d’un responsable. La différence est le profil : WordPress peut être maintenu par un généraliste rigoureux ; Next.js est maintenu par un développeur ou une agence.

WordPress est bon en SEO, surtout grâce à des extensions comme Yoast ou Rank Math : titres et descriptions par page, plans de site, balises canoniques, fil d’Ariane et données structurées, le tout depuis le back-office. Un rédacteur peut en gérer l’essentiel sans aide. Les limites apparaissent sur les gros sites : pages d’archives en double, pages lourdes et conflits d’extensions demandent une attention technique.

Next.js donne un contrôle total, mais rien n’est fourni par défaut : métadonnées, plans de site, hreflang, données structurées et redirections sont codés une fois, puis pilotés par des champs du CMS. Bien fait, le résultat est plus propre qu’avec n’importe quelle extension : chaque gabarit produit exactement le balisage voulu, les pages sont rapides, et aucune URL d’archive parasite n’apparaît. Notre propre site génère titres, descriptions, URL canoniques et versions linguistiques pour chaque langue à partir de Payload.

Sur le SEO seul, c’est une égalité : les deux peuvent très bien se positionner. La différence est dans la répartition du travail. Sur WordPress, une extension s’en charge et vous surveillez les effets de bord ; sur Next.js, un développeur le construit une fois et cela reste propre.

Le catalogue d’extensions de WordPress est son super-pouvoir. Formulaires, réservations, abonnements, une boutique avec WooCommerce, une plateforme de formation, un site d’emploi : il existe une extension pour presque tout, souvent gratuite ou peu chère, installée en quelques minutes. Pour les besoins courants, rien n’est plus rapide.

Le problème arrive quand les besoins cessent d’être courants. Combiner cinq extensions qui n’ont pas été pensées ensemble, puis les plier à vos règles métier, donne un site fragile que personne n’ose mettre à jour. C’est en général le moment où les équipes nous appellent.

Next.js n’a pas de boutique d’extensions dans ce sens : les fonctionnalités se construisent, avec des bibliothèques et des services (Stripe pour le paiement, une bibliothèque d’authentification pour les comptes, l’API de votre CRM). C’est plus long pour une fonction standard, et beaucoup plus rapide pour une fonction spécifique. Et comme Next.js gère la logique back-end, le même projet peut passer d’un site marketing à un espace client, un simulateur de devis ou une application complète, sans changer de plateforme. C’est la raison principale pour laquelle nous le recommandons pour les sites appelés à devenir des produits.

Il existe une voie intermédiaire : garder WordPress comme back-office et construire le front en Next.js, en lisant le contenu par l’API REST ou WPGraphQL. Les rédacteurs gardent l’interface qu’ils connaissent, les visiteurs profitent d’un site Next.js rapide.

Cela fonctionne, et c’est une étape sensée pour une grosse équipe éditoriale attachée à WordPress. Mais vous faites désormais tourner deux systèmes : WordPress demande toujours ses mises à jour et sa sécurité, et beaucoup d’extensions cessent de fonctionner parce qu’elles s’attendent à afficher la page elles-mêmes (constructeurs de pages, certaines extensions de SEO et de formulaires). Pour un nouveau projet, nous préférons en général un CMS pensé pour le headless, comme Payload, qui vit dans l’application Next.js et supprime purement et simplement le second système.

WordPress n’a pas de multilingue natif : il faut ajouter une extension comme WPML, Polylang ou TranslatePress. Elles fonctionnent et sont très répandues, mais elles ajoutent leurs propres tables, réglages et licences, et sont une source fréquente de conflits avec d’autres extensions.

Dans Next.js, les langues font partie du routage (/fr, /de, etc.), et un CMS comme Payload stocke nativement les champs traduits, avec une langue de repli. Les balises hreflang, les slugs traduits et les plans de site par langue sont générés par le code. Notre propre site tourne ainsi en anglais et en français. Pour un site en deux langues ou plus qui comptent commercialement, Next.js offre une base plus propre.

WordPress tourne chez presque n’importe quel hébergeur PHP, de l’hébergement mutualisé bon marché aux plateformes WordPress gérées qui s’occupent du cache, des sauvegardes et des mises à jour. Ce choix est une force, et aussi un piège : c’est souvent sur l’hébergement bon marché que vivent les sites WordPress lents et piratés.

Next.js tourne sur Vercel, l’entreprise qui le maintient, sur n’importe quel serveur Node.js, dans un conteneur, ou en export statique quand aucune fonction serveur n’est nécessaire. Avec Payload, le contenu est dans votre propre base PostgreSQL ou MongoDB, dans la région de votre choix, y compris en Europe. Notre site est hébergé sur Vercel, avec la base et les fichiers sous notre contrôle.

Dans les deux cas, vous êtes propriétaire du code et du contenu. Aucun des deux ne vous enferme chez un éditeur comme le fait un outil hébergé.

Le bon choix dépend de votre situation, pas d’un classement. La règle simple : si le site est un site de contenu classique, tenu par une équipe qui connaît WordPress, gardez WordPress et entretenez-le bien ; si le site est un canal d’acquisition ou le début d’un produit, construisez-le en Next.js avec Payload.

Nous construisons aussi des sites marketing compacts sur Webflow et Framer, qui battent souvent les deux pour une petite équipe sans développeur. Notre page agence Next.js détaille notre façon de travailler sur les sites et applications sur mesure.

Les deux logiciels sont gratuits et open source. Ce que vous payez, c’est l’hébergement, les modules et surtout le temps des personnes.

L’hébergement. WordPress tourne sur un hébergement mutualisé pour quelques dollars par mois, ou sur un hébergement WordPress géré, plus cher, avec cache et sauvegardes inclus ; les prix varient beaucoup, consultez la page de prix de l’hébergeur. Next.js sur Vercel démarre avec une offre Hobby gratuite pour les projets personnels ; l’offre Pro coûte 20 $ par siège de développeur et par mois, avec 20 $ de consommation inclus (novembre 2026). Un serveur Node.js ou un conteneur ailleurs est une autre option.

Les modules. Un site WordPress professionnel paie souvent des licences annuelles pour un thème premium, un constructeur de pages, une extension multilingue, une extension de formulaires, un service de sauvegarde ou de sécurité. Chacune est modeste ; ensemble, elles s’additionnent, et chacune est du code à mettre à jour. Un site Next.js utilise des bibliothèques open source et quelques services (e-mail, formulaires, recherche) payés à l’usage. Payload est lui-même gratuit, sous licence MIT ; son offre Enterprise est sur devis.

La construction. Un site WordPress bâti sur un thème coûte moins cher au lancement. Un site Next.js est conçu et développé pour vous, donc le coût initial est plus élevé ; pour les fonctionnalités et applications sur mesure, nous travaillons toujours sur devis. Sur deux ou trois ans, l’écart se réduit : pas de licences d’extensions, moins de corrections en urgence, et de nouvelles fonctions sans contournement.

La maintenance. WordPress demande des mises à jour et une surveillance chaque semaine. Next.js demande des mises à jour de dépendances et des déploiements, moins souvent mais par un développeur. Prévoyez l’un ou l’autre : aucun site ne tourne tout seul.

La plupart des sites WordPress qu’on nous demande d’examiner ont la même histoire. Le site a démarré propre, puis chaque nouveau besoin a apporté une extension, le thème a été personnalisé au-delà de ses limites, et les mises à jour sont devenues risquées. À ce stade, l’équipe a peur de toucher au site, ce qui est l’inverse de ce dont un canal d’acquisition a besoin.

Quand WordPress reste simple, maintenu chaque semaine et utilisé pour ce qu’il fait le mieux, publier, il reste un très bon choix, et nous le disons. Quand le site doit convertir, se positionner en plusieurs langues et gagner de nouvelles fonctions chaque mois, Next.js avec Payload offre une base qui ne se dégrade pas avec le temps.

Notre propre site tourne sur Next.js et Payload depuis novembre 2026. Dans les quatre jours qui ont suivi la mise en ligne, nous avons livré 113 modifications, parce qu’ajouter un type de page, un champ ou une fonction est un travail de développement ordinaire, pas une chasse à l’extension.

Le contenu se déplace bien : articles, pages, catégories et médias s’exportent de WordPress et s’importent dans Payload par script. Les thèmes et les extensions ne se déplacent pas ; le design et les fonctionnalités sont reconstruits. Le vrai risque est le SEO, c’est pourquoi chaque URL est cartographiée avant toute chose. Notre service de migration de site suit la méthode que nous avons appliquée à notre propre site.

Nos notes tirées des sites que nous construisons en Next.js et des sites WordPress que nous maintenons ou reprenons. Le détail est dans nos fiches Next.js et WordPress.

Versions, prix et fonctionnalités ont été vérifiés sur les pages officielles ci-dessous le 14 novembre 2026. Les prix sont les prix officiels en dollars américains, hors taxes ; les prix d’hébergement changent souvent, vérifiez-les avant de vous engager.