PrestaShop bloqué ou lent : diagnostiquer un disque saturé ou une base gonflée

Quand PrestaShop tombe en panne sans prévenir

Un matin, votre boutique PrestaShop affiche des erreurs 500, les pages mettent une éternité à charger, ou pire : le back-office devient inaccessible. Pas de mise à jour récente, pas de changement de configuration — et pourtant, tout est cassé.

Dans la majorité des cas, le coupable est invisible : l'espace disque du serveur est saturé ou la base de données a gonflé silencieusement jusqu'à atteindre les limites de votre hébergement.

Ce guide vous montre comment diagnostiquer et corriger ces deux problèmes, qui sont parmi les causes de panne les plus fréquentes sur PrestaShop.

Première piste : le disque dur du serveur est plein

Pourquoi ça arrive

PrestaShop génère en permanence des fichiers temporaires : cache Smarty ou Symfony, logs PHP, logs d'erreurs Apache/Nginx, sauvegardes automatiques, images régénérées… Sur un hébergement mutualisé avec un quota disque limité (souvent 5 à 20 Go), il suffit de quelques mois sans maintenance pour atteindre la limite.

Diagnostic en SSH

Si vous disposez d'un accès SSH, vérifiez l'espace disponible :

# Espace disque global
df -h

# Les 10 dossiers les plus volumineux à la racine de PrestaShop
du -sh /var/www/html/prestashop/*/ | sort -rh | head -10

Les suspects habituels :

DossierCause fréquente `var/cache/` (PS 1.7/8.x) ou `cache/` (PS 1.6)Cache Symfony/Smarty non purgé `var/logs/` ou `log/`Logs d'erreurs PHP accumulés `img/`Images produits + régénérations multiples `upload/`Fichiers d'import CSV oubliés `download/`Produits virtuels volumineux

Diagnostic sans SSH (hébergement mutualisé)

Sans accès SSH, connectez-vous au panneau de contrôle de votre hébergeur (cPanel, Plesk, OVH Manager) et consultez la jauge d'utilisation disque. Vous pouvez aussi utiliser le gestionnaire de fichiers intégré pour repérer les dossiers anormalement lourds.

Nettoyage immédiat

# Purger le cache Symfony (PrestaShop 1.7 / 8.x)
rm -rf var/cache/prod/* var/cache/dev/*

# Purger le cache Smarty
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

# Vider les logs volumineux (garder le fichier, vider le contenu)
truncate -s 0 var/logs/*.log

# Supprimer les anciennes sauvegardes manuelles
rm -f backup/*.sql.bz2

Attention : après avoir purgé le cache, rechargez une page du front-office pour que PrestaShop régénère les fichiers nécessaires. Un premier chargement plus lent est normal.

Deuxième piste : la base de données a explosé en volume

Le problème des tables de statistiques

PrestaShop embarque un module de statistiques intégré qui enregistre chaque visite, chaque connexion et chaque invité dans la base de données. Sur une boutique avec un trafic régulier, ces tables grossissent de plusieurs centaines de Mo par mois :

TableContenuTaille typique après 1-2 ans `ps_connections`Chaque session visiteur500 Mo – 2 Go `ps_connections_source`Origine de chaque connexion200 Mo – 1 Go `ps_guest`Chaque visiteur unique300 Mo – 1.5 Go `ps_pagenotfound`Chaque erreur 40450 Mo – 500 Mo `ps_statssearch`Chaque recherche interne10 Mo – 200 Mo

Sur un hébergement mutualisé où la base est limitée à 200 Mo ou 1 Go, ces tables saturent silencieusement votre quota MySQL jusqu'à provoquer des erreurs d'écriture.

Diagnostic de la taille de la base

Connectez-vous à phpMyAdmin et exécutez :

-- Voir les 15 plus grosses tables
SELECT 
    table_name AS 'Table',
    ROUND(data_length / 1024 / 1024, 2) AS 'Données (Mo)',
    ROUND(index_length / 1024 / 1024, 2) AS 'Index (Mo)',
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS 'Total (Mo)',
    table_rows AS 'Lignes (estimation)'
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 15;

Si ps_connections, ps_connections_source ou ps_guest apparaissent en haut du classement avec plusieurs centaines de Mo, vous tenez votre coupable.

Purger les tables de statistiques

Avant toute manipulation, faites une sauvegarde de votre base de données.

-- Vider les tables de statistiques (données non critiques)
TRUNCATE TABLE ps_connections;
TRUNCATE TABLE ps_connections_source;
TRUNCATE TABLE ps_guest;
TRUNCATE TABLE ps_pagenotfound;
TRUNCATE TABLE ps_statssearch;

Note : TRUNCATE est préférable à DELETE FROM car il libère immédiatement l'espace disque et réinitialise l'auto-increment. Vous perdrez l'historique de statistiques intégrées de PrestaShop, mais pas vos commandes ni vos clients.

Empêcher que ça recommence

Deux approches complémentaires :

1. Désactiver les modules de statistiques intégrés

Dans le back-office, allez dans Modules > Module Manager et désactivez :

• Statistiques (statsdata)
• Visites et visiteurs (statsvisits)
• Pages vues (statsforecast)
• Navigateurs (statsequipment)
• Et tous les modules commençant par `stats`

2. Utiliser Google Analytics ou Matomo à la place

Les modules stats intégrés de PrestaShop sont largement inférieurs aux solutions dédiées. Google Analytics 4, Matomo (auto-hébergé pour la conformité RGPD) ou Plausible offrent des données bien plus riches sans surcharger votre base de données.

Pour PrestaShop 8.x, le module officiel ps_metrics couple les données Google Analytics avec les données de vente — c'est la solution recommandée.

3. Mettre en place un cron de nettoyage automatique

Si vous souhaitez garder les modules stats actifs, programmez un nettoyage mensuel :

# Crontab : purger les entrées de plus de 90 jours, chaque 1er du mois à 3h
0 3 1 * * mysql -u VOTRE_USER -pVOTRE_PASS VOTRE_BASE -e "
  DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);
  DELETE FROM ps_connections_source WHERE id_connections NOT IN (SELECT id_connections FROM ps_connections);
  DELETE FROM ps_guest WHERE id_guest NOT IN (SELECT id_guest FROM ps_connections);
"

Hébergement mutualisé : le piège classique pour PrestaShop

Un hébergement mutualisé à 5 €/mois est tentant pour lancer sa boutique, mais PrestaShop est un CMS gourmand. Les limites typiques d'un mutualisé posent rapidement problème :

• **Espace disque limité** (10-20 Go partagés entre fichiers et base)
• **Mémoire PHP limitée** (souvent 128 Mo, PrestaShop en demande 256 Mo minimum)
• **Pas d'accès SSH** pour diagnostiquer et intervenir rapidement
• **Processus PHP limités** (temps d'exécution max de 30 secondes)
• **Pas de contrôle sur la configuration MySQL** (pas d'optimisation possible)

Recommandations d'hébergement

Pour une boutique PrestaShop en production :

TypeBudgetPour qui VPS managé (2 Go RAM min.)15-30 €/moisBoutiques jusqu'à 5 000 produits Serveur dédié ou cloud50-150 €/moisBoutiques à fort trafic ou gros catalogue Hébergeur spécialisé PrestaShop20-60 €/moisMarchands sans compétence serveur

L'investissement dans un hébergement adapté est rentabilisé dès la première panne évitée. Une boutique inaccessible pendant 48 heures coûte bien plus cher que la différence entre un mutualisé et un VPS.

Checklist de maintenance préventive

Pour éviter que votre PrestaShop ne tombe en panne silencieusement, programmez ces vérifications mensuelles :

• [ ] Vérifier l'espace disque disponible (> 20 % libre)
• [ ] Contrôler la taille de la base de données et des tables stats
• [ ] Purger le cache Symfony/Smarty
• [ ] Vider les logs applicatifs et serveur
• [ ] Supprimer les anciens fichiers d'import/export dans `upload/`
• [ ] Vérifier que les sauvegardes automatiques ne s'accumulent pas
• [ ] Mettre à jour PrestaShop et les modules (après test en préprod)

Conclusion

Une boutique PrestaShop qui "plante sans raison" a presque toujours une raison technique précise. Le disque saturé et la base de données gonflée par les statistiques sont les deux causes les plus courantes — et les plus simples à résoudre une fois identifiées.

La vraie solution à long terme est triple : un hébergement adapté à PrestaShop, la désactivation des modules stats intégrés au profit de Google Analytics ou Matomo, et une routine de maintenance mensuelle. Ces trois mesures éliminent la grande majorité des pannes silencieuses.