C'est le réflexe le plus coûteux du e-commerce : une boutique ralentit, on prend un serveur plus puissant, rien ne change. Dans la grande majorité des cas que j'ouvre, la seconde perdue est dans la façon dont la boutique va chercher ses données, pas dans la machine : un raccourci manquant, des tables de filtres jamais remises à jour, ou les restes de modules désinstallés il y a deux ans.
La recherche à facettes, le filtrage par taille, couleur, prix ou disponibilité, est le point sensible. Pour filtrer un catalogue, PrestaShop s'appuie sur des tables de filtres, des tableaux préparés à l'avance dans la base de données, qui doivent être construites puis tenues à jour. Après un import massif, elles restent souvent dans l'état où elles étaient avant : la requête (la question que la boutique pose à sa base pour afficher une page) fonctionne toujours, mais elle parcourt le catalogue au lieu de lire un index, le sommaire qui permet de trouver une donnée sans tout relire.
Sur trois mille références l'effet est invisible ; sur quinze mille, la page catégorie passe à quatre secondes et personne ne comprend pourquoi. Le deuxième foyer est la table des métadonnées de produits et l'accumulation générale. Chaque module installé crée ses tables ; désinstallé, il les laisse presque toujours derrière lui.
Une boutique de quelques années traîne ainsi des dizaines de tables mortes, des colonnes inutilisées et des lignes orphelines : cela ne casse rien mais alourdit les sauvegardes, les migrations et parfois les requêtes qui croisent beaucoup de tables à la fois. Le travail consiste à mesurer avant de toucher : activer le journal des requêtes lentes (un relevé automatique des questions qui prennent trop de temps), identifier les cinq ou six qui pèsent réellement, et voir ce qu'un index bien placé change. On termine par l'entretien : reconstruction des tables de filtres après import, purge des données de session et de panier abandonné, et une sauvegarde dont on vérifie qu'elle se restaure.
Une base saine ne se voit pas ; c'est précisément l'objectif.
Relevé automatique des demandes lentes sur une période représentative, heures de pointe comprises.
Testés sur une copie, effet mesuré, puis appliqués en production après une sauvegarde.
Tables mortes et données de session purgées. Ce qu'on supprime est listé avant, pas découvert après.
Remise à jour des filtres après chaque import, purge régulière, et restauration de sauvegarde vérifiée à intervalle fixe.
Clients, commandes et produits migrés vers PrestaShop 1.7, avec un environnement de préproduction (une copie d'essai) pour tout vérifier avant la bascule. Suivi sur le long terme, architecture serveur comprise.
Devis gratuit sous 48h. Réponse sous 24h. Aucun engagement.
Certification délivrée par l'éditeur du CMS