Un CMS est un acronyme qui tire son nom de l’anglais « Content Management System », ce qui se traduit comme étant un système de gestion de contenu (S.G.C.).
Plus souvent qu’autrement, un CMS est une application web développée pour la saisie et l’édition des données pertinentes à créer du contenu informatif. Il facilite aussi grandement la vie du webmestre par l’encadrement de ce dernier dans ses opérations quotidiennes. Généralement, les CMS offrent des fonctions de saisi du contenus en mode brouillon (Drafting), la sauvegarde de l’historique des éditions du contenu (Versionning), des mécanismes d'approbation du contenu (Content Authoring), la gestion de permission et des groupes, etc.
Typiquement, un CMS est divisé en deux grandes composantes. La première est la composante de gestion du contenu de l’application (CMA pour « Content Management Application ») et l’autre est celle pour la livraison de contenu de l’application (CDA pour « Content Delivery Application »). Dans un CMS traditionnel, comme WordPress ou Craft CMS, ces deux composantes interagissent étroitement ensemble au sein du même code source.
Dans un modèle de site construit selon la méthode traditionnelle, les données alimentant les gabarits du visuel et proviennent d’ordinaire de la base de données. La composante de gestion du contenu alimente la base de données et la composante de livraison consomme ces données. Traditionnellement, cette dernière permet la création de page par l'utilisation de gabarit qui sont personnalisés à même le code du CMS. C’est précisément là que le développement back-end (données) rejoint le développement front-end (visuel).
Le code développé pour le visuel (front-end) doit suivre et s’adapter à celui qui a été fait pour recevoir les données (back-end). Éventuellement, le code du visuel devra être en très grande partie revu en même temps que la refonte ou que la mise à jour du CMS lorsqu’elle est requise.
De plus, il arrive que les données contenues dans le CMS doivent être fournies de manière brute à des systèmes qui n’ont pas besoin du visuel. Il faut donc être en mesure d’étendre les fonctionnalités du CDA en offrant des données brutes et non pas seulement par des pages générées au moyen de gabarits. Dans ces cas précis, il est possible d'ajouter au CMS des points d’accès (ou « endpoints ») qui permettent d’exposer ces données convoitées.
Imaginons la situation suivante :
Une entreprise dans le domaine de la vente au détail réputée pour l’expérience client qu’elle offre dans ces succursales souhaite aller de l’avant pour offrir une expérience en ligne similaire à celle vécue en magasin. Elle souhaite orienter sa stratégie numérique vers le multicanal et éventuellement pousser l’expérience vers celle de l’omnicanal. Elle souhaite également que les efforts de marketing soient faits sur une seule et même plateforme et que les communications soient envoyées simultanément à tous leurs clients peu importe les modes de communication auxquels ils ont adhéré. Aussi, elle aimerait adapter son marketing en fonction des saisons et ce uniformément sur toutes les plateformes de média sociaux.
Pour éviter que ce projet deviennent trop gros tant du côté de la gestion que du système lui-même, nous conseillons une architecture plus découpée, c'est-à-dire faiblement couplée pour le volet CMS.
Dans un cas comme celui-ci, une architecture qui inclut un Headless CMS contiendra toutes les informations relatives aux contenus du sites web d’entreprise, de sous-sites, d’applications mobiles et de communications de marketing et commercial. Des applications web, des connecteurs ou des API de tiers parties pourront facilement s’y abreuver. La génération des pages pour les sites web ne se fera toutefois pas au niveau du CMS, mais plutôt grâce à une application web front-end développée séparément qui consomme les informations provenant du CMS. Bref, un headless CMS n’est ni plus ni moins qu’une API avec un interface de gestion de contenu qui ne gère pas la livraison du contenu, mais seulement celle des données.
Si jamais l’une des solutions qui s’y connecte doit être mise à jour, revue ou refaite de zéro, le CMS ne sera pas ou très peu impacté. Ça ne sera pas le cas dans le cas de la méthode traditionnelle où la génération de pages est intimement liée à la composante de livraison (CDA). Un Headless CMS bien planifié et bien entretenu pourra facilement survivre à 2, 3 ou même 4 refontes de sites web sans avoir à être refait. D’autant plus, que le fait de conserver le même CMS minimise les problèmes d’importation de données car aucun autre sources de données de contenus ne sera nécessaire d’être créé pour accommoder la couche visuelle.
Dans un cas comme la situation exemplifiée plus tôt, il sera plus profitable à long terme pour l’entreprise d’investir dans un Headless CMS. Certes, un plus grand investissement initial sera à prévoir pour le premier projet qui nécessitera plus d’analyse et de coordination pour le mettre en place. Par contre, il y a de forte chance que la solution de CMS soit plus robuste, flexible, moins dispendieuse à maintenir sur le moyen/long terme, de meilleure qualité.
Bien que l’exemple ci-haut fait mention d’un gros système, il est tout à fait possible de développer un site qui utilise un Headless CMS pour devenir à l’épreuve du temps dès le départ. Le choix d’un CMS qui permet d’être évolutif dans son aspect Headless pourra être enrichi au fil de la croissance de l’entreprise et de l’évolution des technologies.
Pour mener à bien des projets de développement de CMS Headless, il faut que certaines conditions soient réunies :
Même si les projets utilisant un CMS Headless demandent plus de connaissances et d’expertise dans leurs réalisations, il en vaut la peine de peser le pour et le contre. Un Headless CMS pourrait apporter une grande valeur ajoutée à vos solutions et stratégies numériques. Le Headless CMS est un investissement pour assurer un futur agréable et performant.