# PrestaShop 1.7 vers 8 : PHP 8 et back-office en TypeScript

> Le passage le plus courant aujourd’hui : compatibilité PHP 8, JavaScript du back-office migré en TypeScript, modules à revérifier un par un avant de lancer quoi que ce soit.

- Source canonique : [https://allaux.fr/prestashop/migration/1-7-vers-8](https://allaux.fr/prestashop/migration/1-7-vers-8)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Traitez-le comme deux chantiers distincts : la montée en 8, puis le passage à PHP 8. Avant de lancer, ouvrez le config.xml de chaque module pour lire sa borne haute de compatibilité, ainsi que la propriété $ps_versions_compliancy de sa classe principale : un module figé sur 1.7 reste grisé après la mise à jour. Revoyez aussi vos scripts d’administration sur mesure, le JavaScript du back-office étant passé en TypeScript.

## Ce qui change concrètement entre 1.7 et 8

Techniquement, le saut de 1.7 à 8 est moins radical que celui de 1.6 à 1.7 : l’architecture hybride Smarty/Symfony et le thème Classic restent en place. Ce qui change vraiment, c’est la compatibilité PHP : PrestaShop 8 demande PHP 7.2.5 au minimum, prend en charge PHP 8.0 et 8.1 dès sa sortie, puis PHP 8.2 depuis la version 8.2 (septembre 2024). Aucune version 1.7.x ne fonctionne sous PHP 8, Smarty plante immédiatement : migrer vers 8 implique donc presque toujours de monter la version PHP en même temps que PrestaShop, ce qui multiplie les points de rupture.

Côté back-office, changement plus discret mais réel : le JavaScript d’administration migre vers TypeScript dès la 8.0, et les surcharges ou scripts personnalisés développés sous 1.7 ne se branchent plus de la même façon. De nombreuses méthodes du cœur déclarent aussi un type de retour, conséquence de PHP 8.1 : un override qui ne respecte pas cette signature déclenche une erreur fatale, pas un avertissement.

La base de données change aussi de structure à chaque version majeure : nouvelles tables, colonnes renommées. Restaurer un dump SQL tel quel sur une 8 fraîche n’est pas fiable ; c’est autoupgrade qui exécute les scripts de mise à jour adaptés.

## Modules et fonctions qui posent problème

- Le back-office affiche une erreur fatale au premier accès après le passage en PHP 8.1, faute de type de retour sur une méthode surchargée.
- Un module installé en 1.7 est introuvable ou grisé après la mise à jour, faute de compatibilité déclarée avec la version 8 dans config.xml.
- Un module personnalisé utilise encore la syntaxe accolades pour accéder à un tableau ou une chaîne ($array{0}), supprimée par PHP 8 : la page plante avec une erreur de syntaxe.
- Un script ou une surcharge back-office sur mesure ne s’exécute plus, à cause du passage du JavaScript d’administration au TypeScript.
- La propriété $ps_versions_compliancy d’un module, figée sur l’ancienne version, empêche son activation même si le code fonctionnerait sans modification.

## Comment je mène cette migration

1. **Audit PHP et modules** — Je vérifie la version PHP actuelle et cible, et je liste les modules installés avec leur compatibilité déclarée dans config.xml et $ps_versions_compliancy.
2. **Sauvegarde complète indépendante** — Dump de la base et copie complète des fichiers avant toute intervention, en plus de la sauvegarde interne d’autoupgrade.
3. **Migration sur copie de la boutique** — Autoupgrade tourne d’abord sur un environnement de test : sauvegarde des fichiers et de la base, puis exécution des scripts de mise à jour de schéma.
4. **Le point de non-retour : la mise à jour de la base** — Une fois que les scripts de mise à jour de la base s’exécutent, revenir en arrière ne consiste plus à annuler des fichiers : seule la restauration du dump pris avant l’opération permet un retour propre. Je ne lance cette étape qu’après avoir validé fichiers et modules.
5. **Correction des modules et surcharges** — Je mets à jour ou remplace les modules bloqués par une compatibilité obsolète ou la syntaxe accolades supprimée en PHP 8, et j’adapte les surcharges back-office touchées par le TypeScript.
6. **Bascule en production** — Une fois la version de test validée, je programme la bascule à faible trafic, PHP compris, pour limiter l’impact sur les commandes en cours.

## Ce que je sauvegarde avant de lancer quoi que ce soit

> Un dump SQL complet de la base (pas seulement l’auto-sauvegarde d’autoupgrade, dans /autoupgrade/backup), une copie intégrale des fichiers, et la liste des modules actifs avec versions. Sauvegardes conservées hors du serveur modifié.

## Comment je vérifie après la migration

Après la bascule, je compare commandes, clients et produits entre ancienne et nouvelle base pour vérifier qu’aucune ligne n’a été perdue. Je teste le tunnel de commande complet sur chaque moyen de paiement actif, les pages clés du front (accueil, catégorie, fiche produit) et l’accès au back-office. Je consulte aussi le journal d’erreurs PHP dans les premières heures : c’est souvent là qu’apparaissent les surcharges auxquelles il manque un type de retour.

## Pages liées

- **Checklist avant une migration** — Ce qu’il faut vérifier et sauvegarder avant une migration, quelle que soit la version de départ. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration))
- **Modules incompatibles après migration** — Pourquoi un module qui fonctionnait plante ou disparaît après une mise à jour, et comment vérifier sa compatibilité. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles))
- **Passer PrestaShop à PHP 8** — Ce qu’implique le changement de version PHP côté hébergement, indépendamment de la version de PrestaShop. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))
- **Migration PrestaShop 8 vers 9** — L’étape suivante logique une fois la boutique stabilisée sur la version 8. ([/prestashop/migration/8-vers-9](/prestashop/migration/8-vers-9))

## FAQ

### Dois-je être sur la dernière sous-version 1.7.8 avant de passer à la 8 ?

Pas une obligation stricte, mais la configuration la plus testée pour autoupgrade : je vérifie l’état de votre 1.7 avant la mise à jour, et je monte la boutique jusqu’à la dernière sous-version 1.7 si nécessaire.

### Le TypeScript du nouveau back-office va-t-il casser mes personnalisations d’administration ?

Seulement si vous avez des scripts ou surcharges JavaScript spécifiques dans le back-office. Le fonctionnement standard de l’administration n’est pas affecté ; c’est le code personnalisé qui doit être adapté.

### Combien de temps dure une migration de 1.7 vers 8 ?

Ça dépend surtout du nombre de modules et de surcharges personnalisées. Une boutique avec peu de modules et un thème standard se migre en quelques jours ; une personnalisation poussée prend plus de temps.

### Mon hébergement doit-il changer avant la migration ?

En général oui. Je vérifie la version PHP proposée par l’hébergeur au regard de PrestaShop 8 ; si elle manque, je signale ce changement avant la mise à jour de PrestaShop.