Drupal : LE CMS pour les professionnels ?

Lorsque l'on entend le terme de CMS, on ne pense pas immédiatement au monde professionnel. On pense plutôt à un outil destiné au grand public, permettant de créer un site web. Pourtant les CMSs ont bien évolué depuis leur apparition, il y a une vingtaine d'années !

Au départ, l'idée des CMSs était de s'adresser à un public non technique et de leurs fournir des outils permettant de créer des sites internet sans avoir à connaitre les techniques sous-jacentes (HTML et CSS principalement). Sans un CMS, cela était très fastidieux car il fallait écrire pas mal de code, à la fois pour le front (interface visible des internautes) et pour le back (partie fonctionnelle).

En quoi Drupal a t-il changé ?

Aujourd'hui, les besoins des sites/applications ont beaucoup évolué : on est passé de la publication de contenus type article façon blog, à des systèmes complexes de gestion d'entreprise, type intranet/extranet. Il est compliqué de rester à la fois simple pour cibler le grand public et de fournir de la flexibilité pour les besoins les plus avancés. Drupal a clairement franchi le pas en privilégiant une approche offrant des fonctionnalités avancées, au détriment d'une certaine simplicité.

Ce changement stratégique a été fait avec la sortie de la version 8 en novembre 2015. Drupal 7 et Drupal 8 sont à bien des égards des systèmes très différents. Même si leurs prises en main semblent assez similaires, sous le capot les choses sont bien différentes, à tel point qu'une partie de la communauté a voulu conservé l'approche de la version 7 en créant un fork : Backdrop CMS.

Drupal, une boite à outils avancée

L'ADN de Drupal est de proposer des outils puissants en terme d'architecture de contenus, de publication, d'intégration dans un SI... mais encore faut-il les prendre en main et comprendre leur utilisation/configuration. C'est un peu comme si on entrait dans le cockpit d'un avion : tout est là pour le faire décoller mais une formation au pilotage est nécessaire !

Par exemple, en terme d'architecture de données, on dispose de beaucoup d'outils : les contenus (noeuds), les médias, la taxonomie, les commentaires, les fichiers statiques, mais aussi les paragraphes, les comptes utilisateurs, les groupes, les blocs... C'est ensuite à vous d'en faire quelque chose par rapport à des contraintes données.

Si vous confiez le même cahier des charges à trois agences différentes, vous aurez trois architectures différentes; certains vont privilégier les modules contrib, tandis que d'autre vont s'orienter davantage vers du développement custom. En plus, de l'aspect purement fonctionnel, il faut tenir compte de la partie contribution, qui oriente forcément vers certains choix pliutôt que d'autres.

Internet est de plus en plus complexe, et Drupal suit cette tendance en proposant toujours plus de fonctionnalités.

Pourquoi Drupal est-il complexe ?

Un système flexible et adaptable est bien souvent aussi complexe. Il est difficile de proposer toutes sortes de fonctionnalités et de rester simple en même temps. Drupal fait clairement le choix de la flexibilité. On pourrait dire qu'il est capable de faire presque tout, mais demande beaucoup de temps en configuration et développement. Avec Drupal, rien n'est jamais simple :( mais tout est possible :)

La complexité de ce système provient des choix technologiques qui ont été fait. Par exemple, plutôt que d'avoir à créer tout le code source nécessaire, le système repose sur des librairies PHP et JS externes. C'est évidemment une bonne idée de ne pas à avoir à refaire la roue, mais cela ne rend pas son utilisation plus simple. Avant même de pouvoir installer Drupal, il est nécessaire de récupérer tout le code externe nécessaire et donc d'utiliser Composer. Pour un novice sans connaissances techniques, c'est un obstacle de taille ! On écarte de fait tous les allergiques à la ligne de commande. Le problème est le même lorsque l'on veut installer un nouveau module : il devient impossible de simplement télécharger le code de ce dernier et de le placer manuellement dans le dossier prévu à cet effet.

On est donc plus en face d'un framework que d'un CMS. En réalité, Drupal est vraiment hybride car il peut être approché depuis ces 2 angles CMS et framework. Pour en tirer le meilleur parti, il est indispensable d'en maitriser les 2 approches.

Site-building vs développement

Lorsque l'on utilise un CMS, on est amené à installer des plugins (ou module, extension, add-on...) afin d'obtenir certaines fonctionnalité non proposées par le coeur du système. Cela permet de gagner du temps à la fois lors du développement d'un site mais aussi lors de sa maintenance.

Ainsi dès que l'on a besoin d'une fonctionnalité non proposée par le coeur, on a toutes les chances de trouver un module adéquat. Il y a plus de 9000 modules disponibles pour la version 9 de Drupal. Si aucun module ne fait l'affaire, alors il faut se lancer dans un développement maison. Cela prendra évidement plus de temps...

Maintenant lorsque l'on utilise un module contrib, il faut quand même se poser la question de son utilité par rapport aux fonctionnalités qu'il propose. Par exemple, si l'on a besoin d'avoir un type de contenu privé, tandis que les autres sont publics, on trouve différents modules pour ce faire. Cependant, il est sans doute plus judicieux de créer un module custom, ne couvrant que ce besoin, plutôt que d'installer un module hyper générique proposant différentes fonctionnalités inutiles dans notre cas.

La décision d'utiliser un module contrib plutôt qu'un module custom n'est pas toujours évidente : cela nécessite, encore une fois, de l'expérience. De plus les habitudes de chacun jouent également : un développeur PHP a tendance à vouloir coder, tandis qu'un site-builder privilégie davantage l'interface de Drupal et donc les modules contrib.

Et après ?

Drupal a atteint depuis quelques années une certaine maturité fonctionnelle : le coeur propose les fonctionnalités essentielles (structure de données hyper flexible, gestion des utilisateurs, workflow de publication, API ready...). Cependant, pour se démarquer des autres CMSs, il est nécessaire de proposer des nouveautés/innovations. Par exemple, le module Workspaces constitue une véritable avancée en proposant des versions éditoriales du site dans son intégralité. Ainsi on peut préparer une nouvelle version d'un site proposant de nouveaux contenus et publier cette version à une date fixée à l'avance. Notons que pour le moment ce module est encore expérimental.

Afin de gagner du temps lors de la configuration d'un site, il faudrait avoir des briques fonctionnelles prêtes à l'emploi. Par exemple, pour un site de e-commerce, on dispose de tous les outils nécessaires, mais leur configuration est très longue. Il faudrait avoir une sorte de package (ensemble de modules) à installer avec un formulaire de paramètrage permettant de mettre en place la boutique, les produits, les devises, les moyens de paiement...  Cela est différent des profiles d'installation car ces derniers n'interviennent que lors de l'installation initiale du site. Il faudrait maintenant pouvoir ajouter des briques fonctionnelles à postériori.

Par ailleurs, comme expliqué précédemment, Composer est obligatoire avec Drupal 9, mais son utilisation est loin d'être facile. La possibilité de faire n'importe quelle mise à jour ou ajout de modules/thèmes via le back-office, va dans le bon sens. Ce n'est pas encore possible, mais ce serait une avancée considérable pour faciliter l'utilisation de Drupal à des non-développeurs.

Finalement l'approche low/no code qui se développe actuellement n'est pas vraiment nouvelle ! C'est le but premier d'un CMS comme Drupal. Il faut simplement que cela redevienne une priorité pour la communauté Drupal.