C’est un petit prompt Windows que tous les admins Intune connaissent.
L’utilisateur ouvre Teams, Outlook, Edge ou une application Microsoft 365, ajoute son compte professionnel, clique un peu vite, et Windows affiche :
Allow my organization to manage my device
En français :
Autoriser mon organisation à gérer mon appareil
Sur le papier, ça ressemble à une simple case de confort.
En réalité, cette case pouvait déclencher beaucoup plus qu’une simple connexion à l’application :
- enregistrement du poste dans Microsoft Entra ID ;
- tentative d’enrôlement MDM ;
- apparition du device dans Intune ;
- application potentielle de politiques ;
- gestion d’un appareil qui n’aurait parfois jamais dû être managé.
Dans un scénario BYOD, multi-tenant, consultant externe, ou simple ajout d’un second compte Teams, c’était franchement pénible.
Microsoft ajoute enfin un vrai contrôle côté Intune.
Le problème : un prompt trop facile à valider
Pendant longtemps, l’ajout d’un compte professionnel ou scolaire dans Windows mélangeait plusieurs notions.
L’utilisateur voulait souvent uniquement :
- se connecter à Teams ;
- ouvrir Outlook ;
- synchroniser OneDrive ;
- accéder à Edge avec son compte professionnel ;
- utiliser une application Microsoft 365.
Mais Windows pouvait aussi lancer un flux plus large :
- Workplace Join ;
- enregistrement Entra ID ;
- tentative d’auto-enrollment MDM ;
- enrôlement Intune si l’utilisateur était dans le scope MDM.
C’est là que les ennuis commencent.
Un utilisateur ne fait pas forcément la différence entre :
- se connecter à une application ;
- enregistrer le device dans Entra ID ;
- enrôler le device dans Intune ;
- laisser l’organisation gérer le poste.
Et dans la vraie vie, il clique.
Résultat :
- des appareils personnels apparaissent dans Intune ;
- des devices non prévus deviennent managés ;
- des politiques peuvent s’appliquer au mauvais poste ;
- des licences peuvent être consommées inutilement ;
- les admins doivent nettoyer des objets Entra / Intune qui n’auraient jamais dû exister.
La nouveauté : désactiver l’enrôlement MDM pendant l’ajout de compte
La nouvelle option s’appelle :
Disable MDM enrollment when adding a work or school account on Windows
Elle se configure dans la partie Automatic enrollment d’Intune.
L’idée est simple :
- garder l’auto-enrollment MDM disponible ;
- éviter qu’un simple ajout de compte dans Teams, Edge ou une application Microsoft déclenche automatiquement l’enrôlement Intune ;
- rendre l’enrôlement MDM plus volontaire et mieux maîtrisé.
Ce paramètre s’applique notamment aux utilisateurs inclus dans le scope MDM Some ou All, sur des devices Entra registered / workplace joined, lorsque le compte professionnel est ajouté pour la première fois via Microsoft Edge ou une application native comme Teams.
C’est exactement le cas qui posait problème.
L’utilisateur peut ajouter son compte.
Le device peut être enregistré si nécessaire.
Mais l’étape MDM n’est plus automatiquement proposée dans ce flux.
Ce que ça change concrètement
Avant, si l’utilisateur était dans le scope d’auto-enrollment MDM, l’ajout d’un compte pouvait aller trop loin.
Maintenant, avec ce paramètre activé :
- le compte professionnel peut être ajouté ;
- le device peut rester dans un mode plus léger ;
- le flux MDM n’est pas déclenché automatiquement ;
- l’utilisateur ne voit plus ce prompt dans les scénarios concernés ;
- l’organisation limite les enrôlements accidentels.
L’intérêt est là : on ne casse pas Intune.
On évite simplement qu’un enrôlement complet soit proposé au mauvais moment.
C’est particulièrement utile pour les environnements où le MDM user scope reste sur All, mais où l’on veut éviter les enrôlements non maîtrisés pendant les connexions applicatives.
Attention : ce n’est pas un blocage global de l’enrôlement
C’est le point à ne pas rater.
Cette option ne désactive pas Intune.
- Elle ne bloque pas tous les chemins d’enrôlement.
- Elle ne remplace pas les enrollment restrictions.
- Elle ne définit pas toute seule votre stratégie BYOD.
- Elle ne s’applique pas non plus à tous les scénarios d’ajout de compte.
Par exemple, si l’utilisateur ajoute son compte via :
Settings > Accounts > Access work or school
le comportement peut être différent.
Donc le message est clair :
- ce paramètre réduit les enrôlements accidentels lors du sign-in applicatif ;
- il ne remplace pas une stratégie complète d’enrôlement Windows ;
- il doit être combiné avec les autres contrôles Intune et Entra.
Ce qui se passe techniquement
Le prompt n’est pas simplement une fenêtre Windows locale.
Il fait partie d’un flux d’authentification entre :
- Windows ;
- le broker d’authentification ;
- Microsoft Entra ID ;
- les paramètres d’enrôlement MDM ;
- Intune.
Quand l’enrôlement MDM est possible et applicable, Entra ID retourne les informations nécessaires au flux Windows.
Windows peut alors afficher le prompt :
Allow my organization to manage my device
Quand la nouvelle option est activée, le flux concerné ne reçoit plus les informations permettant de déclencher l’enrôlement MDM dans ce scénario.
Donc le prompt n’est pas seulement masqué.
Le flux MDM n’est pas lancé.
Et c’est toute la différence.
Cacher une interface sans changer le comportement aurait été dangereux. Là, Microsoft agit plus haut dans le flux.
Cas d’usage typiques
BYOD Windows
C’est le cas le plus évident.
Vous voulez permettre à un utilisateur de se connecter à :
- Teams ;
- Outlook ;
- OneDrive ;
- Edge ;
- Microsoft 365 Apps.
Mais vous ne voulez pas que son poste personnel devienne automatiquement un device Intune complet.
Dans ce cas, cette option va dans le bon sens.
Elle permet de garder une approche plus propre :
- MAM si possible ;
- Conditional Access ;
- protection des applications ;
- contrôle des données ;
- pas forcément MDM complet sur le poste personnel.
Multi-tenant
Autre cas fréquent : un utilisateur ajoute un compte Teams d’un autre tenant.
Avant, selon la configuration de l’autre tenant, le device pouvait se retrouver embarqué dans un flux d’enrôlement non souhaité.
Résultat possible :
- objets Entra inattendus ;
- devices fantômes ;
- confusion entre tenants ;
- tickets support inutiles ;
- nettoyage administratif pénible.
Cette option réduit ce risque.
Consultants et prestataires
Un consultant utilise son propre PC ou un PC géré par une autre organisation.
Il a besoin d’accéder à :
- Teams ;
- SharePoint ;
- Outlook ;
- une application Microsoft 365.
Mais il n’a pas vocation à faire gérer son poste par votre tenant.
Avec ce paramètre, on réduit fortement le risque d’enrôlement involontaire.
Stratégie MAM sans MDM
Si votre objectif est de protéger les données dans les applications sans gérer tout le device, cette option devient quasiment logique.
Elle permet de mieux séparer :
- l’accès applicatif ;
- la protection des données ;
- la gestion complète du poste.
C’est une séparation beaucoup plus saine.
Ce que je configurerais
Dans beaucoup d’environnements, je partirais sur cette logique :
- MDM user scope : All ou Some
- Disable MDM enrollment when adding a work or school account on Windows : Yes
- Enrollment restrictions : bloquer les devices personnels si nécessaire
- Conditional Access : exiger MDM uniquement pour les scénarios qui le justifient
- MAM : utilisé pour les scénarios BYOD applicatifs
L’idée est simple :
- un device corporate passe par un processus maîtrisé ;
- un device personnel ne devient pas managé par accident ;
- l’utilisateur peut se connecter à ses applications ;
- l’IT garde le contrôle sur les vrais scénarios d’enrôlement.
Pour les devices corporate, les chemins propres restent :
- Autopilot ;
- GPO auto-enrollment ;
- Company Portal ;
- provisioning contrôlé ;
- enrollment via processus IT.
Pour les devices personnels, il faut éviter le “clic trop rapide” qui transforme un simple accès applicatif en gestion complète du poste.
Ce que ça ne règle pas
Il ne faut pas tout attendre de cette option.
Elle ne corrige pas :
- les devices déjà enrôlés par erreur ;
- les objets Entra ID existants ;
- les mauvaises enrollment restrictions ;
- les stratégies BYOD mal définies ;
- les politiques Conditional Access trop larges ;
- les chemins d’enrôlement volontaire.
Elle ne décide pas non plus à votre place :
- ce qui est corporate ;
- ce qui est personnel ;
- ce qui est autorisé ;
- ce qui doit être bloqué ;
- ce qui relève du MDM ou du MAM.
C’est une brique de contrôle supplémentaire.
Pas une stratégie complète.
Ma lecture
Cette évolution est petite, mais elle corrige un vrai irritant.
Pendant trop longtemps, Windows mélangeait trop facilement :
- connexion applicative ;
- registration Entra ;
- enrollment Intune ;
- gestion complète du device.
Pour un admin, la différence est évidente.
Pour un utilisateur, absolument pas.
Et quand une case apparaît au milieu d’un flux de connexion, il clique.
Avec cette nouvelle option, Microsoft remet un peu d’ordre.
L’ajout d’un compte professionnel ne doit pas automatiquement vouloir dire :
mon organisation gère mon poste.
C’est particulièrement important aujourd’hui, parce que les environnements sont plus complexes :
- plusieurs tenants ;
- plusieurs comptes ;
- postes personnels ;
- postes corporate ;
- accès partenaires ;
- consultants ;
- applications cloud ;
- Conditional Access ;
- MAM ;
- MDM.
Dans ce contexte, il faut éviter que l’enrôlement complet soit déclenché par accident.
Conclusion
Le nouveau paramètre Disable MDM enrollment when adding a work or school account on Windows est une bonne évolution Intune.
Il permet de réduire les enrôlements MDM accidentels lors de l’ajout d’un compte professionnel dans Edge, Teams ou d’autres applications natives Windows.
Ce n’est pas un bouton magique.
Mais c’est une vraie brique de gouvernance pour les scénarios :
- BYOD ;
- MAM-only ;
- multi-tenant ;
- consultants ;
- prestataires ;
- accès applicatif sans gestion complète du poste.
Mon conseil : testez-le sur un tenant de validation, vérifiez vos scénarios réels, puis intégrez-le dans votre stratégie d’enrôlement Windows. Parce qu’un utilisateur qui veut juste ouvrir Teams ne devrait pas, par accident, donner à une organisation la gestion complète de son poste.