Lecture : 8 min · Yoan Gwizdala

Modules, thème, overrides : ce qui survit à une migration PrestaShop

PrestaShop se met à jour presque tout seul. Ce qui coûte cher dans une migration, ce n'est jamais PrestaShop : c'est tout ce que vous avez ajouté autour. Les modules, le thème, et le code qu'un prestataire a écrit un jour pour régler un problème que vous avez oublié.

Le tableau qui résume tout

Le saut	Le thème	Les modules
1.6 → 1.7	Inutilisable. Bascule sur le thème Classic, aucune conversion automatique.	Non installables. Hooks retirés, structure différente : chaque module se rachète ou se réécrit.
1.7.8 → 8	Conservé. Ajustements ponctuels au pire.	La plupart passent. Le vrai sujet est PHP 8, pas PrestaShop.
8 → 9	Templates à reprendre : plusieurs pages préparent désormais leurs données autrement.	Ruptures réelles : Symfony 6.4, hooks retirés, contrôleurs à déclarer en services.

Autrement dit : le saut cher est derrière vous si vous êtes déjà en 1.7. Il est devant vous si vous êtes en 1.6.

Ce qui a réellement changé en PrestaShop 9

La 9.0 est sortie en juin 2025. C'est la première version depuis longtemps qui demande un vrai travail d'adaptation aux modules, et il vaut mieux savoir pourquoi avant de recevoir un devis :

Symfony passe de 4.4 à 6.4, et PHP 8.1 devient le minimum. Un module qui n'a pas été retouché depuis PrestaShop 8.0 a de bonnes chances de tousser.
Des bibliothèques historiques ont été remplacées : Guzzle par le client HTTP de Symfony, SwiftMailer par Symfony Mailer. Un module qui les utilisait directement doit être repris.
Une trentaine de hooks ont disparu, dont tous les actionAdminProducts* : l'ancienne page produit du back-office n'existe plus. Tout module qui s'y greffait doit être réécrit.
Les contrôleurs doivent être déclarés comme services. C'est une réécriture, pas un réglage.
L'autoloader historique a été retiré, et le back-office est passé entièrement sous Symfony et Twig.
Des fonctionnalités ont été supprimées : la gestion avancée des stocks, la livraison multi-adresses, les images haute densité, la possibilité de désactiver un module sur mobile.
Le chiffrement SSL des mails a disparu : c'est TLS ou rien. Un réglage d'envoi hérité de 2015 doit être revu.
Compiler les assets d'un thème demande Node 20. Détail invisible pour vous, structurant pour qui reprend un thème sur mesure.

Le cas qui surprend le plus : la gestion avancée des stocks. Si votre boutique s'en sert — entrepôts, réapprovisionnement, valorisation — la migration en 9 devient une question métier avant d'être une question technique, et elle se traite avant de signer quoi que ce soit.

Quatre cas, et un seul est gratuit

Chaque module de votre boutique tombe dans l'une de ces quatre cases. L'inventaire consiste à les répartir ; le devis, à additionner.

Module d'éditeur encore vendu et maintenu. Le meilleur cas payant : on met à jour, parfois on rachète une licence pour la version majeure. Le coût est connu d'avance, il tient en une ligne.
Module d'éditeur abandonné. On cherche un équivalent, on le configure, on rejoue le paramétrage. Le coût réel n'est pas le module : c'est le temps de retrouver les mêmes réglages.
Module écrit sur mesure. C'est presque toujours la ligne la plus chère du devis. Il faut le lire, comprendre ce qu'il fait vraiment — pas ce qu'on croit qu'il fait — et le réécrire pour la nouvelle version.
Module que plus personne n'utilise. On le supprime, et c'est le seul cas qui fait baisser la facture. Sur une boutique de dix ans, c'est souvent un tiers de la liste.

Compter les modules, vraiment

Le nombre affiché dans le back-office n'est pas le nombre réel. Il faut regarder trois choses :

Les modules installés et actifs — ceux qui comptent.
Les modules présents dans le dossier modules/ mais désinstallés : du code toujours sur le serveur, parfois des tables toujours dans la base.
Les overrides, dans override/, et les fichiers du cœur modifiés à la main. Ce sont eux qui font échouer les mises à jour automatiques sans message clair, et ils ne s'affichent nulle part dans le back-office.

