# Modules PrestaShop incompatibles après une migration

> Un module qui tournait sans problème depuis des années peut disparaître silencieusement ou planter net après une migration PrestaShop. Ce n’est presque jamais un hasard : il y a toujours un mécanisme technique précis derrière, et il se vérifie avant de migrer.

- Source canonique : [https://allaux.fr/prestashop/migration/modules-incompatibles](https://allaux.fr/prestashop/migration/modules-incompatibles)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Sur une copie, cherchez dans modules/ trois motifs précis : la syntaxe à accolades du type $array{0}, supprimée en PHP 8 et fatale ; le hook displayPayment, ignoré depuis la 1.7 au profit de paymentOptions ; et les fichiers de override/ dont la classe du cœur a changé de signature. Ces trois recherches expliquent la plupart des modules qui disparaissent après une migration.

## Comment un module déclare sa compatibilité

Chaque module PrestaShop déclare la plage de versions avec laquelle il fonctionne dans son fichier config.xml, via les balises <compatibility><min> et <max>. La même information existe aussi dans la classe PHP principale du module, sous la forme de la propriété $ps_versions_compliancy. C’est sur cette déclaration que se base le marketplace officiel Addons pour indiquer si un module est proposé comme compatible avec une version donnée : si le module n’a jamais été mis à jour pour couvrir la version cible, il n’apparaît simplement plus comme disponible pour elle.

Cette déclaration ne garantit pas à elle seule que le module fonctionnera réellement : elle indique l’intention de l’éditeur, pas le résultat d’un test exhaustif. Mais son absence est un signal fiable : un module dont la plage de compatibilité s’arrête avant la version visée n’a de toute façon aucune chance de fonctionner correctement.

## Les quatre mécanismes qui rendent un module incompatible

- Le hook de paiement a changé de nom entre PrestaShop 1.6 et 1.7 : displayPayment (1.6) est remplacé par paymentOptions (1.7, 8 et 9). Un module de paiement écrit pour 1.6 et jamais mis à jour n’apparaît simplement plus au moment de payer, sans message d’erreur : c’est une cause fréquente et sournoise de « le module a disparu ».
- Beaucoup de modules anciens utilisent une syntaxe d’accès aux tableaux ou aux chaînes avec des accolades, par exemple $array{0} au lieu de $array[0]. Cette syntaxe a été supprimée en PHP 8 et provoque une erreur fatale dès que le module tourne sur un serveur passé en PHP 8, indépendamment même de la version de PrestaShop installée.
- Le système d’override, qui remplace des fichiers du dossier override/ pour modifier une classe ou un contrôleur du cœur, casse à chaque migration majeure si la classe d’origine a changé de signature ou de structure entre les deux versions : l’override peut alors ne plus être appelé du tout, ou provoquer une erreur PHP à l’exécution.
- Un module déclaré compatible sur le papier peut malgré tout ne jamais avoir été réellement testé sur la version cible par son éditeur, en particulier pour des modules peu maintenus ou abandonnés : la déclaration de compatibilité dans config.xml reflète une intention, pas un test exhaustif.

## Comment je vérifie la compatibilité avant de migrer

1. **Lire le config.xml de chaque module installé** — Je vérifie la plage de compatibilité déclarée dans chaque module réellement installé sur la boutique, y compris ceux qui semblent secondaires.
2. **Vérifier la fiche du module sur Addons** — Je consulte la page du module sur le marketplace officiel pour voir quelles versions sont annoncées comme compatibles par l’éditeur, et si une version à jour existe.
3. **Tester sur une copie de la boutique** — La déclaration de compatibilité ne remplace jamais un test réel. Je migre d’abord sur une copie et j’exerce chaque module dans ses fonctions principales avant de valider la bascule.
4. **Relire manuellement les overrides et personnalisations** — Un module ou une personnalisation qui repose sur beaucoup d’overrides demande une relecture manuelle systématique, pas seulement un test automatisé, parce qu’une erreur d’override peut rester silencieuse jusqu’à ce qu’une action précise la déclenche.

## Que faire quand un module n’a pas d’équivalent officiel sur la version cible

Quand un module n’existe tout simplement pas pour la version visée, je commence par chercher un module équivalent chez un autre éditeur : la fonctionnalité en elle-même est rarement unique, même si le module précis ne l’est plus. Si aucune solution du marché ne convient, je développe un module sur mesure adapté à la nouvelle architecture, en reprenant la logique métier du module d’origine sans hériter de son code devenu obsolète.

## Pages liées

- **Checklist avant une migration PrestaShop** — Ce qu’il faut inventorier et sauvegarder avant de lancer une migration, quelle que soit la version de départ ou d’arrivée. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration))
- **Passer PrestaShop à PHP 8** — Ce que ça implique quand un hébergeur retire PHP 7 de son offre et que le passage à PHP 8 fait planter du code ancien. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))
- **Migration PrestaShop 1.6 vers 1.7** — Passage à Symfony partiel, thème Classic à reconstruire, hook displayPayment disparu : ce que casse réellement le saut de 1.6 vers 1.7. ([/prestashop/migration/1-6-vers-1-7](/prestashop/migration/1-6-vers-1-7))

## FAQ

### Pourquoi mon module de paiement a-t-il disparu de la page de paiement après la migration, sans aucune erreur ?

C’est très probablement lié au changement de hook entre 1.6 et 1.7 : displayPayment est remplacé par paymentOptions. Un module de paiement jamais mis à jour ne s’accroche plus au nouveau hook et disparaît sans message d’erreur.

### Un module annoncé compatible sur Addons peut-il quand même planter ?

Oui, la déclaration de compatibilité dans config.xml reflète l’intention de l’éditeur, pas un test exhaustif sur ma configuration précise. C’est pour ça qu’un test réel sur une copie de la boutique reste indispensable.

### Pourquoi un module qui marchait très bien plante d’un coup après un passage à PHP 8 ?

Souvent à cause d’une syntaxe d’accès aux tableaux avec des accolades, du type $array{0}, supprimée par PHP 8. Cette erreur fatale n’a rien à voir avec la version de PrestaShop, elle vient uniquement du changement de version PHP.

### Un override qui fonctionnait en 1.6 peut-il vraiment casser sans qu’on touche à son code ?

Oui, si la classe qu’il surcharge a changé de signature ou de structure dans la nouvelle version. L’override n’est alors soit plus appelé, soit source d’une erreur PHP au moment de l’exécution.

### Que faites-vous si aucun module équivalent n’existe pour ma version cible ?

Je cherche d’abord une alternative chez un autre éditeur. Si rien ne convient, je développe un module sur mesure qui reprend la logique métier du module d’origine, adapté à l’architecture de la nouvelle version.