Migrer PrestaShop 1.7 vers 8 : ce qu'on apprend après 30 migrations

PrestaShop 8 est sorti fin 2022. En 2026, la plupart des boutiques ont migré, mais beaucoup gardent encore une 1.7.x en production. Voici ce qu'il faut savoir avant de se lancer — et les erreurs qu'on voit revenir le plus souvent.

Le pré-requis qui casse tout : PHP 8.1

PrestaShop 8 exige PHP 8.1 minimum. C'est généralement à ce niveau qu'on découvre que la moitié des modules tiers n'est pas compatible. Avant même de toucher au cœur, on lance un script qui scanne /modules/ et tente une compilation OPcache de chaque fichier PHP. Ça révèle les fatales avant qu'elles n'arrivent en production.

Les modules les plus problématiques en pratique :

• Modules de paiement développés en interne il y a 5+ ans (souvent en PHP 5.6-style)
• Modules d'export comptable (Sage, EBP) basés sur des SDK obsolètes
• Vieux thèmes "Smart" ou "Warehouse" avec des Smarty hooks tordus

La trappe Composer

PrestaShop 8 est passé à un modèle où composer install doit tourner sur le serveur. Si votre hébergeur ne le permet pas (ou si vous êtes sur un mutualisé Cloud), il faut absolument faire un composer install --no-dev --optimize-autoloader en local et uploader le dossier /vendor entier. C'est lourd mais incontournable.

L'erreur classique : oublier composer dump-autoload --classmap-authoritative avant de packager. Résultat : 30 % de perte de perf en prod sur les pages produit.

Les controllers FrontController custom

Beaucoup d'agences ont créé des controllers custom dans /override/controllers/front/. En 1.7, ça passait. En 8, le mécanisme d'override est plus strict, et la plupart de ces fichiers cassent silencieusement (la classe n'est plus chargée, on retombe sur le controller core).

Le test rapide : avec cache/class_index.php en mode dev, vérifier que vos overrides sont bien listés. Si ce n'est pas le cas, il faut migrer vers un module avec installModule + override dynamique, ou refactorer le controller en module standalone.

La base de données : pas de surprise majeure mais quelques pièges

Le schéma DB de PS8 reste très proche de la 1.7. Les vraies migrations DB sont celles vers PS9 (mais c'est un autre billet). Cela dit, deux pièges :

• Les colonnes active en SMALLINT qui passent en TINYINT — pas de souci sauf si vous avez du code custom qui INSERT des valeurs > 1.
• Les indexes sur id_lang qui sont reconstruits — sur une grosse boutique (>500k produits multilangues), ça prend 20-40 minutes. Prévoir une fenêtre de maintenance.

Le mode "maintenance" qui ne suffit pas

Activer le mode maintenance via le BO ne suffit pas pour une migration sereine. On utilise systématiquement un fichier .htaccess qui bloque tout sauf nos IPs pendant la phase de bascule. Sinon, dès qu'un bot crawle pendant les 5-10 minutes critiques, vous récoltez 200 erreurs 500 dans Search Console.

Le checklist final qu'on applique

1. Backup complet (DB + fichiers + config Apache/Nginx)
2. Clone de la prod sur staging avec données réelles
3. Migration sur staging avec script automatisé
4. Tests : checkout, recherche produit, BO, paiement (en mode test)
5. Validation par le marchand sur staging pendant 48h minimum
6. Bascule en prod en heure creuse, fenêtre 30 min max
7. Surveillance des logs error + Sentry pendant 72h

Combien ça coûte vraiment ?

Sur une boutique « standard » (10-30 modules, thème custom léger, ~50k produits), il faut compter 3 à 5 jours-homme. Pour une boutique complexe (multistore, ERP synchronisé, modules custom métier), ça peut monter à 15-25 jours-homme. Le poste qui dérape le plus souvent : la mise à jour des modules tiers payants (l'éditeur exige une nouvelle licence pour PS8, négociation à prévoir).

Si vous êtes encore en 1.7 et que vous hésitez, contactez-nous : on fait un audit gratuit sur 1h pour estimer la difficulté de votre cas spécifique.