Configuration PrestaShop Multiboutique : Guide complet

Ce qu'est le multiboutique, et ce que cela fait de le gérer au quotidien

Nous utilisons le multiboutique sur mypresta.rocks même : six langues, six boutiques, un seul back office. Notre client wetroomsdesign.co.uk en gère cinq (UK, IT, DE, ES, NL) depuis une seule installation. Ainsi, lorsque nous décrivons le multiboutique sur cette page, nous ne citons pas la documentation, nous décrivons l'outil sur lequel nous nous connectons chaque matin.

Le multiboutique permet à une seule installation PrestaShop d'héberger plusieurs vitrines qui partagent le code, la base de données et l'ensemble des modules, mais affichent des produits, des thèmes, des prix et des URL différents. Cette fonctionnalité fait partie du cœur depuis la version 1.5 et reste réellement exploitable en 8.x et 9.x. C'est aussi la fonctionnalité la plus susceptible d'exposer un module bâclé, dès qu'un élément oublie de filtrer par id_shop, les réglages d'une boutique commencent à se propager dans une autre.

Quand le multiboutique est le bon choix

Plusieurs marques partageant un même entrepôt. Deux vitrines, des thèmes distincts, des produits et un stock partagés, une équipe dans une seule administration.

Déclinaisons par pays d'un même catalogue. Le cas d'usage que nous rencontrons le plus souvent. wetroomsdesign vend les mêmes receveurs de douche dans cinq pays, mêmes produits, prix différents, TVA différente, livraison différente, structure de catégories différente. Le multiboutique permet à chaque boutique de diverger là où elle en a besoin tout en partageant la colonne vertébrale.

B2B aux côtés du B2C. Le commerce de détail voit des prix TTC et une livraison standard. Le grossiste voit des prix nets, des quantités minimales et des transporteurs négociés. Un seul catalogue, deux expériences.

Boutique de déstockage ou d'outlet. Une seconde vitrine avec son propre thème, puisant des articles remisés dans la même base de données produits.

Quand c'est le mauvais choix

• Activités sans rapport. Les fournitures pour animaux et les machines industrielles n'ont rien en commun. Deux installations distinctes sont plus simples en tout point.
• Versions de PrestaShop différentes. Toutes les boutiques d'une même installation utilisent le même cœur. Il est impossible d'en maintenir une en 1.7 pendant qu'une autre passe en 9.
• Modules incompatibles. Si deux boutiques ont réellement besoin de modules en conflit, des installations distinctes évitent une lutte permanente.
• Isolation des risques. Une migration ratée ou une requête incontrôlée touche toutes les boutiques d'un coup. Des installations indépendantes limitent les dégâts.
• Vous avez seulement besoin de plusieurs langues. Une boutique PrestaShop unique gère nativement le contenu multilingue. Il ne faut pas recourir au multiboutique uniquement pour cela.

Avant d'activer le multiboutique, notez ce qui est réellement partagé (produits ? clients ? stock ? configuration ?) et ce qui doit diverger par boutique. Si la liste du « partagé » est courte, deux installations distinctes vous épargneront beaucoup de peine.

Planifier avant de cliquer où que ce soit

Les groupes de boutiques décident de ce qui est partagé, et vous ne pouvez pas facilement les modifier

La hiérarchie est Groupe de boutiques → Boutique. Le groupe contrôle deux réglages pénibles à inverser :

• Partager les clients. Une personne inscrite sur la boutique UK peut-elle se connecter à la boutique italienne avec les mêmes identifiants ? Le B2C transfrontalier veut généralement cette option désactivée ; le multimarque au sein d'une même entreprise la veut généralement activée.
• Partager les quantités disponibles. Une vente sur une boutique fait-elle baisser le stock affiché sur une autre ? Même entrepôt : oui ; inventaire séparé : non.

Réglez ces points correctement dès la première fois. Les modifier après l'apparition des commandes vous laisse avec des comptes clients qui existent dans la table d'une boutique mais pas dans l'autre, et des enregistrements de stock qui divergent de la réalité.

Catalogues partagés ou séparés

Un produit peut être associé à toutes les boutiques ou seulement à certaines. Même partagés, le prix, le nom, la description courte et complète, les images et les métadonnées SEO peuvent tous être propres à chaque boutique. Les catégories fonctionnent de la même manière. C'est ce qui rend le multiboutique digne d'intérêt, un seul enregistrement produit, six vitrines, chacune avec sa propre version des éléments qui font bouger le SEO et la conversion.

