Je vais citer un cas que je connais fort bien et que je ne peux pas citer ici pour des raisons que certains comprendront : j'ai vu le développement d'un gros site professionnel en équipe. La modélisation a été faite à la hache, l'analyse à été en grande partie court-circuitée. Il a fallu pratiquement dès le départ tomber dans le code. Résultat, une application qui devait être livrée à Noël dernier a finalement été mise en production avec 4 mois de retard.

Vouloir se lancer trop vite dans le code sous prétexte "qu'on est un professionnel", ou encore "Qu'avec l'habitude on sait où on s'en va", c'est une erreur. Il ne faut pas confondre vitesse et précipitation.

@HyWaN
Là, comparer un framework comme Symphony directement à un CMS, c'est sûr que tu cherche la guerre Sinon j'ai connu un autre HyWaN beaucoup plus rigoureux (jusqu'à limite pénible) dans son langage

En fait je disais que Symphony était plus un CMF qu'un Framework (et donc un CMS) et que les CMS allaient tous crevés car on voit des applications beaucoup plus professionnelles, avec moins de code, pour un meilleur résultat, et tout aussi facile à concevoir.
Et j'ai pas compris quand tu dis que tu connaissais un autre Hywan '^^.

on voit des applications beaucoup plus professionnelles, avec moins de code, pour un meilleur résultat, et tout aussi facile à concevoir.

Lesquelles par exemple ?

Pour ma part, les CMS arrivent au bout de leur vie. Cyrano a tout a fait raison, trop de code et surtout trop de n'importe quoi. Un CMS est rarement très bien codé (d'après mon expérience, j'espère me tromper).

Je trouve cette affirmation un peu légère : si on parle de l'utilité d'un CMS, qui est de gérer du contenu, je ne crois pas que cette demande soit rapidement amenée à disparaître. Après leur conception plus ou moins bonne, c'est à mon avis un autre problème. Tu raisonnes en tant que développeur, et donc comme la personne susceptible d'installer un CMS, pourtant ce sont les utilisateurs (potentiels) qui font la demande, pas toi.

D'ailleurs tu dis bien dans la suite de ton message que tu as des bibliothèques toutes prêtes, des "mini-CMS", tu fais donc du CMS... sauf que tu n'installes pas un déjà existant. Le CMS n'est donc pas en fin de vie

Hmm c'est très juste.
n-ème essai de formulation : le CMS ne devrait se résumer qu'à un WYSIWYG performant et une gestion de document avancée. On voit que ça dépend vite de l'architecture de l'application.

On se rend compte aussi à l'usage que chaque application est unique dans le sens où elle se destine pour une personne (ou un groupe de) pour une application/but donnée et précis. Ce qu'on appelle CMS aujourd'hui, essaye d'être complet sur tous les tableaux, problème donc, 80% de inutile etc.

Donc quand je pensais à Symphony, on conçoit une application rapidement (très rapidement même si on en croit les démos), on le fait uniquement pour le but que l'on s'est fixé, donc pas de code inutile. Symphony étant tout de même un bon framework, il est bien conçu, donc performant (dans une certaine mesure, on ne rentre pas dans le débat Sf vs ZF et compagnie …). On a donc moins de code, on cible mieux notre but, on augmente les performances (car aussi moins de code inutile), et il me semble qu'une appli basée et construite sur un framework (ou un ensemble de librairies) est plus facilement modulaire et maintenable.

J'ai bossé sur quelques CMS et je ne voudrais jamais, au grand jamais, réitérer l'opération … C'est du bidouillage en force, tout ce que j'aime …

Donc pour répondre à ouckileou, dans ma tête (c'est le bazar) ce qu'on appelait CMS était ces énormes applications sur-dimensionnées orientées usines à gaz. Si on s'en tient à la définition que j'ai donné au début de ce message, un CMS ne va pas mourir. Tu as raison, j'ai parlé trop vite sans éclaircir mes dires .

En même temps un CMS est généralement modulaire... Un client arrive avec une demande, tu réponds déjà à son besoin de gestion de contenu avec le CMS adapté, tu réponds ensuite à une bonne part (variable) de ses autres besoins (grands classiques : news, newsletter, gestion d'agenda, flux rss, sondages, enquêtes, forums, statistiques, versionning, gestion d'utilisateurs, traçage des actions du backend, gestion fine des droits, etc...) avec des modules existants, et tu concentres ta valeur ajoutée sur ce qui est vraiment spécifique au client.

Ainsi tu ne perds pas de temps à faire une analyse sur ses besoins en gestion de contenu alors que d'une part lui-même ne connait pas ses besoins (l'usage d'un CMS lui donne alors des habitudes, généralement bonnes), et que d'autre part 90% de ses besoins sont loin d'être spécifiques.

L'idéal étant d'avoir dans une équipe la connaissance de plusieurs CMS, et de choisir le plus adapté selon le cas (Typo3, Joomla, SPIP, Plume, ou autre). Un CMS pré-existant doit avoir les caractéristiques suivantes :
- Modulaire côté frontend et côté backend.
- Tous les modules standard sont déjà disponibles.
- Extensibilité des modules (possibilité de faire un module pour modifier le comportement d'un autre module, afin de pouvoir modifier un module existant sans avoir à trifouiller son code).
- Un framework cohérent pour l'écriture de modules.
- Une communauté active.
- Et bien sûr un coeur qui gère de façon performante l'authentification et le cache.

Oui ça fait une usine à gaz, mais ça permet de faire des sites en une semaine (de codage, je ne compte pas l'analyse qui prendra quasiment le même temps avec ou sans CMS de toute façon, elle aura d'ailleurs pour but de déterminer si on peut utiliser un CMS et lequel) avec des fonctionnalités avancées au lieu de mettre des mois à réinventer la roue et à modifier son «mini CMS maison» pour coller aux besoins du client (et on se retrouve avec 60 versions de son «mini CMS»).


Je préfère travailler avec une seule version d'une usine à gaz que je ne maintiens pas moi-même, que de passer mon temps à maintenir moi-même X branches d'un outil perso.

En général ceux qui n'aiment pas les CMS pré-fabriqués leur reprochent :
- Le code est mal fait : et alors ? ce n'est pas moi qui le maintiens, comme je l'utilise activement je vais essayer d'y contribuer pour améliorer cet état de fait, mais après tout tant qu'il fonctionne bien, qu'il remplit les critères précédents, et qu'il est aisément extensible, peu importe. Le code issu de *ma* prestation sera de qualité car c'est ce que j'aurais vendu et que c'est la partie que je vais maintenir. Le reste je m'en fous, je ne vais pas refuser à mon client de faire tourner son site sur un serveur Windows sous pretexte que le code de l'OS est trop pourri...
- C'est une usine à gaz : c'est vrai, et c'est généralement plutôt vu comme une qualité, vu que ce que beaucoup nomment "usine à gaz" est en réalité une application fortement modulaire, et que je lui préfère de loin ça à une application monolithique.
- C'est pas moi qui l'ai fait : ça vous ne le dites pas, mais avouez que c'est ce qui vous chiffone le plus. Devoir vous rabaisser au rang d'installateur/configurateur/utilisateur au lieu de faire votre beau métier de développeur. Devoir apprendre comment fonctionne l'outil d'un autre, ne pas être le roi en son royaume tout ça... C'est dur, très dur, et je pense que c'est l'obstacle principal.

Moi je préfère utiliser les outils des autres, ça m'évite une bonne part du boulot, et j'aime bien l'idée de n'avoir à me focaliser que sur les éléments vraiment importants, ceux où mon intelligence apporte une vraie valeur ajoutée par rapport au boulot du voisin, et ne pas perdre de temps avec des trucs génériques

Et puis hein, on n'a pas l'air un peu incohérent quand on tanne les gens avec nos «ne réinvente pas la roue !» et qu'on se refuse à utiliser les roues des autres parce qu'on préfère inventer les notres ?

- C'est pas moi qui l'ai fait : ça vous ne le dites pas, mais avouez que c'est ce qui vous chiffone le plus. Devoir vous rabaisser au rang d'installateur/configurateur/utilisateur au lieu de faire votre beau métier de développeur. Devoir apprendre comment fonctionne l'outil d'un autre, ne pas être le roi en son royaume tout ça... C'est dur, très dur, et je pense que c'est l'obstacle principal.

lu sur un autre forum, je parle d'utiliser symfony pour faire des sites, j'argumente, voici une réponse :

pour ma part je suis pas adept des outils prefabriques... j'ai besoin de sentir sur chaque ligne que c'est moi qui ai bossé
bon apres c'est ptete quelquechose qui va me passer

no comment ...

A+

Pascal

Pour ma part, je préfère concevoir l'outil que l'utiliser. Donc c'est encore un autre point de vue.

Je vous pris de revenir sur le sujet.
Ce n'est pas un enieme post à debat sur les cms vs les framework etc !!

Les questions ont été clairement enoncées je penses pour éviter les hors sujet.

Je vous pris de revenir sur le sujet.
Ce n'est pas un enieme post à debat sur les cms vs les framework etc !!

Les questions ont été clairement enoncées je penses pour éviter les hors sujet.

Merci

Je vous pris de revenir sur le sujet.
Ce n'est pas un enieme post à debat sur les cms vs les framework etc !!

Les questions ont été clairement enoncées je penses pour éviter les hors sujet.

Je n'ai pas le sentiment qu'on s'éloigne tant que ça du sujet de base.

En revanche il y a peut-être une étape qui a été un peu trop rapidement passée. En arriver en effet à choisir si on utilisera tel ou tel Framework, tel ou tel CMS ou si on codera tout soi-même, ça sous-entend que l'analyse préliminaire a déjà été faite et qu'on sait assez précisément quels sont les besoins pour l'application projetée : partant de là, on peut explorer si certains outils libres et disponibles peuvent ou non combler ces besoins, sont relativement aisément utilisables ou s'ils imposent un minimum de connaissances/documentations et surtout si à long terme leur utilisation ne posera pas de problèmes sur la maintenance et/ou l'évolution de l'application.