Configuration requise pour PrestaShop 9 : PHP, MySQL et hébergement

Choisir un hébergement pour PrestaShop 9 ne devrait pas commencer par une étiquette marketing comme « hébergement e-commerce » ou « optimisé pour PrestaShop ».

Il faut commencer par les exigences réelles de l’application.

PrestaShop 9 repose sur une pile technique modernisée comprenant PHP 8.x, Symfony 6.4, MySQL ou MariaDB, et une architecture applicative plus exigeante que celle d’un simple site vitrine. Un serveur capable d’installer techniquement PrestaShop n’est pas nécessairement capable de faire fonctionner une véritable boutique de façon fiable.

Ce guide présente les exigences système officielles de PrestaShop 9 et explique surtout comment transformer ces exigences minimales en un environnement de production adapté.

Note de version : cet article a été vérifié le 22 septembre 2026. La page officielle actuelle des exigences recommande PHP 8.5 pour PrestaShop 9.1. PrestaShop 9.1.5 est la dernière version stable de la branche 9.1 au moment de la rédaction.

Exigences de PrestaShop 9 en un coup d’œil

La documentation officielle actuelle de PrestaShop 9 indique les exigences de base suivantes :

Composant	Exigence de PrestaShop 9
Serveur Web	Apache 2.4+ recommandé ; Nginx pris en charge
PHP	Dépend de la branche PrestaShop 9.x
Version PHP recommandée pour PrestaShop 9.0	PHP 8.4
Version PHP recommandée pour PrestaShop 9.1	PHP 8.5
Base de données	MySQL 5.7 minimum ou MariaDB 10.2 minimum
Limite de mémoire PHP	Au moins 512 Mo recommandés par script
Système d’exploitation	Les systèmes de type Unix, comme Linux, sont à privilégier
HTTPS	Fortement recommandé pour toutes les boutiques en production

Ces valeurs constituent un point de départ.

Une boutique proposant 500 produits et recevant dix commandes par jour peut fonctionner confortablement sur une infrastructure modeste.

Une boutique avec :

100 000 produits ;
des millions de fichiers image ;
des milliers de déclinaisons ;
des imports XML de fournisseurs ;
une synchronisation avec les marketplaces ;
plusieurs boutiques ;
une intégration ERP ;
des tâches cron volumineuses ;
de nombreux utilisateurs du Back Office ;

présente un profil de consommation des ressources complètement différent.

Compatibilité PHP de PrestaShop 9

PHP est l’un des premiers éléments à vérifier avant d’installer ou de mettre à niveau PrestaShop 9.

PrestaShop 9.0

Le tableau officiel de compatibilité indique actuellement :

PHP 8.1 — pris en charge
PHP 8.2 — pris en charge
PHP 8.3 — pris en charge
PHP 8.4 — recommandé
PHP 8.5 — non pris en charge pour la version 9.0

PrestaShop 9.1

Le tableau actuel indique :

PHP 8.1 — pris en charge
PHP 8.2 — pris en charge
PHP 8.3 — pris en charge
PHP 8.4 — pris en charge
PHP 8.5 — recommandé

Cette distinction est importante.

Ne vous contentez pas de demander à votre hébergeur s’il « prend en charge PHP 8 ».

Vous devez connaître :

la version exacte de PrestaShop ;
la version exacte de PHP ;
la compatibilité de vos modules avec cette version de PHP ;
l’existence éventuelle de problèmes de compatibilité PHP dans votre thème ou votre code personnalisé.

Faut-il toujours utiliser la version PHP recommandée ?

Pour une nouvelle installation, utiliser la version de PHP recommandée est généralement un bon choix par défaut.

Pour une boutique déjà en production, effectuez d’abord des tests.

Un module peut être compatible avec PrestaShop 9.1 tout en contenant du code qui ne fonctionne pas sous PHP 8.5.

Les problèmes de compatibilité PHP courants comprennent :