Stratégie d'URL

• Domaines distincts (brand-a.com, brand-b.com), ce que nous utilisons pour des marques véritablement séparées. Chacun a besoin de son propre certificat SSL ou d'un certificat multidomaine.
• Sous-domaines (de.shop.com, fr.shop.com), naturels pour des déclinaisons par pays. Un certificat SSL générique les couvre tous. C'est ce qu'utilise mypresta.rocks pour ses six boutiques par langue.
• Sous-répertoires (shop.com/wholesale/), une configuration simple avec un seul certificat SSL.

Une base de données, une sauvegarde, un seul rayon d'impact

Le multiboutique repose sur une base de données unique. Les tables gagnent des colonnes id_shop et PrestaShop filtre selon le contexte. Une seule sauvegarde couvre toutes les boutiques (pratique). Une seule requête défaillante met toutes les boutiques à terre (moins pratique).

Activer la fonctionnalité et ajouter la seconde boutique

Étape 1 : activer la fonctionnalité

Activez le multiboutique dans Paramètres de la boutique → Général, puis gérez les boutiques dans Paramètres avancés → Multiboutique. Un sélecteur de contexte de boutique apparaît dans l'en-tête, à partir de ce moment, c'est l'élément d'interface le plus important du back office.

Planifiez les URL avant d’activer la fonctionnalité.

Cette capture réelle du back office montre l'interrupteur qui fait apparaître la page d'administration Multiboutique. Ne l'activez qu'après avoir décidé de ce qui doit être partagé et de ce qui doit rester propre à chaque boutique.

Étape 2 : créer un groupe de boutiques

Sous Paramètres avancés → Multiboutique, Ajouter un nouveau groupe de boutiques. Nommez-le, choisissez les réglages de partage des clients et de partage du stock. Ces réglages sont difficiles à modifier par la suite.

Étape 3 : ajouter la boutique

Ajouter une nouvelle boutique. Choisissez le nom, le groupe, la catégorie racine et, le cas échéant, importez la structure d'une boutique existante. L'import fait gagner un temps réel lorsque la nouvelle boutique démarre comme une copie. Par exemple, lorsque wetroomsdesign a ajouté l'Espagne après l'Italie, la boutique IT était un point de départ utile.

L'arborescence est votre source de vérité.

Après avoir activé le multiboutique, vérifiez ici la hiérarchie groupe, boutique et URL avant de modifier les produits, les modules ou les thèmes. Si l'arborescence semble incorrecte, corrigez-la avant d'ajouter de vraies données de catalogue.

Étape 4 : configurer les URL

Ouvrez la boutique et ajoutez une ligne d'URL :

# Domaine distinct
Domain: www.my-second-shop.com
Physical URI: /
Virtual URI: (empty)

# Sous-domaine
Domain: shop2.myshop.com
Physical URI: /
Virtual URI: (empty)

# Sous-répertoire
Domain: www.myshop.com
Physical URI: /
Virtual URI: wholesale/

Chaque boutique a besoin d'une URL principale propre.

La liste des URL est l'endroit où vous confirmez le domaine canonique, le domaine SSL, l'URI physique, l'URI virtuelle, l'indicateur d'URL principale et l'état d'activation. La plupart des boucles de redirection commencent par une incohérence sur cet écran.

Étape 5 : configurer le routage du serveur

Pour les domaines distincts et les sous-domaines, chaque domaine doit pointer vers le même répertoire PrestaShop. Sous Apache, le fichier .htaccess s'en charge. Sous Nginx, faites pointer chaque server_name vers le même docroot. Pour les sous-répertoires, PrestaShop gère le routage tout seul via le fichier .htaccess.

Après toute modification d'URL, videz le cache. Le routage des URL est mis en cache de façon agressive, et les entrées périmées sont la cause la plus fréquente de boucles de redirection après l'ajout d'une boutique.

Vivre avec le sélecteur de contexte de boutique

L'habitude la plus importante de toutes

Le menu déroulant en haut du back office décide à quelle boutique vos modifications s'appliquent : Toutes les boutiques, un groupe ou une boutique précise. La règle que nous inculquons à chaque équipe qui reprend une installation multiboutique : travaillez dans le contexte le plus restreint que la modification doit concerner. Modifier dans « Toutes les boutiques » alors que vous visiez une seule boutique est l'erreur multiboutique la plus fréquente que nous corrigeons.

