Joomla! face à Wordpress et Drupal

Les CMS, Joomla! et les autres technologies

Pourquoi l'agence web Pulsar a-t-elle choisi le CMS Joomla! depuis 2007 ? Selon l'observateur w3techs.com le CMS Joomla! se place tous ans dans le trio de tête des CMS avec Wordpress et Drupal mais n'arrive pourtant pas en première position et reste même très en retrait par rapport à Wordpress !

Il faut cependant relativiser ces chiffres car une autre étude, toujours du même observateur, montre que 56% des sites web mondiaux ne sont pas fait avec un CMS connu. Joomla! occupe environ 2.7% du marché toutes technologies confondues, Drupal 2.2% et Wordpress s'octroyant 26% du marché. Les 3 CMS les plus réputés n'occupent donc ensemble que moins d'un tiers du marché. 

Une écrasante majorité relative pour Wordpress, mais ...

Au vu des chiffres Wordpress s'impose comme LA solution CMS Open Source. C'est effectivement la solution la plus largement utilisée. C’est un excellent C.M.S Open Source du marché qui bénéficie de surcroît d’une large communauté francophone et internationale pro-active. D’un « simple » moteur de blog à ses débuts, WordPress est devenu aujourd’hui la plateforme technique permettant de faire pratiquement tout ce dont une société, ou une association, à besoin. De la publication d’articles à la diffusion médias et de produits en passant par la gestion d’une communauté, tout est possible avec cet environnement utilisé tant par les petites structures que par les grands groupes.

Son gros avantage reste sa simplicité et son imposante utilisation provient essentiellement d'une écrasante base de blogs et sites personnels réalisés par des personnes séduites par une interface simplissime.

Wordpress présente cependant quelques inconvénients qu'il convient de connaître:

Les modifications nécessitent rapidement une connaissance de PHP. 

Des opérations comme le retrait d'un champ date nécessite la compréhension du langage PHP et c'est le cas de la plupart des modifications.

Plugins et performance

Pour se mesurer à Joomla! ou à Drupal, Wordpress utilise une très grande collection de plugins à installer. Malheureusement ces plugins influencent les performances des scripts dans le mauvais sens. Un autre souci apparaît quand vous avez besoin de choisir un plugin pour atteindre une fonction donnée. Parmi les milliers de plugins, la plupart d'entre eux possédant leur propres clones développés par différents auteurs, il devient très difficile de choisir. Avec cette approche on arrive très vite à un assemblage peu fiable, peu sécurisé, hétéroclite et peu maintenable.

Sécurité PHP

Si la sécurité du coeur de Wordpress est assez solide il en va tout autrement de la multitudes des plugins que vous devrez installer. La très grande majorité des attaques sur les sites Wordpress passent par des plugins mal sécurisés. 

Un autre gros souci inhérent au succès de Wordpress est qu'il est naturellement la cible de plus d'attaques car il est plus visible et plus exposé que les autres solutions. 

Chemins absolus

C'est ici un héritage des premières versions de Wordpress et qui ne peut être remis en cause sans casser la rétro-compatibilité. Les chemins dans Wordpress sont écrits dans la base de données en dur (quand ils ne sont pas écrits dans les fichiers). Cela pose évidemment un problème lors d'une migration. Des plugins existent pour passer temporairement les liens en relatif le temps du développement mais il faut tout de même penser dans certains cas à venir vérifier manuellement. 

Complexité des requêtes SQL

Du au manque d'approche modulaire (CCK ou Content Construction Kit) de Wordpress, les requêtes peuvent être complexes car tous les champs additionnels ne bénéficient pas d'une modélisation unifiée comme on peut en rencontrer avec FIELDS de Drupal ou SEBLOD de Joomla! En clair cela signifie qu'on peut bien sûr à peu près tout faire avec Wordpress mais au prix d'une lourdeur et d'une complexité croissante. 

Architecture vieillissante... au final une solution qui devient complexe 

