WordPress headless : garder l’administration, changer la façade

Le WordPress découplé fait partie de ces sujets où l’enthousiasme technique précède souvent l’analyse. Découpler n’est pas une amélioration automatique : c’est un déplacement de complexité, de l’extension vers le code, du prestataire vers l’équipe. Cet article donne autant de raisons de ne pas le faire que de raisons de le faire, avec les deux points qui font réellement échouer les projets en pratique : la prévisualisation des brouillons et la reconstruction du socle de référencement.

Ce que veut dire découpler

Dans une installation classique, WordPress stocke le contenu, l’administre et fabrique les pages vues par le public. Dans une architecture découplée, il conserve les deux premiers rôles et abandonne le troisième. Un autre programme récupère le contenu et construit le site, soit à l’avance sous forme de pages statiques, soit à la volée sur un serveur.

Deux voies d’accès au contenu coexistent, et le choix entre elles a des conséquences pratiques.

• L’API REST, intégrée au cœur de WordPress depuis la version 4.7, en décembre 2016. Prévisible, documentée, disponible sans rien installer. Son défaut est de renvoyer des objets entiers là où vous ne vouliez que trois champs, et d’imposer plusieurs appels pour reconstituer une page complète. La documentation officielle de l’API REST en donne le détail.
• GraphQL, via l’extension WPGraphQL, devenue extension canonique de WordPress en octobre 2024, son auteur ayant rejoint Automattic. Elle permet de demander exactement les champs voulus, imbriqués comme l’interface les consomme, en une seule requête.

Règle simple : commencez avec l’API REST, et passez à GraphQL le jour où vous écrivez trois requêtes REST pour ce qui devrait être une seule question logique.

Les quatre bonnes raisons de le faire

1. La performance sur un site riche. Le front ne calcule plus rien à chaque visite : les pages sont produites une fois et servies depuis un cache en périphérie. Sur un site éditorial de plusieurs milliers d’articles, l’écart avec un WordPress classique mal mis en cache est spectaculaire, et il se mesure sur les signaux réellement perçus par les visiteurs.
2. La réduction de la surface exposée. L’administration peut vivre sur un domaine séparé, filtré, voire fermé au public. Les robots qui scannent en permanence les chemins d’administration n’ont plus rien à se mettre sous la dent sur le site visible.
3. La réutilisation du contenu. Le même fonds sert le site, une application mobile, un affichage en boutique, un partenaire qui consomme un flux. C’est l’argument le plus solide, et le seul qui justifie à lui seul l’investissement.
4. La liberté de conception du front. Plus de contrainte de thème, plus de compromis avec un constructeur de pages. On construit exactement l’interface voulue, avec la sobriété de code qu’on décide.

Les cinq raisons de ne pas le faire

1. La prévisualisation des brouillons devient un chantier. C’est le premier reproche des équipes éditoriales, et de très loin. Le bouton « Aperçu » ne fonctionne plus tout seul : il faut développer une route de prévisualisation qui va chercher le brouillon authentifié et le rend dans les gabarits réels. Tant que ce travail n’est pas fait, vos rédacteurs publient à l’aveugle.
2. Les extensions qui produisent du rendu cessent de fonctionner. Formulaires, carrousels, visionneuses d’images, boutons de partage, constructeurs de pages : tout ce qui générait du HTML côté WordPress est à refaire. Les extensions de référencement continuent de stocker les métadonnées, mais elles ne les affichent plus : c’est à votre front de les lire et de les écrire dans la page.
3. Le cache et son invalidation deviennent un sujet permanent. Il faut décider ce qui déclenche une reconstruction, à quelle granularité, et en combien de temps une correction de faute de frappe apparaît en ligne. Une réponse honnête à cette dernière question sépare les projets sérieux des autres.
4. Deux socles à maintenir. WordPress et ses extensions d’un côté, la chaîne de construction du front et ses dépendances de l’autre. Deux calendriers de mise à jour, deux surfaces de vulnérabilité, deux compétences.
5. La dépendance à un développeur augmente. Des évolutions que le client faisait seul, ajouter un bloc, changer une mise en page, réclament désormais une intervention technique et un déploiement.

Le découplage se justifie quand le gain dépasse ces cinq coûts. Pas avant, et pas parce que l’architecture est élégante.

Le front : Astro ou React, et pourquoi ce n’est pas la même décision

Les deux options répondent à deux besoins différents, et les confondre est l’erreur la plus fréquente.

Un site majoritairement éditorial, où l’interactivité se limite à un menu, un moteur de recherche et un formulaire, gagne à être produit sous forme de pages statiques. Astro a été conçu pour ce cas et documente son intégration avec WordPress : le JavaScript n’est envoyé que pour les composants qui en ont besoin, le reste est du HTML.

