La vérité à propos du Headless

Avant d'écrire cette entrée de blog, j'ai passé beaucoup de temps à lire ce qu'internet avait à dire au sujet du Headless. Des billets de blog souvent partisans ou biaisés par le point de vue de leurs auteurs - c'est souvent le cas au sujet du Headless - se focalisant principalement sur les attraits techniques de la démarche.

Nous avons passé ces dernières années à collaborer à un grand nombre de projets de CMS ou de DXP (Digital Experience Platform) Headless, Hybrides et Traditionnels en collaboration avec les profils techniques et métiers qui gravitent autours de ces projet, et pensons avoir quelques choses intéressantes à dire sur le sujet.

Qu'est-ce que le Headless ?

Le Headless est un changement de paradigme par rapport aux CMS historiques (que l’on devrait d’ailleurs appeler des WCMS - Web Content Management System). Un énorme compromis, porteur de beaucoup de promesses : en échange de ne plus produire d’HTML directement consommable par les navigateurs internet, le CMS headless se rend agnostique de la manière dont son contenu va être présenté au lecteur. Le contenu devient consommable via n’importe quel médium : site web, application mobile, IOT...

D’autres attraits découlent de cette nouvelle architecture: 

• Expérience visiteur multi-channel

• Meilleure réutilisation des contenus

• (presque) Aucune contrainte technique sur l’implémentation du projet, les développeurs n’ont pas à monter en compétence sur une technologie spécifique au CMS utilisé

• Les briques de contenu et de rendu du contenu sont décorrélées. Elles peuvent être redimensionnées indépendamment l’une de l’autre.

Le Headless du point de vue du créateur de contenu et du marketeur

Le sujet de l’expérience de création de contenu dans un context Headless n’est (bizarrement) presque jamais abordée dans les articles de blog. C’est compréhensible, les principaux promoteurs de la technologie sont les profils techniques qui ont tout à gagner à pouvoir utiliser des technologies attrayantes qu’ils choisiront eux même, et à pouvoir réutiliser des compétences acquises dans leurs projets précédents.

Alors, que-ce qui rend l’expérience de contribution dans un CMS Headless spécifique ? Presque tout.

Ce qui rend confortable l’expérience de contribution de contenu dans un CMS traditionnel est sa forte adhérence avec le concept de site web:

• Capacité à prévisualiser les pages

• Drag&Drop d’éléments dans une page

• Ordonnancement des éléments au sein d’une liste

• Création de nouvelles pages

• Possibilité d’utiliser un WYSIWYG HTML

• Outils visuels pour la création de formulaires

• Trouver et éditer les contenus et les pages de la façon dont ils sont organisés sur le site

• Gérer les URLs de redirection pour une page (vanity URLs)

Tous ces éléments sont reliés de près ou de loin à la notion de web et sont absents de l’expérience de création de contenu en mode Headless. Pire, cette réalisation vient souvent en cours ou à la fin de l’implémentation du projet reposant sur du Headless.

La relation avec les développeurs

Dans un projet de CMS traditionnel ou de DXP, il est attendu que les métiers et les profils techniques collaborent étroitement en phase de définition du besoin et d’implémentation. Il est également attendu que les développeurs assurent une TMA (Tierce Maintenance Applicative) sur toute la période de vie du projet, voire réalisent des évolutions ponctuelles. La relation avec les équipes de développement est différente dans un contexte Headless.

Là où un CMS traditionnel propose de nombreuses fonctionnalités de mise en page, d'agrégation de contenu et de création de pages, ces fonctionnalités sont souvent remplacées par du semi-manuel par des développeurs.

Dit différemment, là où un CMS traditionnel pilote la création de contenu et sa disposition dans des pages, le CMS Headless ne permet que de créer les contenus, indépendamment de l’endroit où ils apparaîtront.

Comment anticiper et contourner les limitations ?

Anticiper les limitations liées au Headless demande beaucoup de recul sur le sujet. L’utilisation d’un CMS Headless dans un contexte web nécessite la création d’une SPA (Single Page Application) : l’application web chargée du rendu du site. Cette SPA est implémentée par les développeurs en charge du projet, et peut être extrêmement restrictive, ou bien très ouverte. Cela dépendra de la définition des besoins du projet.

Il convient alors que les métiers définissent tous les degrés de liberté attendus dans le cadre du projet. Cela peut être initié en posant des questions très concrètes sur l’expérience de contribution :

• Pourra-t-on réordonner deux contenus sur une page ?