L'héritage de configuration, et la case à cocher qui piège tout le monde

Les valeurs définies dans « Toutes les boutiques » deviennent les valeurs par défaut. Une boutique précise peut redéfinir n'importe quel champ, et une case à cocher à côté de chaque champ détermine si cette boutique utilise la valeur héritée ou la sienne. Le piège : l'état de la case ne signifie pas la même chose selon les versions de PrestaShop. Nous avons vu une configuration « enregistrée » avec succès retomber silencieusement sur le parent parce que la redéfinition n'était pas cochée. Rechargez et vérifiez toujours dans le contexte de la boutique, pas seulement juste après l'enregistrement.

Produits et catégories

• Créés dans « Toutes les boutiques » → disponibles partout.
• Créés dans une boutique précise → limités à cette boutique, vous pourrez les associer à d'autres plus tard.
• Désactiver dans une boutique ne désactive pas dans les autres.
• Supprimer dans « Toutes les boutiques » l'efface de toutes les boutiques définitivement. Il n'y a pas de corbeille.
• Le comportement du stock dépend du réglage « Partager les quantités disponibles » du groupe.

Thème, langue et devise par boutique

Chaque boutique exécute son propre thème, ses propres langues et devises activées. Basculez d'abord dans le contexte de la boutique, puis effectuez les modifications dans Apparence → Thème et logo et International → Localisation. Modifiez les réglages du thème dans le contexte « Toutes les boutiques » et vous écrasez la configuration de thème de chaque boutique en un seul clic.

Comment les modules se comportent, et déraillent

Ce que fait un module bien conçu

Un module qui respecte le multiboutique stocke sa configuration par boutique (Configuration::updateValue(), qui honore le contexte actif, et non Configuration::updateGlobalValue()) et lit Shop::getContextShopID() dans les hooks avant de supposer une boutique unique. La table ps_configuration possède à la fois les colonnes id_shop_group et id_shop, et un module bien écrit les remplit.

La table de configuration a besoin que la portée id_shop_group et id_shop soit renseignée, sinon vous verrez les réglages d'autres boutiques transparaître. Un module qui « prend plus ou moins en charge le multiboutique » signifie généralement qu'il renseigne id_shop mais laisse id_shop_group à NULL, et alors les valeurs disparaissent ou se dupliquent selon le contexte actif.

Les quatre façons dont les modules cassent

• Configuration uniquement globale. Réglages écrits sans id_shop, si bien que modifier une boutique les modifie toutes.
• ID de boutique codé en dur. Quelque part dans les requêtes du module : id_shop = 1 en valeur littérale. La boutique 1 fonctionne, toutes les autres sont vides ou défaillantes.
• Filtre de boutique manquant dans les requêtes. Une requête SQL personnalisée joint ps_product sans filtre de boutique, le front office de la boutique 2 affiche des produits qui n'appartiennent qu'à la boutique 1.
• Collisions de clés de cache. Le module met en cache un bloc rendu sans l'ID de la boutique dans la clé. La boutique A charge et met en cache, la boutique B sert le bloc de la boutique A à ses visiteurs.

Comment évaluer un module avant de l'installer

• La description dit-elle réellement « compatible multiboutique », ou esquive-t-elle la question ?
• Existe-t-il une documentation sur la configuration par boutique ?
• Après installation, la page de configuration affiche-t-elle les cases à cocher d'héritage lorsque vous basculez vers une boutique précise ?
• Le vrai test : définissez des valeurs différentes sur deux boutiques, enregistrez, rechargez, confirmez que les deux fronts reflètent la différence.

Un module qui ignore le multiboutique ne plantera pas forcément, il se contente de partager un seul jeu de réglages entre toutes les boutiques. Pour un identifiant Google Analytics global, c'est acceptable. Pour la livraison, le texte du tunnel de commande ou les transporteurs propres à chaque boutique, c'est un désastre silencieux.

Le SEO sur plusieurs boutiques

URL canoniques

