Comment créer un module PrestaShop (guide complet)

Créer un module est la bonne façon d’ajouter une fonctionnalité à PrestaShop : on étend la boutique proprement, sans toucher au cœur ni au thème, et le code survit aux mises à jour. Voici l’anatomie d’un module, les points clés du développement et les bonnes pratiques pour qu’il reste maintenable de PrestaShop 1.6 à 9.

Anatomie d’un module PrestaShop

Un module vit dans son propre dossier sous /modules/monmodule/. La structure minimale :

• monmodule.php : le fichier principal, une classe qui étend Module.
• logo.png : l’icône affichée dans le back-office.
• views/templates/ : les gabarits Smarty (.tpl) front et hook.
• controllers/ : les contrôleurs front et/ou admin.
• config.xml : généré automatiquement, décrit le module.

Le fichier principal

La classe du module déclare ses métadonnées dans le constructeur (nom technique, version, auteur, compatibilité) puis gère son cycle de vie via install() et uninstall(). C’est aussi là qu’on enregistre les hooks :

public function install()
{
    return parent::install()
        && $this->registerHook('displayHeader')
        && $this->registerHook('displayProductAdditionalInfo');
}

Le install() est aussi l’endroit où créer les tables dédiées et les valeurs de configuration ; le uninstall() doit tout nettoyer proprement.

Les hooks : s’accrocher aux événements

Les hooks sont des points d’ancrage déclenchés par PrestaShop (affichage d’une zone, action sur une commande, etc.). Votre module implémente une méthode hookNomDuHook() qui s’exécute au bon moment. C’est le mécanisme à privilégier — bien plus propre que les overrides. J’y consacre un guide complet : les hooks PrestaShop expliqués avec exemples.

Vues front et back-office

Côté front, les hooks d’affichage rendent des templates Smarty (.tpl) auxquels on passe des variables via $this->context->smarty->assign(). Côté administration, pour une vraie interface (listes, formulaires, onglets), on crée un ModuleAdminController. Astuce de compatibilité : privilégier ModuleAdminController plutôt que des contrôleurs Symfony permet de rester cross-compatible entre PrestaShop 8 et 9.

Une base de données dédiée

Si le module stocke ses propres données, on crée des tables préfixées (_DB_PREFIX_) à l’installation et on les supprime à la désinstallation. Pensez aux montées de version : prévoyez une routine de mise à jour de schéma pour les versions suivantes du module.

Bonnes pratiques

• Pas d’override sale : tout passe par les hooks. C’est ce qui évite que vos mises à jour PrestaShop ne cassent le module.
• PSR-4 : organiser le code en namespaces, avec un autoloader (sans forcément Composer).
• Traductions : utiliser $this->l() dans le module et $this->module->l() dans les contrôleurs.
• Requêtes : avec Db::getValue() ou getRow(), ne pas ajouter de LIMIT explicite (ils en ajoutent déjà un — sinon erreur SQL « LIMIT 1 LIMIT 1 »).
• Compatibilité : tester de la 1.6 à la 9 si vous visez large.

Erreurs courantes

• Recourir aux overrides par facilité — la dette technique garantie.
• Oublier le nettoyage en uninstall() (tables et configuration orphelines).
• Mélanger logique métier et présentation dans les templates.
• Coder en dur des chaînes non traduites.

FAQ

Faut-il Composer ? Pas obligatoirement : un autoloader SPL manuel suffit pour respecter PSR-4 sans dépendance.

Un module peut-il être compatible 1.6 à 9 ? Oui, au prix de quelques précautions (choix des contrôleurs, API utilisées).

Combien coûte un module sur mesure ? Voir mon guide dédié : combien coûte un module PrestaShop.

Besoin d’un module fiable et durable ? Découvrez mon offre de développement de module PrestaShop sur mesure ou décrivez votre besoin.