Gestion de contenu : faut-il passer au headless CMS et au Content as a service ?

8 Mai 2017
fabricefrossard
4064
0

Les CMS monolithiques  sont-ils en voie d’obsolescence ? La question émerge progressivement sous la pression de la diffusion massivement omnicanal des contenus.  Amp, Instant articles, médias sociaux, nouveaux périphériques, IoT, réalité virtuelle, chatbot, assistant personnel…désormais les contenus sont diffusés sur de multiples canaux et doivent être adaptés au format d’affichage du périphérique d’affichage, et surtout à l’application cible.

La démarche la plus courante est aujourd’hui d’utiliser son CMS (wordpress, drupal…) comme base-arrière et utiliser de multiples plugins et APIs pour diffuser et conformer le contenu aux médias de destination. Avec en contrepartie la difficulté à afficher le contenu comme on le souhaite. Ce qui est particulièrement saillant lorsque l’on souhaite envoyer du contenu vers applications IOS ou Android, ou adapter des chatbots au contenu existant. Sans compter l’utilisation d’outils tiers pour automatiser par exemple les partages sociaux.

Headless CMS : un découplage entre contenu et code

Depuis 2013, pour pallier ces défauts, apparaissent ce que l’on nomme les Headless CMS. Pour faire (très) simple, le système de gestion de contenu (CMS) sans-tête peut être considéré comme un réservoir à contenu, positionné dans le cloud, dans lequel des interfaces de programmation (en l’occurrence RESTful APIs) vont puiser pour diffuser et afficher le contenu au format attendu selon le média.

Autrement dit, il y a un découplage entre le répertoire de contenus et le front-end. Plutôt que de créer une page web statique, vous pouvez puiser les éléments de la page séparément, le titre, la description et considérer chacun de ces éléments comme un contenu structuré qui peut être diffusé n’importe où comme le montre le schéma ci-dessous issu de Kenticloud.

Kenticocloud

 

Headless CMS : en route vers le contenu as a service

Cette approche découplée présente plusieurs avantages. Le premier d’entre eux est que l’équipe dédiée à la création de contenu peut se focaliser uniquement sur la création sans penser à la présentation formelle. En étant asynchrone, la production peut répondre à de nouvelles logiques de workflow.

Le second porte sur un « désilotage » de fait de la création de contenu. La plupart du temps chaque service de l’entreprise produit son contenu et le diffuse selon son timing, ses objectifs propres et ses canaux. Une approche généralisée qui fait perdre en cohérence globale dans les messages émis par l’entreprise. Avec un réservoir commun, l’ordonnancement des contenus est supervisé et peut plus aisément s’inscrire dans un cadre global cohérent et surtout permet de se focaliser sur l’expérience digitale, mots pompeux pour évoquer les services rendus, en éradiquant la complexité de la gestion du contenu.

Headless CMS : pour qui ?

Séduisant sur le papier, le Headless CMS reste pour l’heure destiné à des cas d’utilisation très spécifiques. Typiquement ce type d’architecture est adaptée aux médias et autres créateurs de contenus chauds dont le contenu est diffusé sur de multiples plateformes via des API.  A l’identique, si votre contenu doit être poussé vers des terminaux de type affichage publicitaire interactif ou application mobile, cela peut un cas d’usage type. Bref, tous les cas d’usages « cross-platform ». A contrario, si la présentation est relativement statique, indépendamment de la profondeur de contenu et fait peu appel à des services tiers, le recours à ce type de système de gestion ne fait pas forcément sens.

D’autre part, cela s’adresse aussi aux entreprises pourvus de développeurs ou aux moyens suffisants. Là où chacun peut créer un  WordPress ou un drupal avec une certaine facilité, le Headless demande l’intervention de développeurs chevronnés pour instancier le contenu avec REST et s’amuser avec les langages de script, et bien sûr des codeurs front-end pour les interfaces graphiques. Et autant de codeurs pour fournir chacun des microservices associés, par exemple une fonction e-commerce, commentaire ou autre. Contrairement à un CMS monolithique, chaque service additionnel devra être créé. De nombreuses APIs facilitent le boulot, mais les profanes du code auront un peu de mal.

WordPress – Drupal en mode Headless

Faut-il jeter le CMS avec l’eau du bain ? D’une part le besoin en headless est spécifique, d’autre part la transition vers le headless se fera avec une phase transitoire. Preuve en est, les deux principaux CMS se sont déjà adaptés à cette transformation.

WordPress a ainsi adopté l’API Rest depuis la version 4.5. Cela lui permet de créer, modifier, supprimer ou récupérer des contenus automatiquement. Bref de créer des interactions selon vos objectifs. Cela peut se faire avec le thème en place ou indépendamment du thème, ce qui induit d’avoir un répertoire différent pour votre contenu, voire de le positionner sur un serveur tiers.

Pour passer Wordpres en Headless des plugins ont déjà été développés :

ACF to WP REST API 

Wp REST API Force SSL 

WP REST API 

Reste que ce passage est encore du work in progress et nécessite une véritable connaissance en développement, une maîtrise des langages de script (angular et consorts…) sans compter le besoin de surveiller le comportement des composants comme le lait sur le feu.

Pour Drupal, l’opération est là aussi relativement aisée selon les spécialistes et le passage vers les headless peut se faire de manière couplée au front-end ou en puisant dans un réservoir indépendant. Pour aller plus loin je vous recommande ce très bon article de Dries Buytaert sur l’architecture headless de Drupal.

Quelle offre pour les CMS Headless

Certains éditeurs se positionnent directement sur cette architecture headless ;

dont ContentFul

headless contentful

Le CMS de Contentful

 

Prismic.io

prismic

Prismic.IO

Ou encore :

Kenticocloud

Zesty IO

DatoCMS 

LAMP n’est pas encore éteint

Vous l’aurez compris, la nouvelle alternative n’est pas site web ou non, mais CMS monolithique vs headless. Dans tous les cas, cette nouvelle architecture peut être pertinente pour concevoir un site web, ne serait-ce que par la rapidité de chargement obtenue grâce à une gestion du cache totalement différente; mais se destine surtout à des architectures de contenu avec de multiples services  et canaux de distribution associés. L’idée force du headless CMS est bien de passer à une logique de content as a service (CaaS) ce qui va dans le sens de l’histoire technique emmenée par le cloud. En contrepartie, l’implémentation dans un cloud induit de se reposer la plupart du temps sur un tiers et d’utiliser un framework particulier. Nous sommes loin de la standardisation connue avec l’architecture LAMP, certes vieillissante, mais qui a fait ses preuves. Enfin, le recours au headless doit répondre à une étude en amont très poussée.

Pour aller plus loin, je vous conseille la lecture de cet article par Roland Benedetti d’EzPublish (un autre CMS aux fonctions Headless) ou encore de celui de l’ami Fred Cavazza, « les sites web sont-ils en voie de disparition ? « 

Si vous voulez tester la méthode, vous pouvez aller sur le site de prismic 

Print Friendly, PDF & Email
The following two tabs change content below.

fabricefrossard

De son métier de journaliste où il a largement contribué au développement digital, Fabrice Frossard conserve une excellente connaissance des nouvelles technologies qui lui permettent d’anticiper les évolutions sociétales et de détecter les modèles émergents. Il a aussi travaillé en agences en tant que directeur du digital. Aujourd’hui Fabrice accompagne les entreprises et les institutions en tant que spécialiste des stratégies de contenus et de la communication digitale.

Laisser un commentaire