Un guide pour les leaders du digital
Headless CMS dans l'entreprise
Qu'est-ce qu'un CMS headless ?
Le terme "headless" est accrocheur, mais qu'est-ce que cela signifie vraiment ? La partie avant est-elle censée représenter la tête et la partie arrière le reste du corps ? C'est certainement très visuel.
Pour être plus précis, un CMS headless est un système de gestion de contenu (CMS) qui ne se concentre pas sur la fourniture de contenu par le biais de pages, mais uniquement sur le travail en amont : fournir aux créateurs de contenu les outils pour amener leurs flux de travail à un point où le contenu est prêt à être consommé dans un cas d'utilisation de type "Content as a Service" (contenu en tant que service). Il s'agit en fait d'un CMS classique amputé de sa couche de diffusion Web : pas de système de templates, pas de diffusion HTML et pas de gestion de la structure et du style du site. Un CMS headless se concentre naturellement sur l'assistance aux utilisateurs pour les tâches suivantes :
- Modélisation du contenu
- Création et rédaction du contenu
- Faciliter le flux de travail et la collaboration autour du contenu (y compris les traductions)
- Organiser le contenu dans le référentiel (sémantique, collections, taxonomies)
Et délibérément, le contenu en tant que service ne touche pas à la manière dont le contenu sera livré ou présenté aux utilisateurs finaux sur le front-end.
Introduction
La gestion de contenu headless est une tendance qui existe depuis un bon moment. Déjà très répandue dans les petites entreprises et les sites de campagne, elle continue de gagner du terrain dans les projets d'entreprise.
Mais avant de vous lancer tête baissée dans un projet de CMS headless, vous devez réfléchir à la manière dont il répond aux besoins de votre organisation. Comme beaucoup de jargon informatique, le terme "Headless CMS" n'est pas très clair. Avant de commencer, il est bon d'avoir une vue d'ensemble de certains des concepts utilisés
ci-dessous :
• API de contenu : Un outil utilisé par les éditeurs pour gérer le contenu qui fournit un flux de contenu brut à consommer par d'autres outils de développement - et non par les utilisateurs directement.
• Couche d'affichage : Un système (ou des systèmes) qui rend le flux fourni par une API de contenu à afficher aux utilisateurs. Un site web ou une application mobile par exemple.
Pour ces deux composants, il existe un certain nombre d'options sur le marché. Pour en savoir plus sur les différentes options d'API de contenu, consultez notre notre eBook : A Business User's Guide to Content as a Service (Guide de l'utilisateur professionnel pour le contenu en tant que service).
Pour les couches d'affichage consommant du contenu fourni par l'API, le paysage est encore plus diversifié et vous pouvez opter pour un frontal personnalisé.
Le bloc ci-dessous présente quelques technologies populaires utilisées pour les interfaces web des Headless CMS.
La combinaison d'une API de contenu et d'une couche d'affichage aboutit à la mise en œuvre d'un Headless CMS. Cela diffère d'un CMS traditionnel typique où l'API de contenu et l'affichage ont été davantage couplés pour former un système unique.
Les deux approches ont leurs avantages et leurs inconvénients, dont certains seront abordés ici. Nous abordons ici les considérations à prendre en compte avant de lancer un projet Headless CMS dans une entreprise.
Technologies utilisées pour construire un front-end (couche d'affichage) pour un Headless CMS :
Générateurs de sites statiques :
Ils génèrent un ensemble de fichiers HTML à l'aide d'un processus de publication. Grande évolutivité à faible coût. Très sûr, mais peut être limité pour les fonctions dynamiques ou lorsque des autorisations au niveau de l'utilisateur doivent être appliquées pour l'accès au contenu.
Produits populaires : Gatsby.js, Hugo, Jekyll
Cadres JavaScript côté serveur :
Cadre web fonctionnant sur un serveur. Récupère le contenu de manière dynamique à partir de l'API de contenu. Grande flexibilité pour les intégrations, les permissions, etc. Nécessite un environnement d'hébergement et une maintenance active.
Produits populaires : Express, Next.js, Koa
Fonction en tant que service (FaaS) :
Un cadre simplifié entièrement géré. Les prix et les performances évoluent en fonction de l'utilisation. Le paysage de l'utilisation frontale des CMS headless est immature et nécessite un certain investissement dans le développement personnalisé. Une situation de verrouillage du fournisseur est également à prendre en compte.
Produits populaires : Azure Functions, AWS Lambda, Google Cloud, Open FaaS
Des applications efficientes aux API efficientes
Aujourd'hui, le secteur de la gestion de contenu est arrivé à maturité, ce qui signifie qu'il existe un grand nombre d'expériences et de bonnes pratiques accumulées. Cela fait des projets de mise en œuvre de CMS un travail de routine relativement banal dans le monde de l'informatique.
Les défis se situent au niveau de la logique commerciale, alors que la technologie elle-même peut ne pas sembler très excitante pour les technologues. Surfant sur la vague de l'économie des API, les outils de gestion de contenu headless remettent en question le statu quo en proposant une autre approche de la fourniture de contenu.
Les API (interfaces de programmation d'applications) existent depuis le début de l'informatique. Dans le passé, la plupart des API étaient des API internes utilisées pour développer des logiciels à proximité : Les applications fonctionnant sous Microsoft Windows utilisent ses API pour interagir avec le matériel.
L'engouement récent pour les API concerne principalement les API distribuées utilisant les technologies web. Le CMS headless est une manifestation de cette tendance pour la gestion de contenu.
Mais tout comme une API dans un système d'exploitation de bureau, une API web n'est en soi qu'un outil. La valeur réside dans les caractéristiques et les fonctionnalités qui peuvent être créées à l'aide de leurs capacités. Les API Windows ont permis aux développeurs de créer des "killer apps" qui ont permis à Microsoft de dominer l'informatique pendant plus de vingt ans.
Avec l'arrivée du web et des smartphones, le système d'exploitation de bureau a perdu sa position dominante. L'entreprise a dû adopter et abandonner sa dépendance à l'égard de Windows pour rester pertinente et faire partie du nouveau monde en introduisant les services en nuage et la tarification par abonnement pour sa suite de productivité Office.
Mais les choses sont rarement noires ou blanches. Si l'informatique de bureau n'est certainement pas un secteur en croissance, il existe des domaines dans lesquels elle reste la meilleure option, qu'il s'agisse de domaines nécessitant une précision en temps réel, comme la création musicale, ou de tâches banales, comme la rédaction d'articles de blog ou de travaux de productivité aléatoires. La possession d'ordinateurs personnels a atteint un point d'inflexion et est en déclin, mais la grande majorité des employés de bureau continuent de manier un ordinateur de bureau ou un ordinateur portable tous les jours.
Cette histoire est une analogie avec l'espace de gestion de contenu. Il est facile pour les fournisseurs de CMS bien établis de souligner les capacités manquantes des systèmes headless, tandis que les équipes marketing des fournisseurs de CaaS s'efforcent de produire du contenu soulignant les déficiences des "anciens produits CMS". En réalité, il y a de la place pour les deux approches. Il s'agit d'un domaine diversifié avec des exigences et des cas d'utilisation différents.
Chez Ibexa, nous ne voyons pas la nécessité d'une telle juxtaposition. L'infrastructure de notre produit nous permet de construire nos API internes et de les exposer par le biais d'API web telles que REST ou GraphQL. Vous pouvez utiliser Ibexa DXP php headless CMS, full stack ou quelque chose entre les deux. Le choix vous appartient.
Besoins des utilisateurs et fonctionnalités des produits
Une plateforme CMS headless est principalement utilisée pour la gestion du contenu.
Aujourd'hui, le terme CMS (Content Management System) est utilisé pour décrire un système dont la fonction va bien au-delà de la création, de la modification et de l'édition de contenu.
Ces systèmes ont dépassé leur champ d'application initial et nombre d'entre eux sont désormais en passe de passer d'un CMS à une DXP (Digital Experience Platform). Ce sujet a été traité en profondeur dans un billet de blog intitulé From CMS to DXP to Deliver Digital Success.
Un CMS headless est plus fidèle à sa définition. Il s'agit d'un système principalement utilisé pour GÉRER LE CONTENU. Un point c'est tout. Cela le rend plus accessible aux utilisateurs, mais aussi moins performant qu'un CMS d'entreprise traditionnel.
Cette ambivalence des fonctions d'un CMS peut créer des surprises au cours du processus de mise en œuvre. Il se peut que vous considériez comme acquises certaines fonctionnalités qui sont (et ont toujours été) hors de portée d'un système de gestion de contenu.
Lorsque vous remplacez un CMS traditionnel ou un DXP existant par une solution headless CMS, il est important d'identifier les tâches que vos rédacteurs de contenu, votre équipe de marketing et les autres utilisateurs effectuent quotidiennement.
Identifiez les écarts entre les deux solutions en ce qui concerne les fonctionnalités clés. Outre les besoins en matière de gestion de contenu, tels que les modèles de contenu riche et les flux de travail, veillez à cartographier les fonctionnalités pour les tâches périphériques de gestion du site, telles que :
- Gestion de la navigation, des redirections et d'autres tâches similaires
- Ajout de scripts de suivi pour le marketing, le suivi de la convivialité, etc.
- Gestion des utilisateurs avec le backend de votre entreprise
- Programmation des promotions pour les week-ends
- Modification de la structure des pages d'atterrissage
- Prévisualisation du contenu et d'une collection d'éléments de contenu.
éléments de contenu.
Tout cela peut être réalisé avec un système intégré ou une combinaison d'une API de contenu et d'une couche d'affichage. La différence est que pour cette dernière, vous devrez peut-être ajouter des outils tiers et des intégrations supplémentaires.
Ne considérez pas les caractéristiques du produit comme acquises lorsque vous passez d'une suite logicielle intégrée à une architecture microservices construite à partir de composants individuels hautement spécialisés.
Les entreprises abandonnent les applications d'entreprise monolithiques au profit de suites de services faiblement couplés afin d'adapter leur technologie à leurs besoins précis en matière de gestion de contenu et de répondre rapidement aux nouvelles exigences.
Complexité et robustesse de la mise en œuvre
Une combinaison de compétences et de technologies adéquates est nécessaire
En raison de leur maturité, les mises en œuvre traditionnelles de CMS dans le cadre de grands projets sont plus faciles (mais pas faciles !) à estimer qu'un projet de mise en œuvre headless d'une portée similaire. Ce n'est pas parce que la technologie est meilleure ou pire, mais parce qu'il y a des méthodes de travail plus établies, des attentes concernant ce que fait un système et qui fait quoi. On peut s'appuyer sur l'expérience passée plutôt que sur des suppositions pour obtenir des estimations réalistes.
Aujourd'hui, ce n'est pas souvent le cas pour les mises en œuvre complexes headless. Le client réalise souvent ce type d'implémentation pour la toute première fois et le partenaire d'intégration n'a peut-être pas l'expérience suffisante.
Cela peut entraîner des problèmes et des coûts inattendus pendant et après le projet, même si vous avez fait preuve de diligence raisonnable en ce qui concerne les caractéristiques décrites. Bien gérés, ces problèmes ne se posent pas.
L'une des principales caractéristiques d'un projet de CMS est qu'il s'agit très probablement d'un projet multifournisseur faisant appel à plusieurs technologies. Si certains fournisseurs de CMS réalisent eux-mêmes des projets de mise en œuvre, il est assez rare qu'un fournisseur de CaaS (Content as a Service) fournisse des services de mise en œuvre.
Cela n'est tout simplement pas compatible avec le modèle commercial d'un fournisseur d'API. Comme pour tout projet technologique, vous devez examiner l'expérience et les références d'un partenaire de mise en œuvre en matière d'utilisation de l'API.
l'expérience et les références d'un partenaire de mise en œuvre en matière d'utilisation de l'API de contenu de votre choix. Vous ne voulez pas être leur premier essai.
L'architecture d'intégration est un autre point à prendre en considération. Les systèmes de gestion de contenu sont traditionnellement des systèmes côté serveur, et il est naturel que les connexions aux systèmes externes soient construites sur le serveur.
Une tendance émergente consiste à déplacer les intégrations vers le client - le navigateur. Cette tendance n'est pas directement liée à l'utilisation ou non d'une plateforme CMS headless, mais les deux coïncident souvent dans les mêmes projets parce qu'il s'agit de nouvelles technologies.
JAMStack est un nom donné à l'approche architecturale technique dans laquelle le navigateur devient la plateforme d'intégration. Le terme vient de JavaScript, APIs and Markup (JAM). L'idée de base est de rechercher les meilleurs fournisseurs d'API pour l'authentification, le commerce électronique, les paiements, etc. et de les intégrer dans le navigateur, ce qui permet de s'affranchir de l'exécution de systèmes côté serveur.
Au mieux, une implémentation JAMStack vous offre la flexibilité de choisir la meilleure technologie à faible coût, au pire, c'est un fouillis fragile de services qui peut prendre beaucoup de temps à résoudre en cas de problème. En réalité, l'expérience moyenne se situe probablement quelque part entre les deux.
Coûts du projet et de la maintenance à long terme
Tenir compte du coût total de possession et prévoir un budget pour la croissance
Le coût de la mise en œuvre d'un CMS headless se résume au coût de l'API de contenu et du ou des consommateurs d'API. Le coût total s'accumule au cours de la phase de développement initiale et au fil des années de développement et de maintenance.
Le coût de l'API de contenu est plus facile à déterminer, car vous devrez examiner les options disponibles sur le marché et choisir celle qui vous offre la capacité et les fonctionnalités requises au prix le plus compétitif. Un jeu de chiffres, de plus et de moins.
Lorsque vous choisissez une API de contenu, veillez à prendre en compte au moins les points suivants :
- Capacité requise (nombre d'éléments de contenu, de référentiels, d'éditeurs...)
- Fonctionnalités disponibles ou développement personnalisé
- Coût d'hébergement (pour les fournisseurs de CMS)
- Coût de l'abonnement (pour CaaS)
Il s'agit ici de trouver la solution la plus équilibrée pour répondre à vos besoins individuels.
La tarification d'un fournisseur CaaS peut être très attrayante pour un faible volume, mais peut monter en flèche à l'échelle dont votre organisation a besoin. L'absence de frais de licence d'un système open source peut être compensée par un coût d'hébergement plus élevé. Veillez à calculer les dépenses futures si vous souhaitez vous développer.
Un PaaS comme Ibexa Cloud, en revanche, pourrait offrir un avantage de coût par rapport aux fournisseurs IaaS en réduisant les coûts de personnel pour gérer votre propre équipe DevOps interne.
Une fois le fournisseur d'API de contenu choisi, il est temps de se pencher sur la couche d'affichage. Il s'agit d'un domaine où les options disponibles sont littéralement illimitées.
Il existe des solutions sur mesure pour les boutiques, des implémentations basées sur des produits, des frameworks tels que Next.js ou Nuxt.js et des générateurs de sites statiques tels que Gatsby.js ou Hugo. Pratiquement tous ces outils sont open source, et le coût est donc basé sur la main d'œuvre. Là encore, il convient de rechercher l'expérience lors de la sélection d'un partenaire de mise en œuvre, car elle permet d'obtenir une meilleure qualité et une plus grande rapidité de développement.
En ce qui concerne les coûts à long terme, les choses peuvent devenir délicates. Les coûts de l'API de contenu sont susceptibles de changer - en général, les prix sont assez stables - mais techniquement, un fournisseur de CaaS pourrait augmenter ses prix du jour au lendemain en fonction des conditions d'abonnement que vous avez convenues.
Toutefois, cela est peu probable car il existe de nombreuses alternatives et il est relativement facile de passer d'un fournisseur à l'autre. Vous devrez retravailler votre implémentation, mais une couche d'affichage de contenu bien architecturée, "la tête", peut s'adapter à cette évolution sans introduire de coûts prohibitifs.
Un architecte en perpétuel changement
Profiter des avantages d'un environnement microservices
Dans une solution CMS headless, la couche d'affichage (API Consumer) devient un choix stratégique. Lors du déploiement d'un CMS traditionnel, les modèles et l'implémentation frontale sont souvent jetables.
Dans les entreprises où un système de gestion de contenu Web (WCMS) peut rester en service pendant cinq à dix ans après le projet de mise en œuvre initial, la conception subit de multiples mises à jour pour faire table rase du passé. Dans le backoffice, les fonctionnalités continuent de s'accumuler.
Dans une solution de gestion de contenu intégrée de bout en bout, l'API de contenu et la couche d'affichage sont par nature étroitement liées - elles font partie de l'ensemble.
L'une des principales propositions de valeur de l'architecture headless est que les deux sont indépendantes. Mais les investissements dans les fonctionnalités ont naturellement tendance à s'accumuler dans la couche d'affichage, ce qui rend l'objectif initial d'être indépendant pour remplacer l'un ou l'autre des composants sans objet.
Si vous liez étroitement votre implémentation à une couche de conception donnée, vous risquez d'aboutir à une augmentation des coûts. Au fil du temps, votre couche d'affichage accumule une dette technique, qui nécessite à son tour des efforts de développement accrus.
Votre capacité d'évolution est entravée et une réécriture en profondeur peut s'avérer nécessaire. Il est facile de vivre dans l'illusion d'un système découplé simplement en raison de l'architecture de haut niveau que vous avez choisie au départ. Rester agile demande des efforts. Les logiciels sont par nature voués à être obsolètes tôt ou tard, mais il est possible d'architecturer un système de manière à ce que certaines parties soient remplaçables.
La clé pour maintenir la flexibilité d'une implémentation headless est de développer consciemment des fonctionnalités jetables. Divisez les capacités complexes en services réutilisables qui ne sont pas liés à une couche d'affichage donnée. Cela vous permettra de récolter les bénéfices de l'approche découplée, même après des années de développement.
Conclusion
Il est essentiel d'investir dans une DXP modulaire doté de solides capacités de contenu et d'API ouvertes.
Aujourd'hui, il existe plus d'options que jamais pour la mise en œuvre technique d'une solution informatique d'entreprise. L'approche "headless" peut être une bouffée d'air frais pour quelqu'un qui travaille avec un système encombrant dont la durée de vie technique a largement dépassé sa date de péremption, mais ce n'est pas nécessairement toujours la meilleure solution.
L'abondance d'options peut rendre plus difficile le choix de la bonne option, et il peut être facile de choisir quelque chose qui n'est pas la solution idéale. Par exemple, si vous ne faites que de la publication de contenu multicanal et que vous n'avez pas besoin de gérer votre site, la mise en œuvre d'un système de gestion de contenu (headless CMS) est parfaitement adaptée. Ne payez pas pour des fonctionnalités headless CMS dont vous n'avez pas besoin.
Dans le même temps, gardez à l'esprit que la disponibilité d'une nouvelle option ne rend pas les outils existants obsolètes. Si certaines fonctionnalités peuvent devenir véritablement obsolètes, d'autres sont essentielles - une sorte de mal nécessaire - à la mise en œuvre d'un projet de gestion de contenu.
Pour ces besoins, vous pouvez utiliser les fonctionnalités d'offres intégrées telles que les DXP ou opter pour une plateforme CMS headless et intégrer des outils tiers pour combler les lacunes. Dans les grands projets, l'ajout de systèmes, de partenaires et de systèmes s'additionne et peut commencer à réduire les avantages perçus à l'origine.
Au lieu de pouvoir introduire des changements rapidement et à moindre coût, vous pourriez consacrer ce même temps et ces mêmes ressources à la coordination de plusieurs fournisseurs de systèmes et au paiement d'honoraires à des prestataires de services fragmentés. Cela est particulièrement vrai si l'on considère le coût total de possession d'une solution sur sa durée de vie.
N'oubliez pas qu'aucune technologie ne garantit le succès. C'est l'équipe et sa collaboration qui font ou défont la mise en œuvre du projet. Cela vaut pour les petits comme pour les grands projets, mais les chances de succès tendent à diminuer à mesure que l'on introduit davantage de personnes et de technologies. Une approche très efficace pour une équipe de cinq personnes peut donner des résultats opposés lorsque l'équipe compte trente personnes.
Si vous souhaitez en savoir plus sur les solutions Headless CMS, ou si vous êtes actuellement au milieu d'un projet d'évaluation, pourquoi ne pas demander une démonstration avec nos experts en expérience numérique ou discuter de vos besoins pour une transformation numérique réussie dans votre organisation ?