Enterprise App Catalog, Microsoft Store ou Win32 personnalisé : choisir le bon modèle

Résumé

J’utilise le modèle le plus supporté qui répond au besoin sans abandonner la maîtrise du cycle de vie. Microsoft Store convient lorsque l’éditeur maintient correctement son application. Enterprise App Catalog réduit le packaging pour les logiciels disponibles. Win32 personnalisé reste nécessaire pour les configurations ou versions qui exigent un contrôle spécifique.

Aucun modèle ne supprime la validation. Il faut connaître source du contenu, commande, détection, comportement de mise à jour, dépendances et stratégie de retrait. Une application préemballée peut encore être incompatible avec une configuration métier.

Les fonctions en déploiement progressif doivent être confirmées dans le tenant et dans Microsoft Learn avant de promettre une mise à jour automatique.

J’utilise le modèle le plus supporté qui répond au besoin sans abandonner la maîtrise du cycle de vie. Microsoft Store convient lorsque l’éditeur maintient correctement son application. Enterprise App Catalog réduit le packaging pour les logiciels disponibles. Win32 personnalisé reste nécessaire pour les configurations ou versions qui exigent un contrôle spécifique.

Contexte, objectif et périmètre

L’intégration Microsoft Store via Windows Package Manager et Enterprise App Management complète le modèle .intunewin historique, mais leurs catalogues, licences et mécanismes de version ne sont pas identiques.

Choisir uniquement sur la vitesse d’onboarding crée une dette si la version, les paramètres silencieux, la détection ou le rollback ne correspondent pas au besoin.

Je traite « Catalog, Store ou Win32 personnalisé » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

La configuration recommandée n’est pas une valeur universelle. Elle constitue un point de départ argumenté, à rapprocher des licences, des contraintes réseau, des responsabilités de support et de la maturité opérationnelle. Lorsque plusieurs méthodes existent, je privilégie celle qui réduit les autorités concurrentes et rend le résultat le plus facilement vérifiable.

Le passage en production suit une progression explicite : validation technique isolée, pilote métier, extension contrôlée puis généralisation. Chaque vague dispose de critères GO et NO-GO, d’une durée d’observation et d’un propriétaire capable d’arrêter ou de revenir en arrière sans attendre une décision improvisée.

• Objectif : définir un arbre de décision reproductible
• Objectif : clarifier la responsabilité des mises à jour
• Objectif : préparer pilote et rollback
• Périmètre : applications Windows dans Intune
• Périmètre : Microsoft Store (new), Enterprise App Catalog et Win32
• Périmètre : applications Required, Available et Autopilot

Architecture et fonctionnement général

Microsoft Store (new) utilise l’intégration Windows Package Manager pour rechercher et distribuer les applications. Selon le produit, le package peut relever du modèle AppX/MSIX ou Win32.

Enterprise App Catalog fournit des applications Win32 préparées et hébergées dans l’écosystème Microsoft. Les commandes et détections proposées réduisent l’effort initial, mais l’offre nécessite la licence adaptée et ne couvre pas toutes les variantes.

Win32 personnalisé place package, commandes, exigences, détection et relations sous la responsabilité de l’organisation. Il offre le contrôle maximal au prix d’une chaîne de packaging, tests et veille éditeur.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

• inventaire des applications et propriétaires
• licences vérifiées
• besoin de personnalisation et version documentés
• matrice de compatibilité Windows
• processus de supersedence et retrait

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

Comparer les responsabilités

Avec Microsoft Store, je vérifie qui publie l’application et comment ses mises à jour sont distribuées. L’intégration simplifie la sélection sans garantir que chaque éditeur adopte le même rythme ou la même stabilité.

Avec Enterprise App Catalog, Microsoft prépare le Win32 et fournit des métadonnées. Je reste responsable des affectations, du pilote, des conflits et du suivi des versions. Une version visible ne signifie pas qu’elle est déjà déployée automatiquement.

Avec Win32 personnalisé, l’organisation devient intégrateur. Ce modèle se justifie pour un transform MST, une configuration métier, une version figée, un wrapper ou une détection spécifique.

Applications essentielles pendant Autopilot

Une application du catalogue n’est pas automatiquement une bonne application bloquante. Je limite l’OOBE aux composants indispensables et déterministes.

Je teste poids, durée, redémarrages et dépendances. Une application volumineuse transforme vite un défaut applicatif en échec global du provisioning.

Je confirme que le type d’application est officiellement supporté par le profil ESP ou Device Preparation utilisé avant de l’intégrer au standard.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

• source identifiée
• installation silencieuse
• détection cohérente
• mise à jour testée
• rollback démontré
• Autopilot qualifié si utilisé

Journaux, diagnostic et constitution des preuves

Je compare l’état Intune avec la version installée et la source de mise à jour active. Pour Win32, je lis l’IME ; pour Store/AppX, j’ajoute les journaux AppX Deployment et l’état WinGet.

Je conserve nom, éditeur, identifiant de package, version et architecture. Une correspondance par nom commercial crée facilement doublons et détections incohérentes.

• version publiée
• commande et détection
• version installée
• source d’update
• journaux endpoint
• résultat du rollback

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : retirer l’affectation pilote
• Rollback : restaurer version précédente
• Rollback : revenir au package interne si le catalogue ne convient plus
• Vigilance : ne pas promettre de SLA de catalogue
• Vigilance : confirmer les fonctions en rollout
• Vigilance : ne pas modifier inutilement les commandes préremplies