Nous migrons votre boutique depuis PrestaShop 1.4, 1.6 ou 1.7 vers PrestaShop 9.x, la version recommandée aujourd'hui — ou vers 8.x si votre serveur n'atteint pas PHP 8.2. Tout est construit et testé sur staging pendant que votre boutique continue de vendre.
Le parcours, le délai et le risque changent complètement selon votre point de départ. Choisissez votre version : vous verrez où en est votre boutique aujourd'hui — et vers quelle version il est logique de l'emmener.
Trois choses commencent dès que votre version cesse de recevoir du support. Aucune ne se voit le premier jour.
PHP 7.4 ne reçoit plus de correctifs de sécurité depuis novembre 2022, et les branches 1.6 et 1.7 de PrestaShop ne reçoivent plus de corrections. Chaque vulnérabilité publiée depuis reste ouverte sur votre boutique, avec les données clients et les paiements à l'intérieur.
Les anciennes versions ne profitent ni de PHP 8, ni du WebP, ni du cache moderne du cœur. La boutique charge plus lentement chaque année, et la lenteur se paie directement dans le panier.
Passerelles de paiement, transporteurs et connecteurs abandonnent progressivement les anciennes versions. Arrive le moment où votre prestataire de paiement exige une version minimale que vous ne pouvez plus atteindre sans migration complète. Là, ça presse vraiment.
Parfois si. Nous vous disons exactement quand le module 1-Click Upgrade — ou un module de migration payant — fait le travail, et quand il vous laissera la boutique à moitié migrée un mardi après-midi.
| Ce qu'il faut régler | 1-Click Upgrade / modules de migration | PrestaChampsMigration clé en main |
|---|---|---|
| Mise à jour mineure (8.1.5 → 8.1.7) | Oui, et c'est ce que nous recommandons | Inutile de nous appeler pour ça |
| Changement de version majeure (1.6 ou 1.7 → 9.x) | Toute l'architecture change | Parcours par étapes, testé de bout en bout |
| Sauvegarde complète et vérifiée | Backup automatique, non vérifié | Fichiers + base de données, restauration testée |
| Environnement de staging avant la production | Agit sur la boutique en ligne | Clone complet ; votre boutique continue de vendre |
| Modules tiers et modules de paiement | Non adaptés | Audités un par un, adaptés ou remplacés |
| Thème sur mesure | Casse sur un saut majeur | Adapté à la nouvelle version, ou reconstruit |
| Passage de PHP 7.x à PHP 8.2+ | Hors de leur périmètre | Incluse, avec le serveur vérifié |
| URLs, SEO et redirections | Dépend de la configuration | Structure préservée et 301 préparées |
| Si ça échoue en cours de route | Boutique à l'arrêt, et cherchez le backup | Rollback prêt ; la production n'est touchée qu'à la fin |
| Après le déploiement | Débrouillez-vous | Support post-migration et monitoring inclus |
Notre recommandation sincère : si vous êtes en 8.x et que vous voulez simplement monter de correctif, utilisez le module et gardez votre budget. Appelez-nous quand le saut est une version majeure, quand vous avez des modules de paiement critiques, ou quand la boutique ne peut pas se permettre d'être à l'arrêt une seule heure.
Voici les migrations que nous réalisons au quotidien. Les délais sont réels, issus de projets livrés, pas des estimations de plaquette.
Le point de départ le plus fréquent. Comme le thème, les modules et la version de PHP doivent être repris de toute façon, autant faire l'effort une seule fois et arriver directement en 9.x.
Entre 1.6 et 1.7, toute l'architecture change : Symfony entre dans le back-office et le système de thèmes est réécrit. C'est une migration par étapes, pas une mise à jour.
Le saut le plus court du catalogue, et celui qu'on nous demande le plus en ce moment. Même lignée, sans reconstruction des données : ce qu'il faut vérifier, c'est le serveur et les modules.
Plus de dix ans d'écart. Ici on ne met pas à jour : on reconstruit la boutique et on migre les données. Et s'il faut reconstruire de toute façon, autant reconstruire sur 9.x.
Si en plus de la mise à jour vous devez déplacer la boutique, le meilleur moment est le même. Une seule fenêtre de déploiement au lieu de deux.
C'est la situation la plus courante, surtout si la boutique a été montée par une autre agence il y a des années. Vous n'avez pas à le chercher vous-même.
Aujourd'hui nous recommandons 9.x par défaut. La branche a suffisamment tourné en production pour ne plus être un pari, et l'effort de migration est pratiquement le même. 8.x reste une sortie valable — mais pour de moins en moins de cas.
Quand nous avons commencé à la proposer, c'était l'option pour ceux qui voulaient prendre de l'avance. Ce n'est plus le cas : elle a plusieurs versions de rodage, l'écosystème de modules l'a rattrapée, et c'est là que se trouvera le support des prochaines années.
Pour vous si votre hébergement atteint PHP 8.2+ — ce qui est le cas la plupart du temps. Nous le vérifions pendant l'audit avant de nous engager sur quoi que ce soit.
Branche mature et parfaitement solide. Nous la réservons aujourd'hui aux cas où 9.x n'est pas encore envisageable, et non comme destination par défaut.
Pour vous si votre hébergement n'atteint pas PHP 8.2, si un module critique n'a pas encore de version 9, ou si vous préférez attendre un cycle de plus. Nous vous le dirons clairement pendant l'audit.
Rien n'est touché en production tant que tout n'est pas testé. C'est pour cette raison que nous pouvons garantir zéro coupure.
Nous examinons version, PHP, serveur, thème et l'inventaire complet des modules. Nous en sortons avec un parcours concret, un délai et un devis ferme — pas une fourchette.
Sauvegarde complète des fichiers et de la base de données, avec la restauration réellement testée. Sur cette copie nous montons un clone exact de votre boutique où tout le travail sera fait.
La migration du cœur est exécutée sur staging et chaque module est classé : compatible, licence à renouveler, code à adapter, ou sans continuité. Le thème est adapté à la nouvelle version.
Nous parcourons tout le tunnel d'achat : catalogue, moteur de recherche, panier, codes promo, transporteurs, passerelles de paiement, factures, e-mails transactionnels et back-office. Avec de vraies données, pas des données de démo.
Le passage en production se fait sur le créneau de plus faible trafic et dure quelques minutes, avec le rollback prêt au cas où. Vos clients ne voient pas de page de maintenance.
Nous surveillons erreurs, performances et commandes les jours suivant le déploiement. Si un détail apparaît, nous le corrigeons. Vous n'êtes pas seul le lendemain.
Dix engagements concrets qui font partie de tout projet de mise à jour, sans extras ni petites lignes.
PrestaChamps est une équipe de 16 spécialistes dédiée à PrestaShop depuis 2014, avec des bureaux à Târgu-Mureș (Roumanie) et à Londres. Nous ne faisons pas de WordPress, ni de Shopify, ni « aussi des sites vitrines ». Uniquement PrestaShop, et depuis plus de dix ans.
La mise à jour a été impeccable : zéro incident, tout testé dans le détail avant le passage en production. Nous n'avons pas perdu une seule commande pendant le changement.
Nous venions d'un 1.6 très bricolé et le saut nous faisait peur. Ils ont migré vers 8.x en conservant absolument tout l'historique des commandes et des clients. Ce qui a été promis est ce qui s'est passé.
Le meilleur, c'était la transparence : le portail de projet nous permettait de suivre l'avancement en temps réel, sans avoir à demander. Sur un projet pareil, ça change tout.
Dites-nous où en est votre boutique aujourd'hui. Nous vous renvoyons un diagnostic réel, le parcours de mise à jour recommandé et un devis ferme — sous 24 heures et sans engagement.
Réponse garantie sous 24 heures ouvrées.
