MSIX à grande échelle : ce que révèlent 3 261 cas d'empaquetage automatisé

Un workflow automatisé peut-il transformer des applications Windows existantes en paquets MSIX sur des milliers de cas, et pas seulement sur une poignée de démonstrations ? Notre nouvelle étude répond oui pour une grande partie des cas tentés : sur 3 261 cas d'applications, 2 957 ont produit un paquet MSIX (90,68 %) et 2 610 ont enregistré un smoke test entièrement réussi (80,04 %). L'article, "MSIX at Scale: An Automated Packaging Study of 3,261 Windows Application Cases", est disponible dès maintenant sur Zenodo sous licence CC BY 4.0 avec le DOI 10.5281/zenodo.21985871, accompagné d'un supplément qui permet à chacun de recalculer chaque chiffre.

Si vous gérez le parc applicatif d'une organisation de 50 à 600 utilisateurs, ou si vous empaquetez des applications pour vos clients en tant que MSP, la question derrière cette étude vous est familière. Vous avez des programmes d'installation, des fichiers MSI, des archives ZIP et des outils portables sous toutes les formes imaginables. Les réempaqueter à la main est lent, chaque packageur s'y prend un peu différemment, et le backlog diminue rarement. L'étude se demande si ce travail peut être répété de façon fiable à grand volume, et elle définit avec soin ce que signifie "a fonctionné".

Ce que l'étude a mesuré

MSIX est le format de paquet de Microsoft pour installer et gérer les applications Windows. Un paquet réunit les fichiers de l'application et un manifeste qui indique à Windows ce que contient le paquet et comment ses applications démarrent. Les recommandations de conversion de Microsoft traitent la préparation, la capture, la création du paquet et les tests comme des étapes distinctes, et l'étude garde elle aussi ces étapes distinctes.

Nous avons analysé les enregistrements, finalisés le 27 juin 2026, de chaque cas pour lequel une tentative d'empaquetage MSIX a été enregistrée. Les applications proviennent de recherches dans le catalogue public de Windows Package Manager (WinGet). Chaque cas tenté compte dans le dénominateur, y compris ceux qui se sont arrêtés tôt, de sorte que les pourcentages principaux ne peuvent pas être gonflés en écartant discrètement les échecs.

Chaque cas a été rapporté selon quatre étapes :

1. Paquet produit : la génération MSIX s'est terminée.
2. Installé et inscrit : le paquet a été installé pour un utilisateur de test et Windows l'a inscrit.
3. Point d'entrée démarré : un programme sélectionné dans le paquet s'est lancé.
4. Smoke test entièrement réussi : l'installation, le lancement, la fermeture et le nettoyage ont tous été enregistrés comme réussis, sans plantage détecté.

Un smoke test est une première vérification rapide, pas un test complet. Il confirme qu'un paquet s'installe, qu'un programme sélectionné démarre et que le test se ferme et nettoie. Il ne teste ni la connexion, ni la modification d'un document, ni l'enregistrement de données. Nous avons gardé cette distinction visible tout au long de l'article, et nous la gardons visible ici.

Les résultats

Chaque pourcentage porte sur les 3 261 cas tentés. Les étapes se recoupent, elles ne doivent donc pas être additionnées.

Regardez où les cas décrochent. 304 tentatives n'ont pas produit de paquet, mais presque autant, 281, se sont installées et inscrites proprement sans ensuite enregistrer le démarrage d'un programme. C'est la leçon pratique pour tout programme d'empaquetage : un fichier de paquet présent sur le disque, ou même une installation propre, n'est pas la même chose qu'une application qui fonctionne. Le succès de la génération et le succès de l'application doivent être rapportés séparément, sinon un plan de migration paraîtra en meilleure santé qu'il ne l'est.

Des réussites ont par ailleurs été obtenues pour chaque type de source de l'étude. Voici les smoke tests entièrement réussis par type de programme d'installation ou de distribution :

Ces groupes contiennent des applications différentes aux exigences différentes, donc le tableau ne montre pas qu'un type d'installation entraîne une probabilité de réussite plus ou moins élevée. Ce qu'il montre, c'est que les réussites ne se limitaient pas à un seul type d'installation. C'est important lorsque votre parc mélange tous ces types.

Comment nous avons vérifié les preuves

Des chiffres comme ceux-ci méritent un examen attentif, c'est pourquoi l'article décrit comment ils ont été vérifiés avant leur publication.

• Chaque réussite a été comparée à son rapport enregistré. Les 2 610 smoke tests réussis enregistrés ont été comparés à leurs rapports de test d'origine associés, sur les six champs d'étape de test. Tous concordaient.
• Les rapports en double ont été identifiés. Les empreintes de fichiers ont révélé six paires de cas partageant des rapports identiques, donc l'article compte des cas du catalogue et des résultats enregistrés, et non des exécutions de test indépendantes.
• Nous avons rapporté le constat gênant. Deux cas réussis ont lancé un utilitaire de désactivation au lieu de l'application principale, et la vérification d'identité automatisée ne l'a pas signalé. Ils restent dans le total selon la règle énoncée, et l'article s'en sert comme l'exemple le plus clair de la raison pour laquelle un lancement ne prouve pas que l'application visée fonctionne.
• Les nouvelles tentatives sont déclarées. Les historiques enregistrés contiennent 3 942 résumés de tentatives : 2 712 cas ont eu une tentative, 417 en ont eu deux et 132 en ont eu trois. Ce sont des résultats du workflow, pas des taux de réussite au premier essai.

