Agence PrestaShop à Chambéry : régler serveur et cache avant de changer d'hébergeur

Quand la boutique rame un jour de soldes, on pense vite à changer d’hébergeur. Pourtant, le problème vient souvent du cache ou d’un module.

Voilà la méthode d’une agence PrestaShop à Chambéry : régler serveur et cache avant de changer d’hébergeur.

• Régler serveur et cache avant de changer d'hébergeur
• En production, les caches PrestaShop doivent rester activés
• Réglages PHP et ressources : ce qui permet de savoir si l’hébergeur bloque
• Une migration se valide sur une copie avant toute bascule
• Les URL et les redirections font l’essentiel du risque SEO
• Foire aux questions

Régler serveur et cache avant de changer d'hébergeur

Une boutique PrestaShop lente ne justifie pas, à elle seule, un changement d’hébergeur. Commencez par mesurer les pages clés, les erreurs et les ressources consommées. Ensuite, modifiez un seul réglage à la fois.

Sur une boutique de 3 800 produits, le diagnostic prend en général 1 à 2 jours ouvrés. Le coût dépend des accès disponibles et du nombre de modules. Comptez :

• À distance : 600 à 1 200 € HT^*
• Sur site, autour de Chambéry : 900 à 1 800 € HT^*

Les indicateurs à relever avant de toucher à quoi que ce soit

Mesurez cinq pages. Pour chacune, relevez :

• le temps de réponse du serveur
• le temps d’affichage complet
• les erreurs HTTP 500
• l’écart entre visiteur anonyme et client connecté

Une moyenne ne suffit pas. Ce qui compte, ce sont les pics. Une boutique qui tient en journée mais s’effondre pendant une vente privée pose un tout autre problème.

Reproduisez ensuite le ralentissement selon le parcours et l’heure. Une fiche rapide le matin et lente à 18 heures signale souvent une saturation des processus PHP. Une erreur limitée au panier pointe plutôt vers un module, une session ou une connexion externe.

Croisez enfin quatre sources : les logs PrestaShop, les erreurs PHP, le journal du serveur web et les erreurs de base de données. La page « Logs » du back-office distingue avertissements, erreurs et problèmes critiques, comme une allocation mémoire impossible.

Ce qu’il faut contrôler dans la configuration

Vérifiez la mémoire PHP, le nombre de cœurs, la RAM, le type de disque, les processus PHP disponibles et les limites de temps d’exécution. Pour PrestaShop 9, la documentation demande au minimum :

• memory_limit d’au moins 512 Mo
• Apache 2.4 ou plus récent
• MySQL 5.7 ou MariaDB 10.2

Mesurez à nouveau les mêmes pages après chaque réglage. Tenez un tableau avant/après : temps serveur, nombre d’erreurs, mémoire utilisée, taux d’échec du panier. Sans cette comparaison, modifier PHP ou OPcache revient à travailler à l’aveugle.

Comment choisir un prestataire local

À Chambéry comme ailleurs, demandez trois choses avant de signer. Il vous faut une migration PrestaShop documentée, un exemple de diagnostic serveur réel et la liste écrite des livrables. Savoir monter un site vitrine ne prouve pas qu’on maîtrise PHP, MySQL ou le cache Smarty.

Exigez aussi, par écrit :

• un accès temporaire
• une sauvegarde vérifiée
• une fenêtre d’intervention

Décrire mon besoin →

En production, les caches PrestaShop doivent rester activés

Le cache Smarty, le cache des fichiers et OPcache doivent rester actifs en production. Seule exception : une opération de dépannage courte. Le mode « forcer la compilation » et le cache désactivé relèvent du développement, pas d’une boutique ouverte aux clients.

Smarty et le cache des fichiers

Smarty compile les templates, c’est-à-dire les fichiers qui construisent l’affichage, puis réutilise le résultat. En production, laissez-le en mode « recompiler seulement si le fichier a changé ». La compilation forcée ralentit chaque chargement de page.

Pour vider le cache après une modification de thème ou de module, passez par « Paramètres avancés », puis « Performances ». Cette action évite de servir un ancien fichier compilé, sans toucher au code de la boutique.

CCC : combiner, compresser, mettre en cache

