Le Headless : une approche moderne du web

Quelques avantages du Headless

L’approche Headless présente un certain nombre d’avantages. Il serait évidemment illusoire de vouloir les lister tous d’autant que certains dépendent du contexte projet.

Voici, selon nous et notre expérience, les avantages principaux de l’approche Headless.

Flexibilité

Si l’on ne devait retenir qu’un seul avantage, ce serait celui-ci. Le Headless offre la liberté aux développeurs de choisir les technologies front-end les mieux adaptées à leurs besoins. Que ce soit React, Vue.js, Angular, ou simplement un développement spécifique, tout devient possible.

Retenez simplement que le front-end ne dépend absolument pas des technologies employées par le back-end. Seule la façon de communiquer entre les deux mondes doit être commune et le front-end a simplement besoin de savoir comment parler avec le back-end (REST, WebServices, etc.) et comment exploiter l’API mise à disposition (routes et terminaisons de l’API).

Cette façon de séparer strictement les deux mondes, front-end et back-end, vous permet donc de proposer des expériences adaptées à vos utilisateurs et de les répartir potentiellement sur plusieurs sites différents mais qui exploiteront au final qu’une seule et unique source de données. Cette façon de faire permet aussi de faciliter les refontes de plateformes puisque l’on peut réécrire un nouveau front-end avec une charte graphique et des technologies totalement différentes sans jamais avoir à modifier le back-end.

Omnicanalité

Ce point est le corrollaire direct du point précédent. Utiliser une API comme source unique de données signifie qu’une seule source de contenu peut alimenter plusieurs plateformes distinctes (site web, application mobile, etc.). Cette approche simplifie drastiquement la gestion du contenu et assure surtout une cohérence totale sur l’ensemble de vos canaux.

Évolutivité

L’évolutivité est la dérivée seconde des deux précédents points ; les entreprises peuvent faire évoluer leur architecture sans avoir à remettre en question l’intégralité de leur système. Cette architecture permet d’intégrer plus facilement de nouvelles fonctionnalités, voire de nouveaux services sans pour autant perturber l’existant, garantissant donc une continuité de l’expérience utilisateur ainsi que, nous l’oublions trop souvent, la sérénité des équipes techniques en charge de la maintenance et de la surveillance du système.

Sécurité

Rappelons-le, la sécurité des systèmes informatiques est un enjeu majeur de notre époque. Le front-end et le back-end étant bien distincts et indépendants, il devient plus difficile pour les attaquants d’exploiter les failles comme ils ont l’habitude pour un CMS traditionnel. En isolant au maximum le back-end et en ajoutant des règles de sécurité très strictes côté front-end, la sécurité augmente ainsi d’un cran. Par exemple : les API peuvent être sécurisées par leurs routes indépendamment du système de gestion de contenu, que l’on ne peut ouvrir qu’à certaines adresses IP, nous permettant de le rendre plus facilement invisible aux attaquants potentiels.

Performance

Le Headless permet souvent d’optimiser les performances dans une certaine mesure en utilisant des solutions front-end légères et modernes, réduisant ainsi les temps de chargement et améliorant l’expérience utilisateur. Comme le back-end est découplé du front-end, il est possible de faire fonctionner le back-end sur une infrastructure dédiée et les front-ends sur plusieurs instances elles aussi dédiées, favorisant et simplifiant ainsi la mise à l’échelle horizontale (augmentation du nombre de serveurs) ou verticale (augmentation des ressources dédiées aux serveurs).

Quelques inconvénients du Headless

Comme toute solution technique, l’approche Headless apporte son lot d’inconvénients.

Voici, selon nous et notre expérience, les inconvénients principaux de l’approche Headless.

Complexité

Contrairement aux CMS traditionnels monolithiques, qui offrent des solutions tout-en-un, un projet Headless nécessite une architecture sur mesure. Il faut bien réfléchir en amont comment structurer ses données, comment les exposer, configurer des API, choisir un framework front-end et développer spécifiquement cette partie et enfin assurer la communication entre les différents éléments.

Coût

La mise en place d’une architecture Headless demande des compétences techniques plus avancées qu’un CMS monolithique traditionnel. Il ne s’agit plus seulement d’installer un système plus ou moins générique sur étagère, de configurer un thème et c’est terminé. Ce type de solution étant plus exigeant, cela peut entraîner des coûts supplémentaires en développement, en maintenance et en hébergement.

Absence de prévisualisation native

Dans un CMS traditionnel, les éditeurs de contenu peuvent le plus souvent voir en temps réel à quoi ressemblera leur publication. Avec un CMS Headless, cette fonctionnalité est plus difficile à mettre en œuvre du fait de la stricte séparation entre le front-end et le back-end, et nécessite en général des outils, des modules complémentaires, voire des développements spécifiques afin de pouvoir prévisualiser le résultat final comme vous l’attendriez.