des types de paramètres plus stricts ;
la valeur null transmise lorsqu’une chaîne ou un nombre est requis ;
des fonctions supprimées ou obsolètes ;
des problèmes de propriétés dynamiques ;
des dépendances Composer incompatibles ;
d’anciennes bibliothèques de fournisseurs ;
des signatures de méthodes non valides.

La bonne procédure est la suivante :

cloner la production → passer le staging à la version PHP cible → tout tester → déployer

Ne changez pas directement PHP sur une boutique à fort chiffre d’affaires simplement parce que le panneau d’hébergement présente l’opération comme un menu déroulant sans conséquence.

Vérifier séparément PHP Web et PHP CLI

C’est une source fréquente de confusion.

La version de PHP utilisée par votre site peut être différente de celle utilisée dans SSH ou les tâches cron.

Par exemple :

php -v

peut afficher PHP 8.3 alors que PHP-FPM, qui sert le site, utilise PHP 8.5.

De même, une commande cron telle que :

php /var/www/shop/bin/console ...

peut utiliser accidentellement le binaire PHP par défaut du serveur plutôt que la version configurée pour la boutique.

Vérifiez toujours :

PHP pour le Web ;
PHP en ligne de commande (CLI) ;
PHP utilisé par cron ;
PHP des processus supervisor et des workers de file d’attente.

Ces composants doivent utiliser des versions choisies et testées intentionnellement.

Limite de mémoire PHP : pourquoi 512M est important

La documentation actuelle de PrestaShop 9 recommande de définir la valeur PHP memory_limit à au moins :

memory_limit = 512M

Cette limite s’applique à chaque processus PHP, et non à la mémoire totale du serveur.

Cette distinction est extrêmement importante.

Supposons que vos workers PHP-FPM puissent consommer jusqu’à 512 Mo chacun.

Si vous configurez 30 workers PHP simultanés, la consommation théorique de mémoire par PHP devient très importante.

En pratique, la plupart des requêtes utiliseront beaucoup moins de mémoire, mais vous devez tout de même dimensionner le pool de workers selon la consommation mesurée.

Ne résolvez pas les problèmes de mémoire en augmentant indéfiniment la limite

Si un processus d’import atteint régulièrement 512 Mo, la solution n’est pas forcément :

memory_limit = 2048M

Le véritable problème peut être un code qui charge en mémoire un fichier XML fournisseur entier ou tous les produits.

Une meilleure architecture consiste à :

Fichier fournisseur
    ↓
Analyseur en flux
    ↓
Lot de produits
    ↓
Traiter
    ↓
Enregistrer la progression
    ↓
Lot suivant

Cela permet de maintenir une consommation de mémoire prévisible.

Le même principe s’applique aux :

imports CSV ;
régénérations d’images ;
exports de catalogues ;
générations de sitemaps ;
grosses opérations de base de données.

Exigences MySQL

La version minimale officiellement requise actuellement pour PrestaShop 9 est :

MySQL 5.7

Cependant, la documentation recommande d’utiliser une version récente de la base de données.

C’est une recommandation judicieuse.

La version minimale sert à définir les limites de compatibilité, mais une nouvelle infrastructure de production ne devrait pas être conçue volontairement autour d’une version de base de données obsolète, sauf contrainte technique particulière.

Votre version de base de données doit également être prise en charge par :

votre système d’exploitation ;
votre hébergeur ;
vos outils de sauvegarde ;
votre système de surveillance ;
votre stratégie de réplication, le cas échéant.

Exigences MariaDB

PrestaShop 9 indique actuellement :

MariaDB 10.2 minimum

Là encore, privilégiez si possible une version moderne et prise en charge pour un nouveau déploiement en production.

Ne choisissez pas entre MySQL et MariaDB uniquement sur la base d’articles de benchmarks.

La maîtrise de l’exploitation compte davantage.

Utilisez le moteur de base de données que votre équipe ou votre hébergeur sait :

surveiller ;
sauvegarder ;
restaurer ;
optimiser ;
mettre à niveau en toute sécurité.

