Le BYOD bien fait : guide de terrain pour sécuriser les téléphones personnels avec Intune

Si vous faites tourner une petite entreprise sur Microsoft 365 et que vous voulez la messagerie pro sur le téléphone de tout le monde, vous tombez sur une question qui a l'air simple et ne l'est pas : comment protéger les données de l'entreprise sur un appareil qui ne vous appartient pas ?

La réponse, c'est une pile d'outils bien définis avec des compromis clairs. Bien utilisés, ils offrent une protection solide pour les données de l'entreprise et une confidentialité totale pour les données personnelles sur le même téléphone. Ce guide couvre les concepts, les compromis, la configuration exacte qu'on a utilisée — et les problèmes rencontrés en chemin, parce qu'il y en a eu plusieurs.

Pourquoi s'en donner la peine — les faits

Quelques raisons simples pour lesquelles ça vaut le coup de faire les choses proprement :

• Les téléphones sont déjà personnels. Une petite entreprise ne distribue pas de matériel corporate. Les gens consultent leurs e-mails et Teams sur l'appareil qu'ils ont dans la poche, donc cet appareil est déjà concerné, que vous le gériez ou non.
• L'accès non géré est un vrai chemin de fuite de données. Laissés tels quels, les mails et fichiers de l'entreprise vivent dans des apps sans exigence de chiffrement, sans code PIN, sans contrôle sur l'endroit où les données sont copiées, et sans moyen de les supprimer si un téléphone est perdu ou si quelqu'un s'en va.
• On détient des données qui comptent. On opère une plateforme avec des fonds de joueurs et des informations personnelles, donc on tient notre propre accès interne à un niveau défini (des contrôles de type CIS/SOC 2), pas à un niveau « au mieux ».
• La confidentialité est une exigence, pas un bonus. Quoi qu'on fasse, ça ne peut pas étendre la portée de l'IT aux apps, photos, messages ou à la localisation personnels de qui que ce soit.

L'objectif était précis : chaque chemin d'accès aux données de l'entreprise sur un téléphone doit respecter un standard de sécurité défini, sans gérer l'appareil personnel autour.

Le problème, énoncé précisément

Deux exigences s'appliquent en même temps :

• Les données de l'entreprise doivent être protégées — chiffrées, à accès contrôlé, et supprimables si un téléphone est perdu ou si la personne part.
• Un téléphone personnel appartient à la personne — photos, conversations, apps et localisation restent privées et hors de portée de l'IT.

La gestion des appareils mobiles, c'est l'outillage construit pour satisfaire les deux à la fois. La suite de ce guide, c'est la boîte à outils et la façon dont les pièces s'assemblent.

La boîte à outils : trois façons de gérer un téléphone

Microsoft Intune propose un spectre, pas un interrupteur :

1. MAM — Mobile Application Management gère l'application. Vous protégez les apps de travail et laissez le reste du téléphone tranquille. Pas d'inscription.

2. MDM — Mobile Device Management gère l'appareil, en deux variantes distinctes :

• Profil professionnel / User Enrollment — un conteneur de travail séparé et chiffré sur un téléphone personnel. L'IT ne gère que le conteneur.
• Entièrement géré — l'IT gère l'appareil entier. Adapté au matériel appartenant à l'entreprise, pas aux téléphones personnels.

La plupart des équipes ne considèrent que l'option 1 et l'extrémité « entièrement géré » de l'option 2, rejettent les deux, et se contentent de quelque chose de flou. L'option utile, c'est celle du milieu.

Concept 1 : MAM / protection d'applications

Les stratégies de protection d'applications d'Intune constituent la couche MAM. Une stratégie appliquée à une app comme Outlook :

• Chiffre les données de l'entreprise à l'intérieur de l'app.
• Exige un code PIN ou une biométrie pour l'ouvrir.
• Bloque copy, Save As et Open in depuis les données de l'entreprise vers les apps personnelles.
• Permet une réinitialisation sélective des données de l'entreprise uniquement, en laissant les données personnelles intactes.

Rien de tout ça n'exige d'inscrire l'appareil. Le téléphone reste entièrement personnel ; seules les apps de travail sont gérées. Pour beaucoup de cas BYOD, c'est suffisant — et c'était notre point de départ.

Concept 2 : la conformité implique l'inscription

Le concept qui relie tout le reste, c'est la conformité de l'appareil.

