Hébergement PrestaShop : mutualisé, serveur dédié ou cloud, comment choisir ?

Les comparatifs classent les hébergeurs selon un nombre de produits ou de visiteurs, sans dire d’où viennent ces seuils. Les critères de ce guide se lisent dans votre back-office, se mesurent ou s’écrivent dans un contrat.

Mutualisé, VPS, dédié ou cloud : quelles différences ?

Les quatre types d’hébergement se distinguent par ce que vous louez et par la personne qui administre le serveur. Sur un mutualisé, l’hébergeur s’en charge. Sur un VPS, un serveur dédié ou une instance cloud, cette charge vous revient, sauf si vous payez une infogérance, l’administration du serveur confiée à un prestataire.

Ces définitions sont celles de l’éditeur. PrestaShop écrit que l’hébergement partagé est « une solution facile et abordable pour les nouveaux sites à faible trafic », et qu’il « n’est pas adapté aux grands sites web à fort trafic ». La documentation de Google indique de son côté qu’un hébergement partagé est en général plus lent, et que le choix pèse davantage pour une application qui interroge une base de données, comme le fait une boutique.

Aucune source officielle ne chiffre le passage d’un type à l’autre. Ni l’éditeur ni Google ne donnent de seuil en nombre de produits, de visiteurs ou de commandes : ceux que vous lisez ailleurs appartiennent à leurs auteurs.

Deux questions qui tranchent

La première question porte sur les personnes. Un VPS ou un serveur dédié sans infogérance ne convient pas si personne, chez vous ou chez votre prestataire, n’installe les correctifs du système. Gardez alors un mutualisé, ou prenez une formule infogérée.

La seconde porte sur la mesure. Tant que votre configuration passe les contrôles de la troisième partie et que le temps de réponse du serveur reste bon, changer de type d’hébergement ne règle rien. Pour un trafic qui varie fort d’une semaine à l’autre, l’éditeur présente le cloud comme une infrastructure « abordable, évolutive et fiable » : faites préciser comment les ressources ajoutées sont facturées.

PrestaShop cloud : que propose l’éditeur aujourd’hui ?

Le 14 novembre 2026, l’éditeur PrestaShop publie trois offres sur son site français, et aucune ne s’appelle « PrestaShop Cloud » : Classic, Hosted et PrestaShop Hosting. Seules les deux dernières comprennent un hébergement.

Avec Classic, tout ce qui touche au serveur vous revient. Service Public le dit de tout site que l’on crée soi-même avec un logiciel gratuit de ce type : « C’est vous qui faites les mises à jour, la sécurité, les sauvegardes des données. »

L’offre Hosted vise le marchand qui ouvre une boutique sans s’occuper du serveur. Elle repose sur la version 8 de PrestaShop, dont la branche ne reçoit plus que des correctifs critiques et de sécurité jusqu’à la sortie de PrestaShop 10, selon le calendrier du projet. Demandez, avant de vous abonner, quand et comment votre boutique passera à la version 9. L’éditeur écrit que vous restez « entièrement propriétaire de votre boutique en ligne et libre de récupérer toutes les données » si vous arrêtez l’abonnement.

PrestaShop Hosting est une infogérance. L’éditeur y annonce une disponibilité de 99,9 % et une sauvegarde quotidienne des fichiers et de la base de données, conservée jusqu’à sept jours sur deux sites distants. Les correctifs de sécurité critiques de l’infrastructure y sont couverts par un engagement de 24 heures ; le transfert du site et le plan de reprise d’activité sont des options. La même page écrit que le client pilote « la maintenance de votre code, de vos modules et de vos thèmes ».

Comment vérifier qu’un hébergement convient à PrestaShop ?

Trois contrôles se font sans l’aide de l’hébergeur : le panneau de configuration du back-office, la version de PHP avec sa date de fin de support, et le temps de réponse du serveur. Les deux premiers se lisent sur la même page du back-office.

La configuration, lue dans le back-office

