Si vous gérez des sites Joomla depuis un certain temps, vous avez probablement ressenti ce malaise familier quand une version majeure arrive. Joomla 4 a été difficile. Joomla 5 a lissé certains aspérités. Mais Joomla 6 ? C'est en passe de devenir la version la plus divisive de l'histoire du CMS. Le panneau d'administration a été entièrement refactorisé, le gestionnaire d'extensions est fondamentalement différent, le rendu des templates présente des changements cassants qui affectent presque chaque template personnalisé, et la communauté... ne le prend pas bien.

Je construis et maintiens des sites Joomla depuis l'époque de Mambo. J'ai migré des clients à travers chaque passage douloureux entre versions majeures. Donc quand je dis que Joomla 6 semble différent — et pas en bien — je ne dramatise pas. Laissez-moi vous expliquer exactement ce qui a changé, pourquoi les administrateurs chevronnés sont contrariés, et quelles alternatives réalistes existent si vous envisagez de sauter le pas.

Table des matières

Pourquoi les administrateurs Joomla sont furieux face aux changements UX de Joomla 6

La refonte du panneau administrateur Joomla 6

Commençons par le changement le plus visible : le panneau d'administration. Joomla 6 introduit ce que l'équipe de développement appelle une « expérience administrative moderne ». En pratique, cela signifie qu'ils ont supprimé la navigation familière de la barre latérale gauche que les administrateurs Joomla utilisent depuis Joomla 4 et l'ont remplacée par une approche de navigation supérieure plus une barre latérale contextuelle.

Ce qui a réellement changé

Le panneau d'administration ancien avait une barre latérale gauche repliable avec des éléments de menu imbriqués. Vous pouviez accéder à n'importe quelle section du CMS en deux clics maximum. Ce n'était pas beau, mais c'était fonctionnel et — crucialement — c'était cohérent.

Joomla 6 bascule vers une barre de navigation horizontale supérieure avec des mega-menus déroulants. La barre latérale gauche n'apparaît maintenant que contextuellement, affichant les options pertinentes pour la section dans laquelle vous vous trouvez. La gestion des articles, la gestion des utilisateurs, la configuration des extensions — elles ont toutes des mises en page de barre latérale différentes maintenant.

Voici une comparaison des modèles de navigation :

Action Joomla 5 (clics) Joomla 6 (clics) Remarques
Créer un nouvel article 2 2-3 Dépend du contexte actuel
Accéder à la configuration globale 2 3 Enterré dans le menu Système
Gérer les extensions 2 2-4 La nouvelle vue catégorisée ajoute des étapes
Modifier les fichiers de template 3 4-5 Éditeur de template réimplanté
Vérifier les informations système 2 3 Déplacé dans le sous-menu
Gérer les fichiers médias 2 2 Sensiblement équivalent

Pourquoi les administrateurs le détestent

La plainte essentielle n'est pas qu'il a une apparence différente. Les administrateurs peuvent s'adapter aux changements visuels. Le problème est que la mémoire musculaire — la chose qui rend la gestion quotidienne du CMS supportable — est complètement brisée.

Quand vous gérez 15+ sites Joomla et que vous basculez entre eux tout au long de la journée, vous comptez sur le fait de savoir exactement où se trouvent les choses sans réfléchir. Joomla 6 vous oblige à tout réapprendre. Et la barre latérale contextuelle signifie que la navigation n'est même pas cohérente dans le nouveau système. La barre latérale affiche des éléments différents selon où vous vous trouvez, ce qui rend la création d'une nouvelle mémoire musculaire plus difficile.

Il y a aussi l'aspect accessibilité. Plusieurs membres de la communauté ont signalé que les mega-menus déroulants ne fonctionnent pas bien avec les lecteurs d'écran, et la navigation au clavier est incohérente. Pour un CMS open-source qui se vante de son accessibilité, c'est une régression importante.

Le problème des widgets du tableau de bord

