Panier d'achat
- iKhronos
- PrestaShop
- 34 vues
L’ESSENTIEL
Une boutique PrestaShop 8 bloquée par la bascule PHP 8.1 → 8.2 de son hébergeur : migration directe vers 9.2 réalisée en une demi-journée, avec environ dix minutes d’interruption et les URL conservées.
, une boutique marchande s’est retrouvée dans une situation délicate : son hébergement, Hostinger, a appliqué le correctif de la faille PHP2Shell en faisant passer le site de PHP 8.1 à PHP 8.2. Or la boutique tournait sous PrestaShop 8.1.4, une version qui s’arrête à PHP 8.1. Voici comment cette migration forcée vers PrestaShop 9.2 a été préparée puis réalisée en une demi-journée, avec environ dix minutes d’interruption.
Le contexte : un correctif de sécurité qui décale la ligne de compatibilité
Le cas illustre concrètement ce que nous décrivions dans nos articles sur PHP2Shell et la compatibilité PHP : le correctif d’une faille se joue sur le serveur, mais c’est la boutique qui doit suivre. Après la bascule de l’hébergement en PHP 8.2, la boutique se retrouvait coincée : PHP 8.2 non prise en charge par PrestaShop 8, et un retour en PHP 8.1 impossible puisque c’est précisément ce que le correctif de sécurité venait de fermer. La seule sortie saine était une migration vers PrestaShop 9, qui accepte les versions maintenues de PHP.
La contrainte supplémentaire : la boutique devait rester ouverte et continuer de vendre pendant la préparation.
Ce que l’étude de faisabilité a établi
Aucune décision n’a été prise sur la foi d’un numéro de version. Un audit a d’abord dressé l’inventaire réel : environ 2 000 produits, plus de 12 000 clients et plus de 12 000 commandes, 84 modules actifs et un thème enfant personnalisé. L’étude de faisabilité qui en a découlé a validé, sur une copie restaurée depuis les fichiers et la base de production :
- la trajectoire directe de PrestaShop 8.1.4 vers 9.2.0, démontrée sur la copie, sans palier intermédiaire pour ce dossier précis ;
- la conservation des données, vérifiée par comparaison de tables et des garde-fous sur les données sensibles : noms de clients, totaux payés, prix produits, numéros de suivi : toute modification non prévue bloque l’opération ;
- les adaptations de compatibilité nécessaires sur 67 fichiers de modules et du thème, contrôlées par empreintes avant/après et par des vérifications syntaxiques sous PHP 8.1, 8.4 et 8.5 ;
- une recette sous PHP 8.4 et PHP 8.5 : pages, panier, tunnel de commande, écrans d’administration, journaux sans nouvelle erreur ;
- la liste des réserves de production, assumée comme telle : conditions du serveur cible et échanges réels avec les prestataires de paiement et de livraison à valider avant ouverture.
Ce dernier point compte autant que les autres : l’étude n’a pas déclaré la migration « réussie » sur la base des seuls tests locaux. Elle a précisément séparé ce qui était démontré de ce qui restait à vérifier en production.
Où le savoir-faire PHP/Symfony a fait la différence
PrestaShop 9 s’appuie sur Symfony 6.4. Les 67 fichiers à adapter ne relevent pas du bricolage de versions : contrats de retour de méthodes, propriétés manquantes, types nullable, encodage JSON, points de chargement historiques : du développement PHP et Symfony classique, appliqué à l’écosystème d’une boutique réelle. C’est précisément le croisement de deux compétences qui a permis de tenir les délais : iKhronos suit PrestaShop depuis son origine en 2007 et développe au quotidien en PHP/Symfony, y compris sur des outils métier maison. Sans cette double lecture, les incompatibilités d’un parc de 84 modules actifs se transforment en impasse.
La bascule en production
½ journée
d’intervention, préparation incluse
≈ 10 min
d’interruption de service seulement
L’intervention, telle que déroulée chez le client : le site a rouvert sous PrestaShop 9.2 sans rupture visible pour les clients, avec les URL existantes conservées. Le retour arrière préparé n’a pas eu à être utilisé.
Ce que ce cas montre et ne montre pas
Ce cas montre qu’une trajectoire directe de PrestaShop 8 vers 9.2 peut être tenue, y compris en urgence, à condition que la préparation soit faite : inventaire réel, copie restaurée, données contrôlées, adaptations documentées, recette sous plusieurs PHP et réserves assumées. Il montre aussi que l’essentiel du travail se joue avant la bascule.
Ce que ce cas ne montre pas : toute boutique 8.1.4 ne peut pas suivre le même chemin : l’étude précise que ce lot validé ne se transpose pas par analogie. Chaque dossier exige sa propre vérification (modules, thème, paiements, hébergement) ; aucune durée n’est promise par analogie.
Si votre boutique est bloquée par une version de PHP ou par son hébergeur, décrivez-nous la situation : parlons de votre besoin. La méthode complète est décrite sur notre page Maintenance, migrations et développement PrestaShop, et notre offre de maintenance et assistance couvre le suivi dans la durée.
Fait éditorial : les constats techniques proviennent du dossier interne du projet (audit, étude de faisabilité et pièces de validation, 31 octobre 2026), anonymisé pour cette publication ; le déroulé de production et les durées citées sont rapportés par iKhronos, intervenant du dossier. Le client n’est pas nommé.