PrestaShop 9 demande PHP 8.1 au minimum, MySQL 5.7 ou MariaDB 10.2, et 512 Mo de mémoire par script, le réglage memory_limit de PHP. La page Paramètres avancés › Informations affiche le résultat des contrôles de PrestaShop sur votre serveur, dans le panneau « Vérifiez votre configuration ». Le guide PrestaShop 9 détaille ces prérequis version par version.

Pour un hébergement où PrestaShop n’est pas encore installé, l’éditeur fournit un fichier de contrôle à déposer sur le serveur, qui détaille chaque exigence et la réponse du serveur. Trois réglages se demandent par écrit à l’hébergeur :

• la mémoire par script : la valeur en service, et si vous pouvez la modifier ;
• la version de la base de données : PrestaShop 9 accepte MariaDB 10.2, que sa fondation ne maintient plus depuis le 23 mai 2022 ;
• OPcache, le mécanisme de PHP qui garde en mémoire le code déjà compilé : la documentation de PrestaShop le compte parmi ses réglages de performance.

Le centre d’aide de PrestaShop reste plus général que la documentation destinée aux développeurs, d’où viennent les chiffres de ce guide.

La version de PHP, puis son calendrier

La version de PHP en service s’affiche sur cette même page Informations. Comparez-la au calendrier publié par php.net : au 14 novembre 2026, seules PHP 8.4 et PHP 8.5 sont en support actif, et PHP 8.2 ne recevra plus aucun correctif de sécurité après le 31 décembre 2026. Posez deux questions à l’hébergeur : quelles versions de PHP il propose aujourd’hui, et qui décide du passage à la suivante.

Le temps de réponse du serveur

Le temps de réponse du serveur, ou TTFB (Time to First Byte), mesure le délai entre la demande d’une page et l’arrivée du premier octet de la réponse. Google le juge bon à 0,8 seconde ou moins, et mauvais au-dessus de 1,8 seconde. Sa documentation place l’hébergement en tête des pistes quand cette valeur est élevée, et suggère deux questions pour un hébergeur : quelle mémoire reçoit votre application, et sa pile logicielle est-elle tenue à jour.

Mesurez aussi une page peu visitée. Google avertit qu’un cache, celui d’un CDN compris, peut masquer un serveur lent ; un CDN est un réseau de serveurs qui distribue vos images et vos fichiers statiques à la place du vôtre. Si la mesure est mauvaise, le guide sur la boutique PrestaShop lente aide à séparer ce qui vient du serveur de ce qui vient d’un module.

Le réglage « Cache » du back-office

Un dernier réglage dépend du serveur : l’interrupteur « Utiliser le cache » de la page Paramètres avancés › Performances, sur « Non » dans notre boutique de test. La documentation de PrestaShop déconseille de l’activer quand MySQL, avant sa version 8, ou MariaDB tourne sur la même machine. Dans les autres cas, elle cite APC pour un seul serveur web et memcached pour plusieurs : demandez à l’hébergeur lequel il fournit avant d’y toucher.

Qui met à jour le serveur, PHP et PrestaShop ?

L’hébergeur met à jour le serveur et PHP sur un mutualisé ou un hébergement infogéré. Sur un VPS ou un serveur dédié sans infogérance, cette tâche revient à vous ou à votre agence. PrestaShop, ses modules et le thème relèvent de la maintenance de la boutique, quel que soit l’hébergement.

Le 21 octobre 2026 en a donné l’exemple. Ce jour-là, deux failles critiques de PHP ont été corrigées, et le projet PrestaShop a écrit, en anglais, que mettre à jour PrestaShop ou ses modules n’y changeait rien : le seul correctif complet était la mise à jour de PHP sur le serveur. Pour un mutualisé ou un hébergement infogéré, son billet indique que PHP est géré par l’hébergeur et conseille de lui demander une confirmation écrite. Pour un serveur que vous administrez, il demande d’installer la mise à jour puis de redémarrer PHP, faute de quoi le correctif n’est pas chargé.

L’infogérance s’arrête au serveur. Même dans celle de l’éditeur, le code, les modules et le thème restent au client. Une faille dans un module ou dans PrestaShop suit un autre chemin : son éditeur publie un correctif, puis votre maintenance l’applique et teste la boutique. Le guide pour choisir une maintenance PrestaShop liste ce que ce contrat doit prévoir.

