A suivre… Quelqu’un a-t-il des retours d’expérience de ces produits ?

C’est notamment un des seul CMS que je connaisse qui gère très très bien un site multilangue.
Un bon exemple d’utilisation : le site de l’EPFL http://www.epfl.ch

Je pense qu’on n’est qu’au début de l’histoire. Peu de personnes connaissent encore Zope. Le nom fait plutôt rire (c’est bête mais cela pose un réel problème d’image, surtout en France) et les gens sont focalisés sur la guerre .Net/J2EE. Certains voient même PHP5 en killer de J2EE, alors que ce n’est qu’un langage comme Perl, Python ou Ruby, qui sont d’ailleurs à mon avis supérieurs et performants (j’ai fait des benchs et PHP est 2 à 3 fois plus lent !). Mais je pense que Plone peut enfin faire décoller Zope. Par exemple, je viens de chercher Plone sur amazone.fr, et j’ai trouvé 4 livres. Pas mal pour un CMS opensource. Y’a que SPIP qui peut en faire autant… Et si je tape “documentum”, “vignette”, “interwoven”, “jalios” ou “noheto” : zéro réponse !
Autre indice : on commence à trouver pas mal de formations un peu partout, et ça, c’est rassurant pour les décideurs.

Qui vivra verra…

• savoir patienter avec humilité, ne pas fanfaronner, ne pas désespérer
• implémenter, en attendant, avec peu de moyens des choses simples et rapides pour pouvoir démontrer … la simplicité et la rapidité de la solution (dans sa “zone de confort”)
• être diplomate (merci au chef qui “prépare le terrain”) pour permettre un dialogue constructif lorsque toutes les parties reviennent à la raison

Autre chose ?

J’imagine que le challenge suivant pour toi doit être de se montrer à la hauteur des attentes lorsqu’il s’agira de tenir la route en production (robustesse, exploitabilité, maintenabilité, …). Bonne chance !

Tiens, pour la petite histoire que je pourrais raconter de mon côté, après avoir eu le sentiment de prêcher longtemps dans le désert, je viens de recevoir un email d’un collègue qui me dit, en substance : “pour le projet X (que l’on doit mettre en prod dans 15 jours), il paraît que le logiciel ‘Plone’ serait une bonne solution ; c’est l’équipe architecture J2EE qui m’en a parlé car ils l’utilisent pour partager leur documentation technique et suivre une partie de leurs activités ; qu’est-ce que tu en penses ?”

Amusant, non ?

Evidemment, c’est totalement impossible à réaliser dans une entreprise de grande taille. Une seule techno ne pourra jamais tout faire de façon optimale, et cela peut même être très dangeureux. Faut jamais mettre ses oeufs dans le même pannier, c’est bien connu. Et puis question intéropabilité, les webservices sont souvent suffisants, permettant ainsi à tout le monde de communiquer très facilement.
L’essentiel, c’est de respecter les normes en vigueur et d’éviter de s’embarquer dans des solutions fermées et propriétaires, comme Notes par exemple, qui vous rendent dépendant d’un éditeur. Par exemple, les architectes ont cru bon d’utiliser le carnet d’adresse Notes comme annuaire LDAP. Pratique, mais pas de bol, les mots de passe sont cryptés dans un algo propriétaire impossible à exporter : il sera très diffile de passer sur un véritable annuaire LDAP après.

Donc pour moi, le juste équilibre pour le web :
* PHP pour les développements rapides et spécifiques, en essayant de s’appuyer sur un framework objet (PHP5 va certainement améliorer les choses)
* Zope pour les portails de moyennes envergures, mais potentiellement riches fonctionnellement.
* J2EE pour les gros projets qui en ont vraiment besoin !

J’ai pas d’avis sur .Net, mais j’ai vu qu’on pouvait faire du Python avec et C# a l’air sympa, mais bon, ça reste du Microsoft… Je ne sais pas ce que vaut non plus le portage sous Unix “Mono”…

