Votre MDM gère vos terminaux, pas vos identités : pourquoi ce n'est pas la même chose
« Nous avons déjà SOTI, Intune, Workspace ONE, Ivanti. Nous sommes couverts. » C'est la phrase la plus fréquente en rendez-vous DSI dès qu'on parle d'orchestration d'accès sur terminaux partagés. Elle repose sur une confusion structurante : le MDM et l'orchestrateur d'accès ne font pas le même métier.
Ce que fait un MDM, et ce qu'il ne fait pas
Le MDM (Mobile Device Management), qu'on appelle aussi UEM (Unified Endpoint Management) dans sa version étendue, s'occupe de la vie du terminal. Il l'enrôle, il le configure, il le pilote à distance, il pousse des applications, il applique des politiques de sécurité. Il sait éteindre, redémarrer, effacer un appareil perdu. Il sait vérifier qu'un terminal est conforme à votre PSSI.
Ce qu'un MDM ne sait pas faire, en revanche, c'est gérer l'identité de la personne qui utilise le terminal à un instant précis. Le MDM voit un appareil : Zebra TC21, numéro de série ZTC0001234, en zone 5 de l'entrepôt. Il ne voit pas qui est en train d'ouvrir une session dessus, ni si c'est le shift du matin ou celui de la nuit, ni si la même personne utilise ce badge que la semaine dernière.
Cette limite n'est pas un défaut : c'est la définition même du produit. Un MDM a été conçu pour un monde où chaque personne avait son propre appareil, le fameux « one user, one device ». Le partage de terminal est un cas d'usage périphérique pour la plupart des MDM du marché.
La frontière en un tableau
Voici, pour une prise en charge complète de vos terminaux partagés, la répartition claire des responsabilités entre les deux couches.
Le MDM et l'orchestrateur d'accès sont complémentaires, pas concurrents. Le premier gère la vie de l'appareil. Le second gère la vie de la session. Vouloir faire faire l'un par l'autre revient à confier la gestion des identités à votre PRA, ou l'inverse.
Les trois fausses solutions que proposent les MDM
Face à la demande croissante de gestion nominative sur terminaux partagés, les éditeurs de MDM ont réagi. Trois approches se sont développées, chacune avec ses limites. Comprendre pourquoi elles ne suffisent pas évite d'investir dans une impasse.
Certains MDM proposent un écran de login custom, positionné avant l'application métier. C'est visuellement satisfaisant. Techniquement, c'est du théâtre : la session Android sous-jacente reste unique, pilotée par un compte de service partagé. Aucun cloisonnement réel, aucune trace nominative dans les logs système.
Android Enterprise propose depuis quelques versions un mode multi-utilisateurs. Sur le papier, c'est la promesse d'une vraie session personnelle. En pratique, le changement d'utilisateur prend 15 à 40 secondes (chargement du profil complet), les applications sont limitées, et les constructeurs de terminaux durcis ne certifient pas ce mode. Inutilisable en production frontline.
Certains éditeurs (SOTI Identity par exemple) proposent d'étendre l'identité de leurs administrateurs et de leurs applications M365 aux opérateurs terrain. Ce n'est pas la même chose : le périmètre couvert est celui des applications SaaS, pas celui de la session du terminal. Les opérateurs continuent d'utiliser un compte partagé pour ouvrir leur session Android ou Windows.
Aucune de ces trois voies ne produit la traçabilité nominative exigée par NIS2, et aucune ne délivre l'expérience opérateur d'une vraie session personnelle rapide.
L'architecture cible : trois couches complémentaires
déploie et pilote le terminal.
gère la session nominative sur le terminal.
la source d'identité de référence (Ilex, Ping, Entra, ForgeRock, Keycloak).
Chaque couche fait bien un métier. Aucune ne cherche à faire celui des autres.
Cette architecture est aujourd'hui la seule qui permet de tenir simultanément trois objectifs : productivité opérateur (session rapide), conformité NIS2 (journal nominatif), et exploitation IT maîtrisée (chaque produit dans son rôle).
Ce que ça change dans vos discussions avec vos éditeurs MDM
Poser cette clarification entre MDM et orchestrateur d'accès change immédiatement plusieurs conversations.
Sa roadmap identité, quand elle existe, est un sujet secondaire. Le pousser à couvrir votre besoin nominatif retarde de 12 à 24 mois votre conformité. Mieux vaut clarifier ce qu'il fait bien et ce que vous adressez ailleurs.
Le MDM ne suffit pas pour cocher les objectifs 09, 10 et 12 du référentiel ANSSI sur les terminaux partagés. Cette lecture est objective et documentée : elle sort le sujet de l'arbitrage politique.
L'orchestrateur d'accès n'est pas un doublon du MDM déjà budgété. Les deux lignes s'additionnent parce que les périmètres ne se recouvrent pas. Le ROI se calcule séparément sur la productivité opérateur, pas contre le MDM.
Comment YMAO se positionne dans votre architecture
YMAO est un orchestrateur d'accès conçu pour se déployer par-dessus votre MDM existant. Il ne le remplace pas, il ne le duplique pas. Il occupe la couche session utilisateur, laissée vide par le MDM.
Nos intégrations natives couvrent SOTI, Microsoft Intune, VMware Workspace ONE / Omnissa, Ivanti et Clyd (Telelogos). Nos intégrations IdP couvrent Ilex Meibo, Okta, Ping, Microsoft Entra ID, ForgeRock et Keycloak. Nous supportons Android Enterprise (Zebra, Honeywell, Datalogic, Samsung Rugged) et Windows partagé (postes, kiosques, bornes).
Nous accompagnons les DSI et architectes IAM dans la conception de cette architecture à trois couches, en démarrant par un schéma cible aligné avec votre stack actuel.
À lire aussi : Vos terminaux partagés : le point d'audit prioritaire de NIS2 et Pourquoi les comptes génériques survivent aux politiques de sécurité.
Suivez-nous sur LinkedIn pour recevoir nos analyses régulières sur l'orchestration d'accès, la frontière MDM / IAM et les bonnes pratiques d'architecture pour terminaux partagés.