Meilleur CMS Java en 2026 : ce qu'il faut vérifier avant de choisir une plateforme

Votre organisation tourne sur Java et vos revues de sécurité, votre observabilité, vos chaînes de build et vos recrutements supposent tous la JVM. De nombreux éditeurs de CMS proposent une stack Node.js et un abonnement SaaS, ce qui donne à vos équipes une seconde stack à exploiter et à sécuriser.

Un CMS Java est un système de gestion de contenu qui tourne sur la JVM et que vous étendez avec votre propre code. Le meilleur CMS Java est celui qui convient à vos équipes. Six questions montrent lequel c'est :

• Mes développeurs front-end peuvent-ils travailler dans la couche de rendu ?
• Que puis-je déployer dans la plateforme : des API, des actions, des jobs, des listeners ?
• Comment la plateforme gère-t-elle les conflits de bibliothèques, les versions et les mises à jour ?
• Quels modes de déploiement, quel runtime et quelle licence propose-t-elle ?
• Le support de l'éditeur tient-il quand quelque chose casse ?
• Les éditeurs de contenu, plus nombreux que mes développeurs, l'accepteront-ils ?

En bref

• La plupart des listes de "CMS Java" incluent des plateformes qui n'ont pas publié de version avec de nouvelles fonctionnalités depuis des années. Trois contrôles les écartent.
• "Open source" recouvre quatre modèles de licence différents, alors lisez le fichier LICENSE de chaque éditeur.
• La modularité n'exige pas de microservices : OSGi la fournit à l'intérieur d'un seul processus depuis 20 ans.
• Le test le plus utile consiste à vérifier que votre équipe Java et votre équipe front-end peuvent toutes les deux déployer du code dans la plateforme.

1. Comment trouver le meilleur CMS Java : trois contrôles pour raccourcir la liste

Les annuaires de logiciels recensent de 15 à 20 plateformes de CMS Java et beaucoup n'ont pas publié de version avec de nouvelles fonctionnalités depuis des années. Trois contrôles montrent quels projets sont encore maintenus :

1. Cadence des versions : si la dernière version avec de nouvelles fonctionnalités a plus d'un an, le projet est en mode maintenance, quoi que dise son site.
2. Support des runtimes : un projet maintenu publie une matrice de support pour les runtimes, les conteneurs et les bases de données. Sans elle, vous ne pouvez pas savoir si le projet suit la plateforme que vous exploitez.
3. Documentation vivante : une documentation arrêtée depuis plusieurs versions montre à quel point l'éditeur investit encore dans l'ingénierie.

Cet article n'étiquette aucune plateforme comme abandonnée, car les trois contrôles vous donnent cette réponse.

2. La modularité sans microservices

Au cours de la dernière décennie, "modulaire" est devenu synonyme de "microservices" dans de nombreuses équipes. Les microservices exécutent chaque partie d'un système dans son propre processus, avec trois coûts :

• Chaque frontière interne devient un appel réseau.
• Le déploiement indépendant exige de la découverte de services, du traçage distribué, des politiques de reprise et une authentification pour chaque service.
• Le périmètre d'astreinte s'élargit à chaque service ajouté.

Ces coûts valent la peine d'être payés quand de nombreuses équipes doivent livrer indépendamment. Une plateforme de contenu est généralement un produit unique exploité par une seule équipe, si bien que ces coûts s'y justifient rarement.

Les équipes attendent généralement des microservices l'isolation, le déploiement indépendant et des contrats explicites. Les trois tiennent dans un seul processus, dans une architecture appelée modulith. Spring propose désormais Spring Modulith, mais il répond à un périmètre différent : il vérifie les frontières de modules dans les tests, dans une application que vous possédez. Une plateforme de contenu a besoin de ces frontières à l'exécution, car elle doit isoler des modules tiers, résoudre des versions de dépendances en conflit et déployer des modules pendant qu'elle tourne. Nous expliquons la différence dans Pourquoi aucun CMS n'est basé sur Spring framework / Spring Boot ?

La différence se voit surtout sur les petits chantiers, comme une intégration CRM, un job de synchronisation nocturne ou une étape d'approbation sur mesure :

