Export GF4 - Dployer Et Configurer Une Boutique en Ligne 2019-02-22 1105 PDF

GF4 - Déployer et configurer une boutique en ligne
Apprendre à déployer une boutique en ligne et à en configurer les principaux

paramètres. Prestashop sera utilisé pour la démonstration.
Last modified by Sébastien Choplin on mercredi 24 octobre 2018, 13:14

This document was downloaded on vendredi 22 février 2019, 11:05
PDF EXPORT TEST EMIAGE PDF EXPORT TEST EMIAGE PDF EXPORT TEST EMIAGE
Introduction
Une fois le cahier des charges établi par l'équipe marketing et son appropriation faite par l'équipe
technique, l'étude technique doit permettre de choisir une ou plusieurs solutions qui prennent en
compte les moyens (financiers et humains) disponibles ou à apporter pour l'installation de la
solution, se mise en production et son fonctionnement.
Choix de la solution
La solution doit être adaptée aux besoins du cahier des charges, il est souhaitable que celui-ci
tienne compte des potentielles évolutions qui pourraient influencer le choix.
A COMPLETER
Mise en oeuvre de la solution
Une boutique en ligne nécessite au minimum:
un logiciel permettant au vendeur de gérer ses produits, traiter les commandes (back-
office)
un logiciel permettant de mettre en oeuvre la partie visible par les visiteurs/clients (front-
office) pour :
présenter les produits,

gérer les comptes des clients
une base de données pour stocker les informations de la boutique (produits,
commandes, comptes clients, ...)
Le boutique devant être "en-ligne", il faut donc qu'elle puisse être accéder à une URL et donc que
le logiciel soit interfacé avec un serveur web (à moins qu'il ne l'embarque directement).
De même pour la gestion de la base de données, il sera intefacé avec un SGBD (à moins qu'il ne
l'embarque directement).
Note: Un des intérêts d'utiliser une boutique en ligne en SAAS est de ne pas avoir à deployer
l'application ni tous les logiciels indispensables à son fonctionnement (serveur web, SGBD).
Exemple: Magento (écrit en langage PHP), nécessite d'être accompagné d'un serveur web Apache
ou Nginx avec un moteur PHP et du SGBD MySQL.
Bonnes pratiques
SSL
L'utilisation du protocole HTTP chiffré (https) est devenu incontournable, cela permet de chiffrer
tous les échanges de données et s'il n'est pas utilisé les navigateurs moderne signale une alerte,
ce qui aura un effet extrêment négatif sur le visiteur du site.
L'utilisateur du protocole HTTPs passe par la mise en place d'un certificat (chiffrement
asymetrique) qui permet :
de prouver aux visiteurs que le site qu'ils consultent est bien le votre (pour cela le
navigateur du visiteur va demander à une autorité de certifcation la partie publique de votre
clef qui lui aura été communiqué lors de le création du certificat)
d'effectuer un échange de clefs symétrique de manière crypter pour que la suite des
échanges soit chiffrée.
Déployer une boutique en ligne en local pour tester
Pour tester le déploiement d'une solution, la première chose à faire peut être de l'installer 'en local':
sur sa machine ou une machine
Prenons l'exemple de la solution prestashop:
Marche à suivre
installer un serveur web (Apache ou Nginx) avec PHP et s'assurer qu'il fonctionne:
vérifier que le serveur "écoute" bien:
ici le serveur Apache "écoute" sur le port 8989, un fichier test.html contenant juste
"ça marche" a été placé à la racine du serveur pour vérifier que ça fonctionne
correctement
vérifier que PHP est installé, avec un fichier simple contenant <?php echo "ok pour
php"; ?>
vérifier que les fonctionnalités de PHP requises sont bien présentes en affichant les
informations de configuration avec la fonction "phpinfo": <?php phpinfo(); ?>"
installer un SGBD (MySQL)
Note: sous Windows, l'utilisaton de WampServer permet d'installer l'ensemble
facilement.
récupérer l'archive de l'application et la déployer dans un dossier de la racine du

serveur web (par exemple /var/www/prestashop)
/var/www/prestashop# unzip ~/Téléchargements/prestashop_1.7.2.1.zip

Archive: ~/Téléchargements/prestashop_1.7.2.1.zip
inflating: index.php
inflating: Install_PrestaShop.html
inflating: prestashop.zip
Note: suivant le système d'exploitation et l'emplacement où vous déployez la solution, il vous

