← Toutes les publications

App-V Server : le support prolongé jusqu’en octobre 2029 laisse du temps pour préparer la migration

Microsoft a annoncé le 6 octobre 2026 le retour d’App-V Server en support étendu jusqu’au 9 octobre 2029. Les organisations qui exploitent encore ces serveurs peuvent réviser leur calendrier de remplacement, sans assimiler cette prolongation à une reprise du développement du produit.

Impact
infrastructures App-V Server existantes ; le client et le séquenceur intégrés à Windows suivent un cycle distinct.
Action
séparer les dépendances serveur, client et packaging dans l’inventaire, puis réviser le plan de migration application par application.
Statut
À planifier

Ce que prolonge Microsoft

La KB5131438, publiée le 6 octobre, revient sur la fin de support d’avril 2026 pour les composants serveur. Ce n’est pas une annonce du jour : elle mérite d’être traitée maintenant parce qu’elle change l’hypothèse de support utilisée pour maintenir ou remplacer une infrastructure encore en exploitation.

La politique App-V confirme la nouvelle échéance. Elle précise aussi que le produit n’est plus en développement actif et que le support étendu ne permet pas de demander de nouvelles fonctionnalités ou des changements de conception.

Composant Règle à retenir
App-V Server Support étendu jusqu’au 9 octobre 2029.
Client et séquenceur App-V Suivent le cycle de la version Windows correspondante ; ils ne sont pas déclarés dépréciés par cette politique.
Windows qui héberge les composants Son propre cycle doit être vérifié : la prolongation App-V ne constitue pas une prolongation du système d’exploitation.

Point documentaire à conserver dans le dossier de décision : la fiche Lifecycle générique « Microsoft Application Virtualization 5.1 » affiche encore l’ancienne échéance d’avril 2026 à la consultation du 22 octobre. La KB et la politique de support concordent explicitement sur 2029 pour le serveur ; ne pas présenter toutes les pages Microsoft comme déjà alignées.

Transformer ce délai en décisions vérifiables

Commencer par rapprocher l’inventaire des serveurs de publication et de gestion, les packages réellement utilisés et les postes consommateurs. Identifier les applications qui dépendent encore de ces serveurs, ainsi que leurs groupes de connexion. Le résultat attendu est une liste attribuée à des responsables applicatifs, pas une simple liste de fichiers App-V. Toute dépendance inconnue reste à qualifier avant un retrait de serveur.

Pour les applications candidates à MSIX, sélectionner un cas autonome et un cas comportant des interactions entre packages. Microsoft documente des mécanismes différents : groupes de connexion côté App-V, conteneurs partagés côté MSIX, avec signature requise pour MSIX. Cela ne prouve pas qu’une conversion particulière sera compatible.

Notre recommandation est de comparer, sur un environnement de test, lancement par un utilisateur standard, accès aux données, échanges entre applications, mise à jour et désinstallation. Une conversion réussie ne suffit pas : poursuivre seulement si les scénarios métier et la confiance dans la signature fonctionnent sur les postes cibles ; sinon, documenter l’écart et conserver le mode de livraison existant pendant sa résolution.

La prolongation permet donc de revoir l’ordre des migrations. Elle ne justifie ni un arrêt du travail de qualification ni une conversion massive sans validation.

Sources