Instances / Sites Web/ Magasins / Vues Magasin: les clés de la décision pour définir la structure d’un projet Magento
Cyril Drouin | 5 août 2009La richesse fonctionnelle et la flexibilité de Magento ne sont plus à prouver. Elles permettent notamment de mettre au point des structures de projets multi sites / multi magasins en cohérence avec une grande variété de cahiers des charges. Revers de la médaille : c’est parfois un véritable casse tête pour se décider à fixer une structure Magento optimale répondant aux contraintes client: combien d’instances Magento? De sites web ? De magasins ? De vues magasin ? Ce découpage devient plus intuitif quand l’on se base sur quelques connaissances et bonnes pratiques énoncées ci-dessous.
La hiérarchisation selon Varien
GWS (Global Website Store) est le petit nom donné par l’éditeur Varien à son système hiérarchique de gestion des données (produits, clients, configurations…) sur différents niveaux.
En résumé :
- Global : fait référence à l’instance Magento dans sa globalité (une installation Magento).
- Website : Les Websites (sites web) sont les ‘parents’ des Stores (magasins). Un site web contient un ou plusieurs magasin(s). Les sites web peuvent être paramétrés pour partager les données client, ou ne partager aucune donnée.
- Store : les stores (magasins) sont les enfants des sites web. Chaque magasin est caractérisé par une catégorie racine, ce qui permet, au sein du même site web, d’avoir plusieurs magasins ayant des structures de catalogues complètement différentes.
- Store View : un magasin a besoin d’un ou plusieurs store views (vues magasin) afin d’être « navigable » en front office. La structure d’un catalogue, d’une vue d’un magasin à une autre du même magasin, sera toujours la même. Cela permet simplement d’avoir des présentations des données différentes. 90% du temps, les vues magasins sont utilisées pour gérer le passage d’une langue à une autre.
Comprendre et gérer la portée des données:
On retrouve GWS dans la gestion de la majeure partie des données des produits, catégories, CMS et configuration. A l’installation d’un projet, toutes les données font référence à une valeur par défaut commune à tous les niveaux hiérarchiques. Mais il est possible de rendre ces valeurs spécifiques à un web site ou store view, le plus souvent grâce aux cases à cocher apparaissant à droite des champs, après la sélection d’une vue magasin dans la liste déroulante correspondant à l’arborescence du projet (en haut à gauche des écrans Backoffice):
Ici pour le nom d’un produit:
Il suffit alors de décocher la case, et d’éditer la valeur du champ pour y mettre une valeur spécifique à une vue magasin ou à un site web.
Vous remarquerez le [STORE VIEW] entre crochet. Il s’agit de la portée des champs. En d’autre terme, [STORE VIEW] signifie « Ce champs peut avoir des valeurs différentes d’une vue magasin à l’autre ».
La portée des données plus en détail:
Ainsi il existe 3 portées distinctes :
- [GLOBAL] signifie que la valeur du champ sera systématiquement commune à tous les sites web, magasins, vues magasin. C’est le cas par exemple du poids d’un article: cela n’a en effet pas de sens que le poids d’un article varie selon le magasin où se trouve l’internaute. La donnée a donc une portée globale.
Il en va de même pour les données d’inventaire : la portée est globale et pour un même SKU (identifiant unique de l’article), il n’est pas possible d’avoir des quantités en stock différentes d’un site web à l’autre, ou d’une vue à une autre.
- [WEBSITE] signifie que la valeur d’un champ peut varier d’un site web à l’autre. En revanche il faut bien comprendre que cette portée signifie qu’au sein d’un même site web, tous les magasins ou vues magasin auront une valeur commune: celle définie au niveau du site web parent.
C’est le cas par exemple pour la classe de TVA d’un produit :
C’est typiquement une donnée qui doit avoir une portée Site Web, car une entreprise peut décider de monter un projet Magento avec 2 sites web contenant les même produits, mais pour un site web il faudrait considérer que le marchand est une filiale basée en France, et un autre site web serait une filiale basée aux USA. Dans ce cas il est possible que la TVA d’un produit ne soit pas la même d’un site à l’autre.
- [STORE VIEW] que nous avons énoncé plus haut : signifie que la donnée peut avoir des valeurs différentes d’une vue magasin à l’autre.
Il n’est en théorie pas possible de changer la portée d’un champ, en tous cas peu recommandé (une modification en base de données est toujours possible pour les irréductibles). Elle est fixée par Magento et contribue à la stabilité du produit de Varien.
Évidemment au moins une exception existe pour confirmer cette règle ! Et pas la moindre : il s’agit de la portée des données de prix des produits. Par défaut la portée d’un prix est global (prix initial, prix spécial, Prix d’achat…).
Il peut être bien utile, pour répondre à un cahier des charges, de savoir les rendre plus flexibles. Cela sera le cas dans le contexte ou une entreprise souhaite exploiter une marque blanche (une marque discount par exemple !), y présenter les même produits que sur son site principal, les administrer depuis le même backoffice, mais gérer des prix différents !
Pour cela rien de plus simple, mais encore faut-il le savoir : rendez vous dans la configuration Magento->Catalogue->Price.
Changer la portée de « Global » à « Site Web », sauvegarder, puis revenez à votre produit :
Il est maintenant possible d’avoir des prix différents d’un site web à l’autre.
Voici maintenant un tableau qui donne un aperçu de la portée de quelques données importantes. Il est loin d’être complet mais pourra s’avérer être une aide non négligeable:
|
Portée : |
Global |
Site Web |
Magasin |
Vue Magasin |
Commentaire |
|
Compte client |
X |
X |
|
|
Au choix : un compte client peut-être global à l’instance Magento, ou limité à un Web Site. Ce choix se fait dans la configuration. |
|
Méthodes de livraison |
|
|
|
X |
|
|
Design |
|
|
|
X |
|
|
Méthodes de paiement |
|
X |
|
X |
La flexibilité dépend des modes de paiement. Exemple pour le module ATOS/Sips : Web Site seulement. |
|
Méthode d’expédition |
|
|
|
X |
|
|
Définition de la catégorie racine |
|
|
X |
|
|
|
Activation d’une catégorie |
|
|
|
X |
|
|
Visibilité d’un article |
|
|
|
X |
|
|
SKU d’un article |
X |
|
|
|
|
|
Poids d’un article |
X |
|
|
|
|
|
Données d’inventaire |
X |
|
|
|
|
|
Prix |
X (défaut) |
X |
|
X |
Dépend de la configuration choisie dans Système/Congiguration/Catalogue/Price. |
|
Images produits |
|
|
|
X |
|
|
Règles de promotions |
|
X |
|
|
|
|
News letter |
|
|
|
X |
|
|
Classe de TVA d’un produit |
|
X |
|
|
|
|
Origine du client pour le calcul de la TVA lorsque le client n’est pas encore connecté à son compte |
|
X |
|
|
|
En résumé…
Les vues magasin sont utilisées pour gérer le multi langue. Le niveau « Magasin » quant à lui, sert à définir des structures de catégories différentes en créant des catégories racines spécifiques. Cela peut être très utile dans le cas où le périmètre des produits vendu est large. Si vous souhaitez par exemple vendre de l’électronique (clés USB, disque durs….) ainsi que du multi média (CD, DVD, …) sur un seul et même site, il peut être judicieux de créer 2 magasins (store). Cela rendra les arbres de catégorie moins encombrants et plus facilement administrables. Si vous devez gérer des prix de produits différents d’une boutique à une autre, des TVA différentes, avoir une séparation des comptes clients, des modes de paiement différents, et des designs différents, alors il parait évident que vous avez besoin de créer plusieurs sites web dans votre structure de projet Magento, plus particulièrement pour les 3 premiers points (prix, comptes client et TVA). Ce serait le cas d’une grande enseigne souhaitant ouvrir un site pour ses clients particuliers, un site pour ses clients professionnels, et un site Discount en marque blanche, tout cela administré depuis le même backoffice. Si vous ne souhaitez toujours pas créer plusieurs websites malgré cela (pour une raison ou pour une autre), charge à vous de trouver des solutions de contournement ou de réaliser des développements spécifiques permettant de répondre à votre besoin – à priori moins optimal (mais chaque projet a ses contraintes…), Magento est assez flexible pour que vous ayez plusieurs scénarios à envisager.
Enfin vous pouvez décider d’installer plusieurs instances Magento si jamais vous avez différentes équipes d’administrateurs (une par site) et que chacune d’elle est indépendante pour gérer son propre catalogue, et ne doit pas voir ce que font les autres. Mais il est à noter que la version entreprise permet maintenant de cloisonner les rôles de manière assez poussée !
Autre raison potentielle de choisir des instances différentes: les contraintes liées à la portée des stocks mentionnée plus haut, ou autre donnée à portée global. Mais notons que par définition, un SKU (Stock Keeping Unit) est un identifiant d’unité en stock !
Conclusion:
Vous avez maintenant en main un outil performant et les connaissances de base pour définir la structure optimale de votre projet. Ne reste plus qu’à faire confiance à Varien, et à votre bon sens!