Joomla 6 introduit également un nouveau système de widgets de tableau de bord qui remplace les modules de tableau de bord précédents. L'ancien système vous permettait d'ajouter et d'organiser les modules du tableau de bord avec une flexibilité raisonnable. Le nouveau système de widgets est plus visuellement attrayant mais nettement moins configurable.

Vous ne pouvez plus créer des mises en page de tableau de bord personnalisées par groupe d'utilisateurs — une fonctionnalité que de nombreuses agences Joomla utilisaient pour créer des expériences d'administration simplifiées pour les clients. Au lieu de cela, il existe une seule mises en page du tableau de bord avec des bascules de visibilité basées sur les rôles pour les widgets individuels. C'est un pas en arrière en termes de fonctionnalité maquillé en pas en avant en termes de conception.

Gestionnaire d'extensions : tout ce que vous saviez est faux

C'est là que les choses deviennent vraiment douloureuses. Joomla 6 introduit un gestionnaire d'extensions entièrement réécrit, et il casse la compatibilité avec la façon dont les extensions ont été empaquetées et installées pendant plus d'une décennie.

La nouvelle architecture d'extension

Joomla 6 passe à un système de gestion d'extensions basé sur Composer. En théorie, c'est une bonne idée. Composer est la norme pour la gestion des dépendances PHP, et aligner Joomla sur les pratiques PHP modernes est logique.

En pratique, cela signifie :

  • Les packages d'extensions doivent maintenant inclure un composer.json avec des déclarations d'espace de noms appropriées
  • L'ancien format de manifeste XML est obsolète (fonctionne toujours dans 6.0 mais lance des avertissements, prévu pour suppression dans 6.2)
  • Les chemins de découverte et d'installation des extensions ont changé — les scripts d'installation personnalisés qui référencent les anciens chemins vont casser
  • Le protocole du serveur de mise à jour a été révisé — les extensions utilisant l'ancien format XML de mise à jour doivent migrer vers le nouveau manifeste de mise à jour basé sur JSON
// Nouveau manifeste d'extension Joomla 6 (extrait composer.json)
{
  "name": "vendor/my-joomla-extension",
  "type": "joomla-plugin",
  "require": {
    "joomla/cms": "^6.0"
  },
  "extra": {
    "joomla": {
      "element": "myextension",
      "group": "content",
      "namespace": "Vendor\\Plugin\\Content\\MyExtension"
    }
  }
}

La crise de compatibilité des extensions

Voici l'impact réel : une portion importante de l'écosystème d'extensions Joomla n'est pas prête. Selon les données du répertoire des extensions Joomla (JED) depuis le début de 2026, environ 40% des extensions répertoriées n'ont pas été mises à jour pour la compatibilité Joomla 5, sans parler de Joomla 6.

Parmi les extensions compatibles avec Joomla 5, les premiers tests suggèrent qu'environ 60-70% nécessiteront des modifications non triviales pour fonctionner avec la nouvelle architecture d'extension de Joomla 6. Nous ne parlons pas de petits ajustements. Nous parlons de restructurer la façon dont les extensions sont empaquetées et distribuées.

Pour les extensions populaires comme Akeeba Backup, RSForm et JCE Editor, les développeurs ont déjà annoncé que les versions compatibles Joomla 6 sont en développement. Mais pour les milliers de petites extensions maintenues par des développeurs solo ou de petites équipes ? Beaucoup de ces éléments seront simplement abandonnés.

Ce que cela signifie pour les propriétaires de sites

Si votre site Joomla dépend de cinq extensions tierces ou plus (et la plupart le font), vous devez auditer chacune avant même de penser à mettre à niveau. Créez une feuille de calcul. Vérifiez le site du développeur de chaque extension pour les annonces de compatibilité Joomla 6. S'il n'y a aucune mention du support Joomla 6, supposez que cela ne fonctionnera pas.

J'ai fait cet audit pour trois sites clients jusqu'à présent. Deux d'entre eux ont au moins une extension critique sans feuille de route Joomla 6. C'est un bloqueur de migration.

Changements cassants du rendu des templates

Les changements du système de templates dans Joomla 6 sont le genre de choses qui fait froncer les sourcils aux développeurs chevronnés. Joomla a abandonné son système traditionnel de remplacement de templates basé sur PHP pour une approche hybride qui introduit une nouvelle couche de modèles.

