Hébergement PrestaShop 9 : prérequis, serveur et migration

Ce que PrestaShop 9 demande à l’hébergement

Un hébergement PrestaShop 9 se juge sur quatre points : la version de PHP et ses extensions, la base de données, les réglages du serveur web et les ressources disponibles au moment où vos clients commandent. PrestaShop 9 est plus exigeant que les versions 1.7 et 8 sur chacun de ces points, et il refuse de s’installer si le minimum n’est pas atteint.

Le contexte rend le sujet urgent. Depuis la faille PHP2Shell d’octobre 2026, seules les branches PHP 8.2 et suivantes reçoivent des correctifs. PrestaShop 8 s’arrête à PHP 8.1 et PrestaShop 1.7 à PHP 7.4 : une boutique restée sur ces versions ne peut plus être corrigée côté PHP. Le guide sur la faille PHP2Shell explique comment vérifier et changer la version de PHP dans Plesk ; celui-ci explique comment sortir de l’impasse en passant à PrestaShop 9.

Version de PrestaShop	PHP accepté	PHP recommandé par le projet	Correctifs PHP disponibles en 2026
1.7.8	7.1 à 7.4	7.4	Non
8.x	7.2.5 à 8.1	8.1	Non
9.0	8.1 à 8.4	8.4	Oui, sur 8.2, 8.3 et 8.4
9.1	8.1 à 8.5	8.5	Oui, sur 8.2 à 8.5

Ce tableau reprend les grilles de compatibilité de la documentation développeur de PrestaShop. PHP 8.1 est la seule version acceptée à la fois par PrestaShop 8 et 9 : c’est le pivot de toute migration.

Prérequis PrestaShop 9 : PHP, extensions et base de données

La liste ci-dessous est celle de la page « System requirements » de PrestaShop 9, valable pour une installation neuve comme pour une mise à jour. Sur un serveur que vous administrez, vérifiez chaque ligne avant de commencer.

Composant	Minimum pour PrestaShop 9	Conseil côté hébergement
PHP	8.1 (9.0 accepte jusqu’à 8.4, 9.1 jusqu’à 8.5)	Visez 8.3 ou 8.4 : branches corrigées, acceptées par les modules récents
Extensions PHP	curl, dom, fileinfo, gd, iconv, intl, json, mbstring, openssl, pdo, pdo_mysql, simplexml, zip	Activées par défaut dans les PHP de Plesk ; `intl` et `zip` manquent souvent sur un serveur monté à la main
Réglages PHP	`allow_url_fopen = On`, `memory_limit` 512M minimum	PrestaShop 8 se contentait de 256M
Base de données	MySQL 5.7 ou MariaDB 10.2 minimum	Préférez une version récente ; InnoDB pour toutes les tables
Serveur web	Apache 2.4 ou nginx 1.0 et plus	Apache avec `mod_rewrite` reste le plus simple pour les URL simplifiées

Vérifier l’environnement avant d’installer

Le projet fournit un script de diagnostic, phppsinfo.php, référencé depuis la page des prérequis : déposez-le à la racine du site, lisez la liste des manques, puis supprimez-le. Dans Plesk, ouvrez Sites web & domaines, puis Paramètres PHP : la version et le mode d’exécution sont affichés pour chaque domaine. Une boutique PrestaShop 9 sous PHP 8 doit tourner en FPM, plus rapide que le mode CGI.

Réglages PHP : mémoire, upload et temps d’exécution

Les valeurs par défaut de PHP conviennent à un site vitrine, pas à une boutique qui manipule des images, des exports CSV, des archives de modules et des mises à jour longues. Voici les valeurs que nous appliquons en général, dans Paramètres PHP de Plesk, domaine par domaine.

Directive	Valeur conseillée	Pourquoi
`memory_limit`	512M, 768M si gros catalogue	Minimum officiel ; l’import CSV et la régénération des miniatures dépassent vite 256M
`upload_max_filesize` et `post_max_size`	64M à 128M, la seconde au moins égale à la première	Archives de thèmes et de modules, images haute définition
`max_execution_time`	120 s en production, 300 s pendant une mise à jour	L’Update Assistant découpe le travail en étapes, mais certaines restent longues
`display_errors`	Off	Les erreurs vont dans les journaux, jamais à l’écran des clients