Java dispose d'un standard pour cela depuis deux décennies : OSGi. OSGi fournit des dépendances versionnées, l'isolation par classloader, la gestion du cycle de vie et le déploiement à chaud. JPMS a modularisé le JDK lui-même et OSGi traite la modularité au niveau de l'application.

OSGi est répandu sur ce marché. AEM s'appuie sur Apache Felix, dotCMS utilise Felix pour ses plugins et Jahia tourne sur Apache Karaf. Pour chaque plateforme, la question utile est de savoir jusqu'où va OSGi : une couche de plugins en périphérie du produit, ou le système de modules de toute la plateforme.

Question à poser à l'éditeur : "Mon module a besoin de Jackson X et votre cœur embarque Jackson Y. Que se passe-t-il ?" Demandez ensuite où s'arrête exactement la couche de plugins.

Appliquer le même test au headless SaaS

Avec un headless SaaS, vous n'exploitez pas de plateforme et les fonctions de ses modules passent chez d'autres éditeurs. La recherche, la personnalisation, les formulaires, le DAM, la traduction et la prévisualisation deviennent chacun un service tiers, avec son authentification, son SLA, sa cadence de versions et sa facture. Votre équipe écrit et exploite le middleware qui relie ces services.

Évaluez cet ensemble de services comme un seul système :

• Ce que coûtent les intégrations au total.
• Quels modes de défaillance traversent plusieurs éditeurs.
• Qui est appelé quand deux services ne sont pas d'accord.

Certaines équipes font ce calcul et constatent qu'elles ont acheté le parc de microservices qu'elles voulaient éviter : les éditeurs exploitent les services et l'équipe exploite chaque intégration entre eux.

3. Où s'exécute votre propre code

Un CMS sur la JVM n'aide que si votre propre code s'exécute à l'intérieur. Vérifiez où atterrit votre logique : les intégrations ERP et SSO, les workflows et les services métier soit se déploient dans la plateforme, soit s'accumulent en middleware autour d'elle.

Dans Jahia, les modules Java sont des bundles OSGi qui s'exécutent sur Apache Karaf, comme le décrit l'aperçu technique. Pour l'angle headless, consultez notre guide du CMS Java headless.

4. Vérifier toute la surface d'extension

Le rendu n'est qu'une partie de ce que vous allez étendre. Attendez-vous à ces points d'extension, présentés ici avec les noms de Jahia (disponibles dans les modules Java) :

• GraphQL extensions : nouvelles queries, mutations et subscriptions
• Services : logique métier réutilisable
• Actions : code derrière une URL
• Jobs : code exécuté selon une planification
• Choicelist initializers : code qui remplit les listes déroulantes que voient les auteurs
• Filters et listeners

Ces extensions utilisent le pattern whiteboard d'OSGi : votre module enregistre ses implémentations dans les registres de la plateforme. Déployez le module et la plateforme les prend en compte, retirez-le et elles disparaissent, sans patch du cœur et sans fork.

Deux dépôts d'exemples montrent le code : exemple d'extension GraphQL et exemples de modules OSGi.

Question à poser à l'éditeur : "Puis-je étendre votre schéma d'API ou seulement le consommer ?"

5. Des développeurs front-end à l'intérieur de la plateforme

Depuis les articles sur le "CMS Java" de l'époque 2019, une chose a changé : la plupart des organisations Java emploient désormais des ingénieurs React et TypeScript. En général, l'équipe back-end possède le CMS, l'équipe front-end construit un front séparé et chaque projet paie l'intégration entre les deux.

Les modules JavaScript de Jahia suppriment cette séparation. Ils sont disponibles depuis Jahia 8.2 et prêts pour la production depuis la 8.2.3.

• Les développeurs front-end construisent les fonctionnalités de Jahia sous forme de paquets npm, avec du JSX ou du TSX côté serveur, un packaging yarn et sans Java.
• Les modules s'exécutent à l'intérieur de la plateforme, pas comme un client headless, si bien que l'édition, la prévisualisation, la publication, le cache et l'authentification fonctionnent sans intégration sur mesure.
• Pour l'interactivité, ils utilisent l'hydratation partielle (islands) : le serveur produit le HTML et seuls les composants qui déclarent un comportement côté client sont hydratés.

