Par Julian Maurel, Directeur du Produit chez Jahia, éditeur de logiciels.
L’architecture headless constitue une réponse à l’évolution des contenus sur internet. Alors que la plupart de ces derniers étaient à vocation éditoriale et diffusés par l’intermédiaire de navigateurs (sous forme de pages web), les modes de consommation se sont multipliés (smartphones, applications web métier), conduisant à une nécessaire adaptation. Pour les développeurs, ce changement de paradigme par rapport aux CMS historiques constitue un énorme compromis, porteur de beaucoup de promesses. Pourtant, cette approche qui séduit les créateurs de contenus cache une réalité technique plus complexe, qu’il convient d’appréhender au mieux.
Attrait technique de la démarche vs. expérience de contribution
Le sujet de l’expérience de création de contenu dans un contexte headless est une question souvent délaissée. C’est compréhensible : les principaux promoteurs de cette technologie sont des techniciens qui ont tout à gagner à pouvoir utiliser des outils qu’ils maitrisent eux même. Cette question est pourtant centrale car elle illustre des réalités bien différentes pour les développeurs et les créateurs de contenus.
Pour les développeurs, l’approche headless libère de toutes contraintes techniques sur l’implémentation d’un projet : ils n’ont pas à monter en compétence sur une technologie spécifique au CMS utilisé.
Du côté des créateurs de contenus, l’approche dite « traditionnelle » rend l’expérience de contribution confortable (forte adhérence avec le site web, ordonnancement des éléments, outils visuels pour la création de formulaire, etc.) et permet de collaborer étroitement avec les différents métiers en phase de définition du besoin et d’implémentation.
Les développeurs se doivent par ailleurs d’assurer une Tierce Maintenance Applicative (TMA) sur toute la période de vie du projet, voire de réaliser des évolutions ponctuelles. Cette relation est différente dans un contexte headless.
Une nécessaire collaboration
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 Single Page Application (SPA) : 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. De fait, la définition du besoin de cette fameuse SPA demande à se mettre dans la peau d’un chef de produit de CMS traditionnel.
Cela peut être initié en posant des questions très concrètes sur l’expérience de contribution.
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.
Un intérêt énorme, oui. Mais pas dans tous les contextes.
Pour faire simple, les CMS headless ont un intérêt évident 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. Une excellente communication entre les développeurs et les métiers devient alors incontournable.
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.
Alors que 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.
Le CMS hybride devient alors une solution, car il autorise une utilisation traditionnelle, headless, ou les deux au sein d’un même projet - offrant le meilleur des deux mondes.