Next.js vs WordPress : pourquoi on ne construit plus sur WordPress

Personne ne choisit WordPress après avoir comparé les options. On le choisit parce qu'on connaît — la dernière agence l'utilisait, un ami développeur l'a recommandé, ou on a tapé « créer un site web » dans Google en 2019. C'est le choix par défaut. Et pour beaucoup d'entreprises, ce choix travaille silencieusement contre elles.

On a reconstruit suffisamment de sites WordPress pour reconnaître le schéma. Des temps de chargement autour de deux secondes. Des scores Lighthouse dans les cinquante. Des conflits de plugins que personne ne sait résoudre. Le dirigeant n'a aucune idée que tout ça se passe — il constate simplement que les leads n'arrivent pas comme prévu. Chez Osea, on construit sur Next.js. Voici pourquoi.

Ce qui se passe réellement sous le capot de WordPress

WordPress est une application PHP lancée en 2003. À chaque visite sur votre site, le serveur reçoit la requête, interroge une base de données, assemble le HTML, et le renvoie au navigateur. À chaque visite. Sur chaque page. Ajoutez à ça la pile de plugins qu'on retrouve sur la plupart des sites WordPress — formulaires de contact, outils SEO, page builder, couche de cache, plugin de sécurité, plugin de sauvegarde — et vous avez une dizaine de processus qui se disputent les mêmes ressources serveur au moment précis où votre visiteur attend.

Le site WordPress moyen tourne avec 22 plugins actifs. Chacun représente du code supplémentaire exécuté à chaque requête. Certains entrent en conflit entre eux. D'autres n'ont pas été mis à jour depuis deux ans. D'autres encore introduisent des failles de sécurité que le propriétaire du site ne découvre qu'après s'être fait pirater — quand ses visiteurs sont redirigés vers une pharmacie en ligne.

Core Web Vitals : les métriques que Google utilise pour classer votre site

Depuis 2021, Google utilise les Core Web Vitals comme signal de classement confirmé. Les trois métriques déterminantes : le Largest Contentful Paint (LCP), qui mesure le temps avant que le contenu principal devienne visible ; l'Interaction to Next Paint (INP), qui évalue la réactivité de la page quand un utilisateur clique ; et le Cumulative Layout Shift (CLS), qui détecte si des éléments bougent pendant le chargement.

Google considère qu'un LCP en dessous de 2,5 secondes est « bon ». La plupart des sites WordPress non optimisés avec un page builder affichent entre 3 et 6 secondes. Ce n'est pas juste mauvais pour le référencement — c'est mauvais pour le business. Les données sur les taux de conversion sont limpides : une seconde de délai supplémentaire au chargement fait chuter les conversions d'environ 7 %. Sur un site qui génère 100 demandes par mois, ça représente 7 contacts perdus tous les 30 jours. Chaque mois. Indéfiniment.

“La vitesse n'est pas une coquetterie technique. C'est de l'argent. Plus précisément, c'est l'argent que votre site lent offre à celui qui charge plus vite que vous.”

— Osea Web Strategy

Ce que Next.js fait différemment

Next.js est un framework React conçu dès le départ pour la performance. La différence fondamentale : au lieu de construire chaque page à chaque requête, il génère les pages au moment du déploiement. Quand un visiteur arrive sur votre site, il reçoit du HTML pré-rendu servi instantanément depuis un nœud CDN — un serveur physiquement proche de lui. Aucune requête en base de données sur le chemin critique. Aucune pile de plugins pour ralentir le tout.

Cette approche s'appelle le Static Site Generation (SSG). Pour les pages qui nécessitent des données fraîches — une page d'annonces mise à jour régulièrement, un blog alimenté en continu — Next.js propose l'Incremental Static Regeneration (ISR). Les pages sont reconstruites en arrière-plan à intervalles définis, sans redéploiement complet. On obtient la vitesse d'un site statique avec la souplesse d'un site dynamique.

Pour la gestion de contenu, nous couplons Next.js avec un CMS headless — généralement Sanity ou Contentful. Votre équipe marketing dispose d'une interface d'édition claire et intuitive. Vos développeurs travaillent sur une vraie base de code. Les deux ne se marchent jamais dessus, parce que le CMS est une source de données, pas un moteur de rendu.

Ce qu'on constate concrètement sur nos projets

Quand on migre un client de WordPress vers Next.js, les gains ne sont pas marginaux. Les scores de performance Lighthouse passent régulièrement de la tranche 40–60 à plus de 90. Le Time to First Byte — le temps avant que le navigateur reçoive le premier octet du serveur — chute de 800 ms à moins de 100 ms. Structurellement, on parle de deux catégories de sites complètement différentes.

Un client dans l'immobilier est venu nous voir avec un site WordPress équipé d'un page builder, 22 plugins actifs, et un Time to First Byte de 1,8 seconde. On l'a reconstruit en Next.js avec un CMS headless. Six semaines après le lancement : les impressions organiques avaient grimpé de 34 %, la position moyenne en recherche s'était améliorée de 11 places. Même contenu. Même domaine. Des fondations différentes.

C'est exactement le type de résultats qu'on documente dans nos études de cas — pas pour se mettre en avant, mais parce que les chiffres parlent mieux que n'importe quelle explication.

« Mais WordPress, c'est plus simple à gérer »

C'est l'objection qu'on entend le plus souvent, et elle mérite une réponse franche. WordPress dispose d'un panneau d'administration visuel que des collaborateurs non techniques peuvent utiliser pour mettre à jour le contenu. C'est vrai. La question, c'est de savoir si cette « simplicité » vaut les compromis en performance et en sécurité — et dans la plupart des cas, la réponse est non, parce que le postulat de départ est dépassé.

Un site Next.js connecté à Sanity offre à un éditeur non technique la même flexibilité — publier des articles, modifier du texte, changer des images — avec une interface plus épurée que celle de WordPress. La différence, c'est que l'éditeur ne touche qu'au contenu, pas à un moteur de rendu qui peut casser si on installe le mauvais plugin.

Si vous voulez voir à quoi ressemble un workflow d'édition moderne, notre page développement web détaille la stack complète que nous recommandons habituellement.

Quand WordPress reste un choix acceptable

On n'a pas de dogme sur les outils. WordPress convient très bien pour un blog personnel, un projet amateur, ou une situation où le budget est la contrainte absolue et le trafic reste faible. Mais dès que votre site web joue un rôle concret dans l'acquisition de clients — quand il sert d'outil de vente, de levier de génération de leads, ou de vitrine pour des prospects qui vont vous juger dessus — il vous faut des fondations capables de tenir cette pression. WordPress, dans la majorité de ses configurations, ne tient pas.

La vraie question

Votre site web travaille pour vous, ou il ne travaille pas. Un site WordPress lent, bourré de plugins, avec un score Lighthouse de 52, n'est pas neutre — il vous fait perdre des positions en recherche, fait fuir des visiteurs, et donne une image en dessous de ce que votre entreprise vaut réellement. Le choix de la stack technique est une décision business, pas une préférence de développeur.

Si vous ne savez pas où en est votre site, nous proposons un audit gratuit qui couvre la performance, les fondamentaux SEO, et une analyse claire de ce qu'il faut corriger et dans quel ordre. Pas de jargon, pas de pression commerciale — juste un état des lieux honnête.