mercredi 16 juin 2010

Pourquoi je déteste Drupal (et la plupart des autres CMS)

Voilà quelque temps que je me retrouve régulièrement empêtré dans des débats stériles concernant les CMS (système de gestion de contenus prêt-à-l'emploi) en PHP, et particulièrement Drupal, auquel j'ai été confronté lors de missions chez différents clients, et dont la popularité le désigne tout naturellement comme bouc-émissaire de premier choix pour traiter du mirage que sont les promesses des CMS.

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 :
  1. 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.
  2. Une modularité très discutable
  3. 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...)
  4. 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 !).

122 commentaires:

Hugo Hamon a dit…

Ton article résume parfaitement ce que je pense de l'approche CMS à savoir un environnement contraint ne permettant pas les évolutions ni les modifications. Bien sûr, je ne parle pas du tout des problèmes de performances, sécurité, bonnes pratiques et consort...

Hugo.

Clement Herreman a dit…

Je n'ai pas forcement la compétence technique pour juger de Drupal, mais par contre, il est evident que d'essayer (et parfois d'arriver!) à faire croire que l'on peut vendre une application métier "clef en main" est au mieux farfelue, voire utopique.

Je ne suis d'ailleur pas toujours convaincu que l'utilisation d'un CMS soit bénéfique niveau temps de developpement, ou alors uniquement si il n'y que très peu de choses à changer, et que ces changements se concentrent sur le graphique.

Alors bien sur, ça coute plus cher et il faut trouver un bon prestataire, qui n'hésite pas à faire de la qualité..

Gauthier a dit…

merci pour vos commentaires - j'avoue que je m'attendais plutôt à des invectives de la part de fervent drupaliens - je suis ravi de constater que mon point de vue sur le sujet n'est pas isolé :)

@Clément: j'ai oublié en effet de tirer cette conclusion, implicite dans mon post, que l'emploi d'un CMS conduit le plus souvent à un temps de développement qui augmente de manière exponentielle au fur et à mesure que la complexité du projet augmente !

Guiguiboy a dit…

Je suis tout à fait d'accord avec votre article.
Il y a aussi le problème des modules proposés par la communauté qui sont pour la plupart, mal développés et dont la compatibilité avec d'autres modules n'est pas assurée.
Si l'application a des besoins bien spécifiques, il est vraiment préférable de développer avec un environnement sur lequel on a la main.

Michael Loughlin a dit…

Although I could agree to a large extent, I also wonder what it might cost the average client, who doesn't care whether the site runs on Drupal or OOPal, to not go the Drupal route and therefore not benefit from the wealth of already developed, community tested and security monitored modules, the majority of which are mature and stable, and which may even give them more functionality than they bargained for...

Perhaps oo experts should offer their wares, and experienced Drupal shops theirs, and the client should decide based on price, performance, delivered quality, and whether they care about hooks or inheritance?

Gauthier a dit…

@Michael Well I think you missed one of the key thought in my post (probably because it's written in french ;)), which is "CMS are not made to develop an application or a website that you'll hardly need to customize".

My opinion is that professional service companies shouldn't rely on CMS to develop such deliverables, because CMS don't offer the proper structure for applying best practices of software development. So if you need to develop, you need a framework, not a CMS. If you don't need to develop, and can deal with what CMS have to offer, go for it :)

Michael Loughlin a dit…

Yes but the title of your article is: "Pourquoi je déteste Drupal (et la plupart des autres CMS)".

I would say that rather than detesting it, perhaps you should point clients who insist on Drupal, or who have a project which would benefit from Drupal, to a Drupal expert, rather than "hating" it and insinuating that the community is: "une foule d'amateurs et de quelques professionnels désoeuvrés".

Gauthier a dit…

The clients are not aimed - I'm talking about people who claim to be professional, because that's their role to guide the client in the right direction.

Regarding the terms I used to qualify them, you're right that they are a bit severe. I'm sorry for that, but this reflects exactly what I've been given to see!

Nevertheless, I'm pretty sure there are some actually skilled developer involved in drupal and other CMS, but I'm convinced that they're wasting their talent and our time!

Simon Rolley a dit…

Michael and Gauthier : sorry for these words, but professionals who advice Drupal in a context where there will be lots of customizations - as it is very often the case - are only pokemons and do not deserve the name "professionals".

Do you often use design patterns when coding with Drupal? Do you have the feeling to know what algorithmic is? It does not hurt you that this tool does not provide any ORM?

When no customization at all is required, Drupal is the perfect tool for static content websites. When optimization or customization is required, which sadly happens very often, it is just a mess to develop with it, as you then develop in an empiric way. Just show one single Drupal module applying all the coding best practices: documentation (phpDoc), abstraction, usage of design patterns, extensibility, etc. There isn't any.

I am very angry to read that "Drupal is a framework" or "it is a developement platform", or that "Drupal developers are highly talented experts". This is bullshit, lies, and missleads the clients who want quality and bullet-solid products. And it is a pain in my ass, because i worked hard and long to level up in developement and be a recognized professional - I didn't satisfy mysef with unzipping Drupal and enabling two crappy modules.

Grégoire a dit…

\o/

Pour avoir fait une tentative de drupalisation, je suis d'accord sur tout. Tu aurais pu t'arrêter plus longuement sur l'implémentation absurde des types de contenus en base de données mais c'est déjà assez drôle comme ça !

++

Gauthier a dit…

@Simon I feel exactly the same as you - I also worked hard to learn how to do my job in the better way, and I'm really upset when people come and tell me "look, I can do the same in no-time with Drupal!". That's untrue, and that's what I wanted to pinpoint with this post. Moreover, they make their customers lose time and money (sometimes a lotta!).

@Grégoire merci de ton commentaire - je suis ravi que tu aies également saisi le côté humoristique de la chose ;)

Unknown a dit…

Et j'ajouterais également le fait que les customizations demandés par les clients empêchent bien souvent les mises à jour futures du core et donc de bénéficier des corrections des nombreuses failles du CMS... (sans parler des nouvelles fonctionnalités)

Alors, à quoi bon utiliser un CMS tout fait si c'est quand même pour tout recommencer quand on veut ajouter quelque chose dessus...

SCiPS a dit…

Excellente synthèse, je link!

Davanlo a dit…

On peut s'étonner du nombre de projets vendus pour des prétendues customisations qui font parties des fonctions standard de la plupart des sites (CMS ou non).

Je pense à Blog - News - Agendas - insertion d'images - etc. qu'on veut souvent faire passer pour du besoin spécifique afin de vendre du module.

egide a dit…

Excellent article.
Rare de trouver une critique fondée.
Mais voilà, existe-il des offres libres, une sorte de package qui offrirait une solution employable "out of the archive", fondées sur des frameworks ?

Gauthier a dit…

@davanlo effectivement, cela fait partie du "business" induit par les CMS et assimilés (c.f. Presta Shop par exemple). Toutefois, acheter un module "tout fait" ne constitue pas selon moi une véritable customisation...

@egide merci pour le commentaire :) cependant, pour ce qui concerne des packages prêts-à-l'emploi basés sur des frameworks, je n'en connais que très peu. Certes, en utilisant des frameworks reconnus comme structure de base, ils ne peuvent qu'offrir un niveau de satisfaction plus élevé, mais ça ne règle pas tout. De même que les supermarchés n'ont pas éradiqué tous les artisans, ces produits ne transformeront pas tous les développeurs en webmasters :) Notre métier consiste à créer des applications pour nos clients, applications (ou sites web d'ailleurs) supposés s'adapter parfaitement aux exigences de leurs métiers. Ce que les CMS n'offriront jamais, en tout cas pas en accord avec le niveau d'exigence qui est le mien, ainsi que celui de la plupart des clients avec qui j'ai travaillé (posez-vous la question... :))

Chris a dit…

Enfin quelqu'un qui voit clair!

Le système d'objets de Drupal est une horreur. Il y a par exemple, d'après ce que j'ai compris, des espèces d'objets "instanciables" et d'autres qui sont "instanciés", autrement dit ils ont même réinventé la notion d'interface et implémentation. Ils ont réinventé tout l'orienté-objet à leur sauce.

Vivement l'abandon complet de PHP < 5.2 pour que les applications web puissent quitter l'âge de pierre.

Unknown a dit…

A noter que le problème de (l'absence de) l'OO est accepté par une partie des développeurs Drupal. Même si retrouve de plus en plus d'OO dans pas mal de "gros" modules (Views, CTools, etc.) ainsi que dans Drupal 7.

Même chose pour ce qui est du "tout en DB" décrit. Les modules Features, Context et Spaces ainsi que la notion d'exportable, soit de données de configuration issus de code et pouvant être surchargées par des données DB (comme le sont les views et les types de contenu), sont des outils qui permettent d'éviter les problèmes décrit. cf. http://developmentseed.org/blog/2009/jul/09/development-staging-production-workflow-problem-drupal

C'est loin, très loin même, d'être parfait. Mais tout n'est pas aussi noir que ne le laisse entendre l'article.

Anonyme a dit…

Bon article ! Merci !
--
Un développeur condamné à travailler avec cette daube à cause des clients qui ont entendu dire que Drupal c'était génial de la part de leur petit cousin en CM2...

Fibo a dit…

B-) Je sens que je vais me faire tirer dessus...

N'étant pas expert en OO (j'ai appris à programmer il y a bien trop longtemps), je ne comprends pas totalement tous les éléments de l'affirmation "c'est pas OO donc ce n'est pas bon".

Utiliser un "package open-source" comme Drupal ou Magento (qui lui est totalement OO), c'est un moyen d'éviter de réinventer la roue.

Si un client vous demande une plate-forme e-commerce avec beaucoup des fonctions de Magento, vous avez le choix entre deux solutions:
- tout réécrire, par exemple avec le framework Zend qu'utilise Magento
- prendre Magento, et y rajouter les modules dont votre client a besoin.

Quelle est la démarche qui en donnera le plus à votre client pour son argent?
Cela dépend en fait de sa spécificité et de sa concurrence:
- si c'est une PME qui démarre et dont la force, c'est les produits... elle a besoin d'un outil et le package open-source, complété par vos soins, est sans doute la meilleure solution pour le client
- si au contraire c'est une grosse boîte et qu'une partie très importante de son succès est due à sa créativité e-commerce, pas question d'utiliser l'open-source dont, juridiquement, vos développements risquent d'être eux aussi open-source, et donc ne reste que la solution du sur-mesures.

Désolé, je n'oublie pas le CMS, même si je suis passé par un Magento dont le statut OO vous incite sans doute à plus d'indulgence.

Drupal n'est sans doute pas la solution parfaite... mais soyez lucides: si vous faites un développement avec le framework X ou Y, vous êtes en fait surtout en train de verrouiller votre client car vous seul serez capable de faire évoluer le site... Pourquoi pas d'ailleurs, même si ce n'est pas ma philosophie?

Ce que le client final veut, c'est pouvoir mettre à jour le contenu son site facilement, et, peut-être, le faire évoluer une ou deux fois par an sans que cela lui coûte un bras. Pourquoi vous priver de l'outil Drupal (ou autre, mais Joomla est tellement mal foutu que c'est un peu galère... disons le "modeste" SPIP qui fait tourner des sites pas si modestes) qui va assurer 80% des fonctions voulues par l'utilisateur, et affecter toute votre énergie (et la facture) aux 20% de fonctions restantes?

Gauthier a dit…

@fibo

> B-) Je sens que je vais me faire tirer dessus...
En aucun cas ; si on ne peut plus discuter, débattre, on avance plus !

> N'étant pas expert en OO (j'ai appris à programmer il y a bien trop longtemps)
Just for fun, les concepts fondamentaux du pradigme objet remontent aux année 60, voire 50 ;)

> Quelle est la démarche qui en donnera le plus à votre client pour son argent?
Celle qui correspondra au plus à ses besoins, sans surcharge inutile, et surtout qui restera maintenable dans le temps

> pas question d'utiliser l'open-source dont, juridiquement, vos développements risquent d'être eux aussi open-source, et donc ne reste que la solution du sur-mesures.
Là, je ne pouvais manquer en effet de tirer à boulets rouges :) Pour répondre simplement, l'"open source" n'existe pas. Il y a *des* licences libres, parfois très différentes. Et celle de Zend Framework, que tu dois connaitre en tant qu'utilisateur de Magento, est précisément totalement "business friendly" : il s'agit de la licence New BSD, qui tient en quelques lignes (http://bit.ly/d9A2j3), et n'est absolument pas contaminative.

> Drupal n'est sans doute pas la solution parfaite...
Il ne fallait pas désespérer, nous voici enfin d'accord :)

> mais soyez lucides: si vous faites un développement avec le framework X ou Y, vous êtes en fait surtout en train de verrouiller votre client car vous seul serez capable de faire évoluer le site...
Là, carton rouge ! ça fait un moment maintenant que je suis appelé en pompier sur des sites (Drupal ou pas par ailleurs) dont les auteurs même ne parviennent plus à y comprendre quoi que ce soit ! A l'inverse un code correctement écrit (ce que l'objet favorise - et non pas permet, ne me faites pas dire ce que je n'ai pas dit), est infiniment plus aisé à relire, et en reprendre la maintenance, y compris évolutive est réaliste. Je me suis par ailleurs toujours engagé contractuellement à documenter mon code, et j'ai toujours renoncé à l'exclusivité des évolutions de ce code (toujours par contrat), ce qui implique le transfert de connaissance sur mes développements. Donc le coup du client captif, à d'autres ! Le client n'est-il pas captif quand il demande "on peut rajouter une colonne dans l'affichage, ici" et qu'on lui répond "ah non, désolé mon petit monsieur, il faudra attendre Drupal 12 et Views 5 pour pouvoir faire ça" !



> Ce que le client final veut, c'est pouvoir mettre à jour le contenu son site facilement, et, peut-être, le faire évoluer une ou deux fois par an
Nous ne parlons manifestement pas des mêmes clients, ce qui pourrait expliquer certaines de nos divergences d'opinion...

> qui va assurer 80% des fonctions voulues par l'utilisateur, et affecter toute votre énergie (et la facture) aux 20% de fonctions restantes?
Ce que j'ai pu constaté, c'est que ces 20% d'aménagements personnalisés prennent souvent, et je n'exagère pas, 100, 200, 500, voire 1000% de ce qu'aurait demandé un développement sur mesure, mené s'entend par des gens compétents !

mageekguy a dit…

Pour m'être pris la tête sur du Drupal en tant qu'admin sys, et sur du prestashop et du magento à la fois en tant qu'admin sys et en tant que développeur, je suis à 200% derrière Gautier en ce qui concerne la sois-disant "modularité" des CMS.
De par mon expérience, j'ai toujours eu des problèmes, et au final, un développement custom, qui semblait trop contraignant au départ en terme de délai et donc de prix, aurait été beaucoup plus efficace à moyen ou long terme.
En effet, un CMS n'est jamais parfaitement adapté au besoin, et il est parfois très difficile de l'adapter au besoin exprimé par le client.
Je ne parle même pas de la problèmatique de la sauvegarde de la compatibilité ascendante (ne serait-ce que pour boucher les trous de sécurité), qui peut vite devenir un obstacle, ou bien encore les changements d'API d'une version à l'autre, ou bien encore la conception objet qui oblige à recourir à des hacks immondes pour parvenir à faire le job.
Au final, on pense gagner du temps, et on en perd.
Alors oui, les CMS comme Drupal répondent à une problématique, mais elle est loin d'être universelle, et ils ne sont certainement pas la solution miracle.
Et je ne parle pas des problèmes de performances... ni de l'ergonomie parfois plus que discutable.

Nicolas FROIDURE a dit…

Comme toujours dans ce type de CMS, les évolutions naturelles de la façon de programmer n'ont pas pu être adoptées à cause du fait que la communauté d'utilisateur demande souvent une compatibilité ascendant minimale.

Bref, un CMS, c'est comme un fruit, au départ c'est une fleur où quelques abeilles butinent, après, c'est un fruit et enfin, ça pourri pour ne devenir qu'un monticule hideux et puant entouré de mouches.

Mais bon, j'imagine que le recul nous donnera le même exemple avec les Frameworks. La vie est un éternel recommencement.

Benoit a dit…

Avez vous déjà testé Typo3 ?
Pour l'avoir utilisé dans de nombreux gros projets, je n'ai absolument jamais eu besoin de toucher au core de cet outil.

Je trouve qu'il y a des généralités et des raccourcis un peu trop vite fait dans ces réactions. Je ne vous le cache pas, je n'ai jamais eu à utiliser Dupral mais à vous lire je dirais que c'est plus des problèmes liés à cet outil qu'aux CMS d'une façon général.

Je suis loin d'être un expert Typo3 mais je pense quand même avoir quelques bases solides puisque ça fait maintenant quelques années que je l'utilise. Sa force, c'est le TypoScript : un espèce de pseudo langage qui permet de configurer le rendu et les extensions sans avoir à gratter à une ligne de code PHP.
Voir ce super billet : http://blogue.infoglobe.ca/2010/02/14/le-typoscript-cest-quoi-exactement/

Il y en t'il parmi vous qui connaissent très bien les deux moteurs ?

Gauthier a dit…

bonjour Benoit, et merci de ton commentaire.

Non, je ne connais pas Typo3 (du moins, je nl'ai pas réessayer ces 5 dernières années ;)).

Si je ne doute pas qu'il y ait des CMS mieux conçus que d'autres, je pense cependant que ça ne change rien au fond de mon propos.

Et quand je lis ce genre de chose (copié/collé des commentaires de l'article que tu as linké) :

> "Drupal est mieux que Typo, plus simple et plus ouvert."

Quand je vois une argumentation pareille, je me dis qu'on est pas rendus :)

Moi je m'intéresse à PHP, et à tout ce que l'on peut faire avec. Je ne m'enferme pas dans une petite sous-partie.

Et si, sous la menace d'une arme (chargée), on veut me refaire bosser sur un CMS, j'en serais capable. Quel que soit le CMS. L'inverse n'est absolument pas vrai (dans la majorité des cas...).

Benoit a dit…

Je n'avais pas lu les commentaires de l'article ... effectivement mais bon c'est un troll c'est évident :)

Vincent a dit…

Utilisant depuis plusieurs années deux CMS que sont TYPO3 & Drupal, j'abonde dans votre avis :

Drupal n'est pas un un CMS conceptuellement bon. Peu de classes, une méthode de surcharge qui n'est pas très propre puisque l'objet est proscrit de son univers.

Néanmoins, il faut comprendre qu'on n'utilise pas un CMS pour "son code propre" pour reprendre l'expression d'un ami. On utilise un CMS parce qu'il permet de fournir un site rapidement administrable et possédant un minimum de "modularité fonctionnelle" (en particulier concernant les gabarits) pour rendre son site différenciable de celui de la concurrence.

Drupal est depuis longtemps utilisé par les sites de Presse car il me semble répondre à leur besoin :
- En trois clics on peut écrire des articles (node dans le jargon Drupalien),
- En quelques clics et un peu de navigation on récupère les modules qui vont bien et on rajoute à son site les fonctionnalités qu'on attendait de lui (commentaires, espace privé, partage d'article...)
- Au final, peu ou pas de développement n'ont été réalisé et pourtant le site a de la gueule. C'est tout ce que le client attend de nous.

C'est pour ces raisons que j'imagine utiliser Drupal : lorsqu'il répond à 80 voire 100% des fonctionnalités attendues, pourquoi les développer de nouveau de notre côté en utilisant un Framework ?

Maintenant, lorsque justement le client attend d'un outil ou d'un site des fonctionnements qui ne sont pas géré par la communauté (Drupal ou autre), il est bien plus rentable d'utiliser un Framework pour sa "modularité technique"

Pour finir ce commentaire, je tiens à compléter la remarque de Benoît, avez-vous penser à TYPO3 ?

C'est un plaisir de l'utiliser car sa logique est bien plus aboutie que celle de Drupal :
- Quasiment tout Objet (du reste il nécessite PHP5.2 minimum depuis au moins un an), par conséquent possibilité de surcharger chaque classe par héritage, on appelle cela l'XCLASS.
- Existence du TYPOScript, ce langage ressemble par certain côté a un mélange entre de l'XML/YAML de configuration tout en ayant son propre paradigme objet.
- Parfois on a besoin d'interférer avec le fonctionnement d'un plugin sans avoir à surcharger l'ensemble de la classe (pour des raisons de compatibilité), à ce moment il est possible d'utiliser un Hook (en règle général, ceci permet de rajouter des conditions d'affichage, des paramètres sans avoir à tout modifier).
- Quand on a besoin d'une nouvelle fonctionnalité, on développe sa nouvelle extension, on déclare une nouvelle classe qui hérite de la classe "pibase" qui contrôle le rendu des "extensions" et on est parti sur du développement qui peut être totalement spécifique.

Résultat, les concepts utilisés permettent à la fois d'avoir une grande souplesse (TYPO3 ressemble plus à un framework qu'à un CMS) tout en permettant d'accéder rapidement à des fonctionnalités de base (créer un site, éditer son contenu).

Pour information, la prochaine version majeure de TYPO3 sera basé sur le Framework FLOW3 (en développement lui aussi).

Anonyme a dit…

c'est étrange de dire qu'un CMS est conçu pour les non développeurs, quand on sait que les grands médias utilisent quasi systématiquement un CMS pour développer leurs sites.
étrange donc ... troll j'en conviens :)

contao a dit…

Personellement j'utilise Contao (ex TYPOlight), c'est un CMS + un framework => un CMF
Je n'en dit pas plus et vous laisse l'essayer si vous ne le connaissez pas.

Fibo a dit…

@Gauthier (pour le fun)

|> B-) Je sens que je vais me faire tirer dessus...
|En aucun cas ; si on ne peut plus discuter, débattre, on avance plus !

