Aujourd'hui, les sites web des collectivités sont conçus à plus de 90% depuis un CMS open source et parmi eux, Wordpress et Drupal sont très largement plébiscités.
Wordpress et Drupal sont arrivés il y a une vingtaine d'années, ils servent aujourd’hui de socles techniques à des millions de sites dans le monde. Mais au-delà de leurs spécificités communes, chaque solution se distingue par ses caractéristiques propres.
Pour ces deux CMS, 2022 a vu l’arrivée d’une nouvelle version majeure, Wordpress 6 en mai et Drupal 10 en décembre 2022. Aussi, en ce début d’année 2023, nous avons souhaité établir un comparatif (essentiellement technique et fonctionnel) de ces deux CMS que nous utilisons pour l’ensemble de nos projets clients.
Des points communs toujours d’actualité
Pour la charte graphique, les deux CMS offrent une grande liberté graphique et permettent la création de thèmes sur-mesure. En cas de changement de prestataire, la réversibilité est assez aisée car les deux CMS sont largement répandus au sein des collectivités.
Le langage de programmation et le système de gestion de base de données sont identiques (PHP et Mysql) mais Drupal accepte d’autres bases de données. Leurs composants sont facilement déployables sur n’importe quel serveur web.
Les deux CMS peuvent aussi répondre pleinement aux exigences du RGPD et de l'accessibilité mais c’est avant tout l’expertise du prestataire qui fera la différence au niveau du degré de conformité du site (notamment dans ses choix de modules/extensions et sa compétence à personnaliser le CMS)..
Les modules
La communauté Wordpress possède un plus grand nombre de modules/extensions que Drupal (module étant le terme côté drupal, extension côté wordpress).
Mais lorsqu’on commence à utiliser les extensions Wordpress, mieux vaut avoir sa carte bancaire à portée de main. En effet, parmi les modules essentiels ou à véritable valeur ajoutée de Wordpress, beaucoup réclament une licence annuelle payante. Là où l’ensemble des modules proposés sur Drupal.org sont gratuits ou parfois subventionnés par des entreprises.
Mais il y a aussi des avantages à payer des licences : support technique, nouveautés, fonctionnalités clés (formulaires, newsletter, référencement, etc..)... Et cette concurrence favorise l’amélioration des extensions.
Certaines extensions ont même leur propre store de plugins additionnels (gratuits ou payants) mais là encore l’addition peut vite grimper !
Wordpress est donc un CMS gratuit mais avec des coûts cachés si l’on souhaite vraiment l’utiliser de façon professionnelle.
Côté Drupal, la carte bancaire peut rester dans le porte-monnaie. Et si le choix des modules est moins important que pour Wordpress, la qualité est très souvent au rendez-vous.
Prenons l’exemple des formulaires qui est un besoin impérieux pour toutes les collectivités (notamment pour la création sur mesure de démarches).
Drupal propose webform, avec un usage de pratiquement 400 000 sites web, un socle fonctionnel impressionnant et une communauté de modules complémentaires, le tout gratuitement et maintenu.
De son côté, Wordpress propose à périmètre fonctionnel équivalent Wp Forms, Forminator, Ninja Forms, Gravity Forms…
Tous incluent une version payante pour avoir accès à tout le panel de fonctionnalités, avec la promesse d’être meilleur que le voisin et avec une ergonomie différente les uns des autres. C’est un peu la jungle pour qui veut tester avant de choisir sereinement le module le plus adapté à son besoin (J'ai personnellement dû tester six modules avant d’orienter notre choix pour Gravity Forms).
Trouver un module est plus simple dans le store de Drupal car la communauté fait souvent le choix de créer un seul module phare par fonctionnalité (dès lors qu’il est utilisé par un nombre suffisant de sites).
Nous ne traiterons pas de la partie thème, car pour les deux CMS nous ne partons jamais d’un thème mais bien d’une charte graphique que nous réalisons et qui respecte les différents standards du web ainsi que la réglementation.
Malgré son côté fourre-tout, le store de Wordpress peut se révéler plus intéressant car on trouvera plus de choses que sur Drupal mais avec un inconvénient de taille, les coûts cachés !
L’éditeur de texte
C’est l’outil principal du webmaster dans son quotidien, il lui permet de rédiger les contenus. L’éditeur de texte est donc un point important dans le choix du CMS.
Drupal s’appuie depuis sa version 8 sur CK Editor. Autrefois il était même installé sans éditeur de texte, on pouvait ainsi choisir l’éditeur de son choix, chose toujours possible d’ailleurs sur Drupal 8 et plus.
Avec la version 10, Drupal embarque le tout nouveau CKEditor 5 qui améliore l’ergonomie générale de CKEditor (éditeur présent sur le web depuis 19 ans).
De son côté, Wordpress utilise depuis sa version 5 son éditeur Gutenberg qui a révolutionné l’ergonomie du back office de Wordpress. Sur le fond, les fonctionnalités sont similaires à CKEditor, sauf que dans la forme, elles offrent une expérience d’écriture mieux pensée.
Citons quelques points sur lesquels il devance Drupal.
Une médiathèque bien plus aboutie et présente nativement, un téléchargement plus aisé des images et de vidéos en masse et la création de galeries photos. Et une fois insérée dans la page, l’image bénéficie encore d’une flopée d'options.
Wordpress intègre également un plan de la page qui permet de se repérer rapidement dans le contenu, on peut transformer un paragraphe en colonne et inversement (pour quelqu’un qui a l’habitude d’utiliser Word ou Libreoffice, la prise en main sera beaucoup plus facile).
Étendre les capacités des deux éditeurs est possible.
Drupal s’appuiera sur le module Paragraphs, véritable usine à blocs, il permet de tout faire, reprise de contenus, requête, bloc complexe, c’est un véritable couteau suisse qui s’appuie sur les capacités techniques de Drupal.
Côté Wordpress, développer un bloc Gutenberg demande beaucoup plus de travail, il est à noter cependant que la communauté livre aussi de jolis blocs prêt à l’emploi, et que le module ACF Pro (sous licence payante) permet l’équivalent de Paragraphs en créant le back office des blocs sans compétence technique. Ce dernier offre même une expérience utilisateur plus intéressante que Paragraphs. Wordpress n’a donc pas à rougir sur ce point.
Sur l’éditeur de texte, Wordpress remporte largement le match car il permet de réaliser plus de choses et de façon plus rapide.
La sécurité
Les chiffres sont là !
Source: https://sucuri.net/reports/2021-hacked-website-report/
Selon sucuri, 95% des sites sous CMS infectés en 2021 étaient des Wordpress contre moins d’ 1% pour Drupal.
Mais Wordpress représente plus de 40% des sites web à travers le monde, il est donc logique pour les hackers de le cibler en priorité. Et Wordpress, de part sa facilité de prise en main, est davantage utilisé par des développeurs peu expérimentés voire des non développeurs, ce qui entraîne des comportements à risque.
Mais le fondement même de Wordpress, plus permissif, le rend moins sécurisé que Drupal.
Nous ne dirons pas que le noyau de Wordpress est un nid à failles, loin de là car tout comme Drupal, Wordpress dispose d’une équipe dédiée à la sécurité et des bounty hunters qui recherchent des bogues. En soi, ce qui rend Wordpress plus fragile que Drupal, c’est l’absence de réel Framework de développement.
Drupal s’appuie sur le framework Symfony et le langage de templating Twig, tous deux sont un gage de qualité en matière de sécurité.
Là encore, prenons un exemple concret.
Je dois créer un formulaire personnalisé pour mon client qui nécessite plusieurs champs texte et un champ fichier.
Sous Drupal, j’aurai la form API qui va me permettre de demander l’affichage de mes champs, la sécurité de ces derniers (au moment de l’affichage et de la récupération des valeurs) est automatiquement assurée d’une part par des composants éprouvés dans le noyau de Drupal, et d’autre part par twig qui nativement sécurise les variables dynamiques envoyées au navigateur en les échappant.
Sous Wordpress, je suis libre de rédiger mon formulaire et son traitement en html/php comme je l’entends, il n’y a pas à proprement parler de boîte à outils prête à l’emploi. Il est donc plus facile sur du code personnalisé créé par une agence de trouver des failles XSS ou pire.
D’ailleurs comme il n’y a pas de réel modèle de champ, il est aussi plus facile de retrouver des formulaires non accessibles où le développeur oublierait des basiques comme un libellé, des messages d’erreurs explicites, etc..
Côté extensions, c’est le même discours, si on ne les sélectionne pas rigoureusement, des failles peuvent vite pointer le bout de leur nez.
Drupal remporte donc le match de la sécurité grâce à son appui sur Symfony et sa popularité moins importante que Wordpress.
La création des gabarits de page
Envie d’une page événements, d'offres d’emploi ou d’un trombinoscope des élus ?
Sous Wordpress tout comme sous Drupal, il est nativement possible de créer autant de gabarits de page que nécessaire. Le moteur de champs de base de Wordpress ne permet cependant que d’ajouter des champs texte ! Il faudra par conséquent vous appuyer sur une extension comme ACF pour obtenir des champs de différents types (version payante).
Avec Drupal, la capacité d’étendre un gabarit avec des champs supplémentaires fait partie intégrante du CMS. La communauté propose par ailleurs beaucoup de modules pour ajouter des types de champs non fournis nativement.
On retrouve donc un résultat très similaire quelque soit le CMS mais avantage à Drupal car il ne demande aucun coût caché pour un même résultat.
Les développements sur-mesure
Source: https://enoxone.ch/drupal-vs-wordpress-le-vrai-cout-dun-site-web/
A nouveau, Drupal va se démarquer de Wordpress par son appui sur Symfony et les nombreuses API développées depuis Drupal 8.
Réaliser un back office sous Wordpress demande beaucoup plus de temps que sur Drupal.
Cela se ressent d’ailleurs beaucoup sur les extensions Wordpress car aucune ne se ressemble, tout le monde fait “à sa sauce”.
Côté Drupal, l’ensemble des composants du noyau sont mis à disposition du développeur, ce qui permet de développer rapidement des backs office très proches de ceux fournis de base. C’est aussi un apprentissage plus facile pour les clients car ils conservent les mêmes composants.
Si Drupal est déjà bien en avance sur le sujet, il enterre définitivement Wordpress sur la gestion des listes avec filtres (vous savez ce fameux agenda paginé avec plein de filtres…)
Et bien sous Drupal, views, inclus de base, permet de réaliser ce type de liste, au clic le développeur sélectionne les filtres qui seront mis à disposition de vos usagers, le nombre de résultats et bien d’autres choses pour se concentrer sur le front Office.
De même, s'il faut s’interconnecter avec un système d’information, Drupal permet via son système d’entité de configuration/de contenu de réaliser facilement des jonctions avec le CMS. Il s’appuie également sur Composer qui permet d’utiliser n’importe quelle librairie php au monde en respectant vos modules déjà en place ainsi que la version de PHP et les contraintes serveurs. Si Wordpress peut également utiliser Composer, ce n’est pas quelque chose de natif.
Un dernier point et pas des moindres.
La livraison des fonctionnalités entre le moment où l’évolution est sur le site de développement et celui où elle doit atterrir sur le site de production.
Sur Drupal on peut réaliser un export de la configuration complète de la base de données, et importer ensuite les changements d’une base à une autre (que l’on soit sur des changements sur un module créé sur mesure ou sur un module de la communauté).
Sur Wordpress ce n’est hélas pas le cas, hormis certains modules qui permettent un import/export de leur configuration, il faut parfois s’armer d’une documentation avec les manipulations à effectuer ou coder un script pour reproduire l’action, ce qui représente une charge de développement non négligeable.
Drupal remporte sans mal le match des développements sur-mesure.
Le multilinguisme
Toutes les collectivités n’ont pas besoin du multilinguisme, par contre lorsqu’on est une ville touristique ou un office de tourisme, il peut vite devenir utile.
Sur Wordpress, le multilinguisme n’est pas vraiment de base, il faut installer une extension type WPML (là encore payante…), puis en fonction des autres modules utilisés, il faut télécharger et installer aussi des mini extensions pour combler l’absence de multilinguisme
Drupal jusqu’à sa version 7 était dans le même cas de figure, pas réellement natif on devait là aussi dégainer une armée de modules pour traduire son site et adapter son code. Avec Drupal 8, les développeurs de Drupal ont rendu natif le multilinguisme.
On configure les langues dont on a besoin, on choisit quel champ sera traduisible, l’interface ne change pas beaucoup ni pour le webmaster (hormis des boutons de traduction), ni pour le développeur.
Si vous souhaitez traduire vous même votre site en plusieurs langues ou avoir des arborescences différentes par langue, Drupal est clairement gagnant. Avec Wordpress le multilinguisme n’est pas natif et il peut même complexifier la maintenance du site.
Si toutefois une traduction automatique suffit, les deux CMS sont équivalents, on installe alors une bibliothèque comme Google Translate et on ne soucie pas d’installer un multilinguisme.
Conclusion
Après lecture de notre comparatif, vous aurez certainement compris que contrairement à pas mal d’idées reçues, Wordpress n’est pas le champion toutes catégories des CMS open source.
Et si vous devez faire un choix entre Drupal et Wordpress, prenez d’abord bien en compte vos besoins.
Si vous souhaitez avant tout un outil simple et rapide d’administration, optez pour Wordpress.
Par contre, si votre site doit s’interconnecter avec des logiciels métiers ou que votre projet nécessite des développements sur mesure ou que vous avez un besoin accru de sécurité ou de multilinguisme, Drupal répondra davantage à vos besoins.
Pour la réalisation d’un écosystème numérique global (site internet, intranet, usine à sites…), les deux CMS sauront répondre présent avec bien entendu des atouts différents pour chacun d’entre eux.
Cet article a été intégralement rédigé par Telmedia.