Un produit riche en interactions, espace personnalisé, tableau de bord, configurateur, relève d’une application React. La contrepartie est connue : sans rendu côté serveur, le contenu risque de n’être vu ni par les moteurs ni par les visiteurs à connexion lente. Le rendu côté serveur n’est donc pas une option de confort, c’est une condition de visibilité dès qu’une page doit être indexée. Si votre besoin réel est une application web sur mesure, la question du découplage devient secondaire : c’est l’application qui structure le projet.

Le point aveugle : le référencement d’un site découplé

C’est la partie que les devis oublient le plus souvent, et elle est entièrement chiffrable. En quittant les extensions de référencement, vous reprenez à votre charge tout ce qu’elles produisaient silencieusement :

• Balises de titre et méta descriptions, page par page, y compris sur les archives et la pagination.
• Adresses canoniques, sans lesquelles les pages paginées et filtrées se dupliquent.
• Plan de site XML, tenu à jour à chaque publication.
• Données structurées : article, fil d’Ariane, organisation, questions fréquentes.
• Flux de syndication, encore utilisé par de nombreux agrégateurs.
• Fichier d’exclusion des robots et balises d’indexation, cohérents entre les deux environnements.
• Plan de redirections, si les adresses changent au passage.
• Gestion des pages introuvables, avec le bon code de réponse et non une page vide en 200.
• Balises de partage social, qui ne sont plus générées par personne.

Rien d’insurmontable, mais rien de gratuit non plus : comptez une à deux semaines de travail dédié, à inscrire au devis. Un site découplé mal outillé de ce côté perd en visibilité ce qu’il gagne en vitesse, et le bilan net est négatif. Les fondations techniques du référencement restent les mêmes, elles changent seulement de main, tout comme les actions qui améliorent réellement le référencement.

Combien cela coûte en temps

Les ordres de grandeur ci-dessous concernent un site éditorial existant, de taille moyenne, migré vers un front découplé. Ils s’expriment en charge de travail, pas en montant.

Une seule question tranche vraiment le débat, et elle n’est pas technique : votre entreprise dispose-t-elle d’un accès durable à une compétence de développement ? Si la réponse est non, le découplage produira un site rapide pendant dix-huit mois, puis un site figé que plus personne n’ose toucher.

Notre position : préférer le chemin progressif

Dans la grande majorité des cas que nous rencontrons, le problème n’est pas WordPress, c’est la façon dont il a été construit. Un thème allégé, un cache de page correct, des images retraitées et un cache en périphérie devant le site produisent souvent le gain de vitesse recherché, pour une fraction de la charge de travail. WordPress reste un socle solide quand il est tenu proprement, et l’effet de la vitesse sur les conversions s’obtient sans changer d’architecture. Avant de trancher, il vaut la peine de comparer Astro et WordPress.

Quand cela ne suffit plus, nous préférons découpler une seule section, le magazine ou le catalogue par exemple, plutôt que le site entier. On mesure le gain réel, on apprend la chaîne de publication sur un périmètre limité, et on garde la possibilité de s’arrêter là. Le passage à l’ensemble ne se décide qu’ensuite, avec des chiffres. Vérifier d’abord si l’hébergement est le vrai goulot d’étranglement, ou poser un cache en périphérie et filtrage devant le site, évite parfois tout le débat.

Questions fréquentes

Le découplage améliore-t-il le référencement ?

Indirectement, par la vitesse et la stabilité d’affichage. Il peut aussi le dégrader nettement si les éléments techniques ne sont pas reconstruits : titres, canoniques, plan de site, données structurées et gestion des pages introuvables.

Peut-on garder une boutique en découplé ?

Oui techniquement, WooCommerce expose ses données par API. Mais le tunnel de commande, les paiements, les taxes et les frais de livraison deviennent un projet à part entière, à chiffrer séparément du reste. La partie catalogue, elle, est un problème résolu : notre thème Nalu, dans nos thèmes Astro, lit la Store API publique de WooCommerce à la compilation, sans extension ni clé, et rend les rayons, les filtres, les variations et les fiches produit. Reste à trancher la caisse, qui est la vraie question.

Mes rédacteurs verront-ils un aperçu ?

Seulement si la prévisualisation est développée explicitement, avec une route dédiée qui récupère le brouillon authentifié. C’est à budgéter dès le départ, sous peine de faire travailler l’équipe éditoriale à l’aveugle.

Est-ce réversible ?

Oui, et c’est le principal atout de cette architecture : le contenu reste dans WordPress, structuré et exportable. Revenir à un thème classique est un travail de façade, pas une migration de données.

Ce qu’il faut retenir

Découplez quand le contenu doit servir ailleurs que sur un seul site, ou quand la performance conditionne directement le chiffre d’affaires. Dans tous les autres cas, un WordPress bien construit et bien mis en cache suffit largement. Avant toute décision, faites mesurer l’état réel de votre site : la moitié des projets de découplage se règlent par un audit et deux jours d’optimisation.

À lire aussi : concevoir un site léger et rapide

Étudier une architecture découpléeFaire auditer mon site actuel