Choisir et configurer un hébergement pour PrestaShop

Ce que nous ferions

Nous commencerions par décider s'il faut améliorer votre hébergement actuel ou en changer, à partir des données de votre boutique : version du cœur, modules, intégrations, thème, données du catalogue, marchés clients et équipe chargée de sa maintenance. Conservez un hébergeur qui répond à vos besoins de compatibilité, de charge maximale mesurée et de reprise. Changez-en lorsqu'une restriction documentée ou un problème de capacité ne peut pas y être résolu et qu'un test représentatif montre que l'hébergeur envisagé y remédie.

Pour une migration ou un changement de configuration important, utilisez une copie de préproduction isolée, répétez l'intervention et convenez des contrôles de validation avant de toucher à la production. Conservez la configuration précédente et une sauvegarde indépendante, planifiez la bascule en tenant compte des mises à jour des commandes et des stocks, et désignez les responsables de la supervision et du retour arrière. Un nouveau contrat d'hébergement ne remplace pas le travail de configuration et de test de la boutique.

Si vous souhaitez un avis étayé pour choisir entre migration et amélioration, le service PrestaShop Hosting & Infrastructure Audit évalue votre installation actuelle ; la migration, les changements de configuration et les frais du prestataire sont distincts.

Préparer un cahier des charges à partir de votre boutique

Transmettez la même fiche aux hébergeurs envisagés et à votre développeur pour que leurs offres couvrent la même charge. Incluez une période récente de forte activité et les pannes à éviter.

Comparer les types d'hébergement et les ressources garanties

Un hébergement mutualisé, un VPS, un serveur dédié et un hébergement infogéré peuvent tous faire fonctionner PrestaShop s'ils répondent à ses exigences. L'étiquette seule ne confirme ni les performances ni la fiabilité.

L'infogérance décrit l'organisation de la maintenance et peut concerner un hébergement mutualisé, un VPS ou un serveur dédié. Un VPS ne fournit pas nécessairement des cœurs de processeur physiques ou des disques dédiés, et une offre infogérée peut limiter l'accès root. Les prestataires distinguent les offres à ressources partagées et dédiées. Demandez les garanties de l'offre précise.

L'infrastructure cloud peut simplifier la création de ressources et les instantanés, mais la montée en charge d'une application exige toujours conception et exploitation. Une seule machine plus puissante ne crée pas de basculement. Choisissez une redondance et un plan de reprise lorsque la disponibilité l'exige.

Comparez les frais de renouvellement, d'infogérance, de stockage des sauvegardes et de migration, ainsi que les limites de trafic. Le seul nombre de produits ne constitue pas un critère fiable pour choisir une gamme d'hébergement. Faites préciser par écrit les limites de ressources, les conditions d'utilisation raisonnable et la configuration réelle de PHP, d'OPcache et de la base derrière les mentions « illimité » ou « optimisé pour PrestaShop ». Demandez si la « migration gratuite » inclut cron, les e-mails, les certificats, les règles de réécriture, les tests d'intégration et la synchronisation finale.

Améliorer, augmenter les ressources ou migrer ?

Faire correspondre les versions PHP et de base de données

Choisissez une version PHP prise en charge par la version exacte du cœur, le thème et chaque module requis. Vérifiez ensuite que la branche PHP reçoit des correctifs de sécurité. Les minimums de compatibilité ne sont pas des recommandations de déploiement sécurisé.

Consultez les prérequis officiels 1.7, 8 et 9. PrestaShop 1.7 est une branche ancienne, pas une recommandation pour une nouvelle boutique.

PHP 8.1 a atteint sa fin de vie amont le 31 décembre 2025. Un hébergeur qui le propose doit expliquer toute maintenance de sécurité assurée en aval. Vérifiez la maintenance des branches PHP plutôt que de supposer qu'une version disponible est maintenue.

PrestaShop 8 et 9 documentent MySQL 5.7 ou MariaDB 10.2 comme minimums de compatibilité SQL. Pour un nouveau déploiement, choisissez une version de base maintenue et testez-la avec votre boutique. MySQL 8.0 est entré en Oracle Sustaining Support le 21 avril 2026 ; consultez l'avis de cycle de vie MySQL pour choisir son remplaçant.

