Lecture : 9 min · Yoan Gwizdala

Migrer PrestaShop 1.7 vers 8 : la méthode complète

Votre boutique tourne sur une 1.7.8. Depuis la sortie de PrestaShop 9 en juin 2025, cette branche n'est plus maintenue du tout : plus de correctifs, pas même de sécurité. La bonne nouvelle, c'est que le passage en 8 est une mise à jour, pas une reconstruction.

La mauvaise, c'est que « mise à jour » ne veut pas dire « bouton vert ». Ce qui casse pendant une migration PrestaShop, ce n'est presque jamais PrestaShop : c'est ce que vous avez ajouté autour depuis huit ans.

1.7 vers 8 : une mise à jour, pas une migration

PrestaShop 8.0 est sorti le 26 octobre 2022, et c'est la suite directe de la 1.7.8. Le changement de numéro marque la fin de la nomenclature « 1.x », pas une refonte de l'outil : le système de thème ne change pas, l'architecture non plus, et la grande majorité des modules prévus pour 1.7.8 continuent de fonctionner.

C'est exactement l'inverse du saut 1.6 vers 1.7, qui a changé le système de thème et rendu inutilisables les thèmes et les modules de l'ancienne génération. Si vous partez d'une 1.6, ce n'est pas cet article qu'il vous faut, mais celui-ci : le chantier n'a rien à voir.

Où en sont les versions, aujourd'hui

Une 1.7.8 en 2026 n'est donc pas « un peu en retard » : c'est une version dont plus personne ne corrigera la prochaine faille publiée. Et comme une faille corrigée en 8 et en 9 est aussi une faille documentée, l'écart ne joue pas en votre faveur.

8 ou 9 : faut-il viser la dernière ?

La question mérite trente secondes de calcul, parce que la réponse tient à une date qui n'est pas celle de PrestaShop.

• PrestaShop 8 s'arrête à PHP 8.2. Or le support de sécurité de PHP 8.2 se termine le 31 décembre 2026. Migrer en 8 aujourd'hui, c'est donc se replacer, dans quelques mois, sur un PHP qui ne recevra plus de correctifs.
• PrestaShop 9 demande PHP 8.1 minimum et accepte jusqu'à 8.4. C'est la seule branche qui vous laisse une marge de plusieurs années côté serveur.
• La 8.2 reste un palier valable si un module indispensable n'est pas encore compatible 9 et que son éditeur a annoncé une date. Elle reçoit encore des correctifs de sécurité, publiés en même temps que ceux de la 9.

L'outil officiel, et ce qu'il ne fait pas

PrestaShop fournit un module de mise à jour, aujourd'hui appelé Update Assistant — c'est l'ancien « 1-Click Upgrade », dont le dépôt s'appelle toujours autoupgrade. Il s'utilise depuis le back-office ou en ligne de commande, ce qui change beaucoup de choses sur une grosse boutique : pas de coupure de session, pas de délai d'exécution PHP dépassé au milieu du transfert.

Ce module fait très bien une chose : remplacer le cœur de PrestaShop et jouer les migrations de base de données. Voilà ce qu'il ne fait pas, et que personne ne fera à votre place :

• Il ne répare pas un module incompatible. Il le désactive, au mieux.
• Il ne relit pas vos override/, ni les fichiers du cœur qu'un ancien prestataire a modifiés à la main.
• Il ne teste pas votre tunnel de commande. Une boutique peut afficher une page d'accueil parfaite et refuser tous les paiements.
• Il ne sait pas que votre flux Google Shopping, votre logiciel de caisse ou votre ERP tapent sur le webservice.

L'ordre des opérations

C'est un ordre, pas une liste de courses. Sauter une étape ne fait pas gagner du temps : ça déplace le problème vers le jour de la bascule, quand la boutique est en ligne et que le téléphone sonne.

1. Une copie complète, ailleurs. Fichiers et base, sur une préproduction. La boutique en ligne n'est jamais le terrain d'essai : c'est la règle qui rend toutes les suivantes possibles.
2. L'inventaire. Version exacte au patch près, modules réellement actifs, overrides, thème, branchements extérieurs. C'est le travail décrit dans l'audit, et c'est lui qui donne le devis.
3. Le PHP d'abord. On place la préproduction sur la version de PHP cible avant de toucher à PrestaShop, pour séparer les erreurs : ce qui casse à cause de PHP, et ce qui casse à cause de la version.
4. La mise à jour, sur la copie, avec l'Update Assistant, en ligne de commande si la boutique est volumineuse.
5. La reprise de ce qui a lâché : mise à jour des modules, remplacement des abandonnés, réécriture du sur-mesure, reprise du thème s'il y a lieu.
6. La recette, et c'est l'étape qu'on saute quand on est pressé. Une commande réelle de bout en bout, depuis un téléphone : ajout au panier, création de compte, adresse, transporteur, paiement, mail de confirmation, facture PDF, changement d'état de la commande, remboursement partiel, retour en stock.
7. Les redirections et le référencement, préparés avant la bascule et pas après. Le détail est ici.
8. La bascule, sur une fenêtre calme, boutique en mode maintenance, avec une resynchronisation de la base au dernier moment.
9. 72 heures de surveillance : journaux d'erreurs, taux d'abandon au paiement, mails transactionnels réellement partis, retours des clients.

