Deprovisioning / Joiners-Movers-Leavers
generalDéfinition
Le processus Joiners-Movers-Leavers (JML), également appelé gestion du cycle de vie des identités (Identity Lifecycle Management), est le cadre organisationnel et technique qui gère les droits d'accès des utilisateurs à chaque étape de leur parcours dans l'organisation : à l'arrivée (Joiner), lors d'un changement de poste (Mover), et au départ (Leaver). Le Deprovisioning est la phase critique de suppression des accès lors du départ. Le Joiner (arrivée) déclenche la création des comptes et l'attribution des accès appropriés au nouveau poste. Un processus Joiner efficace automatise : création du compte Active Directory, attribution des groupes correspondant au rôle, provisioning des applications métier (Office 365, CRM, ERP), configuration de la messagerie, et remise du poste de travail configuré. L'objectif est que le nouvel employé soit opérationnel dès son premier jour sans délais liés aux processus manuels de provisioning IT. Les solutions IGA (SailPoint, Saviynt) intègrent avec les systèmes RH (Workday, SAP HR) pour déclencher automatiquement le provisioning dès que le RH valide l'embauche. Le Mover (mobilité interne) est souvent la phase la plus négligée. Un changement de poste doit déclencher : la suppression des accès liés à l'ancien poste (qui ne sont plus nécessaires), l'attribution des accès liés au nouveau poste, et une revue des droits résiduels. Sans ce processus, le "privilege creep" s'accumule — un employé qui a changé de poste trois fois a souvent les droits de ses trois postes précédents, violant le principe du moindre privilège. Automatiser les Movers via l'intégration IGA-RH (le changement de poste dans le SIRH déclenche automatiquement la mise à jour des droits) est la meilleure pratique. Le Leaver (départ) est la phase la plus critique pour la sécurité. Un employé qui quitte l'organisation mais conserve des accès actifs représente un risque majeur (intentionnellement ou non — accès conservés par erreur, malveillance d'un employé mécontent). Les statistiques sont alarmantes : selon plusieurs études, les anciens employés conservent des accès actifs pendant 36 jours en moyenne après leur départ. Le Deprovisioning doit être immédiat (dès que le départ est confirmé, idéalement avant même que l'employé quitte les locaux) et exhaustif (tous les comptes : AD, email, applications SaaS, VPN, accès physiques, comptes cloud AWS/Azure).
Deprovisioning immédiat — procédures d'urgence
Le deprovisioning lors d'un départ non planifié (licenciement, départ conflictuel) doit être géré comme une urgence de sécurité. Checklist deprovisioning immédiat : (1) Désactiver le compte Active Directory (désactiver, pas supprimer — pour conserver l'audit trail) ; (2) Révoquer toutes les sessions actives (AAD : révoquer les refresh tokens via `Revoke-AzureADUserAllRefreshToken`, Microsoft 365 : sign-out de toutes les sessions) ; (3) Changer les mots de passe des comptes de service dont l'employé avait connaissance ; (4) Désactiver les accès VPN ; (5) Révoquer les accès aux applications SaaS (Salesforce, GitHub, AWS IAM) ; (6) Désactiver les accès physiques (badges) ; (7) Récupérer les équipements (laptop, téléphone) ; (8) Archiver la boîte mail. Une procédure documentée et testée annuellement garantit que rien n'est oublié lors d'un départ sous pression.
Intégration IGA-RH — provisioning automatique
L'intégration entre le SIRH (Système d'Information RH — Workday, SAP HR, Cegid) et la solution IGA (SailPoint, Saviynt, One Identity) est le fondement d'un processus JML automatisé. L'objectif est que tout événement RH (embauche, mutation, départ, changement de titre) déclenche automatiquement les actions IAM correspondantes sans intervention manuelle IT. Le flux typique : le manager valide le recrutement dans Workday → SailPoint reçoit l'événement via une API ou un connecteur → SailPoint évalue le rôle de la personne (basé sur son département, localisation, type de contrat) → provisioning automatique des accès correspondants dans AD, Office 365, et les applications métier définies dans les rôles. Ce modèle "role-based provisioning automatique" garantit la cohérence des accès et élimine les délais de provisioning manuel (qui frustraient les nouveaux arrivants et surchargeaient les équipes IT).
Orphan Accounts — comptes orphelins et risques
Les comptes orphelins (Orphan Accounts) sont des comptes Active Directory ou applicatifs qui existent mais ne sont associés à aucun employé actif — soit parce que l'employé est parti sans deprovisioning correct, soit parce que le compte a été créé pour un projet et jamais désactivé, ou parce que c'est un compte de service non documenté. Ces comptes représentent un risque de sécurité élevé : ils sont souvent moins surveillés que les comptes actifs, peuvent avoir des mots de passe anciens et faibles (jamais changés), et représentent une surface d'attaque invisible. Une campagne de nettoyage des comptes orphelins (identifiés par leur date de dernière connexion — tous les comptes sans connexion depuis 90 jours sont suspects) doit être réalisée trimestriellement. La corrélation entre les comptes AD actifs et les employés actifs dans le SIRH permet d'identifier automatiquement les comptes orphelins.
Ce terme vous interpelle ?
Nos experts interviennent sur toutes les thématiques de ce glossaire — pentest, conformité NIS 2 / ISO 27001, forensics, sécurité IA. Réponse sous 24h, devis gratuit et sans engagement.