Un client m'a appelé début 2023, un éditeur médias avec environ 14 000 articles sur WordPress, un thème assemblé par quatre développeurs sur six ans, et un score Core Web Vitals véritablement gênant. Son LCP était à 7,2 secondes sur mobile. Ils avaient essayé WP Rocket, ils avaient essayé un CDN, ils avaient même supprimé la moitié de leurs plugins. Toujours lent. Le problème n'était pas WordPress lui-même. C'était que chaque rendu de page passait par PHP, un thème alourdi, et une chaîne de requêtes en base de données qui n'avait pas été regardée depuis 2018.
Point clé : WordPress headless avec Astro est le meilleur compromis pour les sites de contenu : wp-admin pour les éditeurs, front-end statique et rapide pour les visiteurs, et WPGraphQL qui relie les deux.
C'est à ce moment que j'ai vraiment adopté une architecture headless avec Astro comme frontend. Pas parce que c'est à la mode, mais parce que pour un site avec des milliers d'articles et du contenu éditorial lourd, c'était la seule architecture qui avait du sens.
Voici exactement comment je l'ai configuré. Les compromis, la vraie configuration, les points qui m'ont posé problème.
---
Pourquoi Astro et Pas Next.js
Je reçois souvent cette question. Next.js est la réponse évidente si vous avez déjà une équipe fortement orientée React ou si vous avez besoin d'interactivité côté client complexe. Mais pour les sites lourds en contenu ? Astro gagne, et ce n'est pas particulièrement serré.
Astro ne livre aucun JavaScript par défaut. Pour un blog, un site d'actualités ou un portail de documentation, c'est le bon défaut. Vous optez pour JavaScript où vous en avez besoin, plutôt que de vous débarrasser d'un bundle React de 200 ko que vous ne voulez principalement pas. La doc d'Astro sur l'hydratation partielle, ils l'appellent l'architecture Islands, l'explique mieux que je ne peux le faire en une phrase, mais en résumé : seules les parties interactives ont du JS. Le corps de l'article, l'en-tête, la barre latérale ? Du HTML statique.
J'ai construit un site de contenu juridique fin 2022 avec Next.js et WordPress. Assez rapide, mais le client n'arrêtait pas de demander pourquoi son score Lighthouse était 74 sur mobile quand « c'est censé être rapide maintenant ». Surcharge d'hydratation. Avec Astro, ce même type de site atteint maintenant régulièrement 95-98. Ce n'est pas de la vantardise, c'est juste ce que l'architecture vous donne gratuitement.
Ce qu'Astro n'est pas bon à faire
C'est important d'être honnête. Si votre site a besoin de personnalisation en temps réel, d'un panier d'achat lourd, ou de quelque chose qui dépend vraiment de l'état côté client sur plusieurs composants, Astro commence à sembler maladroit. Ce n'est pas une application React. Le motif Islands est puissant, mais c'est un modèle mental différent de la construction d'SPA. J'ai essayé de forcer un tableau de bord client dans un projet Astro mi-2023 et j'ai fini par revenir à Next.js en deux semaines. Sachez ce que vous construisez.
---
Configurer WordPress comme CMS découplé
WordPress est véritablement un bon backend découplé. L'API REST WP est livrée dans le cœur, elle est bien documentée, et votre équipe éditoriale n'a rien de nouveau à apprendre. Ce dernier point compte bien plus que les développeurs ne l'admettent généralement.
Voici la configuration que j'utilise :
- Installez WordPress sur un sous-domaine, j'utilise cms.yourdomain.com ou api.yourdomain.com. Gardez-le derrière une authentification basique ou au minimum restreignez le trafic public direct. Le frontend est yourdomain.com. Deux déploiements séparés.
- Installez le [plugin WPGraphQL](https://www.wpgraphql.com/), je préfère GraphQL à REST pour les sites de contenu parce que vous pouvez co-localiser vos requêtes avec vos composants et récupérer exactement les champs dont vous avez besoin. Pas de sur-récupération. L'API REST c'est bien, mais une fois que vous avez 15+ champs personnalisés par type de contenu, l'approche GraphQL est nettement plus propre.
- Installez Advanced Custom Fields (ACF) et l'extension WPGraphQL pour ACF. Cette combinaison rend WordPress véritablement flexible comme modèle de contenu headless, vous pouvez définir des données structurées par type de contenu, les exposer via GraphQL, et Astro les consomme proprement.
- Désactivez les commentaires, les emojis et le XML-RPC par défaut si vous ne l'avez pas déjà fait. Ceux-ci ajoutent une surcharge et une surface d'attaque dont vous n'avez pas besoin.
- Définissez les permaliens à quelque chose de sensé avant de commencer à construire. Les changer en milieu de projet une fois que vos routes Astro sont déjà en place, c'est vraiment pénible.
Une chose qui piège les gens : CORS. Par défaut, WordPress ne laissera pas votre serveur de développement Astro (fonctionnant sur localhost:4321) faire des requêtes vers votre installation WP. Mettez ceci dans le functions.php de votre thème ou un petit plugin utilitaire pendant le développement :
`` add_action('init', function() { header("Access-Control-Allow-Origin: *"); }); ``
Resserrez cela sur des origines spécifiques en production. Évidemment.
---
La Structure du Projet Astro
Je la garde opinée et cohérente d'un projet à l'autre. Après une douzaine ou so de constructions headless, c'est ce qui fonctionne :
`` src/ components/ layouts/ pages/ index.astro blog/ [slug].astro lib/ wpgraphql.ts ← toute la logique de requête WP vit ici styles/ ``
Le fichier lib/wpgraphql.ts est l'endroit où je centralise chaque fetch GraphQL. Pas d'appels fetch dispersés dans les fichiers de pages. Chaque requête est une fonction async nommée et exportée. Déboguer cela sur 14 000 articles quand quelque chose casse à 2h du matin, vous vous féliciterez vous-même plus tard.
Récupérer les articles au moment de la construction
getStaticPaths d'Astro est ton pain et beurre ici. Pour un blog avec des milliers d'articles :
`` export async function getStaticPaths() { const posts = await getAllPostSlugs(); // appelle WPGraphQL return posts.map(post => ({ params: { slug: post.slug }, })); } ``
getAllPostSlugs pagine à travers WPGraphQL en utilisant des curseurs after, la couche GraphQL de WordPress retourne 100 articles par défaut, donc pour 14 000 articles vous faites 140 requêtes au moment du build. Ça semble effrayant. En pratique, sur un serveur décent, le build complet s'exécute en environ 4-5 minutes. Tout à fait acceptable pour un site qui recompile quelques fois par jour.
---
Gérer les images sans perdre la tête
C'est le truc dont personne ne parle assez. WordPress stocke les URLs des images pointant vers votre sous-domaine CMS. Quand Astro construit en statique, ces images vivent toujours sur cms.yourdomain.com, ce qui signifie que les navigateurs de vos visiteurs les récupèrent depuis votre serveur WordPress, contournant potentiellement votre CDN.
Quelques façons de gérer cela :
- Cloudflare devant les deux domaines. L'option la plus simple. Proxy à travers Cloudflare yourdomain.com et cms.yourdomain.com, configurez un cache agressif sur /wp-content/uploads/*, et c'est bon.
- Utilisez un plugin de décalage de médias. J'aime bien WP Offload Media, il déplace les uploads vers S3 (ou un stockage compatible) et réécrit les URLs automatiquement. C'est l'approche que j'utilise pour tout site attendant un trafic sérieux. Votre serveur WordPress arrête complètement de servir les images.
- Le composant Image d'Astro. Pour les images que vous contrôlez au moment de la construction (images mises en avant récupérées via GraphQL), vous pouvez passer l'URL distante dans le composant <Image> d'Astro et il va optimiser, redimensionner, et les servir depuis votre sortie de construction. Ça marche brillamment. Ne fonctionne pas pour les images embarquées dans le HTML du corps du post, ça demande une passe différente.
Seahawk avait un client de contenu voyage l'année dernière, environ 8 000 posts, extrêmement chargé en images, moyenne de 12 images par article. Leur serveur WordPress se prenait des coups simplement par les requêtes d'images, même avec la configuration headless. Passer à S3 + CloudFront a réduit leur bande passante d'origine de 94%. Vraiment transformateur pour leur facture d'hébergement.
---
Builds Incrémentaux et le Problème du Rebuild
Voici un vrai problème avec la génération statique à l'échelle : votre éditeur publie une correction de post à 15h et doit attendre 5 minutes pour un rebuild complet. Ce n'est pas acceptable dans une salle de rédaction.
Quelques approches que j'ai utilisées :
Option 1 : Netlify ou Vercel avec ISR à la demande. Astro supporte le rendu côté serveur avec des adaptateurs, vous pouvez lancer Astro en mode hybride où la plupart des pages sont statiques mais certaines routes sont rendues à la demande. Pour un site d'actualités, je pré-rendrai souvent statiquement les 30 derniers jours de posts (trafic élevé, besoin de vitesse) et définirai les pages d'archive plus anciennes pour se rendre à la demande. Le meilleur des deux mondes.
Option 2 : Constructions partielles déclenchées par webhook. WordPress déclenche un webhook à la sauvegarde du post (facile avec le plugin WP Webhooks). Ce webhook frappe un hook de déploiement Netlify ou Vercel. La construction s'exécute, elle récupère seulement ce qui a changé. Ce n'est pas vraiment partial, Astro reconstruit quand même tout, mais si vous gardez votre construction rapide, 4 minutes c'est acceptable.
Option 3 : Utilisez simplement SSR pour tout. Déployez Astro avec l'adaptateur Node sur un VPS (j'utilise Hetzner pour ça, bon marché, rapide, fiable). Chaque page se rend à la demande, vous mettez en cache agressivement au niveau Nginx ou Cloudflare, et vous avez des mises à jour instantanées des posts. C'est ce que je ferais pour une vraie opération d'édition au-delà de 50 000 posts.
Pour être honnête ? La plupart des sites n'ont pas besoin de la complexité de l'Option 1 ou 3. Une reconstruction de 4 minutes déclenchée par un webhook, c'est bon pour 90 % des sites de contenu.
---
Performance : ce que vous obtenez réellement
Sur le projet d'éditeur du début, voici ce qui s'est passé après la migration Astro :
- LCP est passé de 7.2s à 1.1s sur mobile (testé avec WebPageTest depuis un nœud à Londres)
- Total Blocking Time est passé de ~800ms à 0ms (zéro JS par défaut, souvenez-vous)
- Leur rapport Core Web Vitals de Google Search Console est passé de 3 % d'URLs « Bon » à 91 % « Bon » en six semaines suivant le déploiement
- Les coûts d'hébergement ont baissé parce que leur serveur WordPress ne servait plus les pages, seulement les réponses API
Rien de magique là-dedans. C'est juste ce qui se passe quand on retire le rendu PHP du chemin critique et qu'on arrête de livrer un bundle JavaScript de theme de 400kb à chaque lecteur.
---
Les points qui vont vous piéger
Parlons franchement, des trucs que j'ai dû déboguer sur des projets réels :
- Les aperçus de brouillon. C'est vraiment pénible dans une architecture headless. L'aperçu natif de WordPress repose sur le rendu front-end. Vous avez besoin de construire un endpoint d'aperçu personnalisé dans Astro qui accepte un nonce d'aperçu WordPress et récupère le brouillon via WPGraphQL. Pas compliqué, mais ça prend une journée pour le faire correctement.
- Les redirections. Si l'ancien site avait des centaines de redirections dans .htaccess, elles vivent maintenant sur le serveur WordPress. Vous devez soit les reproduire dans la config d'Astro, soit garder WordPress accessible et faire un proxy sur des chemins spécifiques. J'ai fait les deux. Reproduire dans Astro est plus propre à long terme.
- La recherche. La recherche intégrée de WordPress est inutile dans une architecture headless. J'utilise Algolia avec le plugin WP Search with Algolia. Indexez vos articles dans WP, interrogez Algolia depuis un composant Astro Island. Ça marche bien.
- Menus et navigation. Les menus WordPress sont bizarrement délicats à exposer via WPGraphQL. La route wpgraphql-acf finit souvent par être plus propre, modélisez juste votre nav comme un répéteur ACF et c'est bon.
---
FAQ
Ai-je besoin de WPGraphQL ou puis-je simplement utiliser l'API REST ?
Vous pouvez tout à fait utiliser l'API REST, elle est intégrée au cœur de WordPress et ne nécessite aucun plugin supplémentaire. Pour les sites simples avec des types de contenu standard et des champs personnalisés minimalistes, c'est parfait. Là où GraphQL gagne sa place, c'est quand vous avez des modèles de contenu complexes avec de nombreux champs personnalisés par type. Pouvoir récupérer exactement les champs dont vous avez besoin en une seule requête, sans vous battre avec les paramètres _embed et les appels REST imbriqués, c'est du temps gagné sur chaque requête que vous écrivez. À vous de voir. Je trouve juste GraphQL plus propre au-delà d'un certain seuil de complexité.
Comment gérer l'authentification WordPress pour le contenu réservé aux membres ?
L'authentification JWT est l'approche standard. Installez le plugin JWT Authentication for WP REST API, émettez des tokens à la connexion, passez-les dans les en-têtes de votre requête GraphQL. Du côté Astro, vous géreriez cela avec une route SSR (pas statique) pour que le contenu spécifique à l'utilisateur soit récupéré côté serveur à chaque requête. N'essayez pas de faire cela de manière statique, c'est le chemin vers la folie.
N'est-ce pas exagéré pour un petit blog ?
Oui, probablement. Si vous avez moins de 500 articles et un seul éditeur, la charge de maintenir une architecture headless n'en vaut pas la peine. Utilisez simplement un bon thème WordPress, optimisez vos images, et passez à autre chose. Cette architecture s'amortit quand vous avez du volume, de la complexité éditoriale, ou des niveaux de trafic où la performance impacte réellement vos revenus.
À quoi ressemble la configuration d'hébergement en production ?
WordPress (CMS uniquement) sur un petit VPS ou un hébergement WordPress géré, j'utilise Kinsta ou Cloudways. Frontend Astro sur Vercel, Netlify, ou un VPS Hetzner avec Nginx selon le projet. Cloudflare en frontal de tout. Le coût mensuel total pour un site de contenu de taille moyenne est généralement entre 60 et 120 £, ce qui est souvent moins que ce que les clients payaient pour un hébergement WordPress tout-en-un qui peinait sous la charge.
---
Le résumé honnête est celui-ci : WordPress headless avec Astro est l'une des meilleures choses qui soit arrivée aux sites de contenu depuis un moment. Non pas parce que c'est nouveau, mais parce que l'écosystème a enfin rattrapé l'idée. WPGraphQL est stable, le système de build d'Astro est rapide, et les gains de performance sont réels et mesurables.
Mettez en place la bonne architecture au départ, en particulier votre stratégie d'images et votre approche de reconstruction, et vous passerez beaucoup moins de temps à combattre les incendies plus tard. C'est vraiment ça.