Premier projet IAM
Projet IAM : commencez par un flux concret, pas par une architecture cible parfaite
Pour démarrer un projet IAM, le cadrage ne doit oublier ni les données ni les accès réels. Les premiers blocages sont souvent un extract RH indisponible, un identifiant impossible à réconcilier, un compte de service manquant ou une validation qui n’arrive pas — bien avant une question d’architecture cible.
Cadrez ces dépendances, puis mettez en œuvre un premier flux assez petit pour être synchronisé, testé et mis sous contrôle. Les enseignements de ce flux feront progresser les spécifications et le périmètre suivant.
Ce que vous mettez en service
Un premier IAM, c’est d’abord un flux qui fonctionne
Pas forcément un grand projet. Exemple : une arrivée saisie dans le SIRH produit le compte Active Directory sans ticket ni ressaisie.
SIRH
Une arrivée est validée par la RH.
Netwrix Identity Manager
Reçoit l’information, rapproche l’identité et applique les règles configurées.
Active Directory
Le compte et ses groupes de base sont créés automatiquement.
Règles définies avec la DSI
Doublons, données manquantes et erreurs sont traités comme convenu, pas improvisés.
Le premier socle peut être opérationnel sans que toutes vos applications soient automatisées. Le périmètre réel dépend de votre système RH, de vos annuaires, des données disponibles et des besoins validés.
Ce que vous achetez
- Le logiciel
- Netwrix Identity Manager, en souscription. Les capacités dépendent de l’édition retenue.
- La mise en service
- Ariovis configure, intègre, teste et met en production le flux sur un périmètre défini ensemble. Vous recevez des règles documentées, des tests et des consignes d’exploitation, pas un rapport de conseil.
- Les évolutions
- D’autres applications, populations ou processus peuvent être raccordés ensuite, après qualification technique et commerciale. Chaque ajout demande une adaptation.
La taille change le périmètre, pas le principe
Trois illustrations anonymisées de premiers périmètres possibles, pas des références clients.
- Industrie, environ 300 identités
- Remplacer une partie des scripts par un flux RH → annuaires Microsoft, en commençant par les arrivées et les départs.
- Banque et services financiers, environ 700 identités
- Fiabiliser le rapprochement personnes / comptes et la traçabilité des droits, sur quelques systèmes et événements prioritaires.
- Santé et médico-social, 2 000 à 2 500 collaborateurs multisites
- Relier la RH aux annuaires pour les arrivées, fins de contrat et changements d’affectation, puis intégrer les applications métiers progressivement.
Décision de périmètre
Un premier projet IAM part d’un problème, pas du catalogue d’une plateforme
Les plateformes IAM couvrent beaucoup de capacités : provisioning, rôles, workflows, revues, séparation des tâches, reporting. Votre premier problème n’en demande souvent qu’une partie. Le point de départ est un problème précis et un résultat que l’on peut vérifier, par exemple : « un nouvel arrivant a ses comptes standard le jour de son arrivée, sans ticket ».
Les cartographies d’éditeurs et études de marché, comme celles de Gartner, aident à découvrir les solutions et leurs familles. Elles ne disent pas quel périmètre traiter d’abord chez vous : cela dépend de vos sources, de vos règles et de qui décide.
Trois situations, trois points de départ
- Un problème circonscrit, des sources fiables, des règles connues
Point de départ : un premier flux ciblé, par exemple RH vers AD/Entra.
À vérifier : la source déclenche bien l’événement et les accès standard sont écrits quelque part.
- Un besoin transverse : revues, séparation des tâches, droits répartis sur de nombreuses applications
Point de départ : une approche IAM/IGA plus large peut se justifier.
À vérifier : des responsables identifiés pour valider et revoir, et une liste des applications concernées.
- Des identités, données sources ou responsabilités mal définies
Point de départ : clarifier d’abord qui est la source, quel identifiant fait foi et qui décide.
Automatiser une donnée fausse ne fait que propager l’erreur plus vite.
Aucune de ces approches n’est meilleure dans l’absolu. Une même organisation peut commencer par un flux ciblé tout en sachant qu’un besoin de gouvernance plus large viendra ensuite.
Exemple concret
Une arrivée de collaborateur, de la RH aux accès
Chaque maillon doit être connu avant d’automatiser. S’il manque, il devient un prérequis du premier lot, pas une raison de tout redessiner.
Événement RH
Le SIRH enregistre l’arrivée : date, fonction, site, manager.
Prérequis ou exception : saisie après le premier jour, champ manager vide.
Règles de gestion
Fonction et site déterminent les comptes et groupes standard.
Prérequis ou exception : règles connues seulement d’un administrateur.
Validation éventuelle
Un responsable valide ce qui sort du standard.
Prérequis ou exception : validateur absent : prévoir un suppléant ou un délai.
Comptes
Le compte AD/Entra est créé ou modifié automatiquement.
Prérequis ou exception : homonymes, compte déjà existant d’un ancien contrat.
Accès
Groupes, licence Microsoft 365 et applications raccordées sont attribués.
Prérequis ou exception : applications non raccordées : tâche manuelle tracée.
Contrôle et traçabilité
On vérifie que l’état réel correspond à l’attendu et on garde qui a décidé quoi.
Prérequis ou exception : écarts à traiter par une personne désignée.
Les prestataires suivent la même chaîne, mais leur source est rarement le SIRH : il faut savoir qui les déclare, qui fixe leur date de fin et qui vérifie que leurs droits sont réellement retirés. Gérer les accès des prestataires et intérimaires. Pour chiffrer ce périmètre, voyez ce qui fabrique le coût; pour le décrire à un éditeur ou un intégrateur, la trame de cahier des charges.
Méthodologie
Les étapes d’un premier projet IAM
Neuf étapes, dans l’ordre où elles se dépendent. Chacune produit un livrable court. Les trois premières tiennent en quelques semaines si les bonnes personnes sont disponibles.
Comprendre l’existant
Décrire comment les comptes sont créés, modifiés et retirés aujourd’hui, avec les outils réels (tickets, mails, scripts).
Livrable : Une page : qui fait quoi pour une arrivée, une mobilité, un départ.
Avec : Support IT, administrateurs AD/Entra, RH.
Déterminer les sources de vérité
Désigner pour chaque population la source qui fait foi et vérifier ses champs : identifiant, dates, service, manager.
Livrable : Tableau population → source → champs disponibles.
Avec : RH, responsable SIRH.
Peut attendre : Les populations sans source (prestataires) si elles sont peu nombreuses.
Définir le périmètre initial
Choisir une population, une source et une cible, avec un résultat observable.
Livrable : Périmètre écrit, avec ce qui en est exclu.
Avec : Sponsor, chef de projet.
Peut attendre : Les applications métiers difficiles.
Documenter arrivée, mobilité, départ
Écrire ce qui doit se passer, et quand, pour chaque mouvement du périmètre.
Livrable : Trois scénarios avec déclencheur, actions et délai.
Avec : RH, managers, IT.
Peut attendre : Les cas rares (retours, absences longues).
Identifier les premières cibles
AD/Entra d’abord, puis 1 à 5 applications qui concentrent les demandes et ont une interface exploitable.
Livrable : Liste des cibles avec mode d’accès et propriétaire.
Avec : Équipe système, propriétaires applicatifs.
Peut attendre : Les applications sans interface : une tâche manuelle suffit au départ.
Définir les règles essentielles
Nommage, groupes par défaut, accès standards de 2 ou 3 profils fréquents, délais de retrait.
Livrable : Règles écrites, testables.
Avec : IT, managers des profils retenus.
Peut attendre : Le modèle de rôles complet.
Choisir un premier lot réaliste
Vérifier que chaque élément du périmètre a ses données, ses accès et ses personnes disponibles.
Livrable : Lot 1 validé par le sponsor.
Avec : Chef de projet, sponsor.
Préparer le déploiement
Rapprocher les comptes existants, simuler en lecture seule, puis automatiser progressivement.
Livrable : Plan de recette par mouvement et critère de passage en automatique.
Avec : Intégrateur, administrateurs, RH.
Prévoir l’extension
Lister ce qui viendra ensuite (applications, demandes, revues) et la condition pour l’ouvrir.
Livrable : Liste ordonnée des lots suivants, révisable.
Avec : Sponsor, chef de projet.
Peut attendre : Tout ce qui n’a pas de besoin exprimé.
Les informations à récupérer la première semaine
- Un extract RH anonymisable avec identifiant, dates, service, managerRH / SIRH
- Un extract des comptes AD / Entra (actifs et désactivés)Équipe système
- Le nombre d’arrivées, mobilités et départs sur 12 moisRH
- La liste des applications avec leur propriétaire et leur mode d’authentificationDSI
- Les tickets d’arrivée et de départ d’un mois typeSupport IT
- Les noms du sponsor, du référent RH et du référent annuaireDirection
Projet IAM et réalité
Ce qui bloque un projet IAM n’est pas toujours ce que l’on avait prévu
Sur plusieurs projets suivis, l’accès aux environnements, les extractions et la disponibilité des équipes ont retardé le travail. Certains ont demandé davantage d’ateliers que prévu sans que tous les entrants soient prêts. Ailleurs, des données mêlant informations AD et RH sont restées inutilisables avant clarification ; un raccordement a dû s’arrêter devant une qualité de données insuffisante.
L’excès de précision peut aussi ralentir : un connecteur peut être spécifié plus loin que le besoin réel ne le justifie. Une architecture cible reste utile pour garder une direction, mais elle ne compense ni un extract RH absent, ni un compte de service non créé, ni une règle de réconciliation impossible à appliquer.
Accès techniques
Un environnement inaccessible, un VPN non ouvert ou un compte de service absent bloque la configuration et la recette avant même le premier développement utile.
Entrants
Un connecteur IAM reste théorique sans extract, format connu, documentation et données suffisamment représentatives pour être confrontées au modèle.
Données
Une qualité de données RH insuffisante peut empêcher le raccordement, même lorsque l’architecture IAM et les interfaces sont déjà connues.
Personnes disponibles
Le propriétaire applicatif, la RH, l’équipe annuaire et l’intégrateur doivent pouvoir expliquer, décider puis valider. Leur absence place le flux sur le chemin critique.
Ces constats sont issus de suivis de delivery et de risques de projets réels, ici entièrement anonymisés.
Ce qu’il faut mettre en place
Gouvernance et administration des identités : ce que cela veut dire pour un premier projet
Administrer les identités, c’est créer, modifier et retirer les comptes et leurs droits : synchroniser depuis la RH, provisionner dans AD / Entra et les applications, rapprocher l’existant, traiter les exceptions.
Les gouverner, c’est décider selon quelles règles ces actions se produisent : quelle source fait foi, quels profils donnent quels accès, qui valide, et comment on vérifie que les droits restent justes.
Le marché appelle l’ensemble IGA. Un premier IAM n’a pas besoin de tout le modèle : il relie les deux sur les mouvements les plus fréquents. Une règle simple produit une action fiable, et cette action peut être vérifiée.
Déclencher
Événement RH ou métier
Arrivée, mobilité, départ, fin de contrat.
puisAdministrer
Identité mise à jour
Le référentiel reconnaît la personne et ses comptes.
puisGouverner
Règle ou validation
Le profil décide automatiquement ; une personne valide l’exception.
puisAdministrer
Comptes et droits
Création, modification ou retrait dans AD / Entra et les applications.
puisGouverner
Contrôle
Rapprochement, comptes orphelins, revue ciblée, trace.
Ce qui manque quand l’un des deux est absent
- Administration sans règles : chaque arrivée passe par un mail ou un ticket, les anciens droits restent après une mobilité, personne ne sait dire qui a accès à quoi et pourquoi.
- Règles sans administration : la politique existe sur le papier, mais un départ dépend encore de quelqu’un qui pense à fermer chaque compte.
Ce qui peut attendre
Modèle de rôles complet, recertification de toutes les applications, contrôles de séparation des tâches : utiles plus tard, pas pour démarrer. Commencez par fiabiliser arrivée, mobilité et départ sur AD / Entra et quelques applications à fort volume, puis ajoutez les premières revues. Un IAM ne rend pas conforme à lui seul ; il fournit des règles appliquées et des traces.
Le bon premier périmètre
Commencez votre projet IAM par une chaîne d’identité courte et observable
Le point de départ le mieux étayé est souvent la chaîne RH / SIRH vers un référentiel d’identité, puis vers Active Directory, Entra ID ou une cible équivalente. Elle transforme des événements concrets — arrivée, mobilité et départ — en résultats visibles. Ce n’est pas une obligation : c’est un choix par défaut à confirmer.
Point de départ
Événement RH
Une arrivée, une mobilité utile ou un départ clairement défini.
Source
RH / SIRH
Fournit les données nécessaires au flux, avec une clé d’identité exploitable.
Pilotage
Référentiel d’identité
Reconnaît la personne, rapproche ses comptes et calcule l’action attendue.
Première cible
AD / Entra ID
Applique l’action et expose un état avant/après visible, testable et explicable.
Population
Une population homogène, par exemple les salariés internes standards.
Source
Une source d’identité clairement identifiée et exploitable.
Cible
AD, Entra ID ou une cible équivalente dont l’accès est maîtrisable.
Événements
Une arrivée, une mobilité utile et un départ définis sans ambiguïté.
Résultat
Un état avant/après visible, testable et explicable.
Ce flux est-il un bon candidat ?
01
Donnée source fiable ?
Les champs nécessaires au flux sont présents et suffisamment cohérents.
02
Cible accessible ?
Le protocole, le compte technique et l’environnement peuvent être obtenus.
03
Douleur réelle ?
Le flux représente un volume, une attente ou une intervention manuelle réellement observée.
04
Résultat mesurable ?
Vous pourrez vérifier que l’automatisation fonctionne mieux que le traitement actuel.
Si les quatre réponses sont oui, le flux est un bon candidat pour le premier lot. Si la donnée source ou l’accès à la cible manque, résolvez ou contournez cette dépendance avant d’élargir le périmètre.
Source d’identité
Avant d’automatiser, vérifiez que la RH peut déclencher une décision fiable
L’IAM doit reconnaître une personne de façon unique, rattacher ses comptes, prendre les décisions prévues et savoir quand son identité ou son affectation devient valide. Cela demande une clé stable, les attributs réellement utilisés par les règles et les dates utiles au cycle de vie des identités.
Le projet n’a pas besoin de « toutes les données RH ». Il a besoin des données nécessaires au premier flux. Si un départ doit désactiver un compte, la date de fin est critique. Si l’accès dépend du site ou du manager, ces informations deviennent critiques à leur tour.
Identifiant instable ou ambigu
S’il est impossible de déterminer qu’un compte correspond à une personne, la réconciliation — le rapprochement entre identités et comptes — devient fragile.
Attributs métier incomplets ou contradictoires
Le modèle ne peut pas automatiser une décision que la source ne permet pas de prendre : organisation, service, fonction, site ou manager ne deviennent critiques que si une règle les utilise.
Dates non exploitables
Une création ou une désactivation automatique a besoin d’un événement fiable : date de début, date de fin ou période de validité selon le flux retenu.
Les externes peuvent nécessiter une source et des règles différentes. Le premier projet IAM n’a pas à résoudre en même temps salariés, prestataires, intérimaires, comptes techniques et tous les cas particuliers.
Cadrage IAM
Vos spécifications doivent survivre au réel, pas le précéder intégralement
Un projet sérieux commence par des entretiens, des ateliers d’architecture, d’identité et de SIRH, puis par un premier niveau de spécifications. Mais ces spécifications doivent être maintenues et adaptées à ce qui est réellement implémenté. Des validations intermédiaires évitent l’effet tunnel entre modèle, synchronisation, rattachement à l’identité et provisioning — l’application automatique des créations, modifications et retraits.
Le bon cadrage fixe le périmètre, les responsabilités, les données, les interfaces et les critères de réussite. Il ne cherche pas à résoudre toutes les exceptions de toutes les applications futures avant le premier test.
À décider maintenant
- La population du premier flux
- La source autoritaire
- La première cible
- La règle de réconciliation
- Les événements couverts
- Les données nécessaires
- Les propriétaires et validateurs
- Les critères de recette
- Les accès techniques et prérequis
À décider plus tard si le premier flux n’en dépend pas
- Le détail de toutes les applications
- Des dizaines de connecteurs
- Le modèle de rôles exhaustif du groupe
- Toutes les exceptions futures
- La recertification universelle
- L’architecture détaillée de chaque extension
Ces sujets ne sont pas inutiles. Ils deviennent pertinents lorsque le périmètre livré les exige.
Delivery observable
Faites progresser le flux par états vérifiables
Testez à chaque passage avec des données proches du réel. La lecture seule ou le blocage temporaire du provisioning réduit les effets de bord avant l’activation.
- 01
Source exploitable
Un jeu de données réel ou représentatif est disponible. Les principaux champs sont compris et la clé d’identité est définie.
- 02
Synchronisation
L’IAM sait lire la source et charger les données attendues. Aucun provisioning automatique n’est nécessaire pour valider cette étape.
- 03
Réconciliation
Les identités sont correctement rapprochées des comptes ou objets de la cible. Les anomalies deviennent visibles et traitables.
- 04
Simulation / lecture seule
Le système calcule ce qu’il ferait sans appliquer aveuglément les modifications. Les responsables examinent les actions attendues.
- 05
Automatisation contrôlée
Les scénarios de recette sont validés. L’automatisation est activée uniquement sur le périmètre convenu.
Pilotage
Pilotez les dépendances, pas seulement le planning
Chaque semaine, le chef de projet doit voir ce qui empêche le prochain état vérifiable. Une tâche « côté client » sans propriétaire ni date reste une dépendance invisible : quelqu’un doit fournir l’extract RH, ouvrir la cible, valider la règle métier et accepter la recette.
- Ce qui se trouve sur le chemin critique
- Les prérequis qui manquent
- Les accès et extractions encore attendus
- Les décisions ou validations qui bloquent la suite
- La dérive du périmètre et du reste à faire
Le signal de santé utile
Le nombre de slides produites ne dit pas si le projet avance. Regardez plutôt si le prochain flux peut franchir son étape sans accès manquant, décision en attente ou responsable introuvable.
Projet IAM par étapes
Étendez après avoir prouvé le premier flux
Étape 1
Source + cycle de vie
Fiabiliser la chaîne d’identité et les arrivées, mobilités et départs sur le premier périmètre.
Étape 2
Accès standards
Ajouter quelques applications ou droits fréquents, simples à raccorder ou déjà portés par l’annuaire.
Étape 3
Contrôle
Élargir la réconciliation, faire apparaître les comptes orphelins et lancer de premières revues ciblées.
Étape 4
Extensions
Traiter les applications métier plus complexes, les workflows, les rôles enrichis et une gouvernance plus avancée.
Les méthodes de mise en œuvre distinguent les connecteurs simples, intermédiaires et complexes. Un connecteur qui demande du développement spécifique prend plus de temps et ajoute de la maintenance : son intérêt technique ne suffit pas à en faire le premier cas d’usage.
Réponse directe
Si vous devez lancer votre projet IAM demain
Identifiez une population, une source fiable et une cible maîtrisable. Obtenez les vraies données et les vrais accès, définissez comment une identité sera reconnue et ce que le premier flux doit produire, puis faites-le progresser de la synchronisation à l’automatisation par étapes testables. Gardez une architecture cible suffisamment claire pour ne pas vous enfermer, sans retarder le premier résultat pour modéliser des applications et des exceptions qui ne font pas encore partie du périmètre.
Pour poursuivre au bon moment
Approfondir seulement ce dont votre premier flux a besoin
Questions fréquentes
Les premières décisions d’un projet IAM
Par quoi commencer pour un projet IAM ?
Commencez par choisir une population, une source d’identité, un premier flux et une cible dont le résultat sera mesurable. Préparez ensuite les accès, données, responsables et validations qui permettent réellement de livrer ce flux.
Faut-il définir toute l’architecture IAM avant de commencer ?
Non pour l’exhaustivité, oui pour le minimum qui situe la source, l’IAM et la première cible. Le cadrage et les premières spécifications sont indispensables, mais ils doivent pouvoir évoluer lorsque l’intégration rencontre les données et les systèmes réels.
Faut-il commencer par le SIRH ou par Active Directory / Entra ID ?
Le SIRH est souvent la source des événements RH et AD ou Entra ID une première cible à forte valeur. C’est un bon choix par défaut, pas une obligation : la qualité des données, l’accès technique, la douleur réelle et la possibilité de mesurer le résultat doivent décider.
Quelles données RH faut-il pour démarrer un IAM ?
Une clé stable, les éléments qui identifient la personne, les attributs réellement utilisés par les règles — organisation, fonction ou manager par exemple — et les dates utiles au cycle de vie. Le SIRH n’a pas besoin d’être parfait partout.
Combien d’applications faut-il raccorder dans un premier projet IAM ?
Il n’existe pas de nombre universel. Le périmètre doit rester assez petit pour livrer et tester un flux de bout en bout. Une application complexe, spécifique ou mal documentée peut rejoindre une étape suivante.
Comment éviter l’effet tunnel dans un projet IAM ?
Faites valider le flux par états : modélisation des données, synchronisation, réconciliation, simulation puis provisioning. Testez et faites valider chaque passage avant d’activer l’automatisation suivante.
Choisir le premier flux
Vous savez que vous devez lancer l’IAM, mais pas encore quel flux choisir en premier ?
Confrontez le périmètre envisagé aux données, aux systèmes et aux dépendances réelles. L’objectif est de trouver un flux assez limité pour être livré, assez complet pour être testé, puis de préparer l’extension.
Netwrix édite la solution. Ariovis est l’équipe française avec laquelle vous la choisissez, l’achetez et la déployez.