Une migration App-V vers MSIX fait passer un parc d'applications App-V hérité vers le format de packaging moderne MSIX, afin que ces applications continuent de fonctionner proprement sur Windows 11 et se déploient via Intune. En pratique, le travail est une séquence courte et reproductible : auditez le parc App-V, convertissez les packages qui se convertissent directement, corrigez les écarts d'exécution qui apparaissent, testez sur de vrais postes, signez chaque package avec un certificat de confiance, puis déployez via Intune avec des anneaux d'attribution progressifs. Certains packages se convertissent en quelques minutes ; d'autres nécessitent une autre route, et savoir lequel est lequel avant de commencer est ce qui rend le projet prévisible.
Pourquoi les organisations quittent App-V
App-V fonctionne toujours, et Microsoft est explicite : les équipes dont l'ensemble de fonctionnalités App-V continue de répondre à leurs besoins ne sont pas contraintes de migrer. Si tant de parcs planifient malgré tout le passage, c'est que la plateforme est désormais figée. App-V n'est plus développé. Le client et le séquenceur App-V sont passés en support étendu fixe : ils sont toujours livrés avec Windows et reçoivent des correctifs de bogues et de sécurité, mais aucune nouvelle fonctionnalité n'est ajoutée. Les composants serveur App-V sont allés plus loin : ils ont été dépréciés et leur support a pris fin en avril 2026, de sorte que la partie serveur d'un déploiement App-V a maintenant dépassé sa durée de vie prise en charge.
Cette combinaison d'un client figé et d'un serveur non pris en charge est la raison pour laquelle une planification anticipée a du sens maintenant, tant qu'il reste du temps pour la mener calmement plutôt que contre une échéance. Les équipes qui doivent continuer à exécuter des packages App-V sur Azure Virtual Desktop sans monter d'infrastructure serveur App-V peuvent utiliser App-V app attach, la voie prise en charge par Microsoft, ce qui laisse de la marge pour planifier un passage en bonne et due forme vers MSIX.
Ce qui se convertit et ce qui ne se convertit pas
Tous les packages App-V ne prennent pas la même route vers MSIX, et la ligne de partage est la version d'App-V.
Le MSIX Packaging Tool convertit directement les packages App-V 5.1. Pointez-le vers le fichier .appv, via l'interface ou la ligne de commande, et l'outil traduit le manifeste existant en package MSIX. Comme les informations du package sont déjà structurées, c'est la conversion la plus rapide et la plus propre disponible.
Les packages App-V 4.x sont une autre affaire. La conversion directe n'est pas prise en charge, et la recommandation de Microsoft est de revenir à l'installateur source d'origine et de convertir celui-ci en MSIX à la place. Lorsque l'installateur source a été perdu, et dans les parcs plus anciens c'est souvent le cas, un réempaquetage capture-first à partir d'une installation active est la route pratique : vous traitez l'application en cours d'exécution comme la source de vérité et la reconstruisez sous forme de package signé.
La conversion s'arrête aussi rarement au package. Certaines applications se comportent différemment à l'intérieur d'un conteneur MSIX, qui redirige certaines écritures de fichiers et de registre. Ces comportements d'exécution se corrigent avec le Package Support Framework (PSF), qui applique des correctifs ciblés et peut exécuter des scripts au lancement pour préparer l'environnement attendu par l'application.
Auditez le parc App-V avant de migrer
Une migration ne vaut que son inventaire. Avant de convertir quoi que ce soit, dressez un tableau de ce que contient le parc et de la façon dont il est utilisé. L'audit doit capturer :
- Inventaire des packages. Chaque package App-V en circulation, avec sa version, son propriétaire et l'endroit où il est publié.
- Utilisation. Quels packages sont activement lancés et par qui ; les packages dormants ne valent peut-être pas la peine d'être migrés.
- Répartition App-V 4.x contre 5.x. Cela décide la route par package : 5.1 se convertit directement, 4.x passe par l'installateur source ou capture-first.
- Média source manquant. Signalez les packages dont l'installateur d'origine a disparu, car ce sont vos candidats capture-first.
- Scripts et middleware. Scripts App-V, runtimes et dépendances partagées qui devront être traités après la conversion.
- Groupes de connexion. Les packages qui s'exécutent ensemble nécessitent que leurs relations soient comprises avant d'être séparés.
- Candidats à la retraite. Les applications que personne n'utilise, ou qui ont déjà un remplaçant moderne, devraient être retirées plutôt que migrées.
Le résultat est une décision par package : convertir directement, convertir depuis la source, capture-first, ou retirer. Cette liste est la colonne vertébrale de l'ensemble du projet.
De l'audit du parc App-V aux packages MSIX signés déployés via Intune.
Choisir une méthode de migration App-V vers MSIX
Une fois l'audit en main, chaque package peut être orienté vers la bonne méthode, qui dépend de sa version, de la survie de sa source, et du nombre de packages à déplacer.
| Méthode | Idéal pour | Niveau d'automatisation | Points de vigilance |
|---|---|---|---|
| Réempaquetage manuel | Applications sans source App-V et logique d'installation complexe | Faible, manuel de bout en bout | Lent et difficile à reproduire de façon cohérente entre packagers |
| Conversion MSIX Packaging Tool | Packages App-V 5.1 au comportement propre et bien compris | Moyen, workflow d'interface guidé | Seul App-V 5.1 se convertit directement ; 4.x nécessite l'installateur source |
| Conversion par lots scriptée (exécutions de modèle en ligne de commande) | Grands parcs App-V 5.x convertis en masse | Élevé, exécutions pilotées par modèle | Nécessite des modèles solides et une validation par application ensuite |
| Réempaquetage capture-first (EtherApps Forge) | App-V 4.x ou packages dont la source est perdue | Élevé, agentique avec revue humaine | Confirmez les droits de licence avant de recapturer une application installée |
Le workflow de conversion
Quelle que soit la méthode qu'un package emprunte, la conversion elle-même suit une forme cohérente.
Commencez sur une machine propre. Utilisez une machine virtuelle ou de référence Windows 11 propre et à jour comme environnement de conversion, afin de packager l'application et non le désordre d'un poste de travail utilisé.
Évaluez d'abord. Comprenez l'installateur ou le package App-V avant de le convertir, afin de savoir s'il se convertira proprement et ce qu'il écrit.
Convertissez. Pour un package App-V 5.1, exécutez le MSIX Packaging Tool. Pour une exécution en masse sur un parc App-V 5.x plus large, pilotez-le depuis la ligne de commande avec un modèle :
MsixPackagingTool.exe create-package --template C:\conversions\LineOfBusinessApp.xml -v
Le modèle porte les informations et paramètres du package, de sorte qu'une configuration peut être réutilisée pour des versions ultérieures et scriptée sur de nombreux packages. Générez-le une fois via l'interface, puis réutilisez-le pour les exécutions par lots.
Passez en revue le package. Ouvrez le MSIX obtenu dans l'éditeur de package et vérifiez le manifeste, les points d'entrée et les capacités avant de signer.
Appliquez PSF si nécessaire. Lorsqu'une application convertie se comporte mal à l'intérieur du conteneur, ajoutez le Package Support Framework avec le correctif dont elle a besoin, y compris un script de lancement si l'application en attend un.
Tests, signature et déploiement Intune
Un package converti n'est qu'un candidat tant qu'il n'est pas testé et signé.
Signez-le. Les packages MSIX doivent être signés avec un certificat auquel le parc fait confiance avant de s'installer sur les postes managés. Il n'y a aucune signature App-V à hériter, donc le package prend le certificat de signature de code de votre organisation, dont l'identité doit correspondre à l'éditeur nommé dans le manifeste.
Testez sur des postes représentatifs. Installez et éprouvez chaque package sur de vrais postes Windows 11 correspondant au parc cible : vérifiez le lancement, les flux de travail essentiels, l'activation des licences, les paramètres par utilisateur et la désinstallation, pas simplement que ça s'installe.
Déployez via Intune avec des anneaux. Ajoutez le MSIX signé à Intune et attribuez-le par étapes : un anneau pilote d'abord, puis des anneaux plus larges, afin qu'un problème apparaisse sur une poignée de postes plutôt que sur tout le parc.
Un exemple concret
Considérez deux packages issus du même audit.
Le premier est une application métier App-V 5.1 en usage quotidien, dont le comportement est bien compris. Elle se convertit directement : le MSIX Packaging Tool lit le fichier .appv et produit un package MSIX en une seule passe. Un pilote Windows 11 fait remonter un bloqueur, l'application s'appuie sur un script de lancement qui définissait une variable d'environnement que le conteneur n'a pas reprise. Un correctif Package Support Framework exécute ce script au lancement et elle se comporte correctement. Le package est signé, piloté sur un petit anneau, puis attribué plus largement dans Intune.
Le second est un package App-V 4.x plus ancien dont l'installateur a été perdu il y a des années, sans média source de repli. La conversion directe n'est pas disponible, il emprunte donc la route capture-first à la place : capturé depuis une installation active, reconstruit en MSIX signé, testé sur Windows 11 et déployé de la même façon. Même destination, route différente, et l'audit a indiqué à l'équipe ce dont chaque package avait besoin avant que le moindre temps ne soit dépensé.
Questions sur la migration App-V vers MSIX, avec réponses
Les packages App-V peuvent-ils être convertis directement en MSIX ?
Les packages App-V 5.1 le peuvent : le MSIX Packaging Tool les convertit directement depuis le fichier .appv, via l'interface ou la ligne de commande. Les packages App-V 4.x ne le peuvent pas ; Microsoft recommande de convertir depuis l'installateur source d'origine, ou un réempaquetage capture-first à partir d'une installation active lorsque cet installateur est perdu.
Quels outils sont disponibles pour la migration App-V vers MSIX ?
Le MSIX Packaging Tool de Microsoft gère la conversion directe App-V 5.1 et les exécutions par lots scriptées depuis la ligne de commande, et le Package Support Framework gère ensuite les correctifs d'exécution. Pour les packages qui ne peuvent pas se convertir directement, une approche capture-first reconstruit l'application à partir d'une installation en cours d'exécution, et c'est là qu'intervient EtherApps Forge.
Qu'est-ce qui casse pendant la conversion ?
Les casses courantes sont des comportements d'exécution que le conteneur MSIX modifie : écritures de fichiers ou de registre qu'il redirige, scripts de lancement qui préparent l'environnement, et configuration par utilisateur qu'une conversion au niveau machine ne transporte pas. La plupart se résolvent avec un correctif Package Support Framework ; les packages App-V 4.x cassent entièrement la route directe.
Les packages convertis doivent-ils être resignés ?
Oui. Chaque package MSIX doit être signé avec un certificat auquel le parc fait confiance avant de s'installer sur les postes managés, et il n'y a aucune signature App-V à réutiliser. Assurez-vous que l'identité du certificat correspond à l'éditeur du manifeste.
Comment déployer les applications MSIX migrées avec Intune ?
Ajoutez le MSIX signé à Intune et attribuez-le en anneaux progressifs, en commençant par un groupe pilote. Testez d'abord sur des postes Windows 11 représentatifs, puis élargissez anneau par anneau afin que tout problème soit détecté tôt.
La place d'EtherApps Forge
La plupart des parcs App-V sont un mélange : des packages App-V 5.1 qui se convertissent directement, et une queue tenace de packages App-V 4.x ou à source perdue qui ne le font pas. EtherApps Forge est conçu pour cette queue. En tant qu'outil de packaging capture-first, il capture l'application depuis une installation active et la reconstruit, de sorte qu'un installateur perdu n'est plus une impasse.
Le workflow est agentique avec revue humaine : EtherApps Forge analyse l'empreinte capturée et recommande une route, qu'un packager confirme, plutôt que de prétendre que les applications difficiles se packagent toutes seules. Les sorties couvrent MSIX, MSI, PowerShell App Deployment Toolkit, IntuneWin et App Attach, de sorte qu'une seule capture peut alimenter une livraison Intune ou un scénario App Attach Azure Virtual Desktop. Prouvez-le d'abord sur une vraie application avec l'essai gratuit de 7 jours avant d'engager le parc plus large.
Pour le volet livraison, voir packaging et déploiement MSIX, et pour les packages dont la source a disparu, moderniser les applications Windows héritées couvre le chemin de l'installateur perdu. Les guides complémentaires sur un chemin capture-first vers MSIX pour les applications complexes et comment réempaqueter une application lorsque l'installateur est perdu vont plus loin, et le packaging d'applications agentique explique le modèle automatisé de capture et de revue.
Une migration App-V vers MSIX est d'abord un travail de planification et ensuite un travail de packaging : auditez le parc, orientez chaque package vers la méthode qui convient, corrigez les écarts d'exécution, signez, testez et déployez via Intune en anneaux. Faites bien l'audit et le reste devient une routine.
Découvrez le packaging et déploiement MSIX pour un accompagnement de migration App-V vers MSIX couvrant la conversion, les correctifs PSF, la signature et le déploiement Intune.