B-) Je l'entends bien ainsi, mais la modération des propos n'est pas toujours la règle dans les commentaires des blogs et forums. Ce qu'on trouve ici est une bien agréable exception!

|> N'étant pas expert en OO (j'ai appris à programmer il y a bien trop longtemps)
|Just for fun, les concepts fondamentaux du paradigme objet remontent aux année 60, voire 50 ;)

Les langages de programmation ne s'y sont mis que bien plus tard. La notion de format d'enregistrement et la DATA AREA du Cobol (ou ses équivalents dans PL/1 ou algol) en étaient une première manifestation centrée sur les attributs tout en ignorant les méthodes... pour donner ensuite Simula (algol + objets). SmallTalk, Ada, C++, Java, Eiffel etc ne sont arrivés qu'au début des années 70.

Comme cours d'informatique, j'ai eu quatre fois une heure de cours sur Fortran Batch... (qui a dit dinosaure?)

----------------------------------------------

Revenons aux choses sérieuses.

Je pense que dans l'ensemble "le programme idéal" de "la situation" n'existe généralement pas. C'est tout le boulot d'exploration de l'AMOA que d'aider le client à le comprendre et à exprimer ses priorités quant aux fonctionnalités demandées ET aux moyens qu'il est prévu d'engager pour faire fonctionner le site après sa livraison. A partir de là, il faut trouver, puisque l'idéal n'existe pas, "le bon" compromis.

Le bon compromis que nous choisissons, c'est celui qui nous paraît le plus raisonnable compte tenu d'une part des besoins d'autre part des capacités techniques de la maîtrise d'oeuvre. Mon opinion très personnelle, mais dont je réalise bien qu'elle découle de mes limitations techniques, c'est que sauf cas particulier la plupart des utilisations n'ont besoin que d'un bon vieux CMS avec quelques modules spécifiques.

Problème de performance?
Ne rigolons pas, on va prendre un dédié à 150 euros/mois au lieu de 100, cela coûtera 600 euros de plus sur l'année, une journée de programmeur expert... J'ai mis longtemps à comprendre qu'aujourd'hui cela coûte souvent moins cher de dépenser plus en matériel que de payer un expert à optimiser le programme (il y a des limites, bien sûr).
Réservons le travail de l'expert (même s'il ne l'est qu'un peu) à des besoins d'expertise, pas à programmer une identification / login qu'en plus il va peut-être mal coder, ce qui là aurait des conséquences désastreuses.
Que l'expert utilise son expérience et son savoir-faire pour "durcir" le CMS (détecter le pays de connexion, les connexions répétées d'un même IP, etc), pour mettre en place des sauvegardes automatiques des alertes, etc. Ou encore pour pondre le "super-module" qui correspond à la spécificité de l'application métier.

Anonyme a dit…

Difficile d'aller contre ton argumentaire, en tout cas concernant les erreurs de conception de drupal qui ne s'arrêtent pas, loin de là, à une simple histoire de POO ou à la cacophonie modulaire. Et pour aller plus loin dans ton analyse sur l'usage du SGBD, c'est même plus grave que cela encore.

Drupal n'impose en effet aucune gestion des données aux modules, et particulièrement concernant la séparation contenus/réglages. Tout est généralement stocké en base, dans la plus joyeuse anarchie. Certains modules feront des tables à eux, d'autre vont littéralement aller bourrer la table "variable" (un design emprunté à Microsoft avec sa Registry ;-), et au final, il ne reste plus aucun moyen simple de discerner le grain de l'ivraie, et d'opérer un déploiement de fonctionnalités sur un site "live". Et c'est encore plus drôle concernant les données contextuelles des modules (ex. l'heure de passage du dernier cron) qui sont là aussi stocké n'importe où. En bref, oui, c'est le souk, et, comme un hypothétique virage objet, je vois difficilement cette situation s'améliorer en regard de l'existant.

Enfin oui et non, car selon la fameuse règle Drupalienne qui dit "on peut casser le code des copains, mais pas les données de l'utilisateur", ce qui est en soit assez comique car les deux vont souvent de paire, il serait logiquement possible d'imaginer un drupal X repensé réellement (objet, véritable design, etc.). Mais comme le montre le lien que tu donnes dans ton article (Drupal programming from an object-oriented perspective, je me suis fait pipi dessus de rire :-), il semble que nombreux sont ceux de la communauté qui trouvent les choses très bien ainsi... Cela ne va donc pas bouger dans le bon sens. C'est même un peu tout le contraire et moi aussi je sens que je vais me lâcher sur un papier concernant Drupal 7. Car les erreurs de design sont une chose, mais se foutre aussi ouvertement de l'investissement fait sur la plateforme précédente en pétant les 3/4 des APIS sur la plateforme suivant, là ça commence à devenir un peu lourdingue.

Ceci étant dit, je continue à bien aimer Drupal pour son ambivalence entre CMS clef en main et plateforme de construction. Même si cette ambivalence est aussi un poison qui avec le temps semble privilégier les interfaces-graphiques-qui-font-tout aux API sous-jacentes. Je te conseil dans cet esprit l'étude de la magnifique fonction drupal_execute qui pour moi est un poème emblématique de tout ce dont on discute ici.

Maintenant la bonne question que l'on pourrait se poser est de savoir pourquoi le produit évolue toujours dans le même sens. Mais là on rentrerait dans la féodalité de gestion des fonctionnalités de Drupal, ce qui est un tout autre débat :-)

Yoran a dit…

Désolé pour le "anonyme" du commentaire précédent, un peu de mal avec l'interface de blogger :)

EP a dit…

RBS Change est un exemple de CMS qui utilise des bons concepts de OOP .Utilisation de classes abstraites, de singletons, d'interfaces etc...mais aussi des trucs plus dynamiques comme l'introspection ou encore même de l'AOP. ça tourne sous php 5.3 en plus...manque encore de doc mais c'est vraiment un environnement de développement complet tout en restant un vrai CMS et une solution d'e-commerce.

Anonyme a dit…

Salut,
Merci pour ce résumé. Notre société qui travaille à la fois du design et du developement c'est posé la question il y a quelque année sur l'utilisation de CMS existant ou sur la création d'une version personnelle.
Nous sommes parti sur une version personnelle pour la simple raison de tous les CMS existant à l'époque ne permettent pas de garantir que le corporate graphique de l'entreprise soie respecter lors de mise a jour du contenu, car souvent les zones a éditer sont en wysiwyg et laissée en charge a l'utilisateur de construire sa mise en page. Notre version permet a un intégrateur web de créer des modéles html, d'objet ou de zones dans laquelle il définit des variables editables, ce qui permet de générer en ajax une fenetre contextuelle peremttant d'éditer uniquement les variables mise a dispostion.
Notre CMS peremt de faire de l'inclusion dynamique.

Bonne journée

delew a dit…

Pas grand chose à ajouter concernant Drupal. Dans le cadre d'un appel d'offres, j'ai dû partir à la recherche d'un CMS Open Source (je travail habituellement sur un CMS proprio), et j'ai été très surpris de me retrouver totalement perdu et impuissant sur chacun des CMS "à la mode" que j'ai pu essayer... Soit très vieux et abominablement austère (typo3, spip, ...) soit très limités en fonctionnalité "out of the box" (drupal, spip, ...). Ce dernier point a été pour moi rédhibitoire, utiliser un CMS pour la mise en place d'un site qui ne me permet nativement que de créer des actualités ("articles"), et pour lesquels ils faut en permanence patcher à l'aide de modules non officiels sortant dont ne sais où afin de ne pas s'obliger à créer nos propres modules et donc perdre en productivité...aberrant!!!

pour appuyer les propos (pas vraiment neutres) de @contao, mon choix s'est finalement porté sur ce CMS qui m'a séduit par son interface moderne, ses possibilités natives, et surtout par la propreté du code et la logique de son architecture objet...
J'espère que la pratique confirmera mes premières impressions...

@contao

Nicolas Hoizey a dit…

C'est vrai, ça, les CMS c'est pourri, tous à la poubelle ! Ah, mais euh.. tu utilises Blogger ? C'esten mode SaaS donc c'est pas un CMS ? :-p

Sérieusement, j'abonde dans le sens de Fibo. Ce n'est pas parce que la plupart des CMS sont mal codés, ou plutôt sont codés à l'ancienne, qu'ils sont à jeter.

Il faut juste éviter de les utiliser quand ils ne sont pas adaptés, car quand ils le sont, ils permettent vraiment une grande économie de moyen, et évitent bien souvent de partir dans n'importe quelle direction en suivant la lettre au Père Noël des MOA qui ont plus d'envies que de besoins.

Un autre énorme avantage des CMS à mon sens, c'est qu'ils imposent une ergonomie de l'interface de contribution qui bénéficie d'années d'expérience, alors que les développements à façon sont souvent de bons exemples de réalisation de développeurs n'ayant aucune notion fonctionnelle/ergonomique.

Par exemple, SPIP a eu longtemps un code PHP vraiment pourri (ça c'est bien amélioré par la suite, mais ça reste très peu objet), mais une interface de contribution vraiment ergonomique. Tout simplement parce que des gens qui avaient des besoins fonctionnels se sont retroussé les manches et ont appris PHP sur le tas pour répondre à leurs besoins. On entend beaucoup dire que l'interface de SPIP est obsolète, mais elle a le grand mérite d'être cohérente et intuitive, là où des concurrents développés par des techos ont une interface qu'il est impossible de mettre dans les mains de contributeurs de contenus non techniciens.


PS: le système de commentaires de Blogger est bien pourri, change de CMS... oups. ;-)

Gauthier a dit…

@Nicolas je réponds rapidement car j'ai à faire, mais je ne peux résister au plaisir de t'adresser toutes mes félicitations pour la pertinence de ta remarque au sujet de Blogger :)

Tu as raison, ça peut sembler paradoxal. Mais ça ne l'est pas : les CMS sont précisément faits pour ça ! Quelques clics, le blog est en ligne et on est prêt à publier. Sans avoir à y retoucher. Là d'accord.

Mais il est évident que dès lors que ce système ne me satisfera plus, je songerai à le changer, et je ne perdrai pas mon temps à tenter en vain de l'adapter à la hache à mes besoins ;)

Fedir a dit…

J'ai travaillé sur les projets différentes réalises avec les CMS open source: TYPO3, Drupal, Wordpress, eZ Publish.

Donc, l'approche procédurale en Drupal - c'est le choix de la communauté, pour optimiser l'apprentissage de son framework, et augumenter la quantité d'installations.

Concernant la volume de requêtes : c'est dépends, si vous saviez utiliser les caches de différentes niveau.

La modularité est réalisé très bien grâce au système de hooks, actions, triggers. Grâce à ça, c'est possible faire des projets très personnalises.

Mais,bien sur, Drupal reste un CMS legere, adapté plutôt au projets plus compactes.

Pour les grandes projets parmis les CMS open source, personnellement, je préfère TYPO3, si on parle de monde PHP, bien sur. TYPO3 est moins flexible au niveau de Back-End en modularité, mais permets faire de développement plus assuré au niveau de mise en ligne. Spécialement, si vous maîtrisez le TypoScript et saviez qq bonnes méthodiques.

Après - vous pouvez toujours utilisez des Frameworks independentes, comme Zend, Symfony, Django. Mais il faut dire, que sur certains projets vous passerez beaucoup plus de temps pour la conception et re-développement des fonctionnalités accessibles "out-of-box" pour les CMS.

Unknown a dit…

En utilisant un CMS, on est bien souvent contraint d'adapter ses contenus et les fonctionnalités à l'outil.

D'où l'intérêt d'utiliser une brique plus bas-niveau, tel un framework extensible et découplé, pour permettre d'adapter et/ou d'étendre l'outil aux fonctionnalités désirées (contenus, métier, features) et se laisser le champ libre pour d'éventuelles évolution qu'on ne (sait|peut) jamais vraiment anticiper (à part madame Irma, sur un gros coup de bol).

#coolfacts : En 10 ans, je n'ai pas rencontré une seule fois un projet où le scope fonctionnel d'un CMS a été suffisant pour couvrir l'ensemble du besoin fonctionnel sans hack nécessaire (quand c'était encore possible, et avec tous les problèmes de maintenance qu'on peut imaginer derrière).

