Microsoft Intune : Politiques de Conformité et : Guide

Les Microsoft Intune politiques conformité appareils sont devenues le socle incontournable de toute stratégie Zero Trust en 2026. Je le vois sur le terrain depuis plusieurs années : les organisations qui ont déployé Intune avec des politiques de conformité bien configurées résistent infiniment mieux aux attaques par vol de credentials que celles qui n'ont que du MFA sur leurs comptes. La raison est simple — même si un attaquant obtient les identifiants d'un utilisateur, son appareil "inconnu" échoue à la vérification de conformité Intune, et la politique Conditional Access bloque l'accès aux données M365. Ce guide couvre l'architecture complète d'Intune : politiques de conformité Windows 11, App Protection Policies pour les appareils BYOD, l'intégration avec Conditional Access, Windows Autopilot pour le déploiement zero-touch, et les rapports de conformité via PowerShell. Pas de théorie abstraite — des configurations concrètes, des blocs JSON et des scripts testés en production sur des tenants M365 d'entreprises françaises.

Architecture Microsoft Intune — comprendre les types de politiques

Microsoft Intune (désormais intégré dans Microsoft Intune Suite et administré depuis intune.microsoft.com) propose quatre types de politiques fondamentaux. Comprendre la différence entre eux est essentiel avant de déployer quoi que ce soit — j'ai vu trop de déploiements ratés parce que les administrateurs confondaient Configuration Profiles et Compliance Policies.

1. Compliance Policies (Politiques de conformité)

Définissent les critères qu'un appareil doit respecter pour être considéré "compliant" : version Windows minimum, BitLocker activé, Secure Boot, antivirus à jour, mot de passe requis. Un appareil non-conforme reçoit le statut "NonCompliant" dans Intune. Ce statut est ensuite lu par Conditional Access pour bloquer ou autoriser l'accès aux ressources M365. Les Compliance Policies sont le pont entre Intune et Conditional Access.

2. Configuration Profiles (Profils de configuration)

Configurent les paramètres des appareils : restrictions device (Bluetooth, USB, caméra), paramètres Wi-Fi et VPN, certificats SCEP, Administrative Templates (équivalent GPO), Endpoint Protection (Windows Defender, ASR rules, Firewall). Ces profils n'ont pas d'impact direct sur le statut de conformité — ils configurent l'appareil selon les standards de l'organisation.

3. App Protection Policies (MAM — Mobile Application Management)

Protègent les données M365 au niveau de l'application, sans nécessiter l'enrôlement MDM complet de l'appareil. Idéal pour les appareils BYOD (Bring Your Own Device) : l'employé garde son téléphone personnel, mais l'accès aux données Outlook, Teams et OneDrive est conteneurisé avec des restrictions (pas de copier-coller vers des apps personnelles, effacement des données pro à distance).

4. Windows Autopilot

Scénario de déploiement zero-touch : un nouveau PC arrive de l'usine directement chez l'utilisateur final. L'utilisateur le démarre, se connecte avec ses credentials M365, et Autopilot configure automatiquement Windows 11, enrôle dans Intune, applique les profils et installe les applications — sans aucune intervention IT sur site.

La relation entre ces composants et Entra ID est au coeur de la stratégie Zero Trust. Consultez notre guide Zero Trust Microsoft 365 implementation pour l'architecture complète.

Politique de conformité Windows 11 — configuration recommandée

Voici la politique de conformité Windows 11 que je déploie en priorité sur les tenants M365 de mes clients. Elle couvre les paramètres de sécurité fondamentaux sans être trop restrictive pour les appareils légitimes. Le fichier JSON ci-dessous correspond à l'export d'une politique Intune via l'API Microsoft Graph :

