En auditant régulièrement des boutiques PrestaShop pour des prospects ou des reprises de maintenance, on retombe souvent sur les mêmes problèmes techniques. Ce ne sont ni les plus rares, ni les plus spectaculaires, mais ce sont eux qui plombent discrètement les performances, la sécurité ou la maintenabilité d’une boutique. Voici les plus fréquents, avec pour chacun comment les détecter vous-même sans être développeur.
Table des matières
1. Des overrides qui empêchent toute mise à jour
Les overrides sont un mécanisme PrestaShop pour modifier le comportement d’une classe ou d’un contrôleur sans toucher au cœur. C’est prévu par la plateforme. Le problème, c’est quand une agence abuse des overrides pour tout et n’importe quoi : modification mineure d’un template, ajout d’un champ à la volée, logique métier qui aurait dû être dans un module.
Résultat : au moment d’une montée de version mineure ou majeure, chaque override doit être analysé, adapté, testé. Et il suffit qu’un override soit cassé pour bloquer toute la mise à jour.
Comment détecter : connectez-vous en FTP et regardez le dossier /override/. S’il contient plus de 5-10 fichiers pour une boutique de taille moyenne, c’est un signal d’alerte. Si vous y voyez des overrides de Cart, Order, Product avec des dizaines de lignes modifiées, il y a de forts risques que votre future migration soit douloureuse.
2. Un cache désactivé ou mal configuré
PrestaShop sans cache, c’est une boutique à genoux dès qu’on dépasse quelques visiteurs simultanés. Pourtant, c’est très courant. Soit parce qu’une agence a désactivé le cache pendant un développement et a oublié de le remettre, soit parce qu’un module instable oblige à le couper pour « stabiliser » la boutique.
Comment détecter : back-office → Paramètres avancés → Performances. Regardez les blocs « Smarty » et « Cache ». Si « Template compilation » est sur « recompile templates on each call » ou si « Cache » est désactivé, vous perdez 30 à 70 % de performance sans raison valable en production.
Autre test rapide : PageSpeed Insights. Si votre page d’accueil met plus de 3 secondes à afficher le premier contenu, il y a quasi-systématiquement un problème côté cache ou images.
3. Des modules abandonnés ou à la sécurité douteuse
Beaucoup de boutiques tournent avec des modules achetés il y a 5 ou 6 ans, jamais mis à jour, parfois même plus maintenus par leur éditeur. C’est la porte d’entrée n°1 aux incidents de sécurité : la faille SQL injection qui vient d’un module de formulaire ou de newsletter négligé.
Comment détecter : back-office → Modules → Gestionnaire de modules. Si vous voyez beaucoup de modules avec le badge « mise à jour disponible », c’est un premier signal. Regardez aussi les auteurs : ceux qui ne sont plus présents sur PrestaShop Addons sont un risque. Un audit de sécurité rapide (via un outil comme Sucuri SiteCheck ou similaires) peut aussi faire remonter les signatures de failles connues.
4. Des images jamais optimisées
C’est le classique absolu. Les fiches produits sont créées en back-office, les images sont uploadées telles que fournies par le fournisseur : 3 Mo, 4000×3000, format JPEG. PrestaShop génère bien des déclinaisons, mais elles partent d’un original surdimensionné, et au final les vignettes restent trop lourdes.
Comment détecter : ouvrez une page de catégorie. Clic droit sur une vignette produit → Inspecter → regardez la taille réelle du fichier (en bas de l’inspecteur). Si une vignette de 200×200 fait plus de 50 Ko, il y a clairement un sujet. Un passage en WebP ou AVIF peut diviser par 3 à 5 le poids de vos pages.
5. Une base de données jamais nettoyée
Sur une boutique vieille de plusieurs années, la base de données accumule des dizaines de milliers de paniers abandonnés, de connexions invités, de logs de recherche, de cart rules expirées… sans aucun nettoyage. Certaines tables atteignent plusieurs Go et ralentissent tout.
Comment détecter : si vous avez un accès phpMyAdmin, regardez la taille des tables ps_cart, ps_cart_product, ps_guest, ps_connections, ps_statssearch. Si ces tables dépassent plusieurs centaines de Mo, un nettoyage est clairement à prévoir. Côté BO, un temps de chargement long sur la liste des commandes est souvent révélateur.
6. Pas d’environnement de préproduction
Beaucoup de boutiques, même à gros CA, n’ont qu’un seul environnement : la prod. Toutes les modifications (mises à jour modules, nouveau thème, test de template, nouveau module de paiement) se font directement sur la boutique en ligne. C’est jouer à la roulette russe avec son chiffre d’affaires.
Comment détecter : demandez simplement à votre agence ou votre prestataire : « Où est-ce que vous testez les mises à jour avant de les mettre en prod ? ». Si la réponse est évasive, ou pire « directement en prod, on fait attention », il y a un vrai problème de méthode.
7. Des sauvegardes qui n’ont jamais été testées
Dernier classique, et pas des moindres. L’hébergeur fait peut-être des sauvegardes, mais personne ne les a jamais testées. Le jour où il faut restaurer, on découvre que le backup ne contient pas la base, ou qu’il est corrompu, ou qu’il date d’il y a 3 semaines.
Comment détecter : demandez la dernière fois qu’une restauration test a été faite. Si la réponse est « jamais », vous savez ce qu’il reste à faire.
Envie d’un audit technique sans jargon ?
L’équipe MDWeb propose des audits techniques PrestaShop avec un rapport clair, priorisé par impact (perf, sécurité, SEO, dette technique). Sans jargon, sans baratin, et avec une estimation des efforts de remédiation. Si ça vous parle, on en discute.