Introduction
Depuis octobre 2018, nous avons traité 3 794 tickets PrestaShop sur notre plateforme de support, sur un total de 8 649 tickets tous CMS confondus — soit 44 % de notre activité sur PrestaShop. Plutôt que de vous livrer une liste théorique des bugs "qu'on croise parfois", cette analyse s'appuie sur nos données réelles : fréquence observée, temps moyen de résolution, exemples de tickets anonymisés.
Résultat : un classement honnête des 20 bugs qui plantent le plus souvent une boutique PrestaShop, avec pour chacun la cause technique la plus fréquente et la piste de résolution. Si votre boutique est déjà en panne, passez directement à la section concernée.
Méthodologie — L'analyse porte sur les 3 793 tickets PrestaShop clôturés entre octobre 2018 et avril 2026 (taux de clôture >99 %). Le clustering se fait par mots-clés dans les titres de tickets, avec une couverture de 53 %. Les 47 % restants sont des tickets au titre trop générique ("Urgent", "Bonjour", "Site", "Modification") où le bug est décrit dans la conversation, non extractible automatiquement. Attribution CMS combinée (website lié + mention dans le ticket + inférence) pour couvrir aussi les tickets pré-2023 où la liaison ticket↔website n'existait pas encore.
Ce que les chiffres révèlent avant même la liste
Avant d'entrer dans le détail, 3 enseignements tirés de 7,5 ans d'interventions :
-
L'erreur 500 est le bug n°1, suivie de très près par les migrations et les bugs de modules — 262 tickets sur "Erreur 500 / internal server error" (6,9 %), 221 sur "Migration/MAJ PrestaShop" (5,8 %), 220 sur "Module/plugin" (5,8 %). Ces trois clusters cumulent 18 % des tickets PrestaShop sur la période. Les erreurs 500 sont particulièrement fréquentes sur PS 1.6/1.7 avec des modules tiers anciens.
-
Les bugs de modules sont les plus longs à stabiliser — 2 527 heures en moyenne (soit plus de 100 jours calendaires), souvent parce qu'il faut identifier le module fautif parmi plusieurs dizaines installés, contacter l'éditeur, parfois patcher manuellement, puis tester en cascade. Bien plus chronophage qu'un bug 500 pur.
-
Le piratage reste un cluster entier (1,2 %) — 46 tickets d'intervention post-intrusion sur 3 794. Pas un épiphénomène : environ un e-commerçant PrestaShop sur 80 qui nous contacte vient pour un site compromis, souvent sur des PS anciens non-mis-à-jour depuis plus d'un an.
Passons à la liste détaillée.
1. Erreur 500 / internal server error — 6,9 %
262 tickets, durée moyenne de résolution : 1 646 heures (tirée par les cas complexes ; la médiane reste plus basse). Le classique "site KO, pas d'explication".
Cause principale : un module admin corrompu, un .htaccess mal régénéré, ou une limite PHP memory_limit trop basse. En 2026, moins de 256 Mo est insuffisant pour PrestaShop 8+.
Solution : augmenter la mémoire PHP côté serveur, vider le dossier var/cache/, puis regénérer le .htaccess depuis Trafic > SEO & URL. Si l'erreur persiste, consulter les logs Apache/Nginx pour identifier le script fautif.
2. Migration ou mise à jour PrestaShop — 5,8 %
221 tickets, durée moyenne : 1 505 heures (63 jours calendaires avec les allers-retours).
Cause principale : incompatibilité d'un module tiers avec la nouvelle version du cœur, ou override obsolète dans override/. PrestaShop 1.7 vers 8 est particulièrement piégeux si vos modules n'ont pas été audités avant.
Solution : activer le mode debug dans config/defines.inc.php pour lire l'erreur exacte, auditer chaque module un par un, puis désactiver les modules obsolètes via SSH en vidant la table ps_module. Une restauration de sauvegarde reste la voie la plus propre si le diagnostic traîne. Voir notre service de mise à jour PrestaShop 9 pour un cadrage.
3. Module / plugin / addon — 5,8 %
220 tickets. Durée moyenne : 2 527 heures (105 jours) — le cluster le plus long à résoudre.
Cause principale : module incompatible avec la version PrestaShop active, conflit entre deux modules qui s'accrochent au même hook, ou module abandonné par son éditeur.
Solution : désactiver tous les modules tiers, réactiver un par un pour identifier le coupable. Si c'est un conflit de hook, l'ordre de chargement peut se rejouer dans Design > Positions. Quand l'éditeur ne répond plus, un fork patché est souvent la seule issue.
4. Commandes / gestion commandes / factures — 5,6 %
213 tickets. Durée moyenne : 1 293 heures.
Cause principale : commande bloquée en "paiement en attente" à cause d'un webhook non reçu, ou layout facture PDF cassé après un changement de thème.
Solution : inspecter les logs du module de paiement, whitelister les IP du prestataire bancaire dans le pare-feu serveur, et vérifier que le template invoice.tpl est à jour avec la version PrestaShop.
5. Catalogue / produit / stock — 4,2 %
160 tickets. Durée moyenne : 2 262 heures (94 jours), souvent parce que les corrections touchent au multi-boutique ou aux imports CSV.
Cause principale : champ id_shop_default incohérent en mode multi-boutique, mauvaise association d'images aux déclinaisons, ou attributs non liés correctement après un import CSV.
Solution : vider le cache dans Paramètres avancés > Performances, vérifier la table ps_product_shop pour le produit concerné, et relancer l'association images/déclinaisons manuellement.
6. Panier / tunnel d'achat / checkout — 3,5 %
131 tickets. Durée moyenne : 1 447 heures.
Cause principale : conflit de cookies entre HTTP et HTTPS, session PHP mal partagée, ou module tiers (PitchPrint, personnalisation produit) qui casse la validation de commande.
Solution : forcer HTTPS dans config/settings.inc.php, vérifier PS_COOKIE_LIFETIME_FO, désactiver les modules tiers un par un pour isoler le coupable.
7. Paiement / passerelle — 3,5 %
131 tickets. Durée moyenne : 2 128 heures.
Cause principale : certificat SSL expiré, identifiants Stripe/PayPal/Monetico obsolètes, ou module de paiement incompatible avec PrestaShop 8.1+.
Solution : vérifier les logs du module de paiement, tester en mode sandbox, mettre à jour le module vers la version compatible avec votre cœur. Les bugs Monetico reviennent particulièrement souvent, liés à la config bancaire.
8. Transport / livraison / frais de port — 3,5 %
131 tickets. Durée moyenne : 881 heures (37 jours).
Cause principale : configuration transporteur (Colissimo, Chronopost, Mondial Relay) cassée après une MAJ du module, points relais qui ne s'affichent plus, ou règles de frais de port qui ignorent certaines zones.
Solution : vérifier les credentials API du transporteur, tester un colis fictif en bout-en-bout, et comparer la config après-MAJ avec une sauvegarde antérieure. La longueur moyenne s'explique par les allers-retours avec le transporteur et les tests avec de vrais colis, pas par le temps technique pur.
9. Performance / lenteur site ou back-office — 3,1 %
117 tickets. Durée moyenne : 944 heures.
Cause principale : tables ps_connections ou ps_guest trop volumineuses, logs non purgés, module de statistiques qui surcharge.
Solution : purger les tables de connexions, désactiver les modules de stats natifs au profit de Matomo ou GA4, passer le cache en Redis. Sur un back-office très lent, la cause est souvent une table qui a dépassé les 5 millions de lignes.
10. Back-office / accès admin / connexion — 3,0 %
114 tickets. Durée moyenne : 1 916 heures.
Cause principale : URL d'admin modifiée sans MAJ du .htaccess, mot de passe oublié, ou module de sécurité qui bloque l'accès.
Solution : réinitialiser le mot de passe via une requête SQL directe sur ps_employee, vérifier le préfixe d'admin dans config/settings.inc.php, et désactiver temporairement les modules de sécurité/anti-brute-force pour retrouver l'accès.
11. Email / notifications / SMTP — 2,2 %
85 tickets. Durée moyenne : 2 282 heures.
Cause principale : config SMTP cassée après migration serveur, ou délivrabilité dégradée (SPF/DKIM/DMARC mal réglés) qui envoie les mails en spam.
Solution : tester la config SMTP dans Paramètres avancés > Emails, vérifier les en-têtes SPF/DKIM via des outils comme MXToolbox, et passer sur un service transactionnel (Mailjet, Brevo, Resend) si le serveur maison n'est pas fiable.
12. Hébergement / serveur / OVH — 1,4 %
53 tickets. Durée moyenne : 656 heures.
Cause principale : espace disque saturé (cpanel), dépassement de quotas OVH, PHP obsolète ou version incompatible avec PrestaShop.
Solution : auditer l'espace disque (du -sh via SSH), purger les logs et les caches, vérifier la version PHP active. Une migration vers un serveur mieux dimensionné est souvent la seule voie durable.
13. Piratage / malware / injection / defacement — 1,2 %
46 tickets. Durée moyenne : 771 heures.
Cause principale : module tiers vulnérable non patché, mot de passe FTP compromis, ou version PrestaShop non mise à jour depuis plus d'un an.
Solution : ne pas se contenter de supprimer le code visible. Il faut nettoyer la base de données, les fichiers, changer tous les accès (FTP, base, admin), et patcher la faille d'origine. Notre service de suppression de malware couvre ces cas en urgence.
14. Thème / template / design — 1,1 %
41 tickets. Durée moyenne : 1 677 heures.
Cause principale : thème personnalisé cassé après une MAJ du cœur, override TPL obsolète, ou CSS conflictuel entre un thème et un module front.
Solution : comparer les TPL du thème custom avec ceux du thème par défaut de la version cible, regénérer le cache thème, et désactiver les surcharges CSS une par une jusqu'à isoler le conflit.
15. SSL / HTTPS / certificat — 0,8 %
29 tickets. Durée moyenne : 20 heures (moins d'un jour) — le cluster le plus rapide à résoudre, de loin.
Cause principale : certificat Let's Encrypt expiré non renouvelé, ou config HTTPS incomplète côté PrestaShop.
Solution : renouveler le certificat via certbot renew, activer HTTPS dans Trafic > SEO & URL > Paramètres généraux, et vérifier que PS_SSL_ENABLED=1 dans ps_configuration.
16. SEO / référencement / sitemap / metas — 0,6 %
21 tickets. Durée moyenne : 521 heures.
Cause principale : sitemap non généré, redirections 301 cassées après migration, ou balises meta dupliquées sur les pages produit.
Solution : regénérer le sitemap depuis le module dédié, auditer les redirections dans .htaccess, et utiliser la Search Console pour identifier les pages en erreur. Un audit SEO complet est souvent plus efficace qu'une correction isolée.
17. Multilingue / traductions — 0,5 %
19 tickets. Durée moyenne : 1 577 heures.
Cause principale : traductions perdues après une MAJ du cœur, fichier fr.gzip corrompu, ou modules multilingue qui écrasent les traductions natives.
Solution : réimporter les paquets de langue depuis Localisation > Traductions, vérifier la cohérence des tables ps_lang et ps_lang_shop, et exporter les traductions custom avant toute MAJ.
18. Base de données / SQL — 0,4 %
14 tickets. Durée moyenne : 428 heures.
Cause principale : connexion BDD perdue (serveur down, credentials invalides), ou table corrompue après un crash.
Solution : vérifier les credentials dans config/parameters.php, relancer le service MySQL, utiliser CHECK TABLE et REPAIR TABLE sur les tables suspectes. Un backup récent sauve énormément de temps en cas de corruption majeure.
19. Page blanche / WSOD — classique de l'écosystème
Le WSOD (White Screen of Death) transparaît dans plusieurs clusters (erreurs 500, modules, cache), d'où sa présence moindre en catégorie dédiée dans nos titres. Bug iconique de PrestaShop toutes versions confondues.
Cause principale : incompatibilité d'un module après une MAJ du cœur, ou erreur PHP fatale non affichée (mode debug désactivé).
Solution : activer define('_PS_MODE_DEV_', true); dans config/defines.inc.php pour afficher l'erreur réelle, puis traiter selon le message. Dans 80 % des cas, c'est un module qu'il faut désactiver via SSH.
20. Too many redirects (boucle de redirection) — classique de l'écosystème
Ce bug n'est pas toujours étiqueté comme tel dans les titres de tickets (souvent libellé "site inaccessible" ou "bug chargement"), mais revient régulièrement dans l'écosystème francophone.
Cause principale : double redirection HTTP vers HTTPS (une côté serveur, une côté PrestaShop), conflit avec un CDN Cloudflare mal configuré, ou règles .htaccess qui se mordent la queue.
Solution : nettoyer le .htaccess (supprimer les doubles redirections), désactiver la redirection côté serveur si elle est déjà gérée par PrestaShop, et vider le cache CDN. Vérifier aussi que PS_SSL_ENABLED et les URLs de domaine sont cohérents dans ps_configuration.
Temps de résolution : ce que la médiane révèle
La durée moyenne de résolution tous clusters confondus est tirée par la longue traîne des migrations et des bugs de modules qui demandent plusieurs interventions étalées sur des mois. La médiane est beaucoup plus parlante : 93 heures, soit environ 4 jours calendaires.
En clair : la moitié des tickets PrestaShop se résout en moins de 4 jours. Les cas qui dépassent la semaine sont des configurations complexes (transporteurs, migrations majeures, modules abandonnés, piratages profonds) où la latence vient autant des allers-retours avec le client et les prestataires externes que du temps technique pur.
Quand faire appel à un pro
Sur la base de nos 3 794 interventions, voici un repère simple :
| Situation | Action |
|---|---|
| Page blanche après MAJ module | Essayer le mode debug + désactivation modules. Si pas de diag en 1h → pro |
| Erreur 500 persistante | Vérifier memory_limit + cache. Si pas de diag en 2h → pro |
| Site piraté (malware visible) | Pro immédiatement, ne touchez à rien |
| Migration à prévoir | Pro systématiquement, la durée moyenne de 63 jours sur ce cluster parle d'elle-même |
| Bug transporteur | Vérifier credentials API. Si pas résolu en 4h → pro |
| Panier qui se vide | Vérifier HTTPS + cookies. Rapide à diagnostiquer pour un pro |
FAQ
Combien de temps pour réparer un bug PrestaShop en moyenne ?
Sur nos 3 793 tickets PrestaShop clôturés, la médiane est de 93 heures (environ 4 jours). La moyenne est bien plus haute, tirée par les cas complexes (migrations, piratages multi-sessions, modules abandonnés). Un bug simple (SSL, page blanche isolée, back-office inaccessible) se résout souvent en moins de 24 heures — notre cluster SSL/HTTPS se résout en 20 heures de moyenne.
Quel est le bug PrestaShop le plus fréquent en 2026 ?
Sur notre base de 3 794 tickets sur 7,5 ans, c'est l'erreur 500 / internal server error (6,9 % des tickets), suivie de près par les migrations/MAJ PrestaShop (5,8 %) et les bugs de modules (5,8 %). Ces trois clusters cumulent près d'un cinquième de tous les tickets PS.
Les bugs PrestaShop 9 sont-ils différents de ceux de PrestaShop 8 ?
La plupart des bugs listés ici existent sur les deux versions. PrestaShop 9 corrige certains bugs historiques mais en introduit d'autres, notamment sur la compatibilité des modules développés pour la version 8.
Puis-je réparer un bug PrestaShop moi-même ?
Pour les bugs simples (régénération images, reconstruction index de recherche, SSL expiré), oui. Pour tout ce qui touche au code, à la base de données, au paiement ou à une intrusion, l'intervention d'un spécialiste évite d'aggraver la panne et fait gagner beaucoup de temps.
Ma boutique est en panne, que faire en priorité ?
Ne touchez à rien, faites une sauvegarde complète (fichiers et base), activez le mode maintenance si le front est impacté, et contactez un prestataire. Plus vous manipulez un bug sans méthode, plus le diagnostic devient coûteux.
Conclusion
Ce classement s'appuie sur 3 794 interventions réelles sur des boutiques PrestaShop entre octobre 2018 et avril 2026 — soit 7,5 ans d'expertise continue sur l'écosystème. Les enseignements pratiques :
- Les erreurs 500 et les mises à jour sont en tête des causes de panne, suivies de très près par les bugs de modules tiers. Si vous prévoyez une MAJ, prévoyez aussi l'intervention qui ira avec.
- Les bugs de modules, paiement et email sont les plus longs à stabiliser (plus de 2 000h en moyenne), principalement à cause des dépendances externes et de l'abandon éditeur.
- La moitié des tickets PrestaShop se résout en moins de 4 jours (médiane 93h), la majorité des cas complexes étant liés à des enchaînements bug → migration → incompatibilités.
Si votre boutique présente un des symptômes décrits, ouvrez un ticket en 2 minutes via notre chat et un expert PrestaShop diagnostique votre problème. Intervention à l'unité, sans forfait mensuel obligatoire.
Si votre site est sur WordPress plutôt que PrestaShop, voir notre page dépannage WordPress dédiée aux bugs WooCommerce et écrans blancs.
Vous avez le même problème ?
Décrivez votre problème, notre équipe vous répond en moins de 10 minutes avec un diagnostic gratuit.
Obtenir un diagnostic gratuit