Les cms sans tête

La gestion de contenu en entreprise tends à se tourner vers une édition unique avec une distribution multiple. Plus clairement, un éditeur va pouvoir distribuer le contenu sur le site public, l’application, l’intranet et le portail, avec un contenu exactement similaire ou presque.

 

Le schéma classique du CMS 

On édite depuis un logiciel comme WordPress ou Drupal, puis on publie au même endroit.

Le schéma Headless Cms

 

L’idée magique est d’avoir une source unique pour le contenu, l’édition est complètement décorrélée de l’affichage du contenu. Votre logiciel d’édition se trouve sur une adresse distincte type https://edition-contenu.fr et vos applications, sites et Intranet peuvent vivre leur vie et aller chercher le contenu qu’ils souhaitent à cet endroit.

Les types de cms

  • API (Contentful, Butter Cms, Cloud Cms)
  • graphql (GraphCms)
  • git based (Jekyll admin)

Les avantages

Édition unique: une seule source pour tous vos contenus, l’édition est simple et efficace

Sécurité: votre contenu est toujours à l’abri, l’accès à l’éditeur lui-même peut être rendu complètement privé

Flexibilité: une seule édition évite tous les soucis de duplicata

 

Les inconvénients

Le coût: certains services en Sass peuvent avoir un coût non négligeable voir excessif.

La possible complexité de l’architecture: construire un site basé sur ce principe peut devenir compliqué comme on le verra dans la section suivante

La faiblesse de la communauté: le projet étant relativement récent, quelques entreprises se sont positionnées, mais peu de développeurs sont rassemblés.

La mise en pratique

Si simplement récupérer du contenu depuis une API rest est simple, construire un environnement web autour de cette technologie peut devenir un vrai casse tête voir un « no-go » as we say in Marketing 🙂

Netlify

éditeur de contenu Netlify

Le scénario commun, imagine générer le site via un générateur de site statique comme Hugo. Dernièrement Smashing magazine en a fait la publicité. Ils utilisent des services en SASS. Le contenu est hébergé sur Github, le générateur est situé chez Netlify, ce dernier offre deux services : un éditeur de contenu en ligne par Netlify en ligne et une distribution du site par netlify via leurs CDN. Cette solution est la plus simple, Netlify s’occupe de tout.

Il faut avoir des connaissance ensuite sur le templating « twig » utilisé par Hugo. L’apprentissage est assez aisé et direct.

 

All by yourself

Si vous souhaitez tout faire vous même, de l’hébergement à l’édition, le système pour un site web peut être plus compliqué. Un scénario parmi tant d’autre pourrait proposer d’utiliser Cockpit. Les Cms headless open source basé sur une API Rest sont assez rares, la communauté qui réside autour est faible. C’est un point négatif à ne pas négliger si on veut faire reposer un gros projet sur cette mécanique…

En utilisant Cockpit, vous avez du contenu, organisé à votre façon, principe de flexibilité merveilleux, ce dernier pourra être recherché via l’API Rest proposé. Plusieurs solutions s’offrent à vous, utiliser Hugo qui a la capacité de générer des fichiers statiques via une API Rest, ou construire un site via un framework javascript comme React ou Vue.js.

Créer un contenu personnalisé sur Cockpit
Edition du contenu sur Cockpit

 

 

 

 

 

 

 

Bien que cela puisse être passionnant, il faudra selon l’exigence de votre équipe reconstruire l’ensemble des inévitables du CMS traditionnel, comme par exemple la capacité de prévisualiser un article, de ne pas le publier, d’avoir les versions antérieures, de créer des url propres, de gérer les redirections, etc…

 

Un troisième scénario:

Les cms modernes ont compris l’importance de la démarche. Pouvoir centraliser le contenu est important. WordPress a mis en place sa propre API Rest en 2016 (toujours en Beta début 2017), cela offre une solution non négligeable. Un des points négatifs à ce scénario est que contrairement à Cockpit, la structure de wordpress n’est pas à l’origine faite pour être flexible. Le contenu d’un article s’articule autour d’un titre, d’un contenu, et d’images. On peut toujours se tourner vers un plugin comme ACF pour ajouter des champs personnalisés, puis rajouter un autre plugin pour pouvoir les rendre accessible via l’API Rest de wordpress.

Les cas d’utilisation

  • Un site vitrine simple
  • Un réseau de publication (applications, sites, billboard, etc…) utilisant un même contenu
  • Un site plus complexe accompagné de collaborateurs dédiés à son édition, développement

 

Commentaires :