PrestaShop mise à jour rime souvent, dans les échanges avec nos clients, avec appréhension légitime : une montée de version mal préparée peut casser un tunnel d’achat en quelques minutes, ou laisser une faille de sécurité ouverte pendant des mois. Chez Progerance, nous traitons ces migrations sur des boutiques en production réelle, avec du code PrestaShop 1.6, 1.7, 8 et 9 sous les yeux au quotidien.
En 2026, les enjeux ont changé de nature : PrestaShop 9.1 s’appuie sur Symfony 6.4 LTS et exige PHP 8.5, deux briques qui imposent de revoir la compatibilité des modules et des thèmes avant toute manipulation. Ce guide détaille ce que nous vérifions concrètement avant, pendant et après une mise à jour, sans promesse de résultat miracle ni raccourci qui n’existe pas.
En bref : une mise à jour PrestaShop se prépare toujours par une sauvegarde complète, un audit de compatibilité des modules et du thème, puis un test en environnement de pré-production avant toute mise en production. Le passage par le mode maintenance et l’usage prudent du 1-Click Upgrade limitent le risque d’indisponibilité, mais ne dispensent jamais de vérifications manuelles. Reporter une mise à jour de sécurité coûte en général plus cher, en disponibilité et en image, que l’opération elle-même.
- Pourquoi mettre à jour PrestaShop : sécurité, performance et conformité légale
- Comment vérifier et choisir votre version : identifier les versions disponibles et les chemins de migration
- Les étapes essentielles avant toute mise à jour : sauvegarde, audit de compatibilité et environnement de test
- Mettre à jour en minimisant les risques : mode maintenance, outils automatisés et gestion des modules
- Problèmes courants après mise à jour et coût réel de l’inaction
- Foire aux questions
Pourquoi mettre à jour PrestaShop : sécurité, performance et conformité légale
Une boutique qui tourne sur une version ancienne de PrestaShop accumule trois types de dette : sécurité, performance, conformité. Les trois se paient un jour ou l’autre, souvent au moment le moins opportun.
Quelles failles de sécurité corrige une mise à jour PrestaShop ?
Chaque nouvelle version corrige des failles de sécurité identifiées dans le code du core ou dans des bibliothèques tierces. Ne pas mettre à jour ne fait pas disparaître ces failles : cela laisse simplement la porte ouverte plus longtemps.
- Injections SQL dans des formulaires ou modules mal filtrés
- Failles XSS permettant d’injecter du code dans les pages publiques
- Contournements d’authentification sur le back-office
- Vulnérabilités dans des bibliothèques PHP tierces embarquées dans le core
Hummingbird 2.0 et les gains de performance
Hummingbird 2.0, le moteur de cache introduit avec les versions récentes de PrestaShop, change concrètement la vitesse perçue par le client, en particulier sur les fiches produit et le catalogue. Combiné à PHP 8.5, il réduit sensiblement les temps de réponse du back-office.
- Temps de chargement des pages catalogue et fiches produit
- Fluidité du back-office pour la gestion des commandes
- Réactivité de l’API Admin pour les intégrations tierces
- Comportement du panier et du tunnel d’achat sous forte charge
Conformité légale et obligations RGPD
Une boutique en ligne a des obligations légales qui évoluent avec les versions du CMS : gestion du consentement, droit de rétractation, mentions obligatoires. Certaines fonctions ne sont plus maintenues sur les branches anciennes, ce qui complique leur mise en conformité. Le module droit de rétractation en ligne par exemple s’installe plus simplement sur une base à jour que sur une version en fin de vie.
Comment vérifier et choisir votre version : identifier les versions disponibles et les chemins de migration
Avant de lancer quoi que ce soit, il faut savoir où vous êtes et où vous pouvez aller. Toutes les versions de PrestaShop ne communiquent pas directement entre elles.
PrestaShop 9.1, Symfony 6.4 LTS et PHP 8.5 : ce qui change
PrestaShop 9.1 repose sur Symfony 6.4 LTS, une version à support long qui structure désormais une grande partie du back-office, alors que l’ancien code Smarty legacy recule d’une version à l’autre. PHP 8.5 est requis, ce qui exclut de fait certains serveurs mutualisés anciens.
- Migration progressive du back-office vers Symfony
- Dépréciation de hooks legacy utilisés par d’anciens modules
- API Admin étendue pour les intégrations et automatisations
- Exigence stricte de PHP 8.5 côté serveur
Quel chemin de migration suivre selon votre version actuelle ?
Sauter plusieurs versions majeures d’un coup multiplie les incompatibilités. Un chemin de migration progressif limite les mauvaises surprises.
| Version de départ | PHP requis | Chemin recommandé |
|---|---|---|
| 1.6 | 5.6 à 7.1 | Passer par 1.7 avant d’envisager 8 ou 9 |
| 1.7 | 7.1 à 8.1 | Vers 8, puis 9 si le thème et les modules suivent |
| 8 | 7.4 à 8.1 | Vers 9.1 après audit de compatibilité |
- Vérifier la version PHP minimale exigée par la cible
- Ne jamais sauter directement de 1.6 vers 9
- Contrôler la disponibilité d’une version compatible de chaque module
Les étapes essentielles avant toute mise à jour : sauvegarde, audit de compatibilité et environnement de test
La majorité des incidents que nous voyons en production viennent d’une étape sautée avant la mise à jour elle-même, pas de la mise à jour en tant que telle.
Sauvegarde complète : base de données et fichiers
Une sauvegarde qui ne couvre que la base de données ne sert à rien si le thème ou les fichiers modules sont corrompus pendant l’opération.
- Export complet de la base de données avant toute manipulation
- Copie intégrale de l’arborescence des fichiers, y compris /modules et /themes
- Vérification que la sauvegarde est restaurable, pas seulement présente
- Stockage de la sauvegarde hors du serveur de production
Comment auditer la compatibilité de vos modules et de votre thème ?
- Lister tous les modules actifs et leur version actuelle
- Consulter le changelog de chaque module pour la version cible
- Identifier les hooks dépréciés utilisés par le thème
- Contacter l’éditeur du module en cas de doute sur la compatibilité
Pourquoi tester en pré-production avant la mise en production ?
Un environnement de test qui reproduit fidèlement la production (même version PHP, même base de données, mêmes modules) est le seul moyen de valider une mise à jour sans exposer les clients.
- Détecter les erreurs 500 avant qu’un client ne les voie
- Vérifier le tunnel d’achat de bout en bout, du panier au paiement
- Mesurer l’impact réel sur les temps de chargement
- Corriger les incompatibilités de thème sans pression de délai
Mettre à jour en minimisant les risques : mode maintenance, outils automatisés et gestion des modules
Une fois la préparation faite, l’exécution elle-même se joue sur trois leviers.
Le mode maintenance, une étape non négociable
Activer le mode maintenance avant de lancer la mise à jour évite qu’un client passe commande sur un site à moitié migré.
- Activation du mode maintenance avant le premier script de migration
- Blocage des commandes et des paiements pendant l’opération
- Accès restreint aux seules adresses IP autorisées pour les tests
- Désactivation uniquement après validation complète
1-Click Upgrade : ce qu’il fait vraiment
Le module 1-Click Upgrade automatise le téléchargement et l’installation du core, mais il ne gère ni la compatibilité de vos modules tiers ni les surcharges de thème.
- Ce qu’il fait : mise à jour automatisée des fichiers du core
- Ce qu’il ne fait pas : vérifier la compatibilité de vos modules
- Ce qu’il ne fait pas : migrer les surcharges de thème personnalisées
- Ce qu’il faut en plus : une sauvegarde préalable et un test en pré-production
Gérer les modules incompatibles avant, pendant et après
Un module incompatible désactivé à tort peut casser une fonctionnalité vendue sur la fiche produit, ou pire, sur le tunnel de paiement. Certains modules édités spécifiquement pour PrestaShop, comme ceux de notre catalogue de modules PrestaShop, sont maintenus en parallèle des versions du core, ce qui simplifie leur mise à jour.
- Désactiver temporairement les modules non essentiels avant la migration
- Mettre à jour les modules critiques (paiement, livraison) en priorité
- Réactiver progressivement chaque module en vérifiant son comportement
- Prévoir un remplacement si l’éditeur a abandonné le module
Pour les interventions urgentes ou les migrations complexes, une intervention et dépannage PrestaShop ponctuelle permet d’éviter une indisponibilité prolongée, et une infogérance e-commerce au long cours prend en charge cette veille en continu.
Problèmes courants après mise à jour et coût réel de l’inaction
Incompatibilités, lenteurs et bugs : les scénarios les plus fréquents
- Erreurs 500 liées à un module non compatible avec la nouvelle version de PHP
- Ralentissement du back-office après activation du cache Hummingbird mal configuré
- Perte d’affichage de blocs de thème utilisant des hooks supprimés
- Comportement erratique du tunnel d’achat sur certains moyens de paiement
Que perdez-vous en restant sur une version obsolète ?
Le coût de l’inaction ne se voit pas tout de suite, ce qui le rend d’autant plus trompeur.
- Exposition prolongée à des failles de sécurité connues et documentées publiquement
- Risque accru sur la sécurité des données clients en cas d’intrusion
- Indisponibilité imprévue du tunnel d’achat lors d’un pic de trafic
- Impact commercial direct : commandes perdues, image dégradée, référencement pénalisé
Certains contrats de maintenance PrestaShop intègrent justement cette veille et cette anticipation, plutôt que de subir la migration dans l’urgence. Un hébergement PrestaShop professionnel infogéré avec veille proactive sur les failles réduit ce risque en amont, avant même qu’une mise à jour majeure ne soit nécessaire.
Mettre à jour PrestaShop n’est jamais une opération anodine, mais ce n’est pas non plus une fatalité si elle est préparée : sauvegarde, audit de compatibilité, test en pré-production et mode maintenance couvrent l’essentiel des risques. Une prestashop mise à jour bien menée protège la sécurité des données, la performance du site et le tunnel d’achat, ce qui pèse directement sur le chiffre d’affaires. Si le sujet vous semble trop technique ou trop risqué à gérer seul, faire auditer votre boutique PrestaShop par une équipe qui connaît le code à toutes les versions reste l’option la plus sûre.
Foire aux questions
Combien de temps prend une mise à jour PrestaShop et quels sont les risques d’indisponibilité du site ?
Sur une boutique standard avec peu de modules, la mise à jour technique dure de quelques minutes à une heure. Le vrai temps se trouve dans la préparation : audit de compatibilité, sauvegarde et test en pré-production, qui peuvent représenter plusieurs heures ou jours selon la complexité. Le risque d’indisponibilité existe surtout si le mode maintenance n’est pas activé ou si un module casse le tunnel d’achat sans avoir été testé avant.
Comment savoir si mes modules et mon thème sont compatibles avant de mettre à jour ?
Il faut vérifier le changelog de chaque module pour la version cible et repérer les hooks dépréciés utilisés par le thème. En l’absence d’information claire de l’éditeur, un test en environnement de pré-production reste le seul moyen fiable de vérifier le comportement réel.
Faut-il obligatoirement passer en mode maintenance pour mettre à jour PrestaShop ?
Ce n’est pas techniquement obligatoire dans tous les cas, mais c’est fortement recommandé dès que la boutique reçoit du trafic ou des commandes. Sans mode maintenance, un client peut valider une commande pendant que le core est en cours de modification, ce qui génère des erreurs difficiles à rattraper.
Que faire si une mise à jour casse mon site ou mes modules ?
La première action est de restaurer la sauvegarde effectuée avant la migration, puis d’identifier précisément le module ou le hook en cause avant de retenter l’opération. Si aucune sauvegarde fiable n’existe, une intervention en urgence peut limiter les dégâts, mais le diagnostic prend nécessairement plus de temps.
Quel est le coût, en temps et en argent, de faire appel à une agence pour mettre à jour PrestaShop ?
Une intervention ponctuelle se facture en général au temps passé, à un tarif horaire de 75 euros HT de l’heure, appliqué en semaine et en heures de bureau. Pour une boutique dont le chiffre d’affaires dépend du site, ce coût reste généralement inférieur à celui d’une indisponibilité non maîtrisée ou d’une donnée client compromise.
