CMS Java headless - Guide pour les développeurs

Introduction

Un CMS Java headless est un système de gestion de contenu qui s'exécute sur la JVM, diffuse le contenu par des API et que les développeurs étendent avec leur propre code Java. Les organisations qui utilisent Java comme principal langage back-end cherchent souvent un CMS qu'elles peuvent étendre et déployer comme le reste de leur parc. Ce guide présente les principales caractéristiques d'un bon CMS Java headless et la manière dont Jahia répond à chaque critère.

Si vous comparez d'abord les architectures, lisez CMS headless ou traditionnel : comment bien choisir.

Modularité avec OSGi : la base d'un CMS Java headless

L'attribut le plus important d'un CMS Java, qu'il soit headless ou non, est sa modularité. La modularité est ce qui permet aux développeurs Java de customiser et d'étendre le CMS. Dans le monde Java, OSGi est le standard de modularité au niveau de l'application. JPMS modularise le JDK lui-même.

Passons en revue les principales exigences d'une bonne modularité, bien couvertes par OSGi :

• Isolation : Le problème le plus complexe à résoudre est de s'assurer que les bibliothèques que vous utilisez dans votre code n'entreront pas en conflit avec celles fournies par le fournisseur du CMS. L'isolation permet à un module d'embarquer ses propres dépendances, même si leurs versions diffèrent de celles de Jahia.
• Gestion des dépendances : La gestion des dépendances entre vos modules ou entre vos modules et le cœur du CMS doit être effectuée correctement. OSGi fournit un support avancé, y compris la possibilité de déclarer des dépendances pour une gamme de versions.
• Déploiement à chaud : Si vous devez redémarrer votre application à chaque fois que vous déployez du code, votre processus de développement sera terriblement lent. Vous avez besoin d'un CMS qui prenne en charge le déploiement à chaud. Cette fonctionnalité est également utile pour modifier la configuration de votre application à la volée (voir About Java modules dans la documentation).
• Prise en charge du "whiteboard pattern" : Ce design pattern est le complément parfait du déploiement à chaud ; il permet aux développeurs qui codent des modules de déclarer des implémentations qui seront déployées dans la plateforme. Par exemple, dans Jahia, vous pouvez déclarer des « actions ». Les actions sont du code qui sera exécuté lorsqu'une URL donnée est appelée. Le motif whiteboard vous permet de déclarer vos actions dans votre module et de vous assurer qu'elles seront prises en compte par Jahia lorsque vous déployez votre module. Le motif whiteboard repose sur des registres, chaque registre étant utilisé pour stocker les actions, les filtres, les travaux ou tout autre point d'intégration que la plateforme peut prendre en charge. La plateforme lit ces registres pour prendre en compte les implémentations que déclarent les modules.
• Bonus : l'outillage. Une bonne technologie de modularité s'accompagne d'un bon outillage pour mettre à jour la configuration, déployer, démarrer, arrêter et annuler le déploiement des modules. Cet outillage doit être accessible à l'aide d'API HTTP, de lignes de commande et d'interfaces utilisateur. Jahia utilise Apache Karaf comme implémentation OSGi, fournissant la plupart de ces fonctionnalités. Jahia a également ajouté une interface utilisateur pour déployer et gérer les modules, ainsi qu'une API de provisionnement basée sur YAML.

Pour le versant Spring de la question, lisez Pourquoi aucun CMS n'est basé sur Spring framework / Spring Boot ?

Modélisation du contenu

L'une des différences entre un CMS et une application classique est l'agilité requise pour gérer le modèle de données, appelé "content modeling" (modélisation du contenu) ou types de contenu. Il existe généralement deux approches pour répondre à cette exigence : 

• Le CMS qui fournit une interface utilisateur pour créer des types de contenu. Cette approche permet d'apprendre rapidement la modélisation de contenu.
• Les CMS qui permettent aux types de contenu d'être déployés en tant que code, en s'assurant que les types de contenu sont versionnés en même temps que le reste de votre code. 

Jahia est le deuxième type de CMS, offrant de nombreuses options pour la modélisation de contenu. Vous pouvez en savoir plus sur notre page présentant l'expérience développeur.

Extension de l'API : GraphQL dans un CMS Java headless