Le nouveau moteur de template

Joomla 6 introduit Twig comme moteur de template facultatif (mais clairement préféré) aux côtés des remplacements PHP traditionnels. Les templates d'administration de base sont maintenant écrits en Twig. Les templates frontaux peuvent utiliser soit PHP soit Twig, mais le système de découverte des remplacements de templates a changé.

{# Exemple de template Twig Joomla 6 #}
{% extends "@joomla/base.html.twig" %}

{% block content %}
  <div class="com-content-article">
    <h1>{{ article.title | escape }}</h1>
    <div class="article-body">
      {{ article.introtext | raw }}
      {{ article.fulltext | raw }}
    </div>
  </div>
{% endblock %}

Ce qui casse

L'ordre de découverte des remplacements a changé. Dans Joomla 5, les remplacements de templates se trouvaient dans templates/your-template/html/com_content/article/default.php. Cela fonctionne toujours dans Joomla 6, mais si une version Twig existe à templates/your-template/html/com_content/article/default.html.twig, la version Twig a priorité.

Cela signifie que si un développeur de template fournit à la fois des remplacements PHP et Twig (ce que beaucoup feront pour supporter la transition), vos remplacements PHP personnalisés pourraient être silencieusement ignorés. J'ai déjà vu cela piéger des gens dans les tests bêta.

De plus, le système de paramètres de template a été repris. Les paramètres de template définis dans templateDetails.xml ont maintenant besoin d'entrées correspondantes dans un nouveau fichier template.config.php. Les anciens paramètres se chargent toujours, mais les nouvelles fonctionnalités comme l'aperçu en direct et le configurateur visuel de template ne fonctionnent qu'avec le nouveau format.

Impact sur les templates commerciaux

Les fournisseurs de templates commerciaux comme JoomlArt, GavickPro et Youjoomla sont dans une position difficile. Leur modèle commercial repose sur la maintenance des frameworks de templates qui fonctionnent sur les versions de Joomla. L'introduction de Twig et les changements de priorité des remplacements signifient qu'ils doivent essentiellement reconstruire leurs frameworks de templates.

Certains ont annoncé qu'ils ignoreront entièrement le support de Joomla 6 et se concentreront sur leurs propres outils de constructeur de pages ou la transition vers d'autres plates-formes. C'est un signal éloquent de la façon dont la communauté des templates voit ces changements.

Pourquoi les administrateurs Joomla sont furieux face aux changements UX de Joomla 6 - architecture

Réaction de la communauté : forums, GitHub et réseaux sociaux

La réaction de la communauté a été... intense. Et surtout négative.

Problèmes et demandes de tirage GitHub

Le référentiel GitHub de Joomla a connu un pic de rapports de problèmes avec la balise J6. Plusieurs membres éminents de la communauté ont ouvert des problèmes détaillés documentant les régressions UX. Un fil particulièrement notable, avec plus de 200 commentaires, soutient que les changements du panneau d'administration ont été apportés sans consultation communautaire adéquate.

La demande de tirage qui a introduit la nouvelle architecture du gestionnaire d'extensions a reçu une résistance importante lors de l'examen, avec plusieurs contributeurs de longue date votant contre la fusion. Il a été fusionné malgré tout, avec l'équipe de direction de production citant le besoin de moderniser la base de code.

Sentiment du forum

Le Forum communautaire Joomla et le subreddit Joomla non officiel ont été submergés par des messages d'administrateurs frustrés. Les thèmes courants incluent :

  • « Pourquoi réparer ce qui ne s'est pas cassé ? » — Le panneau d'administration UX, bien qu'imparfait, était fonctionnel et familier
  • « Apocalypse des extensions » — Craintes que le système basé sur Composer tue l'écosystème des extensions
  • « Qui a demandé Twig ? » — Les développeurs de templates se sentent surpris par le changement du moteur de templates
  • « Où est le chemin de migration ? » — Manque de chemins de migration clairs et automatisés pour les sites existants

Le contexte plus large

Ce n'est pas se produisant dans le vide. La part de marché de Joomla décline régulièrement. Selon les données de W3Techs de 2026, Joomla alimente environ 1,5% de tous les sites Web avec un CMS connu, en baisse par rapport à 2,6% en 2022. WordPress se situe à plus de 62%. Chaque décision controversée accélère la migration des sites en dehors de la plate-forme.

La frustration de la communauté ne concerne pas seulement Joomla 6 spécifiquement. C'est l'accumulation d'années où l'on a le sentiment que la direction du projet n'écoute pas les personnes qui utilisent réellement le logiciel quotidiennement. Joomla 6 est le catalyseur, mais le ressentiment s'accumulait.

Ce que dit la direction de Joomla

Le conseil Open Source Matters (OSM) et la direction de la production de Joomla ont réagi à la critique, bien que beaucoup pensent que les réponses ont été maladroites.

La position officielle est que ces changements sont nécessaires pour la survie à long terme de Joomla. Le système d'extensions basé sur Composer aligne Joomla avec les pratiques modernes de développement PHP. La couche de modèles Twig rend la plate-forme plus accessible aux développeurs provenant d'autres frameworks. Les changements UX d'administration sont basés sur des recherches utilisateur (bien que la méthodologie de recherche et la taille de l'échantillon aient été remises en question).