Sous CloudLinux, la mémoire réellement disponible dépend aussi de la limite LVE du compte, indépendante de memory_limit. C’est une des raisons pour lesquelles l’hébergement e-commerce NovaHoster réserve aux boutiques PrestaShop et WooCommerce des ressources garanties, plus larges que celles d’un pack web classique.

Apache, nginx, .htaccess et HTTPS

PrestaShop génère lui-même son fichier .htaccess à partir du back-office (Paramètres de la boutique, puis Trafic & SEO, section URL simplifiées). Ce fichier porte les règles de réécriture des URL, les en-têtes de cache navigateur et la compression. Trois conséquences :

Sous Apache, mod_rewrite et AllowOverride All doivent être actifs, sinon toutes les pages hors accueil répondent en erreur 404. C’est le cas par défaut sur les hébergements Plesk.
Sous nginx seul, le .htaccess est ignoré : il faut reporter les règles dans la configuration du serveur, dont la documentation développeur donne un exemple. Sinon, gardez nginx devant Apache, configuration standard de Plesk : Apache lit le .htaccess, nginx sert les fichiers statiques.
Ne modifiez pas le .htaccess entre les balises générées par PrestaShop : il est réécrit à chaque sauvegarde des réglages. Vos règles personnelles vont au-dessus de la section # ~~start~~.

HTTPS sur toute la boutique

Un tunnel de commande servi en HTTP est refusé par la plupart des modules de paiement. Dans Plesk, activez le certificat Let’s Encrypt inclus pour le domaine et le sous-domaine www, puis cochez dans le back-office Activer le SSL et Activer le SSL sur toutes les pages. Un domaine saisi sans https dans Trafic & SEO provoque des boucles de redirection et des paniers vidés.

Tâches planifiées, OPcache et cache PrestaShop

Le cœur de PrestaShop fonctionne sans tâche planifiée, mais une boutique réelle en utilise presque toujours : indexation de la recherche, plan de site, paniers abandonnés, flux marketplace. Chaque module indique l’URL ou la commande à appeler. Dans Plesk, créez-les dans Tâches planifiées avec la version de PHP du domaine, et non le PHP système.

# Appel d’une URL de module toutes les heures
0 * * * * curl -s "https://www.votre-boutique.fr/module/monmodule/cron?token=XXXX" > /dev/null

Deux caches, deux rôles

OPcache est le cache de code de PHP, actif sur toutes les versions PHP 8.x des hébergements NovaHoster. Sur un serveur que vous gérez, vérifiez opcache.enable=1 et réservez-lui au moins 128 Mo : PrestaShop 9 et ses dépendances Symfony représentent plusieurs milliers de fichiers.
Le cache PrestaShop se règle dans Paramètres avancés, puis Performances : cache Smarty, combinaison des CSS et JavaScript, cache serveur optionnel. Mal réglé, il est la première cause de panier qui se vide. Le guide pour configurer PrestaShop, le paiement et le cache sans casser le panier indique les réglages à activer et ceux à laisser désactivés en production.

Après une mise à jour majeure, videz le cache PrestaShop et redémarrez PHP-FPM depuis Plesk : un cache de templates hérité de PrestaShop 8 provoque des pages blanches sur PrestaShop 9.

Dimensionner l’hébergement PrestaShop 9 selon le catalogue et le trafic

Il n’existe pas de chiffre universel : une boutique de 200 références avec déclinaisons, cinq langues et recherche à facettes consomme plus qu’un catalogue de 2 000 produits simples. Les ordres de grandeur ci-dessous sont ceux que nous observons en général, à ajuster après quelques semaines de mesures.

