PrestaShop

PrestaShop n’est pas WordPress

C’est un vrai logiciel de commerce, plus puissant, et beaucoup moins tolérant à l’erreur. Une erreur de configuration sur les transporteurs ou les règles de taxe ne se voit pas tout de suite : elle se voit sur la marge, trois mois plus tard.

Ce sur quoi j’interviens

• Montées de version 1.7 vers 8, avec recette complète avant bascule.
• Transporteurs et frais de port : zones, tranches de poids ou de prix, outre‑mer.
• Tunnel de commande : abandons, paiements en attente, commandes fantômes.
• Modules : conflits, modules abandonnés, remplacement par du code natif.
• Performance : cache, images, requêtes SQL lentes sur les gros catalogues.
• Sécurité : failles des modules, version de PHP, clés de webservice oubliées.

Le piège des commandes en attente

Sur presque toutes les boutiques que je reprends, il y a des centaines de commandes figées en attente de paiement. Beaucoup de commerçants les prennent pour des ventes perdues à relancer. Ce sont, dans leur immense majorité, de simples abandons de panier : le client n’est jamais allé jusqu’au paiement.

Savoir faire la différence change tout : ici on relance, là on corrige le tunnel.

Une précaution que je ne négocie pas

Sur une boutique en production, aucune opération de masse sans avoir testé l’effet sur un seul élément d’abord. Annuler quarante étiquettes d’expédition peut faire basculer trente commandes dans un statut erroné, et déclencher trente courriels aux clients. Cela s’est déjà vu. On vérifie d’abord toute la chaîne.

Faut‑il monter en version 8

Si votre boutique est en 1.7, la question n’est pas de savoir si vous allez monter, mais quand. Les versions 1.7 ne reçoivent plus de correctifs, et les modules de paiement finissent par exiger une version récente.

En revanche, une montée de version ne s’improvise pas. Elle se prépare sur une copie complète de la boutique, avec une recette écrite qui va jusqu’au paiement réel, et un chemin de retour prêt avant de commencer. Le jour de la bascule ne doit apporter aucune surprise.

Sur une boutique qui vend, l’opération se fait de nuit. Une commande passée pendant la copie de la base serait enregistrée dans l’ancienne, et disparaîtrait au moment de la bascule. Le client a payé, il a reçu sa confirmation, et vous ne verrez jamais son achat.

Les modules : ce que je remplace par du code

Une boutique installée depuis plusieurs années porte en moyenne une centaine de modules, dont une bonne part ne sert plus. Chacun charge son code, ajoute ses tables, et peut ouvrir une faille : plusieurs des vulnérabilités les plus graves de l’écosystème PrestaShop viennent de modules tiers, pas du cœur.

Quand un module payant ne rend qu’un service simple, je le remplace par quelques lignes dans le thème. Moins de code chargé, plus de mise à jour à suivre, et une dépendance de moins.

Par où je commence sur une boutique que je découvre

• La version du cœur et celle de PHP, et les failles publiées qui les concernent.
• Les transporteurs tels qu’ils apparaissent dans le tunnel de commande, et non tels qu’ils sont réglés dans l’administration : un transporteur « activé » n’est pas forcément livrable.
• Les commandes figées, pour distinguer les abandons des paiements réellement encaissés mais non enregistrés.
• Les sauvegardes, et surtout la preuve qu’une restauration fonctionne.

Ce premier passage se fait en lecture seule. Rien n’est modifié tant que l’état des lieux n’est pas écrit et que vous ne l’avez pas validé.

Les frais de port, là où se joue la marge

C’est le réglage le plus mal compris de PrestaShop, et celui qui coûte le plus cher. Une boutique peut facturer un transport au poids alors que son contrat transporteur est au prix, et perdre quelques euros sur chaque commande pendant des mois sans que rien ne l’alerte.

Le contrôle ne se fait pas dans l’administration mais dans le tunnel de commande, avec des adresses réelles, y compris l’outre‑mer et les frontaliers. C’est le seul endroit où l’on voit ce que voit le client.

Ce que je ne fais pas

Je n’installe pas de module dont je ne sais pas ce qu’il fait dans la base de données. Un module qui crée ses propres tables et ses propres champs laisse des traces bien après sa désinstallation.

Et je ne lance jamais une opération de masse sans avoir vérifié son effet sur un seul élément d’abord, y compris ce que reçoit le client par courriel.