PrestaShop Multiboutique : gérer plusieurs boutiques depuis un seul panneau d’administration

Relu en juin 2026, le modèle groupe de boutiques / boutique / URL de boutique et l’écran Paramètres avancés → Multiboutique s’appliquent à PrestaShop 1.7, 8 et 9.

PrestaShop Multiboutique est la fonctionnalité vers laquelle les marchands se tournent quand une boutique devient trois : une vitrine allemande, une vitrine française, une activité de gros. La promesse est séduisante, tout gérer depuis une seule administration, partager un même catalogue produit, se connecter une seule fois. Et dans l’ensemble, elle tient ses promesses. Mais le multiboutique n’est pas un simple sélecteur de langue, ni un moyen de regrouper des activités sans lien entre elles. C’est une partie précise de l’architecture PrestaShop, avec son propre modèle de contexte, ses propres pièges, et une décision structurante (ce que vous partagez et ce que vous séparez) que vous prenez une fois pour toutes, puis avec laquelle vous vivez pendant des années. Ce guide traite de cette architecture et du quotidien de son exploitation. Ce que le back-office vous donne réellement, les endroits où le contexte boutique peut vous piéger, et les cas où le multiboutique n’est tout simplement pas le bon outil.

Ce qu’est réellement le multiboutique, sur le plan structurel

Sous le capot, PrestaShop Multiboutique repose sur trois niveaux imbriqués. Les comprendre fait toute la différence entre une administration maîtrisée et des dégâts accidentels sur plusieurs boutiques :

• Groupes de boutiques (la table shop_group, id_shop_group). Un groupe définit la frontière du partage. Les clients, commandes, quantités disponibles et paniers peuvent être partagés au sein d’un groupe, mais jamais entre plusieurs groupes. Si deux boutiques doivent partager une même connexion client, elles doivent appartenir au même groupe.
• Boutiques (la table shop, id_shop). La vitrine individuelle, son propre thème, sa propre sélection de catalogue, ses propres valeurs de configuration.
• URL de boutique (la table shop_url). Chaque boutique est accessible via une ou plusieurs combinaisons domaine/URI physique, myshop.de, myshop.fr ou shop.example.com/de. C’est ce qui associe une requête entrante à la bonne boutique.

Vous activez l’ensemble du système dans Paramètres avancés → Multiboutique (dans les anciennes installations 1.6, l’option se trouvait sous Préférences → Général → Activer le multiboutique). Une fois activé, presque chaque page du back-office affiche un sélecteur de contexte boutique en haut à gauche. Ce sélecteur est le contrôle le plus important d’une installation multiboutique : il détermine si la modification que vous vous apprêtez à enregistrer s’applique à Toutes les boutiques, à un groupe de boutiques ou à une boutique unique.

Le modèle partagé ou surchargé

Le modèle de partage n’est pas un mécanisme unique et universel, il fonctionne différemment pour les entités du catalogue et pour la configuration, et cette distinction compte. Pour les données de catalogue comme les produits, les catégories et les transporteurs, PrestaShop conserve un enregistrement de base et ajoute une table d’association par boutique, product_shop, category_shop, carrier_shop, etc., qui permet à une boutique donnée de surcharger certains champs (pour un produit, par exemple le prix, l’état actif, la redirection, voire le nom) tout en héritant du reste. Vous gérez donc réellement un seul produit, mais son prix dans la boutique française et sa visibilité dans la boutique de gros peuvent différer. Les paramètres, eux, ne sont pas des lignes associées : ils vivent dans la table configuration avec une portée boutique et groupe de boutiques. Une valeur peut donc être définie globalement, par groupe ou par boutique. Cette couche de surcharges est le vrai avantage du multiboutique par rapport à des installations séparées : modifier une seule fois, puis faire varier volontairement.

Quand le multiboutique est le bon outil

Boutiques par pays sur des domaines différents

