Cadrer un premier lot
Premier lot IAM : la méthode du périmètre de survie
Le premier lot ne doit pas couvrir tout votre IAM. Il doit prouver qu’un flux d’identité peut fonctionner de bout en bout sans se faire bloquer par dix dépendances externes.
Tout mettre dans le lot 1
- Beaucoup d’applications
- Beaucoup d’équipes à mobiliser
- Des données encore imparfaites
- De nombreuses dépendances externes
- Une recette qui n’en finit pas
Périmètre de survie
- Une source d’identité exploitable
- Une population maîtrisée
- Un flux arrivée / changement / départ concret
- Un annuaire ou une cible maîtrisée
- Un résultat mesurable
Un bon premier lot n’est pas celui qui couvre le plus de choses. C’est le plus petit périmètre capable de faire fonctionner un flux d’identité complet, mesurable et reproductible, sans dépendre de prérequis que personne ne maîtrise encore.
Section 1
Le piège du « tout est prioritaire »
Au démarrage, chaque partie prenante a une bonne raison d’entrer dans le premier lot. Les RH veulent les arrivées et les départs. L’IT veut AD ou Entra ID. Une direction métier veut son application. Le RSSI veut les comptes orphelins. Quelqu’un ajoute les prestataires. Puis arrivent SAP, les workflows, la recertification et les rôles.
Le problème n’est pas que ces besoins soient mauvais. Le problème est que chaque élément ajoute ses propres dépendances : une équipe, un extract, un accès technique, une règle à trancher.
C’est le rayon de dépendances du lot — son blast radius projet. Plus le lot dépend simultanément d’équipes, de données, de systèmes et de décisions non stabilisées, plus une seule défaillance peut arrêter l’ensemble.
On ne réduit donc pas le premier lot en rayant des applications au hasard. On réduit le nombre d’inconnues simultanées.
Section 2
Sur les vrais projets, les premiers bloqueurs sont souvent beaucoup plus banals
Ce n’est pas forcément l’application la plus complexe du SI qui fait perdre les premières semaines. Un compte inaccessible, un extract absent ou une équipe applicative indisponible suffit à bloquer une chaîne entière.
Accès
Impossible de configurer ou de tester tant que les environnements, le VPN, les comptes de service ou les droits techniques ne sont pas ouverts.
Entrants
Un connecteur sans extract, sans format connu, sans documentation ni données représentatives reste un connecteur théorique.
Données
Sans clé fiable pour reconnaître une personne, ou avec des attributs incohérents, l’automatisation ne sait pas décider correctement.
Disponibilité des acteurs
Une application techniquement facile devient impossible à intégrer si personne ne peut expliquer ses données, ses droits ou valider la recette.
Ces quatre familles ressortent de plusieurs suivis de projets et registres de risques internes, anonymisés. Sur un projet, des attributs nécessaires à l’AD, un extract SIRH, des matrices et le modèle de données étaient encore attendus alors que l’intégration devait avancer.
Avant de demander « cette application est-elle importante ? », demandez « avons-nous réellement ce qu’il faut pour la raccorder et la tester ? ».
Section 3
Les trois faux amis du lot 1
« C’est juste un connecteur »
Derrière un raccordement annoncé comme simple se cachent souvent une synchronisation, du provisioning, un modèle de données, des règles de calcul, une réconciliation, des traitements automatiques et une recette de bout en bout. Sur un projet observé, une brique présentée comme un connecteur simple s’est révélée bien plus structurante une fois son fonctionnement réel découvert.
Simple
Mécanisme déjà maîtrisé, ou droits portés par un annuaire déjà raccordé.
Intermédiaire
API standard, SCIM, CSV ou autre protocole exploitable.
Complexe
Développement spécifique, logique particulière, maintenance supplémentaire.
Cette distinction vient de la méthode de mise en œuvre que nous utilisons. Ce n’est pas une nomenclature universelle : elle sert à estimer l’effort, pas à classer les applications une fois pour toutes.
« On a un fichier RH, donc la source est prête »
Un fichier disponible n’est pas encore une source d’identité exploitable. Il faut au minimum savoir comment reconnaître une personne de façon stable, quelles données pilotent les accès, et à quelles dates une identité ou une affectation deviennent valides.
Automatiser un départ
La date de fin doit être exploitable.
Attribuer selon le manager
La relation manager doit être fiable.
Attribuer selon le site
Le site doit être renseigné de façon exploitable.
Cela ne veut pas dire qu’il faut un SIRH parfait avant de commencer. Seuls les champs utilisés par le flux retenu doivent être fiables.
« L’application métier la plus importante doit forcément être dans le lot 1 »
Criticité métier et aptitude à entrer dans un premier lot sont deux critères différents. Une application essentielle mais très spécifique, mal documentée ou dépendante de développements sur mesure peut attendre. À l’inverse, un annuaire, ou une application à gros volume avec une interface maîtrisée, démontre beaucoup plus vite que le modèle fonctionne.
Section 4
La méthode du périmètre de survie
Quatre questions suffisent pour tester chaque élément candidat : une population, une source, une application, un accès.
Ai-je une source exploitable ?
- Une source autoritaire, ou au moins un mécanisme clairement défini, alimente les identités de la population choisie.
- Les attributs nécessaires au flux existent et sont suffisamment fiables.
Puis-je suivre une identité de bout en bout ?
- On reconnaît sans ambiguïté la même personne entre la source et la cible.
- La corrélation est assez claire pour tester réellement le processus, pas seulement en théorie.
La cible est-elle raccordable aujourd’hui ?
- Accès, compte de service, protocole, extract ou API sont disponibles ou obtenables dans le calendrier du lot.
- Un interlocuteur applicatif et un environnement de recette existent.
Puis-je démontrer le résultat ?
- Le flux produit un résultat observable : créer, modifier ou désactiver un compte, affecter un accès standard, réconcilier un compte.
- On peut montrer qu’une intervention manuelle a disparu.
Si une brique échoue sur plusieurs de ces quatre points, elle n’est probablement pas prête pour le lot 1. Cela ne veut pas dire qu’elle est abandonnée : elle devient un chantier de préparation, ou un lot suivant.
Section 5
À quoi ressemble un bon premier lot
Un exemple, pas un modèle valable partout. Adaptez-le à votre source et à vos cibles.
Population
Collaborateurs internes standards.
Source
SIRH ou source RH dont les attributs nécessaires sont identifiés.
Événements
Arrivée, modification utile, départ.
Première cible
AD / Entra ID, ou une cible équivalente déjà maîtrisée.
Accès
Quelques accès standards compréhensibles, si leur règle d’attribution est stable.
Contrôle
Vérifier qu’un événement RH produit l’état attendu, et savoir expliquer le résultat.
Ce lot est volontairement peu spectaculaire. Sa valeur est ailleurs : il construit le premier chemin réutilisable. Une fois ce chemin fiabilisé, d’autres populations, applications, rôles, workflows ou contrôles s’ajoutent progressivement.
Section 6
Ce qu’il est raisonnable de laisser hors du lot 1
Un premier projet étroit, mesurable et extensible rend service plus vite qu’un big-bang.
- Le role mining exhaustif de toute l’organisation.
- La modélisation complète des combinaisons de droits à risque (SoD) avant d’avoir fiabilisé le cycle de vie.
- Des dizaines de connecteurs rares ou fortement personnalisés.
- La recertification universelle de tout le SI.
- Les populations très spécifiques dont les règles de gestion ne sont pas encore maîtrisées.
- Les applications complexes retenues parce qu’elles sont prestigieuses ou politiquement importantes.
SAP n’est pas interdit dans un premier lot. En revanche, une intégration SAP comportant des rôles complexes, des exceptions locales, de la séparation des tâches, des développements spécifiques ou des données insuffisamment maîtrisées doit être évaluée comme telle, et non comme « une application de plus ».
Section 7
Les données RH réellement rédhibitoires
Il n’existe pas de liste universelle de champs obligatoires. Une donnée devient critique lorsqu’une décision du lot 1 dépend d’elle.
Décision à automatiser
Donnée critique
Reconnaître la personne
Un identifiant stable, utilisable comme clé de corrélation.
Activer ou désactiver à la bonne date
Les dates de validité réellement exploitables.
Donner un accès selon l’organisation
Site, entité, département, fonction : l’attribut utilisé par la règle.
Faire approuver par le manager
Une relation manager fiable.
Ne transformez pas un projet IAM en projet de nettoyage global du SIRH. Corrigez d’abord les données nécessaires aux décisions automatisées du périmètre choisi.
Cette règle de décision est issue du croisement du modèle de données d’identité et des retours projet. Ce n’est pas une mesure relevée telle quelle dans un registre de risques.
Section 8
Dire non sans bloquer le projet
Au lieu de
« Cette application n’est pas prioritaire. »
Préférez
« Elle est bien dans la trajectoire. Mais son accès technique, son modèle de données, ses règles ou son mécanisme de provisioning ne permettent pas encore de la mettre dans le chemin critique du premier lot. Nous préparons ces prérequis pendant que le premier flux est livré. »
Un périmètre réduit ne signifie pas « non ». Il signifie « pas encore dans le chemin critique ».
Section 9
Votre lot 1 tient-il debout ?
Un filtre de décision, pas une checklist administrative. Si plusieurs lignes restent floues, le périmètre n’est pas encore figé.
- La population est clairement définie.
- La source d’identité est connue.
- Les données qui pilotent le flux sont exploitables.
- La corrélation entre source et cible est possible.
- Les accès techniques sont disponibles ou engagés.
- Les équipes nécessaires peuvent participer.
- La cible peut être synchronisée ou provisionnée avec un mécanisme compris.
- La recette peut tester un scénario de bout en bout.
- Un résultat mesurable existe.
Si vous ne pouvez pas raconter le parcours d’une identité, du déclencheur RH jusqu’au résultat attendu dans la cible, votre lot est probablement encore un catalogue de besoins plutôt qu’un périmètre livrable.
Pour aller plus loin
Les briques que votre lot 1 va manipuler
Questions fréquentes
Ce qu’on nous demande au moment du cadrage
Faut-il attendre que les données RH soient propres pour démarrer ?
Non. Une donnée devient critique lorsqu’une décision du lot 1 dépend d’elle. Corrigez d’abord les champs qui pilotent le flux retenu ; une donnée sans effet sur ce flux ne doit pas repousser le projet.
Et SAP dans un premier lot ?
SAP n’est pas interdit dans un premier lot. En revanche, une intégration comportant des rôles complexes, des exceptions locales, de la séparation des tâches, des développements spécifiques ou des données insuffisamment maîtrisées doit être évaluée comme telle, et non comme « une application de plus ».
Comment refuser une application sans bloquer le projet ?
En parlant de chemin critique, pas de priorité. Elle reste dans la trajectoire : c’est son accès technique, son modèle de données, ses règles ou son mécanisme de provisioning qui ne permettent pas encore de la mettre dans le chemin critique du premier lot. Ces prérequis se préparent pendant que le premier flux est livré.
Combien d’applications dans un lot 1 ?
La bonne question n’est pas le nombre d’applications mais le nombre d’inconnues simultanées. Une cible maîtrisée et un flux complet valent mieux que cinq raccordements partiels dépendant chacun d’une équipe différente.
Passer à l’action
Définir mon premier périmètre IAM
Partez de votre source d’identité, de vos populations et de quelques applications candidates pour identifier ce qui peut réellement tenir dans un premier lot. Préparez sérieusement ce qui peut bloquer, puis lancez un flux limité, complet et mesurable. Le reste devient une trajectoire d’extension, pas une condition pour commencer.
Netwrix édite la solution. Ariovis est l’équipe française avec laquelle vous la choisissez, l’achetez et la déployez.