Vérifier les extensions et l'environnement PHP web

Pour PrestaShop 9, vérifiez cURL, DOM, Fileinfo, GD, Iconv, Intl, JSON, Mbstring, OpenSSL, PDO avec son pilote MySQL, SimpleXML et Zip. Exécutez le contrôle des prérequis de votre version exacte ; ne considérez pas une liste complémentaire d'extensions d'une ancienne branche comme complète.

Confirmez la version PHP de l'environnement web, memory_limit, les limites d'exécution et d'envoi et les extensions. PHP CLI peut utiliser un autre binaire et une autre configuration. La réussite de php -i ou d'une commande cron ne confirme pas les réglages de la boutique.

Paramètres avancés > Informations indique des réglages utiles de l'environnement d'exécution ; Paramètres avancés > Performances affiche la configuration du cache de la boutique. La page Informations n'est pas un outil de supervision d'OPcache. Utilisez un diagnostic à accès contrôlé passant par le même pool PHP web pour vérifier OPcache, puis supprimez les pages de diagnostic.

Vérifiez allow_url_fopen et les fonctions nécessaires aux contrôles d'installation de la version. Vérifiez le HTTPS sortant, les envois ZIP, les écritures de fichiers et l'accès aux tâches planifiées. Les restrictions d'un hébergement infogéré peuvent provoquer des échecs, mais une installation de module peut aussi échouer pour des causes applicatives ; examinez l'erreur avant d'attribuer la responsabilité.

Dimensionner mémoire, processeur et stockage à partir de mesures

memory_limit est un plafond d'allocation par script. La RAM totale du serveur sert aussi aux processus PHP, à la base, à OPcache, au serveur web, aux tâches et au système d'exploitation. PrestaShop 9 recommande au moins 512M par script ; ce n'est pas une spécification de serveur de 512 Mo.

Mesurez la mémoire habituelle et maximale des processus pendant les requêtes de la boutique, les imports et le travail du back-office. Estimez la capacité en multipliant les processus simultanés par leur mémoire de travail mesurée, puis ajoutez la base, les caches partagés, les tâches et une marge pour le système. Évitez de compter deux fois la mémoire partagée dans les mesures de processus.

Par exemple, dix processus mesurés à 80 Mo chacun représentent environ 800 Mo de mémoire de processus avant les autres services. La valeur de 80 Mo est une mesure illustrative, pas une constante PrestaShop. Un plafond de script de 512 Mo ne signifie pas que chaque processus consomme toujours 512 Mo.

Ajustez pm.max_children à la mémoire disponible et à la simultanéité observée. Examinez aussi la file FPM, la saturation du processeur, les requêtes lentes et les événements de manque de mémoire. Relever les limites de mémoire ou ajouter des processus sans capacité peut aggraver les échecs.

Mesurez les répertoires d'images, originaux, types d'images générés, modules, journaux, fichiers de base et espace local de préparation des sauvegardes. Prévoyez de la place pour les imports et les copies temporaires de régénération d'images. Les nombres de produits et d'images seuls ne permettent pas de connaître l'espace disque nécessaire.

Conservez les horaires des échecs avec les mesures de ressources. Si les imports échouent uniquement pendant les sauvegardes ou la régénération d'images, examinez ce chevauchement avant de passer à une offre supérieure. Vérifiez l'erreur PHP, le code de sortie de la tâche et les événements de limitation des ressources de l'hébergement pour distinguer un plafond de script, un délai dépassé et un serveur à court de mémoire.

Utilisez du stockage SSD ou NVMe avec des garanties d'entrées/sorties adaptées. Testez les performances de la base et du cache fichiers sous une charge réaliste. La taille du catalogue, la complexité des recherches et filtres, les déclinaisons, les hooks de modules et les requêtes simultanées affectent tous la capacité.

Configurer OPcache et PHP-FPM délibérément

OPcache conserve le bytecode PHP compilé et peut réduire les analyses répétées du code. Vérifiez la mémoire utilisée, le nombre de fichiers en cache, les redémarrages et le taux de succès du cache avant de choisir l'allocation mémoire et la limite de fichiers. Ne supposez pas qu'une taille fixe convient à tous les ensembles de modules.

