Le CMS Headless est-il nécessaire, voire suffisant ?

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”. Avec l’émergence des nouveaux formats de diffusion, des alternatives sont aujourd’hui disponibles afin d’alimenter leurs contenus en tant que service. On le décrira 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 comme 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.

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.

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
• 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

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 pointsB:

• Ces sites sont générés statiquement. Un fichier .html est créé pour chaque page.
• 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.  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. 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, nous ne recommandons pas l’utilisation d’un CMS “headless” 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. Le 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). Ceci afin de 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 ! ;)