Multi-boutique PrestaShop sur un même serveur : méthode fiable et scalable

Une multi-boutique mal cadrée peut transformer un simple déploiement en incident récurrent.

Dans ce guide, vous allez poser une architecture propre pour héberger plusieurs boutiques PrestaShop sur un même serveur (domaines, vhosts, bases, médias), puis activer la multi-boutique sans casser le backoffice, les modules, les cookies, ni les performances.

Si vous traitez aussi des cas avancés (stack, cache, exploitation), parcourez notre page PrestaShop pour une offre d’hébergement adaptée et performante.

Prérequis et préparation (ce qui évite 80% des retours arrière)

Avant de parler “multi-boutique prestashop”, clarifiez d’abord ce que vous hébergez exactement : plusieurs installations séparées, ou une seule installation avec la fonctionnalité multi-magasin. Les deux approches n’ont pas les mêmes impacts sur les produits, les catégories, les catalogues, les modules, les licences, les imports, et la gestion des quantités.

• Accès : accès serveur (SSH), DNS, FTP/SFTP, et accès MySQL/MariaDB (ou MariaDB compatible MySQL).
• Niveau & risque : si vous touchez aux vhosts, réécritures et TLS, prévoyez une fenêtre de changement et un rollback.
• Pré-vol technique : PHP compatible, extensions requises, mod_rewrite, et configuration serveur recommandée.
• Sécurité : HTTPS partout, sauvegardes testées, et journalisation exploitable.
• Exploitation : logs web + logs PHP + logs applicatifs, sinon “aide base” impossible en incident.

Pour les prérequis applicatifs, basez-vous sur la documentation officielle (versions PHP/MySQL/MariaDB, mémoire PHP recommandée, et modules requis) afin d’éviter un écart de versions difficile à diagnostiquer ensuite : Documentation PrestaShop (pré-requis) et PrestaShop Help Center (configuration serveur).

Architecture cible : isoler ce qui doit l’être, partager ce qui a du sens

Héberger plusieurs boutiques sur un même serveur ne veut pas dire “tout mélanger”. L’objectif est de réduire les effets de bord : conflits de modules, collision de caches, erreurs 500 à cause d’une seule boutique, ou backoffice instable à cause d’un thème expérimental.

• Instances : une installation PrestaShop (multi-boutique) ou plusieurs installations séparées (une par boutique).
• Bases : idéalement une base dédiée par installation (et pas une base partagée entre installations).
• Médias : distinguer les répertoires img, uploads, et caches pour éviter les collisions.
• Exécution : séparer pools PHP-FPM (ou au minimum utilisateurs système) si vous avez plusieurs périmètres.
• URLs : définir dès le départ domaines/sous-domaines/chemins, sinon la multi-boutique devient fragile.

Flux : Domaine (DNS) → vhost (Apache/Nginx) → dossier (docroot) → boutique (contexte PrestaShop)

Décidez aussi votre stratégie TLS (certificats par domaine, SAN, wildcard). Si vous automatisez le HTTPS via ACME, suivez les principes officiels : Let’s Encrypt (Getting Started).

Configurer serveur web et bases : vhosts propres, droits minimaux, réécriture maîtrisée

Votre serveur web doit router chaque domaine (ou sous-domaine, ou chemin) vers le bon docroot, avec des permissions cohérentes. Le point critique est la réécriture (friendly URLs) : un mauvais mapping peut “faire marcher” la page d’accueil mais casser panier, catégorie, ou redirections.

• Vhosts : un vhost par domaine/boutique (ou par installation), avec un docroot dédié.
• Permissions : un utilisateur système par installation si possible ; droits d’écriture strictement limités.
• Réécriture : activer et tester les règles (mod_rewrite côté Apache / équivalent Nginx).
• PHP : pool dédié si vous devez isoler mémoire/limites par boutique.
• Base : une base + un compte SQL par installation, droits minimaux (pas de privilèges globaux).

Arborescence recommandée (lisible et opérable) :

/var/www/
  boutiques/
    shop-a/
      current/        # docroot (symlink vers release)
      releases/
      shared/
        img/
        upload/
        var/          # cache/logs si externalisés
    shop-b/
      current/
      releases/
      shared/
/var/log/
  nginx/ ou apache2/
  php/

Astuce : si vous déployez souvent, l’approche “releases + shared” limite les incidents lors d’une mise à jour de versions (rollback instantané) et évite de recopier des médias volumineux.

Activer la multi-boutique PrestaShop proprement (sans pièges de contexte)

Si vous partez sur une seule installation, la multi-boutique prestashop se pilote via l’activation du mode multi-magasin, puis la création de groupes et de boutiques, et enfin la configuration des URLs par boutique. Référez-vous à la documentation officielle pour l’activation et l’écran de gestion : PrestaShop 8 (activer Multistore) et PrestaShop 8 (URLs de boutique).

• Activer : activez la multi-boutique puis vérifiez l’apparition du menu Multistore dans le backoffice.
• Groupe : créez un groupe en décidant le niveau de partage (clients, commandes, quantités).
• Boutiques : ajoutez chaque boutique avec sa catégorie racine et son thème.
• URLs : définissez domaine, domaine SSL, chemin physique/virtuel selon votre architecture.
• Importation : si vous dupliquez une boutique, sélectionnez précisément ce que vous importez (catalogue, etc.).

