MDM et nLPD : minimiser les données collectées sur les terminaux personnels

Un MDM collecte plus que vous ne le pensez

Un profil MDM bien configuré permet de gérer 250 endpoints depuis une console centrale. Un profil mal pensé transforme la même console en outil de surveillance de masse : géolocalisation permanente, inventaire exhaustif des applications personnelles, journaux d'appels sur les SIM professionnelles. Depuis l'entrée en vigueur de la nouvelle Loi fédérale sur la protection des données (nLPD) le 01.09.2023, ces pratiques exposent l'employeur à une responsabilité civile et pénale concrète — non plus théorique.

Ce que la nLPD impose réellement aux employeurs

Minimisation et finalité

L'art. 6 al. 2 nLPD codifie le principe de minimisation : seules les données adéquates, pertinentes et limitées à la finalité déclarée peuvent être traitées. Appliqué aux MDM, cela signifie que chaque attribut collecté (IMEI, localisation GPS, liste des apps installées, identifiants Wi-Fi, captures d'écran de conformité) doit être justifié par un objectif métier documenté. « Gestion des terminaux » est une finalité trop vague ; « vérification de la version iOS pour l'accès VPN » est conforme.

Terminaux personnels (BYOD) vs terminaux d'entreprise

La distinction est structurante. Sur un terminal d'entreprise (livré via Apple Business Manager ou Windows Autopilot avec supervision totale), la collecte est plus large car la finalité professionnelle exclusive est défendable. Sur un terminal personnel en BYOD, la nLPD — combinée à l'art. 328b CO qui interdit le traitement des données du travailleur sauf nécessité directe — impose une séparation nette entre espace professionnel et personnel. L'Autorité fédérale de protection des données (PFPDT) a rappelé ce principe dans ses lignes directrices sur la surveillance du personnel : un employeur ne peut pas légitimement inventorier les applications privées d'un collaborateur sous couvert de gestion MDM.

Registre des activités de traitement

L'art. 12 nLPD exige un registre des activités de traitement pour les organisations de plus de 250 employés, mais le PFPDT recommande explicitement aux PME de tenir ce registre dès 50 personnes. Chaque flux de données MDM (inventaire hardware, télémétrie OS, logs d'authentification, rapports de conformité) doit y figurer avec la base juridique, la durée de conservation et les destinataires éventuels (fournisseur cloud MDM, SOC externalisé).

Architecture technique : ce qu'on active et ce qu'on désactive

Apple Business Manager et profils supervisés

Sur iOS/iPadOS, la supervision via ABM active des MDM keys qui n'existent pas en mode non supervisé : RequestMirroring, EnableScreenTimeReporting, AllowLostMode avec géolocalisation à la demande. Pour les terminaux BYOD, on déploie un profil utilisateur (User Enrollment, disponible depuis iOS 13) qui crée un APFS volume chiffré séparé pour les données professionnelles. Ce mode expose uniquement les apps managées à la console MDM — les apps personnelles, photos et contacts privés restent opaques. Les attributs remontés se limitent à :

• Version iOS et niveau de patch
• Conformité au passcode (booléen, pas le code lui-même)
• État du chiffrement (FileVault / APFS)
• Certificats MDM installés

La géolocalisation en User Enrollment est techniquement bloquée côté Apple — un garde-fou architectural, pas seulement politique.

Windows Autopilot et Intune

Sur Windows 11 (build 23H2+), le mode Autopilot user-driven avec un compte Azure AD joint en hybride collecte par défaut : matériel (CPU, RAM, disque), logiciels installés (inventaire complet), dernière connexion, adresse IP locale, journaux d'événements Windows. Pour un parc BYOD, on préfère l'Enrollment de compte professionnel (Workplace Join) couplé à une politique MAM sans MDM complet : seules les applications Microsoft 365 sont sous gestion, le reste du terminal n'est pas inventorié. Si le MDM complet est requis (accès à des données sensibles classificées), on applique les CIS Benchmarks Windows 11 niveau 1 en désactivant explicitement la collecte de télémétrie (GPO AllowTelemetry = 0 ou 1 selon la version) et en documentant le delta avec le niveau 2.

Android (Android Enterprise)