CCC signifie « Combiner, compresser et mettre en cache ». PrestaShop regroupe les fichiers CSS et JavaScript, les compresse, puis sert une version déjà préparée. Le nombre de requêtes et la charge du serveur baissent d’autant.

La combinaison JavaScript demande plus de prudence. Un module de paiement, un menu ou un outil de suivi peut dépendre de l’ordre des scripts. Activez l’option sur une copie. Puis testez recherche, panier, paiement et formulaires.

Cache serveur : ce que l’hébergeur doit fournir

PrestaShop documente trois options de cache serveur :

• Memcached : cache distribué, utile avec plusieurs serveurs ;
• APC : adapté à une architecture sur un seul serveur ;
• Xcache : lié à Lighttpd, il ne convient pas à un Apache classique.

L’hébergeur doit fournir l’extension PHP et son paramétrage réel. Une mention « cache » dans une offre commerciale ne suffit pas.

Réglages PHP et ressources : ce qui permet de savoir si l’hébergeur bloque

Avant de changer d’hébergeur, vérifiez si le serveur actuel permet de régler PHP, OPcache, les processus, la base et les tâches planifiées. Un hébergement trop juste peut être en cause. Mais un module défaillant produit les mêmes symptômes sur une machine plus chère.

Optimiser l’environnement existant

OPcache garde le code PHP compilé en mémoire. Ainsi, PHP ne le recompile pas à chaque appel. Contrôlez son activation, sa taille mémoire, le nombre de fichiers acceptés et son comportement après un déploiement.

PrestaShop 9.0 exige PHP 8.1 au minimum et prend en charge PHP 8.1 à 8.4. PrestaShop 9.1 ajoute PHP 8.5 comme version recommandée. Un vieux module ou thème peut pourtant rester incompatible, même si le cœur supporte cette version.

Demandez à l’hébergeur l’accès aux réglages PHP, au journal PHP, aux statistiques de processus, au slow query log de MySQL et à la configuration OPcache. Sans ces accès ni le moindre indicateur, le problème devient contractuel autant que technique.

Quand changer d’hébergement

Mieux vaut changer d’hébergeur si la saturation persiste après correction du cache, suppression du module fautif et réglage de PHP.

Les signes les plus nets sont :

• des processus PHP constamment au maximum
• des erreurs de mémoire répétées
• un disque saturé
• une base inaccessible pendant les pics

Comparez les offres sur les ressources réellement allouées, pas sur le nombre de cœurs affiché. Pour une boutique de 5 000 produits et 50 000 visites mensuelles, comptez 150 à 350 € HT^* par mois pour un serveur géré correctement dimensionné. Le montant varie selon le support, les sauvegardes et le trafic.

Pour la migration elle-même, comptez :

• Simple (moins de 5 000 produits, thème standard, moins de 15 modules) : 1 800 à 3 500 € HT^*
• Complexe (thème sur mesure, paiement spécifique, marketplace, flux ERP ou plusieurs boutiques) : 3 500 à 8 000 € HT^*, et 2 à 6 semaines

Décrire mon besoin →

Une migration se valide sur une copie avant toute bascule

Une migration d’hébergement doit reproduire la boutique sur le nouveau serveur avant toute modification DNS. Pour une boutique simple, prévoyez en général 3 à 10 jours de préparation et de tests. Ensuite, une bascule courte, pendant une période de faible commande.

Préparer le transfert

Sauvegardez séparément les fichiers et la base de données. Les fichiers contiennent code, modules, thème et images. La base contient produits, clients, commandes, réglages et contenus. Une copie unique, stockée sur le même serveur, ne constitue pas une sauvegarde.

Contrôlez la taille des fichiers, la présence de toutes les tables et la possibilité de restaurer chaque sauvegarde. Pour la base, mysqldump ou un export phpMyAdmin doit contenir structure et données. PrestaShop recommande de vérifier l’intégrité de la sauvegarde avant de continuer.

Tester avant la bascule

Créez une copie protégée par mot de passe ou par restriction d’adresse IP. Vérifiez-y le front-office, le back-office, le thème, les modules et les droits d’écriture. La version PHP du nouveau serveur doit correspondre à PrestaShop et aux modules réellement utilisés.

