Headless CMS

TL;DR Mon client a l'habitude de son CMS favori, comment développer une appli qui va utiliser (consommer) les datas de son CMS, en s'affranchissant du moteur de rendu du CMS en question, et surtout, en ayant toute liberté pour exploiter les contenus sans les contraintes liées au CMS ?

Objectif (et un peu d'histoire)

L'idée de base est de découpler le module d'administration — et donc le CMS qui va avec —, du rendu front, afin de bien les séparer. Quand on dit "bien séparer", comprenez "ne pas les mélanger"…

Le CMS est sensé permettre la gestion du contenu avant tout. C'est son job principal après tout ! Et on va admettre qu'il le fait… bien. Ou en tous les cas suffisamment bien pour les besoins du client !

Le fait que la plupart des CMS gèrent également le rendu front est historique ; une fois le contenu géré, il fallait bien avoir la vue qui va avec. Et… quand Wordpress / Joomla et consorts ont délivré une v1, il n'avaient pas d'autres moyen que de gérer eux-même les vues qui vont avec le contenu. Chaque CMS a donc géré son propre rendu homemade. Et ce n'était pas si mal, finalement, vu qu'il n'y avait pas d'autre moyen de faire.

Mais ça, c'était avant.

A l'époque où on ne savait pas trop comment faire autrement, ce n'était pas une hérésie, mais aujourd'hui, ça ne semble plus tellement judicieux au vue des possibilités qu'offrent les systèmes de rendu actuel (Symfony, ReactJS, etc. pas besoin de rentrer dans le détail pour cet article).

C'est là où le Headless est intéressant : le découplage que ce principe permet (back versus front) permet d'avoir les vues/templates/front vraiment distincts du module d'administration qui, lui, reste autonome et transparent — invisible, même.

Voyons tout ça en détail.

Qu'est ce que c'est ?

Le principe "Headless CMS" sépare le backend et le frontend d'une application. Il dispose d'un système de gestion de contenu (CMS) afin de saisir les données et d'une API afin de rendre ces données accessibles. La terme “headless” vient du fait que l’on retire la couche de vue fournie par le CMS afin de la remplacer.

Les CMS, un confort mais...

Les CMS (tels que WordPress, Joomla, Drupal, eZ...) sont très répandus sur internet et sont donc logiquement une demande régulière de nos clients pour gérer les contenus de leurs sites. Ces demandes sont généralement faites car ils ont l'habitude d'utiliser ces outils et souhaitent garder le fonctionnement qu'ils connaissent pour leurs conforts. Cependant, les CMS sont limités dans leurs fonctions de rendu de contenu par des systèmes de blocs, difficilement paramétrables comme souhaités. Or, de nos jours, les internautes utilisent de multiples supports pour naviguer sur les sites : ordinateurs, ordinateurs portables, tablettes, téléphones... Les résolutions sont très différentes et l'affichage peut être différent selon l'usage. Le fait de gérer l'affichage du contenu en dehors du CMS permet cette souplesse d’affichage car nous ne sommes pas contraint à ce que propose le CMS.

De plus, les sites utilisants des CMS sont assez facilement reconnaissables à l’affichage et ils sont cibles de hackers : les CMS étant répandus, si les hackers trouvent une faille, ils peuvent lancer leurs attaques sur tous les sites utilisants ce CMS. Des failles sont régulièrement trouvées, et des mises à jours sont nécessaires pour fermer les brèches et sécuriser les données. L’avantage d’avoir un serveur contenant les données peut permettre de fermer tous les accès extérieurs exceptés ceux provenant du serveur de rendu.

La liberté de technologie

Le développeur en charge de la couche d’affichage a une liberté totale sur le choix de la technologie à employer pour développer. Il lui suffira de faire appel à l’API proposée par le CMS afin de récupérer les données, pour ensuite les afficher à sa guise selon le type de support.

Mixage de données

Le fait d’avoir une partie d’affichage indépendante peut également permettre de récupérer des données de plusieurs sources de données. Si 3 sites basés sur des CMS sont utilisés par un client et qu’il souhaite afficher toutes ces sources sur un même site, c’est possible avec une approche “headless”. De plus, il est également possible d’avoir une partie de logique métier attenante, afin d’effectuer des actions complémentaires, autre que de la gestion de contenu basique.

Le headless CMS en plein essor

Nous connaissons les plateformes de CMS traditionnelles comme Wordpress, Drupal, Joomla... Mais de nouvelles plateformes basées uniquement sur des APIs voient le jour: Storyblok, Prismic ou encore Contentful. Ces CMS sont proposés sous forme de SaaS et ne fournissent pas de couche d'affichage, elles sont uniquement utilisables en Headless (c'est leur finalité en fait). Une nouvelle mouvance également: la JAMStack. La JAMStack est issue de JavaScript, API, et Markup généré en amont. C'est une architecture sans serveur, avec des pages statiques pré-générées. Amenant de meilleurs performances, moins cher — il n'y a pas de serveur — et plus sécurisé car les pages sont… statiques !

Pour conclure…

Le headless CMS est tendance ! Il est surtout très malléable. Que ce soit au niveau des technologies utilisées pour le développeur jusqu’à l’affichage final pour l’utilisateur, peu importe le support qui est utilisé. Quant à la partie administration, aucune modification n'est requise au niveau de l'utilisation du CMS habituellement utilisé. Enfin, cela apporte une couche de sécurité supplémentaire et une maintenabilité plus facile car le principe ne dépend pas de plugins du CMS, mais uniquement de ce que le développeur a mis en place. Le site mettra un tout petit peu plus de temps à être développé, car le travail relatif à l'affichage doit être personnalisé selon ce qui est souhaité.