Hébergement PrestaShop : serveur, SSL et performances

L'hébergement, c'est le sol sur lequel repose votre boutique

Nous avons fait tourner PrestaShop sur à peu près tous les niveaux d'hébergement qui existent : des hébergements mutualisés cPanel bon marché hérités de clients, des VPS chez Hetzner et OVH, des machines dédiées en datacentre, et le TrueNAS du bureau qui héberge mypresta.rocks lui-même. Après plus de dix ans à ce régime, notre position est simple : aucune quantité de mise en cache, d'optimisation d'images ou de réglage de modules ne sauvera une boutique coincée sur un hébergement sous-dimensionné ou mal configuré. Mettez le sol au carré d'abord, et tout ce qui se construit au-dessus devient plus facile.

Cette page est volontairement tranchée. C'est là que nous enverrions un client qui demande « sur quoi devrais-je héberger ? » avant de signer quoi que ce soit.

Les types d'hébergement, dans l'ordre où ils sont réellement appropriés

Hébergement mutualisé bon marché (autour de 3 à 15 $/mois)

Votre boutique partage un serveur avec des centaines d'autres. Vous obtenez cPanel ou DirectAdmin, une configuration PHP verrouillée et aucun accès root. Les bons (nous en avons vu) vous laissent choisir un PHP récent, activer OPcache et ne surchargent pas les disques. Les mauvais font exactement le contraire.

Ce que vous obtenez : une facture mensuelle basse, l'e-mail inclus, quelqu'un d'autre qui applique les correctifs de l'OS.
Ce que vous abandonnez : des voisins bruyants qui font chuter aléatoirement les temps de réponse, pas de SSH sur les formules d'entrée, pas de Redis, pas de Varnish, des versions de PHP que vous ne choisissez pas, et une IP partagée qu'un autre locataire peut faire blacklister à votre place.

Convient pour une boutique toute neuve de moins de 500 produits, avec un faible trafic et aucune pression de temps pour optimiser. Ne convient pas pour quoi que ce soit que vous cherchez à faire grandir.

VPS (managé ou non managé, 5 à 60 $/mois)

RAM dédiée, CPU dédié, disque dédié, accès root. C'est là que vivent la plupart de nos boutiques clientes, et c'est là que nous placerions la vôtre.

VPS managé : le prestataire applique les correctifs de l'OS et gère les mises à jour de sécurité. Vous gérez PrestaShop. Un panneau de contrôle ou un service managé ajoute généralement 5 à 20 $/mois au prix brut du VPS.
VPS non managé : une machine Debian ou Ubuntu vierge avec SSH. Moins cher, mais vous possédez chaque ligne de la configuration nginx et chaque mise à jour du noyau.

Pour 90 % des boutiques que nous touchons, un VPS managé dans la tranche 15 à 30 $/mois surpasse l'hébergement mutualisé sur toutes les dimensions qui comptent.

Serveur dédié (80 à 300+ $/mois)

Une machine physique entière, sans surcoût d'hyperviseur. Surdimensionné pour une boutique de 2 000 produits. Le bon choix lorsque vous dépassez 50 000 produits avec un trafic sérieux : c'est là que nous faisons migrer les clients du VPS cloud vers quelque chose comme un dédié Hetzner, parce que le rapport prix/performance devient ridicule en votre faveur.

VPS cloud

Facturation à l'heure, provisionnement rapide, snapshots, une API. 2 Go / 2 vCPU se situe dans la tranche 5 à 15 $/mois chez les prestataires qui en valent la peine, et les prestataires basés dans l'UE sous-cotent régulièrement les américains pour des caractéristiques équivalentes.

Hébergement « PrestaShop managé »

Des machines préconfigurées avec un support spécifique à PS. L'argumentaire est séduisant si vous n'avez jamais touché à un serveur. La réalité, c'est qu'il s'agit généralement d'une infrastructure revendue avec une marge, et le support connaît le panneau de contrôle de la boutique, pas vos modules spécifiques.

L'hébergement PS managé mérite son prix lorsque vous n'avez véritablement aucune envie d'apprendre un serveur. Pour tous les autres, un VPS managé avec une pile LEMP saine est plus performant et coûte moins cher.