C’est le cas d’usage le plus propre. myshop.de, myshop.fr et myshop.es comme trois boutiques dans un même groupe, partageant produits et clients, chacune avec son propre thème, sa devise par défaut, sa langue par défaut et ses règles de taxe. Le stock est partagé, ce qui vous évite de réconcilier trois inventaires. C’est le multiboutique exactement comme il a été conçu, avec une limite nette : le multiboutique gère les vitrines, mais ne vous donne pas à lui seul des devises correctement localisées, un affichage TTC par pays ou du hreflang. Ce sont des sujets distincts, traités dans vendre en Europe : langues, devises et taxes et les balises hreflang.

Marques premium et économiques, un seul entrepôt

Les mêmes produits physiques, deux vitrines avec des noms, thèmes et niveaux de prix différents, puisant dans un stock commun. La surcharge de prix par boutique et le nom de produit par boutique transforment ce qui serait un catalogue dupliqué en quelques clics de configuration.

B2B et B2C côte à côte

Une boutique de détail affichant des prix TTC et une boutique de gros affichant des prix nets, des quantités minimales de commande et le paiement sur facture : toutes deux sur la même base de données produits. Les groupes clients, associés à une deuxième boutique dans le même groupe, vous donnent un stock partagé avec des règles commerciales complètement différentes.

Plusieurs boutiques de niche avec un recouvrement partiel du catalogue

Des boutiques jardin, cuisine et salle de bain qui partagent une partie du catalogue, mais gardent une identité de marque distincte. Ce recouvrement est ce qui justifie le multiboutique ; les produits partagés méritent leur place chaque fois qu’une mise à jour se propage.

Quand le multiboutique n’est pas le bon outil

Vous voulez seulement plus de langues

C’est l’erreur la plus fréquente. PrestaShop est multilingue dans une seule boutique, chaque champ traduisible (nom du produit, description, CMS, meta) est stocké par langue dans les tables _lang, et vous ajoutez les langues dans International → Localisation → Langues. Si tout ce dont vous avez besoin est une version anglaise et une version française au même prix, le multiboutique ajoute une gestion de contexte inutile. Faites-le de manière standard, voir configuration d’une boutique multilingue.

Les boutiques n’ont vraiment aucun lien entre elles

Alimentation pour animaux et électronique, aucun produit partagé, aucun client partagé, aucune opération commune. Ici, le multiboutique vous impose une taxe de complexité sans aucun bénéfice de partage. Deux installations séparées sont plus faciles à comprendre, plus faciles à sauvegarder indépendamment, et impossibles à contaminer entre elles par une modification faite dans le mauvais contexte. Le multiboutique se justifie par le recouvrement ; sans recouvrement, ce n’est que de la surcharge.

Une seule personne, déjà débordée

Chaque modification en multiboutique pose la question : « dans quel contexte suis-je ? » Un opérateur seul qui oublie une fois le sélecteur peut pousser un prix ou un statut désactivé sur toutes les boutiques. Si l’équipe est petite et que la discipline n’est pas encore installée, la charge mentale peut coûter plus cher que des installations séparées.

Le contexte boutique : là où le multiboutique vous rattrape vraiment

Le sélecteur de contexte n’est pas un confort. C’est une portée active qui change ce que fait votre bouton d’enregistrement :

[SCREENSHOT: menu déroulant du sélecteur de contexte boutique en haut à gauche du back-office, ouvert, affichant "Toutes les boutiques", un groupe de boutiques et des boutiques individuelles comme portée sélectionnable]

Contexte	Ce que fait un enregistrement	À utiliser pour
Toutes les boutiques	Écrit la valeur dans toutes les boutiques à la fois (et définit l’enregistrement partagé/par défaut)	Un changement réellement global, une nouvelle règle de taxe pour toutes les boutiques, un paramètre que vous voulez partout
Groupe de boutiques	S’applique à toutes les boutiques de ce groupe	Des paramètres qui doivent être identiques dans un même ensemble de marchés, mais pas ailleurs
Boutique unique	Écrit une surcharge propre à la boutique ; les autres boutiques conservent leur valeur	Le prix français, le thème allemand, la page d’accueil d’une seule boutique