Mais j'ai sans doute pas eu de bol, bien entendu.

My two cents.

Gauthier a dit…

j'en profite également pour réagir rapidement aux remarques de @Fibo concernant les performances et le coût des serveurs dédiés.

Une fois encore, il ne faut pas confondre support de la montée en charge et performances. Prendre un meilleur CPU et/ou augmenter la RAM ne changera pas grand choses aux limites en termes d'I/O disque et réseau.

Partir du principe que l'on peut se permettre de gâcher des ressources car elles ne coûtent pas cher ne me semble par ailleurs pas vraiment dans l'air du temps : fais-tu la même chose avec le pétrole ? De la même façon, un code ne peut être durable (comprendre "maintenable" et "évolutif") que s'il a été conçu correctement, avec cette préoccupation en tête, plutôt que de se dire que si jamais ça patine, il suffira de gonfler le serveur.... jusqu'à ce qu'il éclate ?

Thomas a dit…

Merci pour cet article !

Pour répondre à une remarque qui a été faite dans un commentaire ci-dessus, utiliser un framework n'implique pas forcément de réinventer la roue à chaque nouveau projet.

Rien n'empêche de développer des modules de gestion de contenu réutilisables pour les situations "standard" (je pense aux pages de contenu statiques, à un formulaire de contact, etc.). De nombreux framework proposent d'ailleurs des modules/plugins/bundles qui permettent d'ajouter rapidement ce type de fonctionnalité à un site.

La différence majeure avec un CMS étant que le (bon) développeur comprend immédiatement le fonctionnement de ces modules "clé-sur-porte", simplement parce qu'ils respectent le cadre de développement imposé par le framework, ce qui permet de les adapter facilement à une situation un peu particulière.

Sans compter qu'en plus, tous les outils fournis par le framework restent disponibles pour mettre en place rapidement et proprement les fonctionnalités spécifiques à l'application développée...

Unknown a dit…

Mes 2 dirhams:

Tout à fait d'accord avec Nicolas H.

Le pb rencontré avec les CMS construits à partir d'une framework ou autre, c'est souvent l'interface d'aministration toute pourrie (genre admin. gén. de Symfony) ou qui coûte un bras à faire.

C'est l'avantage d'un SPIP (même si c'est pas la panacée) et d'un Wordpress. On oublie les Drupal et autres, que je ne trouve pas très ergo en admin.

Pour moi l'idéal pour un site qui ne peut pas être fait par mon neuveu en CM2 est quand même un CMS basée sur un framework que bcp de dev comprennent, avec un thème bien foutu sur l'admin (j'ai déjà vu ça sur du sf ping @n1k0)

Pas un énorme développeur plutôt un AMOA mais perso:
- j'ai fait du SPIP sur un petit site tout con
- j'ai fait du Drupal que j'ai jeté
- j'ai fait du Joomla qui m'a pris la tête
- j'ai fait du symfony pour des choses qui sortent de l'ordinaire mais mes clients râlent pour l'admin (pas le temps de faire keke chose de beau)
- j'aimerais bien faire du typo3 dont bcp de gens me parlent

Unknown a dit…

Gauthier, tu es mon héros !

Je pense que les CMS sont mal utilisés. Ils servent à tort et à travers, en fonction des désirs des clients, des arguments des commerciaux, et du reflux de l'amazonie pendant la mousson indienne...

Bref je crois que :
. il est faux de dire qu'un dév sur un CMS coute moins cher. Avec des bons outils, un dév sur mesure est très rapide.
. à moins qu'on passe outre un cahier des charges fonctionnel indépendant de l'outil... Auquel cas, on reviendra toujours sur ce CDC, ne nous permettant pas de satisfaire le besoin du client...
. à moins de passer un temps fou à personnaliser des modules existants...
. qui ne seront plus compatibles à la prochaine mise à jour

Bref, de mon côté, je travaille sur un CMF maison, proposant
. une méthodologie de développement, avec un VRAI MVC qui permet aux intégrateurs HTML de ne vraiment pas avoir à connaître de PHP
. des "helpers" pour les développements classiques (formulaires, vues, etc.)
. un backoffice simple (gestion des données, des pages, paragraphes, et droits d'accès) et personnalisable

Le site du projet devrait bientôt voir le jour : http://www.oospores.net

En tout cas, merci de dire tout haut ce que je pensais tout bas depuis si longtemps, je me sens moins seul !

Arialia a dit…

C'est un peu vrai tout ça

Spip : un peu lourd
Joomla : sympa mais prise de tête dès fois
Drupal : j'adore le thème par défaut mais ... trop de modules à rajouter

J'avoue que pour mon site et celui de ma commune je suis un peu perdue

l'intérêt du cms c'est quand ses fonctionnalités cadrent avec les besoins or à force de vouloir tout faire ils le font pas forcément bien

Je croyais avoir trouvé la perle rare mais modules non compatibles entre versions , des modules trop indépendants qui pousse à la redondance d'informations ...
Par contre j'aime quand même le principe d'Artiphp en trois parties : le contenu dans la BDD, le code de gestion/extraction en PHP, la présentation couple HTML/CSS ( avec juste le nécessaire PHP pour intégrer les blocs d'informations )

Dans l'interface d'administration on s'occupe de la structure du site et de la gestion des droits j'aime bien.

Mais du coup vous m'avez mis un doute :D

Faire mon CMS ou faire un fork des modules qui ne me conviennent pas ?

Nicolas a dit…

Concernant Magento, c'est un framework et non un CMS, non? :)

Gauthier a dit…

@Nicolas pour autant que je sache, Magento est un moteur d'e-commerce basé sur Zend Framework, mais n'est pas à proprement parler un framework lui-même

Anonyme a dit…

Je pense que vous evoquez des problemes qui ont depuis été réglé. C'est bien de pointer du doigt, c'est un peu mieux de suivre les évolutions ( module features, backup&migrate aegir, arrivé de POO a certains endroits dans le core )
Et si les modules ne sont pas assez bien codé, et bien contribuez, c'est aussi le but des projets open source non ?

Arialia a dit…

Là tu marques un point ...
Effectivement s'il y a des soucis dans un module plutôt que de faire sa petite modification dans son coin rien n'empêche de faire évoluer le module ... c'est le principe des produits libres open sources

Par contre je me souviens de ce qui m'avait gênée dans tous ses cms à part Artiphp c'est l'obligation d'indiquer où se mettait le module ou contenu alors qu'on définissait la structure du site.

Gauthier a dit…

@anonyme (marrant ça quand même) : puis-je me permettre de souligner la vacuité de ton argumentation ?

"des problèmes qui ont [...] été réglés" => lesquels ? comment ?
"POO a certains endroits dans le core" => tu peux parler d'objets à certains endroits, mais pas de POO... utiliser des objets ne suffit pas pour faire de la POO).

Quant à l'emploi de l'impératif pour nous enjoindre à contribuer, il me laisse dubitatif... Je ne comprendrais jamais pourquoi les gens prennent ce genre de chose autant à coeur. Ce que je veux dire par là, c'est que l'on peut s'intéresser au sujet, mais de là à se sentir personnellement concerné ça m'échappe. Et par-dessus tout, réfuter les critiques est vraiment le meilleur moyen de stagner...

Anonyme a dit…

C'est bien beau de signaler qu'il y a un problème avec les CMS mais quelles sont les solutions ?

Laisser le "professionnel" du développement faire sa sauce dans son coin ? Il y de quoi rire sachant que chacun a sa logique et ses outils qui n'appartiennent qu'à lui et l'on est pas à l'abri d'usines à gaz qui ne laissent pas la main à leur clients. Il y a peut être des exceptions chez les développeurs mais ce n'est pas la généralité.

Et si les CMS causent des problèmes tant mieux finalement ça donne du boulot aux super pros que l'on appelle pour les résoudre et qui ce ce fait ne devrait pas avoir d'états d'âme. Votre finalité c'est de bien gagner votre croûte ? Difficile de comprendre alors en quoi c'est si gênant d'avoir à résoudre ce genre de problème.

Par ailleurs vous encensez PHP mais d'autres "vrais" professionnels considèrent seuls Django et Python comme étant des outils valables. Ceux ci pourraient donc juger les développeurs sous PHP comme étant à côté de la plaque en terme d'outils de développement Web. L'arroseur arrosé en quelque sorte... Vous auriez du parler de ce genre de plateforme de développement.

En résumé vous chargez trop les CMS pour en être tout à fait crédible. Et je ne crois pas du tout à votre théorie du "professionnel" qui résout tout. Quelque soit la solution il y a toujours un prix à payer (et je ne parle pas uniquement de l'aspect financier).

Vous faite un diagnostic intéressant mais au final vous n'apportez pas vraiment de solutions qui puissent être industrialisées.

Il y a surtout à réfléchir en fonction du problématique et du budget que l'on y consacre, la solution miracle d'un côté comme de l'autre n'existe pas.

Gauthier a dit…

Cher Anonyme,

il me semble que quelques éclaircissements s'imposent...

> Laisser le "professionnel" du développement faire sa sauce dans son coin ? Il y de quoi rire sachant que chacun a sa logique et ses outils qui n'appartiennent qu'à lui
Apparemment, vous n'êtes pas du métier - ou alors vous ne le comprenez pas. Le "professionnel" dont je parle n'est pas celui qui écrit le code, mais l'architecte, ou l'expert technique, qui précisément détermine la meilleure solution en fonction du contexte, et qui fait en sorte que celle-ci soit déployée dans les règles de l'art.

> et l'on est pas à l'abri d'usines à gaz qui ne laissent pas la main à leur clients.
Je condamne autant que vous ces gens qui ne "laissent pas la main à leur clients", pour le rendre captif, et je n'hésite pas à qualifier ces pratiques de brigandage. Très peu pour moi.

> Il y a peut être des exceptions chez les développeurs mais ce n'est pas la généralité.
En revanche ce que vous prétendez là en est une, de généralité :)

> Et si les CMS causent des problèmes tant mieux finalement ça donne du boulot aux super pros que l'on appelle pour les résoudre et qui ce ce fait ne devrait pas avoir d'états d'âme.
Quelle aigreur ! Ils vous ont aussi volé votre voiture, ces développeurs ?

> Votre finalité c'est de bien gagner votre croûte ? Difficile de comprendre alors en quoi c'est si gênant d'avoir à résoudre ce genre de problème.
C'est très simple à comprendre. Je veux juste faire correctement mon job, et je préfère que mes clients me paient pour avancer dans leurs projets plutôt que pour que je patine à corriger des problèmes que j'aurais moi-même induis en faisant de mauvais choix. Au final, ça lui coûte (et me rapporte) la même chose, sa satisfaction (et la mienne) en prime ! Sans parler de la confiance et de la durabilité de la collaboration qui peut s'ensuivre. En outre, un projet mal exécuté fini par être abandonné, tandis qu'un projet qui rencontre le succès est le plus souvent maintenu et étendu.

> Par ailleurs vous encensez PHP

Ah oui ? Ce doit être subliminal en ce cas :)

> mais d'autres "vrais" professionnels considèrent seuls Django et Python comme étant des outils valables. Ceux ci pourraient donc juger les développeurs sous PHP comme étant à côté de la plaque en terme d'outils de développement Web.
Et ils seraient dans l'erreur, car la technologie sous-jacente n'est pas essentielle. Les problèmes que j'expose sont inhérent aux CMS, pas à PHP.

> Vous auriez du parler de ce genre de plateforme de développement.
Eh bien non puisque mon propos concernait les CMS en PHP, et non pas les frameworks en Python, sur lesquels je n'ai pas plus d'expertise que d'avis.

> Et je ne crois pas du tout à votre théorie du "professionnel" qui résout tout.
Alors que fait-on ? S'en remet-on aux amateurs en ce cas ?

> Vous faite un diagnostic intéressant mais au final vous n'apportez pas vraiment de solutions qui puissent être industrialisées.
Le post ne s'intitule pas "comment se passer des CMS" :)

> Il y a surtout à réfléchir en fonction du problématique et du budget que l'on y consacre
Pas d'accord. Seule la problématique compte. Si vous n'avez pas les moyens d'acheter un utilitaire, et que pour rester dans votre budget votre concessionnaire vous bricole une brouette équipée d'un moteur de solex, je ne suis pas convaincu que ça vous aide vraiment dans votre business.

C'est bien parce que j'ai vu beaucoup de clients se retrouver avec sur les bras une solution inadaptée, impossible à maintenir et encore moins à faire évoluer, ayant finalement perdu beaucoup d'argent et n'ayant pas toujours les moyens de recommencer, que je veux les mettre en garde.

Guillaume.C a dit…

Le modèle MVC est un principe philosophique, là où le CMS est une religion.

Dans les deux cas, aucun des deux modèles ne disposent d'une accise suffisamment confortable, pour prétendre être véritablement viable dans le temps.

Les envies, les moyens, les méthodes, les tendances sont autant de facteurs qui influent sur la façon dont nous abordons les projets de nos clients. Un code pondu à un instant "t" donnera toujours des difficultés à son repreneur "x" années plus tard et ce pour plusieurs raisons :

- PHP faisant, nous ne codons pas tous de la même manière.
- Le temps filant, certains modules/plugins/helpers se retrouvent obsolètes et sans mise à jour suite à une évolution du framework.
- Un site, c'est aussi de l'HTML, du CSS et du Javascript, donc autant de fichiers dont le code risque de déplaire pour une raison x ou y.

Cependant, tout dépend à l'origine du projet du client :

Si il souhaite un outil spécifique qui sort de l'ordinaire (API Web, Intranet complexe, etc...), choisir un MVC devient une nécessité.

Si par contre, rien dans le cahier des charge ne s'oppose à l'utilisation d'un CMS, pourquoi diable s'en passer?
Ce que l'on gagne en temps de développement peut être investie dans l'ergonomie et le design.

bargainhunter a dit…

Je suis tout à fait d'accord avec votre article.

Stol a dit…

Hello,

je ne suis pas utilisateur de Drupal, mais certains de mes collègues sont en prise avec cet outil depuis 2 mois. Et le moins qu'on puisse dire, c'est que la complexité du machin et la gestion des modules rendent son utilisation extrêmement lourde. Et pourtant, les fonctionnalités demandé par le site sur lequel ils travaillent ne sont pas extrêmement complexes.

En fait, ils se heurtent exactement au syndrome décrit plus haut : les 20% de fonctionnalités non prises en charge par les gros CMS prennent au final, 1000% + de temps à développer, que si on partait de rien.

C'est exactement la même chose avec eZpublish que j'ai eu le malheur d'utiliser sur l'un de mes projets.

Alors certes, les gros CMS àla drupal/ezpublish ont sûrement leurs avantages, grâce à certains mécanismes de mise en cache ou de gestion des utilisateurs, mais j'ai du mal à voir dans quelles situations ils seraient utiles.

Les systèmes de cache de drupal/ezpublish sont peut-être bien conçus en théorie (plusieurs niveau, gestion par block, etc), mais au final ils sont extrêment lourds et nécessitent du très gros matos.

Dans le cas de développement spécifiques, si des problématiques de charge se présentent, ils est infiniment plus facile d'y remédier avec un développement spécifique, car on sait comment faire, d'autant plus que c'est bien codé et commenté, ce qui n'est pas forcément le cas des gros CMS.

Pour les sites, j'utilise maintenant 2 solutions :

- Pour des sites de contenu : utilisation de CMS simples, tels que MODx ou Wordpress, pour avoir le socle basique permettant de publier le contenu en ligne, ce qui intéresse le client, suivi de développements spécifiques pour les fonctionnalités un peu compliquées.

- Pour des sites nécessitant de nombreuses fonctionnalités et d'actions sur la base : utilisation de framework simples, tels que Rails ou Cake

Anonyme a dit…

Bonjour,

article intéressant, mais...

Bien sur, avec un CMS on perd en souplesse. Bien sur, je suis d'accord avec la plupart des critiques que vous faites de Drupal.

Par contre, vous faites un gros résumé, en disant que les CMS sont tous php : certains sont en Java (ex. : Magnolia), en .NET (ex. : DotNetNuke), en ruby, en python, etc. Donc les critiques sur le code tombent à l'eau (bien choisir son CMS, c'est important)

A mon avis les CMS sont très utiles dans la mesure où ils répondent à un problématique relativement standard (publier du contenu) en une vitesse et avec une robustesse record (forcément, l'outil est utilisé par des miliers d'autres personnes).

Par contre je suis 100% d'accord pour dire que, dans certains cas, on comment une erreur en s'acharnant à vouloir utiliser un CMS pour une projet complexe, en collant des tas de rustines partout. Là, c'est une erreur d'outil, c'est essayer de planter un clou avec un tournevis.

En bref, vous ne pouvez pas dénigrer en bloc les outils de gestion de contenu. Ils ont permit et permettent à M. tout le monde d'arrêter de publier des pages HTML façon années 90 avec gifs clignotants. Et au niveau professionnel, ils couvrent une grosse partie des besoins. Alors, ils posent des problèmes, certes, mais ils apportent surtout beaucoup.

Dernier point : je ne m'estime pas être un professionnel désœuvré. Je pense bien travailler et généralement satisfaire les clients et/ou employeurs. Pourtant, je met en oeuvre un certain nombre des CMS.

Nicolas Guillaume a dit…

Le début de ce billet me rappelle ce que disaient les évangélistes de Microsoft (cela vaut aussi pour Sun)au sujet de Php dans le courant de cette décennie comme quoi quand on faisait de l'objet, on ne faisait pas du Php.
Après, cela me rappelle ce que disaient les développeurs qui s'occupaient des applications de gestion spécifiques dans les entreprise à la fin des années 90 : "nos besoins sont trop spécifiques pour mettre en place des progiciels".

Est-ce que Drupal et les CMS sont pour un public de non développeurs ?
Cette affirmation me parait très péremptoire. On peut dire la même chose de Php. C'est le langage de développement le plus répandu et le plus accessible. Faire du Php avec un framework n'est pas non plus très sélectif puisque généralement plus une technologie est packagée (par exemple sous la forme d'un framework), plus elle est accessible à des développeurs médiocres. Mais de même,je pense aussi que plus une technologie est "à la mode" (comme Drupal), plus on a de chance d'y trouver des développeurs médiocres.
Il y a certainement beaucoup de projets de CMS techniquement médiocres mais il y a aussi beaucoup de développements spécifiques médiocres en Php. Peut-on, pour autant en tirer des conclusions radicales en conséquence ?
Un développeur en assembleur est probablement un très bon développeur mais, à tout prendre, je préfère quelqu'un qui assemble des briques logicielles en tâtonnant (voir le commentaire rapporté au début).

Qu'il n'existe pas de projets d'envergure basés sur des CMS dont Drupal, je laisse consulter les sites respectifs des communautés.

La remarque sur l'"emploi déraisonnable de la base de données" me semble être une méconnaissance de ce qu'est le développement progiciel. Un progiciel bien développé se caractérise par des possibilités étendues de paramétrage qui conduisent à étendre de manière assez extensive le schéma de base de données. La construction d'un objet métier peut ainsi faire appel à un nombre surprenant de tables (d'autant plus surprenant quand on a l'habitude de "coder en dur" plutôt que de mettre en table). Pour situer les choses, il y a 10.000 tables dans SAP (source : http://www.thespot4sap.com/articles/Corporate%20Overview.asp)

Vaut-il mieux faire du développement spécifique ou utiliser un socle progicialisé ?
Sur cette question l'histoire est effectivement plus ouverte d'un point de vue technique. Si les progiciels de gestion se sont imposés, la tendance à la simplification a vu sombrer les progiciels web tel ATG Dynamo et Broadvision.
D'un point de vue utilisateur, il est néanmoins intéressant d'utiliser un CMS car cela permet de récupérer toute la partie d'administration du site (création, recherche, modification des différents types de contenus et des règles d'affichage, gestion des utilisateurs,...). Toutes choses qu'il est plus difficile de faire spécifier aux utilisateurs plus intéressés par la partie front-office (mais dont ils n'hésiteront pas à vous reprocher l'absence "pourquoi on n'a pas ça comme dans Wordpress ?").
Il me semble aussi très consommateur en temps de redévelopper toutes les mécanismes et options de publication, la gestion des droits, tout le paramétrage de l'affichage,etc. J'ai du mal à croire qu'un développement spécifique puisse être compétitif avec le travail centré sur le sujet de toute une communauté depuis plusieurs années.

Gauthier a dit…

@anonyme

>Par contre, vous faites un gros résumé, en disant que les CMS sont tous php
Je n'ai aucunement dit ça - simplement je ne parle que de ceux-là, car ça fait maintenant plus de 10 ans que je travaille exclusivement avec PHP, 8 heures par jour (les jours creux :)) Aussi je me garderais bien de donner un avis sur d'autres technologies que je ne maîtrise pas du tout.

>(forcément, l'outil est utilisé par des miliers d'autres personnes)
je dois avouer que les bras m'en tombent lorsque je lis des arguments pareils. Que répondre à ça ?

> permettent à M. tout le monde d'arrêter de publier des pages HTML
il ne m'avais semblé nécessaire de préciser que les considérations présentées dans ce billet ne concernent pas le site perso de M. tout le monde. Pour qui en effet, les CMS sont parfaits.

> je ne m'estime pas être un professionnel désœuvré
l'expression visait des gens qui ont eu la fumeuse idée de vendre à leurs clients du CMS lorsque ceux-ci avaient besoin d'une réalisation sur mesure. J'en avais exclu par exemple les web agencies.

@Nicolas Guillaume

> ce billet me rappelle ce que disaient les évangélistes de Microsoft [...] au sujet de Php
m'accuseriez-vous de m'en prendre à PHP ? Voici qui n'est pas commun :)

> Cette affirmation me parait très péremptoire
Je me demande bien pourquoi j'ai pris tant de temps à argumenter et expliciter ma position, si c'est pour que tout ceci soit qualifié d'affirmations quand il s'agit de constats.

> mais il y a aussi beaucoup de développements spécifiques médiocres en Php
et je n'ai jamais dit le contraire (c.f. "PHP, un éléphant aux pieds d'argile ?" dans le numéro de Programmez du mois de Juin)

> La remarque sur l'"emploi déraisonnable de la base de données" me semble être une méconnaissance de ce qu'est le développement progiciel
Comparer une application web à une application compilée me semble être une méconnaissance etc. etc.

> il est néanmoins intéressant d'utiliser un CMS car cela permet de récupérer toute la partie d'administration du site
Je maintiens que cette partie reste la portion congrue de la majorité des projets d'entreprise. Car c'est une fois le contenu stocké dans la base que commence le vrai challenge.

> J'ai du mal à croire qu'un développement spécifique puisse être compétitif avec le travail centré sur le sujet de toute une communauté depuis plusieurs années.
Et pour ma part je ne m'explique toujours pas le mystère par lequel Drupal a su et sait encore faire illusion de ses qualités.

Dernière chose... combien de Drupal avez-vous déployés ? A destination de combien d'utilisateurs ? Sous quelles conditions de charge ? Car apparemment Drupal est parfait et ce doit être moi qui ne sait pas m'en servir :)

