eZpublish Vs Drupal : pourquoi EzPublish est battu par KO.

Après avoir relaté l'enfer vécu avec la solution norvégienne EzPublish dans le cadre de nos sites media et la décision de refondre complètement les sites sous EzPublish sous une autre technologie moins consommatrice de ressources, je reviens vous parler d'une comparaison -exemple à l'appui - entre DRUPAL et eZPublish.

Nous avions un site Femina.ch sous Ezpublish et nous avions décidé de le refaire sous DRUPAL.

Après 6 mois d'expérience, voici les quelques remarques que nous en tirons.

Ce qui frappe chez DRUPAL c'est son accessibilité, là où eZpublish nécessite une formation - créant ainsi son écosystéme autour de lui -, Drupal se laisse apprivoiser sans difficultés par un novice sur le CMS.

La comparaison est sans appel...c'est cette fois ci le responsable projet qui aime voir ses prévisions budgétaires coller à la réalité projet qui parle.

On peut développer un site media complet sous DRUPAL en quelques dizaines de jours avec 1 ou 2 développeurs contre plusieurs dizaines de semaines sous Ezpublish avec plus de développeur derrière.

L'investissement en temps est donc largement supérieur avec Ezpublish qu'avec Drupal.

En terme de cout, le rapport a été chez nous de 1 à 6 sur des fonctionnalités équivalentes !

Là où un excellent développeur PHP mettait 3 semaines pour entrer dans eZpublish, Drupal se laisse dompter en 2 ou 3 jours.
La maintenance du premier mobilise peu les développeurs qui peuvent être ré-affectés sur d'autres projets alors qu'Ezpublish, lui, nécessite pour la moindre adaptation visuelle une connaissance du langage de template Ez qui n'est pas standard (vous ne l'apprenez que pour EzPublish) et de multiples "décompilation" "recompilation" sur les serveurs ou le serveur si vous utilisez un NFS ou son équivalent.
Là où cela devient "détonant" c'est sur la véritable vitesse de chargement des pages - celle que vous mesurez et non celle qu'on vous vend en benchmark marketing -.

Avec IP LABEL - mesures qui font autorité -, nous avons pu précisément suivre les performances du même site - Femina.ch - avant et après sa refonte ...le temps moyen de chargement avec Ezpublish était au dessus des 5-7 secondes sur la home page contre 0,8 secondes sur Drupal à Trafic égal et contenus égaux.

La comparaison pour la production du même site entre DRUPAL et eZPUBLISH est donc sans appel possible.
Drupal nous a fait économiser du temps, de l'argent a rendu nos utilisateurs internes contents.
Nous attendons maintenant de voir comment Drupal gérera un gros site media, je vous en parlerai à ce moment là.
Nous savons déja qu'Ezpublish le peut difficilement si vous avez un rafraichissement important de l'information affichée.
Attention la version mise en oeuvre était eZpublish 3.8. De plus un Framework avait été posé devant masquant ainsi une partie des fonctionnalités d'eZpublish.

Commentaires postés sur l'ancienne version du site

Submitted by Anonymous on Fri, 07/31/2009 - 17:11. #
Tout d'abord les 2 systèmes ne sont pas très comparables. EzPublish est beaucoup plus puissant que Drupal. Ceci étant dit nous avons réalisé de nombreux sites avec EzPublish et Drupal. Jamais aucun projet n'a connu de problèmes avec EzPublish. Et nous n'avons jamais rencontré de difficultés à implémenter les fonctions dont nous avions besoin. Nous considérons Drupal comme plus adapté à des sites simples. Sans doute Ez est-il plus complexe. Mais en tout cas en ce qui nous concerne c'est un bel outil. Et pour rebondir sur un autre commentaire je pense que la compétence des développeur est évidemment en cause.


Submitted by Pierre Jean Duvivier on Mon, 08/10/2009 - 16:19. #
Ezpublish peut très bien convenir à des sites vitrines sans beaucoup de trafic dessus.
notre site corporate est encore sous Ezpublish et il tourne sans aucun probléme.
Le problème est que Zpublish est structurellement défaillant pour moi en cumulant des erreurs de conception de MCD (le schéma de base de donnée pour être plus clair), d'emploi du PHP là il n'est pas bon (dans le traitement des chaines de caractère par un méta-language), dans la complexité de ses configurations (dispersion des fichiers ini) et à l'époque - cela a peut etre changé par contre - le "tout base de donnée" dans la gestion des binaires en particulier en load balancing qui était balancé dans la base (mode cluster amélioré depuis lors je crois).
Pourriez vous citer des sites à fort trafic et fort rafraichissement de l'info qui tournent sur eZpublish ?


Submitted by Anonymous on Sun, 06/14/2009 - 10:37. #
Les 2 systèmes sont concurrents mais pas différents au point que vous le dites.
Nous connaissons les 2 et nous développons avec les 2 depuis 3 ans et franchement votre "post" assassin sur eZ est loin d'etre vrai.
Drupal est très bien pour des sites communautaires, de presse (si pas de publication de contenu programmée) et SURTOUT si vous avez 17 devs en Interne et pas besoin de support éditeur !!
De tres gros sites Presse en France tournent sous Drupal et de l'avis même des équipes ca donne "On a du tellement faire de devs dessus que finalement c'est du spécifique maintenant" donc ils ont embauché des devs en internes NON prévus au budg du projet.
On a jamais vu ca avec eZ par contre oui eZ ne gere pas aussi simplement la notion de communauté (reactions aux articles, etc..).
Article qui me parait tres partisant :-) Essayez donc de monter un portail complexe en multulingues/multisites/multipublication/workflow complexe/Versionning evolué /etc..avec Drupal..c'est pas si simple.
On aime bien les 2 produits..un choix est a faire au départ et OUI ce choix ne dépend pas uniquement de la maturité techno des outils.