Sur les pages produit, catégorie et configuration en contexte boutique unique, vous verrez une petite case à cocher à côté de nombreux champs, c’est l’interrupteur de surcharge. Cochez-la et le champ se détache de la valeur partagée pour cette boutique seulement. Laissez-la décochée et la boutique hérite. La règle pratique que nous appliquons : lisez le sélecteur de contexte à voix haute avant de cliquer sur Enregistrer. Modifier en mode « Toutes les boutiques » alors que vous vouliez une seule boutique est l’erreur multiboutique la plus coûteuse, et elle ne génère aucune erreur. PrestaShop fait simplement, en silence, exactement ce que vous lui avez demandé, partout.

Partage des données : la décision que vous prenez une seule fois

Pour chaque type de donnée, vous choisissez partager ou séparer au moment de créer la boutique, et changer d’avis plus tard devient un travail de migration. Les valeurs par défaut honnêtes :

• Produits, généralement partagés. Un catalogue, avec des surcharges par boutique pour le prix, le nom et la visibilité. C’est le gain d’efficacité central.
• Clients et paniers, partagés au sein d’un groupe quand la même personne doit pouvoir se connecter sur plusieurs marchés ; séparés (groupes différents) pour des marques réellement distinctes où une identité commune n’a pas de sens.
• Commandes, elles conservent toujours leur boutique d’origine (chaque commande porte son id_shop). Si le groupe de boutiques est configuré pour partager les commandes, elles peuvent être visibles et partagées au sein de ce groupe ; sinon, une commande reste limitée à sa propre boutique. Dans les deux cas, vous pouvez consulter et traiter les commandes de toutes les boutiques depuis une seule liste Commandes, ce qui est le bénéfice concret d’une préparation centralisée.
• Quantités disponibles (stock). Elles peuvent être partagées au sein d’un groupe de boutiques lorsque l’option « partager les quantités disponibles » du groupe est activée, ce qui rend possibles les scénarios à entrepôt unique ; sinon, le stock reste propre à chaque boutique.
• Catégories et CMS, partageables, mais souvent à séparer : une arborescence produit partagée, avec des pages légales localisées et une page d’accueil propre à chaque pays.

Le problème de compatibilité des modules

C’est le plus grand risque pratique, et il est bien réel. La prise en charge du multiboutique dans un module n’est pas automatique. Le développeur doit la construire. Un module qui ignore le multiboutique va :

• Ignorer le contexte boutique et appliquer chaque changement à toutes les boutiques, parce qu’il lit et écrit la configuration avec Configuration::get() / Configuration::updateValue() sans passer l’identifiant de boutique ni respecter Shop::CONTEXT_SHOP.
• Stocker les paramètres globalement, ce qui vous empêche de donner des valeurs différentes à deux boutiques, la deuxième écrase la première.
• Créer ses propres tables de base de données sans colonne id_shop, ce qui rend ses données inévitablement partagées même quand elles devraient être propres à chaque boutique.
• Fonctionner correctement sur la boutique principale puis casser, ou laisser fuir silencieusement des données, dans n’importe quel autre contexte boutique.

Un module bien conçu lit ses paramètres avec l’identifiant de boutique (Configuration::get('MY_KEY', null, $id_shop_group, $id_shop) via le contexte boutique), ajoute id_shop à ses tables et enregistre ses hooks par boutique. Avant de vous engager dans le multiboutique, auditez tous les modules dont vous dépendez sous cet angle. Consultez la documentation, interrogez directement le développeur et, point non négociable, testez dans une installation de préproduction avec au moins deux boutiques avant de construire l’environnement réel. Découvrir qu’un module critique n’est pas compatible multiboutique après avoir configuré trois boutiques en production est une très mauvaise après-midi.

C’est exactement pour cela que nous construisons nos modules de cette manière. Nos suites de modules sont écrites pour respecter le contexte boutique dès la couche de données : un paramètre modifié sur la boutique française reste sur la boutique française, et les tables du module portent leur id_shop au lieu d’étaler les données sur toutes les boutiques. C’est la différence entre une installation multiboutique fiable et une installation où chaque enregistrement de configuration devient un petit pari, que vous utilisiez la gestion SEO, la facturation ou le contenu en boutique sur plusieurs boutiques. Vérifiez toujours module par module, mais l’intérêt d’acheter auprès d’un développeur qui teste le multiboutique est précisément de ne pas hériter du problème de compatibilité décrit ci-dessus.

