Actuellement, la dernière tendance est le CMS « headless », qui dissocie complètement la gestion du contenu de sa présentation.  

En conséquence, les propriétaires de site Web et les développeurs Web se posent la question suivante : avons-nous besoin d’un CMS headless ? 

Le CMS headless offre de nombreux avantages par rapport au CMS traditionnel, mais la valeur ajoutée dépend également du contexte, du nombre de canaux et de ce que vous essayez d’obtenir avec votre contenu. 

Dans l’un de nos projets, nous avons suivi une approche headless et nous avons beaucoup appris.  

Aujourd’hui, nous aimerions vous faire part de nos connaissances, en espérant que cela vous aidera à décider de la marche à suivre pour votre futur projet Web.

Quels sont les avantages d’un CMS headless ? 

Un CMS headless diffère d’un CMS traditionnel, souvent décrit comme un CMS « monolithique ».  

En mode headless, le contenu et la couche présentation du site Web sont entièrement séparés. En outre, la présentation ne relève pas de la responsabilité du CMS et doit être implémentée ailleurs.

La stratégie headless offre des avantages réels : le CMS prend uniquement en charge le contenu, et ses fonctionnalités peuvent être entièrement optimisées pour cela.  

Comme le contenu ne contient aucune information sur la façon dont il doit être présenté, le même contenu peut être utilisé sur plusieurs canaux de sortie, tels que le site Web, une application mobile, les réseaux sociaux et même la presse écrite, dans le meilleur des cas.  

En revanche, un CMS monolithique s’occupe à la fois de la création et de la présentation du contenu sur les « pages ». La structure de la page correspond en fin de compte à la navigation du site Web.  

Selon l’architecture du CMS, le contenu peut être placé directement sur des pages, ce qui complique la réutilisation du contenu sur d’autres canaux. Dans d’autres architectures, il peut y avoir un découplage logique entre le contenu et la forme.  

Comment Adobe Experience Manager gère-t-il le contenu ? 

Dans Adobe Experience Manager (AEM), le CMS d’Adobe Experience Cloud, les auteurs assemblent généralement directement le contenu en pages, qui correspondent ensuite (plus ou moins) aux pages Web, même si, du point de vue technique, la gestion de contenu et la présentation des pages sont distinctes.  

Pourquoi est-ce que je vous parle d’AEM ?  C’est assez simple.

Tout d’abord, parce que One Inside est un partenaire Adobe certifié et que nos équipes sont spécialisées dans la mise en œuvre des projets avec AEM.

Deuxièmement, parce que c’est le CMS qui a été utilisé pour le projet (comme pour presque tous nos projets). 

Évoquons maintenant ce projet.

Le projet : utiliser le headless à n’importe quel prix 

Le but du projet était d’afficher du contenu (déjà disponible sur le site Web) sur un autre canal : un kiosque digital. 

Un kiosque digital est un « distributeur automatique » composé d’un ordinateur et d’un écran tactile. Les utilisateurs du kiosque digital peuvent être informés des produits proposés en libre-service. 

Notre équipe a rejoint le projet assez tard, après la conception de la solution technique. 

Le kiosque a exploité la technologie Angular pour afficher des informations à ses utilisateurs. L’application (front-end) du kiosque était déjà en partie mise en œuvre.

Le choix de l’architecture avait déjà été fait : le kiosque devrait stocker tout le contenu localement, sur l’appareil.  

Comme la solution était déjà conçue, il n’était pas possible de bénéficier directement du site Web principal créé dans AEM. Autrement, il aurait été possible de créer relativement facilement une version du site Web adaptée au kiosque. 

Au lieu de cela, il a fallu utiliser des API REST pour fournir du contenu au kiosque.

Une bibliothèque d’objets JSON a été définie pour le contenu et la configuration du kiosque. Grâce aux capacités de customisation d’AEM et à l’utilisation des technologies REST et JSON, la mise en œuvre pouvait s’effectuer sans trop de difficultés. 

L’approche headless est-elle toujours la plus adaptée ? 

Au cours du projet, un autre avantage de la séparation du contenu et de la présentation a été mis en évidence : l’équipe front-end et l’équipe back-end pouvaient travailler indépendamment l’une de l’autre. 

L’équipe back-end était chargée de gérer le contenu dans AEM, tandis que l’équipe front-end s’occupait d’une application Angular pour la présentation du contenu. 

Chaque équipe peut :  

• se concentrer pleinement sur son domaine d’expertise ;  
• travailler avec ses technologies et dans ses cadres habituels ;  
• et n’a pas à se préoccuper de l’autre partie. 

Une réunion de coordination hebdomadaire et la définition de l’interface (correctement documentée) sont suffisantes pour permettre aux équipes de collaborer.

