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 ?


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 ?

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

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

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

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...



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...



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...

+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).

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
c'est faisable mais pas facile : voir ma signature

- pour un site portail je rejoins dotweb
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.

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

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...


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...


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 ?


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 ?

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...


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

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 ?

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 :

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

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



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.



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).

b) 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.




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.



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 :



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.

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...


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]


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 ?

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



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...



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...

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.

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...

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.

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...

Hello David,

Tout à fait d'accord.


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.

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



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

Qu'est-ce que tu entends pas support ?


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 ?


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


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 ?


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)


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 ?

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.



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é).

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



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...



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

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


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 : l’eCommerce, pour lequel il propose peu de modules, ou des modules de qualité moyenne.


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 d’apprentissage 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 l’implémentation de leurs besoins avec cet outil).


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


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 c’est reparti.
Quelques réactions aux questions de départ de ce thread.


En quoi la solution d’AtelierPHP est-elle plus personnalisée qu’un CMS standard ? A moins que tu compares d’un côté AtelierPHP qui vend son CMS obligatoirement avec de la personnalisation, et d’un autre côté l’utilisation d’un 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 » ?


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

Allez, je vais me coucher.
Bon week-end.

Malheureusement, cela arrive souvent, a un degré ou à un autre les clients ont l'impression de savoir ce qui est mieux pour leur site et parfois sont fixés sur des idées qui ne sont pas forcémment pertinentes. Il y a un gros travail de pédagogie à faire, ne serait-ce que pour expliquer ce qu'est le web tout simplement, et pourquoi faire tel ou tel choix peut être vraiment handicapant pour un projet. Le problème, c'est la comparaison avec l'existant : un dirigeant ou un responsable voit un site qui lui plaît, il voit la surface des choses et souvent, lorsqu'on regarde sous le capot, on a peur !!! Sémantique inexistante, code fouilli, technique obsolètes, outil mal choisi...et je ne parle même pas de conformité aux standards.

[copyright]

Les avantages du web sur les autres médias c'est avant tout ( là je dévoile un peu du contenu du contenu de mon site pro en refonte ):

1. l'interactivité -> de plus en plus vraie avec les interfaces riches
2. la recherche-abilité (désolé pour le néologisme -> la possibilité de trouver une information rapidement et facilement)
3. la connectivité -> de plus en plus vrai avec les web services, les connecteurs entre applications, les protocoles ouverts
4. l'ubiquité (i.e le fait d'être accessible depuis n'importe quel point du globe équipé d'une connection)
5. l'universalité -> de plus en plus vrai grâce à la séparation du contenu et de la présentation (CSS), possiblité de servir du contenu à différent support de manière cohérente (PDA, télphone, TV, dispositif pour aveugles... etc).
6. la facilité d'accès -> le web n'est pas un medium cher ni en publication ni en consultation

Je suis obligé de répeter ça très souvent, sur un point ou un autre, pour objecter par rapport à des demandes clients, et voilà comment je traduis les avantages du web (enfin les points 1,2,3 et 5) en exigences à prendre en compte pour le développement :

