À retenir

• Le modèle JML (Joiner-Mover-Leaver) structure le cycle de vie d’une identité numérique autour de trois événements : l’arrivée, la mobilité interne et le départ.
• Le Mover est le maillon faible du dispositif : on attribue facilement les nouveaux droits, mais on oublie de retirer les anciens. C’est la cause principale de l’accumulation des accès.
• JML ne se limite pas aux employés : prestataires, stagiaires, comptes techniques et partenaires ont chacun leur cycle de vie, souvent hors du SIRH.
• Un processus JML solide repose sur l’identification des sources d’autorité par population, des délais explicites par type d’événement, et une réconciliation régulière entre l’état attendu et l’état réel des accès.

Introduction

Un collaborateur qui change de poste trois fois en dix ans dans la même organisation accumule, dans une majorité de cas, les droits cumulés de ses trois postes. Le problème n’est pas qu’il ait quitté l’organisation sans qu’on ne désactive ses comptes — ça, c’est généralement détecté. Le problème est qu’à chaque mobilité, on lui a ajouté les droits du nouveau poste sans retirer ceux de l’ancien. Ce silence du Mover est la première cause d’accumulation d’accès dans les organisations.

Le modèle JML (Joiner-Mover-Leaver) est le cadre qui structure le cycle de vie d’une identité numérique pour éviter ce type de dérive. Cet article le présente côté IAM/IGA, en clarifiant ses trois phases, ses points de fragilité réels — pas ceux dont parle le marketing — et la démarche pour le mettre en place.

Qu’est-ce que le cycle de vie des identités ?

Le cycle de vie d’une identité numérique recouvre l’ensemble des états par lesquels elle passe entre sa création et sa suppression définitive : provisioning initial, attributions de droits, changements de fonction, suspensions temporaires, désactivation, archivage, suppression. Pour chaque état, des droits sont attribués, ajustés ou retirés.

Le modèle JML structure ce cycle autour de trois grands événements : l’arrivée (Joiner), la mobilité interne (Mover) et le départ (Leaver). C’est un cadre simple — peut-être un peu trop, comme on va le voir — mais il a l’immense avantage d’aligner la gestion des accès sur des événements concrets et déclencheurs, plutôt que sur des décisions ponctuelles et arbitraires. L’ISO/IEC 27001:2022 attend d’une organisation qu’elle gère ce cycle de manière maîtrisée dans le cadre de ses contrôles d’accès (notamment 5.16, gestion des identités, et 5.18, droits d’accès).

Les trois phases en détail

Joiner : l’arrivée

À l’arrivée, on attribue les droits de base nécessaires à l’opérationnalité — souvent appelés birthright, ceux qui découlent automatiquement du poste, de l’entité et de la localisation — en créant l’identité numérique qui les porte. L’objectif est d’avoir un collaborateur opérationnel dès le premier jour : messagerie, accès aux applications de base, droits métier de son rôle initial.

Le Joiner concentre naturellement l’attention : un nouvel arrivant qui ne peut pas travailler le matin de son arrivée est un échec visible et coûteux. C’est aussi la phase pour laquelle les plateformes IGA proposent le plus de mécaniques prédéfinies, généralement déclenchée par un événement « embauche » remonté par la source d’autorité RH.

Mover : la mobilité interne

À chaque changement de fonction, de service ou d’affectation projet, les droits doivent évoluer : ajouter ceux du nouveau périmètre, retirer ceux de l’ancien. La phrase soulignée n’est pas anodine : dans la pratique, l’ajout est presque toujours fait, le retrait beaucoup plus rarement. C’est précisément ce qui transforme un changement de poste en accumulation de droits.

Leaver : le départ

Au départ, qu’il soit volontaire ou non, planifié ou immédiat, les accès doivent être retirés selon des règles cohérentes avec le risque. Une bonne pratique consiste à distinguer au moins trois temps : la suspension immédiate des comptes (le jour J ou avant pour un départ sensible), la désactivation complète dans un délai court, et la suppression définitive après une période de conservation alignée sur les obligations légales et les besoins de traçabilité.

