Une migration de version majeure ne se joue pas sur le cœur de PrestaShop, qui se met à jour correctement dans la plupart des cas. Elle se joue sur vos modules. Sur une boutique qui en compte quarante, il suffit qu’un seul touche au tunnel de commande et ne soit plus compatible pour que la migration soit bloquée.
L’audit des modules doit donc précéder tout le reste, y compris le devis.
Ce qui change réellement
PrestaShop 9 s’appuie sur des versions plus récentes de PHP et de Symfony, ce qui entraîne trois familles de ruptures.
Les ruptures liées à PHP. Typage plus strict, propriétés dynamiques dépréciées, fonctions retirées. Un module écrit il y a cinq ans et jamais repris produit des erreurs fatales, pas des avertissements.
Les ruptures liées au framework. Les modules qui étendent des contrôleurs Symfony ou qui déclarent des services doivent suivre la nouvelle version. C’est le cas des modules récents et bien construits, paradoxalement plus exposés que les modules purement legacy.
Les ruptures propres à PrestaShop. Méthodes supprimées des classes historiques, hooks retirés ou renommés, changements dans les templates du thème par défaut.
L’inventaire, premier livrable
Avant toute manipulation, produisez un tableau avec une ligne par module et six colonnes.
- Nom technique et version installée.
- Éditeur, et son existence actuelle. Un éditeur disparu est un module condamné.
- Date de la dernière mise à jour disponible. Au-delà de dix-huit mois sans publication, considérez le module comme abandonné jusqu’à preuve du contraire.
- Compatibilité annoncée avec la version cible, en distinguant ce qui est écrit sur la fiche produit de ce qui est réellement testé.
- Criticité : le module touche-t-il au paiement, au tunnel, au catalogue, ou seulement à un affichage secondaire ?
- Présence d’overrides, visible dans le dossier des surcharges. C’est le meilleur indicateur de fragilité.
Ce tableau se remplit en une demi-journée et il détermine tout le reste du projet.
Les quatre catégories
Chaque module tombe dans l’une d’elles, et le traitement diffère.
Compatible et maintenu. Vous mettez à jour et vous testez. C’est le cas le plus simple, et il représente rarement la majorité.
Compatible annoncé mais non vérifié. La mention sur la fiche produit ne vaut pas recette. Ces modules doivent être testés en priorité, parce qu’une incompatibilité découverte tard coûte un report.
Abandonné. Deux issues : trouver un remplaçant, ou faire reprendre le code. La reprise n’a de sens que si la fonctionnalité est spécifique à votre activité.
Remplaçable par du natif. Catégorie systématiquement sous-estimée. Chaque version majeure intègre des fonctions qui existaient auparavant sous forme de modules. Une migration est le bon moment pour désinstaller ce qui ne sert plus.
Sur les audits réels, ce dernier tri retire souvent entre cinq et dix modules de la liste, ce qui allège d’autant le projet.
Vérificateur de Liens Morts PrestaShop 8 & 9 - Liens Cassés & Images ManquantesTrouvez les liens morts et les images cassées avant vos clients€59.00
Les pièges techniques les plus fréquents
Pour les développeurs et les agences, quatre ruptures reviennent constamment sur les modules à reprendre.
La méthode de traduction disponible directement sur les contrôleurs a disparu : il faut passer par l’instance du module. Les surcharges de méthodes dont la signature a changé produisent des erreurs de compatibilité, notamment sur les méthodes de rendu utilisées pour les réponses asynchrones. Les appels asynchrones aux contrôleurs d’administration historiques ont changé de forme et exigent que les paramètres soient passés différemment. Et les modules qui écrivaient directement dans des tables du cœur se heurtent aux évolutions de schéma.
Aucune de ces corrections n’est complexe prise isolément. Le coût vient du nombre.
L’environnement de recette
Non négociable, et pourtant régulièrement sauté.
Il doit reposer sur une copie récente de la base de production, pas sur un jeu de démonstration. La plupart des incompatibilités apparaissent sur des données réelles : produits avec cent déclinaisons, clients avec des adresses incomplètes, commandes dans des statuts oubliés.
Deux précautions : anonymisez les données clients avant de copier, et désactivez tout envoi d’email depuis cet environnement. Un test de migration qui envoie deux mille emails de changement de statut à de vrais clients est une histoire vraie et fréquente.
Le plan de test
Testez des parcours, pas des pages. Six parcours couvrent l’essentiel.
Une commande complète en tant que visiteur non connecté, avec paiement réel en environnement de test. Une commande avec un compte existant et une adresse enregistrée. Un ajout au panier depuis une page catégorie avec filtres actifs. Une recherche interne suivie d’un achat. Un retour ou une demande de service après-vente. Et côté administration, la création d’un produit avec déclinaisons et la validation d’une commande.
Chaque parcours doit être joué sur desktop et sur mobile. Comptez une journée pour l’ensemble, à refaire après chaque correction significative.
La bascule et l’après
Prévoyez la migration en dehors des périodes commerciales, avec une fenêtre de retour arrière définie et testée. Une sauvegarde qui n’a jamais été restaurée ne compte pas.
Les jours suivants, trois contrôles s’imposent. Les journaux d’erreur du serveur, qui révèlent les incompatibilités que la recette n’a pas rencontrées. Les liens et images cassés, car un changement de version peut affecter les chemins d’images et les URL réécrites. Et le suivi des commandes, à comparer au niveau habituel : une chute brutale signale un blocage dans le tunnel que personne n’a signalé.
Sur ce dernier point, le Vérificateur de Liens Morts pour PrestaShop est utile en phase de recette comme après la bascule : il détecte les liens internes cassés et les images manquantes que la migration a pu produire, sur PrestaShop 8 comme sur PrestaShop 9.