Bref, j'ai exposé des faits, à partir desquels j'ai forgé une conclusion. Vous vous contentez de contredire cette conclusion sans contre-argumenter sur les faits, ce qui me semble dommage pour la qualité du débat.

Nicolas Guillaume a dit…

Pour préciser ma pensée :

J'ai entendu les mêmes arguments lorsque Php s'est développé sur le marché "c'est procédural, ce n'est pas objet. Ce n'est pas structuré, c'est développé comme un plat de spaghettis."
Pourtant, on sait maintenant que l'on peut réaliser des projets complexes (par example Facebook)et des progiciels (CMS, Gestion collaborative, CRM) avec du Php.
L'affirmation sur les CMS et Drupal est exactement de même nature (ce sont même les mêmes termes et pour Drupal c'est la même technologie sous-jacente).

Les CMS sont utilisés dans de très nombreux projets de sites de media et d'entreprise dont pour Drupal Fedex, Sun, la Nasa, Adobe, France 24, Harvard, etc, etc...
http://www.lektum.info/2009/05/08/references-mondiales-sous-drupal/
Ce ne sont pas des sites développés par des "non développeurs". Ce sont des sites complexes avec des volumétries importantes.

Pour reprendre les arguments :
- Ce n'est pas de développer en objet qui donne une garantie de bonne qualité (on pourrait aussi parler de compilé vs non compilé puisque est évoquée la "permissivité" du Php)
- Les problèmes de modularité c'est aussi la moitié de l'histoire de l'informatique.
- Sur les appels aux bases de données, c'est toute la différence entre du progiciel et du spécifique "codé en dur". Je ne vois pas ce que le compilé vient faire ici. Un CMS c'est un progiciel et il n'est pas nécessairement compilé et il existe d'autres progiciels développés en Php (ou dans d'autres langages non compilés) que l'on peut utiliser comme des applications web ou en interne d'entreprise.

Tout ce que vous dites est vrai mais cela s'applique aussi à un champ beaucoup plus large que celui que vous considérez. Et par ailleurs, il existe d'autres faits, tout à fait significatifs, qui vont en sens inverse de vos conclusions.

L'affirmation "les CMS sont conçus uniquement pour un public de non-développeurs" est bien péremptoire tant du point de vue de la technologie que des projets.
Je prends l'affirmation "Pourquoi je déteste Drupal (et la plupart des autres CMS)" comme du ressort de l'opinion et non du fait.

Il y a certainement des mauvais projets menés par des mauvais développeurs utilisant des CMS dont Drupal mais je ne vois pas ce qui permet d'en faire une règle générale. Cela ressemble plutôt à de la guerre de chapelle au mépris de toute rigueur intellectuelle.

Je ne suis pas un développeur, je n'irai pas argumenter sur le dernier hook ou le module à la mode. Dans notre cas, nous avions besoin de développer un service avec une plateforme sociale qui gère des contenus complexes générés par les utilisateurs, des profils multiples avec des vues et des fonctions différentes sur les contenus et des groupes privés d'utilisateur. Nous avons fait un appel d'offre à l'issue duquel sont arrivés en short-list une solution Drupal et une solution en développement spécifique. Le volume de charge était bien supérieur avec la solution spécifique. Nous avons pris Drupal pour ce qu'il savait faire (gestion des contenus et plateforme sociale) et nous l'avons complété par des développements dans Drupal (dont un véritable workflow). Je n'ai jamais dit que Drupal était parfait (c'est un concept qui n'existe pas dans l'informatique) mais dans notre cas je n'ai pas vu d'alternatives réellement crédibles.

Gauthier a dit…

@Nicolas Guillaume

> Je ne suis pas un développeur
d'où le quiproquo... car sans être développeur vous souhaitez à tout prix contredire un développeur, c'est assez difficile, non :)

Quant aux exemples de projets apparemment réussis avec Drupal, ils ne contredisent pas non-plus mes propos.

Je n'ai pas dit qu'il était impossible d'obtenir un résultat avec ces solutions, j'ai dit, en substance, que c'était plus malcommode, plus long, et moins souple.

En tout cas, je peux vous dire que pour ma part, avoir travaillé sur ces solutions a été une véritable punition... et je ne suis visiblement pas tout seul :)

Nos objectifs sont donc différents : je tâche d'expliquer en quoi des solutions, qui au demeurant présentent certaines qualités, sont trop souvent employées de manière inadaptée. Quant à vous... j'avoue que je m'interroge :) Vous ne vendez apparemment pas de Drupal, vous n'êtes pas du métier, donc non qualifié pour ce débat, alors vraiment, je ne vois pas ce qui vous incite à prendre la défense de Drupal, si ce n'est peut-être vous rassurer sur les choix que vous avez faits.

Pour finir, je ne peux en revanche pas laisser passer ceci :

> Je prends l'affirmation "Pourquoi je déteste Drupal (et la plupart des autres CMS)" comme du ressort de l'opinion et non du fait.

N'auriez-donc lu que le titre de mon billet ? et encore, en ignorant le premier mot ! Evidemment, "Je déteste Drupal" aurait été très différent de "Pourquoi je déteste Drupal".

Fibo a dit…

@Gauthier
"Partir du principe que l'on peut se permettre de gâcher des ressources car elles ne coûtent pas cher ne me semble par ailleurs pas vraiment dans l'air du temps : fais-tu la même chose avec le pétrole ? De la même façon, un code ne peut être durable (comprendre "maintenable" et "évolutif") que s'il a été conçu correctement, avec cette préoccupation en tête, plutôt que de se dire que si jamais ça patine, il suffira de gonfler le serveur.... jusqu'à ce qu'il éclate ?"
Le prix du pétrole ne fait qu'augmenter et c'est une ressource qui va se raréfier.
La puissance des ordis et de leurs accessoires va continuer à baisser sur la même période (et vraisemblablement se stabiliser après). C'est une dimension essentielle même si elle va contre nos réflexes intellectuels. Sans cela, il n'y aurait pas autant d'utilisation grand public: GPS, MP3, smartphones, meilleure météo, etc. Cette augmentation de puissance ne règle pas tout et je n'ai jamais dit "programmons mal, la puissance de l'ordi y pourvoira".
Simplement, il faut trouver le meilleur compromis POUR LE CLIENT, celui qui en payant la note nous fait vivre. Parfois il vaut mieux utiliser une technologie qui marche en 3 jours quoique techniquement imparfaite, plutôt que prendre 10 jours pour développer la technique parfaite qui marchera avec 20 secondes de CPU/ jour au lieu des 70 secondes/ jour de l'autre techno.
Bien sûr, si l'on est à des milliers de secondes de cpu par jour... faut regarder... mais là encore ne pas oublier d'étudier l'option "cpu plus chère mais plus puissante".

"> Je ne suis pas un développeur

d'où le quiproquo... car sans être développeur vous souhaitez à tout prix contredire un développeur, c'est assez difficile, non :)"

Certes. Euh... désolé je n'avais pas compris que le problème posé ne concernait que les développeurs.
Il est évident que dans ce contexte il ne peut y avoir la moindre discussion: un développement propre avec un framework propre sera toujours plus propre qu'un CMS tout prêt (et résultant donc forcément de compromis, voire de médiocrités, techniques)

