Déployer une application Windows avec Intune sans winget

winget est pratique en ligne de commande pour installer une application sur son propre poste. Mais en dépendre pour le déploiement de masse via Intune montre vite ses limites : disponibilité du paquet dans le dépôt, dépendance au réseau au moment de l'installation, exécution dans le contexte du compte système, versions parfois en retard sur celle de l'éditeur. Beaucoup d'équipes préfèrent, pour ces raisons, déployer directement le vrai installeur signé fourni par l'éditeur, dont elles maîtrisent la version et le comportement.

L'approche recommandée par Microsoft pour cela est le déploiement d'applications Win32 empaquetées au format .intunewin. Elle donne le contrôle total sur l'installeur, la commande d'installation, les règles de détection et le comportement en cas d'échec. En contrepartie, elle demande de comprendre quelques concepts et d'éviter deux ou trois pièges classiques. Voyons-les en détail, avec un exemple concret et la façon dont AuPoint automatise l'ensemble du parcours.

Le principe du packaging Win32

Une application Win32 dans Intune, c'est un installeur empaqueté dans une archive chiffrée .intunewin, accompagné d'instructions précises : comment l'installer silencieusement, comment détecter qu'il est bien présent, et à quel groupe l'assigner. Intune télécharge le paquet sur le poste, exécute la commande d'installation, puis évalue la règle de détection pour confirmer le succès.

1. 1Récupérer l'installeur officiel (.msi ou .exe) et sa commande d'installation silencieuse.
2. 2L'empaqueter au format .intunewin à l'aide de l'outil de préparation de contenu Microsoft.
3. 3Définir la commande d'installation et de désinstallation silencieuses.
4. 4Définir les règles de détection (version du fichier, clé de registre, présence du produit MSI).
5. 5Assigner au groupe cible, en tenant compte de l'architecture (x86, x64, ARM).
6. 6Tester sur un poste pilote avant l'assignation générale.

Les règles de détection, cœur du sujet

La règle de détection indique à Intune si l'application est déjà installée. Mal définie, elle provoque des réinstallations en boucle ou, à l'inverse, des installations considérées à tort comme réussies. Pour un MSI, la détection par code produit est fiable et se génère automatiquement. Pour un EXE, on s'appuie sur la version d'un fichier clé ou sur une clé de registre écrite par l'installeur.

La règle d'or est de toujours vérifier que la détection correspond exactement à la version déployée. Une détection trop laxiste (« le dossier existe ») considérera une vieille version comme à jour ; une détection trop stricte relancera l'installation à chaque cycle. C'est le réglage qui demande le plus de soin, et celui où les erreurs sont les plus discrètes.

Le piège des architectures

C'est l'erreur la plus fréquente et la plus silencieuse. Si plusieurs installeurs existent (x86, x64, ARM), il faut créer une règle par architecture, chacune avec sa détection et ses conditions d'applicabilité. Déployer un binaire x64 sur un poste ARM, ou l'inverse, échoue — parfois sans message clair. Les postes Windows sur ARM se multiplient, ce piège devient donc de plus en plus concret.