# Créer une politique de conformité Windows 11 via PowerShell Graph
# La configuration JSON représente les paramètres recommandés
$compliancePolicyBody = @{
    "@odata.type" = "#microsoft.graph.windows10CompliancePolicy"
    displayName = "Compliance-Windows11-Secure-AYI"
    description = "Politique de conformité Windows 11 - Niveau sécurisé"

    # Version OS minimum : Windows 11 22H2
    osMinimumVersion = "10.0.22621"
    osMaximumVersion = $null  # Pas de version maximum bloquante

    # Chiffrement et démarrage sécurisé
    bitLockerEnabled = $true        # BitLocker OBLIGATOIRE
    secureBootEnabled = $true       # Secure Boot OBLIGATOIRE
    codeIntegrityEnabled = $true    # Code Integrity (HVCI)
    storageRequireEncryption = $true

    # Authentification locale
    passwordRequired = $true
    passwordMinimumLength = 10
    passwordRequiredType = "alphanumeric"
    passwordMinutesOfInactivityBeforeLock = 15
    passwordExpirationDays = 90

    # Microsoft Defender
    defenderEnabled = $true
    defenderVersion = "4.18"        # Version minimum Defender
    signatureOutOfDate = $false     # Signatures à jour requises
    rtpEnabled = $true              # Protection temps réel active
    antivirusRequired = $true
    antispywareRequired = $true

    # Firewall et TPM
    firewallEnabled = $true
    tpmRequired = $true             # TPM 2.0 requis (standard W11)

    # Actions pour non-conformité
    scheduledActionsForRule = @(
        @{
            ruleName = "PasswordRequired"
            scheduledActionConfigurations = @(
                @{ actionType = "block"; gracePeriodHours = 0 },
                @{ actionType = "notification"; gracePeriodHours = 0; notificationTemplateId = "" }
            )
        }
    )
} | ConvertTo-Json -Depth 10

# Déployer via Microsoft Graph API
Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"
$policy = Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicies" `
    -Body $compliancePolicyBody -ContentType "application/json"
Write-Host "Politique créée : $($policy.id)"

Points importants sur le déploiement : affectez d'abord la politique à un groupe pilote (20-30 appareils représentatifs), vérifiez les rapports de conformité après 24-48h, puis déployez progressivement. Définissez une période de grâce de 7 jours pour que les utilisateurs puissent mettre leurs appareils en conformité avant d'être bloqués par Conditional Access.

Conditional Access basé sur la conformité — le coeur du Zero Trust

La politique de conformité Intune n'a de valeur que si elle est couplée à une politique Conditional Access qui bloque les appareils non-conformes. C'est l'intégration Intune/Entra ID qui donne toute sa puissance au modèle Zero Trust : l'identité (MFA) + l'appareil (conformité) = l'accès.

La politique Conditional Access à créer :

• Nom : "CA-Require-Compliant-Device-M365"
• Utilisateurs : All users (avec exclusion des comptes break-glass)
• Applications cibles : Office 365 (ou sélection précise : Exchange, SharePoint, Teams)
• Conditions : Device platforms = Windows, iOS, Android, macOS
• Contrôle d'accès : Require device to be marked as compliant
• Session : Sign-in frequency = 7 days (évite les reconnexions trop fréquentes)

Pour les appareils non-enrollés (contractuels, prestataires), proposez une alternative : MFA renforcé + accès limité à une version web sans synchronisation OneDrive. Cette approche est documentée dans notre article sur la sécurisation des accès M365 avec MFA.

# Créer la politique CA "Require Compliant Device" via PowerShell
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$caPolicy = @{
    displayName = "CA-Require-Compliant-Device-M365"
    state = "enabled"  # "enabledForReportingButNotEnforced" pour tester d'abord
    conditions = @{
        users = @{
            includeUsers = @("All")
            excludeGroups = @("ID-DU-GROUPE-BREAK-GLASS")
        }
        applications = @{
            includeApplications = @("Office365")
        }
        platforms = @{
            includePlatforms = @("windows","iOS","android","macOS")
        }
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("mfa", "compliantDevice")
    }
}

$newPolicy = New-MgIdentityConditionalAccessPolicy -BodyParameter $caPolicy
Write-Host "Politique CA créée : $($newPolicy.Id)"

Un point d'attention critique : avant d'activer cette politique en mode "enabled", passez d'abord par "Report-only" pendant 7 à 14 jours. Cela vous permet de voir quels appareils seraient bloqués sans impacter la production. Le rapport est disponible dans Entra ID > Sign-in logs avec le filtre "Report-only".

Configuration Profiles Windows 11 — durcissement endpoint

Au-delà des politiques de conformité, les Configuration Profiles configurent les paramètres de sécurité des appareils Windows 11 déployés via Intune. Ces profils remplacent les GPO Active Directory traditionnelles pour les appareils cloud-managed.