Les performances de la base de données ne se résument pas aux numéros de version

Une version moderne de base de données ne peut pas compenser une mauvaise architecture de données.

Les facteurs importants comprennent :

la taille du buffer pool InnoDB ;
la latence du disque ;
la RAM disponible ;
la surveillance des requêtes lentes ;
la taille des tables ;
les index ;
les limites de connexions ;
le comportement des tables temporaires ;
la conception des requêtes.

PrestaShop peut générer de grands volumes de données même avec un nombre modéré de produits.

Un produit peut être représenté dans :

les tables de produits ;
les tables de langues ;
les tables de boutiques ;
les associations de catégories ;
les tables d’images ;
les tables de caractéristiques ;
les tables d’attributs ;
les tables de stock ;
les tables propres aux modules.

Un catalogue de 100 000 produits peut donc représenter des millions de lignes associées.

Utiliser le journal des requêtes lentes

Pour les grandes boutiques, l’optimisation de la base de données doit reposer sur des éléments concrets.

Activez et analysez le journal des requêtes lentes de manière contrôlée.

Recherchez les requêtes exécutées lors :

du chargement des catégories ;
de la recherche ;
de la modification des produits ;
de l’affichage des listes de commandes ;
des importations ;
de la synchronisation des stocks ;
de la génération des flux.

Analysez-les ensuite à l’aide de :

EXPLAIN

N’installez pas de packs d’index téléchargés au hasard sur Internet.

Un index doit correspondre à une requête réellement exécutée par votre boutique.

Exigences Apache

La documentation officielle de PrestaShop indique actuellement :

Apache 2.4 ou version ultérieure

Apache reste une plateforme parfaitement adaptée à PrestaShop.

Le serveur web doit prendre en charge la réécriture d’URL requise et disposer d’une configuration permettant aux URL conviviales et aux règles de sécurité de PrestaShop de fonctionner correctement.

Les points importants comprennent :

les règles de réécriture ;
les redirections HTTPS ;
la mise en cache des ressources statiques ;
les limites de téléversement ;
les limites de taille du corps des requêtes ;
la compression ;
les contrôles d’accès.

Si vous utilisez Apache avec PHP-FPM, surveillez les deux couches indépendamment.

PrestaShop 9 peut-il fonctionner sur Nginx ?

Oui.

PrestaShop prend en charge Nginx, et la documentation officielle des développeurs fournit un exemple avancé de configuration Nginx.

Nginx est couramment utilisé pour :

le proxy inverse ;
la distribution des ressources statiques ;
PHP-FPM ;
la terminaison TLS ;
la mise en cache ;
la limitation du débit des requêtes.

Un point important pour PrestaShop 9 concerne la gestion des images.

Comme PrestaShop 9 prend en charge des formats modernes tels que WebP et AVIF, vos règles de réécriture et votre configuration des fichiers statiques doivent traiter correctement ces extensions d’image.

Ne copiez pas une ancienne configuration Nginx de PrestaShop 1.7 sans l’examiner.

Apache ou Nginx pour PrestaShop 9

Il n’existe pas de gagnant universel.

Une installation Apache bien configurée peut surpasser une installation Nginx mal configurée, et inversement.

Choisissez en fonction :

de l’expérience de l’administrateur ;
du support proposé par l’hébergeur ;
des outils de déploiement ;
de l’architecture de mise en cache ;
de l’observabilité.

Pour de nombreuses boutiques, les principaux problèmes de performance ne viennent pas du serveur web.

Ils proviennent notamment :

de modules lents ;
de requêtes SQL inefficaces ;
d’images trop volumineuses ;
d’un trop grand nombre de processus PHP ;
d’importations lourdes ;
de disques lents.

Extensions PHP requises

PrestaShop nécessite plusieurs extensions PHP pour fonctionner correctement.

La documentation officielle répertorie explicitement les extensions suivantes :

OpenSSL ;
PDO ;
PDO MySQL ;
SimpleXML ;
Zip.