Android Enterprise propose deux modes BYOD : Work Profile (profil professionnel isolé, recommandé) et Fully Managed (terminal entièrement contrôlé). En Work Profile, l'employeur ne peut pas lister les apps personnelles, accéder aux contacts personnels ni activer le micro ou la caméra hors applications managées. Les attributs MDM accessibles sont restreints : IMEI (si l'app DPC a la permission READ_PHONE_STATE, ce qui doit être explicitement accordé), version Android, patch de sécurité, conformité du verrou d'écran. À noter : en Suisse, la collecte de l'IMEI sur terminal personnel doit figurer dans la notice d'information aux employés et dans le registre des traitements — même si la permission est techniquement disponible, la légitimité doit être justifiée.

FleetDM (Linux et macOS en entreprise)

FleetDM (open source, autodéployé ou cloud) utilise osquery pour remonter des inventaires système granulaires. Par défaut, la configuration osquery.conf collecte : processus actifs, connexions réseau ouvertes, clés de registre (Windows), plist de démarrage (macOS), historique bash. Sur des terminaux mixtes (personnels utilisés en télétravail), il faut restreindre les tables osquery exposées. Un exemple de politique minimisée conforme à la nLPD :

• Tables autorisées : os_version, kernel_info, disk_encryption, certificates, scheduled_tasks
• Tables désactivées : browser_history, chrome_extensions, users (noms d'utilisateur locaux non-pros), shell_history

Cette liste doit être validée par le RSSI et versée au registre des traitements.

Obligations procédurales : information, consentement, durée

Notice d'information préalable

Avant tout enrôlement MDM d'un terminal personnel, l'art. 19 nLPD impose une information claire sur : l'identité du responsable du traitement, la finalité, les catégories de données collectées, les destinataires (y compris le fournisseur MDM basé aux USA ou en UE), la durée de conservation et les droits de l'employé (accès, rectification, suppression). Cette notice doit être remise par écrit, idéalement dans un avenant au contrat de travail signé — le simple règlement informatique affiché dans l'intranet n'est pas suffisant.

Durée de conservation des logs MDM

Les logs d'événements MDM (connexions, mises à jour, alertes de non-conformité) doivent avoir une durée de conservation documentée. Une bonne pratique : 90 jours pour les logs opérationnels, 12 mois pour les logs de conformité liés à des audits, suppression immédiate lors du départ du collaborateur pour les données personnalisées. Si un incident de sécurité survient, les logs peuvent être conservés le temps de la procédure, mais cette exception doit être notée dans le registre.

Notification au PFPDT en cas de violation

Si une configuration MDM expose involontairement des données personnelles (par exemple, un export d'inventaire incluant des données privées envoyé à un prestataire non autorisé), la nLPD art. 24 impose une notification au PFPDT dans les meilleurs délais, sans délai fixe légal contrairement au RGPD (72h), mais avec une exigence de promptitude. La procédure interne doit prévoir :

1. DSI/RSSI — détection et qualification de l'incident (données personnelles exposées ? Employés concernés ?)
2. Juriste — évaluation du risque pour les personnes concernées
3. Direction — décision de notification au PFPDT et aux employés concernés
4. DSI — mesures correctives techniques (révocation du profil MDM, purge des données, audit des accès)
5. RSSI — mise à jour du registre des incidents et du registre des traitements

Cas pratique : fiduciaire vaudoise, 38 terminaux mixtes

Une fiduciaire basée à Lausanne, 22 collaborateurs, gère un parc de 38 terminaux : 15 MacBook Pro d'entreprise (gérés via ABM + MDM maison), 14 iPhones personnels BYOD et 9 PC Windows 11 personnels utilisés en télétravail pour l'accès à leur ERP comptable (logiciel sensible, données de clients soumis au secret fiscal).

Situation avant audit : le profil MDM iPhone collectait IMEI, géolocalisation (activée par erreur dans la config), liste complète des apps installées, et les logs étaient conservés 3 ans dans un bucket S3 chez un prestataire américain sans DPA signé. Risque nLPD : triple — collecte excessive, transfert hors Suisse sans garanties, durée excessive.

Mesures correctives appliquées sur 6 semaines :

1. Semaine 1 — Audit des profils MDM : inventaire de chaque MDM key activée, croisement avec la finalité documentée. Résultat : 8 attributs sur 23 collectés n'ont pas de justification métier.
2. Semaine 2 — Migration vers User Enrollment iOS : re-enrôlement des 14 iPhones BYOD en mode User Enrollment. Géolocalisation techniquement supprimée. Collecte réduite à 4 attributs (version iOS, conformité passcode, chiffrement, certificat MDM). CHF 0 de coût licence supplémentaire.
3. Semaine 3 — Windows 11 BYOD en MAM sans MDM complet : déploiement de la politique MAM Intune pour Microsoft 365 uniquement. Les 9 PC personnels ne remontent plus d'inventaire logiciel complet — seuls les apps M365 sont managées.
4. Semaine 4 — DPA avec le prestataire MDM : signature d'un Data Processing Agreement conforme, migration des logs vers un bucket dans une région EU (Frankfurt). Durée de rétention réduite à 90 jours opérationnels, 12 mois pour les alertes de conformité.
5. Semaine 5 — Notice d'information : rédaction et signature d'un avenant au contrat de travail pour les 22 collaborateurs, détaillant les données collectées selon le type de terminal et les droits d'accès/suppression. Délai d'exécution : 10 jours ouvrables.
6. Semaine 6 — Mise à jour du registre des traitements : création d'une entrée dédiée « Gestion MDM terminaux personnels » avec base juridique (intérêt légitime + nécessité contractuelle), catégories de données par type de terminal, destinataires, durée, mesures techniques.

Résultat chiffré : passage de 23 attributs collectés à 4 sur BYOD iOS, de 31 à 6 sur BYOD Windows, suppression de la géolocalisation permanente, conformité nLPD documentée. Coût total estimé : CHF 4'800 (3 jours consultant + 2 jours DSI interne). Économie potentielle : éviter une sanction administrative ou un litige prud'homal estimé à CHF 20'000–80'000 selon la gravité.

Récapitulatif opérationnel

• Cartographier avant de déployer : lister chaque attribut MDM collecté par type de terminal (supervisé, BYOD iOS, BYOD Android, BYOD Windows) et le justifier par une finalité précise.
• Séparer supervisé et BYOD : utiliser User Enrollment (iOS), Work Profile (Android), MAM sans MDM complet (Windows) pour les terminaux personnels — l'architecture technique limite la collecte en dur.
• Désactiver la géolocalisation sauf exception documentée : sur BYOD, la localisation GPS n'est quasiment jamais justifiable légalement ; sur terminaux supervisés perdus/volés, activer le mode perdu à la demande uniquement.
• Signer un DPA avec chaque fournisseur MDM cloud : vérifier la localisation des données (de préférence Suisse ou UE) et les sous-traitants du fournisseur.
• Formaliser la notice d'information : avenant au contrat de travail signé avant l'enrôlement, pas un simple règlement IT.
• Définir des durées de conservation par catégorie de logs : 90 jours pour les logs opérationnels, 12 mois pour les logs de conformité, suppression immédiate post-départ collaborateur.
• Mettre à jour le registre des traitements : une entrée par flux MDM, avec base juridique nLPD explicite (art. 6 ou art. 31 al. 2 let. a pour intérêt légitime).
• Appliquer les CIS Benchmarks niveau 1 : sur terminaux supervisés, documenter les écarts et les justifier ; désactiver la télémétrie OS non essentielle.
• Tester la procédure de départ collaborateur : révocation du profil MDM, wipe des apps managées uniquement (pas du terminal personnel), confirmation de la suppression des données dans la console MDM.
• Former le DSI et le RSSI à la procédure de notification : en cas de fuite de données MDM, la chaîne DSI → juriste → direction → PFPDT doit être rodée, pas découverte au moment de l'incident.

SynGuard accompagne les PME suisses dans l'audit et la configuration de leurs politiques MDM pour aligner gestion des endpoints et conformité nLPD — sans sur-ingénierie.

Sources

• Loi fédérale sur la protection des données (nLPD), fedlex.admin.ch — Texte consolidé de la nLPD en vigueur depuis le 01.09.2023.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Lignes directrices sur la surveillance des employés et les obligations de notification.
• Centre national pour la cybersécurité (NCSC) — Recommandations pour la sécurité des systèmes d'information en entreprise.
• CIS Benchmarks, Center for Internet Security — Référentiels de configuration sécurisée pour Windows 11, macOS et Android.