Héberger WordPress sur Vercel (Headless) : Quand ça marche et quand ça ne marche pas

En 2021, un client m'a apporté un brief que j'avais entendu environ quarante fois : « On veut le backend WordPress que nos éditeurs connaissent, mais le site doit être rapide. Genre, vraiment rapide. » Il avait lu quelque chose sur l'architecture headless sur une page marketing de Vercel. Il était convaincu avant que je ne dise un mot. J'ai pris le projet, construit un frontend Next.js sur Vercel récupérant le contenu d'une API REST WordPress, et livré quelque chose de vraiment impressionnant. Les scores Lighthouse étaient beaux. Le client l'a adoré pendant environ trois mois.fast. Like, really fast." They'd read something about headless architecture on a Vercel marketing page. They were sold before I said a word. I took the project, built a Next.js frontend on Vercel pulling content from a WordPress REST API, and delivered something genuinely impressive. The Lighthouse scores were beautiful. The client loved it for about three months.

Puis leur responsable marketing a voulu ajouter un formulaire pop-up. Puis un plugin d'adhésion. Puis un chat en direct avec une logique conditionnelle liée aux catégories d'articles. Et lentement, discrètement, tout le système a commencé à craquer.

Ce projet m'a appris plus sur les vraies limites de WordPress headless que n'importe quel tutoriel ne l'aurait fait. Alors laissez-moi vous donner le tableau honnête.

Ce que « WordPress Headless sur Vercel » signifie réellement

Vaut mieux être précis ici, parce que les gens utilisent le terme sans rigueur.

Vous exécutez WordPress (généralement sur un serveur distinct, un hébergement géré comme Kinsta ou WP Engine, ou même un VPS bon marché) purement en tant que système de gestion de contenu. Aucun thème ne sert le frontend. À la place, votre application Next.js (ou Nuxt, ou Astro, ou SvelteKit) récupère le contenu via l'API REST WordPress ou WPGraphQL, puis Vercel construit et déploie ce frontend.Kinsta or WP Engine, or even a cheap VPS) purely as a content management system. No theme serves the frontend. Instead, your Next.js (or Nuxt, or Astro, or SvelteKit) app fetches content via the WordPress REST API or WPGraphQL, then Vercel builds and deploys that frontend.

Vercel n'héberge pas WordPress lui-même. Point final. WordPress nécessite PHP, une base de données (MySQL) et une exécution côté serveur. Vercel exécute des fonctions Node.js serverless et des fichiers statiques. Vous ne pouvez pas placer une installation WordPress sur Vercel de la même manière que vous la placeriez sur un serveur cPanel.

Donc quand quelqu'un dit « héberger WordPress sur Vercel », ce qu'il veut vraiment dire c'est : héberger le frontend sur Vercel, tandis que WordPress s'exécute ailleurs complètement. Cette distinction a une importance énorme, et je suis choqué de la fréquence à laquelle elle est passée sous silence dans les articles de blog.frontend on Vercel, while WordPress runs somewhere else entirely. That distinction matters enormously, and I'm shocked how often it gets glossed over in blog posts.

Quand cette architecture brille vraiment

Je veux être juste ici. J'ai livré des projets WordPress headless + Vercel dont je suis vraiment fier, et il existe des conditions spécifiques où l'architecture justifie sa complexité.

Sites éditoriaux ou médias à fort trafic

Seahawk avait un projet pour un éditeur de médias sportifs en 2022. Des dizaines de milliers de pages vues par jour, une équipe de contenu de douze personnes, des éditeurs qui refusaient catégoriquement de quitter WordPress. Nous avons construit un frontend Next.js sur Vercel avec la Régénération Statique Incrémentale (ISR) réglée sur des fenêtres de revalidation de 60 secondes. Un jour de grand match, le serveur WordPress d'origine ne bronchait à peine. Le réseau edge de Vercel a absorbé le pic de trafic sans une seule conversation sur la mise à l'échelle.

Pour les sites où le contenu change par lots (les articles sont publiés, pas modifiés toutes les deux minutes), ISR est un ajustement brillant. Vous obtenez la performance des fichiers statiques à la limite avec du contenu raisonnablement frais.

Sites qui ont besoin d'une flexibilité frontend extrême

Si votre designer veut des animations de défilement personnalisées, des transitions de composants complexes, ou un outil interactif basé sur React intégré au milieu de la page, un thème WordPress traditionnel vous oppose une résistance à chaque étape. Un frontend découplé redonne ce contrôle au développeur entièrement. Les contraintes de conception des thèmes WordPress disparaissent simplement.

Les équipes de développeurs déjà bien ancrées dans l'écosystème Node/React

