Un client m'a appelé en 2021, une agence immobilière, budget décent, venait de renvoyer leur ancienne agence. Le cahier des charges était simple : reconstruire leur portail d'annonces. Le dev sortant avait passé huit mois à scaffolder une application Next.js sur mesure. Ça avait l'air brillant en démo. Personne dans leur équipe ne pouvait la mettre à jour sans pull request et pipeline de déploiement. L'agent immobilier gérant les annonces utilisait un Google Sheet comme contournement.
Point clé : WordPress l'emporte quand les éditeurs ont besoin d'autonomie et que le contenu change quotidiennement ; Next.js l'emporte quand le site est un produit avec une équipe d'ingénierie derrière. C'est l'équipe qui décide, pas le framework.
Je l'ai reconstruit sous WordPress avec Advanced Custom Fields Pro en environ six semaines. Ils le gèrent eux-mêmes depuis.
Cette histoire n'est pas un argument contre Next.js. C'est un argument contre choisir un outil avant d'avoir compris le problème. J'ai fait l'inverse aussi, j'ai fourni à un client un multisite WordPress alors qu'ils avaient besoin d'une véritable application pilotée par React, et je l'ai vu peiner dix-huit mois plus tard.
Après avoir construit plus de 12 000 sites chez Seahawk Media, j'ai arrêté de me soucier du framework qui « gagne ». Je me soucie de celui qui se livre, performe, et ne revient pas vous hanter à 23h un dimanche.
---
L'État Honnête des Deux Technologies en Ce Moment
WordPress alimente plus de 43 % du web entier. Ce chiffre est tellement répété qu'il a perdu son sens, mais prenez un instant pour y réfléchir. Quarante-trois pour cent. Ce n'est pas de l'inertie héritée, c'est l'effet réseau, l'écosystème de plugins, l'infrastructure d'hébergement, et deux décennies de savoir institutionnel intégré à chaque serveur partagé de la planète.
Next.js, lui, est devenu le framework React dominant pour les applications en production. Les données d'utilisation 2023 de Vercel ont montré qu'il traitait des centaines de milliards de requêtes par mois. L'App Router introduit dans Next.js 13 a changé la façon dont les gens pensent les composants serveur, et oui, ça a aussi cassé beaucoup de tutoriels publiés avant 2023, ce qui cause encore de la confusion dans les serveurs Discord partout.
Voici le truc : ces deux technologies ne sont pas vraiment des concurrents de la façon dont les débats sur Twitter les présentent. WordPress est un CMS avec une couche de thème. Next.js est un framework React avec intégration CMS optionnelle. Le diagramme de Venn de ce qu'ils savent vraiment faire bien a très peu de chevauchement une fois que vous devenez spécifique sur les exigences.
---
Où WordPress Est Véritablement Imbattable
Sites Riches en Contenu Gérés par des Non-Développeurs
Je vais être direct. Si votre client a une équipe marketing, un responsable de contenu, ou quelqu'un qui a besoin de publier sans toucher au code, WordPress est presque toujours la bonne réponse. L'éditeur Gutenberg, qu'on l'aime ou non (j'ai eu une relation compliquée avec depuis 2018), offre une expérience d'édition par blocs aux utilisateurs non techniques qui fonctionne réellement.
Rien dans l'écosystème React ne s'approche de l'expérience éditoriale de WordPress d'emblée. Sanity.io a un studio magnifique, Contentful est solide pour le contenu structuré, mais ni l'un ni l'autre n'a l'écosystème de plugins ou la familiarité avec les moteurs de recherche que WordPress a. L'embauche marketing moyenne a déjà utilisé WordPress. Elle n'a pas utilisé un CMS découplé.
Profondeur de l'Écosystème d'Extensions
WooCommerce, Yoast, Gravity Forms, WP Rocket, ACF Pro. Ce ne sont pas juste des plugins, ce sont des plateformes entières avec leurs propres écosystèmes. Quand Seahawk fait un projet e-commerce pour un client avec un catalogue modeste (disons, moins de 5 000 SKU), WooCommerce associé à un hébergement décent chez Kinsta ou WP Engine fonctionne très bien. On parle de temps de chargement sous les 2 secondes après mise en cache, gestion complète des stocks, récupération de paniers abandonnés, intégration Stripe, tout configuré en une après-midi.
Reproduire cette fonctionnalité dans un développement custom Next.js avec Shopify ou une couche de commerce headless ? Vous envisagez des semaines de temps de développement et des coûts de maintenance continus que la plupart des clients PME ne peuvent pas justifier.
Réalités budgétaires et calendaires
Honnêtement, la plupart des projets n'ont pas le budget pour une application React sur mesure. Un site WordPress bien construit avec un thème premium comme Kadence ou Blocksy, ACF pour les structures de données personnalisées, et WP Rocket pour la performance peut être livré en deux à quatre semaines et maintenu par presque n'importe qui. Ce n'est pas une limitation, c'est du pragmatisme.
---
Où Next.js mérite vraiment sa complexité
Interactivité et logique applicative
En 2022, Seahawk avait un projet fintech, un tableau de bord pour une entreprise d'analyse de crédit. Des flux de données en temps réel, des filtres complexes, un contrôle d'accès basé sur les rôles, des intégrations API avec trois fournisseurs de données différents. J'ai étudié WordPress headless pendant environ deux heures avant d'admettre que ce n'était pas du tout le bon outil. On l'a construit en Next.js avec NextAuth.js pour l'authentification et React Query pour la récupération des données. Il fonctionne toujours, il est toujours rapide, et la base de code est quelque chose à laquelle l'équipe interne du client peut réellement contribuer.
WordPress peut techniquement faire des choses ressemblant à des applications. Mais chaque fois que j'ai essayé de le pousser dans un vrai territoire dynamique, pensez à des formulaires multi-étapes avec une logique conditionnelle qui alimente des API externes, des tableaux de bord en temps réel, n'importe quoi nécessitant un état côté client fin, j'ai fini par combattre l'architecture plutôt que de travailler avec elle.
Performance à l'échelle sans dépendance aux plugins
Next.js avec Static Site Generation (SSG) ou Incremental Static Regeneration (ISR) peut produire des pages d'une rapidité presque embarrassante. Aucun plugin de cache requis. Aucun cadran de configuration WP Rocket. Les pages sont simplement... du HTML statique avec hydratation là où vous en avez besoin.
La documentation de Vercel sur ISR explique bien le mécanisme, mais l'implication pratique est celle-ci : un site Next.js pour une publication d'actualités avec 50 000 articles peut revalider les pages individuelles selon un calendrier sans reconstruire le site entier. C'est vraiment puissant et quelque chose que WordPress ne peut qu'approximer par la mise en cache de fragments.
Expérience développeur et composition d'équipe
Si vous êtes une agence avec une équipe de développement React native, le développement WordPress a une vraie courbe d'apprentissage qui est souvent sous-estimée. PHP, la hiérarchie des templates WordPress, l'architecture des hooks, le terrier des fonctions.php, ce n'est pas difficile, mais c'est différent. J'ai embauché des développeurs JS talentueux qui ont regardé une base de code de thème WordPress et se sont sentis perdus pendant les deux premières semaines.
Inversement, si votre équipe vit dans TypeScript et React, un projet Next.js avec un CMS découplé comme Contentful ou Sanity est un environnement plus confortable. Le code est testable, les types sont explicites, et le workflow de déploiement via Vercel ou Netlify est véritablement bon.
---
Le compromis WordPress découplé (Et ses problèmes réels)
Beaucoup d'agences se sont converties à « WordPress headless » comme compromis, WordPress comme backend CMS, Next.js comme frontend. L'argument semble parfait. L'équipe éditoriale garde son interface familière ; les développeurs obtiennent une stack frontend moderne.
En pratique ? C'est véritablement utile dans des situations spécifiques et un vrai casse-tête dans d'autres.
Les bons cas :
- Les grandes plateformes éditorialistes où le workflow éditorial est non-négociable mais la performance frontend est aussi une exigence stricte
- Les organisations déjà investies dans l'infrastructure WordPress qui veulent moderniser le frontend sans recycler les équipes de contenu
- Les sites avec des relations de contenu complexes qui bénéficient de la modélisation de données d'ACF mais qui ont besoin de React pour la couche de présentation
Les problèmes réels :
- WPGraphQL est excellent, mais déboguer la performance des requêtes GraphQL dans un contexte WordPress est douloureux. Vous ajoutez une couche de complexité qui peut vous mordre.
- La fonctionnalité d'aperçu pour les éditeurs, voir un brouillon de post sur le frontend Next.js, est une source constante de bugs. J'ai gaspillé des jours sur ceci à travers plusieurs projets.
- Héberger deux systèmes séparés signifie deux points de défaillance distincts, deux ensembles de coûts d'infrastructure, et deux pipelines de déploiement à maintenir.
- Les fonctionnalités en temps réel sont toujours maladroites. Vous n'obtenez pas les WebSockets d'une API REST WordPress sans travail supplémentaire important.
Le WordPress headless n'est pas un juste milieu magique. C'est une troisième option avec ses propres compromis, et elle n'a du sens que quand les exigences spécifiques justifient véritablement la complexité.
---
Comment je prends réellement la décision (Ma véritable checklist)
Après assez de projets, j'ai réduit cela à un ensemble rapide de questions que je me pose avant le deuxième appel client.
Pencher vers WordPress quand :
- Le client ou son équipe doit gérer le contenu de manière indépendante
- Le projet est principalement des pages de contenu et marketing (même complexes)
- Le budget est inférieur à £20K et la timeline est inférieure à huit semaines
- L'e-commerce est nécessaire mais le catalogue compte moins de ~10 000 produits
- Le client est déjà sur WordPress et la migration ne sert aucun objectif réel
Pencher vers Next.js quand :
- Le projet a des exigences interactives ou semblables à une application importants
- L'équipe est principalement composée de développeurs JS/React
- Vous avez besoin d'un contrôle précis sur la stratégie de rendu (SSG, SSR, ISR par route)
- Le système de design du frontend est sur mesure et piloté par des composants React
- Il y a une véritable raison d'intégrer un CMS headless moderne comme Sanity ou Contentful
- À long terme, le client veut posséder et étendre le frontend lui-même avec ses développeurs JS internes
Et quelques signaux d'alerte qui devraient vous faire hésiter indépendamment de la direction vers laquelle vous penchez :
- Un client exigeant Next.js parce qu'il a lu que c'était « plus moderne », ce n'est pas une exigence.
- Choisir WordPress parce que « c'est plus facile » alors que le projet a vraiment besoin d'une logique applicative
- Quiconque utilise l'expression « pérenne » comme justification sans expliciter ce que l'avenir exige réellement
---
Performance : Utilisons les vrais chiffres
C'est là que la conversation déraille souvent. Les gens brandissent les scores Lighthouse comme si c'était toute l'histoire.
Un site WordPress bien optimisé, un hébergement décent, WP Rocket ou FlyingPress, des images WebP, un thème bien construit, score régulièrement 90+ sur PageSpeed Insights. Seahawk a livré des sites WordPress à 95+ de façon constante. Ce n'est pas de la magie ; c'est juste une bonne configuration.
Une application Next.js mal configurée avec des récupérations de données côté client partout, des images non optimisées et aucune stratégie de cache appropriée obtient un score dans les 50. Je l'ai vu.
L'écart entre un « site WordPress rapide » et un « site Next.js rapide » est beaucoup plus étroit que ne le suggèrent les évangélistes du framework. La propre recherche Google Core Web Vitals montre que la technologie d'origine importe bien moins que la qualité de l'implémentation. Les goulots d'étranglement dans la plupart des sites mal performants sont les images, les ressources bloquantes de rendu et les temps de réponse du serveur, aucun de ces problèmes n'est inhérent à WordPress ou à Next.js.
Ce que Next.js offre réellement, c'est davantage de contrôle sur la performance. Vous pouvez prendre des décisions précises par route sur la façon dont les données sont récupérées et quand les pages sont rendues. Mais le contrôle ne vous aide que si vous l'exercez correctement.
---
SEO : WordPress a l'avantage de l'écosystème, pas l'avantage inhérent
Voici une idée fausse que je dois corriger régulièrement : WordPress n'est pas meilleur pour le SEO par nature. Les applications Next.js avec un rendu côté serveur approprié sont entièrement explorables par Google. Le composant <Head>, la génération de sitemap via next-sitemap, les données structurées via JSON-LD, tout est réalisable.
Ce que WordPress possède, c'est Yoast SEO ou Rank Math, qui donnent aux utilisateurs non techniques une interface visuelle pour gérer les méta titres, les descriptions, les URL canoniques et le balisage de schéma. C'est un avantage de flux de travail éditorial, pas un avantage technique.
Si le site sera géré par des développeurs qui comprennent les balises meta et les données structurées, le SEO Next.js n'est pas plus difficile à implémenter. Si le site a besoin qu'un consultant SEO ou un responsable marketing ajuste les titres de pages sans ouvrir un ticket, donnez-leur WordPress.
---
FAQ
WordPress n'est-il pas ancien et en train d'être remplacé par des frameworks modernes ?
WordPress est "en train de se faire remplacer" depuis au moins 2014, quand j'ai commencé à entendre cet argument sérieusement. Ça ne s'est pas produit et je ne m'attends pas à ce que ça arrive. La question n'est pas de savoir si WordPress est moderne, c'est de savoir s'il résout le problème que tu as. Pour un énorme pourcentage de sites web, c'est le cas. Automattic continue d'investir massivement dans Gutenberg et l'expérience Full Site Editing. C'est en évolution, juste pas de manière à faire vibrer les fils Twitter.
Pouvez-vous utiliser WordPress comme backend avec un frontend React ?
Oui, c'est du WordPress headless, et j'ai couvert les compromis ci-dessus. En bref : utilisez WPGraphQL ou l'API REST pour servir le contenu, construisez votre frontend avec Next.js. Ça marche. Ça ajoute aussi de la complexité. Ne le faites que si les exigences le demandent réellement, pas parce que ça semble architecturalement intéressant.
Combien de temps faut-il pour construire un site Next.js comparé à WordPress ?
Ça dépend vraiment de l'envergure, mais pour un site marketing comparable, Next.js prend généralement 40 à 60 % plus longtemps à développer pour la livraison initiale. Tu écris les composants à partir de zéro, tu mets en place un système de design, tu intègres un CMS, tu configures le déploiement. WordPress avec un thème premium et ACF te propulse beaucoup plus loin, plus rapidement. Là où Next.js te rembourse l'investissement en temps, c'est dans la scalabilité à long terme et l'ergonomie développeur, à condition que la composition de l'équipe le justifie.
Qu'en est-il d'Astro, Remix ou d'autres frameworks ?
C'est bon à savoir. Astro est particulièrement intéressant pour les sites statiques riches en contenu et j'ai expérimenté avec pour des projets plus petits chez Seahawk. Remix a un modèle de chargement de données convaincant. Mais ni l'un ni l'autre n'a la maturité écosystémique ou la familiarité client de WordPress, ni l'adoption en entreprise de Next.js. Pour la plupart des décisions d'agence en ce moment, c'est encore un choix WordPress-ou-Next.js avec tout le reste comme considération de niche.
Devrais-je toujours recommander le meilleur choix technique aux clients ?
Non. Le meilleur choix technique qu'une équipe client ne peut pas maintenir est pire que le deuxième meilleur choix qu'elle peut réellement utiliser. Je l'ai appris à la dure plus d'une fois. Livrez la solution qui fonctionne pour les humains impliqués, pas juste le diagramme architectural.
---
Le vrai savoir-faire, ce n'est pas connaître WordPress ou connaître Next.js. C'est savoir quand recourir à l'un ou à l'autre, et être honnête assez envers toi-même et tes clients pour prendre cette décision en fonction de leur réalité, pas de tes préférences.
Ce client immobilier de 2021 ? Toujours sur WordPress. Toujours en train de gérer ses propres annonces. Pas d'appels téléphoniques du dimanche soir de ma part.