WordPress fait tourner une part énorme du web, et pour de bonnes raisons : il est connu, souple, et les équipes savent s’en servir. Chez Mill, on l’utilise depuis nos débuts. Mais depuis quelques années, on ne l’utilise plus tout à fait de la même façon. On lui a coupé la tête. Je vous explique pourquoi, et pourquoi on vous conseillera souvent d’en faire autant.
Headless, ça veut dire quoi ?
Dans un WordPress classique, tout est dans le même bloc : le back-office où l’on écrit, la base de données, et le thème qui fabrique les pages que voit le visiteur. Pratique, mais tout est lié : un plugin mal fichu, un thème lourd, et c’est tout le site qui trinque.
En headless, on sépare les deux. WordPress reste là où il excelle : l’édition des contenus, le back-office que vos équipes connaissent. Le site public, lui, devient une application à part (chez nous, en Nuxt) qui vient chercher les contenus via l’API de WordPress.
WordPress, c’est la cuisine. Le site, c’est la salle. On ne sert plus les clients au milieu des casseroles.
Ce que ça change pour vos visiteurs
- La vitesse. Pages rendues côté serveur ou pré-générées, mises en cache au plus près du visiteur : le site s’affiche vite, même sur un mobile en bord de rivière avec une barre de réseau.
- Le référencement. Un HTML propre, complet dès le premier chargement, lisible par Google comme par les robots des IA. C’est exactement ce qu’on recommandait dans notre article sur le SEO et le GEO.
- L’accessibilité. On écrit chaque balise. Pas de constructeur de pages qui injecte des couches de code inutiles : le RGAA devient tenable, et vérifiable.
- L’expérience. Transitions, cartes interactives, filtres instantanés : le front fait ce qu’on veut, sans se battre avec un thème.
Ce que ça change pour vos équipes
Bonne nouvelle : presque rien. Vos rédacteurs gardent leur WordPress, leurs habitudes, leurs blocs Gutenberg. Chaque bloc correspond à un composant du site, dessiné et développé une fois pour toutes. Résultat : on ne peut plus « casser » la mise en page en collant un texte depuis Word, et le site reste cohérent même après trois ans de publications.
La seule chose qui change vraiment, c’est la prévisualisation : elle se met en place spécifiquement. On la prévoit dès le départ, pour que « Aperçu » montre bien le vrai site.
Ce que ça change pour la sécurité et la maintenance
En headless, WordPress n’est plus exposé directement au public. Le back-office peut vivre sur une adresse à part, à l’accès restreint. La surface d’attaque fond, et les mises à jour de plugins deviennent beaucoup moins stressantes : elles ne risquent plus de faire tomber le site que voient vos visiteurs.
Un site qui se branche partout
C’est l’argument qui nous a convaincus. Dans nos métiers, un site n’est jamais seul : il agrège des fiches Apidae, des disponibilités Millcheck, une billetterie, des offres d’emploi, des aides publiques. En headless, le front assemble toutes ces sources proprement, et le même contenu peut nourrir le site, une application, une borne ou un assistant IA.
Le portail du Département de l’Ardèche en est un bon exemple : WordPress headless connecté à MGDIS, Apidae et Job Affinity. Le site des Alpes-de-Haute-Provence aussi, éco-conçu et 100 % RGAA.
| WordPress classique | WordPress headless | |
|---|---|---|
| Rendu des pages | Par le thème PHP | Par une application dédiée (Nuxt) |
| Performance | Dépend du thème et des plugins | Rendu serveur, cache, très rapide |
| Sécurité | Back-office exposé | Back-office isolé |
| Liberté de design | Contrainte par le thème | Totale |
| Interconnexions | Plugin par plugin | Natives, via les API |
| Investissement initial | Plus léger | Plus important |
Les objections, honnêtement
Je ne vais pas vous vendre le headless comme la solution à tout. Il a un coût :
- Un investissement de départ plus élevé : deux briques à concevoir au lieu d’une.
- Deux applications à héberger et à maintenir, même si l’une des deux devient très simple.
- Certains plugins « front », constructeurs de pages ou formulaires tout faits, ne fonctionnent pas tels quels. Il faut les remplacer par des composants.
- Pour une vitrine de cinq pages mise à jour deux fois par an, c’est souvent trop. Un WordPress classique bien fait suffit, et on vous le dira.
Pourquoi c’est devenu un réflexe
Pour la plupart de nos projets, destinations, collectivités, portails de services, la question n’est plus « pourquoi le headless ? » mais « pourquoi pas ? ». Le headless s’impose si :
- Vos contenus vivent Actualités, agenda, offres, pages qui bougent chaque semaine : le confort d’édition de WordPress, sans ses lourdeurs côté visiteur.
- Vous consommez des données externes Apidae, disponibilités, billetterie, CRM, offres d’emploi : le front les assemble proprement, sans empiler les plugins.
- La performance et l’accessibilité comptent Un HTML qu’on maîtrise de bout en bout, c’est un site rapide et un RGAA qu’on peut vraiment tenir.
- Vous diffusez sur plusieurs canaux Site, application, borne, newsletter, assistants IA : un seul back-office, plusieurs sorties.
- Votre site doit durer Le jour où vous refaites le design, le back-office ne bouge pas. Et inversement.
Au fond, c’est une question de durée. Un design se démode, un back-office s’apprivoise. En les séparant, on peut faire évoluer l’un sans tout reconstruire. On change la tête, on garde la mémoire.
Votre site mérite-t-il de perdre la tête ? On en parle, sans jargon.