Profil	Catalogue et trafic typiques	Ressources à viser	Formule adaptée
Petite boutique	Moins de 1 000 références, quelques centaines de visites par jour	2 processeurs logiques, 2 à 4 Go de mémoire, NVMe, PHP-FPM	Hébergement e-commerce NovaHoster : ressources garanties, Plesk et sauvegardes quotidiennes inclus
Boutique moyenne	1 000 à 20 000 références, plusieurs milliers de visites par jour, multi-langue ou multi-boutique	4 processeurs logiques, 8 Go ou plus, base de données sur NVMe, cache serveur	Formule e-commerce supérieure, ou serveur VPS dédié à la boutique avec infogérance
Forte saisonnalité	Pics concentrés (soldes, fêtes, campagnes), catalogue de toute taille	Capacité calée sur le pic : 8 processeurs et 16 Go et plus, base de données isolée, surveillance	Serveur dédié en France ou VPS puissant, avec infogérance serveur pour le monitoring et les incidents

Ce qui fait monter la charge, en général : la base de données, lue à chaque affichage de catégorie, d’où l’intérêt du NVMe ; les imports CSV et régénérations d’images lancés en journée, à planifier la nuit ; les modules de recherche ou de recommandations, qui peuvent doubler les requêtes SQL par page. Si la boutique reste lente alors que les ressources paraissent suffisantes, le guide pour diagnostiquer un e-commerce lent et traiter les incidents décrit la méthode de mesure et les erreurs à éviter en urgence.

Pourquoi PrestaShop 1.7 et 8 bloquent sur PHP 8.1

PrestaShop 8 a été conçu pour PHP 7.2.5 à 8.1, et sa grille officielle marque PHP 8.2 et suivants comme non pris en charge : des bibliothèques embarquées, le moteur de templates et de nombreux modules s’appuient sur des comportements retirés de PHP 8.2. Forcer PHP 8.3 sur une boutique PrestaShop 8 donne en général une page blanche, un back-office inaccessible ou des erreurs au paiement. PrestaShop 1.7.8 s’arrête encore plus tôt, à PHP 7.4.

Jusqu’en 2025, PHP 8.1 recevait des correctifs de sécurité. La faille PHP2Shell d’octobre 2026, qui permet l’exécution de commandes à distance sans authentification, n’a été corrigée que dans PHP 8.2, 8.3, 8.4 et 8.5. Une boutique PrestaShop 8 est donc coincée : elle ne peut pas monter de branche sans casser, ni rester sur sa branche sans rester vulnérable. Le pare-feu applicatif Imunify360 et une restriction d’accès au back-office réduisent l’exposition le temps de migrer, mais ne remplacent pas le correctif.

Migrer PrestaShop 8 vers 9 : la méthode côté serveur

L’outil officiel s’appelle aujourd’hui Update Assistant. C’est l’ancien module « 1-Click Upgrade », dont le nom technique reste autoupgrade. Il s’installe comme un module ordinaire et enchaîne cinq étapes : choix de version, options, sauvegarde, mise à jour, post-mise à jour. Il ne propose que les versions compatibles avec le PHP du serveur, d’où l’ordre ci-dessous. La procédure couvre la partie hébergement ; le détail module par module relève de votre agence.

Sauvegarde complète hors du serveur. Export de la base depuis Plesk ou phpMyAdmin, archive des fichiers, copie téléchargée sur votre poste. L’Update Assistant fait sa propre sauvegarde dans /votre-dossier-admin/autoupgrade/backup, mais elle est sur le même disque que la boutique.
Copie sur un sous-domaine de test. Créez test.votre-boutique.fr dans Plesk, copiez les fichiers, importez la base dans une base distincte. Adaptez app/config/parameters.php puis la table ps_shop_url (domaine, domaine SSL, chemin). Protégez le sous-domaine par mot de passe, bloquez son indexation et passez les modules de paiement en mode test : aucun paiement réel ne doit partir de la copie.
Passage sur PHP 8.1, le pivot. Réglez le sous-domaine sur PHP 8.1 dans Plesk et vérifiez que la boutique fonctionne encore. Une boutique 1.7 doit d’abord être mise à jour vers PrestaShop 8 sur PHP 7.4, puis passée sur 8.1.
Mise à jour vers PrestaShop 9. Montez temporairement max_execution_time à 300 et memory_limit à 768M, activez le mode maintenance, lancez l’Update Assistant et choisissez la version marquée « recommandée ». Sur une grosse boutique, préférez le mode ligne de commande du module via SSH, moins sensible aux coupures de session.
Passage sur une branche PHP corrigée. PrestaShop 9 en place, réglez le sous-domaine sur PHP 8.3 ou 8.4. Videz le cache, réactivez les modules désactivés par la mise à jour, repérez ceux désinstallés pour incompatibilité et cherchez leur version PrestaShop 9.
Tests du tunnel de commande. Créez un compte client, ajoutez un produit avec déclinaison, appliquez un code promo, choisissez un transporteur, payez avec chaque module en mode test, vérifiez l’e-mail de confirmation et la facture PDF. Testez aussi la connexion d’un client existant.
Bascule. Mettez la production en maintenance, sauvegardez sa base à jour, rejouez la mise à jour sur la production selon le même chemin. Réglez le domaine principal sur la même version de PHP que le test, régénérez le .htaccess, contrôlez les tâches planifiées et sortez de maintenance.