Du coup, le contexte du blog, que je pensais orienté vers "le logiciel libre en tant que principe", me paraît bien différent de la discussion ici (j'exagère dans mon raccourci) "le logiciel libre c'est moins bien que du bon framework" que l'on pourra ainsi appliquer à tout développement php hors framework.

Oaz a dit…

Bonjour,

Je ne suis pas un professionnel du web mais ce billet et les commentaires qui précèdent me parlent car ils me font penser à un problème plus général que l'opportunité d'utiliser ou non un CMS.

Si j'ai bien compris, ce drupal bénéficie d'une forte part de marché et nombre de développeurs sont contraints, à regret, de s'y plonger
- parce qu'un développeur précédent a voulu faire vite et pas cher. Il a pris un drupal prêt à l'emploi et il a bricolé un truc répondant au besoin immédiat du client sans se soucier de l'évolutivité de la chose
- ou parce qu'un client n'a pas voulu réaliser un investissement dans la durée et a préféré, bien renseigné par des geeks d'école primaire, imposer une solution supposée marcher rapidement pour pas cher
- ou pour toute autre raison du même acabit

Ces choix posent un problème fondamental dans la relation entre un client et un prestataire en développement logiciel.
Est-ce qu'un tel client se comporte de même en allant chez son médecin et en réclamant tel médicament plutôt qu'un autre (sur la recommandation de la mère du petit cousin de CM2 qui n'est pas plus médecin que lui) ?
Est-ce qu'un tel client se comporte de même avec son chauffagiste, qui lui conseille une chaudière A pour sa robustesse, en choisissant la chaudière B qui est très bien parce que son beau-frère a la même et elle coute 3 fois moins cher ?
Mais ce n'est pas tout.
Est-ce que le médecin répond favorablement à la demande même si cela peut causer un grave problème de santé compte-tenu des antécédents médicaux du client ?
Est-ce que le chauffagiste répond favorablement à la demande en se disant que ça fait toujours une commande de gagnée et que si le client doit changer à nouveau sa chaudière dans 2 ans, ce n'est pas vraiment son problème ?

Pour le médecin, la réponse est évidente. Il respecte une déontologie, une éthique et il y a un ordre des médecins qui veille.
Poiur le chauffagiste, l'évidence est moindre. Il y en aura de bons qui se soucieront de l'investissement de leur client dans la durée et il y en aura de moins bons qui prendront l'argent là où il est. Les seconds, s'ils travaillent dans une zone géographique bien définie, auront rapidement des problèmes avec leur réputation et songeront peut être à changer de métier.

N'est-ce pas, in fine, le problème du développement logiciel, activité hautement artisanale par bien des aspects, que de ne pas avoir une profession un peu plus structurée ?
La capacité à modifier quelques lignes de php dans un paquet de fichiers plus ou moins bien écrits ne fait pas d'un individu lambda un "artisan développeur", soucieux des règles de l'art de son métier, qui écrit du code vérifié, lisible, compréhensible et malléable.
L'absence de code déontologique garantissant le respect d'une éthique de développement nuit à tous ceux qui se soucient des investissements de leurs clients et profite à ceux qui offrent monts et merveilles avec du rapide pas cher.
La réalisation d'un logiciel à façon (que l'on se base sur un CMS, un framework ou n'importe quoi) est une activité où le coût principal provient du savoir faire humain que l'on y met.
Dans cette activité plus que dans beaucoup d'autres, il est très facile de livrer quelque chose et de le faire passer pour un bon investissement alors que ce que n'est qu'un truc qui devra être jeté à la moindre velleité d'évolution.

----

A part ça, j'ai bien rigolé avec l'article sur les concepts OO dans drupal.
Faire passer les extension methods de C# pour un concept OO majeur qui est disponible dans drupal mais pas dans PHP, il fallait le voir pour le croire.
La partie sur les design patterns vaut aussi son pesant de cacahuètes puisque qu'elle explique comment ce drupal résout les problèmes classiques rencontrés en conception objet, sans faire appel à de la conception objet.

Gauthier a dit…

@fibo

> il faut trouver le meilleur compromis POUR LE CLIENT, celui qui en payant la note nous fait vivre

voici des paroles qui sonnent comme celles d'un indépendant, me trompé-je ? En tout cas, pour ma part, et même durant les nombreuses années pendant lesquelles j'ai été indépendant, ce que veux le client ne m'intéresse pas - en ce sens que la seule chose qui compte est ce dont il a besoin. Et c'est mon métier de le lui dire. Et je te prie de croire qu'il y en a plus d'un à qui j'ai dit des choses du genre "désolé, mais ce n'est pas mon rayon - adressez-vous à x ou y, ils font ça très bien. Ne confondons pas les métiers de développement d'applications (certains sites en sont à part entière) et de simples sites corporate et/ou communautaires qui n'ont pas du tout les mêmes besoins. (@oaz nous sommes donc d'accord :))

> la technique parfaite qui marchera avec 20 secondes de CPU/ jour au lieu des 70 secondes/ jour de l'autre techno.

désolé, je ne parle en aucun cas de ce genre de sites :) en outre, je le répète, quand je parle de problématiques de charge, je parle de manière globale, et non pas de CPU. 9 fois sur 10 ce sont les connexions trop nombreuses vers la base de données ou les entrées/sorties qui font ramer voire péter les serveurs web.

> "le logiciel libre c'est moins bien que du bon framework"

je suis désolé de rejeter une fois plus cette objection : ai-je évoqué le moindre framework propriétaire ? PHP n'est-il pas libre ? Zend Framework n'est-il pas libre ? symfony, CakePHP, etc. ne sont-ils pas libres ? Opposer frameworks et logiciels libre est une sottise, pardonne-moi de te le dire aussi sèchement.

Honnêtement, Drupal fait partie de ces logiciels qui font passer le logiciel libre pour du bout de ficelle, et je lui en veux d'ailleurs pas mal aussi pour cette raison.

L'essence du logiciel libre, c'est viser l'excellence sans contrainte commerciale. Sans compromis, et surtout sans compromission. Et c'est pour cette raison qu'il est intéressant, et non pas "philosophiquement".

Si tu veux en savoir plus quant à ma position concernant le logiciel libre, je t'invite à lire ce billet, qui t'apprendra entre autre pourquoi ce premier post date du 27 Septembre 2008... etaprès on rediscutera de logiciel libre :)

Nicolas Guillaume a dit…

> Je n'ai pas dit qu'il était impossible d'obtenir un résultat avec ces solutions, j'ai dit, en substance, que c'était plus malcommode, plus long, et moins souple.

J'en conviens tout à fait. Mais j'ai entendu ce type de remarques, il y a un certains nombres années "pourquoi des "vrais" développeurs développent-ils en Php ?" (sous-entendu au lieu d'utiliser du C++, C# ou Java) avec toute la tirade sur la permissivité des variables, le fait que ce soit non compilé, que le code ne puisse pas être édité, etc.
Ces remarques étaient tout à fait justes (comme les vôtres) mais aujourd'hui avec le recul c'est plutôt positif que l'on ait continué d'utiliser cette technologie si imparfaite. Elle a continué de progresser et a franchit les barrières dont on avait dit qu'elles étaient impossibles à franchir.

Ces affirmations me rappellent aussi ce que j'ai entendu venant d'un développeur Ruby. Celui-ci rejetait toutes autres technologies de développement arguant de la perfection de la lisibilité et de la compacité du code.

C'est probablement vrai aussi mais au final, "l'optimalité" de la technologie de développement n'est pas déterminant pour un projet.

Quand on me dit "Drupal" (ou n'importe quel autre CMS) ne satisfait pas la bonne pratique d'éviter les variables tant ou n'est pas orienté objet, cela n'a aucun implication concrète pour moi en tant que client et ne m'aide pas du tout à faire un choix.

Ce qui est bien plus important c'est la disponibilité des compétences pour le développer et en réaliser la maintenance et les évolution,l'existence de références de projets avec un périmètre fonctionnel comparable, la possibilité de bénéficier de retours d'expérience d'autres utilisateurs, la capacité à l'exploiter (techniquement et fonctionnellement - c'est là où la pré-existence de modules d'administration est importante), l'existence d'une communauté qui permet de résoudre les problèmes et de continuer à faire évoluer la technologie.

A contre exemple, je connais aussi des projets développés en spécifique (dont notamment un développé en Ruby, a priori sur la base du framework Ruby on rail) dont les évolutions majeures ont été difficiles (celui en Ruby a été abandonné pour être entièrement redéveloppé - en Php d'ailleurs - la lisibilité du code ne l'a pas sauvé).

Pour la forme :
> Je ne suis pas un développeur
d'où le quiproquo... car sans être développeur vous souhaitez à tout prix contredire un développeur, c'est assez difficile, non :)
et
> vous n'êtes pas du métier, donc non qualifié pour ce débat,
Ça c'est un argument d'expertise.

>Je me demande bien pourquoi j'ai pris tant de temps à argumenter et expliciter ma position, si c'est pour que tout ceci soit qualifié d'affirmations quand il s'agit de constats.
Ça c'est un argument d'autorité.

Le type d'argument que l'on sort lorsque justement on est à court d'argument.
C'est de bonne guerre puisque nous sommes dans une discussion polémique. Mais néanmoins ça ne contribue pas du tout à faire avancer le sujet.

Nicolas Guillaume a dit…

Le commentaire était trop long, la suite :

Pour répondre à la question posée, Pourquoi je participe à ce débat :
- Parce que j'ai déjà entendu ce débat et que je trouve dommage que l'on ne profite pas des leçons de l'histoire de l'informatique.
- Parce que je trouve les conclusions tirées exagérées par rapport aux arguments présentés et mériteraient d'être sérieusement nuancées. J'ai échangé avec un certain nombre de développeurs et certains m'ont paru de grande qualité. Je ne pense pas qu'ils se soient orientés vers Drupal par hasard et cela ne me parait pas très compatible avec l'affirmation de ce billet.
- Parce que mon ami qui m'a indiqué ce lien partage votre opinion (sur des bases un peu différentes) et que c'est l'opportunité d'argumenter ma position.
- Parce que je sais que c'est une tendance pour les développeurs d'argumenter leur choix sur des considérations techniques incompréhensibles (voire même parfois qu'ils rendent incompréhensibles) pour le profane. Mais il n'y a pas que ça qui compte !

En tout cas félicitations pour votre blog, c'est bien écrit, réactif et punchy !

Gauthier a dit…

> [Cette technologie] a continué de progresser et a franchit les barrières dont on avait dit qu'elles étaient impossibles à franchir.

Vous mettez pour moi le doigt là où ça fait mal :) Tous ces efforts qui ont été faits ces dernières années pour faire de PHP une technologie "respectable" et "business compatible" ne l'ont pas été fait par Drupal. C'est précisément pourquoi ce CMS reste la cible de critiques qui vous semblent éculées, et qui sont pourtant toujours d'actualité le concernant.

Je reviens rapidement sur un argument développé dans mon billet original : l'impossibilité de disposer d'environnements répliqués à 100%. Ceci proscrit la mise en oeuvre d'une usine logicielle conforme aux standards dictés par l'expérience, et le simple bon sens. Vous qui semblez être au courant, vous devriez être conscient que PHP a beaucoup plus été décrié pour l'absence de méthode et de rigueur de ses développeurs que pour les défauts intrinsèques du langage. Ce qui était parfaitement fondé (j'ai fait partie de ces développeurs suffisamment longtemps pour en attester :) !

> cela n'a aucun implication concrète pour moi en tant que client
Si car le choix d'une plateforme inadaptée amènera votre prestataire à vous répondre "non, je suis désolé mais la modification que vous me demandez ne peut être faite qu'au prix d'un temps de développement indécent". Parce que si elle ne peut être prise en charge par le module concerné, il va falloir soit contourner largement, soit même tout redévelopper, avec comme base un framework qui n'en est pas un.

> et ne m'aide pas du tout à faire un choix.
En tant que client, je le répète, vous ne devriez pas faire de choix technologique : seuls vos besoins comptent - y compris l'ergonomie, la possibilité de maintenir le code, etc. C'est pour faire ce choix que vous faîtes appel à un prestataire de service. Evidemment, si vous n'avez dès le départ aucune confiance en son intégrité (ambiance "il me propose du sur mesure juste pour faire exploser le nombre de jours" ...)

> Le type d'argument que l'on sort lorsque justement on est à court d'argument.
que j'associe à
> c'est une tendance pour les développeurs d'argumenter leur choix sur des considérations techniques incompréhensibles

Non, pas du tout - simplement mes arguments ont déjà été exposés, et j'attends toujours qu'ils soient réfutés :) Je ne voudrais pas me répéter inutilement (c.f. la première partie de ce commentaire cependant).

>En tout cas félicitations pour votre blog, c'est bien écrit, réactif et punchy !
Je ne peux que vous remercier, et saluer votre "sportivité" :)

Rouzik a dit…

J'aurais pu écrire cet article tant il rejoint ce que je pense de Drupal et de la plupart des CMS. Ce sont pour la plupart des outils pour les non développeurs, outils qui n'ont jamais repris les concepts plus plus professionnels appliqués depuis quelques années à PHP pour lui donner plus de crédits. Dans la plupart des projets, partir d'un bon framework, c'est s'assurer une réalisation non bancale.

Heureusement qu'il reste quelques exceptions genre Joomla (1.5 et plus) intégralement en objet, MVC, reposant sur un véritable framework et ne multipliant pas les requêtes SQl à foison (mais il y a encore des progrès à faire). C'est l'une des rares applications PHP dont la core team a eu le courage de tout réécrire à zéro. Ceci explique cela. Malheureusement pour Joomla, jusqu'à la version 1.6 (qui sort bientôt) il n'est pas aussi modulable que peuvent l'être d'autres CMS genre Drupal. Avec cette dernière version, il devrait devenir un CMS presque parfait pour les développeurs comme pour les utilisateurs. A voir.

Unknown a dit…

Bonjour,

Un bon article de critique des CMS je dois l'avouer... mais ceci avec la casquette de developpeur.

Je conduits un certain nombre de projets web basé souvent sur des CMS.
A chaque projet et problematique son CMS.

Je travail donc sur Wordpress, Wordpress MU (pour une plateforme de generation de mini site), Joomla, Drupal, Typo3, Prestashop...

Dans toute solution, il y a ses defaut. Ces defauts d'un point de vue projet peuvent aussi etre leur force à savoir :
-Utiliser un CMS du monde du libre s'est ne pas de rendre 100% dépendant du prestataire qui vous l'aura developper à sa façon.
- Comme dans tout projet web, il y a des bugs, les cms n'en sont pas exempt bien sur, mais c'est pourquoi le choix d'un cms en fonction de sa communauté est tres importante (pour debuggage pour les non dev)
- Drupal sur les projet d'ampleur est encore "jeune", mais arrive grave a une architecture assez innovante. Je vous encourrage à regarder ce qui se fait de plus lourd et complexe dans les cms avec TYPO3 qui reste pour moi à ce jour le meilleur des cms.

Amicalement

PooLP a dit…

Article un peu réducteur qui fait croire que tous les CMS se comporte comme Drupal ... et concernant ce dernier, pourquoi vouloir faire courir une 2CV sur une piste de formule 1, chaque projet à des besoins précis ! Drupal n'est fait que pour de simple site Web !

Mickaël a dit…

Là où je rejoins parfaitement votre avis c'est sur le point 3 "Un emploi déraisonnable de la base de données".

Devant le succès que rencontre Drupal, j'ai donc tout naturellement cherché à évaluer le potentiel de ce CMS et à reproduire avec lui les modes d'organisation que nous avons sous TYPO3 depuis des années : développement coopératif, versionning base et fichiers, plateformes de développement/recette/production...

Et là, je me suis confronté à un point qui me semble rédhibitoire avec Drupal. Tellement d'actions sont réalisées en base de données qu'il devient impensable d'adopter la même logique d'organisation car il faut reproduire encore et encore manuellement les mêmes actions en base pour faire passer les développements de leurs serveurs de développement vers la recette et une nouvelle fois en production... là où avec TYPO3, la programmation et configuration du site se fait dans des fichiers et les contenus sont en base de donnée, ces passages deviennent quasi automatisés via des scripts shell se connectant aux différents repository Subversion/Git...

Enfin, quand on sait que le core de Drupal effectue dans quasiment chaque release importante des changements en profondeur de son API rompant ainsi toute compatibilité avec des modules développés pour les versions antérieures... on se demande comment on peut envisager des développements spécifiques pour les clients.

Enfin, ce n'est qu'une opinion forgée après seulement une grosse dizaine d'heures d'essais et quelques livres engloutis sur Drupal. Je serai heureux d'apprendre que ces limitations peuvent être contournées et qu'elles sont dues à une méconnaissance du CMS (comme on peut voir certains avis sur TYPO3 après seulement quelques heures d'utilisation...).

Je reprendrai alors mon exploration de Drupal, mais ce genre de posts et les recherches que j'ai pu faire sur ces points semblent malheureusement confirmer cet état de fait.

Gauthier a dit…

@PoolP c'est vrai j'évoque "la plupart des CMS" dans le titre du billet. Il ne vous aura cependant pas échapper que c'est essentiellement de Drupal que je parle lorsque j'avance des faits concrets.

Concernant les autres, je l'ai dit et je le répète, je n'ai que peu d'expérience dessus, pour les raisons suivantes :

- cela fait déjà bien longtemps que j'ai fait les constats exposés dans le présent billet, par voie de conséquence, je n'ai pas touché de moi-même au moindre CMS depuis une éternité.

- j'ai été eu récemment a travailler, à deux reprises sur des projets Drupal (importants, avec de grosses équipes et des moyens).

Voilà pourquoi c'est lui qui prend :) Mais d'après les souvenirs que j'en ai, ainsi que pour des raisons structurelles qui me semblent incontournables, je pense que "la plupart" (et j'insiste sur le fait que je ne dis pas "tous") des autres CMS souffrent peu ou prou des mêmes défauts.

Avant qu'on me pose la question, ce que j'entends par raison structurelle c'est principalement la tentative d'extrapoler et de généraliser un maximum de traitements. Ceci a pour conséquence inévitable une inflation très importante de la complexité du code. C'est celle-ci qui handicape ensuite les ajouts personnalisés qui se doivent de rester bâtis sur la même base pour des raisons évidentes de cohérence.

Ti Aya a dit…

Mon avis est qu'au fond, le contenu de cet article ne concerne que Drupal et quelques autres comme Joomla, mais absolument pas tous. Les auteurs de cette catégorie de CMS, dès leur conception, ont mis l'accent sur la facilité de prise en main par un non-developpeur, au détriment d'une architecture interne cohérente. C'est d'ailleurs ce qui a fait leur succès auprès du grand public. D'ailleurs ils devraient leur être exclusivement réservés. J'ai toujours trouvé cela aberrant pour des professionnels d'utiliser ces CMS, dont on sait très bien que la personnalisation n'est pas leur première qualité. Sur ce point, des CMS comme MODx ou encore Silverstripe, que l'on définit souvent comme des CMF (F pour Framework), me semblent plus adapté. Les fonctions de gestion de contenu y sont une couche au dessus dessus d'une API qui n'est rien d'autre qu'un framework.
A ce propos, un mot sur Typo3. Il est clair qu'à une certaine époque, c'est un CMS qui faisait office de pionnier, avec les possibilités offertes par le typoscript. Mais aujourd'hui, je ne pense pas que la complexité inhérente soit encore justifiée. Silverstripe par exemple offre la même puissance, mais avec une api en PHP pur, plus facile à apprendre.

Pour terminer, il y a la question de savoir à partir de quel moment un projet cesse d'être un site web, pour devenir une application web. Car si pour les premiers l'usage d'un CMS est plus adapté, pour les seconds il vaut mieux utiliser un bon framework, du genre Zend ou Symphony.

Lovelive a dit…