Les pages destinées à rester indexées indépendamment doivent avoir une canonique au sein de leur propre boutique. Un produit sur shop-a.com ne doit pointer vers shop-b.com que si vous choisissez délibérément d’y consolider le contenu dupliqué. Si vous diffusez un contenu quasi identique sur plusieurs boutiques, choisissez une source principale et mettez en place des canoniques inter-domaines de façon délibérée ; Product Canonical Manager est la voie la plus sûre lorsque les canoniques produit nécessitent un contrôle par boutique. Ne laissez pas Google deviner.

Le hreflang pour les boutiques multilingues

Si vos boutiques ciblent des langues et des régions différentes, les balises hreflang indiquent aux moteurs de recherche quelle version servir à quel public :

<link rel="alternate" hreflang="de" href="https://de.myshop.com/produkt" />
<link rel="alternate" hreflang="fr" href="https://fr.myshop.com/produit" />
<link rel="alternate" hreflang="x-default" href="https://www.myshop.com/product" />

La lacune que PrestaShop ne comble pas : le cœur gère le hreflang entre les langues au sein d'une boutique, mais pas d'une boutique à l'autre. Pour un hreflang multiboutique, vous aurez besoin d'un module tel que Hreflang Tags Manager, de modifications du thème ou de balises écrites à la main. Les balises doivent aussi être bidirectionnelles, si la boutique A référence la boutique B, la boutique B doit référencer la boutique A en retour, sinon Google ignore l'ensemble.

Plans de site et contenu dupliqué

Chaque boutique a besoin de son propre sitemap.xml contenant uniquement ses propres URL. Enregistrez chaque boutique séparément dans Google Search Console ; pour les grands catalogues multiboutiques, Advanced SEO Sitemap Builder vous offre un contrôle des plans de site par boutique sans maintenir les fichiers à la main. Pour gérer le contenu dupliqué lorsque les boutiques partagent des produits : rédigez des descriptions par boutique pour au moins vos meilleures ventes, posez les balises canoniques de façon délibérée et réécrivez les introductions des pages de catégories afin qu'elles ne soient pas des chaînes identiques sur cinq domaines.

Pour des boutiques multilingues sur des domaines distincts, le hreflang n'est pas optionnel. Sans lui, Google indexe régulièrement la mauvaise langue pour chaque marché et le trafic organique chute sans cause évidente.

Ce que le multiboutique coûte en performance

Trois domaines en pâtissent :

• Les tables de configuration grossissent. N lignes par réglage (une par boutique), et non une seule. Chaque consultation de configuration lit davantage de données.
• Chaque requête gagne un filtre de boutique. Presque chaque requête SQL reçoit une clause WHERE id_shop = X. Sans les bons index, cela ralentit à mesure que la base grossit.
• L'empreinte du cache se multiplie. Chaque boutique a ses propres entrées de cache pour les templates, les configurations et les listes. La mémoire évolue avec le nombre de boutiques.

Sur Redis ou Memcached, vérifiez bien que les préfixes de clés de cache incluent l'ID de la boutique. Nous avons hérité d'installations où ce n'était pas le cas, et les visiteurs de la boutique B voyaient les blocs de la boutique A pendant toute la durée de vie de l'entrée de cache.

