Déployer une application Win32 avec Intune

Déployer une application métier avec Intune est l’opération qui génère le plus de frustration chez les administrateurs qui débutent. Le paquet s’installe en local mais échoue depuis Intune, ou pire : il s’installe en boucle indéfiniment. Dans la quasi-totalité des cas, la cause est la même — et elle n’est pas là où on la cherche.

Le format .intunewin

Intune ne distribue pas directement un .exe ou un .msi. Il faut d’abord encapsuler les fichiers source dans un conteneur chiffré au format .intunewin, produit par l’outil gratuit Microsoft Win32 Content Prep Tool.

L’outil demande trois informations : le dossier contenant les fichiers source, le fichier d’installation principal, et le dossier de sortie.

IntuneWinAppUtil.exe -c C:\Sources\MonApp -s setup.exe -o C:\Paquets

Deux précautions dès cette étape :

Ne mettez dans le dossier source que le strict nécessaire. Tout son contenu est embarqué : un dossier de 4 Go produit un paquet de 4 Go, téléchargé sur chaque poste.
Le fichier d’installation doit être à la racine du dossier source, pas dans un sous-dossier.

Les commandes d’installation et de désinstallation

Intune exécute ces commandes dans le contexte SYSTEM, sans interface graphique et sans utilisateur connecté. Toute installation attendant un clic échouera silencieusement — d’où l’importance des commutateurs silencieux.

Type	Installation	Désinstallation
MSI	`msiexec /i "app.msi" /qn /norestart`	`msiexec /x {GUID} /qn /norestart`
EXE (InstallShield)	`setup.exe /s /v"/qn"`	Variable selon l’éditeur
EXE (NSIS)	`setup.exe /S`	`uninstall.exe /S`

Le commutateur silencieux dépend entièrement de l’éditeur. En cas de doute, testez d’abord en local dans une invite de commandes ouverte en tant qu’administrateur : si l’installation affiche la moindre fenêtre, elle échouera via Intune.

Les règles de détection : la vraie source des problèmes

C’est ici que se joue la réussite ou l’échec. Après installation, Intune vérifie la présence de l’application au moyen d’une règle de détection. Si cette règle ne trouve rien, Intune considère que l’installation a échoué — et recommence. Indéfiniment.

Une boucle de réinstallation est toujours un problème de détection, jamais un problème d’installation. Gardez cette phrase en tête, elle vous fera gagner des heures.

Détection par fichier ou dossier

La plus simple. On vérifie l’existence d’un fichier, ou mieux, sa version.

Piège classique : sur un poste 64 bits, une application 32 bits s’installe dans C:\Program Files (x86), pas dans C:\Program Files. Vérifiez le chemin réel après une installation de test.

Détection par registre

Adaptée aux applications sans arborescence prévisible. On cible une clé et, idéalement, une valeur de version.

Détection par code MSI

Réservée aux vrais MSI. Intune compare le code produit. Fiable, mais inopérante si l’éditeur change ce code à chaque version mineure.

Détection par script

La plus souple pour les cas complexes. La règle est simple et souvent mal comprise : le script doit écrire quelque chose sur la sortie standard et se terminer avec le code 0 pour signaler la présence de l’application. Un script qui retourne 0 sans rien écrire est interprété comme « non détecté ».

$chemin = "C:\Program Files\MonApp\app.exe"
if (Test-Path $chemin) {
    Write-Output "Detecte"
    exit 0
}
exit 1

Contexte d’installation : système ou utilisateur

Choisissez Système dans la quasi-totalité des cas : l’application s’installe une fois pour la machine, avec les droits nécessaires.

Le contexte Utilisateur ne se justifie que pour les applications qui s’installent dans le profil de l’utilisateur. Attention : en contexte utilisateur, la règle de détection doit alors chercher dans le profil, et non dans les emplacements système.

Les dépendances et les règles de remplacement

Intune permet de déclarer qu’une application en requiert une autre — un moteur d’exécution, par exemple. Intune installe alors la dépendance en premier. Utile, mais à manier avec parcimonie : une chaîne de dépendances trop longue devient impossible à diagnostiquer.

Les règles de remplacement (supersedence) permettent de remplacer proprement une ancienne version, avec ou sans désinstallation préalable.

Diagnostiquer une installation qui échoue

Sur le poste concerné, le journal de l’extension de gestion Intune se trouve dans :

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

Ce fichier indique le téléchargement du paquet, la commande exécutée, le code de retour et le résultat de la détection. L’outil gratuit CMTrace en rend la lecture nettement plus confortable.

Les codes de retour les plus fréquents : 0 succès, 1603 échec générique d’installation MSI, 1618 une autre installation est déjà en cours, 3010 succès nécessitant un redémarrage.

Méthode de travail recommandée

Tester l’installation silencieuse en local, en SYSTEM, avant tout empaquetage.
Noter le chemin exact et la version du fichier installé.
Construire la règle de détection à partir de ces éléments constatés, jamais supposés.
Déployer sur un poste pilote unique.
Vérifier le journal, puis seulement ensuite généraliser.

En résumé

La difficulté du déploiement Win32 ne réside pas dans l’empaquetage mais dans la détection. Testez toujours l’installation silencieuse en amont, relevez le chemin réel du fichier installé, et construisez votre règle sur ce constat. Pour replacer cette brique dans l’ensemble, voyez notre guide complet de Microsoft Intune.

Déployer une application Win32 avec Intune : le guide complet