Migration Vue 2 → Vue 3 : modernisez votre frontend
Vue 2 est en fin de vie depuis décembre 2023. Failles non corrigées, écosystème qui rétrécit, recrutement difficile →chaque mois supplémentaire sur Vue 2 est un risque supplémentaire.
Audit complet, migration progressive via @vue/compat, tests automatisés : nous sécurisons la bascule sans bloquer vos évolutions métier.
Ça vous parle ?
Les situations qui déclenchent une migration
Vue 2 n'est plus maintenu depuis janvier 2024
Les failles de sécurité ne sont plus corrigées. Chaque mois supplémentaire sur Vue 2 expose votre application et complique le recrutement de développeurs.
L'écosystème Vue 2 se ferme
Les bibliothèques UI, les plugins et les outils (Vite, Vitest, Pinia) n'existent qu'en Vue 3. Rester sur Vue 2, c'est être bloqué sur un écosystème qui rétrécit.
La migration a été commencée mais abandonnée
Une branche @vue/compat en sommeil depuis des mois, des composants à moitié portés →reprendre ce type de chantier à mi-chemin est notre quotidien.
Notre conviction
Une migration Vue 3 n'est pas une réécriture →c'est une modernisation progressive
Le piège classique est de vouloir tout réécrire d'un coup en Vue 3 avec la Composition API, Pinia et Vite. Ce type de projet "big bang" dure 6 mois, gèle les évolutions métier et livre rarement ce qui était prévu. Vue 3 a été conçu pour une migration progressive : @vue/compat permet de faire cohabiter du code Vue 2 et Vue 3 dans la même application.
Notre approche : on migre par feature, on déploie régulièrement, on garde la production stable à chaque sprint. La migration avance en parallèle des évolutions pas à leur place.
Vue 3
Ce que la migration apporte concrètement
Migrer vers Vue 3, c'est accéder à un écosystème vivant, des performances améliorées et une DX (Developer Experience) nettement supérieure avec TypeScript et la Composition API.
Performances améliorées
Le moteur de rendu de Vue 3 est jusqu'à 2× plus rapide que Vue 2 sur les listes longues et les mises à jour fréquentes. L'arbre DOM virtuel est optimisé par compilation.
TypeScript de premier ordre
Vue 3 a été réécrit en TypeScript. La Composition API avec <script setup> offre une inférence de types complète sans configuration supplémentaire.
Écosystème actif
Vite, Pinia, Vue Router 4, Nuxt 3, VueUse : l'écosystème Vue 3 est vivant et entretenu. Rester sur Vue 2, c'est rester sur des outils en fin de vie.
Composition API
Organisation de la logique par feature plutôt que par option (data/methods/computed). Meilleure réutilisabilité via les composables →l'équivalent des hooks React.
<script setup>
Syntaxe de composition sans boilerplate : variables et fonctions déclarées directement exposées au template. Réduit la taille des composants de 30 à 40 %.
Pinia : Store simplifié
Remplaçant officiel de Vuex : pas de mutations, pas de modules complexes. Un store = une fonction composable. TypeScript natif, DevTools inclus.
Vite : Build instantané
Démarrage du serveur de développement en moins d'une seconde, HMR quasi-instantané. Remplacement définitif de Vue CLI et Webpack pour les projets Vue.
Teleport
Rendu d'un composant dans un nœud DOM arbitraire (ex : body) sans rompre la logique du composant parent. Idéal pour les modales et tooltips.
Suspense
Gestion native du chargement asynchrone des composants avec un fallback UI. Simplifie les états de chargement complexes sans state management supplémentaire.
Méthodologie
4 étapes pour migrer sans bloquer la production
Pas d'improvisation. Chaque migration suit le même processus structuré, de l'audit initial jusqu'à la bascule en production.
Étape 1 : Audit
Cartographie des dépendances et risques
Avant d'écrire la moindre ligne, nous analysons l'état réel de votre application : version de Vue, bibliothèques tierces, utilisation des API dépréciées, couverture de tests.
Le livrable est un rapport d'audit avec la liste des incompatibilités, une priorisation des actions et une estimation du chantier. Vous validez avant de vous engager sur la suite.
Inventaire des dépendances
Audit de toutes les bibliothèques Vue 2 : compatibilité Vue 3, alternatives disponibles, bibliothèques sans successeur à remplacer.
API dépréciées et breaking changes
Scan du code source avec @vue/compat pour identifier toutes les utilisations d'API supprimées en Vue 3 : filtres, $on, v-model sur composants, render functions.
Rapport et estimation
Document structuré avec charge estimée, risques classifiés et recommandations sur la stratégie de migration. Vous savez exactement ce qui vous attend.
Étape 2 : Préparation
Mise en place du filet de sécurité
Avant de toucher au code, nous sécurisons la base : branche de migration dédiée, Vitest configuré sur les flux critiques, @vue/compat activé pour révéler toutes les incompatibilités en conditions réelles.
Cette étape est non négociable. Elle conditionne la réversibilité de chaque modification et la fiabilité des validations avant la mise en production.
Applications Vue 2 très anciennes
Sur des applications volumineuses avec beaucoup de mixins et de bibliothèques sans équivalent Vue 3, une réécriture partielle ciblée (les écrans les plus utilisés) peut être plus rentable qu'une migration exhaustive. Cette décision est prise à l'issue de l'audit en fonction du volume de code et de la couverture fonctionnelle.
Tests automatisés sur les flux critiques
Écriture ou renforcement des tests Vitest sur les composants et fonctionnalités métier essentiels pour détecter les régressions dès leur apparition.
Environnement de staging isolé
Une branche dédiée à la migration avec une instance de staging identique à la production, où toutes les validations sont effectuées avant la bascule.
Activation de @vue/compat
Le build de compatibilité Vue 3 est activé en premier, il fait tourner l'application comme Vue 3 tout en émettant des warnings pour chaque API dépréciée utilisée.
vue-codemod pour les transformations mécaniques
L'outil officiel automatise les refactorings répétitifs : Options API vers Composition API, renommages d'API, suppression des filtres sans erreur humaine.
Étape 3 : Exécution
Migration composant par composant
Nous progressons composant par composant, en regroupant par feature métier. @vue/compat nous indique exactement quelles API restent à migrer →on ne passe pas en mode Vue 3 natif tant qu'un warning subsiste.
Les bibliothèques sans équivalent Vue 3 sont traitées au cas par cas : remplacement, fork ou développement interne selon leur criticité.
La force de SmartBooster
Nous ne bloquons pas les évolutions métier pendant la migration. Les nouvelles fonctionnalités sont développées directement en Vue 3 ; l'ancien code est migré en parallèle. Chaque sprint livre à la fois de la valeur métier et du code migré.
Options API → Composition API
Conversion progressive des composants vers <script setup> et la Composition API. Priorité aux composants les plus réutilisés et les plus critiques.
Mise à jour des bibliothèques tierces
Chaque dépendance est mise à jour vers sa version Vue 3, remplacée par un équivalent ou développée en interne si aucune alternative n'existe.
Validation continue
Les tests Vitest tournent à chaque commit. Les warnings @vue/compat sont traités systématiquement. Jamais de dette cachée entre deux sprints.
Étape 4 : Déploiement
Bascule en production sans surprise
La migration production est planifiée avec une fenêtre de maintenance, une checklist de validation post-déploiement et une procédure de rollback testée en staging.
Nous restons disponibles les jours suivants pour monitorer et corriger d'éventuels comportements inattendus en conditions réelles.
Une fois la migration stabilisée, nous pouvons prendre en charge la maintenance et les évolutions de votre frontend sur le long terme. Découvrez notre approche TMA (Tierce Maintenance Applicative).
Fenêtre de maintenance planifiée
La bascule est cadrée : heure, durée, équipe présente, rollback prêt. Rien n'est laissé au hasard.
Vérification post-déploiement
Check complet après la bascule : fonctionnalités, performances, logs. L'application est validée avant de lever la maintenance.
Suivi post-migration
Surveillance active les jours suivants et prise en charge rapide de tout incident lié à la migration.
Nos bonnes pratiques
Ce qui fait la différence pour réussir nos migrations
Ces pratiques ne s'improvisent pas →elles s'acquièrent avec l'expérience et la confiance de nos clients pour réaliser des chantiers parfois invisibles.
Avec les années, trois bonnes pratiques essentielles nous permettent de livrer des migrations de qualité sans perturber la production.
Nettoyer avant de migrer
- Composants inutilisés : Les composants jamais appelés, les pages abandonnées et les mixins redondants s'accumulent dans les projets Vue 2 anciens. On les retire avant de migrer →moins de code à porter, moins de risques.
- Bibliothèques obsolètes : Moment.js, Vue2Leaflet, vue-good-table… Les alternatives modernes (Day.js, Leaflet 1.9, TanStack Table) sont souvent plus légères et Vue-3-compatibles. On profite de la migration pour mettre à jour.
- Mixins → Composables : Les mixins Vue 2 posent des problèmes de collisions et de lisibilité. La migration est l'occasion de les convertir en composables Vue 3 →plus explicites, plus testables, sans magie implicite.
Automatiser pour uniformiser
- @vue/compat comme filet de sécurité : Le build de compatibilité officiel émet des warnings pour chaque API dépréciée utilisée. On l'active en premier et on traite les warnings systématiquement avant de basculer sur Vue 3 natif.
- vue-codemod pour les transformations mécaniques : L'outil officiel automatise la plupart des renommages et des restructurations répétitives (Options API → Composition API, $on/$off, filtres supprimés). Il réduit le volume de code à traiter manuellement.
- Vitest pour la couverture de tests : La migration est l'occasion d'adopter Vitest : le remplaçant natif de Jest dans l'écosystème Vite. Chaque composant migré est couvert par des tests qui détectent les régressions immédiatement.
Garder la production opérationnelle
- Migration par feature, pas par composant : Plutôt que de migrer tous les composants en séquence, on regroupe les composants par feature métier. Chaque livraison est une feature complète, testée de bout en bout →pas un demi-composant en attente.
- Déploiements successifs : On ne bloque pas les évolutions métier pendant la migration. Les nouvelles fonctionnalités sont développées directement en Vue 3 ; l'ancien code est migré en parallèle. La production reste stable à chaque sprint.
- Monitoring des erreurs en conditions réelles : L'analyse statique ne détecte pas tous les cas aux limites. Nos outils de monitoring repèrent les erreurs runtime après chaque déploiement, là où les tests ne peuvent pas tout anticiper.
BREAKING CHANGES
Principaux changements incompatibles Vue 2 → Vue 3
Vue 3 a supprimé les API dépréciées de Vue 2 et modifié plusieurs comportements fondamentaux. Ce recensement permet de calibrer le chantier avant de démarrer.
-
Vue 2 → Vue 3
Migration principaleSuppression des API dépréciées et changement du modèle de composants. Utiliser @vue/compat pour identifier toutes les incompatibilités avant de migrer.
- createApp() remplace new Vue() : L'application n'est plus une instance globale →chaque app a son propre contexte isolé. Vue.use(), Vue.mixin() et Vue.component() deviennent app.use(), app.mixin(), app.component().
- v-model sur composants : La prop change de value → modelValue, l'event de input → update:modelValue. Les composants avec v-model doivent être mis à jour manuellement.
- Filtres supprimés : Les filtres Vue 2 ({{ value | filter }}) sont retirés. Les remplacer par des computed properties ou des méthodes utilitaires.
- $on / $off / $once retirés : Le pattern EventBus basé sur une instance Vue ne fonctionne plus. Migrer vers mitt ou tiny-emitter pour les communications inter-composants.
- Fragments (racines multiples) : Un composant Vue 3 peut avoir plusieurs éléments racine. Les wrappers <div> ajoutés uniquement pour satisfaire Vue 2 peuvent être supprimés.
- render() et VNodes : L'API de la fonction render change : h() est maintenant importé globalement, les VNodes sont des objets plats →les render functions Vue 2 doivent être réécrites.
-
Vue Router 3 → 4
Obligatoire avec Vue 3Vue Router 4 est requis pour Vue 3. L'API est très proche mais quelques points de rupture nécessitent des ajustements.
- createRouter() remplace new VueRouter() : L'instanciation change et le mode history utilise createWebHistory() au lieu de mode: 'history'.
- Propriétés $route dépréciées : $route.params et $route.query restent disponibles mais les guards de navigation reçoivent un objet RouteLocationNormalized plus complet →mettre à jour les signatures.
- Hooks dans la Composition API : onBeforeRouteLeave et onBeforeRouteUpdate remplacent les hooks d'options beforeRouteLeave et beforeRouteUpdate dans les composants en Composition API.
-
Vuex 3 → Pinia
RecommandéVuex 4 fonctionne avec Vue 3 mais Pinia est désormais le store officiel. La migration peut se faire progressivement, module par module.
- Pas de mutations en Pinia : En Pinia, l'état se modifie directement dans les actions →les mutations Vuex n'existent pas. Simplification majeure du code de store.
- defineStore() remplace les modules Vuex : Chaque store Pinia est une fonction indépendante avec son propre namespace. Plus besoin de modules imbriqués ni de namespaced: true.
- useStore() par store : On importe et utilise chaque store individuellement (useUserStore(), useCartStore()) au lieu d'un store global unique →meilleure traçabilité et tree-shaking.
Source : Guide de migration officiel Vue 3 — liste non exhaustive, centrée sur les cas les plus fréquents en contexte applicatif.
« Au départ, nous avons contacté SmartBooster pour réaliser un outil de suivi de contrat en facturation en remplacement de notre outil de gestion sous Excel.
Ce qui nous a plus par la suite, c'est la possibilité de rajouter progressivement de nouvelles fonctionnalités en fonction de nos besoins.
À présent, notre outil intègre un CRM, des statistiques pour le suivi de l'activité, l'accès aux fonctionnalités en fonction des droits des collaborateurs et nous réfléchissons à une interface client pour l'année prochaine. »
« Une belle expertise dans le développement !
Une équipe sympathique, réactive, toujours à l'écoute de nos besoins et surtout force de proposition dans la mise en place de nouvelles fonctionnalités optimales nous faciliter le quotidien.
Cela fait plus de 3 ans que SmartBooster nous accompagne, je recommande vivement! »
Pour aller plus loin
Approfondir votre réflexion
Après une migration réussie, la TMA prend le relais pour maintenir votre frontend à jour en continu — sans nouveau chantier à gérer.
Si la migration révèle une dette technique trop importante, une refonte partielle ou complète peut être la bonne réponse.
Historique des versions, avantages et cas d'usage de Vue.js dans nos projets Symfony.
FAQ
Les réponses à vos questions
Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !
Cela dépend de la taille de l'application, du nombre de composants, de l'utilisation de Vuex et des bibliothèques tierces. Un projet de taille moyenne (50 à 150 composants) prend généralement de 4 à 10 semaines. Nous réalisons d'abord un audit pour vous fournir une estimation avant tout engagement.
Oui. Nous utilisons @vue/compat (le build de compatibilité officiel de Vue 3) qui permet de faire cohabiter du code Vue 2 et Vue 3 dans la même application. On migre composant par composant, en production, sans bloquer les évolutions métier pendant des semaines.
Vuex 4 est compatible Vue 3, donc vous pouvez conserver Vuex temporairement. Cependant, Pinia est désormais le store officiel →plus simple, mieux typé TypeScript, mieux intégré aux DevTools. Nous recommandons de migrer Vuex vers Pinia en même temps ou juste après la migration Vue 3.
La plupart des bibliothèques populaires ont publié une version Vue 3 (Vuetify 3, Quasar 2, Element Plus, etc.). Certaines n'ont pas de version Vue 3 et devront être remplacées. L'audit initial identifie tous les bloquants et vous propose des alternatives.
Non. Vue 3 supporte JavaScript et TypeScript. Cependant, la Composition API avec TypeScript offre une expérience de développement nettement supérieure. Nous pouvons migrer en JS d'abord, puis introduire TypeScript progressivement sur les nouveaux composants.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.