Qu'est-ce qu'un site web traditionnel ?
Dans une architecture WordPress traditionnelle, le CMS gère simultanément le stockage des données, la logique métier et le rendu HTML. Concrètement :
- Le contenu (articles, pages, médias) est stocké dans une base de données MySQL
- Le thème PHP génère le HTML, le CSS et contrôle la mise en page
- Le visiteur reçoit directement le rendu produit par le serveur WordPress
- Modifier le design implique d'intervenir sur le thème, qui est couplé à la logique d'affichage du contenu
Ce couplage fort entre contenu et présentation signifie que toute modification visuelle nécessite de travailler dans le même environnement que la gestion de contenu.
Le concept "headless" : séparation back-end / front-end
L'architecture headless repose sur un principe de découplage : le CMS (back-end) ne gère plus que le stockage et la structuration du contenu, tandis qu'un ou plusieurs front-ends indépendants se chargent de l'affichage.
Le contenu reste dans WordPress et sa base de données. Plusieurs front-ends peuvent consommer ce contenu via une API. Chaque front-end dispose de sa propre stack technologique et de son propre design. Modifier un front-end n'a aucun impact sur les autres ni sur le back-end.
Pourquoi on appelle ça "headless" ?
Le terme "head" désigne la couche de présentation d'un CMS, c'est-a-dire le thème qui génère les pages HTML visibles par l'utilisateur. "Headless" signifie que cette couche de présentation a été retirée du CMS. Le back-end WordPress ne produit plus de HTML destiné aux visiteurs : il expose ses données via une API, et c'est une application front-end distincte qui prend en charge le rendu.
Principe de découplage
Le back-end (WordPress) diffuse le contenu sous forme de données structurées (JSON). Un ou plusieurs front-ends consomment ces données via l'API et les restituent chacun avec leur propre interface. Ce découplage permet de faire évoluer chaque couche indépendamment.
L'architecture headless en détail
L'évolution de WordPress vers le headless
WordPress existe depuis 2003 et propulse environ 40 % des sites web dans le monde. L'adoption de l'architecture headless répond à des besoins croissants en performance, en flexibilité de design et en distribution multi-canal.
40%
du web mondial
Part de marché de WordPress (W3Techs)
×3
plus rapide
Gain de performance moyen en architecture headless avec SSG
100%
de choix technologique
Aucune contrainte sur le framework front-end utilisé
Concrètement, qu'est-ce que ça change pour vous ?
Si vous gérez le contenu
L'interface d'administration WordPress reste identique. La rédaction, la publication et l'organisation du contenu ne changent pas. Seule la couche d'affichage est remplacée par un front-end moderne.
Si vous visitez le site
Les temps de chargement passent sous la seconde grâce au pré-rendu et à la distribution via CDN. L'interface est plus fluide et le design n'est plus contraint par un thème WordPress.
Si vous développez le site
Vous travaillez avec une stack front-end moderne (React, Next.js, TypeScript). Le code est découplé, testable et versionné indépendamment du back-end WordPress.
Les étapes pour passer au headless
Conserver WordPress comme CMS
Le contenu et l'interface d'administration restent en place. La base de données est préservée, aucune migration de contenu n'est nécessaire.
Activer l'API
WordPress expose nativement une API REST. Le plugin WPGraphQL peut être ajouté pour disposer d'un endpoint GraphQL, qui offre des requêtes plus ciblées et performantes.
Développer le front-end
Une application front-end est créée avec un framework comme Next.js. Elle consomme les données de l'API WordPress et gère le rendu des pages.
Connecter les deux couches
Le front-end effectue des requêtes vers l'API WordPress pour récupérer le contenu, puis génère les pages avec un design sur mesure, en SSG (Static Site Generation) ou SSR (Server-Side Rendering).
Continuer la lecture
Pour aller plus loin