Les modules et les hooks d'un développeur PrestaShop, de la 1.7 à la 9

Le développeur PrestaShop crée et maintient des modules, adapte le thème, branche l'ERP, le transporteur ou le prestataire de paiement, et garde la boutique à jour. Il code en PHP 8 sur MySQL ou MariaDB. Le front reste en Smarty, le back-office moderne en Symfony et Twig. La version 9.0 a fait passer le framework de Symfony 4.4 à 6.4, supprimé l'ancienne page produit et ajouté une API d'administration bâtie sur API Platform, avec OAuth2. Beaucoup de boutiques tournent encore en 1.7, quelques-unes en 1.6.

La montée de version revient dans presque tous les postes. Elle casse les overrides, les modules branchés sur des hooks supprimés et ceux qui comptaient sur des bibliothèques retirées du cœur, comme Guzzle ou SwiftMailer. Un développeur qui en a mené une vous parle de l'inventaire des modules, de la copie de production qui a servi aux tests et des hooks remplacés.

Le profil à surveiller règle tout par override ou en modifiant les fichiers du cœur, parce que ça marche vite sur une boutique. Demandez un module écrit de bout en bout, avec son installation, sa mise à jour et sa désinstallation, et sa cohabitation avec des modules achetés sur PrestaShop Addons. Le PDF contient un cas de 20 minutes sur une boutique 1.7 à passer en 9.

Ce que manipule un développeur PrestaShop au quotidien

Modules

Toute fonction ajoutée passe par un module : une classe principale qui hérite de Module, des méthodes install() et uninstall(), une configuration et, sur les versions récentes, des contrôleurs Symfony pour le back-office. Un module bien écrit crée ses tables à l'installation, les fait évoluer par des scripts de mise à jour et les retire à la désinstallation.

Hooks

Les points d'accroche du cœur. Les hooks display insèrent du contenu dans une page, les hooks action réagissent à un événement comme une commande validée ou un produit modifié. Un module s'y inscrit à l'installation et implémente une méthode hookNomDuHook. Certains hooks disparaissent d'une version à l'autre, et un module peut alors cesser de fonctionner sans erreur visible.

Overrides

Le mécanisme qui remplace une classe ou un contrôleur du cœur. Il est exclusif : deux modules ne peuvent pas surcharger la même méthode sans conflit. La documentation officielle le réserve aux modules propres à une boutique et l'interdit dans les modules partenaires. Une boutique qui en compte beaucoup annonce une montée de version difficile.

Symfony dans PrestaShop

Le back-office migre page par page vers Symfony depuis la 1.7. La version 9 tourne sur Symfony 6.4, avec des contrôleurs déclarés comme services et la décoration de services comme alternative propre à l'override. Les pages pas encore migrées gardent l'ancien AdminController.

Smarty, Twig et thèmes

Le front des thèmes Classic et Hummingbird s'écrit en Smarty, le back-office moderne en Twig. Un thème enfant permet de modifier des templates sans toucher au thème parent. Le développeur doit savoir surcharger le template d'un module dans le thème plutôt que de modifier le module.

ObjectModel, Doctrine et base de données

Les entités historiques (Product, Order, Customer) héritent d'ObjectModel, et les requêtes passent par les classes Db et DbQuery. Les modules récents peuvent déclarer leurs propres entités Doctrine. Les tables product_lang et product_shop portent la logique multilingue et multiboutique, à connaître avant d'écrire la moindre requête SQL.

Webservice et API d'administration

Le webservice historique expose les ressources en XML ou en JSON, avec une clé d'accès par application. La version 9 ajoute une API d'administration bâtie sur API Platform, avec authentification OAuth2. Les deux servent à brancher l'ERP, le PIM ou la logistique.

Montées de version

Le module officiel de mise à jour (autoupgrade) gère le passage d'une version à l'autre. Le vrai travail se fait autour : vérifier chaque module et chaque override sur une copie de la production, remplacer les hooks retirés, reprendre les contrôleurs et tester le tunnel de commande.

