Le titre de ce billet est inspiré du titre d’un article très connu de Jakob Nielsen nommé « Flash 99% bad ». Je ne prétends pas être aussi pertinent que Jakob Nielsen dans mes analyses mais je trouvais l’idée des 99% très appropriée. En effet, je trouve que dans 99% des cas, les CMS sont à chier !
Très récemment, j’ai eu une expérience relativement malheureuse avec un CMS (SilverStripe pour ne pas le citer) et comme je l’avais déjà laisser entendre sur Twitter, j’ai décidé d’en faire une note car je trouve le sujet relativement important (toutes proportions gardées).
Je ne sais pas si vous réagissez comme moi mais personnellement, quand un nouveau CMS sort et commence à buzzer sur le Web, je m’emballe vite et je pense avoir trouvé la perle rare, le CMS parfait que j’attends depuis longtemps… Au début, tout à l’air beau et génial mais au final, après avoir trempé ses mains dedans un certain temps, il y a toujours une grosse quantité de trucs qui ne nous conviennent pas et qui deviennent carrément insupportables sur la durée !
Mais repartons à zéro et définissons le terme CMS…
CMS est l’abréviation de « Content Management System » ce qui veut dire « système de gestion de contenu » dans la langue de Molière. Ce site se compose en général de deux parties. La première est le « frontend », il s’agit du site public, accessible au monde entier. La deuxième partie est privée. On l’appelle le « backend » ou « admin » et elle permet aux administrateurs du site (via un login/password) d’en modifier le contenu, de façon plus ou moins sophistiquée. Ils sont devenus très populaires aujourd’hui car ils constituent un argument commercial de poids ! En effet, une fois le site terminé, le client ne devra plus faire appel à l’agence/webmaster pour faire la maintenance. Il peut se débrouiller tout seul ! En général, ça ne se passe jamais vraiment comme ça, mais c’est une autre histoire…
Et alors, pourquoi c’est si merdique un CMS ?
Pour moi, la grande faiblesse des CMS, c’est son élément central et indispensable : l’éditeur WYSIWYG. Un éditeur WYSIWYG (acronyme de « What You See Is What You Get ») permet, sans aucune connaissance d’HTML, de pouvoir structurer et mettre en forme le contenu. Il s’agit d’un outil puissant et complexe mais qui a ses limites. Il est en effet difficile d’assurer la qualité du code source généré par un éditeur WYSIWYG. Pour un accro aux standards du Web comme moi, c’est un véritable cauchemar !
Mais le pire ennemi de l’éditeur WYSIWYG se cache ailleurs, il s’agit de Microsoft Word ! Même si vous faites le backend le plus ergonomique du monde, la plupart des clients éditeront d’abord leur texte dans Word et le copieront ensuite dans votre éditeur… Et là, c’est l’hécatombe… En effet, Word génère un code HTML propriétaire merdique qui va foutre en l’air tout votre beau travail. Au mieux, le site s’affichera correctement mais la validation HTML ne sera plus au rendez-vous. Au pire, votre interface sera totalement explosée ! C’est en général à ce moment là que le client vous téléphone (et que vos ennuis commencent)… Certains éditeurs WYSIWYG proposent une fonction « Paste from Word » qui arrange le problème. Encore faut-il que le client l’utilise en lieu et place du classique Ctrl+V…
L’éditeur WYSIWYG est malheureusement incontournable. Imposer au client d’éditer directement en HTML ou via une syntaxe alternative (WIki, Markdown, Textile, etc.) est rarement envisageable. Personnellement, j’utilise TinyMCE, en limitant les fonctionnalités au strict minimum (paragraphes, gras, italique, liens et listes).
Une autre raison pour laquelle je n’aime pas les CMS est leur lourdeur, pas tellement au niveau des performances mais surtout en ce qui concerne le nombre de fichiers. On peut considérer cette situation comme normale car les CMS essayent de couvrir le plus de besoins possibles et ont généralement des possibilités assez larges mais ça me fait toujours mal au coeur de devoir mettre plusieurs dizaines de méga-octets de fichiers en ligne, tout ça pour un formulaire de contact et un forum… Ca me donne une sensation de bordel et de perte de contôle total de l’outil… Je déteste ça !
Et puis, même si, comme je viens de le dire, les CMS proposent de nombreuses fonctionnalités dont la plupart ne vont vous servir à rien (souvenez vous de la loi de Pareto qui dit que 20% des fonctionnalités sont utilisées par 80% des personnes), il y en a toujours une ou deux que vous auriez bien aimé avoir mais qui manquent à l’appel. C’est super frustrant !
La plupart des CMS Open Source sont au départ des CMS destinés à un usage personnel qui sont devenus tellement aboutis que le développeur a décidé de le mettre à disposition sur le Web. Environ un développeur sur deux développe son propre CMS (et parmi eux, un sur dix le finira un jour). Le problème, c’est qu’il s’agit en général d’un CMS dont les idées viennent du cerveau d’un seul mec (le développeur) et destiné au départ à n’être utilisé que par un seul mec (toujours lui). Pour le mec en question, c’est génial mais ce n’est peut-être pas comme ça que l’aurait fait un autre développeur. Dix développeurs vont aborder de dix manières différentes un problème et le résoudre de dix manières différentes, pour arriver au final au même résultat. Ce que je veux dire par là c’est qu’utiliser le CMS d’un autre, c’est un peu comme si on allait dormir dans un autre lit que le sien. Ca peut être super confortable mais rien de tel que son propre lit ! Même si c’est Open Source, se plonger dans le code d’un autre (qui a un autre style et d’autres conventions) et le modifier est une chose que je déteste car je considère (à tort, bien évidemment) que mon style et mes conventions sont meilleurs (c’est très subjectif).
Et n’allez pas croire que les CMS payants sont meilleurs ! Je connais quelques CMS en .NET (dont je ne citerai pas les noms) qui coutent un porte-avion et qui ne valent rien (façon de parler).
Bref, tout ça pour dire que les CMS et moi, ça n’a jamais été le grand amour et que je suis partisan du full custom. Le seul CMS que j’aime encore bien est WordPress qui répond parfaitement à mes besoins de bête blogueur qui se croit influent. J’essaye d’éviter Drupal, CMS Made Simple et SilverStripe si je veux rester de bonne humeur.
Si j’ai le choix, je préfère donc utiliser un framework comme symfony qui me permet d’écrire mes propres composants réutilisables. Sur le long terme, ça permet de gagner du temps et d’avoir des sites plus facilement maintenables et qui tiennent la route !
Le blog de Vincent Battaglia 
Ah, j’allais te demander ce que tu pensais de Drupal mais vu que tu l’as listé dans tes “à éviter”…
En tout cas, j’ai été agréablement surpris par ce CMS, j’avais une idée toute faite sur le sujet (les cms ça pue) mais là après quelques sites, je l’apprécie bien. Bien sûr il y a certaines choses qui me paraissent encore un peu obscures ou bien qui sont carrément buggy, mais c’est un projet qui dispose d’une communauté et d’un développement très actifs. Si tu lui redonnes une chance et que tu pousses un peu plus loin que les fonctionnalités de base, tu te rendras compte qu’il est tout à fait possible d’obtenir le résultat escompté, notamment au niveau de l’éditeur de texte auquel il ne faut pas systématiquement avoir recours (google: module cck).
Pour un nouveau site, ma démarche est maintenant de voir si Drupal peut en gérer chaque aspect (en gros s’il n’y a pas de dev à proprement parler), sans quoi je me tourne plus volontiers vers MODx (modxcms.com) qui est à mis chemin entre CMS et custom dev. Pour l’instant un point faible de ce CMF est le support multi langues, mais une nouvelle version (Revolution) arrive cette année.
LikeLike
J’suis complétment d’accord avec toi pour ce qui est des CMS, c’est une approche qu’à ma boite (un CMS perso) que l’on adapte sur tout nos site. Je ne suis pas trop fan des framework à titre perso mais je préfère largement une approche from scratch !
LikeLike
Pour ma part, je fuie tous les WYSIWYG, aucun ne m’a jamais satisfait.
Du coup, je persiste avec SPIP et sa syntaxe spécifique, pas si difficile que ça à prendre en main par n’importe quel contributeur lambda et bien plus puissante au final que n’importe quel WYSIWYG.
LikeLike
Ca ressemble à un débat religieux. Ca ne peut donc pas aller bien au delà du d’accord // pas d’accord.
Idéalement la courbe d’apprentissage du client doit être la moins raide/pentue possible, ce qui se retrouve derrière (typo, WP, Drupal, CMSMS,SPIP, …) c’est avant tout la cuisine du développeur. Développeur qui peut tirer parti des API XMl/RPC et de leur intégration dans Word (justement) pour “lisser la pente”.
Ce qui est plus intéressant que ton ressentiment par rapport à un CMS particulier c’est ce qui dans ta pratique ou celle de ton employeur vous pousse à changer de solution.
Pourquoi cette curiosité, volatilité alors que quasi toutes les agences ont leur CMS attitré ?
Depuis le temps où est la fonction javascript qui sur un on focus validerait ou non le contenu du formulaire de l’éditeur et en stripperait les balises ?
LikeLike
Je suis tout à fait d’accord avec toi. Rien de tel qu’un framework dans tous les cas, c’est plus souple et ça va pratiquement aussi vite.
Avec un CMS, aussi bien pensé soit-il, il arrive toujours un moment où quelque chose ne convient pas et là c’est bien la merde car il faut commencer à bidouiller!
LikeLike
Je suis bien d’accord sur un point: inutile d’installer un CMS pour utiliser 20% de ses capacités. Néanmoins, à l’opposé, certains sites se prêtent parfaitement à ceux-ci et je ne vois strictement pas l’intérêt de réinventer la roue.
Pour moi, toute l’expertise est de sélectionner LE CMS ou LA SOLUTION sur mesure qui convient aux besoins finaux, un peu comme pour le choix d’une voiture.
Les CMS ont, en effet, une chiée de folders et ça semble un peu lourd. Pour moi le tout est que le CMS soit développé de façon à ne pas utiliser l’inutile, c’est là que la performance jouera. La taille n’a pas d’importance… Si?
D’un point de vue performance, de plus en plus de CMS prennent (enfin!) ce sujet au sérieux et permettent un meilleur contrôle du rendu client side. Par exemple, j’ai réussi à obtenir des grades YSLOW B voire A pour des Joomla et Drupal (Merci à Marin).
Je partage ton avis quant à ‘utilisation d’un éditeur WYSIWYG: Que veut-on: du content management strict ou ouvrir la possibilité de tout “mettre en page”? J’en suis arrivée à accepter la solution TinyMCE mais avec une petite préférence pour JCE, un éditeur développé pour Joomla qui offre une ergonomie d’emploi inégalée, de plus, il interprète du code “complexe” correctement et sans le convertir: il n’y a rien qui m’énerve plus que du filtrage de code à la FCK.
LikeLike
Tout à fait d’accord avec toi Vinch. Pour en avoir essayé quelques-uns (Drupal, CMS Made Simple, TextPattern, et j’en passe), je suis à chaque fois assez déçu au bout de quelques heures de chippotage.
La solution serait peut-être un CMS extrêmement basique (une simple gestion de page en somme) et une gestion des modules extrêment souple…
LikeLike
Entièrement d’accord, et ça ne vaut pas que pour les CMS … il n’y a pour ainsi dire aucune applis qui soient au poil pour un développeur. Ton billet m’a quand même fait penser à TigerWiki (projet abandonné devenu Wikiss) qui est d’une simplicité époustouflante en prise en main et ultra facile à relire pour adapter. Un must pour du site corporate où les MAJ demandées par le client sont faites par le dev lui-même.
LikeLike
D’accord également! En général le CMS, peut importe lequel, ne conviendra jamais totalement à nos besoins, contrairement à notre application perso.
Le développeur aime bien faire les choses soit mêmes lorsqu’il doit les utiliser.
Avec les frameworks web modernes, le développement est extrêmement rapide, et développer sa propre solution CMS pour son business est certainement payant!
LikeLike
Contrairement à WYSIWYG, CMS n’est pas un acronyme mais bien une abréviation. Voilà, sinon c’est bien 🙂
LikeLike
Totalement d’accord avec toi Vinch.
Les CMS font souvent tout, sauf ce dont on a besoin… Il faut donc vraiment se plonger dedans pour exploiter les sytèmes de modules/widget/etc. Et on se rend parfois compte qu’il aurait été plus efficace d’utiliser directement un Framework.
J’utilise encore WordPress mais là aussi il y a beaucoup de choses qui ne me conviennent pas (vivement que je finisse mon propre CMS…un jour).
Le WYSIWYG est toujours la bête noir des CMS. Comment permettre aux rédacteurs (qui n’y connaissent bien souvent rien en HTML) de pouvoir faire tout ce dont ils ont envi tout en gardant un code propre ? C’est quasiment mission impossible…
LikeLike
Tu nous tiens au courant pour les sorties de VinchPress, VinchMadeSimple, VinchBB, VinchLa et VinchWiKi ? 😉
LikeLike
Je suis en train de migrer vers ExpressionEngine qui est produit assez souple (mais j’ai activé l’éditeur graphique, pas besoin 🙂 et surtout très extensible… donc il fait un peu framework.
Par contre la V2 qui devrait sortir cette année est assez intéressante parce qu’elle est construite sur un framework (CodeIgniter) donc tu pourras (normalement, pas encore testé) basculer entre le CMS pour les besoins de base (à quoi bon redéveloppé une gestion utilisateur) et le framework.
LikeLike
Je suis d’accord, mieux vaut un framework bien conçu et surtout bien maîtrisé qu’un CMS qu’on ne maîtrise pas et dont on espère des miracles sans une ligne de code! (je crois que c’est là le principal problème aussi bien des développeurs que des utilisateurs)
Wordpress est un succès parce qu’il ne s’égare pas dans des tonnes de fonctionnalités : contenu = billet.
Personnellement, je suis satisfait de Drupal. Il faut dire que j’ai réalisé un site bénévolement donc j’ai un peu adapté les fonctionnalités en fonction de ce qu’il était possible de faire avec Drupal…
J’aime bien l’approche de CushyCMS: rendre des zones d’une site statique éditables. C’est un peu simpliste mais le principe est intéressant et cela suffit pour certains clients.
LikeLike
@Benja : J’avais un peu perdu de vue CushyCMS. C’est clair que c’est pas mal du tout comme approche !
LikeLike
Héhé entièrement d’accord avec ton analyse des CMS 😉
Concernant CushyCMS je l’ai installé sur quelques petits sites donc l’édition ne concerne pas de changements conséquents et ça ne marche pas trop mal…
Seul bémol: le fichier en lui-même est édité (le contenu n’est pas stocké ailleurs, comme par exemple un BDD) et donc il faut faire attention à la gestion des version des fichiers locaux et online lorsqu’on travaille sur le site…
LikeLike
Hopla Vinch,
Je suis quand même étonné par ce post.
Il y a plusieurs points que tu relèves pour déterminer que (en résumé)
“les CMS, dans 99% des cas, c’est de la merde”.
Tout d’abord, quand je te lis, j’ai plus l’impression de lire un rassemblement de frustration que tu as du assimiler avec tes projets. Ca fait très “rah, ca marche pas comme JE veux,pfff”.
Reprenons :
– le WYSIWYG : comme le précise Denis, ce qui fait la qualité d’une mise à jour avec un CMS, c’est l’attention que porte l’utilisateur à l’insertion du contenu (et au contenu bien évidement).
Si tu fourgues un CMS à un newbee sans le former ni l’avertir, il faut pas s’étonner qu’il fasse du copier-coller Word sans réfléchir. Un CMS, un WYSIWYG, c’est un outil complet, il y a un temps d’adaptation, et d’apprentissage.
Pour revenir sur ce problème de Word, cela n’en est pas un réellement puisque tinyEditor justement permet justement de nettoyer le code automatiquement.
Et à savoir si le site sera toujours 100% compatible aux normes… Un CMS, c’est rarement une belle pub qu’on crée et qui reste fixe, ca vie, ca bouge. Alors personnellement, je préfère un site qui vie plutôt qu’un site fixe mais 100% aux normes.
Si un framework te permet de développer tes propres composants, pourquoi ne pas faire la même chose avec un CMS ? Il ne faut quand même pas vouloir ré-inventer la roue tout le temps…
Quoi tu préfères développer tes propres fonctionnalités ? Ok à la limite. Mais comment dans une boite comme la votre vous n’avez pas encore choisi un CMS PHP ? Vous pourriez le customiser, l’approfondir et en être content (avec toutes les fonctionnalités qu’il vous faut).
« rien de tel que son propre lit » pas très constructif tout ça.
En résumé, je trouve que tu vois les CMS comme une source de conflit pour ton travail mais tu as complètement oublié l’objectif central d’un CMS –> permettre la mise à jour d’un site facilement par son propriétaire.
Et rien que si cet objectif là est atteint, ca vaut toutes les sueurs du monde 🙂
Par sûr que si tu recevais 100 demandes de modifications de contenu par jour, tu tiendrais toujours le même discours.
LikeLike
Je plussoie entièrement à penser que les CMS sont véritablement des grosses merdes en terme de réponse à des besoins clients.
Le principal défaut des CMS, c’est qu’ils intègrent tout un tas de fonctionnalités dont l’utilisateur final n’a nul besoin. Quand bien même il utilise les fonctionnalités qui lui conviennent, il vous fera généralement qu’il lui manque telle ou telle autre qui lui manque.
De ce fait, pour respecter votre cahier des charges et contentez Mr Le Client Presque Content, vous êtes obligés d’ouvrir le -merdier- code source du CMS, de retrousser vos manches et de plonger dedans en apnée. Bien souvent, le code d’un CMS c’est une pagaille sans nom, difficilement maintenable et peu évolutif. Bref, vous vous cassez les dents à essayer de faire évoluer le module de base pour qu’il intègre le petit plus que vous demande votre client dans son CDC.
Les CMS open-source ont pour moi également bien d’autres défauts comme :
– Une qualité du code souvent médiocre,
– Pas de possibilités de faire des tests unitaires et fonctionnels car ce n’est pas gérer à la base dans l’outil,
– Niveau sécurité c’est rarement top : combien de CMS open-source utilisent les dossiers hors web par exemple pour déposer tous les documents sensibles ?
– Niveau performances, c’est rarement meilleur. Il n’y a qu’à voir déjà comment sont construites les tables de la base de données…
– C’est super galère à faire évoluer, skinner…,
– Quant à l’accessibilité, n’en parlons même pas…
En utilisant l’approche framework avec symfony par exemple, c’est tout l’inverse. Le framework vous donne déjà tous les outils nécessaires pour bâtir les piliers de votre application : manipulation de la bdd, génération des tâches CRUD, outil de migration, framework de tests unitaires et fonctionnels, internationalisation, sécurité… Vous avez le contrôle total sur l’application. Vous développez et n’intégrez uniquement les fonctionnalités dont le client a besoin.
Au final, on obtient une application qui :
– répond aux besoins exprimés,
– dont le code est testé unitairement et fonctionnellement (à condition d’avoir cette rigueur à l’esprit mais c’est loin d’être le cas de tous les prestataires…),
– est performante si les systèmes de cache sont mis en place par exemple,
– est potentiellement plus securisée,
– est potentiellement plus maintenable si les développeurs savent utiliser correctement le framework
– …
Au final, on peut même capitaliser du code en ayant une approche custom et from scratch à partir d’un framework. Si certains modules développés sont suffisamment génériques, ils peuvent être transformés sous forme de plug-ins réutilisables simplement. symfony le fait déjà et propose sur son site tout un tas de plug-ins, et Zend Framework le permet également si je ne me trompe pas.
Et en mot de la fin, je dirais que le développeur prend davantage de plaisir à coder car il peut pleinement exprimer sa technique et sa créativité dans le framework en développant from scratch, contrairement à l’approche CMS qui va le contraindre et le démotiver plus qu’autre chose.
Je ne sais pas ce que vous en pensez ?
Hugo.
LikeLike
Je suis d’accord avec Vinch sur le fond, peut être pas dans sa “démonstration”. Dans mon boulot je me vois mal vendre un CMS à un client, ça sera casse gueule (car il va demander XX modifications, ajout de fonctionnalités etc). Si le client est prêt à rester “coincé” dans son CMS alors ok… Mais faut lui faire signer l’accord avec son sang!
Mais pour moi les CMS = faire des sites à la chaîne. Je suis plutôt partisan du travail fait sur mesure (et donc oui, cher… mais bien). Et pouvoir s’adapter à TOUTES les demandes du client.
Il me semble plus pertinent un Django bien maitrisé qu’un Drupal bien lourd.
LikeLike
Juste au sujet de “paste from word” :
Faire adopter un produit à un client nécessite son évangélisation, donc lui expliquer, le repréciser tant que nécessaire (donc même sur la page de l’éditeur), et si il faut, adapter le fonctionnement (en ajoutant un raccourci Alt+V par exemple).
LikeLike
Pas complètement d’accord avec ta définition d’un CMS. Je pense qu’il y a un gros malentendu sur ce qu’est un CMS: dans la pratique un CMS regroupe 2 choses complètement différentes (d’où un certain nombre de confusions sur ce qu’on attend de lui…): c’est (1) un back office prêt à l’emploi pour éditer une base de données et des médias, et c’est aussi (2) un front, un cadre pré-développé pour afficher des contenus. A cette base s’ajoute souvent des outils pour interagir avec les visiteurs du site (des formulaires et les scripts qui vont bien). Le tout forme un système contraignant parce que complet… qui, c’est vrai, bride la créativité des projets web.
L’avenir est sans doute dans un mixte de ce qu’on appelle aujourd’hui d’une part des CMS et d’autre part des frameworks. MODX annonce la couleur à mon avis (CMS orienté framework) comme Symfony (framework orienté CMS). eZ publish, à une autre échelle, aussi.
Mais pour chaque projet, ne doit-on pas se poser la question: on cherche avant tout: un back bien pratique pour le client ? Une structure d’intégration (notion de template)? Des outils déjà développés ? Si on sait exactement ce qu’on attend d’un CMS, on est moins déçu, on accepte mieux la contrainte.
Quant à la tarte à la crème du WYSIbidule, en puriste je dirais que s’il a été implémenté dans un projet, c’est que le projet n’est pas abouti (ou mal défini) et que le client doit faire de la mise en forme (car WYSIWYG = mise en forme) et pas seulement entrer ses textes et médias. En gros, on laisse au client une partie du boulot, ce qui n’est pas bien, et comme ce n’est pas son métier au client, normal que ça se passe mal…
LikeLike
Hello,
Je pense comprendre ta frustration, si on a été confronté à plus ou moins la même situation. Peut-être pas mais j’explique mon expérience …
Un CMS c’est très bien pour des gens pas difficiles, très pragmatiques, qui vont orienter leur communication via le site web autour des fonctionnalités disponibles. Exemple typique : une asso qui veut une homepage avec ses news, un forum, une galerie photo, un agenda. Ce sont des personnes qui savent déjà ce qu’elles veulent et perçoivent bien l’adéquation de l’outil à leur but de communication. Point de vue visiteur, on a rapidement l’info recherchée, et en plus comme c’est standard on y retrouve vite ses habitudes. Une personne suffisamment motivée, pas informaticienne mais qui traîne suffisamment sur internet pour comprendre les bases parviendra sans trop de mal à s’installer un CMS en PHP sur un hosting gratuit, quelques soirée de chipotage c’est fait, tout le monde est content. Dans ce contexte, les CMS c’est génial.
Là où ça coince c’est quand on a une approche typiquement business. Et je me permet de me lâcher : c’est à dire que le client est un ensemble de personnes qui … ( cocher les réponses vécues ) :
– ne savent pas ce qu’elles veulent, c’est le chef qui a dit qu’il fallait un site pour leur boîte
– n’en n’ont rien à foutre ou qui tout du moins ne prendront aucune initiative ( trop habitués à l’approche : tu fais ce qu’on te dit .., de toutes façons la culture d’entreprise incite rarement à proposer des idées )
– ne vont jamais glander sur internet et n’ont donc aucune idée de ce qu’il suffit de faire pour avoir quelque chose de fonctionnel
– têtus et pas pragmatiques pour un sou, qui vont vouloir reproduire leurs vieux schémas à tout prix sans se remettre en question
– pour qui le site idéal consiste en une page de download de pdf scannés
– considèrent l’ordinateur comme un ennemi – et pour cause, savent à peine copier-coller, créer un dossier, faire la différence entre word, un navigateur internet et leur micro-ondes, mais c’est pas grave, c’est bientôt la retraite ( ou pire: travaillent depuis pas longtemps mais n’ont jamais vu d’ordinateur avant de bosser ). Danger : c’est eux qui vont demander les trucs les plus tordus qui compliquent la vie de tout le monde.
– ne comprennent rien au but de leur propre boîte et n’ont donc aucune idée du contenu à transmettre
– restent dans les stéréotypes de communication en mode “flyer”, “catalogue”, “affiche de pub”, “courrier”, “fax”, … à ajouter les plus folkloriques cartes de voeux qui font de la musique, les powerpoint de blagues des grosses têtes ou les plans d’architectes de 200 Mégas.
– … ou n’ont pas compris que le but d’un site web c’est de communiquer et s’imaginent que c’est juste un truc technique ( on trouve encore des cas où le département responsable du site n’est pas le département communication mais “l’informatique” )
Ce magma improbable va approcher une “agence web” pour faire faire son site.
Pour essayer de savoir ce qu’ils veulent, on leur présente une maquette, et pour peu qu’on tombe sur des allergiques à la simplicité qui ne veulent rien faire comme tout le monde on va vouloir des bidules custom à tout va. S’ensuit un cahier de charges qui avant même de s’attaquer à l’aspect technique ressemble déjà à une tour de babel.
Tour de babel qui un beau jour vient s’effondrer dans toute sa splendeur sur le bureau d’une équipe des développeurs web qui n’ont plus qu’à écarquiller leur yeux, et à qui on impose d’utiliser un CMS “pour gagner du temps”. Problème: tout est tellement custom qu’au final il faudra tout refaire, mais comme on veut absolument “un CMS”, on passe un temps considérable à tenter de faire rentrer des ronds dans des carrés. L’anti-pattern a un nom, c’est Abstraction Inversion ( http://en.wikipedia.org/wiki/Abstraction_inversion ) : on veut gagner du temps en utilisant un truc “tout fait”, mais quand on veut ajouter ses propres fonctionnalités il faut tout refaire et le CMS, vidé de son utilité, n’est rien de plus qu’une casserole de plus à traîner ( ou une enclume si noyade s’ensuit ).
Oui, dans ces cas-là, les CMS c’est la roue carrée et il y a de quoi fulminer.
J’adhère donc à ton point de vue sur l’usage d’un framework, c’est ce qu’il y a de mieux adapté si on te demande un site très custom, et ça ne t’empêche pas d’intégrer du WISYWIG tel que tinymce et consorts pour que le client rentre son contenu qui s’intégrera dans le design. Je n’ai pas été convaincu par symfony mais c’était il y a 3-4 ans, et depuis une crise d’ayathollisme m’a rendu allergique au PHP ( non, pas pour faire du java ou du .net, saint matz et guido m’en gardent .. ).
J’ai entendu du bien de CakePHP qui semble plus “pur”, as-tu essayé ?
LikeLike
@V : Merci de m’avoir fait découvrir l’Abstraction Inversion ! Sinon, j’ai déjà utilisé CakePHP et symfony et j’ai ma petite préférence personnelle pour ce dernier mais CakePHP reste un très bon produit !
LikeLike
bien parlé, V !
et je suis d’accord avec Vinch aussi.
(Tridion rules ! :o) )
lol
LikeLike
@Tristan : depuis quand symfony est orienté CMS ?
LikeLike
En alternative aux éditeurs WYSIWYG, il y a les éditeurs WYSIWYM: http://www.wymeditor.org/
J’avoue ne jamais avoir essayé avec un newbie mais qui sait peut-être serait-il plus “aware” de son contenu.
LikeLike
@Hugo : peut-être es-tu pointilleux en même temps que Tristan fait un peu d’abus de langage 😉 Pour dégager un peu d’objectivité il serait probablement intéressant de savoir ..
a) quelles features de symfony sont considérées comme “orientées CMS”
b) de faire un petit inventaire de la plupart des applications/sites qui sont développées sur base de symfony, est-ce que ça tend à être des CMS plus qu’autre chose, ou pas.
c) comparer avec d’autres frameworks
d) conclure si oui ou non, symfony est plutôt orienté CMS par rapport aux autres
Je ne suis pas en mesure de juger, ceci dit, je connais juste autour de moi deux réalisations sur base de symfony ( qui ne sont justement pas très “CMS” ) : un social network et l’autre qui est plutôt de l’ordre de l’ERP ( gestion/rapports/etc. ).
Pour illustrer des frameworks qui seraient “plutôt CMS” ou pas, ces dernières années j’ai fait du ruby on rails, puis un projet moyen avec turbogears, et présent django. Au vu de ce que ces frameworks gèrent, et des fonctionnalités qu’on trouve “out-of-the-box”, je serais tenté de dire que django est plus orienté CMS que les autres, surtout grâce à son backoffice “automatique” ; mais sans _être_ un CMS, entendons-nous bien … on trouvera sur la faq une réponse très claire à la question : http://docs.djangoproject.com/en/dev/faq/general/#is-django-a-content-management-system-cms
LikeLike
Que ce soit un cms ou pas ne change pas grand chose, il faut juste des developpeurs/utilisateurs qui connaissent comment ça marche/comment faire fonctionner correctement/optimalement.
Si t’as une bonne documentation et une communauté active, je pense que tous les besoins peuvent être satisfaits.
Bref, le débat de tel ou tel framework/librairie/bidule/machin/ etc est pour moi vraiment un faux débat.
J’ai des collègues qui pensent que telle librairie JS est meilleure que celle là pour telle ou telle raison. D’autres qui pensent que pas de librairie JS est mieux qu’une autre. Moi, je m’en fout un peu. Je veux juste que mes collègues travaillent ensemble et pas comme des francs tireurs.
Et Vincent, si t’as des mauvaises expériences, pour moi, c’est certainement dû a un manque de connaissance de la technologie (du framework) avec laquelle tu as du travailler.
Tout peut-être codé n’importe comment, c’est pas que tu sois sur mac ou pc qui va changer quoi que ce soit (pour faire un gros cliché)…
Sur ce… bonne chance pour ta suite
LikeLike
@V :
a) symfony comme Django sont purement des frameworks et n’ont rien à voir avec des CMS. Les admins generator que proposent les deux frameworks ne peuvent pas être considérés comme des features de CMS. Ils permettent d’accélérer le développement des interfaces de saisies de contenus mais en l’état ce ne sont pas des features de CMS. C’est pour moi du des interfaces CRUD améliorées. Alors que dans un CMS, il y’a une notion d’organisation du contenu (page, rubrique, thématique…).
b) Il y’a un tas d’applications qui tournent sous symfony. Il suffit de regarder dans le wiki du site officiel du projet symfony ou bien sur le site symfonians.net.
c) Beaucoup d’autres frameworks PHP proposent de la génération d’interfaces CRUD ou des admin générators comme Jelix, CakePHP, Stato… C’est selon moi une feature relativement primordiale “out of the box” pour un framework.
d) symfony n’est pas orienté CMS et c’est même plutôt tout l’inverse puisque sa philosophie est de permettre de créer des sites Internet sur mesure, qui seront au final des sortes de CMS. Mais à la base, on se sert du framework pour monter un site (de type CMS ou pas).
D’ailleurs en parlant de CMS, il y’a le projet SeerCMS, qui est un CMS open-source développé en symfony. Ca montre bien que sous le CMS en lui même, c’est du framework symfony. Le développeur a développé sur la base symfony un ensemble de fonctionnalités que l’on retrouve dans un CMS (gestion des users, gestion des pages, gestion des thèmes…).
http://www.steercms-project.org/
++
Hugo.
LikeLike
Moi aussi j’ai construis mon CMS et j’ai choisi TinyMCE comme WYSIWYG.
Moi aussi j’aime que le code qui en résulte soit beau, pour arriver à mes fins, j’ai potassé longuement la doc de l’outil qui s’avère au final super complet et j’ai supprimé certaines fonctionnalités.
Et pour vraiment maitriser la sortie, je fais une vérif serveur sur le contenu qui cherche d’éventuelles traces de Word et autres résidus hideux.
Ajouter à cela une preview de l’article avant post pour voir si rien n’explose, et normalement ca se passe bien.
A noter aussi, la fonctionnalité des templates de TinyMCE, très pratique pour éviter à votre client de s’engager dans des montages HTML trop complexes et crades en lui proposant des truks tout fait qu’il n’a plus qu’à insérer et modifier.
LikeLike
Bonjour Vinch,
Je pense que ton article, avec un peu plus de temps, aurait en effet donné une impression autre que de la frustration.
Il semble avoir été écrit sur un vrai coup de tête (de nerf ?) alors qu’il existe du pour et du contre dans l’usage des CMS.
C’est un point qui n’est (sauf erreur, j’ai pas lu en détail tous les commentaires) abordé par personne : la formation.
Pourquoi voudrait-on que CMS = très simple d’emploi ?
Un CMS, c’est un logiciel, et comme tout logiciel, il nécessite un apprentissage, une formation.
Si cette phase n’est pas présente dans le contrat, c’est au vendeur qu’en revient la faute, pas au client.
Comment voudrait-on aujourd’hui, avec tout le tapage du web 2.0 and Co, des médias (j’entends médias web) et de leurs complexités, qu’il soit simple d’utiliser un (vrai) CMS pour en faire autre chose qu’un petit blog perso ?
Après seulement, on peut dresser un tableau des CMS les moins complexes à manipuler.
LikeLike
Wouaw ca “lache des coms” par ici ! Sujet auquel je me dois de participer bien entendu.
Bravo pour la synthèse, très intéressant. Même si je suis totalement en désaccord avec le fond et le titre du post. Et qu’au final, la vérité comme à chaque fois, en sans doute entre les deux, ni noire, ni blanche, plutôt 50% bad/50% good.
Dans un monde idéal on veut du sur mesure. J’aimerais une voiture de telle couleur, avec telle consommation, telle coupe, telle capacité. Je voudrais une maison avec un grand jardin mais en plein coeur de la ville. Je voudrais une femme avec les yeux de Mélanie Laurent et la bouche de Scarlet Johanssen (oui, ça vous fait penser aux 3 Frères)…
Dans le monde réel, certains ont la possibilité et la folie d’essayer d’atteindre cet idéal, d’autres (et c’est la majorité), se contentent de choisir ce que le marché propose après avoir fait une étude comparative qualité/prix/besoins.
La métaphore est un peu lourde mais fonctionne selon moi pour les CMS.
Dans l’offre des CMS actuellement disponibles en OpenSource, il me semble que beaucoup ont la maturité d’être compétitifs et de pouvoir couvrir bons nombres des besoins exprimées par les futurs “content managers”.
La définition d’un bon CMS selon moi repose sur cette notion de simplicité de base (exprimée plus haut) avec une capacité de customisation. Approche qui n’est pas réservée aux Framework (on peut tout à fait envisager d’utiliser un CMS en framework, c’est d’ailleurs pour moi un des avenirs certain pour les CMS).
Au rang des faiblesses du “full custom”, on notera entre autres : des cahiers des charges ne prenant en compte que les besoins du moment et non le long terme et l’évolution du web, des phases de tests et de debuggage plus ou moins longues vu que l’outil n’est qu’un bébé au sens humain du terme, un support technique parfois désolant et dépendant d’une seule équipe sur lequelle on espère que la crise n’aura pas de fâcheuses conséquences.
Le choix d’un outil de gestion de contenu doit donc se faire avec des personnes compétentes capables d’évaluer les outils en fonction des besoins exprimés et pas en fonction d’une équipe de développement plus ou moins rigide/fan de tel ou tel CMS, framework, langages et j’en passe. Mais une fois de plus on est dans l’idéal…
Vive les CMS, vive SPIP !
LikeLike
moi perso j’utilise le CMS TypoLight…qui je trouve est franchement bien fichu…
à tester !
http://www.typolight.fr
LikeLike
Je viens de me prendre la tête a modifier un Joomla. Plus jamais !!!! Rien ne vaut un site fait de A à Z avec une parfaites maitrise de chaque élément.
J’ai modifié un module mais il m’a fallu 1h pour trouver comment faire un lien entre un menu et un article.
D’ailleurs je n’aime pas le terme Article cela ramene trop au blog.
LikeLike
Ben pour ma part le CMS, et moi c’est une belle histoire de haine, récemment j’installe la version 1.5 de Joomla, version dont j’entends de bons échos, je me fais chier à installer tout le bazar, wamp2, et cie quand je m’aperçois qu’elle n’est pas compatible avec la version Php du serveur, donc déjà première solution qu’ils sortent des versions qui soient compatibles les unes avec les autres bref…
Deuzio toujours pour joomla, je le trouve à la fois d’une simplicité déconcertante mais agrémenté d’un fouillis pas possible, exemple dans le mode administration une gestion catégories,sections nulle à chier, (je le dis), la même gestion bien pensée aurait été d’avoir une représenation graphique visuelle du menu et des catégories, sections générales, là j’avoue avoir été vraiment perdu, sans oublier une gestion des modules pas top mais pas affreuse non plus à voir.
Après pas fan des wordpress, mambo, spip et cie… autre chose qui m’irrite c’est de voir Adobe qui verrouillent autant le marché que microsoft l’a fait, Flash flash et encore flash, ça devient plus qu’embarassant surtout quand tu vois le prix du logiciel, donc dans ce cas j’approuve le CMS qui se veut ouvert et non l’inverse et rien que pour cette belle initiative je ne peux pas complètement enterrer le CMS mais à force de travail et de passion les choses s’amélioreront j’en suis sûr.
Bon courage entout cas et merci pour l’article.
LikeLike
Bonjour,
Je trouve l’argumentation de l’article très limite : le plus gros défaut des CMS serait donc que l’édition du contenu est d’abord réalisée sous MS-Word et que Microsoft continue à refuser de respecter les standards ?
J’en conclus qi’il n’y a qu’à jeter tout ce dont le nom commence par MS, et les CMS n’auront plus de défaut !
Je dois mettre en place un CMS, et en lisant cet article j’espérais trouver des informations un peu plus sérieuses que : ‘Microsoft fait de la m… mais personne ne sait rien utiliser d’autre donc on doit tout arrêter.’
Au fait, vous a-t-on expliqué qu’on était entré dans le 21ème siècle et que les locomotives à vapeur étaient toutes au musée ?
LikeLike