Table des matières :
- Mutualisé, isolation et « noisy neighbor » : ce que vous achetez vraiment
- Ressources PHP côté mutualisé : FPM/LSAPI, limites de processus et OPcache
- Base de données en mutualisé : MariaDB/MySQL, latence et contraintes invisibles
- Stockage, inodes et sauvegardes : le mutualisé casse rarement par « manque de Go »
- Réseau, TLS, CDN et caches : la pile HTTP du mutualisé (souvent) décide de vos CWV
- Exploitabilité dev : SSH, cron, logs, et le droit de faire des déploiements propres
- Sécurité, support et seuil de sortie : quand le mutualisé n’est plus rationnel
Mutualisé, isolation et « noisy neighbor » : ce que vous achetez vraiment
En hébergement mutualisé, votre PrestaShop (8.1/9.x) tourne sur un serveur partagé avec des dizaines/centaines d’autres comptes. Le point critique n’est pas « la puissance théorique » du CPU, mais la façon dont l’hébergeur isole les locataires et arbitre les ressources. Sans isolation robuste, le scénario classique c’est le noisy neighbor : un site voisin lance un import, un crawl agressif ou un script PHP qui fuit la mémoire, et votre boutique se prend des timeouts/503 sans avoir changé quoi que ce soit.
La bonne question à poser n’est donc pas « combien de cœurs ? », mais « quel mécanisme d’isolation et de quotas est appliqué par compte ? ». Sur les mutualisés sérieux, vous verrez des briques type cgroups/containers et, côté hébergeurs orientés hébergement, CloudLinux (LVE/CageFS) revient souvent. Ce n’est pas magique : ça évite la famine totale, mais ça introduit des plafonds stricts (CPU, mémoire, I/O, nombre de processus) qui vont se traduire par des erreurs applicatives si votre trafic ou vos tâches cron dépassent.
Quand un hébergeur parle d’« offres illimitées », partez du principe que tout est limité… mais pas documenté. Vous voulez des chiffres : CPU en % ou en CPU seconds, RAM en Mo, I/O en MB/s, IOPS, inodes, nombre de processus, connexions simultanées, limites PHP-FPM/LSAPI, et politique de throttling. C’est exactement ce qui explique la plupart des pannes « aléatoires » sur PrestaShop. Pour un diagnostic côté boutique, la lecture de logs et les symptômes type saturation sont détaillés dans Erreur HTTP 503 : diagnostic serveur, logs et ressources.
Pour rendre ce sujet « concret », voici une grille simple (les noms des limites changent selon les panneaux d’hébergement, mais les symptômes se ressemblent) :
| Ressource plafonnée | Symptômes côté PrestaShop | Ce que fait l’hébergeur (souvent) |
|---|---|---|
| CPU (quota) | back-office lent, pages qui expirent, pics de TTFB | throttling (ralentissement), files d’attente |
RAM / memory_limit |
erreurs fatales PHP, imports qui échouent | kill du process, 500/503 |
| Processus PHP | connexions simultanées qui « bloquent » | refus/queue, 503/504 |
| I/O / IOPS | lenteur « en dents de scie », cache qui traîne | throttling disque, latence DB accrue |
| Inodes | uploads impossibles, cache non écrit | erreurs fichiers, comportement erratique |
« Site Reliability Engineering is what happens when you ask a software engineer to design an operations function. » — Betsy Beyer et al., Site Reliability Engineering (Google/O’Reilly), page SRE book
À exiger dans la fiche technique (ou par ticket avant achat) : quotas chiffrés, isolation par compte, accès aux métriques (CPU/RAM/I/O), et une explication claire de ce qui se passe quand vous atteignez un plafond (throttle, kill, 503, queue).
Mini-scenario (très classique) : vous lancez une campagne e-mail sur un créneau « soldes / promo » ; le trafic grimpe mais reste raisonnable. Pourtant le back-office devient impraticable et vous voyez des 503 intermittentes. Sur un mutualisé sans isolation stricte, ce n’est pas forcément votre hausse de trafic qui casse : c’est parfois le voisin qui sature le disque (I/O) ou la CPU du nœud. Sur un mutualisé bien isolé, l’incident se traduira plutôt par vos limites atteintes (et donc des symptômes reproductibles dans vos métriques), ce qui est paradoxalement plus facile à diagnostiquer et à corriger.
Ressources PHP côté mutualisé : FPM/LSAPI, limites de processus et OPcache
PrestaShop 9 est plus proche de Symfony qu’une 1.6, donc plus sensible à la latence CPU et à la mémoire par requête (autoloading, container, back-office plus lourd, modules plus verbeux). Votre objectif en mutualisé : minimiser le nombre de requêtes PHP « chères » et éviter les pics de concurrence. Les offres fiables exposent un gestionnaire PHP permettant de choisir une version moderne (au minimum PHP 8.1, idéalement 8.2/8.3 selon votre version PrestaShop) et d’activer les extensions indispensables. Pour le contexte versions et incohérences de recommandations, voir PrestaShop 9 : versions PHP recommandées et incohérences de documentation.
À vérifier avant achat (ou dès la mise en place), parce que c’est une source fréquente de “ça marche chez moi / ça casse en prod” :
- Extensions PHP utiles/attendues selon votre stack :
intl,curl,mbstring,zip,gdouimagick,openssl,pdo_mysql. - Limites d’exécution :
memory_limit,max_execution_time,max_input_vars(formulaires back-office), upload (upload_max_filesize,post_max_size). - Mode d’exécution et gestion de la concurrence : PHP-FPM / LSAPI, et surtout la limite de workers par compte.
Le deuxième critère, rarement affiché, c’est le mode d’exécution : PHP-FPM (Apache/Nginx) ou LSAPI (LiteSpeed). Sur mutualisé LiteSpeed, vous avez souvent un meilleur rendement sous charge parce que la pile est pensée pour du multi-tenant avec une gestion fine des files d’attente (WaitQ côté LiteSpeed). Si vous cherchez des repères concrets sur la lecture de ces symptômes côté LiteSpeed/PHP, la méthodologie est similaire à celle décrite dans Performances PHP LiteSpeed : cache opcode, LSAPI et suivi WaitQ.
Un point « contre-intuitif » : en mutualisé, le plafond le plus douloureux n’est pas toujours la CPU, mais le nombre de processus PHP. Exemple : vous avez 10 requêtes simultanées (clients + robots + API + back-office), mais votre compte n’a droit qu’à 2–4 workers PHP. Résultat : les requêtes s’empilent, dépassent les timeouts, et vous observez des 503/504. Dans ce cas, optimiser “un peu” le thème ne suffit pas ; il faut réduire la concurrence (cache page, désindexer certaines facettes, limiter les bots) ou changer d’offre.
Enfin, OPcache : en 2026, ne pas avoir OPcache correctement dimensionné en production est une pratique à éviter. Sur mutualisé, vous ne contrôlez pas toujours la conf globale, mais certains hébergeurs permettent un php.ini/.user.ini par compte. Les paramètres qui comptent réellement pour PrestaShop : taille du cache, max_accelerated_files, et stratégie de revalidation. Une base recommandée et les points d’attention sont détaillés dans PHP OPcache : paramètres recommandés pour optimiser les performances.
Signaux faibles de mutualisé « fragile » : memory_limit bloqué à 128–256 Mo pour PHP, max_execution_time trop bas (imports), pas de contrôle des versions PHP, et aucune transparence sur la limite de processus (souvent l’origine d’un back-office qui « mouline » puis 504/503).
Base de données en mutualisé : MariaDB/MySQL, latence et contraintes invisibles
Sur PrestaShop, la base fait la performance (catalogue, prix spécifiques, facettes, paniers). En mutualisé, vous êtes presque toujours sur un serveur SQL partagé : c’est là que se concentrent les contentions (I/O disque, buffer pool, locks), et c’est aussi la couche que vous pouvez le moins maîtriser (pas de my.cnf, pas de slow query log accessible, pas de tuning InnoDB). Une offre fiable doit au minimum annoncer clairement la version (MySQL 8 / MariaDB 10.6+ typiquement), le charset/collation (utf8mb4), et une politique de quotas (taille DB, connexions, requêtes/minute si throttling).
Si vous migrez depuis une base vieillissante ou hétérogène (collations mixtes, tables MyISAM résiduelles), l’hébergement mutualisé ne pardonne pas : chaque requête plus lente amplifie l’effet de la charge partagée. Avant de signer, assurez-vous que l’offre est compatible avec une base InnoDB propre et une collation cohérente ; ce point est détaillé dans Prérequis système : migration MySQL vers MariaDB, InnoDB et collation UTF-8.
Trois vérifications rapides (souvent possibles sur une offre “test” ou remboursable) :
- Temps de réponse DB aux heures de pointe : testez front + back-office à différents horaires (milieu de journée, fin d’après-midi). En mutualisé, la variabilité est un signal.
- Concurrence : lancez un import (même petit) pendant que vous naviguez dans le back-office. Si tout “gèle”, vous êtes probablement limité en CPU/process PHP et la DB suit mal.
- Charset/collation dès le départ : validez que la DB est en
utf8mb4partout. Corriger après coup (sur gros catalogue) peut être coûteux.
Côté applicatif, vous n’avez pas mille leviers en mutualisé : (1) réduire les requêtes inutiles (modules bavards, N+1), (2) limiter les pages qui explosent l’indexation (facettes), (3) surveiller et corriger les requêtes lentes. La pratique concrète (profiling SQL, lecture des patterns) est proche de ce qui est couvert dans Optimisation de code PrestaShop : diagnostiquer lenteurs et requêtes SQL et, si vous avez besoin d’une approche plus MySQL “pure”, Développeur MySQL : optimiser requêtes, schémas et performances en production.
Point transactionnel concret : demandez explicitement si Redis est proposé (même en option). Sans cache objet, PrestaShop retombe sur DB pour trop de choses (sessions, états, configurations), ce qui rend le mutualisé plus instable quand le trafic grimpe. Si Redis est disponible, clarifiez l’usage autorisé (cache objet, sessions, persistance) et le quota mémoire, sinon vous risquez un cache qui “évapore” au mauvais moment.
Stockage, inodes et sauvegardes : le mutualisé casse rarement par « manque de Go »
Sur le papier, beaucoup d’offres mutualisées affichent des quotas disque confortables. En pratique, les incidents viennent plutôt (a) des limites d’inodes (nombre de fichiers), (b) d’un stockage HDD/RAID saturé en IOPS, ou (c) d’un throttling I/O agressif. PrestaShop génère énormément de petits fichiers (cache Smarty/Twig, miniatures produits, logs, exports, sessions si non externalisées). Un plafond d’inodes atteint se manifeste par des erreurs bizarres : uploads impossibles, cache non écrit, back-office erratique.
Deux actions très “rentables” en mutualisé :
- Gouverner les fichiers qui explosent : miniatures produits, caches, exports, logs. Un nettoyage périodique (automatisé) évite d’atteindre les limites “silencieuses”.
- Réduire les écritures inutiles : si vous régénérez les thumbnails, faites-le sur un créneau calme, et vérifiez que le cache (page/CDN) absorbe bien la charge après.
Côté performance, cherchez explicitement « NVMe » et pas seulement « SSD ». Ce n’est pas un fétichisme matériel : la différence se voit sur les 95e/99e percentiles de TTFB quand le serveur est chargé et que PHP/SQL attendent le disque (cache froid, writes de sessions, invalidations). Si vous optimisez agressivement les images et que vous regénérez souvent les thumbnails (déploiement de thème, WebP), vous multipliez les écritures ; le sujet image/caching côté LiteSpeed est abordé dans LiteSpeed Cache : lazy‑loading, LQIP et VPI pour optimiser les images.
Le critère non négociable : la sauvegarde et surtout la restauration testable. Exigez : fréquence, rétention, localisation (même DC ou autre), et mécanisme de restore (self-service ou ticket). Mettez des mots dessus : RPO (perte maximale acceptable) et RTO (temps max de remise en service). Sur PrestaShop, un backup fichier sans dump DB cohérent (ou l’inverse) ne sert à rien. Et si votre base gonfle avec des tables temporaires/modules, prévoyez un nettoyage périodique (cf. MedCleanMyShop PrestaShop : nettoyage base de données et fichiers automatisé).
Vérification simple : demandez un exemple de procédure de restore (pas une promesse). Un hébergeur fiable sait expliquer comment restaurer un point dans le temps et ce qui est inclus/exclu. Idéalement, il doit pouvoir préciser si la restauration est un snapshot (rapide mais parfois “tout ou rien”) ou une restauration logique (dump SQL + fichiers), et comment il gère la cohérence DB (verrous, outils de backup, fenêtre de sauvegarde).
Réseau, TLS, CDN et caches : la pile HTTP du mutualisé (souvent) décide de vos CWV
Le mutualisé « correct » en 2026 doit fournir HTTP/2 partout, TLS 1.3, certificats automatisés (Let’s Encrypt ou équivalent) et une gestion propre de la compression (Brotli si possible, sinon gzip). Ça ne fait pas la performance à lui seul, mais ça évite de partir avec un boulet. Si l’offre ne supporte pas HTTP/2, ce n’est pas « un détail » : PrestaShop charge beaucoup d’assets (CSS/JS/images), et HTTP/2 limite le coût de la multiplexation par rapport à HTTP/1.1.
Si votre clientèle est majoritairement en France (ou plus largement en Europe de l’Ouest), la localisation réelle de l’infrastructure compte : un datacenter dans l’UE simplifie aussi certains sujets de conformité (données personnelles, sous-traitance), et réduit mécaniquement la latence réseau par rapport à une zone très éloignée. Sans tomber dans l’obsession géographique, demandez au moins : pays/ville du datacenter principal, et si le support sait vous répondre sans détour.
« 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load. » — Think with Google (2017)
Think with Google — Mobile site load time statistics
Pour la diffusion statique (images, JS/CSS), un CDN est souvent plus déterminant que le choix d’un mutualisé “plus cher” — surtout si vous vendez national/international. Si votre hébergeur propose un pseudo-CDN maison opaque, comparez-le à un CDN standard et documenté. Pour des repères 2026 et des critères de comparaison (cache keys, purge, HTTP/3, règles), vous avez un panorama dans CDN en 2026 : comparatif Bunny.net, Cloudflare, Akamai, CloudFront, Fastly.
Côté cache serveur, attention à l’illusion : sur mutualisé, vous n’aurez pas Varnish dédié, ni Redis garanti, ni tuning fin. Le « mieux » réaliste est LiteSpeed + cache page via plugin, mais ça exige une stratégie propre (cache du catalogue vs cache du panier/checkout, exclusions, variations). PrestaShop peut encaisser des pics si le cache est bien posé, mais le checkout doit rester dynamique ; sinon vous créez des bugs de session et de stock. Pour les problématiques de trafic fort (soldes, campagnes) et l’articulation cache/CDN, voir PrestaShop soldes : optimiser caches, CDN et Varnish pour trafic élevé.
Astuce pratique : si vous hésitez entre “monter en gamme” sur un mutualisé ou mettre un CDN, faites un test mesurable. Un CDN bien configuré réduit la charge serveur (moins de hits PHP), améliore le TTFB perçu sur les assets, et stabilise souvent vos Core Web Vitals plus sûrement qu’un +10% de CPU “théorique”.
Exploitabilité dev : SSH, cron, logs, et le droit de faire des déploiements propres
Un mutualisé peut être “rapide” et pourtant inexploitable si vous n’avez pas les bons accès. Pour un PrestaShop maintenu sérieusement (CI/CD, hotfix, build front), le minimum c’est : SSH, Git, Composer (ou au moins la possibilité de déployer un vendor/ complet), et des cron jobs configurables. Sans cron fiable, vous allez rater des tâches critiques (indexations, imports, relances, nettoyages), ou les exécuter via appels HTTP bricolés (et donc instables).
Deux questions très discriminantes à poser au support :
- Les crons tournent-ils en CLI (recommandé) ou via un “pseudo-cron” HTTP ? Un cron CLI est en général plus stable et moins sujet aux timeouts web.
- Quelle est la politique sur les process longs (imports, génération d’images, feeds) : kill au bout de X secondes, throttle, ou possibilité de passer par des tâches planifiées ?
Deuxième point : l’accès aux logs. Si l’hébergeur ne vous donne que des « stats » et masque error_log, access.log et les logs PHP-FPM/LSAPI, vous êtes aveugle. C’est là que l’approche Twelve-Factor reste pertinente :
« Treat logs as event streams. » — The Twelve-Factor App, The Twelve-Factor App — Logs
Sur PrestaShop, vous voulez corréler rapidement : erreurs PHP, erreurs JS front, exceptions Symfony, timeouts SQL, et pics 5xx. Le guide opérationnel côté boutique (collecte/alerting) est détaillé dans PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail.
Enfin, posez la question de la pré-production. Beaucoup de mutualisés ne proposent pas d’environnement de staging isolé (ou alors c’est un sous-domaine dans le même compte, donc mêmes quotas et mêmes risques). Or, les mises à jour PrestaShop et modules ne sont pas « safe by default ». Si vous devez maintenir une boutique en prod, une checklist de process (backup, tests, rollback) reste indispensable, même en mutualisé ; voir Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests et, en cas d’échec, Mise à jour PrestaShop ratée : diagnostiquer et réparer rapidement.
Sécurité, support et seuil de sortie : quand le mutualisé n’est plus rationnel
En mutualisé, vous déléguez une partie du patching OS/webserver, mais vous n’échappez pas aux risques applicatifs PrestaShop (modules, back-office exposé, uploads, surface PHP). Une offre fiable doit au minimum proposer : WAF (ModSecurity ou équivalent) avec possibilité de lever des faux positifs, isolation des comptes, anti-malware, et des options de durcissement (désactivation fonctions dangereuses, règles sur /admin, limitation brute-force). Pour les implications concrètes côté PrestaShop (checkout sensible, faux positifs), voir WAF PrestaShop : réduire les faux positifs et sécuriser le checkout.
Côté e-commerce, gardez aussi en tête le périmètre “paiement” : si vous utilisez une page de paiement hébergée (PSP) ou une redirection, votre exposition technique est différente d’un paiement embarqué. Dans tous les cas, votre serveur reste critique (compromission = redirections frauduleuses, webskimmers, vol de session). Un repère utile pour cadrer les classes de risques web (sans être spécifique PrestaShop) est la liste OWASP Top 10.
Le support est un critère technique, pas un critère “relationnel”. Ce que vous voulez mesurer : délai de réponse réel sur incident, compétence (capacité à lire un log, identifier un throttling, restaurer un backup), et transparence (status page, historique d’incidents). En cas de compromission (webskimmer, backdoor, fuite de données), la différence entre un mutualisé « pas cher » et un mutualisé « sérieux » se joue sur la capacité de containment et de rotation (restauration propre, changement secrets, audit). Pour cadrer votre playbook, voir Sécurité PrestaShop : plan de réponse à incident et containment immédiat.
Enfin, définissez votre seuil de sortie. Le mutualisé devient une dette dès que vous avez besoin de composants non compatibles (Elasticsearch/Meilisearch, workers, queues), d’une observabilité sérieuse, ou d’un contrôle réseau/système. Exemple : si vous voulez un moteur de recherche dédié, ce n’est pas un sujet mutualisé ; cf. Moteur de recherche marketplace : Meilisearch, Elasticsearch ou Algolia. À partir d’un certain volume (catalogue massif, import quotidien, pics marketing), un VPS ou un dédié infogéré devient plus rationnel (maîtrise de Redis, tuning DB, reverse proxy, workers). Pour cadrer la bascule, vous pouvez partir de VPS pour Docker : critères techniques et ressources recommandées et, si vous externalisez l’exploitation, Serveurs dédiés infogérés e-commerce : NVMe, Redis, Varnish et haute disponibilité.
Un indicateur simple (sans chiffre magique) : si vous voyez chaque semaine des limites atteintes (process PHP, I/O, DB) et que votre seule action possible est “attendre”, vous avez dépassé la zone rationnelle du mutualisé. À l’inverse, si vos lenteurs viennent surtout d’un thème lourd, d’images non optimisées, ou de modules bavards, vous pouvez souvent stabiliser une boutique sur un mutualisé correct avec cache + hygiène applicative.
Checklist d’achat (à copier-coller au support avant commande) :
- Quotas chiffrés : CPU (mécanique et plafond), RAM, I/O (MB/s + IOPS), inodes, processus PHP, connexions SQL.
- Stack : serveur web (LiteSpeed/Apache/Nginx), HTTP/2, TLS 1.3, version PHP disponible, extensions, OPcache.
- DB : version MySQL/MariaDB, charset/collation, limites de connexions, politique de sauvegarde DB.
- Exploit : SSH, Git, Composer, cron, accès logs, procédure de restore.
- Sécurité : WAF, isolation comptes, anti-malware, processus d’incident, historique de vulnérabilités/patch.
Tant que l’hébergeur n’est pas capable de répondre précisément à ces points (sans jargon flou), vous n’achetez pas une « offre fiable » : vous achetez de l’aléa.