A user is a natural person who has a contractual relationship with the company and who can be granted access to IT resources.
Error #1: Confusing the HRIS with the user repository
"Can you give me a list of all the employees please?". This is the request that the IT department sends to the HR department for a list of users in the company.
In this request, there are 2 problems: the request is addressed to the HR department and it refers to "employees."
Why is this a problem? Because this HR repository is only partial. HR departments generally manage internal employees, those who are part of a recruitment process and who have a payslip.
By requesting information from the HR department, a blind spot is created on a sometimes significant portion of users: temporary workers, external service providers, consultants, etc.
Users (in the IT sense of the term) are not just employees: temporary workers or freelancers, for example, have a contractual relationship with the company and must regularly have access to internal applications. It is therefore necessary to deal with these "HR side" categories who are users absent from the HRIS.

Error #2: Using an identity repository as a user repository
Within the IT department, the question arises: how to get a list of all HR and non-HR users currently present in the company?
And then, the idea springs forth like a cry of victory: "we already have a place where we store all the users! It's the AD!"
Beyond the fact that shouting this sentence confuses "users" (physical persons) and "identities" (access accounts), it is very dangerous to use a technical tool like AD to centralize users: if we want to use this repository to determine the legitimacy of authorizations for users, it's a bit like the snake biting its tail.
The Active Directory is not designed for this purpose; its original use should not be twisted to include all users. For example, what about a temporary worker who is entered into the AD to declare their arrival but does not need an AD account?
The AD is not an HR source, and even less a "golden source" (it contains many system accounts that should be excluded to have a clean list).
Finally, it is generally not an "open" database: it is difficult to synchronize or import other HR data sources that may exist within the company.
What is a user repository?
A user repository is a list that contains the administrative data of all users who have a contractual relationship with the company.
It must be:
- Always up to date.
- Multi-source (data from the HRIS and from temporary declarations from managers, for example).
- Compatible with multiple import technologies (csv, bdd, etc.)
- Contain all the attributes necessary for arbitration on authorizations: the most obvious are arrival date and departure date (to know if he is authorized or not to have authorizations), then the function, the department... to define more precisely which authorizations (access rights...) he is authorized to have.

How to build a user repository?
- Identify information sources
The primary source of information is generally the HRIS: this is the "golden source" that contains contractual information and is therefore considered reliable.
Other users are often known by managers: a temporary worker who joins a team is declared by the manager who knows all the information necessary to create the accounts for this user: arrival date, departure date, function, etc. To simplify the manager's work, it is better to give them a way to transmit the data in a structured manner. If they have to send an email or create a ticket, they will be plunged into great perplexity: what information to communicate? What do they need at the IT department to create access?
It is better to give them a form to fill out in which all the information can be entered, this will limit the back and forth between the IT department and the manager.
- Standardize input
It is not necessary to have 50 pieces of information about a user to create their access rights, so do not ask the HRIS or managers for too much information in the form you provide them.
Ce qui est important et de pouvoir se contenter du minimum nécessaire et d'adapter les informations demandées : les champs à saisir pour un intérimaire ou un freelance ne sont pas les mêmes que pour un collaborateur qui arrive en CDI.
It is also necessary to give multiple choices for input rather than free fields, this makes it possible to standardize the information and have a clean repository.
- Automate imports
This point is the cornerstone of building a repository: automation. If the repository is updated manually, these updates will be cumbersome and of random regularity. Imports from HR sources must be automated.
- Handle exceptions
A final point is the handling of anomalies or exceptions: duplicates, true homonyms, multiple contracts, contract changes (a temporary worker who becomes permanent, etc.). These points must be dealt with in the repository: either upstream in the HRIS, or directly in the repository so that it remains of high quality.

A single user repository is the foundation for HR and especially the IT department. It's impossible to build a clean information system when you don't know who's there, who's arriving, who's leaving, and who's changing positions.
HR must perform double entry for themselves and for IT services, which increases their workload. There may be omissions, and the same is true on the IT side.
Les sources RH sont multiples et c'est un enjeu à prendre en compte. C'est pour cela que réaliser son référentiel à la main n'est pas vraiment envisageable car les mouvements sont permanents. À peine réalisé qu'il est déjà obsolète.
That's why an IAM, identity and access management tool is perfectly suited for this kind of time-consuming and essential exercise.
You can build your entitlement management strategy based on a reliable and up-to-date user repository, ensuring security for your company.





