Les avantages d’un CMS headless : souplesse et capacité à évoluer
Comprenez le fonctionnement d’un CMS headless à travers une conférence publiée sur un site et une application : possibilités offertes, besoins éditoriaux et essai du processus complet.
Un même ensemble de contenus, plusieurs présentations. Chaque site ou application doit toutefois être développé et connecté.
Imaginez que vous publiiez l’annonce d’une conférence. Son titre, sa photographie, sa description et son heure de début doivent figurer sur votre site et dans une application mobile. Si l’horaire change, vous souhaitez ne le corriger qu’une seule fois. Vous voulez aussi que le site ressemble à un site et que l’application offre l’expérience d’une application.
Un système de gestion de contenu headless sépare ces deux fonctions : organiser l’information et déterminer la manière dont les lecteurs la voient. Cette séparation peut être utile. Son intérêt dépend de ce que vous devez publier et des personnes qui développeront et entretiendront les connexions.
Que signifie exactement « headless » ?
Un CMS est l’espace dans lequel un rédacteur écrit, organise et publie du contenu. Dans une configuration classique, il fournit aussi les modèles qui transforment ce contenu en pages web. Un CMS headless confie la présentation à un site, une application ou une autre interface distincte.
Les deux parties communiquent par une API : un mode de communication convenu qui permet à un logiciel de demander des informations à un autre. Le site peut demander le titre, l’horaire et la photographie de la conférence, puis les intégrer à sa propre mise en page. L’application peut demander les mêmes informations et les disposer autrement.
Strapi en est un exemple. Il fournit une interface de rédaction, des modèles de contenu et des API que les applications peuvent utiliser. L’API donne aux développeurs accès au contenu ; elle ne conçoit pas à leur place l’expérience du lecteur.
Quand cette souplesse devient utile
Un même contenu peut être utilisé à plusieurs endroits. L’horaire de la conférence peut être enregistré dans un seul champ, au lieu d’être recopié dans plusieurs pages tenues à jour séparément. Chaque application a néanmoins besoin d’une connexion fonctionnelle et d’un moyen de récupérer les modifications. Une ancienne page en cache peut rester obsolète jusqu’à son actualisation.
Une nouvelle présentation n’oblige pas à réécrire chaque article. Si les titres, paragraphes, images et légendes sont stockés indépendamment d’une mise en page particulière, une nouvelle interface peut les réutiliser. Cette approche fonctionne mieux lorsque le modèle de contenu décrit clairement les éléments, plutôt que de stocker un seul grand bloc de balisage propre à une mise en page.
Différents lecteurs peuvent bénéficier de présentations différentes. Un écran de téléphone, un long article et un écran d’affichage événementiel répondent à des besoins distincts. Les mêmes informations peuvent servir aux trois sans leur imposer un modèle unique.
Ce que l’architecture ne fait pas à votre place
Headless ne signifie pas automatiquement rapide. Une page peut être préparée à l’avance et servie rapidement, ou enchaîner des requêtes lentes avant que quoi que ce soit apparaisse. Les images, la mise en cache, l’hébergement et la façon dont l’interface est construite continuent de déterminer le résultat. Séparer les composants donne à l’équipe plusieurs possibilités pour améliorer les performances et accroître la capacité ; quelqu’un doit faire ces choix et les tester.
Les équipes éditoriales ont également besoin de plus qu’un champ de saisie. Elles doivent pouvoir prévisualiser un brouillon, vérifier les liens et les images, publier dans la bonne langue et retrouver une version antérieure. Les développeurs doivent relier ces fonctions à la nouvelle interface. Un système élégant sur un schéma d’architecture peut malgré tout compliquer la publication au quotidien.
La même distinction vaut pour la maîtrise du système. Une API ne détermine pas qui peut modifier les règles, si vous pouvez tout exporter ou si vous pourrez continuer à publier lorsqu’un fournisseur cessera de vous fournir son service. Les réponses dépendent du logiciel, des conditions d’hébergement, des autorisations et des possibilités concrètes de passer à un autre système.
Essayez un processus de publication complet
- Choisissez un contenu représentatif : par exemple, une conférence avec une photographie, une date, une description et une seconde langue.
- Demandez à la personne qui le rédigera de créer un brouillon et d’en prévisualiser la présentation réelle sur le site et dans l’application.
- Publiez-le, modifiez l’horaire et vérifiez à quel moment chaque destination affiche la correction.
- Rétablissez la version précédente. Exportez le contenu et les médias, puis vérifiez ce qu’il faudrait pour les utiliser ailleurs.
Ce petit essai en dit plus qu’une liste de fonctionnalités. Il montre si l’architecture offre à votre équipe une liberté utile et si le travail quotidien reste gérable.
Choisissez cette architecture pour répondre à un besoin de publication
Une architecture headless peut être très adaptée lorsque plusieurs applications ont besoin du même contenu structuré ou lorsque l’expérience de lecture exige un important développement sur mesure. Pour un site simple avec une seule destination de publication, un système réunissant rédaction et présentation peut demander moins de travail. Partez du travail à accomplir, puis choisissez l’architecture.
Pour une comparaison plus large, lisez comment choisir un CMS selon l’effort de publication et la possibilité de changer de système.