Gardez une vérification des horodatages compatible avec votre processus de déploiement. Si vous désactivez ou retardez les contrôles de fichiers, prévoyez une réinitialisation fiable du cache lors des publications afin de ne pas servir du code périmé aux clients.

Configurez le nombre de processus FPM, les processus disponibles et leur recyclage selon le trafic mesuré. Les imports lourds et la régénération d'images peuvent s'exécuter comme tâches CLI contrôlées lorsque c'est pris en charge, avec leurs limites et leur planification propres.

Les gains du JIT dépendent de la charge. Privilégiez une branche PHP maintenue, OPcache et le traitement des opérations lentes identifiées avant de considérer le JIT comme une amélioration générale de la vitesse de la boutique.

Optimiser MySQL ou MariaDB sans affaiblir la durabilité

Utilisez InnoDB là où il est requis et vérifiez les données actives, le comportement du pool de mémoire tampon, la latence disque, les index et les requêtes lentes. Sur un serveur regroupant plusieurs services, laissez de la mémoire pour PHP et les autres services. Un serveur consacré à la base dispose d'un budget mémoire différent. Pour examiner l'allocation active du pool, exécutez SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; sur le serveur de base utilisé par votre boutique, ou demandez le résultat à l'hébergeur. La valeur est en octets ; évaluez-la avec l'activité du pool et les données actives.

Conservez cette base favorisant la durabilité :

[mysqld]
innodb_flush_log_at_trx_commit = 1

Définir cette valeur à 2 modifie la manière dont le journal de transactions atteint le stockage durable et peut faire perdre des transactions validées après une panne du système d'exploitation ou une coupure électrique. Ne l'appliquez pas comme optimisation courante aux données de commande. Examinez ensemble les réglages de durabilité et de réplication, avec la documentation du journal de transactions.

Distinguez les exemples de configuration MySQL et MariaDB. MariaDB a supprimé innodb_buffer_pool_instances en 10.6 ; ne copiez donc pas ce réglage obsolète dans une configuration MariaDB actuelle.

Activez une visibilité adaptée sur les requêtes lentes, recherchez les requêtes coûteuses répétées et surveillez la croissance de la base. Évitez de supprimer aveuglément des paniers ou de convertir des tables. Sauvegardez et testez d'abord les opérations de maintenance.

Une base proche peut réduire les allers-retours réseau, mais mesurez la latence réelle et le nombre de requêtes. Un service distant sur un réseau privé à faible latence diffère d'une base mutualisée éloignée. Choisissez la localisation du serveur d'origine selon vos marchés clients et les points de connexion des intégrations, puis testez le parcours d'achat depuis ces lieux. Un CDN qui sert les images plus près des clients ne prouve pas que le passage de commande sans cache ou les appels aux API externes sont rapides.

Choisir Apache ou Nginx et installer les bons paquets

Apache et Nginx peuvent tous deux servir PrestaShop avec PHP-FPM. Apache prend en charge .htaccess lorsque sa configuration le permet. Nginx nécessite des règles équivalentes au niveau serveur ; il ne lit pas .htaccess. Aucun des deux n'est automatiquement plus rapide pour toutes les charges.

Utilisez la configuration serveur PrestaShop de votre version et testez les URL simplifiées, images, chemins protégés et routes de modules. Un proxy inverse devant Apache est une autre possibilité, mais ajoute de la configuration à maintenir.

Les noms de paquets dépendent de la version du système. Debian 12 fournit des paquets PHP 8.2. La série PHP fournie par Ubuntu 22.04 est 8.1 ; une procédure PHP 8.2 y nécessite un dépôt supplémentaire maintenu ou une autre version du système. Ubuntu 24.04 fournit des paquets PHP 8.3. Ne choisissez la série qu'après avoir vérifié la compatibilité de la boutique.

Installez l'environnement FPM choisi, son pilote MySQL et les extensions requises, puis configurez le serveur web pour utiliser ce pool. N'installez une base en local que si l'architecture le prévoit. Redis est facultatif et exige une véritable intégration applicative.