Un module actif qui ne sert plus depuis trois ans ressemble exactement à un module indispensable. La seule façon de trancher, c'est de vous poser la question — d'où l'importance d'avoir quelqu'un côté boutique qui connaît l'activité.

Le thème sur mesure : garder ou refaire

Le calcul est presque toujours le même, et il est rarement celui qu'on attend.

Reprendre un thème sur mesure, c'est payer un développeur pour lire le travail d'un autre, puis l'adapter à une structure de templates qui a changé. Refaire, c'est repartir d'un thème récent et bien entretenu, et remettre votre identité dessus. Sur une boutique de dix ans, refaire est souvent moins cher et donne un meilleur résultat — parce qu'on hérite au passage du responsive, de l'accessibilité et des performances d'un thème moderne.

La bonne raison de garder un thème sur mesure, c'est qu'il fait quelque chose de spécifique à votre métier : un configurateur, un affichage de déclinaisons particulier, un tunnel adapté. Là, on garde et on reprend. « On y est habitués » n'est pas une raison suffisante : vos clients, eux, ne le sont pas.

Ce que ça implique pour le devis

Un devis de migration sérieux liste les modules un par un, avec la case dans laquelle chacun tombe et ce qu'il coûte. S'il n'y a pas cette liste, il n'y a pas de devis : il y a une estimation, et elle bougera. C'est le rôle de l'audit de la produire, et c'est ce qui fait varier le prix d'une migration dans un rapport de un à dix.

Faire l'inventaire de mes modules

Questions fréquentes

Mes modules PrestaShop 1.7 fonctionneront-ils en 8 ?

En grande majorité, oui : PrestaShop 8 est la continuité directe de la 1.7.8, sans rupture du système de modules. Le point de friction vient plutôt de PHP 8, sur lequel un module écrit pour PHP 7.4 peut se comporter différemment. Les vrais cas à traiter sont les modules dont l'éditeur a cessé toute maintenance : ceux-là se remplacent.

Et en PrestaShop 9 ?

Là, il faut vérifier module par module. PrestaShop 9 est passé de Symfony 4.4 à 6.4, exige PHP 8.1 au minimum, a retiré une trentaine de hooks — dont tous ceux de l'ancienne page produit — et impose de déclarer les contrôleurs comme services. Les modules d'éditeurs actifs ont publié des versions compatibles ; les modules sur mesure demandent une reprise réelle.

Faut-il racheter les licences des modules ?

Souvent oui, pour un changement de version majeure : beaucoup d'éditeurs vendent la compatibilité d'une branche à l'autre, parfois à tarif réduit. C'est une dépense qui vous revient directement, pas au prestataire, et elle doit figurer noir sur blanc dans le devis. C'est aussi le bon moment pour se demander si le module en vaut encore le prix.

Mon thème sur mesure sera-t-il conservé ?

De 1.7.8 vers 8, oui, sans chantier. De 8 vers 9, il demande une reprise : plusieurs pages préparent désormais leurs données autrement et les templates doivent suivre. De 1.6 vers n'importe quelle version récente, non : le thème est à refaire, il n'existe aucune conversion automatique. Sur une vieille boutique, repartir d'un thème récent coûte souvent moins cher que de reprendre l'ancien.

Que deviennent les overrides ?

Ils ne survivent pas tels quels, et ce sont eux qui font échouer les mises à jour automatiques sans message compréhensible. Chacun doit être retrouvé — dans le dossier override/, et aussi dans les fichiers du cœur modifiés à la main — puis lu, compris et décidé : réécrire, remplacer par un module standard, ou abandonner. C'est le poste le plus imprévisible d'une migration, d'où l'audit préalable.

La gestion avancée des stocks existe-t-elle encore ?

Non, elle a été retirée de PrestaShop 9, tout comme la livraison multi-adresses, les images haute densité et la désactivation d'un module sur mobile. Si votre boutique utilise réellement la gestion avancée des stocks, c'est une question à trancher avant la migration : soit un module ou un logiciel extérieur reprend le rôle, soit la 8.2 sert de palier le temps de s'organiser.