Gestion des permissions et des accès

Les contenus étant exposés par des API, ces dernières nécessitent d’être sécurisées correctement afin d’éviter toute fuite d’informations ou exploitation malveillante ou non autorisée de vos contenus. La gestion des droits et des rôles utilisateurs devient donc un peu plus complexe qu’avec un CMS traditionnel du fait de cette stricte séparation entre le front-end et le back-end.

Quelques solutions Headless

Point n’est question ici de dresser une liste exhaustive de solutions Headless, mais voici quelques solutions qui pourraient vous intéresser.

Strapi

Probablement le CMS Headless le plus en vogue du moment. Strapi est le CMS Headless par excellence. C’est un projet open-source, basé sur Node·JS et écrit en JavaScript et TypeScript.

Conçu pour être orienté « API first », il offre la possibilité de créer, gérer et diffuser le contenu à l’aide d’API REST ou GraphQL. Il propose évidemment la gestion du contenu, la sécurisation des accès, la possibilité de personnaliser tout type de contenu et surtout dispose d’une communauté importante et très active.

WordPress et Drupal

Cela pourrait peut-être vous surprendre, mais les solutions open-sources légendaires et historiquement monolithiques WordPress et Drupal offrent désormais la possibilité de se comporter comme un CMS Headless.

Cela comporte de nombreux avantages tels que des ressources abondement disponibles, des communautés très importantes et très actives, des interfaces de gestion déjà bien connues et maîtrisées par les développeurs.

Le risque serait cependant d’avoir la tentation de créer un système hybride entre le monolithique et le Headless et donc de perdre des avantages sur les deux tableaux en obtenant une solution difficilement maintenable.

Un choix à bien étudier pour votre projet mais qui pourrait s’avérer être un choix gagnant !

D’ailleurs, le saviez-vous ? L’article que vous êtes en train de lire est délivré par une solution que nous avons conçue sur un Drupal configuré en mode Headless et un front en Next·JS avec rendu côté serveur afin de privilégier le SEO.

Solutions propriétaires

Il existe de nombreux CMS Headless propriétaires, disponibles le plus souvent en mode SaaS.

Voici quelques références :

• ButterCMS
• Contentful
• Prismic
• Storyblok

Ces solutions proposent certains avantages, tel que des modules pour se connecter à des CRM, des ERP, des PIM, des plateformes e-commerce, … et proposent le plus souvent un hébergement en mode SaaS (mais qui peut s’avérer extrêmement coûteux si vous n’y prenez pas garde).

Ces solutions peuvent être envisagées et peuvent dans certains cas être des accélérateurs. Par contre, étant propriétaires, elles peuvent vous transformer en utilisateurs captifs et rendre les migrations vers d’autres solutions extrêmement compliquées, voire très coûteuses.

Comment choisir ?

C’est là que le bât blesse, il n’existe pas de règles absolues, car tout peut dépendre de vos enjeux fonctionnels, business, techniques, et j’en passe.

Cependant, voici quelques règles simples et une méthode qui peut vous permettre d’évaluer un choix rapidement :

• Vous souhaitez réaliser un site web ou un blog, sans besoin particulier de partager les contenus et ressources vers d’autres systèmes différents, alors un CMS traditionnel semble adapté à votre besoin.
• Vous souhaitez réaliser un site web, avec éventuellement un blog, peut-être plusieurs versions du site en fonction des utilisateurs, pays ou langues, des mini-sites ou pages événementielles, mais tout en partageant les même contenus pour éviter de les dupliquer, alors l’approche Headless est très probablement plus adaptée à votre besoin.

Dans tous les cas, gardez en tête que tout se joue dans l’épaisseur du trait, car il est nécessaire d’anticiper les besoins et la complexité technique, les coûts associés, etc.

Conclusion

L’approche Headless offre de nombreux avantages, les plus évidents étant la flexibilité, et l’expérience omnicanale. En revanche elle nécessite une expertise et des ressources techniques plus importantes et peut donc s’avérer plus coûteuse à mettre en place et à maintenir. Tout cela doit donc être mis en regard du ROI attendu lors de l’étude de votre projet.

Le choix d’adopter une architecture Headless doit être basé sur des besoins spécifiques au projet ainsi que sur les compétences disponibles. Si vous cherchez une solution évolutive et adaptable à différents supports, le Headless peut être une option extrêmement pertinente. En revanche, pour des besoins plus simples, un CMS traditionnel peut s’avérer amplement suffisant.

En bref, il n’y a pas de « silver bullet» ; votre choix doit être dirigé par une étude solide et objective concernant vos besoins et les enjeux de votre projet, et surtout ne jamais reposer sur des critères subjectifs tels que la mode du moment par exemple, plus connue sous le nom de « Hype Driven Developement ».