Beaucoup trop de commentaires pour que ça soit lisible, mais si l'article est largement meilleur que la grande majorité des articles anti-Drupal, il y a quelques détails qui sonnent troll (vecteur d'audience) ou mésinterprétation.
Certaines choses marquées comme impossibles ou cauchemardesques peuvent être faites avec méthode, voire être faites sans toucher au core ou à un module.
Certains qualificatifs aussi sont je pense délibérément dédaigneux. Mais même en étant attaché à Drupal, beaucoup de points cités ici tiennent carrément la route. Ce qui me choque le plus étant la façon de gérer les hooks; c'est sympa c'est pratique (à mon sens), mais dieu ce que c'est évident que ça ralentit tout, pour peu que l'on soit « obligé » d'activer un peu trop de modules.
Bon, coup de chance, pour moi Drupal et PHP 5.2 (habillés de modules) arrivent à être plus rapides qu'un Ruby on Rails par exemple (nu). Dommage, parce que Ruby on Rails, c'est un framework sympatoche (vu de loin, je n'ai pas essayé de creuser).

Falafelschtroud a dit…

Bonjour,

je pense que j'aurais pu écrire cet article...je suis chef de projets en SSII sur les CMS opensource (java et PHP) et le constat est le même, bosser avec Drupal est cauchemardesque.

Pour moi le principal problème vient de l'impossibilité d'industrialiser les développements et ce principalement à cause du sur emploi de la base de données comme c'est mentionné.
Ajoutez à cela les nombreux bugs, les failles de sécurité à foison, le multi site qui n'en a que le nom, le multilingue qui marche aussi bien que le multi site et le tout épaulé par pléthore de modules qui marchent bien quand ils le décident.
De notre coté, parfois, les client imposent le CMS, donc pas le choix mais pour le coup dès qu'on le peut, on utilise une solution OpenSource Java qui sépare correctement contenus (XML) et contenant (et qui de surcroît est extrêmement modulaire).

Sur ce, je retourne m'arracher les cheveux sur la procédure de migration que nous allons proposer au client pour la V2 de son site en Drupal.....

Anonyme a dit…

Très bon article pour ceux qui s'intéressent au CMS Drupal sans prendre le temps de savoir vraiment s'en servir.

Unknown a dit…
Ce commentaire a été supprimé par l'auteur.
Unknown a dit…

Quel buzz, bravo.

Décrier un outil informatique sans dire pour quel usage on l'utilise, On crois rêver !
C'est comme dire 'je hais les marteaux (et la pluspart des outils manuels)'
car les marteaux ont souvent un manche en bois qui casse facilement'
car les marteaux ne permettent pas de casser des blocs de béton'
car les marteaux s'usent vite et laissent des traces sur le mur'

Et non drupal n'est pas fait pour faire du café, des house de couettes, des distributeurs de haribots ! Belle observation.

Aillant travaillé plusieurs années dans l'architecture technique bancaire et utilisant aussi drupal, je nie ce point de vue.

Cet auteur, à ses dires, n'arrive pas à comprendre l'angouement de la communauté drupal : Là est le point essentiel de ce post !
- A-t-il déjà travaillé dans une communauté ? Je ne pense pas, ses framework ne doivent pas être open source (.non..).
- A-t-il déjà vu et fait un logiciel utilisé par des milliers de personnes et devant être retro compatibles et durer sur une dizaine d'années ? hum hum
- Voit-il ce qu'il y a de remarquable dans ce phénomène ?

Mais cet auteur a observé des défaillances qu'il pose comme arguments décifs ayant des conséquences générales.
Je commente ses dires :
- "approche procédurale"
> Aucun argument valable dans ce chapitre, que de la polémique, plutôt dénigrant en plus. Vous n'ignorez pas que le typage fort introduit d'autres problèmes, je suppose.

- "étrangement, la communauté préfère réaliser deux modules disposant chacun de 3 fonctionnalités plutôt qu'un seul doté des 6"
> oui, rien compris aux principes fondamentaux de drupal visiblement. Il faut bien voir que ces deux modules seront utilisables potentiellemnt par 10 autres modules (contrairement à 1 seul module)...
C'est un principe de base dans drupal, ce qui en fait aussi sa complexité,son intérêt et sa force, et que malheureusement très peu de gens comprennent !

- "cette vilaine manie qu'ont les développeurs de recourir aux patches pour appliquer leurs modules..."
> pas faux, ça arrive... mais pas sur les modules essentiels (encore aucune référence concrète de l'auteur..).

- "le recours à l'appel "à l'aveugle" de fonctions via call_user_func(), dans le.."
> pas faux non plus, mais c'est pas une généralité, et l'auteur ne précise pas où comme d'habitude..

- "j'ai souvent vu des pages de sites Drupal nécessiter de 400 à 1000 requêtes SQL pour être générées.."
> L'auteur ne cite pas ses sources (comme d'habitude). ça ne veut donc strictement rien dire.
Avec un framework, on peut très bien arriver à la même chose sur des pages complexes..sans blague.

moi aussi, j'en aurai beaucoup plus à dire sur ce post, mais j'arrête là.
Il dit que ce sont des constats : ok. Moi, je ne suis pas d'accord avec les conclusions de ses constats.

Gauthier a dit…

Je ne vais passer trop de temps à répondre à une argumentation (en est-ce vraiment une ?) aussi fantaisiste, et surtout qui pose des questions dont la plupart des réponses sont dans mon post original, mais je tiens quand même à clarifier certains points.

Alouest, assurément tu devais l'être lorsque tu as lu mon article :)

> ses framework ne doivent pas être open source
je te repsoe la question à l'envers : peux-tu me présenter un framework PHP propriétaire, ça m'intéresse et je n'en connais pas :)

> devant être retro compatibles et durer sur une dizaine d'années
Drupal retro compatible ? C'est désopilant :D

> Vous n'ignorez pas que le typage fort introduit d'autres problèmes, je suppose.
Opposer la question du typage à celle du paradigme est très curieux. Que l'on fasse du procédural ou de l'objet, PHP reste typé dynamiquement...

> Il faut bien voir que ces deux modules seront utilisables potentiellemnt par 10 autres modules
Je parlais de modules aux fonctionnalités identiques, ou pour le moins similaires. S'il te semble intéressant d'utiliser un module de newsletter en conjonction avec un autre module de newsletter, libre à toi. Moi je préfère n'en avoir qu'un seul :)

> pas faux, ça arrive... mais pas sur les modules essentiels
mais ils sont tous essentiels ! au moins pour quelqu'un sinon, ils n'existeraient pas, tu ne crois pas ? La qualité n'est donc pas constante, et employer un module demande beaucoup d'attention et d'étude d'impact...

> et l'auteur ne précise pas où comme d'habitude..
en tant que consultant, il serait tout de même indélicat d'étaler sur la place publique les "petits secrets" observés chez mes clients, cela ne t'aura pas échappé.

> Avec un framework, on peut très bien arriver à la même chose sur des pages complexes..sans blague.
Certes (encore que il faut quand même beaucoup d'imagination pour trouver le moyen d'exécuter 1000 requêtes SQL pour une seule page), mais das cecas, il faut tout simplement changer de métier :)

> Moi, je ne suis pas d'accord avec les conclusions de ses constats.
Et ceci me va très bien, ce qui me gêne dans ton commentaire, c'est que tu réfutes mon argumentation sans proposer de contre-argumentation.

En résumé, quand je dis "c'est mal pour tel et tel raison ...", tu ne peux pas te contenter de me répondre "si c'est bien, tu as tort".

PS : on avait évité jusque-là le ton trollesque pour rester sur un plan le plus objectif possible. Il serait bon de poursuivre dans cette voie. Est-il besoin de préciser qu'il est absurde de prendre mes observations sur Drupal pour des attaques personnelles aux utilisateurs de Drupal ?

Unknown a dit…

Désolé pour le ton trollesque voire confus, j'étais un peu bourré quand j'ai écrit ce post :).

Je ne dis pas "si c'est bien, tu as tort", je dis que je ne suis pas d'accord avec tes conclusions.
Ton argumentation est basée sur des constats égrenés ici ou là et avérés, ils ne se prêtent pas à des sortes de contre constats..

Je crois simplement qu'effectuer une analyse critique d'un soft sans dire pour quel usage et comment on s'en sert, interdit de facto de conclure objectivement.

Lovelive a dit…