1. l'interactivité : si votre interface n'est pas accessible, vous rendez difficile la navigation sur votre site, vos pages ne seront pas consultées, vos visiteurs ne reviendront plus (ou peu).
2. la recherche-abilité : si vos contenus ne sont pas balisés sémantiquement (voire pour Flash, pas balisés du tout ), l'indexation de votre site sera handicapée
3. la connectivité : si vous choisissez une solution utilisant des protocoles propriétaires, le coût de développement des "connecteurs" sera beaucoup plus élevé.
4. l'universalité : si vos pages web ne respectent pas certaines bonnes pratiques, elles ne seront pas accessibles à tous les publics et aussi vous devrez re-coder toutes vos pages si d'autres moyens de navigation se développent (qui peut dire combien de personne surferont sur leur téléphone ou PDA d'ici 2 ou 3 ans...).

[/copyright]

Par ailleurs, on en discutait l'autre jour avec des développeurs : un client n'aura pas la même approche avec une application web qu'avec une application traditionnelle. Pour commencer, une entreprise est prête à dépenser des fortunes en logiciel que ce soit en bureautique (même si Open Office grignote du terrain) ou du côté progiciel. Par contre, elle ne sera pas forcémment prête à investir beaucoup dans un site ou une application web (dans le cas des PME souvent moins que pour leur banale plaquette "papier" !). Le paradigme derrière ça c'est que le web, c'est simple . Même à l'époque des pages web statiques, les non-initiés sous-estimaient la complexité du développement d'un site compatible avec les navigateurs du marché. Maintenant que quasiment tous les sites sont animés par des applications de gestion de contenu, et que de plus en plus d'applications sont hébergées sur des serveurs web (y compris la bureautique avec des applis comme Google Docs), le contexte est encore plus complexe pour le développement web.





Comme tu le dis, les moins compétents sont aussi ceux qui écoutent le moins... et qui se sentent menacés parcequ'en fait il ne comprennent pas le web...



Exactamente !

Ahhhh, David...

• Si j'étais un client, je t'embaucherais.
• Quel dommage que tu aies choisis MODx et non pas Drupal.

Merci
Puisse le ciel t'entendre !

Même si ça marche plutôt bien, rien n'est jamais gagné. Je ne sais pas ce que vous en pensez mais le marché est tendu (notamment, pas mal de gens qui travaillent "vite fait bien fait" qui tirent les prix vers le bas, et il faut vraiment argumenter pour tirer les budgets vers le haut...). Mes deux prochaines références sont "ajaxifiées" (je me suis beaucoup formé ces derniers temps côté AJAX et framework d'effets js comme MooTools) ce qui devrait me rapporter des contacts (curieusement, ce sont les effets "visibles" qui attirent les clients, alors que ce n'est qu'une partie de la valeur ajoutée qu'on apporte). Un des trucs que j'ai mis au point c'est le lancement au chargement de la page d'une animation flash dans une fenêtre type Lightbox, assez cool

Ceci dit, pour le "Quel dommage que tu aies choisis MODx et non pas Drupal." je ne pense pas car la diversité est aussi une bonne chose.

Certains site seront mieux servi par Drupal, d'autres par MODx...
Et de toute façon, rien n'est définitif. A l'époque où j'ai trouvé Textpattern début 2004, j'étais hyper enthousiaste car ça a été le premier CMS à offrir une flexiblité totale côté template (perso un des gros points bloquant côté Drupal pour moi c'est l'utilisation de phpTemplate. Je n'aime pas les moteurs de templates, Smarty non plus d'ailleurs... pour moi ça ajoute une couche supplémentaire et surtout je ne clique pas avec la logique). Ensuite, Dean a laissé tomber Textpattern pour s'occuper de son nouveau bébé, l'hébergeur TextDrive puis ensuite les web apps avec Joyent. Le projet a stagné et dès que j'ai trouvé MODx l'année dernière, j'ai su que j'aurai les avantages de Textpattern (une logique assez similaire côté template), combiné avec la souplesse de structuration des données (via les variables de modèles) et en plus une API et une DBAPI (le côté framework quoi). En plus quand je vois avec qui je bosse dans l'équipe MODx, je peux dire qu'en un an j'ai énormément appris ! (le fait d'être bilingue anglais aide énormément pour apprendre car les ressources sur les techniques de pointe sont majoritairement en anglais) Ceci dit, je suis toujours à l'affut... mais pour l'instant je ne vois pas quel autre outil pourrait avoir ma faveur, d'autant que j'ai une visibilité totale sur ce qui va venir : c'est ambitieux, innovant et ça va faire mal !

Et moi, rien... snif, je suis jaloux...

Sur ce je repars dans Django...

Ok, je vois... Et ton paragraphe sur les responsables informatiques qui peuvent être des freins dans le développement d'un projet m'interpellent, j'espère que je ne correspond pas trop à cette description... Je vais y travailler, en tous cas !


Prestation plus personnalisée, car en effet développement spécifique compris dans la prestation si besoin... Mais tu as raison, ça revient au même avec un CMS open source...


Disons que ma logique ne se présente pas exactement en ces termes : je me doute bien qu'une collaboration avec un prestataire externe compétent a toutes les raisons d'être constructive.

Mais cela représente aussi un coût, non-négligeable. Et mon boulot consiste aussi à choisir entre :
- faire appel au prestataire qui me semble le plus adapté, en allouant au projet un budget
ou
- mener moi-même le projet, en y consacrant davantage de temps


Je n'ai pas bien compris le lien entre interactivité et accessibilité...

Et pour revenir sur l'aspect interactif des sites web... Je perçois bien tout ce que cela a de séduisant dans l'idée (interaction directe, partage des connaissances, prise en compte de l'avis de chacun, valorisation de l'utilisateur, etc.), mais est-ce qu'il vous est déjà arrivé de conseiller à un client de ne pas trop miser là-dessus, tout simplement parce qu'un site interactif, ça consomme plus en ressources humaines ?


Ta photo me fait penser à l'agent Smith, dans Matrix !

Sans vouloir te flatter ou te rassurer, dans la mesure où tu as une démarche visant à te renseigner ou mieux comprendre les choses, je ne pense pas que tu sois ce type de personnes . Ce type de personnes connaissent la vérité ultime donc ne seraient pas venus poster un message ici...

Et puis maintenant que tu es prévenu, tu n'as pas de raisons de tomber dans ce travers

Bonne journée,
Nicolas

"faire" ou "faire faire", un choix effectivement qui se présente quand on a les ressources en interne.

Attention toutefois à ce que je disais, si le web semble "facile", il ne l'est pas forcémment... un projet web est un projet complexe, et une application web n'est pas moins complexe qu'une application traditionnelle (le fait de devoir gérer des environnements clients hétérogène -> i.e plusieurs plateforme + navigateurs, n'y est pas étranger).



