Les CMS Headless ont-ils oublié les équipes de contenu ?

Les CMS Headless ont-ils oublié les équipes de contenu ?
tenant un masque d'escrime

PHOTO:
Alev Takil | unsplash

Les systèmes de gestion de contenu (CMS) existent depuis des décennies et comme beaucoup de choses qui survivent à l’épreuve du temps, ces solutions ont subi de nombreuses métamorphoses. Un CMS conventionnel, simple et tête-en-tête, offre trois fonctionnalités principales : le stockage de données, une interface utilisateur pour la gestion de contenu et un mécanisme de diffusion de contenu.

Alors, que se passe-t-il lorsque vous coupez la tête?

Le pendule oscille à nouveau avec les DXP sans tête

Dans un sprint pour devenir ultra-agilité et ultra-flexible, dépriorisons-nous l’importance et l’expérience de l’auteur avec nos (supposées) plateformes d’expérience numérique sans tête (DXP) ?

L’expérience de création dans la plupart des nouvelles plates-formes de diffusion de contenu sans tête a, encore une fois, fait reculer la technologie. Des questions comme :

  • Comment vous déployez-vous ?
  • De quelle manière technique ?
  • Vers quelle chaîne ?

A supplanté les priorités de l’expérience de création telles que :

  • L’interface utilisateur de création est-elle intuitive ?
  • L’outil est-il accessible ?
  • Un auteur peut-il s’intéresser à la technologie ou a-t-il besoin d’un doctorat. en développement front-end ?

Ayant été dans cette entreprise pendant plus de 20 ans, j’ai vu les hauts et les bas du monde de la gestion de contenu, et je pense que le pendule tourne dans la mauvaise direction.

Article connexe : Pourquoi nous avons besoin d’un nouveau grand compromis dans les systèmes de gestion de contenu

Un rapide historique du CMS Web

À la fin des années 90, nous avons assisté à la montée en puissance des titans des systèmes de gestion de contenu (CMS) : Documentum, Vignette et Interwoven (entre autres). Ainsi ont commencé les premières batailles entre les auteurs de contenu et l’interface de création de contenu. Cette bataille s’est déroulée avant que le Web 2.0 surmédiatisé ne se retrouve sur le devant de la scène et que l’interface Web et sa convivialité soient soudainement devenues la priorité de la communauté numérique.

Au début, l’accent était mis sur le visiteur du site, encourageant l’interactivité avec le site. Répondre à ce besoin de contenu a nécessité une augmentation significative de la vitesse du contenu (plus de contenu, plus souvent, à une cadence plus élevée) et a rapidement poussé les fournisseurs de logiciels de système de gestion de contenu à emboîter le pas. Comment pouvons-nous améliorer la relation entre nos produits et les utilisateurs ? La vitesse et la productivité étaient au cœur de cette nouvelle vague, répondant à une nouvelle question : à quelle vitesse pouvons-nous ajouter du contenu convaincant à nos sites ?

Alors que la révolution numérique se poursuivait, un nouveau besoin est apparu : l’utilisabilité des systèmes par des utilisateurs non techniques.

La convivialité n’était pas un besoin nouveau, mais permettrait aux équipes de marketing et de contenu (c’est-à-dire aux équipes non techniques) de s’approprier véritablement le processus de gestion de contenu en supprimant les exigences de compétences HTML et JavaScript aléatoires des précédentes itérations du CMS. L’époque du « webmaster » était révolue. De gros acteurs du marché, comme Fatwire, RedDot et Percussion, ont repris une page de certains des premiers systèmes d’édition en page, comme Contribute de Macromedia, et ont commencé à introduire de nouvelles façons de saisir du contenu. In-context – pas seulement un éditeur WYSIWYG qui affichait quelques styles, mais une page qui tentait de ressembler au rendu final d’une page publiée – est devenu la norme à respecter. Pouvoir cliquer sur un petit point rouge et modifier le contenu « juste là » était un énorme tirage et la clé du nom de, vous l’avez deviné, RedDot.

Mais il y avait des inconvénients. Le processus était lent, le résultat présentait souvent un mauvais alignement et les systèmes étaient difficiles à coder. Par conséquent, permettre l’édition et la prévisualisation du contenu structuré a demandé de sérieux efforts. Les progrès réalisés par les auteurs de contenu vers la convivialité ont été considérables. Ou, comme la plupart d’entre nous l’ont vu, un changeur de jeu pour la paternité du contenu et la portabilité de l’entrée de contenu.

