« Il vous faut d’abord un core RH solide. » Cette phrase, vous l’entendrez dans toutes les démonstrations d’éditeurs et dans tous les appels d’offres. Le problème, c’est que chacun met derrière ce terme ce qui l’arrange. Après quinze ans à déployer des SIRH (Systèmes d’Information de gestion des Ressources Humaines), je vous propose de remettre les choses à plat, simplement, comme je le fais au premier atelier d’un projet.
Core RH : la définition en une phrase
Le core RH — littéralement « noyau RH », on dit aussi « socle RH » ou « Core HR » — est le référentiel central qui contient les données administratives de chaque salarié : identité, contrat, poste, affectation, rémunération, historique. C’est la base sur laquelle tous les autres modules du SIRH viennent se brancher.
Une image que j’utilise souvent : si le SIRH est une maison, le core RH en est les fondations. La paie, la gestion des temps, le recrutement, la formation sont les pièces de la maison. On peut vivre sans certaines pièces ; on ne construit rien sans fondations.
Ce qu’on trouve concrètement dans un core RH
Le périmètre varie un peu selon les éditeurs, mais sur mes projets, le socle regroupe presque toujours :
- Le dossier individuel du salarié : état civil, coordonnées, situation familiale, documents administratifs.
- Les contrats et avenants : type de contrat, temps de travail, période d’essai, dates clés.
- Les postes et affectations : qui occupe quel poste, dans quel service, sous la responsabilité de qui — et l’historique de ces mouvements.
- Les éléments de rémunération : salaire de base, primes récurrentes, classification conventionnelle.
- L’organigramme : la structure de l’entreprise, dont découlent les circuits de validation (qui approuve les congés de qui, par exemple).
Un point que l’on oublie souvent : le core RH gère aussi les événements du cycle de vie — embauche, mobilité, changement de temps de travail, départ. Chacun de ces événements met à jour le dossier et se propage vers les autres modules.
Core RH et SIRH : ne confondons pas le socle et la maison
La confusion est fréquente, y compris chez certains commerciaux. Le core RH n’est pas un synonyme de SIRH : c’en est le premier module, le plus structurant. J’ai détaillé l’ensemble des briques dans mon article SIRH : définition simple et concrète ; retenez ici la hiérarchie :
- Le core RH détient la donnée de référence : c’est lui qui « dit la vérité » sur le salarié.
- Les modules métiers (paie, gestion des temps et activités — la GTA —, recrutement, entretiens, formation) consomment cette donnée et renvoient la leur.
C’est pour cela qu’on parle de « donnée maître » : quand le gestionnaire modifie une adresse ou un intitulé de poste dans le socle, la modification doit se retrouver partout, sans double saisie. À l’inverse, si chaque module garde sa propre version du dossier salarié, vous n’avez pas un système : vous avez des silos qui divergent.
Pourquoi tout projet SIRH devrait commencer par le core RH
C’est la conviction que je défends sur chaque cadrage, et elle tient en trois arguments :
1. La qualité de la donnée conditionne tout le reste. Une GTA alimentée par des affectations fausses produit des plannings faux. Une paie alimentée par des contrats mal renseignés produit des bulletins faux. Corriger à la source coûte toujours moins cher que corriger dans chaque module.
2. Les référentiels doivent être tranchés une fois, pas dix. La liste des services, la nomenclature des postes, les types de contrats : ces référentiels servent à tous les modules. Les définir proprement au moment du socle évite de refaire le débat à chaque nouveau chantier.
3. C’est le socle qui porte la conformité. Droits d’accès (qui voit quoi), traçabilité des modifications, durées de conservation des données imposées par le RGPD (Règlement Général sur la Protection des Données) : tout cela se règle au niveau du référentiel central, pas module par module.
Le retour terrain de Pierre
Sur un projet dans une entreprise de services de taille intermédiaire, j’ai trouvé deux nomenclatures de postes concurrentes : celle de la paie et celle d’un ancien outil d’entretiens annuels. Personne ne savait laquelle faisait foi, et chaque service défendait la sienne. Nous avons perdu plusieurs semaines à réconcilier les deux avant même de paramétrer quoi que ce soit. Depuis, je pose la question au tout premier atelier : « si vos outils se contredisent sur un salarié, lequel a raison ? » Si la réponse n’est pas immédiate, le vrai chantier n’est pas logiciel — il est là.
Les pièges classiques au déploiement d’un core RH
Le socle a la réputation d’être le module « facile » — pas de calcul de paie, pas de compteurs de congés. C’est trompeur. Voici ce qui fait déraper les projets que je reprends :
- Sous-estimer la reprise des données. Migrer des années de dossiers dispersés entre tableurs, papier et ancien logiciel est presque toujours le chantier le plus long. Budgétez le nettoyage avant de choisir l’outil.
- Ne pas désigner de propriétaire de la donnée. Qui a le droit de modifier un poste ? Le gestionnaire RH, le manager, le salarié lui-même ? Sans règle claire, le référentiel se dégrade en quelques mois.
- Négliger l’interface avec la paie. Si la paie reste dans un outil séparé — cas très fréquent —, la qualité de l’interface entre le socle et la paie fait le succès ou l’échec du projet. C’est un sujet de conception à part entière, pas un détail technique de fin de projet.
- Vouloir tout historiser sans réfléchir. L’historique des postes, oui. Conserver indéfiniment des données personnelles sans usage défini, non — le RGPD impose de s’interroger sur les durées de conservation.
Core RH d’abord, ou module métier d’abord ?
Question légitime : certaines entreprises souffrent d’abord d’un problème de plannings ou de recrutement, pas de dossier du personnel. Faut-il quand même commencer par le socle ?
Ma réponse de praticien : le socle n’a pas besoin d’être parfait avant de lancer un module métier, mais il doit exister — même minimal. Un référentiel propre des salariés, des postes et des affectations suffit souvent à démarrer. Ce qu’il faut éviter à tout prix, c’est de déployer un module métier qui crée son propre fichier du personnel dans son coin : vous fabriquez le silo que vous mettrez des années à résorber.
FAQ — les questions qu’on me pose sur le core RH
Un logiciel de paie peut-il servir de core RH ?
En petite structure, c’est souvent le cas de fait : le dossier salarié vit dans l’outil de paie. Cela fonctionne tant que les besoins restent administratifs. Dès que vous voulez brancher des processus (entretiens, onboarding, formation), les limites apparaissent : la paie est conçue pour calculer, pas pour servir de référentiel partagé.
Le core RH est-il obligatoire dans un SIRH ?
Formellement non, fonctionnellement oui : tout SIRH repose sur un référentiel des salariés. La vraie question est de savoir s’il est assumé — un module socle désigné comme source de vérité — ou subi, éclaté entre plusieurs outils.
Combien de temps prend le déploiement d’un socle RH ?
Cela dépend presque entièrement de l’état de vos données de départ et du nombre de référentiels à trancher — c’est précisément ce qu’un cadrage sérieux permet d’estimer avant d’engager le budget.
Ce qu’il faut retenir
Le core RH est le référentiel central des données salariés, le premier module d’un SIRH et celui qui conditionne tous les autres. Il paraît simple, mais il concentre les sujets qui fâchent : qualité des données, référentiels, gouvernance, conformité. Le traiter sérieusement au début d’un projet, c’est s’épargner de le payer au triple ensuite.
Vous êtes en réflexion sur votre socle RH ou en plein choix d’outil ? Parlons-en — un regard extérieur au bon moment évite bien des nomenclatures concurrentes.