CMS, web-agency : complémentaire ?

davidm · 21 Octobre 2006

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

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] :excl:

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

l'interactivité -> de plus en plus vraie avec les interfaces riches
la recherche-abilité (désolé pour le néologisme -> la possibilité de trouver une information rapidement et facilement)
la connectivité -> de plus en plus vrai avec les web services, les connecteurs entre applications, les protocoles ouverts
l'ubiquité (i.e le fait d'être accessible depuis n'importe quel point du globe équipé d'une connection)
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).
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 :

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).
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
la connectivité : si vous choisissez une solution utilisant des protocoles propriétaires, le coût de développement des "connecteurs" sera beaucoup plus élevé.
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] :excl:

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

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

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

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.

Exactamente !

vincedo · 21 Octobre 2006

Ahhhh, David...

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

Modifié 21 Octobre 2006 par vincedo

davidm · 21 Octobre 2006

Ahhhh, David...

Si j'étais un client, je t'embaucherais.

Quel dommage que tu aies choisis MODx et non pas Drupal.

Merci :blush:

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 :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 !

NiCoS · 22 Octobre 2006

Ahhhh, David...

Si j'étais un client, je t'embaucherais.

Quel dommage que tu aies choisis MODx et non pas Drupal.

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

Sur ce je repars dans Django...

aspeum · 23 Octobre 2006

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.

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 !

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 » ?

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

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.

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

[*]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).

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 ?

Moi aussi j'ai des lunettes de soleil sur mon avatar !
Elles font cheap ?

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

NiCoS · 23 Octobre 2006

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 !

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

davidm · 23 Octobre 2006

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

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

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

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

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 ?

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

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

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

aspeum · 24 Octobre 2006

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

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

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

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

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

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 :whistling:

vincedo · 24 Octobre 2006

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.

Modifié 24 Octobre 2006 par vincedo

davidm · 24 Octobre 2006

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

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 en la matière.

Un premier moyen de savoir si une fonctionnalité va être utile et surtout utilisée c'est de ne pas prendre le projet à l'envers au démarrage.

C'est à mon avis un des gros écueil du processus traditionnel de définition d'un cahier des charges : on raisonne dèjà en terme de fonctionnalités souhaitées et souvent c'est le responsable informatique ou dans les petites structure le dirigeant ou un manager qui formule et décide des fonctionnalités qu'il souhaite. A mon sens, on devrait d'abord se poser la question de savoir quels sont les objectifs que l'on vise lorsque l'on lance un site ou/et une application web. Ensuite, on devrait sonder les futurs utilisateurs sur ce qu'ils attendent de l'outil (de manière très simple, sans forcémment lancer une étude qualitative complexe). Cela présente deux avantages : on prend en compte les besoins des utilisateurs finaux pour valider les objectifs et les prioriser. Ensuite seulement, on traduit ces objectifs en spécifications fonctionnelles.

Moins l'écart entre les besoins et les fonctions est grand, plus on a de chance que l'outil soit utilisé. Moins l'écart entre les objectifs et les fonctions est grand, plus on a de chance que l'outil soit efficace (rappelons que la définition de l'efficacité c'est le rapport Résultat/Objectif. L'efficience, c'est Résultat/Moyens...).

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

Vincent a raison, plus un outil permet de combiner librement des briques fonctionnelles très granulaire, plus il est capable de s'adapter aux besoins de l'utilisateur final. Le type même d'outil qui permet ce genre de chose, c'est le framework. Les briques fonctionnelles d'une API visent avant tout à automatiser les opérations de base dont on a besoin pour traiter les données. On ne part pas de zéro (on a des composants ayant chacun leur fonction), mais on est pas coincé dans un moule pré-défini (qui nécessairement ne correspond pas forcémment au besoin).

Ceci dit, il faut quand même nuancer parceque la logique derrière cette approche, c'est la personnalisation complète des applications. Et qui dit personnalisation dit quand même développement additionnel. La question a se poser c'est donc : mon besoin est-il spécifique ou générique ?

S'il est spécifique, alors il peut être plus pertinent de prendre la voie "37 signals", s'il est générique alors c'est plutôt le packaging pré-configuré à la Joomla!

