CMS headless

Lorsque vient le temps de choisir votre système de gestion de contenu, il n’est pas simplement question de piocher parmi les déjà nombreux CMS dit “traditionnels”.
En effet, avec l’émergence des nouveaux formats de diffusion, des alternatives sont aujourd’hui disponibles afin d’alimenter leurs contenus en tant que service, que l’on décrira également comme “Content-as-a-Service” (CaaS, ou Contenu en tant que service). C’est-à-dire qu’il est possible d’administrer, récupérer, gérer du contenu (container) depuis des requêtes API exploitables indépendamment d’un contexte.
Parmi ces solutions, la mise en place d’un CMS “headless” pourra parfois s’avérer la solution la plus adaptée à vos besoins.

CMS “traditionnel” vs CMS “headless”

Historiquement, les CMS “traditionnels” prenaient en charge à la fois ce qu’on appelle le “front-office” (qu’on peut traduire  comment la « boutique »), c’est à dire l’affichage de votre site, de ses pages, de ses contenus…  et le “back-office” (et donc « l’arrière-boutique »), qui permet de gérer l’édition de ses contenus et l’administration des différents réglages sur votre site.

Dans un tel contexte, le “front-end” et le “back-end” de votre site sont donc fortement liés.
Ainsi, les contenus renseignés dans le “back” ne serviront que le site « front » couplé. A l’inverse, la plupart de vos contenus “front” seront alimentés via les données du “back” associées et mis en forme par l’utilisation de gabarits (ou “templates”) dédiés.

Après avoir créé le contenu, celui-ci va aller se stocker dans la base de données, pour ensuite aller alimenter le système de templating. L’étape finale est bien sur l’affichage sur la page web.

 

Un CMS “headless” quant à lui, n’ayant pas de “front-office » associé, ne proposera aucune interface d’affichage directement accessible par l’utilisateur final.
Un tel système se contentera uniquement de vous donner la main sur la partie “immergée de l’iceberg”, en vous offrant la possibilité de gérer les contenus de votre outil.
Pour accéder à ces flux de données, une interface dédiée (ou « API ») sera donc disponible.

Un ou plusieurs services internes, voire externes, pourront ainsi se connecter à cette API pour récupérer les informations nécessaires et se chargeront elles-mêmes de les extraire, les traiter et les mettre en forme selon leurs convenances. Ces services peuvent être un site internet, une montre connectée, un application mobile, ou encore un site indépendant.

Ces couches d’affichage supplémentaires, qui viendront se greffer en aval du CMS “headless”, seront donc fortement découplés de ce dernier.

 

A la différence du CMS traditionnel, les données ne vont pas se diriger dans un template mais vers une API qui permettra de mettre en forme les données selon l’affichage final.

 

Pour quels usages ?

L’utilisation d’un CMS “headless” ne peut donc pas être systématique. Ce choix doit se faire en toute connaissance de cause.
Voici quelques pistes pour vous aider à faire votre choix.

Utilisations recommandées d’un CMS “headless”:

  • Sites web et applications utilisant des frameworks JavaScript tels que VueJS, React ou AngularJS (exemple avec le site « plusdunmetier.fr »)
  • Sites web créés avec un générateur de site statique
  • Tout écosystème où le même contenu doit être publié sur plusieurs plateformes de diffusion (iOs ou Android natif, application windows, …)
  • Projet nécessitant une forte optimisation. Cet article en anglais explique très bien pourquoi et comment le site Smashing Magazine a réussi à multiplier par 10 sa vitesse.

Utilisations non recommandées d’un CMS “headless”:

  • Sites web de petites entreprises avec seulement quelques pages sans contrainte d’optimisation forte
  • Projets avec un délai de livraison très court (l’utilisation d’un CMS tel que WordPress reste plus rapide et efficace)
  • Projets de type catalogue avec une base de données importante
Pour ne rater aucun nouvel article, abonnez-vous à notre liste et recevez nos articles directement dans votre boîte mail

Aller plus loin

L’apparition des CMS “headless” et d’autres technologies dont la Stack JS permet d’entrevoir de nouvelles perspectives.
Ainsi nous voyons en ce moment émerger la JAMstack, pour Javascript, Api et Markup. Il ne s’agit pas à proprement parler d’une nouvelle technologie mais plutôt d’une façon de concevoir des sites web.

En trois points, ces sites:

  • sont générés statiquement, c’est-à-dire que pour chaque page du site, un fichier .html est créé
  • le front est entièrement développé via un framework JS tel que VueJS, React, Angular (liste plus exhaustive de générateur de site statique)
  • utilisent des appels à une (ou plusieurs) API pour afficher le contenu (utilisation d’un CMS “headless”)

Les bénéfices d’une telle structure sont de meilleures performances que ce soit au niveau du temps de chargement des pages, que de l’expérience utilisateur. En effet, avoir complètement la main sur le code permet de minimiser au maximum la taille des fichiers, et la dépendance à du code tiers et opaque (plugins). On est aussi plus libre dans la conception de l’interface étant donné que du JS est utilisé, on peut imaginer des transitions inter-écrans rendant l’interface plus fluide et agréable à utiliser.

Enfin, comme nous l’avons vu précédemment, l’utilisation d’un CMS “headless” n’est pas recommandée pour tous les usages. L’utilisation de WordPress n’est donc pas devenue obsolète, loin de là.
Néanmoins, ces mêmes CMS (WordPress, Drupal) se mettent au “headless”. Ils commencent à mettre à disposition des APIs ou “web services” permettant de se passer du système des templating livrés de base, tout en conservant la même structure côté “back-office”.

On peut alors s’affranchir des contraintes de rendu et de toute la structure qui peut paraître trop figée (inclusion obligatoire de dépendance, …) pour recréer de A à Z un “front” avec le framework (structure) de notre choix.
Et dernier point, c’est carrément plus fun pour les développeurs ! 😉