Configuration minimale requise, par version de PrestaShop

PrestaShop 1.7

PHP : 7.1-7.4 • MySQL : 5.5+ (5.7 recommandé) • RAM : 2 Go au plancher, 4 Go raisonnable
Extensions : curl, gd, intl, mbstring, zip, xml, json, openssl

PrestaShop 8.x

PHP : 7.2-8.1 (8.1 est celle sur laquelle nous déployons) • MySQL : 5.6+ • RAM : 4 Go au plancher
Extensions : la liste de la 1.7 plus fileinfo et iconv

PrestaShop 9.x

PHP : 8.1-8.4 (nous faisons tourner 8.2 en production) • MySQL : 8.0+ ou MariaDB 10.5+ • RAM : 4 Go au plancher, 8 Go si vous avez un trafic réel
Extensions : la liste de la 8.x, avec les exigences de Symfony 6.4 qui s'appliquent en plus

Considérez ces chiffres comme des « la boutique s'installera », pas des « la boutique sera performante ». Un catalogue de 5 000 produits avec 50 modules et du trafic en direct réclame 4 à 8 Go de RAM, quelle que soit la version installée au sol.

Écran Informations de l’interface d’administration PrestaShop affichant la configuration PHP, MySQL et serveur

Guide de dimensionnement

Taille de la boutique	Produits	Visiteurs quotidiens	RAM	CPU	Disque
Démarrage	<500	<200	2 Go	1 cœur	20 Go SSD
Petite	500-2 K	200-1 K	4 Go	2 cœurs	40 Go SSD
Moyenne	2 K-10 K	1 K-5 K	8 Go	4 cœurs	80 Go SSD
Grande	10 K+	5 K+	16 Go+	4-8 cœurs	160 Go+ SSD

Un rappel sur le disque : 5 000 produits avec 5 images chacun, régénérées à travers 7 types d'images PrestaShop, dévorent 10 à 20 Go avant même que vous n'ayez ajouté quoi que ce soit d'autre. Prévoyez le disque en conséquence.

Ce qui fait réellement la différence

Chaque hébergeur affiche des cœurs, de la RAM et de la bande passante. D'après notre expérience, voici l'ordre dans lequel les choses comptent réellement.

1. Version de PHP et OPcache

PHP 8.1 est environ 20 à 40 % plus rapide que 7.4 sur le même code, et OPcache se révèle être le gain le plus important par-dessus. Sans OPcache, PrestaShop recompile des centaines de fichiers PHP à chaque requête. Avec, le bytecode compilé arrive directement depuis la mémoire.

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

Si un hébergeur ne vous laisse pas activer OPcache, ou sert encore PHP 7.x en 2026, passez votre chemin. Il n'y a aucun avantage.

2. Entrées/sorties disque : SSD ou NVMe, jamais de plateau tournant

PrestaShop lit des centaines de fichiers par page. La lecture aléatoire d'un disque dur se situe autour de 5 à 15 ms, celle d'un SSD à 0,1 ms. Cela seul fait une différence d'un facteur 3 sur le temps de page réel. Nous ne déploierons pas une boutique sur disque dur. Vous non plus.

3. Configuration de MySQL

Une page PS typique déclenche 100 à 300 requêtes. Le réglage qui compte le plus est innodb_buffer_pool_size : il contrôle quelle part de vos données réside en RAM. 50 à 70 % de la RAM totale sur un serveur de base de données dédié, 25 à 40 % sur une machine combinée application+BDD. Avant de régler autour d'une base de données surchargée, utilisez Database Cleanup ou des audits SQL équivalents pour élaguer les paniers abandonnés, les journaux et les statistiques périmées.

4. RAM

Chaque worker PHP-FPM utilise 30 à 80 Mo de mémoire résidente. Dix workers, cela représente 300 à 800 Mo rien que pour PHP, puis ajoutez MySQL, Redis, OPcache lui-même et l'OS. 2 Go, c'est juste avant même d'avoir servi une seule requête.

