Conformité mobile Intune pour iOS et Android

Une politique de conformité mobile définit ce qu'est un appareil « sain » avant qu'il n'accède à vos données. Sur iOS et Android, Intune évalue en continu des critères clés — jailbreak ou root, version d'OS, chiffrement, code d'accès — puis transmet le verdict à l'accès conditionnel, qui autorise ou bloque l'accès aux ressources Microsoft 365. C'est la brique qui relie l'état réel de l'appareil à une décision d'accès concrète, et donc le cœur d'une stratégie mobile alignée sur NIS2, ISO 27001 et RGPD.

Les critères essentiels

Une bonne politique reste simple mais couvre les risques majeurs. Chaque critère non respecté marque l'appareil comme non conforme et déclenche l'action définie. Mieux vaut quelques règles claires et appliquées qu'une longue liste jamais tenue.

Ce qu'il faut vérifier en priorité

Ces critères couvrent l'essentiel des scénarios de compromission d'un mobile, du jailbreak à l'absence de correctifs de sécurité.

• Bloquer les appareils jailbreakés (iOS) ou rootés (Android), signe d'intégrité compromise.
• Exiger une version d'OS minimale pour bénéficier des correctifs de sécurité.
• Imposer le chiffrement du stockage de l'appareil.
• Exiger un code d'accès ou une biométrie pour déverrouiller l'appareil.

Adapter les critères à iOS et Android

Les deux plateformes n'exposent pas exactement les mêmes signaux. Le chiffrement est natif et généralement actif sur iOS récent, tandis qu'Android demande une attention particulière selon les constructeurs. Définir une politique par plateforme permet de coller aux spécificités de chacune sans compromis.

Du verdict de conformité à l'accès conditionnel

La conformité seule n'empêche rien : elle produit un verdict, mais c'est l'accès conditionnel qui applique la décision. Un appareil non conforme se voit refuser l'accès à Exchange, Teams ou SharePoint jusqu'à sa remise en conformité. Sans ce couplage, la politique reste un simple tableau de bord informatif.

1. 1Définir une politique de conformité iOS et une politique Android distinctes.
2. 2Configurer les critères jailbreak/root, OS minimal et chiffrement.
3. 3Fixer une action en cas de non-conformité, avec une période de grâce.
4. 4Créer une règle d'accès conditionnel exigeant un appareil conforme.
5. 5Cibler les applications sensibles (Exchange, Teams, SharePoint) dans la règle.

Déployer sans casser l'usage

Le principal danger d'une politique de conformité est de bloquer massivement des utilisateurs légitimes du jour au lendemain. Une introduction progressive, avec pédagogie et remédiation claire, fait toute la différence entre une adoption sereine et une avalanche de tickets.

Période de grâce et remédiation

Introduisez une période de grâce pour laisser aux utilisateurs le temps de se mettre à jour ou de chiffrer leur appareil. Prévoyez un chemin de remédiation explicite : que doit faire concrètement l'utilisateur pour redevenir conforme ? Communiquez sur les raisons pour transformer une contrainte en réflexe de sécurité.

• Tester d'abord sur un groupe pilote restreint avant l'ensemble du parc.
• Prévoir une période de grâce avant le blocage effectif de l'accès.
• Fournir des instructions de remédiation claires et accessibles.
• Communiquer en amont sur le pourquoi de chaque exigence.
• Surveiller le rapport de conformité pour détecter les écarts récurrents.

Erreurs fréquentes à éviter

Quelques pièges classiques transforment une bonne intention en incident de production.

• Activer le blocage immédiat sans période de grâce ni communication.
• Oublier de coupler la conformité à l'accès conditionnel, la rendant inopérante.
• Exiger une version d'OS que certains appareils du parc ne peuvent pas atteindre.
• Négliger la remédiation et laisser l'utilisateur sans solution claire.
• Créer une politique unique iOS/Android au lieu de deux adaptées.

La conformité définit la confiance ; l'accès conditionnel la fait respecter.

Un exemple concret

Une entreprise décide d'imposer le chiffrement et une version d'Android minimale sur les téléphones accédant à Exchange. Plutôt que d'activer le blocage du jour au lendemain, elle configure la politique en mode non bloquant pendant deux semaines. Le rapport de conformité révèle alors qu'une dizaine d'appareils tournent sur une version d'OS trop ancienne, jamais mise à jour par leurs utilisateurs. Grâce à la période de grâce et à des instructions claires, ces utilisateurs mettent leur téléphone à jour avant l'échéance. Le jour où l'accès conditionnel devient bloquant, quasiment tout le parc est déjà conforme : aucun blocage massif, aucun afflux de tickets.

Cet exemple montre que la réussite d'une politique de conformité tient autant à la méthode de déploiement qu'aux critères choisis. Observer avant de bloquer, communiquer et laisser un délai transforme une mesure potentiellement brutale en montée en sécurité progressive et acceptée. C'est aussi ce qui permet de présenter à un auditeur non seulement des règles, mais la preuve qu'elles sont réellement appliquées et suivies.