6. Une plateforme, deux langages

Les modules JavaScript et les modules Java partagent les mêmes services de la plateforme :

• Le code JavaScript appelle directement les services Java, sans appel HTTP.
• Le hook useServerContext() donne à un composant React le contexte de rendu, le nœud JCR courant et les objets Java de la plateforme.
• L'équipe back-end expose des services OSGi et l'équipe front-end les appelle depuis du TSX.
• Les deux types de modules partagent un seul modèle de déploiement, un seul périmètre de sécurité et un seul cache.

Le dépôt des modules JavaScript est sous Apache 2.0.

Statut : orientation à court terme, pas encore livrée.

Améliorations à venir des modules JavaScript :

• Filters, actions et choicelist initializers en JavaScript
• Query builder : créer facilement des requêtes de contenu efficaces
• Content Patches : migrer plus facilement les définitions et le contenu avec des scripts TypeScript

Nous travaillons à couvrir chaque point d'extension avec des modules et à étendre les modules JavaScript. Notre documentation publique présente les actions côté serveur et l'outillage comme à venir.

7. Un déploiement sur l'infrastructure que vous exploitez déjà

• Jahia tourne sur Apache Tomcat, le conteneur de servlets que de nombreuses équipes plateforme Java exploitent déjà.
• Vous pouvez le déployer directement ou utiliser nos images Docker, qui tournent sur OpenJDK depuis Jahia 8.2.3.
• La stack est Apache de bout en bout : Tomcat pour les servlets, Karaf pour les modules.
• Vous déployez les modules avec Maven ou yarn, sans redémarrage de la plateforme.
• Jahia fonctionne on-premise ou dans votre propre cloud.

L'objectif est que votre équipe plateforme exploite Jahia comme le reste de votre parc Java.

Question à poser à l'éditeur : "Que faut-il pour livrer une modification : un déploiement à chaud, un redémarrage ou une exécution complète du pipeline ?"

8. "CMS Java open source" recouvre quatre modèles de licence

"CMS Java open source" est l'une des expressions les plus recherchées de cette catégorie et elle recouvre quatre modèles économiques. La différence se voit au renouvellement du contrat, pas au téléchargement.

Jahia est open core. Le cœur est disponible sous Apache 2.0 ou sous la licence commerciale JSEL, comme le montre l'en-tête de licence de notre dépôt public. La distribution Enterprise est commerciale. Pour les modules JavaScript, le dépôt est sous Apache 2.0 et certains paquets npm sont sous MIT : la bibliothèque, le plugin Vite et l'outil de création de projet.

Quel que soit l'éditeur, lisez le fichier LICENSE plutôt que l'étiquette de la catégorie.

9. Huit contrôles à faire avant de signer

Ces différences se voient rarement dans les schémas d'architecture, mais elles se voient dans le travail quotidien quelques mois après le début du projet.

