5 minutes de lecture
Sur cette page
En une phrase, l’architecture de système de gestion de contenu headless sépare les fonctions de contenu back-end (telles que la création, la gestion et le stockage) des fonctions front-end (telles que la présentation et la livraison).
Avant d’entrer dans les détails techniques, commençons par ce que cela signifie dans le contexte de l’expérience de marque.
L’architecture headless est en partie une réponse à la façon dont la relation entre le contenu web et la création de contenu a évolué. Pendant longtemps, la plupart du contenu Web a été livré par un navigateur, souvent sous forme de page Web. Mais de nouveaux devices connectés arrivent tout le temps et le public consomme du contenu par différentes interfaces utilisateur, comme les devices intelligents, les appareils portables, les assistants vocaux compatibles avec l’intelligence artificielle et les casques de réalité virtuelle (VR).
L’architecture de système de gestion de contenu sans tête est fondamentale pour relever ces nouveaux défis en matière de contenu. Cela signifie que vous pouvez facilement créer et gérer autant de contenu que votre public l’exige et adopter une approche omnicanale qui fournit du contenu à tous les points de contact pertinents.
Les systèmes monolithiques traditionnels gestion de contenu ont deux moitiés : une avant et une arrière.
D’une manière générale, le back-end d’un système de gestion de contenu se rapporte à la façon dont le contenu est géré, et le front-end se rapporte à la façon dont il est présenté. Considérez-le comme une vitrine de magasin.
Les tâches front-end comprennent tout ce que vous verriez en regardant dans la rue : la sélection et l’agencement des produits et de l’image de marque.
Les tâches d’arrière-plan comprennent la logistique : la fabrication de la signalisation, le stockage de l’inventaire et la gestion du mouvement des marchandises dans le magasin.
Ainsi, pour un site Web de base, le back-end peut inclure :
Le front-end extrairait ensuite le contenu par, les ressources de marketing stockées et les conceptions et les publierait sur une page HTML.
Avec un système de gestion de contenu traditionnel, la présentation frontale, également connue sous le nom de couche de présentation, et le back-end étaient étroitement verrouillés ensemble. Les utilisateurs peuvent créer, stocker, gérer et publier du contenu au sein d’une seule interface.
Pour les utilisateurs non techniques et les éditeurs de contenu publiant du contenu simple - par exemple, un blog WordPress - il s’agissait d’une excellente configuration transparente.
Mais à mesure que les expériences numériques et le commerce électronique continuent d’évoluer, les développeurs passent trop de temps à créer des solutions de contournement personnalisées pour optimiser les expériences et fournir un contenu plus sophistiqué sur tous les devices.
Les CMS découplés divisent les tâches back-end et front-end. En pratique, cela signifie que les développeurs peuvent rapidement coder et concevoir des expériences front-end dans leur langage préféré sans être liés par des technologies back-end restrictives.
Au lieu de cela, ils peuvent utiliser l’API RESTful ou l’API GraphQL pour connecter les fonctions back-end, telles que le stockage et la gestion de contenu, à n’importe quel environnement de livraison front-end.
Lorsque les CMS découplés séparent les fonctions back-end et front-end, ils incluent souvent encore certains outils de livraison front-end, tels que des modèles de page ou des intégrations de modules.
Les CMS API-first sont fonctionnellement identiques aux systèmes headless CMS en ce sens qu’ils n’ont pas de front-end par défaut. Les développeurs sont libres de créer autant de couches de diffusion que nécessaire (dans la langue qu’ils préfèrent) pour pousser le contenu vers n’importe quel nouveau canal imaginable.
Les CMS API-first sont parfaits si vous disposez d’une équipe de développeurs qualifiés prêts à l’emploi : le système de gestion de contenu gère simplement le contenu et attend un appel d’API à partir d’une couche de livraison frontale créée par l’équipe de développement.
Les CMS découplés, quant à eux, conviennent aux entreprises qui souhaitent bénéficier de la flexibilité d’un front-end et d’un back-end distincts, mais qui peuvent tout de même avoir besoin d’un support de publication.
Les solutions de systèmes de gestion de contenu headless sont sans aucun doute l’avenir de la gestion de contenu, pour deux raisons importantes :
En adoptant le contenu structuré et la modélisation de contenu dans un système headless CMS système de gestion de contenu, les marques peuvent améliorer leurs opérations de contenu et offrir un meilleur expérience utilisateur à leurs clients.
...ils peuvent créer du contenu une seule fois tout en permettant à leurs développeurs de l’afficher n’importe où. Cela signifie moins de temps consacré à l’administration et plus de temps à la création d’expériences belles et cohérentes.
En permettant de réutiliser le contenu, le hub de contenu centralisé supprime les processus manuels, tels que le copier-coller. Les spécialistes du marketing et les créateurs de contenu peuvent également modifier la mise à jour une seule fois et la partager n’importe où.
...l’expérience utilisateur final est toujours rapide, cohérente et réactive. C’est parce que le côté client n’a pas besoin de communiquer avec le système back-end - il doit juste rendre le contenu.
Ils sont libérés des restrictions back-end des langages de programmation où ils manquent d’expertise. Au lieu de cela, ils peuvent créer l’apparence, la convivialité et les fonctionnalités des expériences utilisateur à l’aide d’outils qu’ils connaissent et apprécient (par exemple, les bibliothèques et les frameworks JavaScript), puis diffuser le contenu n’importe où à l’aide des dernières API.
Développeurs ont la possibilité de choisir leur cadre front-end préféré et diverses options sont disponibles pour les générateurs de sites statiques, par exemple, Next.js, Gatsby.js et NUXT.js. Dans un système headless CMS système de gestion de contenu open-source, les développeurs peuvent accéder au code (JavaScript, PHP) pour créer leurs propres appels et modèles d’API.
Les systèmes de système headless CMS gestion de contenu prêts à l’emploi ne sont pas une solution miracle pour résoudre tous vos problèmes de contenu. Ils peuvent s’accompagner de deux compromis majeurs qui doivent être sérieusement pris en compte.
D’une part, ce que vous gagnez en flexibilité avec ce type de référentiel de contenu, vous le perdez en accessibilité. Étant donné que la présentation est laissée aux développeurs qui écrivent du JavaScript, les spécialistes du marketing non techniques ne peuvent pas utiliser la création ou l’édition WYSIWYG (What You See Is What You Get).
Le second est plus grand.
Quelque chose de drastique se produit lorsque vous coupez la tête d’un système de gestion de contenu : vous coupez la possibilité d’envoyer des données d’interaction client entre le front-end et le back-end en temps réel.
Cela signifie que vous ne pouvez pas personnaliser d’expériences ou exécuter du contenu données analytiques des activités.
La personnalisation est passée d’un « nice to have » à une exigence de table. Les clients apprennent à quoi ressemble une bonne personnalisation grâce à des leaders de l’industrie comme Amazon, Netflix, Spotify et d’autres.
Si vous ne pouvez pas fournir une expérience similaire, les clients iront probablement ailleurs – et bientôt. Alors, quelle est la réponse ?
L’architecture système de gestion de contenu idéale combinerait la flexibilité et l’extensibilité des plates-formes système headless CMS système de gestion de contenu avec la personnalisation et le contenu données analytiques capacités offerts par les système CMS non-headless traditionnels.
C’est exactement ce que Les options de livraison composable et système headless CMS de Sitecore fournissent.
Plusieurs options de système headless CMS prennent en charge les développeurs frontaux lorsqu’ils créent des solutions et des applications qui affichent du contenu sur n’importe quel appareil ou navigateur. Qu’il s’agisse d’utiliser des bibliothèques JavaScript telles que Vue.js, React.js et Angular.js, ou de tirer parti du nouveau ASP.NET Core SDK et de l’architecture hôte système headless CMS rendu, les développeurs peuvent choisir ce qui leur convient le mieux.
Ces options sont également fournies avec une API qui se connecte au serveur de diffusion de contenu contextuel de Sitecore, de sorte que les utilisateurs voient un contenu personnalisé basé sur les informations de profil, les interactions passées et plus encore en temps réel.