Liste de contrôle avant de basculer en production

À passer sur la copie de test, puis une seconde fois sur la production après bascule. Chaque point correspond à un incident déjà rencontré.

Version de PHP du domaine principal, du sous-domaine www et des tâches planifiées : 8.3 ou 8.4, mode FPM.
Extensions intl, zip, gd et pdo_mysql présentes dans Paramètres PHP.
memory_limit au moins 512M, max_execution_time redescendu à sa valeur de production.
Dossier install supprimé, dossier d’administration renommé, accès au back-office restreint par IP ou mot de passe Plesk.
Certificat Let’s Encrypt valide, redirection HTTP vers HTTPS, URL de la boutique en HTTPS dans Trafic & SEO.
.htaccess régénéré, URL simplifiées testées sur une fiche produit, une catégorie et une page CMS.
Mode debug désactivé, display_errors à Off.
Modules de paiement repassés en production, URL de notification pointant vers le domaine définitif.
E-mails transactionnels envoyés en SMTP authentifié avec SPF et DKIM, réception testée.
Tâches planifiées recréées dans Plesk avec la bonne version de PHP.
Sauvegarde quotidienne active, restauration testée une fois sur le sous-domaine.
Mode maintenance désactivé, puis contrôle des journaux d’erreurs une heure et vingt-quatre heures après la bascule.

Erreurs fréquentes après le passage à PrestaShop 9

Symptôme	Cause habituelle	Correction
Page blanche sur tout le site après la mise à jour	Cache Smarty ou OPcache hérité, ou extension PHP absente	Vider `var/cache`, redémarrer PHP-FPM, comparer les extensions avec la liste des prérequis
L’Update Assistant ne propose aucune version 9	Le serveur est sur PHP 7.4 ou plus ancien	Passer le domaine sur PHP 8.1 avant de relancer le module
Erreur 500 sur les fiches produit, accueil correct	Module de thème ou de catalogue incompatible	Activer le mode debug sur la copie, lire le message, chercher la version PrestaShop 9 du module
Erreur 404 partout sauf sur l’accueil	`.htaccess` non régénéré ou `mod_rewrite` inactif	Enregistrer à nouveau les réglages d’URL simplifiées
Panier vidé à l’étape paiement	Domaine ou cookie mal réglé après la bascule HTTPS, cache trop agressif	Vérifier `ps_shop_url` et les réglages de cookie

Si la copie de test échoue et que la cause ne se trouve pas en une heure, arrêtez. Restaurez la copie, notez le message exact du journal et contactez le support 7j/7 depuis l’Espace client, en indiquant le sous-domaine, la version de PHP, les versions de PrestaShop de départ et d’arrivée et l’erreur. Sur un VPS ou un serveur dédié, l’infogérance prend en charge la partie système et PHP ; la mise à jour de PrestaShop et de ses modules reste à planifier avec votre agence.

Questions fréquentes

Quelle version de PHP pour PrestaShop 9 ?