Utilisez HTTP/2 ou HTTP/3 lorsque c'est pris en charge et une compression adaptée du texte. Mesurez leurs effets avec vos ressources et conditions réseau plutôt que d'attribuer un pourcentage universel d'amélioration.

Distinguer les couches de cache et de session

La compilation Smarty et le cache de sortie, les caches applicatifs, les cookies d'authentification, les sessions PHP ou Symfony et les enregistrements de sessions clients ou employés en base sont des mécanismes différents. Vérifiez la configuration de chaque couche avant de changer son stockage.

Un serveur Redis ne déplace automatiquement aucune de ces couches. Configurez séparément l'adaptateur de cache et tout gestionnaire de sessions PHP, puis testez le verrouillage, l'expiration, l'authentification et la reprise. Une connexion Redis gérée par le prestataire peut fonctionner sans accès shell ; elle nécessite un accès au service, une authentification et le client PHP approprié.

Redis Cache Manager & Monitor assure la gestion et la supervision. Consultez l'aide du module pour connaître les fonctions de données, de sessions et de pages visiteurs disponibles dans votre version installée, puis testez chaque couche activée. Un test de connexion Redis réussi ne suffit pas à confirmer le bon fonctionnement du cache ou des sessions.

Le cache de page complète nécessite une gestion explicite des devises, langues, groupes de clients et contenus personnalisés. Testez séparément les parcours du panier, de la connexion et de la commande. Consultez le guide du cache de page complète.

Configurer HTTPS et un CDN séparément

Servez la boutique en HTTPS et surveillez le renouvellement des certificats. Testez le front-office, le back-office, les webhooks et les URL de retour de paiement. Utilisez un seul nom d'hôte HTTPS voulu et évitez les boucles de redirection.

Le proxy Cloudflare s'active via sa configuration DNS et de proxy. Les réglages de serveurs de médias PrestaShop choisissent les noms d'hôte des ressources ; ils n'activent pas Cloudflare.

Avec Cloudflare, utilisez Full (strict) avec un certificat d'origine valide. Le mode Flexible ne chiffre pas la connexion Cloudflare-origine. Configurez correctement les proxys de confiance et la gestion du protocole et empêchez les visiteurs de falsifier les en-têtes de transfert de confiance.

Commencez par les ressources statiques. Excluez du cache de pages partagé le back-office, le panier, le passage de commande, les pages du compte et les réponses personnalisées. Une règle Cache Everything appliquée partout peut exposer le contenu d'un autre client. Testez les cookies et les clés de cache avant d'autoriser la mise en cache du HTML.

Exiger des sauvegardes restaurables et une supervision utile

Demandez ce que contiennent les sauvegardes, où elles sont stockées, combien de temps elles sont conservées et qui peut les restaurer. Un instantané peut faciliter le retour arrière, mais sa cohérence et son indépendance dépendent du service.

Définissez la fréquence des sauvegardes selon la perte de données acceptable et leur conservation selon vos besoins de reprise. Des sauvegardes quotidiennes de la base et des fichiers avec une copie indépendante peuvent être une politique de départ ; les boutiques actives peuvent nécessiter des points de restauration de base plus fréquents. Testez les restaurations dans un environnement isolé.

Supervisez la disponibilité depuis l'extérieur, l'expiration des certificats, l'espace disque, la pression mémoire, les files FPM, les tâches en échec et les résultats des sauvegardes. Un SLA de disponibilité définit des conditions contractuelles, pas une indemnisation pour chaque commande perdue. Un objectif annuel de disponibilité de 99,9% correspond à environ 8,76 heures d'arrêt sur une année de 365 jours.

Pour plusieurs boutiques, prévoyez la charge maximale combinée. Le multiboutique partage le code et l'état de la base ; les installations séparées nécessitent leurs propres mises à jour et sauvegardes. Des répertoires distincts sur un même serveur ne garantissent pas l'isolation de sécurité ou de ressources. Utilisez des utilisateurs, permissions et périmètres de pools ou de conteneurs adaptés.

Consultez le guide des sauvegardes pour le processus de reprise.

Changer d'hébergeur avec une bascule testée

