On a livré une cinquantaine de sites WordPress entre 2018 et 2023. Beaucoup ont bien tourné. Quelques-uns sont devenus des cauchemars. La balance n'a pas tenu — et depuis 2024, on ne propose plus WordPress à un nouveau client. Pas par snobisme tech. Par lassitude des mêmes patterns qu'on retrouve six mois après livraison.
Le problème n'est pas WordPress en soi
Le cœur de WordPress (le moteur, l'éditeur Gutenberg) est correct. Le problème, c'est l'écosystème de plugins qu'on est forcé d'empiler pour livrer un site moderne :
- Un page builder (Elementor, Bricks, Divi) — 80 à 200 ko de JS hydraté.
- Un SEO plugin (Yoast, Rank Math) — qui s'achète à 99 €/an pour avoir le schema.org et les sitemaps propres.
- Un cache (WP Rocket, LiteSpeed) — pour compenser les requêtes SQL qu'on a empilées sans le vouloir.
- Un optimiseur d'images (ShortPixel, Smush) — encore 49 €/an.
- Un security plugin (Wordfence) — parce que le core est une cible.
Et il faut maintenir tout ça. Une mise à jour de plugin casse un autre. Une mise à jour de PHP casse trois plugins. Le client appelle paniqué deux ans après — et on est censé débugger un thème custom qu'on n'a pas écrit.
Ce que Next 16 + un CMS headless change
Sur la même typologie de site (vitrine 10-20 pages + blog + formulaires), on a mesuré sur 8 projets :
| WordPress + builder | Next 16 + Payload | |
|---|---|---|
| JS initial hydraté | 280 — 450 ko | 90 — 150 ko |
| LCP mobile p75 | 2,8 — 4,1 s | 1,2 — 1,8 s |
| Coût hébergement/an | 120 — 600 € | 0 — 240 € (Vercel) |
| Plugins payants | 150 — 400 €/an | 0 € |
| Vulnérabilités/an | 4 — 12 CVE actives | 0 — 2 CVE actives |
| Lighthouse Perf | 55 — 85 | 95 — 100 |
Le hosting Next.js est moins cher, le code est moins lourd, les métriques sont meilleures, et il n'y a plus de plugin payant à reconduire chaque année.
"Mais le client veut éditer son site lui-même"
Argument numéro un en faveur de WordPress. Vrai en 2015. Faux en 2026.
Les CMS headless modernes (Payload, Sanity, Strapi, Tina) ont un back-office
plus clair que WordPress 6.x, avec des permissions plus fines, des champs
typés (pas de meta_key qui traîne), et des prévisualisations live qui
marchent vraiment.
On forme nos clients en 30 minutes — ils éditent leur site en autonomie. Aucun client de la nouvelle stack n'a demandé à revenir sur WordPress.
"Mais il y a déjà X milliers de templates WordPress"
Et c'est exactement ce qu'on essaie d'éviter. Un site basé sur un thème acheté à 49 $ ressemble à 4 000 autres sites. Le design éditorial, c'est ce qui distingue votre marque — pas un thème générique qu'on a customisé avec un plugin custom CSS.
Les cas où on continuerait à recommander WordPress
Trois contextes uniquement :
- Site éditorial massif (presse, magazine) qui a déjà sa logique d'édition WordPress depuis dix ans, plusieurs rédacteurs formés, et des workflows complexes. Le coût de migration ne se justifie pas.
- Communauté open-source avec contributeurs WordPress (un thème d'association ou de collectif maintenu collectivement).
- Site purement vitrine qui n'évoluera plus jamais et dont la performance n'a aucun enjeu. Cas rare.
Ce qu'on propose à la place
- Site vitrine → Next 16 + Payload CMS (admin en français, prévisualisation live, déploiement Vercel).
- E-commerce → Shopify Hydrogen ou Medusa, jamais WooCommerce.
- Blog éditorial → Notion ou Sanity en CMS, rendu Next 16 ISR.
- App métier → Next 16 full custom + Supabase ou Postgres dédié.
Le résultat : moins de plugins, plus de contrôle, moitié moins de maintenance sur trois ans selon notre suivi client.
Ce qu'on assume
Cette position ferme certaines portes. Des clients qui voulaient WordPress pour des raisons légitimes (équipe interne déjà formée, intégration avec un plugin métier précis) sont allés ailleurs. Tant mieux : un studio qui n'a pas d'avis n'est pas un studio.