Headless CMS
Définition
Système de gestion de contenu sans interface publique, qui expose son contenu via une API. Le front-end (Next.js par exemple) consomme ces données pour les afficher comme il veut. Exemples : Sanity, Strapi.
Comment ça marche
Un headless CMS sépare la gestion de contenu de la présentation. L'équipe éditoriale crée et organise le contenu (articles, pages, médias, traductions) dans une interface dédiée, et le CMS expose ce contenu via une API REST ou GraphQL. Le site (Next.js, Astro, app mobile, écran physique) récupère ces données à la build ou à la volée, et les affiche avec sa propre stack technique. À l'opposé, un CMS classique (WordPress, Drupal) gère contenu et rendu dans le même outil, imposant son framework de templates. Le headless rend les deux totalement indépendants.
À quoi ça sert
Le headless CMS résout un conflit classique : l'équipe contenu veut une interface confortable pour éditer (avec aperçu, workflow de validation, médiathèque), l'équipe technique veut la liberté de choisir Next.js pour les performances et le SEO. En séparant les deux, chacun a son terrain. On peut aussi alimenter plusieurs canaux depuis le même contenu : site principal, version mobile, newsletter, écrans en magasin, app interne. Pour un projet média ou e-commerce avec plusieurs auteurs, c'est rapidement indispensable.
Les acteurs
Sanity domine sur les projets exigeants : éditeur Studio personnalisable, query language GROQ puissant, GraphQL en option, image pipeline excellent. Storyblok cible le marketing avec un visual editor par bloc, idéal pour les pages d'atterrissage. Strapi est open-source et auto-hébergeable, populaire en France pour la souveraineté. Contentful reste un standard d'entreprise. Pour de plus petits projets, Payload CMS (Node-first) ou Directus (auto-hébergeable, basé PostgreSQL) sont d'excellentes options. Sur des sites très simples, Notion ou Google Docs + un script suffisent.
Quand l'utiliser
On choisit un headless CMS quand on a plusieurs auteurs non techniques qui doivent publier régulièrement, des workflows éditoriaux (brouillon, validation, publication), des médias à gérer (images, vidéos avec transformations), du multilingue, ou plusieurs canaux à alimenter depuis le même contenu. Sur un blog d'agence avec un seul auteur qui maîtrise Markdown, c'est une overkill. Sur un site e-commerce avec catalogue produits éditorial, des landing pages marketing à itérer toutes les semaines et une équipe de 5 contributeurs, c'est clairement utile.
Quand ne pas l'utiliser
Pour un site vitrine avec 10 pages éditées 2 fois par an, un headless CMS est trop lourd : MDX dans le repo Git, édité en pull request, fait largement le travail. Pour un blog technique mono-auteur, idem : Markdown + Git suffit. Pour un site dont le contenu est essentiellement structuré et techniquement riche (documentation API, glossaire), un CMS classique est un frein. La règle : on introduit le headless CMS quand l'effort éditorial devient un facteur limitant, pas pour cocher une case d'architecture moderne.
Les coûts
Sanity et Storyblok proposent un plan gratuit généreux pour démarrer, payant à partir du moment où on multiplie les utilisateurs et le volume de contenu (50-100€/mois en plan Pro typique). Contentful démarre plus haut (300$/mois pour le plan Team). Strapi est gratuit mais demande de payer l'hébergement et la maintenance d'un VPS si auto-hébergé. À budget équivalent, Sanity offre la meilleure flexibilité technique, Storyblok la meilleure expérience marketing visuelle. Strapi gagne sur la souveraineté pour les projets avec contraintes spécifiques.
Les pièges à éviter
Le verrouillage est le piège classique : on a investi des dizaines d'heures à configurer le schéma, et migrer ailleurs coûte cher. On limite ce risque en gardant le contenu exportable (Sanity et Strapi le font bien), en versionnant les schémas en Git, et en ne dépendant pas trop des features propriétaires. Autre piège : laisser l'équipe contenu créer des structures non standardisées (10 façons différentes de représenter une carte produit), ce qui rend le rendu côté code cauchemardesque. On définit le schéma avec rigueur dès le départ. Et on prévoit la stratégie de cache : un CMS appelé à chaque requête coûte cher et ralentit le site, on utilise ISR ou un cache distribué.