Devises, drapeaux et détails de vitrine par boutique

Le multiboutique donne à chaque boutique sa devise par défaut et son propre ensemble de langues activées, mais les éléments visibles côté client, le sélecteur de devise, les drapeaux de langue, la manière dont un visiteur récurrent arrive sur la bonne boutique, relèvent d’un travail de front-office qui repose sur le multiboutique sans être inclus dedans. Bien traiter ces petits détails évite de faire repartir un visiteur international ; nous les couvrons dans sélecteur de devise et drapeaux de langue, ainsi que toute la mécanique des prix en plusieurs devises dans le guide de configuration multidevise.

Conseils pratiques de gestion

• Lisez le sélecteur de contexte avant chaque enregistrement. C’est l’habitude qui évite l’erreur multiboutique la plus coûteuse. Traitez « Toutes les boutiques » comme un paramètre à manier avec prudence.
• Nommez les ressources propres à une boutique avec le nom de la boutique. banner-myshop-de.jpg, pas banner.jpg. Lorsque vous importez des logos et images de thème propres à chaque boutique, le nom du fichier est votre seul rappel du contexte dans lequel vous vous trouvez.
• Testez dans le contexte de chaque boutique. Une retouche de thème qui semble correcte sur la Boutique A peut casser sur la Boutique B avec un thème ou une configuration de module différente. Consultez le front-office réel de chaque boutique après un changement, pas seulement celui de la boutique principale.
• Sauvegardez avant les changements structurels. Une modification faite dans le mauvais contexte peut se propager à toutes les boutiques d’un coup ; une sauvegarde récente de la base de données est votre bouton Annuler.
• Documentez la carte des boutiques. Quelles boutiques sont dans quel groupe, ce qui est partagé ou surchargé, quels modules sont propres à une boutique. Quand quelque chose casse ou qu’une nouvelle personne rejoint l’équipe, c’est le document qui sauve la situation.
• Surveillez le mappage shop_url. Les réglages SSL, le drapeau d’URL principale et l’URI physique/virtuelle par boutique sont faciles à mal configurer et peuvent produire des boucles de redirection ou charger la mauvaise boutique. Vérifiez-les sous Paramètres avancés → Multiboutique → l’URL de chaque boutique.

Considérations de performance

Chaque requête multiboutique porte un filtre boutique, PrestaShop joint les tables d’association _shop et filtre par id_shop sur la plupart des lectures de catalogue et de configuration. Pour deux ou trois boutiques avec des catalogues normaux, cette surcharge est négligeable. Pour plus de dix boutiques avec de gros catalogues, elle devient mesurable, et la solution relève de l’hygiène classique de base de données : assurez-vous que les index existent sur les colonnes id_shop des tables d’association les plus lourdes, gardez vos volumes de catégories et de produits sous contrôle, et appuyez-vous sur le cache pleine page afin que le front-office ne relance pas des requêtes filtrées par boutique à chaque visite. Mesurez sur votre propre installation, activez le multiboutique, puis observez les temps de requête dans le profiler de débogage avant de supposer qu’il y a un problème.

Questions fréquentes

Le multiboutique est-il la bonne façon d’ajouter plus de langues ?

Non, c’est l’erreur la plus fréquente. PrestaShop est multilingue dans une seule boutique : chaque champ traduisible est stocké par langue dans les tables _lang, et vous ajoutez les langues dans International → Localisation → Langues. Si tout ce dont vous avez besoin est le même catalogue aux mêmes prix en anglais et en français, le multiboutique ajoute une gestion de contexte inutile. Utilisez les champs multilingues intégrés, voir configuration d’une boutique multilingue. N’utilisez le multiboutique que lorsque vos marchés nécessitent réellement des catalogues, structures tarifaires ou identités de marque différents.

Quelle est l’erreur multiboutique la plus coûteuse ?