PrestaShop 9.0 accepte PHP 8.1 à 8.4 et recommande 8.4 ; PrestaShop 9.1 ajoute PHP 8.5. Visez 8.3 ou 8.4 : ces branches reçoivent les correctifs de sécurité, dont celui de la faille PHP2Shell, et la plupart des modules récents les prennent en charge. PHP 8.1 ne doit servir que de version de transition pendant la migration.

PrestaShop 8 fonctionne-t-il avec PHP 8.2 ou 8.3 ?

Non. La grille officielle de PrestaShop 8 s’arrête à PHP 8.1 et marque 8.2 et suivants comme non pris en charge. En pratique, forcer PHP 8.2 ou 8.3 provoque des pages blanches, un back-office inaccessible ou des erreurs au paiement. La seule façon de bénéficier d’un PHP corrigé est de migrer vers PrestaShop 9.

Peut-on migrer directement PrestaShop 1.7 vers 9 ?

L’Update Assistant ne propose que les versions compatibles avec le PHP du serveur, et PrestaShop 1.7 ne tourne pas au-delà de PHP 7.4. Le chemin habituel passe par PrestaShop 8 sur PHP 7.4, puis PHP 8.1, puis PrestaShop 9, puis PHP 8.3 ou 8.4. Chaque étape se teste sur une copie avant de toucher la production.

Quel hébergement choisir pour une boutique PrestaShop 9 ?

Pour une boutique de moins d’un millier de références et quelques centaines de visites par jour, un hébergement e-commerce avec ressources garanties, NVMe, PHP-FPM et sauvegardes quotidiennes suffit en général. Au-delà, ou en cas de pics saisonniers marqués, un VPS ou un serveur dédié avec infogérance permet de dimensionner la base de données et la mémoire pour le pic.

Combien de mémoire PHP faut-il pour PrestaShop 9 ?

Le projet recommande un memory_limit d’au moins 512M, contre 256M pour PrestaShop 8. Montez à 768M le temps d’une mise à jour ou d’un gros import CSV. Sur un hébergement mutualisé, vérifiez aussi la limite mémoire globale du compte, car memory_limit ne peut pas dépasser ce que le compte autorise réellement.

Faut-il nginx ou Apache pour PrestaShop 9 ?

Les deux sont pris en charge : Apache 2.4 ou nginx 1.0 et plus. Apache lit le fichier .htaccess généré par PrestaShop, ce qui simplifie les URL simplifiées et les redirections. Avec nginx seul, ces règles doivent être réécrites dans la configuration du serveur. La configuration Plesk, nginx devant Apache, combine les deux sans réglage particulier.

Le module 1-Click Upgrade existe-t-il encore ?

Oui, sous un nouveau nom. Le module officiel s’appelle désormais Update Assistant ; son nom technique reste autoupgrade. Il s’installe depuis la marketplace du back-office ou depuis le dépôt GitHub du projet, propose une sauvegarde intégrée, fonctionne en interface web ou en ligne de commande, et affiche une liste de contrôle post-mise à jour.

La migration gratuite NovaHoster met-elle PrestaShop à jour ?

Non. La migration gratuite déplace la boutique telle quelle, fichiers, base de données et e-mails, en 24 heures et sans coupure. La montée de version vers PrestaShop 9 est une opération distincte, à réaliser ensuite sur une copie de test avec l’Update Assistant, ou à confier à votre agence ; le support peut vous aider sur la partie PHP et serveur.

Guides liés

Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :

Sources techniques

[1] PrestaShop Project — System requirements for PrestaShop 9 [2] PrestaShop Project — System requirements for PrestaShop 8 [3] PrestaShop Project — Update from the back office (Update Assistant) [4] PrestaShop Project — Post-update checklist [5] PrestaShop Project — Nginx configuration for PrestaShop 9 [6] PHP Group — Supported versions

Votre situation ne correspond pas exactement à ce guide ?

Les options visibles et les formules dépendent de votre abonnement. Faites vérifier le contexte depuis l’Espace client, sans transmettre de mot de passe.

Demander une vérification

Héberger PrestaShop 9 : prérequis techniques, dimensionnement et migration depuis PrestaShop 1.7 ou 8