Un appareil est « conforme » quand il est inscrit dans la gestion et qu'il respecte des règles d'intégrité que vous définissez — chiffrement du disque activé, verrouillage d'écran configuré, OS à jour, pas de root, et ainsi de suite. La conformité est un état que l'appareil rapporte et que la gestion vérifie.

Le point clé : vous ne pouvez pas évaluer la conformité d'un appareil qui n'a jamais été inscrit. La prémisse du MAM, c'est l'absence d'inscription, donc un téléphone en MAM uniquement est protégé au niveau de l'app mais ne peut jamais être « conforme » — il n'y a rien d'inscrit à vérifier. Require compliant device et « pas d'inscription » sont mutuellement exclusifs par conception.

Si vous voulez une garantie au niveau de l'appareil, l'appareil doit être inscrit dans quelque chose. Ça pointe vers l'option du milieu.

Concept 3 : le profil professionnel

Sur Android, l'option du milieu, c'est le profil professionnel (via Android Enterprise). Sur iOS, l'équivalent est le User Enrollment. Le modèle :

Un profil professionnel est un conteneur séparé et chiffré sur un téléphone personnel. L'IT ne gère que ce qui se trouve à l'intérieur de ce conteneur. Tout ce qui est en dehors — apps personnelles, photos, messages, comptes — se trouve dans un espace que l'IT ne peut ni voir, ni toucher, ni effacer.

Les apps de travail apparaissent comme un ensemble badgé à côté de l'écran d'accueil personnel, sandboxées dans le conteneur. L'appareil devient inscrit et conforme, dans les limites du conteneur de travail. Les données personnelles restent privées. « Inscription » veut dire ici que l'entreprise gère un conteneur, pas l'appareil.

Concept 4 : l'accès conditionnel

L'accès conditionnel dans Microsoft Entra est la porte d'accès. Avant d'accorder une connexion, il vérifie des conditions que vous définissez. Deux octrois sont pertinents ici :

• Require app protection — l'accès est autorisé si l'app a votre stratégie MAM appliquée. Se marie avec le MAM.
• Require compliant device — l'accès est autorisé si l'appareil est inscrit et sain. Se marie avec le MDM / profil professionnel.

L'accès conditionnel, c'est là que vous imposez le modèle que vous utilisez. Changez l'octroi, et vous changez le niveau d'exigence pour l'accès.

Le chemin qu'on a pris

Une fois le modèle en place, la construction est directe :

1. Commencer par le MAM. Protection d'applications sur les apps de travail, plus une règle d'accès conditionnel exigeant la protection d'applications. L'approche la plus légère.
2. Décider de la garantie dont vous avez besoin. Si « l'app est protégée » suffit, arrêtez-vous ici — c'est valable. Nous, on voulait la garantie au niveau de l'appareil.
3. Activer Android Enterprise en liant Managed Google Play au tenant. Une connexion unique qui débloque l'inscription en profil professionnel.
4. Inscrire le téléphone comme profil professionnel à propriété personnelle. Un espace de travail badgé et chiffré est créé, le côté personnel n'est pas touché, et l'appareil se signale compliant en quelques minutes.
5. Livrer les apps de travail depuis Managed Google Play — approuver Outlook, Teams, Edge et les apps Office, les affecter, et elles s'installent dans le conteneur.
6. Basculer l'octroi d'accès conditionnel de Require app protection vers Require compliant device — le même niveau d'exigence que pour les laptops.

Ça, c'est la version propre. Voilà ce qui s'est réellement passé.

Les problèmes rencontrés, et comment on les a résolus

1. Toutes les apps gérées bloquées avec « l'appareil n'est pas conforme ». Notre stratégie de protection d'applications MAM portait une règle de lancement conditionnel, appActionIfDeviceComplianceRequired, réglée sur block. Quand on a essayé de l'assouplir, Intune n'acceptait que block ou wipe — l'API rejette null et warn. Combiné avec le concept 2, c'est une boucle fermée : la stratégie exige un appareil conforme, un téléphone en MAM uniquement n'est jamais inscrit, donc jamais conforme, donc chaque app est bloquée et Company Portal essaie de s'inscrire en boucle. C'est appliqué côté client, donc ça n'apparaît jamais comme un échec de connexion dans Entra — un détail qui rend le diagnostic difficile.

Correctif : arrêter de se battre contre la porte. Inscrire l'appareil (profil professionnel) pour qu'il puisse réellement être conforme, puis abandonner le MAM pour cette plateforme (problème 5).