1. Modélisation du contenu : certaines plateformes construisent les types de contenu dans une interface et d'autres, dont Jahia, les déploient sous forme de code que votre pipeline versionne et promeut. Si votre modèle de contenu ne peut pas circuler dans votre pipeline CI/CD, chaque livraison dépend encore d'étapes manuelles. Voir l'expérience développeur. À demander : "Les types de contenu sont-ils versionnés avec mon code et comment passent-ils d'un environnement à l'autre ?"
2. Sécurité et conformité : votre CMS porte votre surface d'attaque la plus publique, alors vérifiez les permissions, le SSO, la cadence des correctifs et les certifications sur des preuves. Nos preuves sont dans le Trust Center de Jahia, dont le certificat ISO 27001. À demander : "Cela peut-il fonctionner en air-gapped ou dans un cloud souverain et quelles données renvoie-t-il à l'éditeur ?"
3. Données clients : les soumissions de formulaires, les événements comportementaux et les préférences produisent un volume élevé d'écritures et ces données demandent une autre architecture que le contenu. Stockez-les dans une CDP. La CDP de Jahia est construite sur Apache Unomi et intégrée à la plateforme. Si un éditeur stocke des données comportementales dans le référentiel de contenu, attendez-vous à devoir réécrire cette partie plus tard.
4. Recherche plein texte : la recherche intégrée à un référentiel de contenu ne suffit pas pour un grand site. Augmented Search de Jahia étend l'API GraphQL avec Elasticsearch, ce qui apporte de la pertinence sur les pages entières, des résultats filtrés par permissions et moins de charge sur la plateforme. Voir l'architecture d'Augmented Search et les prérequis on-premise.
5. Options de déploiement : attendez-vous à un vrai choix entre cloud managé et auto-hébergement, car les besoins changent souvent pendant un contrat. Jahia propose les deux. Voir la section 7 pour le runtime et le Trust Center de Jahia pour notre posture de sécurité.
6. Support : chaque éditeur juge son support excellent, alors jugez-le sur des engagements écrits. Cherchez par écrit les fenêtres de versions et les dates de fin de vie, comme dans notre politique de maintenance et d'assistance, qui définit les règles de release. Les dates de fin de vie des runtimes figurent dans notre stack supportée. Testez la documentation sur une tâche réelle. À demander : "Quand cela casse à 2 h du matin, mon équipe peut-elle lire le code source ?"
7. Coût des montées de version : les mises à jour de modules doivent être un travail courant et les montées de version de la plateforme sont l'endroit où se voit votre coût total de possession réel. À demander : "Montrez-moi les notes de migration de vos deux dernières versions majeures. Qu'est-ce qui a cassé dans les modules des clients et qui l'a corrigé ?" Si vous faites face à ce coût aujourd'hui, pensez à notre Migration CMS gratuite par IA : la migration vers Jahia est gratuite et les clients réalisent jusqu'à 50 % d'économies sur leur abonnement CMS annuel par rapport à leur plateforme actuelle, pour des fonctionnalités d'expérience digitale équivalentes.
8. Expérience des éditeurs de contenu : les éditeurs de contenu sont plus nombreux que les développeurs et un CMS Java doit aussi bien fonctionner pour eux. Testez avec eux l'édition, la prévisualisation et les workflows, à l'aide de notre liste de points à vérifier pour les marketers sur un projet headless.

Plateformes CMS Java : Jahia, Adobe AEM, Magnolia, dotCMS et Liferay

Ces cinq plateformes soutenues par un éditeur sont celles que ce guide nomme. Appliquez les trois contrôles de la section 1 à chacune d'elles et à toute autre plateforme de votre liste. Si vous évaluez déjà AEM, lisez notre guide des alternatives à AEM. Si vous évaluez Liferay, lisez notre guide des alternatives à Liferay.

Quel est le meilleur CMS Java selon votre situation ?

Aucune plateforme ne convient à toutes les situations. Ce tableau associe des situations courantes à un type de plateforme.

Comment évaluer un CMS Java : les questions à poser à chaque éditeur

Posez les mêmes questions à chaque éditeur, nous compris, puis notez toute question à laquelle un éditeur ne sait pas répondre précisément.

1. Mon module a besoin de Jackson X et votre cœur embarque Jackson Y. Que se passe-t-il ?
2. Où s'arrête exactement votre couche de plugins ? Que ne puis-je pas surcharger ?
3. Montrez-moi les notes de migration de vos deux dernières versions majeures. Qu'est-ce qui a cassé dans les modules des clients et qui l'a corrigé ?
4. Les types de contenu sont-ils versionnés avec mon code et comment passent-ils d'un environnement à l'autre ?
5. Que faut-il pour livrer une modification : un déploiement à chaud, un redémarrage ou une exécution complète du pipeline ?
6. Puis-je étendre votre schéma d'API (queries, mutations, subscriptions) ou seulement le consommer ?
7. Cela peut-il fonctionner en air-gapped ou dans un cloud souverain et quelles données renvoie-t-il à l'éditeur ?
8. Quand cela casse à 2 h du matin, mon équipe peut-elle lire le code source ?
9. Que demande votre modèle front-end à mon équipe : compétences, dépôts, déploiement ?

Si vous préférez tester plutôt que lire, demandez une démo et venez avec cette liste.