Enregistrer en contexte « Toutes les boutiques » alors que vous visiez une seule boutique. Le sélecteur de contexte (en haut à gauche) est une portée active : en mode « Toutes les boutiques », un enregistrement écrit la valeur dans toutes les boutiques à la fois, sans produire d’erreur. PrestaShop fait simplement, en silence, exactement ce que vous lui avez demandé, partout. L’habitude qui l’évite est simple : lisez le sélecteur de contexte à voix haute avant de cliquer sur Enregistrer, et traitez « Toutes les boutiques » comme un paramètre à manier avec prudence.

Mes boutiques peuvent-elles partager les clients et le stock ?

Au sein d’un groupe de boutiques, oui. Un groupe de boutiques définit la frontière du partage. Les clients, paniers et quantités disponibles peuvent être partagés au sein d’un groupe, mais jamais entre plusieurs groupes. Donc, si deux boutiques doivent partager une connexion client, elles doivent appartenir au même groupe, et le stock partagé (lorsque l’option « partager les quantités disponibles » du groupe est activée) est ce qui rend les scénarios à entrepôt unique possibles. Les commandes conservent toujours l’id_shop de leur boutique d’origine, mais vous pouvez traiter les commandes de toutes les boutiques depuis une seule liste Commandes.

Comment savoir si un module peut être utilisé sans risque sur plusieurs boutiques ?

Vous devez le vérifier, la prise en charge du multiboutique n’est pas automatique, le développeur doit la construire. Un module qui ignore le contexte boutique appliquera chaque changement à toutes les boutiques, stockera les paramètres globalement de sorte que deux boutiques ne puissent pas différer, ou créera des tables sans colonne id_shop, rendant ses données inévitablement partagées. Un module bien conçu lit ses paramètres avec l’identifiant de boutique (Configuration::get('MY_KEY', null, $id_shop_group, $id_shop)), ajoute id_shop à ses tables et enregistre ses hooks par boutique. Testez chaque dépendance dans une installation de préproduction avec au moins deux boutiques avant de construire l’environnement réel. Nos suites de modules sont écrites pour respecter le contexte boutique dès la couche de données, que vous utilisiez la gestion SEO, la facturation ou le contenu en boutique sur plusieurs boutiques.

Le multiboutique gère-t-il pour moi les devises, les taxes et hreflang par pays ?

Non, le multiboutique gère les vitrines. Chaque boutique reçoit sa devise par défaut et son ensemble de langues activées, mais l’affichage de devise correctement localisé, les prix TTC par pays et hreflang sur des domaines séparés sont des sujets distincts qui s’ajoutent par-dessus. Voir vendre en Europe pour les devises et les taxes, et les balises hreflang pour le signal SEO inter-domaines que le cœur de PrestaShop n’assemble pas automatiquement entre boutiques.

Lectures associées

• Configuration d’une boutique multilingue, le bon outil quand vous avez seulement besoin de plus de langues, pas de plus de boutiques.
• Vendre en Europe, la couche devises, taxes et OSS que le multiboutique ne résout pas à lui seul.
• Balises hreflang. La réciprocité entre domaines devient le cas difficile dès que chaque marché possède sa propre boutique.

L’essentiel

Le multiboutique est la bonne réponse lorsque vos boutiques se recouvrent vraiment, produits partagés, clients partagés, stock partagé, et que vous voulez faire varier volontairement la vitrine, les prix et l’identité de marque au-dessus de ce socle commun. C’est la mauvaise réponse pour « j’ai juste besoin de plus de langues » (utilisez les champs multilingues intégrés) et pour des activités réellement séparées (utilisez des installations séparées). Prenez correctement la décision partager ou séparer dès le départ, respectez scrupuleusement le sélecteur de contexte, vérifiez que vos modules sont compatibles multiboutique avant de construire l’ensemble, et le multiboutique transforme l’équivalent de trois administrations en une seule. La discipline de configuration est le prix à payer ; la simplicité opérationnelle au quotidien est ce que vous achetez.

Pour un guide pas à pas de création de votre premier groupe de boutiques et de votre première boutique, consultez notre guide de base de connaissances Comment configurer PrestaShop Multiboutique.