Qu'est-ce qu'un CMS headless, et quand en avez-vous réellement besoin ?
Un CMS headless sépare le contenu de la présentation — et pour un site vitrine de cinq pages, c'est le mauvais outil. Voici quand il rapporte vraiment.
Un CMS headless stocke votre contenu et le livre via une API. Il ne rend pas de pages. Il n'y a ni thème, ni gabarit, ni interface — cette partie-là, c'est vous qui la construisez.
C'est toute la définition. Tout le reste de cet article porte sur la question de savoir si c'est un bon compromis pour vous, et l'essentiel de la réponse honnête est « ça dépend du nombre d'interfaces que vous avez ».
Dans un CMS traditionnel — WordPress, Drupal, la plupart de ceux que vous avez utilisés — le stockage du contenu et le rendu des pages vivent dans le même système. Vous rédigez un article, le CMS le met dans une base de données, et le même CMS le transforme en HTML à l'aide d'un thème. Pratique, et indissociable.
« Headless » signifie retirer la moitié rendu. Ce qu'il reste, c'est :
un endroit pour définir des types de contenu et leurs champs
un éditeur pour les personnes qui rédigent
une API qui renvoie du contenu structuré — du JSON, pas du HTML
Le compromis est net. Vous perdez le site web gratuit. Vous gagnez un contenu qui n'a pas la forme d'une page web, et qui peut donc être utilisé par des choses qui ne sont pas des pages web.
Vous rencontrerez les deux mots. À la lettre, un CMS découplé livre tout de même une couche de rendu que vous pouvez choisir d'utiliser ; un CMS headless n'en a aucune. En pratique, on les emploie de manière interchangeable, et la distinction change rarement une décision.
La question qui vaut la peine d'être posée à propos de n'importe quel produit est plus simple : peut-il rendre une page ? Si oui, passer au headless avec lui revient à faire tourner un moteur de rendu puis à en ignorer la sortie.
Vous avez plus d'une interface. Un site web, une application iOS, une borne, un partenaire qui veut un flux. Dans un CMS traditionnel, le second consommateur est un problème de scraping. Dans un CMS headless, c'est un second client d'API.
Vous avez plus d'un projet. Une agence avec dix clients, un groupe avec cinq marques, un SaaS où chaque client a besoin de son propre contenu. C'est là que les modèles tarifaires commencent à diverger nettement — certains produits facturent par projet, par jeu de données ou par espace, et c'est au troisième projet que vous le découvrez.
Votre contenu n'a pas la forme d'une page. Un catalogue de produits, un site de documentation, un journal des modifications, un tableau d'offres d'emploi. Si vous vous battez contre le modèle « article » à coups de champs personnalisés, vous payez déjà la taxe sans en avoir le bénéfice.
La localisation est réelle. Pas « on a traduit le menu » — un contenu véritablement parallèle en plusieurs langues, avec des états de publication différents par langue. Les CMS traditionnels font cela avec des extensions. Les CMS headless le traitent comme une propriété au niveau du champ.
La performance de l'interface est un chiffre métier. Le découplage vous permet de servir une sortie pré-rendue et mise en cache au lieu de calculer une page à chaque requête. Ce n'est pas automatique, mais cela devient possible.
C'est la section que la plupart des articles d'éditeurs sautent, parce qu'ils vendent.
Un seul site, une seule langue, une seule équipe, aucun développeur. Un CMS headless déplace le travail de rendu vers vous. Si personne ne va faire ce travail, vous avez payé pour une soustraction. Utilisez WordPress, ou un créateur de sites, et dépensez l'argent dans le contenu.
Un site vitrine de cinq pages. L'API, l'étape de compilation, le pipeline de déploiement et le dépôt de l'interface sont autant de surcoûts face à cinq pages qui changent deux fois par an.
Votre équipe édite avec un aperçu visuel et n'y renoncera pas. Certains produits headless ont un excellent aperçu en direct ; beaucoup n'en ont aucun. Si « je veux voir la page à mesure que je tape » n'est pas négociable, placez cela en tête de vos critères et laissez-le éliminer des candidats tôt.
Vous avez besoin d'un écosystème d'extensions. Réservations, formulaires, adhésions, e-commerce — si votre site dépend de modules prêts à l'emploi, le headless signifie les écrire. C'est une ligne de budget, pas un détail.
Un test utile : comptez vos interfaces et comptez vos projets. Si les deux valent un, la réponse honnête est généralement « pas encore ».
Une fois que vous avez décidé qu'il vous en faut un, le modèle qui décide de votre facture, c'est la façon dont l'éditeur facture les lectures.
La plupart des produits headless hébergés facturent quelque chose que le trafic des visiteurs fait bouger : appels d'API, bande passante, requêtes CDN, ou un quota d'usage combiné. La conséquence est facile à énoncer et facile à manquer : un lancement réussi est indiscernable d'un incident de facturation. Rien n'a changé dans votre contenu ni dans votre travail — seulement le nombre d'inconnus qui le lisent.
Il existe une alternative architecturale, et elle mérite d'être comprise quel que soit le produit que vous choisissez : servir le contenu publié sous forme de fichiers pré-construits et immuables depuis un cache, au lieu de calculer une réponse à chaque requête.
C'est ainsi que fonctionne corpusctl. Appuyer sur publier déclenche une compilation : le contenu est validé, rendu, et écrit dans un fichier adressé par hachage dans le stockage objet, puis le manifeste est rafraîchi. Le client du lecteur résout le slug vers un fragment de manifeste en local, puis récupère cette adresse depuis le cache de périphérie nginx. Comme l'adresse est un hachage de contenu, la même adresse ne peut jamais renvoyer un contenu différent — elle peut donc être mise en cache pendant trente jours sans aucune stratégie d'invalidation. Publier écrit une nouvelle adresse.
Deux requêtes HTTP, toutes deux depuis le cache. Aucune n'atteint l'API. Aucune n'atteint la base de données. Il n'y a pas de compteur par appel parce qu'il n'y a pas d'appel.
Vous n'êtes pas obligé de choisir corpusctl pour en faire un critère. Demandez à n'importe quel éditeur : qu'arrive-t-il à ma facture si cet article marche dix fois mieux que prévu ?
WordPress headless est-il un vrai CMS headless ? Fonctionnellement oui — l'API REST et WPGraphQL exposent le contenu. Architecturalement, c'est un aménagement a posteriori : vous conservez la machinerie de rendu des pages puis vous en jetez la sortie.
Est-ce mauvais pour le SEO ? Pas de manière inhérente. Les trois façons courantes dont les équipes perdent du trafic lors d'une migration sont : ne faire le rendu que côté client, laisser tomber les balises canoniques pendant la reconstruction, et servir depuis une origine lente au lieu d'un cache.
Est-ce plus cher ? Généralement plus cher en temps d'ingénierie au départ, et moins cher dans le cas précis où vous étiez sur le point de construire trois sites web.
Ce que « open source » coûte réellement dans un CMS headless
Open source signifie rarement libre à exécuter. Licences, ventes additionnelles cloud et coût vérifié de six CMS headless populaires — avec les chiffres tirés de leurs propres pages.