Hello Gauthier,
Je retombe ici et je rebondis là-dessus :
Certes (encore que il faut quand même beaucoup d'imagination pour trouver le moyen d'exécuter 1000 requêtes SQL pour une seule page), mais das cecas, il faut tout simplement changer de métier :)
Je connais au moins un exemple de Drupal pour lequel une page pas particulièrement compliquée (utilisant Views) appelle sans problème 400 requêtes, dont un bon 2/3 venant de modules (dont du core) qui ne devraient pas être utilisés dans la page. Des fois, les mêmes requêtes sont appelées plusieurs fois par page, ce qui va avec l'idée qu'on ne maîtrise pas vraiment le workflow avec les hooks.
Alors coup de chance, il existe QueryCache dans MySQL, heureusement, ce qui permet d'exécuter ces 400 requêtes en peu de temps.
J'ai réussi à rendre un Drupal agréable à naviguer (excepté pour certaines pages), mais je sais qu'il aura énormément de mal à passer les 100 utilisateurs concurrents. Et ceci pour des problèmes de mémoire (il arrive à Drupal de manger trop de RAM avec pas grand chose : être obligé de mettre une limite de mémoire par script à 256Mo ou plus pour éviter des écrans blancs, c'est très grave. Et c'est dû à l'architecture de Drupal.)

Lovelive a dit…

Ah, encore une chose qui énerve dans Drupal. On suppose qu'on essaie de créer une page pour renvoyer des réponses JSON (ou XML). Cette page doit accéder à la base de données Drupal pour renvoyer des données.
Pour chaque requête à la page il faudra lancer le bootstrap de Drupal (on peut choisir ce qu'on veut exécuter dans le bootstrap, mais il y a un minimum); il le faut pour pouvoir utiliser l'API de Drupal. (et ça m'étonnerait pas que ça génère des hits à la base de données)
Donc un module de tchat "natif" pour les membres devient assez vite très lourd, même avec un memcache/APC/etc.
Un module sur Drupal.org qui propose un tchat pose de nombreux problèmes de performance : pour même pas 10 utilisateurs concurrents, la consommation CPU et les performances sont catastrophiques.
Et malgré tout ça, j'aime Drupal.
Mais j'aime encore plus Django, en ce moment.

Unknown a dit…

Hello,

Comme ici, on n'arrive pas visiblement à sortir de la bête, et à ne pas parler de l'usage et des fins..
Je pose une question toute conne (oui conne) :

est-ce que la maison blanche (http://www.whitehouse.gov/) a eu tort d'utiliser drupal pour son site ?

quelqu'un peut-il dire quelque chose la dessus ?

Unknown a dit…

Comme je pointe mon nez ici, on va dire tous les dix jours pour y voir, et comme le thread m'intéresse ainsi que les propos de l'auteur, j'en remets un petit coup.

1- Tous les soft ont des défauts, mêmes les custom (et pour des raisons peut-être différentes).
2- pour des petits projets web, les solutions custom sont hors de prix par rapport à des solutions genre drupal
3- Pour des gros projets web, complexes, drupal peut (peut-être) répondre si les intervenants maitrisent très bien drupal (condition nécessaire, rarement réalisée apparemment)
4- ça veut dire quoi maitriser une techno ? Pour drupal, selon moi, ça veut dire savoir comprendre le code (et oui, ligne à ligne) de chaque module et en déduire sa petinence dans le projet (a minima)
5- conséquences : dans les projets complexes, faire la part des choses, et prévoir de "gérer les choses soi-même" le cas échéant.

Je souhaite éviter la grossièreté (imminente ici) qui dirait que drupal est mauvais 'en soi'.

Merci

tetrahead a dit…

J'attendais le coup de la Maison Blanche... Si même la Maison Blanche utilise Drupal alors on n'a plus qu'à s'incliner...

Anonyme a dit…

Drupal est loin d'être parfait, c'est un outil à disposition, qui plus est gratuit. Il faut avoir en effet une connaissance un peu poussé de Drupal pour qu'il puisse faire gagner du temps. Je développe sur tout un tas de plateforme (CMS, Framework, voir rien) et Drupal peut selon le projet être complètement adapté à bien des situations ou non, tout dépend du projet (performance ou fonctionnalités souhaité etc...). Rien qu'un exemple, pour la création d'une plateforme de traduction (gérant 5 langues) et de classification de vidéos, avec gestion de compte des entreprises sous-traités cela m'a mis grassement 4 jours, coût du projet 3400€.
Le client s'en foutait royalement des performances, et là on aime Drupal.

Ashish Kumar a dit…

Informative article!!!!!!!!!
Thanks for sharing it....

Maxime a dit…

Bonjour Messieurs,

Je pense que vous oubliez tous une approche plus globale. WordPress est par exemple un outil très mal écrit. L'architecture n'y est que très peu pensée. Pourtant c'est l'outil le plus utilisé aujourd'hui.

Les outils qui ont du succès ne l'ont pas par hasard. Il en va de même pour Drupal. Quelque soient les manquent des CMS/CMF, il n'en demeure pas moins que le succès est la preuve que ces outils répondent à des besoins.

Dans ma boite, on fait un peu tout Zend, Ruby, Drupal, Magento, ... Néanmoins, même pour des projets fortement customisés (exemple : ppr.com) on propose du Drupal, des qu'il y a du contenu.

Je veux dire par la, que developper from scratch un back office complet et gestion des utilisateurs, contenu, workflow, notifications mail, layout netvibes like, .... tout ca fait beaucoup de boulot. Avec Drupal le site est sorti en 3 mois...

L'idée est de ne pas tout faire avec Drupal, mais proposer le bon outil correspondant au besoin.

En revanche je pense que vous sous-estimez certains developpeurs Drupal :).

Je prendrais un exemple : Views / CTools / Panels développés tous les trois par la meme personne, merlinofchaos.

Le code de ces 3 module est propre, et terriblement bien concu. Le niveau d'abstraction atteint est remarquable.

Gauthier a dit…

Bonjour Maxime,

en quelques mots:

> Quelque soient les manquent des CMS/CMF
je ne prétends pas qu'ils manquent de quoi que ce soit (à part de qualité), je dis au contraire qu'ils font beaucoup trop de chose, et les font mal

> un back office complet et gestion des utilisateurs, contenu, workflow, notifications mail, layout netvibes like,
j'ai déjà pris l'exemple du workflow de drupal : il n'y en a pas ! (historiser des version de nodes ne constitue en aucun cas un workflow)

> .... tout ca fait beaucoup de boulot.
certes, mais c'est notre boulot (je parle des architectes et développeurs)

> Avec Drupal le site est sorti en 3 mois...
tu n'as manifestement pas la moindre idée de ce que l'on peut faire en trois mois de développement :)

> Le code de ces 3 module est propre, et terriblement bien concu. Le niveau d'abstraction atteint est remarquable.

alors là je suis obligé de développer un peu - avec un simple exemple pris au hasard (je ne connaissais pas le code) :

class views_handler_argument_many_to_one extends views_handler_argument {
function init(&$view, &$options) {
parent::init($view, $options);

voyons parent::init() (dans class views_handler_argument)

function init(&$view, &$options) {
parent::init($view, $options);
}

et maintenant parent::init() again dans views_handler (classe qui trainait dans un tout autre dossier, perdu dans un fichier .inc au milieu d'un tonne de fonctions gobales - ça aide drôlement pour le chargement des ressource à la demande ! oO)

function init(&$view, $options) {
$this->view = &$view;

Faut-il vraiment commenter ces absurdités ?

Moi quand je vois un développeur qui fait des choses pareilles, je ne le prendrais même pas en stage (très sérieusement).

Gauthier a dit…
Ce commentaire a été supprimé par l'auteur.
Yoan a dit…

Je note du vrai mais je ne suis pas d'accord avec la vision globale sur les CMS.

S'ils sont bien développés, ils apportent un gain de temps non négligeable, des interfaces d'administration soignées et des budgets de développement raisonnable.

Un peu trop cliché pour moi :)

Gauthier a dit…

> S'ils sont bien développés
n'est-ce pas le problème que je soulève ?

> des budgets de développement raisonnable.
non, pas s'il s'agit de développement - uniquement si l'on peut ne se contenter QUE des fonctionnalités incluses, auquel cas je suis d'accord avec toi

> Un peu trop cliché pour moi :)
oO ça valait le coup de développer et d'argumenter autant que je l'ai fait pour m'entendre rétorquer que ma position est "cliché" !

je pense que tu n'as pas pris le temps de lire les autres commentaires, et c'est dommage... le débat y est dans l'ensemble de qualité, et apporte beaucoup au sujet initial

Yoan a dit…

Je n'ai pas eu le temps de lire tous les commentaires.

Quoi qu'il en soit un CMS propre avec un système de plugins fiable est efficace.

Unknown a dit…

Les CMS commencent à se démarquer par rapport à ces grosses structures. Place aux jeunes pousses parfois plus en phase avec la réalité. A tester Magix CMS présenté au salon de l'AFUP (Forum PHP)
il n'a peut-être pas autant de modules que certains autres, mais ceux présents sont super bien pensés

Tom a dit…

Bon article, rien a ajouter. Nous avons pris la décision de dévlopper notre propre CMS avec le Zend Framework. Résultat un CMS très userfriendly avec des modules „out of the box“ qui peuvent être personalisés selon les besoins du client.

Avec cette aproche on peut accélérer le dévloppemlent et faciliter la maitenance de sites internet (sites vitrine ou portails). La découpe en HTML (maquette graphique personalisée) et l'installation du CMS avec 2-3 modules se fait en deux jours ma. Impossible de faire plus vite avec Drupal.
a+

Anonyme a dit…

Le sage montre la lune et l'imbécile regarde le doigt.

Il existe plus de 2000 CMS sur le marché, niez l'intérêt d'un tel outil est aussi absurde que niez les langages eux-mêmes, mais en plus le faire sur Blogger qui lui-même utilise un CMS devient comique.

Bref toute personne qui a déjà réalisé des sites en dehors d'une petite agence de quartier sait que ces sites doivent être mis à jour et donc de manière idéale utiliser des gestionnaire de contenus (back-office d'édition...) et donc des CMS. Un développeur qui prétend tout réécrire à chaque fois (sinon cela revient a développer son propre CMS) et écrit à côté un billet intitulé "l'humilité la première des bonnes pratiques" mérite une palme de mauvaise fois. Quand en plus il pense que les frameworks sont propres et freebug là il mérite la palme de l'incompétence. Je reprendrai la réaction de certains, je n'en voudrais même pas en stage dans mon entreprise, trop jeune, trop inexpérimenté.

Jean-Sébastien Iker a dit…
Ce commentaire a été supprimé par l'auteur.
Devlop78 a dit…

Je n'ai pas tout lu Gauthier, mais ce matin lors d'un entretien, j'ai entendu parler de drupal. La personne n'était pas pour, mais je ne m'arrête pas à cela. C'est le mot "procédural" qui m'a fait sursauter. Effectivement, sur leur site, leur exemple c'est drupal_get_fonction() avec un beau global dedans. Je me bats personnellement, et j'insiste sur ce dernier point, pour me remettre sans cesse en question et travailler pour coder "bien" (là dessus, on peut faire des années de débat, on n'en fera pas merci), et j'ai justement eu un entretien d'embauche cet aprem, ils utilisent à fond Drupal. Gloups. J'avais déjà fait la tête pour ColdFusion (rien à voir avec PHP), j'avais dit non, là je pense dire non. Effectivement, on se pose la question de : quand dois-je me trouver fermé ou intolérant, entre guillemets "un programmeur c'est réaliser des fonctionnalités, au plus vite au moins cher". Caricature bien sûr, mais c'est nullement niable. Perso, j'avais regardé vite fait Symfony et Zend, j'ai tout de suite accroché à Zend et pas à Symfony. Rien que "escape" (ou un truc comme ça) dans symfony était déjà un gros -1 (mais ce n'est pas forcément déterminant). Zend_View::escape(), là c'est clair, on sait où il va et on imagine, sans lire la def, ce qu'il fait. PHP joue sur deux tableaux (procédural et objet), et c'est dommage que certaines solutions (Drupal ... ?) restent sur le procédural. Symfony est objet, j'aime moins sa syntaxe que Zend (Ce dernier est très "carré" (pas restrictif, attention) ce que j'aime). Si j'aimais pas autant PHP et ne croyait pas autant à ses qualités et en son potentiel (Op-codes cache, compilation peut-être future), certainement que je passerais à C# ou Java. Est-il toujours resté dans les langages de purs scripts donc ?

Tout ça pour dire ... T'as pas un compte Twitter ? ;)

fredo a dit…

mort de rire vos commentaires.
Developpeur senior drupal je peux vous affirmer que vous avez tout faux sur toute la ligne. A lire vos commentaires on en ressort simplement que vous n'etes pas compétent en la matiere (sans vouloir vous vexer). C'est toujours quand on ne maitrisse pas l'outils qu'on le "casse". J'ai mis trois mois pour arriver a me servir de drupal. J'ai developpe un CMS en 2002 qui est toujours utilisé et encore loin d'etre tres loin dépassé techniquement. Cependant Drupal m'a démontré ce qu'était un vrai CMS ouvert. Ce n'est pas pour rien que la maison blanche l'utilise, le gouvernement francais l'utilise et que les plus grand sites l'utilisent. Son apprentissage est long et on a tendance a baisser les bras tellement c'est pas facile de rentrer dans un tel CMS car il est techniquement complexe, et il faut acquerir les connaissances et competances.
Mais une fois que vous les avez, et que vous faites faire ce que vous voulez a votre CMS, et que vous lisez tous vos commentaires ... mort de riirreee.

Gauthier a dit…

Bonjour Fredo,

> mort de rire vos commentaires.
tu me vois déjà ravi que la lecture de ce billet de ces commentaires t'ait permis de passer un bon moment :)

> Developpeur senior drupal je peux vous affirmer que vous avez tout faux sur toute la ligne.
Oups, je suis confus ; toutes mes excuses, j'ai du me tromper quelque part :D

> A lire vos commentaires on en ressort simplement que vous n'etes pas compétent en la matiere (sans vouloir vous vexer).
rassure-toi, tu n'as vexé personne, le débat est ouvert

>C'est toujours quand on ne maitrisse pas l'outils qu'on le "casse". J'ai mis trois mois pour arriver a me servir de drupal.
et moi il m'a fallut plus d'un an pour en arriver aux conclusions exposées dans ce billet ;)

> J'ai developpe un CMS en 2002 qui est toujours utilisé et encore loin d'etre tres loin dépassé techniquement.
j'ai comme un doute mais je ne demande qu'à voir ; pour autant que je me rappelle, les pratiques de développement en PHP à cette époque n'était pas ce qu'il y a de plus... académique.

> Cependant Drupal m'a démontré ce qu'était un vrai CMS ouvert.
> Ce n'est pas pour rien que la maison blanche l'utilise, le gouvernement francais l'utilise et que les plus grand sites l'utilisent.
Ce n'est pas pour rien sans doute, mais ça n'en fait pas une solution de référence non plus...

> Son apprentissage est long et on a tendance a baisser les bras tellement c'est pas facile de rentrer dans un tel CMS
Là nous sommes d'accord - la plupart des utilisateurs de Drupal le connaissent fort mal, et s'en servent de fait très mal...

> car il est techniquement complexe, et il faut acquerir les connaissances et compétences.
là, j'avoue passer à côté de ton argument "massue" : techniquement complexe ? à quel égard ? il ne faut pas confondre complexité et sophistication... tu noteras que j'ai pris le temps d'expliciter les raisons pour lesquelles j'ai forgé cette opinion négative, je serai ravi que tu en fasses de même.

>Mais une fois que vous les avez, et que vous faites faire ce que vous voulez a votre CMS, et que vous lisez tous vos commentaires ... mort de riirreee.
Une fois encore, si tu asbien rigolé en lisant ce billet, c'est déjà ça ;)

MaggiC solutions a dit…

Salut,

Excellent article. Developer (.NET, PHP) depuis 12 ans, mon expérience m'amène aux mêmes conclusions que vous. J'ajouteais simplement mon petit grain de sable... Vous ne parlez pas du tout dans votre article de l'aspect "Sécurité" de Drupal ... Et bien je peux vous le dire, c'est catastrophique... les failles sont énormes et nombreuses, les attaques sur ces failles sont légions (suffit de monitorer les attaques dédiés à Drupal (ou à WP d'ailleurs) pour se rendre compte que c'est monnaie courante. Ce genre de CMS est a éviter dès que le projet devient trop sérieux... Pour un blog OK, pour le reste, oubliez le.

alduc a dit…

Intéressante discussion. Toutefois, je vais me permettre de relever que l'argumentaire de base, bien que contenant quelques très bons points, est quelque peu fallacieux. Très beau mécanisme de rhétorique qui permet d'émettre un constat basé sur des prémisses insuffisantes.



>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

-> Ne tient plus la route. Drupal 7 a comme requirements : PHP 5.2.5 or higher (5.3 recommended) et Drupal 8 est 5.3

> les CMS ont dû se plier à cette contrainte et maintenir une compatibilité totale avec cette version désormais obsolète de PHP
-> Mauvaise foi. Voir ci-dessus.

> le foisonnement en est tel qu'il est souvent long et difficile de sélectionner le plus approprié

->Pour un néophyte, j'en conviens. Lorsque l'on développe en Drupal régulièrement, cet argument n'a aucune pertinence.

> limitant de fait les personnalisations possibles
-> Sophisme

> la communauté préfère réaliser deux modules disposant chacun de 3 fonctionnalités plutôt qu'un seul doté des 6
-> Je suppose que si je n'ai besoin que de trois fonctionnalités, peut-être est-il plus léger de n'avoir que celles-ci...

> (au moins jusqu'à PHP 5.3, dont je ne suis pas certain de la compatibilité avec Drupal par ailleurs)
-> Cela vous aurait pris un an à composer votre argumentaire et vous ne savez pas cela ?

>Dans Drupal, tout ou presque se passe dans la base de données
-> Fallacieux. Dans un Drupal bien développé, tout ou presque est dans le code. Il est effectivement possible de créer par exemple une "vue" pour laquelle la configuration se retrouvera dans la BD, mais ensuite cette vue est exportable en code.

> il faut synchroniser les bases de données, ce qui n'est pas chose aisée
-> Fallacieux. Il est possible d'avoir un environnement développement/recette/production sur lesquels les tests peuvent être opérés en gardant le configuration dans le code. Il y a effectivement parfois certaines limites, mais en majorité les configurations peuvent être gérées par le code. Ce code peut donc très bien être versionné.


Par ailleurs, je rappelle aussi que l'auteur prétend d'une part que le besoin doit primer sur la solution, mais conclut : "Pour un développement sur la base d'un cahier des charges précis, utilisez des frameworks". N'est-ce pas une superbe pirouette intellectuelle ?

Gauthier a dit…

bonjour alduc,

et merci pour ce commentaire, le 100ème, qui relance la discussion avec force :) je pense qu'il s'agit là du premier commentaire contradictoire tant soit peu argumenté.

Tout d'abord, avant de m'accuser de mauvaise foi, je tiens à rappeler que je n'ai rien à gagner à tenir cette position hostile à Drupal, bien au contraire, si l'on constate son succès indéniable sur le marché. Ce faisant, je prends le risque de me couper de clients potentiels, et je n'y ai naturellement aucun intérêt. Mais c'est parce que je suis sincère dans mes critiques que j'ai pris cette décision, refusant de fournir à mes clients des solutions dont je sais qu'elles ne seront pas les meilleures pour eux.

Ne disposant que d'un temps compté, je ne répondrai qu'à quelques points, veuillez m'en excuser par avance :

-> Ne tient plus la route. Drupal 7 a comme requirements : PHP 5.2.5 or higher (5.3 recommended) et Drupal 8 est 5.3
--> hélas si, cela tient encore la route : que certains fragments de la montagne de code que représente chacune des versions successives finissent par exploiter les spécificités de versions moins antiques du langage ne dément pas une architecture qui reste globalement d'un autre temps. Drupal progresse certes, mais la pratique du refactoring, à l'échelle de l'architecture, reste marginale.

-> Cela vous aurait pris un an à composer votre argumentaire et vous ne savez pas cela ?
--> je ne peux m'empêcher de récrier cette pique vraiment gratuite : il m'a fallut un an pour me décider à poster sur le sujet, certainement pas pour constater (et non composer) l'argumentaire :) et le produit ne me passionnant pas (litote), je n'ai pas investigué plus que ça, car ce point est de toute façon d'une importance mineure (voire réponse précédente).

-> Fallacieux. Dans un Drupal bien développé, tout ou presque est dans le code.
--> Non point. J'en veux pour preuve Drupal 7.8, qui fait 244 appels à la DB (insert, update et delete mélangés) pour ... afficher le formulaire de login de LA PAGE D'ACCUEIL PAR DEFAUT ! Après rechargement, et donc mise en cache, il en reste encore plusieurs dizaines ! Pour moi, une telle conception hypothèque d'emblée la solution. Si pour vous cette surcharge est acceptable, soit. Je pense que je vais refaire un petit post avec plus de chiffres, cela nous épargnera peut-être certaines dérives dans la discussion :)


> Par ailleurs, je rappelle aussi que l'auteur prétend d'une part que le besoin doit primer sur la solution, mais conclut : "Pour un
> développement sur la base d'un cahier des charges précis, utilisez des frameworks". N'est-ce pas une superbe pirouette
> intellectuelle ?
En aucun cas - imaginer un instant que les CMS et les Frameworks sont ne serait-ce que partiellement comparable est une erreur. Les frameworks sont constitués de composants et de leur "mode d'emploi" ; mais ces composants ne sont en aucun cas fonctionnels ! Ils sont là pour permettre le développement des éléments fonctionnels de l'application. Il n'y a AUCUN point commun entre les deux approches.

G

jratompo a dit…

Bonjour,

Cet article et ce débat nourrissent la réflexion qu'il faudrait mener sur les CMS en général, merci pour tous les points soulevés, je partage cet article ;)

Anonyme a dit…

Drupal c'est une usine à gaz. Même son auteur reconnais que son apprentissage prend beaucoup de temps et qu'il y a pqs beaucoup qui le maitrise comme il faut.
Drupal est sorti depuis 2002 et je ne peux pas comprendre que jusqu'à date qu' il y a peu de programmeur qui le maîtrise contrairement à framework.

Anonyme a dit…

Bon depuis 2010 Drupal à sacrément évolué le contenu de cet article n'est plus tout à fait objectif et il faut bien avoir en tête qu'un CMS c'est fait pour cracher du contenu un point c'est tout et pour ça il est pas mal.
Mais en aucun cas il faut s'imaginer que l'on peut développer une application métier avec Drupal on peut à la rigueur y arriver mais on mettra 10 fois plus de temps qu'avec un framework avec un résultat tordu de la mort.

Gauthier a dit…

Bonjour, et merci pour ce commentaire.

Je crois que nous sommes d'accord en tous points : un CMS ne doit servir qu'à gérer du contenu, et non pas à créer une application métier.

Quand au fait que Drupal ait évolué depuis la rédaction de ce papier, je ne dirai pas le contraire. Mais le recours à quelques objets issus de Symfony, et à cette absurdité qu'est Twig par exemple, n'a rien changé à la philosophie générale de l'outil, qui très bon pour gérer du contenu ; pourvu que l'on s'en tienne à ça :)

Unknown a dit…

je suis très touché de voir sur ce blog qui n'est même un développement personnel du proprio parce que c'est du blogger, y publier des articles contre les CMS et surtout contre Le CMF Drupal, écouter par son nom et sa définition, c'est un assembleur des sites c'est un framework sa puissance réside dans les possibilités de pouvoir coder ou de ne pas coder, vraiment vous étonnant, allez y visité le site de la maison blanche whitehouse.gov c'est du drupal, si vous êtes incapables d'offrir à drupal un projet de grande envergure arrêté de parle sur des question techniques que vous ne maitrisez pas, avec un IDE de java il est possible de développer des modules super orienté objet, la question reste une que ce que vous faite ou vous êtes en mesure de faire avec Drupal?, dite moi à quoi ressemble le site et la télé en ligne de france24 avec votre blog qui repose sur du bloggeur c'est très bêtes de votre part, vous pensez ainsi qu'en étant dans votre chambre vous auriez un prix Nobel de meilleur développeur, voilà le symbole de meilleur, je souligne les américains ne sont pas bêtes pour remettre ce prix à Drupal pendant que vous vous êtes des super développeurs, c'est vraiment décevant de votre part en ayant un petit blog avec des pages qui s'altèrent au clic pour ajouter des commentaires mais avez cas même les courages de critiquer bêtement un outil aussi puissant, dite moi pourquoi le gouvernement français a quitté SPIP pour drupal, laisse-moi vous rafraichir la mémoire, la NASA a des sites web en Drupal; la liste est longue parlons aussi de l'armée américaine donc mettons-nous d'accord vous êtes peut être en mesure de créer une application métier avec drupal c'est là ou vous avez de problème, votre préoccupation personnelle ne peut pas être un cas général. Et c'est quoi une application métier pour vous?
je suis développeur en java web service restfull, php, administrateur de réseaux et bd de formation, développeur sur les embarqués.

Unknown a dit…

Voila comment c'est encore plus betes tous les commentaires doivent etre approuvé par toi le proprio du blog sur blogger c'est de la honte total pcq moi j'ai abandonné mon blog blogger il ya des année, la liberter d'expression c'est quelque chose que Julian avec Wikileaks se battu pour tous les hackers et les combattant de liberté. voila tu approuve des commentaires avant de publier c'est triste et si c'était un forum de discussion, c'est malheureu pour de petit developpeur. cherche à apprendre aujourd'hui même le developpement natif commence ceder la place au developpement web, parce que les choses chenge c'est la loi de la nature.

Gauthier a dit…

Bonjour Allen,

ce qui me touche pour ma part, c'est de voir que plus de 4 ans après sa publication, ce billet est encore lu et continue de faire réagir :)

Ce qui est dommage, c'est qu'il n'y a dans votre long message que des opinions - pas le moindre argument technique, or c'est sur ce plan qu'était orienté mon post.

Votre seul argument pour supporter Drupal est de me dire : des gens s'en servent. En creux, on comprend également que votre autre argument, c'est que aimez Drupal :) Comme tout ça est bien léger, ça vous amène forcément à des mesquineries ad personam, en mettant en doute mes compétences et en me disant que je suis "bêtes" (sic).

Je ne vais donc répondre qu'à un seul point :

> Et c'est quoi une application métier pour vous?

Et bien voilà, il aurait suffit de me poser cette question directement :) Vu d'où on part, je vais vous donner une définition simple, voire simpliste, mais qui nous permettra peut-être de nous comprendre un peu mieux : une application métier est un logiciel qui permet à une entreprise de faire tourner son business.

Autrement dit, un site web présentant du contenu n'est pas une application métier. Et tant qu'on se sert de Drupal pour faire des sites webs (sans workflows trop complexes, ni connexion critique avec d'autres composants du SI), ça me va très bien. Dans les autres cas, non. Pour les raisons expliquées dans mon billet initial, que je vous invite à relire avec peut-être un peu plus d'attention et moins de parti pris.

Gauthier

Gauthier a dit…

et pour le second message, concernant la modération a priori des commentaires, il s'agit simplement d'éviter que le fil de commentaires ne soit pollué par les nombreux spams que dont j'empêche la publication grâce à ce système.

Sachez que je n'ai jamais censuré le moindre commentaire qui soit réellement une réaction à mon billet, quelle que soit l'opinion de son auteur.

Unknown a dit…

Bonjour mon cher Gauthier Delamarre

Vois y consulter ce lien:
http://paris2013.drupalcamp.fr/session/drupal-cms-oriente-metier.html
si tu ne comprend pas contact moi je suis là pour t'orienter.
ALLEN

Gauthier a dit…

Bonsoir Allen,

à toutes fins utiles, si ça intéresse quelqu'un parmi les lecteurs, je publie ton lien.

Toutefois, tout en te remerciant de me proposer ton aide, je m'en passerai : je ne pense pas avoir besoin d'aide pour déchiffrer du bullshit marketing :)

L'argument Sf2 + Twig pour vanter Drupal 8 me fait plutôt rire.

Pour mémoire, j'ai avancé des arguments techniques pour dire pourquoi je n'aime pas ce type de plateforme (dès lors qu'on les détourne de leur usage originel, bien sûr).

J'attends toujours des réponses concrètes à ces problématique, et la présentation vers laquelle tu nous renvoies n'est que du blah blah qui nous répète en boucle "Drupal, c'est super". Avec pour argument majeur : "y a plein de gens qui s'en servent, et plein aussi qui font des modules, donc c'est bien".

Bref, ce fil de commentaire n'a pas pour vocation d'opposer des opinions, mais des faits. Donc, si tu as autre chose à dire que "Drupal, c'est bien, tu es bête et méchant d'en dire du mal", je t'invite à le faire. Dans le cas contraire, inutile de poursuivre cette discussion, du moins par le biais des commentaires. Si tu le souhaites, contact moi par mail.

trololol a dit…

Bonsoir Gauthier,

En premier lieu, merci pour ce somptueux article, qui décrit mon état d'esprit après 2 heures de R&D pour tomber un DRUPAL avec des fonctions kikou XD.
Je vais te passer le scène ou j'ai tenté d'expliquer au client: que c'était le mal. A leurs dev (css): qu’après mon passage, ce ne serait plus comme avant, il ne pourra plus faire mumuse avec ses modules comme il le faisait (oui faut voir la logique de l'animal (ou de drupal?) )..
Mais bon, je viens pas pour écrire un pavé.

Jutes te remercier pour la lecture de cet article argumenté qui m'a fait du bien et faire quelques [at] pour ceux qui grincent des dents en le lisant..( et parce que je suis d'humeur trololol là).

