MDM Android : Work Profile, COBO, COPE — quel mode pour quel usage

Un parc Android sans mode défini, c'est une surface d'attaque non maîtrisée

En Suisse romande, beaucoup de PME de 20 à 150 employés ont hérité d'un parc Android constitué d'appareils personnels, d'appareils achetés en détail et de quelques terminaux de caisse — le tout géré par un seul profil MDM générique. Résultat : des politiques trop permissives sur les appareils d'entreprise, ou trop intrusives sur les personnels, avec un risque de violation de la nLPD dès qu'un RSSI regarde le rapport d'inventaire. Android Enterprise propose trois modes structurants — Work Profile (BYOD), COBO et COPE — chacun avec des garanties techniques précises, des contraintes différentes et des cas d'usage bien distincts.

Les trois modes Android Enterprise : architecture et garanties

Work Profile (profil professionnel) — BYOD structuré

Le Work Profile crée une partition chiffrée séparée sur l'appareil personnel de l'employé. Les apps professionnelles (email, VPN, MDM agent) s'exécutent dans ce conteneur ; les apps personnelles restent entièrement hors de portée du MDM. L'administrateur ne peut pas lire les SMS personnels, l'historique d'appels privé, ni effacer la totalité de l'appareil — seulement le profil professionnel.

Techniquement, le profil est monté via un KeyStore distinct ; les certificats d'entreprise (EAP-TLS pour le Wi-Fi, SCEP ou PKCS#12 pour les VPN) restent confinés à ce profil. Android 11+ impose des restrictions supplémentaires : l'IT ne peut plus lister les apps personnelles, même si l'appareil est enrollé. Cette évolution est favorable à la conformité PFPDT — collecter moins de données sur le terminal personnel est un principe de minimisation directement issu de la nLPD.

Limites : l'IT ne contrôle pas la version d'OS, ne peut pas forcer le chiffrement complet (il est géré par le constructeur), et ne peut pas bloquer le partage de données hors profil si l'utilisateur copie-colle manuellement. Le mode Work Profile convient aux collaborateurs disposant d'un smartphone personnel et accédant à la messagerie, aux outils de collaboration ou à un ERP en SaaS.

COBO — Corporate-Owned, Business-Only

Un appareil COBO est entièrement géré par l'entreprise : pas de compte Google personnel, pas de Play Store libre, pas d'accès à des apps non approuvées. L'enrollment se fait via Android Zero-Touch Enrollment (ZTE) ou via un QR code à la première mise sous tension, avant toute interaction utilisateur.

L'IT dispose d'un contrôle total : politique de mot de passe fort (minimum 8 caractères alphanumériques, timeout 60 secondes), désactivation du Bluetooth, du NFC, de la caméra si nécessaire, restriction des ports USB (mode charge uniquement via la politique usbFileTransferDisabled). Les mises à jour OS peuvent être forcées avec une fenêtre de maintenance définie (ex. : dimanche 02h00–04h00). Le CIS Benchmark Google Android recommande ce mode pour tout appareil traitant des données sensibles sans besoin d'usage personnel.