• Pourra-t-on créer simplement une landing page ? (sans l’intervention d’un développeur)

• Pourra-t-on rajouter un champ à un formulaire ? Et les réordonner ?

• Comment pourra-t-on formater du texte riche (WYSIWYG ?) En manipulant de l’HTML ?

• Comment le sitemap sera-t-il généré ?

Le sujet de l’absence (probable) de WYSIWYG peut apporter des contraintes qui ne seront visibles que bien plus tard : le WYSIWYG et l’éditeur d’HTML souvent associé permet d’implémenter des cas limites, autorise les marketers au profil geek à modifier les CSS et le code HTML eux même.

Finalement, la définition du besoin de cette fameuse SPA demande à se mettre dans la peau d’un chef de produit de CMS traditionnel. Il faut définir les fonctionnalités liées à l’expérience de contribution dans un site afin de l’associer à l’expérience de contribution du contenu déjà présente dans le CMS Headless.

Et les DXP dans tout ça ?

Une DXP est un CMS enrichi de nombreuses fonctionnalités : personnalisation, A/B testing, connexion aux annuaires d’entreprises, recherche avancée, intégration e-commerce, meilleure gestion des expériences authentifiées… Toutes ces fonctionnalités nécessitent une intégration personnalisée pour chaque projet. L’avantage majeur est que le Headless permet une intégration avec tous les produits Headless, et donc la composition d’un “Stack” sur mesure. Il faut surtout en avoir les moyens, la compétence et le temps.

Les fonctionnalités de segmentation, personnalisation et d’A/B testing ne fonctionneront qu’au prix d’une implémentation spécifique très dépendante de l'implémentation de la SPA de chaque projet.

L’indexation par les moteurs de recherche (SEO)

La faculté des moteurs de recherche à indexer le contenu issu des Single Page Applications continue de s’améliorer depuis des années, mais une SPA seule reste fortement incompatible avec un référencement efficace par Google et ses concurrents.

L’utilisation d’un générateur de site statique (“Static Site Generator” dans la littérature) ou de la génération des pages côté serveur restent une nécessité absolue pour tous les sites publics dépendants de l’indexation par les moteurs de recherche.

La génération des fichiers sitemap.xml et robots.txt doit être anticipée et correctement spécifiée (la notion de “page” n’étant pas généralisée dans les CMS purement Headless). 

Déprimés par le Headless?

Plein de promesses sur le papier, et plein de contraintes dans la réalité, le CMS Headless a-t-il un intérêt ? Un intérêt énorme, oui. Mais pas dans tous les contextes.

Les CMS Headless ont une supériorité absolue pour tous les cas d’usage qui n’impliquent pas le web (Funnels, Applications mobiles…) et les applications web métier.

Les avantages des CMS Headless peuvent également être très marqués dans les entreprises très matures sur le numérique, qui savent contourner les défis mentionnés dans cet article. Une excellente communication entre les développeurs et les métiers est alors nécessaire.

Finalement, beaucoup d’applications web métier (simulateurs, portails clients, intégration de services externes...) ont une composante éditoriale secondaire et profiteront davantage d’une implémentation Headless où les développeurs ont toute liberté d’implémenter la fonctionnalité avec les technologies de leur choix.

Le CMS Hybride à la rescousse

Les usages sont de plus en plus riches, divers en matière de support (sites, applications…) et de périmètre. Les sites web complexes mélangent souvent les zones éditoriales et les applications métiers, rendant la recherche d’une seule et même technologie trop porteuse de compromis extrêmes.

Les CMS hybrides - permettant une utilisation Traditionnelle, Headless, ou les deux au sein d’un même projet - permettent le meilleur des deux mondes. Les possibilités d’imbrication de ces deux méthodes sont presque infinies : jusqu’à les combiner au sein d’une même page, où un sous-blog peut être une SPA tandis que le reste est livré de manière traditionnelle. 

Le fait de se reposer sur un CMS hybride est également l’assurance de pouvoir s’ajuster à un écosystème et à des besoins changeants. 

Jahia, la plateforme d’expérience digitale hybride 

Jahia est utilisé comme plateforme de CMS hybride et de DXP par les plus grandes entreprises du CAC 40 et du Fortune 5000 pour propulser des expériences numériques riches et personnalisées sur tous les types de supports. Disponible dans le Cloud et on premise, nous disposons d’une expérience de nombreuses années sur les problématiques de Headless, Hybride et Traditionnelle. 

Si vous voulez en savoir plus, n’hésitez pas à nous contacter pour obtenir une démonstration de la plateforme.