faudra probablement les droits "administrateur".
Note: l'utilisateur exécutant le process du serveur web ayant en général des droits restreint, il est
indispensable qu'il ai le droit d'écrire dans le dossier d'installation.
Par exemple sous linux/unix/..: chown -R www-data
/var/www/prestashop (affectera la propriété du dossier et tous ses sous-dossier à
l'utilisateur www-data)
L'installation se poursuit ensuite via le serveur web en accédant à l'URL pointant sur 'index.php':
Il suffit ensuite de suivre les instructions pour poursuivre l'installation qui vérifiera si les
fonctionnalités nécessaires sont présentes.
Les informations importantes à compléter sont:
le nom de la boutique
les informations du compte d’administration de la boutique
et les paramètres d'accès à la base de données:
vous pourrez y vérifier la bonne communication avec avec le SGBD ainsi que la présence de la
base de données.
Si elle n'est pas présente et que l'utilisateur renseigné a le droit de créer des bases, elle peut être
créée par le programme d'installation, sinon il faut utiliser le logiciel du SGBD pour créer la base.
L'installation terminée il vous est juste demandé de supprimer le dossier d'installation 'install'.
Le front-office est maintenant accessible, un jeu de produits de démonstration est
automatiquement installé:
screensshot-frontoffice.png
Le back-office est accessible via une URL générée pour éviter d'être trop facilement devinée par
un tiers (dossier admin773jzp8jd par
exemple): http://localhost:8989/admin773jzp8jd/
Si vous êtes arrivé jusqu'ici alors félicitations, vous avez réussi à déployer votre boutique e-
Commerce sur votre ordinateur, les actions suivantes sont quasiment de l'ordre de la
configuration dans le backoffice.
Configuration d'une boutique en ligne - la boutique
Apparence
Dans la plupart des applications web, la manière dont est construit l'ensemble des éléments des
pages web (HTML, CSS, ...) est décrit dans des "thèmes". Cela concerne donc le rendu visuel (de
préférence 'responsive') mais aussi l'organisation du DOM HTML (qui sera parcouru par les
moteur de recherche pour l'indexation par exemple).
Dans le cas d'une solution permettant le "multi-boutique", chaque boutique doit pouvoir posséder
son propre thème (prestashop, magento, ...)
La gestion des thèmes dans le backoffice est en général très simple (Prestashop: Menu
Personnaliser > Apparence > Thème et logo > Ajouter un thème) et on trouve des bibliothèques de
thèmes (souvent payants) qui sont remodifiables en général.
Exemple dans Prestashop après application du thème "nature" fourni par https://www.arnaud-
merigeau.fr/10-themes-prestashop-1-7-gratuits-et-responsive/ :
La structure d'un thème est propre à chaque solution (par exemple: il n'est pas possible d'utiliser
un thème Prestashop dans Magento)
Les thèmes sont en général modifiables (à contrôler dans la licence du thème si elle existe) et il
est souvent simple d'y apporter quelques modifications (retoucher le CSS, adapter les fichiers de
"template", ...)
Systèmes de paiement
Les systèmes de paiement "simples" (chèque, virement, espèce) sont en général intégré dans
l'outil car ils n'ont pas de dépendance particulière.
Pour les autres systèmes il suffit en général d'installer un plugin/module fourni par l'organisme
de paiement ou un tiers.
Si aucun plugin/module n'existe il faut alors le développer soi-même, ce qui peut vite être
complexe.
Modes de paiements par défaut dans Prestashop:
Dans tous les cas il convient d'effectuer des tests, les prestataires de paiement proposent des
environnements de tests avec des identifiants de paiement utilisable en mode 'test'.
Exemple:
plateforme de test de paybox

: http://www1.paybox.com/espace-integrateur-documentation/la-plateforme-de-tests/
Une fois le mode de paiement installé, il faut le configurer (par exemple indiquer vos identifiants
auprès du système de paiement pour réceptionner les paiements des clients)
Gestion des utilisateurs backoffice
Sur l'ensemble du process de vente, il y a plusieurs acteurs au sein de l'entreprise:
validateur de commandes
préparateur de commandes
intervenant du SAV
commercial
...
Chacun de ces acteurs a besoin d'outil spécifique à sa mission et d'accès aux données limitées à
ses besoins.
Il faut donc bien identifier ces rôles et que le système permette une présentation de l'information et
des restrictions d'accès adéquates.
Exemple dans Prestashop des rôles définis par défaut avec quelques droits associés:
On constate rapidement que cette configuration par défaut est impérativement à modifier, par
exemple ici le rôle "Vendeur" a la possibilité de modifier les produits du catalogues.
WEB
HTTPs/HTTP
en général on peut définir si le site est fournis via HTTP ou HTTPs. Une utilisation en production
doit être en HTTPs
réécriture d'URL
Cela permet une définition des URL basées sur un éléments textuel des produits,
categories ou autre, donc un affichage plus convivial et (surtout) un élément important du
référencement (SEO) des pages. Exemple:
http://www.maboutique.com/index.php?id_product=2&id_product_attribute=7&rewrite=che
misier&controller=product#/1-taille-s/11-couleur-noir
versus
http://www.maboutique.com/blouses/2-7-chemisier.html#/1-taille-s/11-couleur-noir
redirections (301 / 302)