Votre environnement d’hébergement peut également nécessiter d’autres extensions courantes utilisées par PrestaShop et ses modules.

Par exemple :

cURL ;
GD ;
Intl ;
Mbstring ;
DOM ;
Fileinfo ;
prise en charge de JSON fournie par les versions modernes de PHP.

Avant l’installation, utilisez l’outil officiel de vérification des prérequis de PrestaShop au lieu de supposer qu’un paquet PHP générique contient tout le nécessaire.

`allow_url_fopen`

Les exigences officielles actuelles de PrestaShop 9 précisent :

allow_url_fopen = On

PrestaShop utilise l’accès aux fichiers distants dans certaines parties de son fonctionnement.

La documentation recommande également :

allow_url_include = Off

Il s’agit de paramètres différents.

allow_url_fopen permet aux fonctions PHP compatibles d’accéder à des URL distantes.

allow_url_include permet d’inclure des fichiers distants via les opérations include de PHP et doit rester désactivé.

Limites d’envoi de fichiers PHP

Les boutiques qui importent des produits, modules, thèmes ou fichiers volumineux doivent examiner :

upload_max_filesize
post_max_size
max_execution_time
max_input_time

Ne fixez pas aveuglément toutes les limites à des valeurs énormes.

Pour les grands flux fournisseurs, la CLI est généralement préférable à l’envoi d’un fichier de 1 Go depuis le Back Office.

Un processus robuste télécharge ou reçoit le flux fournisseur de manière contrôlée, puis le traite par lots.

Configuration des workers PHP-FPM

Si vous utilisez PHP-FPM, la capacité des processus de traitement est l’un des paramètres les plus importants.

Parmi les paramètres courants du pool :

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers

Il n’existe pas de valeur universelle correcte.

Mesurez la consommation mémoire réelle des processus PHP.

Par exemple, si un processus occupé consomme en moyenne 150 Mo et que votre machine dispose de 8 Go de RAM, configurer 50 processus PHP serait dangereux en tenant compte de :

MySQL ;
Redis ;
le système d’exploitation ;
le serveur web ;
les tâches cron ;
le cache du système de fichiers.

Manquer de mémoire peut provoquer bien plus de dégâts que faire patienter brièvement un utilisateur jusqu’à la disponibilité d’un processus.

OPcache doit être activé

Un serveur PrestaShop en production doit utiliser PHP OPcache.

OPcache conserve en mémoire le bytecode PHP compilé, évitant à PHP de réanalyser et recompiler chaque fichier à chaque requête.

Pour une grande installation PrestaShop comportant de nombreux modules, OPcache doit disposer de suffisamment de mémoire pour conserver le code utile en cache.

Surveillez :

l’utilisation mémoire d’OPcache ;
le nombre de scripts en cache ;
la fréquence des redémarrages ;
le taux de réussite du cache.

Ne vous contentez pas de l’activer en supposant que la configuration par défaut est optimale.

RAM du serveur : de combien avez-vous vraiment besoin ?

Les exigences officielles de PrestaShop indiquent en substance qu’une quantité de RAM plus importante est utile et recommandent au moins 512 Mo de mémoire par script PHP.

Cela ne signifie toutefois pas qu’un serveur de production a besoin d’exactement 512 Mo de RAM au total.

Voici un aperçu pratique approximatif :

Petite boutique

Une petite boutique à faible trafic peut fonctionner avec :

2 à 4 Go de RAM ;
un nombre limité de processus PHP ;
une base de données modeste ;
peu de tâches en arrière-plan.

Boutique moyenne

Une boutique plus active peut bénéficier de :

4 à 8 Go de RAM ;
plus de processus PHP ;
un cache InnoDB plus important ;
Redis ;
des imports réguliers.

Grand catalogue ou boutique très fréquentée

Les boutiques disposant de grands catalogues et d’une automatisation intensive peuvent avoir besoin de :

8 à 32 Go de RAM, voire davantage ;
ressources dédiées à la base de données ;
processus distincts pour les tâches ;
pools PHP correctement dimensionnés.