Un article de blog du département de production de Joomla au début de 2026 a reconnu la douleur de transition mais a soutenu que la perturbation à court terme est nécessaire pour la viabilité à long terme. Le message établit des comparaisons avec la transition de Joomla 1.5 à 2.5, qui était aussi douloureuse mais a finalement fait progresser la plate-forme.

La comparaison est appropriée, mais pas de la façon qu'ils l'entendent. La transition 1.5 à 2.5 a éloigné une grande partie de la communauté. Beaucoup de ces utilisateurs ne sont jamais revenus.

Dois-je migrer ou dois-je partir ?

C'est la question que tout le monde se pose, et la réponse honnête dépend de votre situation spécifique.

Rester si...

  • Votre site utilise principalement les fonctionnalités de base de Joomla sans dépendances d'extensions importantes
  • Votre template est basé sur Cassiopeia ou un framework qui s'engage à supporter Joomla 6
  • Vous avez des développeurs PHP en interne qui peuvent gérer le travail de migration
  • Votre organisation s'engage envers Joomla pour des raisons politiques/institutionnelles

Partir si...

  • Votre site dépend d'extensions qui n'ont pas de feuille de route Joomla 6
  • Vous êtes déjà frustré par Joomla et c'est la goutte d'eau qui a fait déborder le vase
  • Vous avez besoin d'une plate-forme avec un écosystème croissant (pas en déclin)
  • Le coût de la migration vers un autre CMS est comparable au coût de la mise à niveau vers Joomla 6

La réalité des coûts

Voici quelque chose que les gens ne parlent pas assez : migrer de Joomla 5 à Joomla 6 peut coûter presque autant que migrer vers un CMS complètement différent. Si vous devez reconstruire les templates, mettre à jour les extensions, recycler le personnel et tester tout, vous regardez des heures de développement importantes quel que soit la plate-forme cible.

Pour un site Joomla de complexité moyenne (50-200 articles, 5-10 extensions, template personnalisé), vous recherchez probablement 40-80 heures de travail de migration pour Joomla 6. Une migration vers une configuration CMS headless avec un frontend moderne ? 60-120 heures. L'écart n'est pas aussi grand que vous le pensez, et l'approche headless vous donne une plate-forme avec un écosystème croissant au lieu d'un écosystème en déclin.

Alternatives réalistes à Joomla en 2026

Si vous envisagez sérieusement des alternatives, voici une évaluation honnête des options.

