Depuis 2026.Q1, Liferay documente officiellement deux CMS. Le nouveau, appelé Liferay CMS ou CMS headless, gère le contenu comme une donnée structurée et réutilisable. L’historique, désormais nommé Classic CMS, reste optimisé pour la diffusion web et se trouve en mode maintenance depuis cette même version. Depuis 2026.Q3, le nouveau CMS est généralement disponible, sans feature flag à activer.
La trajectoire est explicite : le CMS headless est le système recommandé pour les nouvelles implémentations, afin de bénéficier de la modélisation par objets et de la diffusion multicanale.
Cette évolution dépasse donc largement la refonte de l’interface de contribution. C’est le modèle de contenu lui-même que Liferay a choisi de reconstruire.
Le multicanal existait déjà
Liferay n’a pas découvert le headless avec ce nouveau CMS.
L’éditeur expose ses contenus via des API headless depuis plusieurs versions. Dès la 7.2, il présentait ces capacités comme un moyen d’activer des expériences omnicanales à partir d’une source de données unique, avec des API de livraison destinées aux développeurs front-end. Le partage entre sites existait également : les asset libraries servent de dépôts de contenu connectables à plusieurs sites, et elles restent disponibles aujourd’hui, en parallèle du nouveau CMS.
Une entreprise qui voulait alimenter une application mobile à partir de ses contenus Liferay pouvait donc le faire, et beaucoup l’ont fait.
Ce que coûtait réellement le modèle historique
Le contenu du Classic CMS est structuré. Les structures du module Web Content définissent des champs typés, et ces champs sont accessibles via les API.
Cette structure appartient toutefois au modèle Web Content, et les services transverses de la plateforme doivent explicitement savoir l’interpréter. Le nouveau CMS change ce rapport en reposant directement sur le framework d’objets.
La recherche sémantique en donne la mesure exacte. Elle produit des représentations vectorielles du contenu pour permettre la recherche par intention. Pour un contenu web classique reposant sur une structure personnalisée, seul le titre localisé de l’article alimente cette représentation : les champs personnalisés ne sont pas traités. Pour une structure de contenu personnalisée du nouveau CMS, ce sont le titre localisé et le contenu combiné des champs indexables.
Même structure, même richesse apparente, et un service transverse de la plateforme qui n’en exploite qu’une fraction dans un cas et l’intégralité dans l’autre. La modélisation est équivalente ; c’est le socle sur lequel elle repose qui change ce que la plateforme sait en faire.
Chaque consommateur externe reste donc dépendant de la représentation propre au module qu’il exploite, et chaque service de la plateforme doit savoir l’interpréter pour en tirer parti. Faire évoluer un type de contenu impose alors d’évaluer l’impact sur chacun des canaux qui le consomment.
Le même raisonnement s’applique à l’organisation du travail. Créer un type de contenu suppose d’en définir la structure et les éléments de rendu qui l’accompagnent. Le partage entre sites repose sur un mécanisme d’administration distinct de l’environnement de travail quotidien des contributeurs. Et la gestion des droits reste liée à l’organisation des sites et des dossiers.
Le contenu peut être utilisé ailleurs, mais il n’a pas été conçu, à l’origine, comme une ressource métier autonome.
Le changement porte sur le modèle de contenu
Le nouveau CMS est construit sur le framework d’objets de la plateforme : le contenu y est stocké comme une donnée structurée et réutilisable plutôt que comme une page. Les structures de contenu et de fichier définissent le schéma de données, y compris les champs personnalisés, les références vers d’autres structures et les configurations de workflow.
Le contenu n’est plus modélisé uniquement selon les conventions propres au Web Content : il repose désormais sur le même framework d’objets que les autres données métier de la plateforme. Ce qui vaut pour un objet vaut donc pour un article : exposition par API REST et GraphQL, indexation, workflow, permissions, affichage dans des collections.
Le travail d’intégration côté canal subsiste : une application mobile doit toujours savoir quoi faire des données qu’elle reçoit. Elle travaille en revanche à partir d’un modèle explicite, partagé par l’ensemble des services de la plateforme, plutôt qu’à partir des conventions d’un module particulier.
Rendre un ancien modèle accessible de l’extérieur est une chose, ce que Liferay faisait déjà ; redéfinir le modèle pour que cette accessibilité soit sa forme naturelle en est une autre.
Des espaces de contribution qui suivent l’organisation
Le nouveau CMS organise le contenu en Spaces, unités d’organisation principales de l’outil. Un Space regroupe des contenus, des membres avec des rôles qui leur sont propres, des paramètres de langues, une corbeille et des règles de partage. Il peut être connecté à un ou plusieurs sites pour la diffusion.
La filiation avec les asset libraries est assumée : les Spaces en offrent la flexibilité tout en étant pleinement intégrés à l’interface du CMS. Le dépôt mutualisé existait donc déjà ; il passe du statut d’outil d’administration à celui d’environnement de travail par défaut.
Dans une organisation à plusieurs entités, une équipe Communication, une équipe RH et une filiale disposent chacune de leur Space, avec leurs contributeurs et leur circuit de validation. Les actualités produites par l’équipe RH peuvent alimenter l’intranet groupe et celui de la filiale sans être recréées dans chaque site.
La production de contenu cesse d’épouser la structure des sites pour épouser celle de l’organisation. Dans les groupes multi-marques, multi-pays ou multi-entités, les deux ne coïncident jamais tout à fait, et cet écart se paie habituellement en duplication.
Une gestion des permissions plus simple à maintenir
C’est le changement le plus visible pour les équipes qui administrent la plateforme au quotidien.
Dans le modèle classique, les permissions définies au niveau d’un dossier ne cascadent pas automatiquement vers les sous-dossiers et les éléments qu’il contient. À l’échelle d’un intranet de groupe, cela se traduit par des campagnes de reprise de droits régulières et par un écart durable entre la politique voulue et la réalité constatée.
Des permissions par défaut se définissent désormais au niveau d’un Space ou d’un dossier, avec des jeux distincts pour les sous-dossiers, les contenus et les fichiers. Elles s’appliquent aux éléments créés après leur configuration, et une action dédiée permet de les propager aux éléments existants, avec confirmation explicite de l’administrateur. Les droits peuvent également être gérés rôle par rôle, en masse, ou affinés au niveau d’un dossier, d’une structure, d’un contenu, d’un vocabulaire ou d’une catégorie.
Concevoir une politique de droits cohérente reste nécessaire ; son application devient administrable et vérifiable, au lieu de reposer sur la discipline des équipes.
Du développement à la configuration
La possibilité de définir des champs dans une interface d’administration existe depuis longtemps chez Liferay. Ce qui change avec le nouveau CMS, c’est ce que la publication d’un type entraîne.
Lorsqu’une structure de contenu est publiée, un collection provider est créé automatiquement, c’est-à-dire une source de contenus prête à l’emploi : elle regroupe tous les contenus issus de cette structure et devient disponible dans la configuration des collections et des fragments d’affichage. Pour l’usage standard d’une structure, l’étape de définition préalable d’une collection disparaît ; les collections dynamiques ou manuelles ne restent nécessaires que pour du filtrage, un tri ou une sélection spécifiques.
Une expérience de saisie est par ailleurs générée automatiquement à la publication de la structure. Avec un abonnement Enterprise, cette expérience peut être ouverte dans l’éditeur de page et retravaillée avec des fragments de formulaire : accordéon, texte d’instruction en ligne, zone de dépôt de fichiers, prévisualisation vidéo. On simplifie le formulaire pour des contributeurs occasionnels, on l’enrichit pour une équipe éditoriale exigeante.
Le rôle des équipes techniques évolue en conséquence : moins de mécanique d’exposition pour chaque nouveau type, davantage de conception du modèle, de gouvernance et d’usages transverses.
Le contenu devient un patrimoine
Cette conséquence ne se voit pas dans une démonstration produit, mais elle structure la gestion des contenus dans le temps.
Dans un CMS orienté site, rien n’impose de créer le contenu dans le site qui en a besoin, mais c’est le chemin le plus court. Le contenu suit alors le cycle de vie de ce site : écarté lors d’une refonte, recréé pour un autre portail, gouverné selon des règles qui varient d’une équipe à l’autre.
Le contenu est désormais produit dans un espace gouverné, puis consommé par différents canaux. L’organisation peut alors se poser les questions qui caractérisent la gestion d’un actif : où cette information est-elle utilisée, qui peut la modifier, dans quelles langues existe-t-elle, quand doit-elle être révisée.
Cette logique facilite également l’exploitation du contenu par des mécanismes plus récents. La recherche sémantique de Liferay couvre les types du nouveau CMS, y compris les structures personnalisées, avec le niveau de traitement évoqué plus haut. D’autres usages, autour des assistants et des agents, reposent sur les mêmes API.
Un contenu structuré et correctement gouverné est plus simple à exploiter par une application mobile, par un moteur de recherche ou par un agent, et pour la même raison : sa structure et ses règles sont explicites et partagées.
Une adoption progressive est possible
Le Classic CMS ne disparaît pas. Il reste pleinement supporté, tandis que les évolutions se concentrent sur le nouveau modèle, et les deux systèmes fonctionnent en parallèle au sein de la même plateforme. Les sites et applications existants qui dépendent des fonctionnalités classiques continuent de fonctionner.
Pour les organisations qui disposent déjà d’un patrimoine de contenu conséquent, rien n’oblige donc à transformer l’existant dans l’immédiat.
L’approche que nous privilégions consiste à concevoir les nouveaux domaines de contenu sur le nouveau modèle, à laisser vivre l’existant, et à ne reprendre que ce dont la reprise apporte un bénéfice identifiable.
Le chantier commence donc par la modélisation : identifier les contenus qui doivent être partagés entre plusieurs canaux ou plusieurs entités, comprendre qui les produit et qui les consomme, définir les Spaces, les rôles et les règles de gouvernance. La migration vient ensuite, si elle est justifiée.
Ce qu’il faut retenir
Liferay ne reconstruit pas son CMS parce que la plateforme ne savait pas diffuser du contenu sur plusieurs canaux. Elle exposait déjà ses contenus via des API headless depuis plusieurs versions, notamment dès 7.2.
Le changement porte sur le socle du contenu dans la plateforme. Liferay le fait reposer sur le même framework que les autres données métier, au lieu de le laisser dépendre des conventions du seul module qui l’héberge. Le cas de la recherche sémantique montre que cette différence n’est pas théorique.
Pour les équipes, cela se traduit par des espaces de contribution plus proches de l’organisation réelle, une gestion des droits administrable, une autonomie accrue sur la définition des types de contenu, et un patrimoine réutilisable sans duplication.
La question que se posent les organisations n’est donc pas de savoir s’il faut adopter ce modèle : pour les nouvelles implémentations, Liferay a déjà tranché. La question utile est de savoir par quelle modélisation commencer, et c’est une décision d’architecture avant d’être un projet de migration.
Cet article reste volontairement centré sur les usages et la gouvernance. Une engineering note dédiée détaille l’architecture du nouveau modèle, les API, le fonctionnement des permissions et les principaux points d’attention pour la mise en œuvre : « Liferay CMS 2.0 : analyse architecturale du nouveau modèle de contenu ».
Nos équipes cadrent votre trajectoire et sécurisent chaque étape. Parlons-en.
Discuter de votre projet →