CMS, web-agency : complémentaire ?

[aspeum]

Messieurs-dames, bonjour !

Cela fait plusieurs semaines que je fouille le web pour m'aider à choisir le bon CMS dans le cadre d'une refonte de site (limite portail). Et ce forum m'a paru incarner les compétences techniques et le bon esprit que je recherche pour recueillir des avis...

Les critères qui m'importent sont ceux-ci, par ordre d'importance :

- Profondeur de navigation (4 niveaux)

- Intégration de module externes

- Fiabilité

- Pérennité

- Souplesse d'administration

- Simplicité de la contribution pour les auteurs

- Rapidité d'affichage

- Multilinguisme

- Support de la communauté

1. Tout d'abord, dans la sélection suivante, lesquels puis-je exclure d'office ?

Typo3

SPIP

Joomla

PhpNuke

e107

Xoops

MODx

Drupal

Textpattern

PostNuke

ezPublish

2. Ensuite, que pensez-vous de solution de ce type : http://www.atelierphp.com ? Ce qui semble séduisant, c'est d'avoir une solution plus personnalisée qu'un CMS standard...

Est-ce une erreur de s'appuyer sur une web-agency ? Est-ce qu'il est parfois intéressant de faire appel à une web-agency, même pour un CMS open source ?

Modifié 18 Octobre 2006 par aspeum

[davidm]

De mon point de vue, tu peux déjà éliminer :

- PHP Nuke : rigide, et toujours des problèmes de sécurité...

- PostNuke: bien qu'un peu mieux que son grand-frère, reste rigide dans le carcan du modèle type "portail".

- Typo3 : puissant, mais lourd ça risque de te coûter fort cher en développement...

- ezPublish : puisssant aussi, et plus flexible mais tu ne trouveras pas des masses de prestataires compétent dessus et NiCoS en a parlé plusieurs fois, les projets sous eZ peuvent vite devenir très complexes. Sans compter les ressources serveurs (eZpublish est très consommateur de ressource, il te faudra un bon dédié).

A ne retenir que sous certaines conditions

- Joomla : si tu as des besoins "standard", séduisant parceque "tout en un click" donc potentiellement mise en oeuvre rapide. Attention toutefois si tu veux customiser que ce soit côté look ou fonctionnalités, ça peut prendre du temps et coûter un peu... Le support de la communauté est excellent.

- e107 : plus flexible au niveau des templates, et pas mal de modules orienté communauté, toutefois attention tous les modules ne sont pas hyper stables. A retenir si tu cherche à construire un site typé portail. Bonne communauté, sympa et dynamique.

Valeurs sûres

- Drupal : Puissant, flexible, rapide, supportant bien la charge, avec un excellent support du multilinguisme, de nombreux modules... Vu les caractéristique du projet, il serait sans aucun doute dans la liste. Par contre, l'admin n'est pas des plus conviviales. Et la communauté française est encore embrionaire et moyennement active.

- SPIP : L'incontournable, qui s'est bien amélioré ces derniers mois avec la 1.9. Pour des communautés, on cite souvent sa variante SPIP-Agora, plus riche fonctionnellement (mais je ne sais pas si les récentes améliorations de la 1.9 ont été reprises). Supporte le multilingue. Communauté active. La limitation c'est peut-être pour le moment le faible nombre de plugin (SPIP vient seulement de se doter de la possbilité d'en ajouter, il faut dire).

- Textpattern: stable, rapide, flexible. Une communauté dynamique et un grand nombre d'extension de grande qualité. Des possibilités de customisation importantes. Le point faible : pas orienté communauté à la base, et un développement en ralentissement depuis 1 an.

L'outsider

- MODx : evidemment étant membre de l'équipe, on peut me taxer d'être partial mais je pense sincèrement que MODx est un peu à part pour le moment. Ce n'est pas encore une "valeur sûre" avec plusieurs années derrière lui. Mais il a pour lui une flexibilité sans égal (que ce soit niveau look -> il vaut Textpattern, ou niveau structure des données -> Il vaut eZpublish) et une communauté sur-vitaminée (il suffit de voir l'augmentation du nombre d'extension en un an, et leur qualité...). La communauté française s'étoffe jour après jour, avec plusieurs français dans l'équipe de MODx y compris aux test / développement (Soda, Heliotrope) ou pour coder des extensions (Marc, Guillaume, et d'autres).... MODx est stable et rapide (les tests le mette à égalité avec Drupal), et aussi sûr que Drupal ou Joomla.

Le gros inconvénient par rapport à ton projet, c'est que MODx ne gère pas nativement le multi-linguisme comme Joomla, Drupal ou SPIP peuvent le faire. Il existe des méthodes, mais elles ne sont pas aussi performantes.

Enfin, la question concernant faire appel à une web agency pour un CMS open source : ce n'est pas une erreur, au contraire. A moins de prendre en charge soi-même la réalisation technique et de faire appel à la communauté pour résoudre les problèmes de développement, c'est même conseillé. Maintenant, tu n'as pas que les web-agency, tu as aussi les indépendants

CMS, web-agency : complémentaire ? Oui j'espère car je fais partie de cette génération d'indépendant qui travaille beaucoup (voire quasi exclusivement comme moi) avec des solutions open source Il y en a d'autres sur les forums ici comme Perrine par exemple. Un bon indicateur c'est de regarder si les prestataires jouent le jeux et participent activement au développement, au debugging, au financement voire font parti des modérateurs ou de l'équipe officielle.

Sans vouloir prêcher pour ma paroisse, je pense qu'un indépendant est un meilleur choix pour des projets de petite à moyenne taille. Les web agency utilisent souvent des techniques, outils et méthodes qui sont loin d'être au top (il n'y a qu'à voir le nombre de page créées sans même une DTD ! qui ne valident même pas HTML4 ou celles qui font 250ko voire plus...). Sans compter qu'au niveau des tarifs, c'est parfois franchement surestimé...

Mais sans rentrer dans ce type de débat je te conseille de choisir quelqu'un qui écoutera ton besoin plutôt que de plaquer des solutions toutes faites sur ton projet.

Evidemment je te conseille aussi de lire ça :

http://www.w3.org/QA/2002/07/WebAgency-Requirements

[Guest dotweb]

Bonjour,

Pour un site portail je te conseille Joomla qui possède énormément de composants pour rajouter des forums, galleries, gestion documentaire, réécriture d'url ...

D'ailleurs davidm je ne suis pas d'accord avec toi, Joomla possède une API qui permet de faire des choses très puissantes et rapidement

Pour un site portail je te déconseille Spip qui est très bien mais ne possède pas assez de modules complémentaires

Pour la question des webagencies, je peux te dire que ... ça dépend des webagencies

Certaines sont très pros et passent par des intégrateurs comme moi qui travaillent en sous-traitance sur ces domaines techniques (mais ça à un coût) lorsqu'elles n'ont pas les compétences en interne.

Sinon tu as aussi le choix de diviser le travail et de passer par des intégrateurs indépendants comme l'a dit davidm

[aour]

Bonjour

Je ne partage pas ton enthousiame sur l'API de Joomla.

Pratiquement Mambo depuis longtemps, puis joomla, le developpement de component ou module n'est pas à la portée de tous le monde et l'adoption de Pat Template ne va pas facilité les choses, et pourtant c'est PatTemplate qui amène le plus de souplesse à J! face à une API dont 60% sont consacrés aux controles HTML et le quasi reste à la gestion des blocs dans le template. De plus, developpé une interface pour l'admin est également hardu.

Aujourd'hui, dans le cadre d'une web-agencie je pense qu'il faut plutôt s'orienter vers des frameworks plus ou moins ardu car il y a heureusement aujourd'hui, une panoplie plus ou moins élevé et David ne me contredira pas, une petite formation Anaska sur php d'une semaine te donnera les billes pour évolué avec facilité dans ce monde

