Un client m'a appelé en 2021 — une agence immobilière, un budget convenable, venait de licencier son ancienne agence. La demande était simple : reconstruire leur portail d'annonces. Le développeur sortant avait passé huit mois à mettre en place une application Next.js sur mesure. C'était brillant en démo. Impossible à mettre à jour par une seule personne de leur équipe sans une pull request et un pipeline de déploiement. L'agent immobilier gérant les annonces utilisait un Google Sheet comme solution de 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.WordPress wins when editors need autonomy and content changes daily; Next.js wins when the site is a product with engineering behind it. The team decides, not the framework.
Je l'ai reconstruit sous WordPress avec Advanced Custom Fields Pro en environ six semaines. Ils le gèrent eux-mêmes depuis.WordPress with Advanced Custom Fields Pro in about six weeks. They've been managing it themselves ever since.
Cette histoire n'est pas un argument contre Next.js. C'est un argument contre le choix d'un outil avant de comprendre le problème. J'ai fait l'inverse aussi — j'ai confié à un client un multisite WordPress quand ils avaient besoin d'une véritable application React, et j'ai vu ça fléchir sous la pression 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.Seahawk Media, I've stopped caring about which framework "wins." I care about which one ships, performs, and doesn't come back to haunt you at 11pm on a Sunday.
---
L'État Honnête des Deux Technologies en Ce Moment
WordPress alimente un peu plus de 43% du web entier. Ce chiffre circule tellement souvent qu'il a perdu son sens, mais prenez-le en compte une seconde. 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 connaissance institutionnelle intégrées dans chaque serveur mutualisé sur la planète.
Next.js, quant à 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 sur les serveurs Discord partout.Vercel's 2023 usage data showed it processing hundreds of billions of requests a month. The App Router introduced in Next.js 13 changed how people think about server components -- and yes, it also broke a lot of tutorials published before 2023, which is still causing confusion in Discord servers everywhere.
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 quiconque a besoin de publier sans toucher au code — WordPress est presque toujours la bonne réponse. L'éditeur Gutenberg, qu'on l'aime ou qu'on le déteste (j'ai eu une relation compliquée avec lui depuis 2018), donne aux utilisateurs non techniques une expérience d'édition par blocs qui fonctionne réellement.anyone who needs to publish without touching code -- WordPress is almost always the correct answer. The Gutenberg editor, love it or loathe it (I've had a complicated relationship with it since 2018), gives non-technical users a block-based editing experience that actually works.
Rien dans l'écosystème React n'arrive à proximité de l'expérience éditoriale de WordPress prête à l'emploi. 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. Un responsable marketing moyen a déjà utilisé WordPress. Ils n'ont pas utilisé un CMS headless.Sanity.io has a beautiful studio, Contentful is solid for structured content -- but neither has the plugin ecosystem or the search-engine familiarity that WordPress has. Your average marketing hire has used WordPress before. They haven't used a headless CMS.
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 sur Kinsta ou WP Engine se débrouille bien. On parle de temps de chargement inférieur à 2 secondes après mise en cache, gestion complète des stocks, récupération des paniers abandonnés, intégration Stripe — tout configuré dans l'après-midi.Kinsta or WP Engine handles it fine. We're talking sub-2-second load times after caching, full stock management, abandoned cart recovery, Stripe integration -- all configured in an afternoon.
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 société 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 examiné WordPress headless pendant environ deux heures avant d'admettre que c'était complètement le mauvais outil. Nous l'avons construit en Next.js avec NextAuth.js pour l'authentification et React Query pour le chargement 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 de type application. Mais chaque fois que j'ai essayé de le pousser dans un vrai territoire dynamique -- pensez à des formulaires multi-étapes avec une logique conditionnelle alimentant des API externes, des tableaux de bord en temps réel, n'importe quoi nécessitant un état côté client granulaire -- 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. explains the mechanism well, but the practical implication is this: a Next.js site for a news publication with 50,000 articles can revalidate individual pages on a schedule without rebuilding the entire site. That's genuinely powerful and something WordPress can only approximate through fragment caching.
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 véritable courbe d'apprentissage qui est souvent sous-estimée. PHP, la hiérarchie de templates WordPress, l'architecture des hooks, le trou de lapin functions.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.functions.php rabbit hole -- it's not hard, but it is different. I've hired talented JS developers who looked at a WordPress theme codebase and felt lost for the first two weeks.
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 ont opté pour « WordPress headless » comme compromis -- WordPress comme backend CMS, Next.js comme frontend. Le discours semble parfait. L'équipe éditoriale garde son interface familière ; les développeurs obtiennent une pile 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 :good cases:
- 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 :actual problems:
- 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. is excellent, but debugging GraphQL query performance in a WordPress context is painful. You're adding a layer of complexity that can bite you.
- 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 là-dessus sur 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 :red flags that should make you pause regardless of which direction you're leaning:
- Un client exigeant Next.js parce qu'il a lu que c'est « 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 correctement construit -- marque régulièrement 90+ sur PageSpeed Insights. Seahawk a livré des sites WordPress à 95+ de manière constante. Ce n'est pas de la magie ; c'est juste une configuration appropriée.
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 le suggèrent les évangélistes du framework. Les propres recherches de Google sur les Core Web Vitals montrent que la technologie d'origine importe beaucoup moins que la qualité de la mise en œuvre. Les goulots d'étranglement dans la plupart des sites peu performants sont les images, les ressources bloquant le rendu et les temps de réponse du serveur -- aucun d'entre eux n'est intrinsèquement un problème WordPress ou Next.js.Google's own Core Web Vitals research shows that origin technology matters far less than implementation quality. The bottlenecks in most poorly performing sites are images, render-blocking resources, and server response times -- none of which are inherently WordPress or Next.js problems.
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.more control over performance. You can make precise decisions per-route about how data is fetched and when pages are rendered. But control only helps you if you exercise it correctly.
---
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 intrinsèquement meilleur pour le SEO. Les applications Next.js avec un rendu approprié côté serveur sont entièrement exploitables par Google. Le composant <Head>, la génération de sitemap via next-sitemap, les données structurées via JSON-LD -- c'est tout réalisable.<Head>component, sitemap generation via next-sitemap, structured data via JSON-LD -- it's all achievable.
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 à mettre en œuvre. Si le site a besoin d'un consultant SEO ou d'un responsable marketing pour ajuster les titres de page sans déposer un ticket -- donnez-leur WordPress.
---
FAQ
WordPress n'est-il pas ancien et en train d'être remplacé par des frameworks modernes ?
WordPress se fait "remplacer" depuis au moins 2014, quand j'ai commencé à entendre cet argument sérieusement. Ça ne s'est pas produit et je ne m'y attends pas. La question n'est pas si WordPress est moderne -- c'est si WordPress 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. Ça évolue, juste pas de façons qui excitent 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 véritablement de la portée, mais pour un site marketing comparable, Next.js prend typiquement 40-60% plus longtemps à construire pour la livraison initiale. Tu écris des composants de zéro, tu configures un design system, tu intègres un CMS, tu paramètres le déploiement. WordPress avec un thème premium et ACF te mène beaucoup plus loin, plus vite. Là où Next.js rembourse l'investissement en temps, c'est dans la scalabilité à long terme et l'ergonomie développeur -- à condition que la composition d'équipe la 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.
---
La véritable compétence n'est pas connaître WordPress ou connaître Next.js. C'est savoir quand utiliser l'un ou l'autre -- et être honnête assez avec toi-même et tes clients pour prendre cette décision basée sur leur réalité, pas 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.