Module PrestaShop standard ou sur mesure : comment décider ?

Votre boutique ne fait pas encore ce dont vous avez besoin : une remise réservée à certains clients, un échange avec votre logiciel de gestion, une étape de commande particulière. Trois voies existent, de la moins engageante à la plus engageante : un réglage déjà présent dans PrestaShop, un module du marché, un module développé pour vous. Ce guide donne les critères qui les départagent, et les cas où le sur-mesure est une mauvaise idée.

Avant tout module : le réglage qui existe déjà

Écrivez d’abord le résultat attendu, puis vérifiez que PrestaShop ne le fait pas déjà. Partez d’un scénario concret : qui réalise l’action, avec quelles données, et quel résultat doit apparaître ? Ajoutez les exceptions. Une remise valable pour certains groupes de clients, dans plusieurs boutiques et avec des exclusions n’a pas la portée d’une remise simple.

PrestaShop gère sans module les groupes de clients, les déclinaisons et les caractéristiques des produits, ainsi que les réductions, depuis son menu « Réductions ». Un besoin qui tient dans ces réglages ne demande ni achat ni développement, et n’ajoute rien à maintenir.

Cette description sert aussi pour la suite. Elle permet de comparer deux solutions sur les mêmes critères, et de tester un module avec vos cas réels plutôt qu’avec sa démonstration.

Module du marché ou sur mesure : ce qu’il faut comparer

Un module du marché convient quand il couvre votre scénario, exceptions comprises, sans que son code soit modifié. Le sur-mesure se justifie quand une règle de gestion ou un échange de données n’appartient qu’à vous.

Entre les deux, comparez ce que chaque voie vous engage à faire après l’installation.

La compatibilité se lit, elle ne se suppose pas : chaque module déclare la plage de versions de PrestaShop avec laquelle il fonctionne.

Quand le sur-mesure est une mauvaise idée

• Le besoin n’est pas stabilisé : vous testez une offre ou un mode de livraison. Un réglage ou un module du marché permet d’essayer sans rien avoir à maintenir.
• Le besoin est commun à la plupart des boutiques. Un module suivi par un éditeur pour de nombreux clients sera mis à jour sans que vous le demandiez.
• Personne ne suivra le module après sa livraison. Sans interlocuteur ni budget pour l’adapter aux versions suivantes, il bloquera la première mise à jour.
• Vous cherchez à compenser le défaut d’un autre module. Mieux vaut faire corriger ce module ou le remplacer.

L’excès inverse existe : empiler des modules du marché pour approcher un besoin particulier. La documentation de PrestaShop rappelle que certains modules ralentissent une boutique, surtout lorsqu’ils sont branchés sur les pages essentielles du site. Si la vôtre en est là, commencez par mesurer ce qui la ralentit.

Compléter un module du marché sans le modifier

Quand un module du marché couvre presque tout, on ne touche pas à son code : on lui ajoute un petit module qui porte la différence. Une modification faite dans les fichiers d’un module disparaît à sa mise à jour suivante, puisque l’éditeur livre alors ses propres fichiers.

PrestaShop prévoit pour cela des points d’accroche, les hooks. Sa documentation les décrit comme le moyen d’associer du code à des événements précis de la boutique, par exemple afficher un contenu dans une page ou envoyer un e-mail à la création d’une commande. Un module complémentaire branché sur ces événements vit à côté du module acheté, et chacun se met à jour de son côté.

Demandez à votre prestataire si l’écart peut être traité ainsi. Si la réponse est non, parce que la règle touche au fonctionnement interne du module, il faut un autre module ou un développement sur mesure complet.

Ce qui résiste aux mises à jour de PrestaShop

Un module résiste aux mises à jour quand il se branche sur les hooks et ne remplace aucun fichier de PrestaShop. L’autre technique s’appelle la surcharge : elle remplace une classe ou un contrôleur de PrestaShop par une version modifiée.

La documentation de PrestaShop met en garde contre les surcharges. Elles sont exclusives : si un module surcharge un comportement, un autre module ne peut plus s’appuyer dessus correctement. Elle les déconseille dans tout module destiné à être distribué, les interdit dans les modules de ses partenaires, et les réserve aux modules propres à une boutique, pour un besoin qui ne peut pas être couvert autrement.

Pour un module sur mesure, demandez donc la liste des surcharges prévues et la raison de chacune. Sur PrestaShop 9.2, l’écran Paramètres avancés › Performances propose l’option « Désactiver toutes les surcharges » : sur une copie de la boutique, elle permet de vérifier si un dysfonctionnement vient de l’une d’elles.

Reste le changement de version majeure. À l’intérieur d’une même version majeure, de la 9.0 à la 9.1 par exemple, PrestaShop vise à ne pas rompre la compatibilité des modules, sauf correctif critique. Au-delà, sa documentation donne une règle : tenir chaque module pour incompatible tant que le contraire n’est pas démontré. Les échéances et les points à contrôler sont dans notre guide sur PrestaShop 9.

Le coût sur la durée

Le prix d’achat ou de développement n’est que la première ligne : comptez aussi le paramétrage, les tests, les mises à jour et le jour où vous changerez de prestataire. Mettez les deux voies côte à côte sur la même période, avec les mêmes lignes :

• les licences et leur renouvellement éventuel
• l’installation, le paramétrage et les tests
• l’adaptation à chaque nouvelle version majeure de PrestaShop
• les corrections après la mise en service
• le temps que votre équipe passe à contourner ce que la solution ne fait pas

Un module du marché qui demande des ajustements à chaque mise à jour perd son avantage de départ. Un module sur mesure sans maintenance prévue reporte la dépense à la première migration.

Ce qui doit être livré avec un module sur mesure

• le code source et sa documentation
• les versions de PrestaShop prises en charge
• la liste des hooks utilisés et des surcharges éventuelles
• la procédure de mise à jour du module
• les scénarios de recette, validés avec votre équipe

Des tests définis avec votre équipe valent mieux qu’une promesse générale de compatibilité : ils disent ce qui sera vérifié, par qui, et sur quelle version.

Questions fréquentes