Intune 2609 : iOS/iPadOS 18 devient le seuil supporté à contrôler
dans la release Intune 2609, Microsoft indique qu'Intune requiert maintenant iOS/iPadOS 18 ou ultérieur pour les scénarios standard de gestion d'appareil, Company Portal et protection applicative. Le changement ne concerne pas le poste Windows, mais il peut couper des usages mobiles si les règles d'enrôlement, de conformité ou de protection applicative sont durcies sans inventaire préalable.
- Impact
- appareils iPhone et iPad gérés ou protégés par Intune, surtout les flottes avec anciens modèles, terminaux partagés ou appareils sans affinité utilisateur.
- Action
- inventorier les versions iOS/iPadOS, distinguer les appareils supportés et ceux seulement autorisés à s'enrôler, puis planifier la montée de version avant de modifier les restrictions ou les règles de blocage.
- Statut
- À planifier
Ce qui change
La page What's new in Microsoft Intune, mise à jour pour la service release 2609, ajoute une entrée Updated minimum supported version for iOS and iPadOS. Microsoft y indique qu'Intune requiert désormais iOS/iPadOS 18 ou ultérieur pour les scénarios standard de gestion d'appareil, Company Portal et protection applicative. L'action explicitement demandée aux administrateurs est d'identifier et de mettre à niveau les appareils concernés ; les appareils sans utilisateur enrôlés par Automated Device Enrollment ont une déclaration de support séparée.
La page de référence des plateformes supportées précise cette nuance. Pour les appareils Apple avec affinité utilisateur, le seuil supporté est iOS/iPadOS 18 et macOS 15. Pour les appareils sans affinité utilisateur enrôlés par ADE ou Apple Configurator, iOS/iPadOS 18 est aussi le niveau supporté, mais l'enrôlement reste autorisé à partir d'iOS/iPadOS 16. Microsoft distingue donc supported et allowed : un OS allowed peut s'enrôler et utiliser certaines capacités éligibles, mais sans garantie que l'ensemble des fonctions Intune se comporte comme prévu.
Ce point est important pour l'exploitation. La bonne lecture n'est pas « bloquer immédiatement tout ce qui est sous iOS 18 », mais « mesurer l'écart et décider quelles populations peuvent encore fonctionner temporairement sous un niveau seulement allowed ». Les terminaux partagés, kiosques, appareils métiers et flottes contraintes par le matériel doivent être séparés des appareils utilisateurs classiques.
Actions recommandées
Commencer par un inventaire Intune des versions iOS/iPadOS réellement présentes. Le résultat attendu est une liste exploitable par population : appareils avec utilisateur, appareils sans affinité utilisateur, modèles incapables de monter en iOS 18, appareils inactifs et appareils déjà conformes. Les groupes d'exception doivent être justifiés par un usage et une date de réexamen, pas par un simple filtre historique.
Ensuite, revoir les trois leviers Intune séparément. Les restrictions d'enrôlement peuvent empêcher de nouveaux appareils trop anciens d'entrer dans le parc. Les politiques de conformité peuvent imposer un minimum d'OS avec une période de grâce avant impact sur l'accès conditionnel. Les app protection policies peuvent avertir ou bloquer l'accès aux données d'entreprise au niveau applicatif ; la documentation Microsoft décrit aussi l'usage de filtres managed apps lorsque des exigences différentes doivent coexister selon les versions majeures.
Recommandation PatchFactory : utiliser d'abord l'avertissement et le reporting pour les utilisateurs encore en dessous d'iOS/iPadOS 18, puis basculer progressivement vers le blocage pour les appareils compatibles qui n'ont pas été mis à jour. Pour les appareils sans affinité utilisateur encore autorisés à s'enrôler sous iOS/iPadOS 16 ou 17, garder une règle distincte et documenter les fonctions qui doivent être retestées, au lieu de les mélanger avec les appareils utilisateurs.
Points de vigilance
Ne pas déduire une date de coupure universelle si elle n'est pas présente dans le tenant ou le Message Center. La page Intune annonce le seuil supporté dans 2609, mais le moment où une règle locale bloque l'accès dépend des paramètres que l'organisation choisit : restriction d'enrôlement, conformité, action de non-conformité, Conditional Access ou Conditional Launch.
Après changement, vérifier deux résultats : aucun nouvel appareil utilisateur sous le seuil ne doit s'enrôler par erreur, et les utilisateurs déjà gérés doivent recevoir l'avertissement ou le blocage prévu selon le scénario choisi. Si des appareils métiers restent sous un OS seulement allowed, le suivi doit porter sur les fonctions réellement utilisées : synchronisation Intune, renouvellement de certificats, applications protégées, profils Wi-Fi/VPN et remontée de conformité.
Sources
- Nouveautés Microsoft Intune, service release 2609, entrée Updated minimum supported version for iOS and iPadOS : https://learn.microsoft.com/en-us/intune/whats-new/
- Plateformes supportées par Intune, distinction Apple supported et allowed pour appareils avec ou sans affinité utilisateur : https://learn.microsoft.com/en-us/intune/fundamentals/ref-supported-platforms
- Gestion des versions d'OS avec Intune, restrictions d'enrôlement, conformité et app protection policies : https://learn.microsoft.com/en-us/intune/device-updates/manage-os-versions