Le code de WP est un code procédural très classique, très loin du code MVC (Modèle-Vue-Contrôleur) dans une approche POO (Programmation Orientée Objet) de Joomla! ou du framework PHP Symfony maintenant utilisé par Drupal8. Dans WP on ne sépare pas le fond de la forme (les fonctions de l'affichage) et il est très courant de trouver des requêtes SQL dans les templates. La mise à jour d'un template (un thème) n'est pas si facile du fait de cette non séparation. 

Une autre conséquence est le manque de modélisation unifiée quand il s'agit de penser des fonctions avec des types de contenus complexes et croisés. Il n'y a pas l'équivalent de VIEWS (pour Drupal) ou des listes SEBLOD (pour Joomla!) qui permettent une modélisation des affichages et des requêtes.

Le résultat est que Wordpress est un outil prêt à l'emploi très simple et performant à utiliser... tant que vous ne lui demandez pas des développements spécifiques. 

Un plébiscite des grands comptes pour Drupal

A l'autre bout du spectre des solutions CMS Open Source on trouve Drupal qui, s'il ne représente qu'un faible pourcentage des cas d'utilisation des CMS, est de plus en plus plébiscité par les grands comptes. Drupal a très souvent l'image auprès des DSI d'être la seule solution CMS Open Source réellement professionnelle pour des sites d'envergures. 

Cette image, qui est pourtant largement fondée, vient en partie de son architecture qui depuis le début permet des développements à façon avec peu voire pas du tout de code à écrire. Depuis des années Drupal a démocratisé la notion de types de contenus et le terme CCK (Content Construction Kit) réutilisé chez Joomla! désignait un module Drupal renommé FIELDS lors de son intégration native avec la version 7. 

C'est cette flexibilité, qui s'accompagne cependant d'une certaine complexité, qui a positionné Drupal sur des projets professionnels dès le départ, là où Wordpress a démarré en séduisant des particuliers et petites structures par une prise en main rapide. Le marché a tendance à se bi-polariser entre d'un coté la simplicité de Wordpress et de l'autre la richesse fonctionnelle de Drupal.

La venue récente de la version 8 de Drupal avec notamment l'intégration du framework Synfony, déjà largement apprécié de la communauté des développeurs PHP, accentue ce positionnement 'dev' de Drupal aux antipodes d'une solution facile. 

Cependant Drupal n'est pas exempt de défauts qu'il faut connaître pour choisir sa solution CMS. Comme toute solution, Drupal possède de (nombreux) avantages mais présente aussi des inconvénients qui peuvent ne pas convenir à votre projet:

Difficulté d'installation ou de mise à jour

Malheureusement Drupal n'est pas exactement user-firendly ou intuitif. Le résultat est qu'il ne peut être installé, mis à jour ou modifié par n'importe qui. Au contraire le système nécessite un développeur expérimenté avec une profonde connaissance et expertise de Drupal.

Interface complexe

En plus d'être plus difficile à installer qu'un Wordpress ou qu'un Joomla! Drupal est aussi difficile à gérer. Son interface est compliquée et même si elle peut être personnalisée elle risque de noyer les développeurs qui la découvrent. Un expert est souvent requis ici encore.

Des ressources difficiles à trouver

C'est un point crucial. Il reste difficile de trouver des epxerts Drupal. Si vous ne voulez prendre aucun risque vous decidez d'embaucher un spécialiste Drupal pour faire tout le travail. C'est une decision sensée si vous ne disposez pas d'un tel expert dans votre équipe. Malheureusement vous n'en trouverez pas facilement et les coûts seront élévés. C'est d'autant plus frustrant qu'on peine à bien évaluer la compétence de ces candidats.

Poids des modules contrib et problèmes de compatibilité

Si on utilise une approche par "modules contrib" où on assemble des modules développés par des auteurs différents de la communauté, ce qui est cependant un des principaux avantages de Drupal, on se heurte à des soucis de compatibilité. Il faut encore faire appel à un développeur expérimenté pour débugger et faire que tous ces modules fonctionnent ensemble.

Lourdeur et lenteur

C'est encore un point essentiel qui de plus ne s'arrange pas avec l'arrivée de chaque nouvelle versions. Drupal est de loin le CMS Open Source qui utilise le plus de mémoire et de CPU. Il est puissant, flexible et on trouve toujours la solution à ses problèmes mais au prix d'une lourdeur qui se traduit par des temps de réponse beaucoup plus longs qu'avec les autres solutions. La parade qui devient presque obligatoire avec Drupal 8 et l'utilisation du framework Symfony, consiste à utiliser des serveurs plus performants avec des caches et des reverse proxy systématiques. Vu que Drupal se destine de plus en plus uniquement à de gros sites à gros trafic, ce genre d'architecture va de soi, mais cela limite l'usage du CMS à des projets plus modestes.

Alors Joomla! dans tout cela ?

Un positionnement intermédiaire

Joomla!, après plus de 10 ans d'expérience, correspond à une approche intermédiaire entre la simplicité de Wordpress et la richesse fonctionnelle de Drupal. En tant que CMS seul Joomla! propose surtout une diversité d'approches intéressantes le rendant accessible à tout type d'utilisateurs:

• l'approche standard en empilant des extensions diverses pour les non programmeurs à la Wordpress
• une approche 100% développeur en utilisant le framework Joomla! orienté objet permettant de développer ses propres fonctionalités 
• une approche CCK à la Drupal avec d'excellentes solutions comme SEBLOD

S'il n'y avait que la première approche, Joomla! resterait intéressant grâce à la qualité et la complétude des extensions existantes. En effet le framework sous-jacent de Joomla! a permis le développement de véritables applications très complètes qui n'ont que peu d'équivalents chez d'autres CMS. 

Reste que cette méthode se heurte tout de même aux mêmes problèmes qu'on rencontre ailleurs c'est à dire: un manque d’homogénéité des interfaces, une instabilité et une vulnérabilité croissantes à cause de l'empilement de développements épars,  une couverture approximative des fonctions du cahier des charges.

L'approche 100% dev, préconisée par certaines agences, donnent de bons résultats mais convient à des projets très spécifiques avec des budgets plus conséquents. 

La dernière approche, qui a notre faveur, consiste à n'utiliser quasiment qu'une seule extension (le CCK) pour développer à façon ce dont nous avons exactement besoin. C'est le couple Joomla! SEBLOD qui donne au CMS une valeur nettement avantageuse par rapport aux autres CMS.

Le couple Joomla! SEBLOD

Positionnement et enveloppes budgétaires

Une tendance que vient confirmer la version 8 est que Drupal se positionne de plus en plus comme le CMS pour des gros sites à fort trafic. Le ticket d'entré moyen d'un projet Drupal est aux alentours de 50K € en lorgnant rapidement vers les 100K €. Sa relative lourdeur (qui a un impact sur sa relative lenteur) nécessite des infrastructures plus musclées qui ne peuvent être justifiées que pour des projets à budgets plus conséquents. A l'inverse les projets Joomla/Seblod (en tous cas pour l'agence Pulsar) se situent dans la fourchette 15-80 K€ environ pour une couverture fonctionnelle quasi équivalente.

