Si vous ajoutez un blog, un journal des modifications ou un centre d’aide à un logiciel, le premier embranchement est architectural : voulez-vous un CMS qui affiche vos pages à votre place, ou un CMS qui vous fournit le contenu par une API et ne touche pas à votre frontend ?
Toute la différence entre un CMS traditionnel et un CMS headless est là. Le reste (prix, extensions, hébergement) découle de ce choix.
Ce que fait un CMS traditionnel
Un CMS traditionnel (ou « couplé ») comme WordPress réunit trois choses dans un seul système : l’interface d’édition, la base de données de contenu et la couche de rendu qui transforme le contenu en HTML. Vous choisissez un thème, les rédacteurs écrivent les articles, et le CMS sert des pages finies depuis son propre serveur.
Ce modèle est excellent quand le site est le produit : un magazine, le site d’un restaurant, une plaquette d’entreprise. Vous obtenez un site qui fonctionne sans une ligne de code frontend, un écosystème d’extensions mûr, et des rédacteurs non techniques qui peuvent presque tout modifier.
Les coûts apparaissent quand le CMS doit vivre à l’intérieur d’un produit plus large :
La couche de rendu est la sienne, pas la vôtre. Votre blog ressemble à un thème, pas à votre application. Pour l’aligner sur votre design system, il faut se battre avec le système de templates.
C’est une deuxième stack à faire tourner. Une application PHP avec sa propre base de données, ses mises à jour et ses correctifs de sécurité, à côté de votre vrai produit.
Le contenu est prisonnier d’une seule présentation. Un même article d’aide alimente difficilement une page web, un widget dans l’application et un index de recherche, parce qu’il a été écrit comme une page, pas comme des données.
Ce que fait un CMS headless
Un CMS headless garde l’interface d’édition et la base de données de contenu, et supprime la couche de rendu. Le contenu sort en JSON structuré par une API, et votre application l’affiche avec vos propres composants, sur votre propre domaine.
Concrètement, récupérer du contenu revient à appeler un SDK depuis votre code serveur :
const posts = await kookee.blog.list({ limit: 10 });
const article = await kookee.help.getBySlug('getting-started');Votre framework (Next.js, Astro, Nuxt, SvelteKit, tout ce qui sait récupérer du JSON) en fait du HTML, comme il le fait pour le reste de votre produit.
L’échange est clair : vous écrivez le frontend une fois et, en contrepartie, vous maîtrisez entièrement le balisage, les styles, le routage et les performances. Pour une équipe SaaS qui a déjà un design system et un frontend déployé, c’est en général une bonne affaire, parce que le travail de frontend se limite à une fine couche au-dessus de composants que vous avez déjà.
La comparaison qui compte vraiment
La plupart des comparatifs « headless ou traditionnel » alignent des avantages et des inconvénients abstraits. Pour un produit SaaS, quatre questions tranchent.
Qui maîtrise le design ?
Traditionnel : le thème, et vous personnalisez dans ses limites. Headless : vous, entièrement. Si votre blog et votre centre d’aide doivent ressembler à votre produit (même navigation, même typographie, même mode sombre), le headless est la seule option qui y arrive sans bricolage.
Où le contenu doit-il apparaître ?
Un CMS traditionnel produit des pages. Un CMS headless produit des données, et les données vont partout : votre site marketing, un panneau du journal des modifications dans l’application, un chat de support qui répond à partir de vos articles d’aide, un flux RSS, une application mobile. Si votre feuille de route prévoit autre chose qu’« un site web », écrire le contenu sous forme de données structurées rapporte tout de suite.
Qui maintient l’infrastructure ?
Un CMS traditionnel auto-hébergé, ce sont des correctifs à appliquer pour toujours. Avec une plateforme headless hébergée, le fournisseur fait tourner l’éditeur, la base de données, l’API et le CDN, et votre seul livrable est du code frontend dans votre dépôt existant, déployé, relu et, au besoin, ramené à sa version précédente exactement comme le reste de votre application.
Et le référencement ?
C’est l’objection la plus courante au headless (« si le contenu vient d’une API, Google le voit-il ? ») et le problème est réglé. Avec un rendu côté serveur ou une génération statique, le robot d’indexation reçoit du HTML ordinaire, à votre URL. La source du contenu est invisible pour les moteurs de recherche ; ce qui compte, c’est le domaine qui sert le HTML, et en headless ce domaine est le vôtre. C’est nettement mieux que d’héberger votre blog sur le sous-domaine d’un fournisseur, où l’autorité que vous construisez profite au site de quelqu’un d’autre.
Où chacun l’emporte
Choisissez un CMS traditionnel quand :
Le site est un contenu autonome, sans application autour.
Personne dans l’équipe n’écrit de code frontend, et personne n’en a envie.
Un thème juste à 90 % vous suffit.
Choisissez un CMS headless quand :
Le contenu vit dans un produit qui a son propre frontend, ou à côté.
Le même contenu alimente plusieurs supports : le web, l’application, la recherche, les flux.
Vous voulez publier le contenu sur votre domaine, avec votre design et votre pipeline de déploiement.
Le juste milieu : du headless avec une issue de secours
Le vrai point faible du headless, c’est le premier jour : tant que votre frontend n’existe pas, vous avez une API et rien à montrer. Certaines plateformes comblent ce manque avec un portail hébergé, un site public prêt à l’emploi pour votre tableau de retours, votre feuille de route, votre journal des modifications et votre centre d’aide, qui fonctionne avant que vous ayez écrit la moindre ligne de code.
C’est l’approche de Kookee : chaque projet dispose tout de suite d’un portail optionnel à une URL publique, et vous le remplacez section par section par vos propres pages à mesure que vous les construisez sur l’API. Le portail vous met en ligne le jour du lancement ; le SDK vous donne plus tard une expérience entièrement à vous, sans migrer de contenu d’un système à l’autre.
En résumé
Pour les sites de pur contenu, un CMS traditionnel reste un bon choix par défaut. Pour les produits SaaS, le modèle s’est clairement imposé : le contenu est rédigé dans un tableau de bord, servi en JSON et affiché par le frontend du produit, sur le domaine du produit. Vous gardez votre design system, votre référencement profite à votre domaine, et votre contenu reste des données portables au lieu de pages captives.
Pour trancher en pratique : prototypez la voie headless sur un seul support. Affichez vos cinq derniers articles avec vos composants existants. Si cela prend un après-midi (et avec un SDK typé, c’est en général le cas), vous avez votre réponse.