Endpoint Protection Profile — les paramètres Windows Defender à configurer :

• Attack Surface Reduction (ASR) rules : activer les 15 règles recommandées par Microsoft (Block Office apps from creating child processes, Block JavaScript from launching executable content, etc.)
• Windows Defender Firewall : activer en mode bloc par défaut pour les connexions entrantes, autoriser les connexions sortantes
• Microsoft Defender Antivirus : Real-time protection, Cloud Protection (niveau High), Automatic sample submission activé
• Credential Guard : activer pour isoler les credentials LSASS
• Device Guard (HVCI) : activer Hypervisor-Protected Code Integrity

Device Restrictions Profile — restrictions d'usage :

• Bluetooth : autoriser uniquement les périphériques Bluetooth approuvés (casques, souris), bloquer le transfert de fichiers BT
• USB : restreindre les périphériques USB de stockage non-approuvés (risque exfiltration physique)
• Caméra : contrôler selon le contexte (désactiver dans les environnements à haute confidentialité)
• Windows Hello for Business : activer l'authentification biométrique/PIN en remplacement du mot de passe

Administrative Templates : Intune supporte nativement les ADMX templates, permettant de pousser exactement les mêmes GPO que vous appliqueriez via Active Directory, mais pour des appareils Azure AD Joined. Cela facilite la migration cloud des organisations avec un héritage GPO important.

App Protection Policies (MAM) — protéger les données BYOD sans MDM

Le Mobile Application Management (MAM) sans MDM est la solution pour les appareils personnels des employés (BYOD). L'idée est simple : on ne contrôle pas l'appareil (pas d'enrôlement Intune, pas d'accès à la localisation ou aux photos personnelles), mais on contrôle les applications M365 installées sur cet appareil et les données qu'elles manipulent.

Concrètement, une App Protection Policy appliquée à Outlook Mobile, Teams et OneDrive sur un iPhone personnel :

• Exige un PIN à 6 chiffres pour ouvrir l'application (distinct du PIN téléphone)
• Bloque le copier-coller depuis Outlook vers une application non-managée (WhatsApp, Notes personnelles)
• Bloque les captures d'écran dans les apps managées
• Chiffre les données stockées localement par les apps M365
• Permet l'effacement sélectif des données M365 uniquement (sans wiper le téléphone perso) si l'employé quitte l'entreprise

# Vérifier les App Protection Policies déployées
Connect-MgGraph -Scopes "DeviceManagementApps.Read.All"

# Lister toutes les App Protection Policies (iOS + Android)
$iosPolicies = Get-MgDeviceAppMgtiOSManagedAppProtection -All
$androidPolicies = Get-MgDeviceAppMgtAndroidManagedAppProtection -All

Write-Host "App Protection Policies iOS : $($iosPolicies.Count)"
$iosPolicies | Select-Object DisplayName, Description, PinRequired, PinMinimumLength,
    AllowedClipboardSharingLevel, DataBackupBlocked | Format-Table

Write-Host "App Protection Policies Android : $($androidPolicies.Count)"
$androidPolicies | Select-Object DisplayName, PinRequired, AllowedClipboardSharingLevel,
    ScreenCaptureBlocked | Format-Table

# Vérifier le statut MAM par utilisateur
$mamStatus = Get-MgDeviceAppMgtManagedAppRegistration -All
$mamStatus | Select-Object @{N='Platform';E={$_.DeviceType}},
    @{N='User';E={$_.UserId}}, ApplicationVersion, CreatedDateTime |
    Group-Object Platform | Select-Object Name, Count

Windows Autopilot — déploiement zero-touch en 45 minutes

Windows Autopilot est la fonctionnalité qui m'a le plus convaincu de la maturité de la stack M365 pour les entreprises en croissance. Le scénario traditionnel : un nouveau PC arrive au bureau IT, un technicien passe 2-3 heures à installer Windows, les drivers, les applications, rejoindre le domaine, configurer les GPO... Avec Autopilot, ce scénario disparaît complètement.

Le nouveau PC est livré directement à l'utilisateur final. Au premier démarrage :