Le schéma architectural ci-dessus montre que l’approche headless est justifiée pour ce cas d’utilisation : au cours du projet, d’autres écrans et appareils seront connectés, chacun via sa propre interface.  

Ils peuvent être exécutés en peu de temps sans grande consultation entre les équipes, et de nouveaux canaux ou appareils peuvent être ajoutés à tout moment.  

Bienvenue dans le monde merveilleux du CMS headless ! Désormais, tous les CMS monolithiques existants peuvent être remplacés ! 

Ou peut-être pas.  

Avec le premier appareil dont nous avons parlé, le kiosque, nous aurions pu consacrer beaucoup moins de temps à notre projet si nous avions simplement mis en place une version allégée du site Web directement dans AEM.  

Le headless impliquait des coûts et introduisait une complexité inutile.

De nombreuses fonctionnalités devaient être créées à l’aide de différentes technologies qui auraient déjà été disponibles. 

Le CMS d’AEM est puissant et offre la possibilité de créer une version allégée d’un site Web, par exemple basée sur des Experience Fragments.

Des efforts trop importants pour de simples sites Web 

En particulier pour les sites Web et les canaux liés au Web, l’approche traditionnelle peut s’avérer être la meilleure solution par rapport à l’approche headless.  

Alors que le back-end pour le référentiel de contenu est créé (le CMS), le front-end est créé de manière complètement indépendante (avec Angular, React ou un cadre similaire). 

Du côté du front-end, tout doit être entièrement développé. Chaque composant, chaque modèle de page, ainsi que l’ensemble de la navigation.  

Il s’agit d’un effort supplémentaire qui ne doit pas être sous-estimé, par rapport aux adaptations de conception du site Web existant avec AEM et les composants de base. 

Le contenu avant tout 

Selon moi, ce qui est négligé est le principal problème de l’approche headless : comment le contenu s’adapte-t-il au site Web, ou plutôt comment la structure de page est-elle définie ? 

Sur un site parfaitement structuré, comme un portail d’informations, où les articles sont classés par catégories (par exemple, politique, sport) et présentés par sujets, cela peut être fait automatiquement, et des solutions similaires sont disponibles pour le e-commerce.

Dans de tels cas, lorsque la navigation peut être automatisée, une approche headless peut constituer la solution appropriée.  

Pour un site Web d’entreprise ordinaire où le contenu est affiché dans une hiérarchie semi-structurée, le front-end doit faire appel au bon contenu.

Cela peut aller jusqu’à la création de l’ensemble de la navigation en front-end, ce qui complique grandement la prise en charge en back-end.  

Toutes les fonctions de structuration du contenu, qui sont considérées comme acquises dans un système de gestion de contenu conventionnel, doivent être créées en front-end au prix de grands efforts, si cela est possible.  

Dans notre exemple du kiosque, ce problème a dû être résolu de manière à ce que l’ensemble de la structure de contenu par appareil soit conservée dans le CMS, puis mise à la disposition de l’appareil correspondant en tant qu’objet JSON.

Le kiosque fournit ensuite le contenu lui-même et veille à ce que la présentation soit adaptée.  

À long terme, la coordination entre front-end et back-end devient problématique : la moindre erreur dans le fichier de configuration JSON entraîne des erreurs dans le front-end.  

Les avantages d’un CMS traditionnel l’emportent sur l’approche headless dans ce cas.

CMS hybride : le meilleur des deux mondes 

Heureusement, Adobe ne s’est pas arrêté à l’approche monolithique et a démontré qu’Adobe Experience Manager était considéré comme l’un des produits les plus innovants du marché, et ce pour une bonne raison. 

Content Services et les technologies connexes telles que Content Fragments et Experience Fragments permettent de séparer la gestion et la présentation du contenu. En outre, tout le contenu peut également être récupéré en tant qu’objets JSON via les API REST.  

Cette approche, connue sous le nom de « CMS hybride », offre un CMS headless en plus du CMS traditionnel basé sur la page, optimisé pour les sites Web.  

Le contenu préparé pour le site Web peut être mis à la disposition d’autres systèmes tels que des écrans, des kiosques, des applications ou l’Internet des objets (IdO) via les API correspondantes. 

La question n’est plus de savoir s’il faut adopter une approche headless ou non, mais de savoir quand adopter une approche headless et quand adopter une approche traditionnelle.  

Faire le bon choix peut être déterminant pour la réussite d’un projet.  

Nous sommes ravis de vous aider à choisir la stratégie de gestion de contenu optimale pour votre projet et de vous présenter un moyen efficace et rentable de réussir. 

Michael Grob

Senior Consultant Digital Marketing