Publié le

Ces deux derniers jours, je me suis fait poser deux questions fort intéressantes (et somme toute assez semblables) par deux dirigeants d’entreprises ayant chacune des équipes de programmeurs, et qui évaluent la pertinence d’utiliser Drupal dans certains projets.

  1. «D’après toi, pour notre équipe très habituée (et très performante) à développer et ré-utiliser ses propres solutions de gestion de contenu, serait-il plus pertinent d’aller vers Ruby on Rails ou Drupal?»
  2. «Pourquoi choisir Drupal plutôt que de bâtir directement les applications en PHP? Je comprends que Drupal fournit plein de fonctionnalités, mais PHP également, à travers de nombreuses bibliothèques.»

(Vous comprendrez qu’il s’agit ici de bibliothèques de fonctions logicielles et non de celles où l’on emprunte des livres.)

D’excellentes questions. Puisque je ne suis pas tout à fait certain d’y avoir parfaitement bien répondu, je vais tenter d’y réfléchir encore un peu ici. Je n’ai pas d’expérience pratique de Ruby on Rails, alors il est pour moi plus difficile d’en parler, mais j’ai tout de même l’impression que les deux questions sont proches.

Chose certaine, la réponse à ces questions dépend de la nature du projet à réaliser. Drupal est un logiciel, il fournit des fonctionnalités prêtes à l’emploi pour des non-programmeurs et, par conséquent, des manières de faire, un certain flux de travail. On peut l’enrichir et l’altérer grandement, bâtir des applications qui n’avaient jamais été envisagées par les concepteurs de Drupal, mais si l’on cherche à construire une application possédant un flux de travail complètement différent, ou si l’on effectue le design interactif de ladite application en ignorant la manière de faire de Drupal, on risque de connaître des difficultés. Dans ces deux situations, il pourrait être préférable de choisir un framework plus générique, pourquoi pas Rails ou Symfony?

Là où l’on tire le mieux profit de Drupal, c’est lorsque ses fonctions (ou celles de modules tiers) répondent out-of-the-box à une partie importante de nos besoins. Je suis tenté d’évoquer la classique règle des 80-20: Si Drupal, clé en main, avec des modules tiers, répond à 80% des besoins du projet, on pourra passer 80% du temps total à régler les 20% de personnalisation nécessaires et on aura déjà gagné beaucoup de temps. (Non vérifié scientifiquement!) D’autant plus que les premiers 80% de besoins comblés peuvent l’être par un bon architecte ou intégrateur, permettant aux programmeurs de s’attaquer à d’autres tâches en parallèle.

Un exemple concret

Sous Drupal, tous les contenus possèdent une structure de base commune appelée noeud. La plupart des fonctions de Drupal et de ses modules tiers font affaire avec cette structure commune. En d’autres mots, les modules partagent un langage commun. Un aspect souvent grisant de Drupal, c’est de découvrir ou d’imaginer de nouvelles façons de faire converser différents modules à travers ce langage, le tout sans écrire une seule ligne de code.

Prenons l’exemple d’un site événementiel où l’on souhaiterait décrire la programmation et des conférenciers. Conférences et conférenciers seront des noeuds, respectivement gérés par les modules Event (qui associe une date à un noeud et peut présenter les noeuds dans des calendriers) et CCK (qui permet de créer un noeud sur mesure, avec différents champs particuliers à la description d’un conférencier: nom, affiliation, photo, biographie, publications récentes, hyperlien vers un site web, etc.). Ces deux types de données sont des noeuds, donc je peux facilement les lier via le module Node Reference (fournit avec CCK), qui permet de connecter des noeuds entre eux. J’obtiens un lien de la fiche de conférence vers celle de son conférencier.

Avec Drupal, tout noeud est automatiquement disponible via RSS, au grand plaisir de visiteurs branchés et de sites agrégateurs, qui seront notifiés dès la publication de nouvelles conférences sur le fil de presse.

J’active les commentaires sur les noeuds, ainsi les visiteurs peuvent commenter les conférences et leurs conférenciers… À travers le module Fivestar, je leur permet de voter sur ces mêmes noeuds puis, avec le module Views, je présente dans la page d’accueil le top cinq des conférenciers les mieux cotés par les visiteurs. Views est ce module que je mentionnais récemment et qui peut produire des listes de noeuds suivant une multitude de critères.

J’adjoins le module Signup et les visiteurs peuvent désormais s’inscrire aux conférences et même recevoir automatiquement un rappel par courriel la veille de l’événement.

Voilà, en quelques heures et sans programmation mon projet a atteint ses objectifs, principalement grâce au fait que toutes les composantes ont une langue commune: le noeud. Le reste du temps sera consacré à la personnalisation, dont l’intégration d’un design graphique distinctif.

Avantage supplémentaire: En n’ayant pas écrit une seule ligne de code, je me trouve à bénéficier des entretiens du code et des mises à jour produits par la communauté Drupal. En d’autre mots, je ne prend pas sur mes épaules l’entretien complet du code, la communauté Drupal le fait! Et si par hasard j’ai rencontré quelques bogues ou fonctionnalités manquantes en construisant le système, j’ai vu à les régler puis à soumettre mes modifications aux équipes concernées sur drupal.org. Par cette petite contribution, je participe à solidifier mes modules préférés en vue de la conférence de l’année prochaine! C’est ainsi que tourne la roue du logiciel libre.

Bien sûr, l’exemple ci-dessus est un cas idéal: J’ai trouvé un module existant pour répondre à chacun des besoins. N’empêche que je prétend que Drupal, tel qu’il se présente actuellement avec ses modules tiers, pourrait être un support avantageux pour 80% des sites de la planète (ce qui ne signifie pas que les autres plateformes soient nécessairement mauvaises!)

Si on reprenait à présent le même exemple en PHP, au moyen de différentes bibliothèques… Je ne doute pas qu’on trouve d’excellentes bibliothèques PHP de calendriers, et même de plus jolis et plus complets que le module Event de Drupal. De même, on trouvera des outils pour manipuler facilement la base de données, gérer les sessions, l’envoi de courriels, la validation et le formatage HTML pour les contenus soumis par les visiteurs, le formatage XML pour les fils RSS, etc. Mais pour que toutes ces composantes se comprennent entre elles, on devra continuellement passer les données à la moulinette, les transformer par programmation au format attendu par l’interface de programmation de chacune. C’est là toute la différence!

Dans une application “normale”, on doit programmer ce genre de fil qui permettra à tous les morceaux de converser. On traduit les données dans la “langue” de chacun. Sous Drupal, la situation est inversée: Ce sont les modules qui se moulent aux structures de Drupal, au “langage” prôné par Drupal. Quand on écrit un nouveau module, on doit lui faire parler la “langue” Drupal. C’est sans doute ce qui cause le plus de difficultés aux programmeurs qui se lancent sous Drupal, mais comme toute langue, ça s’apprend. Et les bénéfices sont énormes. ;-)

Commentaires