Vue 2 a atteint sa fin de vie le 31 décembre 2023 : plus aucune mise à jour, y compris les correctifs de sécurité. Les applications qui reposent encore sur Vue 2 — et sur son écosystème (Vue Router 3, Vuex, Vuetify 2) — sont désormais figées et exposées. Migrer vers Vue 3 est une transition nécessaire, facilitée par la compatibilité partielle entre les deux versions mais qui exige néanmoins une préparation rigoureuse, notamment pour adopter la Composition API et le nouveau modèle de réactivité.
Pourquoi sortir de Vue 2 maintenant
Vue 2 reste techniquement fonctionnel, mais son écosystème s’éteint. Les principales bibliothèques de composants (Vuetify, Element Plus, Quasar) ont migré vers Vue 3 et abandonnent leurs versions Vue 2. Les outils de build, les plugins et les correctifs de sécurité ne sont plus maintenus pour Vue 2. Au-delà de la sécurité, rester sur Vue 2 isole l’application des évolutions du framework et complique le recrutement : les développeurs Vue travaillent désormais en Vue 3.
| Critère | Vue 2 | Vue 3 |
|---|---|---|
| Support | Terminé (déc. 2023) | Actif |
| Réactivité | Object.defineProperty | Proxies (plus performant) |
| API | Options API | Options API + Composition API |
| Performance | Référence | Rendu plus rapide, bundle réduit |
| TypeScript | Support partiel | Support natif |
Ce qui change entre Vue 2 et Vue 3
Vue 3 conserve l’Options API pour faciliter la transition, mais introduit plusieurs changements structurants :
- La Composition API (
setup,ref,reactive,computed) : une nouvelle façon d’organiser la logique par fonctionnalité, plus lisible et plus testable, qui coexiste avec l’Options API. - Le nouveau moteur de réactivité basé sur les Proxies JavaScript : plus performant, il corrige les limites de Vue 2 (détection des ajouts/suppressions de propriétés, index de tableau).
- Le support natif de TypeScript et un compilateur optimisé qui réduit la taille du bundle.
- La fin des filtres (
filters), des événements globaux ($on,$off) et de certaines API internes, remplacés par des alternatives. - Le multi-racine dans les templates et les fragments, ainsi qu’un nouvel outillage (Vite) recommandé en remplacement de webpack.
La stratégie de migration progressive
Vue fournit un pont de compatibilité, @vue/compat (le « migration build »), qui permet de faire tourner du code Vue 2 dans Vue 3 en émulant les anciennes API. C’est la clé d’une migration incrémentale :
- Audit de l’application : inventorier les composants, les dépendances (Vue Router, Vuex/Pinia, bibliothèques UI) et les usages des API dépréciées.
- Mise à jour des dépendances : vérifier la compatibilité Vue 3 de chaque bibliothèque, et planifier les remplacements (Vuex → Pinia, Vuetify 2 → Vuetify 3).
- Activation du migration build : basculer l’application sur
@vue/compatpour la faire tourner en Vue 3 tout en émulant les anciennes API. - Migration des composants : convertir progressivement les composants, en adoptant la Composition API sur les nouvelles fonctionnalités et en supprimant les API dépréciées.
- Suppression du pont de compatibilité : une fois tout le code migré, retirer
@vue/compatpour bénéficier des performances complètes de Vue 3. - Tests et bascule : valider par des tests automatisés, puis déployer avec un plan de rollback.
Les pièges à anticiper
Le piège le plus fréquent est la coexistence des bibliothèques : une application qui dépend d’un composant tiers non porté en Vue 3 peut bloquer toute la migration ; il faut alors planifier son remplacement ou son fork. Le deuxième piège est la réactivité : le passage aux Proxies corrige des comportements, mais un code qui s’appuyait sur les limites de Vue 2 (ou sur des mutations non tracées) peut se comporter différemment. Enfin, la conduite du changement est essentielle : la Composition API demande un temps d’apprentissage, et il faut accompagner les équipes pour éviter un rejet.
Migrer Vuex vers Pinia et adopter Vite
La migration vers Vue 3 ne s’arrête pas au framework lui-même : l’écosystème doit suivre. Le store Vuex, historique en Vue 2, est remplacé par Pinia, désormais recommandé par l’équipe Vue. Pinia offre une API plus simple, un meilleur support TypeScript et une intégration native à la Composition API. La migration de Vuex vers Pinia consiste à traduire les state, getters, mutations et actions en store, getters et actions Pinia, un travail mécanique mais qui mérite une validation fonctionnelle.
Parallèlement, l’outil de build Vite remplace avantageusement webpack : il offre un démarrage du serveur de développement quasi instantané, un HMR (hot module replacement) rapide et des builds optimisés. Le passage à Vite implique de réorganiser la configuration (vite.config.js), de vérifier les alias et les plugins, et d’adapter le chargement des ressources. Combinée à la Composition API, cette modernisation de l’outillage réduit sensiblement le temps de compilation et améliore l’expérience de développement.
Points de vigilance :
- Vérifier la compatibilité de chaque plugin Vue 2 (et de ses alternatives Vue 3) avant de basculer sur Vite ;
- Auditer les imports globaux et les
require(CommonJS) qui doivent être convertis enimportESM ; - Revalider les variables d’environnement (
VITE_*) et la configuration de build pour chaque environnement.
La réactivité par Proxies, TypeScript et les tests
Le passage au moteur de réactivité par Proxies modifie des comportements subtils qu’il faut valider. Là où Vue 2 ne détectait ni l’ajout ou la suppression d’une propriété d’objet ni la modification directe d’un index de tableau, Vue 3 les trace nativement. Un code qui contournait ces limites via Vue.set ou $set doit être simplifié, tandis qu’un code qui exploitait accidentellement la non-réactivité peut désormais déclencher des re-rendus inattendus. Passez en revue les mutations d’objets et de tableaux lors de la conversion.
Côté typage, l’adoption progressive de TypeScript est l’un des principaux bénéfices de Vue 3 : commencez par les composants les plus sollicités, en typant les props, les emits et les refs, sans nécessairement convertir toute la base d’un coup. Côté tests, l’écosystème a évolué : Vitest remplace Jest avec un démarrage plus rapide et une intégration native à Vite, et @vue/test-utils permet de tester les composants en montage réel ou en rendu isolé. Rejouez la suite de tests après chaque lot migré et complétez la couverture sur les composants refactorisés en Composition API, afin de garantir que la transition ne modifie aucun comportement fonctionnel.
Enfin, quelques subtilités de l’API méritent d’être anticipées : ref enveloppe les valeurs primitives dans un objet réactif quand reactive s’applique aux objets, les computed sont désormais mis en cache automatiquement, et la liste des événements émis (emits) doit être déclarée pour bénéficier d’une meilleure vérification des types. Ces ajustements, traités au fil de la conversion, évitent les régressions discrètes et facilitent l’adoption de TypeScript sur le long terme.
L’accompagnement d’un expert
Migrer une application Vue 2 vers Vue 3 est un projet d’ingénierie qui combine compatibilité, refactorisation et montée en compétences. Chez Performances Digital, nous pilotons cette transition de bout en bout : audit de l’écosystème, planification de la migration incrémentale, conversion des composants, adoption de la Composition API et formation de vos équipes. Notre méthode s’appuie sur le migration build de Vue pour garantir une application stable et déployable à chaque étape.
Vue 2 est en fin de vie depuis fin 2023 : chaque mois supplémentaire accroît l’obsolescence et l’exposition de votre application. Demandez votre devis gratuit : nous évaluerons votre application Vue 2 et vous proposerons un plan de transition vers Vue 3, adapté à la taille de votre front-end et à votre écosystème.
