Deux objets différents, pas deux concurrents
La comparaison est trompeuse tant qu'on ne l'a pas posée correctement. WordPress est un système de gestion de contenu : il stocke, organise et publie des textes, avec une interface d'administration que des millions de personnes savent utiliser. Next.js est un cadre de développement d'applications web : il ne gère aucun contenu par lui-même, il construit des interfaces et des parcours.
Un projet Next.js s'accompagne donc presque toujours d'un CMS, dit headless, qui joue le rôle d'administration de contenu. La vraie comparaison est celle-ci : un système intégré où le contenu et l'affichage sont liés, contre une architecture découplée où ils sont séparés.
Chaque modèle a un domaine où il est nettement supérieur.
Là où WordPress reste le bon choix
Sur un site éditorial, il est difficile à prendre en défaut. L'écosystème couvre l'immense majorité des besoins courants, les équipes marketing connaissent déjà l'interface, et la mise en ligne d'un site présentable demande peu de développement.
C'est aussi le choix le plus économique à court terme. Si le besoin se limite à publier des pages, des articles et des formulaires de contact, développer un site sur mesure revient à payer plus cher un résultat équivalent pour le visiteur.
Le critère d'autonomie compte enfin plus qu'on ne le croit : une équipe qui peut modifier une page sans ouvrir de ticket publie plus souvent, et un site qui vit se référence mieux qu'un site figé.
Là où l'architecture montre ses limites
Les difficultés de WordPress ne viennent presque jamais du cœur, elles viennent de l'empilement.
Chaque besoin non couvert se règle par une extension. Chacune ajoute du code, des requêtes et des ressources chargées sur chaque page. Au bout de vingt extensions, le site est lent, et l'origine de la lenteur est difficile à isoler puisqu'elle est répartie entre des composants écrits par des auteurs différents.
Cet empilement pèse aussi sur la sécurité. Le cœur est solide et corrigé rapidement, mais chaque extension est une porte d'entrée potentielle, maintenue par un tiers dont vous ne contrôlez ni le rythme ni la pérennité. La charge de maintenance qui en découle est réelle et permanente.
Enfin, dès que le site doit faire autre chose que publier, un espace client, un simulateur, un parcours en plusieurs étapes connecté à un système interne, on quitte le terrain naturel de l'outil. C'est faisable, mais on paie en complexité ce qu'un cadre applicatif fournit directement.
Ce que Next.js apporte, et à quel prix
Le premier apport est la performance. Les pages peuvent être générées à l'avance et servies au plus près du visiteur, ce qui produit des temps d'affichage difficiles à atteindre avec un rendu dynamique classique. Sur des sites où le référencement et le taux de conversion se mesurent, cette différence a une valeur chiffrable.
Le deuxième est la réduction de la surface exposée : l'administration du contenu est séparée du site public, ce qui limite mécaniquement ce qui est attaquable depuis internet.
Le troisième est la capacité applicative. Un espace client authentifié, un calculateur de prix branché sur votre système, un tableau de bord alimenté par vos données : ce sont des développements normaux, pas des contournements.
Le prix est un développement initial plus élevé et le besoin d'un partenaire technique pour faire évoluer le socle. L'éditorial reste autonome grâce au CMS, mais le rendu ne se modifie pas depuis une interface d'administration.
Le montage intermédiaire à connaître
Il existe une voie qui conserve les deux avantages : garder WordPress comme outil de rédaction, uniquement pour son interface, et afficher le contenu à travers un site développé avec Next.js qui interroge son API.
Les équipes éditoriales ne changent pas d'outil, le site public gagne en performance, et l'administration n'est plus exposée directement. C'est une transition pertinente pour un site existant dont le contenu est riche mais dont le rendu est devenu le maillon faible.
La limite à connaître : vous maintenez alors deux briques au lieu d'une, et la synchronisation entre le contenu publié et le site rendu doit être outillée sérieusement.
La question qui tranche
Votre site publie-t-il, ou fait-il faire quelque chose à ses visiteurs ?
S'il publie, WordPress fera le travail pour moins cher, et l'argent économisé sera mieux investi dans le contenu lui-même.
Si vos visiteurs y accomplissent des actions, s'y connectent, y consultent leurs données, alors ce n'est plus un site, c'est une application. Et une application se construit avec un cadre applicatif.
