Logo DRUPAL
Voici ci-après quelques explications, certes un peu techniques, largement inspirées du site de Gauthier Delamarre et confirmées par l’équipe des développeurs de l’agence 2S3i, qui peut-être feront réagir certains internautes, au premier rang desquels les développeurs, les utilisateurs de DRUPAL et autres CMS1 (WordPress, Joomla, SPIP, etc.), et autres « professionnels du web » :
1. L’approche procédurale
Le fait est que DRUPAL tourne le dos à Php5 et reste dépendant de Php4 ! Or cette version de Php n’est plus maintenue à ce jour. Elle est plus lente que la version 5 et de nombreux bugs de sécurités subsistes. Les normes de développement avec ce langage sont absentes, le typage de données est absent. En conséquence , tous les avantages en terme de développement offert par la programmation objet de haut niveau (offert par des langages comme Java, C++, Python, PHP5) sont absents. Dit plus schématiquement et de façon caricaturale, Php4, pousse à un développement brouillon, sans hiérarchie de fonctions, et ne permet en aucun cas la mise en place des bonnes pratiques de programmation reconnus et utilisés en milieu professionnel. Qui plus est, qui dit version non maintenue, dit version avec des bugs de sécurités non résolus. A l’heure où la communauté php à déclarer ne plus maintenir la branche 5.2 du langage, où la branche 5.3 apporte de nombreuse améliorations en terme de performance (gestion optimisée du « garbage collector » pour la mémoire), en terme de programmation orientée objet avec l’ajout des espaces de nom et des « closures », Drupal se contente toujours d’utiliser la branche dépréciée 4.x de php.
2. Modularité très discutable
Au niveau des utilisateurs voulant ajouter de nouvelles fonctionnalités via des modules externes : communauté non concise, tout le monde fait dans son coin sans se parler, résultat on se retrouve avec des milliers de modules sans savoir lequel choisir car la plupart sont incomplets ou plus maintenus. Vu que le développement de drupal est brouillon (cf. paragraphe ci-avant) , les développeurs de modules sont obligés de modifier le cœur même de drupal pour installer leur module donc :
- une fois le cœur de DRUPAL modifié, il est possible que les autres modules ne fonctionnent plus
- impossible de mettre à jour la version de drupal si un correctif suite à un bug de sécurité apparait
3. Un suivi de mise à jour complexe
Chaque nouvelle version majeure de Drupal apporte son lot de nouveauté mais aussi son lot de nouvelles incompatibilités. Ainsi un site développé sur la branche 5.x de Drupal, ne pourra pas être mise à jour vers la branche 6.x de Drupal sans devoir revoir l’ensemble des développements initiaux. De plus les versions antérieures ne sont rapidement plus maintenues par la communauté, les bugs de sécurités restants ne sont pas corrigé, ce qui oblige de prévoir le passage à la branche actuelle pour maintenir un site viable en production. Qui plus est rien ne dit que les modules développés par la communautés seront migrés, donc le site peut perdre en fonctionnalité lors d’une migration. La maintenance est donc longue et couteuse en journée / homme. Sachant qu’une nouvelle version majeure de Drupal sort environ tous les 12 / 16 mois, il faut répéter cette phase de maintenance couteuse régulièrement.
4. Un emploi démesuré de la base de données
46 tables pour une installation classique de Drupal 6.x. L’ensemble des paramètres de configuration sont partagés entre des fichiers de configuration et la base de données ce qui rend le développement d’un site sous Drupal et sa phase de déploiement sur serveur hardue : sans protocole de système de déploiement avancé pour modifier les paramètres lors de l’installation, la mise en place d’un site sous Drupal sur un nouvel environnement devient vite un casse tête. De plus la base de données est utilisée à outrance sur chaque page générant parfois prêt de 500 requêtes seulement pour afficher une page de contenue. Donc sans système de cache avancé (reverse proxy, serveur memcache, varnish proxy), le site sera extrèmement goumand en ressource CPU et mémoire, et aura du mal à tenir la charge. Le cas « france.fr » en est le parfait exemple : un site développé sous Drupal sans stratégie de cache optimisé, installé sur 12 serveurs frontaux n’a pas pu tenir la charge suite à un pic de fréquention de 16 000 visites. Pour comparaison, un site développé à partir d’un framework optimisé pour les sites à fortes charges, peut tenir la charge sur des pics de 20 000 visites sur un seul frontaux avec un serveur HTTP léger tel que Nginx.
5. Un coût de développement prohibitif
Il est rare vouloir mettre en place un site se contentent uniquement des fonctionnalités de base proposé par un CMS. Un client à vite des besoins additionnelles, et il faut donc régulièrement casser le fonctionnement normal du CMS pour pouvoir étendre ces fonctionnalités. Avec un CMS il est donc de pratique courante de tout déconstruire pour pouvoir arriver à construire son projet. Cela provoque donc une perte de temps significative et des problèmes de maintenances du cœur du CMS. Un développement à partir d’un framework professionnel, permet quand à lui de partir sur une base vierge, et laisse toute latitude aux équipes techniques pour répondre aux besoins du client sans perdre de temps.
Conclusion : vous l’aurez compris, DRUPAL n’est pas la panacée. Mais alors, au final, faut-il faire le choix d’un autre CMS ? N’existe-il pas une solution alternative crédible… début de réponse !
1 Un système de gestion de contenu (ou Content Management System ou CMS) est une famille de logiciels destinés à la conception et à la mise à jour dynamique de site web ou d’application multimédia (source Wikipedia => http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_de_contenu)
Bonjour,
pas vraiment d’accord avec ce que dit l’article ! Juste pour info : drupal est compatible PHP5 sans aucun soucis … en php 5.3 on a des « deprecated » mais pas de soucis… il travaillent et il va bientot etre compatible 5.3 qui oui ajoute des fonctionnalité avancé pour la programmation… objet? ah mince drupal est procédural, alors… pas de soucis
Drupal est procédural depuis son existance, je pense que le « cout » pour réécrire drupal en objet est phénoménal, et comme le dit l’article
http://www.freeblogware.org/2010/06/pourquoi-je-deteste-drupal-et-la.html
drupal a un peu « réinventé » le modele objet avec les fonctions « dynamiques »
Le nombre de requete par page peux facilement etre largement diminué avec les mécanisme de cache propre à Drupal …
Le passage de drupal 5 à 6 a peut etre été un peu hardu, mais la compatibilité de 6 à 7 est mieux géré de plus, on a maintenant de nombreux modules « core » qui eux fournissent nativement les possibilité de monter en version.
La difficulté est de bien choisir les modules, de ne pas prendre des modules peu maintenus…
j’attend vos réactions…
« un seul frontaux » ?
Comme quoi les trucs à la mode ne sont pas forcément les meilleurs techniquement
Cet article regorge d’erreurs et vous avez en effet raison de ne pas choisir drupal vu la méconnaissance de l’outil. J’espère que c’est un troll délibéré tellement il est bien velu et malheureusement je ne peux m’empêcher de répondre.
Drupal supporte php4 mais cela fait longtemps que la communauté et l’outil fonctionne avec php5, le support de php4 était un choix réaliste vu le nombre d’hebergeur qui ont mis du temps à passer à PHP5. http://drupal.org/gophp5
« Don’t hack the core » voici la devise des drupaliens donc quand je lis « les développeurs de modules sont obligés de modifier le cœur même de drupal pour installer leur module. » je ne peux que me dire que nous ne travaillons pas avec les mêmes développeurs.
Drupal est fait de manière à ne pas avoir besoin de modifier son code source pour faire des modifications diverses et variés. Si une personne le fait c’est qu’elle ne connait pas Drupal.
Concernant les mises à jours majeur drupal propose une chemin de migration, certes ne c’est pas toujours trivial surtout dans le cas où ils y a bcp de code custom et en particulier s’il est mal écrit. Mais cela est pris en compte et devrait être amélioré entre D6 et D7.
Allons demander à la communauté Symfony comment ils vont passer de la v1 à la v2.
Pour info sur les cycles de durée de vie :
D5 : January 15, 2007 (http://drupal.org/drupal-5.0)
D6 : February 13, 2008 (http://drupal.org/drupal-6.0)
D7 : pas encore sortie soit plus de 2ans
La communauté a appris de ses erreurs suite à la sortie rapide de Drupal 6 et soigne maintenant le processus de migration autant du core que des modules contrib (voir opération #D7CX qui vise à avoir un max de modules contrib prêt pour la sortie de D7).
Pour le reste le cas france.fr a déjà été discuté un peu partout, ils est clairement pas normal que drupal n’est pas réussi à fonctionner dans un cas pareil, le problème doit venir d’ailleurs, je vous laisse chercher sur la toile les divers articles à ce sujet.
En tout cas ce post m’a tout l’air d’un bon gros coup de pub profitant de la médiation soudaine de drupal par chez nous.
Bravo c’est réussi.
Bonsoir,
je ne peux pas m’empêcher moi non-plus d’ajouter mon grain de sel, même si je réfute le qualificatif de troll associé à ce débat. Pour ma part, je considère qu’un troll est un débat sans fin qui n’oppose que des partis pris. En l’espèce, il s’agit de constats argumentés. Et j’ajouterai, pour ce qui me concerne, d’une véritable préoccupation concernant l’avenir de mon métier.
Sinon, ce qui m’a fait particulièrement réagir, c’est cette sentence de Guillaume :
« Drupal est fait de manière à ne pas avoir besoin de modifier son code source pour faire des modifications diverses et variés. Si une personne le fait c’est qu’elle ne connait pas Drupal. »
Je voudrais corriger la conclusion, en disant que dans certains cas, si un développeur choisi de modifier des sources de Drupal, c’est parce qu’il ne lui était pas possible de faire autrement, sauf à renoncer à la fonctionnalité qu’il était en charge d’implémenter. Et voici précisément ce que je n’accepte pas : devoir dire à mes clients « désolé, on ne peut pas faire ça, parce que Drupal ne le supporte pas ».
Alors je veux bien imaginer que l’on puisse accepter cette contrainte, mais ce n’est pas mon cas. En tant que développeurs/architectes, on doit réaliser ce dont les clients ont besoin. Quoi que ce soit. Seul PHP peut être la limite, pas le CMS ni le framework.
Et au passage, merci pour les crédits, ça fait plaisir d’être repris mais pas pillé
« et ne permet en aucun cas la mise en place des bonnes pratiques de programmation reconnus et utilisés en milieu professionnel »
En gros si c’est pas programmé en POO c’est pas une application sérieuse ?
Ca sent le discours d’un « Pro POO », anti procédural…
Un développement sérieux entraîne une analyse sérieuse qui doit définir le mode de développement POO ou Procédural.
Un site web, ou une autre application en PHP, ne doit pas être forcément être écrite en POO.
Un code procédural bien fait est souvent plus efficace et plus rapide (tant en écriture qu’en exécution) qu’un code en POO !
L’article est en effet un peu sévère. Mais j’ai refusé un emploi à cause de leur emploi (seul outil) de Drupal. Drupal, pour un utilisateur final, où éventuellement quelques améliorations sont à founir, est certainement un bon choix, au même titre que Joomla! ou d’autres CMS/CMF. Toutefois, si un lourd développement est à prévoir, cela peut être problématique. L’emploi du procédural est plus rapide à executer (on en a peut-être jamais douté), mais l’objet est un petit investissement qui rend le développement et la maintenance plus facile et rapide par la suite. C’est surtout la logique qu’elle fournit qui est un atout à mon sens, en dehors de toute fonctionnalité utilisateur (l’objet même du développement finalement). Je serais ravi un jour de pouvoir utiliser Math::round() plutôt que round(). Je travaille sans cesse sur mes bonnes méthodes de programmation, sans forcément me dire « Java c’est le meilleur exemple, c’est le boss », mais il faut avouer que les design pattern (le décorateur par exemple), couplé avec l’objet offre un développement presque instinctif. Si je dois me dire que je dois nommer mes fonctions de la manière x pour définir leur rôle, je trouve ça problématique. Je n’ose même pas imaginer la réaction d’un IDE avec l’auto-complétition en tapant « drupal_ » : un tas de fonctions ! Taper Array. pour un langage objet « normal » est un vrai plaisir. Programmer oui, mais avec manière. Je veux être développeur de métier, mais aussi dans le coeur,
avec, l’art du métier. l’art, la beauté.
Un avis subjectif, d’un développeur qui préfère Zend Fmk.
Je ne suis pas du tout d’accord sur cet article. Pour m’argumenter j’invite les personnes intéressées à lire l’article (dommage, il faut faire un effort en anglais) qui est très bien écrit et que je confirme (je travaille depuis 6 mois sur cet outil).