Les annonces parlent de développeur PrestaShop, de développeur PHP PrestaShop ou de développeur e-commerce PrestaShop, avec Symfony souvent demandé en plus. Le poste mélange back-end et front : un même module peut demander un contrôleur Symfony, un template Smarty et un peu de JavaScript. PrestaShop est un projet open source d'origine française. La branche 9 est la version courante, la 8 et la 1.7 restent en production chez beaucoup de marchands. Les modules publiés sur PrestaShop Addons ou sur GitHub, et les contributions au cœur, donnent une bonne base pour l'entretien.

Six compétences PrestaShop à valider

• Développement de modules et hooks
• Overrides et alternatives
• Symfony et back-office moderne
• Thèmes Smarty et front
• Données, multiboutique et API
• Montées de version et performance

Questions techniques sur PrestaShop, avec bonnes et mauvaises réponses

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

1. Question 1 · confirmé

   Vous devez envoyer chaque commande validée vers l'ERP du client. Où branchez-vous ce code ?

   Une bonne réponseUn module inscrit sur un hook action, actionValidateOrder ou actionOrderStatusPostUpdate selon le moment voulu. L'appel à l'ERP ne doit pas bloquer la commande : le hook écrit la commande dans une table d'attente qu'un cron traite, avec reprise en cas d'échec et journal des envois. Il vérifie qu'une commande envoyée deux fois n'est pas créée deux fois dans l'ERP.

   Signal d'alerteUn override de la classe Order ou du contrôleur de commande, ou un appel HTTP synchrone dans le hook qui ralentit la commande dès que l'ERP répond mal.

2. Question 2 · confirmé

   Combien d'overrides comptait la dernière boutique que vous avez maintenue, et qu'avez-vous fait de ceux qui posaient problème ?

   Une bonne réponseUn chiffre ou une liste, puis une méthode : chaque override relu, remplacé quand c'est possible par un hook, une surcharge de template, une classe étendue ou une décoration de service Symfony. Il sait qu'un override est exclusif, qu'il est copié dans /override à l'installation et que le cache des classes doit être vidé. Il connaît l'option du back-office qui désactive tous les overrides, utile pour isoler un bug.

   Signal d'alerte« Je ne sais pas, il y en avait beaucoup », ou « l'override, c'est la manière normale de modifier PrestaShop ».

3. Question 3 · confirmé

   Une page catégorie met huit secondes à s'afficher. Comment trouvez-vous la cause ?

   Une bonne réponseLe mode debug et le profiler de PrestaShop pour voir les requêtes SQL, les hooks et les modules qui coûtent, ou un outil comme Blackfire. Causes fréquentes : un module qui fait une requête par produit dans un hook de la liste, un index manquant sur une table de module, le cache Smarty désactivé ou une recompilation des templates forcée à chaque appel. Il corrige la cause avant d'ajouter du cache.

   Signal d'alerte« On passe sur un plus gros serveur » sans mesurer, ou désactiver les modules un par un sur la boutique en ligne.

4. Question 4 · junior à confirmé

   Le client veut changer l'affichage du bloc d'un module sur la fiche produit. Comment faites-vous sans toucher au module ?

   Une bonne réponseUne copie du template du module dans le thème, sous themes/<thème>/modules/<module>/, au même chemin que dans le module : PrestaShop la charge en priorité. De préférence dans un thème enfant, pour garder les mises à jour du thème parent. Il vide le cache Smarty après la modification.

   Signal d'alerteModifier directement le template dans le dossier du module, écrasé à la prochaine mise à jour.

5. Question 5 · confirmé

   L'ERP doit mettre à jour les stocks toutes les dix minutes. Webservice, API d'administration ou module maison ?

   Une bonne réponseSelon la version : en 1.7 ou en 8, le webservice avec une clé limitée à la ressource stock_availables et l'envoi des seules variations ; en 9, l'API d'administration avec un client OAuth2 aux droits restreints. Un module avec son propre endpoint et une file d'attente se justifie si l'ERP envoie des fichiers ou si le volume demande des lots. Il prévoit un journal et un rapprochement régulier des stocks.

   Signal d'alerteUne clé de webservice avec tous les droits, partagée par tous les connecteurs, ou une écriture SQL directe dans la table stock_available.

Les questions fréquentes des recruteurs sur PrestaShop

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.