1. Windows 11 OEM se connecte à Internet via DHCP
2. Le hash matériel du PC est reconnu par Autopilot (enregistré par le fabricant ou importé en CSV)
3. Le profil Autopilot s'applique : renommage automatique, compte admin local supprimé, personnalisation de l'écran OOBE
4. L'utilisateur entre ses credentials M365 — Entra ID Joined automatiquement
5. Intune reçoit l'enrôlement, pousse les Configuration Profiles et les applications requises
6. En 30-45 minutes, le PC est prêt à l'emploi avec toutes les politiques appliquées

# Import des devices Autopilot depuis un CSV (fourni par le fabricant)
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"

# Format du CSV : Device Serial Number, Windows Product ID, Hardware Hash
# Importer le CSV Autopilot
$csvPath = "C:utopilot_devices.csv"
$autopilotDevices = Import-AutopilotCSV -CsvFile $csvPath

# Vérifier les devices Autopilot enregistrés
$registeredDevices = Get-AutopilotDevice -All
Write-Host "Devices Autopilot enregistrés : $($registeredDevices.Count)"
$registeredDevices | Select-Object SerialNumber, Model, GroupTag, EnrollmentState,
    LastContactedDateTime | Format-Table

# Créer un profil Autopilot (Self-Deploying ou User-Driven)
$autopilotProfile = @{
    "@odata.type" = "#microsoft.graph.azureADWindowsAutopilotDeploymentProfile"
    displayName = "Autopilot-UserDriven-Standard"
    description = "Déploiement utilisateur standard"
    language = "fr-FR"
    deviceNameTemplate = "AYI-%SERIAL%"  # Nommage automatique
    enableWhiteGlove = $false
    outOfBoxExperienceSettings = @{
        hidePrivacySettings = $true
        hideEULA = $true
        skipKeyboardSelectionPage = $true
        deviceUsageType = "singleUser"
    }
}

Pour les organisations qui déploient 20+ appareils par mois, le ROI d'Autopilot est immédiat : économie de 2-3h technicien par machine, déploiement possible directement depuis le fournisseur sans passage par l'IT, et standardisation garantie de la configuration.

SCEP Certificates — authentification réseau via certificats

Pour les organisations avec un réseau Wi-Fi d'entreprise sécurisé (802.1X), Intune peut déployer des certificats clients via le protocole SCEP (Simple Certificate Enrollment Protocol). Chaque appareil enrollé Intune reçoit automatiquement un certificat unique qui lui permet de s'authentifier sur le réseau Wi-Fi d'entreprise — sans mot de passe Wi-Fi partageable, sans risque de credential phishing.

L'architecture requiert un serveur NDES (Network Device Enrollment Service) on-premise ou le connecteur Intune Certificate Connector pour les PKI internes. Une alternative cloud-native : utiliser les certificats Entra ID SCEP directement si votre PKI est hébergée dans Azure.

Cette approche renforce considérablement la sécurité réseau en garantissant que seuls les appareils enrollés Intune (et donc conformes) peuvent accéder au réseau d'entreprise.

Rapports de conformité Intune — monitoring et tableau de bord

Le monitoring de la conformité Intune est disponible dans le portail intune.microsoft.com, mais l'API Microsoft Graph permet d'automatiser l'export et la génération de rapports exécutifs. Voici le script que j'utilise pour produire le tableau de bord de conformité mensuel :

# Rapport de conformité Intune — export complet via Microsoft Graph
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

# Récupérer tous les appareils managés
$allDevices = Get-MgDeviceManagementManagedDevice -All -Property `
    DeviceName,ComplianceState,OperatingSystem,OSVersion,LastSyncDateTime,
    UserPrincipalName,SerialNumber,Model,Manufacturer,JoinType,EnrollmentType

# Rapport global par statut de conformité
$complianceStats = $allDevices | Group-Object ComplianceState |
    Select-Object Name, Count, @{N='Percentage';E={[math]::Round(($_.Count/$allDevices.Count)*100,1)}}
Write-Host "`n=== STATUT DE CONFORMITÉ GLOBAL ===" -ForegroundColor Cyan
$complianceStats | Format-Table

# Appareils non-conformes : détails pour remédiation
$nonCompliant = $allDevices | Where-Object {$_.ComplianceState -ne "compliant"}
Write-Host "`n=== APPAREILS NON-CONFORMES ($($nonCompliant.Count)) ===" -ForegroundColor Red
$nonCompliant | Select-Object DeviceName, UserPrincipalName, OperatingSystem,
    OSVersion, LastSyncDateTime, ComplianceState |
    Sort-Object LastSyncDateTime | Format-Table

