On entend partout parler de CMS Headless, de Content As A Service, mais qu’en est-il exactement ? Qu’est-ce que c’est, et surtout quel intérêt et quel impact pour les développeurs et les éditeurs de contenus ?
C’est quoi une CMS Headless ?
Les CMS Headless sont avant tout des systèmes d’édition de contenu ; ça c’est la partie CMS (Content Management System), mais qui ont une particularité bien spécifique, c’est qu’ils s’affranchissent totalement de la façon dont ils sont affichés : par qui, par quoi ? Ils s’en moquent. En d’autres termes, ils sont totalement indépendants de toute plateforme d’affichage et de canvas. Ce qui signifie qu’ils ne dépendent pas d’une technologie en particulier pour fonctionner. Et c’est là toute leur puissance.
En effet, si un contenu n’est pas dépendant d’une technologie particulière pour exister, cela signifie qu’il peut être bien plus flexible dans la manière dont il va être distribué.
Et dans les faits ça donne quoi ?
Imaginons que l’article que vous êtes en train de lire actuellement soit « Headless », pour moi qui écris cet article, ça signifie plusieurs choses :
Pour commencer, je peux récupérer et utiliser ce contenu dans différentes applications. Pourtant je n’ai pas à faire de réplication car la source du contenu restera inchangée. Si je souhaite que certains de mes articles soient affiché à la fois sur mon site mais aussi dans une application mobile de mon cru (ou de quelqu’un d’autre d’ailleurs), je n’ai qu’à écrire mon contenu et « brancher » les applications concernée avec la plateforme sur laquelle j’édite mon texte. Je ne suis pas forcé non plus d’intégrer mon contenu via des procédés peu pratiques comme c’est encore trop souvent le cas via des iframes. Non, tout ce que j’ai à faire est d’écrire mon contenu sur ma plateforme d’édition et d’accorder les permissions nécessaires aux différentes applications qui vont le consommer.
Quel est l’intérêt ?
Je pense qu’avec les lignes précédentes, l’intérêt devrait vous sauter aux yeux : Pour faire simple, votre contenu peut être distribué vers n’importe quelle application et son affichage ne dépend que de la plateforme sur laquelle il est affiché.
Pour les publicateurs, c’est du temps gagné : Une plateforme de publication unique, pas de « tweak » ni de pris de tête avec des considérations techniques. L’écriture du contenu sera la seule considération.
Pour les développeurs aussi c’est du temps de gagné, car les données avec lesquels ils devront interagir seront toujours de même format : du JSON.
Les avantages en termes de créativité sont conséquents qui plus est, car le choix des technologies de développement ne sera plus un frein lié au canvas d’édition, comme ça peut être le cas avec des CMS Couplés type WordPress ou Liferay pour ne parler que d’eux. En tant que développeur, on peut être tenté d’utiliser une technologie qui n’est pas adaptée dans le but de gagner du temps, parce qu’on connait bien la dite technologie. Imaginons qu’on souhaite créer une application qui délivre du contenu, le souci étant qu’il faut permettre à notre client de pouvoir éditer son contenu avec un outil qui gère bien cette problématique. On peut être tenté d’utiliser une CMS Couplé, puisqu’ils gèrent normalement très bien la gestion de contenus (en même temps c’est pour ça qu’ils sont conçus). Les problèmes de cette solution sont nombreux :
Pour commencer, ces CMS viennent souvent avec un arsenal de fonctionnalités dont on n’a pas besoin. Ils viennent également avec des background techniques qui peuvent être assez lourd. C’est le cas de Liferay par exemple, qui est un puissant outil de gestion de contenu, mais c’est aussi, et avant tout un outil de création de portails qui pèse à lui seul plusieurs centaines de Mo. D’autre part chaque CMS Couplé est tributaire d’un environnement d’exécution : ça peut être Php / Apache, Java etc, qui nécessitent des serveurs qu’il faudra configurer et administrer. Ce sont des coûts supplémentaires non négligeables. Enfin, disons le simplement, c’est souvent « overkill », ou dit plus simplement, ça revient à tuer des mouches avec un fusil.
Alors attention, je ne dis pas que les CMS Headless n’impliquent plus de développement et qu’ils ne nécessitent pas d’environnement d’exécution, ce serait faux. Mais si l’on envisage uniquement les CMS Headless As A Service, la facture finale ne concernera au mieux que la partie frontale de nos applications, et au pire quelques middlewares supplémentaires.
L’intérêt des CMS Headless est donc conséquent, tant pour l’éditeur qui n’aura plus à se soucier des aspects techniques, comme c’est encore malheureusement le cas avec beaucoup de CMS populaires, mais aussi pour les développeurs qui peuvent travailler rapidement, grâce à l’utilisation de langages simples comme json, et de conventions de communication standardisées comme REST. Et si l’on est tout à fait ouvert à l’idée de CaaS (Content As A Service) et que l’on est prêt à embrasser ce que nous offre le cloud computing, les coûts de production seront drastiquement réduits pour les clients et les développeurs.
Quels service choisir ?
Bon, c’est bien beau, mais alors quels CMS Headless méritent qu’on s’y arrête ? Vaste question à laquelle une réponse nuancée est de mise. Déjà il faut savoir si l’on souhaite une solution auto-hébergée ou une solution As A Service. En ce qui me concerne je n’ai pour le moment utilisé que des solutions Cloud. Le but ici n’est pas non plus de faire un comparatif des offres qui existent sur le marché, d’autres articles en parlent bien mieux que je ne le ferais. Mais les deux solutions qui me semblent aujourd’hui viables, avec chacune une offre gratuite sont Contentful, DatoCms et Prismicio. J’ai une préférence pour Prismicio : Support en français, équipe réactive, et l’interface est vraiment sympa à utiliser. Seul « bémol » à l’heure actuelle, il n’est pas possible d’éditer du contenu en dehors de leur application web. Mais l’équipe y travaille actuellement d’après ce que j’ai appris de mes échanges avec eux.
Et les CMS Couplés dans tout ça ?
Mais du coup, est-ce que les CMS Headless signent l’arrêt de mort des CMS Couplés ? Là aussi une réponse nuancée est de rigueur. D’abord parce que certains acteurs du secteur sont en train de faire bouger les lignes : WordPress en tête, qui a amorcé un virage significatif ces trois dernières années en proposant de manière désormais standard, une api Rest. Drupal lui emboite le pas. La transition est donc marche. Quant à dire si les CMS tels que nous les connaissons vont mourir, j’ai tendance à penser que oui. Je pense aussi que les dinosaures qui n’auront pas su évoluer vers les contenus distribués disparaitront aussi. Quant à savoir quand tout cela se produira, je dirais qu’au vu de la vitesse à laquelle les choses ont évolué ces cinq dernières années, cela va arriver vite. Très vite même.
Conclusion
En ce qui me concerne, je continue d’utiliser les CMS Couplés, car à ce jour, ils bénéficient d’écosystèmes riches en termes fonctionnalités notamment. Ils permettent donc de travailler rapidement sans être forcé de réinventer la roue. Mais je me tourne de plus en plus vers du développement Javascript pure, car le langage propose aujourd’hui à peu près tout ce dont on a besoin pour développer des applications robustes et aux fonctionnalités riches. NodeJS et les framworks Javascripts comme Angular, VusJS et React sont en train de parachever cette transition, et c’est un plaisir de travailler avec ces technologies. Je vous invite par ailleurs à jeter un oeil à mon site personnel que je viens de mettre en ligne et qui embrasse cette philosophie de Headless CMS : http://francklebas.fr
Si vous souhaitez aller plus loin, je vous recommande les articles suivants :
https://pantheon.io/decoupled-cms
Gestion de contenu : faut-il passer au headless CMS et au Content as a service ?