La CNIL liste, parmi ce qu’il ne faut pas faire : « Présumer que l’obligation de sécurité dans le cloud incombe uniquement au fournisseur. » Faites écrire, pour chaque couche, qui agit et sous quel délai. C’est ce que couvre l’hébergement et l’infogérance d’une boutique PrestaShop : les responsabilités de chaque intervenant y sont écrites, et nous pouvons conserver votre hébergeur actuel si son environnement convient.

Sauvegardes, contrat, localisation : que faire écrire ?

Trois points s’écrivent avant de signer : l’endroit où sont les sauvegardes et la date de leur dernier essai de restauration, le contrat de sous-traitance, et le pays où sont hébergées les données.

Les sauvegardes

Une sauvegarde complète de PrestaShop comprend les fichiers et la base de données. La CNIL écrit : « Stocker au moins une sauvegarde sur un site géographiquement distinct du site d’exploitation. » Elle demande aussi d’en isoler une hors ligne et d’essayer régulièrement la restauration. Pour un service cloud, elle classe parmi les erreurs une sauvegarde gardée dans le même centre de données que la boutique.

Demandez à l’hébergeur où part la copie, combien de jours elle est conservée, et qui a restauré une sauvegarde complète pour la dernière fois.

Le contrat de sous-traitance

Votre hébergeur est un sous-traitant au sens du RGPD : la CNIL cite l’hébergement parmi les prestataires concernés, et vous restez, en principe, responsable du traitement des données de vos clients. L’article 28 du règlement impose un contrat. La CNIL demande qu’il fixe notamment « les conditions de restitution et de destruction des données en fin du contrat » et les règles de notification des incidents. Lisez ces deux clauses avant de signer : la première décide de votre liberté de changer d’hébergeur.

Le pays des données et le chiffrement

La CNIL déconseille tout service cloud « sans garantie quant à la localisation géographique effective des données ». Demandez le pays des serveurs et celui des sauvegardes. Une certification de l’hébergeur est, selon elle, « un premier indice » de fiabilité : elle ne dispense pas de lire le contrat.

Pour le chiffrement des échanges, la CNIL demande le protocole TLS sur tous les sites web, en version 1.3 ou, à défaut, 1.2. Vérifiez que le certificat HTTPS est compris dans l’offre et renouvelé par l’hébergeur.

Comment changer d’hébergeur sans perdre de commandes ?

Un changement d’hébergeur se prépare sur une copie : la boutique est installée et testée chez le nouvel hébergeur avant que le nom de domaine ne bascule, et l’ancien serveur reste en service tant qu’il reçoit des visites. Google documente cette méthode pour un déménagement qui garde les mêmes adresses de pages.

1. Une semaine au moins avant la bascule, abaissez à quelques heures la durée de vie (TTL) des enregistrements DNS, qui relient votre nom de domaine au serveur.
2. Copiez les fichiers et la base de données chez le nouvel hébergeur, puis testez la commande et le paiement sur une adresse provisoire, fermée aux moteurs de recherche.
3. Le jour du transfert, passez la boutique en mode maintenance et faites une sauvegarde : aucune commande ne doit arriver sur l’ancien serveur pendant la dernière copie.
4. Modifiez les enregistrements DNS pour pointer vers le nouveau serveur, puis suivez le trafic des deux côtés.
5. Coupez l’ancien hébergement quand son trafic est tombé à zéro.

Google juge normale une baisse passagère de son exploration juste après la bascule ; vérifiez que le pare-feu du nouvel hébergeur laisse passer son robot. Il reste à corriger les identifiants de la base de données dans le fichier app/config/parameters.php, à inscrire le nom et l’adresse du nouvel hébergeur dans vos mentions légales, et à mesurer de nouveau le temps de réponse.

Changer d’hébergeur et de version de PrestaShop le même jour cumule deux risques. Si le nouvel hébergement impose une version de PHP que votre boutique ne supporte pas, traitez d’abord la version, avec le guide pour préparer une migration PrestaShop.

Questions fréquentes