Modules et extensions : acheter, faire développer, réparer

À qui s’adresse cette rubrique

On arrive ici dans deux états d’esprit très différents. Soit il manque une fonction : un configurateur de produit, un paiement en plusieurs fois, un écran de suivi pour l’équipe, une notification qui n’existe pas en standard. Soit un module déjà installé pose problème : il a cessé de s’afficher après une mise à jour, il entre en conflit avec un autre, il ralentit chaque page, ou son éditeur ne répond plus.

Dans les deux cas la question de fond est la même : jusqu’où faut-il s’appuyer sur l’existant, et à partir de quand vaut-il mieux écrire du code que l’on maîtrise. Ces pages répondent en donnant les critères, pas une recommandation unique — le bon arbitrage dépend du volume de commandes, de la durée de vie prévue de la boutique et de qui la maintiendra ensuite.

Comment la rubrique est organisée

Les vingt-quatre pages suivent le cycle de vie d’un module. Les pages de décision d’abord : acheter ou faire développer, officiel, tiers ou sur mesure, ce qui fait réellement le prix, comment cadrer un besoin avant de demander un devis. Puis les besoins fonctionnels les plus fréquents : abonnement et espace membre, acompte et paiement fractionné, configurateur, documents PDF, notifications, champ supplémentaire sur un produit ou une commande, écran métier dans le back-office, service après-vente, traitement en tâche de fond.

Viennent ensuite les pannes : module cassé après une mise à jour, conflit entre deux modules, module actif dont rien ne s’affiche, modifications écrasées, module qui ralentit la boutique, éditeur disparu. Et enfin le cycle de vie : auditer un parc de modules, tester avant la production, désinstaller proprement, maintenir dans le temps, reprendre un développement inachevé.

Ce qu’un module fait vraiment à votre boutique

Un module n’est pas une brique posée à côté du site : il s’insère dedans. Sur PrestaShop, il se greffe sur des hooks, ajoute ses tables, et peut déposer un fichier dans override/ pour modifier le comportement d’une classe du cœur. C’est là que naissent la plupart des conflits : deux modules qui veulent surcharger la même méthode ne peuvent pas coexister, et le second refuse simplement de poser son override, souvent sans message visible pour le commerçant.

Sur WooCommerce, le mécanisme équivalent passe par les actions et les filtres, et par les gabarits recopiés dans le thème enfant sous woocommerce/. Ces copies ne suivent pas les mises à jour de l’extension : quand WooCommerce fait évoluer un gabarit, la copie continue d’être utilisée telle quelle, et la page s’affiche avec une version périmée. C’est la cause la plus banale d’un tunnel de commande qui perd une mention légale ou un champ après une montée de version.

Retenir ces deux mécanismes suffit à comprendre pourquoi un parc de modules se dégrade avec le temps, et pourquoi la question à poser avant d’acheter n’est pas seulement « fait-il ce que je veux » mais « que touche-t-il ».