À partir de cette première ère de contenu centré sur le propriétaire, CMS est venu une nouvelle génération de plates-formes CMS qui ont fourni des niveaux concurrents de création en contexte. Sitecore, Adobe, SDL Tridion, FatWire Content Server et Drupal sont devenus des leaders s’efforçant de fournir l’expérience d’édition contextuelle la plus riche en fonctionnalités. Chaque sortie était un témoignage de cet objectif. Étaient-ils parfaits ? Non, et dans certains cas pas du tout ! Mais ils ont fait un effort concerté, et chaque version était une étape vers une meilleure expérience utilisateur pour l’un de leurs principaux clients : l’auteur de contenu.

Article connexe : Avec la diffusion de contenu, ce qui se passe autour de vous

Où en sommes-nous maintenant avec la diffusion de contenu ?

Une multitude de nouveaux produits CMS sans tête ont inondé le marché, beaucoup sous le terme générique DXP. Chacun vante ses côtelettes techniques et écrit des éloges sur la mort du CMS monolithique. Avec headless, microservices et découplage étant le mantra de cette ère de DXP, l’expérience de création a pris un peu de recul en importance et en concentration pour de nombreuses plateformes headless populaires.

Cela ne veut pas dire qu’une approche sans tête ou microservice est terrible – ce n’est pas le cas. C’est excellent, permettant de séparer de nombreuses préoccupations liées à la gestion de contenu. Autrefois, nous appelions cela « découplé » ou « au four, pas frit ».

cms découplés cuits

Une approche big-bang « cuite » – avec des sites Web entiers publiés à la fois – était en proie à un manque d’interactivité avec d’autres systèmes (comme, se connecter ou, pour les plus audacieux, la personnalisation). Cette lacune a été comblée (au moins en partie) par du JavaScript asynchrone. Cependant, une série d’API à latence élevée de certains systèmes étaient souvent lourdes et nécessitaient de grandes quantités de bande passante et de puissance de calcul. JavaScript n’était pas une panacée.

Au début des années 2000, de nombreux ergs d’énergie ont été déployés pour convaincre les organisations de déplacer leur production de contenu hors des cycles de vie de développement de logiciels (SDLC) centrés sur les développeurs. Cette approche lourde, un va-et-vient apparemment sans fin d’édition de copie entre les auteurs de contenu et les développeurs, était douloureusement lente et sujette aux erreurs. Nous avons appelé cela l’ère de la libération du contenu et nous sommes allés au-delà, en nous concentrant davantage sur la richesse des fonctionnalités et les améliorations continues de la convivialité.

Aujourd’hui, on nous présente un grand nombre de plates-formes de contenu sans tête, SaaS, basées sur des microservices qui ont peu ou pas de réelles capacités de création de contenu. Ils nous ramènent aux premiers jours du CMS, où les auteurs de contenu devaient compter sur la patience des utilisateurs techniques pour expliquer, former et même saisir leur contenu. L’aspect visuel et la convivialité des expériences numériques, construits séparément, à dessein, entravent fortement la capacité d’un auteur de contenu à voir à quoi ressemblerait l’expérience avant de publier. De nombreuses solutions de contournement ont été et continuent d’être créées pour combler cette lacune. Le résultat? Nous commençons maintenant à voir une résurgence de la demande d’outils de création de contenu.

À titre d’exemple, l’une des principales plateformes de contenu de la nouvelle ère, Contentful, a lancé son expérience d’édition appelée Compose en 2021, sept ans après le lancement de son produit principal. À mon avis, c’est de loin la meilleure expérience d’édition sur cette nouvelle génération de plates-formes. Pourtant, cela leur a pris sept ans — sept ans ! — de reconnaître que l’un de leurs principaux publics était complètement mal desservi (lu, ignoré). Alors que les DXP’ plus établis qui ont passé de nombreux cycles de publication à se concentrer sur ce besoin sont mis de côté pour l’agilité technique.

Article connexe: Un voyage dans la mémoire WCM

DXP sans tête : bien conçus ? ou piraté ensemble ?

Il n’y a pas de solution unique en matière de gestion de contenu. De même, aucune technologie ne comblera toutes les lacunes pour les besoins de gestion de contenu de toutes les organisations. Pour certains, un CMS traditionnel, avec toutes les parties du corps attachées, sera le bon choix. Pour d’autres, le DXP sans tête sera une solution pratique.

Cela dit, ce cycle de développement prolongé et ce revirement soudain donnent matière à réflexion à ceux qui envisagent leur prochain investissement CMS/DXP et soulèvent la question suivante : les DXP sans tête d’aujourd’hui sont-ils vraiment sans tête – ou plutôt un monstre de Frankenstein ?

Dustin Collis, directeur principal des solutions de contenu à l’EPAM, a plus de 20 ans d’expérience dans le conseil, en se concentrant sur les entreprises clientes ayant des besoins commerciaux critiques sur le marché numérique.

Les CMS Headless ont-ils oublié les équipes de contenu ?

#Les #CMS #Headless #ontils #oublié #les #équipes #contenu