Le Leaver concentre lui aussi l’attention, pour une raison différente du Joiner : la pression de sécurité (un ex-collaborateur qui conserve des accès) et la pression de conformité (les comptes orphelins remontent vite dans un audit).

Le Mover, maillon faible

Joiner et Leaver sont visibles et urgents ; le Mover ne l’est pas. C’est exactement ce qui le rend dangereux. Trois raisons concrètes expliquent cette fragilité :

D’abord, l’asymétrie entre ajout et retrait. Le collaborateur lui-même signale s’il manque un accès indispensable à sa nouvelle fonction — il ne signale pas qu’il en a un en trop. Personne, dans la chaîne, n’a un intérêt direct à demander un retrait.

Ensuite, le manque de visibilité. Sans plateforme IGA, l’information « cette personne avait ces droits, en a-t-elle encore besoin ? » n’est nulle part. Et même avec un outil, encore faut-il que le changement de poste soit qualifié comme un événement de mobilité et pas comme une simple mise à jour de fiche RH silencieuse.

Enfin, la qualité de l’information de mobilité. Toutes les mobilités ne passent pas par le SIRH (mission interne de quelques mois, changement de manager sans changement de poste officiel, prestataire qui change d’équipe). Sans signal, pas de déclenchement.

La réponse n’est pas un outil de plus, mais une discipline : traiter le Mover comme un événement à part entière, qui déclenche un retrait explicite des droits liés à la fonction précédente — quitte à les ré-attribuer ensuite s’ils sont aussi pertinents pour la nouvelle. Et en complément, des campagnes de recertification régulières pour rattraper ce qui aura inévitablement glissé. Cette logique se combine avec la démarche de role mining, qui structure les droits par fonction et facilite leur retrait au moment de la mobilité.

Au-delà des employés : tout ce que JML doit couvrir

Une grande partie des contenus disponibles sur JML implique, sans le dire, qu’on parle uniquement des salariés. La réalité opérationnelle est plus large.

Les prestataires et consultants externes ont un cycle de vie souvent plus court et plus difficile à suivre : début et fin de mission peuvent ne pas remonter au SIRH, voire ne pas être tracés du tout. Les stagiaires, alternants et intérimaires ont des cycles spécifiques, avec un risque élevé d’oubli du retrait. Les comptes techniques (comptes de service, comptes applicatifs, identités machines) ont eux aussi un cycle de vie, avec un propriétaire identifiable à maintenir et une date de revue à fixer — point trop rarement traité comme tel. Enfin, les identités partenaires et clients B2B relèvent davantage du CIAM, mais s’inscrivent dans la même logique de gouvernance du cycle de vie.

Pour chacune de ces populations, deux questions doivent être tranchées : quelle est la source d’autorité ? et quel est l’équivalent du Mover ? Pour un prestataire, le « Mover » peut être un changement de mission ; pour un compte technique, un changement de propriétaire.

Sources d’autorité : le SIRH et après

Le SIRH (système d’information RH) peut être la source d’autorité pour les salariés, à condition d’en être véritablement un : un SIRH connaît les fonctions, les rattachements organisationnels et les mobilités — un simple SI de paie sait combien on paye qui, pas ce que la personne fait dans l’organisation. Confondre les deux conduit à bâtir un processus JML sur une source qui ne porte pas l’information dont il a besoin.

Mais le SIRH ne couvre presque jamais l’ensemble des populations. Pour les prestataires et externes, il faut souvent une source complémentaire : outil de gestion des contrats, plateforme de gestion des prestataires, voire un référentiel maintenu manuellement. Pour les comptes techniques, c’est un référentiel dédié — parfois construit pour l’occasion.

L’enjeu est moins technique que méthodologique : identifier explicitement la source d’autorité pour chaque population et l’inscrire dans le processus, plutôt que de laisser les identités « hors SIRH » exister sans gouvernance.

Mettre en place un processus JML

La démarche, en grandes étapes :

