Refonte PrestaShop après PHP2Shell : sécuriser PHP et moderniser votre boutique
Votre boutique dépend d’une ancienne version de PHP et ses modules bloquent la mise à jour ? Je vous accompagne pour vérifier l’exposition, coordonner la correction avec l’hébergeur et préparer une refonte PrestaShop sur un environnement de test.
Quand une refonte PrestaShop devient-elle pertinente ?
L’alerte PHP2Shell remet en lumière une difficulté fréquente : une boutique fonctionne encore, mais personne ne peut mettre à jour son environnement sans casser un module, un paiement ou une modification spécifique. Une refonte devient pertinente lorsque ces dépendances empêchent durablement de maintenir la boutique. Elle doit alors répondre à un blocage identifié, et non être présentée comme un remède automatique à toute alerte de sécurité.
Je commence par distinguer trois situations : un correctif PHP compatible peut être appliqué sans migration majeure ; quelques composants doivent être adaptés ; ou l’ensemble repose sur une version de PrestaShop, un thème et des modules devenus trop contraignants à maintenir. Cette distinction détermine le périmètre du devis. Elle évite de reconstruire une boutique qui a surtout besoin d’un correctif, et de lancer une simple mise à jour quand les dépendances demandent une migration préparée.
Un audit de compatibilité avant de choisir la version cible
Le couple PrestaShop et PHP doit être vérifié dans la documentation de la version exacte de PrestaShop visée. La branche PHP la plus récente disponible chez l’hébergeur n’est pas forcément celle que votre boutique, votre thème et vos modules peuvent utiliser ensemble. Je relève les versions installées, les modules indispensables, les modifications du cœur, les surcharges et les connexions aux outils externes.
Je classe ensuite les composants à conserver, à mettre à jour, à remplacer ou à reprendre. Les moyens de paiement, la livraison, la facturation et les synchronisations de stock méritent une attention particulière parce qu’une boutique peut afficher son catalogue tout en ayant un tunnel de commande inutilisable. Le résultat attendu est une cible justifiée et une liste de vérifications, avec les dépendances qui restent à résoudre avant toute bascule.
La méthode : protection immédiate, puis refonte sur copie
-
Vérifier PHP et coordonner la correction
Je relève le moteur web réellement utilisé et fais confirmer avec l’hébergeur la correction des deux CVE. Si une mise à jour immédiate est bloquée, les mesures provisoires et leurs limites sont examinées avec lui sans attendre la fin de la refonte.
-
Préparer une copie isolée et des sauvegardes restaurables
La base et les fichiers sont sauvegardés. Une copie de travail sert à tester le nouveau couple PrestaShop/PHP, sans envoyer de vrais e-mails ni déclencher de paiements ou de synchronisations de production.
-
Adapter le thème et les modules
Le thème, les surcharges et les modules sont adaptés à la cible retenue. Chaque fonction métier critique reçoit un scénario de contrôle, y compris les tâches planifiées et les intégrations externes.
-
Préparer la reprise des données et du référencement
Catalogue, clients, commandes et médias font l’objet d’un plan de reprise. Les URL importantes sont inventoriées pour conserver les chemins utiles ou préparer leurs redirections.
-
Organiser et vérifier la bascule
La synchronisation finale, la fenêtre d’intervention et le retour arrière sont préparés. Après la bascule, les commandes, les erreurs serveur et les connexions aux services essentiels sont contrôlées.
Préserver le SEO pendant la migration PrestaShop
Changer de thème ou de version peut modifier les URL, les balises canoniques, la navigation et les liens vers les produits. Avant la bascule, j’inventorie les pages qui reçoivent du trafic et les liens internes importants. Lorsque les chemins peuvent être conservés, cela simplifie la transition ; lorsqu’ils changent, les redirections doivent pointer vers une page réellement équivalente.
Le contrôle porte aussi sur le sitemap, les directives d’indexation et les réglages de la préproduction. Une copie de travail doit rester protégée, tandis que la boutique finale doit pouvoir être explorée. Après la migration, les erreurs d’exploration et les URL exclues sont à surveiller dans Search Console. Ces préparatifs réduisent les risques, sans permettre de garantir une absence de variation de positions ni un délai d’indexation.
Ce que je demande pour cadrer l’intervention
Pour commencer, indiquez la version de PrestaShop, l’hébergeur, la branche PHP connue et ce qui bloque actuellement : erreur lors d’un changement de PHP, module abandonné, thème ancien ou fonctionnalités spécifiques à reprendre. Une liste des modules de paiement et de livraison aide à définir les premiers tests. Les accès techniques sont à transmettre par un canal adapté après le cadrage, jamais dans un formulaire public.
Le périmètre précise les composants concernés, les éléments de catalogue à reprendre, les adaptations nécessaires et les contrôles avant livraison. Si des signes de piratage existent déjà, leur analyse doit être intégrée séparément : recopier une boutique compromise vers un nouvel hébergement peut déplacer le problème. Le correctif du moteur PHP et la suppression d’une éventuelle persistance répondent à deux besoins différents.
Préparer votre projet
-
Comprendre PHP2Shell
Les deux CVE, les versions corrigées et les premières actions à demander à l’hébergeur.
-
Vérifier votre version PHP
Identifier le moteur web et faire confirmer les correctifs du fournisseur.
-
Migration PrestaShop
Préparer un changement de version et les adaptations de thème ou de modules.
-
Maintenance après la refonte
Organiser les mises à jour et les contrôles réguliers de la boutique.
Sources techniques et demande de diagnostic
Le contexte de sécurité est vérifié le 22 octobre 2026 à partir des annonces officielles PHP. La compatibilité de la cible doit être confrontée aux prérequis officiels de PrestaShop 9 ou à la documentation de la version retenue. Les recommandations de mise à jour sont détaillées dans la documentation de maintenance PrestaShop.
Pour cadrer une correction ou une refonte PrestaShop liée à PHP2Shell, décrivez votre situation ou utilisez le questionnaire de migration de cette page. Si la boutique est déjà indisponible, passez par le dépannage urgent.
- 2019 développeur e-commerce depuis
- 1.6 → 9 versions de PrestaShop couvertes
- 3 langues de travail : FR, EN, TR
- 100 % des échanges directs avec le développeur
Aucun intermédiaire : la personne qui répond est celle qui intervient sur le code.
Faisons le point sur votre boutique PrestaShop
Décrivez ce qui vous préoccupe. Les informations techniques sont facultatives : vous pouvez répondre « Je ne sais pas » et passer les étapes qui ne vous concernent pas.