Répétez l'opération sur une copie à accès contrôlé, connectée à des comptes de paiement de test et isolée des e-mails clients, des exports de stocks et des autres effets sur les systèmes réels. Confirmez que ses tâches planifiées ne peuvent pas doubler les traitements de production. Les tests de restauration, les tests applicatifs et la bascule finale du trafic sont des contrôles distincts ; une copie de fichiers réussie ne prouve pas que la boutique est prête.

1. Relevez les versions du cœur, des modules, du thème, de PHP, de la base et des extensions, ainsi que les réglages cron, e-mail et d'intégration. Incluez les enregistrements DNS et de messagerie, les identifiants des services et les listes d'IP autorisées qui dépendent de l'ancien hébergement.
2. Préparez une cible compatible. Évitez de combiner une mise à niveau PHP non testée avec le changement d'hébergement.
3. Faites un export cohérent de la base et copiez les fichiers de la boutique, y compris les fichiers cachés et les images générées. Gardez la sauvegarde d'origine indépendante.
4. Restaurez la base avec le bon jeu de caractères et le bon préfixe de tables. Mettez à jour les paramètres de connexion dans le fichier de configuration de la version, tel que app/config/parameters.php.
5. Définissez les permissions selon le modèle de déploiement. Donnez au processus web un accès en lecture, avec un accès en écriture limité aux emplacements où l'exécution ou les mises à jour gérées l'exigent. N'attribuez pas globalement tous les fichiers à l'utilisateur web et ne donnez pas à tous un accès en écriture.
6. Videz les caches applicatifs pertinents par la procédure normale. Confirmez le domaine et le chemin de base dans la configuration des URL de boutique.
7. Testez les parcours du front-office et du back-office via une correspondance locale dans le fichier hosts avant de modifier le DNS public. Vérifiez la recherche, l'enregistrement des produits, les grilles du back-office et la création de commandes. Vérifiez les e-mails et les tâches planifiées dans l'environnement de test isolé ; les notifications de paiement nécessitent un point de réception de test contrôlé et accessible au prestataire.
8. Réduisez à l'avance le TTL DNS si cela est utile. Avant la synchronisation finale, arrêtez les tâches planifiées et contrôlez les écritures sur l'ancien hébergement, y compris les imports et les mises à jour des intégrations. Empêchez l'ancienne boutique d'accepter des commandes indépendantes après la bascule. Convenez du traitement unique des notifications de paiement tardives et des mises à jour en attente sur le nouvel hébergement.
9. Effectuez la synchronisation finale de la base et des fichiers, basculez le trafic et supervisez les deux hébergements jusqu'à ce que l'ancienne destination ne soit plus utilisée. Activez les tâches de production uniquement sur l'hébergement prévu, confirmez les références des commandes et des paiements, et vérifiez que les intégrations atteignent la nouvelle destination.

Conservez un plan de retour arrière tenant compte des commandes créées après la bascule. Revenir au DNS précédent sans rapprocher ces écritures peut faire perdre des données métier.

Vérifier l'offre avant de vous engager

• Intersection exacte des versions cœur/PHP/base prises en charge et politique de maintenance de sécurité
• Extensions requises dans l'environnement web, limites de mémoire et OPcache configurable
• Limites documentées de processeur, RAM, processus et entrées/sorties
• Accès shell ou accès de déploiement équivalent et intervalles cron adaptés à vos tâches réelles
• Proximité de la base, accès aux requêtes lentes et cohérence des sauvegardes
• Renouvellement des certificats, e-mails sortants et accès aux API externes
• Procédure de restauration, possibilités de sauvegardes indépendantes et périmètre d'assistance en cas d'incident
• Localisation des données, conditions de service, coûts de renouvellement et moyen d'export

Effectuer une comparaison reproductible

Mesurez une copie de préproduction représentative avec les mêmes modules, catalogue et conditions de cache. Notez les temps de réponse, les erreurs et l'utilisation des ressources pendant les requêtes normales et la charge simultanée. Le TTFB comprend le réseau et le travail du serveur ; il est donc utile, mais n'isole pas à lui seul un goulot d'étranglement.