Le lien, c'est qu'un système de navigation (menu) par exemple, qui est une des pièces maîtresse de l'interactivité sur un site, ne peut pas se permettre d'être inaccessible. Si il est mal conçu, ou inacessible à certains visiteurs, ceux-ci ne reviendront pas... Exemple type : menu en Flash, menu en javascript (si une alternative n'est pas prévue...). Mais il ne s'agit pas seulement de la technique utilisée pour le menu (full CSS est préférable toutefois), mais aussi de la réflexion initiale sur la façon dont on va structurer le site et penser la logique de la navigation...



Oui. Très souvent.
En partie parcequ'en plus d'avoir beaucoup lu sur le knowledge management depuis 1998, j'ai une bonne expérience du conseil en organisation (et une formation initiale (DESS) en management).

En fait, je met souvent en garde contre les espoirs vis à vis d'un site web. Que cela soit d'un point de vue des retombées commerciales ou des conditions de réussites pour la mise en oeuvre des outils collaboratifs (et comme tu le soulignes, cela signifie investir du temps et effectuer des choix en terme de management des ressources humaines).

Pour un site "plaquette" par exemple, les bénéfices ne sont pas "directs", et dépendent largement de l'intégration de la stratégie web avec la stratégie de com (curieusement, c'est assez rare !), la stratégie commerciale, l'attitude de la société vis à vis de ses clients d'une manière générale... etc. C'est d'ailleurs la raison pour laquelle je passe du temps au début à bien comprendre l'activité de mes clients, et ensuite pour laquelle j'insiste sur la nécessité de ne pas envisager le site web comme une extension "désarticulée". Donc bon point oui : un site web, qu'il comprenne des outils permettant l'interactivité ou pas, est un projet qui ne doit pas être envisagé comme indépendant du reste de l'activité et de la stratégie....

Mais là, ne nous faisons pas d'illusion, nos managers sont peu nombreux a bien comprendre les enjeux et le changement de paradigme induit par ces outils. Ce qui explique aussi qu'ils soient réticents à voir leur autorité (fondé sur le statut) mis en question par des outils qui re-définissent l'autorité (les outils collaboratifs ont le don de faire émerger ceux qui ont des compétences... qui gagnent alors en autorité. Mais aussi ils modifient les interactions des acteurs dans l'entreprise, et les réseaux de pouvoir informels peuvent se développer au détriment de la hiéarchie classique...). Mettre en place ces outils n'est donc pas neutre...



J'espère que je ne finirai pas comme lui

Pas de doute là-dessus : le web est un média complexe... Je me souviens de propos d'un graphiste, expert du print passé au web, qui trouvait extrêmement difficile de créer une mise en page efficace quand tant de paramètres pouvaient entre en ligne de compte...

En fait, ma petite expérience du web m'a appris une chose : plus tu cherches à creuser, plus le trou te parait grand


D'accord, de ce point de vue, je comprends... Même si, dans ma tête, j'aurais classé cet aspect dans la recherche-abilité : un bon menu permet de trouver rapidement l'information... L'interactivité, pour moi, ça fait référence à la "marge d'action" de l'utilisateur, telle que prévue par le site...


J'avoue qu'un des points qui m'inquiète le plus, c'est bien celui-ci : comment anticiper l'utilisation réelle d'une fonctionnalité ? Je lis partout qu'il faut se concentrer sur l'essentiel, que beaucoup de demandes de futurs utilisateurs sont superflus, etc. Mais, concrètement, comment distinguer au cas par cas ce qui va être utile ou non ? Si vous avez des astuces, je suis tout ouïe

Ta question me fait penser au bouquin des gars de 37 signals qui parle exactement de ça. Si j'ai bien compris leur propos, faut construire des fonctionnalités "génériques" plutôt qu'essayer d'anticiper exactement ce que les utilisateurs voudront faire. Un bon exemple est le système des tags. Dans une application, les tags te permettent d'organiser le contenu de façon bien plus intuitive et puissante que des folders par exemple, et ils peuvent être "détournés" pour servir à plein d'autres usages. C'est aux utilisateurs de les découvrir (en fonction de leurs besoins), il faut juste essayer de leur donner un outil qui leur donne ce genre de flexibilité.

Un autre moyen de se concentrer sur l'essentiel, c'est de dire non à toutes les fonctionnalités qu'on te demande (je caricature) et de laisser passer du temps. Si la demande ne cesse de revenir 3 mois après, il y a sûrement qqchose à creuser. En revanche, si elle est oubliée, c'est qu'elle ne servait à rien.

Difficile question. Faire simple, c'est compliqué

La tendance actuelle du web c'est le recentrage sur l'essentiel, que ce soit côté applicatif ou côté design. 37signals est en effet un modèle du genre et "Getting Real" donne quelques recettes