Les demandes sur PrestaShop commencent rarement par une envie. Elles commencent par une version de PHP qui saute, un module qui ne suit plus, une boutique devenue lente, ou un devis de migration jugé incompréhensible. Voici le calendrier réel des versions, ce qu'une migration casse, ce qui ralentit une boutique qui grossit, et quand il vaut mieux ne pas nous écrire.
Où en est réellement votre boutique
Une boutique en 8.x reçoit encore des correctifs, mais la branche 8.2 est elle aussi passée en support étendu à la sortie de la 9.0 : Une boutique en 8.x reçoit encore des correctifs, mais la branche 8.2 est elle aussi passée en support étendu à la sortie de la 9.0 : elle n'est plus mise à jour que pour un bogue critique ou une faille de sécurité, et cette période s'arrêtera à la sortie de la 10. Son socle PHP recommandé est par ailleurs déjà sorti du support amont., et cette période s'arrêtera à la sortie de la 10. Son socle PHP recommandé est par ailleurs déjà sorti du support amont.
Migrer depuis 1.6 ou 1.7 : ce que cela casse
Le module officiel de mise à jour, aujourd'hui appelé Update Assistant et anciennement 1-Click Upgrade, ne traite pas toutes les versions avec la même branche. Ses versions récentes couvrent PrestaShop 1.7 et au-delà, et son dépôt indique que la mise à jour d'une boutique en 1.6 passe par la branche 4.14.x, en 4.14.3, pour atteindre d'abord une version 1.7. Une boutique en 1.6 se met donc à jour en deux temps, et le premier saut bascule le thème sur le thème par défaut et désactive les modules non natifs : la charge de travail n'a rien à voir avec une montée de version depuis une 1.7 déjà en place.
Ce qui ralentit une boutique PrestaShop qui grossit
Un catalogue qui grossit ne ralentit pas de façon linéaire, il ralentit par paliers, et chaque palier a une cause différente. Traiter le mauvais palier coûte cher sans rien changer.
Les déclinaisons sont le premier facteur, et le plus sous-estimé. Elles ne s'additionnent pas, elles se multiplient : trois tailles, quatre couleurs et deux matières font vingt-quatre combinaisons pour un seul produit, chacune avec sa ligne en base, son stock, éventuellement son prix et son image. Une fiche qui doit établir le prix, la disponibilité et l'image de chaque combinaison au moment de l'affichage n'a pas le coût d'une fiche à référence unique, et la page de catégorie qui liste ces produits hérite du même travail.
Les prix spécifiques sont le deuxième. Chaque promotion, chaque tarif par groupe de clients, chaque remise sur quantité, chaque prix négocié pour un compte s'écrit dans une table consultée pour établir le prix affiché. Une boutique qui empile les campagnes sans jamais retirer les règles expirées fait payer cette accumulation sur chaque page produit et chaque page de listing.
Viennent ensuite l'index de recherche, qui doit être régénéré et qui grossit avec le catalogue, les modules greffés sur les points d'accroche d'affichage qui ajoutent chacun leurs requêtes à des pages déjà lourdes, et les fichiers du dossier override qui réécrivent des méthodes appelées en boucle dans les boucles de produits.
L'ordre de traitement compte plus que la liste elle-même. Passer à un hébergement plus puissant avant d'avoir regardé les requêtes revient à payer tous les mois pour ne pas corriger une fois. Nous mesurons d'abord ce que coûte une page réelle de votre boutique, avec votre catalogue et vos modules, avant de toucher au serveur.
Déclinaisons, filtres, contenu dupliqué, et quand ne pas nous écrire
La navigation à facettes est un excellent outil pour l'acheteur et une machine à adresses pour le robot. Chaque combinaison de filtres, chaque tri, chaque page de pagination produit une adresse différente pour un contenu très proche, et un catalogue de taille moyenne suffit à en générer bien plus que la boutique n'a de pages réelles.
Le cœur a bougé sur ce point, et la nuance compte pour savoir ce que vous avez à faire. PrestaShop 9 pose une balise noindex sur les pages de listing appelées avec le paramètre de filtre q ou le paramètre de tri order, à condition que le thème implémente correctement la balise robots dynamique, et ajoute q aux règles du robots.txt qu'il génère. Sur une boutique en 8.x, ce comportement n'est pas fourni : il se met en place dans le thème, et une modification posée ailleurs, dans un override ou un module maison mal isolé, risque d'être écrasée à la mise à jour suivante.
Le travail utile tient en quelques décisions, prises une fois et écrites quelque part. Quelles combinaisons de filtres méritent une vraie page, optimisée et liée depuis la navigation, parce qu'elles correspondent à une demande réelle et mesurable. Lesquelles doivent rester accessibles à l'acheteur mais non indexables. Quels paramètres n'ont aucune raison de créer une adresse. Ce que la balise canonique déclare sur une fiche à déclinaisons, sur une page paginée, sur une page filtrée. Et ce que contient le plan de site XML, qui doit correspondre exactement à ce que vous acceptez de voir indexé, sans un lien de plus.
Quand ne pas nous écrire, maintenant. Si votre boutique tourne, qu'elle est en 8.x à jour, que rien ne casse et que votre sujet est le volume de visiteurs, un prestataire de maintenance ne changera rien à votre chiffre d'affaires. Si votre catalogue tient en quelques dizaines de références sans déclinaisons ni logique de prix, PrestaShop est plus lourd que ce que vous avez à porter, et le dire coûte moins cher que de le maintenir. Si vous cherchez quelqu'un qui se déplace, qui décroche en cas d'incident ou qui anime un comité de suivi, ce n'est pas nous : nous travaillons depuis Dijon, à distance, uniquement par écrit, avec une réponse sous vingt-quatre heures ouvrées. Et si vous attendez un devis ferme sans donner d'accès au code, nous préférons refuser plutôt qu'annoncer un chiffre que l'ouverture du dossier override viendra démentir.
