# PrestaShop 8.0 vers 8.2 : la 8.1 fait passer Vue 2 à Vue 3

> Passer de PrestaShop 8.0 à 8.2 ressemble à une mise à jour mineure : même branche majeure, même thème, même structure de base. C’est trompeur. Entre les deux se trouve la 8.1, qui fait passer le back-office de Vue.js 2.6 à 3.2 — et c’est précisément ce qui casse les personnalisations JavaScript de l’administration.

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

## Réponse directe

> Le point de bascule est la 8.1, qui fait passer le back-office de Vue.js 2.6 à 3.2 : listez d’abord les modules et développements qui ajoutent un écran ou un composant à l’administration, ce sont les seuls réellement menacés. Entre 8.0 et 8.2, le front-office, le thème Classic et la structure des tables ne bougent pas.

## Ce qui change réellement entre 8.0 et 8.2

PrestaShop 8.0 exige au minimum PHP 7.2.5 et ajoute la prise en charge de PHP 8.0 et 8.1. Le JavaScript des pages déjà migrées y est écrit en TypeScript, et de nombreuses méthodes déclarent un type de retour, du fait de la compatibilité PHP 8.1.

Entre les deux se trouve la version 8.1, sortie en juin 2023 : c’est elle qui fait passer Vue.js de 2.6 à 3.2 dans le back-office, ajoute la compatibilité multi-boutique sur la page client, et introduit de nouvelles fonctionnalités de sécurité. PrestaShop 8.2, sorti en septembre 2024, apporte ensuite la prise en charge complète de PHP 8.2, avec des correctifs de performance et de sécurité. La branche 8.2.x est ensuite la seule de la série 8 à recevoir encore des correctifs de bugs critiques et de failles de sécurité ; l’éditeur n’a pas publié de date de fin pour ce suivi.

Sur le papier, 8.0 vers 8.2 reste dans la même branche majeure : la numérotation suggère une mise à jour mineure. En réalité, ce trajet traverse un changement de version majeure de Vue.js, un framework dont l’API interne n’est pas compatible d’une version majeure à l’autre pour tout ce qui manipule directement ses composants.

## Pourquoi une mise à jour « mineure » casse le back-office

Vue 2 et Vue 3 ne partagent pas la même API interne pour définir et manipuler les composants. Un widget d’administration sur mesure, ou un module qui ajoute un onglet à l’interface en s’appuyant directement sur des composants Vue 2, cesse de fonctionner une fois le back-office passé sur Vue 3 : ce n’est pas une question de configuration, le code qui manipulait Vue 2 n’a simplement plus d’équivalent direct.

C’est ce qui distingue ce couple de versions d’une simple mise à jour de sécurité : le numéro suggère un changement mineur, mais le passage par la 8.1 embarque une rupture technique réelle pour tout développement touchant l’interface d’administration.

Côté catalogue, commandes et front-office public, l’impact est généralement faible. La structure de la base ne change pas entre 8.0 et 8.2, et le thème public n’est pas concerné par ce changement de framework JavaScript. Le risque se concentre sur le JavaScript de l’administration et les modules qui y touchent directement.

## Signes qu’une personnalisation va casser en passant par la 8.1 puis la 8.2

- Un module ajoute un onglet ou un widget personnalisé en manipulant directement des composants Vue.js.
- Un développement sur mesure appelle l’API interne de Vue 2 (options API, mixins) plutôt qu’un point d’extension officiel PrestaShop.
- Le module n’a pas été mis à jour depuis avant juin 2023, date de sortie de la 8.1.
- La documentation du module ne précise aucune compatibilité au-delà de la 8.0.

## Comment je conduis cette migration mineure

1. **Audit des personnalisations du back-office** — Je repère les modules et développements sur mesure touchant l’interface d’administration : onglets, widgets, composants JavaScript.
2. **Sauvegarde des fichiers et de la base** — Sauvegarde complète avant toute opération, en plus de celle que le module autoupgrade réalise dans /autoupgrade/backup.
3. **Migration sur copie de la boutique** — Je fais transiter la copie par la 8.1 puis la 8.2 avec autoupgrade, pour isoler à quelle étape une personnalisation cesse de fonctionner.
4. **Exécution de la mise à jour** — Point de non-retour : une fois la mise à jour validée par autoupgrade, revenir en arrière suppose de restaurer la sauvegarde complète plutôt que d’annuler l’étape.
5. **Correction du JavaScript admin cassé** — Je réécris les personnalisations qui manipulaient Vue 2 pour les adapter à Vue 3, ou je les remplace par un point d’extension officiel quand c’est possible.
6. **Vérification et bascule** — Je contrôle en priorité le back-office (onglets, widgets, formulaires), puis le catalogue et les commandes, avant de basculer la production.

## Le catalogue et le front-office sont rarement concernés

> L’essentiel du risque se situe côté back-office et modules qui y touchent : catalogue, commandes et thème public ne sont, en règle générale, pas affectés par le passage de Vue 2 à Vue 3.

## Pour aller plus loin

- **Checklist avant toute migration** — Les vérifications avant de lancer une migration, quelle que soit la version cible. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration))
- **Modules incompatibles** — Comment repérer un module qui ne migrera pas tel quel, et par quoi le remplacer. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles))
- **Passer à PHP 8** — La montée de version PHP qui accompagne souvent une migration récente. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))
- **Migration PrestaShop 8 vers 9** — L’étape suivante une fois la 8.2 stabilisée : Symfony 6.4 et disparition des derniers contrôleurs legacy. ([/prestashop/migration/8-vers-9](/prestashop/migration/8-vers-9))

## FAQ

### Pourquoi une mise à jour mineure comme 8.0 vers 8.2 casserait-elle quelque chose ?

Parce qu’entre les deux se trouve la 8.1, qui fait passer le back-office de Vue.js 2.6 à 3.2. Le numéro reste dans la même branche majeure, mais ce changement de framework casse réellement les personnalisations manipulant directement des composants Vue 2.

### Dois-je m’inquiéter pour mon catalogue ou mes commandes ?

En règle générale non : la structure de la base ne change pas entre 8.0 et 8.2, et le thème public n’est pas concerné. Le risque se concentre sur l’administration.

### Puis-je passer directement de 8.0 à 8.2 sans passer par la 8.1 ?

Autoupgrade gère l’enchaînement des mises à jour successives. Je teste néanmoins sur une copie pour vérifier qu’aucune personnalisation ne casse au passage par la 8.1.

### Pourquoi migrer vers 8.2 si c’est risqué pour l’administration ?

Parce que la 8.2.x est la seule branche de la série 8 qui reçoit encore des correctifs de bugs critiques et de failles de sécurité. Rester sur 8.0 expose à des failles non corrigées, un risque généralement plus grand que corriger quelques personnalisations.