Fin de support de Xamarin, Vue 2 et AngularJS : que faire de votre application ?

Une application peut tourner sans incident et reposer sur une technologie que plus personne ne maintient : Xamarin, l’outil mobile de Microsoft, ou Vue 2 et AngularJS côté web. Voici ce qui change, comment vérifier votre situation, ce que coûte chaque option et quand ne rien toucher. Pour une réponse sur votre propre code, un audit de reprise tranche en 1 à 3 jours.

Quelles technologies sont en fin de support, et depuis quand ?

Trois technologies très répandues ne reçoivent plus aucun correctif de leur éditeur : AngularJS depuis janvier 2022, Vue 2 depuis le 31 décembre 2023 et Xamarin, Xamarin.Forms compris, depuis le 1er mai 2024. Le code reste téléchargeable et les applications existantes fonctionnent, mais plus personne, côté éditeur, ne les corrige.

La fin de support est la date à partir de laquelle un éditeur cesse de publier correctifs, mises à jour de sécurité et nouveautés pour une technologie. Le logiciel reste disponible, mais figé.

Un framework est une boîte à outils logicielle qui fournit la structure d’une application, sur laquelle les développeurs écrivent le code du produit : en changer touche une grande partie du code.

Ces dates viennent des éditeurs : la politique de support de Xamarin de Microsoft, la page de fin de vie de Vue 2 et la page de statut du support d’AngularJS de l’équipe Angular de Google.

Que change la fin de support pour votre application ?

La fin de support ne fait pas tomber votre application : elle la fige. Quatre conséquences suivent, à un rythme qui dépend de votre produit : plus de correctifs de sécurité, des stores qui refusent vos mises à jour, des dépendances qui cassent une à une, et des développeurs de plus en plus rares pour la maintenir.

Plus aucun correctif de sécurité

Microsoft l’écrit dans sa politique : sans support, plus de mise à jour de sécurité. Restons honnêtes sur l’ampleur : l’équipe de Vue rappelle que Vue 2 n’a pas connu de faille majeure, tout en prévenant que des vulnérabilités finissent par apparaître, directement ou par les dépendances.

Le risque le plus immédiat est souvent contractuel : questionnaire de sécurité d’un grand compte, contrat qui interdit les logiciels non supportés, ou due diligence technique, l’audit qu’un investisseur mène sur un produit avant de signer.

Des stores qui refusent vos mises à jour

Pour une application Xamarin, le blocage est daté. Selon Microsoft, les derniers kits Xamarin s’arrêtent à Android 14 (niveau d’API 34) et à Xcode 15. Or Google Play exige Android 15 pour toute mise à jour depuis le 31 août 2025, puis Android 16 depuis le 31 août 2026, avec un délai possible jusqu’au 1er novembre 2026. Apple, de son côté, impose Xcode 26 depuis le 28 avril 2026.

Le niveau d’API cible est le réglage par lequel une application Android déclare pour quelle version du système elle a été conçue ; Xcode est l’outil d’Apple qui compile les applications iPhone. Une application Xamarin ne peut donc plus publier de version conforme, sauf bricolage que personne ne garantit. Elle reste en ligne, mais si elle cible Android 14 ou moins, les nouveaux utilisateurs des téléphones récents ne la voient plus. Le calendrier complet est dans notre article sur l’obligation Android 16 de Google Play.

Vue 2 et AngularJS échappent aux stores, sauf dans une application hybride, un site web emballé dans une application de store, qui cumule alors les deux problèmes.

Des dépendances qui cassent

Une dépendance est une brique logicielle écrite par un tiers, comme un module de paiement ou de cartographie, que l’application intègre au lieu de la réécrire. Chacune finit par abandonner les frameworks en fin de support : le correctif sort pour Vue 3 ou .NET MAUI, pas pour vous. L’équipe de Vue reconnaît aussi que les navigateurs cassent parfois les anciennes bibliothèques.

Un recrutement de plus en plus difficile

Vue 3 est la version par défaut depuis le 7 février 2022 : un développeur formé depuis apprend Vue 3. Angular partage son nom avec AngularJS, pas son architecture. Trouver qui maintiendra l’ancien code coûte plus cher chaque année, et cette personne devient vite la seule capable d’intervenir.