David, je ne suis pas trop d'accord avec toi concernant la capacité multilingue de Joomla qui n'est pas au niveau de drupal.

Pour se faire une idée je vous propose le tutos flash de Mabelfish aujourd'hui renommé Joom!Fish avec il est vrai quelques améliorations.

Aour

Modifié 18 Octobre 2006 par aour

[davidm]

D'ailleurs davidm je ne suis pas d'accord avec toi, Joomla possède une API qui permet de faire des choses très puissantes et rapidement

La question n'est pas le nombre de module existant (d'ailleurs j'ai insisté sur leur nombre), ni même sur l'API. Relis ce que j'ai écrit : j'ai dit que Joomla était un très bon CMS lorsque l'on souhaite faire du "standard" mais moins efficace lorsque l'on souhaite customiser que ce soit le look ou la structure de données.

Maintenant, c'est faisable et il y a des gens qui font des choses très bien avec Joomla, simplement c'est plus compliqué (donc plus long, donc plus cher).

Pour résumer, Joomla n'est pas (à mon avis) le meilleur choix pour faire du sur mesure...

Pour la question des webagencies, je peux te dire que ... ça dépend des webagencies Certaines sont très pros et passent par des intégrateurs comme moi qui travaillent en sous-traitance sur ces domaines techniques (mais ça à un coût) lorsqu'elles n'ont pas les compétences en interne. Sinon tu as aussi le choix de diviser le travail et de passer par des intégrateurs indépendants comme l'a dit davidm

Je pense que je me suis mal expliqué.

Je ne dis pas qu'il n'y a pas des web agencies qui travaillent proprement (l'exemple de groupe-reflect est pour moi un bon contre-exemple de ce qui se fait de bien dans les agences. Mais pour un exemple de ce type, il y en a facilement 100 qui sont à l'opposé.

Ce que je dis c'est que les indépendants sont obligés de se différencier et que souvent, ça les pousse à être plus pointu pour se différencier. On voit plus d'indépendant défendre les standards, l'accessiblité, que d'agences (en tout cas, française ). Maintenant, c'est vrai que pour des projet plus importants, de multiples compétences sont parfois nécessaires. La plupart du temps, les agences sont mieux placées pour ces demandes mais on voit de plus en plus de freelance s'allier sur des missions sous forme de réseaux informels (voire, plus formels comme des GIE).

Aussi, en moyenne, l'approche d'une agence est plus celle d'une stratégie de volume que celle de la personnalisation des prestations par rapport au besoin du client. Il est plus rapide et plus rentable pour une agence de vendre un produit "standardisé" (ou dont les éléments sont standardisé) que du sur-mesure. D'où une offre plus souvent basée sur du Typo3 ou du Joomla que sur des frameworks type Django, Code Igniter, et autre RoR pour prendre l'autre extrême.

Quant à la sous-traitance, en dehors des questions de prix, elle n'est pas toujours abordée de manière "transparente" (le client n'est pas toujours au courant que son site est réalisé par un sous-traitant). C'est un point à vérifier...

David, je ne suis pas trop d'accord avec toi concernant la capacité multilingue de Joomla qui n'est pas au niveau de drupal. Pour se faire une idée je vous propose le tutos flash de Mabelfish aujourd'hui renommé Joom!Fish avec il est vrai quelques améliorations.

Je n'ai pas dit que Joomla était aussi pointu que Drupal sur le multilinguisme, le module i18n de Drupal est un modèle du genre qui a peu d'équivalent en open source...

[NiCoS]

+1 / premier post de davidm sur le choix des outils et sur l'appel à un prestataire (qu'il s'appelle webagency, intégrateur, ssii,...).

Comme dans tout métier, il faut choisir le bon partenaire et pour chaque type de partenaire, il y a des bons et des moins bons...

De même, plutot que de choisir directement un outil, il me semble plus judicieux que tu te concentres sur la définition de tes besoins, qu'éventuellement tu communiques à l'éventuel prestataire une liste des outils que tu as vues mais qu'il puisse éventuellement t'en conseiller d'autre ou du moins celui qui lui parait le plus approprié pour ta demande. Ensuite, sur l'évaluation des différents outils, vous pouvez très bien lancer une discussion pour qu'il argument son choix

J'avoue avoir du mal parfois avec "je veux faire mon site avec tel outil" (sauf s'il y a une contrainte forte bien sur...), car souvent on voit que ce n'est pas l'outil le plus adapté ou que ce n'est pas la solution la plus optimale (en cout, délais, etc).

Modifié 19 Octobre 2006 par NiCoS

[gt4mike]

Bonjour tout le monde,

Etant utilisateur de joomla, quelques commentaires :

- pour le multi langues, ce n'est pas la peine.

- pour un truc original, je rejoins daviddm

Joomla : si tu as des besoins "standard", séduisant parceque "tout en un click" donc potentiellement mise en oeuvre rapide. Attention toutefois si tu veux customiser que ce soit côté look ou fonctionnalités, ça peut prendre du temps et coûter un peu... Le support de la communauté est excellent.

c'est faisable mais pas facile : voir ma signature

- pour un site portail je rejoins dotweb

Pour un site portail je te conseille Joomla qui possède énormément de composants pour rajouter des forums, galleries, gestion documentaire, réécriture d'url ...

joomla est parfais pour cela, mais les modules permettant le rewriting et les gestion des membres sont assez complexes à maitriser, mais une fois maitrisés tu peux faire des trucs assez pointus "formulaires php, rewriting, creation de multiples champs dans le profil des membres, creation de listes de membres, boutique en ligne, creation de groupes d'utilisateurs ayant des droits d'acces différents, etc...

Et puis concernant les modules galeries et forum, je préconise pour des raisons de securité la creation d'une galerie et d'un forum, indépendants de la base de données Joomla, facilitant ainsi les mise à jour joomla.

Modifié 19 Octobre 2006 par gt4mike

[aspeum]

Tout d'abord, merci à tous pour vos réponses, sacrément argumentées.

Je vais réagir point par point.

Typo3 : puissant, mais lourd ça risque de te coûter fort cher en développement...

Qu'entends-tu par là ?

- Textpattern: stable, rapide, flexible. Une communauté dynamique et un grand nombre d'extension de grande qualité. Des possibilités de customisation importantes. Le point faible : pas orienté communauté à la base, et un développement en ralentissement depuis 1 an.

Je ne comprends les deux passages en gras. Parles-tu dans le premier cas de la communauté de développeurs, et dans le second de la destination de l'outil ? Je suis perdu...

Maintenant, tu n'as pas que les web-agency, tu as aussi les indépendants

J'ai utilisé un terme précis, mais je pensais surtout à "un prestataire" en général (web-agency, développeur indépendant, SSLL, etc.) Donc, oui, on est d'accord !

CMS, web-agency : complémentaire ? Oui j'espère car je fais partie de cette génération d'indépendant qui travaille beaucoup (voire quasi exclusivement comme moi) avec des solutions open source Il y en a d'autres sur les forums ici comme Perrine par exemple. Un bon indicateur c'est de regarder si les prestataires jouent le jeux et participent activement au développement, au debugging, au financement voire font parti des modérateurs ou de l'équipe officielle.

Evoques-tu le cas où je choisis d'abord mon CMS, et ensuite je vais voir un indépendant qui fait partie de l'équipe de développement ? Parce que sinon, si je choisis d'abord un prestataire, je ne peux pas lui demander d'être investi dans l'équipe du CMS qui sera finalement choisi... A moins que j'ai mal compris...

Sans vouloir prêcher pour ma paroisse, je pense qu'un indépendant est un meilleur choix pour des projets de petite à moyenne taille. Les web agency utilisent souvent des techniques, outils et méthodes qui sont loin d'être au top (il n'y a qu'à voir le nombre de page créées sans même une DTD ! qui ne valident même pas HTML4 ou celles qui font 250ko voire plus...). Sans compter qu'au niveau des tarifs, c'est parfois franchement surestimé...