Lorsqu'un produit ou une catégorie est supprimé, l'URL correspondante doit pouvoir fournir
une information pertinente de redirection pour
ne pas faire arriver sur une page d'erreur (404) un visiteur venu par un lien disposé
sur un autre site
conserver le bénéfice du référencement de la page supprimée (peut être au profit
Lorsqu'un
du produit est
qui modifié
le remplace
et que
parceexemple)
qui a été modifié servait à définir l'URL réécrite:
https://www.maboutique.com/produits/chemise-vert.html =>
https://www.maboutique.com/produits/chemise-verte.html
Il faut que l'accès à l'ancienne URL renvoie sur la nouvelle (avec code HTTP 301 -
redirection permanente)
ou alors que l'ancienne URL soit conservée, ce qui n'est pas forcément souhaitable
(correction orthographique par exemple) (Fonctionnalité "Forcer la mise à jour des URL
simplifiées" dans Prestashop)
Logs
Les logs sont des informations journalisées permettant de stocker des informations sur ce qui se
passe.
L'application doit pouvoir fournir des logs pour
identifier les problèmes de configuration

tracer les actions faites, il est impératif de consulter les logs de l'application (et/ou du
serveur web le cas échéant) pour s'assurer qu'aucun problème n'est signalé.
Exemple de logs dans Prestashop:
Comme dans tout système de 'logs' un niveau de priorité doit être défini pour permettre différents
niveaux de lecture. Exemple dans Prestashop:
Des logs applicatifs peuvent aussi être remontées sur le système (par exemple pour Prestashop
tournant sur Apache, les logs de Apache peuvent apporter des informations importante sur
d'éventuels problèmes)
Beaucoup d'autres éléments sont paramétrables (et doivent être paramétrés), par exemple
Modes de livraison
Emails dans le flux de commande
Contenus des différents emails envoyés
Choix des modes de notifications
Possibilité de commander sans avoir de compte client
Ecriture des CGV/CGU
Gestions de stock
...
Configuration d'une boutique en ligne - derrière la boutique
WEB
HTTPs/HTTP
en général on peut définir si le site est fournis via HTTP ou HTTPs. Une utilisation en production
doit être en HTTPs
réécriture d'URL
Cela permet une définition des URL basées sur un éléments textuel des produits,
categories ou autre, donc un affichage plus convivial et (surtout) un élément important du
référencement (SEO) des pages. Exemple:
http://www.maboutique.com/index.php?id_product=2&id_product_attribute=7&rewrite=che
misier&controller=product#/1-taille-s/11-couleur-noir
versus
http://www.maboutique.com/blouses/2-7-chemisier.html#/1-taille-s/11-couleur-noir
redirections (301 / 302)

Lorsqu'un produit ou une catégorie est supprimé, l'URL correspondante doit pouvoir fournir
une information pertinente de redirection pour
ne pas faire arriver sur une page d'erreur (404) un visiteur venu par un lien disposé
sur un autre site
conserver le bénéfice du référencement de la page supprimée (peut être au profit
Lorsqu'undu produit est
qui modifié
le remplace
et que
parceexemple)
qui a été modifié servait à définir l'URL réécrite:
https://www.maboutique.com/produits/chemise-vert.html =>
https://www.maboutique.com/produits/chemise-verte.html
Il faut que l'accès à l'ancienne URL renvoie sur la nouvelle (avec code HTTP 301 -
redirection permanente)
ou alors que l'ancienne URL soit conservée, ce qui n'est pas forcément souhaitable
(correction orthographique par exemple) (Fonctionnalité "Forcer la mise à jour des URL
simplifiées" dans Prestashop)
Performances
La rapidité d'exécution et de livraison des pages web au client est très importante. Un site lent est
très souvent facteur de déception et donc de baisse du taux de conversion (ventes par rapport aux
visites).
De plus les moteurs de recherche, comme Google, ayant pour objectif de faire remonter dans les
recherches des sites qui satisferont les utilisateurs auront tendance à pénaliser les sites 'lents'
dans leur classement.
Plusieurs étapes sont importantes:
interprétation de la requête
génération du contenu à fournir
transmission du contenu
interprétation par le navigateur de l'utilisateur du contenu reçu
Pour optimiser la "rapidité du site" il faut donc comprendre le fonctionnement de chacune de ces
étapes pour identifier les "goulots d'etranlement".
Temps passé côté serveur
L'utilisation de "cache" permet d'éviter de recalculer trop souvent le même contenu. Il doit
permettre d'identifier si du contenu est modifié pour se "rafraîchir" automatiquement.
Suivant les systèmes utilisés, des données peuvent être systématiquement "interprétées" (fichier
de template, fichier de configuration, ...); une étape de compilation/précompilation/... permettant
une mobilisation plus rapide de l'information peut permettre un gain important.
Bien entendu la base de données doit être correctement indexée.
Les logs permettent de tracer ce qui se passe mais à un niveau trop fin (debug par exemple), ils
sont consommateurs de beaucoup de ressource et souvent d'accès disques important. Il faut donc
limiter leur usage trop fin en production.
Temps passé entre le serveur et le client
L’instanciation de connexion HTTP est coûteuse en temps, si le contenu HTML fait référence à de
nombres autres documents (feuilles de styles, fichiers javascript, images, ...) cela peut engendrer
un nombre de connexion à établir important (même en réutilisation de connexion ouverte). Il faut
donc les limiter :
en agrégeant les fichiers css ensemble (ou en les incluant dans le HTML, mais on perd tout
l'intérêt de la feuille de style externe)
en agrégeant les fichiers javascript ensemble
en limitant le volume des images (par exemple une image jpeg s'optimise facilement pour
un affichage web)
en indiquant au navigateur du client qu'il peut mettre lui même certaines ressources en
cache (par exemple le fichier css, inutile de le charger au chargement de chaque page)
en envoyé un contenu compressé (augmente le temps de calcul mais diminue le temps de
transfert)
Temps passé côté client
La principale problématique côté client est de charger tous les contenus utiles, de les interpréter et
les afficher.
Le premier élément est le document HTML qui donnera l'ensemble des autres éléments (CSS,
javascript, images, ...). Le rendu par le navigateur nécessite l'obtention du CSS pour savoir
comment donner l'affichage. Le navigateur prend les ressources dans l'ordre donné, donc s'il est
indiqué de charge du javascript avant le CSS, l'affichage sera inutilement retarder. Il faut donc :
limiter le nombre de ressources CSS (agrégation) et faire en sorte qu'ils soient chargés en premier
(javascript après ou en chargement asynchrone)
Il faut aussi avoir une manipulation du DOM de manière dynamique aussi simple que possible pour
éviter d'avoir trop d'actions d'agencement une fois la page affichée.
Logs
En dehors des logs de l'application, il faut surveiller les logs du système ou de l'application qui est
"au-dessus" de la boutique (serveur apache+php par exemple)
Interactions avec une boutique en ligne
A COMPLETER:
import/export fichiers csv/xls

sql direct (à éviter)
webservice
Powered by TCPDF (www.tcpdf.org)

Export GF4 - Dployer Et Configurer Une Boutique en Ligne 2019-02-22 1105 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Export GF4 - Dployer Et Configurer Une Boutique en Ligne 2019-02-22 1105 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

GF4 - Déployer et configurer une boutique en ligne

Apprendre à déployer une boutique en ligne et à en configurer les principaux

Last modified by Sébastien Choplin on mercredi 24 octobre 2018, 13:14

Mise en oeuvre de la solution

Une boutique en ligne nécessite au minimum:

présenter les produits,

Prenons l'exemple de la solution prestashop:

récupérer l'archive de l'application et la déployer dans un dossier de la racine du

/var/www/prestashop# unzip ~/Téléchargements/prestashop_1.7.2.1.zip

Note: suivant le système d'exploitation et l'emplacement où vous déployez la solution, il vous

Les informations importantes à compléter sont:

Modes de paiements par défaut dans Prestashop:

plateforme de test de paybox

Gestion des utilisateurs backoffice

Sur l'ensemble du process de vente, il y a plusieurs acteurs au sein de l'entreprise:

redirections (301 / 302)

identifier les problèmes de configuration

Exemple de logs dans Prestashop:

redirections (301 / 302)

Plusieurs étapes sont importantes:

Temps passé côté serveur

Bien entendu la base de données doit être correctement indexée.

Temps passé entre le serveur et le client

Temps passé côté client

import/export fichiers csv/xls

Powered by TCPDF (www.tcpdf.org)

Das könnte Ihnen auch gefallen