Vos équipes gardent leur interface, le site change de moteur

Ce qu’un CMS classique fait en même temps

Un CMS traditionnel range votre contenu et fabrique la page au moment où le visiteur la demande. Les deux dans le même logiciel, sur le même serveur, avec les mêmes extensions. C’est simple, et c’est ce qui explique le succès de WordPress.

C’est aussi ce qui crée trois problèmes le jour où le site prend de l’importance : chaque visite coûte du calcul, la partie publique expose l’administration et ses extensions, et le contenu n’est réutilisable que sous forme de pages web.

Découpler, sans changer d’outil d’écriture

Une approche headless — littéralement « sans tête » — coupe le CMS en deux. Il garde la gestion du contenu et l’interface d’administration ; il cesse de fabriquer les pages. Celles-ci sont produites à l’avance par un autre outil, qui lit le contenu par une interface de programmation.

Le point important est ce qui ne change pas : ceux qui écrivent gardent l’écran qu’ils connaissent. Une refonte technique qui oblige la personne chargée du contenu à réapprendre son métier échoue à l’usage, quelle que soit sa qualité par ailleurs.

WordPress fait très bien la tête coupée

C’est la réponse la plus pragmatique et celle que nous employons le plus souvent. Gatsby, par exemple, se branche facilement sur WordPress, dont il récupère alors la gestion de contenu et l’interface d’administration. Astro sait faire de même.

Vous conservez donc un outil d’édition que tout le monde connaît, que n’importe quel prestataire saura reprendre, et dont la documentation existe en français — tout en obtenant un site public qui n’a plus rien de WordPress.

C’est aussi une voie de refonte : un WordPress existant dont le contenu est bon n’a pas à être jeté. Il devient le CMS headless, et seul le site public est refait.

Rapide par nature

Un site headless est rapide sans qu’on ait à le rendre rapide. Les pages sont produites une fois, à la publication : au moment de la visite, il n’y a plus ni requête en base de données ni page à assembler, seulement un fichier prêt à partir. Les images, les styles et les scripts sont optimisés au même moment — redimensionnés, compressés, réduits à ce que la page utilise vraiment.

Et comme ces pages sont de simples fichiers, elles se placent très bien derrière un CDN, un réseau de serveurs répartis dans le monde qui garde une copie du site au plus près de chaque visiteur. Avec notre partenariat Cloudflare, votre site est servi très rapidement partout — à Nantes comme à Montréal — sans que le serveur d’origine travaille davantage.

Et pour une boutique en ligne

Le principe vaut aussi pour le commerce. Le back-office de la boutique continue de gérer le catalogue, les stocks et les commandes ; la vitrine que voient vos clients est générée à l’avance, et profite de la même vitesse et de la même sécurité. Seules les parties qui doivent rester interactives — panier, filtres, recherche, paiement — passent par des API.

Un prix ou un stock qui change souvent se lit directement depuis le navigateur, pour rester exact en temps réel ; le reste de la fiche produit est déjà prêt. Le détail est sur notre page e-commerce headless.

Classique ou headless : ce qui change

	CMS classique	CMS headless
Vitesse	La page est calculée à chaque visite	La page est prête avant la visite, et servie par un CDN au plus près du visiteur
Sécurité	Base de données, extensions et page de connexion exposées	Rien de tout cela côté public ; l’administration peut n’être joignable que depuis vos locaux
En cas de faille	Tout le site exécute le code vulnérable : il faut corriger dans l’urgence, ou le couper	Seule l’API concernée est coupée ; le site reste en ligne, en mode dégradé
Contenu	Réutilisable sous forme de pages web	Accessible par API : un site, une application, un écran en boutique
Publication	Immédiate	Après régénération des pages concernées, en quelques instants
Systèmes à tenir	Un seul	Deux : le CMS et le site public

Un site qui reste en ligne pendant une faille

Une faille n’est exploitable que là où du code s’exécute. Sur un CMS classique, chaque page passe par le langage du serveur : chaque adresse du site est une porte d’entrée possible, et une faille dans ce langage touche le site entier.

Avec des pages générées à l’avance, le code dynamique se réduit à quelques API bien délimitées : le formulaire de contact, la recherche, le paiement. Le jour où une faille est publiée, on coupe la seule API concernée le temps de corriger — le formulaire invite alors à appeler ou à écrire — et le reste du site continue de fonctionner, en mode dégradé plutôt que hors ligne.

C’est aussi vrai pour un site simple, et c’est même là que l’avantage est le plus net : quelques pages et un formulaire de contact n’ont pas besoin d’un langage serveur à chaque visite. Nous l’avons détaillé dans notre article sur les failles PHP et les pages statiques.

Le compromis

Le prix de l’approche tient en deux lignes du tableau : deux systèmes au lieu d’un, et un court délai de publication. Cela se traite — régénération ciblée plutôt que du site entier — mais c’est un point à décider en début de projet, pas à découvrir en cours de route.

Sur un site de vingt pages mis à jour trois fois par an, un CMS headless complet est rarement justifié. Générer les pages à l’avance et isoler le formulaire dans une API, en revanche, l’est presque toujours : c’est simple, et c’est ce qui garde le site en ligne le jour d’une faille. Nous vous dirons laquelle des deux approches vous convient.