Headless CMS - decoupled CMS - idées théoriques
Bien que souvent confondues, les notions de CMS headless et de CMS découplé sont distinctes. Cet article présente les principales caractéristiques de ce type d'architecture de manière théorique, c'est à dire indépendamment des outils réels existants sur le marché.
Dans un CMS classique comme Drupal, le backend (qui permet de composer les pages) et le frontend (qui affiche ces pages) sont inséparables.
Un CMS headless ne fournit que le backend et une API qui permet d'exposer le contenu saisi. La partie frontend (head) est absente.
Un CMS découplé est un CMS headless auquel est associé un frontend par défaut qui utilise l'API pour récupérer les contenus et les mettre en forme.
Sources :
- https://www.coredna.com/blogs/headless-vs-decoupled-cms
- https://www.contentful.com/blog/2019/02/04/difference-between-headless-decoupled-contentful/
Dans un CMS classique comme Drupal, le backend (qui permet de composer les pages) et le frontend (qui affiche ces pages) sont inséparables.
Un CMS headless ne fournit que le backend et une API qui permet d'exposer le contenu saisi. La partie frontend (head) est absente.
Un CMS découplé est un CMS headless auquel est associé un frontend par défaut qui utilise l'API pour récupérer les contenus et les mettre en forme.
Sources :
- https://www.coredna.com/blogs/headless-vs-decoupled-cms
- https://www.contentful.com/blog/2019/02/04/difference-between-headless-decoupled-contentful/
Les avantage d'un CMS headless sont :
1. On n'est pas prisonnier de la technologie propriétaire du fournisseur du CMS, technologie potentiellement complexe à acquérir et à maintenir. On peut choisir un frontal qui utilise des technologies que l'on connaît et pour lesquelles on est performant. Exemple de technos : JS frameworks (React, Vue, ...).
2. On peut changer de technologies front au cours du temps, ce qui évite d'être obligé de faire nécessairement appel à un connaisseur d'une technologie particulière, ressource qui pourrait potentiellement être rare sur le marché.
3. On peut brancher un peut ce que l'on veut comme front (par exemple un source de données pour un application sur smartwatch ou encore un générateur de page statiques (Gatsby, Jeckyll, ...). On peut ainsi, plus facilement qu'avec un CMS classique proposer une information multi-support.
4. On peut mixer les technologies de front sur un même site. Ce qui permet de prendre en compte des situations particulières en matière de sécurité, de temps de réponse, d'interactivité ou de tenue à la charge par exemple.
5. L'utilisation d'une API permet de régler finement les échanges entre le front et le back, et contrôler ce qui remonte du front vers le back.
6. Le front n'emporte pas des outils nécessaires au back, ce qui offre une surface d'exposition aux attaques moindre.
7. Il n'est pas nécessaire de changer le back-office pour moderniser le front. Cela demande moins de travail lors d'un tel changement et limite la formation à dispenser aux contributeurs.
Les inconvénients d'un CMS headless sont :
1. On obtient pas directement un résultat montrable, ce qui rend difficile de susciter l'adhésion lors de refontes.
2. Le front est à construire, ce qui nécessite du travail de développeurs (denrée rare et chère).
3. Le front et le back peuvent être dans des technologies très différentes, ce qui rend la maîtrise technique de l'ensemble plus complexe.
4. Pas d'outil de prévisualisation dans le back-office.
5. La structure du front et l'organisation du back peuvent être très différentes, ce qui peut dérouter le contributeur (NB : ce problème peut aussi exister dans les CMS classiques dans lesquels une information peut être reprise en différents endroits du site web, voire faire l'objet d'alertes ou de newlettters).
Les avantages d'un CMS découplé sont :
1. Les même avantages qu'un CMS headless (mais si on utilise le CMS découplé comme un CMS headless, on a aussi certains inconvénients de celui-ci).
2. L'existence de modèles et d'outils sur lesquels on peut immédiatement d'appuyer pour fabriquer le site (comme dans le cas d'un CMS classique).
3. Sans aucun développement, on peut voir le fonctionnement du site (avec une charte non adaptée, comme dans le cas des CMS clqssiques)
4. Possibilité d'avoir une prévisualisation WYSIWYG comme dans les CMS classiques.
5. Dans la mesure où il existe une méthode standard de publication front, les développeurs peuvent se concentrer sur les parties front spécifiques et garder le mode de publication standard pour les autres.
Commentaires
Afficher les commentaires en Vue non groupée | Vue groupée