Flux : Groupe → boutique → contexte catalogue (produits, catégorie racine, caractéristiques)

Choix structurants à verrouiller avant d’installer des modules : le partage de clients/commandes/paniers et de “quantités disponibles” conditionne votre modèle d’exploitation. Par exemple, un groupe de boutiques qui partage des quantités impose une discipline stricte sur la gestion des stocks et sur la compatibilité des modules de stock. La documentation PrestaShop précise les options de partage au niveau du groupe (dont clients, quantités et commandes) : PrestaShop (options de groupe Multistore).

Notez aussi un point souvent sous-estimé : les cookies et la session. Si vous exploitez plusieurs boutiques sur un même domaine (en sous-dossiers), le périmètre de cookie et certaines configurations peuvent générer des effets “fantômes” (panier perçu comme partagé, déconnexions, redirections inattendues). D’où l’intérêt d’une stratégie d’URLs claire et testée.

Validation et résultats : tests end-to-end + performance + diagnostics rapides

Une multi-boutique se valide comme un système complet : front, backoffice, paiement, emails transactionnels, réécritures, et performance. L’idée n’est pas d’obtenir “ça charge”, mais de s’assurer que chaque boutique a son comportement attendu (catalogue, prix, taxes, devises, langues) et que vos modules critiques ne se contredisent pas selon le contexte de boutique.

• Front : navigation catégorie, recherche, fiche produit, panier, tunnel, compte client.
• Backoffice : vérifiez le contexte (toutes boutiques vs une boutique) avant chaque modification.
• Paiements : testez par boutique (clés API, webhooks, retour, statuts), sans supposer l’uniformité.
• Mails : testez les emails transactionnels et l’expéditeur par boutique.
• Perf : contrôlez cache, index, génération d’images, et erreurs applicatives.

Astuce d’exploitation : lorsque vous débuggez, capturez systématiquement (1) le contexte multistore visible dans le backoffice, (2) la boutique impactée, (3) l’URL et (4) l’horodatage précis pour corréler aux logs. C’est ce qui rend l’“aide base” réellement efficace au lieu d’une chasse au hasard.

FAQ multi-magasin : arbitrages, modules, sauvegardes, montée en charge

Une instance ou plusieurs installations séparées : quel choix pour limiter la casse ?

Choisissez une seule instance si vous voulez un seul backoffice et un partage contrôlé (catalogue, clients, quantités, commandes). Préférez plusieurs installations si vous devez isoler fortement les modules, les thèmes, les versions, ou si chaque boutique a un cycle de release différent. Plus vous avez de modules spécifiques et de licences hétérogènes, plus l’isolation devient pertinente.

Comment éviter les conflits de modules et de thèmes partagés (délai : 2 heures vs 2 jours) ?

Règle simple : ne configurez jamais un module “en aveugle” en contexte “toutes boutiques”. Documentez vos modules critiques (paiement, SEO, transport, taxes) avec un tableau “actif où / configuré où / dépendances / versions”. Côté thèmes, évitez de mutualiser des surcharges non maîtrisées : vous limitez les régressions lors des mises à jour de versions.

Quelle stratégie de sauvegarde pour plusieurs boutiques (retour arrière garanti) ?

Appliquez le triptyque : base (dump cohérent), fichiers (médias + config), preuve de restauration (restauration testée). En multi-boutique, prévoyez aussi une sauvegarde avant toute importation massive de produits, de catégories, ou de caractéristiques, car les erreurs se propagent vite au niveau catalogue.

Comment gérer cookies et sessions quand plusieurs boutiques partagent un domaine (risque panier) ?

Évitez autant que possible d’empiler plusieurs boutiques en sous-dossiers sur le même domaine si vous avez des parcours clients sensibles. Si vous devez le faire, testez les parcours (connexion, panier, checkout) boutique par boutique et vérifiez que les redirections, le domaine SSL et l’URL principale sont cohérents. Un mauvais périmètre de cookies peut créer des effets de bord difficiles à diagnostiquer.

Quand migrer vers un serveur plus robuste (seuil : erreurs 500, lenteurs backoffice) ?

Quand les lenteurs touchent le backoffice, que l’indexation images devient instable, ou que les pics de charge d’une boutique impactent les autres, il faut augmenter l’isolation (pool PHP, quotas, cache) et/ou la capacité. L’objectif est d’éviter qu’une seule boutique “aspire” CPU/RAM et dégrade tout le reste, surtout avec des modules lourds ou des catalogues volumineux.

Peut-on faire cohabiter plusieurs versions PrestaShop sur le même serveur (maintenance, patchs) ?

Oui, via plusieurs installations séparées (une par version). C’est souvent le meilleur compromis pour gérer des contraintes de compatibilité de modules, de licences, et de thèmes. En revanche, standardisez au maximum : même méthode de déploiement, mêmes conventions de logs, même politique TLS et mêmes pratiques de sauvegarde.

Prochaine action : posez votre schéma “domaine → vhost → dossier → boutique”, puis validez les URLs multistore avant d’installer le moindre module.