Une fois que vous avez un moyen de déployer du code Java - grâce à une bonne modularité - l'exigence la plus courante pour un CMS Java Headless serait de créer des nouvelles API sur mesure. 

Jahia utilise principalement GraphQL, et vous pouvez étendre les points de terminaison d'API existants ou en créer de nouveaux. Cette capacité s'applique aux queries et aux mutations. Si vous souhaitez voir à quoi ressemble une extension GraphQL, un exemple est disponible dans notre repository GraphQL Github.

Autres "integration patterns"

Outre la personnalisation des API, un bon CMS Java Headless prendra également en charge d'autres modèles d'intégration, tels que :

• Les services : Code réutilisable mettant en œuvre tout comportement personnalisé
• Actions : Code derrière une URL, appelé par exemple lors de l'envoi d'un formulaire
• Jobs : Exécution du code en fonction d'un calendrier
• Initialiseurs de listes de choix (choicelist initializers) : Remplir de manière programmée les listes déroulantes que voient les auteurs.
• D'autres modèles peuvent inclure des filtres, des règles, des validateurs, des décorateurs, etc. 

Si vous voulez voir à quoi cela ressemble dans Jahia, il y a un dépôt dédié : OSGi modules samples. 

Open source / open core

Pouvoir accéder au code source d'un produit que l'on souhaite étendre ou personnaliser est souvent très utile. Cela facilite le débogage et la relation avec l'éditeur. 

Jahia est open core : le cœur est disponible sous licence Apache 2.0 ou sous la licence commerciale JSEL, comme le montre l'en-tête de licence du dépôt public. La distribution Enterprise est commerciale.

Pour comparer les quatre modèles de licence open source, voir Meilleur CMS Java en 2026.

Expérience pour les utilisateurs métier

Il ne faut pas oublier qu'un bon CMS Java headless doit être un bon CMS. N'oubliez donc pas de vérifier les fonctionnalités pour les utilisateurs métier avec lesquels vous travaillez. Pour plus d'informations, lisez l'article Headless CMS - Quelles fonctionnalités pour les marketers ?

Couche de présentation / La tête

Si vous lisez ce billet et que vous cherchez un CMS headless, vous ne serez peut-être pas d'accord avec toutes les lignes ci-dessous... et ce n'est pas grave. Chez Jahia, nous pensons qu'une couche de présentation (générant du HTML à partir d'éléments de contenu) est toujours pratique et souvent essentielle. La capacité de rendre des pages HTML complètes ou des fragments HTML offre beaucoup plus de flexibilité qu'un CMS qui ne peut produire que du JSON. 

Jahia propose deux technologies de présentation (également appelées « templating ») : 

• JSP (Java Server Pages), technologie Java éprouvée depuis longtemps
• React JSX (JavaScript XML), qui peut être intégré dans des modules JavaScript. 

Pour voir comment le JSX est rendu et hydraté, lisez Sous le capot : hydratation des composants React en Java.

Les modules JavaScript sont arrivés avec Jahia 8.2.

Composants complémentaires 

Un CMS seul n'est parfois pas suffisant. Les données clients, surtout à forte fréquence d'écriture, demandent une autre architecture que le contenu : stockez-les dans une CDP (Customer Data Platform). La CDP de Jahia est construite sur Apache Unomi, la plateforme de données clients open source née chez Jahia. Elle est intégrée à la plateforme. Elle stocke aussi et gère les données de formulaires, le contenu généré par les utilisateurs, les données comportementales et les préférences des visiteurs.

Conclusion

En résumé, un bon CMS Java headless doit :

• Être modulaire et basé sur OSGi
• Fournir un modèle de données/contenu flexible
• Offrir une personnalisation/extensibilité des API
• Prendre en charge de multiples modèles d'intégration
• Être un bon CMS pour les utilisateurs métier
• Avoir une couche de présentation (donc, idéalement, ne pas être purement headless)

Si vous voulez en savoir plus, vous pouvez : 

• Lire notre page résumant l'expérience de développeur
• Lire la vue d'ensemble technique
• Comparer les plateformes avec notre checklist pour choisir un CMS Java.
• Essayer Jahia et parcourir nos tutoriels, décrivant l'intégration d'une page d'atterrissage dans Jahia.