PrestaShop a intégré Symfony dans son cœur dès la version 1.7. Pourtant, rares sont les modules qui vont au-delà du strict minimum. Chez Mintfull, on voit les choses autrement : Symfony n’est pas juste là pour faire joli. C’est un vrai levier pour développer plus vite, plus proprement… et surtout pour créer des modules PrestaShop à la hauteur des attentes modernes.
Pourquoi ça nous parle ? Parce qu’on fait aussi bien du PrestaShop que du Symfony en full-stack. Et forcément, quand les deux mondes se croisent, ça donne des modules costauds, pensés pour durer.
Pourquoi intégrer Symfony dans vos modules PrestaShop ?
Intégrer Symfony dans vos modules, ce n’est pas une coquetterie technique. C’est un vrai changement de paradigme dans la façon de développer sur PrestaShop. Vous passez d’un environnement global, parfois rigide et difficile à tester, à un écosystème modulaire, propre et extensible.
Concrètement, ça change quoi ?
◉ Un conteneur de services : fini les helpers globaux ou les appels à $this->module->context. Vous structurez votre logique métier en services réutilisables, testables, injectés automatiquement avec leurs dépendances. Ça vous évite les appels statiques et rend votre code bien plus maintenable.
◉ Des commandes CLI : vous pouvez créer vos propres commandes Symfony, accessibles via bin/console. Parfait pour lancer des traitements lourds, programmer des cron, importer/exporter des données ou même tester un comportement métier sans interface. Et c’est bien plus propre que de bidouiller un contrôleur d’admin pour “déclencher un script”.
◉ Doctrine ORM : au lieu de manipuler la base avec Db::getInstance() ou de galérer avec un ObjectModel, vous créez des entités riches, typées, capables d’encapsuler de la logique métier. Vous profitez aussi de l’autocomplétion, des relations entre objets, de la DQL… bref, vous codez comme dans n’importe quelle app Symfony moderne.
Mais surtout, vous gagnez en confort : votre module devient un petit projet PHP bien architecturé, isolé, documenté, versionné. Vous bossez mieux, plus vite, et à plusieurs sans vous marcher sur les pieds.
Et ça, quand on développe à plusieurs, avec de la dette technique à gérer ou des modules qui évoluent souvent… c’est un game-changer.
3 cas concrets d’intégration avancée de Symfony
Passons aux choses sérieuses. Voici trois usages de Symfony qu’on intègre régulièrement dans nos modules PrestaShop. Ils changent la donne côté qualité, mais aussi côté DX (developer experience).
1. Des commandes console pour automatiser vos tâches
Dès la 1.7.5, PrestaShop permet à vos modules de déclarer leurs propres commandes Symfony. Et franchement, c’est sous-exploité.
Chez Mintfull, on les utilise pour :
déclencher des imports produits depuis une API externe
générer des rapports PDF de ventes ou de SAV
reprocesser une file d’attente en cas d’erreur
vider un cache ou recalculer des prix
Côté code, c’est classique Symfony : une classe qui hérite de Symfony\Component\Console\Command\Command, une configuration YAML avec le tag console.command, et hop, votre commande est listée dans php bin/console.
💡 Attention : le contexte PrestaShop n’est pas toujours initialisé. Les objets comme Context::getContext() peuvent renvoyer des valeurs partielles (pas d’employee, pas de langue…). Pour fiabiliser ça, on s’appuie souvent sur le module fop_console de la communauté Friends of Presta. Il embarque un BaseCommand robuste, prêt à l’emploi.
2. Doctrine ORM pour gérer vos entités proprement
Doctrine dans un module PrestaShop, c’est comme changer de monde. Fini les ObjectModel lourds, difficiles à étendre, et souvent couplés au framework.
Vous définissez une entité avec annotations ou attributs PHP, PrestaShop la détecte automatiquement (sous src/Entity/), et vous pouvez utiliser tout le confort de Doctrine : repositories personnalisés, relations, hydrations automatiques, DQL…
⚠️ On le répète : ne lancez jamais de migration Doctrine sur la BDD PrestaShop en production. Préférez un --dump-sql que vous adaptez et appliquez manuellement dans le install() du module.
L’avantage ? Vous isolez vos données métiers dans des entités claires, typées, testables. Ça respire, ça se versionne facilement, et ça s’intègre dans un flux de dev moderne (tests unitaires, fixtures, etc.).
3. Services Symfony et injection de dépendances
L’autre game-changer, c’est le conteneur de services. Avec lui, vous découpez votre code en briques indépendantes, injectées automatiquement. Plus besoin de recharger 15 fois la même dépendance ou d’instancier un helper global à la main.
Vous avez un logger, un traducteur, un client HTTP, un validateur, une classe métier ? Injectez-les. Symfony s’occupe de tout. Et en bonus, vous avez l’autocomplétion et les erreurs au runtime disparaissent.
Et comme PrestaShop distingue le front et le back, vous pouvez charger des services spécifiques via :
-
config/front/services.ymlpour le FO -
config/admin/services.ymlpour le BO - ou un
common-services.ymlsi vous factorisez Dans les modules Mintfull, tous nos traitements métiers sont des services injectables. Résultat : une logique claire, testable, qui ne dépend pas duContextglobal. Et ça, c’est la base pour un module durable.
Structurer son module comme un mini-bundle Symfony
Quand on pousse l’intégration Symfony dans un module PrestaShop, une évidence s’impose vite : il faut structurer le code comme un bundle Symfony.
C’est ce qu’on essai de faire au maximum chez Mintfull. Et ça change tout.
D’un côté, vous avez les modules “classiques”, où tout se passe dans le fichier .php racine, avec des dossiers classes/, controllers/, views/ plus ou moins organisés. De l’autre, un module pensé comme un vrai package PHP, modulaire, bien rangé.
Concrètement, voilà ce que ça donne :
/votremodule/
├─ config/
│ ├─ services.yml
│ ├─ admin/services.yml
│ └─ front/services.yml
├─ src/
│ ├─ Command/
│ ├─ Entity/
│ ├─ Controller/
│ ├─ Service/
│ └─ (autres dossiers métier)
├─ views/ (Smarty ou Twig)
├─ translations/
├─ composer.json
├─ votremodule.php
Pourquoi c’est précieux ?
Vous bénéficiez du PSR-4 autoloading : plus besoin de require_once partout, tout est chargé via Composer
Vos classes sont organisées par rôle : entités, services, commandes, contrôleurs…
Vous pouvez écrire des tests unitaires ou d’intégration sans hack
Un nouveau développeur comprend la logique du module en 2 minutes chrono
Et bonus : vous pouvez réutiliser vos outils Symfony habituels (PHPStan, PHPUnit, PHP-CS-Fixer…) sans adaptation. Le module devient un projet PHP comme un autre — juste branché à PrestaShop.
Les limites de l’approche Symfony dans PrestaShop (et quand en sortir)
On ne va pas se mentir : même avec toutes ses qualités, Symfony dans PrestaShop reste une intégration partielle. C’est puissant, mais ce n’est pas magique. Et il faut connaître les limites pour éviter de se tirer une balle dans le pied.
Voici les principales contraintes à garder en tête :
- ❌ Contexte legacy vs contexte Symfony : une commande CLI ou un service injecté n’a pas toujours accès au Context PrestaShop complet (langue, employé, devise...). Il faut parfois le reconstituer manuellement.
- ❌ Symfony côté front : très limité. Les contrôleurs FO sont encore majoritairement en contexte legacy. Impossible d’utiliser HttpFoundation\Request ou EventDispatcher comme on le ferait en full Symfony.
- ❌ Doctrine et le multi-shop / multi-langue : ça ne marche pas tout seul. Il faut gérer à la main les champs traduits ou les déclinaisons multi-boutique, ce que fait le ObjectModel automatiquement (même si c’est moche).
- ❌ Performance / charge mémoire : lancer un bin/console avec tout le kernel PrestaShop, c’est lourd. Pour de très gros traitements, un microservice Symfony à côté sera plus rapide et plus efficace. Alors, que faire quand ça coince ? On sort du cadre. Littéralement.
Résultat : on garde PrestaShop pour ce qu’il fait très bien (produits, commandes, catalogue), et on s’appuie sur Symfony pour le reste. Sans compromis.
Exemples de modules open-source pour aller plus loin
Pour creuser les usages avancés de Symfony dans un module PrestaShop, rien de tel que de lire du code bien écrit. Voici quelques références qu’on suit (et qu’on utilise parfois comme base) :
🛠 Friends of Presta – fop_console Un module communautaire ultra complet pour ajouter des commandes CLI. Il gère le contexte legacy, fournit une base AbstractCommand solide, et propose des dizaines de commandes prêtes à l’emploi (vider le cache, exporter des produits, etc.). 🧪 PrestaShop – demodoctrine Le module de démo officiel pour Doctrine. Idéal pour comprendre la structure attendue, la déclaration des entités, et la logique CRUD avec Symfony. Pas parfait en prod, mais excellent pour apprendre. 💬 PrestaShop – productcomments Un module natif qui utilise Doctrine de manière propre pour gérer les avis produits. Il montre comment coupler entités, formulaire Symfony et gestion des hooks PrestaShop. Prenez le temps de lire ces modules. Vous y trouverez des patterns, des erreurs à éviter… et sûrement quelques idées à piquer pour vos projets.
Conclusion
Utiliser Symfony dans un module PrestaShop, ce n’est pas une lubie de développeur. C’est une méthode sérieuse pour construire des modules plus solides, plus testables, plus maintenables.
Chez Mintfull, on le fait depuis des années. Parce qu’on code aussi bien des apps Symfony sur-mesure que des modules PrestaShop avancés. Et quand les deux univers se rencontrent, ça donne des résultats nets, efficaces, durables.
Vous avez un besoin spécifique, un module à refondre ou un back-office à muscler ? On en parle quand vous voulez.