5. HTTP/2

Multiplexe tout sur une seule connexion. 20 à 40 % plus rapide sur les pages chargeant 60 à 80 ressources, ce qui est le cas de la plupart des pages PrestaShop. Nécessite HTTPS, dont vous aviez de toute façon besoin.

Hébergement mutualisé : les murs que vous allez heurter

Le mutualisé peut fonctionner pour les plus petites boutiques, mais vous buterez sur ceux-ci à peu près dans cet ordre :

Pas de SSH. Vous ne pouvez pas lancer Composer en CLI, des commandes de console, ni aucun des scripts de nettoyage sur lesquels nous nous appuierions normalement.
Limites de cron. De nombreux hébergeurs mutualisés plafonnent le cron à toutes les 15 minutes. Le ménage de PrestaShop en demande davantage.
memory_limit plafonné. 128 à 256 Mo est la norme sur les formules bon marché. Les gros imports échouent silencieusement lorsqu'ils l'atteignent.
Pas de Redis. Vous êtes coincé sur la mise en cache par système de fichiers, sur un stockage partagé déjà occupé.
IP partagée. Les habitudes de spam d'un voisin font blacklister votre IP, et les e-mails de confirmation de commande cessent d'arriver. Nous couvrons la solution dans notre guide de délivrabilité des e-mails.

Si vous magasinez tout de même du mutualisé, privilégiez l'accès SSH, un panneau de contrôle qui vous laisse choisir la version de PHP, la prise en charge d'OPcache, et une limite de mémoire que vous pouvez relever. Et lisez toujours le prix de renouvellement : le tarif d'appel, c'est du marketing.

2,99 $/mois se renouvelle à 10,99 $ un an plus tard. Tous les sites d'avis sur le mutualisé bon marché passent là-dessus. Pas nous.

VPS : le bon choix pour la plupart des boutiques

Pourquoi nous finissons toujours ici

Accès root. Installez Redis, Varnish, toute la pile.
CPU et RAM dédiés. Pas de voisin à blâmer à 14 h le Black Friday.
Contrôle complet de PHP-FPM et d'OPcache.
SSH et cron sans restriction.
nginx, pas Apache, sauf si vous en décidez autrement.
Des snapshots avant les mises à jour risquées : trois clics pour revenir en arrière.

Ce qu'il faut réellement vérifier avant de souscrire

Stockage SSD ou NVMe. Si la fiche technique ne le dit pas, supposez du disque dur et passez.
Tarification équitable. 2 Go / 2 vCPU à 5 à 15 $/mois, c'est normal. 30 $, c'est payer trop cher.
Emplacement du datacentre. Les boutiques de l'UE veulent des datacentres dans l'UE. La latence est réelle, le RGPD l'est encore plus.
Snapshots bon marché. La fonctionnalité unique qui se rentabilise dès la première fois qu'une mise à jour de module tourne mal.
Documentation. Vous allez passer du temps dans leur documentation. Si elle est maigre, cela vous dit quelque chose.

Si vous n'avez jamais administré une machine Linux, payez le supplément pour un service managé ou un panneau de contrôle. Un VPS mal configuré surpassera l'hébergement mutualisé dans les benchmarks et sera moins performant que lui dans la vraie vie, parce que personne n'a appliqué les correctifs du noyau.

Pile LEMP de base

# Debian 12 / Ubuntu 22.04
apt install nginx php8.2-fpm php8.2-mysql php8.2-curl \\
    php8.2-gd php8.2-intl php8.2-mbstring php8.2-xml \\
    php8.2-zip php8.2-opcache mariadb-server redis-server -y
mysql_secure_installation

Vous n'avez jamais exploité un serveur Linux ? Commencez par un VPS managé ou un panneau. Un VPS DIY cassé est pire qu'un hébergement mutualisé. Notre guide de durcissement de la sécurité couvre ce qu'il faut verrouiller une fois que vous êtes en ligne.

Dédié et cloud : quand le VPS ne suffit plus