Suite en fait à l’étude sur les CMS il y a plus d’un an, j’avais réussi à faire passer l’idée à mon chef (qui lui est assez ouvert) le fait de faire travailler un p’tit stagiaire (non payé) sur une maquette du site du département en Plone. Ca tombait super bien car il avait déjà fait un peu de Zope pendant son DUT. Evidemment, ça n’a pas plus à certaines personnes, plus particulièrement les experts PHP, Notes et J2EE qui voyaient d’un sale oeil une nouvelle techno arriver. Tout le monde se moquait un peu de nous, trouvant le mot Zope très amusant.

Mais voilà, un mois après, le site était terminé. Après une petite demo, le chef devant le fait accompli s’exclama : “ben maintenant qu’il est fait, ça serait con de le refaire en PHP ou Java, on n’a qu’à l’utiliser. On dira aux architectes que c’est une expérimentation et surtout, il ne faudra pas dire aux clients qu’il est fait en Zope, ils seraient capables de nous en demander !!”
Vers mars 2004, les projets J2EE, englués dans des Bea Portal et Documentum surdimensionnés par rapport aux besoins, coûtant une fortune pour des résultats peu glorieux, firent émerger l’idée d’une solution certes moins riche mais plus rapide et moins chère. Alors, je retentai ma chance, mais encore raté. Les architectes décidèrent de lancer le projet J2EE “light”: développer un CMS basé sur Bea WorkShop, dans le genre de SPIP mais en Java, car Java, c’est du sérieux ! Franchement, j’ai failli mourrir de rire et je leur souhaitais bon courage, car ils avaient 6 mois pour réussir et 250 K€. Et comme prévu, 6 mois plus tard, rien n’était fait : Panique à bord, il faut trouver tout de suite un autre truc, car le client va pas être content !
Parallèlement, le chef du département lança un concours d’idée sur le principe : “Faire mieux et moins cher”. Très bien, et bien moi, j’ai un joujou extra, qui fait crack boom huuu, les sites en tombe à mes genoux. Le chef du département, convaincu par une offre basée sur Zope, alla voir les architectes pour préparer le terrain. 1 mois et une demo plus tard, c’étaient eux qui étaient à genoux :-)). Je les ai ensuite rassuré avec des références, des SSII…
Cet après-midi encore, j’ai refait une démo aux développeurs et chefs de projets : “Ouais, ç’est super ton truc pour mon projet, c’est bien mieux que SPIP”. Maintenant, il va falloir mettre en place très vite une cellule Zope car les frustrés de J2EE et PHP vont déferler !

@++

ARGH ! GNNN ! COMMENT !?!? Mais comment as-tu fait ??? Quelle est la recette miracle ? Comment as-tu réussi à convaincre un architecte Java ou un manager conservateur de la valeur de Zope et de l’opportunité d’adopter cette techno dans le S.I. ? J’avoue humblement que la tâche me paraît insurmontable chez mon employeur et que j’ai un peu baissé les bras (ce n’est pourtant pas faute d’avoir essayé). STP, raconte !

Après plus de 2 ans de veille sur les CMS, j’en suis arrivé à la même conclusion : les CMS Java ne sont pas très aboutis, surtout d’un point de vue “utilisateur”. Les développeurs Java pensent plutôt à quelles normes ils vont implémenter plutôt qu’aux fonctionnalités finales. En PHP, les CMS pulullent mais sont souvent médiocres et peu extensibles. SPIP est populaire mais vraiment trop limité et salement codé. Au boulot, des projets sont partis avec et ils ont voulu évoluer après : quelle mauvaise idée !

Finalement, depuis mon dernier commentaire, j’ai enfin réussi à faire comprendre aux architectes que Zope et Plone, c’est pas du pipo. Mais que ce fut long et pénible ! Le plus dur finalement a été de les convaincre d’assister à une petite démo concrète. Et ce fut pour eux LA révélation : comment un produit gratuit peut-il faire des trucs pareils sans EJB ni JSR168 !! Et en plus, 5 jours de dev pour faire un proto fonctionnel à 90%, c’est de la folie pure !

Depuis, ils vendent du Zope aux projets qui veulent partir sur du Java. Comme quoi, y’a que les imbéciles qui ne changent pas d’avis !