Submitted by Pierre Jean Duvivier on Mon, 08/10/2009 - 16:21. #
Je suis désolé mais nous avons eu l'expérience inverse.
Nous étions obligé d'immobiliser environ 14 devs pour soutenir 3 gros sites sous Ezpublish (à l'époque pour 100'000 visiteurs uniques par jour) pour simplement faire de la maintenance corrective (donc permettre au site d'être online). Je ne compte les heures de nuit à redémarrer les bases qui partaient en sucette.
Sur Drupal, c'est maintenant 11 sites qui tournent pour 200'000 visiteurs uniques et nous n'avons qu'1 seul poste dedié à la maintenance corrective dessus. Le reste de nos équipes (5 développeurs) est sur du projet.


Submitted by Anonymous on Fri, 04/24/2009 - 17:50. #
Les personnes jugeant drupal plus efficace et moins chronophage qu'EzPublish devraient se poser de sérieuse question sur leurs compétences en développement.
On voit d'ailleur ici que c'est un chef de projet qui en parle et non un developpeur


Submitted by Pierre Jean Duvivier on Sat, 04/25/2009 - 09:55. #
Sauf que dans notre équipe, nous développons "tous". Typiquement les chefs de projet "webfactory" ont tous bati un site "pro" sur les 2 dernières années "tout seul" gardant au final un lien avec la technique. Nos chefs de projet sont des développeurs capable de remplacer les développeurs qu'ils dirigent. On ne sort pas 17 sites en 1 an avec de petites équipes sans avoir cette capacité.
eZpublish a de grosses défaillances d'architecture applicative...et de beaux ratés. Je suis désolé mais utiliser PHP pour processer du un méta-langage (le langage de template) c'est stupide connaissant les perfs PHP sur la gestion des chaines.
Utiliser 2 pauvres tables (à l'époque...je crois que maintenant il est possible de passer par des fichiers à plat) qu'on présente comme "Un cluster" c'est faire insulte à un vrai cluster. Là encore c'est de la "neuneuterie marketing".
Après la compétence des développeurs joue bien évidemment.
Nous avions eu avec EZpublish de très mauvais prestataire qui sont venus développer sur un mauvais outil. Cette "désastreuse soupe" a été maintenue ensuite par des très bons prestataires qui, eux, ont pu réussir à coup de 60.000 euros par mois à conserver les sites jusqu'à leur basculement sur un systéme "qui fonctionne sans dépenser des sommes folles".


Submitted by Anonymous on Thu, 12/11/2008 - 15:54. #
Merci pour cet éclairage. Je ne me suis jamais plongé dans eZ, et ai depuis le début été assez bluffé par les possibilités de Drupal, même pour un non développeur comme moi.
Je me contente de faire du lego, c'est à dire d'assembler des modules, et je parviens à faire des applications qui font à 95% ce que je souhaite... sous Drupal.
Ton explication m'éclaire: je comprends maintenant pourquoi l'informaticien de la boite où j'étais avant refusait drupal (pas assez de code pour lui , et donc perte de la maîtrise) et demandait eZ publish.
Ce qu'il a obtenu après ma démission...


Submitted by tigrou on Tue, 05/20/2008 - 15:00. #
le temps moyen de chargement avec Ezpublish était au dessus des 5-7 secondes sur la home page contre 0,8 secondes sur Drupal à Trafic égal et contenus égaux.
à qualité de réalisation égale ? ça m'étonnerait fortement... D'aulleurs c'est difficilement mesurable.
nécessite pour la moindre adaptation visuelle une connaissance du langage de template Ez qui n'est pas standard (vous ne l'apprenez que pour EzPublish
ce n'est pas tout à fait vrai. Le langage de template actuel dérive fortement de Smarty qui est quand même un "pseudo standard" dans le monde PHP (bon ok c pas le même à 100% mais passer d'un langage de template à un autre n'est quand même pas le plus dur ou alors il faut changer les "excellents développeurs PHP")
Pour le reste ce que vous dites c'est qu'eZ Publish est plus complexe que Drupal ce qui est probablement vrai vu que le spectre fonctionnel des deux outils n'est pas tout à fait le même...


Submitted by Pierre Jean Duvivier on Tue, 05/20/2008 - 17:42. #
Le périmètre a même était étendu....
Le nouveau Femina sur DRUPAL propose beaucoup plus de fonctionnalités que l'ancien sous EzPublish car les couts liés au temps de développement sur EzPublish était trop important.
Concernant le chargement des pages, c'est un fait incontestable pour nous que nos sites sous EzPublish (site media a fréquence de rafraichissement important et non simple vitrine) étaient largement plus lents que nos nouveaux sites sous DRUPAL à complexité égale et à charge égale.


Submitted by Anonymous on Mon, 03/08/2010 - 18:42. #
Et quelles sont ces fonctionnalités supplémentaires?


Submitted by Pierre Jean Duvivier on Fri, 03/12/2010 - 15:05. #
La 1ere fonctionnalité est d'avoir un cache qui fonctionne et permet de doubler l'audience en 2 ans.
A l'époque les sites couvraient exactement le périmétre Ezpublish + les spécificités drupal qui fonctionnaient bien et en live comme le changement de content type à la volée qui fonctionne sous Drupal et ne fonctionnaient pas à l'époque sous Ez ( je ne sais pas maintenant honnêtement sous EzPublish).


Submitted by Anonymous on Fri, 07/09/2010 - 06:15. #
|merci pour le complément d'info] google