1. Cartographier les populations : salariés, prestataires, stagiaires, comptes techniques, partenaires. Chaque population a ses spécificités.
2. Identifier la source d’autorité par population. SIRH pour les salariés, et explicitement quoi pour les autres.
3. Définir la matrice événement → action. Pour chaque type d’événement (embauche, mobilité, fin de mission, départ), lister les actions IAM attendues : créer/modifier/désactiver/supprimer quoi, avec quel délai.
4. Connecter les sources à la plateforme IGA, ou à défaut, ritualiser les transmissions d’information.
5. Définir les délais (SLA). Pas le même délai pour suspendre la messagerie d’un Leaver à risque et pour supprimer son compte de domaine. Pas le même délai pour ajouter un accès à un Joiner et pour retirer un accès à un Mover.
6. Tracer et réconcilier. Toutes les actions doivent être loguées, et l’état attendu doit être périodiquement comparé à l’état réel des systèmes pour détecter les écarts. C’est la clé du lien avec la recertification.

Une vérification SoD à chaque mobilité est également un garde-fou utile : un Mover peut créer involontairement un cumul de droits interdits si l’ancien rôle n’est pas retiré et que le nouveau y entre en conflit. C’est l’un des points d’articulation directs entre le JML et la séparation des tâches.

Erreurs fréquentes

• Traiter le Mover comme une simple mise à jour. Sans retrait explicite, l’accumulation est inévitable.
• Abandonner le cycle de vie des comptes techniques. Créés un jour, oubliés ensuite, sans propriétaire identifié : c’est une dette de sécurité qui grossit.
• Délai de désactivation flou pour les Leavers. « Le compte sera désactivé sous peu » n’est pas un délai. Sans SLA explicite, la pratique varie d’un cas à l’autre.
• Pas de propriétaire identifié pour les identités hors SIRH. Les prestataires existent dans les systèmes mais personne n’est responsable de signaler leur fin de mission.
• Pas de réconciliation entre l’état attendu et l’état réel. Le JML automatisé donne une fausse confiance : il faut vérifier que ce que l’on croit avoir provisionné l’est effectivement, et que ce qui devrait avoir été retiré l’a été.

FAQ

Quelle différence entre JML et provisioning ? Le JML décrit le cadre événementiel (arrivée, mobilité, départ). Le provisioning est l’action technique d’attribuer ou de retirer des droits qui en découle. JML déclenche, provisioning exécute.

Le Mover est-il vraiment plus risqué que le Leaver ? Pas plus risqué intrinsèquement, mais bien plus insidieux. Le Leaver est urgent et visible ; un audit interne le détecte. Le Mover est silencieux : il faut le chercher activement, et il s’accumule pendant des années.

Faut-il un outil dédié pour faire du JML ? À petite échelle, un processus formalisé et appliqué rigoureusement peut suffire. À mesure que les populations se diversifient (salariés, prestataires, comptes techniques) et que les systèmes cibles se multiplient, une plateforme IGA devient nécessaire pour automatiser et tracer.

Le SIRH est-il toujours la source de vérité pour le JML ? Pour les salariés, oui. Pour les autres populations (prestataires, comptes techniques, externes), non — il faut identifier des sources d’autorité alternatives. C’est l’un des points souvent sous-estimés d’un projet JML.

Conclusion

Le modèle JML est simple à énoncer, plus difficile à tenir. Sa réussite ne se mesure pas à l’efficacité du Joiner — c’est le plus facile — mais à la rigueur avec laquelle le Mover est traité et à la capacité à couvrir l’ensemble des populations, pas seulement les salariés. Pour démarrer concrètement, le plus utile est de cartographier les populations et leurs sources d’autorité, puis de définir une matrice événement → action avec des délais explicites, avant de chercher l’outillage. Un JML automatisé sur des bases floues automatise les approximations.

Sources

• ISO/IEC 27001:2022, Annexe A — contrôles 5.16 (gestion des identités) et 5.18 (droits d’accès), qui encadrent la gestion du cycle de vie des identités et des accès.