Il ne s’agit pas d’exigences officielles de PrestaShop.

Ce sont des exemples de planification des capacités.

La bonne réponse dépend des mesures de votre charge de travail.

Exigences CPU

PrestaShop n’exige pas de modèle de processeur particulier.

L’important, c’est la charge de travail.

PHP tire profit de performances élevées par cœur, tandis que le trafic simultané et les tâches en arrière-plan bénéficient de cœurs supplémentaires.

Les tâches gourmandes en CPU comprennent :

le redimensionnement des images ;
l’encodage AVIF ;
les imports volumineux ;
la génération de flux ;
l’indexation de la recherche ;
la reconstruction du cache ;
le traitement XML.

Si une boutique gère le trafic des clients et plusieurs imports lourds simultanément, des cœurs supplémentaires peuvent fournir une marge de capacité utile.

Stockage : SSD ou NVMe

Pour un hébergement PrestaShop moderne, le SSD doit être considéré comme le minimum de référence.

Le NVMe est particulièrement utile pour :

les grandes bases de données ;
les nombreuses lectures/écritures aléatoires ;
les catalogues riches en images ;
les charges utilisant intensivement le cache ;
une forte concurrence.

Les disques durs mécaniques peuvent encore servir aux sauvegardes ou à l’archivage, mais sont mal adaptés aux bases de données d’une boutique en activité.

Surveiller l’utilisation des inodes

Les installations PrestaShop contenant beaucoup d’images peuvent générer un nombre immense de fichiers.

Chaque image de produit peut générer plusieurs variantes.

Si vous avez :

100,000 produits
× 3 images
× 8 types d'images

vous pouvez facilement atteindre des millions de fichiers générés.

Certaines offres d’hébergement imposent des limites d’inodes.

Un serveur peut donc afficher beaucoup d’espace disque libre tout en refusant de créer de nouveaux fichiers parce que le quota d’inodes est épuisé.

Surveillez les deux indicateurs :

la capacité de stockage ;
la consommation d’inodes.

Formats d’image dans PrestaShop 9

PrestaShop 9 a introduit la prise en charge native de :

WebP ;
AVIF.

Ces formats peuvent réduire considérablement le volume des images transférées.

Cependant, l’encodage AVIF peut exiger davantage de CPU.

Si vous régénérez des centaines de milliers d’images, planifiez l’opération pendant une maintenance ou comme tâche CLI plutôt que pendant les pics de trafic.

Planification de l’espace disque

Ne dimensionnez pas le stockage uniquement selon le répertoire actuel d’images de produits.

Prenez également en compte :

la base de données ;
les journaux ;
le cache ;
les imports temporaires ;
les sauvegardes ;
les miniatures générées ;
les copies de préproduction ;
les versions de déploiement ;
les fichiers d’exportation.

Un serveur fiable a besoin d’espace libre supplémentaire.

Une utilisation permanente de 90 à 95 % du disque laisse peu de place aux opérations temporaires et accroît le risque d’incident.

Système d’exploitation

La documentation officielle de PrestaShop indique que la plateforme fonctionne mieux sur des systèmes basés sur Unix, tels que :

Linux ;
macOS.

Pour l’hébergement en production, Linux est le choix habituel.

Windows peut fonctionner dans certains scénarios, mais ne bénéficie pas du même niveau de prise en charge active.

Une pile logicielle de production classique peut utiliser :

Linux
Nginx ou Apache
PHP-FPM
MySQL/MariaDB
Redis
Cron/systemd

Un hébergement mutualisé suffit-il ?

Un hébergement mutualisé peut suffire pour :

un petit catalogue ;
un faible trafic ;
une automatisation minimale ;
un petit nombre de modules.

Les limites apparaissent généralement lorsqu’il vous faut :

des tâches CLI de longue durée ;
des paramètres PHP personnalisés ;
des limites élevées de processus ;
Redis ;
des imports volumineux ;
SSH ;
une configuration Nginx personnalisée ;
la supervision des processus ;
une surveillance détaillée.