Facilité de mise à jour et maintenabilité

Un projet type Drupal contient des dizaines de modules imbriqués qu'il devient souvent très difficile à mettre à jour tant les dépendances sont fortes. Les hook qui sont souvent des hacks ne permettent pas non plus des montées de version transparentes. 

Par ailleurs la mise à jour d'un Drupal 5 vers 6 ou d'un 6 vers 7 (et d'un 7 vers 8) représente une véritable migration bien plus qu'une mise à jour. La (trop?) forte dépendance de Drupal aux modules contrib qui ne sont pas disponibles au moment de la nouvelle release de Drupal fait que la mise à jour constitue en elle-même un véritable projet facturé, en dehors de la maintenance. Les coûts de maintenance peuvent alors devenir potentiellement insupportables. L'architecture profondément modifiée à chaque nouvelle version du CMS ajoute une couche de complexité. 

A l'inverse Joomla! après la très difficile migration des versions 1.5 vers la 1.6 a opté pour des migration simples voir très simples ce qui protège les investissements des clients. D'autre part la modélisation apportée par Seblod (unification formulaire et types de contenu d'un coté, listes et recherches de l'autre) permet de faire la quasi totalité des travaux sans extensions tierces. Ces raisons font que la mise à jour d'un projet Joomla/Seblod est nettement plus simple et donc moins coûteuse qu'un projet Drupal. 

Enfin la modification d'un type de contenu, formulaire ou d'une liste avec le couple Joomla! Seblod se fait essentiellement au travers d'une interface graphique drag & drop très simple. On retrouve les mêmes fonctions ou à peu près dans Drupal mais avec le sentiment que l'interface graphique n'est pas aussi aboutie et l'essentiel du travail se fait au niveau du code informatique.

Richesse des templates Joomla!

Ce n'est pas nouveau mais les frameworks de template Joomla! ont toujours été très riches et plus variés que les thèmes Drupal. Par ailleurs Joomla 3.x intégre le responsive design nativement, ce que Drupal ne fera pas avant l'année prochaine avec la version 8.

Richesse des extensions ‘applications’ complètes

Une autre force de Joomla! réside dans la disponibilité de quelques extensions applicatives très complètes comme la gestion de forum, blogs ou de newsletter qu'on ne retrouve pas dans le monde Drupal (même si il existe des modules Drupal très performants). L'avantage de ces extensions Joomla! est d'être des applications installables en quelques clics plus 'finies' ( http://www.kunena.org/, http://stackideas.com/easyblog ou https://www.acymailing.com/) que celles chez Drupal (https://www.drupal.org/documentation/modules/forum, https://www.drupal.org/project/newsletter ou https://www.drupal.org/project/simplenews). 

Performances

Drupal est réputé convenir pour des gros sites à fort trafic mais ce n'est qu'au prix de gros efforts de développement et d'une mise en place de cache sur le serveur. Drupal 'out of the box' est au contraire beaucoup plus lent qu'une solution Wordpress ou Joomla! De plus l'assemblage naturel de modules pour obtenir les fonctions souhaitées ne fait que ralentir une solution peu adaptée pour des sites standards. Cette situation empire avec la version 8 basée en partie sur le framework Symfony qui alourdit la structure comme tous les tests actuels le montrent sur le net. Vous n'êtes pas obligé de me croire, installez un wordpress, un Joomla et un Drupal (7 ou 8) et mesurer le temps d'affichage d'une page!

Vous pouvez aussi avoir plus de détails techniques avec cet autre comparatif réalisé par un développeur PHP.

Réutilisation par les dossiers d’application

Une force industrielle majeure de Joomla! avec Seblod réside dans sa capacité de constituer des dossiers d'applications réutilisables de projet en projet. Seblod n'est pas seulement un cck mais c'est avant tout un application builder permettant un gain de productivité important qu'on ne retrouve pas dans le monde Drupal.

Séparation template général et template de contenu

Seblod permet de répartir graphiquement très simplement les champs et modules à l'intérieur même du bloc de contenu, sans toucher au template général du site. Cela permet de constituer des interfaces back et front tres rapidement.

Framework Joomla!

A l'heure où Drupal a choisi enfin de passer d'un modèle procédural à un modèle MVC on ne peut que constater que Joomla! repose sur un framework objet MVC depuis la première version. Certains d'ailleurs ne développent qu'avec le framework Joomla!

Multi sites très simple

La gestion multi sites est native dans Seblod et permet la mise en place de plateformes multi sites où chaque site peut partager des contenus et des fonctions. Basée sur les ACLs natifs de Joomla! la gestion multi sites de Seblod est d'une grande simplicité.

Approche Seblod vs celle de Drupal

Quand on travaille avec Drupal on est vite surpris de l'approche traditionnelle qui consiste à trouver les bons modules qui empilés vont réaliser les fonctions demandées par le cahier des charges. En effet cette approche aboutit rapidement à un mille feuilles où les performances et l'intégrité complète de la solution sont souvent sujet à caution.

Le nombre d'écrans de configuration devient aussi envahissant. Un développeur peut ne pas aimer du tout cette approche et lui préférera la programmation sous Drupal mais qui se heure à un manque de framework MVC / OOP . A contrario Seblod opère certes à un plus bas niveau mais la modélisation et l'unification des processus web dans Seblod permet un contrôle plus fin. Tout est ici modélisé avec des formulaires, des listes et des vues détail, c'est tout.

Séparation comportement du stockage d’un champ

Dans Seblod chaque champ est défini par son type (texte, boîte à boutons, liste déroulante, etc) mais aussi son stockage en base de données. C'est un atout majeur qui distingue le fond (le stockage en base) de la forme (l'interface du champ) et qui permet un contrôle plus fin de ce qu'on manipule.

Conclusion: pourquoi nous avons choisi Joomla!

Il ne peut y avoir de véritable conclusion à ce rapide tour d'horizon. Le but n'est pas de prouver que Joomla! est meilleur qu'une autre solution. Cela n'a aucun sens. Il s'agit plutôt de mettre en avant certains avantages pas toujours connus de Joomla! qui peut, dans de nombreux cas, et en particulier avec le CCK Seblod, répondre mieux à la réalisation de votre projet dans une tranche de projet moyen (20-50K). C'est cette caractéristique "couteau-suisse" du CMS Open Source qui permet de s'adapter à tous les besoins et tous les budgets.