Obtenez plus de votre propre contenu avec le headless CMS

Sans système de gestion de contenu, le travail des créateurs de contenu serait beaucoup plus compliqué. Au lieu d'entrer di­rec­te­ment dans le code du site Web, le contenu d'un CMS est entré via un backend et affiché par le système dans le frontend. Ceci fonc­tionne très bien tant que vous ne gérez qu'un seul site Web. Toutefois, les éditeurs et les ges­tion­naires de contenu utilisent de plus en plus souvent plusieurs sites et ap­pli­ca­tions si­mul­ta­né­ment. Ceci nécessite également plusieurs CMS, ce qui peut signifier que le contenu doit être transféré ma­nuel­le­ment de l'un à l'autre. Il est également possible d’avoir recours à un headless CMS, ce qui rend les ap­pli­ca­tions possibles dans un grand nombre de médias.

Un headless CMS est à la fois un dé­ve­lop­pe­ment et une li­mi­ta­tion d'un CMS classique. Des com­po­sants intégrés sont extraits du système pour le rendre com­pa­tible avec une grande variété d'édi­tions. Ceci est possible parce que le frontend et le backend ne sont plus liés de manière mo­no­li­thique dans un headless CMS.

Afin de rendre l'uti­li­sa­tion de ces systèmes aussi simple que possible, on utilise une com­bi­nai­son mo­no­li­thique de frontend et backend. Sur l'in­ter­face d'ad­mi­nis­tra­tion de WordPress, par exemple, vous pouvez modifier l'ap­pa­rence du site Web à l'aide du moteur de modèles, même sans con­nais­sance ap­pro­fon­die en design Web. Toutefois, cela signifie également que vous êtes lié aux spé­ci­fi­ca­tions du système lors de la création. Ceci s'ap­plique aussi bien au nombre de sorties qu'à l'uti­li­sa­tion du langage de pro­gram­ma­tion (en WordPress c'est PHP). Pour éviter cette li­mi­ta­tion, vous pouvez passer à un headless CMS.

Une API REST (Re­pre­sen­ta­tio­nal State Transfer-Ap­pli­ca­tion Pro­gram­ming Interface) est une interface peu complexe mais très flexible. Une API REST utilise les méthodes de requête HTTP définies telles que PUT, GET, POST et DELETE pour la com­mu­ni­ca­tion. De telles commandes per­met­tent à un client d'accéder, de récupérer ou même de modifier les in­for­ma­tions sur le serveur. REST suit fon­da­men­ta­le­ment le style ar­chi­tec­tu­ral du Web. Les API REST, souvent aussi appelées API RESTful, sont struc­tu­rées selon les critères suivants :

• Les serveurs four­nis­sent des res­sources : une API REST est également dis­po­nible pour les ap­pli­ca­tions externes via un serveur. Par con­sé­quent, l'accès ne fonc­tionne pas seulement lo­ca­le­ment.
• Les adresses iden­ti­fient les éléments : dif­fé­rents types d'ap­pli­ca­tions né­ces­si­tent dif­fé­rents formats de fichiers. Avec REST, toutefois, l'URI/URL ne se réfère pas à une ressource dans un format spé­ci­fique, mais seulement à l'élément lui-même. Le client demande l'élément dans le format désiré via la né­go­cia­tion du contenu.
• Les messages sont ex­pli­cites : chaque message adressé au serveur est autonome et ne fait pas référence à un message précédent.
• Liaison des res­sources grâce à des liens : dans REST, les objets sont reliés entre eux par des hy­per­liens pour faciliter la na­vi­ga­tion.

En adhérant à ces principes d’ar­chi­tec­ture, la com­mu­ni­ca­tion entre le serveur API et les dif­fé­rents clients fonc­tionne sans problème. Par con­sé­quent, l'ar­chi­tec­ture REST est par­fai­te­ment adaptée à une API headless CMS.

La sé­pa­ra­tion décrite ci-dessus a un double sens : du point de vue du dé­ve­lop­pe­ment backend, il y a le désir de dis­tri­buer le contenu plu uni­que­ment par le biais d'une seule sortie. Dans un headless CMS, peu importe sur quelle pla­te­forme le contenu doit être édité. L'API REST ne fournit que les données (sous forme de JSON). Ceux-ci peuvent être lus à partir de n'importe quel frontend, quelles que soient les tech­niques utilisées pour les pro­gram­mer.

Mais il y a aussi des avantages du point de vue du dé­ve­lop­pe­ment du frontend : en tant que con­cep­teur Web, un headless CMS vous permet de vous défaire des exigences de la gestion de contenu. Cela signifie également que le langage de pro­gram­ma­tion n'est plus prédéfini. Ceci permet de cons­truire des ap­pli­ca­tions mobiles sur dif­fé­rentes pla­te­formes. Seules les données brutes doivent être reçues et traitées. Ce système offre enfin beaucoup plus de pos­si­bi­li­tés d'af­fi­chage qu'avec la plupart des CMS clas­siques.

Les requêtes dy­na­miques cons­ti­tuent un autre avantage. Récupérer le contenu d'un site Web nécessite un re­char­ge­ment de la page dans un CMS classique. L'API REST, en revanche, fournit des données dy­na­miques qui peuvent être intégrées dans la structure de la page à tout moment, même sans la ra­frai­chir.

La sé­pa­ra­tion du backend du headless CMS du frontend in­di­vi­duel crée également une situation pratique : comme les tendances dans le Web design sont sujettes à des chan­ge­ments réguliers, il est logique d'adapter de temps en temps le frontend de votre propre site. S'il n'est pas lié à la gestion de la base de données et du contenu, il peut également être édité in­dé­pen­dam­ment. Les éditeurs peuvent continuer à poster, gérer et publier du contenu tout en tra­vail­lant sur un nouveau frontend.

Voici donc un résumé des avantages du headless CMS :

• Nombre illimité de frontends
• Com­pa­tible avec dif­fé­rents langages de pro­gram­ma­tion
• Con­cep­tion du frontend flexible
• Con­ti­nuité grâce au dé­cou­plage
• Données dy­na­miques

Il y a de plus en plus de four­nis­seurs de systèmes de gestion de contenu headless sur le marché. Les fa­bri­cants listés ci-dessous diffèrent prin­ci­pa­le­ment par le fait qu'ils offrent un pack complet avec coûts ou une version open source gratuite. De plus, ils four­nis­sent divers services d'hé­ber­ge­ment.

• Con­tent­ful : l'équipe basée à Berlin travaille sur le principe d'un headless CMS depuis 2011. Ils ont développé leur système, y compris un backend fonc­tion­nel, à partir de zéro, au lieu de convertir un CMS classique existant. Toutefois, l'offre gratuite est re­la­ti­ve­ment limitée.
• Directus : Directus adopte une approche dif­fé­rente. En principe, le système est offert gra­tui­te­ment sous la forme d'un logiciel libre. Pour ceux qui sou­hai­te­raient opter pour une al­ter­na­tive déjà hébergée, il existe plusieurs variantes d’abon­ne­ments.
• Con­tents­tack : Built.io, fabricant de plusieurs solutions nu­mé­riques, offre avec Con­tents­tack un headless CMS payant. Ici aussi, les créateurs de contenu disposent d'un backend facile à utiliser qui peut fournir du contenu pour le Web, les ap­pli­ca­tions mobiles et l'In­ter­net des objets grâce à une API REST. L'offre s'adresse prin­ci­pa­le­ment aux grandes en­tre­prises.
• Cloud CMS : ce four­nis­seur de services offre son headless CMS sous forme de service cloud. Il fonc­tionne en principe comme les autres offres, si ce n’est que la gestion de contenu, la base de données et l'in­ter­face ne fonc­tion­nent pas sur leur propre hôte, mais via le cloud du four­nis­seur. En revanche, seules les offres les plus chères offrent un CMS auto-hébergé.
• eZ Platform : la société eZ Systems propose depuis 1999 un CMS classique avec le produit open source eZ Publish. 16 ans plus tard, l'ancien concept a été abandonné et eZ Platform s'est concentré sur un headless CMS, open source également, puisque le produit est librement dis­po­nible sous la licence GNU GPL. Il existe également des variantes payantes avec une as­sis­tance pro­fes­sion­nelle et d'autres offres de licence.

Afin de décider de la bonne offre headless CMS, il faut d'abord s'in­ter­ro­ger sur les besoins et l'ex­per­tise de chacun. Si vous avez votre propre serveur et que vous pouvez im­plé­men­ter un CMS open source, les versions gratuites d'eZ Systems ou Directus cons­ti­tuent un bon choix. Si vous n'avez pas les con­nais­sances pour l'ins­tal­la­tion et la con­fi­gu­ra­tion du système, vous devriez plutôt prendre une version payante afin de pouvoir bé­né­fi­cier de ses avantages spé­ci­fiques.

Depuis que le headless CMS est de plus en plus souvent discuté, les four­nis­seurs de systèmes de gestion de contenu tra­di­tion­nels se réo­rien­tent à leur tour. Par exemple, WordPress a ajouté l'API REST comme partie in­té­grante de la version 4.7. Dans les versions an­té­rieures, cela ne pouvait être activé que par l'in­ter­mé­diaire d'un plugin. L'ex­ten­sion n'en fait pas pour autant un headless CMS, mais WordPress devient un CMS découplé. Les uti­li­sa­teurs qui ap­pré­cient l'étendue de la solution de contenu, y compris le moteur de modèles, peuvent continuer à tra­vail­ler le programme sans perte de fonc­tion­na­lité. Cependant, quiconque souhaite utiliser le CMS pour gérer le contenu d'une ap­pli­ca­tion, par exemple, bénéficie de l'in­ter­face insérée. Drupal peut également être converti en hybride, car ce CMS open source offre également des services Web RESTful à partir de la version 8, un moyen de sortir du contenu dans d'autres in­ter­faces.

Passer ou non de votre système existant à un headless CMS dépend prin­ci­pa­le­ment de ce que vous planifiez. Si vous voulez seulement présenter votre contenu sur un site Web, comme un blog, rejeter le frontend n'est pas une bonne idée. Un headless CMS offre également des avantages qui vont au-delà de la quantité de média de sortie possible, mais dans certains rares cas, l’effort peut être justifié. L'uti­li­sa­tion d'un CMS découplé n'a pas non plus de valeur ajoutée : pourquoi im­plé­men­ter une interface alors que vous n'uti­li­sez que le frontend intégré du système ?

C'est différent lorsque vous présentez votre contenu sur dif­fé­rentes pla­te­formes. Un headless CMS est par­ti­cu­liè­re­ment adapté lorsque l’on souhaite réaliser de grands projets. Il permet en effet de créer des options sur canaux multiples, des sites Web en PHP, Python ou Ruby, des ap­pli­ca­tions pour iOS ou Android sans aucun problème. Les éditeurs de contenu peuvent gérer leur contenu comme d'ha­bi­tude via l'in­ter­face backend. Avec un headless CMS (et avec l'uti­li­sa­tion correcte d’un CMS découplé), les dé­ve­lop­peurs de frontend pro­fes­sion­nels s'oc­cu­pent désormais de l'af­fi­chage, mais ils peuvent aussi le faire en toute liberté grâce à l'API REST.

Le re­dé­ve­lop­pe­ment des systèmes de gestion de contenu est une simple réaction à l'évo­lu­tion des besoins sur Internet. Les ca­rac­té­ris­tiques par­ti­cu­lières des smart­phones, de l'In­ter­net des objets ou des réalités vir­tuelles né­ces­si­tent en effet de repenser la création et la pu­bli­ca­tion de contenu. Les CMS headless et découplés ne sont que le début de ce mouvement. Par con­sé­quent, même si tra­vail­ler avec un CMS tra­di­tion­nel est encore tout à fait suffisant, il ne faut pas perdre de vue les dé­ve­lop­pe­ments actuels et futurs. Compte-tenu de l'évo­lu­tion rapide de ces dernières années, il se pourrait que les CMS clas­siques ne répondent bientôt plus aux habitudes et aux besoins de nombreux uti­li­sa­teurs, comme c’est déjà le cas des sites Web statiques.