Un client m'a appelé en 2021 — une agence immobilière, budget correct, venait de renvoyer son ancienne agence. Le brief était simple : reconstruire son 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. Impossible à mettre à jour par une seule personne de son équipe sans une pull request et un pipeline de déploiement. L'agent immobilier gérant les annonces utilisait une Google Sheet comme contournement.
Je l'ai reconstruit en WordPress avec Advanced Custom Fields Pro en environ six semaines. Ils la gèrent eux-mêmes depuis.Advanced Custom Fields Proin 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 d'avoir compris le problème. J'ai fait l'inverse aussi — livré à un client un WordPress multisite alors qu'il avait besoin d'une véritable application pilotée par React, et regardé ça s'effondrer sous la pression dix-huit mois plus tard.
Après avoir construit 5 000+ sites chez Seahawk Media, j'ai arrêté de me soucier de quel framework « gagne ». Je me soucie de celui qui livre, qui performe, et qui ne revient pas te 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 % de l'ensemble du web. Ce chiffre circule tellement souvent qu'il a perdu de son sens, mais prenez un moment pour le considérer. Quarante-trois pour cent. Ce n'est pas de l'inertie héritée du passé — c'est l'effet réseau, l'écosystème des extensions, l'infrastructure d'hébergement, et deux décennies de connaissances institutionnelles intégrées dans 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 aux composants serveur — et oui, cela a aussi cassé beaucoup de tutoriels publiés avant 2023, ce qui cause encore de la confusion sur 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 gestionnaire de contenu, ou n'importe qui ayant 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 entretenu une relation compliquée avec lui depuis 2018), offre aux utilisateurs non techniques une expérience d'édition par blocs qui fonctionne réellement.anyonewho 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 ne s'approche 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 aucun des deux n'a l'écosystème d'extensions ou la familiarité avec les moteurs de recherche que WordPress possède. L'embauche marketing moyenne a utilisé WordPress avant. Elle n'a pas utilisé un CMS headless.
Profondeur de l'Écosystème d'Extensions
WooCommerce, Yoast, Gravity Forms, WP Rocket, ACF Pro. Ce ne sont pas simplement des plugins — ce sont des plateformes entières avec leurs propres écosystèmes. Quand Seahawk réalise un projet e-commerce pour un client avec un catalogue modeste (disons, moins de 5 000 SKU), WooCommerce associé à une bonne infrastructure d'hébergement chez Kinsta ou WP Engine fonctionne parfaitement. On parle de temps de chargement inférieurs à 2 secondes après mise en cache, gestion complète des stocks, récupération de panier abandonné, intégration Stripe — tout configuré en une après-midi.Kinstaor 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 à peu près 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. Flux de données en temps réel, filtrage complexe, contrôle d'accès basé sur les rôles, intégrations API avec trois fournisseurs de données différents. J'ai envisagé WordPress headless pendant environ deux heures avant d'admettre que c'était complètement le mauvais outil. On l'a construit en Next.js avec NextAuth.js pour l'authentification et React Query pour la récupération de données. C'est toujours en production, toujours rapide, et la base de code est quelque chose à laquelle l'équipe interne du client peut vraiment contribuer.
WordPress peut techniquement faire des choses ressemblant à une application. Mais chaque fois que j'ai essayé de le pousser vers un territoire vraiment dynamique — pensez à des formulaires multi-étapes avec logique conditionnelle alimentant des API externes, des tableaux de bord en temps réel, n'importe quoi exigeant un état client-side à grain fin — j'ai fini par me battre contre 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 des pages individuelles selon un calendrier sans reconstruire l'ensemble du site. C'est véritablement puissant et quelque chose que WordPress ne peut qu'approximer par le 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 souvent sous-estimée. PHP, la hiérarchie des templates WordPress, l'architecture des hooks, le terrier des 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 les deux premières semaines.functions.phprabbit hole — it's not hard, but itisdifferent. 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 se sont orientées vers le « WordPress découplé » 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 :goodcases:
- 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 vrais problèmes :actual problems:
- WPGraphQL est excellent, mais déboguer la performance des requêtes GraphQL dans un contexte WordPress est pénible. Vous ajoutez une couche de complexité qui peut vous poser problème.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, quelle que soit la direction vers laquelle vous penchez :red flagsthat 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 bon hébergement, WP Rocket ou FlyingPress, des images WebP, un thème correctement construit — obtient régulièrement un score de 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 ne le suggèrent les évangélistes des frameworks. La propre recherche de Google sur Core Web Vitals montre que la technologie d'origine compte bien moins que la qualité de l'implémentation. Les goulets d'étranglement dans la plupart des sites peu performants sont les images, les ressources bloquantes du rendu et les temps de réponse du serveur — aucun d'entre eux n'est un problème inhérent à WordPress ou Next.js.Google's own Core Web Vitals researchshows 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 véritablement, c'est plus de contrôle sur les performances. Vous pouvez prendre des décisions précises par route concernant 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 controlover 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 régulièrement corriger : WordPress n'est pas intrinsèquement meilleur pour le SEO. Les applications Next.js avec un rendu côté serveur approprié sont entièrement rastreables 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 vianext-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, l'SEO avec Next.js n'est pas plus difficile à implémenter. Si le site a besoin d'un consultant SEO ou d'un responsable marketing pour ajuster les titres de page sans créer un ticket — choisissez WordPress.
---
FAQ
WordPress n'est-il pas ancien et en train d'être remplacé par des frameworks modernes ?
WordPress est « en train d'être remplacé » au moins depuis 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 vous avez. Pour une énorme proportion de sites web, c'est le cas. Automattic continue d'investir massivement dans Gutenberg et l'expérience Full Site Editing. Il évolue, simplement pas de manière à exciter 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 la portée, mais pour un site marketing comparable, Next.js prend généralement 40–60 % plus de temps à construire pour la livraison initiale. Vous écrivez des composants à partir de zéro, configurez un design system, intégrez un CMS, configurez le déploiement. WordPress avec un thème premium et ACF vous permet d'avancer beaucoup plus loin, plus rapidement. Où Next.js rembourse l'investissement en temps, c'est dans l'évolutivité à long terme et l'ergonomie des développeurs — à 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 utiliser l'un ou l'autre — et être honnête assez avec soi-même et ses clients pour prendre cette décision en fonction de leur réalité, pas de vos 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.