Passez au niveau supérieur lorsque vous avez 50 000+ produits, un trafic soutenu de 5 000+ visiteurs quotidiens, un multiboutique avec cinq boutiques ou plus partageant la machine, ou une véritable exigence de disponibilité à 99,99 %.

Une machine dédiée 64 Go / NVMe chez un prestataire européen peut se situer à 40 à 60 EUR/mois, plus de capacité que la plupart des boutiques n'en utiliseront jamais, mais l'écart prix/performance par rapport à un VPS cloud aux mêmes caractéristiques est difficile à contester.

L'ordre de mise à l'échelle, lorsque vous devez effectivement passer à l'échelle : déplacez d'abord MySQL sur son propre serveur (le plus grand saut unique), puis placez Redis sur sa propre instance, puis envisagez un répartiteur de charge avec plusieurs serveurs applicatifs, et à ce stade vous avez aussi besoin d'un stockage partagé et de sessions Redis, alors ne brûlez pas les étapes.

Configuration du serveur pour PrestaShop

nginx, pas Apache

Apache est la valeur par défaut parce que l'hébergement mutualisé l'utilise, pas parce qu'il est mieux adapté. nginx utilise des entrées/sorties pilotées par les événements (10 à 30 Mo par processus contre 300 à 800 Mo pour Apache en prefork), sert les fichiers statiques sans passer par PHP, et est livré avec un cache FastCGI prêt à l'emploi.

Si vous êtes contraint à Apache, faites tourner mpm_event avec PHP-FPM, jamais mpm_prefork avec mod_php. Ce dernier est le déploiement PrestaShop le plus lent que nous ayons vu dans la nature.

Réglages PHP-FPM

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.max_requests = 500
php_admin_value[memory_limit] = 512M
php_admin_value[max_execution_time] = 300

La formule que nous utilisons pour pm.max_children : (RAM en Mo - empreinte de MySQL - OS) / 50 Mo par worker. Sur une machine de 4 Go : (4000 - 1500 - 500) / 50 = 40. Nous réglons sur 20 à 30 pour garder de la marge, parce qu'un pool FPM saturé, ce sont des 502 au visage du client.

Réglage de MySQL

