Un marchand affiche 80 000 références produits, dont 15 000 actives en ligne. La page catégorie met huit secondes à s'afficher. L'agence recommande un serveur dédié 32 Go de RAM. Sauf que le profilage montre autre chose : une requête SQL à quatre secondes, un module de filtres qui joint six tables, et un cache Smarty désactivé « pour faciliter le débogage ». La vraie limite n'était pas PrestaShop en lui-même — c'était l'architecture du listing sur un catalogue dense.
Ce scénario se répète sur des boutiques qui ont grandi progressivement. Le back-office affiche correctement des dizaines de milliers de fiches, ce qui rassure l'équipe commerciale. Pourtant, le client ne consulte pas l'administration : il parcourt des catégories, lance des recherches, compare des déclinaisons. C'est là que la charge se concentre, bien avant que le processeur de l'hébergeur atteigne son plafond.
La question utile n'est donc pas « combien de produits PrestaShop supporte-t-il ? ». Elle est plus concrète : quelle requête votre visiteur attend-il en premier, et qui la ralentit — la base, un module, l'absence de cache, ou enfin l'infrastructure ?
Où la limite apparaît en pratique
Sur un gros catalogue, les goulots d'étranglement se répartissent en couches distinctes. La base MySQL souffre d'abord sur les listings et l'administration produits lorsque les index manquent ou que les tables ps_product* grossissent sans maintenance. La recherche native devient pénalisante dès que les facettes multiplient les jointures. Le cache Smarty ou objet, s'il est absent ou mal invalidé, laisse un temps de réponse élevé même quand le serveur semble disponible.
Les modules tiers amplifient le problème : filtres facettés mal optimisés, extensions marketing qui s'exécutent sur chaque page catégorie, imports CSV synchrones qui bloquent la boutique en heures ouvrées. Les images non servies par un CDN peuvent absorber une part importante de la bande passante sans expliquer à elles seules huit secondes de latence, mais elles aggravent l'expérience perçue.
| Zone | Symptôme | Levier |
|---|---|---|
| Base MySQL | Listing lent, admin produits | Index, nettoyage, réplica lecture |
| Recherche native | Timeout ou lenteur recherche | Elasticsearch, Algolia |
| Smarty / cache | Temps de réponse élevé constant | Cache page, Redis |
| Modules facettes | Pic processeur sur catégories | Refactor ou service dédié |
| Images | Bande passante saturée | CDN, formats modernes |
| Imports CSV | Blocage boutique | File asynchrone, heures creuses |
Un gros catalogue expose les jointures mal pensées — pas la marque PrestaShop elle-même.
Hébergement : au-delà du nombre de cœurs processeur
Comparer des hébergeurs sur le seul nombre de processeurs virtuels masque les critères qui comptent réellement pour PrestaShop. Les entrées-sorties disque déterminent la vitesse des requêtes sur des tables volumineuses : un stockage NVMe local ou équivalent vaut mieux qu'un disque partagé lent. La mémoire vive doit dimensionner le pool de tampons MySQL ; huit gigaoctets représentent souvent le seuil de confort pour un catalogue lourd avec cache actif.
Redis sert à la fois aux sessions et au cache Smarty ou objet lorsque l'application est correctement configurée. Côté PHP, viser la version 8.1 ou supérieure, activer OPcache, et ajuster max_execution_time pour les imports planifiés. Un cron fiable est indispensable pour l'indexation, le nettoyage du cache et les files d'attente. Enfin, un environnement de préproduction permet de tester imports et modules sans bloquer la production.
Le mutualisé convient rarement à un catalogue lourd avec filtres avancés. Un VPS ou un cloud dédié à la boutique est plus réaliste dès que les listings dépassent quelques secondes malgré une base optimisée. Pour comparer les offres orientées commerce, consultez notre annuaire d'hébergeurs et le guide MySQL pour site dynamique.
Optimisations applicatives avant de monter en gamme
Avant d'augmenter la facture hébergement, vérifiez les gains applicatifs les plus fréquents. Les index manquants sur les attributs filtrés, id_category et active transforment parfois une requête de six secondes en quelques centaines de millisecondes. Désactivez les modules de listing un par un en mesurant le temps de génération de page : la méthode est fastidieuse, mais elle identifie souvent le coupable en une matinée.
Activez le cache avec une stratégie d'invalidation documentée : sans règle claire, vous échangez lenteur contre données obsolètes. Externalisez la recherche dès que les requêtes SQL de listing dépassent plusieurs centaines de millisecondes malgré les index. Un CDN pour les images produit réduit le poids perçu de la page — souvent autour de soixante-dix pour cent du poids total. Planifiez les imports nocturnes avec un mode maintenance partiel pour éviter de saturer la base en journée.
Si vous hésitez entre stacks e-commerce, le guide Magento n'est pas un WordPress lourd aide à situer PrestaShop face à d'autres solutions catalogue.
Signaux que l'hébergeur est devenu le plafond
L'infrastructure devient le facteur limitant lorsque l'optimisation applicative est déjà faite et que les symptômes persistent. Un processeur utilisé à moins de quarante pour cent alors que l'attente entrées-sorties disque reste élevée en permanence indique un goulot disque, pas processeur. Un journal MySQL des requêtes lentes qui se remplit malgré des index corrects suggère un dimensionnement mémoire ou disque insuffisant. Une mémoire saturée par un pool de tampons trop petit force des lectures disque répétées. Une latence réseau élevée vers une base managée distante pénalise chaque page.
Dans ces cas, monter en gamme ou rapprocher l'application et la base a du sens. Tant que le profilage montre une requête SQL dominante, un serveur plus puissant ne fait que payer plus cher la même lenteur.
Le sommet : le catalogue révèle la dette modules
Magento et WooCommerce ne sont pas les seuls à souffrir du catalogue massif. PrestaShop est plus léger en théorie, mais plus sensible aux modules tiers sur les listings. La comparaison avec d'autres stacks n'a de sens que si vous mesurez la même page catégorie, pas le même nombre de références en base.
Décider et avancer sans angle mort
Commencez par profiler une page catégorie représentative et la recherche interne, avec les mêmes filtres que vos visiteurs utilisent le plus. Auditez ensuite les modules qui interviennent sur le listing et les facettes, en préproduction si possible. Activez cache objet et Redis si ce n'est pas déjà fait, puis dimensionnez MySQL en mémoire et en index avant d'envisager un changement d'hébergeur. Ne montez en infrastructure qu'après preuves chiffrées : temps de requête, charge processeur, attente disque. Parcourez les hébergeurs orientés e-commerce dans notre annuaire et le comparateur en vous appuyant sur ces mesures, pas sur une recommandation générique « serveur plus gros ».
Questions fréquentes
Combien de produits PrestaShop peut-il gérer ?
Il n'y a pas de plafond officiel. Des boutiques tournent avec plus de 100 000 références produits lorsque l'architecture est adaptée. Sans cache, index SQL et modules optimisés, les problèmes commencent souvent entre 5 000 et 20 000 références actives, surtout avec des filtres facettés lourds.
Quelle RAM minimum pour un gros catalogue ?
Comptez 4 Go pour une boutique moyenne bien optimisée, et 8 Go ou plus avec recherche externe, nombreux modules ou imports fréquents. Le mutualisé devient rarement suffisant au-delà de quelques milliers de produits avec filtres avancés.
Elasticsearch est-il obligatoire ?
Non, mais la recherche native SQL devient lente sur les gros catalogues avec facettes. Elasticsearch ou Algolia devient pertinent lorsque les requêtes de listing dépassent plusieurs centaines de millisecondes malgré l'indexation.
Comment identifier si le problème vient des modules ?
Désactivez temporairement les modules marketing, filtres et SEO en préproduction, puis comparez le temps de génération d'une page catégorie. Un module mal codé sur le listing reste l'une des causes les plus fréquentes sur les catalogues denses.
Avec 80 000 références, la question n'est pas « quel hébergeur ? » — c'est « quelle requête SQL votre client attend-il en premier ? »