Plateforme Meilleure pour Courbe d'apprentissage Taille de l'écosystème Trajectoire à long terme
WordPress Sites riches en contenu, blogging Basse Massive Stable mais Gutenberg controversé
Headless CMS + Next.js Sites critiques en performance, applications Moyen-Élevé Croissance rapide Forte croissance
Headless CMS + Astro Sites de contenu, sites marketing Moyen Croissance Forte croissance
Drupal Entreprise, gouvernement, données complexes Élevée Grand Stable
Craft CMS Sites de contenu de taille moyenne Moyen Modéré Stable
Statamic Boutiques Laravel, sites de contenu Moyen Croissance Positif

L'approche CMS Headless

Je suis biaisé ici car c'est ce que nous faisons chez Social Animal, mais l'approche CMS headless résout le problème fondamental qui se reproduit constamment avec les CMS traditionnels comme Joomla : le couplage de la gestion de contenu avec le rendu du frontend.

Quand votre CMS est headless, les changements UX dans le CMS ne cassent pas votre frontend. Le rendu des templates est géré par votre framework frontend (Next.js, Astro, peu importe), pas par le CMS. Et votre contenu est accessible via des API, ce qui signifie que vous n'êtes jamais enfermé dans une seule technologie de rendu.

Si vous êtes intéressé par cette approche, nous avons fait pas mal de migrations Joomla vers headless. Notre travail en développement CMS headless s'accorde bien avec soit Next.js soit Astro sur le frontend, selon vos besoins.

WordPress : le choix évident ?

WordPress est la suggestion par défaut chaque fois que quelqu'un demande des alternatives à Joomla, et ce n'est pas faux. L'écosystème est énorme, les options d'hébergement sont nombreuses, et la plupart des développeurs web le connaissent.