Bien sûr, je schématise fortement, on est rarement dans un cas où dans un autre. Dans la liste des besoins, certains sont génériques (et donc des modules pré-configuré, à condition de laisser une certaine liberté quand même) sont adaptés - certains sont spécifiques (il est alors pratique d'avoir une API sous la main pour travailler vite et efficacement au développement d'un module). C'est l'essence même qui m'a conduit à choisir MODx comme fer de lance de mon activité : à la fois CMS et framework...

NiCoS · 24 Octobre 2006

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

Plusieurs éléments de réponse :

- il faut penser "simple" : plus ta fonctionnalité est complexe, moins elle sera utilisé (car inutilisable)

- il faut penser "simple" (bis) : mieux vaut une fonctionnalité simple et l'enrichir dans les version ultérieures que spécifier/implémenter une uzine à gaz qui ne verra jamais le jour

- il faut faire confiance au prestataire (ou au moins en discuter) sur ce qu'il a l'habitude de voir (combien de fois on m'a demandé des workflow en au moins 3 étapes ou debrayables ou avec et au final, on voit que 2 est suffisant...)

Sinon, je rejoinds l'avis de mes camarades

aspeum · 25 Octobre 2006

Ta question me fait penser au bouquin des gars de 37 signals qui parle exactement de ça.

Je viens de lire un passage au hasard, et ça commence déjà à battre en brèche un paquet de conseils habituellement donnés... Bon, c'est en plein dans le sujet, en tous cas, merci pour le lien !

J'en profite pour tous (davidm, NiCoS, vincedo, dotweb, etc.) vous remercier de votre contribution à cette discussion, c'est très enrichissant. Même si je passe du temps sur le web, je ne suis pas un expert en ressources documentaires, et cet échange me permet d'aborder plein de sujets sur lesquels je peine à y voir clair... Merci pour ça.

vincedo · 25 Octobre 2006

Bien sûr, je schématise fortement, on est rarement dans un cas où dans un autre. Dans la liste des besoins, certains sont génériques (et donc des modules pré-configuré, à condition de laisser une certaine liberté quand même) sont adaptés - certains sont spécifiques (il est alors pratique d'avoir une API sous la main pour travailler vite et efficacement au développement d'un module). C'est l'essence même qui m'a conduit à choisir MODx comme fer de lance de mon activité : à la fois CMS et framework...

C'est exactement le raisonnement qui m'a poussé à choisir Drupal : à la fois CMS et framework !

Pour expliquer Drupal aux gens qui ne connaissent pas (ils sont nombreux ), j'utilise souvent la comparaison entre Lego et Playmobil (en gros, Drupal = Lego et Joomla/WordPress = Playmobil), mais je trouve que cette expression "à la fois CMS et framework" est très parlante aussi.

Et je me joins à aspeum pour les remerciements. Le fait de devoir expliquer les choses nous pousse encore plus à y réfléchir que quand on "se contente de" les faire. Personnellement, les échanges de ce thread m'ont donné plein d'idées pour améliorer DrupalFrance.org :

comment mieux expliquer ce qu'est un CMS/framework,
pourquoi le choisir,
éviter de se perdre dans les détails techniques pour répondre aux vraies questions que les gens se posent ("à quoi ça ressemble ?" ; "existe-t-il des prestations commerciales sur ce CMS ?"...)

froidure_nicolas · 25 Octobre 2006

Personellement, rien de tel que d'avoir son propre CMS. De cette façon, on maîtrise entièrement les possibilités du CMS. Par exemple, je peux créer un module sur mesure en peu de temps grâce au fait que je connais chaque fonction de mon CMS sur le bout des doigts.

Ca me permet aussi d'atteindre une grande rapidité d'éxecution car je ne réimplémente pas des fonctionnalités qui existent déjà et j'exploite au maximum la libraire de fonctions préexistantes.

De plus, j'ai un avantage très important, nottamment si mon client choisi l'hébergement mutualisés sur mon serveur. Car, comme je n'utilise qu'un seul et même CMS, tous les sites hébergés sur une même lame utilisent les même fichiers du CMS. Donc le client n'a pas à subir le poids du CMS sur son espace d'hébergement.

Son site est totalement personnalisable grâce aux templates (plusieurs menus différents, inclusion des templates n'importe où dans le document etc...), et la base de donnée n'est pas solicité car un système de cache enregistre les documents et les réutilise tant qu'aucun changement n'a eu lieu.

Bref, comme j'en ai les capacités, j'ai préféré créer mon propre CMS pour passer mon temps à coder plutôt qu'à lire une documentation... Après, c'est une histoire de choix...

aspeum · 25 Octobre 2006

Je viens de lire un passage au hasard, et ça commence déjà à battre en brèche un paquet de conseils habituellement donnés... Bon, c'est en plein dans le sujet, en tous cas, merci pour le lien !

Bon... Cet ouvrage va changer ma vie (de perfectionniste anxieux). Merci infiniment :wub:

drakulls · 25 Octobre 2006

personellement, je maintiens que Joomla est assez facile à relooker pour le peut que l'on maitrise les CSS...

regardez ceci et cela...

davidm · 25 Octobre 2006

Je pense que cette discussion dépasse largement le cadre des outils... Joomla! peut être customisé bien sûr, et sortir du modèle à 3 colonnes -> mais pas aussi rapidement et facilement qu'avec d'autres outils. Mais c'est un autre débat...

vincedo · 26 Octobre 2006

Hello froidure_nicolas,

Je comprends ton point de vue mais je ne le partage pas.

Ca fera bientôt une dizaine d'années que je fais des sites Web, dont pas mal passées en agence Web, et crois-moi la question du CMS maison VS CMS existant (open source ou autre) s'est posée quasiment tous les jours. Quoi j'exagère ? Disons qu'elle s'est posée à chaque projet. Il y a 6-7 ans, j'aurais sûrement été d'accord avec toi, mais je trouve que les CMS ont aujourd'hui atteint une maturité et une "versatilité" qui fait pencher la balance en leur faveur.

Personellement, rien de tel que d'avoir son propre CMS. De cette façon, on maîtrise entièrement les possibilités du CMS. Par exemple, je peux créer un module sur mesure en peu de temps grâce au fait que je connais chaque fonction de mon CMS sur le bout des doigts.

Tu peux arriver à un point de maîtrise quasi équivalent sur un CMS open-source dans lequel tu te serais spécialisé.

Et puis, pour les CMS open source, tu peux t'impliquer dans le développement, rien de tel pour le connaître à fond.

Ca me permet aussi d'atteindre une grande rapidité d'éxecution car je ne réimplémente pas des fonctionnalités qui existent déjà et j'exploite au maximum la libraire de fonctions préexistantes.

Il y a encore plus rapide : utiliser un module/une fonctionnalité déjà développée pour ton CMS par la communauté.

Même en codant toi-même, les CMS de type "framework" (MODx, Drupal...) te font gagner du temps grâce à leur API et le fait que la plupart des tâches de "bas niveau" sont déjà implémentées.

De plus, j'ai un avantage très important, nottamment si mon client choisi l'hébergement mutualisés sur mon serveur. Car, comme je n'utilise qu'un seul et même CMS, tous les sites hébergés sur une même lame utilisent les même fichiers du CMS. Donc le client n'a pas à subir le poids du CMS sur son espace d'hébergement.

1) Drupal est multi-sites (1 install de Drupal peut faire tourner plusieurs sites)

2) Drupal 4.7.4 fait 1,68 Mo, je trouve ça raisonnable