# Vérifier la taille des tables
SELECT table_name, ROUND(data_length/1024/1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'prestashop'
ORDER BY data_length DESC LIMIT 20;

# Repérer les index manquants sur les colonnes id_shop
SELECT t.table_name, c.column_name
FROM information_schema.columns c
JOIN information_schema.tables t
  ON c.table_schema = t.table_schema AND c.table_name = t.table_name
WHERE c.table_schema = 'prestashop' AND c.column_name = 'id_shop'
  AND c.column_name NOT IN (
    SELECT column_name FROM information_schema.statistics
    WHERE table_schema = 'prestashop' AND table_name = c.table_name
  );

Les problèmes que vous rencontrerez vraiment

Un produit apparaît dans la mauvaise boutique

Cause : créé dans le contexte « Toutes les boutiques », ou mal associé lors d'une édition en masse. Correction : basculez dans le contexte de la boutique indésirable et retirez l'association. Vérifiez dans la base de données :

SELECT ps.id_product, ps.id_shop, ps.active
FROM ps_product_shop ps WHERE ps.id_product = 123;

Une modification de configuration affecte toutes les boutiques

Soit le sélecteur était sur « Toutes les boutiques » au moment de l'enregistrement, soit le module stocke de façon globale. Vérifiez :

SELECT id_shop, name, value FROM ps_configuration
WHERE name = 'MODULE_SETTING_NAME' ORDER BY id_shop;

Si vous ne voyez qu'une seule ligne avec id_shop = 0 ou NULL, le module stocke de façon globale quel que soit le contexte. C'est un bug du module, corrigez-le pour qu'il appelle Configuration::updateValue() avec l'ID de la boutique, ou insérez les lignes par boutique manuellement.

Le module n'enregistre pas les réglages par boutique

Presque toujours Configuration::updateGlobalValue() là où Configuration::updateValue() devrait être. Correction de code dans le module ou mise à jour de l'éditeur, aucun contournement possible depuis le back office.

Le panier déborde d'une boutique à l'autre

Domaine du cookie défini de façon trop large. Si le cookie est limité à .myshop.com, un panier sur shop-a.myshop.com est visible par shop-b.myshop.com. Correction par boutique dans Paramètres de la boutique → Général : limitez le cookie au sous-domaine précis.

L'import CSV atterrit dans la mauvaise boutique

L'outil d'import respecte le contexte actif. Basculez dans la boutique cible avant d'ouvrir la page d'import, pas après. Vérifiez ensuite que ps_product_shop contient les lignes attendues, corriger à la main de mauvaises associations sur des milliers de produits, c'est une longue soirée.

Boucles de redirection après l'ajout d'une boutique

Soit la configuration d'URL est incorrecte, soit le fichier .htaccess est périmé. Régénérez le .htaccess depuis Paramètres avancés → Performances, puis vérifiez que ps_shop_url correspond à la réalité :

SELECT s.name, su.domain, su.domain_ssl, su.physical_uri, su.virtual_uri
FROM ps_shop s
JOIN ps_shop_url su ON s.id_shop = su.id_shop AND su.main = 1;

Le SSL doit aussi être cohérent, un domain_ssl pointant vers un hôte non-SSL alors que le client arrive en https:// est une source classique de boucles.

Routine de maintenance

Chaque semaine

• Chargez la vitrine de chaque boutique. Aucune redirection, aucune erreur, le bon thème.
• Vérifiez que les commandes récentes sont bien associées au bon ID de boutique.
• Effectuez un tunnel de commande de test sur chaque boutique.

Chaque mois

• Auditez les associations de produits : y a-t-il quelque chose dans une boutique où il ne devrait pas être ?
• Parcourez le contexte de chaque boutique et contrôlez par sondage les pages de configuration des modules.
• Lisez les journaux d'erreurs par boutique, pas seulement globalement.
• Confirmez que les plans de site sont à jour et renvoient des codes 200.
• Envoyez un e-mail de test depuis chaque boutique et vérifiez le domaine de l'expéditeur.

Après une mise à jour de module

• Ouvrez la page de configuration du module dans le contexte de chaque boutique et vérifiez qu'elle enregistre toujours de façon indépendante.
• Testez le comportement côté front par boutique, pas seulement sur la boutique 1.
• Videz les caches de chaque boutique.

Après une mise à jour du cœur PrestaShop

• Testez chaque boutique immédiatement. Les régressions multiboutiques sont fréquentes, l'équipe du cœur teste surtout sur des installations à boutique unique.
• Revérifiez ps_shop_url.
• Régénérez le .htaccess.
• Effectuez un tunnel de commande complet sur chaque boutique, pour chaque moyen de paiement.

Pour aller plus loin

• Checkout Revolution : un tunnel de commande prêt pour le multiboutique avec configuration par boutique
• Performance Revolution : une mise en cache par boutique qui respecte le contexte de la boutique
• Guide d'optimisation des performances : le panorama plus large des performances, qui compte encore plus en multiboutique
• Guide de l'hébergement PrestaShop : les besoins d'hébergement évoluent avec le nombre de boutiques
• Sauvegarde et reprise après sinistre PrestaShop : la stratégie de sauvegarde lorsqu'une seule base de données contient toutes les boutiques
• Conformité RGPD pour les boutiques PrestaShop : les obligations RGPD sur plusieurs vitrines

Questions liées

• Puis-je ajouter des règles hreflang et noindex aux pages PrestaShop ?
• Les balises hreflang corrigeront-elles mes problèmes SEO multilingues ?
• La configuration de mon module ne s'enregistre pas.