Si votre équipe déploie des apps React toute la journée et traite PHP comme une langue étrangère, les forcer au développement de thèmes WordPress est vraiment pénible. Headless leur permet de rester dans leur univers tout en donnant aux éditeurs de contenu un outil qu'ils connaissent déjà. C'est un vrai gain de productivité pour la bonne équipe.

La Stack d'Outils que j'Utilise Réellement

Si je fais du headless WordPress + Vercel aujourd'hui, voici à quoi ressemble la stack :

1. Hébergement WordPress : Kinsta ou Cloudways. Les deux gèrent les sauvegardes MySQL managées sans que j'y pense. Kinsta or Cloudways. Both handle managed MySQL backups without me thinking about it.
2. Couche GraphQL : le plugin WPGraphQL. Il rend les requêtes de contenu bien plus propres que l'API REST pour les custom post types complexes. WPGraphQL plugin. It makes content queries far cleaner than the REST API for complex post types.
3. Framework frontend : Next.js. App Router si l'équipe est à l'aise, Pages Router si on a besoin d'une transition plus rapide vers quelqu'un de moins expérimenté. Next.js. App Router if the team is comfortable with it, Pages Router if we need a faster handoff to someone less experienced.
4. Déploiement : Vercel, évidemment. Les déploiements de prévisualisation par PR valent à eux seuls le prix d'admission. Vercel, obviously. Preview deployments per PR are worth the price of admission alone.
5. Revalidation à la demande : webhooks WordPress (via un plugin custom ou des hooks Advanced Custom Fields) qui pingent un endpoint de revalidation Vercel lors de la publication du contenu. WordPress webhooks (via a custom plugin or Advanced Custom Fields hooks) that ping a Vercel revalidation endpoint when content is published.
6. Aperçu du contenu : le package @wpengine/headless ou une configuration custom de draft mode Next.js pour que les éditeurs puissent prévisualiser les posts non publiés sans rebuilding. The @wpengine/headless package or a custom Next.js draft mode setup so editors can preview unpublished posts without a rebuild.

Ce dernier point sur les aperçus m'a pris bien plus de temps à faire fonctionner correctement que je ne suis à l'aise de l'admettre. Les éditeurs s'attendent à cliquer sur « Preview » dans WordPress et voir exactement ce qui sera publié. Avec une architecture découplée, câbler cela correctement demande une journée complète de travail.

Où Cela S'effondre (Et Cela S'effondre)

Bon. Voilà où je dois être honnête avec toi, parce que c'est la partie que la plupart des posts « headless, c'est l'avenir » évitent.

Les plugins. Tellement de plugins.

La puissance de WordPress vient de son écosystème de plugins. WooCommerce, Gravity Forms, les plugins d'adhésion, les systèmes de réservation, les outils SEO avancés comme Yoast (oui, Yoast fonctionne toujours, mais le rendu frontend de ses méta tags nécessite du câblage supplémentaire), les plugins de carrousel, tout ce qui touche au frontend. Dans une configuration traditionnelle, le plugin rend du PHP directement dans la page. Dans une configuration headless, il ne fait rien de visible à moins que tu aies explicitement créé un composant frontend pour reproduire son rendu.

J'avais un client fin 2023 qui m'a contacté en cours de projet (pas un projet Seahawk, le bazar de quelqu'un d'autre que j'ai hérité). Ils étaient passés au headless avec de bonnes intentions et ont ensuite essayé d'ajouter WooCommerce. Ce qui a suivi, c'est un détour de quatre mois pour construire un flux panier et paiement personnalisé en React, appeler l'API REST de WooCommerce, gérer les webhooks Stripe manuellement, et globalement réinventer des roues que WooCommerce avait déjà construites. Le coût en temps était environ trois fois supérieur à ce qu'une simple configuration WordPress + WooCommerce traditionnelle aurait coûté.

Le WooCommerce headless est faisable. WooCommerce a bien documenté son API REST. Mais « faisable » et « valable » sont des questions différentes.WooCommerce has documented their REST API well. But "doable" and "worth it" are different questions.

L'expérience d'aperçu ne correspond jamais tout à fait

J'ai lancé six ou sept projets WordPress headless maintenant et je n'ai jamais eu un seul client qui était entièrement satisfait du workflow d'aperçu. Il y a toujours un écart entre cliquer sur « Preview » dans WordPress et voir ce qui rend réellement. Parfois c'est un problème de cookie en mode brouillon. Parfois c'est le timing du cache ISR. Les éditeurs qui venaient d'une configuration WordPress traditionnelle trouvent cela désorientant, et les plaintes arrivent tranquillement mais de manière persistante.

Deux systèmes à maintenir

Cela semble évident, mais ça surprend vraiment les équipes. Vous gérez maintenant deux domaines d'infrastructure distincts : le serveur WordPress (avec ses propres mises à jour, correctifs de sécurité, conflits de plugins, sauvegardes de base de données) et le frontend Vercel (avec son propre pipeline de build, variables d'environnement, limites de fonctions serverless). Quand quelque chose se casse à 2h du matin, vous avez deux fois plus d'endroits où chercher.