La recette couvre la recherche, les catégories et les déclinaisons. Elle couvre aussi les comptes clients, le panier, les coupons, la commande et l’historique client. Contrôlez enfin les stocks, les prix par groupe et les règles de taxes. Ces fonctions dépendent souvent de modules ou de réglages personnalisés : elles cassent les premières.

Organiser la mise en ligne

Baissez le TTL DNS, c’est-à-dire la durée pendant laquelle les résolveurs conservent l’adresse du serveur, 24 à 48 heures avant la bascule. Le certificat SSL, les tâches cron, les boîtes e-mail et les accès externes doivent être prêts avant de couper l’ancienne boutique.

Pour une boutique bien préparée, la mise en ligne prend souvent 30 à 90 minutes :

1. passage de l’ancienne boutique en maintenance
2. dernière sauvegarde
3. synchronisation des données récentes
4. changement du DNS
5. contrôle du certificat, des journaux et du tunnel de commande

Le plan de retour arrière tient sur une page : ancienne adresse serveur, sauvegarde finale, responsable de la décision et seuil d’abandon. Pendant 24 heures, surveillez les erreurs 500, les paiements, les e-mails, les commandes et les temps de réponse.

Décrire mon besoin →

Les URL et les redirections font l’essentiel du risque SEO

Changer d’hébergeur sans toucher aux URL reste bien moins risqué pour le référencement qu’une refonte des adresses. Le danger apparaît quand les chemins, les domaines, les catégories ou les règles de réécriture changent en même temps.

Dressez une correspondance complète entre chaque ancienne URL et sa destination. Elle couvre les produits, les catégories, les pages CMS, les images importantes et les anciennes pages encore présentes dans les journaux ou les outils d’analyse.

Quand une URL change, posez une redirection permanente côté serveur, en 301 ou 308, directement vers la nouvelle adresse. Évitez les chaînes de redirections.

Vérifiez aussi les balises canoniques, les liens internes et les liens vers les images. Une redirection ne corrige pas une page qui déclare encore l’ancienne URL comme canonique.

Gardez les redirections au moins un an. Si des liens externes pointent encore vers les anciennes adresses, gardez-les plus longtemps. Pendant le premier mois, contrôlez chaque semaine les erreurs 404 et les pages stratégiques.

Avant de payer un nouvel hébergeur, vérifiez d’abord ce que le serveur actuel peut encore donner : mesurez les pages clés, réglez PHP et OPcache un réglage à la fois, et gardez les caches activés en production. Si la saturation persiste après ces corrections, demandez à votre prestataire un devis écrit, une sauvegarde vérifiée et une copie de test avant toute bascule DNS.

Foire aux questions

Quel accès faut-il donner à l’agence ?

Prévoyez un accès temporaire au back-office, au serveur, aux journaux, à la base et au DNS si la bascule est incluse dans la mission. Les mots de passe doivent être individuels et limités au périmètre utile, puis supprimés ou renouvelés dès la fin de l’intervention.

Faut-il passer directement à PrestaShop 9 ?

Pas forcément. PrestaShop 9 demande PHP 8.1 au minimum et peut imposer de vérifier le thème et les modules. Validez d’abord la compatibilité des développements spécifiques, puis séparez la correction du serveur d’une mise à niveau majeure, pour limiter le nombre de variables à la fois.

Un CDN remplace-t-il le cache PrestaShop ?

Non. Un CDN distribue les ressources statiques, comme les images, le CSS et le JavaScript, mais il ne remplace ni le cache Smarty, ni OPcache, ni la gestion des sessions et du panier. Ajoutez-le seulement une fois l’application stabilisée et les pages pouvant être mises en cache clairement définies.

Combien de temps garder l’ancien hébergement ?

Pour une migration simple, gardez l’ancien environnement accessible et intact, avec ses sauvegardes, pendant au moins 7 à 14 jours. Si les URL changent, les redirections doivent rester actives au moins un an pour limiter les pertes de visites et d’exploration.

* Tarifs et prix moyens constatés en décembre 2025, sur des retours d'appels d'offres provenant de freelances et d'agences. Ces chiffres ne sauraient être une référence de négociation, car les sources varient selon la taille du site et la séniorité du prestataire.