Son site est totalement personnalisable grâce aux templates (plusieurs menus différents, inclusion des templates n'importe où dans le document etc...), et la base de donnée n'est pas solicité car un système de cache enregistre les documents et les réutilise tant qu'aucun changement n'a eu lieu.

Idem avec les CMS évoqués plus haut.

Bref, comme j'en ai les capacités, j'ai préféré créer mon propre CMS pour passer mon temps à coder plutôt qu'à lire une documentation... Après, c'est une histoire de choix...

Ben moi, je crois pas que j'aurais les capacités de développer aussi vite, découvrir autant de bugs et créer autant de nouvelles fonctionnalités qu'une communauté Open-Source de plusieurs dizaines de développeurs. Mais "c'est ton choix", et une certaine Evelyne nous a appris il y a bien longtemps qu'il fallait le respecter.

Je ne dis pas qu'il ne faut pas de sur mesure, mais peut-être pour des projets qui ne sont pas dans "l'esprit CMS", ou très orientés métier. Si c'est pour faire des sites typiques CMS (ré utilisabilité d'un site à l'autre, templates, modules...), ce qui semble être ton cas, alors moi aussi j'ai fait mon choix.

Vincent

PS. J'omettrais un point important en ne parlant pas de la courbe d'apprentissage liée à chaque CMS. Là-dessus, tu as raison : un outil qu'on a développé, on le maîtrise dès le début, alors qu'un CMS "extérieur" oblige à se plonger dans le code de quelqu'un d'autre (en l'occurrence, de plusieurs autres). C'est pour ça que le code est super important : en ce qui me concerne, j'ai choisi un CMS dont la logique de codage était parlante pour moi, et que je trouvais particulièrement bien réalisé. Au début, on passe beaucoup de temps à comprendre comment tout fonctionne, mais par la suite, on récupère largement ce temps grâce à tous les apports de la communauté (correction de bugs, nouvelles versions, nouvelles fonctionnalités...).

davidm · 26 Octobre 2006

J'ajouterai juste à l'excellente réponse de Vincent que, pour moi, le sur mesure en partant de zéro n'est plus une option viable aujourd'hui.

Maintenant, on peut soit partir d'un coeur de fonctionnalités avec une API permettant l'extension de ce coeur (cas de Drupal ou MODx et de tous les Content Management Framework), soit partir de zéro mais s'appuyer sur un framework applicatif (Web application framework) qui est plus généraliste qu'un CMF (typiquement aujourd'hui c'est Django, CakePHP, Code Igniter, Symfony, Ruby On Rails...etc).

C'est simplement une question d'efficacité. Ces frameworks offrent effectivement des bibliothèque de fonctions de bas niveau comme dit Vincent et qui permette d'éviter de ré-inventer l'eau chaude.

froidure_nicolas · 26 Octobre 2006

Effectivement, c'est un point de vue. mais dans le cas où tu adoptes un CMS tu ne peux pas prédir son évolution et donc ton activité dépend d'une communauté qui peut tout aussi bien s'éteindre du jour au lendemain ou encore, prendre une orientation en contradiction avec la politque commerciale de ta société... Bref, avoir mon propre CMS c'était aussi conserver mon indépendance et prendre les orientations qui me plaisent.

Ca me permet de marquer un temps d'avance dans certains domaines par rapport à mes concurrents qui peuvent devenir des arguments commerciaux redoutables.

Et puis, chacun sait que dérrière une communauté de développeur, en général, il y a un "noyau dur" de quelques "élus" qui fond le plus gros du travail... Ca peut largement être égalé voir devancé par une équipe de développeurs dans une société privée.

Quand aux extensions faîtes par des développeurs qui n'ont pas vraiment participé à l'écriture du noyau, c'est autant de failles potentielles... et donc, rarement un gage de qualité, surtout pour les plus marginales...

XCMS occupe 586 Ko (600 135 octets) dont 124 Ko (127 538 octets) pour les fichiers sons (alphabet + chiffres) et 289 Ko (296 212 octets) pour le fichier .ttf des polices du captcha.

Les images ne sont pas pris en compte (mais il y en a très peu comme il est en XHTML et CSS... C'est juste des boutons pour faire joli, mais pas nécessaires.

davidm · 26 Octobre 2006

Effectivement, c'est un point de vue. mais dans le cas où tu adoptes un CMS tu ne peux pas prédir son évolution et donc ton activité dépend d'une communauté qui peut tout aussi bien s'éteindre du jour au lendemain ou encore, prendre une orientation en contradiction avec la politque commerciale de ta société... Bref, avoir mon propre CMS c'était aussi conserver mon indépendance et prendre les orientations qui me plaisent.

Cet argument n'est pas totalement faux en ce qui concerne l'indépendance. Pas totalement faux, mais dans la pratique je ne suis pas sûr que ce choix soit forcémment optimal. Il est quand même difficile pour un développeur seul de produit le même niveau de qualité de code qu'une équipe de personnes motivées et souvent très compétentes (les statistiques nous disent que l'expérience moyenne d'un développeur dans le monde de l'open source est de 11 ans). D'autre part, l'open source est un monde habité de passionnés, qui ne sont pas là pour l'argent mais pour travailler librement, de manière collaborative. Les conditions d'émergence de l'innovation sont bien là...

Concernant la perrenité, l'argument n'est pas moins vrai pour une entreprise que pour une communauté. Voire même, moins vraie en ce qui concerne l'open source puisque précisémment les sources sont ouvertes et à supposer qu'une communauté abandonne un projet ou décide de passer à une licence commerciale pour les versions ultérieures d'autres dev peuvent très bien reprendre le code et le faire évoluer.

C'est, au passage, ce qui s'est en partie passé lorsque le concepteur d'Etomite a abandonné le projet pour se consacrer à l'écriture d'un CMS commercial dérivé du code d'Eto. Certains dév, dont Ryan Thrash et Raymon Irving (deux des fondateurs), qui avait développé une extension majeur nommée... MODx, sont parti de la communauté en "forkant" suite à des luttes de pouvoir intestines.

Je ne pense pas que le fait qu'un CMS propriétaire soit plus pérenne qu'un CMS open source. Les sources sont fermées et si un produit n'est plus supporté pour X ou Y raisons, vous êtes le nez dans le sable avec un code propriétaire dont vous ne pouvez rien faire.

Ca me permet de marquer un temps d'avance dans certains domaines par rapport à mes concurrents qui peuvent devenir des arguments commerciaux redoutables. Et puis, chacun sait que dérrière une communauté de développeur, en général, il y a un "noyau dur" de quelques "élus" qui fond le plus gros du travail... Ca peut largement être égalé voir devancé par une équipe de développeurs dans une société privée.

Je ne partage pas cet avis. En quoi cela permet-il d'avoir un "temps d'avance" ? Dans quel domaines ?

J'aimerai comprendre en quoi cela peut devenir des arguments commerciaux redoutables... je suis curieux !

Pour te contredire, tout dépend des communautés : certaines sont animés par un développeur unique (c'était le cas de Textpattern, maintenant ils sont trois mais il n'ont pas le talent de Dean...), d'autres par 2/3 développeurs, d'autres (comme Drupal, MODx ou Joomla) par une équipe de fondateur entourée de dizaines de développeurs.

Pour avoir testé pas mal de CMS propriétaires, rares sont ceux qui sortent du lot... la proportion n'est ni moins bonne ni meilleure que dans l'open source (encore que )....

Quand aux extensions faîtes par des développeurs qui n'ont pas vraiment participé à l'écriture du noyau, c'est autant de failles potentielles... et donc, rarement un gage de qualité, surtout pour les plus marginales...

Encore une fois, je vais te contredire : tout dépend de la qualité de la documentation de l'API... et pour ce qui est des failles de sécurité, reprenons l'exemple de Windows et Linux : lequel est le plus sûr ?

XCMS occupe 586 Ko (600 135 octets) dont 124 Ko (127 538 octets) pour les fichiers sons (alphabet + chiffres) et 289 Ko (296 212 octets) pour le fichier .ttf des polices du captcha. Les images ne sont pas pris en compte (mais il y en a très peu comme il est en XHTML et CSS... C'est juste des boutons pour faire joli, mais pas nécessaires.

Je ne pense pas que la taille d'un CMS soit directement proportionnelle à sa qualité : tout dépend des fonctionalités présentes....

froidure_nicolas · 28 Octobre 2006

Bah, je pense que ça ne vaut pas la peine de continuer cette discussion. On a chacun fait nos choix en matière de création de sites...

La seule chose qui est sûre, c'est que si un CMS Open Source était vraiment abouti, alors tout le monde y plancherai plutôt que de faire chacun dans son coin sa petite sauce...

Pour les innovations dont je te parlais, je pourrai citer les captcha vocal que beaucoup n'ont pas encore créé ou encore, le BBComposer que je propose à mes clients et que j'utilise en ce moment pour rédiger ce message.

D'ailleurs, j'en profite pour passer un petit message aux membres du HUB qui peuvent le télécharger gratuitement.

davidm · 28 Octobre 2006

Bah, je pense que ça ne vaut pas la peine de continuer cette discussion. On a chacun fait nos choix en matière de création de sites...

Dommage... en ce qui me concerne je pense que le débat est toujours intéressant...

En ce qui me concerne je n'ai pas d'idée préconçue. Je ne pense pas que l'open source soit la réponse à tout projet, que les solutions commerciales sont intrinsèquement mauvaises, ou que développer un CMS maison soit une mauvaise option. Dans un grand nombre de cas, je suis par contre de ceux qui pensent que les solutions libres sont très compétitives et que le modèle derrière le développement open source est un bel exemple d'une forme d'économie alternative à l'économie de marché...

Enfin, pour finir aucun choix n'est définitif en ce qui me concerne. Si je teste une solution qui me semble meilleure qu'une autre pour un projet donné, je n'hésiterai pas à m'y plonger et à m'en faire l'avocat, l'utiliser et en faire bénéficier mes clients ou même mes concurrents. Evidemment, si je ne peux pas tester une solution, je ne risque pas de l'utiliser (souvent, tester les solutions commerciales passe par un processus qui n'est pas ouvert et donc qui n'incite pas les prestataires à l'adopter).

La seule chose qui est sûre, c'est que si un CMS Open Source était vraiment abouti, alors tout le monde y plancherai plutôt que de faire chacun dans son coin sa petite sauce...

Je ne partage pas ton opinion.

1) Il existe des CMS open source aboutis : autrement dit fonctionnels, surs, performants.

2) Il n'existe pas (heureusement !) de solution universelle : l'outil qui viserait à répondre à *tous* les besoins est voué à devenir une usine à gaz qui sera difficile à maintenir, pour lequel le développement d'extension sera long et coûteux, et qui finalement à vouloir être "tout pour tout le monde" ne sera "rien pour personne. C'est à mon avis le travers de 95% des CMS de type "Portail"...

La tendance actuelle du développement web est aux applications "agiles" (pour prendre un mot à la mode .

Le livre de 37signals cité plus haut est l'archétype du courant actuel du web qui consiste à recentrer les outils sur les fonctionnalités les plus uliles et utilisées... et comme chacun sait "faire simple, c'est compliqué".

Le véritable enjeu est là et non pas dans la licence des applications : les applications de 37 signals ne sont pas open source et pourtant j'applaudi des deux mains BaseCamp, TaDa List, WriteBoard et CampFire (le seul hic, le manque d'internationalisation de ces applications hébergées).

Il faut donc changer notre mode de réflexion sur les outils, "moins, c'est plus". Cela demande un effort constant au quotidien, car nous sommes formatés à penser en terme de puissance, de comparison de listes de fonctionnalités, de cahiers des charges.... etc. Mais les vrais juges sont les utilisateurs : qu'ils soient prestataire chargé de la mise en oeuvre comme moi ou qu'il soit utilisateurs finaux.

Pour les innovations dont je te parlais, je pourrai citer les captcha vocal que beaucoup n'ont pas encore créé ou encore, le BBComposer que je propose à mes clients et que j'utilise en ce moment pour rédiger ce message. D'ailleurs, j'en profite pour passer un petit message aux membres du HUB qui peuvent le télécharger gratuitement.

Catpcha vocal, voilà une innovation intéressante pour l'accessibilité des sites web !

Bravo donc J'aimerai voir largement diffusé ce type d'innovation... d'où mon goût pour l'open source je dois dire

Quant à BBComposer, j'utilise le même type d'outil depuis quelques temps... Citons l'extension BBCode Extra pour Firefox, mais il y en a d'autres.... Ceci dit il semble que tu ai amélioré le principe d'une façon intéressante !

Je vais le tester

Edit : tiens j'ai pu voir la démo de XCMS, côté admin.

froidure_nicolas · 29 Octobre 2006

Le BBComposer doit encore être amélioré et subit un bug de la version 2.0 de Firefox qui empêche le pointage direct d'un élément textarea... Pas de bol, c'est le noeud de mon extension... J'ai fait un patch de correction temporaire... Je pense faire une adapt à la syntaxe Wiki pour que tout soit supporté.

Mais pour en revenir à nos moutons, j'attend avec impatience une adaptation pour ModX... Pour Spip, c'est déjà fait, mais si tu veux, tu peux améliorer ça car comme je n'utilise que mon CMS, je ne suis pas prêt de faire le test pour voir si ça marche.

Modifié 29 Octobre 2006 par froidure_nicolas

**Dadou** · 31 Octobre 2006

Je reposte mon message car il y a eu un problème et il s'est effacé :

non, non il ne s'est pas effacé, le post à été coupé en deux : http://www.webmaster-hub.com/index.php?sho...c=29687&hl=

Edit : zut, le temps que je poste Nicolas à supprimé son post, moi par contre, je ne trouve pas ou faire la même chose :wacko:

Modifié 31 Octobre 2006 par Dadou

Connexion

CMS, web-agency : complémentaire ?

Sujets conseillés

Contributeurs actifs dans ce sujet

Jours d'activité

Contributeurs actifs dans ce sujet

Jours d'activité

Veuillez vous connecter pour commenter

Contenu similaire