Le piège numéro un : la boutique continue à vendre

Une migration dure des jours ou des semaines. Pendant ce temps, votre boutique encaisse des commandes, crée des clients, décrémente des stocks. Si la base que vous mettez en ligne le jour J est celle que vous avez copiée trois semaines plus tôt, vous venez d'effacer trois semaines de commandes.

C'est pour ça qu'une migration ne se termine pas par un copier-coller, mais par une resynchronisation : on rejoue la migration de la base sur un dump frais, pris juste avant la bascule, pendant que la boutique est en maintenance. Le travail préparé sur la préproduction sert à rendre cette dernière étape rapide et répétable — pas à être copié tel quel.

Le retour en arrière se prépare avant

Un plan de retour arrière écrit après la panne n'est pas un plan, c'est une improvisation. Avant la bascule : une sauvegarde des fichiers et de la base sortie du serveur, la procédure de restauration testée une fois, le TTL du DNS abaissé si le domaine bouge, et une décision prise à l'avance — au bout de combien de temps on renonce et on remet l'ancienne boutique.

Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde. C'est un fichier.

Combien de temps ça prend, honnêtement

Sur une 1.7.8 propre, à jour de ses patchs, avec un thème enfant du Classic et une quinzaine de modules d'éditeurs connus : un à deux jours de travail, étalés sur une semaine pour laisser la recette respirer. Sur une boutique de dix ans, avec quarante modules, un thème acheté sur une place de marché et un dossier override/ bien rempli : comptez en semaines.

Je ne donne pas de délai avant d'avoir ouvert le back-office et regardé le serveur. Un délai annoncé sans avoir vu la boutique n'engage que celui qui le croit.

Faire regarder ma boutique PrestaShop

Questions fréquentes

Peut-on passer directement de PrestaShop 1.7 à 9 ?

Oui, c'est même souvent le bon choix. Le point de blocage n'est pas PrestaShop mais vos modules : PrestaShop 9 repose sur Symfony 6.4, demande PHP 8.1 au minimum et a retiré une trentaine de hooks, dont tous ceux de l'ancienne page produit. Si vos modules suivent, on va directement en 9. Sinon, la 8.2 sert de palier — en sachant qu'elle s'arrête à PHP 8.2, dont le support de sécurité se termine fin 2026.

Mes modules 1.7.8 vont-ils fonctionner en PrestaShop 8 ?

Pour la plupart, oui : PrestaShop 8 est la continuité de la 1.7.8, il n'y a pas de rupture du système de modules. Les problèmes viennent plutôt de PHP : un module écrit pour PHP 7.4 peut mal se comporter en PHP 8.1. Les modules abandonnés par leur éditeur sont l'autre cas à traiter, et ils se remplacent plutôt qu'ils ne se réparent.

Faut-il refaire le thème en passant de 1.7 à 8 ?

Non. Le système de thème n'a pas changé entre 1.7.8 et 8, votre thème est conservé. Des ajustements ponctuels sont possibles sur des templates surchargés, mais ce n'est pas un chantier. C'est le passage de 1.6 à 1.7 qui imposait de refaire le thème, pas celui-ci. Le passage en 9, lui, demande de reprendre certains templates, les données de plusieurs pages étant désormais préparées différemment.

Combien de temps la boutique est-elle indisponible ?

Quelques dizaines de minutes, si le travail a été fait sur une copie. La bascule consiste à mettre la boutique en maintenance, reprendre un dump frais de la base, rejouer la migration déjà répétée, basculer, vérifier. Tout le reste — les modules, le thème, la recette — a été fait avant, hors ligne. Une migration menée directement sur la boutique en production, elle, peut la laisser cassée plusieurs jours.

Que se passe-t-il si la mise à jour échoue ?

Sur une préproduction : rien, on recommence. C'est tout l'intérêt. Sur la boutique en ligne, on restaure la sauvegarde — à condition qu'elle existe, qu'elle soit stockée ailleurs que sur le serveur, et qu'on ait déjà testé la restauration au moins une fois. Un plan de retour arrière se prépare avant la bascule, pas pendant la panne.

Faut-il migrer maintenant ou attendre PrestaShop 10 ?

Attendre coûte plus cher que migrer. Chaque version sautée allonge le chemin et augmente le nombre de modules devenus incompatibles entre-temps. Une boutique tenue à jour se met à jour en une journée ; une boutique qui a sauté deux versions majeures se migre en semaines. La date qui compte pour vous n'est pas celle de PrestaShop 10, c'est celle où votre hébergeur retirera la version de PHP que votre boutique exige.