1. Convenez des parcours de test : catégorie avec filtres actifs, options de produit, recherche, panier, commande et opération problématique du back-office. Utilisez les mêmes données et le même contexte client sur chaque hébergement.
2. En préproduction, contournez le cache de page complète pour examiner les requêtes qui atteignent PHP. Notez si OPcache, les caches applicatifs et les tampons de la base sont froids ou préchauffés, et conservez la même préparation. Ne désactivez pas le cache de production pour comparer les ventes.
3. Relevez les temps depuis le même lieu de test, avec les observations sur la file FPM, le processeur, la mémoire, la base et le stockage. Utilisez un trafic simultané et des tâches planifiées réalistes ; arrêtez le test s'il affecte la boutique en production ou des services partagés.
4. Répétez les mesures du front-office avec le cache de production activé. Vérifiez l'état du cache pour ne pas confondre une réponse rapide du CDN avec un PHP plus rapide, et vérifiez le bon fonctionnement des paniers et des parcours des clients connectés.
5. Conservez la configuration et les résultats des tests avec l'offre proposée. Convenez de la validation en fonction de votre situation actuelle et de vos besoins métier, plutôt que d'un seuil universel de vitesse des pages.

Pour un simple échantillon de temps de réponse sur votre boutique de test autorisée, remplacez l'URL d'exemple par une page représentative et répétez dans les conditions consignées :

curl -o /dev/null -sS -w 'HTTP: %{http_code} TTFB: %{time_starttransfer}s\n' https://www.example.com/

Vérifiez séparément le statut et le contenu de la réponse ; une erreur ou une redirection rapide n'est pas un affichage de page réussi. L'hébergement, le code applicatif et les ressources du navigateur constituent des couches de performance distinctes. Identifiez la couche limitante avant d'acheter un serveur plus puissant, à l'aide du guide des performances.

Si vous ne pouvez pas encore répartir le délai entre hébergement, application et navigateur, le service PrestaShop Speed & Core Web Vitals Audit fournit un plan de correction fondé sur des mesures ; les modifications du code et la configuration serveur font l'objet de périmètres distincts.

Questions à poser à votre développeur ou agence

• Quelle observation justifie la correction proposée, et pouvez-vous reproduire l'échec avec nos modules et données réels ?
• Quels réglages ou services changeront, qui les maintiendra ensuite et quels accès conserverons-nous ?
• Quels contrôles d'achat, d'import et de restauration doivent réussir avant la bascule, et qui consigne les résultats ?
• Qui contrôle les écritures pendant la synchronisation finale, décide du retour arrière et rapproche les commandes si le trafic atteint les deux hébergements ?

Questions des commerçants

Un hébergement plus rapide accélérera-t-il le back-office ?

Cela peut aider lorsque les ressources ou le stockage sont la contrainte. Si seul un import ou un écran d'administration échoue, relevez d'abord son erreur et le comportement de ses requêtes. Un défaut de module, l'attente d'une API externe ou une limite de script nécessitent une autre correction qu'un serveur saturé.

Faut-il changer d'hébergeur et mettre à niveau PrestaShop ensemble ?

Un changement nécessaire de l'environnement d'exécution peut lier les projets, mais testez la migration d'hébergement et la mise à niveau applicative comme des changements distincts en préproduction. Notez quel changement introduit un échec et conservez un point de reprise pour chaque état testé avant de planifier la bascule en production.

Un test réussi via le fichier hosts valide-t-il les notifications de paiement ?

Non. Une correspondance locale dans le fichier hosts affecte votre ordinateur, pas le prestataire de paiement ni le serveur ERP. Convenez d'un point de réception de test accessible et contrôlé lorsque c'est possible, puis vérifiez les notifications entrantes sur le nom d'hôte public après la bascule. Le retour du navigateur à la page de confirmation ne prouve pas l'arrivée des notifications entre serveurs.

Quand résilier l'ancien hébergement ?

Lorsque le trafic et les intégrations atteignent systématiquement le nouvel hébergement, que les commandes récentes sont rapprochées et que vous avez conservé indépendamment les fichiers, la base, les e-mails et les journaux nécessaires. Vérifiez si des boîtes mail, le DNS ou les sauvegardes dépendent encore de l'ancien compte avant de le fermer.