Oui, mais qu'est-ce qu'un projet à moyenne taille ? Je suis travaille pour une petite association, mais la quasi-totalité des grand médias nationaux consulte le site ou est abonnée au service d'alertes quotidiennes [j'aimerais bien en dire plus, mais je ne souhaite pas que dans un mois, quand on tape le nom de l'association en question, on tombe sur cette discussion ]

PS : DTD, qu'est-ce ?

Evidemment je te conseille aussi de lire ça :

http://www.w3.org/QA/2002/07/WebAgency-Requirements

Effectivement, ça m'a l'air très intéressant, je le garde sous le coude.

Pour un site portail je te conseille Joomla qui possède énormément de composants pour rajouter des forums, galleries, gestion documentaire, réécriture d'url ...

D'ailleurs davidm je ne suis pas d'accord avec toi, Joomla possède une API qui permet de faire des choses très puissantes et rapidement

Pour un site portail je te déconseille Spip qui est très bien mais ne possède pas assez de modules complémentaires

Une question, à ce propos : lorsque des extensions sont développées, n'y a-t-il pas un risque de voir ces extensions ne plus fonctionner lors de la mise à jour du CMS ?

Sinon, j'en profite au passage pour rectifier un peu ce que j'ai écrit : il s'agit bien d'un site à part entière, et non d'un portail... J'ai parlé de portail, mais j'aurais plutôt dû parler de site-ombrelle, contenant plusieurs grandes rubriques autonomes les unes par rapport aux autres...

De même, plutot que de choisir directement un outil, il me semble plus judicieux que tu te concentres sur la définition de tes besoins, qu'éventuellement tu communiques à l'éventuel prestataire une liste des outils que tu as vues mais qu'il puisse éventuellement t'en conseiller d'autre ou du moins celui qui lui parait le plus approprié pour ta demande. Ensuite, sur l'évaluation des différents outils, vous pouvez très bien lancer une discussion pour qu'il argument son choix

J'avoue avoir du mal parfois avec "je veux faire mon site avec tel outil" (sauf s'il y a une contrainte forte bien sur...), car souvent on voit que ce n'est pas l'outil le plus adapté ou que ce n'est pas la solution la plus optimale (en cout, délais, etc).

Oui, entièrement d'accord. Mais...

- Il est possible que je ne passe finalement par aucun prestataire externe. Dans cette hypothèse, je devrais bien faire le choix, seul.

- Les critères auxquels je fais allusion sont extraits d'un cahier des charges que je suis entrain de rédiger. Connaître les contraintes et possibilités des différents CMS permet de compléter ce cahier des charges, de rajouter des éléments auxquels je n'ai pas pensé, bref, de nourrir ma réflexion... Je n'ai jamais utilisé de CMS, je n'ai aucune préférence, je ne suis fermé à rien... Mais si je dois faire appel à un prestataire, j'estime que plus je serais informé (j'allais dire "armé"), plus je serais clair dans la description de mon besoin et lucide face aux propositions qui me seront faites.

Au vu des différentes remarques, ma liste se réduit à :

- Typo3

- SPIP

- MODx

- Drupal

- Textpattern

Si dans ma liste de départ, j'en ai oublié un incontournable, je suis à l'écoute

Depuis hier, j'ai pensé à d'autres fonctionnalités qui seront indispensables :

- génération de code qui ne posent pas de problème de référencement

- intégration de fichiers audio/vidéo

- possibilité de personnaliser (graphiquement et organisationnellement) les grandes rubriques du site

- possibilité d'interroger (via une sorte d'intranet que j'ai créé moi-même, en PHP) une base de données remplie à partir du site

Modifié 19 Octobre 2006 par aspeum

[buzzistic]

Visiblement dans ton cas le cahier des charges est très concret et bien finalisé : dans ce genre de cas, il est souvent plus rapide de passer par un développeur qui te fera exactement ce que tu recherches. Tu y gagnes en souplesse et en image : ton site est unique. Tu y gagnes du temps : pas mal de CMS demandent de comprendre le code avant de le modifier. A mon avis, en choisissant un bon presta qui te fais ce que tu veux point par point, tu y gagnes.

Les CMS sont à envisager hors d'un cadre commercial ou "professionnel" pour la rapidité de mise en oeuvre : pour la personnalisation , le temps de codage peut s'avérer long. Je peux en témoigner dans les solutions e-commerce par exemple (VirtueMart/PhpShop, OsCommerce) qui sont des produits où il faut pas mal de temps pour les rendre "dociles" niveau fonctions utiles et niveau interface.

Modifié 19 Octobre 2006 par tribords

[aspeum]

Visiblement dans ton cas le cahier des charges est très concret et bien finalisé : dans ce genre de cas, il est souvent plus rapide de passer par un développeur qui te fera exactement ce que tu recherches. Tu y gagnes en souplesse et en image : ton site est unique. Tu y gagnes du temps : pas mal de CMS demandent de comprendre le code avant de le modifier. A mon avis, en choisissant un bon presta qui te fais ce que tu veux point par point, tu y gagnes.

Les CMS sont à envisager hors d'un cadre commercial ou "professionnel" pour la rapidité de mise en oeuvre : pour la personnalisation , le temps de codage peut s'avérer long. Je peux en témoigner dans les solutions e-commerce par exemple (VirtueMart/PhpShop, OsCommerce) qui sont des produits où il faut pas mal de temps pour les rendre "dociles" niveau fonctions utiles et niveau interface.

Arf, me dis pas ça ! J'ai écarté cette piste récemment, après une longue réflexion, et voilà que tu me fais douter

En fait, mon directeur m'a demandé si je ne voulais pas moi-même développer ce site... Mais je débute en PHP, et je ne pense pas être à la hauteur... Par contre, passer par un développeur externe, pourquoi pas, c'est vrai...

Mais en même temps, n'y a-t-il pas un risque de "réinventer la route", c'est-à-dire de recréer plein de fonctionnalités qui existent déjà via CMS ? Je sais que je vais de toute manière avoir à faire appel à un développeur, car une fonctionnalité du site est complètement inédite et nécessite d'être créée from scratch...

Quand tu dis qu'en évitant de passer par un CMS, je pourrais obtenir un site "unique", tu veux dire que c'est impossible avec un CMS ? En ce moment, je travaille avec le graphiste sur les maquettes du site : elles ne ressemblent en rien aux standard-trois-colonnes qui semble proposé par défaut sur de nombreux CMS... Est-ce que je commet une erreur en imaginant pouvoir paramétrer à ma guise un CMS, en ce qui concerne le graphisme ?

[Guest dotweb]

aspeum, c'est une erreur de penser qu'on ne peut faire que du 3 colonnes avec des cms.

C'est vrai que souvent on imagine une structure d'affichage rigide.

Par exemple on dit de Joomla que tous les sites qui tournent grâce à lui se ressemblent, pourquoi ? Parce que tous les créateurs de templates pour Joomla sont Américains et pondent du 3 colonnes alors que j'ai vu des sites où tu ne peux même pas soupsonner que Joomla est derrière car il y a une charte graphique unique faite par un vrai pro et car la structure d'affichage est totalement différente.

[aspeum]

aspeum, c'est une erreur de penser qu'on ne peut faire que du 3 colonnes avec des cms.

C'est vrai que souvent on imagine une structure d'affichage rigide.

Par exemple on dit de Joomla que tous les sites qui tournent grâce à lui se ressemblent, pourquoi ? Parce que tous les créateurs de templates pour Joomla sont Américains et pondent du 3 colonnes alors que j'ai vu des sites où tu ne peux même pas soupsonner que Joomla est derrière car il y a une charte graphique unique faite par un vrai pro et car la structure d'affichage est totalement différente.