Usage typique : terminaux logistiques (scanners de colis, tablettes d'entrepôt), appareils de caisse, bornes de terrain pour techniciens. En PME romande, ce sont souvent des appareils Zebra, Honeywell ou des smartphones Samsung Galaxy dédiés. Coût indicatif de gestion : 3–8 CHF/mois/appareil selon la solution MDM retenue.

COPE — Corporate-Owned, Personally-Enabled

COPE combine la propriété corporate avec un usage personnel structuré : l'appareil appartient à l'entreprise, mais l'employé peut installer des apps personnelles dans un profil séparé. Contrairement au Work Profile BYOD, l'IT garde la main sur la couche OS complète — elle peut forcer les mises à jour, chiffrer le stockage, effacer l'intégralité de l'appareil en cas de perte.

L'architecture est similaire au Work Profile côté isolation des données, mais les droits de l'administrateur sur la couche système sont ceux du COBO. Android 11 a restructuré COPE : le profil personnel est désormais géré comme un Work Profile inversé, ce qui signifie que l'IT ne voit pas les apps personnelles mais peut imposer des restrictions système globales (pas de root, no sideloading, SafetyNet/Play Integrity obligatoire).

Ce mode convient aux équipes commerciales ou aux cadres qui reçoivent un téléphone d'entreprise mais souhaitent y accéder à leurs apps personnelles (Signal, Spotify, banking). Le coût de l'appareil est porté par l'entreprise, ce qui simplifie la comptabilité et la reprise en fin de contrat.

Critères de sélection et implications nLPD

Tableau de décision rapide

• L'appareil appartient à l'employé + usage mixte → Work Profile. Obligation de transparence : informer l'employé par écrit de ce que l'IT peut et ne peut pas faire (art. 19 nLPD sur l'information).
• L'appareil appartient à l'entreprise + usage exclusivement professionnel → COBO. Contrôle maximal, zero-touch enrollment, pas de compte Google personnel.
• L'appareil appartient à l'entreprise + usage mixte toléré → COPE. Politique d'utilisation acceptable à signer, clause de wiping total en cas de perte dans le règlement interne.

Minimisation des données et nLPD

Le nouveau droit suisse de la protection des données (en vigueur depuis le 01.09.2023) exige que le traitement de données personnelles soit proportionné à la finalité. En mode Work Profile, l'inventaire MDM remonte le modèle de l'appareil, la version Android, le statut de chiffrement et la conformité Play Integrity — mais pas les apps personnelles ni la géolocalisation hors horaires de travail si la politique est correctement configurée. En COBO ou COPE, la géolocalisation peut être activée en permanence si justifiée (techniciens de terrain) : cette collecte doit être documentée dans le registre des activités de traitement (art. 12 nLPD) et mentionnée dans le règlement interne.

Un point souvent oublié : l'enrollment MDM lui-même constitue un traitement de données. Le PFPDT considère que l'employeur doit documenter la finalité, la base légale (intérêt légitime ou contrat de travail) et les droits de l'employé avant tout déploiement.

Zero-Touch Enrollment et sécurité de la chaîne d'approvisionnement

Pour les parcs COBO et COPE, le Zero-Touch Enrollment (ZTE) garantit que l'appareil s'enrôle automatiquement dès la première mise sous tension, sans intervention manuelle. Cela élimine la fenêtre de vulnérabilité entre la remise de l'appareil et l'enrollment. La configuration ZTE requiert un compte Google Zero-Touch d'entreprise et un revendeur certifié qui associe les IMEI au portail avant livraison. En Suisse, plusieurs revendeurs IT proposent ce service ; vérifiez que les IMEI sont enregistrés côté portail avant expédition aux utilisateurs distants (Valais, Fribourg).

Déploiement pas à pas : Work Profile pour une PME BYOD

Voici la procédure recommandée pour un parc BYOD de 20 à 80 employés utilisant leurs propres appareils Android :

1. Inventaire préalable (DSI) : recenser les modèles et versions Android. Android 9+ est requis pour le Work Profile complet ; Android 11+ pour les restrictions de listing d'apps personnelles. Les appareils sous Android 8 ou antérieur doivent être mis hors service ou basculés en COBO si le firmware peut être mis à jour.
2. Choix de la console MDM (DSI + RSSI) : configurer un Managed Google Play Account pour l'organisation (compte Google Workspace ou compte EMM standalone). C'est ce compte qui approuve les apps déployées dans le Work Profile.
3. Rédaction de la politique d'usage acceptable (RSSI + juriste) : documenter explicitement ce que l'IT peut voir (version OS, statut chiffrement, compliance Play Integrity, apps dans le profil pro) et ce qu'elle ne peut pas voir (apps perso, photos, SMS). Faire signer avant enrollment.
4. Configuration des politiques MDM (DSI) : mot de passe Work Profile (min. 6 chiffres ou biométrie forte), timeout 5 minutes, chiffrement du profil activé, restriction copier-coller entre profils, déploiement du certificat VPN via SCEP.
5. Enrollment utilisateur : envoi d'un lien d'enrollment par email professionnel ou QR code. L'utilisateur télécharge l'agent MDM, accepte la création du profil pro. Durée : 5–10 minutes par appareil.
6. Vérification de conformité (DSI) : contrôler dans la console que 100 % des appareils remontent un statut Play Integrity MEETS_DEVICE_INTEGRITY. Les appareils rootés ou avec bootloader déverrouillé doivent être bloqués automatiquement.
7. Documentation registre de traitement (RSSI + juriste) : enregistrer la finalité (sécurisation accès aux ressources entreprise), les catégories de données collectées, la durée de conservation, les mesures techniques (chiffrement AES-256 du profil) conformément à l'art. 12 nLPD.

Cas pratique : fiduciaire vaudoise, 45 endpoints Android

Une fiduciaire de la région lausannoise (45 collaborateurs, dont 12 à distance) a migré en mars 2024 d'un MDM legacy (enrollment admin de base, pas de Work Profile) vers une architecture mixte après un audit interne révélant que des données clients étaient synchronisées avec des clouds personnels.

Contexte : 28 appareils BYOD (collaborateurs utilisant leur Samsung personnel), 10 tablettes dédiées à la saisie de données clients (reception + back-office), 7 smartphones de pool pour les associés.

Architecture retenue :

• 28 appareils BYOD → Work Profile. Politique : apps perso hors scope IT, déploiement Outlook + VPN Always-On + app interne de gestion de dossiers dans le profil pro, restriction du copier-coller vers apps personnelles.
• 10 tablettes back-office → COBO. Enrollment via QR code (ZTE non disponible car achat en détail). Apps : uniquement l'ERP fiduciaire et l'app MDM. Caméra désactivée (données clients sensibles à l'écran). Mise à jour OS forcée le vendredi à 22h00.
• 7 smartphones pool → COPE. Compte Google personnel autorisé dans le profil perso, politique d'effacement total documentée et signée par chaque utilisateur au moment de la remise.

Chiffres de déploiement : Migration complète réalisée en 3 semaines. Coût MDM : environ 6 CHF/appareil/mois (45 appareils = 270 CHF/mois). Temps IT interne : 2 jours pour la configuration initiale, 4 heures pour l'enrollment des 45 appareils (combiné helpdesk self-service + enrollment supervisé pour les COBO). Résultat audit post-déploiement : zéro app non approuvée dans les profils pro, 100 % des tablettes COBO en MEETS_STRONG_INTEGRITY (appareils Samsung avec Knox), conformité Play Integrity à 97 % sur le parc BYOD (1 appareil sous Android 9 remplacé).

Incident évité : En juin 2024, un collaborateur perd son Samsung personnel (Work Profile). L'IT efface uniquement le profil pro en 4 minutes depuis la console. Les données personnelles de l'employé restent intactes. Sans Work Profile, l'effacement total aurait déclenché une procédure RH complexe et potentiellement une plainte pour violation de la vie privée.

Récapitulatif opérationnel

• Cartographier le parc avant tout choix de mode : propriétaire de l'appareil (employé vs entreprise), version Android minimale requise, type de données traitées.
• Work Profile uniquement si l'appareil appartient à l'employé — ne jamais déployer un profil géré complet (COBO/COPE) sur un appareil personnel.
• COBO pour les terminaux dédiés : caisse, logistique, borne terrain. Activer ZTE si le revendeur est certifié, sinon QR code supervisé.
• COPE pour les flottes de pool ou les cadres : rédiger et faire signer une politique de wiping total avant remise de l'appareil.
• Exiger Play Integrity MEETS_DEVICE_INTEGRITY minimum sur tous les modes ; MEETS_STRONG_INTEGRITY pour les appareils accédant à des données financières ou de santé.
• Documenter le traitement MDM dans le registre nLPD (art. 12) : finalité, données collectées par mode, durée de rétention, mesures techniques.
• Informer les employés par écrit avant enrollment, avec distinction claire de ce que l'IT voit et ne voit pas selon le mode — obligatoire sous l'art. 19 nLPD.
• Tester la procédure de wiping sélectif (Work Profile) et total (COBO/COPE) au moins une fois par an, avec chronométrage et vérification des données résiduelles.
• Vérifier les versions Android du parc : Android 11+ pour les fonctionnalités COPE restructurées et les restrictions BYOD renforcées ; planifier le remplacement des appareils sous Android 10 et antérieur.
• Pour les incidents impliquant des données clients (ex. perte d'un appareil COBO avec données fiduciaires) : activer le wiping immédiat via MDM, documenter l'incident, évaluer si le seuil de notification NCSC ou PFPDT est atteint selon la gravité (art. 24 nLPD).

SynGuard accompagne les PME romandes dans la définition et le déploiement de ces architectures Android Enterprise, en intégrant les contraintes nLPD dès la phase de conception.

Sources

• Fedlex — Loi fédérale sur la protection des données (nLPD), RS 235.1 — texte consolidé de la nLPD en vigueur depuis le 01.09.2023, incluant les art. 12 (registre), 19 (information) et 24 (notification des violations).
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — autorité de surveillance suisse, guides et recommandations sur le traitement de données en contexte professionnel.
• NCSC — Obligation de signalement pour les exploitants d'infrastructures critiques — procédure officielle de notification des incidents de cybersécurité.
• CIS Benchmark for Google Android — référentiel de durcissement officiel pour les appareils Android en environnement d'entreprise.
• NIST Cybersecurity Framework (CSF) — cadre de référence pour la gestion du risque cyber, applicable aux politiques de gestion d'endpoints mobiles.