Bon bouquin pour création de boutique en ligne
Booleanne
Membre
Bonjour à tous,
Encore une fois, l'essentiel est dans le titre : je recherche un bon bouquin technique pour la création d'une boutique en ligne.
Ce qui me pose problème étant essentiellement les notions de session, gestion des cookies, paiement en ligne, sécurité. Eventuellement base de données.
Merci d'avance de vos bons conseils.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
PS: Ne pas oublier le côté légal.
Merci Larme, oui, j'avais oublié ça.
Un peu tout quoi ! :-*
T'as 2 options:
- tout développer toi même...
- utiliser des outils tout prêts (CMS...) mais moins de sécurité... cependant 90% des sites de commerce utilisent des packages prêts à l'emploi.
Je n'ai pas de livre à te conseiller, ce que tu cherches à comprendre ne s'adresse pas uniquement à un site/boutique en ligne; c'est assez général ! Installer une solution de paiement en ligne n'est pas trivial non plus (solution fournie par la banque), à part si tu n'utilises que Paypal.
Oui, un peu tout. Merci pour ta réponse.
Créer un site, PHP, HTML, je m'en débrouille. Et surtout pas de CMS... je veux pouvoir faire tout ce que je veux, moi ::) .
C'est vrai que c'est surtout la partie paiement en ligne qui m'inquiète... ce n'est peut-être pas trivial, comme tu dis, mais il faut toujours aller à la pêche aux informations, on perd un temps fou !
C'est pour ça que je voudrais trouver une bonne base que me dégrossisse déjà un peu le boulot.
Côté technique, si tu choisis de tout faire toi-même, je te conseille d'essayer stripe.com qui est une API simple pour recevoir des paiements.
Ils sont encore en beta en France mais tu peux quand même t'inscrire et recevoir des paiements.
Merci pour ton conseil. Je vais me pencher là -dessus.
Y a prestashop qui est très répandu pour les boutiques en ligne.
Après, je connais pas plus que ca...
Prestashop c'est un CMS
C'est surtout que dans le développement d'un site e-shop, il y a beaucoup d'à côté, si tu veux tout gérer :
- Les certificats.
- Le paiement sécurisé (beaucoup de solutions existe notamment une version de paypal
, ou d'autres qui proposent même le paiement par chèque ).
- Les informations légales.
- Les frais de ports.
Après tout dépend de ce que tu vends, ou si tu développe pour quelqu'un d'autre. Mais il y une question logistique de stock qui peut être en corrélation avec ton site.
Un site e-commerce est très vite noyé dans la masse, suivant son secteur d'activité. Alors une campagne e-marketing réfléchi et un bon référencement ne sera pas de trop.
Et bien sur, le développement qui comprend BDD, sécurité, etc.... le truc classique quoi.
Ca fait une paire d'année que je n'ai pas développé de site e-commerce, c'est ce qui me revient comme ça.
Merci, oui, c'est ce qu'il m'a semblé. Après, je me fais peut-être une idée fausse des CMS.
Pour moi, un CMS, ça veut dire :
1. On ne peut pas toujours modifier le code comme on veut.
2. Même si on veut taper dans le code, c'est compliqué parce qu'il faut rentrer dans des routines qu'on n'a pas créées.
Merci, du coup, ce qui te revient est certainement une bonne synthèse !
Le 1 c'est pas tout à fait vrai en principe tu peux tout modifier mais après le problème vient du 2 : c'est pas toi qui a codé le truc et il a son fonctionnement propre qui peut être parfois déroutant et/ou difficile à comprendre
Le gros avantage du CMS c'est surtout les choses qui existe déjà : on a par exemple beaucoup parlé de paiement, avec un prestashop tu n'aura pas vraiment cette problématique puisque tu trouveras facilement des modules déjà codés qu'il te suffiras de paramétrer
L'idée, alors, serait un site standard et je peux utiliser un CMS juste pour la gestion du paiement en ligne ?
Non si tu utilise un CMS ça sera pour l'intégralité de ton site.
Le CMS fait déjà pas mal de choses pour toi (je ne connais pas spécialement les CMS de site e-commerce mais le principe reste le même) :
- Tu auras déjà une grosse partie du site de développé et c'est à toi ensuite de modifier le template pour le personnaliser
- La partie administrateur est déjà codé et la gestion utilisateur existe déjà
- Selon les CMS tu peux aussi avoir des gestionnaires de contenues (une architecture catégorie>items où tu auras juste à paramétrer tes catégories et à rentrer tes items)
La personnalisation du CMS se fait via les template :
Tu en as qui sont fournit avec le CMS mais tu peux ajouter des templates partagés par la communautés ou codé le tiens
Ensuite tu pourras rajouter des modules :
Tu définis l'emplacement dans ton template qui va appeler un module (un morceau de code) qui peut être un peut tout et n'importe quoi (boite de connexion, calendrier, météo...)
Tu auras la possibilité de trouver de nombreux modules déjà codé par la communauté autour du CMS qui pourront potentiellement répondre à tes besoins
Attention tu peux recoder pas mal de chose mais si tu veux que ton site garde de la cohérence et conserve les avantages du CMS tu devra coder selon la logique du CMS. Il faut donc prévoir un temps d'apprentissage sur l'architecture des templates/modules/extensions du CMS
Merci, du coup, je reste sur mon idée que je ne veux pas de CMS. J'aime bien garder la maà®trise et être libre de pouvoir tout faire, au moins pour la partie site. Je vais réfléchir à ce qui me convient le mieux.
Grande question. CMS/pas CMS...
Je ne connais pas prestashop donc je ne peux pas vraiment t'aider. Mais je sais qu'il couvre bcp de choses et qu'énormément de sites e-commerces l'utilisent.
Peut être devrais tu procéder ainsi :
=> déterminer les éléments clés et prio que tu veux voir sur ton site
=> les coder à la main et voir ce que ça donne
=> tester un cms et voir ce que ça donne.
Laisse toi 2 jours pour coing perso, 2 jours pour cmd et ça t'aidera à trancher.
Le coding perso, c'est bien mais tu risques de te heurter à tous ces pb de compatibilité de navigateurs qui sont déjà pris en charge par les cms...
Merci, c'est vrai que j'ai failli oublier cette vraie galère !!!
Ca vas dépendre de ceux que tu veux comme design : si tu veux un truc 100% perso avec ton propre template le CMS ne va pas beaucoup t'aider, en revanche si tu prend un truc déjà existant (donc configurable et modifiable mais pas forcément à 100% comme tu veux) il y a de grande chance qu'il soit compatible multi-browser voir même responsive en fonction du template que tu vas prendre
Au pire tu fais comme Kogan !
http://www.numerama.com/magazine/22891-un-cyber-marchand-taxe-les-utilisateurs-d-internet-explorer-7.html
Je vais poser la question qui fâche : Dans quels délais aimerais-tu démarrer ton site ?
En fait, c'est plutôt que je cherche à diversifier mon panel de compétences. Donc, pas de délai. J'ai des demandes, éventuellement des besoins pour moi-même. Je suis donc dans la phase étude, recherche d'infos... Donc, tu vois, ça ne fâche pas, j'ai tout le temps !
Après si tu veux tout développer par toi-même il y a la technologie à choisir (PHP / ASP / Ruby / Phyton / etc... Je sais que tu semble avoir déjà choisi PHP mais un tour chez les concurrents pour savoir ne peut faire de mal), un framework ou non (exemple en PHP : Symfony 2 - dont je suis grand fan). De même pour ta base de données, serveur, etc etc ...
Pourquoi ? Car à partir sur du neuf complet autant bien étudié cette question à fond est, à mon avis, nécessaire.
En fait, je ne voudrais pas que ça me prenne trop la tête... Je n'ai pas très envie d'apprendre de nouvelles techno, justement... ou un minimum...
Faudra vraiment un jour que je pense à m'y mettre sérieusement à Ruby on Rails. Faut juste trouver du temps.
Chuttt ! Toi, t'as presque toute une vie
.
Si je peux donner un conseil, c'est de commencer par un bon design d'architecture.
Je ne suis pas un grand spécialiste réseau, mais si je devais pondre un tel système, j'opérerais avec plusieurs serveurs.
Un serveur très sécurisé dans la DMZ, avec le moins de fonctionnalité possible.
Un serveur DB de travail : avec les infos du site (articles, leurs descriptions, leurs prix).
Un serveur DB avec les données utilisateurs, éventuellement avec une couche logicielle qui interdirait l'accès direct à la DB.
J'essaierais aussi d'ajouter des contrôles à divers endroit. Par exemple :
- prix minimum du panier (histoire que si la DB de travail est hackée ou que tu fais une fausse manip dans les prix, tu ne te retrouves pas à vendre ta culotte).
- quantité maximum de produit
- monitoring du nombre de transaction à l'heure (par exemple)
- captcha systématique pour accéder à sa page utilisateur
- mail de confirmation pour changer des données importantes : adresse de livraison
Pour info, l'autre jour, j'ai annulé une commande de sandwich au moment d'entrer le code fourni pas la calculette.
J'ai repassé ma commande 2 minutes plus tard. Résultat : j'ai eu 2 sandwiches pour 1 seul payé.
J'en ai discuté avec le commerçant et il m'a dit avoir oublié de vérifier les commandes interrompues.
Si tu n'es pas pressée, tu attends que swift soit utilisable pour le web.
Mais de toutes façons, le problème du langage côté serveur est un faux problème.
Les technos serveurs sont toutes correctes. Bien sur, Rails est surement mieux que php, mais on arrive à tout faire en php.
Même javascript, j'en suis venu à me dire que c'était un langage correct en regard des deux points noirs que sont
le html/css et le serveur (hard+soft).
HTML+CSS c'est quand même un système de layout où pour pouvoir utiliser une constante, il faut recourir à des librairies externes.
Si t'as quinze div qui sont rouges, ben faut écrire quinze fois rouge dans ton code. Il parait que c'est pas du code, beau métier...
Côté serveur, le problème c'est le serveur justement. Où l'héberger, comment l'administrer. Mutualisé, dédié, virtualisé, installé soi-même (ne pas faire n'importe quoi avec la sécurité, configurer soi-même apache, bien faire les mises à jour, etc).
On est loin du Archive & Submit de Xcode.
S'il y a un secteur de l'ingénierie informatique qui a besoin d'une disruption, c'est bien le web (http, html, css en tête).
Quel enfer quand on vient du monde des apps.
Tu as l'air d'en connaà®tre un rayon, pourtant. Merci pour ta réponse. Pas très rassurante, malgré tout...
Alors, je ne vais peut-être pas déjà y aller... attendre mieux, ça me va bien...