C'est bien ce que je pensais, et tu me rassures sur ce point... En effet, j'ai souvent l'impression que les personnes qui mettent en place les CMS réfléchissent à la disposition des éléments une fois qu'il est installé... Ce qui doit considérablement brider l'imagination, à mon sens...

D'ailleurs, j'ai lu de nombreuses discussions sur l'accessibilité qui affirmait que c'était une erreur de se pencher sur des maquettes graphiques avant d'avoir entièrement défini l'architecture du site... Je comprends bien l'idée, mais travailler sur des maquettes (en ayant en tête des notions d'ergonomie, de navigation), ça peut parfois sacrément inspirer ce à quoi va ressembler le site, même sur le plan de l'arborescence...

Sinon, il y a un point sur lequel personne n'a répondu, c'est le suivant :

que pensez-vous de solution de ce type : http://www.atelierphp.com ? Ce qui semble séduisant, c'est d'avoir une solution plus personnalisée qu'un CMS standard...

C'est à mi-chemin entre le CMS open source et le développement entièrement à la carte... Ca vous parait pertinent ?

[davidm]

Je vais réagir point par point.

Qu'entends-tu par là ? Je ne comprends les deux passages en gras. Parles-tu dans le premier cas de la communauté de développeurs, et dans le second de la destination de l'outil ? Je suis perdu...

Pardon oui ça n'était pas clair : ton interprétation est bonne...

J'ai utilisé un terme précis, mais je pensais surtout à "un prestataire" en général (web-agency, développeur indépendant, SSLL, etc.) Donc, oui, on est d'accord ! Evoques-tu le cas où je choisis d'abord mon CMS, et ensuite je vais voir un indépendant qui fait partie de l'équipe de développement ? Parce que sinon, si je choisis d'abord un prestataire, je ne peux pas lui demander d'être investi dans l'équipe du CMS qui sera finalement choisi... A moins que j'ai mal compris...

J'aurai du être plus précis en effet.

Je pense qu'étant donné ta problématique et le fait que tu ne sais pas encore si tu vas confier la réalisation à un prestataire, tu pourrai envisager de faire appel à un professionnel pour définir ton besoin. En général, une petite réunion de 1h30 bien menée avec une méthodologie en entonnoir (on élimine pas à pas les éléments clés à vérifier pour arriver à cerner le besoin progressivement) permet d'aboutir à un choix d'outil (ou liste de 2/3 d'outils) cohérent.

Une fois que tu as choisi l'outil, tu peux choisir ton prestataire plus facilement, en examinant justement quel est la maîtrise qu'il a de la solution qu'il propose.

Oui, mais qu'est-ce qu'un projet à moyenne taille ? Je suis travaille pour une petite association, mais la quasi-totalité des grand médias nationaux consulte le site ou est abonnée au service d'alertes quotidiennes [j'aimerais bien en dire plus, mais je ne souhaite pas que dans un mois, quand on tape le nom de l'association en question, on tombe sur cette discussion ]

Petite, moyenne, grande taille, c'est un peu arbitraire c'est vrai. J'aurai du parler de complexité plutôt que de taille comme on le fait traditionnellement dans le milieu. Comme tu le dis ça ne reflète pas l'envergure du site.

Personnellement, je m'appuie sur plusieurs critères pour évaluer la complexité d'un projet :

1) La couverture fonctionnelle : c'est là que ton cahier des charges rentre en ligne de compte. En plus des grandes fonctionnalités (forum, blog ou autre galeries), il doit détailler les actions type qu'un utilisateur doit pouvoir effectuer. Ensuite, tu attribue une priorité à telle ou telle fonction, puis tu effectues une comparaison avec l'existant. Pour résumer, plus la couverture fonctionnelle est large (plus tu as besoin de fonction), plus le projet est complexe.

Comment on évalue la couverture fonctionnelle ? On se pose quelques questions. Prenons l'exemple d'un forum.

Tel module de forum existe : répond t-il à toutes les exigences les plus importantes ? oui. Répond t-il aux exigences secondaire ? non. Est-ce que les avantages de la solution sont suffisant pour laisser de côté des fonctionnalités ? oui/non. Souvent, les fonctionnalités secondaires sont surestimées dans la valeur perçue par l'utilisateur final. N'oublions pas que plus une extension ou un système est fonctionnellement riche, moins la proportion de fonctionnalités utilisées sera importante. Autrement dit parfois moins, c'est plus. Attention, je ne dis pas que Vanilla (forum ultra léger) sera toujours meilleur que IPB par exemple. Simplement que lorsqu'on envisage IPB, il faut que cela corresponde à un besoin réel. Il ne suffit pas de dire "Vous avez besoin d'un forum, je vais vous installer le forum le plus puisssant du marché". Comme le dit NiCoS, il faut d'abord, encore et toujours partir des besoins.

2) Le degré de personnalisation :

a) Côté design : un site sur mesure demande une réflexion préalable plus approfondie. On ne part pas d'une structure prédéfinie. L'idée est de partir d'une réflexion approfondie sur les besoins des visiteurs/utilisateurs du site pour élaborer une structure de page qui permette de mettre en valeur les informations, des plus importantes aux moins importante (hiéarchie visuelle). Avec les méthodes modernes (CSS), on peut faire énormément de variantes de mise en page. Si on fait les choses bien, on met aussi en place les briques nécessaire à une maintenance et un redesign facilité (par exemple, j'utilise une technique dénommée "server side CSS" qui permet de modulariser les feuilles de styles et rendre certains éléments dynamiques. En gros, faire avec les styles CSS ce qu'on a commencé à faire avec les pages web avec php dans les années 90 -> des pages dynamiques. Donc on utilise maintenant des feuilles de styles dynamiques).

