Les considérations à prendre en compte pour l'introduction du CMS Headless en entreprise
Aujourd'hui, le terme CMS (Content Management System) est utilisé pour décrire un système dont la fonction va bien au-delà de la création, de la modification et de l'édition de contenu. Progressivement, ces systèmes ont dépassé le périmètre initial ci-dessus, et beaucoup sont en train d'évoluer et de devenir de véritables plateformes d'expérience - DXP (Digital Experience Platform.
Un CMS Headless est fidèle à sa définition : c'est un système principalement utilisé pour créer et gérer le contenu. Il s'agit en fait d'un CMS sans la partie liée à la distribution et à la présentation du contenu à son audience, se concentrant uniquement sur la phase de création. Un CMS Headless brille vraiment dans certaines circonstances lorsque vous souhaitez fournir du contenu dynamique (via des APIs) dans une application mobile ; publier du contenu sur des plateformes, des canaux et des appareils connectés ; ou intégrer des contenus dans une application Web existante.
En se concentrant uniquement sur la création de contenu, un CMS Headless le rend plus accessible aux utilisateurs, mais sa portée est plus limitée qu'un CMS d'entreprise traditionnel.
Cartographier les fonctionnalités, identifier les tâches
Lors du remplacement d'un CMS ou DXP traditionnel existant par une configuration CMS Headless, une tâche importante consiste à identifier les tâches que vos éditeurs de contenu, votre équipe marketing et d'autres utilisateurs effectuent quotidiennement. Vous devriez envisager de cartographier tout écart de caractéristiques entre les deux dans les fonctionnalités clés.
En plus des besoins de gestion de contenu tels que des modèles de contenu et des workflows riches, assurez-vous de cartographier des fonctionnalités pour les tâches de gestion de sites périphériques comme la navigation, les redirections, la modification des structures de page de destination, l'ajout de scripts de suivi pour le marketing et le suivi de l'utilisabilité.
Tout ce qui précède peut être réalisé avec un système intégré ou une combinaison d'une API de contenu et d'une couche d'affichage. La différence est que pour ce dernier, vous devrez peut-être ajouter des outils tiers et des intégrations supplémentaires.
Dans une solution CMS Headless, la couche d'affichage (le « front-end ») devient un choix stratégique. Lors d'un déploiement d'un CMS traditionnel, les templates et les implémentations frontales sont aisément remplaçables.
Dans une implémentation traditionnelle d'un système de gestion de contenu Web (WCMS), qui peut être active pendant cinq à dix ans après le projet d'implémentation initial ; il est souvent nécessaire de procéder à une refonte fonctionnelle dans les moindres détails. Les projets ont tendance à ajouter de plus en plus de fonctionnalités, notamment au niveau de la couche back-office. Dans une solution de gestion de contenu intégrée de bout en bout, l'API de contenu et la couche d'affichage sont par nature étroitement couplées - elles font partie du même package.
L'une des principales propositions de valeur de l'architecture Headless est que les deux sont indépendants, offrant plus de liberté et de flexibilité. La clé pour maintenir la flexibilité d'une implémentation Headless est de développer consciemment des fonctionnalités à usage unique. Divisez les capacités complexes en services réutilisables qui ne sont liés à aucune couche d'affichage donnée. Cela vous permettra de profiter des avantages de l'approche découplée même au cours des années de développement.
Chez eZ, nous proposons une plate-forme qui permet tout autant l'utilisation de la plate-forme the contenu en mode Headless qu'en mode traditionnel. Nous pensons qu'en fonction des cas d'utilisation, l'une ou l'autre des approches peut être plus indiquée, et nous avons également de nombreux exemples ou l'entreprise trouvera énormément de valeur dans la possibilité de combiner les deux dans le cadre de projets d'envergure.