Comment savoir si votre application est concernée ?

Une heure suffit, sans compétence technique, si vous avez accès au code source ou à votre prestataire. Trois indices tranchent : le nom et la version du framework dans les fichiers du projet, la date de la dernière publication sur les stores, et les avertissements envoyés par Google ou Apple dans leurs consoles de publication.

La méthode, dans l’ordre :

1. Demandez la liste des technologies par écrit, avec leurs versions, à votre prestataire ou à votre CTO.
2. Ouvrez le fichier « package.json » d’une application web : « vue » en version 2 signale Vue 2, « angular » en version 1 signale AngularJS. Angular, lui, s’appelle « @angular/core ».
3. Cherchez le mot Xamarin dans les fichiers « .csproj » d’une application mobile écrite en C#.
4. Notez la date de la dernière version publiée sur chaque store et lisez les avertissements de la Play Console et d’App Store Connect.
5. Faites lister les failles connues des dépendances : sur un projet web, la commande « npm audit » le fait en quelques minutes.
6. Vérifiez que le code et les comptes stores sont à votre nom. Sinon, la migration bloque avant la première ligne.

Les signaux qui montrent que la fin de support pèse déjà sur votre produit :

• chaque petite évolution prend des semaines ;
• votre prestataire refuse de mettre à jour une bibliothèque « parce que ça casse tout » ;
• aucune version mobile n’est sortie depuis plus d’un an ;
• un client ou un investisseur demande la liste des composants non supportés.

Ce sont les symptômes d’une dette technique : notre article sur la mesure de la dette technique donne quatre indicateurs pour la chiffrer.

Quelles options pour migrer une application Xamarin, Vue 2 ou AngularJS ?

Chaque technologie a sa sortie naturelle : .NET MAUI, Flutter ou React Native pour Xamarin, Vue 3 pour Vue 2, Angular ou Vue 3 pour AngularJS. Le vrai choix porte sur la méthode : migrer progressivement en gardant le produit en ligne, ou reconstruire l’interface d’un bloc en conservant le serveur et les données.

Xamarin : .NET MAUI, Flutter ou React Native

Microsoft trace la voie officielle : Xamarin.Forms migre vers .NET MAUI, Xamarin.Android et Xamarin.iOS deviennent .NET pour Android et .NET pour iOS. .NET MAUI est le framework de Microsoft qui produit des applications iOS, Android, macOS et Windows depuis une base de code en C#. Il garde le langage et les compétences de l’équipe, mais impose un rythme : une version majeure sort chaque année, et la précédente n’est garantie que six mois après. .NET MAUI 10 est supporté jusqu’au 11 mai 2027.

Flutter est le framework open source de Google qui produit des applications iOS et Android depuis une seule base de code, avec son propre moteur d’affichage. Passer de Xamarin à Flutter, c’est réécrire l’application mobile ; le serveur, l’API et les données restent en place. Krafter utilise Flutter en production depuis 2024 : Melimelo, notre application d’organisation du foyer, compte plus de 50 versions publiées. Notre pratique de Flutter détaille quand nous le recommandons.

React Native se justifie si une équipe JavaScript doit reprendre l’application. Et si votre équipe écrit du C# et veut garder la main, .NET MAUI est souvent le meilleur choix, même s’il ne fait pas partie de notre stack : nous vous le dirons dès le premier échange.

Vue 2 : passer à Vue 3, de préférence progressivement

L’équipe de Vue fournit une version de compatibilité officielle, le migration build : l’application tourne en mode Vue 2, chaque usage à modifier est signalé, et la mise en production reste possible avant la fin de la migration. Limites documentées : les bibliothèques de composants liées au fonctionnement interne de Vue 2 doivent être remplacées, et une application vaste reste un chantier. Krafter écrit ses propres interfaces web en Vue 3.

La migration progressive est une méthode qui remplace une application écran par écran ou module par module, en gardant le produit en ligne pendant les travaux. Elle étale le coût et le risque, au prix d’une période où l’ancien et le nouveau code cohabitent.