Mais WordPress a ses propres controverses UX (la saga de l'éditeur de blocs/Gutenberg reflète un peu ce qui se passe avec Joomla 6). Et la domination du marché de WordPress en fait la cible la plus grande pour les attaques. Si vous quittez Joomla en raison de préoccupations liées à la gouvernance, la situation actuelle de Matt Mullenweg avec WordPress pourrait aussi vous donner à réfléchir.

Drupal : le choix de l'utilisateur avancé

Drupal vaut le coup d'être envisagé si votre site Joomla a des relations de contenu complexes, des types de contenu personnalisés ou des exigences d'entreprise. Drupal 11 est solide, et la communauté Drupal est plus stable (si plus petite) que celle de Joomla.

L'inconvénient : la courbe d'apprentissage de Drupal est raide, et les coûts de développement sont généralement plus élevés que Joomla ou WordPress.

Stratégies de migration qui fonctionnent réellement

Si vous avez décidé de quitter Joomla, voici comment aborder la migration sans perdre votre santé mentale ou vos classements SEO.

Étape 1 : Audit du contenu

Exportez tout. La structure de base de données de Joomla est bien documentée, et vous pouvez extraire le contenu directement des tables #__content, #__categories, #__menu et #__users. Ne comptez pas sur les outils d'exportation intégrés de Joomla — ils sont limités. Écrivez des requêtes SQL personnalisées ou utilisez un outil comme la fonctionnalité d'exportation de données d'Akeeba.

Étape 2 : Mappage des URL

C'est l'étape que tout le monde saute, et c'est celle qui détruit votre SEO. Créez une carte complète de chaque URL sur votre site Joomla et son URL correspondante sur la nouvelle plate-forme. Configurez des redirections 301 pour chacune d'elles.

# Exemple : génération d'une liste d'URL à partir de la base de données de Joomla
mysql -u root -p joomla_db -e "
  SELECT CONCAT('/', alias) as url, title
  FROM j_content
  WHERE state = 1
  ORDER BY id;
" > joomla_urls.csv

Étape 3 : Choisissez votre architecture cible

Décidez si vous voulez un autre CMS traditionnel ou une configuration headless. Si votre site est principalement orienté contenu (articles, articles de blog, documentation), un CMS headless avec un framework frontend axé sur le statique comme Astro vous donnera des performances considérablement meilleures.

Étape 4 : Migrez en parallèle

N'essayez pas de faire une migration au complet. Configurez le nouveau site aux côtés de l'ancien. Migrez le contenu par lots. Testez minutieusement. Ne changez le DNS que lorsque vous êtes confiant que tout fonctionne.

Si vous avez besoin d'aide pour planifier cela, contactez-nous. Nous avons développé un processus répétable pour les migrations de CMS qui préserve l'équité SEO et minimise les interruptions. Vous pouvez également consulter notre page de prix pour des chiffres approximatifs sur les projets de migration.

FAQ

Quand Joomla 6 sera-t-il officiellement lancé ?

Joomla 6 cible une version stable fin 2026, suivant le nouveau cycle de versions chronométré du projet. Des versions alpha et bêta sont déjà disponibles pour les tests. Le calendrier de publication a glissé un couple de fois déjà, donc la date exacte reste fluide.

Mes extensions Joomla 5 fonctionneront-elles dans Joomla 6 ?

La plupart ne fonctionneront pas sans modifications. Le système d'extensions basé sur Composer de Joomla 6 nécessite de nouveaux formats de manifeste et des déclarations d'espace de noms mises à jour. Les extensions qui reposent sur des API obsolètes ou des anciens chemins d'installation vont casser. Vérifiez auprès de chaque développeur d'extension pour sa feuille de route de compatibilité Joomla 6 avant de tenter une mise à niveau.

Puis-je rester sur Joomla 5 au lieu de mettre à niveau ?

Oui, pour l'instant. Joomla 5 recevra des mises à jour de sécurité jusqu'à environ 2 ans après la version stable de Joomla 6, ce qui signifie environ fin 2028. Après cela, vous êtes livrés à vous-mêmes. Rester sur une version non supportée d'un CMS est un risque de sécurité important, donc c'est une solution temporaire au mieux.

La communauté Joomla se divise-t-elle réellement sur ce sujet ?

Il y a une vraie tension, mais cela n'a pas entraîné un fork officiel (encore). Plusieurs membres éminents de la communauté se sont publiquement retirés de la contribution. La communauté Joomla a traversé des conflits internes avant, mais la combinaison du déclin des parts de marché et les décisions techniques controversées rend cette période plus précaire que les disputes passées.

Quel est le moyen le moins cher de migrer loin de Joomla ?

Le chemin de migration le plus rentable dépend de la complexité de votre site. Pour les sites de contenu simples avec moins de 100 pages, une migration manuelle vers WordPress ou un CMS headless peut être faite en 20-30 heures. Pour les sites complexes avec des extensions personnalisées, comptez sur 80-150+ heures. L'utilisation d'outils de migration automatisés comme CMS2CMS peut réduire les coûts pour les mouvements de contenu simples mais ne gèrera pas les fonctionnalités personnalisées.

Dois-je attendre que Joomla 6 se stabilise avant de l'évaluer ?

C'est un conseil juste pour les changements UX — les premières impressions des nouvelles interfaces sont souvent plus dures que l'opinion établie. Mais les changements architecturaux (extensions Composer, templates Twig) ne vont pas changer. Ce sont des décisions de conception fondamentales. Si c'est votre préoccupation, attendre n'aidera pas.

Comment Joomla 6 se compare-t-il à Drupal 11 pour les sites d'entreprise ?

Drupal 11 est généralement un choix plus fort pour les sites de grade entreprise avec des modèles de contenu complexes, des permissions granulaires et des exigences de livraison sans tête. L'écosystème de Drupal pour les cas d'utilisation d'entreprise (workflows de contenu, support multilingue, livraison sans tête) est plus mature. Si vous envisagez déjà l'effort de migration, Drupal vaut la peine d'être évalué.

Quel est le meilleur CMS headless pour remplacer Joomla ?

Cela dépend de votre équipe et de vos exigences. Pour les sites marketing riches en contenu, Sanity ou Contentful associés à Next.js ou Astro sont d'excellents choix. Pour les sites qui ont besoin de plus de structure, Strapi ou Payload CMS vous donnent plus de contrôle sur vos modèles de contenu. L'avantage clé de toute approche headless est que vous êtes découplé du rendu frontend du CMS — ce qui signifie que vous ne ferez jamais face à ce genre de mise à niveau qui casse les templates à nouveau.