# Export CSV pour tableau de bord
$reportDate = Get-Date -Format "yyyyMMdd"
$allDevices | Select-Object DeviceName, UserPrincipalName, ComplianceState,
    OperatingSystem, OSVersion, LastSyncDateTime, Model, SerialNumber, JoinType |
    Export-Csv "intune_compliance_$reportDate.csv" -NoTypeInformation

# KPI pour rapport exécutif
$compliantCount = ($allDevices | Where-Object {$_.ComplianceState -eq "compliant"}).Count
$complianceRate = [math]::Round(($compliantCount / $allDevices.Count) * 100, 1)
Write-Host "`n✓ Taux de conformité global : $complianceRate% ($compliantCount/$($allDevices.Count) appareils)" -ForegroundColor $(if($complianceRate -ge 95){'Green'}elseif($complianceRate -ge 80){'Yellow'}else{'Red'})

Pour une intégration avec votre monitoring via l'API Microsoft Graph, ces données peuvent alimenter un dashboard Power BI ou être envoyées dans Sentinel pour des alertes automatiques quand le taux de conformité descend sous un seuil défini.

Comment créer une politique de conformité Windows 11 dans Intune ?

Procédure pas-à-pas dans le portail Intune (intune.microsoft.com) :

1. Accéder au portail : intune.microsoft.com > Devices > Compliance policies > Create policy
2. Sélectionner la plateforme : Windows 10 and later (couvre W10 et W11)
3. Paramètres de conformité : Device Health (Secure Boot, BitLocker, Code Integrity), Device Properties (OS min/max version), System Security (password, firewall, antivirus, Defender)
4. Actions for noncompliance : définir les actions (mark as noncompliant immédiatement, envoyer un email à J+1, bloquer l'accès à J+7)
5. Affectation : cibler un groupe Entra ID (All Devices ou groupe pilote)
6. Review + Create

Après création, vérifiez dans Devices > Monitor > Device compliance que les appareils commencent à remonter leur statut (délai de 8-24h selon la fréquence de check-in Intune). Les appareils qui n'ont pas contacté Intune depuis >30 jours sont automatiquement marqués "Not evaluated".

Les paramètres les plus souvent problématiques lors du premier déploiement : BitLocker (les machines sans TPM 2.0 ne peuvent pas l'activer), Secure Boot (désactivé sur certaines configs dual-boot Linux/Windows), et la version OS minimum (si vous avez encore des Windows 10 21H2 en production).

Comment bloquer l'accès aux non-conformes via Conditional Access ?

La chaîne de valeur Intune → Conditional Access fonctionne ainsi : Intune évalue la conformité et publie le statut dans Entra ID → Conditional Access lit ce statut au moment de chaque connexion → si non-conforme, accès refusé ou redirigé vers une page d'explication avec les actions correctives.

Recommandations pour un déploiement sans incident :

• Commencez en mode Report-only : 2 semaines d'observation avant d'activer le blocage
• Excluez les comptes de service : les comptes utilisés par des applications (connecteurs ERP, scripts d'automatisation) ne peuvent pas avoir de device compliance — excluez-les de la politique ou créez des exemptions
• Gérez les exceptions : contractuels, prestataires, direction — documentez chaque exception et révisez-les trimestriellement
• Page d'erreur personnalisée : configurez une Custom Blocked Page dans Entra ID qui explique à l'utilisateur pourquoi il est bloqué et comment mettre son appareil en conformité

Pour la stratégie complète de déploiement, consultez notre article sur l'audit sécurité Microsoft 365 guide complet et le référentiel NIST SP 800-124 Rev 2 — Guidelines for Managing the Security of Mobile Devices in the Enterprise.

Tableau — politiques Intune et référentiel NIST 800-124

Gestion des appareils non-Windows — iOS, Android, macOS

Intune est une solution cross-platform : Windows, macOS, iOS/iPadOS et Android sont tous supportés avec des niveaux de gestion variables. Pour les flottes mixtes que je rencontre souvent en PME :

macOS : Configuration profiles (profils .mobileconfig), conformité (FileVault, Gatekeeper, OS version), Declarative Device Management (DDM) pour macOS 13+. L'enrôlement se fait via le programme Apple Business Manager si vous achetez des Mac directement chez Apple (équivalent Autopilot pour le monde Apple).

iOS/iPadOS : Supervision via Apple Business Manager pour les appareils d'entreprise (contrôle total), ou MAM sans enrollment pour les BYOD. Les apps M365 (Outlook, Teams, OneDrive) supportent les App Protection Policies nativement.

Android : Android Enterprise (Work Profile pour BYOD, Fully Managed pour appareils d'entreprise, Dedicated devices pour les kiosques). Le Work Profile crée une partition séparée sur le téléphone : les apps professionnelles sont isolées des apps personnelles avec un badge distinctif.

Pour les appareils Linux (de plus en plus présents dans les équipes DevOps), Intune propose un agent en preview pour les distributions Ubuntu — la conformité est limitée mais en progression rapide. Consultez la documentation officielle Microsoft Intune pour les dernières fonctionnalités par plateforme et les recommandations CISA sur la gestion des endpoints pour les bonnes pratiques interagences.

Pour aller plus loin sur les logs Intune et la corrélation avec les événements M365, notre article sur l'audit avancé des journaux M365 couvre l'intégration Intune/Sentinel.

Questions fréquentes sur Microsoft Intune et les politiques de conformité

Quelle est la différence entre MDM et MAM dans Intune ?

MDM (Mobile Device Management) = gestion complète de l'appareil. L'appareil est enrôlé dans Intune, l'IT peut voir l'inventaire matériel, pousser des applications, configurer le Wi-Fi/VPN, effacer l'appareil à distance. Recommandé pour les appareils d'entreprise. MAM (Mobile Application Management) = gestion au niveau de l'application uniquement, sans enrôlement de l'appareil. L'IT contrôle les données dans les apps M365 (Outlook, Teams, OneDrive) mais n'a aucun accès au reste du téléphone. Recommandé pour les BYOD. On peut combiner les deux : MDM pour les appareils d'entreprise, MAM pour les BYOD, avec des politiques d'accès différenciées via Conditional Access.

Comment fonctionne Windows Autopilot avec Intune ?

Autopilot est le scénario de déploiement, Intune est la plateforme de gestion. Autopilot orchestre le provisionnement initial (OOBE, Entra ID Join automatique, renommage), puis Intune prend le relai pour pousser les Configuration Profiles, les politiques de conformité et les applications. Le device hash (identifiant matériel unique) est enregistré dans Autopilot par le fabricant (via le programme Microsoft Autopilot OEM) ou manuellement via un CSV PowerShell. Sans ce hash, Windows ne reconnaît pas le device au premier démarrage et n'applique pas le profil Autopilot.

Intune remplace-t-il SCCM/MECM complètement ?

Non, pas complètement — et Microsoft ne le recommande pas non plus. Pour les environnements avec des appareils on-premise uniquement, un legacy applicatif complexe (packages MSI anciens, sequences de tâches avancées) ou des déploiements OS via PXE/WDS, MECM (renommé Configuration Manager) reste nécessaire. Le modèle recommandé par Microsoft est le Co-Management : MECM gère les workloads on-premise (déploiement OS, application catalog), Intune gère les workloads cloud (conformité, Conditional Access, Modern Apps via Store). La migration progressive est contrôlée par des "workloads" que vous basculez de MECM vers Intune au fur et à mesure de votre maturité cloud.

Comment gérer les appareils non-Windows (iOS, Android) dans Intune ?

Pour les appareils d'entreprise iOS/Android : utiliser Apple Business Manager / Android Zero Touch Enrollment pour l'enrôlement automatique, puis Intune pour les Configuration Profiles et les politiques de conformité. Pour les BYOD : déployer uniquement des App Protection Policies (MAM) sur les apps M365. Depuis le portail intune.microsoft.com > Apps > App protection policies, créez deux politiques distinctes (iOS et Android) affectées aux utilisateurs. Chaque collaborateur installe Outlook, Teams et OneDrive depuis l'App Store/Play Store — les politiques MAM s'appliquent automatiquement à ces apps sans que l'appareil soit enrôlé.