2. Company Portal : « ne répond pas aux exigences pour s'inscrire ». Avant qu'Android Enterprise soit connecté, il n'existait aucun chemin d'inscription en profil professionnel, donc la tentative d'inscription n'avait nulle part où atterrir.

Correctif : connecter Managed Google Play pour lier Android Enterprise. C'est cette seule connexion qui rend l'inscription en profil professionnel disponible.

3. Le conflit de compte Google — l'étape qui a coûté le plus de temps. Managed Google Play se lie via un compte Google qui devient le propriétaire de l'entreprise. Notre adresse e-mail professionnelle était déjà rattachée à un compte Google personnel, et Google traite ça comme un compte en conflit — il refuse de vous laisser utiliser la même adresse pour créer l'admin organisationnel/Workspace. C'est facile à rater et ça bloque tout.

Correctif : résoudre le conflit d'abord. Soit libérer l'adresse via le processus de comptes en conflit de Google (renommer ou fermer le compte Google personnel existant sur cette adresse), soit utiliser un compte dédié sans aucune inscription Google préalable. Prévoyez du vrai temps pour ça — c'est le truc le plus susceptible de bloquer une petite équipe dès le premier jour, et ça n'a rien à voir avec Intune.

4. Le profil professionnel était vide après l'inscription. Les apps du profil professionnel ne sont pas reprises du côté personnel. Un conteneur fraîchement créé ne contient rien.

Correctif : approuver les apps dans Managed Google Play et les affecter à votre groupe en Required (installation automatique) ou Available (installation à la demande depuis le store du profil professionnel). Elles apparaissent alors comme apps badgées dans le conteneur.

5. Toujours « non conforme » — même après que l'appareil est devenu conforme. L'appareil se signalait désormais compliant, mais Outlook refusait toujours. La cause : la stratégie de protection d'applications MAM était encore appliquée à la même app, désormais gérée en MDM dans le profil professionnel, et sa porte de conformité d'appareil entrait en conflit avec l'inscription. MAM et MDM ne veulent pas co-gérer la même app.

Correctif : s'engager sur un seul modèle par plateforme. On a désaffecté la stratégie de protection d'applications Android et basculé l'octroi d'accès conditionnel d'Android de Require app protection vers Require compliant device. L'appareil en profil professionnel le satisfait directement ; il ne reste aucune porte MAM pour créer un conflit.

6. Notre propre stratégie a bloqué notre outillage d'admin — AADSTS530033. En automatisant les changements Intune, une connexion admin a été refusée : l'accès conditionnel déclinait une connexion par code d'appareil parce que ce jeton n'est pas lié à un appareil conforme.

Correctif : exécuter le travail privilégié depuis un appareil déjà conforme pour que le jeton soit lié à l'appareil — par exemple Connect-MgGraph en interactif depuis une machine gérée. La leçon est positive : si votre accès conditionnel est capable de stopper une connexion par code d'appareil, c'est qu'il est bien configuré.

Construire avec l'IA

On construit en public, et on construit avec l'IA, y compris sur les opérations. L'IA est efficace pour faire avancer rapidement une configuration à travers de nombreuses branches. On l'associe à une règle : l'IA propose, un humain décide — surtout sur tout ce qui touche à la sécurité. Cette division du travail permet à une petite équipe d'avancer au rythme d'une équipe plus grande.

Les modèles mentaux à retenir

1. Le MAM gère l'app ; le MDM gère l'appareil. Choisissez selon la garantie dont vous avez besoin.
2. La conformité implique l'inscription. Vous ne pouvez pas vérifier un appareil qui n'a jamais été inscrit, donc Require compliant device et « pas d'inscription » ne peuvent pas coexister.
3. Le profil professionnel est l'option du milieu. Il gère un conteneur, pas l'appareil — conformité de l'appareil et vie privée personnelle en même temps.
4. Un seul modèle par app. Ne laissez pas une stratégie MAM sur une app passée en MDM ; choisissez votre voie.
5. L'accès conditionnel fixe le niveau d'exigence. Choisissez l'octroi qui correspond à votre modèle et laissez-le faire respecter la règle.

On a mis ce niveau de soin dans quelques boîtes mail professionnelles parce que la même discipline qui sécurise notre accès mobile est celle qui protège votre compte, vos fonds et vos données sur la plateforme. La sécurité est une habitude qui traverse tout le travail interne, pas seulement les parties que les clients voient.

On se retrouve aux tables.