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 ?
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 :
- [u]Le code est mal fait[/u] : 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...
- [u]C'est une usine à gaz[/u] : 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.
- [u]C'est pas moi qui l'ai fait[/u] : ç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 ?
