Media & Business.

En préambule je dirais que je n'affiche que mon intime conviction à travers cet article et mon expérience d'un an et demi de mise en application d'une solution à base d'EzPublish sur 4 grands sites totalisant environ 100.000 visiteurs uniques par jour.

J'étais tout d abord chef de projet sur un des projets puis ensuite responsable du département qui gérait l'ensemble des développements techniques liés à ces sites.

Ma première décision en tant que "nouveau" responsable du département fût d'arrêter les développements sous EZPublish.

Nous avions refondu tout nos sites sous un framework basé sur eZpublish en version "cluster". Il s'agissait de la version 3.8 mais il semble que la dernière version 4.0 présente des similarités.
Après un an et demi, nous avons donc décidé d'abandonner les solutions EzPublish pour nos sites et de refaire l'ensemble des sites eZpublish sous d'autres technologies dont je vous parlerai dans un nouveau post.

En voici les raisons :

La structure "macro" d'eZpublish :
Ce qui lui donne sa souplesse fonctionnelle lui enlève une percussion technique. En effet la structure de donnée d'EZpublish induit de multiples jointures SQL pour accèder à des éléments simples comme les titres ou chapeau...ou body d'un article. Pour pouvoir sortir ces éléments c'est parfois jusqu'à 7 tables qu'il faut mettre en action. Le résultat est la production de requêtes SQL très lourdes pour le serveur de Base de donnée.

La construction automatique des requêtes SQL:
Le moteur eZpublish produit automatiquement un certain nombre de requetes SQL avec les données que vous lui fournissez. Elles ne sont pas optimisées. En mettant en place un simple debug sur la première page dès son installation vous verrez que parfois nous avons des requetes de plusieurs pages pour la complexité d'un blog.

L'atomisation du système de cache:
EZpublish fragmente son systéme de cache. Ce qui parait séduisant au début devient vite un cauchemard de programmation car les blocks ou les vues ne décachent pas tous en maintenant. Vous avez donc des "pics de décachage" qui induisent la "reproduction des templates".

eZpublish ré-invente la compilation en PHP :

Au moment où vous "décachez"....misère car le moteur eZpublish va processer un language de template qui va reproduire des scripts PHP. Ce langage de template est en texte...non optimisé et non compilé. PHP va donc s'amuser à processer des fichiers textes pour reproduire des fichiers PHP.
Tout le monde sait bien que PHP est très à l'aise avec ces manipulations géantes de chaine de caractère (c'est une plaisanterie le langage n'est pas fait pour ça contrairement à PERL).

Bref dès que vous produisez du cache, les serveurs frontaux en bi quad core 3.8 ghz montaient à 100% de leur capacité pour la home..ralentissant toute la plateforme.

Notons qu'à chaque modification même infime d'un template il faut "le recompiler" à savoir se logguer sur le serveur en SSH...passez sa commande et attendre. Si vous avez plusieurs serveurs...cela devient un bel enfer.

du SQUID ou du VARNISH (quelque chose comme ça) tu mettras :

Les défaillances énoncées plus haut aménent plusieurs conséquences : nous avons été dans l'obligation de poser des SQUIDs devant nos 4 frontaux bi quad core doublés de 4 bases de données "costaud" pour simplement pouvoir mettre en ligne nos sites.

Là les pages avec du dynamique deviennent une horreur à gérer tant les problématiques de "surcachage" sont nombreuses entre les 3 ou 4 niveaux de cache eZ (même les fichiers de configuration ont du cache) et le SQUID devant.

Ton systéme deviendra difficilement maintenable :

eZpublish base sa pub sur sa souplesse. C'est certainement vrai ....mais par contre c'est guère prévu pour un site dèja en production.
Pour avoir essayer à plusieurs reprises d'ajouter à la volée des éléments dans une classe (à savoir par exemple un champs téléphone dans une classe "utilisateur)...c'est l'enfer car eZpublish va devoir reprocesser tout ce que vous avez déja mis en base de donnée pour transformer ces entrées pour chacun des éléments déja entrés avec la "vieille" classe.

Ces opérations sur des dizaines de milliers d'article laissent le bon vieux back d'EzPublish en rade grâce au bon PHP....

Il reste à utiliser une rustine non officielle d'EzPublish qui fait le boulot avec parfois quelques surprises
:)

Ajoutez à cela, l'explosion des fichiers de configuration "ini" qui sont légions et qui doivent être aussi recompilés....

Clou sur le gâteau : dans les fichiers ini des Ids de table sont mises en durs pour pouvoir faire fonctionner l'ensemble donc vous oubliez la possibilité de les faire passer de vos environnements de dev à une recette puis à une qualité....ces ini sont propres à chaque environnement et modifiables à la main à chaque fois après avoir été cherché dans la base de donnée support le bon ID de la bonne classe ou de la bonne vue.

Conclusion :

En 7 ans d'expérience sur des projets internet, j'ai vécu le cauchemard de ma vie avec ce CMS.

Pour moi, rien n'est y bien "pensé" au niveau technique.

Le temps de chargement de nos page était lent(10 secondes) en front office et affreusement lent (>30 secondes parfois ) en back office avec des plantages fréquents lors des transactions impliquant une perte des données en cours de stockage.

La solution de cluster imposant à l'époque (je crois qu'ils ont modifié maintenant) de toute mettre en base de donnée (binaire et data) nous a posé des problèmes de maintenance insolubles.

Pour terminer, le temps de développement est supérieur car en local nos développeurs sur nos serveurs étaient obligés d'attendre plusieurs minutes parfois pour avoir le résultat de leurs tests.

Sachant que quand vous programmez vous faites ce type de vérification fréquemment, je vous laisse imaginer la perte de temps liée.

Au final, la mise en place d'un framework basé sur une solution eZpublish a été un échec technique et commercial cuisant pour nous.

Hormis un choix malheureux de prestataire(s) 'peu performant(s)' dans notre cas, je suis persuadé que la solution EzPublish est structurellement défaillante pour des sites à fort traffic.

eZpublish peut faire tourner un blog comme n'importe quel autre CMS voir un site 'vitrine' (corporate par exemple) mais guère plus.

La solution eZpublish a gravement marqué les esprits "digitaux" au sein de notre entreprise et nous a poussé à développer de nouvelles approches dont je vous parlerai bientôt :

Approches liant économie de couts et efficacité de mise en oeuvre des solutions techniques.

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 natives d'eZpublish. Les éléments doivent donc être validés avec la dernière version d'EzPublish 4.0 que nous n'avons pas testé