Yhann Posté 7 Mai 2007 Posté 7 Mai 2007 Bonjour, Après 7 années de développement de sites internet dynamiques, je sollicite votre expérience pour avoir des avis pouvant m'aider dans mon actuelle réflexion. 99,99% des sites que j'ai réalisé (en PHP, MySQL) ont été fourni avec un backoffice personnalisé, permettant au client d'agir uniquement sur les contenus nécessitant une mise à jour régulière. Cela peut-être un édito, une rubrique actualités, un annuaire de liens, une galerie d'images, etc. Ces éléments étaient décidés en concertation avec le client, dans le cahier des charges. De rare fois, lorsqu'il était nécessaire que le client dispose de la possibilité d'agir sur le contenu intégral de son site, j'ai utilisé Spip. Aujourd'hui, force est de constater que les appels d'offres qui circulent mentionnent l'emploi de CMS. Les clients souhaitent avoir la main sur l'ensemble de leur site web. Ce que je comprends bien volontiers. Autrefois, cette méthide était suffisante. Aujourd'hui, les Blogs sont passés par là, et les gens ont pris l'habitude de plus d'interactivité entre le web et eux. Je pense donc que la méthode que j'utilisais n'est plus satisfaisante. Travailler sur un organigramme de site web, en réfléchissant aux contenus devant être relié au backoffice pour permettre au client de procéder à ces mises à jour n'est plus envisageable. Je pense généraliser l'emploi de CMS, pouvant être différents selon le type de site à concevoir. Maintenant, j'aimerais savoir comment vous procédez. Faites vous, comme moi, le plus souvent des sites statiques, avec des zones dynamiques à l'intérieur, ou concevez-vous votre site intégralement en dynamique, avec un backoffice permettant d'éditer l'ensemble des textes (et photos ?) Vos avis m'intéressent. Merci par avance pour vos posts à ce sujet. Yhann.
captain_torche Posté 7 Mai 2007 Posté 7 Mai 2007 A mon avis, tout dépend du site en question. A partir du moment où le contenu est amené à évoluer plus ou moins régulièrement, un back office complet est nécessaire (que ce soit un CMS ou un BO propriétaire). J'imagine également que, pour tes clients, le prix n'est pas le même dans les deux cas; ils doivent choisir l'une ou l'autre des solutions en toute connaissance de cause.
Yhann Posté 7 Mai 2007 Auteur Posté 7 Mai 2007 Salut, J'imagine également que, pour tes clients, le prix n'est pas le même dans les deux cas Bein, mettre en place un Spip (par exemple) ne prend pas plus de temps que la réalisation d'un site dédié...
Wefficient Posté 7 Mai 2007 Posté 7 Mai 2007 (modifié) Le marché évolue selon 2 aspects : - la technique qui veut qu'il soit plus facile de faire un site en CMS car c'est quasiment "out of the box" - la psychologie du client qui prefere qu'on lui offre un truc open avec toutes les options. Il aime la sensation de liberté genre je roule a fond les cheveux au vent. Ce que j'en dit, assez cyniquement c'est vrai, c'est que le client prefere souvent avoir la possibilité de se prendre le mur tout seul a toute vitesse, que de l'eviter si c'est pas lui qui est au volant :-( Perso, je préfère avoir un controle total sur le site des clients, et qu'ils ne puissent changer que ce qu'ils ont à changer eux même (et encore !). C'est ce que je prefere mais c'est pas toujours ce qui se passe concretement. Pourquoi je prefere cela, parce que je vend surtout du conseil et de l'optimisation, donc j'aime pas avoir à refaire plusieurs fois le travail parce qu'en mettant une info à jour ils bousillent tout. Cas concret : J'ai eu un client pour lequel le référencement à été totalement inefficace pendant 7 mois. Chaque fois que je passais pour optimiser qqch, le fils du patron repassait derrière pour mettre une ancienne version qu'il avait optimisé lui même. S'ils n'avaient eu accès qu'à la page des news, cela ne serait pas arrivé. C'est avec un changement de serveur qu'en 1 mois le site est apparu en top10, et que j'ai pu découvrir le pot aux roses. (l'accès ftp ayant changé, il a du me le redemander...) Dans ton cas, si tu veux pas te prendre la tete, fait du CMS car c'est ce qui répond aux 2 exigences des clients. Si tu fais du conseil en plus dans ton package, bride le CMS pour pas qu'ils te bousillent le boulot a valeur ajoutée. Modifié 7 Mai 2007 par Wefficient
Yhann Posté 7 Mai 2007 Auteur Posté 7 Mai 2007 Salut Wefficient, Analyse sympa. Merci d'avoir pris la peine de faire part de ton avis. C'est terrible, l'exemple que tu donnes, avec le fils du patron qui agissait en parallèle !
who Posté 7 Mai 2007 Posté 7 Mai 2007 (modifié) Bonjour à tous, Et bien va pour la solution CMS mais... à ce sujet, un CMS concu (j'entends là developpé par le webmaster, et non pas de l'open-source) pour un site tout dynamique, donne quels droits d'utilisation au client? Un contrat de vente pour un site web peut-il stipuler que l'oeuvre en question ne doit être utilisée que dans le cadre du site contractuel, et surement pas être copiée afin de publier d'autres sites web en se passant allègrement de débourser à nouveau pour une nouvelle conception....?? Et si oui de quelle maniere? Faut t'il passer par une license logicielle? En bref comment le créateur peut-il vendre son CMS "maison" sans céder tous ses droits et perdre son bébé ? J'espere rester dans le sujet en traitant ainsi de l'aspect commercial de la chose... Modifié 7 Mai 2007 par who
Wefficient Posté 7 Mai 2007 Posté 7 Mai 2007 Je peux te dire que les 2 premiers mois, j'ai pensé à une sandbox car le site à ploppé d'un seul coup sur la toile. Mais les mois 3 à 7 ont été d'autant plus durs que je ne comprennais absolument pas pourquoi ce site était le seul que je n'arrive pas a positionner au moins en top 20. J'avoue j'ai douté ! et je me suis arraché quelques cheveux, les blancs en premier ! J'ai subi les remarques puis remontrances du clients plusieurs mois de suite, le poing dans la poche et l'ego laissé à la maison, ce qui ne me ressemble pas ;-) Une fois découvert le pot aux roses, le client et son fils ont morflés car je suis venu avec les preuves concretes des manipulations. Depuis je demande si le client à un enfant qui "touche" en informatique et en web, et si la réponse est oui, je verrouille sur ce que je dois faire sinon je prend pas ;-) (oui j'avoue c'est plus simple quand on peut se permettre de poser ses conditions )
Dadou Posté 7 Mai 2007 Posté 7 Mai 2007 Pour notre part, nous avons développé notre propre CMS qui est installé sur un serveur semi-dédié. L'application est mutisites, donc rien à installer, c'est déjà fait. Lors de l'établissement du contrat, le client est au courant qu'il n'aura aucun accès FTP au serveur, et que si il désire nous quitter il n'aura que la sauvegarde statique du site. Nous lui expliquons que l'avantage de cette solution, est que dès qu'un client nous signale un bug sur l'outil, nous intervenons rapidement pour le corriger et tous profitent du correctif en direct, et puis pour le client, l'autre avantage de ce type de solution, c'est qu'il a accès à un outil bien abouti en fonctionnalités pour un cout financier peut élevé. Dans le cas ou le client veut quand même les accès FTP, nous installons le CMS à part (facturé), le prévenons que les mises à jour seront facturé (maintenance supplémentaire), lui faisont signer un contrat lui interdisant de ré-exploiter notre CMS pour toute autre site que celui défini dans le contrat. En général, quand ils voient le cout plus élévé, ils reste sur la solution multisite
who Posté 7 Mai 2007 Posté 7 Mai 2007 Merci beaucoup pour toutes ces infos Dadou c'est bien plus clair pour moi maintenant. Je trouve tout cela trés convaincant, c'est une force certaine que de proposer un outil bien abouti, en effet, tout en se préservant des manipulations d'un tiers sur le serveur (n'est-ce pas Wefficient? ) Apparemment tout le monde doit y trouver son compte...
Yhann Posté 8 Mai 2007 Auteur Posté 8 Mai 2007 Juste pour revenir à la question initiale : sur vos backoffices respectifs : 1. le client a t-il la main sur quelques contenus dynamiques seulement ? 2. le client a t-il la main sur l'ensemble du contenu du site (il peut modifier TOUS les textes) ? 3. le client a t-il la main sur tout (à la Spip, avec possibilité d'éditer les rubriques, sous-rubriques, etc.) ? Les réponses à ces questions m'intéressent grandement !
Wefficient Posté 8 Mai 2007 Posté 8 Mai 2007 Chez moi, c'est au cas par cas. Si le client cree lui même ses pages parce qu'il a les compétances (ou a qqn qui les a) il peut avoir la main. S'il a pas les compétances, généralemetn il prend alors un package complet de webmarketing et la gestion du site est integrée dedans. Mais bon, mes prestations ne sont pas tout à fait du site et de l'hébergemetn dans mon cas, c'est plus une approche globale. Les réponses des autres intervenants seront certainement plus représentatives.
Dadou Posté 8 Mai 2007 Posté 8 Mai 2007 Pour ma part, il a la main sur tout le contenu, par contre, le jour ou il veux ajouter un module de galerie photos par exemple, c'est un module que permet notre CMS, mais que nous devons activer pour lui. La charte graphique est modifiable depuis le CMS, mais c'est une partie dont on ne laisse pas la main au client (pas fou non plus, c'est la qu'il est possible de faire le plus de dégats)
who Posté 9 Mai 2007 Posté 9 Mai 2007 Je m'excuse Yhann si j'ai un peu zappé ta question ... voila la réponse par laquelle j'aurai dû commencer, elle n'a de valeur que pour réflexion puisque mon projet n'est pas tout à fait terminé, et que mes choix sur la question n'ont rien de définitif... Pour l'instant j'ai mis en place un systeme disposant de 4 niveaux de sécurité: visiteur, membre, rédacteur, et administrateur. Le backoffice permet aux rédacteurs d'éditer le contenu des articles qu'ils ont signés, avec une mise en forme à base de bbcode, et de les switcher online/offline. il offre aussi une zone média dédiée au classement et à l'upload des images/sons/vidéos intégrables aux publications. Le groupe administrateur accède en plus à tout le reste (gestion des rubriques, permissions sur les membres, choix de la page d'accueil, de gabarits et feuilles de style, backup sql... et activation d'autres modules en cours et à venir (chatbox, webcam, ...).
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant