Outil gratuit
Application Advisor
Quelle méthode pour quelle application, combien à packager, et un outil tiers se rembourse-t-il ?
Décrivez vos familles d'applications — d'où elles viennent, ce qu'elles exigent, ce qu'elles pèsent — et l'outil nomme la méthode de livraison Intune qui convient à chacune : catalogue géré, Store, winget, ou paquet Win32. Il compte celles qui demandent vraiment du packaging, chiffre les jours que cela coûte la première fois puis tous les ans, et pose l'arithmétique d'une fabrique tierce face au devis que vous avez reçu.
Aucune inscription, aucun cookie : ce que vous saisissez reste dans votre navigateur et s'efface quand vous fermez l'onglet — rien n'en sort. Seule la visite est comptée, par une mesure d'audience sans cookie qui ne vous identifie pas, décrite dans les mentions légales.
Le parc, et ce qu'il peut dépenser
Deux de ces réponses opposent un veto à toutes vos familles à la fois : si un lien vous fait hésiter, et si le catalogue géré est couvert par vos licences. Les autres transforment un nombre d'applications en jours, et les jours en euros.
Vos familles d'applications
Une famille, c'est un ensemble d'applications qui répondraient la même chose aux questions ci-dessous : « les produits éditeurs courants sans configuration », « les applications métier packagées à la main », « le développement maison ». Une application que vous voulez arbitrer seule fait une famille d'une.
Le plan
Tous les jours affichés dérivent d'un seul nombre que vous avez donné : l'effort de packaging d'une application standard chez vous. L'outil le module par la personnalisation déclarée et par le nombre de versions que vous déployez, et suppose qu'un repackaging coûte une fraction d'un premier packaging. Ces rapports sont des conventions énoncées dans l'avertissement, pas des mesures. Mesurez vingt applications réelles avant d'annoncer un chiffre à qui que ce soit, et refaites le calcul : c'est une soirée de travail et cela change tout le dossier.
Une aide à la décision, pas un audit. L'outil raisonne sur ce que vous déclarez ; il ne voit ni votre catalogue, ni la couverture réelle d'un éditeur sur vos produits, ni ce que vos applications font à l'installation. La position de licence du catalogue géré a bougé en 2026 : vérifiez-la à la date où vous lisez ceci plutôt que de la supposer.
La stratégie
Six méthodes, et aucune ne couvre seule un catalogue
Choisir entre un paquet Win32 et une application du Store n'est pas une décision sur la façon dont un fichier est déposé. C'est une décision sur qui possède la version suivante, d'où viennent ses octets, et ce que vous gardez le droit de contrôler une fois qu'elle est en production. Ce qui suit est ce dont il faut disposer pour trancher.
Les six méthodes, et ce que chacune engage
Une méthode n'est pas un format de paquet : c'est un cycle de vie. Elle décide qui produit la version suivante, d'où viennent ses octets à chaque fois qu'elle change, et ce que vous avez encore le droit de modifier. Elle ne décide ni qui reçoit l'application — c'est le modèle d'affectation — ni si l'application mérite d'exister, ce que seule la rationalisation tranche.
| Méthode | Qui possède la version suivante | D'où viennent les octets |
|---|---|---|
| Win32 standard | Vous, paquet par paquet | CDN Intune — partage et cache s'appliquent |
| Win32 + winget | L'éditeur, via le dépôt public | CDN éditeur — ni partage, ni cache |
| Application du Store | Le Store, à son calendrier | CDN Store en UWP ; CDN éditeur en Win32 |
| Catalogue géré | Microsoft, pour son catalogue | CDN Intune — partage et cache s'appliquent |
| LOB (MSI) | Vous, avec moins d'outils qu'en Win32 | CDN Intune — partage et cache s'appliquent |
| Fabrique tierce | L'outil, sur des anneaux que vous définissez | CDN Intune — partage et cache s'appliquent |
Le LOB (MSI) n'est pas proposé par l'outil : il n'accepte ni détection personnalisée, ni dépendance, ni remplacement, et tout ce qu'il sait faire, le paquet Win32 le fait mieux. Il ne survit que là où un éditeur interdit contractuellement le repackaging.
Le verdict réseau : deux méthodes laissent le réseau hors du cadre
C'est le critère qui tranche le plus de cas, et le moins discuté. Le contenu servi par le CDN Intune passe par Delivery Optimization et par Connected Cache : un poste du site paie le téléchargement, les autres sont servis localement. Le contenu servi par un CDN éditeur — winget, et les applications Win32 publiées au Store — ne passe par aucun des deux : chaque poste tire le binaire entier, à chaque version, et rien dans la console ne le montre.
L'arithmétique est brutale et c'est celle à poser devant qui veut un catalogue « winget d'abord » : une application de cent mégaoctets, rendue requise sur un site de trois cents postes, c'est trente gigaoctets par un seul lien — et autant à la version suivante. La même application livrée en Win32 traverse ce lien une fois.
La règle
- Requis sur un site contraint : le contenu vient du CDN Intune, sans exception.
- winget et le Win32 du Store restent légitimes en libre-service, où seuls les demandeurs téléchargent.
- Sous cinquante mégaoctets, rien n'est partagé entre pairs par défaut : abaissez le seuil si vos paquets sont petits.
- Un point de distribution décommissionné devient un nœud de cache, pas un serveur à éteindre.
Ce qui ne se voit pas
- Une application publiée au Store peut être UWP ou Win32, et la console ne le dit pas : la première est servie comme le CDN Intune, la seconde pas du tout.
- Aucun rapport Intune ne mesure ce qui est passé par un CDN éditeur : la saturation se voit sur le routeur, pas dans la console.
- Une famille passée de « libre-service » à « requise » change de verdict réseau sans que personne ne refasse le calcul.
- Le poids d'un paquet augmente à chaque version : le calcul d'il y a deux ans ne vaut plus.
La dette de mise à jour : ce que personne ne chiffre
Un catalogue n'est pas migré une fois, il est mis à jour aussi longtemps qu'il existe. L'effort initial de packaging est visible et se chiffre dans un plan de charge ; l'effort récurrent est invisible et se paie tous les mois par la même équipe. Une application à cadence mensuelle coûte, sur trois ans, plusieurs fois son premier packaging.
Deux pièges au moment de confier cette dette à une mise à jour automatique. Les deux mécanismes natifs ne couvrent pas la même intention d'affectation : concevez la stratégie par intention, pas par application, faute de quoi une partie du parc cessera silencieusement d'être à jour. Et il n'existe pas de retour arrière en un clic : le recours est un remplacement inversé construit sous pression. L'anneau pilote est la protection — ce n'est pas un raffinement, c'est la seule chose entre une mauvaise version éditeur et tout le parc.
Ce qui reste à mesurer avant tout engagement chiffré
- L'effort réel d'un packaging chez vous — c'est le seul nombre dont dépend toute la page, et il varie d'un facteur trois entre deux équipes selon leur niveau de test.
- Le coût d'une reprise de version — supposé ici à deux cinquièmes d'un premier packaging. Mesurez-le séparément : c'est lui qui décide du dossier de la fabrique tierce.
- La couverture d'un catalogue sur vos produits — une taille annoncée en milliers de produits ne dit rien du recouvrement avec les vôtres. Exigez le recoupement sur votre propre liste.
- La part du catalogue qui survit à la rationalisation — c'est le plus gros effet isolé sur la charge, et le moins souvent mesuré avant qu'un projet soit engagé.
- Ce que les mises à jour automatiques font sur un an — à quelle fréquence une version non voulue arrive réellement, et ce qu'elle coûte quand elle arrive.