Surveiller et maintenir la conformité dans le temps

Une politique de conformité n'est pas un projet ponctuel mais un processus vivant. Les appareils évoluent, de nouvelles versions d'OS sortent, des utilisateurs rejoignent ou quittent l'entreprise. Sans surveillance continue, le taux de conformité se dégrade insensiblement jusqu'au jour où un incident le révèle. Le rapport de conformité Intune est votre tableau de bord : consultez-le régulièrement pour repérer les tendances et les écarts récurrents avant qu'ils ne deviennent problématiques.

• Consulter régulièrement le rapport de conformité pour suivre les tendances.
• Adapter la version d'OS minimale au fil des mises à jour majeures.
• Surveiller les appareils qui basculent fréquemment en non-conformité.
• Réviser les critères à chaque évolution réglementaire.
• Conserver un historique pour alimenter vos preuves d'audit.

Cette surveillance continue distingue une conformité affichée d'une conformité réelle. C'est elle qui vous permet de démontrer, à tout moment, que votre parc mobile respecte durablement vos obligations NIS2, ISO 27001 et RGPD.

Renforcer la conformité avec le niveau de risque des menaces

Les critères de base (jailbreak, OS minimal, chiffrement) décrivent l'état statique de l'appareil, mais pas les menaces actives qui pèsent sur lui. Pour aller plus loin, Intune sait consommer le niveau de risque calculé par une solution de défense contre les menaces mobiles (Mobile Threat Defense), comme Microsoft Defender for Endpoint sur iOS et Android. Un appareil exposé à une application malveillante, à un réseau Wi-Fi piégé ou à une tentative de hameçonnage voit son niveau de risque grimper, ce qui peut le basculer en non-conformité en temps quasi réel. La conformité cesse alors d'être une photo prise à l'enrôlement pour devenir une évaluation dynamique.

1. 1Connecter la solution de défense contre les menaces mobiles à Intune via son connecteur dédié.
2. 2Déployer l'application de protection (Defender for Endpoint) sur les appareils iOS et Android ciblés.
3. 3Définir dans la politique de conformité le niveau de risque maximal toléré, par exemple faible.
4. 4Laisser Intune marquer non conforme tout appareil dont le risque dépasse ce seuil.
5. 5Coupler à l'accès conditionnel pour bloquer l'accès jusqu'au retour à un niveau de risque acceptable.

Prenons un utilisateur qui installe, hors catalogue, une application Android piégée. La solution de défense détecte le comportement malveillant et élève le niveau de risque de l'appareil à élevé. Comme la politique de conformité n'autorise qu'un risque faible, l'appareil bascule immédiatement en non-conformité, et l'accès conditionnel lui refuse Exchange et Teams. L'utilisateur est invité à supprimer l'application incriminée ; une fois la menace neutralisée, le niveau de risque redescend et l'accès est rétabli automatiquement. Le tout sans intervention manuelle de l'IT, et avec une trace complète exploitable en audit.

Comment AuPoint vous aide

AuPoint transforme ces exigences en politiques de conformité et règles d'accès conditionnel prêtes à l'emploi, en langage clair et sans PowerShell. Un aperçu d'impact vous montre qui serait bloqué avant d'activer une règle, et les politiques réversibles vous permettent d'ajuster sans risque. Vous alignez iOS et Android sur vos obligations NIS2, ISO 27001 et RGPD, avec des preuves de conformité mobilisables lors d'un audit.

Questions fréquentes

Faut-il une politique distincte pour iOS et Android ?

Oui, c'est recommandé. Les deux plateformes exposent des signaux et des réglages différents ; une politique par système permet de coller aux spécificités de chacun sans compromis et facilite la maintenance.

Que se passe-t-il pendant la période de grâce ?

L'appareil est marqué non conforme mais conserve temporairement l'accès, avec des notifications invitant l'utilisateur à se mettre en conformité. À l'expiration du délai, l'accès conditionnel applique le blocage.

La conformité suffit-elle sans accès conditionnel ?

Non. Sans accès conditionnel, la conformité ne fait que produire un verdict informatif. C'est l'accès conditionnel qui traduit ce verdict en autorisation ou en blocage effectif de l'accès aux données.

Le niveau de risque des menaces est-il indispensable ?

Non, ce n'est pas obligatoire pour démarrer. Les critères statiques (jailbreak, OS, chiffrement) constituent déjà une base solide et suffisante pour la plupart des organisations. Le niveau de risque des menaces mobiles est une couche supplémentaire, recommandée pour les environnements sensibles, qui ajoute une détection dynamique des compromissions en cours plutôt que de se limiter à l'état de configuration de l'appareil.

Prêt à aligner votre parc mobile sur vos obligations réglementaires sans PowerShell ? Avec AuPoint, déployez vos politiques de conformité et vos règles d'accès conditionnel en quelques clics, en toute confiance.