Le supplément comprend les résultats par cas, les notes de sélection et des scripts Python qui reproduisent chaque tableau et chaque pourcentage.

Ce que l'étude n'affirme pas

Les limites sont aussi utiles que les résultats, en particulier si vous prévoyez de partager cette étude avec d'autres personnes de votre organisation.

• Ce n'est pas un taux de compatibilité général. Les applications ont été tirées de recherches dans le catalogue, pas d'un échantillon aléatoire, et elles ne représentent ni votre liste d'applications ni les logiciels Windows en général.
• Ce n'est pas une preuve de préparation à la production. Les tests de tâches métier, la fiabilité à long terme et le déploiement auprès des utilisateurs finaux n'ont pas été mesurés.
• Elle ne mesure pas les gains de temps ou de coûts. Aucune comparaison n'a été faite avec l'empaquetage manuel ou d'autres approches.
• Elle n'a pas été reproduite de manière indépendante. L'article est un preprint et n'a pas été évalué par des pairs. Je développe EtherApps Forge, l'outil utilisé dans l'étude, et j'ai un intérêt commercial dans les résultats. Cette relation est déclarée dans l'article et chaque lecteur doit en tenir compte.

Un cas sans résultat réussi ne prouve pas non plus que l'application ne peut pas fonctionner avec MSIX. Certaines applications ont besoin de correctifs (fix-ups), d'un autre format de paquet ou d'un examen plus approfondi.

Ce que cela signifie pour votre programme d'empaquetage

Pour les responsables informatiques et les dirigeants de MSP, l'étude soutient une position claire : MSIX est une option d'empaquetage pratique pour les applications Windows existantes adaptées, et il a sa place dans votre stratégie d'empaquetage. Il ne doit pas être obligatoire pour chaque application, et la décision se prend de préférence application par application.

Pour les praticiens qui font le travail, l'article propose un processus de décision que vous pouvez appliquer à votre propre parc :

1. Testez avec vos propres applications. Évaluez MSIX avec les applications que votre organisation utilise réellement, pas avec la liste d'exemples d'un fournisseur.
2. Gardez les étapes distinctes. Enregistrez la création du paquet, l'installation, la vérification initiale et les tests de tâches métier comme des résultats distincts.
3. Vérifiez que le bon programme démarre. Assurez-vous que le test de lancement sélectionne l'application principale visée, et non un programme d'aide ou un utilitaire.
4. Testez le travail réel. Connexion, gestion des fichiers, intégrations, mises à jour et utilisation prolongée, puis déploiement sur des appareils cibles propres.
5. Orientez les exceptions. Les applications qui nécessitent des pilotes, des services ou des modifications à l'échelle de la machine relèvent peut-être d'un autre format. Le parcours capture d'abord vers MSIX pour les applications Windows complexes explique comment trancher.

Gardez aussi à l'esprit le comportement en confiance totale (full trust). Les recommandations de Microsoft sur la conteneurisation indiquent qu'une application de bureau empaquetée en confiance totale s'exécute avec les mêmes autorisations qu'une application de bureau standard. MSIX vous apporte donc une installation et une suppression propres, et non une frontière de sécurité automatique.

Si vous devez présenter ce sujet à un comité des changements ou à un client, le DOI et le supplément reproductible vous fournissent des preuves que vous pouvez transmettre et que d'autres peuvent vérifier.

La place d'EtherApps Forge

EtherApps Forge est le workflow utilisé tout au long de l'étude. Il a vérifié chaque source, capturé les fichiers et les paramètres de l'application, généré et signé le paquet MSIX, puis l'a installé, lancé et nettoyé comme premier test. La conclusion de l'article est volontairement mesurée : EtherApps Forge peut vous aider à transformer des sources d'applications existantes adaptées en paquets MSIX prêts pour votre propre validation. Ce n'est pas la promesse d'une migration entièrement automatique et prête pour la production.

EtherApps Forge est une application de bureau Windows qui s'exécute dans votre propre environnement, de sorte que les captures et les paquets restent chez vous. Son workflow d'empaquetage d'applications agentique recommande un parcours à partir de l'empreinte réelle de l'application, et ses correctifs Package Support Framework aident les applications capturées qui ont besoin d'une redirection de fichiers ou du registre. Pour les parcs accumulant des années de programmes d'installation, la modernisation des applications héritées couvre la découverte et la remédiation. Des articles antérieurs du même programme de recherche examinent MSIX natif face à App Attach pour Azure Virtual Desktop et où le Package Support Framework ajoute du risque à MSIX et App Attach.

Le moyen le plus rapide de savoir si vos propres applications se comportent comme les cas de l'étude est de les faire passer par le même workflow. EtherApps Forge comprend un essai gratuit de 7 jours du workflow complet, et chaque licence inclut la formation et le support.

Découvrir l'empaquetage et le déploiement MSIX pour voir comment les preuves en quatre étapes de l'étude deviennent un processus reproductible d'empaquetage et de livraison pour votre parc.