Choisir entre architectures CMS headless, couplée et hybride

Un CMS traditionnel, ou couplé, stocke le contenu et génère les pages qui l’affichent. Les rédacteurs travaillent dans un système qui sait à quoi ressemble la page ; les développeurs créent les gabarits à l’intérieur de ce système. Un CMS headless stocke et gère le contenu et l’expose via une API, et la « tête » (le site web, l’application mobile, l’écran de borne) est une application distincte qui récupère le contenu et l’affiche de manière indépendante.

Toute la différence tient à cette séparation. Chaque avantage attribué au headless (rapidité, flexibilité, frameworks front-end modernes, diffusion multicanale) en découle, tout comme chaque inconvénient. Le contenu devient des données structurées et non plus des pages, ce qui apporte de la flexibilité mais suppose que quelqu’un conçoive cette structure. L’affichage devient une application propre à l’organisation, dont l’équipe assume alors les performances, l’accessibilité et la disponibilité.

Le headless se justifie le mieux pour un contenu qui doit apparaître à plusieurs endroits. Par exemple : un groupe disposant d’une douzaine de sites de marque qui partagent des informations produit, des mentions légales et des communiqués de presse ; une entreprise qui publie le même contenu sur un site web, une application mobile et des écrans en magasin ; une organisation qui travaille en trois langues et dont les traductions doivent rester alignées sur la source. Dans chaque cas, stocker le contenu une seule fois sous forme d’entrées structurées et multilingues, puis le diffuser via une API, supprime une grande partie des copies et des incohérences qui les accompagnent.

Le headless convient aussi aux organisations dotées d’une solide équipe front-end qui développe déjà en React ou avec des frameworks similaires et souhaite traiter le site web comme un produit, avec les mêmes pipelines, tests et pratiques de déploiement que ses autres applications. Si cette équipe existe, une API de contenu lui convient mieux qu’un système de gabarits.

Les développeurs préfèrent en général le headless : une API propre, un front-end qu’ils maîtrisent, aucun langage de gabarits hérité. Les rédacteurs sont souvent moins enthousiastes, et c’est leur expérience qui détermine si le contenu est publié. Dans un CMS couplé, le rédacteur voit la page telle qu’elle apparaîtra, fait glisser un composant à sa place et clique sur Publier. Dans une configuration purement headless, les rédacteurs remplissent les champs d’un formulaire en comptant sur le front-end pour bien les afficher. L’aperçu de la page réelle avec du contenu non publié doit être développé, de même que la planification, le workflow et les validations si le CMS ne les fournit pas.

Avant de choisir le headless, interrogez les rédacteurs. Déterminez combien de pages ils publient par semaine, s’ils créent eux-mêmes les pages d’atterrissage ou s’adressent à un développeur, et s’ils ont besoin de voir la page pendant la rédaction. Si le marketing doit créer et modifier des pages sans l’aide de l’équipe technique, l’organisation a besoin soit d’un CMS offrant une véritable édition visuelle en plus de son API, soit d’un modèle hybride, et doit dans les deux cas prévoir un budget pour les outils d’aperçu et de composition.

C’est dans l’e-commerce que ce choix a le plus de conséquences. Une architecture headless associe une plateforme de contenu à un moteur de commerce, un service de recherche et un prestataire de paiement distincts : c’est ce qu’on appelle une architecture composable. Pour un distributeur aux besoins spécifiques et doté d’une équipe compétente, elle apporte le meilleur de chaque solution et la liberté de remplacer n’importe quel élément. Pour la plupart des organisations, elle implique aussi d’assumer l’intégration entre catalogue, contenu, panier, paiement et promotions, et de garder alignées les feuilles de route de plusieurs éditeurs.

Une plateforme intégrée, dans laquelle contenu et commerce partagent un modèle de données et une interface d’administration, supprime ce coût d’intégration et offre généralement aux équipes merchandising un meilleur confort au quotidien. La décision dépend de la question de savoir si les besoins en e-commerce sont suffisamment particuliers pour justifier d’assembler l’architecture en interne. Dans bien des organisations, ce n’est pas le cas.

Les sites headless sont souvent rapides, mais cette rapidité tient à la façon dont le front-end est construit plutôt qu’à l’architecture elle-même. Ils sont rapides lorsque les pages sont générées à l’avance ou en périphérie (edge), mises en cache de manière intensive, et que le contenu est récupéré à la compilation ou à la requête plutôt que dans le navigateur à chaque visite. Un site headless qui appelle l’API de contenu depuis le navigateur pour chaque composant peut être plus lent que le CMS couplé qu’il remplace. Un CMS couplé bien configuré derrière un CDN sert lui aussi les pages très rapidement.

Traitez les performances comme une exigence assortie d’un budget (délai d’affichage du premier contenu, plus grand élément de contenu, disponibilité pour l’interaction) et demandez à chaque architecture candidate de démontrer comment elle respecte ce budget, y compris sur les réseaux mobiles et pas seulement sur une connexion de bureau.

Choisissez un CMS couplé ou hybride lorsque le contenu vit sur un seul site web, que les rédacteurs doivent composer eux-mêmes les pages, que l’équipe technique est réduite ou partagée avec d’autres systèmes et que le délai de lancement compte davantage que la latitude architecturale. C’est le cas d’un très grand nombre de sites marketing, d’intranets et de portails de services d’entreprise. Un CMS hybride, qui génère les pages tout en exposant l’ensemble via une API, couvre le site web dès aujourd’hui et laisse la place à une application ou à un second canal par la suite.

Choisissez le headless lorsque le contenu a plusieurs destinations, que les traductions et les sites de marque doivent rester cohérents sur de nombreuses propriétés, qu’une solide équipe front-end souhaite maîtriser l’expérience, ou que les besoins en e-commerce appellent une architecture composable que l’organisation est prête à exploiter. La décision dépend de l’organisation, et non de la réputation de la technologie.