Bonjour,
Je ne vais pas te dire que ce n'est pas "intéressant" de travailler avec ce CMS : je l'utilise au quotidien
Mais ici, à part qu'il s'agit d'un site "corporate" (ce qui est un peu vague), on n'a aucun contexte donc difficile d'avoir un propos plus argumenté…
Connais-tu déjà ce CMS ? As-tu des contraintes particulières ? Design from scratch ? framework CSS ? Travail en dinôme (ou plus) avec un graphiste ? Es-tu à l'aise avec PHP (le templating WP est en PHP) ? As-tu le temps de te former au CMS dans le cadre de ce projet ? Quel est cahier des charges du projet, son périmètre fonctionnel, le SAV prévu par la suite ? Bref, autant de questions contextuelles qui pourront orienter ton choix… et dont les réponses sont indispensables aux forumeurs qui pourront éventuellement t'aider à choisir
Modifié par audrasjb (06 Apr 2015 - 20:11)
Je ne vais pas te dire que ce n'est pas "intéressant" de travailler avec ce CMS : je l'utilise au quotidien
Mais ici, à part qu'il s'agit d'un site "corporate" (ce qui est un peu vague), on n'a aucun contexte donc difficile d'avoir un propos plus argumenté…
Connais-tu déjà ce CMS ? As-tu des contraintes particulières ? Design from scratch ? framework CSS ? Travail en dinôme (ou plus) avec un graphiste ? Es-tu à l'aise avec PHP (le templating WP est en PHP) ? As-tu le temps de te former au CMS dans le cadre de ce projet ? Quel est cahier des charges du projet, son périmètre fonctionnel, le SAV prévu par la suite ? Bref, autant de questions contextuelles qui pourront orienter ton choix… et dont les réponses sont indispensables aux forumeurs qui pourront éventuellement t'aider à choisir
Modifié par audrasjb (06 Apr 2015 - 20:11)
merci pour ta réponse. Non, je ne connais pas encore ce WortPress. Et je pense que je vais le développer en traditionnel. Mais au vu du marché actuel, je me posais cette questions ? On voit trop de site qui sont développé en WordPress, .... Oui, je vais travaillé seul, et l'actualisé tout simplement. Je pense que je vais développer le site entreprise en traditionnel et un blog avec WordPress .. histoire de voir un peu le Framework ...
Je pense que la première question à te poser est "qui va mettre à jour le site" et à quelle fréquence les contenus vont-ils changés ? Si c'est quelqu'un qui n'a aucune affinité avec le code et qu'il faut mettre à jour le contenu toutes les semaines, un WordPress (ou autre CMS il en existe pleins) pourrait être pratique pour lui permettre de le mettre à jour en autonomie.
Mais bon, si c'est toi et que le contenu ne bougera pas trop, à voir un petit dev maison c'est pas mal aussi. Pense quand même à documenter histoire que d'autres puissent reprendre ton code si un jour tu quittes l'entreprise
Mais bon, si c'est toi et que le contenu ne bougera pas trop, à voir un petit dev maison c'est pas mal aussi. Pense quand même à documenter histoire que d'autres puissent reprendre ton code si un jour tu quittes l'entreprise
Hum, je suis pas développeur moi je suis designer 
Le seul WordPress que je touche c'est le templating de mon portfolio/blog, mais on peut pas trop appeler ça du développement je me contente de bidouiller les boucles WP pour afficher ce qu'il faut et installer des plugins
En freelance je travaille en collaboration avec des développeurs qui font soit du WordPress, soit du Spip (huhu), moi je fournis le design, et eux codent le joli site pour qu'il soit fonctionnel. La boulangerie aurait dû être sur du WordPress il me semble, mais j'ai plus trop de nouvelles de la boite de com' qui m'a commandé le design donc je ne sais pas trop au final je ne suis même pas sûre que le site ai vu le jour (comme ça arrive parfois).
Le seul WordPress que je touche c'est le templating de mon portfolio/blog, mais on peut pas trop appeler ça du développement je me contente de bidouiller les boucles WP pour afficher ce qu'il faut et installer des plugins
En freelance je travaille en collaboration avec des développeurs qui font soit du WordPress, soit du Spip (huhu), moi je fournis le design, et eux codent le joli site pour qu'il soit fonctionnel. La boulangerie aurait dû être sur du WordPress il me semble, mais j'ai plus trop de nouvelles de la boite de com' qui m'a commandé le design donc je ne sais pas trop au final je ne suis même pas sûre que le site ai vu le jour (comme ça arrive parfois).
Les désavantages des CMS en général :
- Il faut les maintenir à jour, car des failles sont régulièrement découvertes et exploitées. Mettre à jour implique souvent un temps de travail important difficilement quantifiable ; un module mal développé peut créer des problèmes. Il faudra alors effectuer chaque mise à jour d'abord sur un serveur de test, mais même là, un problème pourra survenir par la suite dont il faudra rechercher la cause, parfois longuement. Parfois, la mise à jour sera impossible à cause d'un module ou d'un thème indispensable qui n'est plus maintenu.
- La mise à jour de contenu est beaucoup moins simple que sur un site fait main. Sur un site fait main, on fait les changements sur les fichiers et sur certaines tables et on upload le tout. On sait quel fichier fait quoi, quelle table est dépendante de quelle autre table. Sur un CMS il faut souvent effectuer le changement une première fois en test pour vérifier que tout se passe bien, puis refaire le travail sur la version en ligne.
- La gestion de l'administration nécessitera beaucoup plus de formation et de support pour le client qu'une administration bien conçue sur mesure. Un développement sur mesure fait ce que le client a demandé. Un CMS open source fait tout et il faut apprendre à l'utiliser de la bonne manière en fonction de ce que l'on souhaite en faire.
- Toute demande un peu particulière peut se révéler compliquée à exécuter avec un CMS open source. Il faudra soit trouver un module adapté, soit en développer un, soit souvent bidouiller pour arriver au résultat escompté, créant ainsi un système difficile à maintenir.
Les désavantages de Wordpress en particulier :
- Le code est bordélique, il y a des fichiers de partout, c'est réellement du travail d'amateur. La racine du site contient plus d'une dizaine de fichiers là où tous les CMS et frameworks sérieux ne contiennent en général qu'un fichier index.php appelant les contrôleurs nécessaires, bien rangés.
- L'url du site est codée en dure à plusieurs endroits de la base de données, ce qui est parfaitement stupide. Lors d'un changement d'url (version test vers version live par exemple), il faudra effectuer une requête remplaçant toutes les occurrences de cette url.
- Il utilise les magic quotes, ce qui est une hérésie.
Bref, pour moi le seul intérêt de Wordpress est qu'il se passe d'un système de templates inutile tel que smarty.
La bonne solution est de développer son propre trousseau à outils et son interface d'administration standardisée qui permettra de déployer rapidement des fonctionnalités communes à la majorité des sites tout en restant suffisamment souple pour pouvoir répondre à n'importe quelle demande.
- Il faut les maintenir à jour, car des failles sont régulièrement découvertes et exploitées. Mettre à jour implique souvent un temps de travail important difficilement quantifiable ; un module mal développé peut créer des problèmes. Il faudra alors effectuer chaque mise à jour d'abord sur un serveur de test, mais même là, un problème pourra survenir par la suite dont il faudra rechercher la cause, parfois longuement. Parfois, la mise à jour sera impossible à cause d'un module ou d'un thème indispensable qui n'est plus maintenu.
- La mise à jour de contenu est beaucoup moins simple que sur un site fait main. Sur un site fait main, on fait les changements sur les fichiers et sur certaines tables et on upload le tout. On sait quel fichier fait quoi, quelle table est dépendante de quelle autre table. Sur un CMS il faut souvent effectuer le changement une première fois en test pour vérifier que tout se passe bien, puis refaire le travail sur la version en ligne.
- La gestion de l'administration nécessitera beaucoup plus de formation et de support pour le client qu'une administration bien conçue sur mesure. Un développement sur mesure fait ce que le client a demandé. Un CMS open source fait tout et il faut apprendre à l'utiliser de la bonne manière en fonction de ce que l'on souhaite en faire.
- Toute demande un peu particulière peut se révéler compliquée à exécuter avec un CMS open source. Il faudra soit trouver un module adapté, soit en développer un, soit souvent bidouiller pour arriver au résultat escompté, créant ainsi un système difficile à maintenir.
Les désavantages de Wordpress en particulier :
- Le code est bordélique, il y a des fichiers de partout, c'est réellement du travail d'amateur. La racine du site contient plus d'une dizaine de fichiers là où tous les CMS et frameworks sérieux ne contiennent en général qu'un fichier index.php appelant les contrôleurs nécessaires, bien rangés.
- L'url du site est codée en dure à plusieurs endroits de la base de données, ce qui est parfaitement stupide. Lors d'un changement d'url (version test vers version live par exemple), il faudra effectuer une requête remplaçant toutes les occurrences de cette url.
- Il utilise les magic quotes, ce qui est une hérésie.
Bref, pour moi le seul intérêt de Wordpress est qu'il se passe d'un système de templates inutile tel que smarty.
La bonne solution est de développer son propre trousseau à outils et son interface d'administration standardisée qui permettra de déployer rapidement des fonctionnalités communes à la majorité des sites tout en restant suffisamment souple pour pouvoir répondre à n'importe quelle demande.
Bonjour,uncahierdeschargesmerciaurevoir
J'hésite à mettre ça sur la pile des questions "Combien coûte un site web ?" ou à créer une pile à part...
Du coup, comme y a pas moyen de te répondre je continue avec le journal de Jean-Pierre Péhoho :
"Et tout de suite nous nous rendons dans la bourgade de Remiremont où l'on développe encore de manière traditionnelle, en témoignent les nombreux copeaux de sapin vosgien qui jonchent le sympathique atelier de linfograph".
traditionnel dans le Web... Qu'est-ce que ça peut bien vouloir dire ? PHP4, méthode à l'arrache, failles de sécu béantes c'est traditionnel je crois bien. Ou bien WordPress parce qu'après tout il a fêté ses 10 ans et qu'il est le n°1 des CMS.
J'hésite à mettre ça sur la pile des questions "Combien coûte un site web ?" ou à créer une pile à part...
Du coup, comme y a pas moyen de te répondre je continue avec le journal de Jean-Pierre Péhoho :
"Et tout de suite nous nous rendons dans la bourgade de Remiremont où l'on développe encore de manière traditionnelle, en témoignent les nombreux copeaux de sapin vosgien qui jonchent le sympathique atelier de linfograph".
traditionnel dans le Web... Qu'est-ce que ça peut bien vouloir dire ? PHP4, méthode à l'arrache, failles de sécu béantes c'est traditionnel je crois bien. Ou bien WordPress parce qu'après tout il a fêté ses 10 ans et qu'il est le n°1 des CMS.
Bonjour,
Je m'étais promis de ne plus nourrir le John, mais comme il n'y a pas tant de troll que ça (et même des remarques intéressantes) dans son intervention par rapport à ses précédentes, petite exception
Tu peux tourner les choses ainsi, mais c'est justement un atout : des mises à jour sont régulièrement mises à disposition afin de disposer d'un système sécurisé et pérenne
Par contre, il faut les suivre, ce qui implique de faire une maintenance suivie. C'est aussi le cas pour une admin maison de toute façon. Un système non-maintenu, c'est un site peu pérenne sur le long terme quoi qu'il en soit.
Ce n'est pas forcément facile à quantifier, mais il faut le faire, c'est clair.
Euh ? Pourquoi tu parles de tables et de fichiers à propos de la mise à jour de contenus. La mise à jour des contenus ne devrait nécessiter que l'accès à un éditeur WYSIWYG pour le rédacteur.
Pas forcément vrai pour tous les CMS. L'intérêt de WP est justement de pouvoir hooker à peu près tout pour fournir une install vraiment adaptée aux besoins. Par ailleurs, l'utilisation de types de contenus personnalisés, de champs personnalisés, etc, permet de faire une admin vraiment adaptée aux besoins du projet.
Soit ce besoin fonctionnel entre dans les clous du CMS choisi et on fait un développement spécifique en respectant les best pratices de développement de ce CMS afin de rester dans ses standards de dév, soit effeectivement, on choisira alors plutôt un développement maison from scratch (le choix dépend du budget, du CdC, du périmètre projet, etc).
Oui, c'est vrai, mais ça ce n'est pas trop grave, sérieux (OSEF, même ?), c'est surtout le manque de vrai MVC qui me gène chez WP pour ma part. Ah et puis aussi le nommage des fonctions PHP qui n'est pas toujours très heureux, et la multiplication de wrapper PHP pas très utiles (mais après la suffit de connaître).
Idem, c'est pas forcément hyper grave non plus, c'est vraiment de la micro-routine et ça peut d'ailleurs très facilement s'automatiser. On peut déployer du CMS sur plusieurs environnement en un tour de main si l'on utilise les méthodes de déploiement modernes (WP-CLI peut aider pour débuter).
Super… sérieux il y a plus génant tout de même : templating PHP (on s'y fait), pas de vrai MVC, par exemple
C'est quand un intérêt relativement anecdotique par rapport à tout le reste, et notamment à son interface d'admin/rédaction qui diminue trèsfortement les temps de formation (et donc de support).
Je ne sais pas si c'est LA bonne solution, mais c'est UNE solution, oui
J'ai rien contre (au contraire !) mais est-ce que ce trousseau ne devrait pas comprendre justement des CMS tels que WP pour être tout à fait complet ?
Bref, je veux pas me lancer dans une guéguerre inutile parce qu'on est en 2015 et que des CMS comme WP ont largement fait leurs preuves. Par contre, attention au développement maison parce que là aussi, on trouve de tout. Je connais de très bonnes agences près de chez moi qui font tout maison et qui font un travail très propre, j'en connais aussi qui font du gros caca à base de code spaghetti. Comme tu as des gens qui utilisent WP n'importe comment à grand renfort de dizaines de plugins ce qui nosu donne un système inmaintenable et complètement instable. Rien de nouveau : ça dépend
Modifié par audrasjb (07 Apr 2015 - 11:04)
Je m'étais promis de ne plus nourrir le John, mais comme il n'y a pas tant de troll que ça (et même des remarques intéressantes) dans son intervention par rapport à ses précédentes, petite exception
John-Rimbaud a écrit :
Les désavantages des CMS en général :
- Il faut les maintenir à jour, car des failles sont régulièrement découvertes et exploitées.
Tu peux tourner les choses ainsi, mais c'est justement un atout : des mises à jour sont régulièrement mises à disposition afin de disposer d'un système sécurisé et pérenne
Par contre, il faut les suivre, ce qui implique de faire une maintenance suivie. C'est aussi le cas pour une admin maison de toute façon. Un système non-maintenu, c'est un site peu pérenne sur le long terme quoi qu'il en soit.
John-Rimbaud a écrit :
Mettre à jour implique souvent un temps de travail important difficilement quantifiable
Ce n'est pas forcément facile à quantifier, mais il faut le faire, c'est clair.
John-Rimbaud a écrit :
- La mise à jour de contenu est beaucoup moins simple que sur un site fait main. Sur un site fait main, on fait les changements sur les fichiers et sur certaines tables et on upload le tout.
Euh ? Pourquoi tu parles de tables et de fichiers à propos de la mise à jour de contenus. La mise à jour des contenus ne devrait nécessiter que l'accès à un éditeur WYSIWYG pour le rédacteur.
John-Rimbaud a écrit :
- La gestion de l'administration nécessitera beaucoup plus de formation et de support pour le client qu'une administration bien conçue sur mesure. Un développement sur mesure fait ce que le client a demandé. Un CMS open source fait tout et il faut apprendre à l'utiliser de la bonne manière en fonction de ce que l'on souhaite en faire.
Pas forcément vrai pour tous les CMS. L'intérêt de WP est justement de pouvoir hooker à peu près tout pour fournir une install vraiment adaptée aux besoins. Par ailleurs, l'utilisation de types de contenus personnalisés, de champs personnalisés, etc, permet de faire une admin vraiment adaptée aux besoins du projet.
John-Rimbaud a écrit :
- Toute demande un peu particulière peut se révéler compliquée à exécuter avec un CMS open source. Il faudra soit trouver un module adapté, soit en développer un, soit souvent bidouiller pour arriver au résultat escompté, créant ainsi un système difficile à maintenir.
Soit ce besoin fonctionnel entre dans les clous du CMS choisi et on fait un développement spécifique en respectant les best pratices de développement de ce CMS afin de rester dans ses standards de dév, soit effeectivement, on choisira alors plutôt un développement maison from scratch (le choix dépend du budget, du CdC, du périmètre projet, etc).
John-Rimbaud a écrit :
Les désavantages de Wordpress en particulier :
- Le code est bordélique, il y a des fichiers de partout, c'est réellement du travail d'amateur. La racine du site contient plus d'une dizaine de fichiers là où tous les CMS et frameworks sérieux ne contiennent en général qu'un fichier index.php appelant les contrôleurs nécessaires, bien rangés.
Oui, c'est vrai, mais ça ce n'est pas trop grave, sérieux (OSEF, même ?), c'est surtout le manque de vrai MVC qui me gène chez WP pour ma part. Ah et puis aussi le nommage des fonctions PHP qui n'est pas toujours très heureux, et la multiplication de wrapper PHP pas très utiles (mais après la suffit de connaître).
John-Rimbaud a écrit :
- L'url du site est codée en dure à plusieurs endroits de la base de données, ce qui est parfaitement stupide. Lors d'un changement d'url (version test vers version live par exemple), il faudra effectuer une requête remplaçant toutes les occurrences de cette url.
Idem, c'est pas forcément hyper grave non plus, c'est vraiment de la micro-routine et ça peut d'ailleurs très facilement s'automatiser. On peut déployer du CMS sur plusieurs environnement en un tour de main si l'on utilise les méthodes de déploiement modernes (WP-CLI peut aider pour débuter).
John-Rimbaud a écrit :
- Il utilise les magic quotes, ce qui est une hérésie.
Super… sérieux il y a plus génant tout de même : templating PHP (on s'y fait), pas de vrai MVC, par exemple
John-Rimbaud a écrit :
Bref, pour moi le seul intérêt de Wordpress est qu'il se passe d'un système de templates inutile tel que smarty.
C'est quand un intérêt relativement anecdotique par rapport à tout le reste, et notamment à son interface d'admin/rédaction qui diminue trèsfortement les temps de formation (et donc de support).
John-Rimbaud a écrit :
La bonne solution est de développer son propre trousseau à outils et son interface d'administration standardisée qui permettra de déployer rapidement des fonctionnalités communes à la majorité des sites tout en restant suffisamment souple pour pouvoir répondre à n'importe quelle demande.
Je ne sais pas si c'est LA bonne solution, mais c'est UNE solution, oui
J'ai rien contre (au contraire !) mais est-ce que ce trousseau ne devrait pas comprendre justement des CMS tels que WP pour être tout à fait complet ?
Bref, je veux pas me lancer dans une guéguerre inutile parce qu'on est en 2015 et que des CMS comme WP ont largement fait leurs preuves. Par contre, attention au développement maison parce que là aussi, on trouve de tout. Je connais de très bonnes agences près de chez moi qui font tout maison et qui font un travail très propre, j'en connais aussi qui font du gros caca à base de code spaghetti. Comme tu as des gens qui utilisent WP n'importe comment à grand renfort de dizaines de plugins ce qui nosu donne un système inmaintenable et complètement instable. Rien de nouveau : ça dépend
Modifié par audrasjb (07 Apr 2015 - 11:04)
En fait le débat ne devrait pas être CMS vs codé à la main, car ça n'a aucun sens, on peut coder à la main un CMS.
La première question est: quel genre de site faut-il? :
1) CMS
2) Site statique
3) Web app
(se décide selon la quantité de contenu, leur fréquence de mise à jour, le/les responsables(s) de l'édition, les fonctionnalités nécessaires, etc.)
Ensuite, et seulement ensuite, il faut se poser la question de la technologie à utiliser:
CMS existant (wordpress, 99Ko, Drupal, etc.), un CMS maison, framework, HTML pur, etc.
Ce second choix est dépendant du cahier des charges, mais aussi beaucoup des développeurs: il y a des questions de préférences, de maintenance, de parc de sites, de qualifications des personnes travaillant dessus, etc.
Qu'il soit codé à la main aussi (voir plus encore même). Après si on parle d'un site de 4 pages avec 22 lignes de php, effectivement, le CMS serait une mauvaise alternative. Mais dès que le site atteint une certaine complexité, les tests avant une mise-à-jour ne devraient jamais être optionnels.
La première question est: quel genre de site faut-il? :
1) CMS
2) Site statique
3) Web app
(se décide selon la quantité de contenu, leur fréquence de mise à jour, le/les responsables(s) de l'édition, les fonctionnalités nécessaires, etc.)
Ensuite, et seulement ensuite, il faut se poser la question de la technologie à utiliser:
CMS existant (wordpress, 99Ko, Drupal, etc.), un CMS maison, framework, HTML pur, etc.
Ce second choix est dépendant du cahier des charges, mais aussi beaucoup des développeurs: il y a des questions de préférences, de maintenance, de parc de sites, de qualifications des personnes travaillant dessus, etc.
a écrit :
Sur un CMS il faut souvent effectuer le changement une première fois en test pour vérifier que tout se passe bien, puis refaire le travail sur la version en ligne.
Qu'il soit codé à la main aussi (voir plus encore même). Après si on parle d'un site de 4 pages avec 22 lignes de php, effectivement, le CMS serait une mauvaise alternative. Mais dès que le site atteint une certaine complexité, les tests avant une mise-à-jour ne devraient jamais être optionnels.
a écrit :
Tu peux tourner les choses ainsi, mais c'est justement un atout : des mises à jour sont régulièrement mises à disposition afin de disposer d'un système sécurisé et pérenne Smiley smile
Par contre, il faut les suivre, ce qui implique de faire une maintenance suivie. C'est aussi le cas pour une admin maison de toute façon. Un système non-maintenu, c'est un site peu pérenne sur le long terme quoi qu'il en soit.
À la différence que mis à part sur un site très important, il y a très peu de chance que des hackers perdent du temps à chercher des failles sur un développement maison. Ils préfèrent très largement se concentrer sur les failles des systèmes utilisés par des milliers voir millions de sites.
a écrit :
Euh ? Pourquoi tu parles de tables et de fichiers à propos de la mise à jour de contenus. La mise à jour des contenus ne devrait nécessiter que l'accès à un éditeur WYSIWYG pour le rédacteur.
Si tu veux perdre du temps à faire le boulot pourquoi pas. Quand un client me demande une mise à jour sur une section qu'il n'administre pas, je la fais en utilisant l'administration sur la version test puis je copie simplement les fichiers et tables concernées sur le site live. Ce n'est pas possible sur un CMS car des modifications manuelles sur les tables vont créer des conflits.
a écrit :
Super… sérieux il y a plus génant tout de même : templating PHP (on s'y fait), pas de vrai MVC, par exemple Smiley
L'utilisation des magic_quotes est une faille de sécurité dépréciée depuis des années et qui ne sera plus supportée dans les prochaines versions de PHP. Que wordpress les implémente encore est juste ridicule.
a écrit :
C'est quand un intérêt relativement anecdotique par rapport à tout le reste, et notamment à son interface d'admin/rédaction qui diminue trèsfortement les temps de formation (et donc de support).
Mon interface d'administration à moi ne requière pour 9 clients sur 10 aucune formation. Elle fait uniquement ce dont le client à besoin, il trouve donc instinctivement comment l'utiliser.
Désolé de taper l'incrust'... mais je lisais mon retard sur Commit Strip...
Et disons que http://www.commitstrip.com/fr/2015/04/03/cms-or-custom/ . Ca me semblait être le coeur du débat
Et disons que http://www.commitstrip.com/fr/2015/04/03/cms-or-custom/ . Ca me semblait être le coeur du débat
Lothindil a écrit :
Désolé de taper l'incrust'... mais je lisais mon retard sur Commit Strip...
Et disons que http://www.commitstrip.com/fr/2015/04/03/cms-or-custom/ . Ca me semblait être le coeur du débat
Même si j'adore ce strip vu il y a quelques jours
… s'il y avait encore un débat, la réflexion ci-dessous du kusto, explique pourquoi il n'a pas spécialement de sens aujourd'hui :kustolololovic a écrit :
La première question est: quel genre de site faut-il? :
1) CMS
2) Site statique
3) Web app
(se décide selon la quantité de contenu, leur fréquence de mise à jour, le/les responsables(s) de l'édition, les fonctionnalités nécessaires, etc.)
Ensuite, et seulement ensuite, il faut se poser la question de la technologie à utiliser
[résolu], non ?
Modifié par audrasjb (07 Apr 2015 - 22:54)
John-Rimbaud a écrit :
À la différence que mis à part sur un site très important, il y a très peu de chance que des hackers perdent du temps à chercher des failles sur un développement maison. Ils préfèrent très largement se concentrer sur les failles des systèmes utilisés par des milliers voir millions de sites.
Et ? Où est le problème. Si le système est à jour où est le souci au juste ?
Parce que tu n'utilise pas de CMS, tu ne fais aucune MAJ de sécurité sur les dévs antérieurs faits par ton agence ? Pas de maintenance ? Rien ?
John-Rimbaud a écrit :
Si tu veux perdre du temps à faire le boulot pourquoi pas. Quand un client me demande une mise à jour sur une section qu'il n'administre pas, je la fais en utilisant l'administration sur la version test puis je copie simplement les fichiers et tables concernées sur le site live. Ce n'est pas possible sur un CMS car des modifications manuelles sur les tables vont créer des conflits.
Hmmmmmm… La première assertion me fait peur. Si des parties ne sont pas administrables, c'est qu'elles ne devraient pas être modifiées. Sinon elles devraient être administrables…
La deuxième est sans objet : quels conflits exactement ?
John-Rimbaud a écrit :
L'utilisation des magic_quotes est une faille de sécurité dépréciée depuis des années et qui ne sera plus supportée dans les prochaines versions de PHP. Que wordpress les implémente encore est juste ridicule.
Sur ton install serveur, suffit de ne pas activer magic_quotes et voilà. Où est le problème ?
Faut arrêter de chipoter là, t'as lu un truc sur l'ensemble d'un système complet et complexe pour remettre en cause le professionnalisme de milliers de tes confrères…
John-Rimbaud a écrit :
Mon interface d'administration à moi ne requière pour 9 clients sur 10 aucune formation. Elle fait uniquement ce dont le client à besoin, il trouve donc instinctivement comment l'utiliser.
Ok, tu démontres juste que 10% des sites sur lesquels tu travaille ont un périmètre fonctionnel nécessitant une formation, c'est tout. À partir d'un moment, quelle que soit la technologie, la technique, le design, le CMS utilisé… la formation d'un client à l'interface qu'il devra manipuler est obligatoire, qu'elle soit comprise ou non dans la prestation, c'est pas la question, mais c'est un problème de livrable et de périmètre de la prestation commandée par les clients de ta boîte. Que ce soit pour une question de contrat de livraison, de garantie ou de confort lors du support associé à la presta. Bref, soit tu travaille sur de très petits projets, soit tu ne fais pas les choses sérieusement…
Le débat CMS vs fait maison est un vieux troll...
Voici mon regard d'étudiant sur la question:
Les avantages du CMS:
* Ca s'installe et ça marche en 5 minutes, tu n'as plus qu'à faire le design
* C'est facile à utiliser par le client et tu n'as pas d'interface admin assez chiante à coder toi-même
Les inconvénients des CMS :
* ON est à la merci des lamers et les mises à jour ne sont pas toujours faciles
* LE moindre ajout de fonctionnalité hors cadre est rapidement un problème
* Le CMS ne fait jamais exactement ce qu'on veut qu'il fasse
* C'est beaucoup moins intéressant de passer sa vie à googler pour trouver des plugins et les tester pour être sûr qu'ils font vraiment ce qu'on veut comme on veut, plutôt que de coder soi-même.
En fait, les trois premiers points des inconvénients viennent essentiellement du fait que quand on utilise un CMS, on ne maîtrise pas la base de code, et on doit faire avec même si la qualité n'est pas toujours celle attendue. Les arguments de l'interface admin souvent chiante à coder et celui de la valorisation intellectuelle d'avoir vraiment fait quelque chose soi-même sont plus personnels et discutables. Ca paraît assez logique que pour les gens plus axés création graphique qu'algorithmes, le code ça ne les intéresse pas plus que ça, tout comme les super développeurs peuvent s'en ficher royalement d'avoir un design basique et austère tant que ça reste pratique et fonctionnel; donc les premiers sont probablement nettement plus enclins à opter pour le CMS puisque, de leur point de vue, ça leur enlève la partie chiante du travail.
En ce qui concerne les plugins, en un sens, je trouve que c'est plutôt contradictoire: si on cherche des plugins, c'est pour aller plus vite et éviter d'avoir à coder quelqeu chose qui ne nous intéresse pas, qu'on ne maîtrise pas et/ou dont on n'a pas le temps. Or si on veut faire les choses correctement, on perd quand même un certain temps à chercher sur le web quelque chose qui correspond à ce qu'on veut, et on doit de toute façon quand même le tester pour être vraiment sûr que ça fait ce que ça doit faire; pire, parfois on doit encore le modifier un petit peu parce que ce n'est pas tout à fait le cas. JE ne suis pas sûr qu'on gagne vraiment du temps au final ! Comme toujours, l'appréciation dépend de ce que c'est.
Donc pour moi, CMS ou pas, c'est essentiellement une question de temps, de maîtrise et de qualité recherchée. Si je carricature, ça donne :
* Tu n'as pas le temps et ça doit marcher dans 5 minutes, tu n'as pas le choix: utilise un CMS
* Entrer dans les méandres du code ne t'intéresse pas, prends un CMS
* Tu n'es pas capable ou tu penses ne pas être capable de coder une fonctionnalité X, va chercher un plugin qui le fait pour toi sur google
* Tu t'en fous si ce n'est pas si bien que ça, si ce n'est pas au top niveau qualité, tant que ça marche c'est l'essentiel, alors cherche pas trop, prends un CMS
* Tu es bien meilleur pour lire le code des autres et bidouiller que faire ton propre code, alors prends un CMS.
D'après moi, la réflexion s'applique à n'importe quel stade d'un projet, pour n'importe quelle technologie. JQuery vs vanilla, même combat; remplacez dans mon message toutes les occurences de CMS par framework et mes arguments resteront globalement encore les mêmes; si on va plus loin, en fait, si on utilise un serveur apache, c'est parce que c'est une solution qui marche pour le quasi 100% des besoins courants en peu de temps, et qu'on n'a ni le temps, ni l'intérêt suffisant pour se pencher sérieusement dans les méandres de la programmation réseau et du protocole HTTP; et si on utilise un OS, c'est pareil, c'est parce que ça fait ce qu'on veut que ça fasse et que personne n'est assez fou pour remettre en cause la gestion du matériel à bas niveau.
Quoi qu'on fasse, le couperet risquera toujours de retomber le jour où on a un besoin spécifique non couvert et qu'il faut alors mettre les mains dans quelque chose qu'on ne maîtrise pas. La question est donc de savoir sur quels sujets on accepte de vivre avec ce risque, ou, autrement dit, comment on décide de vivre avec un marteau sachant que les vis existent et qu'on est ou non capable de construire un tournevis le jour où on en a besoin.
Si on résume, il s'agit donc essentiellement de connaître ses compétences et ses limites, le temps qu'on a à disposition et son intérêt.
LE meilleur CMS est sans doute celui qu'on confectionne soi-même, et qu'on étoffe au fil des projets et des années.
Pour avancer sur cette question, il serait intéressant d'avoir des retours d'expérience de gens qui ont utilisé un CMS, ou au contraire qui n'en n'ont pas utilisé, et qui ont regretté leur choix par la suite; le tout en restant neutre et sans citer de noms en particulier, parce que ça n'apporte rien hormis cristaliser le débat en « pour ou contre tel CMS », « X est-il mieux que Y » ou bien « quel CMS est le meilleur ».
Pour ma part, pour le moment, je n'ai aucun impératif de temps, je suis perfectionniste et j'aime ce que je fais, donc je fais tout moi-même et j'exècre généralement les CMS et autres frameworks. Je vais probablement devoir commencer à réfléchir différemment le jour où je travaillerai pour un patron et de l'argent; quelque part ça me fait peur...
Modifié par QuentinC (08 Apr 2015 - 09:21)
Voici mon regard d'étudiant sur la question:
Les avantages du CMS:
* Ca s'installe et ça marche en 5 minutes, tu n'as plus qu'à faire le design
* C'est facile à utiliser par le client et tu n'as pas d'interface admin assez chiante à coder toi-même
Les inconvénients des CMS :
* ON est à la merci des lamers et les mises à jour ne sont pas toujours faciles
* LE moindre ajout de fonctionnalité hors cadre est rapidement un problème
* Le CMS ne fait jamais exactement ce qu'on veut qu'il fasse
* C'est beaucoup moins intéressant de passer sa vie à googler pour trouver des plugins et les tester pour être sûr qu'ils font vraiment ce qu'on veut comme on veut, plutôt que de coder soi-même.
En fait, les trois premiers points des inconvénients viennent essentiellement du fait que quand on utilise un CMS, on ne maîtrise pas la base de code, et on doit faire avec même si la qualité n'est pas toujours celle attendue. Les arguments de l'interface admin souvent chiante à coder et celui de la valorisation intellectuelle d'avoir vraiment fait quelque chose soi-même sont plus personnels et discutables. Ca paraît assez logique que pour les gens plus axés création graphique qu'algorithmes, le code ça ne les intéresse pas plus que ça, tout comme les super développeurs peuvent s'en ficher royalement d'avoir un design basique et austère tant que ça reste pratique et fonctionnel; donc les premiers sont probablement nettement plus enclins à opter pour le CMS puisque, de leur point de vue, ça leur enlève la partie chiante du travail.
En ce qui concerne les plugins, en un sens, je trouve que c'est plutôt contradictoire: si on cherche des plugins, c'est pour aller plus vite et éviter d'avoir à coder quelqeu chose qui ne nous intéresse pas, qu'on ne maîtrise pas et/ou dont on n'a pas le temps. Or si on veut faire les choses correctement, on perd quand même un certain temps à chercher sur le web quelque chose qui correspond à ce qu'on veut, et on doit de toute façon quand même le tester pour être vraiment sûr que ça fait ce que ça doit faire; pire, parfois on doit encore le modifier un petit peu parce que ce n'est pas tout à fait le cas. JE ne suis pas sûr qu'on gagne vraiment du temps au final ! Comme toujours, l'appréciation dépend de ce que c'est.
Donc pour moi, CMS ou pas, c'est essentiellement une question de temps, de maîtrise et de qualité recherchée. Si je carricature, ça donne :
* Tu n'as pas le temps et ça doit marcher dans 5 minutes, tu n'as pas le choix: utilise un CMS
* Entrer dans les méandres du code ne t'intéresse pas, prends un CMS
* Tu n'es pas capable ou tu penses ne pas être capable de coder une fonctionnalité X, va chercher un plugin qui le fait pour toi sur google
* Tu t'en fous si ce n'est pas si bien que ça, si ce n'est pas au top niveau qualité, tant que ça marche c'est l'essentiel, alors cherche pas trop, prends un CMS
* Tu es bien meilleur pour lire le code des autres et bidouiller que faire ton propre code, alors prends un CMS.
D'après moi, la réflexion s'applique à n'importe quel stade d'un projet, pour n'importe quelle technologie. JQuery vs vanilla, même combat; remplacez dans mon message toutes les occurences de CMS par framework et mes arguments resteront globalement encore les mêmes; si on va plus loin, en fait, si on utilise un serveur apache, c'est parce que c'est une solution qui marche pour le quasi 100% des besoins courants en peu de temps, et qu'on n'a ni le temps, ni l'intérêt suffisant pour se pencher sérieusement dans les méandres de la programmation réseau et du protocole HTTP; et si on utilise un OS, c'est pareil, c'est parce que ça fait ce qu'on veut que ça fasse et que personne n'est assez fou pour remettre en cause la gestion du matériel à bas niveau.
Quoi qu'on fasse, le couperet risquera toujours de retomber le jour où on a un besoin spécifique non couvert et qu'il faut alors mettre les mains dans quelque chose qu'on ne maîtrise pas. La question est donc de savoir sur quels sujets on accepte de vivre avec ce risque, ou, autrement dit, comment on décide de vivre avec un marteau sachant que les vis existent et qu'on est ou non capable de construire un tournevis le jour où on en a besoin.
Si on résume, il s'agit donc essentiellement de connaître ses compétences et ses limites, le temps qu'on a à disposition et son intérêt.
LE meilleur CMS est sans doute celui qu'on confectionne soi-même, et qu'on étoffe au fil des projets et des années.
Pour avancer sur cette question, il serait intéressant d'avoir des retours d'expérience de gens qui ont utilisé un CMS, ou au contraire qui n'en n'ont pas utilisé, et qui ont regretté leur choix par la suite; le tout en restant neutre et sans citer de noms en particulier, parce que ça n'apporte rien hormis cristaliser le débat en « pour ou contre tel CMS », « X est-il mieux que Y » ou bien « quel CMS est le meilleur ».
Pour ma part, pour le moment, je n'ai aucun impératif de temps, je suis perfectionniste et j'aime ce que je fais, donc je fais tout moi-même et j'exècre généralement les CMS et autres frameworks. Je vais probablement devoir commencer à réfléchir différemment le jour où je travaillerai pour un patron et de l'argent; quelque part ça me fait peur...
Modifié par QuentinC (08 Apr 2015 - 09:21)
a écrit :
Et ? Où est le problème. Si le système est à jour où est le souci au juste ?
Ouiiii, c'est très bien tenir le système à jour ... à partir du moment où tous les développeurs de modules ou thèmes utilisés par le site ont respecté à la lettre les recommandations du CMS, ce qui n'arrive pratiquement jamais. Et il y aura de toute manière fatalement le moment où une mise à jour majeure ne permettra pas la rétrocompatibilité de certains modules plus maintenus.
a écrit :
Parce que tu n'utilise pas de CMS, tu ne fais aucune MAJ de sécurité sur les dévs antérieurs faits par ton agence ? Pas de maintenance ? Rien ?
Je répare quand il y a un bug ou un problème, par contre je n'ai jamais eu de problème de faille. D'autres part parce que je pense mon développement solide, d'autre par parce que contrairement aux CMS, je n'ai pas en permanence une armée de hackers à la recherche de ces failles.
a écrit :
Hmmmmmm… La première assertion me fait peur. Si des parties ne sont pas administrables, c'est qu'elles ne devraient pas être modifiées. Sinon elles devraient être administrables… Smiley murf
Quelques fois je mets à jour directement le code html, quelques fois directement la base de données. J'évite de mettre des éditeurs WYSIWYG quand ce n'est pas indispensable.
a écrit :
La deuxième est sans objet : quels conflits exactement ?
Quand je mets à jour mes news, je mets à jour ma table news. Quand tu mets à jour les news sur un CMS, ça met à jour la table type de contenus, la table type de champs, la table liant les types de contenus et types de champs, la table type de champs et contenus des champs .... Bref, il faut nécessairement passer par l'interface d'administration, et ce deux fois en quoi de version test.
a écrit :
Sur ton install serveur, suffit de ne pas activer magic_quotes et voilà. Où est le problème ?
Faut arrêter de chipoter là, t'as lu un truc sur l'ensemble d'un système complet et complexe pour remettre en cause le professionnalisme de milliers de tes confrères…
Les désactiver ne sert à rien puisque les modules en ont besoin. Les magic quotes ont été dépréciées pour une bonne raison : elles servent de filet de sécurité à des développeurs travaillant mal. On ne bosse plus avec ça depuis des années, surtout avec les différentes couches d'abstraction telles que PDO qui suppriment tout risque d'injection SQL. Bref, Wordpress incite ses développeurs à mal travailler.
a écrit :
À partir d'un moment, quelle que soit la technologie, la technique, le design, le CMS utilisé… la formation d'un client à l'interface qu'il devra manipuler est obligatoire, qu'elle soit comprise ou non dans la prestation, c'est pas la question
Je dis simplement aux clients d'aller bidouiller dans l'interface en version test et de m'appeler pour que l'on parcoure cela ensemble si des choses ne leur paraissent pas claires. Ils appellent rarement. Sur un Wordpress installé par un concurrent dont nous avions récupéré la gestion par contre, le client appelait une à plusieurs fois par semaine parce qu'il ne s'en sortait pas.
Est-ce que les gens ont besoin d'une formation pour utiliser facebook, leur client mail ? Non. Une administration de site ça doit être pareil, ça ne doit faire que ce dont le client a besoin.
Modifié par John-Rimbaud (08 Apr 2015 - 09:22)
a écrit :
Je dis simplement aux clients d'aller bidouiller dans l'interface en version test et de m'appeler pour que l'on parcoure cela ensemble si des choses ne leur paraissent pas claires. Ils appellent rarement. Sur un Wordpress installé par un concurrent dont nous avions récupéré la gestion par contre, le client appelait une à plusieurs fois par semaine parce qu'il ne s'en sortait pas.
Ok, je comprends mieux
C'est bien ce que je disais : tu parles de sites de taille très réduite avec un voire deux contributeurs maximum et aucune gestion des droits, aucun workflow de validation interne.
C'est clairement pas le type de sites sur lequel interviennent principalement les agences. Ça nous arrive aussi de monter un mini-site pour un petit client cool/copain des gérants. On lui monte un WP tout épuré de tout ce qui est en trop dans l'admin et on ne le forme pas non plus. Mais je crois pas qu'une bonne agence puisse décemment vivre de ce type de mini clients
Pour les clients normaux, ayant des exigences définies dans un cahier des charges et des spécifications très détaillées, tu ne peux pas faire les choses à la RACHE© en les envoyant se balader sur l'admin. Il y a des niveaux de droits, des priorisation de publication, une interface différente pour chaque type de profil, etc. Tout cela est documenté de façon précise (important en cas de turn over sur les postes chez le client), et fait l'objet d'une ou plusieurs séances de formation suivant les profils de contributeurs/rédacteurs/gestionnaires de commandes/admin.
Modifié par audrasjb (08 Apr 2015 - 09:55)