• Vérifier quelles architectures l'éditeur propose réellement.
• Créer une application Intune (ou une règle d'applicabilité) par architecture nécessaire.
• Adapter la détection à chaque variante, car les chemins d'installation peuvent différer.
• Ne jamais supposer qu'un installeur x64 couvrira les postes ARM.
• Tester chaque variante sur un poste réel de l'architecture correspondante.

Un exemple concret : déployer un lecteur PDF métier

Une équipe veut déployer un lecteur PDF professionnel sur cent postes. L'éditeur fournit un .msi en x64 et un .msi en ARM. La tentation est de ne packager que le x64, puisque la majorité du parc l'utilise. Mais cinq nouveaux portables ARM viennent d'arriver : sur ceux-là, l'installation échouerait silencieusement, et les utilisateurs se retrouveraient sans l'application sans que personne ne comprenne pourquoi.

La bonne démarche consiste à créer deux applications Win32, une par architecture, chacune avec sa règle de détection par code produit et sa condition d'applicabilité. On teste d'abord sur un poste x64 et un poste ARM, on confirme la détection, puis on assigne au groupe complet. Résultat : les cent postes reçoivent la bonne version, et le déploiement ne laisse aucun poste orphelin.

Gérer les mises à jour dans le temps

Déployer une application n'est que le début : il faut ensuite la maintenir à jour. On publie une nouvelle version avec une règle de détection mise à jour, et Intune constate que la version en place est obsolète pour appliquer la nouvelle. Le point de vigilance est toujours le même : la détection doit cibler précisément la nouvelle version, sinon Intune considérera l'ancienne comme conforme et n'installera rien.

Une gestion propre des versions évite l'accumulation d'applications obsolètes sur le parc, qui est une source majeure de vulnérabilités. Garder un lien direct avec l'installeur officiel de l'éditeur, plutôt qu'un binaire figé téléchargé une fois, facilite grandement ce suivi et réduit le risque de déployer une version vulnérable.

Contexte d'exécution et prérequis

Au-delà de la détection et de l'architecture, quelques réglages déterminent la fiabilité d'un déploiement Win32. Les négliger conduit à des installations qui réussissent sur le poste de test mais échouent en production, sur des machines aux profils variés.

• Le contexte : installer en tant que système pour les applications destinées à tous les utilisateurs, ou en tant qu'utilisateur pour les cas particuliers.
• Les exigences : imposer une version minimale de Windows, une architecture, un espace disque libre suffisant.
• Le comportement de redémarrage : gérer proprement les codes de retour qui demandent un redémarrage.
• Le délai et les nouvelles tentatives : Intune réessaie une installation échouée, encore faut-il que la commande soit idempotente.
• La disponibilité ou l'obligation : proposer l'application au catalogue, ou l'imposer silencieusement selon le besoin.

Comment AuPoint automatise le déploiement

AuPoint récupère le vrai installeur signé de l'éditeur, gère les différentes architectures et réalise le packaging .intunewin à votre place, puis assigne l'application aux postes. Aucun winget n'est requis côté endpoint : c'est bien l'installeur officiel qui est déployé. Les règles de détection sont générées automatiquement, ce qui élimine la principale source d'erreur et le réglage le plus délicat.

Comme pour les contrôles de sécurité, l'aperçu vous montre les postes concernés avant l'assignation, et l'ensemble reste réversible. Vous pouvez commencer par un poste pilote, valider, puis étendre — tout en gardant la maîtrise du parcours et sans manipuler d'outils en ligne de commande ni d'archives à préparer manuellement.

Questions fréquentes

Faut-il abandonner complètement winget ?

Non, winget reste utile pour des cas simples ou ponctuels. Mais pour un déploiement de masse fiable et reproductible, empaqueter le vrai installeur en Win32 donne davantage de contrôle et moins de dépendances au moment de l'installation, notamment quand le réseau ou le dépôt sont indisponibles.

Comment mettre à jour une application déployée ?

On déploie une nouvelle version de l'application avec une règle de détection mise à jour. Intune détecte que la version en place est obsolète et applique la nouvelle. Il faut veiller à ce que la détection cible bien la nouvelle version, sans quoi rien ne s'installe.

Pourquoi une installation échoue-t-elle silencieusement ?

Le plus souvent, à cause d'une architecture inadaptée (x64 sur ARM) ou d'une règle de détection incorrecte. Générer la détection automatiquement et séparer les architectures, comme le fait AuPoint, élimine ces deux causes.

Connectez votre tenant à AuPoint et testez le déploiement d'une application sur un poste pilote en quelques minutes — le vrai installeur, empaqueté et assigné pour vous. Démarrez gratuitement.