Côté fonctionnalités : On a parlé de couverture fonctionnelles (nombre de fonctionnalités) mais là on va parler de fonctionnalités sur mesure. Lorsqu'un besoin n'est satisfait par aucun outil (ou aucun qui corresponde au budget et à l'environnement technique comme le serveur), il faut examiner l'opportunité d'un développement spécifique. Là plus qu'ailleurs il faut clairement établir que cela correspond à un besoin réel, car un développement spécifique, ça coûte. Evidemment, plus un projet demande de développement spécifique, plus il est complexe (et aussi, plus le délai de livraison est soumis à des aléas).

D'autres critères rentrent en ligne de compte, mais ce sont les deux principaux.

PS : DTD, qu'est-ce ? Effectivement, ça m'a l'air très intéressant, je le garde sous le coude.Une question, à ce propos : lorsque des extensions sont développées, n'y a-t-il pas un risque de voir ces extensions ne plus fonctionner lors de la mise à jour du CMS ?

Oui pardon, DTD c'est "Document Type Definition", autrement dit cela permet au navigateur qui parcoure une page web de savoir quel "grammaire" le document web utilise. Cet article d'OpenWeb te donnera plus de billes.

Pour ce qui est des extensions, effectivement lors des montées en version il peut être nécessaire de modifier celles-ci. Dans la plupart des cas, ça n'est nécessaire que lorsque l'API du CMS est modifiée, ce qui ne se produit pas à chaque version. Aussi, tout dépend du degré d'activité de la communauté de développeur autour du CMS. Une extension "majeure" reste rarement longtemps sans être mise à jour, parceque la communauté en fait largement l'usage.

Depuis hier, j'ai pensé à d'autres fonctionnalités qui seront indispensables :

- génération de code qui ne posent pas de problème de référencement

- intégration de fichiers audio/vidéo

- possibilité de personnaliser (graphiquement et organisationnellement) les grandes rubriques du site

- possibilité d'interroger (via une sorte d'intranet que j'ai créé moi-même, en PHP) une base de données remplie à partir du site

J'ai aussi vu que tu parlai d'un système d'alerte. C'est un point important, tous les CMS n'en disposent pas...

Enfin, concernant A****PHP (je m'auto-censure, et pas de lien), je dirai que leur site est très ambigu et ce genre de déclaration ne m'inspire guère confiance :

Open source mais pas... GNU-GPL.

A*****PHP est une solution Open-Source, entièrement en PHP, simple à installer, mettre en oeuvre et faire évoluer. Les développeurs qui l'ont inspectées vous le confirmeront. Mais elle appartient à ses concepteurs qui en assurent, avec leurs clients, les évolutions et la sécurisation

Vrai, tous les projets open source ne sont pas en GNU GPL : il y a aussi les licences BSD, MIT, Apache... etc. Mais ils ont une licence !

Là, on ne sait pas, c'est le flou total. Ca me semble être purement et simplement une application commerciale.

"Les développeurs qui l'ont inspectées vous le confirmeront."

Habituellement, il existe un forum de développeur accessible à tous qui permet justement de le savoir... d'autre part, le code est ouvert donc on peut regarder soi-même... là : rien.

"Mais elle appartient à ses concepteurs qui en assurent, avec leurs clients, les évolutions et la sécurisation"

Autrement dit c'est une application commerciale (dont on a aucun prix, d'ailleurs, sur le site... détrompez moi si j'ai raté quelque chose...).

D'autre part, tu n'as pas de démo, et tu ne peux pas le télécharger (une première pour un soft open source ).

D'ailleurs, à propos de démos, je te suggère de faire un tour sur opensourcecms.com ou tu pourras tester les sytèmes qui t'intéressent.

[aspeum]

Je pense qu'étant donné ta problématique et le fait que tu ne sais pas encore si tu vas confier la réalisation à un prestataire, tu pourrai envisager de faire appel à un professionnel pour définir ton besoin. En général, une petite réunion de 1h30 bien menée avec une méthodologie en entonnoir (on élimine pas à pas les éléments clés à vérifier pour arriver à cerner le besoin progressivement) permet d'aboutir à un choix d'outil (ou liste de 2/3 d'outils) cohérent.

Une fois que tu as choisi l'outil, tu peux choisir ton prestataire plus facilement, en examinant justement quel est la maîtrise qu'il a de la solution qu'il propose.

D'accord, je comprends mieux la démarche. C'est vrai que ça peut être une bonne solution... Je note

Merci aussi pour ta "méthode de définition de la complexité d'un projet" : c'est bête, mais ça clarifie carrément ma vision de voir les choses... Je vais plancher un peu pour essayer de me faire une idée objective de la question quant à mon projet...

J'ai aussi vu que tu parlai d'un système d'alerte. C'est un point important, tous les CMS n'en disposent pas...

Ok... En même temps, je pense que ça sera développé en dehors du CMS, parce que ça fait partie de toute une application à part entière, qu'aucun CMS actuel ne peut gérer de toute manière...

Sinon, pour l'application sur laquelle je m'interrogeais, merci pour tes remarques... Oui, il s'agit bien d'une application payante... Mais c'était justement une partie de ma question : y a-t-il une différence (et si oui, à quel niveau) entre payer un prestataire pour choisir/mettre en place un CMS open source, et payer un prestataire pour qu'il installe son propre CMS ? Cette dernière solution n'est pas différente de travailler directement avec un développeur pour un site personnalisé, si ?

[Autre site (du même genre) qui a retenu mon attention : http://www.waaps.fr]

D'ailleurs, à propos de démos, je te suggère de faire un tour sur opensourcecms.com ou tu pourras tester les sytèmes qui t'intéressent.

Oui, j'ai été y faire un tour... Et je vais probablement devoir m'y plonger plus longuement... Tiens, d'ailleurs, j'ai été surpris d'un détail, lors de mon dernier essai... J'avais lu qu'il était impossible d'imbriquer plus de 2 niveaux de rubriques avec Joomla! ; or, j'en en imbriqué 4 hier... Miracle de l'informatique ou malcompréhension de ma part ?

[davidm]

D'accord, je comprends mieux la démarche. C'est vrai que ça peut être une bonne solution... Je note Merci aussi pour ta "méthode de définition de la complexité d'un projet" : c'est bête, mais ça clarifie carrément ma vision de voir les choses... Je vais plancher un peu pour essayer de me faire une idée objective de la question quant à mon projet...

A mon avis, c'est une étape clé de ton projet.

Pour la méthodo, je suis sûrement influencé par mes 5 années en tant que consultant en organisation / processus, ceci dit

Sinon, pour l'application sur laquelle je m'interrogeais, merci pour tes remarques... Oui, il s'agit bien d'une application payante... Mais c'était justement une partie de ma question : y a-t-il une différence (et si oui, à quel niveau) entre payer un prestataire pour choisir/mettre en place un CMS open source, et payer un prestataire pour qu'il installe son propre CMS ? Cette dernière solution n'est pas différente de travailler directement avec un développeur pour un site personnalisé, si ?

Je pense qu'il faut distinguer plusieurs choses. C'est vrai qu'on va souvent se focaliser sur les prix :

- le coût des prestations elles-même (là, ça dépend plus de la nature de la prestation que de la licence du logiciel)

- le coût des licences (zéro pour l'open source, payante selon des modalités plus ou moins restrictives -> nb d'utilisateurs, fréquence de renouvellement...etc)

- le coût du support (c'est souvent là qu'on va te dire que l'open source n'est pas forcémment économique parcequ'il faut passer par un prestataire au lieu de s'adresser à l'éditeur du logiciel, supposémment moins cher. Mais franchement, ça reste à voir...)

Ce qu'on oublie parfois de souligner, c'est que choisir une application "propriétaire" demande de faire attention :

- au format des données : s'agit-il d'un format "ouvert" dont les spécifications sont publiques ? Si ce n'est pas le cas (comme pour Office) tu te retrouve captif de ton fournisseur parceque tu n'est pas vraiment totalement propriétaire de tes données (!).

- à la pérennité du fournisseur : dans le monde du propriétaire, on a pas accès au code source de l'application, si l'éditeur fait faillite on se retrouve dans une situation assez désagréable car on ne maîtrise plus son application...

[Autre site (du même genre) qui a retenu mon attention : http://www.waaps.fr] Oui, j'ai été y faire un tour... Et je vais probablement devoir m'y plonger plus longuement... Tiens, d'ailleurs, j'ai été surpris d'un détail, lors de mon dernier essai... J'avais lu qu'il était impossible d'imbriquer plus de 2 niveaux de rubriques avec Joomla! ; or, j'en en imbriqué 4 hier... Miracle de l'informatique ou malcompréhension de ma part ?

Avec d'autres applications, comme MODx, l'imbrication n'a aucune limite de niveaux (quoique, d'un point de vue de l'utlisabilité, faire ce genre de choix est discutable...)

Pour en revenir à waaps, il faudrait que je regarde...

[vincedo]

- Drupal : Puissant, flexible, rapide, supportant bien la charge, avec un excellent support du multilinguisme, de nombreux modules... Vu les caractéristique du projet, il serait sans aucun doute dans la liste. Par contre, l'admin n'est pas des plus conviviales. Et la communauté française est encore embrionaire et moyennement active.

A mon grand damn ! C'est bien pour ça qu'un site comme http://drupalfrance.org/ a été créé.

Sinon, rien à ajouter sur le comparatif des différents CMS, à part que, comme l'évoque la question-titre de ce thread, je suis persuadé que la combinaison "open source + cms + prestataire" a de l'avenir (et je dis pas seulement ça parce que c'est mon gagne-pain ). En termes d'efficacité, de coût, de logique (ne pas réinventer la roue...), etc.

[NiCoS]

y a-t-il une différence (et si oui, à quel niveau) entre payer un prestataire pour choisir/mettre en place un CMS open source, et payer un prestataire pour qu'il installe son propre CMS ? Cette dernière solution n'est pas différente de travailler directement avec un développeur pour un site personnalisé, si ?

Pour moi il y a une énorme différence :

- si tu fais appel à un prestataire qui ne vend qu'un cms (au delà des problématiques de format ouverts, pérennité de l'entreprise, etc mentionnés par davidm), le prestataire ne pourra pas te proposer autre chose et tu risques de payer très cher le fait d'adapter l'outil à ton besoin... voir même tu devras adapté ton besoin à l'outil...

- si tu fais appel à un prestataire utilisant des outils opensource/libre et que ce dernier en maitrise plusieurs, alors il va pouvoir répondre à ton besoin en prenant l'outil qui répond le plus à tes besoins (le 100% est rarement atteignable, quoique...) et donc tu évites d'être dépendant d'un prestataire en tant que tel (un autre prestataire peut maitriser l'outil retenu) et en plus, le cout des dev devrait être moindre (et à long terme, la maintenance et montée de versions devrait être facilitée).

C'est cette approche (compétences sur plusieurs cms & technologique) que ma boite a retenu. Cela nous permet pour un cahier des charges données de pouvoir répondre avec l'outil qui nous semble le plus adapté (que celui-ci soit open source ou propriétaire d'ailleurs). Il nous arrive même d'évaluer les outils de nos clients au regard de produits du marché. Il m'est ainsi arrivé dernièrement d'évaluer des CMS comme drupal, ezpublish avec le framework d'un de nos clients pour voir quel était l'outil le plus adapté pour réaliser leur projet...

Pour en finir, je te dirais effectivement de bien définir ce que tu veux d'un point de vue fonctionnel (voir les propos de davidm que je rejoinds totalement) et ensuite de proposer ton cahier des charges à des prestataires qui ont des compétences multiples pour avoir la meilleure réponse possible... Il est à mon avis pas/peu souhaitable que tu te focalises déjà sur un outil (mais avoir un aperçu des fonctionnalités des cms existants peut t'aider bien sur dans ta réflexion...).

Hope it helps...

[vincedo]

Pour moi il y a une énorme différence :

- si tu fais appel à un prestataire qui ne vend qu'un cms (au delà des problématiques de format ouverts, pérennité de l'entreprise, etc mentionnés par davidm), le prestataire ne pourra pas te proposer autre chose et tu risques de payer très cher le fait d'adapter l'outil à ton besoin... voir même tu devras adapté ton besoin à l'outil...

- si tu fais appel à un prestataire utilisant des outils opensource/libre et que ce dernier en maitrise plusieurs, alors il va pouvoir répondre à ton besoin en prenant l'outil qui répond le plus à tes besoins (le 100% est rarement atteignable, quoique...) et donc tu évites d'être dépendant d'un prestataire en tant que tel (un autre prestataire peut maitriser l'outil retenu) et en plus, le cout des dev devrait être moindre (et à long terme, la maintenance et montée de versions devrait être facilitée).

Oui, cela dit, tu peux être un prestataire spécialisé dans UN outil open source (c'est mon cas). A toi de dire alors à tes clients potentiels si ce CMS est adapté à leurs besoins ou non. S'il l'est, c'est idéal car tu es spécialiste du domaine.

En plus, du point de vue du prestataire, en utilisant toujours le même outil, tu augmentes ton expertise et tu peux ré-utiliser l'expérience/le code d'un projet à l'autre.

[davidm]

Je pencherai quand même pour un compromis entre proposer 20 outils open source et 1 seul. Le problème d'être mono-produit c'est qu'on est pas forcémment objectif par rapport au choix de l'outil et que si on aborde une demande on peut être tenté de ne pas écouter le besoin (c'est naturel, sinon on ne vit pas ).

Ceci dit, si le client passe d'abord par un prestataire uniquement pour définir son besoin et obtenir une matrice de correspondance entre besoin/fonctionnalités alors oui tu peux être bien placé. Mais par expérience, c'est rarement le cas pour des petits/moyens projets (et c'est bien dommage ).

Personnellement, je passe systématiquement par une phase (qui paraît parfois longue au client parcequ'il ne voit pas les choses avancer "concrètement") de définition des besoins et du choix de l'outil. Parfois il faut bien insister qu'on gagne tu temps par la suite, et surtout on évite (ou on réduit les risques) de se fourvoyer...

Sinon pour ce qui est de la spécialisation, en ce qui me concerne, j'ai choisi un positionnement intermédiaire. J'ai quelques outils à mon arc : MODx bien sûr mais aussi Textpattern ou CMS Made Simple. Je compte passer un peu de temps à approfondir SPIP et Drupal pour étendre ma capacité de réponse. Et aussi, développer mes compétences sur Code Igniter pour faire du très spécifique. Enfin côté applications web plus pointues j'en choisi une par "type" : ActiveCollab pour la gestion de projet, UNB pour les forums, Vtiger pour la CRM, DotClear pour le blog... Sinon, pour ce qui est du positionnement, j'ai décidé de ne faire que du sur mesure : je n'utilise jamais de template "tout fait" ni de contrat "tout fait". J'ai déjà refusé des clients qui souhaitaient ce genre de prestations. Le "vite fait bien fait" pour pas cher, ce n'est pas mon marché...

Je pense qu'il est tout à fait possible que maîtriser plusieurs applications. Mais cela prend du temps. Je sais que je passe facilement un tiers de mon temps lorsque je suis en mission et deux tiers hors contrat à me former . Il faut dire aussi que pour moi, c'est une passion et que ma semaine ne fait pas 40 heures J'imagine que c'est la même chose pour pas mal d'indépendants...

[vincedo]

Hello David,

Je pencherai quand même pour un compromis entre proposer 20 outils open source et 1 seul. Le problème d'être mono-produit c'est qu'on est pas forcémment objectif par rapport au choix de l'outil et que si on aborde une demande on peut être tenté de ne pas écouter le besoin (c'est naturel, sinon on ne vit pas ).

Tout à fait d'accord.

J'ai quelques outils à mon arc : MODx bien sûr mais aussi Textpattern ou CMS Made Simple. Je compte passer un peu de temps à approfondir SPIP et Drupal pour étendre ma capacité de réponse. Et aussi, développer mes compétences sur Code Igniter pour faire du très spécifique. Enfin côté applications web plus pointues j'en choisi une par "type" : ActiveCollab pour la gestion de projet, UNB pour les forums, Vtiger pour la CRM, DotClear pour le blog...

Je pense qu'il est tout à fait possible que maîtriser plusieurs applications. Mais cela prend du temps. Je sais que je passe facilement un tiers de mon temps lorsque je suis en mission et deux tiers hors contrat à me former . Il faut dire aussi que pour moi, c'est une passion et que ma semaine ne fait pas 40 heures J'imagine que c'est la même chose pour pas mal d'indépendants...

Je suis impressionné par le nombre de cordes à ton arc, et j'aimerais en avoir autant. Perso, je trouve qu'il n'est déjà pas évident de maîtriser à fond un outil de type CMS, ensuite il faut également maîtriser le langage qu'il utilise (en l'occurence, PHP), et enfin maîtriser les compétences annexes mais nécessaires (base de données, design, hébergement...).

Même si j'adhère tout à fait à tes arguments, la spécialisation est une nécessité liée à la taille de ma société, au temps dont je dispose, et aussi à une politique commerciale : le fait d'être "le type qui fait des sites avec ZZZZ" fait que les gens viennent te voir pour ça. Dans mon cas, je reçois pas mal de demandes du type "devis pour faire notre site avec Drupal", plutôt que "quelle solution préconisez-vous pour notre site ?".

Ensuite, c'est aussi une affaire de passion, d'envergure et de variétés des projets. Comme tu l'as souligné, toi tu ne fais que du sur mesure, chose que tu peux te permettre vu l'éventail de tes compétences. Quand on est "le type qui fait des sites avec ZZZZ", on risque de faire toujours le même type de sites, et vu qu'on est mono-compétence (ou quasi), on bosse souvent sur des projets qui impliquent peu de compétences, donc des petits/moyens projets.

[NiCoS]

Je n'ai pas dit non plus qu'il fallait avoir 20 outils à son arc

Sur le principe, on a la même logique que davidm (se concentrer sur qqs outils pour avoir une bonne compétence sur chacun d'entre eux tout en ayant la possibilité d'offrir un panel à nos clients) sauf qu'avec notre nombre (~40), on a un effet multiplicateur intéressant

Ensuite, c'est aussi une affaire de passion, d'envergure et de variétés des projets. Comme tu l'as souligné, toi tu ne fais que du sur mesure, chose que tu peux te permettre vu l'éventail de tes compétences. Quand on est "le type qui fait des sites avec ZZZZ", on risque de faire toujours le même type de sites, et vu qu'on est mono-compétence (ou quasi), on bosse souvent sur des projets qui impliquent peu de compétences, donc des petits/moyens projets.

Faut en tous cas bien choisir son produit pour une telle stratégie.

Il y a 2 ans en arrière, alors que beaucoup de CMS permettaient encore peu de typer ses contenus ou de créer des nouveaux types de contenus, je me suis souvent retrouvé bloqué ou du moins un peu en peine à répondre à certains cahier des charges.

Si les besoins vont vers des aspects que ton outil ne couvre pas du tout ou peu, tu vas te retrouver dans la mouise et à devoir trouver un remplaçant. Néanmoins, avec drupal, tu as a priori un panel de fonctionnalités importantes qui devrait te permettre de voir venir les choses

[aspeum]

- le coût du support (c'est souvent là qu'on va te dire que l'open source n'est pas forcémment économique parcequ'il faut passer par un prestataire au lieu de s'adresser à l'éditeur du logiciel, supposémment moins cher. Mais franchement, ça reste à voir...)

Qu'est-ce que tu entends pas support ?

Ce qu'on oublie parfois de souligner, c'est que choisir une application "propriétaire" demande de faire attention :

- au format des données : s'agit-il d'un format "ouvert" dont les spécifications sont publiques ? Si ce n'est pas le cas (comme pour Office) tu te retrouve captif de ton fournisseur parceque tu n'est pas vraiment totalement propriétaire de tes données (!).

- à la pérennité du fournisseur : dans le monde du propriétaire, on a pas accès au code source de l'application, si l'éditeur fait faillite on se retrouve dans une situation assez désagréable car on ne maîtrise plus son application...

Et dans le cas où l'application propriétaire est entièrement codée en PHP, et que le client a entièrement accès à ce code, on se retrouve ni plus ni moins dans la même situation que si on avait travaillé avec un développeur indépendant qui avait tout créé pour l'ocassion, non ?

Avec d'autres applications, comme MODx, l'imbrication n'a aucune limite de niveaux (quoique, d'un point de vue de l'utlisabilité, faire ce genre de choix est discutable...)

C'est vrai... là, je suis sur 4 niveaux... 3 niveaux sont incompressibles... le quatrième, je planche sur mon arborescence pour le faire disparaitre

je suis persuadé que la combinaison "open source + cms + prestataire" a de l'avenir (et je dis pas seulement ça parce que c'est mon gagne-pain ). En termes d'efficacité, de coût, de logique (ne pas réinventer la roue...), etc.

Et vu que tu occupes précisément ce poste de prestataire, peux-tu me dire à quoi correspond ton rôle ? (dans les grandes lignes, hein) T'arrive-t-il de sentir que ton apport est minime, par exemple dans le cas où ton interlocuteur a de solides connaissances du web, voire en matière de programmation ?

Pour en finir, je te dirais effectivement de bien définir ce que tu veux d'un point de vue fonctionnel (voir les propos de davidm que je rejoinds totalement) et ensuite de proposer ton cahier des charges à des prestataires qui ont des compétences multiples pour avoir la meilleure réponse possible... Il est à mon avis pas/peu souhaitable que tu te focalises déjà sur un outil (mais avoir un aperçu des fonctionnalités des cms existants peut t'aider bien sur dans ta réflexion...). Je te demande parce que je ne voudrais faire appel à un prestataire qui ne ferait que faire ce que je pourrais faire moi...

Hope it helps...

Ca m'aide, sans aucun doute. Et si je cherche à me faire une idée sur les outils disponibles, c'est parce que je ne sais pas encore si je passe par un prestataire ou non (cf. le paragraphe juste au-dessus)

Ceci dit, si le client passe d'abord par un prestataire uniquement pour définir son besoin et obtenir une matrice de correspondance entre besoin/fonctionnalités alors oui tu peux être bien placé. Mais par expérience, c'est rarement le cas pour des petits/moyens projets (et c'est bien dommage ).

En ce qui me concerne, je n'aurais même jamais pensé que c'était possible ! Mais ça a peut-être plus de sens pour un client qui ne connait pas grand chose au web, non ?

[davidm]

Je suis impressionné par le nombre de cordes à ton arc, et j'aimerais en avoir autant. Perso, je trouve qu'il n'est déjà pas évident de maîtriser à fond un outil de type CMS, ensuite il faut également maîtriser le langage qu'il utilise (en l'occurence, PHP), et enfin maîtriser les compétences annexes mais nécessaires (base de données, design, hébergement...).

N'exagérons pas. Je ne suis pas un martien non plus : je connais plusieurs personnes qui sont à peu près dans ma configuration en tant qu'indépendants. Je me suis plongé dans les CMS depuis 1998, et vraiment activement depuis 2002. J'ai eu le temps de m'imprégner donc. A partir d'un certain moment, on capitalise aussi car la logique d'un CMS n'est jamais totalement unique. Par exemple, le fait d'avoir bossé 2 ans avec Textpattern m'a aidé à me former à MODx en très peu de temps (par exemple, Textpattern utilise des forms comme micro template pour les plugin de la même manière que MODx utilise des chunks comme micro-templates pour les snippets). Idem pour CMS Made Simple qui a une logique très similaire.

Le cas de Drupal est un peu à part, il a sa propre logique et c'est aussi la raison qui le rend plus difficile d'accès (ceci dit, eZpublish ou Typo3 sont assez différent dans leurs approches aussi...). Parfois, c'est une question de manière de penser, ça clique ou ça ne clique pas pour un développeur/designer.

Même si j'adhère tout à fait à tes arguments, la spécialisation est une nécessité liée à la taille de ma société, au temps dont je dispose, et aussi à une politique commerciale : le fait d'être "le type qui fait des sites avec ZZZZ" fait que les gens viennent te voir pour ça. Dans mon cas, je reçois pas mal de demandes du type "devis pour faire notre site avec Drupal", plutôt que "quelle solution préconisez-vous pour notre site ?". Ensuite, c'est aussi une affaire de passion, d'envergure et de variétés des projets. Comme tu l'as souligné, toi tu ne fais que du sur mesure, chose que tu peux te permettre vu l'éventail de tes compétences. Quand on est "le type qui fait des sites avec ZZZZ", on risque de faire toujours le même type de sites, et vu qu'on est mono-compétence (ou quasi), on bosse souvent sur des projets qui impliquent peu de compétences, donc des petits/moyens projets.

Je ne dis pas que la spécialisation est une erreur... simplement que pour la dimension "conseil" en avant projet, cela rend la crédibilité moins évidente.

Je ne pense pas qu'un positionnement mono-produit soit inéluctable pour un freelance, même si il est évident qu'on ne peut pas être spécialisé dans un grand nombre de système. La question est plus de savoir quel type d'outil on souhaite proposer.

Personnellement je préfère les outils :

- flexibles (qui ne contraint pas le designer dans un modèle pré-défini)

- modernes (conformité aux standards, bonne séparation du contenu et de la présentation, approche modulaire = core léger et API pour faciliter le développement d'extension)

- innovants (qui s'appuient sur les techniques les plus récentes)

Cedi dit, comme tu dis l'avantage du positionnement mono-produit c'est qu'on est identifié clairement comme un spécialiste d'un outil et que si cet outil est connu des entreprises, tu es sollicité pour un devis. Mais même sans être mono-produit, on peut bénéficier de contacts (par exemple, je suis pas mal sollicité sur MODx - ce qui est logique vu ma position privilégiée au sein de la core team et mon implication dans le projet - et j'ai décroché du business via des contacts spontannés ).

Je n'exclu pas, côté CMS, de basculer sur un positionnement mono-produit à partir de MODx 1.0 puisque les limitations actuelles seront levées (système de permission, multi-linguisme natif, revisionning et workflow). Je n'aurai vraiment que peu de raison d'utiliser un autre système (du moins, en l'état actuel du marché).

[NiCoS]

Qu'est-ce que tu entends pas support ?

Ben la maintenance corrective/évolutive, ainsi que les montées de version je présume

Et dans le cas où l'application propriétaire est entièrement codée en PHP, et que le client a entièrement accès à ce code, on se retrouve ni plus ni moins dans la même situation que si on avait travaillé avec un développeur indépendant qui avait tout créé pour l'ocassion, non ?

Tout dépend du contrat avec le prestataire. Même si le PHP est lisible (pour le coup, il peut être encodé pour éviter qu'on lise les sources), le contrat qui te lie à ton prestataire peut t'empêcher d'y toucher...

En ce qui me concerne, je n'aurais même jamais pensé que c'était possible ! Mais ça a peut-être plus de sens pour un client qui ne connait pas grand chose au web, non ?

Sans vouloir te vexer (ce n'est pas le but, juste du vécu que je raconte), je me méfie du client qui connait le web / a des compétences en matière de programmation. Cela peut être un grand atout comme une cause d'échec. J'ai déjà eu des responsables informatiques de structure ou des personnes qui soit disant s'y connaissaient et qui en faisant part de leurs avis ont failli faire capoter certains projets. En voulant briller devant leurs camarades peu au fait du monde du web, ils donnent parfois de mauvais conseils et peuvent ainsi pousser le projet dans une direction qui n'est pas la bonne sous prétexte "qu'ils connaissent" ou "qu'ils savent". A contrario, j'ai aussi eu des clients ayant ses compétences et avec qui se fut un plaisir de travailler et le projet a ainsi pu bénéficier de synérgies très intéressantes. Je pense que tant du coté prestataire que "client qui connait" il faut savoir rester humble/honnête et apprécier les apports de chacun et chercher à jouer sur les complémentarités. Un client peut être doué en programmation / architecture web / ... mais nul en ergonomie par ex. On a l'impression que pour certains responsables informatiques, c'est reconnaitre leur défaillance que de faire appel à des prestataires... et du coup ils se braquent...

Pour conclure, je pense qu'il faut laisser le prestataire présenter sa méthodologie et l'ajuster le cas échéant si certains sujéts sont maitrisés ou si la réflexion est mature / a déjà été menée proprement.

Sur ce, bon week end

[vincedo]

Prévoyez une boisson chaude, ce message est un peu long.

Si les besoins vont vers des aspects que ton outil ne couvre pas du tout ou peu, tu vas te retrouver dans la mouise et à devoir trouver un remplaçant. Néanmoins, avec drupal, tu as a priori un panel de fonctionnalités importantes qui devrait te permettre de voir venir les choses

Tout à fait d'accord, et c'est vrai que je n'ai pas trop à me plaindre avec Drupal. :-) Même s'il (comme n'importe quel outil) impose parfois des détours qu'on aurait pu éviter en codant from scratch (car il faut coder "dans l'esprit" de l'outil). Autre point faible : leCommerce, pour lequel il propose peu de modules, ou des modules de qualité moyenne.

Et vu que tu occupes précisément ce poste de prestataire, peux-tu me dire à quoi correspond ton rôle ? (dans les grandes lignes, hein) T'arrive-t-il de sentir que ton apport est minime, par exemple dans le cas où ton interlocuteur a de solides connaissances du web, voire en matière de programmation ?

Si mon interlocuteur avait ce genre de connaissances, il ne ferait probablement pas appel à moi.

En gros, j'ai 2 types de clients : ceux qui se fichent éperdument de savoir en quoi leur site est fait (clients de type "utilisateurs finaux"). Dans ce cas, mon rôle est de leur fabriquer un site/outil qui réponde à leurs attentes. Si je choisis d'utiliser Drupal, je leur explique pourquoi et les avantages/inconvénients que ça représente, mais la plupart du temps, ça leur importe peu.

Par ailleurs, il y a les clients qui viennent me voir précisément parce qu'ils veulent du Drupal (clients de type "prestataires Internet"). Dans ce cas, mon rôle est multiple : valider la faisabilité du projet avec Drupal, réduire leur courbe dapprentissage si je travaille avec leurs développeurs, garantir la réussite du projet (dans le sens où, en tant qu « expert » sur Drupal, je suis censé résoudre tous les obstacles techniques rencontrés dans limplémentation de leurs besoins avec cet outil).

A partir d'un certain moment, on capitalise aussi car la logique d'un CMS n'est jamais totalement unique.

Comme les langues étrangères. Plus tu en connais, plus il est facile d'en apprendre.

Le cas de Drupal est un peu à part, il a sa propre logique et c'est aussi la raison qui le rend plus difficile d'accès (ceci dit, eZpublish ou Typo3 sont assez différent dans leurs approches aussi...). Parfois, c'est une question de manière de penser, ça clique ou ça ne clique pas pour un développeur/designer.

Tout à fait d'accord. En l'occurrence, j'ai cliqué avec Drupal, et je n'avais pas du tout cliqué (à l'époque) avec Mambo. Cela dit, tu as éveillé ma curiosité et je suis tenté de me pencher du côté des CMS dont tu parles...

... jusquà un certain point. Autant je trouve judicieux d'être pointu dans un outil de chaque catégorie, autant je ne vois pas l'intérêt de maîtriser plusieurs outils de la même famille, proches en fonctionnalités.

Pour reprendre l'exemple des CMS, je vois difficilement quelle fonctionnalité un CMS pourrait proposer qui me pousserait à en adopter un autre. Bien sûr, chaque CMS est un compromis, mais celui que j'ai choisi est - pour reprendre tes critères - flexible, modulaire, extensible, programmable, open source, innovant... Il arrivera toujours qu'il lui manque une fonctionnalité qu'un autre CMS propose, mais à supposer qu'il ne s'agisse pas d'une fonctionnalité "core" (comme le multilinguisme), je devrais pouvoir la programmer.

Un petite pause, et cest reparti.

Quelques réactions aux questions de départ de ce thread.

Que pensez-vous de solution de type http://www.atelierphp.com ? Ce qui semble séduisant, c'est d'avoir une solution plus personnalisée qu'un CMS standard...

En quoi la solution dAtelierPHP est-elle plus personnalisée quun CMS standard ? A moins que tu compares dun côté AtelierPHP qui vend son CMS obligatoirement avec de la personnalisation, et dun autre côté lutilisation dun CMS « out of the box », je ne comprends pas cette question.

Un site comme http://www.projectopus.com/ te fait-il penser à un site Drupal « standard » ?

Est-ce une erreur de s'appuyer sur une web-agency ? Est-ce qu'il est parfois intéressant de faire appel à une web-agency, même pour un CMS open source ?

Encore une fois, pourquoi serait-ce une erreur ? Et pourquoi « même pour un CMS open source » ? Pourrais-tu expliquer en quoi lintervention dune web agency compromettrait la réussite de ton projet par rapport à une réalisation « en solo » ? A part certains cas que jespère exceptionnels (escrocs, incompétents, tarifs exorbitants...), je ne vois pas.

Allez, je vais me coucher.

Bon week-end.