AngularJS : Angular ou Vue 3, une réécriture dans les deux cas

Angular n’est pas une nouvelle version d’AngularJS, mais un framework réécrit. Passer à Angular ou à Vue 3 revient donc à réécrire l’interface, de préférence écran par écran, en gardant le serveur et la base de données. Le bon choix dépend de l’équipe qui maintiendra le code.

Reconstruire d’un bloc se justifie pour une petite application, un code sans tests où chaque correction en casse une autre, ou un changement de framework qui impose déjà une réécriture. Migrer progressivement convient à une application vaste, qui fait du chiffre d’affaires et repose sur des fondations saines.

Combien coûte la sortie d’une technologie en fin de support ?

Le budget dépend de la taille de l’application et de l’option retenue. Chez Krafter, tout commence par un audit de 1 à 3 jours, soit 700 à 3 300 € HT, qui aboutit à un plan chiffré. La migration progressive se facture ensuite au temps passé ; une reconstruction suit la grille publique du studio, dès 6 000 € HT.

Le plancher de 6 000 € HT vaut quand le besoin est déjà défini, et une application existante joue souvent ce rôle ; s’il faut le reformuler, le cadrage d’un logiciel à reprendre ajoute 1 500 à 5 000 € HT. Ce plancher tient à un socle open source, à deux associés seniors qui s’appuient sur l’IA et relisent chaque ligne, et à l’absence de couche commerciale. Les grilles complètes sont sur nos pages développement mobile et développement SaaS, et le simulateur de budget situe votre projet en 8 questions.

Scénario type : une PME a fait développer en 2020 une application Xamarin.Forms de prise de rendez-vous, reliée à un back-office en Vue 2. Le freelance est parti. L’audit, mené en deux jours, montre un serveur sain et une application mobile à réécrire. Le plan prévoit une reconstruction en Flutter sur la grille d’un MVP mobile, avec l’API existante, puis la migration progressive du back-office vers Vue 3. La nouvelle application sort sur la même fiche de store, comme une simple mise à jour. Le rapport d’audit vous appartient, quelle que soit l’équipe qui réalise la suite.

Quand ne faut-il pas migrer ?

Ne migrez pas une application qui n’a plus d’avenir. Si elle compte peu d’utilisateurs, ne porte pas votre chiffre d’affaires ou sera remplacée dans l’année, la laisser figée coûte moins cher que de la refaire. La fin de support est un risque à piloter, pas une obligation de dépenser.

Les cas où le statu quo est la bonne décision :

• Un outil interne en Vue 2 ou AngularJS, derrière un accès restreint : surveillez les failles annoncées et planifiez la sortie sans urgence.
• Une application mobile interne bloquée par les stores : une application web installable sur le téléphone, hors stores, la remplace souvent pour moins cher. Trottr, notre logiciel d’interventions terrain, a fait ce choix.
• Un produit en fin de vie, remplacé dans les douze mois par un autre produit ou un logiciel du marché.
• Une contrainte de conformité sans budget immédiat : pour Vue 2 et AngularJS, les pages officielles orientent vers des offres de support étendu payantes. C’est un pont, pas une destination, et Microsoft ne prévoit rien de tel pour Xamarin.

Dernière règle : ne migrez pas pour migrer. Une migration doit débloquer quelque chose de concret : une mise à jour, l’exigence d’un client, une évolution bloquée. Sinon, l’argent est mieux placé dans le produit.

Par où commencer cette semaine ?

Identifiez la technologie et sa version, puis sécurisez le code source et les comptes : ce sont eux qui bloquent le plus souvent, bien avant la technique. Faites ensuite chiffrer les options par une équipe qui publie elle-même des applications, avant qu’une échéance de store ou une faille ne décide à votre place.

Si le prestataire d’origine a disparu, suivez la marche décrite dans que faire quand votre logiciel n’a plus de développeur. Après la migration, le maintien en conditions évite de revivre la même impasse à la prochaine fin de support.

Parlez-nous de votre application : un des deux fondateurs vous répond sous 24 à 48 heures, avec un avis honnête, y compris quand la bonne réponse est .NET MAUI ou le statu quo.