Une offre mutualisée peut annoncer beaucoup d’espace disque tout en imposant de fortes restrictions sur le CPU ou le temps d’exécution.

Lisez les limites réelles.

Quand choisir un VPS ?

Un VPS est utile lorsque vous avez besoin d’un contrôle prévisible sur :

la version de PHP ;
PHP-FPM ;
la configuration de la base de données ;
cron ;
Redis ;
le système de fichiers ;
le serveur web ;
les journaux ;
les outils de sécurité.

Pour les boutiques réalisant d’importantes importations, utilisant des modules personnalisés ou proposant des dizaines de milliers de produits, un VPS devient souvent plus adapté qu’un hébergement mutualisé contraignant.

Il facilite également la standardisation des environnements de développement et de production.

Serveur dédié ou infrastructure cloud

Un serveur dédié ou un environnement cloud plus important devient intéressant lorsque :

le trafic reste constamment élevé ;
les tâches sur le catalogue sont lourdes ;
la base de données est volumineuse ;
de nombreux employés travaillent dans le Back Office ;
les exigences de disponibilité sont strictes.

Ne divisez pas tout en microservices au seul motif que la boutique est grande.

Une machine unique puissante, dotée d’une base de données bien configurée, peut être plus simple à maintenir qu’une architecture distribuée inutilement complexe.

Adaptez l’infrastructure à l’échelle lorsque les mesures le justifient.

Redis et mise en cache

Redis peut être utile dans des architectures qui l’emploient correctement pour :

le cache ;
les sessions ;
les files de tâches ;
les verrous.

Ce n’est pas un interrupteur universel qui « accélère PrestaShop ».

Si une page produit passe l’essentiel de son temps à exécuter une requête SQL sans index, Redis ne résoudra pas la cause du problème.

Mettez en cache après avoir mesuré où le temps est consommé.

CDN

Un CDN est utile pour les ressources statiques telles que :

les images des produits ;
CSS ;
JavaScript ;
les polices.

Ses avantages comprennent :

une réduction du trafic vers le serveur d’origine ;
une livraison plus rapide aux visiteurs éloignés ;
un meilleur taux de réussite du cache ;
une baisse de la pression sur la bande passante.

Mais un CDN ne fait pas disparaître les lenteurs de PHP ni des requêtes de base de données.

Mesurez le TTFB séparément du temps de téléchargement des ressources.

Accès cron et CLI

Pour une boutique PrestaShop sérieuse, l’accès SSH et cron est extrêmement précieux.

Les longues tâches devraient plutôt être exécutées via la CLI :

php bin/console ...

ou au moyen de commandes propres aux modules.

Exemples :

imports de produits ;
mises à jour du stock ;
optimisation des images ;
synchronisation des catégories ;
génération de flux ;
maintenance courante.

La CLI permet d’éviter de nombreux délais d’expiration du navigateur et du proxy.

Les grandes boutiques doivent séparer les charges de travail

Si votre boutique importe 100 000 produits chaque nuit, ce travail en arrière-plan rivalise avec le trafic client pour les ressources.

Une meilleure conception utilise :

des lots de taille limitée ;
des files de tâches ;
des limites de processus ;
des verrous ;
des plages horaires creuses.

Par exemple :

Trafic Web → Pool PHP-FPM
Importation de produits → Processus CLI
Traitement des images → Processus dédié
Synchronisation des stocks → Petite tâche cron fréquente
Base de données → Ressource partagée mais surveillée

Cela empêche une tâche géante de monopoliser tout le serveur.

Exigences de sauvegarde

Un hébergement n’est pas complet sans sauvegardes.

Conservez des sauvegardes de :

la base de données ;
les fichiers ;
les images de produits ;
la configuration des modules ;
la configuration de l’environnement.

Ne conservez pas l’unique sauvegarde sur le même disque que le système de production.

Une panne de disque ne doit pas détruire la boutique et sa sauvegarde à la fois.

