Les cycles de vie d'une identité

L'arbre décisionnel

Un événement arrive d'une source d'autorité. Que faut-il en faire ? Répondez aux questions : chaque branche mène au traitement attendu et à son point de vigilance. La carte en dessous situe votre position dans l'arbre complet — vous pouvez aussi y naviguer directement.

Les branches qui font dérailler les modèles

En parcourant l'arbre, un constat revient : le risque ne se situe pas aux extrémités du cycle, mais dans ses branches intermédiaires. Trois d'entre elles méritent d'être arbitrées dès le cadrage.

• ↗

  Le pic de la mutation

  La période de recouvrement est le moment où une identité détient le plus de droits de toute sa carrière. Elle est légitime — mais elle doit expirer d'elle-même.

• ⌁

  Le palier de la dispense

  Entre la dispense de préavis et la fin de contrat, la personne est active dans le SIRH mais absente de l'entreprise. Aucune règle fondée sur le seul statut RH ne traite ce cas.

• ⧉

  Le doublon de l'internalisation

  Deux sources décrivent la même personne. Sans clé de rapprochement stable, l'organisation se retrouve avec deux identités actives — et n'en révoquera qu'une.

Les questions à poser en tant qu'intégrateur

Ces questions n'ont pas de bonne réponse universelle : elles ont une réponse propre à chaque organisation. Le rôle de l'intégrateur est de les poser tôt, d'obtenir un arbitrage explicite, et de le faire écrire — parce qu'elles reviendront toutes en recette.

• Quelle est la source d'autorité, et que fait-on quand elles se contredisent ?

  Une identité est rarement décrite par une seule source. Le SIRH connaît le contrat, l'annuaire connaît le poste réel, le référentiel prestataires connaît la mission.

  Déterminez la source faisant foi attribut par attribut, et non globalement. Le SIRH peut être maître sur la date de sortie tout en étant systématiquement en retard sur le rattachement hiérarchique.

  Prévoyez aussi le cas où la source ne dit plus rien : une identité disparue du flux ne doit pas être interprétée comme un départ, sinon une panne d'export révoque toute l'entreprise.

• Quel identifiant garantit l'unicité d'une personne dans le temps ?

  Le matricule paraît naturel — mais il change lors d'une internalisation, d'une mutation entre entités juridiques ou d'une réembauche. Le nom n'est pas unique. L'adresse mail est dérivée, donc instable.

  Il faut un identifiant interne propre à l'IGA, sans signification métier, généré une fois et jamais réutilisé, auquel viennent se rattacher les identifiants successifs des sources.

  Formulez la question autrement pour la rendre concrète : si cette personne revient dans cinq ans, comment la reconnaîtrez-vous ?

• Quelle date fait foi : celle de l'événement ou celle de sa détection ?

  Un changement est publié le 3 pour une prise d'effet le 30 ; une mutation est saisie avec deux semaines de retard, donc avec effet rétroactif.

  Le moteur doit distinguer la date d'effet de la date de traitement, savoir planifier dans le futur, et décider explicitement du comportement en cas d'effet passé : rattraper immédiatement, ou ignorer ?

  Sans cette distinction, vous obtiendrez soit des révocations prématurées, soit des droits ouverts après la sortie.

• Que fait-on des droits attribués en dehors du modèle ?

  La réconciliation révélera toujours des accès qu'aucune règle ne justifie : attribués à la main, hérités d'un projet, ou créés directement dans l'application.

  Trois politiques possibles, à choisir consciemment : les tolérer et les tracer, les rattacher à l'identité comme exceptions à revoir en campagne, ou les supprimer automatiquement.

  La troisième option est la plus vertueuse et la plus dangereuse : appliquée trop tôt, elle coupe des accès que personne n'avait documentés mais dont la production dépend.

• À qui appartiennent les comptes sans propriétaire ?

  Comptes de service, comptes techniques, comptes génériques partagés par une équipe, comptes de test : ils ne correspondent à aucune personne physique et échappent donc au cycle de vie.

  Ils doivent malgré tout avoir un propriétaire humain responsable, une date de revue et une justification. Faute de quoi ils deviennent l'angle mort permanent du dispositif.

  Question complémentaire : que se passe-t-il quand ce propriétaire quitte l'entreprise ? La réponse doit être automatique.

• Quel délai est acceptable entre l'événement et son application ?

  Une révocation immédiate au départ suppose un flux temps réel. Un traitement nocturne laisse une fenêtre de plusieurs heures.

  Ce délai est un arbitrage entre risque et coût, pas un paramètre technique. Il se décide avec la sécurité et se contractualise.

  Prévoyez également la procédure d'urgence : en cas de licenciement pour faute, il faut pouvoir couper en quelques minutes, hors du cycle nominal.

• Que se passe-t-il quand la cible ne répond pas ?

  Une application en maintenance, un connecteur en erreur, un quota atteint : l'ordre de provisioning échoue.

  Définissez la stratégie de reprise (nombre de tentatives, temporisation), le devenir des demandes en attente, et surtout qui est alerté. Un rejet silencieux crée un écart durable entre ce que l'IGA croit et ce qui existe.

  Cas le plus critique : l'échec d'une révocation. Il doit être traité comme un incident de sécurité, pas comme une simple erreur technique.

• Combien de temps conserve-t-on une identité après le départ ?

  Trop peu : vous perdez l'historique d'audit et la capacité à traiter une réembauche. Trop longtemps : vous conservez des données personnelles sans base légale.

  C'est une décision juridique, à faire trancher par le métier et le DPO, puis à implémenter comme une règle datée et traçable.

  Distinguez trois horizons : désactivation (immédiate), archivage (moyen terme), suppression ou anonymisation (échéance légale).

• Qui valide quand le validateur n'est plus là ?

  Les circuits d'approbation reposent sur le manager. Or celui-ci peut être absent, parti, ou être précisément la personne concernée par la demande.

  Prévoyez l'escalade vers le N+1, la délégation temporaire, le comportement en cas d'absence de réponse (approbation tacite ou rejet — rarement l'approbation), et l'auto-validation, qui doit être interdite.

• Le modèle sait-il gérer plusieurs relations simultanées ?

  Une même personne peut cumuler deux contrats, être salariée d'une filiale et prestataire d'une autre, ou occuper deux postes à temps partiel.

  Décidez si votre modèle repose sur une identité par personne (avec plusieurs relations rattachées) ou sur une identité par contrat. Le premier choix est plus juste et nettement plus exigeant.

  La conséquence pratique : la fin d'un contrat ne doit pas déclencher un départ si un autre reste actif.

• Peut-on rejouer, simuler et revenir en arrière ?

  Avant d'activer une règle sur une population entière, il faut pouvoir mesurer son impact : combien de droits seraient retirés, à qui, et avec quelles conséquences.

  Exigez un mode simulation et une exécution par vagues. Une règle de retrait appliquée d'un coup à cinquante mille identités ne se corrige pas en annulant : elle se corrige en réattribuant, ce qui prend des jours.

• Comment l'organisation absorbera-t-elle ses propres changements ?

  Fusion, réorganisation, création d'entité, changement de convention de nommage : le référentiel bougera plus vite que le modèle de rôles.

  Prévoyez dès la conception qui possède le modèle après la mise en production, à quelle fréquence il est revu, et selon quel processus il évolue. Un modèle de rôles sans propriétaire se dégrade en dix-huit mois.