3 erreurs fréquentes avec les modules PrestaShop (et ce qu'elles coûtent vraiment)

Quand un e-commerçant vient me consulter pour un module PrestaShop, je passe souvent les premières minutes à analyser ce qui existe déjà sur la boutique. Et dans la majorité des cas, le problème qu'on cherche à résoudre vient d'une décision prise en amont, une décision qui semblait logique à l'époque.

Trois schémas reviennent systématiquement. Ils ne concernent pas uniquement les petites boutiques ou les marchands débutants. On les retrouve sur des projets bien établis, avec des équipes techniques, et parfois après plusieurs années de fonctionnement correct. C'est d'ailleurs ce qui les rend coûteux : ils s'installent progressivement, sans signal d'alarme immédiat.

Erreur n°1 : modifier directement le code d'un module marketplace

C'est la première réaction face à un module qui "fait presque ce qu'il faut". Le code est accessible, le développeur est disponible, l'adaptation semble rapide. On modifie le fichier PHP directement dans le répertoire du module.

Si le module est sous licence commerciale, la prochaine mise à jour de l'éditeur écrase les modifications. Sans exception. La boutique revient à l'état d'avant, parfois avec des erreurs si les fichiers modifiés ont été restructurés par l'éditeur. Ce cycle se répète à chaque mise à jour, avec le coût en développement que ça implique.

Si le module est open-source, la situation n'est pas meilleure. On pourrait théoriquement maintenir une branche locale, mais en pratique personne ne le fait durablement. Chaque mise à jour PrestaShop, chaque nouvelle version du module devient un diff à réconcilier manuellement. Au bout de deux ans, personne ne touche plus à la branche et le module tourne sur une version abandonnée.

Ce qu'on peut faire à la place, c'est un override dans le dossier /override de PrestaShop. Ça fonctionne, mais c'est vraiment à éviter dans la mesure du possible. À chaque mise à jour du module ou du CMS, il faut vérifier que l'override ne casse rien. C'est un enfer à maintenir, surtout si plusieurs overrides coexistent sur la même boutique.

La vraie question à se poser est simple : est-ce que le module répond au besoin, ou est-ce qu'on peut faire l'effort de s'y adapter ? Si oui, on garde le module tel quel. Si le besoin est trop éloigné de ce que le module propose, développer un module sur mesure est une solution tout à fait viable, et souvent moins complexe qu'on ne l'imagine.

Erreur n°2 : ne jamais désinstaller les modules qui ne servent plus

Une boutique PrestaShop qui tourne depuis quelques années accumule des modules. Certains ont été installés pour tester une fonctionnalité, d'autres répondaient à un besoin ponctuel qui n'existe plus, d'autres encore ont été remplacés par un concurrent sans que l'ancien soit supprimé. Le résultat, c'est un back-office qui ressemble à un cimetière de modules obsolètes.

Le problème n'est pas uniquement visuel. Un module désactivé mais toujours présent peut encore charger des assets, laisser des tables en base de données, ou enregistrer des hooks qui s'exécutent en arrière-plan. Certains modules enregistrent leurs hooks à l'installation et ne les suppriment pas à la désactivation. PrestaShop continue de les appeler à chaque requête, pour rien.

Plus grave : les modules non maintenus sont une surface d'attaque. Un module abandonné par son éditeur ne reçoit plus de correctifs de sécurité. S'il reste installé sur une version vulnérable, il représente un risque réel, même s'il n'est plus utilisé au quotidien.

Faire le ménage régulièrement n'est pas une tâche de confort. C'est une opération de maintenance concrète : désinstaller proprement (pas seulement désactiver), vérifier les tables orphelines laissées en base, et s'assurer que les hooks enregistrés sont bien supprimés. Sur une boutique qui tourne depuis cinq ans sans nettoyage, c'est souvent là qu'on trouve les premières sources de lenteur et d'instabilité.

Erreur n°3 : choisir un prestataire sans vérifier ses références PrestaShop concrètes

PrestaShop est un CMS PHP, ce qui attire parfois des développeurs PHP compétents qui n'ont jamais travaillé en profondeur avec son architecture. La différence se voit dans le code livré.

Un développeur qui connaît PrestaShop sait utiliser ses hooks pour injecter du comportement sans toucher au cœur du CMS. Il sait structurer ses services Symfony, gérer les dépendances via le conteneur IoC, respecter les conventions de nommage et de structure qui garantissent la compatibilité lors des montées de version. Il sait aussi quand un override est inévitable, et comment le documenter pour limiter la dette technique.

Un développeur généraliste peut livrer un module qui fonctionne en recette, mais qui repose sur des overrides massifs, des requêtes SQL directes dans les contrôleurs, ou une gestion des erreurs absente. La boutique fonctionne. Jusqu'au jour où une mise à jour PrestaShop casse l'override, ou où la base de données prend des requêtes non indexées sous charge.

La vérification est simple : demandez à voir des modules opérationnels développés pour d'autres clients PrestaShop. Pas des captures d'écran, pas une démo en local : des références que vous pouvez contacter. Les cas de modules jamais livrés ou d'abandons après acompte versé restent courants dans ce secteur.

Ce que la qualité initiale change sur le coût à long terme

Ces trois erreurs ont un point commun : elles optimisent le coût immédiat au détriment du coût réel sur la durée.

Un module bien développé a une caractéristique qu'on sous-estime au moment du devis : il est facile à reprendre. Architecture claire, gestion des erreurs rigoureuse, logs lisibles, documentation fonctionnelle. Un autre développeur peut le comprendre et l'adapter sans avoir à le réécrire. Une mise à jour PrestaShop implique des ajustements, pas une refonte.

À l'inverse, un module "développé à la va-vite" peut sembler économique à l'achat. Mais chaque intervention ultérieure prend deux fois plus de temps parce que personne ne comprend le code. Chaque montée de version devient une intervention corrective. Et si le prestataire initial n'est plus disponible, la reprise peut coûter plus cher que le développement d'origine.

Ce n'est pas une justification pour des tarifs élevés. C'est un argument pour se poser la bonne question avant de démarrer : quel est le coût total de possession de ce module sur trois ans, pas seulement le coût de développement initial ?

Un point technique sur PrestaShop 9 et les overrides

Si votre boutique est sur PrestaShop 8 ou 9, ou si vous envisagez une migration prochaine, la question des overrides prend une dimension supplémentaire.

PrestaShop 9, sorti en juin 2025, déconseille explicitement les overrides. Ce n'est pas une suppression immédiate, ils fonctionnent encore, mais l'équipe PrestaShop a signalé clairement que cette approche sera progressivement écartée dans les versions futures. Les modules développés aujourd'hui avec des overrides massifs auront une durée de vie limitée.

La nouvelle Admin API de PrestaShop 9, basée sur API Platform, facilite les intégrations ERP, CRM et PIM via des endpoints RESTful mieux documentés. Pour les connecteurs sur mesure, c'est un vrai changement par rapport à PS 8 : moins de bricolage autour des contrôleurs legacy, une architecture plus solide.

Si vous avez des modules sur mesure développés sur une base PS 1.7, comptez généralement deux à cinq jours de développement pour les adapter avant de migrer vers PS 9. C'est un coût à anticiper dans le budget de migration.

En pratique

Ces trois erreurs ne sont pas des fautes. Ce sont des décisions prises dans des conditions de contrainte : temps limité, budget serré, besoin urgent. L'objectif n'est pas de les éviter à tout prix, mais de les identifier avant qu'elles ne s'accumulent.

Avant de lancer un développement ou de corriger une situation existante, un audit technique PrestaShop permet de cartographier l'état réel des modules en place, d'identifier les sources de fragilité et de prioriser les interventions. C'est souvent plus rapide et moins coûteux qu'une refonte complète.

Si votre besoin est déjà identifié et que vous cherchez à le développer proprement, les services de développement de modules sur mesure couvrent le cycle complet, du cadrage à la mise en ligne.