Chez Seahawk, nous avons eu des projets où un plugin WordPress s'est mis à jour automatiquement et a silencieusement modifié la forme d'une réponse API REST, ce qui a cassé un composant frontend. Aucune erreur levée du côté WordPress. Juste un vide de contenu silencieux sur le site en direct. Ce genre de défaillance est franchement plus difficile à détecter qu'une erreur WordPress traditionnelle.

Le contenu en temps réel, c'est compliqué

Si votre site a du contenu qui change fréquemment (pensez aux scores en direct, aux cours des actions, aux commentaires générés par les utilisateurs, à tout ce qui a besoin d'une fraîcheur sub-minute), le modèle de revalidation d'ISR ne convient pas. Vous finissez par servir des données obsolètes ou en frappant votre backend WordPress à chaque requête, ce qui élimine une part significative de l'argument de performance.

Les Coûts : Ce que Personne ne Met dans la Proposition

Laissez-moi être concret sur l'argent et le temps, parce que j'ai vu des agences sous-enchérir massivement sur ces projets.

• Surcharge de build initiale : Budgétez au moins 30-40% de temps de développement supplémentaire comparé à une construction WordPress traditionnelle de complexité équivalente. Cet écart est réel. Je l'ai suivi sur plusieurs projets. Budget at least 30-40% more development time compared to a traditional WordPress build of equivalent complexity. That gap is real. I've tracked it across projects.
• Tarification Vercel : Le plan gratuit Hobby ne suffira pas pour du travail commercial. Pro est 20$/mois par siège, et les coûts de bande passante et d'exécution de fonctions serverless s'accumulent sur les sites à fort trafic. Faites les calculs avant de vous engager. The free Hobby plan won't cut it for commercial work. Pro is $20/month per seat, and bandwidth and serverless function execution costs stack up on high-traffic sites. Run the numbers before you commit.
• Hébergement WordPress : Vous avez toujours besoin d'un hôte géré fiable. C'est un autre 30-100$/mois selon le trafic. Votre narratif « d'hébergement statique bon marché » s'effondre donc rapidement. You still need a reliable managed host. That's another $30-100/month depending on traffic. So your "cheap static hosting" narrative falls apart quickly.
• Maintenance continue : Deux plateformes, deux ensembles de problèmes potentiels. Comptez au moins 20% de temps de retenue mensuelle supplémentaire comparé à une configuration WordPress gérée traditionnelle. Two platforms, two sets of potential problems. Factor in at least 20% more monthly retainer time compared to a traditional managed WordPress setup.

Quand je le recommanderais vraiment

Après tout ce que je viens de dire, voici les scénarios spécifiques où je dirais à un client que headless WordPress sur Vercel vaut les compromis :

• Le site est riche en contenu et orienté lecture : principalement des articles ou des pages d'atterrissage, pas des flux transactionnelscontent-heavy and read-heavy: mostly articles or landing pages, not transactional flows
• L'équipe de contenu connaît déjà WordPress et n'envisagera pas de changer de CMSalready knows WordPress and won't entertain switching CMS
• Les performances à l'échelle sont une véritable exigence métier, pas seulement un plus
• L'équipe de développement maîtrise React et les outils modernes JavaScript
• Il n'y a pas de dépendances complexes de plugins dans le cahier des charges, ou vous les avez explicitement écartées are in the brief, or you've explicitly scoped around them
• Un propriétaire technique à long terme est en place et comprend les deux côtés de la pile

Et voici les scénarios où je repousserais l'idée :

• Le client veut WooCommerce ou n'importe quelle fonctionnalité frontend dépendante d'un plugin
• L'équipe est petite et ne peut pas absorber la surcharge de maintenance de deux systèmes
• Les éditeurs ont besoin d'un workflow de prévisualisation rapide et familier, et il n'y a pas de budget pour le construire correctement
• Le site a des comptes utilisateur, de la personnalisation dynamique, ou des exigences de données en temps réel
• Le client le veut juste « parce que ça semble moderne »

Celle-là. Je l'entends plus souvent que je ne le devrais.

Des alternatives qui valent le coup d'être considérées en premier

Avant de se rabattre sur cette stack, je mettrais au moins ces options sur la table :

• WordPress traditionnel sur un bon hébergeur géré : Kinsta, Cloudways, ou Rocket.net avec un bon cache (WP Rocket ou Nginx FastCGI cache) vous donneront des scores Lighthouse dans les 90 sans découpler quoi que ce soit. J'ai vu ça surprendre des clients qui pensaient avoir besoin du headless juste pour être rapides. Kinsta, Cloudways, or Rocket.net with proper caching (WP Rocket or Nginx FastCGI cache) will get you Lighthouse scores in the 90s without decoupling anything. I've seen this surprise clients who assumed they needed to go headless just to be fast.
• Faust.js par WP Engine : Conçu spécifiquement pour WordPress headless, il gère une grande partie du boilerplate (mode de prévisualisation, authentification, routage) que vous construiriez autrement vous-même. Ça vaut le coup d'œil si vous êtes vraiment engagé dans cette architecture. Built specifically for headless WordPress, it handles a lot of the boilerplate (preview mode, authentication, routing) that you'd otherwise build yourself. Worth a look if you're committed to the architecture.
• Un CMS headless sur mesure : Si votre équipe n'a pas vraiment besoin de l'écosystème de plugins WordPress, quelque chose comme Sanity ou Contentful pourrait tout simplement être un meilleur choix pour un frontend Next.js hébergé sur Vercel. Pas de serveur PHP à maintenir du tout. If your team doesn't actually need WordPress's plugin ecosystem, something like Sanity or Contentful might just be a cleaner fit for a Vercel-hosted Next.js frontend. No PHP server to maintain at all.

---

FAQ

Puis-je vraiment déployer WordPress sur Vercel ?

Non. WordPress nécessite PHP et une base de données MySQL. L'infrastructure de Vercel est construite autour de fonctions serverless Node.js et de la diffusion de fichiers statiques. Vous pouvez déployer votre frontend Next.js (ou autre JavaScript) sur Vercel, et faire en sorte que ce frontend récupère le contenu d'une instance WordPress hébergée ailleurs, mais WordPress lui-même s'exécute sur un serveur séparé.

Est-ce que WordPress headless nuit à mon SEO ?

Pas intrinsèquement, mais cela peut être le cas si vous le configurez sans attention. Avec Next.js, vous bénéficiez du rendu côté serveur et de la génération statique, qui produisent tous deux du HTML entièrement rendu que les moteurs de recherche peuvent indexer sans problème. Les zones à risque sont la gestion des balises meta (la sortie de Yoast doit être explicitement consommée et rendue par votre frontend) et la génération du sitemap (vous voudrez créer une route sitemap dynamique dans Next.js qui récupère les données depuis WordPress). Si vous faites cela correctement, le SEO fonctionne bien.

Le plan gratuit de Vercel est-il suffisant pour un frontend WordPress headless ?

Pour un projet personnel ou un prototype, peut-être. Pour un site commercial, non. Le plan Hobby interdit l'usage commercial selon les conditions de Vercel, et vous atteindrez les limites d'invocation des fonctions serverless sur tout site ayant du vrai trafic. Budgétisez le plan Pro dès le départ.

Comment gérer le mode aperçu de WordPress dans Next.js ?

Next.js a un Draft Mode intégré (anciennement Preview Mode dans le Pages Router). Le pattern est : créer une route /api/preview dans Next.js qui définit un cookie d'aperçu, puis configurer un bouton « Preview » WordPress pour appeler cette route avec un token secret. Quand le cookie est présent, vos composants de page récupèrent le contenu brouillon directement depuis WordPress au lieu de la version statique mise en cache. WPGraphQL supporte nativement les requêtes de posts brouillons, c'est pourquoi je le préfère à l'API REST pour ce flux particulier./api/preview route in Next.js that sets a preview cookie, then configure a WordPress "Preview" button to call that route with a secret token. When the cookie is present, your page components fetch draft content directly from WordPress instead of the cached static version. WPGraphQL supports draft post queries natively, which is why I prefer it over the REST API for this particular flow.

Et les formulaires et pages de contact ?

Les formulaires font partie des migrations plugin-vers-headless les plus simples. Une soumission Gravity Forms peut être envoyée directement vers l'API REST de Gravity Forms. Sinon, abandonnez complètement les formulaires WordPress et utilisez quelque chose comme Netlify Forms (même si vous êtes sur Vercel) ou une intégration Formspree directe côté frontend. Honnêtement, pour les formulaires, je vais généralement droit à Formspree et c'est réglé en une après-midi.Formspree and call it done in an afternoon.

---

WordPress headless sur Vercel est une véritable architecture avec de vrais cas d'usage. Ce n'est pas une solution universelle et ce n'est pas un gadget. Les équipes qui en tirent le plus profit sont celles qui y sont allées les yeux ouverts sur ce qu'elles échangeaient, qui ont budgétisé le temps de build supplémentaire, et qui résolvaient un problème spécifique de performance ou de flexibilité. Si c'est le cas de votre projet, c'en vaut la peine. Sinon, épargne-vous la complexité.