Dans l’idéal du « Modern Workplace », chaque application serait une application web ou un package cloud-native. Cependant, la réalité des entreprises implique souvent des logiciels legacy qui s’appuient sur des fichiers de configuration locaux stockés au cœur du profil utilisateur (%AppData%).
Le défi s’intensifie lorsque ces fichiers ne sont pas de simples préférences cosmétiques, mais des éléments critiques : licences logicielles, certificats de sécurité ou paramètres de connexion sensibles.
Cet article explore les compromis architecturaux entre les méthodes de déploiement traditionnelles et modernes, en mettant l’accent sur les raisons pour lesquelles l’approche « Intune Win32 » est souvent plus complexe qu’il n’y paraît.
1. L’approche legacy : GPO et scripts de connexion
Pendant des décennies, le script de connexion piloté par GPO a été la référence pour la personnalisation des profils.
Mécanisme : un script PowerShell ou Batch s’exécute à la connexion de l’utilisateur et copie des fichiers depuis un partage SMB on-premises.
Avantages : synchronisation parfaite ; le script ne s’exécute que lorsque le profil utilisateur est monté et prêt. Il gère nativement les appareils multi-utilisateurs.
Inconvénients : nécessite une visibilité directe sur un contrôleur de domaine (dépendance VPN/on-premises). Il manque d’idempotence native — il écrase souvent les fichiers à chaque exécution, générant une surcharge réseau inutile.
2. La difficulté hybride : applications Win32 Intune (contexte utilisateur)
Lors de la migration vers Intune, de nombreux architectes tentent d’« empaqueter » la configuration du profil dans une application Win32 (.intunewin) configurée en contexte utilisateur. Logique sur le papier, cette approche se heurte souvent à un mur technique lors de la phase de détection.
Le piège de la règle de détection
Le principal obstacle est l’agent Intune Management Extension (IME). Bien que le script d’installation puisse s’exécuter en tant qu’utilisateur, la règle de détection est gérée par un agent au niveau système.
La crise d’identité
Même en contexte utilisateur, l’IME évalue souvent les règles de détection avec le compte SYSTEM. Si votre règle vérifie HKEY_CURRENT_USER, elle peut consulter le registre du profil System au lieu de celui de l’utilisateur connecté.
La condition de course du profil
Microsoft documente que la détection des applications Win32 s’effectue périodiquement. Si l’IME déclenche une vérification pendant les quelques secondes où un utilisateur se connecte, le dossier %AppData% ou la ruche de registre de l’utilisateur peut être verrouillée ou pas encore montée. Cela produit des « faux négatifs », où Intune signale un échec d’installation simplement parce qu’il n’a pas pu « voir » l’environnement de l’utilisateur à cet instant précis.
La détection « collante » multi-utilisateur
Sur les appareils partagés, si votre règle de détection pointe vers un emplacement global (comme C:\ProgramData) pour éviter les problèmes de profil, Intune marquera l’application comme « Installée » pour tout l’appareil après le premier utilisateur. Le second utilisateur qui se connecte ne déclenchera jamais le script de configuration, car Intune considère que le « prérequis » est déjà satisfait.
Note de l’architecte : tenter d’utiliser %AppData% dans une règle de détection Intune standard est l’une des causes principales du statut redouté « Install Pending » ou « Fatal Error » dans le portail MEM.
L’approche moderne : remédiations et stockage cloud
Il s’agit de l’architecture la plus granulaire et « cloud-native », utilisant les remédiations Intune.
Mécanisme : un script de détection s’exécute périodiquement pour vérifier le profil de l’utilisateur. Si la configuration sensible est absente ou obsolète, un script de remédiation télécharge les ressources depuis une source cloud sécurisée (par exemple, Azure Blob Storage).
Avantages : * Auto-réparation : si un utilisateur supprime sa configuration, elle est restaurée automatiquement en quelques heures.
Véritable multi-utilisateur : les scripts s’exécutent indépendamment pour chaque profil utilisateur sur la machine.
Inconvénients : * Maturité de l’infrastructure : les remédiations ne peuvent pas « transporter » de fichiers. Vous devez héberger vos certificats ou licences sensibles dans un coffre externe sécurisé ou un stockage cloud avec des jetons SAS.
Complexité : nécessite des compétences avancées en PowerShell et une gestion Azure.
Matrice de comparaison des architectures
| Fonctionnalité | GPO Logon | Intune Win32 (User) | Intune Remediations |
|---|---|---|---|
| Stabilité du profil | Excellente | Instable (condition de course) | Excellente |
| Prise en charge multi-utilisateur | Native | Faible (détection globale) | Native |
| Capacité hors ligne | Non | Oui | Oui |
| Sécurité des données | Moyenne (SMB) | Élevée (package chiffré) | Très élevée (coffre cloud) |
| Gestion d’état | Aucune (événementielle) | Basique (règle de détection) | Continue (auto-réparation) |
Tableau 1 — Matrice de comparaison
Conclusion : une question de compromis
L’architecture consiste rarement à trouver l’outil « meilleur », mais le bon compromis pour vos contraintes spécifiques.
Si votre environnement est strictement on-premises avec des postes de travail partagés, les GPO offrent toujours une stabilité inégalée pour le timing des profils. Si vous êtes entièrement en télétravail et pouvez absorber la surcharge Azure, les remédiations offrent l’expérience « moderne » la plus résiliente.
L’approche par application Win32 reste un compromis viable, à condition d’accepter ses limites : c’est un outil de déploiement « one-shot » plutôt qu’un moteur de configuration continue. Lorsqu’il s’agit de données sensibles au niveau utilisateur, l’essentiel est de s’assurer que votre règle de détection est aussi robuste que votre script d’installation — ce qui exige souvent une logique « aveugle » tenant compte de l’écart entre l’agent System et la réalité de l’utilisateur.