[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
tmp_table_size = 64M
max_heap_table_size = 64M
slow_query_log = 1
long_query_time = 1

Activez le journal des requêtes lentes dès le premier jour. Une seule mauvaise requête exécutée 200 fois par page bat tout diagnostic de « serveur lent » que nous ayons jamais posé, et le journal, c'est ainsi qu'on la trouve. Notre guide de performance détaille quoi faire une fois que vous avez les coupables.

Redis pour les sessions et le cache

PrestaShop place les sessions et le cache sur disque par défaut. Déplacez les deux vers Redis et les pages d'administration cessent de bloquer sur le verrouillage des sessions par système de fichiers, qui est la cause unique la plus fréquente des tickets « l’interface d’administration est très lente » que nous ouvrons. Redis vous coûte 50 à 100 Mo de RAM et les rembourse immédiatement.

SSL/TLS : pas optionnel

Chaque boutique a besoin de HTTPS. Google déclasse le HTTP, les navigateurs le stigmatisent, et aucun prestataire de paiement ne fonctionnera sans. Le débat est clos.

Let's Encrypt

Gratuit, automatique, renouvellement tous les 90 jours. Certbot l'installe une fois et vous l'oubliez :

apt install certbot python3-certbot-nginx -y
certbot --nginx -d yourshop.com -d www.yourshop.com

SSL Cloudflare

Gratuit via leur proxy, avec un piège : utilisez toujours Full (Strict). Le mode Flexible envoie du texte en clair entre Cloudflare et votre origine, ce qui réduit tout l'intérêt à néant. Définissez X-Forwarded-Proto pour que PrestaShop sache qu'il est derrière HTTPS même lorsque le saut vers l'origine est plutôt en HTTP.

Forcer HTTPS

Activez-le dans Paramètres de la boutique → Général, puis ajoutez la redirection serveur :

# Nginx
server {
    listen 80;
    server_name yourshop.com;
    return 301 https://yourshop.com$request_uri;
}

# Apache (.htaccess)
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

CDN : quand et comment

Si vous servez une seule région depuis un serveur local, le CDN ne vous apporte pas beaucoup de vitesse. Ce qu'il vous apporte, c'est la mise en cache des ressources statiques et une couche anti-DDoS gratuite.

L'offre gratuite de Cloudflare couvre la plupart des boutiques : CDN mondial, SSL gratuit, anti-DDoS de base, HTTP/2, Brotli. Branchez-le dans Paramètres avancés → Performances → Serveurs média.

Mettez en cache agressivement : images, CSS, JS, polices.
Ne mettez jamais en cache : l'administration, le panier, le tunnel de commande, mon-compte, tout ce qui touche à un cookie PrestaShop.

N'activez jamais « Cache Everything » pour tout le domaine. Nous l'avons vu : un client voit le panier d'un autre client parce que le tunnel de commande a été mis en cache à la périphérie. Mettez en cache uniquement les ressources statiques et les motifs d'URL nommés.

Sauvegardes : les snapshots de l'hébergeur ne sont pas une stratégie

Les sauvegardes du prestataire sont généralement hebdomadaires, exécutées sur la même infrastructure, et ont une probabilité non nulle de ne pas se restaurer au moment où vous en avez besoin. C'est un doudou rassurant. Si le prestataire a une mauvaise nuit, les sauvegardes partent avec la boutique. Si un rançongiciel chiffre vos fichiers, les versions chiffrées sont consciencieusement sauvegardées. Et vous voulez probablement une base de données d'il y a deux heures, pas de mardi dernier.

Ce que vous voulez, au minimum : des dumps de BDD automatisés quotidiens plus des sauvegardes de fichiers, stockés hors du serveur de production, conservés pendant 30 jours, avec une restauration de test chaque mois. Planifiez ces tâches quelque part de visible ; MPR Cron Manager est l'option côté PrestaShop lorsque vous voulez que les tâches de sauvegarde soient suivies plutôt que cachées dans des lignes de crontab anonymes. Notre guide de sauvegarde contient la procédure.

Migrer entre hébergeurs

Provisionnez le nouveau serveur avec la même version de PHP et les mêmes extensions.
Exportez la base de données : mysqldump -u root -p prestashop_db | gzip > backup.sql.gz
Synchronisez les fichiers : rsync -avz /var/www/html/prestashop/ newserver:/var/www/html/prestashop/
Importez la base de données sur le nouveau serveur.
Mettez à jour les identifiants dans app/config/parameters.php.
Corrigez les permissions : chown -R www-data:www-data, répertoires en 755, fichiers en 644.
Videz le cache : rm -rf var/cache/*
Testez via /etc/hosts : pointez votre ordinateur portable vers la nouvelle IP et parcourez le tunnel de commande et l'administration avant tout le monde.
Abaissez le TTL DNS à 300 secondes 24 heures avant la bascule.
Synchronisation finale de la BDD juste avant de basculer le DNS, pour que les dernières commandes ne soient pas perdues.

Là où les migrations tournent mal

Propriété des fichiers. L'utilisateur web doit posséder les fichiers. cache, img, upload, download doivent tous être accessibles en écriture.
.htaccess manquant. Les interfaces graphiques de migration adorent ignorer les fichiers cachés. Apache a aussi besoin d'AllowOverride All pour le respecter.
Décalage de l'URL de base. Si le domaine a changé, mettez à jour ps_shop_url ou chaque lien se casse.
Saut de version de PHP. Passer de 7.4 à 8.1 casse tout module qui appelle encore des fonctions dépréciées.

Ne basculez jamais le DNS avant d'avoir testé via /etc/hosts. Nous avons vu deux migrations casser le tunnel de commande en production parce que personne n'avait cliqué sur « acheter » sur le nouveau serveur d'abord.

Signaux d'alerte : passez votre chemin quand vous voyez ceci

Technique

Pas de SSH. Vous ne pouvez pas déployer, vous ne pouvez pas déboguer, vous ne pouvez lancer aucun des outils qui résolvent réellement les problèmes.
PHP 7.x en 2026. Fin de vie. Des vulnérabilités connues qui ne seront pas corrigées.
Pas d'OPcache. 3 à 5 fois plus lent que le même code avec OPcache activé. Aucune raison de l'accepter.
Stockage sur disque dur. S'ils ne disent pas SSD ou NVMe par écrit, supposez du disque dur.
php.ini verrouillé. Vous ne pouvez pas faire tourner PrestaShop correctement sans relever au moins memory_limit.

Commercial

N'importe quoi en « illimité ». Rien n'est illimité. Ils brident les locataires bruyants au lieu de le dire.
Marques de société holding. Cinq hébergeurs « différents » détenus par la même maison mère, tous sur la même tôle surchargée, avec des logos différents.
Pas de SLA de disponibilité. Ils ne font pas assez confiance à leur propre infrastructure pour y mettre un chiffre.
Un support qui répond en jours. Une panne à 2 h du matin réclame des minutes, pas « le jour ouvré suivant ».
Facturation annuelle imposée. Ils comptent sur le fait que vous ne partirez pas quand vous réaliserez que c'était une erreur.

L'hébergement le moins cher, c'est celui qui reste en ligne pendant le Black Friday. Économiser 5 $/mois sur un hébergeur qui vous fait perdre 5 000 $ de conversions sur un week-end, ce n'est pas économiser quoi que ce soit.

Liste de contrôle avant achat

Chaque ligne ici compte. Cochez-les avant de sortir une carte.

Serveur

La version de PHP correspond à votre version de PrestaShop
Toutes les extensions PHP requises sont disponibles (intl, mbstring, gd au minimum)
php.ini est configurable (memory_limit, réglages OPcache)
MySQL ou MariaDB dans une version réellement prise en charge par PrestaShop
SSD ou NVMe par écrit
Accès SSH
Fréquence de cron sans restriction

Performance

OPcache activé et configurable
4 Go+ de RAM sur la formule que vous choisissez
HTTP/2 activé
Redis ou Memcached disponible

Fiabilité

SLA de disponibilité de 99,9 % ou mieux
Options de sauvegarde automatisées et manuelles
Temps de réponse du support critique mesuré en heures, pas en jours
Datacentre proche de vos clients

Tarification

Prix de renouvellement (pas le prix d'appel) vérifié
Facturation mensuelle disponible
Limites de bande passante ou de transfert comprises
Aucune clause vous empêchant de migrer ailleurs

Ce sur quoi nous vous placerions, par étape

Boutique toute neuve : VPS cloud avec 2 Go de RAM (5 à 10 $/mois) plus un CDN gratuit et Let's Encrypt. Bat de loin la plupart des mutualisés à 15 $/mois.
Boutique en croissance : VPS managé à 15 à 30 $/mois. Payez quelqu'un pour maintenir l'OS à jour pendant que vous vous concentrez sur la vente.
Établie (1 000+ visiteurs par jour) : VPS avec 8 à 16 Go de RAM, MariaDB réglé, Redis activé, nginx avec cache FastCGI. 15 à 40 $/mois vous y amènent.
Gros catalogue ou trafic intense : serveur dédié (un dédié EU bon marché surpasse un VPS cloud à cette échelle) ou une architecture cloud correctement séparée. 50 à 100+ $/mois et chaque centime en vaut la peine.

Mettez en place une surveillance de la disponibilité dès le premier jour. UptimeRobot est gratuit pour 50 sondes et suffisamment bon. Une fois l'hébergement réglé, le reste du travail d'optimisation a un endroit solide où se poser.

Lectures associées

Optimisation des performances PrestaShop : accélérer votre boutique : quoi régler une fois l'hébergement stabilisé
Durcissement de la sécurité PrestaShop : la liste de contrôle complète : verrouillage au niveau du serveur
Dépannage PrestaShop : corriger les pages blanches et erreurs 500 : quand l'hébergeur est le problème et qu'il faut le prouver
Sauvegarde PrestaShop : de vraies sauvegardes, pas des doudous : la procédure que nous utilisons nous-mêmes
Performance Revolution : l'un de nos modules ; se marie bien avec un VPS correctement dimensionné