Je vais donc tenter dans ce post de résumer les raisons objectives pour lesquelles je n'accepte plus de travailler sur des projets basés sur cet environnement. Bien sûr la liste n'est pas exhaustive, mais les problèmes qu'elle pointe sont tels qu'il ne devrait pas être nécessaire d'en ajouter plus. Ces observations sont issues de l'expérience, et dénoncent des défauts qui handicapent réellement les projets. Il faut les prendre pour ce qu'ils sont, à savoir une mise en garde.
Voici donc les reproches que je peux adresser à Drupal, même si encore une fois ils pourraient s'appliquer à l'essentiel des autres CMS disponibles à l'heure actuelle :
- L'approche procédurale
Les CMS s'adressent principalement à un public de non-développeurs ; autrement dit, au grand public. Celui-ci ayant quasi systématiquement recours aux hébergements mutualisés, lesquels ont très longtemps (et continuent pour certains !) imposé PHP4 à leurs clients, les CMS ont dû se plier à cette contrainte et maintenir une compatibilité totale avec cette version désormais obsolète de PHP, sur laquelle beaucoup ont en plus été conçus, sans que leur design initial n'ait jamais été remis en cause.
Ceci semble avoir parfaitement satisfait les développeurs de Drupal (ainsi que ceux de sa communauté), qui sont dans l'ensemble très fâchés avec le développement objet. Songez que l'un des seuls objets core de Drupal est le node (concept absolument central de Drupal), qui n'est autre qu'une bête StdClass !
Je suis même tombé (merci Alex !) sur un article d'un évangéliste Drupal qui nous explique avec le plus grand sérieux que l'absence de classes dans le design de Drupal est un choix délibéré, mais que cela n'empêche pas Drupal d'appliquer la majorité des concepts du paradigme objet. Encore plus savoureux, il nous est exposé la thèse suivante : en se gardant d'utiliser les objets, il a été possible aux développeurs Drupal d'implémenter des concepts "encore plus objet" que ce que permet le moteur orienté objet de PHP ! Ca me fait penser à ceux des artistes contemporains qui mettent trente secondes à créer une "oeuvre", puis des années à en théoriser le concept, mais c'est une autre histoire... Bref, pour consulter ce chef-d'oeuvre de mauvaise foi, c'est par là !
Nous pouvons donc constater que ces développeurs sont adeptes de ce que PHP a de plus médiocre à offrir, du fait d'une utilisation sans discernement de sa permissivité, au mépris de toute bonne pratique. Je pense ici notamment à ces fameuses variables globales, à commencer par $user (dont je vous laisse deviner ce qu'elle matérialise...), ainsi qu'au recours à eval(), le honni (encore présent dans Drupal 7, j'ai vérifié) !
On se retrouve donc confronté à une base de code foisonnant de fonctions par milliers, très fermement couplées entre elles (puisqu'impossibles à redéfinir, naturellement), limitant de fait les personnalisations possibles. Ceci à conduit à la mise au point dans Drupal d'un système de module qui a paradoxalement fait sa renommée. Mais j'y reviendrai dans le point suivant.
- Une modularité très discutable Drupal offre à ses utilisateurs un aréopage de modules hétéroclites, et surtout très souvent en conflit les uns avec les autres. S'il est juste de dire que des modules existent pour couvrir fonctionnellement de très nombreux besoins concrets, il faut toutefois relativiser la soit disant valeur-ajoutée de cette manne :
- le foisonnement en est tel qu'il est souvent long et difficile de sélectionner le plus approprié (étrangement, la communauté préfère réaliser deux modules disposant chacun de 3 fonctionnalités plutôt qu'un seul doté des 6...)
- cette vilaine manie qu'ont les développeurs de recourir aux patches pour appliquer leurs modules vous amène très vite à casser toute compatibilité descendante avec les futures versions du CMS, ainsi qu'avec certains autres modules.
- le recours à l'appel "à l'aveugle" de fonctions via call_user_func(), dans le contexte du mécanisme de hooks, est une plaie du point de vue des performances d'une part (au moins jusqu'à PHP 5.3, dont je ne suis pas certain de la compatibilité avec Drupal par ailleurs), mais aussi et surtout pour la compréhension du flux d'exécution ! C'est bien simple, on n'y comprend rien (point de vue confirmé par d'honnêtes Drupal fan boys...)
- Un emploi déraisonnable de la base de données
Dans Drupal, tout ou presque se passe dans la base de données. Outre que ceci est parfaitement imbécile là encore du point de vue des performances (j'ai souvent vu des pages de sites Drupal nécessiter de 400 à 1000 requêtes SQL pour être générées, le cache n'arrangeant que peu les choses, sans compter les modules qui parfois produisent des requêtes de plusieurs dizaines de secondes), c'est absolument cataclysmique pour les tests (unitaires ou pas), la gestion des versions et des mises en production.
En effet, les modifications que l'on apporte à un projet sous Drupal sont partagées entre le code et la base de données. Autrement dit, pour tester ce que l'on a fait localement sur un serveur de recette par exemple, il faut synchroniser les bases de données, ce qui n'est pas chose aisée. Bien sûr, cela sera également nécessaire pour que les autres collaborateurs du projet puissent appliquer vos modifications sur leurs environnements locaux. Et une fois de plus sur la production. Et procéder à l'opération inverse pour revenir en arrière, le tout en parfait accord avec le versionning SVN/GIT. Mission quasi impossible.
Moralité, les développeurs travaillent sur des versions qui ne sont pas identiques, ce qui se révèle être une source intarissable de bugs les plus idiots qui soient.
Conclusion
J'en aurais encore beaucoup à dire sur le sujet, mais je préfère partir du principe que si nous ne sommes pas d'accord à ce stade, nous ne le serons jamais, et inversement !Je finirai donc en rappelant simplement une fois de plus que les CMS sont conçus uniquement pour un public de non-développeurs, et qu'il ne faut pas y recourir si l'on à la moindre velléité de personnalisation (essayer d'intégrer un véritable workflow à Drupal, on en reparlera...).
Dans le cas contraire, c'est-à-dire dans tous les projets que l'on peut avoir à gérer dans un contexte professionnel (hors "web agencies de quartier" s'entend), ces CMS sont à proscrire. Ils ne sont pas faits pour vous, même si le succès rencontré auprès d'une foule d'amateurs et de quelques professionnels désoeuvrés leur a laissé croire le contraire.
Pour un développement sur la base d'un cahier des charges précis, utilisez des frameworks, c'est-à-dire des environnements maîtrisés de bout en bout, lesquels vous fourniront le cadre nécessaire pour écrire un code métier efficace et maintenable, les outils nécessaires à la mise en place d'un véritable cycle de développement, plutôt que l'illusion de vous fournir un code métier "clés en main" (ce qui est, convenons-en, proprement absurde !).