Au hasard (je ne sait plus les noms, j'ai lu en diagonal, mais vers la fin, vu que l'article date un peu..

@ jeDéfendsSonCode :
Éclate toi bien ! la "conception même" du support pour communiquer dans la com drupal officiel est "louche".

@ laMaisonBlancheSousDrupal :
Toi là bas tu causes beaucoup ! Si tu connaissais le fonctionnement d'un appel d'offre public....

@laNasaAdesSitesWebSousDRupal-pourRapidementPoster :
Le dev qui parle sur ce site est sous blogger..(ce ne résonnera pas en toi comme je le veux. mais ça fera rire les copains, ça me suffit).

Bon pas très constructif mon commentaire,
Mais nous salueront la page PR2 (lol), le courage de Gauthier de parler de ça à cœur ouvert0

Je salue aussi tout les autres coms qui parlent de DRUPAL comme le dieu des CMS pour dev SELECT..
slt ;)

Gauthier a dit…

Salut @trolol,

merci pour ton message.

Au passage, le fait que de nouveaux commentaires aient été postés récemment sur ce vieux post m'a donné envie de voir comment progresse Drupal.

Je viens donc d'installer la beta 1 de Drupal 8, et je dois tirer mon chapeau aux développeurs de cette mouture : seulement 191 requêtes SQL pour afficher le formulaire de login avant mise en cache, et, tenez-vous bien, à peine 46 petites requêtes pour réafficher le même formulaire après mise en cache !

Il faut dire que la page se compose tout de même de 2 champs, 1 bouton et 11 chaînes de caractères. Réussir à générer une telle page avec un tel de nombre de requêtes, sans oublier les 2482 appels de fonctions (méthodes ?? :)), ça tient du prodige, non ?

Enfin, moi, je l'avoue humblement, je me sens incapable d'écrire un code susceptible de produire autant de requêtes et d'appels de fonctions/méthodes pour produire si peu de résultat :)

trololol a dit…

fonctions (méthodes ?? :)), (très bon)

je suis dans l'obligation de dev un drupal custom sur ce client, je me dit ce matin :

"dans la vie de tout les jours, tu peux t'adapter au pattern des autres dev, parfois c'est tordu, mais ça va.."

Là c'est un truc de fou drupal!
Conclusion :
je vais vomir le code et basta !!!
Merci à la communauté drupal de l'avoir fait évolué dans ce sens..
slt

Seb a dit…

Au-delà du ton absolument dédaigneux vis-à-vis de Drupal, de sa communauté active, ainsi que des développeurs gravitant autour, est-il utile de rappeler que ce billet de blog est un avis intime avant tout, bien plus qu'un sacro-saint constat objectif.

Drupal réclame du temps pour être correctement appréhendé, et ce ne sont pas quelques mois de TMA dans des boites qui n'ont rien pigé à ce concept qui vont changer quoi que ce soit.

Chaque mois, des projets Drupal d'envergure sont menés à bien, et ce parce qu'ils ont été confiés à des professionnels. Ça ne sert à rien de prôner le tout à la main lorsque la réalité du marché est de proposer une solution qui doit être à la fois customisable, rapide à mettre en place et facilement maintenable par la suite.

Il y a deux sortes de développeurs dans le monde du web : les évangélistes du code entièrement fait main qui auront un avis biaisé sur le sujet et ne changeront pas d'avis même quand leur profession sera en danger, et ceux qui sont capables de trouver un compromis entre leur passion et la réalité du marché. Ces derniers prendront le bon train pour faire évoluer le web.

Gauthier a dit…

Bonjour Seb,

je trouve que c'est le ton de ce commentaire qui est dédaigneux :) Et surtout, il semblerait que tu aies lu ce billet un peu en diagonale :

- dédaigneux parce que ce n'est pas sur la base des mois passés sur des applications Drupal que j'ai forgé mon opinion, mais sur le retour d'une expérience qui était déjà de près de 10 ans à l'époque de la rédaction de ce billet (qui va avoir 5 ans...)

- lu en diagonale parce que :
- je ne prône en aucun cas l'écriture d'applications "tout à la main" (sauf à considérer qu'écrire une application basée sur un framework consiste à tout écrire à la main)
- je ne m'intéresse pas au code mais aux applications qu'il permet de créer
- je ne dis pas que Drupal ne sert à rien, mais qu'il est le plus souvent utilisé de manière impropre, incohérente avec sa vocation

Enfin, pour ce qui concerne le reproche concernant mon objectivité... c'est drôle comme tu ignores les arguments parfaitement concrets que je présente, de sorte que tu n'y apportes aucune contradiction. Non, au lieu de ça, tu te contentes de dénigrement personnel, et de nous dire que "il y a pleins de projets Drupal en prod, donc c'est que Drupal c'est bien !", ou encore "si, Drupal c'est génial quand c'est utilisé par des pros".

Je n'appelle pas ça des arguments objectif :)

Maintenant, comme j'ai déjà eu l'occasion de le dire, ça me va très bien que des intégristes Drupal, à qui le code fait peur parce qu'ils ne savent pas l'écrire, continuent de foirer des projets trop ambitieux pour leurs compétences - ça nous fait plus de boulot, à nous autres :)

Seb a dit…

Gauthier : Je voulais simplement utiliser le même ton que toi. D'ailleurs je te rappelerai que :

- Tu qualifies les développeurs Drupal de "fâchés avec le dév objet" (depuis quand développer sur Drupal induit qu'on n'aime pas la POO ? On peut très bien faire les deux) ;

- Tu estimes que les CMS s'adressent à un public de non-développeurs : faux, et ça n'était déjà il y a 5 ans. Si c'était le cas, aucune entreprise ne ferait appel à des développeurs pour le leur installer et moduler ;

- Tu qualifies d'évangéliste Drupal quelqu'un qui n'a pas le même avis que toi. Peut-être se trompe-t-il, peut-être pas, en tout cas l'expérience m'a appris que souvent, personne n'a raison, personne n'a tort, chacun a ses méthodes. Du coup, permet moi de réutiliser la même expression (cf mon premier point) ;

- Enfin, sur tes dernières assertions, je t'invite à ne pas détourner mes phrases et à te renseigner un peu plus sur notre métier.

Bien sûr, car balancer 2 ou 3 points négatifs n'a jamais composé un argumentaire, c'est au meilleur des cas un avis personnel orienté.

C'est dommage, tout ton billet n'est pas à jeter.

Anonyme a dit…

Je suis Devincydrupalien ,@Gauthier Delamarre avant les CMS on utilisait directement du code source HTML, ensuite HTML+CSS, après HTML+CSS+PHP, on a trouvé que le processus était trop , les frameworks sont rentrés en action, que dire de Dreamweaver qui avait fait son temps, les choses ont maintenant evoluées , le web n'est plus reservé uniquement aux developpers qui se croient tous monopoliser, le web est devenu liberal tout le monde peut y participer sans forcement etre developpeur d'ou la naissance des CMS.Un exemple precis ton article est redigé sur BLogger, tu aurais pu monter ton site en codant et le publié sur un hebergement, xa coute rien maintenant.Les CMS c’est l’avenir du web, et Drupal c’est le CMS devenu CMF qui donne le plus de liberté de créativité et surtout de sécurité. Affaire a suivre

Gauthier a dit…

La remarque concernant Blogger a déjà été faite et j'y ai déjà répondu : oui, pour un blog, un CMS est l'outil adéquat. Je n'ai jamais dit le contraire, et il aurait été complètement idiot de ma part de coder un moteur de Blog uniquement pour publier mes quelques posts alors que d'excellents outils, dédiés à mon besoin, sont disponibles, qui plus est gratuitement.

Maintenant, ll faut remettre les choses un peu en perspective : je n'ai jamais dit que les CMS étaient inutiles.

Je suis architecte PHP depuis pas mal de temps ; mon job, ce sont de gros sites web et des applications réalisées avec les technos web. Je ne parle donc pas de sites institutionnels, ou de communication.

C'est donc dans le contexte de ce type de réalisation que je dis que les CMS sont inappropriés. Et je ne dis pas ça parce que "je n'aime pas le CMS", même si le titre du billet peut le laisser penser (c'est pour ça qu'il faut lire le billet, pas seulement son titre :)). Non, je dis ça parce que j'ai constaté durant ces 15 dernières années, que réaliser un projet ambitieux, et ayant vocation à durer dans le temps, sur la base d'une plateforme de type CMS est toujours plus coûteux dans un premier temps, et plus limité ensuite dans ses capacités d'évolution.

Ceci n'est donc pas une opinion, c'est un constat. Drupal en tant que tel ne m'intéresse pas. Je n'empêche personne de l'utiliser ; mais dans le cadre de mon métier, quand je conseille une entreprise ou que j'agis pour elle, je proscris la fausse bonne idée d'utiliser un CMS si le périmètre fonctionnel est nettement plus vaste que ce que sait faire initialement le CMS. Et ça me navre quand je vois des clients gâcher des ressources incroyables pour s'entêter à utiliser une techno plutôt qu'une autre pour des raisons idéologiques. Je tâche d'être objectif et pragmatique.

Prototyper un projet avec un CMS, faire un POC, pourquoi pas. Mais l'expérience démontre tout simplement qu'adapter une plateforme inadaptée n'est pas efficace, et encore moins économique, à long terme.

bilsesbil a dit…

Bonjour a vous je tiens tout dabor a tirer un coup de chapeau a ce blog qui a pu animer un tel debat.
en effet je suis deja tomber sur ce blog plusieur foismais le sujet ne ma jamais intriguer car j'estimais que l'auteur faisait une reproche a drupal de decoule de son experience passe.
alor si jecris ces ligne de commentaire c'est juste que jai pris du temps a vous lire et a essayer de vous comprendre. bien en tant que devellopeur sur drupal je voudrais juste apporter des eclaircissement a ce sujet.
1-drupal est un cms+framwork=CMF sa vous le savez deja

2-drupal dans sa version brute n'est pas fais pour les non codeurs ou les non develeoppeur pour cela i faut avoir une expertise dans la matiere de devellopement en php pour comprendre comment il fonctionne.(dedié aux expert)

3-pour les profane de code il ya drupal garden(dedier au debutant)

4-il vrai que genere trop de requette en arriere pour charger une page ou un formulaire mais cela etait vrai il ya 4 ans car chaque le travail de drupal est dameliorer ces diferent bug et surcharge.

5-les devellopeur de drupal nont jamais ete contre le POO car on vois bien que aujourd'hui il sinsere la dedan.

6-drupal 9 avenir sera coder sur PHPPO rasurer vous!

7-drupal 8 en est la preuvre dans sa revolution puisque tu te dis devellopeur fais les constat par toi meme.

8-quel est la critique que tu porte a la fonction eval()

9-vous parlez de modules mais il faut dabord comprendre la notion de module dans la programmation avant de dire quoi que se soit jai comme l'impression que vous ne lavez pas bien saisi

10-jai lu un commentaire parlant de securité lui il commet une ereur en disant que la securité rencontre des defaillance mais vous gautier valider cet opinion est un manque de serieux dans ce que vous dite et deplorable a la fin vu que vous avez utilisé drupal bien longtemps comme vous le pretendez. soyez un peu serieux dans ce que vous dites quand vous savez que drupal es dedier a la securité.
je ne vous dirai pas pourqui la NASA, la whitHouse et les autre utilise drupal je vous laisse de decouvrir par vour vous mem en tant que developeur hein! :)

11- ne soyez pas specimiste dans la chose si vous navez justement pas pris le temps de comprendre le fonctionnemtnde base de drupal sa devrait etre facile si vous programmer en php bien longtemps

12-cessez de traiter les autre de mediocre comme vous le faite car il ya pas de programme sans bug sa vous le savez! et il faut bien de temps pour trouver le bug et le resoudre!

alors soyez libre dans votre choix et je vous voulais ajouter le temps augmente pour celui qui ne sait pas ce qu'il cherche ou fait!(voir ne comprend mem pa)

je vous pose la question aujourd'hui maintiendrai vous encor votre propos de 4 ans? soyez un devellopeur humble!

Unknown a dit…

bonjour, petite lecture du blog et bizarrement je suis complètement d'accord quand je vois sur quoi je tombe au taf...

donc on a une boite cliente du CAC40 dont je tairais le nom (client) qui a eu à développer une appli métier, elle est passé par une autre grosse boite qui s'appelle Altran(1 milliard d'euro de benef par an, 25 000 employés) et vous serez heureux de savoir (ou pas) que cette grosse boite développe des applications métier avec drupal !!!!

Ducoup cette superbe boite s'est faite blacklist (c'est compréhensif), et notre petite PME de développeur se retrouve avec cette chose immonde entre les pattes, une usine à gaz ou plutôt un sac de nœud horrible

bref, je suis entrain de tenter de comprendre ce "truc" car on peut pas appeler ça une application, et franchement, on vois bien que les mecs qui développent avec ça ne sont pas des développeur, même pas en herbe...

donc je dois refaire cette appli, j'ai choisis silex (framework à base de synphony), et je dois ressortir les infos qui ont été stocké dedans et là je pleure...

Gauthier a dit…

Une fois encore, merci pour tous vos commentaires, critiques ou favorables, qui continuent d'arriver 6 ans après ! :)

Et désolé pour Bilsesbil, qui a peut-être eu le sentiment d'être censuré, car j'avais omis de valider la publication de son commentaire, ce qui n'était aucunement intentionnel !