Tester les restaurations

Un statut de sauvegarde « réussie » prouve seulement qu’un programme a créé un fichier.

Il ne prouve pas que vous pouvez reconstruire la boutique.

Restaurez régulièrement les sauvegardes dans un environnement de test et vérifiez :

l’import de la base de données ;
la présence des images ;
le fonctionnement du Back Office ;
le chargement des modules ;
la connaissance des définitions cron ;
la disponibilité des variables d’environnement.

HTTPS est indispensable en pratique

Une boutique en ligne de production doit fonctionner entièrement en HTTPS.

Cela protège :

les identifiants des comptes ;
les sessions ;
les communications API ;
les données de paiement.

Utilisez une configuration TLS moderne et automatisez le renouvellement des certificats.

Vérifiez également que :

HTTP redirige vers HTTPS ;
les URL canoniques utilisent HTTPS ;
les liens internes ne créent pas de contenu mixte.

La livraison des e-mails fait partie de l’hébergement

Les confirmations de commande, les réinitialisations de mot de passe, les messages d’assistance et les notifications de compte dépendent d’un envoi fiable des e-mails.

Utilisez un prestataire d’e-mails transactionnels adapté ou un service SMTP correctement configuré.

Surveillez :

les erreurs de livraison ;
l’authentification ;
SPF ;
DKIM ;
DMARC.

Un serveur parfait ne sert à rien si les clients ne reçoivent jamais leurs confirmations de commande par e-mail.

Journaux et surveillance

Une infrastructure PrestaShop en production doit donner accès à :

les journaux d’accès Nginx/Apache ;
les journaux d’erreurs Nginx/Apache ;
les erreurs PHP ;
les journaux PrestaShop ;
les requêtes lentes de la base de données ;
les métriques système ;
les journaux cron.

Surveillez :

le CPU ;
la RAM ;
le disque ;
l’utilisation des inodes ;
la saturation des processus PHP ;
les connexions à la base de données ;
les erreurs HTTP 5xx ;
la durée des tâches.

Sans surveillance, les problèmes de capacité ne sont découverts qu’après les plaintes des clients.

Exigences de développement

Si vous travaillez avec une version de développement de PrestaShop plutôt qu’avec un paquet de production installé, la documentation officielle mentionne également les outils de développement.

PrestaShop utilise Composer pour les dépendances PHP.

La documentation actuelle précise également Node.js 20.x pour le processus de développement concerné.

Les commerçants installant une version empaquetée de PrestaShop n’ont normalement pas besoin de compiler eux-mêmes toute la plateforme.

Les développeurs de modules et de thèmes doivent toutefois conserver une chaîne d’outils de développement compatible.

Docker pour le développement PrestaShop

Docker peut être extrêmement utile pour le développement et les tests, car il permet de définir explicitement les versions.

Une pile de développement peut figer :

PHP ;
MySQL/MariaDB ;
le serveur web ;
Redis ;
les outils de test des e-mails.

Cela aide à reproduire les bogues et à tester la compatibilité des modules.

Docker peut aussi être utilisé en production, mais la conteneurisation ne rend pas automatiquement une application évolutive.

Vous avez toujours besoin de :

un stockage persistant pour la base de données ;
une stratégie de sauvegarde ;
un stockage pour les images ;
la journalisation ;
une architecture de processus ;
une stratégie de déploiement.

Exemple d’architecture pour une petite boutique en production

Une petite boutique, mais professionnelle, pourrait utiliser :

1 VPS
├── Nginx
├── PHP-FPM
├── PrestaShop 9
├── MariaDB/MySQL
├── Redis
└── cron / Processus CLI

Cette architecture est simple et facile à dépanner.

Exemple d’architecture plus importante

Une boutique plus grande pourrait évoluer vers :

Répartiteur de charge / CDN
        ↓
Serveurs applicatifs
        ↓
PHP-FPM
        ↓
Redis
        ↓
Serveur de base de données
        ↓
Sauvegarde / réplique

Processus séparés :
- importations
- images
- flux
- synchronisation des stocks

N’adoptez pas cette architecture d’emblée si votre trafic et vos opérations ne justifient pas cette complexité supplémentaire.

Liste de contrôle pour l’hébergement de PrestaShop 9

Avant le lancement, vérifiez :

la version exacte de PrestaShop sélectionnée
la version de PHP compatible configurée
la version PHP du serveur web vérifiée
la version PHP de la CLI vérifiée
la version PHP des tâches cron vérifiée
les extensions PHP requises installées
memory_limit au moins 512M lorsque cela convient
allow_url_fopen activé
allow_url_include désactivé
la version MySQL/MariaDB compatible
la sauvegarde de la base de données automatisée
la restauration de la base de données testée
le stockage SSD/NVMe
assez d’espace disque libre
la consommation d’inodes surveillée
OPcache activé
un pool PHP-FPM correctement dimensionné
HTTPS activé
l’envoi d’e-mails transactionnels testé
cron disponible
SSH/CLI disponible pour la maintenance
les journaux du serveur web accessibles
les journaux PHP accessibles
la surveillance des requêtes lentes disponible
la surveillance système active

Questions fréquentes

Quelle version PHP nécessite PrestaShop 9 ?

PrestaShop 9.0 prend en charge PHP 8.1 à PHP 8.4, PHP 8.4 étant recommandé. PrestaShop 9.1 prend en charge PHP 8.1 à PHP 8.5, PHP 8.5 étant recommandé selon le tableau officiel actuel des exigences.

PrestaShop 9 prend-il en charge PHP 8.5 ?

Oui, PrestaShop 9.1 prend en charge PHP 8.5 et le recommande actuellement. PrestaShop 9.0 ne répertorie pas PHP 8.5 parmi les versions prises en charge.

Quelle est la version minimale de MySQL pour PrestaShop 9 ?

Le minimum officiel est MySQL 5.7. Une version récente prise en charge est recommandée pour les nouveaux déploiements.

Quelle est la version minimale de MariaDB ?

Le minimum officiel est MariaDB 10.2.

De combien de mémoire PHP PrestaShop 9 a-t-il besoin ?

La documentation officielle recommande un minimum memory_limit de 512M par script. Le serveur lui-même doit disposer d’assez de RAM pour les processus PHP, la base de données, le système d’exploitation, le cache et les tâches en arrière-plan.

PrestaShop 9 peut-il fonctionner avec Nginx ?

Oui. Nginx est pris en charge et PrestaShop fournit des indications de configuration.

2 Go de RAM suffisent-ils ?

Cela peut suffire à une petite boutique peu fréquentée avec des processus PHP soigneusement limités, mais les besoins en ressources dépendent de la taille du catalogue, des modules, des imports et de la charge de la base de données.

8 Go de RAM suffisent-ils pour 100 000 produits ?

Potentiellement, mais le nombre de produits ne suffit pas à lui seul pour répondre. Les déclinaisons, images, visites, imports, modules, la taille de la base de données et le nombre de processus simultanés comptent.

Ai-je besoin de Redis ?

Non. Redis peut être utile pour le cache, les sessions, les files de tâches ou les verrous dans une architecture adaptée, mais il n’est pas obligatoire pour toutes les boutiques.

Faut-il choisir un hébergement mutualisé ou un VPS ?

L’hébergement mutualisé peut convenir aux petites boutiques. Un VPS est généralement plus pratique lorsque vous avez besoin de maîtriser PHP, cron, Redis, les imports, les journaux et le réglage du serveur.

Guides et ressources connexes sur PrestaShop 9

Tags : Configuration requise PrestaShop 9, Exigences MySQL PrestaShop 9, Hébergement PrestaShop 9, PrestaShop 9, PrestaShop 9 MariaDB, PrestaShop 9 PHP 8.5, Serveur PrestaShop 9, Version PHP PrestaShop 9

Posted in: Mises à jour et mises à niveau PrestaShop